From jayk123 at hotmail.com Tue Jan 1 22:33:18 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 1 Jan 2008 21:33:18 +0000 Subject: [M3devel] efficient "safe" Modula-3? Message-ID: How can I write this in idiomatic Modula-3: date : Date.T Fmt.FN( (* heap alloc *) "%04s-%02s-%02s %02s:%02s:%02s", ARRAY OF TEXT{ (* heap alloc? easily avoided, but just over the limit *) Fmt.Int(date.year), (* heap alloc *) Fmt.Int(ORD(date.month) + 1), (* heap alloc *) Fmt.Int(date.day), (* heap alloc *) Fmt.Int(date.hour), (* heap alloc *) Fmt.Int(date.minute), (* heap alloc *) Fmt.Int(date.second) (* heap alloc *) }))); to be more like in performance to: Date_t date; /* Win32 SYSTEMTIME essentially */ char Buffer[sizeof("2008-01-01 20:29:58")]; sprintf( Buffer, "%04u-%02u-%02u %02u:%02u:%02u", date.year, ORD(date.month) + 1, date.day, date.hour, date.minute, date.second); or, ok: Date_t date; /* Win32 SYSTEMTIME essentially */ char* Buffer = (char*) malloc(sizeof("2008-01-01 20:29:58")); /* deliberate heap alloc for long lived string */ if (Buffer== NULL) ... sprintf( Buffer, "%04u-%02u-%02u %02u:%02u:%02u", date.year, ORD(date.month) + 1, date.day, date.hour, date.minute, date.second); Unnecessary heap allocations bug me. I seem to see a fair amount of tedious Modula-3 code around to avoid heap allocs,folks manually managing growing arrays instead of using something generic and efficient. Can "safe" code be efficient and convenient to write? (and yes, I know about snprintf, sprintf_s, etc.) - Jay _________________________________________________________________ The best games are on Xbox 360. Click here for a special offer on an Xbox 360 Console. http://www.xbox.com/en-US/hardware/wheretobuy/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Tue Jan 1 21:17:51 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 1 Jan 2008 20:17:51 +0000 Subject: [M3devel] time/date/version functions in Quake? Message-ID: Hi. This is per Olaf. Quake code in m3-sys\cm3\src\version.quake wants/needs the time/date like so: C:\dev2\cm3.2\m3-sys\m3quake>\cm3\bin\cm3.exe -version Critical Mass Modula-3 version d5.5.1 last updated: 2007-12-30 compiled: 2008-01-01 19:59:32 <=== configuration: \cm3\bin\cm3.cfg In UTC (universal coordinated time, also known as "greenwich mean time (GMT)")Currently this is via an application specific global variable in m3quake called "CM3_VERSION_NOW"."Currently", as in, I just did it, it is committed. (I'm impatient and impulsive and love coding, take me or leave me...) C:\dev2\cm3.2\m3-sys\m3quake>findstr /s NOW * src\QMachine.m3: "CM3_VERSION_NOW", It's only used on Windows, because I haven't yet tested elsewhere. Olaf wants to consider something more general, as I understand.Some little extra feature in Quake, new built in function(s)/variable(s) (probably function(s)).Maybe something like Unix date (er, probably less general than that)or strftime, or something. I'm skeptical that resolution to the second is useful here, seems overly precise. Please discuss/decide/spec. :)(I don't care much. I'd be content just to change the variable to a function and decide on a name that isn't ALL CAPS, though those were my own doing in the first place, as well as learning the best idiom for those few lines of code, such as hopefully to avoid the six+ extra heap allocs for the TEXTs before concating them, like something involving a small fixed sized buffer on the stack maybe? :) ) (Not clear how much "safety" a "competent programmer" needs and if it is all worth it...obviously has its place, but...) Oh, and to be a bit obnoxious -- maybe the higher level version.quake should be pushed into Modula-3 code????I mean..something like..some stamp that is applied to all binaries? You know, like on Windows, there are these nice version resources.Putting them in every file automatically would be nice, unless overridden by the use -- typical override wouldbe provision of all Win32 resources, and hopefully that'd include a version resource. I /know/ I am confusing issues -- universal injection of such data, vs. implementation in Quake vs. Modula-3.Any conventions/mechanisms for other platforms?The Mac has/had version resources, but these days that'd probably involve creating 10 more files and directories per executable.I can research it though easily enough.. On Windows it would be an extra dependency, on a resource compiler, but they are ubuiquitous.They come with all commercial toolsets and many free ones. - Jay _________________________________________________________________ Don't get caught with egg on your face. Play Chicktionary! http://club.live.com/chicktionary.aspx?icid=chick_wlhmtextlink1_dec -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Wed Jan 2 11:18:33 2008 From: jayk123 at hotmail.com (Jay) Date: Wed, 2 Jan 2008 10:18:33 +0000 Subject: [M3devel] FW: time/date/version functions in Quake? Message-ID: The one I got from m3devel had most newlines removed such as to be hard to read, AND got /slightly/ truncated (just the signature). Let's try this. I will change the global to datetime() shortly. I was thinking of GetDateTimeStamp() but others probably don't like my verbosity and it is not consistent with the terse lowercasing "Romans". - Jay From: jayk123 at hotmail.comTo: m3devel at elegosoft.comCC: wagner at elegosoft.comSubject: time/date/version functions in Quake?Date: Tue, 1 Jan 2008 20:17:51 +0000 Hi. This is per Olaf. Quake code in m3-sys\cm3\src\version.quake wants/needs the time/date like so: C:\dev2\cm3.2\m3-sys\m3quake>\cm3\bin\cm3.exe -version Critical Mass Modula-3 version d5.5.1 last updated: 2007-12-30 compiled: 2008-01-01 19:59:32 <=== configuration: \cm3\bin\cm3.cfg In UTC (universal coordinated time, also known as "greenwich mean time (GMT)")Currently this is via an application specific global variable in m3quake called "CM3_VERSION_NOW"."Currently", as in, I just did it, it is committed. (I'm impatient and impulsive and love coding, take me or leave me...) C:\dev2\cm3.2\m3-sys\m3quake>findstr /s NOW * src\QMachine.m3: "CM3_VERSION_NOW", It's only used on Windows, because I haven't yet tested elsewhere.Olaf wants to consider something more general, as I understand.Some little extra feature in Quake, new built in function(s)/variable(s) (probably function(s)).Maybe something like Unix date (er, probably less general than that)or strftime, or something.I'm skeptical that resolution to the second is useful here, seems overly precise.Please discuss/decide/spec. :)(I don't care much. I'd be content just to change the variable to a function and decide on a name that isn't ALL CAPS,though those were my own doing in the first place, as well as learning the best idiom for those few lines of code,such as hopefully to avoid the six+ extra heap allocs for the TEXTs before concating them, like something involvinga small fixed sized buffer on the stack maybe? :) ) (Not clear how much "safety" a "competent programmer"needs and if it is all worth it...obviously has its place, but...)Oh, and to be a bit obnoxious -- maybe the higher level version.quake should be pushed into Modula-3 code????I mean..something like..some stamp that is applied to all binaries?You know, like on Windows, there are these nice version resources.Putting them in every file automatically would be nice, unless overridden by the use -- typical override wouldbe provision of all Win32 resources, and hopefully that'd include a version resource. I /know/ I am confusing issues -- universal injection of such data, vs. implementation in Quake vs. Modula-3.Any conventions/mechanisms for other platforms?The Mac has/had version resources, but these days that'd probably involve creating 10 more files and directories per executable.I can research it though easily enough..On Windows it would be an extra dependency, on a resource compiler, but they are ubuiquitous.They come with all commercial toolsets and many free ones. - Jay _________________________________________________________________ The best games are on Xbox 360. Click here for a special offer on an Xbox 360 Console. http://www.xbox.com/en-US/hardware/wheretobuy/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Wed Jan 2 11:22:28 2008 From: jayk123 at hotmail.com (Jay) Date: Wed, 2 Jan 2008 10:22:28 +0000 Subject: [M3devel] FW: "where to root archives?" In-Reply-To: <20071230162432.C498A10D4596@birch.elegosoft.com> References: <20071230162432.C498A10D4596@birch.elegosoft.com> Message-ID: More messed up formating in the first copy I got from m3devel. I'm going to have to send things to myself first, or experiment to see how to avoid newline deletion. I often add spaces to the start/end of lines to avoid this problem. It's sad that mere email doesn't really work... :( I realize wordwrap vs. linejoin vs. leaveonly are hard to decide about... - Jay From: jayk123 at hotmail.comTo: m3devel at elegosoft.comSubject: "where to root archives?"Date: Mon, 31 Dec 2007 11:04:53 +0000 "where to root archives?"Maybe this is along the lines of "how to format my code?"Religous and unanswerable and strong proponents of every answer?but:A) *.zip|*.tar.gz|*.tar.bz2 shall be named cm3.* or B) cm3-.* ok, no question here, B is it.And shall contain the structure: 1) more than one file/directory at the root bin/cm3(.exe) pkg/libm3/...or 2) root contains only one directory, and it has a version in its name (and target probably) cm3-/bin/cm3(.exe) cm3-/pkg/libm3/.. or 3) root contains only one directory, with no version in its name cm3/bin/cm3(.exe) cm3/pkg/libm3/.. #1 is what the current cminstall-using distributions use I believe.Since it is wrapped by an installer, doesn't really matter.Note though that the enclosing archive is also formed this way I think, but with fewer than 10 files.It seems clearly the worst, unless you know about the tar -C or unzip -d switches, though tar -C doesn'tcreate the output directory, unzip -d does.#2 is VERY popular and tempting for me#3 is what the Win32 builds use currently (scripts/win/make-dist.cmd) It has the advantage of being more directly useable. cd \ unzip cm3-.zip and it goes into \cm3, a reasonable default, but could be preexisting (unzip does prompt I think) If it went to cm3-version, you'd probably want to either rename it, or create a link to it, Window having varying support for different types of links on different versions, not sure if use is widespread. fsutil hardlink create creates file hard links on XP+ mklink creates hardlinks and symlinks on Vista+ probably only file hardlinks and file or directory symlinks At some point, directory links were avoided because a) not required by Posix? b) allows creating cycles I see cycles now on my default installs and have crashed stuff as a result. :( junction from www.sysinternals.com creates directory linkes on...Win2000+? (This is all NTFS only of course, or over SMB to other file systems; actually stupid fsutil demands a local file system, even though underlying CreateHardLink works over SMB..) #2 seems safer, and user can immediatley rename to #3 after extraction.Oh, and in the Explorer GUI, the default is to extract in a directory with the same name as the basename of the archive.That makes #1 slightly better and the others slightly worse. Inevitably it seems the command line is doomed to always check before extracting anyway.. unzip -l foo.zip | more tar tfz foo.tar.gz | more Besides that, it still impresses and bugs me how much smaller .tar.bz2 is vs. anything else...but the Explorer support or .zip filesis also somewhat compelling...except that you have to use the command line with CM3 anyway.... - Jay The best games are on Xbox 360. Click here for a special offer on an Xbox 360 Console. Get it now! _________________________________________________________________ i?m is proud to present Cause Effect, a series about real people making a difference. http://im.live.com/Messenger/IM/MTV/?source=text_Cause_Effect -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Wed Jan 2 12:21:48 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 2 Jan 2008 12:21:48 +0100 Subject: [M3devel] cvs question: how to know what I have changed on my machine? In-Reply-To: References: <20071230163328.GB5689@elegosoft.com> Message-ID: <20080102112147.GA12332@elegosoft.com> On Mon, Dec 31, 2007 at 09:48:26AM +0000, Jay wrote: > > I swear I looked for this on the web, several times. :) > What is the right/fast way to see what I have changed in cvs? > Is it really to go to the top of the tree and say cvs diff? > Some source control system I have used, makes "checked in" files > read only, requires you to "check out", and keeps track of what > you checked out. > This model seems quite nice. cvs works recursively from the current directory by default. To check what has changed you use cvs -nq up which simulates an update and lets you know the status of changes. To get more details, you use cvs -q diff -u [files] | less This is of course what I do most of the times. There may be other ways. > There is a fallback if the network is needed and not available. > It is a little annoying, the inevitable failed save, but it is well > worth it. CVS use an optimistic approach wrt. locking, and it works well in practice. Locks or watches can be set if one really wants to, but this needs the cooperation of all users. See `cvs edit' and `cvs watchers' for details. > I've been doing cvs diff but it seem terribly inefficient. > Same question for Subversion, though I haven't looked. > It at least seems to rapidly know what I have changed, on my puny > tree, > and I know it also saves away all the originals, so diff is a client > only operation. In Subversion, diff is a client operation wrt. the base vesion you checked out, because that is held as backup copy in your workspace. This leads to workspaces which occupy twice the amount of space, but is sometimes worth the effort. > Oh another question -- how to view history? In CVS, the history for one file is called log. Use `cvs log file' to view it. To get a complete history of changes, use the cvs2cl utility, which accumulates changes recursively into ChangeLog files. It's what you can see at http://modula3.elegosoft.com/cm3/ChangeLog for the cm3 repository. > Like, what i keep doing is navigating to individual files on the web. > It's fairly tedious. > It'd be nice if checkins at right about the same time, with the same > comment, > where packaged up in the ui, like Perforce (well, for it, it is just > one change).... > I usually look at the diffs after commit, besides before. I'd suggest to do commits at package level (to always have a consistent version checked-in) and look at the diffs before commit. There are some more suggestions in http://modula3.elegosoft.com/cm3/cm3-cm-rules.html Olaf > Thanks, > - Jay > _________________________________________________________________ > > Share life as it happens with the new Windows Live. Share now! -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From lemming at henning-thielemann.de Wed Jan 2 12:20:14 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Wed, 02 Jan 2008 12:20:14 +0100 (CET) Subject: [M3devel] cvs question: how to know what I have changed on my machine? In-Reply-To: References: <20071230163328.GB5689@elegosoft.com> Message-ID: On Mon, 31 Dec 2007, Jay wrote: > I swear I looked for this on the web, several times. :) > What is the right/fast way to see what I have changed in cvs? > Is it really to go to the top of the tree and say cvs diff? Yes, if you want to see the lines which changed. Otherwise 'status' gives more of an overview. I rarely use that, but most oftenly type just 'update' because that marks all modified files with 'M' and added files with 'A'. From wagner at elegosoft.com Wed Jan 2 12:24:51 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 2 Jan 2008 12:24:51 +0100 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: References: <20071230162432.C498A10D4596@birch.elegosoft.com> Message-ID: <20080102112451.GB12332@elegosoft.com> On Mon, Dec 31, 2007 at 10:44:37AM +0000, Jay wrote: > > Olaf, > 1) I PERSONALLY really don't like hidden files. > Most things that people hide aren't worth hiding and might be worth > seeing. > Rename the . file you create? > Besides that, get this.. > I have a low end Western Digital NAS. > It runs Linux but it's very much a "sealed box" "appliance". > The source to the thing is available of course. > It has files that start with dot. > They show as hidden -- and they cannot be unhidden. > This caused me problems trying to copy the source over itself, since > on Windows "hidden" is somewhat "protected", kind of like "read only". > So that just makes me further dislike this notion. > 2) You created the .datenow file outside the output directory on > purpose? > So it doesn't get cleaned as often? No, I just used existing quake code there; I've got no objection to change name and location. The code got copied from DCVS and in turn from CVSup. I just recycled 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 Wed Jan 2 12:28:03 2008 From: jayk123 at hotmail.com (Jay) Date: Wed, 2 Jan 2008 11:28:03 +0000 Subject: [M3devel] cvs question: how to know what I have changed on my machine? In-Reply-To: <20080102112147.GA12332@elegosoft.com> References: <20071230163328.GB5689@elegosoft.com> <20080102112147.GA12332@elegosoft.com> Message-ID: I look before and after, fyi, not just after, and do strive for coherence, within the limits of CVS (I think it's still only one file at a time, rapidly, one right after the other). Thanks for the other tips. cvs diff seems so inefficient. SVN's double diskspace is definitely worthwhile vs. CVS, but the way it should REALLY work is have the files be initially read only on the client, make me "check them out", which would save a copy and save some state locally as to what is checked out. No cooperation with others should be needed here. Perforce does this all correctly.. it seems pretty obvious and simple how to impelement this well. Ok, actually Perforce doesn't save the local copy. But it does know what you checked out, so it only goes to the server for the small number of files. So nobody gets it quite right, that I know, that I have used, yet, really, it seems so obvious and simple and inefficient and convenient...... sorry about the annoying ad, it's not my doing > Date: Wed, 2 Jan 2008 12:21:48 +0100> To: jayk123 at hotmail.com> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] cvs question: how to know what I have changed on my machine?> From: wagner at elegosoft.com> > On Mon, Dec 31, 2007 at 09:48:26AM +0000, Jay wrote:> > > > I swear I looked for this on the web, several times. :)> > What is the right/fast way to see what I have changed in cvs?> > Is it really to go to the top of the tree and say cvs diff?> > Some source control system I have used, makes "checked in" files> > read only, requires you to "check out", and keeps track of what> > you checked out.> > This model seems quite nice.> > cvs works recursively from the current directory by default.> To check what has changed you use> > cvs -nq up> > which simulates an update and lets you know the status of changes.> > To get more details, you use> > cvs -q diff -u [files] | less> > This is of course what I do most of the times. There may be other> ways.> > > There is a fallback if the network is needed and not available.> > It is a little annoying, the inevitable failed save, but it is well> > worth it.> > CVS use an optimistic approach wrt. locking, and it works well in> practice. Locks or watches can be set if one really wants to, but> this needs the cooperation of all users. See `cvs edit' and> `cvs watchers' for details.> > > I've been doing cvs diff but it seem terribly inefficient.> > Same question for Subversion, though I haven't looked.> > It at least seems to rapidly know what I have changed, on my puny> > tree,> > and I know it also saves away all the originals, so diff is a client> > only operation.> > In Subversion, diff is a client operation wrt. the base vesion you> checked out, because that is held as backup copy in your workspace.> This leads to workspaces which occupy twice the amount of space,> but is sometimes worth the effort.> > > Oh another question -- how to view history?> > In CVS, the history for one file is called log. Use `cvs log file' to> view it. To get a complete history of changes, use the cvs2cl> utility, which accumulates changes recursively into ChangeLog files.> It's what you can see at http://modula3.elegosoft.com/cm3/ChangeLog> for the cm3 repository.> > > Like, what i keep doing is navigating to individual files on the web.> > It's fairly tedious.> > It'd be nice if checkins at right about the same time, with the same> > comment,> > where packaged up in the ui, like Perforce (well, for it, it is just> > one change)....> > I usually look at the diffs after commit, besides before.> > I'd suggest to do commits at package level (to always have a> consistent version checked-in) and look at the diffs before commit.> There are some more suggestions in > > http://modula3.elegosoft.com/cm3/cm3-cm-rules.html> > Olaf> > 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 _________________________________________________________________ Share life as it happens with the new Windows Live. http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_122007 -------------- next part -------------- An HTML attachment was scrubbed... URL: From lemming at henning-thielemann.de Wed Jan 2 12:28:18 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Wed, 02 Jan 2008 12:28:18 +0100 (CET) Subject: [M3devel] efficient "safe" Modula-3? In-Reply-To: References: Message-ID: On Tue, 1 Jan 2008, Jay wrote: > How can I write this in idiomatic Modula-3: > date : Date.T Fmt.FN( (* heap alloc *) "%04s-%02s-%02s %02s:%02s:%02s", ARRAY OF TEXT{ (* heap alloc? easily avoided, but just over the limit *) Fmt.Int(date.year), (* heap alloc *) Fmt.Int(ORD(date.month) + 1), (* heap alloc *) Fmt.Int(date.day), (* heap alloc *) Fmt.Int(date.hour), (* heap alloc *) Fmt.Int(date.minute), (* heap alloc *) Fmt.Int(date.second) (* heap alloc *) }))); I think that this solution is the most elegant one can do. It's still not entirely safe, because the number of arguments may not match the number of placeholders in the format string. GCC checks this for printf and friends, but I'm afraid this is restricted to the standard format strings. Even more safe, but maybe less readable and less efficient is Fmt.Int(date.year) & "-" & Fmt.Int(date.month+1) & "-" ... People have even invented dependently typed languages in order to get functions like printf typed in a statically safe manner: http://en.wikipedia.org/wiki/Cayenne_(programming_language) From mika at async.caltech.edu Wed Jan 2 13:47:24 2008 From: mika at async.caltech.edu (Mika Nystrom) Date: Wed, 02 Jan 2008 04:47:24 -0800 Subject: [M3devel] efficient "safe" Modula-3? In-Reply-To: Your message of "Wed, 02 Jan 2008 12:28:18 +0100." Message-ID: <200801021247.m02ClO9D076834@camembert.async.caltech.edu> Well it's hard (i.e., impossible) to do a safe sprintf in Modula-3 that doesn't require heap allocations. Fast idiomatic Modula-3 would involve using procedures to append to an ARRAY OF CHAR, and then passing it a SUBARRAY as you go down the string. If the format string is constant, as it is in most cases, why don't you write a printf compiler? :) Something that can write to a Wr.T, maybe. By the way, from the point of view of performance, the worst piece of the Modula-3 system that I have found is Scan.LongReal. It's horrid! (At least with PM3, but I think CM3 still has problems.) The libraries I have that need to read lots of numbers from disk files use the C routines strtod and strtol for that reason. The performance loss here, in my experience, dwarfs any memory allocator/garbage collector performance issues from the code you attached... Mika Henning Thielemann writes: > >On Tue, 1 Jan 2008, Jay wrote: > >> How can I write this in idiomatic Modula-3: > >> date : Date.T Fmt.FN( (* heap alloc *) "%04s-%02s-%02s %02s:%02s:%02s", ARRAY OF TEXT{ (* heap alloc? easily avoided, but just over t >he limit *) Fmt.Int(date.year), (* heap alloc *) Fmt.Int(ORD(date.month) + 1), (* heap alloc *) Fmt.Int(date.day), (* heap alloc *) Fmt.In >t(date.hour), (* heap alloc *) Fmt.Int(date.minute), (* heap alloc *) Fmt.Int(date.second) (* heap alloc *) }))); > > I think that this solution is the most elegant one can do. It's still not >entirely safe, because the number of arguments may not match the number of >placeholders in the format string. GCC checks this for printf and friends, >but I'm afraid this is restricted to the standard format strings. > Even more safe, but maybe less readable and less efficient is > Fmt.Int(date.year) & "-" & Fmt.Int(date.month+1) & "-" ... > > People have even invented dependently typed languages in order to get >functions like printf typed in a statically safe manner: > http://en.wikipedia.org/wiki/Cayenne_(programming_language) From rcoleburn at scires.com Wed Jan 2 17:31:54 2008 From: rcoleburn at scires.com (Randy Coleburn) Date: Wed, 02 Jan 2008 11:31:54 -0500 Subject: [M3devel] M3 concerns Message-ID: <477B7629.1E75.00D7.1@scires.com> I've seen quite a number of m3commit and m3devel messages lately. Many of these give the appearance of "thinking out loud" with various commits followed by apparent reversals. In many cases the m3commit log messages are terse and don't give the rationale behind the change. For those of us in the M3 community who rely upon the stability of the libraries and core M3 principles, these types of messages cause concern. While I appreciate everyone's efforts to move forward, I don't want to abandon the great care that went into formulating this language. Question: As various people make contributions and changes, is there any group of folks who is verifying that the changes don't break existing code or core principles? Another idea would be to have a series of test batteries that have to be passed before changes can be accepted. I know of a number of projects where many people contribute, but the contributions have to be vetted by passing some tests. Without these types of controls, I fear that good forward progress will inevitably be hampered or compromised by changes made by someone who hasn't completely thought out and tested the ramifications of those changes. For example, I've tried to get cm3 working for me on Windows XP several times. I still can't seem to get the "current" system to build correctly on XP. In the past, I have on occasion gotten the "system" to build, but then some of my programs don't work correctly when rebuilt using the new cm3. Thus, some changes somewhere have "broken" my code, yet all of my code uses the "safe" subset of the language. If I go back to my old reliable cm3 version 4.1 (the last one put out before Critical Mass, Inc. threw in the towel), my code compiles and works, even on Windows XP, even using Trestle, FormsVBT, NetObj, cross-platform pickles (e.g., pickles shared between Windows & Unix boxes), etc.! Much of my code was originally developed under Windows NT, so I think it is a tribute to the original language developers that my code and their compiler work through various OS version upgrades (NT, 2000, XP) and changes to the underlying C/C++ compilers used to build the core components. I would appreciate constructive feedback on this topic. Regards, Randy Coleburn Randy C. Coleburn, CISSP Senior Systems Engineer, Communications, Networks, & Electronics Division (CNE) Corporate & Atlanta Information Systems Security Manager (ISSM) Scientific Research Corporation 2300 Windy Ridge Parkway, Suite 400 South, Atlanta, Georgia 30339 voice: (770) 989-9464, email: RColeburn at SciRes.com, fax: (770) 989-9497 Quality Policy: "SRC CNE Division is committed to delivering continually improving research & engineering excellence that meets or exceeds customer requirements." -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Wed Jan 2 19:36:10 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 2 Jan 2008 13:36:10 -0500 Subject: [M3devel] M3 concerns In-Reply-To: <477B7629.1E75.00D7.1@scires.com> References: <477B7629.1E75.00D7.1@scires.com> Message-ID: On Jan 2, 2008, at 11:31 AM, Randy Coleburn wrote: > I've seen quite a number of m3commit and m3devel messages lately. > Many of these give the appearance of "thinking out loud" with > various commits followed by apparent reversals. In many cases the > m3commit log messages are terse and don't give the rationale behind > the change. Yes, I agree. Also, I tend to avoid committing multiple small patches and rather defer until I have had a chance to test everything and let it stabilize, before checking in as one single commit. So, less frequent, coherent commits, are preferable to many smaller, incoherent commits. > For those of us in the M3 community who rely upon the stability of > the libraries and core M3 principles, these types of messages cause > concern. While I appreciate everyone's efforts to move forward, I > don't want to abandon the great care that went into formulating > this language. Indeed. > Question: As various people make contributions and changes, is > there any group of folks who is verifying that the changes don't > break existing code or core principles? Another idea would be to > have a series of test batteries that have to be passed before > changes can be accepted. I know of a number of projects where many > people contribute, but the contributions have to be vetted by > passing some tests. I try to verify that all my code doesn't break existing code (though I admit GC/thread subsystems can be devilish to completely verify). We do need to have some sort of procedures in place for deciding what commits make sense and should go into the CVS head. Tentative work should always be done to a CVS branch until it can be vetted. > Without these types of controls, I fear that good forward progress > will inevitably be hampered or compromised by changes made by > someone who hasn't completely thought out and tested the > ramifications of those changes. Agree! > For example, I've tried to get cm3 working for me on Windows XP > several times. I still can't seem to get the "current" system to > build correctly on XP. In the past, I have on occasion gotten the > "system" to build, but then some of my programs don't work > correctly when rebuilt using the new cm3. Thus, some changes > somewhere have "broken" my code, yet all of my code uses the "safe" > subset of the language. If I go back to my old reliable cm3 > version 4.1 (the last one put out before Critical Mass, Inc. threw > in the towel), my code compiles and works, even on Windows XP, even > using Trestle, FormsVBT, NetObj, cross-platform pickles (e.g., > pickles shared between Windows & Unix boxes), etc.! Much of my > code was originally developed under Windows NT, so I think it is a > tribute to the original language developers that my code and their > compiler work through various OS version upgrades (NT, 2000, XP) > and changes to the underlying C/C++ compilers used to build the > core components. I thought we were getting closer to stability in this regard, though I am not a heavy Windows user and have never built CM3 on Windows. > I would appreciate constructive feedback on this topic. It would be great to have a set of regression tests run on a regular basis to ensure that checkins don't break things. What good candidates do we have? cm3 itself I suppose. Any others? I can probably devise a couple of thread and GC stress tests pretty easily. Anyone willing to set up a testing regime? I have machines that could be used to test on several supported platforms on a nightly basis even. > > Regards, > Randy Coleburn > > > Randy C. Coleburn, CISSP > Senior Systems Engineer, Communications, Networks, & Electronics > Division (CNE) > Corporate & Atlanta Information Systems Security Manager (ISSM) > Scientific Research Corporation > 2300 Windy Ridge Parkway, Suite 400 South, Atlanta, Georgia 30339 > voice: (770) 989-9464, email: RColeburn at SciRes.com, fax: (770) > 989-9497 > > Quality Policy: "SRC CNE Division is committed to delivering > continually improving research & engineering excellence that meets > or exceeds customer requirements." From rcoleburn at scires.com Wed Jan 2 20:32:02 2008 From: rcoleburn at scires.com (Randy Coleburn) Date: Wed, 02 Jan 2008 14:32:02 -0500 Subject: [M3devel] M3 concerns In-Reply-To: References: <477B7629.1E75.00D7.1@scires.com> Message-ID: <477BA060.1E75.00D7.1@scires.com> Tony: I'm thinking that with a little work we could set up an automated set of builds and regression tests that would make available a "scoreboard" via a web interface where everyone could see the results. That way, as problems are uncovered, folks could begin working on them. For an example of how all this works, take a look at the scoreboard set up for the ACE+TAO+CIAO projects. An overview is at http://www.dre.vanderbilt.edu/Scoreboard/ . They provide instructions for setting up your own daily build and scoreboard at https://svn.dre.vanderbilt.edu/viewvc/autobuild/trunk/README?revision=HEAD . You can see the scoreboard in operation at http://remedy.nl/ . Regards, Randy >>> Tony Hosking 1/2/2008 1:36 PM >>> On Jan 2, 2008, at 11:31 AM, Randy Coleburn wrote: > I've seen quite a number of m3commit and m3devel messages lately. > Many of these give the appearance of "thinking out loud" with > various commits followed by apparent reversals. In many cases the > m3commit log messages are terse and don't give the rationale behind > the change. Yes, I agree. Also, I tend to avoid committing multiple small patches and rather defer until I have had a chance to test everything and let it stabilize, before checking in as one single commit. So, less frequent, coherent commits, are preferable to many smaller, incoherent commits. > For those of us in the M3 community who rely upon the stability of > the libraries and core M3 principles, these types of messages cause > concern. While I appreciate everyone's efforts to move forward, I > don't want to abandon the great care that went into formulating > this language. Indeed. > Question: As various people make contributions and changes, is > there any group of folks who is verifying that the changes don't > break existing code or core principles? Another idea would be to > have a series of test batteries that have to be passed before > changes can be accepted. I know of a number of projects where many > people contribute, but the contributions have to be vetted by > passing some tests. I try to verify that all my code doesn't break existing code (though I admit GC/thread subsystems can be devilish to completely verify). We do need to have some sort of procedures in place for deciding what commits make sense and should go into the CVS head. Tentative work should always be done to a CVS branch until it can be vetted. > Without these types of controls, I fear that good forward progress > will inevitably be hampered or compromised by changes made by > someone who hasn't completely thought out and tested the > ramifications of those changes. Agree! > For example, I've tried to get cm3 working for me on Windows XP > several times. I still can't seem to get the "current" system to > build correctly on XP. In the past, I have on occasion gotten the > "system" to build, but then some of my programs don't work > correctly when rebuilt using the new cm3. Thus, some changes > somewhere have "broken" my code, yet all of my code uses the "safe" > subset of the language. If I go back to my old reliable cm3 > version 4.1 (the last one put out before Critical Mass, Inc. threw > in the towel), my code compiles and works, even on Windows XP, even > using Trestle, FormsVBT, NetObj, cross-platform pickles (e.g., > pickles shared between Windows & Unix boxes), etc.! Much of my > code was originally developed under Windows NT, so I think it is a > tribute to the original language developers that my code and their > compiler work through various OS version upgrades (NT, 2000, XP) > and changes to the underlying C/C++ compilers used to build the > core components. I thought we were getting closer to stability in this regard, though I am not a heavy Windows user and have never built CM3 on Windows. > I would appreciate constructive feedback on this topic. It would be great to have a set of regression tests run on a regular basis to ensure that checkins don't break things. What good candidates do we have? cm3 itself I suppose. Any others? I can probably devise a couple of thread and GC stress tests pretty easily. Anyone willing to set up a testing regime? I have machines that could be used to test on several supported platforms on a nightly basis even. > > Regards, > Randy Coleburn > > > Randy C. Coleburn, CISSP > Senior Systems Engineer, Communications, Networks, & Electronics > Division (CNE) > Corporate & Atlanta Information Systems Security Manager (ISSM) > Scientific Research Corporation > 2300 Windy Ridge Parkway, Suite 400 South, Atlanta, Georgia 30339 > voice: (770) 989-9464, email: RColeburn at SciRes.com, fax: (770) > 989-9497 > > Quality Policy: "SRC CNE Division is committed to delivering > continually improving research & engineering excellence that meets > or exceeds customer requirements." -------------- next part -------------- An HTML attachment was scrubbed... URL: From kschleiser at elego.de Wed Jan 2 21:51:00 2008 From: kschleiser at elego.de (Kaspar Schleiser) Date: Wed, 02 Jan 2008 21:51:00 +0100 Subject: [M3devel] M3 concerns In-Reply-To: <477BA060.1E75.00D7.1@scires.com> References: <477B7629.1E75.00D7.1@scires.com> <477BA060.1E75.00D7.1@scires.com> Message-ID: <477BF934.80805@elego.de> Hey all, Randy Coleburn wrote: > I'm thinking that with a little work we could set up an automated set of builds and regression tests that would make available a "scoreboard" via a web interface where everyone could see the results. That way, as problems are uncovered, folks could begin working on them. Just to let you know, we at elego have set up a tinderbox based automated build system which should be ready for production soon. Regards, Kaspar Schleiser From lemming at henning-thielemann.de Wed Jan 2 22:51:23 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Wed, 02 Jan 2008 22:51:23 +0100 (CET) Subject: [M3devel] M3 concerns In-Reply-To: References: <477B7629.1E75.00D7.1@scires.com> Message-ID: On Wed, 2 Jan 2008, Tony Hosking wrote: > > I would appreciate constructive feedback on this topic. > > It would be great to have a set of regression tests run on a regular > basis to ensure that checkins don't break things. What good > candidates do we have? cm3 itself I suppose. Any others? Do you mean m3-sys/m3tests ? From mika at async.caltech.edu Thu Jan 3 01:10:42 2008 From: mika at async.caltech.edu (Mika Nystrom) Date: Wed, 02 Jan 2008 16:10:42 -0800 Subject: [M3devel] M3 concerns In-Reply-To: Your message of "Wed, 02 Jan 2008 14:32:02 EST." <477BA060.1E75.00D7.1@scires.com> Message-ID: <200801030010.m030AgKN099099@camembert.async.caltech.edu> I can happily volunteer FreeBSD 4.x and 5.x (i386) systems, Windows 2000, and, I believe, Digital Unix 4.0 systems to run nightly (daily?) builds. Unfortunately I am of course a bit short on Time, which is probably what's lacking the most, anyhow... Mika "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. > >--=__Part103621A2.1__= >Content-Type: text/plain; charset=US-ASCII >Content-Transfer-Encoding: quoted-printable > >Tony: >=20 >I'm thinking that with a little work we could set up an automated set of = >builds and regression tests that would make available a "scoreboard" via a = >web interface where everyone could see the results. That way, as problems = >are uncovered, folks could begin working on them. >=20 >For an example of how all this works, take a look at the scoreboard set up = >for the ACE+TAO+CIAO projects. An overview is at http://www.dre.vanderbilt= >.edu/Scoreboard/ . They provide instructions for setting up your own = >daily build and scoreboard at https://svn.dre.vanderbilt.edu/viewvc/autobui= >ld/trunk/README?revision=3DHEAD . You can see the scoreboard in operation = >at http://remedy.nl/ . >=20 >Regards, >Randy > >>>> Tony Hosking 1/2/2008 1:36 PM >>> > >On Jan 2, 2008, at 11:31 AM, Randy Coleburn wrote: > >> I've seen quite a number of m3commit and m3devel messages lately. =20 >> Many of these give the appearance of "thinking out loud" with =20 >> various commits followed by apparent reversals. In many cases the =20 >> m3commit log messages are terse and don't give the rationale behind =20 >> the change. > >Yes, I agree. Also, I tend to avoid committing multiple small =20 >patches and rather defer until I have had a chance to test everything =20 >and let it stabilize, before checking in as one single commit. So, =20 >less frequent, coherent commits, are preferable to many smaller, =20 >incoherent commits. > >> For those of us in the M3 community who rely upon the stability of =20 >> the libraries and core M3 principles, these types of messages cause =20 >> concern. While I appreciate everyone's efforts to move forward, I =20 >> don't want to abandon the great care that went into formulating =20 >> this language. > >Indeed. > >> Question: As various people make contributions and changes, is =20 >> there any group of folks who is verifying that the changes don't =20 >> break existing code or core principles? Another idea would be to =20 >> have a series of test batteries that have to be passed before =20 >> changes can be accepted. I know of a number of projects where many =20 >> people contribute, but the contributions have to be vetted by =20 >> passing some tests. > >I try to verify that all my code doesn't break existing code (though =20 >I admit GC/thread subsystems can be devilish to completely verify). =20 >We do need to have some sort of procedures in place for deciding what =20 >commits make sense and should go into the CVS head. Tentative work =20 >should always be done to a CVS branch until it can be vetted. > >> Without these types of controls, I fear that good forward progress =20 >> will inevitably be hampered or compromised by changes made by =20 >> someone who hasn't completely thought out and tested the =20 >> ramifications of those changes. > >Agree! > >> For example, I've tried to get cm3 working for me on Windows XP =20 >> several times. I still can't seem to get the "current" system to =20 >> build correctly on XP. In the past, I have on occasion gotten the =20 >> "system" to build, but then some of my programs don't work =20 >> correctly when rebuilt using the new cm3. Thus, some changes =20 >> somewhere have "broken" my code, yet all of my code uses the "safe" =20 >> subset of the language. If I go back to my old reliable cm3 =20 >> version 4.1 (the last one put out before Critical Mass, Inc. threw =20 >> in the towel), my code compiles and works, even on Windows XP, even =20 >> using Trestle, FormsVBT, NetObj, cross-platform pickles (e.g., =20 >> pickles shared between Windows & Unix boxes), etc.! Much of my =20 >> code was originally developed under Windows NT, so I think it is a =20 >> tribute to the original language developers that my code and their =20 >> compiler work through various OS version upgrades (NT, 2000, XP) =20 >> and changes to the underlying C/C++ compilers used to build the =20 >> core components. > >I thought we were getting closer to stability in this regard, though =20 >I am not a heavy Windows user and have never built CM3 on Windows. > >> I would appreciate constructive feedback on this topic. > >It would be great to have a set of regression tests run on a regular =20 >basis to ensure that checkins don't break things. What good =20 >candidates do we have? cm3 itself I suppose. Any others? I can =20 >probably devise a couple of thread and GC stress tests pretty =20 >easily. Anyone willing to set up a testing regime? I have machines =20 >that could be used to test on several supported platforms on a =20 >nightly basis even. > >> >> Regards, >> Randy Coleburn >> >> >> Randy C. Coleburn, CISSP >> Senior Systems Engineer, Communications, Networks, & Electronics =20 >> Division (CNE) >> Corporate & Atlanta Information Systems Security Manager (ISSM) >> Scientific Research Corporation >> 2300 Windy Ridge Parkway, Suite 400 South, Atlanta, Georgia 30339 >> voice: (770) 989-9464, email: RColeburn at SciRes.com, fax: (770) =20 >> 989-9497 >> >> Quality Policy: "SRC CNE Division is committed to delivering =20 >> continually improving research & engineering excellence that meets =20 >> or exceeds customer requirements." > > > >--=__Part103621A2.1__= >Content-Type: text/html; charset=US-ASCII >Content-Transfer-Encoding: quoted-printable >Content-Description: HTML > > >"> > > >
Tony:
>
 
>
I'm thinking that with a little work we could set up an automated set = >of builds and regression tests that would make available a "scoreboard" = >via a web interface where everyone could see the results.  That way, = >as problems are uncovered, folks could begin working on them.
>
 
>
For an example of how all this works, take a look at the scoreboard = >set up for the ACE+TAO+CIAO projects.  An overview is at tp://www.dre.vanderbilt.edu/Scoreboard/">http://www.dre.vanderbilt.edu/Scor= >eboard/ .  They provide instructions for setting up your own = >daily build and scoreboard at wvc/autobuild/trunk/README?revision=3DHEAD">https://svn.dre.vanderbilt.edu/= >viewvc/autobuild/trunk/README?revision=3DHEAD .  You can see = >the scoreboard in operation at http://remedy.= >nl/ .
>
 
>
Regards,
>
Randy
>

>>> Tony Hosking <hosking at cs.purdue.edu> 1/2/2008 = >1:36 PM >>>

On Jan 2, 2008, at 11:31 AM, Randy Coleburn = >wrote:

> I've seen quite a number of m3commit and m3devel = >messages lately.  
> Many of these give the appearance of = >"thinking out loud" with 
> various commits followed by = >apparent reversals.  In many cases the 
> m3commit log = >messages are terse and don't give the rationale behind 
> the = >change.

Yes, I agree.  Also, I tend to avoid committing = >multiple small 
patches and rather defer until I have had a = >chance to test everything 
and let it stabilize, before checking = >in as one single commit.   So, 
less frequent, coherent = >commits, are preferable to many smaller, 
incoherent commits.
<= >BR>>  For those of us in the M3 community who rely upon the = >stability of 
> the libraries and core M3 principles, these = >types of messages cause 
> concern.  While I appreciate = >everyone's efforts to move forward, I 
> don't want to abandon = >the great care that went into formulating 
> this language.
= >
Indeed.

>  Question:  As various people make = >contributions and changes, is 
> there any group of folks who = >is verifying that the changes don't 
> break existing code or = >core principles?  Another idea would be to 
> have a = >series of test batteries that have to be passed before 
> = >changes can be accepted.  I know of a number of projects where = >many 
> people contribute, but the contributions have to be = >vetted by 
> passing some tests.

I try to verify that = >all my code doesn't break existing code (though 
I admit = >GC/thread subsystems can be devilish to completely verify).   = >
We do need to have some sort of procedures in place for deciding = >what 
commits make sense and should go into the CVS head.  = >Tentative work 
should always be done to a CVS branch until it = >can be vetted.

>  Without these types of controls, I fear = >that good forward progress 
> will inevitably be hampered or = >compromised by changes made by 
> someone who hasn't completely= > thought out and tested the 
> ramifications of those = >changes.

Agree!

>  For example, I've tried to get = >cm3 working for me on Windows XP 
> several times.  I = >still can't seem to get the "current" system to 
> build = >correctly on XP.  In the past, I have on occasion gotten the  = >
> "system" to build, but then some of my programs don't work  = >
> correctly when rebuilt using the new cm3.  Thus, some = >changes 
> somewhere have "broken" my code, yet all of my code = >uses the "safe" 
> subset of the language.  If I go back = >to my old reliable cm3 
> version 4.1 (the last one put out = >before Critical Mass, Inc. threw 
> in the towel), my code = >compiles and works, even on Windows XP, even 
> using Trestle, = >FormsVBT, NetObj, cross-platform pickles (e.g., 
> pickles = >shared between Windows & Unix boxes), etc.!  Much of my  = >
> code was originally developed under Windows NT, so I think it is = >a 
> tribute to the original language developers that my code = >and their 
> compiler work through various OS version upgrades = >(NT, 2000, XP) 
> and changes to the underlying C/C++ = >compilers used to build the 
> core components.

I = >thought we were getting closer to stability in this regard, though  = >
I am not a heavy Windows user and have never built CM3 on Windows.
<= >BR>>  I would appreciate constructive feedback on this topic.
R>It would be great to have a set of regression tests run on a regular = >;
basis to ensure that checkins don't break things.  What = >good 
candidates do we have?  cm3 itself I suppose.  = >Any others?  I can 
probably devise a couple of thread and = >GC stress tests pretty 
easily.  Anyone willing to set up a = >testing regime? I have machines 
that could be used to test on = >several supported platforms on a 
nightly basis even.

><= >BR>> Regards,
> Randy Coleburn
>
>
> Randy C. = >Coleburn, CISSP
> Senior Systems Engineer, Communications, Networks, = >& Electronics 
> Division (CNE)
> Corporate & = >Atlanta Information Systems Security Manager (ISSM)
> Scientific = >Research Corporation
> 2300 Windy Ridge Parkway, Suite 400 South, = >Atlanta, Georgia 30339
> voice: (770) 989-9464, email: RColeburn at SciR= >es.com, fax: (770) 
> 989-9497
>
> Quality = >Policy:  "SRC CNE Division is committed to delivering 
> = >continually improving research & engineering excellence that meets = >;
> or exceeds customer requirements."


L> > >--=__Part103621A2.1__=-- From dabenavidesd at yahoo.es Thu Jan 3 04:52:51 2008 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Thu, 3 Jan 2008 04:52:51 +0100 (CET) Subject: [M3devel] cm3 winvbt concerns Message-ID: <846332.60063.qm@web27115.mail.ukl.yahoo.com> Hi all: Talking about Windows state, the gui packet (winvbt used in mentor, juno, etc, ..) needs to be checked, at least as I see the problem that Jay and maybe Randy are seeing was reported in a 2003 post on comp.lang.modula3: http://groups.google.com/group/comp.lang.modula3/browse_thread/thread/cffb2c2cfda5d9b7/a1822c17c9381925#a1822c17c9381925 Looking more closely, I think there is some code that need to be completed as is documented on the file WinContext.m3 at the procedure: PushStroke (below is a url to show you the comment on that function of dec src that is equal implemented on cm3): http://www.cs.tut.fi/lintula/manual/modula3/m3sources/html/ui/src/winvbt/WinContext.m3.html#PushStroke It says: (* * The main omission is that I don't deal with pixmaps! * * Refer back to XGC.ResolveStrokeGC to see just how much functionality * is missing! *) The comment refers to this function that is implemented in xvbt implementation: http://modula3.elegosoft.com/cm3/doc/help/gen_html/ui/src/xvbt/XGC.m3.html#ResolveStrokeGC I got into this function (PushPixmap of WinContext ) because the assert fails at WinContext.PushPixmap in the line: *** <*ASSERT*> failed. *** file "..\src\winvbt\WinContext.m3", line 165 : brush := WinGDI.CreatePatternBrush (pst.pmtable[pm].hbmp); brush gets NIL. I suspect that is because of the (pst.pmtable[pm].hbmp) argument is not correct. If you have a m3browser winnt machine (pcname named) with latest cm3, this is the url of the procedure implementation: http://pcname:3829/SWinContext.i3.PushPixmap#PushPixmap Or in the cvs online this is the source file of that function: http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/~checkout~/cm3/m3-ui/ui/src/winvbt/WinContext.m3?rev=1.1.1.2;content-type=text%2Fplain Also, the function doesn't exist on the old implementation of winvbt (of dec src): http://www.cs.tut.fi/lintula/manual/modula3/m3sources/html/ui/src/winvbt/WinContext.m3.html One can look more further, but let me know what do you think. Daniel Benavides --------------------------------- ?Chef por primera vez? - S? un mejor Cocinillas. Entra en Yahoo! Respuestas. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Thu Jan 3 23:09:22 2008 From: jayk123 at hotmail.com (Jay) Date: Thu, 3 Jan 2008 22:09:22 +0000 Subject: [M3devel] PPC_LINUX breaks Message-ID: I can't build PPC_LINUX. I can build the compiler with 5.2.6 but then stuck at building m3core with current compiler. There are several problems. Some I can fix, some stump me. This platform still uses non-PTHREADs. I figure that is worth fixing, but maybe afterward? [jay at localhost m3core]$ /tmp/make-dist/compiler_with_self/bin/cm3 -override -DROOT='/dev2/cm3' new source -> compiling Uucontext.i3 "../src/unix/linux-ppc/Uucontext.i3", line 102: syntax error: missing ']' 1 error encountered [jay at localhost m3core]$ cvs diff src/unix/linux-ppc/Uucontext.i3 Index: src/unix/linux-ppc/Uucontext.i3 =================================================================== RCS file: /usr/cvs/cm3/m3-libs/m3core/src/unix/linux-ppc/Uucontext.i3,v retrieving revision 1.1 diff -r1.1 Uucontext.i3 102c102 < vrregs: ARRAY[0..32,0..4] OF unsigned_int; --- > vrregs: ARRAY[0..32 * 4] OF unsigned_int; new source -> compiling Uucontext.i3 "../src/unix/linux-ppc/Uucontext.i3", line 92: undefined (double) "../src/unix/linux-ppc/Uucontext.i3", line 93: undefined (double) "../src/unix/linux-ppc/Uucontext.i3", line 94: undefined (unsigned_int) "../src/unix/linux-ppc/Uucontext.i3", line 102: undefined (unsigned_int) "../src/unix/linux-ppc/Uucontext.i3", line 103: undefined (unsigned_int) "../src/unix/linux-ppc/Uucontext.i3", line 104: undefined (unsigned_int) "../src/unix/linux-ppc/Uucontext.i3", line 105: undefined (unsigned_int) "../src/unix/linux-ppc/Uucontext.i3", line 149: undefined (char) "../src/unix/linux-ppc/Uucontext.i3", line 10: warning: not used (unsigned_short) "../src/unix/linux-ppc/Uucontext.i3", line 11: warning: not used (unsigned_short_int) 8 errors and 2 warnings encountered [jay at localhost m3core]$ cvs diff src/unix/linux-ppc/Uucontext.i3 Index: src/unix/linux-ppc/Uucontext.i3 =================================================================== RCS file: /usr/cvs/cm3/m3-libs/m3core/src/unix/linux-ppc/Uucontext.i3,v retrieving revision 1.1 diff -r1.1 Uucontext.i3 10,11c10,11 < IMPORT int, unsigned_long, unsigned_long_int, unsigned_short, void_star, < unsigned_short_int; --- > IMPORT int, unsigned_long, unsigned_long_int, void_star, > double, unsigned_int, char; new source -> compiling RTSignal.m3 "../src/runtime/PPC_LINUX/RTSignal.m3", line 82: undefined (Usignal.struct_sigcontext) 1 error encountered [jay at localhost m3core]$ cvs diff src/runtime/PPC_LINUX/RTSignal.m3 Index: src/runtime/PPC_LINUX/RTSignal.m3 =================================================================== RCS file: /usr/cvs/cm3/m3-libs/m3core/src/runtime/PPC_LINUX/RTSignal.m3,v retrieving revision 1.1 diff -r1.1 RTSignal.m3 10c10 < IMPORT RTError, RTProcess, Csignal, Usignal, Uprocess; --- > IMPORT RTError, RTProcess, Csignal, Usignal, Uprocess, Uucontext; 82c82 < scp : Usignal.struct_sigcontext; --- > scp : Uucontext.struct_sigcontext; new source -> compiling RTSignal.m3 "../src/runtime/PPC_LINUX/RTSignal.m3", line 85: unknown qualification '.' (eip) 1 error encountered This I looked into a while. The problem is obvious, the fix is not. For now I replaced whatever.eip with 0. Sometimes PowerPC calls eip srr0, but sometimes not. The first thing I found reading about PowerPC is that there's no instruction counter register, because it is rarely needed directly in code. But anyway, it's still need for traps/exceptions. I'll look at an old winnt.h. And then I am stuck on: new source -> compiling RTThread.m3 "../src/runtime/PPC_LINUX/RTThread.m3", line 88: unknown qualification '.' (sa_handler) "../src/runtime/PPC_LINUX/RTThread.m3", line 89: unknown qualification '.' (empty_sigset_t) "../src/runtime/PPC_LINUX/RTThread.m3", line 91: incompatible types (act) "../src/runtime/PPC_LINUX/RTThread.m3", line 91: VAR actual must be a designator (oact) "../src/runtime/PPC_LINUX/RTThread.m3", line 96: incompatible types (set) "../src/runtime/PPC_LINUX/RTThread.m3", line 96: VAR actual must be a designator (oset) "../src/runtime/PPC_LINUX/RTThread.m3", line 101: incompatible types (set) "../src/runtime/PPC_LINUX/RTThread.m3", line 101: VAR actual must be a designator (oset) "../src/runtime/PPC_LINUX/RTThread.m3", line 108: unknown qualification '.' (sigmask) 9 errors encountered The code: PROCEDURE setup_sigvtalrm (handler: Usignal.SignalHandler) = VAR x: Usignal.struct_sigaction; BEGIN x.sa_handler := LOOPHOLE (handler, Usignal.SignalActionHandler); (* line 88*) x.sa_mask := Usignal.empty_sigset_t; (*89*) x.sa_flags := Usignal.SA_RESTART; (*90*) EVAL Usignal.sigaction (Usignal.SIGVTALRM, ADR (x), NIL); (*91*) END setup_sigvtalrm; Other platforms get away without this stuff by using just "signal" which takes fewer parameters. I ASSUME PPC_LINUX as some interest in more parameters in order to implement vtalarm based threads, instead of pthreads. Usignal does define these types..unless I am looking at the wrong one. Or heck, even the obvious wrong one. Except..overrides..the local package..stuff doesn't need an override to refer to itself, right? Non-standalone binaries also don't work. I think I reported that two weeks ago. I figured that'd come afterward.. There is also: new source -> compiling Long.m3 GenWord.mg: In function `Long__Divide': GenWord.mg:13: Internal compiler error in emit_library_call_value_1, at calls.c:3684 Please submit a full bug report, with preprocessed source if appropriate. See for instructions. though I thought I had gotten past that by building m3cc. Not likely a Modula-3 problem and I could always get around it by making LONGINT only 32 bits (I think "long" is dumb in a name...). [jay at localhost m3core]$ uname -a Linux localhost.localdomain 2.6.15-rc5.ydl.1 #1 Wed Jan 4 16:25:38 EST 2006 ppc ppc ppc GNU/Linux [jay at localhost m3core]$ gcc -v Reading specs from /usr/lib/gcc/ppc64-yellowdog-linux/3.4.4/specs Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --disable-checking --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-java-awt=gtk --host=ppc64-yellowdog-linux --build=ppc64-yellowdog-linux --target=ppc64-yellowdog-linux --with-cpu=default32 Thread model: posix gcc version 3.4.4 20050721 (Yellow Dog 3.4.4-2.ydl.2) This is like Yellow Dog 4.x or so. I don't know why all the ppc64 references. This is an iBook G3 -- 32bit. I guess maybe it can build both -- oh, not that this gcc is in use. Nor do I expect it matters. - Jay _________________________________________________________________ The best games are on Xbox 360. Click here for a special offer on an Xbox 360 Console. http://www.xbox.com/en-US/hardware/wheretobuy/ From jayk123 at hotmail.com Thu Jan 3 23:51:46 2008 From: jayk123 at hotmail.com (Jay) Date: Thu, 3 Jan 2008 22:51:46 +0000 Subject: [M3devel] PPC_LINUX breaks Message-ID: I'll try upgrade.sh instead of my make-dist.py. I got the same gcc error on PPC_DRAWIN too, but that was definitely without building m3cc. Also from an older build. - Jay ---------------------------------------- > From: jayk123 at hotmail.com > To: m3devel at elegosoft.com > Subject: PPC_LINUX breaks > Date: Thu, 3 Jan 2008 22:09:22 +0000 > > > I can't build PPC_LINUX. > > > I can build the compiler with 5.2.6 but then stuck at building m3core with current compiler. > There are several problems. > Some I can fix, some stump me. > This platform still uses non-PTHREADs. > I figure that is worth fixing, but maybe afterward? > > > [jay at localhost m3core]$ /tmp/make-dist/compiler_with_self/bin/cm3 -override -DROOT='/dev2/cm3' > > > new source -> compiling Uucontext.i3 > "../src/unix/linux-ppc/Uucontext.i3", line 102: syntax error: missing ']' > 1 error encountered > > > [jay at localhost m3core]$ cvs diff src/unix/linux-ppc/Uucontext.i3 > Index: src/unix/linux-ppc/Uucontext.i3 > =================================================================== > RCS file: /usr/cvs/cm3/m3-libs/m3core/src/unix/linux-ppc/Uucontext.i3,v > retrieving revision 1.1 > diff -r1.1 Uucontext.i3 > 102c102 > < vrregs: ARRAY[0..32,0..4] OF unsigned_int; > --- >> vrregs: ARRAY[0..32 * 4] OF unsigned_int; > > > new source -> compiling Uucontext.i3 > "../src/unix/linux-ppc/Uucontext.i3", line 92: undefined (double) > "../src/unix/linux-ppc/Uucontext.i3", line 93: undefined (double) > "../src/unix/linux-ppc/Uucontext.i3", line 94: undefined (unsigned_int) > "../src/unix/linux-ppc/Uucontext.i3", line 102: undefined (unsigned_int) > "../src/unix/linux-ppc/Uucontext.i3", line 103: undefined (unsigned_int) > "../src/unix/linux-ppc/Uucontext.i3", line 104: undefined (unsigned_int) > "../src/unix/linux-ppc/Uucontext.i3", line 105: undefined (unsigned_int) > "../src/unix/linux-ppc/Uucontext.i3", line 149: undefined (char) > "../src/unix/linux-ppc/Uucontext.i3", line 10: warning: not used (unsigned_short) > "../src/unix/linux-ppc/Uucontext.i3", line 11: warning: not used (unsigned_short_int) > 8 errors and 2 warnings encountered > > > [jay at localhost m3core]$ cvs diff src/unix/linux-ppc/Uucontext.i3 > Index: src/unix/linux-ppc/Uucontext.i3 > =================================================================== > RCS file: /usr/cvs/cm3/m3-libs/m3core/src/unix/linux-ppc/Uucontext.i3,v > retrieving revision 1.1 > diff -r1.1 Uucontext.i3 > 10,11c10,11 > < IMPORT int, unsigned_long, unsigned_long_int, unsigned_short, void_star, > < unsigned_short_int; > --- >> IMPORT int, unsigned_long, unsigned_long_int, void_star, >> double, unsigned_int, char; > > > > new source -> compiling RTSignal.m3 > "../src/runtime/PPC_LINUX/RTSignal.m3", line 82: undefined (Usignal.struct_sigcontext) > 1 error encountered > > [jay at localhost m3core]$ cvs diff src/runtime/PPC_LINUX/RTSignal.m3 > Index: src/runtime/PPC_LINUX/RTSignal.m3 > =================================================================== > RCS file: /usr/cvs/cm3/m3-libs/m3core/src/runtime/PPC_LINUX/RTSignal.m3,v > retrieving revision 1.1 > diff -r1.1 RTSignal.m3 > 10c10 > < IMPORT RTError, RTProcess, Csignal, Usignal, Uprocess; > --- >> IMPORT RTError, RTProcess, Csignal, Usignal, Uprocess, Uucontext; > 82c82 > < scp : Usignal.struct_sigcontext; > --- >> scp : Uucontext.struct_sigcontext; > > > new source -> compiling RTSignal.m3 > "../src/runtime/PPC_LINUX/RTSignal.m3", line 85: unknown qualification '.' (eip) > 1 error encountered > > This I looked into a while. The problem is obvious, the fix is not. > For now I replaced whatever.eip with 0. > Sometimes PowerPC calls eip srr0, but sometimes not. > The first thing I found reading about PowerPC is that there's no instruction > counter register, because it is rarely needed directly in code. > But anyway, it's still need for traps/exceptions. > I'll look at an old winnt.h. > > > And then I am stuck on: > > > new source -> compiling RTThread.m3 > "../src/runtime/PPC_LINUX/RTThread.m3", line 88: unknown qualification '.' (sa_handler) > "../src/runtime/PPC_LINUX/RTThread.m3", line 89: unknown qualification '.' (empty_sigset_t) > "../src/runtime/PPC_LINUX/RTThread.m3", line 91: incompatible types (act) > "../src/runtime/PPC_LINUX/RTThread.m3", line 91: VAR actual must be a designator (oact) > "../src/runtime/PPC_LINUX/RTThread.m3", line 96: incompatible types (set) > "../src/runtime/PPC_LINUX/RTThread.m3", line 96: VAR actual must be a designator (oset) > "../src/runtime/PPC_LINUX/RTThread.m3", line 101: incompatible types (set) > "../src/runtime/PPC_LINUX/RTThread.m3", line 101: VAR actual must be a designator (oset) > "../src/runtime/PPC_LINUX/RTThread.m3", line 108: unknown qualification '.' (sigmask) > 9 errors encountered > > > The code: > > > PROCEDURE setup_sigvtalrm (handler: Usignal.SignalHandler) = > VAR x: Usignal.struct_sigaction; > BEGIN > x.sa_handler := LOOPHOLE (handler, Usignal.SignalActionHandler); (* line 88*) > x.sa_mask := Usignal.empty_sigset_t; (*89*) > x.sa_flags := Usignal.SA_RESTART; (*90*) > EVAL Usignal.sigaction (Usignal.SIGVTALRM, ADR (x), NIL); (*91*) > END setup_sigvtalrm; > > > Other platforms get away without this stuff by using just "signal" which > takes fewer parameters. I ASSUME PPC_LINUX as some interest in more parameters > in order to implement vtalarm based threads, instead of pthreads. > > > Usignal does define these types..unless I am looking at the wrong one. > Or heck, even the obvious wrong one. > > > Except..overrides..the local package..stuff doesn't need an override to refer to itself, right? > > > Non-standalone binaries also don't work. I think I reported that two weeks ago. > I figured that'd come afterward.. > > > There is also: > new source -> compiling Long.m3 > GenWord.mg: In function `Long__Divide': > GenWord.mg:13: Internal compiler error in emit_library_call_value_1, at calls.c:3684 > Please submit a full bug report, > with preprocessed source if appropriate. > See for instructions. > > > though I thought I had gotten past that by building m3cc. > Not likely a Modula-3 problem and I could always get around it > by making LONGINT only 32 bits (I think "long" is dumb in a name...). > > > [jay at localhost m3core]$ uname -a > Linux localhost.localdomain 2.6.15-rc5.ydl.1 #1 Wed Jan 4 16:25:38 EST 2006 ppc ppc ppc GNU/Linux > > > [jay at localhost m3core]$ gcc -v > Reading specs from /usr/lib/gcc/ppc64-yellowdog-linux/3.4.4/specs > Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --disable-checking --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-java-awt=gtk --host=ppc64-yellowdog-linux --build=ppc64-yellowdog-linux --target=ppc64-yellowdog-linux --with-cpu=default32 > Thread model: posix > gcc version 3.4.4 20050721 (Yellow Dog 3.4.4-2.ydl.2) > > > This is like Yellow Dog 4.x or so. > I don't know why all the ppc64 references. This is an iBook G3 -- 32bit. > I guess maybe it can build both -- oh, not that this gcc is in use. > Nor do I expect it matters. > > > - Jay > _________________________________________________________________ > The best games are on Xbox 360. Click here for a special offer on an Xbox 360 Console. > http://www.xbox.com/en-US/hardware/wheretobuy/ _________________________________________________________________ The best games are on Xbox 360. Click here for a special offer on an Xbox 360 Console. http://www.xbox.com/en-US/hardware/wheretobuy/ From jayk123 at hotmail.com Fri Jan 4 02:55:25 2008 From: jayk123 at hotmail.com (Jay) Date: Fri, 4 Jan 2008 01:55:25 +0000 Subject: [M3devel] test Message-ID: I think this is down again. - Jay _________________________________________________________________ Don't get caught with egg on your face. Play Chicktionary! http://club.live.com/chicktionary.aspx?icid=chick_wlhmtextlink1_dec -------------- next part -------------- An HTML attachment was scrubbed... URL: From stsp at elego.de Fri Jan 4 15:15:23 2008 From: stsp at elego.de (Stefan Sperling) Date: Fri, 4 Jan 2008 15:15:23 +0100 Subject: [M3devel] PPC_LINUX breaks In-Reply-To: References: Message-ID: <20080104141523.GC1459@ted.stsp.lan> On Thu, Jan 03, 2008 at 10:09:22PM +0000, Jay wrote: > > I can't build PPC_LINUX. It's been broken at least since the 5.4 release was made. Back then I failed to build it, and we decided to drop it from the 5.4 release. It needs fixing. -- Stefan Sperling Software Developer elego Software Solutions GmbH HRB 77719 Gustav-Meyer-Allee 25, Gebaeude 12 Tel: +49 30 23 45 86 96 13355 Berlin Fax: +49 30 23 45 86 95 http://www.elego.de Geschaeftsfuehrer: Olaf Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From hosking at cs.purdue.edu Fri Jan 4 15:43:31 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 4 Jan 2008 09:43:31 -0500 Subject: [M3devel] PPC_LINUX breaks In-Reply-To: <20080104141523.GC1459@ted.stsp.lan> References: <20080104141523.GC1459@ted.stsp.lan> Message-ID: <65C183A8-6102-49E9-9C38-8D59C966E42D@cs.purdue.edu> Has anyone built PPC_LINUX? I've never tried. On Jan 4, 2008, at 9:15 AM, Stefan Sperling wrote: > On Thu, Jan 03, 2008 at 10:09:22PM +0000, Jay wrote: >> >> I can't build PPC_LINUX. > > It's been broken at least since the 5.4 release was made. > > Back then I failed to build it, and we decided to drop > it from the 5.4 release. It needs fixing. > > -- > Stefan Sperling Software Developer > elego Software Solutions GmbH HRB 77719 > Gustav-Meyer-Allee 25, Gebaeude 12 Tel: +49 30 23 45 86 96 > 13355 Berlin Fax: +49 30 23 45 86 95 > http://www.elego.de Geschaeftsfuehrer: Olaf Wagner From dabenavidesd at yahoo.es Fri Jan 4 19:34:29 2008 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Fri, 4 Jan 2008 19:34:29 +0100 (CET) Subject: [M3devel] Ubuntu Gutsy problems Message-ID: <122805.74554.qm@web27110.mail.ukl.yahoo.com> Hi all: I'm trying to compile the first step bootstrap compiler on ubuntu gutsy 2.6.22-14-386, and I get into segmentation fault: adminfbd at fbd-desktop:/home/daniel/code/cm3/scripts$ sudo ./do-pkg.sh buildship m3core CM3C = /home/daniel/code/cm3/scripts/pkgmap.sh -c "/usr/local/cm3/bin/cm3 -build -DROOT='/home/daniel/code/cm3' && /usr/local/cm3/bin/cm3 -ship -DROOT='/home/daniel/code/cm3' " m3core === package /home/daniel/code/cm3/m3-libs/m3core === +++ /usr/local/cm3/bin/cm3 -build -DROOT='/home/daniel/code/cm3' && /usr/local/cm3/bin/cm3 -ship -DROOT='/home/daniel/code/cm3' +++ --- building in LINUXLIBC6 --- ignoring ../src/m3overrides new source -> compiling RTHooks.i3 RTHooks.i3: In function 'RTHooks_I3': RTHooks.i3:146: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling RT0.i3 RT0.i3: In function 'RT0_I3': RT0.i3:230: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling RuntimeError.i3 RuntimeError.i3: In function 'RuntimeError_I3': I used the new binaries of the d5.5.0 branch. Thanks --------------------------------- Web Revelaci?n Yahoo! 2007: Premio Favorita del P?blico - ?Vota tu preferida! -------------- next part -------------- An HTML attachment was scrubbed... URL: From dabenavidesd at yahoo.es Fri Jan 4 19:42:40 2008 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Fri, 4 Jan 2008 19:42:40 +0100 (CET) Subject: [M3devel] Ubuntu Gutsy problems In-Reply-To: <122805.74554.qm@web27110.mail.ukl.yahoo.com> Message-ID: <735847.33274.qm@web27102.mail.ukl.yahoo.com> Hi: Here is a stacktrace of cm3cg, compiled with a gcc 4.1 compiler (of this machine). daniel at fbd-desktop:~$ gdb cm3cg GNU gdb 6.6-debian Copyright (C) 2006 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i486-linux-gnu"... Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1". (gdb) run RTHooks.ic -o RTHooks.is -g Starting program: /usr/local/cm3/bin/cm3cg RTHooks.ic -o RTHooks.is -g Program received signal SIGSEGV, Segmentation fault. 0x080d8e6d in gen_field_die () (gdb) where #0 0x080d8e6d in gen_field_die () #1 0x080dc988 in gen_decl_die () #2 0x080d9d61 in gen_type_die () #3 0x080dcb45 in gen_decl_die () #4 0x080dcd34 in dwarf2out_decl () #5 0x080dcd55 in dwarf2out_type_decl () #6 0x08050178 in debug_struct () #7 0x080505ea in m3cg_declare_formal () #8 0x080515b6 in m3_parse_file () #9 0x082682aa in toplev_main () #10 0x080568ca in main () "Daniel Alejandro Benavides D." escribi?: Hi all: I'm trying to compile the first step bootstrap compiler on ubuntu gutsy 2.6.22-14-386, and I get into segmentation fault: adminfbd at fbd-desktop:/home/daniel/code/cm3/scripts$ sudo ./do-pkg.sh buildship m3core CM3C = /home/daniel/code/cm3/scripts/pkgmap.sh -c "/usr/local/cm3/bin/cm3 -build -DROOT='/home/daniel/code/cm3' && /usr/local/cm3/bin/cm3 -ship -DROOT='/home/daniel/code/cm3' " m3core === package /home/daniel/code/cm3/m3-libs/m3core === +++ /usr/local/cm3/bin/cm3 -build -DROOT='/home/daniel/code/cm3' && /usr/local/cm3/bin/cm3 -ship -DROOT='/home/daniel/code/cm3' +++ --- building in LINUXLIBC6 --- ignoring ../src/m3overrides new source -> compiling RTHooks.i3 RTHooks.i3: In function 'RTHooks_I3': RTHooks.i3:146: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling RT0.i3 RT0.i3: In function 'RT0_I3': RT0.i3:230: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling RuntimeError.i3 RuntimeError.i3: In function 'RuntimeError_I3': I used the new binaries of the d5.5.0 branch. Thanks --------------------------------- Web Revelaci?n Yahoo! 2007: Premio Favorita del P?blico - ?Vota tu preferida! --------------------------------- Web Revelaci?n Yahoo! 2007: Premio Favorita del P?blico - ?Vota tu preferida! -------------- next part -------------- An HTML attachment was scrubbed... URL: From dabenavidesd at yahoo.es Fri Jan 4 19:58:49 2008 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Fri, 4 Jan 2008 19:58:49 +0100 (CET) Subject: [M3devel] Ubuntu Gutsy problems In-Reply-To: <735847.33274.qm@web27102.mail.ukl.yahoo.com> Message-ID: <546440.55084.qm@web27111.mail.ukl.yahoo.com> Hi: It gets compiled well when using -gstabs command line option of cm3cg, as Tony marked on this post, so for now we can change the cm3.cfg debug variable of m3_backend: https://mail.elegosoft.com/pipermail/m3devel/2007-June/000238.html proc m3_backend (source, object, optimize, debug) is local args = [ "-quiet", source, "-o", object ] if optimize args += "-O" end if debug args += "-gstabs" end (gdb) run RTHooks.ic -o RTHooks.is -gstabs Starting program: /usr/local/cm3/bin/cm3cg RTHooks.ic -o RTHooks.is -gstabs RTHooks_I3 Execution times (seconds) TOTAL : 0.02 0.00 0.02 596 kB Program exited normally. (gdb) Thanks "Daniel Alejandro Benavides D." escribi?: Hi: Here is a stacktrace of cm3cg, compiled with a gcc 4.1 compiler (of this machine). daniel at fbd-desktop:~$ gdb cm3cg GNU gdb 6.6-debian Copyright (C) 2006 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i486-linux-gnu"... Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1". (gdb) run RTHooks.ic -o RTHooks.is -g Starting program: /usr/local/cm3/bin/cm3cg RTHooks.ic -o RTHooks.is -g Program received signal SIGSEGV, Segmentation fault. 0x080d8e6d in gen_field_die () (gdb) where #0 0x080d8e6d in gen_field_die () #1 0x080dc988 in gen_decl_die () #2 0x080d9d61 in gen_type_die () #3 0x080dcb45 in gen_decl_die () #4 0x080dcd34 in dwarf2out_decl () #5 0x080dcd55 in dwarf2out_type_decl () #6 0x08050178 in debug_struct () #7 0x080505ea in m3cg_declare_formal () #8 0x080515b6 in m3_parse_file () #9 0x082682aa in toplev_main () #10 0x080568ca in main () "Daniel Alejandro Benavides D." escribi?: Hi all: I'm trying to compile the first step bootstrap compiler on ubuntu gutsy 2.6.22-14-386, and I get into segmentation fault: adminfbd at fbd-desktop:/home/daniel/code/cm3/scripts$ sudo ./do-pkg.sh buildship m3core CM3C = /home/daniel/code/cm3/scripts/pkgmap.sh -c "/usr/local/cm3/bin/cm3 -build -DROOT='/home/daniel/code/cm3' && /usr/local/cm3/bin/cm3 -ship -DROOT='/home/daniel/code/cm3' " m3core === package /home/daniel/code/cm3/m3-libs/m3core === +++ /usr/local/cm3/bin/cm3 -build -DROOT='/home/daniel/code/cm3' && /usr/local/cm3/bin/cm3 -ship -DROOT='/home/daniel/code/cm3' +++ --- building in LINUXLIBC6 --- ignoring ../src/m3overrides new source -> compiling RTHooks.i3 RTHooks.i3: In function 'RTHooks_I3': RTHooks.i3:146: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling RT0.i3 RT0.i3: In function 'RT0_I3': RT0.i3:230: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling RuntimeError.i3 RuntimeError.i3: In function 'RuntimeError_I3': I used the new binaries of the d5.5.0 branch. Thanks --------------------------------- Web Revelaci?n Yahoo! 2007: Premio Favorita del P?blico - ?Vota tu preferida! --------------------------------- Web Revelaci?n Yahoo! 2007: Premio Favorita del P?blico - ?Vota tu preferida! --------------------------------- Web Revelaci?n Yahoo! 2007: Premio Favorita del P?blico - ?Vota tu preferida! -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Fri Jan 4 20:17:23 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 4 Jan 2008 14:17:23 -0500 Subject: [M3devel] Ubuntu Gutsy problems In-Reply-To: <735847.33274.qm@web27102.mail.ukl.yahoo.com> References: <735847.33274.qm@web27102.mail.ukl.yahoo.com> Message-ID: <70ABAF58-FC5A-4FBB-8CCC-BEC58BAC73E4@cs.purdue.edu> Did you update your m3cg backend? Also, make sure your config file has "-gstabs" defined in the debug portion of the arguments to the m3_backend. It seems you are suffering from a lag between the 4.1 backend and config file and the newer one. On Jan 4, 2008, at 1:42 PM, Daniel Alejandro Benavides D. wrote: > Hi: > Here is a stacktrace of cm3cg, compiled with a gcc 4.1 compiler (of > this machine). > > daniel at fbd-desktop:~$ gdb cm3cg > GNU gdb 6.6-debian > Copyright (C) 2006 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, > and you are > welcome to change it and/or distribute copies of it under certain > conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for > details. > This GDB was configured as "i486-linux-gnu"... > Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so. > 1". > (gdb) run RTHooks.ic -o RTHooks.is -g > Starting program: /usr/local/cm3/bin/cm3cg RTHooks.ic -o RTHooks.is -g > > Program received signal SIGSEGV, Segmentation fault. > 0x080d8e6d in gen_field_die () > (gdb) where > #0 0x080d8e6d in gen_field_die () > #1 0x080dc988 in gen_decl_die () > #2 0x080d9d61 in gen_type_die () > #3 0x080dcb45 in gen_decl_die () > #4 0x080dcd34 in dwarf2out_decl () > #5 0x080dcd55 in dwarf2out_type_decl () > #6 0x08050178 in debug_struct () > #7 0x080505ea in m3cg_declare_formal () > #8 0x080515b6 in m3_parse_file () > #9 0x082682aa in toplev_main () > #10 0x080568ca in main () > > > "Daniel Alejandro Benavides D." escribi?: > Hi all: > I'm trying to compile the first step bootstrap compiler on ubuntu > gutsy 2.6.22-14-386, and I get into segmentation fault: > > adminfbd at fbd-desktop:/home/daniel/code/cm3/scripts$ sudo ./do- > pkg.sh buildship m3core > CM3C = > /home/daniel/code/cm3/scripts > /pkgmap.sh -c "/usr/local/cm3/bin/cm3 -build -DROOT='/home/daniel/ > code/cm3' && /usr/local/cm3/bin/cm3 -ship -DROOT='/home/daniel/ > code/cm3' " m3core > === package /home/daniel/code/cm3/m3-libs/m3core === > +++ /usr/local/cm3/bin/cm3 -build -DROOT='/home/daniel/code/cm3' > && /usr/local/cm3/bin/cm3 -ship -DROOT='/home/daniel/code/cm3' +++ > --- building in LINUXLIBC6 --- > > ignoring ../src/m3overrides > > new source -> compiling RTHooks.i3 > RTHooks.i3: In function 'RTHooks_I3': > RTHooks.i3:146: internal compiler error: Segmentation fault > Please submit a full bug report, > with preprocessed source if appropriate. > See for instructions. > new source -> compiling RT0.i3 > RT0.i3: In function 'RT0_I3': > RT0.i3:230: internal compiler error: Segmentation fault > Please submit a full bug report, > with preprocessed source if appropriate. > See for instructions. > new source -> compiling RuntimeError.i3 > RuntimeError.i3: In function 'RuntimeError_I3': > > I used the new binaries of the d5.5.0 branch. > > Thanks > > Web Revelaci?n Yahoo! 2007: > Premio Favorita del P?blico - ?Vota tu preferida! > > > Web Revelaci?n Yahoo! 2007: > Premio Favorita del P?blico - ?Vota tu preferida! From jayk123 at hotmail.com Fri Jan 4 20:58:45 2008 From: jayk123 at hotmail.com (Jay) Date: Fri, 4 Jan 2008 19:58:45 +0000 Subject: [M3devel] PPC_LINUX breaks In-Reply-To: <65C183A8-6102-49E9-9C38-8D59C966E42D@cs.purdue.edu> References: <20080104141523.GC1459@ted.stsp.lan> <65C183A8-6102-49E9-9C38-8D59C966E42D@cs.purdue.edu> Message-ID: I figured out a bunch here. a) the diffs I showed. b) "nip" is "next instruction pointer"; that's what you want in the SegV function. And the last parameter should be void_star instead of int. You can use like pt_regs.nip for the old definition or uc_regs.gprregs[PT_NIP] for the new definition. I have diffs here. c) Usignal.i3 had the stuff vtalarm stuff removed, which PPC_LINUX still uses, "POSIX threads" vs. "PThreads" (oh the names..), though perhaps broken by setjmp/longjmp "scrambling". Is it possible to break up an interface into linux-common/foo.i3 linux-ppc/foo.i3 I think not. Shall we just go ahead and translate LINUX_PPC pthread.h into Modula-3? (Btw, doesn't anyone find all this header rewriting sleazy? Or they have to maintain compat anyway so no problem?) The error messages are poor. Let's say I.T does not exist. VAR x : I.T; (* no error *) x.foo = bar; (* "unknown qualification" *) FROM I IMPORT T; (* "T not exported" -- better, but should say T does not exist I was fumbling around with needing a module to say "EXPORTS" or to capitalize the Interface directive in m3makefile, neither of which seemed right *) - Jay > From: hosking at cs.purdue.edu > Date: Fri, 4 Jan 2008 09:43:31 -0500 > To: stsp at elego.de > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] PPC_LINUX breaks > > Has anyone built PPC_LINUX? I've never tried. > > On Jan 4, 2008, at 9:15 AM, Stefan Sperling wrote: > > > On Thu, Jan 03, 2008 at 10:09:22PM +0000, Jay wrote: > >> > >> I can't build PPC_LINUX. > > > > It's been broken at least since the 5.4 release was made. > > > > Back then I failed to build it, and we decided to drop > > it from the 5.4 release. It needs fixing. > > > > -- > > Stefan Sperling Software Developer > > elego Software Solutions GmbH HRB 77719 > > Gustav-Meyer-Allee 25, Gebaeude 12 Tel: +49 30 23 45 86 96 > > 13355 Berlin Fax: +49 30 23 45 86 95 > > http://www.elego.de Geschaeftsfuehrer: Olaf Wagner > _________________________________________________________________ Share life as it happens with the new Windows Live. http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Fri Jan 4 21:45:06 2008 From: jayk123 at hotmail.com (Jay) Date: Fri, 4 Jan 2008 20:45:06 +0000 Subject: [M3devel] PPC_LINUX breaks In-Reply-To: References: <20080104141523.GC1459@ted.stsp.lan> <65C183A8-6102-49E9-9C38-8D59C966E42D@cs.purdue.edu> Message-ID: I'm confused here on what got deleted. I keep seeing it present. I swear I saw the diff though.. :( Browing CVS is such a pain. - Jay From: jayk123 at hotmail.com To: hosking at cs.purdue.edu; stsp at elego.de Date: Fri, 4 Jan 2008 19:58:45 +0000 CC: m3devel at elegosoft.com Subject: Re: [M3devel] PPC_LINUX breaks I figured out a bunch here. a) the diffs I showed. b) "nip" is "next instruction pointer"; that's what you want in the SegV function. And the last parameter should be void_star instead of int. You can use like pt_regs.nip for the old definition or uc_regs.gprregs[PT_NIP] for the new definition. I have diffs here. c) Usignal.i3 had the stuff vtalarm stuff removed, which PPC_LINUX still uses, "POSIX threads" vs. "PThreads" (oh the names..), though perhaps broken by setjmp/longjmp "scrambling". Is it possible to break up an interface into linux-common/foo.i3 linux-ppc/foo.i3 I think not. Shall we just go ahead and translate LINUX_PPC pthread.h into Modula-3? (Btw, doesn't anyone find all this header rewriting sleazy? Or they have to maintain compat anyway so no problem?) The error messages are poor. Let's say I.T does not exist. VAR x : I.T; (* no error *) x.foo = bar; (* "unknown qualification" *) FROM I IMPORT T; (* "T not exported" -- better, but should say T does not exist I was fumbling around with needing a module to say "EXPORTS" or to capitalize the Interface directive in m3makefile, neither of which seemed right *) - Jay > From: hosking at cs.purdue.edu > Date: Fri, 4 Jan 2008 09:43:31 -0500 > To: stsp at elego.de > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] PPC_LINUX breaks > > Has anyone built PPC_LINUX? I've never tried. > > On Jan 4, 2008, at 9:15 AM, Stefan Sperling wrote: > > > On Thu, Jan 03, 2008 at 10:09:22PM +0000, Jay wrote: > >> > >> I can't build PPC_LINUX. > > > > It's been broken at least since the 5.4 release was made. > > > > Back then I failed to build it, and we decided to drop > > it from the 5.4 release. It needs fixing. > > > > -- > > Stefan Sperling Software Developer > > elego Software Solutions GmbH HRB 77719 > > Gustav-Meyer-Allee 25, Gebaeude 12 Tel: +49 30 23 45 86 96 > > 13355 Berlin Fax: +49 30 23 45 86 95 > > http://www.elego.de Geschaeftsfuehrer: Olaf Wagner > Share life as it happens with the new Windows Live. Start sharing! _________________________________________________________________ Share life as it happens with the new Windows Live. http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Fri Jan 4 22:10:59 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 04 Jan 2008 22:10:59 +0100 Subject: [M3devel] M3 concerns In-Reply-To: <477B7629.1E75.00D7.1@scires.com> References: <477B7629.1E75.00D7.1@scires.com> Message-ID: <20080104221059.uwf80xrms0gw8880@mail.elegosoft.com> Quoting Randy Coleburn : > I've seen quite a number of m3commit and m3devel messages lately. > Many of these give the appearance of "thinking out loud" with > various commits followed by apparent reversals. In many cases the > m3commit log messages are terse and don't give the rationale behind > the change. > > For those of us in the M3 community who rely upon the stability of > the libraries and core M3 principles, these types of messages cause > concern. While I appreciate everyone's efforts to move forward, I > don't want to abandon the great care that went into formulating this > language. I agree that some of the recent commit messages seem to give the impression of quick changes. More care should be taken here. I'm not really concerned about the stability of the whole system, as those changes did mostly concern build infrastructure and minor fixes and adaptions. > Question: As various people make contributions and changes, is > there any group of folks who is verifying that the changes don't > break existing code or core principles? Another idea would be to > have a series of test batteries that have to be passed before > changes can be accepted. I know of a number of projects where many > people contribute, but the contributions have to be vetted by > passing some tests. Automated regression tests have been on my agenda for CM3 for a long time. I coulnd't contribute much myself during the last year, as I've been very busy. I've done a little bit in the last two weeks, and others have also worked in this area, so that I hope we will be able to present some working regression test setup within some days. At least we'll have some initial setup that can be extended and improved. More to this topic in another mail. > Without these types of controls, I fear that good forward progress > will inevitably be hampered or compromised by changes made by > someone who hasn't completely thought out and tested the > ramifications of those changes. Yes, this is the usual problem with all systems without periodic automatic regression testing. > For example, I've tried to get cm3 working for me on Windows XP > several times. I still can't seem to get the "current" system to > build correctly on XP. In the past, I have on occasion gotten the > "system" to build, but then some of my programs don't work correctly > when rebuilt using the new cm3. Thus, some changes somewhere have > "broken" my code, yet all of my code uses the "safe" subset of the > language. If I go back to my old reliable cm3 version 4.1 (the last > one put out before Critical Mass, Inc. threw in the towel), my code > compiles and works, even on Windows XP, even using Trestle, > FormsVBT, NetObj, cross-platform pickles (e.g., pickles shared > between Windows & Unix boxes), etc.! Much of my code was originally > developed under Windows NT, so I think it is a tribute to the > original language developers that my code and their compiler work > through various OS version upgrades (NT, 2000, XP) and changes to > the underlying C/C++ compilers used to build the core components. Ah well, Windows is a somewhat special topic. I even haven't a system here for tests, and most of the other contributors don't use it either. I was of the opinion that Jay Krell had fixes or workarounds for most current problems (except for the missing LONGINT support), but I haven't tried his distribution archives yet. It would indeed be very helpful if we could setup regression tests on Windows, too. As for the stability and interoperability, this is a very complex requirement that needs much care and testing. It is difficult to achieve in an open source project, at least in one with so few contributors. I'm sure Critical Mass did an excellent job on this, but it's been a commercial company with other organization and resources. We'll have to become better in this respect step by step. It would also be possible to define a group of reviewers for every change, but I doubt that there would be enough competent volunteers, and I'm afraid that it would rather repress development of CM3. And we really need to have development, as the underlying systems and techniques change and we need to adapt to that. So I'd vote for free commits for everybody, as long as there are not too many contributors, and setup of continually improved regression testing. And we don't need to worry, as all changes can be reverted; we won't lose development history with CVS. > I would appreciate constructive feedback on this topic. I hope this has been constructive enough, Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From hosking at cs.purdue.edu Fri Jan 4 22:17:19 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 4 Jan 2008 16:17:19 -0500 Subject: [M3devel] M3 concerns In-Reply-To: <20080104221059.uwf80xrms0gw8880@mail.elegosoft.com> References: <477B7629.1E75.00D7.1@scires.com> <20080104221059.uwf80xrms0gw8880@mail.elegosoft.com> Message-ID: <063F2D47-D837-4E11-9001-D152527E8694@cs.purdue.edu> My comments embedded: On Jan 4, 2008, at 4:10 PM, Olaf Wagner wrote: > Quoting Randy Coleburn : > >> For example, I've tried to get cm3 working for me on Windows XP >> several times. I still can't seem to get the "current" system to >> build correctly on XP. In the past, I have on occasion gotten >> the "system" to build, but then some of my programs don't work >> correctly when rebuilt using the new cm3. Thus, some changes >> somewhere have "broken" my code, yet all of my code uses the >> "safe" subset of the language. If I go back to my old reliable >> cm3 version 4.1 (the last one put out before Critical Mass, Inc. >> threw in the towel), my code compiles and works, even on Windows >> XP, even using Trestle, FormsVBT, NetObj, cross-platform pickles >> (e.g., pickles shared between Windows & Unix boxes), etc.! Much >> of my code was originally developed under Windows NT, so I think >> it is a tribute to the original language developers that my code >> and their compiler work through various OS version upgrades (NT, >> 2000, XP) and changes to the underlying C/C++ compilers used to >> build the core components. > > Ah well, Windows is a somewhat special topic. I even haven't a system > here for tests, and most of the other contributors don't use it > either. > I was of the opinion that Jay Krell had fixes or workarounds for most > current problems (except for the missing LONGINT support), but I > haven't > tried his distribution archives yet. It would indeed be very helpful > if we could setup regression tests on Windows, too. LONGINT = INTEGER on Windows, which is fine as far as it goes (everything builds appropriately), but not particularly useful. > As for the stability and interoperability, this is a very complex > requirement that needs much care and testing. It is difficult to > achieve > in an open source project, at least in one with so few contributors. > I'm sure Critical Mass did an excellent job on this, but it's been > a commercial company with other organization and resources. We'll > have to become better in this respect step by step. > > It would also be possible to define a group of reviewers for every > change, but I doubt that there would be enough competent volunteers, > and I'm afraid that it would rather repress development of CM3. > And we really need to have development, as the underlying systems and > techniques change and we need to adapt to that. So I'd vote for > free commits for everybody, as long as there are not too many > contributors, and setup of continually improved regression testing. > And we don't need to worry, as all changes can be reverted; we won't > lose development history with CVS. One option is to have moderated commits for non-core developers. After someone has earned the trust of the core developers they can be elected as a member of the core team. This approach is used with the Jikes RVM (www.jikesrvm.org). From jayk123 at hotmail.com Fri Jan 4 22:26:08 2008 From: jayk123 at hotmail.com (Jay) Date: Fri, 4 Jan 2008 21:26:08 +0000 Subject: [M3devel] PPC_LINUX breaks In-Reply-To: References: <20080104141523.GC1459@ted.stsp.lan> <65C183A8-6102-49E9-9C38-8D59C966E42D@cs.purdue.edu> Message-ID: [redundant] ok, I commited fixes for what I have seen so far. There was no delete, though probably changes -- sigset changes from int to 1024 bits for example, or somesuch. I'm sure you all see the commits. Given that PPC_LINUX still uses usermode threads, could have "that" problem, we'll see.. Gotta go for a while now. - Jay From: jayk123 at hotmail.com To: hosking at cs.purdue.edu; stsp at elego.de CC: m3devel at elegosoft.com Subject: RE: [M3devel] PPC_LINUX breaks Date: Fri, 4 Jan 2008 20:45:06 +0000 I'm confused here on what got deleted. I keep seeing it present. I swear I saw the diff though.. :( Browing CVS is such a pain. - Jay From: jayk123 at hotmail.com To: hosking at cs.purdue.edu; stsp at elego.de Date: Fri, 4 Jan 2008 19:58:45 +0000 CC: m3devel at elegosoft.com Subject: Re: [M3devel] PPC_LINUX breaks I figured out a bunch here. a) the diffs I showed. b) "nip" is "next instruction pointer"; that's what you want in the SegV function. And the last parameter should be void_star instead of int. You can use like pt_regs.nip for the old definition or uc_regs.gprregs[PT_NIP] for the new definition. I have diffs here. c) Usignal.i3 had the stuff vtalarm stuff removed, which PPC_LINUX still uses, "POSIX threads" vs. "PThreads" (oh the names..), though perhaps broken by setjmp/longjmp "scrambling". Is it possible to break up an interface into linux-common/foo.i3 linux-ppc/foo.i3 I think not. Shall we just go ahead and translate LINUX_PPC pthread.h into Modula-3? (Btw, doesn't anyone find all this header rewriting sleazy? Or they have to maintain compat anyway so no problem?) The error messages are poor. Let's say I.T does not exist. VAR x : I.T; (* no error *) x.foo = bar; (* "unknown qualification" *) FROM I IMPORT T; (* "T not exported" -- better, but should say T does not exist I was fumbling around with needing a module to say "EXPORTS" or to capitalize the Interface directive in m3makefile, neither of which seemed right *) - Jay > From: hosking at cs.purdue.edu > Date: Fri, 4 Jan 2008 09:43:31 -0500 > To: stsp at elego.de > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] PPC_LINUX breaks > > Has anyone built PPC_LINUX? I've never tried. > > On Jan 4, 2008, at 9:15 AM, Stefan Sperling wrote: > > > On Thu, Jan 03, 2008 at 10:09:22PM +0000, Jay wrote: > >> > >> I can't build PPC_LINUX. > > > > It's been broken at least since the 5.4 release was made. > > > > Back then I failed to build it, and we decided to drop > > it from the 5.4 release. It needs fixing. > > > > -- > > Stefan Sperling Software Developer > > elego Software Solutions GmbH HRB 77719 > > Gustav-Meyer-Allee 25, Gebaeude 12 Tel: +49 30 23 45 86 96 > > 13355 Berlin Fax: +49 30 23 45 86 95 > > http://www.elego.de Geschaeftsfuehrer: Olaf Wagner > Share life as it happens with the new Windows Live. Start sharing! Share life as it happens with the new Windows Live. Start sharing! _________________________________________________________________ Put your friends on the big screen with Windows Vista? + Windows Live?. http://www.microsoft.com/windows/shop/specialoffers.mspx?ocid=TXT_TAGLM_CPC_MediaCtr_bigscreen_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Fri Jan 4 22:32:52 2008 From: jayk123 at hotmail.com (Jay) Date: Fri, 4 Jan 2008 21:32:52 +0000 Subject: [M3devel] Darwin upgrade/fingerprint error In-Reply-To: References: <20080104141523.GC1459@ted.stsp.lan> <65C183A8-6102-49E9-9C38-8D59C966E42D@cs.purdue.edu> Message-ID: Starting with an older release on PPC_DARWIN and running upgrade.sh, I keep getting: === package /dev2/cm3/m3-sys/m3middle === +++ cm3 -build -DROOT='/dev2/cm3' -DCM3_VERSION_TEXT='d5.5.1' -DCM3_VERSION_NUMBER='050501' -DCM3_LAST_CHANGED='2007-12-30' && cm3 -ship -DROOT='/dev2/cm3' -DCM3_VERSION_TEXT='d5.5.1' -DCM3_VERSION_NUMBER='050501' -DCM3_LAST_CHANGED='2007-12-30' +++ --- building in PPC_DARWIN --- ignoring ../src/m3overrides stale imports -> compiling CoffTime.m3 stale imports -> compiling M3Process.i3 stale imports -> compiling M3Process.m3 stale imports -> compiling TFloat.m3 Fatal Error: bad version stamps: TFloat.m3 version stamp mismatch: TargetMap.Float_types <31f4d45a27120488> => TFloat.m3 <663449bb704e9c85> => TargetMap.i3 *** execution of failed *** I assume this will be fixed by: ijayk:/dev2/cm3/scripts jay$ cvs diff upgrade.sh Index: upgrade.sh =================================================================== RCS file: /usr/cvs/cm3/scripts/upgrade.sh,v retrieving revision 1.4 diff -r1.4 upgrade.sh 52a53,55 > echo "$ROOT/scripts/do-pkg.sh" "$@" "realclean ${P}" > "$ROOT/scripts/do-pkg.sh" "$@" "realclean" ${P} || exit 1 > 58a62,64 > echo "$ROOT/scripts/do-cm3-core.sh" "$@" "realclean" > "$ROOT/scripts/do-cm3-core.sh" "$@" "realclean" || exit 1 > Will that really harm/slow anyone's workflow? In fact, notice how the older upgrade, while broken for other reasons, did this dance with upgrading and restoring the pkg store. win\upgrade.cmd still does. Something to consider.. (And I realize that backup/restore of install/pkg is different than realclean of root/*, so maybe that diff is not the fix.) Though it is a problem to manage the versions, in doing the backup/restore. Perhaps this all falls under the heading of -- not worth automating, people know what they are doing, else they can pickup a current binary distribution?? I'll get something working locally no doubt, I don't need any further help. :) (Though past help has helped shed light here, the local/global/ship thing is still just a tad vague to me and I'm just slightly unconvinced it has to be this way, but probably it does, what with necessary circularities between compiler and runtime, building with an older compiler and all that...) - Jay _________________________________________________________________ Share life as it happens with the new Windows Live. http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Fri Jan 4 22:51:48 2008 From: jayk123 at hotmail.com (Jay) Date: Fri, 4 Jan 2008 21:51:48 +0000 Subject: [M3devel] Darwin upgrade/fingerprint error In-Reply-To: References: <20080104141523.GC1459@ted.stsp.lan> <65C183A8-6102-49E9-9C38-8D59C966E42D@cs.purdue.edu> Message-ID: (probably OMIT_GCC=1 on the second clean and build; I assume it has no dependency into the tree and it'd just be building the same thing a second time, slowly) From: jayk123 at hotmail.com To: m3devel at elegosoft.com Date: Fri, 4 Jan 2008 21:32:52 +0000 Subject: [M3devel] Darwin upgrade/fingerprint error Starting with an older release on PPC_DARWIN and running upgrade.sh, I keep getting: === package /dev2/cm3/m3-sys/m3middle === +++ cm3 -build -DROOT='/dev2/cm3' -DCM3_VERSION_TEXT='d5.5.1' -DCM3_VERSION_NUMBER='050501' -DCM3_LAST_CHANGED='2007-12-30' && cm3 -ship -DROOT='/dev2/cm3' -DCM3_VERSION_TEXT='d5.5.1' -DCM3_VERSION_NUMBER='050501' -DCM3_LAST_CHANGED='2007-12-30' +++ --- building in PPC_DARWIN --- ignoring ../src/m3overrides stale imports -> compiling CoffTime.m3 stale imports -> compiling M3Process.i3 stale imports -> compiling M3Process.m3 stale imports -> compiling TFloat.m3 Fatal Error: bad version stamps: TFloat.m3 version stamp mismatch: TargetMap.Float_types <31f4d45a27120488> => TFloat.m3 <663449bb704e9c85> => TargetMap.i3 *** execution of failed *** I assume this will be fixed by: ijayk:/dev2/cm3/scripts jay$ cvs diff upgrade.sh Index: upgrade.sh =================================================================== RCS file: /usr/cvs/cm3/scripts/upgrade.sh,v retrieving revision 1.4 diff -r1.4 upgrade.sh 52a53,55 > echo "$ROOT/scripts/do-pkg.sh" "$@" "realclean ${P}" > "$ROOT/scripts/do-pkg.sh" "$@" "realclean" ${P} || exit 1 > 58a62,64 > echo "$ROOT/scripts/do-cm3-core.sh" "$@" "realclean" > "$ROOT/scripts/do-cm3-core.sh" "$@" "realclean" || exit 1 > Will that really harm/slow anyone's workflow? In fact, notice how the older upgrade, while broken for other reasons, did this dance with upgrading and restoring the pkg store. win\upgrade.cmd still does. Something to consider.. (And I realize that backup/restore of install/pkg is different than realclean of root/*, so maybe that diff is not the fix.) Though it is a problem to manage the versions, in doing the backup/restore. Perhaps this all falls under the heading of -- not worth automating, people know what they are doing, else they can pickup a current binary distribution?? I'll get something working locally no doubt, I don't need any further help. :) (Though past help has helped shed light here, the local/global/ship thing is still just a tad vague to me and I'm just slightly unconvinced it has to be this way, but probably it does, what with necessary circularities between compiler and runtime, building with an older compiler and all that...) - Jay Share life as it happens with the new Windows Live. Start sharing! _________________________________________________________________ Get the power of Windows + Web with the new Windows Live. http://www.windowslive.com?ocid=TXT_TAGHM_Wave2_powerofwindows_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Sat Jan 5 01:13:35 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 05 Jan 2008 01:13:35 +0100 Subject: [M3devel] M3 concerns In-Reply-To: <063F2D47-D837-4E11-9001-D152527E8694@cs.purdue.edu> References: <477B7629.1E75.00D7.1@scires.com> <20080104221059.uwf80xrms0gw8880@mail.elegosoft.com> <063F2D47-D837-4E11-9001-D152527E8694@cs.purdue.edu> Message-ID: <20080105011335.n767h3zbz4gcgk4k@mail.elegosoft.com> Quoting Tony Hosking : > My comments embedded: > > On Jan 4, 2008, at 4:10 PM, Olaf Wagner wrote: >> Ah well, Windows is a somewhat special topic. I even haven't a system >> here for tests, and most of the other contributors don't use it either. >> I was of the opinion that Jay Krell had fixes or workarounds for most >> current problems (except for the missing LONGINT support), but I haven't >> tried his distribution archives yet. It would indeed be very helpful >> if we could setup regression tests on Windows, too. > > LONGINT = INTEGER on Windows, which is fine as far as it goes > (everything builds appropriately), but not particularly useful. I know that it should run this way, but pickles for example wouldn't be exchangeable then, would they? Has anybody tested pickle support for LONGINT yet? >> It would also be possible to define a group of reviewers for every >> change, but I doubt that there would be enough competent volunteers, >> and I'm afraid that it would rather repress development of CM3. >> And we really need to have development, as the underlying systems and >> techniques change and we need to adapt to that. So I'd vote for >> free commits for everybody, as long as there are not too many >> contributors, and setup of continually improved regression testing. >> And we don't need to worry, as all changes can be reverted; we won't >> lose development history with CVS. > > One option is to have moderated commits for non-core developers. After > someone has earned the trust of the core developers they can be elected > as a member of the core team. This approach is used with the Jikes RVM > (www.jikesrvm.org). I wouldn't object to such a policy, though I don't really think that it is currently necessary. But if more active committers do prefer it, we can set up the necessary commit checks. I assume that Randy Coleburn and you are in favour of restricted commits? What about the others? Who would volunteer to review commits from other people? Would this be a responsibility inherited by the unrestricted access? Should we allow commits to branches and only restrict access to the main line? Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jayk123 at hotmail.com Sat Jan 5 02:04:47 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 5 Jan 2008 01:04:47 +0000 Subject: [M3devel] M3 concerns In-Reply-To: <20080105011335.n767h3zbz4gcgk4k@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> Message-ID: I oppose most red tape. However branching can be good, as long as there are frequent merges (between once a week and once a month..well, those timelines are based on other contexts, in this context, I don't know) and automated testing/buildmonkeys/tinderboxes. That is, if I'm in a ghetto branch, I loose both the pressure not to break things, because few/nobody else is in the branch, and the feedback loop of hearing that I've broken someone, so automation would be nice to replace that. I am not experienced with CVS though. I don't know how to setup or merge branches. Even browsing history I find painful, in one branch. Perforce I am quite familiar with. Subversion I learned enough about to know it doesn't suffice, so I'm leary of CVS, which is supposedly in all ways worse. In particular, Subversion doesn't track which changes have been merged from one branch to another. Whereas in Perforce that is a key feature of the system. Amazing that Subversion doesn't do it, but it is near the top of their wishlist. This is a small project. I haven't yet heard of anyone getting one of my possibly "in between" changes and being broken, and even when I checkin frequently, that doesn't mean any one state was broken or wrong. I haven't tested anything with Pickes. One set of tests I found failed all over the place, the m3tests stuff, floating point problems, I think a bunch of never implemented stuff on Windows around calling _fpcontrol or such (platform dependent). The system does build itself, the compiler and "std" packages. I consider that a pretty good start. I realize you can always do more, more and less obvious. There's probably no threading in the compiler, and maybe not even any garbage collection, nor any pickles. I'll look what Olaf commited over the weekend.. Bah humbug and happy new year, :) - Jay > Date: Sat, 5 Jan 2008 01:13:35 +0100> From: wagner at elegosoft.com> To: hosking at cs.purdue.edu; m3devel at elegosoft.com> CC: m3-support at elegosoft.com> Subject: Re: [M3devel] M3 concerns> > Quoting Tony Hosking :> > > My comments embedded:> >> > On Jan 4, 2008, at 4:10 PM, Olaf Wagner wrote:> > >> Ah well, Windows is a somewhat special topic. I even haven't a system> >> here for tests, and most of the other contributors don't use it either.> >> I was of the opinion that Jay Krell had fixes or workarounds for most> >> current problems (except for the missing LONGINT support), but I haven't> >> tried his distribution archives yet. It would indeed be very helpful> >> if we could setup regression tests on Windows, too.> >> > LONGINT = INTEGER on Windows, which is fine as far as it goes> > (everything builds appropriately), but not particularly useful.> > I know that it should run this way, but pickles for example wouldn't> be exchangeable then, would they? Has anybody tested pickle support> for LONGINT yet?> > >> It would also be possible to define a group of reviewers for every> >> change, but I doubt that there would be enough competent volunteers,> >> and I'm afraid that it would rather repress development of CM3.> >> And we really need to have development, as the underlying systems and> >> techniques change and we need to adapt to that. So I'd vote for> >> free commits for everybody, as long as there are not too many> >> contributors, and setup of continually improved regression testing.> >> And we don't need to worry, as all changes can be reverted; we won't> >> lose development history with CVS.> >> > One option is to have moderated commits for non-core developers. After> > someone has earned the trust of the core developers they can be elected> > as a member of the core team. This approach is used with the Jikes RVM> > (www.jikesrvm.org).> > I wouldn't object to such a policy, though I don't really think that> it is currently necessary. But if more active committers do prefer> it, we can set up the necessary commit checks. I assume that Randy Coleburn> and you are in favour of restricted commits? What about the others?> > Who would volunteer to review commits from other people? Would this> be a responsibility inherited by the unrestricted access?> > Should we allow commits to branches and only restrict access to the> main line?> > Olaf> -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194> _________________________________________________________________ Share life as it happens with the new Windows Live. 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 Jan 5 02:22:13 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 5 Jan 2008 01:22:13 +0000 Subject: [M3devel] "crazy cross" In-Reply-To: <20080105011335.n767h3zbz4gcgk4k@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> Message-ID: You've all heard of "Canadian cross"? It is cross-building a cross-compiler.I'm sitting in Windows. I'm going to build a compiler that is going to run on Linux that is going to target Solaris.For one example. You've all seen that Apple has switches like so: gcc -arch i386 ppc ppc64 x86_64 hello.cand poof out comes a binary that runs natively on four architectures I don't like the "inconvenience" of non cross systems and having to have all the machines/OSes just to build the binaries.I realize that you hit the wall if you actually want to test the results. So cross building only gets so much.Of course I also don't want to multiply out build times for tools... Ok, well what is the possibility of: cm3 -target NT386cm3 -target NT386 -target PPC_DARWIN ? In my crazy imagination, you have: \cm3\bin\cm3.cmd %~dp0..\libexec\%processor_architecture%\%TARGET%\cm3.exe %* \cm3\bin\cm3 #!/bin/sh dirname(dirname($0))/libexec/`uname whatever`/$TARGET/cm3 $@ Thus it becomes POSSIBLE to have an n x m matrix, host x target, and be able to build"anything" from one environment. Actually the targets could all be merged into one .exe or be .dll/.sos.Except the code isn't setup for that. Interesting? I guess the hard part is the C code and linking?The Modula-3 stuff is already setup to do most of this? (partly by virtue of all that header rewriting that I labeled sleazy) - Jay _________________________________________________________________ Share life as it happens with the new Windows Live. http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Sat Jan 5 02:28:46 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 5 Jan 2008 01:28:46 +0000 Subject: [M3devel] NT386GNU? In-Reply-To: <20080105011335.n767h3zbz4gcgk4k@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> Message-ID: I assume NT386GNU remains very interesting to folks. Right? Anyone know what's the deal with it? Little work? Lots of work? It'd net LONGINT at least. I realize you'd need sh/awk/sed/gmake/etc., and ld. You'd start by installing mingwin or cygwin. And they (or one) would likely be required for all users, at least for ld and some libs.I assume cygwin/mingwin have long since merged to mainline. I'll try to look into it..... - Jay _________________________________________________________________ Get the power of Windows + Web with the new Windows Live. http://www.windowslive.com?ocid=TXT_TAGHM_Wave2_powerofwindows_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: From hendrik at topoi.pooq.com Sat Jan 5 02:33:07 2008 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Fri, 4 Jan 2008 20:33:07 -0500 Subject: [M3devel] 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> Message-ID: <20080105013307.GB5064@topoi.pooq.com> On Sat, Jan 05, 2008 at 01:04:47AM +0000, Jay wrote: > I oppose most red tape. > > However branching can be good, as long as there are frequent merges > (between once a week and once a month..well, those timelines are based > on other contexts, in this context, I don't know) and automated > testing/buildmonkeys/tinderboxes. That is, if I'm in a ghetto branch, > I loose both the pressure not to break things, because few/nobody else > is in the branch, and the feedback loop of hearing that I've broken > someone, so automation would be nice to replace that. Distributed revision systems have completely implicit, low red-tape branching just by being distributed. > I am not experienced with CVS though. I don't know how to setup or > merge branches. Even browsing history I find painful, in one branch. > Perforce I am quite familiar with. > Subversion I learned enough about to know it doesn't suffice, so I'm > leary of CVS, which is supposedly in all ways worse. gravityboy (http://gravityboy.livejournal.com/39755.html) has a few things to say about people who compare svn with cvs: essentially, he says cvs is so obsolete no one should even be comparing things with it any more. Saying something is better than CVS is like saying that a new model of automatic washing machines work better than rocks by the side of the river. > In particular, Subversion doesn't track which changes have been merged > from one branch to another. Whereas in Perforce that is a key feature > of the system. Amazing that Subversion doesn't do it, but it is near > the top of their wishlist. > > This is a small project. > I haven't yet heard of anyone getting one of my possibly "in between" changes and being broken, and even when I checkin frequently, that doesn't mean any one state was broken or wrong. > > I haven't tested anything with Pickes. One set of tests I found failed all over the place, the m3tests stuff, floating point problems, I think a bunch of never implemented stuff on Windows around calling _fpcontrol or such (platform dependent). > > The system does build itself, the compiler and "std" packages. I consider that a pretty good start. > I realize you can always do more, more and less obvious. There's probably no threading in the compiler, and maybe not even any garbage collection, nor any pickles. > > I'll look what Olaf commited over the weekend.. > > Bah humbug and happy new year, :) > - Jay > > > > > Date: Sat, 5 Jan 2008 01:13:35 +0100> From: wagner at elegosoft.com> To: hosking at cs.purdue.edu; m3devel at elegosoft.com> CC: m3-support at elegosoft.com> Subject: Re: [M3devel] M3 concerns> > Quoting Tony Hosking :> > > My comments embedded:> >> > On Jan 4, 2008, at 4:10 PM, Olaf Wagner wrote:> > >> Ah well, Windows is a somewhat special topic. I even haven't a system> >> here for tests, and most of the other contributors don't use it either.> >> I was of the opinion that Jay Krell had fixes or workarounds for most> >> current problems (except for the missing LONGINT support), but I haven't> >> tried his distribution archives yet. It would indeed be very helpful> >> if we could setup regression tests on Windows, too.> >> > LONGINT = INTEGER on Windows, which is fine as far as it goes> > (everything builds appropriately), but not particularly useful.> > I know that it should run this way, but pickles for example wouldn't> be exchangeable then, would they? Has anybody tested pickle support> for LONGINT yet?> > >> It would also be possible to define a group of reviewers for every> >> change, but I doubt that there would be enough competent volunteers,> >> and I'm afraid that it would rather repress development of CM3.> >> And we really need to have development, as the underlying systems and> >> techniques change and we need to adapt to that. So I'd vote for> >> free commits for everybody, as long as there are not too many> >> contributors, and setup of continually improved regression testing.> >> And we don't need to worry, as all changes can be reverted; we won't> >> lose development history with CVS.> >> > One option is to have moderated commits for non-core developers. After> > someone has earned the trust of the core developers they can be elected> > as a member of the core team. This approach is used with the Jikes RVM> > (www.jikesrvm.org).> > I wouldn't object to such a policy, though I don't really think that> it is currently necessary. But if more active committers do prefer> it, we can set up the necessary commit checks. I assume that Randy Coleburn> and you are in favour of restricted commits? What about the others?> > Who would volunteer to review commits from other people? Would this> be a responsibility inherited by the unrestricted access?> > Should we allow commits to branches and only restrict access to the> main line?> > Olaf> -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194> > _________________________________________________________________ > Share life as it happens with the new Windows Live. > http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_012008 From hendrik at topoi.pooq.com Sat Jan 5 02:17:19 2008 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Fri, 4 Jan 2008 20:17:19 -0500 Subject: [M3devel] M3 concerns In-Reply-To: <20080105011335.n767h3zbz4gcgk4k@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> Message-ID: <20080105011719.GA5064@topoi.pooq.com> On Sat, Jan 05, 2008 at 01:13:35AM +0100, Olaf Wagner wrote: > Quoting Tony Hosking : > > >My comments embedded: > > > >On Jan 4, 2008, at 4:10 PM, Olaf Wagner wrote: > > >>Ah well, Windows is a somewhat special topic. I even haven't a system > >>here for tests, and most of the other contributors don't use it either. > >>I was of the opinion that Jay Krell had fixes or workarounds for most > >>current problems (except for the missing LONGINT support), but I haven't > >>tried his distribution archives yet. It would indeed be very helpful > >>if we could setup regression tests on Windows, too. > > > >LONGINT = INTEGER on Windows, which is fine as far as it goes > >(everything builds appropriately), but not particularly useful. > > I know that it should run this way, but pickles for example wouldn't > be exchangeable then, would they? Has anybody tested pickle support > for LONGINT yet? > > >>It would also be possible to define a group of reviewers for every > >>change, but I doubt that there would be enough competent volunteers, > >>and I'm afraid that it would rather repress development of CM3. > >>And we really need to have development, as the underlying systems and > >>techniques change and we need to adapt to that. So I'd vote for > >>free commits for everybody, as long as there are not too many > >>contributors, and setup of continually improved regression testing. > >>And we don't need to worry, as all changes can be reverted; we won't > >>lose development history with CVS. > > > >One option is to have moderated commits for non-core developers. After > >someone has earned the trust of the core developers they can be elected > >as a member of the core team. This approach is used with the Jikes RVM > >(www.jikesrvm.org). > > I wouldn't object to such a policy, though I don't really think that > it is currently necessary. But if more active committers do prefer > it, we can set up the necessary commit checks. I assume that Randy Coleburn > and you are in favour of restricted commits? What about the others? > > Who would volunteer to review commits from other people? Would this > be a responsibility inherited by the unrestricted access? > > Should we allow commits to branches and only restrict access to the > main line? The philosophy among the monotone developers (who use monotone as their revision control system) is to separate committing from certification. Anyone can commit a revision, which cen then be looked at, discussed, revised a few times, and if found worthy, certified. It gives them an informal kind of flexibility for small changes. Because monotone is a distributed revision conttrol system, they frequently have multiple heads in a branch (I prefer to call them leaves, or buds ready for the growth of new twigs). It's usualy to check out the most recent certified revision when you start a new bit of development. But being stuck with multiple heads, and having their system understand multiple heads, gives them a kind of flexibility that reflects the chaotic structure of real-sorld development. Official branches can also exist. If so, it's usually done by certifying revisions with different branch certificates. Botice that one same revision of one same file can be on several branches with no problems at all. I fact, it's perfectly possible to discover that development that has gone on for a few weeks really belongs on a different branch and so certify it after the fact. Now I'm not telling you to convert your whole development system to monotone, though I might advise it if you were looking for a new revision-control system. Such a changeover could involve substantial disruption. But looking at how it's done there might suggest possibilities after you map it hack to what you are using. The separation of commit from certify seems to be quite useful. -- hendrik From rcoleburn at scires.com Sat Jan 5 03:12:24 2008 From: rcoleburn at scires.com (Randy Coleburn) Date: Fri, 04 Jan 2008 21:12:24 -0500 Subject: [M3devel] 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> Message-ID: <477EA137.1E75.00D7.1@scires.com> Given the current situation, I'm not sure that moderated commits are practical. I think the best route is to get enough tests in place so that all developers can run a regression test suite BEFORE committing changes. Having an automated scoreboard would also help point out where things are broken and need fixing so that folks can volunteer to help. I'll try to find time again this weekend to do a build of cm3 on Windows XP again. If one goes to the website, there seems to be several choices for getting started, so I need some advice on the best way to move forward. 1. Get current sources from head branch and try to build from scratch (after first installing free Microsoft Visual C/C++ tools). 2. Get an older variant (5.2.6, 4.1, etc.) and try to use it to build the new current sources from CVS. 3. Get Jay's d5.5.0 min Win32 and use it to build the current sources from CVS. 4. ?? I know that there are some scripts that have been built to help in building things. One thing that would be helpful I think is to have a text file that lists the correct build sequence order for all packages in the repository. I know that some packages may not build on every platform, but if we keep this text file up-to-date, it would help folks as they work on scripts, etc. Also, I seem to recall that in the past that for some of the core packages, you had to build these twice in the process of getting everything up and running. Again, these facts need to be made very obvious so folks don't go down a wrong path. Once I get started on a path (1..4 above), I also need to know which of the current scripts to use in building on Windows XP to get the best results. I love the language and have been a zealous proponent of it for a long time, but we've got to make it easier for folks to get started with Modula-3. I will carefully document the steps I take in getting the system built on Windows so we can make this available to everyone. As for Jay's comment that he hasn't heard of anyone getting a "broken" version, please understand that I am not directing my comments at any one person, but rather to the system of "checks and balances" that need to be put in place for everyone. The last time I was able to get the sources and build on Windows was v5.26. That version didn't work correctly with some of my programs and I reported the problems to Olaf et al. The last time I checked out the sources and tried to build 5.40, I wound up with compiler errors. I recall some of these were related to LONGINT and some were related to the garbage collector. So yes, there was a situation where I checked out sources that represented a "broken" version in that it would not build. Thus, there are at least two types of "broken": (1) the system sources can't be built correctly, (2) the newly built system causes previously working code to misbehave when recompiled with the new system. Broken #1 should never be allowed to occur for the core system. From what Olaf said, the rule seems to be to keep broken #1 stuff in a branch and only merge it back into the main line when the broken state is resolved. Broken #2 should be avoided using regression test suites. The package status page at http://modula3.elegosoft.com/cm3/package-status.html is headed up by the title CM3 v5.1. Is this page up-to-date? It would be helpful to know where we stand wrt each package on each supported platform relative to the current source tree. Again, I think an automated scoreboard could make this possible. Sorry to ramble on so much in this post. My main interest is in getting the current sources built and running on Windows XP. As soon as I am successful, I will run tests using my code base. I have a number of programs that were built using cm3 v4.1 that are still in use. These use a lot of features, including pickles, netobj, trestle, etc. So, my tests should help uncover Broken #2 problems on Windows. Finally, once I get a working cm3 system on Windows, I'll provide the new cm3-IDE (aka Reactor) package. Regards, Randy >>> Jay 1/4/2008 8:04 PM >>> I oppose most red tape. However branching can be good, as long as there are frequent merges (between once a week and once a month..well, those timelines are based on other contexts, in this context, I don't know) and automated testing/buildmonkeys/tinderboxes. That is, if I'm in a ghetto branch, I loose both the pressure not to break things, because few/nobody else is in the branch, and the feedback loop of hearing that I've broken someone, so automation would be nice to replace that. I am not experienced with CVS though. I don't know how to setup or merge branches. Even browsing history I find painful, in one branch. Perforce I am quite familiar with. Subversion I learned enough about to know it doesn't suffice, so I'm leary of CVS, which is supposedly in all ways worse. In particular, Subversion doesn't track which changes have been merged from one branch to another. Whereas in Perforce that is a key feature of the system. Amazing that Subversion doesn't do it, but it is near the top of their wishlist. This is a small project. I haven't yet heard of anyone getting one of my possibly "in between" changes and being broken, and even when I checkin frequently, that doesn't mean any one state was broken or wrong. I haven't tested anything with Pickes. One set of tests I found failed all over the place, the m3tests stuff, floating point problems, I think a bunch of never implemented stuff on Windows around calling _fpcontrol or such (platform dependent). The system does build itself, the compiler and "std" packages. I consider that a pretty good start. I realize you can always do more, more and less obvious. There's probably no threading in the compiler, and maybe not even any garbage collection, nor any pickles. I'll look what Olaf commited over the weekend.. Bah humbug and happy new year, :) - Jay > Date: Sat, 5 Jan 2008 01:13:35 +0100 > From: wagner at elegosoft.com > To: hosking at cs.purdue.edu; m3devel at elegosoft.com > CC: m3-support at elegosoft.com > Subject: Re: [M3devel] M3 concerns > > Quoting Tony Hosking : > > > My comments embedded: > > > > On Jan 4, 2008, at 4:10 PM, Olaf Wagner wrote: > > >> Ah well, Windows is a somewhat special topic. I even haven't a system > >> here for tests, and most of the other contributors don't use it either. > >> I was of the opinion that Jay Krell had fixes or workarounds for most > >> current problems (except for the missing LONGINT support), but I haven't > >> tried his distribution archives yet. It would indeed be very helpful > >> if we could setup regression tests on Windows, too. > > > > LONGINT = INTEGER on Windows, which is fine as far as it goes > > (everything builds appropriately), but not particularly useful. > > I know that it should run this way, but pickles for example wouldn't > be exchangeable then, would they? Has anybody tested pickle support > for LONGINT yet? > > >> It would also be possible to define a group of reviewers for every > >> change, but I doubt that there would be enough competent volunteers, > >> and I'm afraid that it would rather repress development of CM3. > >> And we really need to have development, as the underlying systems and > >> techniques change and we need to adapt to that. So I'd vote for > >> free commits for everybody, as long as there are not too many > >> contributors, and setup of continually improved regression testing. > >> And we don't need to worry, as all changes can be reverted; we won't > >> lose development history with CVS. > > > > One option is to have moderated commits for non-core developers. After > > someone has earned the trust of the core developers they can be elected > > as a member of the core team. This approach is used with the Jikes RVM > > (www.jikesrvm.org). > > I wouldn't object to such a policy, though I don't really think that > it is currently necessary. But if more active committers do prefer > it, we can set up the necessary commit checks. I assume that Randy Coleburn > and you are in favour of restricted commits? What about the others? > > Who would volunteer to review commits from other people? Would this > be a responsibility inherited by the unrestricted access? > > Should we allow commits to branches and only restrict access to the > main line? > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > Share life as it happens with the new Windows Live. Start sharing! ( 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 Jan 5 05:24:17 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 5 Jan 2008 04:24:17 +0000 Subject: [M3devel] M3 concerns In-Reply-To: <477EA137.1E75.00D7.1@scires.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> <477EA137.1E75.00D7.1@scires.com> Message-ID: Anything that was broken in 5.2.6 is "probably" still broken."Probably" as in that *I* haven't fixed much.Not that *I* am a big deal or anything.Other folks might have fixed stuff. There's been some talk about GUI stuff and not much progress.I'm not much into GUI programming, though I can't standnot having a good GUI (hypocrite I am!) The build stuff, yes and no. There isn't QUITE a canonical build order it turns out.It's circular. I'll explain. I agree work is needed here though.I put forward a very lame candiate for improvement here inscripts\python\pylib.py where at least all the "filters" are in one place.Now any of scripts\python\do*.py can ask for whatever, no need toknow what works on what platform, and the filtering is centralized.The ordering is not. Hey, that's easy.But still, my representation is wrong. It should be a more generic textformat and less actual Python code. Except that there isn't one ordering. I will explain in a sec. For your options 1-4, well, hey, I've endeavored to keep multiple options working.Don't be confused. Just pick one. :) Specifically, you can start with 5.2.6 and run scripts\win\upgrade.It WAS broken recently, related to LONGINT, but it is fixed now.(There isn't yet scripts\python\upgrade, but I promise there will be. :) ) Or you can take my 5.5.0 distribution, and run "anything". I would also recommend you take the exact checked in config file.m3-sys\cminstall\src\config\NT386.It shouldn't require any edits. Feel free to read it, and consider editing it,but it shouldn't require any. I'm assuming current source.There should be no need to "sync backward" or such.I have even endeavored to make one cm3.cfg file work with latest and older source.That is still a developing story on PPC_DARWIN and PPC_LINUX.(And "autoconf-ish" instead of "version checking" checks might be good) You should be able to use just about any Visual C++ toolset.I put in fixes to accomodate various versions.Of course, 8.0 is about the best. 9.0 is a recent release.The releases are all high quality in my experience. Ok, let me explain the ordering thing.There is a necessary circular dependency between the compiler and runtime.You cannot build the runtime unless you have a compiler.You cannot build a compiler unless you have a runtime.An older compiler cannot compile the current runtime, because of LONGINT. Or could be other reasons in the future.However if you already have a runtime (somehow), an older compiler cancompile a current compiler, and then you can use the new compiler tobuild the current runtime, and then rebuild (or at least relink),the compiler against the current runtime. (I'm not sure "compile" and "link"apply per se in Modula-3, I'm not sure it builds in quite the traditionalway.) scripts\win\make-dist and scripts\win\upgrade both take care of this.They can both start with a 5.2.6 compiler/runtime, or a current compiler/runtime.They do waste time if starting with current.Yes, they do build the compiler twice. At some point the first computers must have been built from sticks and rocks and dirt,but once they were working, the second computer could be built with more advanced materials. In particular, the first Modula-3 compiler was probably written in C.The first C compiler was probably written in assembly. Or maybe written in C and hand compiled into assembly.The first assembler was probably hand translated into "machine code". Bootstrapping is a funny thing.Circular dependencies seem wrong, but they are necessary. Bootstrappability from earlier than 5.2 I cannot at this time vouch for.I was thinking of trying with 3.6 which I have and 4.1 if I can find my CD.But it might not be easy and it might be fairly pointless.Bootstrapping does tend to lead to building up and up and up and an inabilityto jump from the initial step to the latest. You do, I expect, restthe starting level from time to time. 3.6 does still build quite easily out of the box on current systems.I built it last week. :)(Only NT386.) Oh, also, the order "only" matters when you don't have a package store already and/or you are changing types. If you are only changing code, and you already have a packge store you can build in any order. When you are changing types, or don't have a package store, I believe you have to build from the bottom of the dependency graph and on up. If you ignore the compiler, the dependency graph that I have in my head is just m3core, then libm3, then everything else. The compiler, well, you get clear errors as to what is missing if you build it out of order. I'll get some ordering into scripts\python, excluding the circularity. I may be mispresenting the circularity. It's probably really m3core, libm3, then the compiler but in the bootstrapping case, you must already have m3core and libm3, from a different build. The circularity exists, but maybe in sort of different terms. You don't need the compiler's .i3 files published to build libm3/m3core, you just need a cm3.exe. - Jay Date: Fri, 4 Jan 2008 21:12:24 -0500From: rcoleburn at scires.comTo: hosking at cs.purdue.edu; m3devel at elegosoft.com; wagner at elegosoft.com; jayk123 at hotmail.comCC: m3-support at elegosoft.comSubject: Re: [M3devel] M3 concerns Given the current situation, I'm not sure that moderated commits are practical. I think the best route is to get enough tests in place so that all developers can run a regression test suite BEFORE committing changes. Having an automated scoreboard would also help point out where things are broken and need fixing so that folks can volunteer to help. I'll try to find time again this weekend to do a build of cm3 on Windows XP again. If one goes to the website, there seems to be several choices for getting started, so I need some advice on the best way to move forward. 1. Get current sources from head branch and try to build from scratch (after first installing free Microsoft Visual C/C++ tools). 2. Get an older variant (5.2.6, 4.1, etc.) and try to use it to build the new current sources from CVS. 3. Get Jay's d5.5.0 min Win32 and use it to build the current sources from CVS. 4. ?? I know that there are some scripts that have been built to help in building things. One thing that would be helpful I think is to have a text file that lists the correct build sequence order for all packages in the repository. I know that some packages may not build on every platform, but if we keep this text file up-to-date, it would help folks as they work on scripts, etc. Also, I seem to recall that in the past that for some of the core packages, you had to build these twice in the process of getting everything up and running. Again, these facts need to be made very obvious so folks don't go down a wrong path. Once I get started on a path (1..4 above), I also need to know which of the current scripts to use in building on Windows XP to get the best results. I love the language and have been a zealous proponent of it for a long time, but we've got to make it easier for folks to get started with Modula-3. I will carefully document the steps I take in getting the system built on Windows so we can make this available to everyone. As for Jay's comment that he hasn't heard of anyone getting a "broken" version, please understand that I am not directing my comments at any one person, but rather to the system of "checks and balances" that need to be put in place for everyone. The last time I was able to get the sources and build on Windows was v5.26. That version didn't work correctly with some of my programs and I reported the problems to Olaf et al. The last time I checked out the sources and tried to build 5.40, I wound up with compiler errors. I recall some of these were related to LONGINT and some were related to the garbage collector. So yes, there was a situation where I checked out sources that represented a "broken" version in that it would not build. Thus, there are at least two types of "broken": (1) the system sources can't be built correctly, (2) the newly built system causes previously working code to misbehave when recompiled with the new system. Broken #1 should never be allowed to occur for the core system. From what Olaf said, the rule seems to be to keep broken #1 stuff in a branch and only merge it back into the main line when the broken state is resolved. Broken #2 should be avoided using regression test suites. The package status page at http://modula3.elegosoft.com/cm3/package-status.html is headed up by the title CM3 v5.1. Is this page up-to-date? It would be helpful to know where we stand wrt each package on each supported platform relative to the current source tree. Again, I think an automated scoreboard could make this possible. Sorry to ramble on so much in this post. My main interest is in getting the current sources built and running on Windows XP. As soon as I am successful, I will run tests using my code base. I have a number of programs that were built using cm3 v4.1 that are still in use. These use a lot of features, including pickles, netobj, trestle, etc. So, my tests should help uncover Broken #2 problems on Windows. Finally, once I get a working cm3 system on Windows, I'll provide the new cm3-IDE (aka Reactor) package. Regards, Randy>>> Jay 1/4/2008 8:04 PM >>>I oppose most red tape. However branching can be good, as long as there are frequent merges (between once a week and once a month..well, those timelines are based on other contexts, in this context, I don't know) and automated testing/buildmonkeys/tinderboxes. That is, if I'm in a ghetto branch, I loose both the pressure not to break things, because few/nobody else is in the branch, and the feedback loop of hearing that I've broken someone, so automation would be nice to replace that. I am not experienced with CVS though. I don't know how to setup or merge branches. Even browsing history I find painful, in one branch.Perforce I am quite familiar with.Subversion I learned enough about to know it doesn't suffice, so I'm leary of CVS, which is supposedly in all ways worse.In particular, Subversion doesn't track which changes have been merged from one branch to another. Whereas in Perforce that is a key feature of the system. Amazing that Subversion doesn't do it, but it is near the top of their wishlist. This is a small project.I haven't yet heard of anyone getting one of my possibly "in between" changes and being broken, and even when I checkin frequently, that doesn't mean any one state was broken or wrong. I haven't tested anything with Pickes. One set of tests I found failed all over the place, the m3tests stuff, floating point problems, I think a bunch of never implemented stuff on Windows around calling _fpcontrol or such (platform dependent). The system does build itself, the compiler and "std" packages. I consider that a pretty good start.I realize you can always do more, more and less obvious. There's probably no threading in the compiler, and maybe not even any garbage collection, nor any pickles. I'll look what Olaf commited over the weekend.. Bah humbug and happy new year, :) - Jay > Date: Sat, 5 Jan 2008 01:13:35 +0100> From: wagner at elegosoft.com> To: hosking at cs.purdue.edu; m3devel at elegosoft.com> CC: m3-support at elegosoft.com> Subject: Re: [M3devel] M3 concerns> > Quoting Tony Hosking :> > > My comments embedded:> >> > On Jan 4, 2008, at 4:10 PM, Olaf Wagner wrote:> > >> Ah well, Windows is a somewhat special topic. I even haven't a system> >> here for tests, and most of the other contributors don't use it either.> >> I was of the opinion that Jay Krell had fixes or workarounds for most> >> current problems (except for the missing LONGINT support), but I haven't> >> tried his distribution archives yet. It would indeed be very helpful> >> if we could setup regression tests on Windows, too.> >> > LONGINT = INTEGER on Windows, which is fine as far as it goes> > (everything builds appropriately), but not particularly useful.> > I know that it should run this way, but pickles for example wouldn't> be exchangeable then, would they? Has anybody tested pickle support> for LONGINT yet?> > >> It would also be possible to define a group of reviewers for every> >> change, but I doubt that there would be enough competent volunteers,> >> and I'm afraid that it would rather repress development of CM3.> >> And we really need to have development, as the underlying systems and> >> techniques change and we need to adapt to that. So I'd vote for> >> free commits for everybody, as long as there are not too many> >> contributors, and setup of continually improved regression testing.> >> And we don't need to worry, as all changes can be reverted; we won't> >> lose development history with CVS.> >> > One option is to have moderated commits for non-core developers. After> > someone has earned the trust of the core developers they can be elected> > as a member of the core team. This approach is used with the Jikes RVM> > (www.jikesrvm.org).> > I wouldn't object to such a policy, though I don't really think that> it is currently necessary. But if more active committers do prefer> it, we can set up the necessary commit checks. I assume that Randy Coleburn> and you are in favour of restricted commits? What about the others?> > Who would volunteer to review commits from other people? Would this> be a responsibility inherited by the unrestricted access?> > Should we allow commits to branches and only restrict access to the> main line?> > Olaf> -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194> Share life as it happens with the new Windows Live. Start sharing! _________________________________________________________________ Share life as it happens with the new Windows Live. http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Sat Jan 5 05:31:03 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 5 Jan 2008 04:31:03 +0000 Subject: [M3devel] 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> <477EA137.1E75.00D7.1@scires.com> Message-ID: Randy if you want to try remote assistance or call me on the phone over the weekend, that's fine. OR, I would agree, that might be cheating. Do it yourself and pound out the good documentation, if you want. Either way. If you cheat, you can always let the next guy tough it out and update the docs. :) There is a checked in document. installation-windows.html or such, though...I'm not the best writer... 1. Get current sources from head branch and try to build from scratch (after first installing free Microsoft Visual C/C++ tools). Not possible -- er, not sufficient. You must start with an existing CM3 distribution as well..the system is written in Modula-3 after all, and CM3 doesn't currently ship the "boot" archives like Digital did, where you just need a C compiler and linker. Heck, it's "binaries" either way. CM3 ships .exes, Digital shipped .obj files. 5.5.0 or 5.2.6 will work. Anything else, I haven't tried (I'm using 5.2.4 on another platform). If you have a particular need/desire/motivation to start with 3.6 or 4.1 or whatever, let me know and I can try. Otherwise, not clear it is interesting. I don't think bootstrapping from *any* version is necessarily interesting, you have to advance sometimes, I think. - Jay From: jayk123 at hotmail.comTo: rcoleburn at scires.com; hosking at cs.purdue.edu; m3devel at elegosoft.com; wagner at elegosoft.comDate: Sat, 5 Jan 2008 04:24:17 +0000CC: m3-support at elegosoft.comSubject: Re: [M3devel] M3 concerns Anything that was broken in 5.2.6 is "probably" still broken."Probably" as in that *I* haven't fixed much.Not that *I* am a big deal or anything.Other folks might have fixed stuff.There's been some talk about GUI stuff and not much progress.I'm not much into GUI programming, though I can't standnot having a good GUI (hypocrite I am!)The build stuff, yes and no.There isn't QUITE a canonical build order it turns out.It's circular. I'll explain.I agree work is needed here though.I put forward a very lame candiate for improvement here inscripts\python\pylib.py where at least all the "filters" are in one place.Now any of scripts\python\do*.py can ask for whatever, no need toknow what works on what platform, and the filtering is centralized.The ordering is not. Hey, that's easy.But still, my representation is wrong. It should be a more generic textformat and less actual Python code.Except that there isn't one ordering. I will explain in a sec.For your options 1-4, well, hey, I've endeavored to keep multiple options working.Don't be confused. Just pick one. :)Specifically, you can start with 5.2.6 and run scripts\win\upgrade.It WAS broken recently, related to LONGINT, but it is fixed now.(There isn't yet scripts\python\upgrade, but I promise there will be. :) )Or you can take my 5.5.0 distribution, and run "anything".I would also recommend you take the exact checked in config file.m3-sys\cminstall\src\config\NT386.It shouldn't require any edits. Feel free to read it, and consider editing it,but it shouldn't require any.I'm assuming current source.There should be no need to "sync backward" or such.I have even endeavored to make one cm3.cfg file work with latest and older source.That is still a developing story on PPC_DARWIN and PPC_LINUX.(And "autoconf-ish" instead of "version checking" checks might be good)You should be able to use just about any Visual C++ toolset.I put in fixes to accomodate various versions.Of course, 8.0 is about the best. 9.0 is a recent release.The releases are all high quality in my experience.Ok, let me explain the ordering thing.There is a necessary circular dependency between the compiler and runtime.You cannot build the runtime unless you have a compiler.You cannot build a compiler unless you have a runtime.An older compiler cannot compile the current runtime, because of LONGINT. Or could be other reasons in the future.However if you already have a runtime (somehow), an older compiler cancompile a current compiler, and then you can use the new compiler tobuild the current runtime, and then rebuild (or at least relink),the compiler against the current runtime. (I'm not sure "compile" and "link"apply per se in Modula-3, I'm not sure it builds in quite the traditionalway.)scripts\win\make-dist and scripts\win\upgrade both take care of this.They can both start with a 5.2.6 compiler/runtime, or a current compiler/runtime.They do waste time if starting with current.Yes, they do build the compiler twice.At some point the first computers must have been built from sticks and rocks and dirt,but once they were working, the second computer could be built with more advanced materials.In particular, the first Modula-3 compiler was probably written in C.The first C compiler was probably written in assembly. Or maybe written in C and hand compiled into assembly.The first assembler was probably hand translated into "machine code".Bootstrapping is a funny thing.Circular dependencies seem wrong, but they are necessary.Bootstrappability from earlier than 5.2 I cannot at this time vouch for.I was thinking of trying with 3.6 which I have and 4.1 if I can find my CD.But it might not be easy and it might be fairly pointless.Bootstrapping does tend to lead to building up and up and up and an inabilityto jump from the initial step to the latest. You do, I expect, restthe starting level from time to time.3.6 does still build quite easily out of the box on current systems.I built it last week. :)(Only NT386.) Oh, also, the order "only" matters when you don't have a package store already and/or you are changing types.If you are only changing code, and you already have a packge store you can build in any order.When you are changing types, or don't have a package store, I believe you have to build from the bottom of the dependency graph and on up. If you ignore the compiler, the dependency graph that I have in my head is just m3core, then libm3, then everything else. The compiler, well, you get clear errors as to what is missing if you build it out of order. I'll get some ordering into scripts\python, excluding the circularity. I may be mispresenting the circularity. It's probably really m3core, libm3, then the compiler but in the bootstrapping case, you must already have m3core and libm3, from a different build. The circularity exists, but maybe in sort of different terms. You don't need the compiler's .i3 files published to build libm3/m3core, you just need a cm3.exe. - Jay Date: Fri, 4 Jan 2008 21:12:24 -0500From: rcoleburn at scires.comTo: hosking at cs.purdue.edu; m3devel at elegosoft.com; wagner at elegosoft.com; jayk123 at hotmail.comCC: m3-support at elegosoft.comSubject: Re: [M3devel] M3 concerns Given the current situation, I'm not sure that moderated commits are practical. I think the best route is to get enough tests in place so that all developers can run a regression test suite BEFORE committing changes. Having an automated scoreboard would also help point out where things are broken and need fixing so that folks can volunteer to help. I'll try to find time again this weekend to do a build of cm3 on Windows XP again. If one goes to the website, there seems to be several choices for getting started, so I need some advice on the best way to move forward. 1. Get current sources from head branch and try to build from scratch (after first installing free Microsoft Visual C/C++ tools). 2. Get an older variant (5.2.6, 4.1, etc.) and try to use it to build the new current sources from CVS. 3. Get Jay's d5.5.0 min Win32 and use it to build the current sources from CVS. 4. ?? I know that there are some scripts that have been built to help in building things. One thing that would be helpful I think is to have a text file that lists the correct build sequence order for all packages in the repository. I know that some packages may not build on every platform, but if we keep this text file up-to-date, it would help folks as they work on scripts, etc. Also, I seem to recall that in the past that for some of the core packages, you had to build these twice in the process of getting everything up and running. Again, these facts need to be made very obvious so folks don't go down a wrong path. Once I get started on a path (1..4 above), I also need to know which of the current scripts to use in building on Windows XP to get the best results. I love the language and have been a zealous proponent of it for a long time, but we've got to make it easier for folks to get started with Modula-3. I will carefully document the steps I take in getting the system built on Windows so we can make this available to everyone. As for Jay's comment that he hasn't heard of anyone getting a "broken" version, please understand that I am not directing my comments at any one person, but rather to the system of "checks and balances" that need to be put in place for everyone. The last time I was able to get the sources and build on Windows was v5.26. That version didn't work correctly with some of my programs and I reported the problems to Olaf et al. The last time I checked out the sources and tried to build 5.40, I wound up with compiler errors. I recall some of these were related to LONGINT and some were related to the garbage collector. So yes, there was a situation where I checked out sources that represented a "broken" version in that it would not build. Thus, there are at least two types of "broken": (1) the system sources can't be built correctly, (2) the newly built system causes previously working code to misbehave when recompiled with the new system. Broken #1 should never be allowed to occur for the core system. From what Olaf said, the rule seems to be to keep broken #1 stuff in a branch and only merge it back into the main line when the broken state is resolved. Broken #2 should be avoided using regression test suites. The package status page at http://modula3.elegosoft.com/cm3/package-status.html is headed up by the title CM3 v5.1. Is this page up-to-date? It would be helpful to know where we stand wrt each package on each supported platform relative to the current source tree. Again, I think an automated scoreboard could make this possible. Sorry to ramble on so much in this post. My main interest is in getting the current sources built and running on Windows XP. As soon as I am successful, I will run tests using my code base. I have a number of programs that were built using cm3 v4.1 that are still in use. These use a lot of features, including pickles, netobj, trestle, etc. So, my tests should help uncover Broken #2 problems on Windows. Finally, once I get a working cm3 system on Windows, I'll provide the new cm3-IDE (aka Reactor) package. Regards, Randy>>> Jay 1/4/2008 8:04 PM >>>I oppose most red tape. However branching can be good, as long as there are frequent merges (between once a week and once a month..well, those timelines are based on other contexts, in this context, I don't know) and automated testing/buildmonkeys/tinderboxes. That is, if I'm in a ghetto branch, I loose both the pressure not to break things, because few/nobody else is in the branch, and the feedback loop of hearing that I've broken someone, so automation would be nice to replace that. I am not experienced with CVS though. I don't know how to setup or merge branches. Even browsing history I find painful, in one branch.Perforce I am quite familiar with.Subversion I learned enough about to know it doesn't suffice, so I'm leary of CVS, which is supposedly in all ways worse.In particular, Subversion doesn't track which changes have been merged from one branch to another. Whereas in Perforce that is a key feature of the system. Amazing that Subversion doesn't do it, but it is near the top of their wishlist. This is a small project.I haven't yet heard of anyone getting one of my possibly "in between" changes and being broken, and even when I checkin frequently, that doesn't mean any one state was broken or wrong. I haven't tested anything with Pickes. One set of tests I found failed all over the place, the m3tests stuff, floating point problems, I think a bunch of never implemented stuff on Windows around calling _fpcontrol or such (platform dependent). The system does build itself, the compiler and "std" packages. I consider that a pretty good start.I realize you can always do more, more and less obvious. There's probably no threading in the compiler, and maybe not even any garbage collection, nor any pickles. I'll look what Olaf commited over the weekend.. Bah humbug and happy new year, :) - Jay > Date: Sat, 5 Jan 2008 01:13:35 +0100> From: wagner at elegosoft.com> To: hosking at cs.purdue.edu; m3devel at elegosoft.com> CC: m3-support at elegosoft.com> Subject: Re: [M3devel] M3 concerns> > Quoting Tony Hosking :> > > My comments embedded:> >> > On Jan 4, 2008, at 4:10 PM, Olaf Wagner wrote:> > >> Ah well, Windows is a somewhat special topic. I even haven't a system> >> here for tests, and most of the other contributors don't use it either.> >> I was of the opinion that Jay Krell had fixes or workarounds for most> >> current problems (except for the missing LONGINT support), but I haven't> >> tried his distribution archives yet. It would indeed be very helpful> >> if we could setup regression tests on Windows, too.> >> > LONGINT = INTEGER on Windows, which is fine as far as it goes> > (everything builds appropriately), but not particularly useful.> > I know that it should run this way, but pickles for example wouldn't> be exchangeable then, would they? Has anybody tested pickle support> for LONGINT yet?> > >> It would also be possible to define a group of reviewers for every> >> change, but I doubt that there would be enough competent volunteers,> >> and I'm afraid that it would rather repress development of CM3.> >> And we really need to have development, as the underlying systems and> >> techniques change and we need to adapt to that. So I'd vote for> >> free commits for everybody, as long as there are not too many> >> contributors, and setup of continually improved regression testing.> >> And we don't need to worry, as all changes can be reverted; we won't> >> lose development history with CVS.> >> > One option is to have moderated commits for non-core developers. After> > someone has earned the trust of the core developers they can be elected> > as a member of the core team. This approach is used with the Jikes RVM> > (www.jikesrvm.org).> > I wouldn't object to such a policy, though I don't really think that> it is currently necessary. But if more active committers do prefer> it, we can set up the necessary commit checks. I assume that Randy Coleburn> and you are in favour of restricted commits? What about the others?> > Who would volunteer to review commits from other people? Would this> be a responsibility inherited by the unrestricted access?> > Should we allow commits to branches and only restrict access to the> main line?> > Olaf> -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194> Share life as it happens with the new Windows Live. Start sharing! Share life as it happens with the new Windows Live. Start sharing! _________________________________________________________________ Put your friends on the big screen with Windows Vista? + Windows Live?. http://www.microsoft.com/windows/shop/specialoffers.mspx?ocid=TXT_TAGLM_CPC_MediaCtr_bigscreen_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Sat Jan 5 05:41:01 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 5 Jan 2008 04:41:01 +0000 Subject: [M3devel] 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> <477EA137.1E75.00D7.1@scires.com> Message-ID: darnit -- one more thing...yeah, I know my email sucks, but you get what you pay for :) Randy asked how to build "everything". "everything" == "standard" == "std". scripts\do-cm3-std.sh scripts\win\do-cm3-std.cmd and def-std-pkgs.sh or such scripts\python\do-cm3-std.py coming soon Yeah, the scripts directory..confused me at first too. So I rewrote it... :) More data driven would be good. If someone can propose the text file format, including specifying the "filters", I can implement the cmd and Python...oh should really move on to using Modula-3 though, stick the knowledge into cm3 itself. cm3 -build libm3 m3core cm3.... Two types of broken, right -- build breaks and run breaks, static breaks and dynamic breaks. - Jay From: jayk123 at hotmail.comTo: rcoleburn at scires.com; hosking at cs.purdue.edu; m3devel at elegosoft.com; wagner at elegosoft.comDate: Sat, 5 Jan 2008 04:31:03 +0000CC: m3-support at elegosoft.comSubject: Re: [M3devel] M3 concerns Randy if you want to try remote assistance or call me on the phone over the weekend, that's fine.OR, I would agree, that might be cheating. Do it yourself and pound out the good documentation, if you want. Either way. If you cheat, you can always let the next guy tough it out and update the docs. :)There is a checked in document. installation-windows.html or such, though...I'm not the best writer... 1. Get current sources from head branch and try to build from scratch (after first installing free Microsoft Visual C/C++ tools). Not possible -- er, not sufficient. You must start with an existing CM3 distribution as well..the system is written in Modula-3 after all, and CM3 doesn't currently ship the "boot" archives like Digital did, where you just need a C compiler and linker. Heck, it's "binaries" either way. CM3 ships .exes, Digital shipped .obj files. 5.5.0 or 5.2.6 will work. Anything else, I haven't tried (I'm using 5.2.4 on another platform). If you have a particular need/desire/motivation to start with 3.6 or 4.1 or whatever, let me know and I can try. Otherwise, not clear it is interesting. I don't think bootstrapping from *any* version is necessarily interesting, you have to advance sometimes, I think. - Jay From: jayk123 at hotmail.comTo: rcoleburn at scires.com; hosking at cs.purdue.edu; m3devel at elegosoft.com; wagner at elegosoft.comDate: Sat, 5 Jan 2008 04:24:17 +0000CC: m3-support at elegosoft.comSubject: Re: [M3devel] M3 concerns Anything that was broken in 5.2.6 is "probably" still broken."Probably" as in that *I* haven't fixed much.Not that *I* am a big deal or anything.Other folks might have fixed stuff.There's been some talk about GUI stuff and not much progress.I'm not much into GUI programming, though I can't standnot having a good GUI (hypocrite I am!)The build stuff, yes and no.There isn't QUITE a canonical build order it turns out.It's circular. I'll explain.I agree work is needed here though.I put forward a very lame candiate for improvement here inscripts\python\pylib.py where at least all the "filters" are in one place.Now any of scripts\python\do*.py can ask for whatever, no need toknow what works on what platform, and the filtering is centralized.The ordering is not. Hey, that's easy.But still, my representation is wrong. It should be a more generic textformat and less actual Python code.Except that there isn't one ordering. I will explain in a sec.For your options 1-4, well, hey, I've endeavored to keep multiple options working.Don't be confused. Just pick one. :)Specifically, you can start with 5.2.6 and run scripts\win\upgrade.It WAS broken recently, related to LONGINT, but it is fixed now.(There isn't yet scripts\python\upgrade, but I promise there will be. :) )Or you can take my 5.5.0 distribution, and run "anything".I would also recommend you take the exact checked in config file.m3-sys\cminstall\src\config\NT386.It shouldn't require any edits. Feel free to read it, and consider editing it,but it shouldn't require any.I'm assuming current source.There should be no need to "sync backward" or such.I have even endeavored to make one cm3.cfg file work with latest and older source.That is still a developing story on PPC_DARWIN and PPC_LINUX.(And "autoconf-ish" instead of "version checking" checks might be good)You should be able to use just about any Visual C++ toolset.I put in fixes to accomodate various versions.Of course, 8.0 is about the best. 9.0 is a recent release.The releases are all high quality in my experience.Ok, let me explain the ordering thing.There is a necessary circular dependency between the compiler and runtime.You cannot build the runtime unless you have a compiler.You cannot build a compiler unless you have a runtime.An older compiler cannot compile the current runtime, because of LONGINT. Or could be other reasons in the future.However if you already have a runtime (somehow), an older compiler cancompile a current compiler, and then you can use the new compiler tobuild the current runtime, and then rebuild (or at least relink),the compiler against the current runtime. (I'm not sure "compile" and "link"apply per se in Modula-3, I'm not sure it builds in quite the traditionalway.)scripts\win\make-dist and scripts\win\upgrade both take care of this.They can both start with a 5.2.6 compiler/runtime, or a current compiler/runtime.They do waste time if starting with current.Yes, they do build the compiler twice.At some point the first computers must have been built from sticks and rocks and dirt,but once they were working, the second computer could be built with more advanced materials.In particular, the first Modula-3 compiler was probably written in C.The first C compiler was probably written in assembly. Or maybe written in C and hand compiled into assembly.The first assembler was probably hand translated into "machine code".Bootstrapping is a funny thing.Circular dependencies seem wrong, but they are necessary.Bootstrappability from earlier than 5.2 I cannot at this time vouch for.I was thinking of trying with 3.6 which I have and 4.1 if I can find my CD.But it might not be easy and it might be fairly pointless.Bootstrapping does tend to lead to building up and up and up and an inabilityto jump from the initial step to the latest. You do, I expect, restthe starting level from time to time.3.6 does still build quite easily out of the box on current systems.I built it last week. :)(Only NT386.) Oh, also, the order "only" matters when you don't have a package store already and/or you are changing types.If you are only changing code, and you already have a packge store you can build in any order.When you are changing types, or don't have a package store, I believe you have to build from the bottom of the dependency graph and on up. If you ignore the compiler, the dependency graph that I have in my head is just m3core, then libm3, then everything else. The compiler, well, you get clear errors as to what is missing if you build it out of order. I'll get some ordering into scripts\python, excluding the circularity. I may be mispresenting the circularity. It's probably really m3core, libm3, then the compiler but in the bootstrapping case, you must already have m3core and libm3, from a different build. The circularity exists, but maybe in sort of different terms. You don't need the compiler's .i3 files published to build libm3/m3core, you just need a cm3.exe. - Jay Date: Fri, 4 Jan 2008 21:12:24 -0500From: rcoleburn at scires.comTo: hosking at cs.purdue.edu; m3devel at elegosoft.com; wagner at elegosoft.com; jayk123 at hotmail.comCC: m3-support at elegosoft.comSubject: Re: [M3devel] M3 concerns Given the current situation, I'm not sure that moderated commits are practical. I think the best route is to get enough tests in place so that all developers can run a regression test suite BEFORE committing changes. Having an automated scoreboard would also help point out where things are broken and need fixing so that folks can volunteer to help. I'll try to find time again this weekend to do a build of cm3 on Windows XP again. If one goes to the website, there seems to be several choices for getting started, so I need some advice on the best way to move forward. 1. Get current sources from head branch and try to build from scratch (after first installing free Microsoft Visual C/C++ tools). 2. Get an older variant (5.2.6, 4.1, etc.) and try to use it to build the new current sources from CVS. 3. Get Jay's d5.5.0 min Win32 and use it to build the current sources from CVS. 4. ?? I know that there are some scripts that have been built to help in building things. One thing that would be helpful I think is to have a text file that lists the correct build sequence order for all packages in the repository. I know that some packages may not build on every platform, but if we keep this text file up-to-date, it would help folks as they work on scripts, etc. Also, I seem to recall that in the past that for some of the core packages, you had to build these twice in the process of getting everything up and running. Again, these facts need to be made very obvious so folks don't go down a wrong path. Once I get started on a path (1..4 above), I also need to know which of the current scripts to use in building on Windows XP to get the best results. I love the language and have been a zealous proponent of it for a long time, but we've got to make it easier for folks to get started with Modula-3. I will carefully document the steps I take in getting the system built on Windows so we can make this available to everyone. As for Jay's comment that he hasn't heard of anyone getting a "broken" version, please understand that I am not directing my comments at any one person, but rather to the system of "checks and balances" that need to be put in place for everyone. The last time I was able to get the sources and build on Windows was v5.26. That version didn't work correctly with some of my programs and I reported the problems to Olaf et al. The last time I checked out the sources and tried to build 5.40, I wound up with compiler errors. I recall some of these were related to LONGINT and some were related to the garbage collector. So yes, there was a situation where I checked out sources that represented a "broken" version in that it would not build. Thus, there are at least two types of "broken": (1) the system sources can't be built correctly, (2) the newly built system causes previously working code to misbehave when recompiled with the new system. Broken #1 should never be allowed to occur for the core system. From what Olaf said, the rule seems to be to keep broken #1 stuff in a branch and only merge it back into the main line when the broken state is resolved. Broken #2 should be avoided using regression test suites. The package status page at http://modula3.elegosoft.com/cm3/package-status.html is headed up by the title CM3 v5.1. Is this page up-to-date? It would be helpful to know where we stand wrt each package on each supported platform relative to the current source tree. Again, I think an automated scoreboard could make this possible. Sorry to ramble on so much in this post. My main interest is in getting the current sources built and running on Windows XP. As soon as I am successful, I will run tests using my code base. I have a number of programs that were built using cm3 v4.1 that are still in use. These use a lot of features, including pickles, netobj, trestle, etc. So, my tests should help uncover Broken #2 problems on Windows. Finally, once I get a working cm3 system on Windows, I'll provide the new cm3-IDE (aka Reactor) package. Regards, Randy>>> Jay 1/4/2008 8:04 PM >>>I oppose most red tape. However branching can be good, as long as there are frequent merges (between once a week and once a month..well, those timelines are based on other contexts, in this context, I don't know) and automated testing/buildmonkeys/tinderboxes. That is, if I'm in a ghetto branch, I loose both the pressure not to break things, because few/nobody else is in the branch, and the feedback loop of hearing that I've broken someone, so automation would be nice to replace that. I am not experienced with CVS though. I don't know how to setup or merge branches. Even browsing history I find painful, in one branch.Perforce I am quite familiar with.Subversion I learned enough about to know it doesn't suffice, so I'm leary of CVS, which is supposedly in all ways worse.In particular, Subversion doesn't track which changes have been merged from one branch to another. Whereas in Perforce that is a key feature of the system. Amazing that Subversion doesn't do it, but it is near the top of their wishlist. This is a small project.I haven't yet heard of anyone getting one of my possibly "in between" changes and being broken, and even when I checkin frequently, that doesn't mean any one state was broken or wrong. I haven't tested anything with Pickes. One set of tests I found failed all over the place, the m3tests stuff, floating point problems, I think a bunch of never implemented stuff on Windows around calling _fpcontrol or such (platform dependent). The system does build itself, the compiler and "std" packages. I consider that a pretty good start.I realize you can always do more, more and less obvious. There's probably no threading in the compiler, and maybe not even any garbage collection, nor any pickles. I'll look what Olaf commited over the weekend.. Bah humbug and happy new year, :) - Jay > Date: Sat, 5 Jan 2008 01:13:35 +0100> From: wagner at elegosoft.com> To: hosking at cs.purdue.edu; m3devel at elegosoft.com> CC: m3-support at elegosoft.com> Subject: Re: [M3devel] M3 concerns> > Quoting Tony Hosking :> > > My comments embedded:> >> > On Jan 4, 2008, at 4:10 PM, Olaf Wagner wrote:> > >> Ah well, Windows is a somewhat special topic. I even haven't a system> >> here for tests, and most of the other contributors don't use it either.> >> I was of the opinion that Jay Krell had fixes or workarounds for most> >> current problems (except for the missing LONGINT support), but I haven't> >> tried his distribution archives yet. It would indeed be very helpful> >> if we could setup regression tests on Windows, too.> >> > LONGINT = INTEGER on Windows, which is fine as far as it goes> > (everything builds appropriately), but not particularly useful.> > I know that it should run this way, but pickles for example wouldn't> be exchangeable then, would they? Has anybody tested pickle support> for LONGINT yet?> > >> It would also be possible to define a group of reviewers for every> >> change, but I doubt that there would be enough competent volunteers,> >> and I'm afraid that it would rather repress development of CM3.> >> And we really need to have development, as the underlying systems and> >> techniques change and we need to adapt to that. So I'd vote for> >> free commits for everybody, as long as there are not too many> >> contributors, and setup of continually improved regression testing.> >> And we don't need to worry, as all changes can be reverted; we won't> >> lose development history with CVS.> >> > One option is to have moderated commits for non-core developers. After> > someone has earned the trust of the core developers they can be elected> > as a member of the core team. This approach is used with the Jikes RVM> > (www.jikesrvm.org).> > I wouldn't object to such a policy, though I don't really think that> it is currently necessary. But if more active committers do prefer> it, we can set up the necessary commit checks. I assume that Randy Coleburn> and you are in favour of restricted commits? What about the others?> > Who would volunteer to review commits from other people? Would this> be a responsibility inherited by the unrestricted access?> > Should we allow commits to branches and only restrict access to the> main line?> > Olaf> -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194> Share life as it happens with the new Windows Live. Start sharing! Share life as it happens with the new Windows Live. Start sharing! Put your friends on the big screen with Windows Vista? + Windows Live?. Start now! _________________________________________________________________ Put your friends on the big screen with Windows Vista? + Windows Live?. http://www.microsoft.com/windows/shop/specialoffers.mspx?ocid=TXT_TAGLM_CPC_MediaCtr_bigscreen_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: From lemming at henning-thielemann.de Sat Jan 5 09:44:40 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Sat, 05 Jan 2008 09:44:40 +0100 (CET) Subject: [M3devel] M3 concerns In-Reply-To: <20080105013307.GB5064@topoi.pooq.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> <20080105013307.GB5064@topoi.pooq.com> Message-ID: On Fri, 4 Jan 2008 hendrik at topoi.pooq.com wrote: > gravityboy (http://gravityboy.livejournal.com/39755.html) has a few > things to say about people who compare svn with cvs: essentially, he > says cvs is so obsolete no one should even be comparing things with it > any more. Saying something is better than CVS is like saying that > a new model of automatic washing machines work better than rocks by the > side of the river. When I was moving from CVS to Darcs, a popular distributed versioning software in the Haskell world, one of my colleagues gave a talk about RCS. I wondered why he still uses and promotes RCS, when even CVS was too restricted for me. However after the talk many of my colleagues seconded his attitude, because CVS was already too complicated for them. To be honest, I still use CVS for small projects, when other machines are invoked, where I can't install Darcs. CVS has the charme, that you have the versioning data in a readable form. You could even repair small damages manually, if it is necessary. From wagner at elegosoft.com Sat Jan 5 13:49:52 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 05 Jan 2008 13:49:52 +0100 Subject: [M3devel] NT386GNU? 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> Message-ID: <20080105134952.6kvyefcy8c0gswkg@mail.elegosoft.com> Quoting Jay : > I assume NT386GNU remains very interesting to folks. Right? > Anyone know what's the deal with it? > Little work? Lots of work? > It'd net LONGINT at least. > I realize you'd need sh/awk/sed/gmake/etc., and ld. > You'd start by installing mingwin or cygwin. > And they (or one) would likely be required for all users, at least > for ld and some libs.I assume cygwin/mingwin have long since > merged to mainline. > I'll try to look into it..... CM3 never had a working NT386GNU target, though PM3 had. It would be great, as this is a POSIX system running on Windows (based on Cygwin32). Some years ago, when I still had a working NT system, I could never get cm3cg backends based on anything above gcc 2.95 to work on Cygwin. They always produced segmentation violations. But I haven't tried for many years now, so things may have changed. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Jan 5 14:32:35 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 05 Jan 2008 14:32:35 +0100 Subject: [M3devel] M3 concerns In-Reply-To: <20080105011719.GA5064@topoi.pooq.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> Message-ID: <20080105143235.ujed2tl3ksogws8k@mail.elegosoft.com> Discussions seem to loose their focus quiet easy on this list :-/ I'd strongly prefer if we could keep the discussion of alternative version control systems out of this. It won't help us, and you can trust this opinion as I really know many version control systems (SCCS, RCS, CVS, Subversion, ClearCase, PVCS Dimensions, Perforce, AccuRev, OpenCM, Vesta,...). I can assure you that CVS is quite adequate for the simple purposes and requirements we have. Changing will make things different, but not better, and cost a lot of efforts we should rather invest into other topics. I'd like to get back to the original topic. How do we need to improve the CM3 development process to ensure and increase the overall quality of the CM3 code base? Could everybody interested in this discussion please just comment on the following items to state his opinion: 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). Technical details should be discussed in a different thread. o Do we need / want to restrict the commit access for the CM3 code repositories? If so, only for certain areas, or for everything? This would be a distinction based on packages. Should we allow or prefer committing new code to branches and merge the resulting change sets based on reviews? (I could also contribute automatic support for creating change sets on branches, as this is part of the DCVS functionality elego developed some time ago). This would be a distinction based on code lines. Yesterday I had the impression that some members of this list would prefer some access restriction, but I'm not really sure. o I'm not sure if and how we should include the Windows target problems here. They were part of the original mail, but seem to belong to another category to me, at least have different causes. Suggestions what exactly to discuss are welcome. o To reach a conclusion on these topics, I suggest that we simply count the majority of opinions of list members that care to participate in this discussion. I'll try to summarize again after everybody has had time for consideration and has spoken up (or remained silent). I'd suggest to continue the discussion for the following week. Please try to keep comments short :-) Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Jan 5 18:06:01 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 05 Jan 2008 18:06:01 +0100 Subject: [M3devel] M3 concerns / Windows problems In-Reply-To: <477EA137.1E75.00D7.1@scires.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> <477EA137.1E75.00D7.1@scires.com> Message-ID: <20080105180601.unyynodmqswo44cs@mail.elegosoft.com> Quoting Randy Coleburn : > I'll try to find time again this weekend to do a build of cm3 on > Windows XP again. That would be great. > 3. Get Jay's d5.5.0 min Win32 and use it to build the current sources > from CVS. I'd choose this one. > I know that there are some scripts that have been built to help in > building things. One thing that would be helpful I think is to have a > text file that lists the correct build sequence order for all > packages in the repository. I know that some packages may not build on > every platform, but if we keep this text file up-to-date, it would help > folks as they work on scripts, etc. The file that lists all packages in order is scripts/def-std-pkgs.sh, though some may be missing from it. It's in Bourne shell format though. A compiler bootstrap may need another more complex order, where some packages are compiled twice at least though. The upgrade process should be automated in scripts/upgrade.sh (for most scenarios). This is due to subtle dependencies between the compiler and the runtime libraries. > Also, I seem to recall that in the past that for some of the core > packages, you had to build these twice in the process of getting > everything up and running. Again, these facts need to be made very > obvious so folks don't go down a wrong path. As explained above... > Once I get started on a path (1..4 above), I also need to know which of > the current scripts to use in building on Windows XP to get the best > results. You should be able to use all, though for the shell scripts you need a POSIX environment (like Cygwin), for the Python scripts you obviously need a Python installation (and they are quiet new, I don't know about their status); easiest will probably be Jay's CMD scripts for Windows. So I think upgrade,cmd would be a good start, followed probably by do-cm3-std.cmd. > I love the language and have been a zealous proponent of it for a long > time, but we've got to make it easier for folks to get started with > Modula-3. I will carefully document the steps I take in getting the > system built on Windows so we can make this available to everyone. I second this. > The last time I was able to get the sources and build on Windows was > v5.26. That version didn't work correctly with some of my programs and > I reported the problems to Olaf et al. The last time I checked out the > sources and tried to build 5.40, I wound up with compiler errors. I > recall some of these were related to LONGINT and some were related to > the garbage collector. So yes, there was a situation where I checked > out sources that represented a "broken" version in that it would not > build. I think that the head of the tree is quiet often broken wrt. a simple compilation of all packages, and sometimes even broken wrt. to the standard compiler upgrade procedure. This is really difficult to foresee for many commits, if they concern the runtime and/or compiler extensions. It's the main reason why I think we need automated regression tests on as many platforms as possible. > The package status page at > http://modula3.elegosoft.com/cm3/package-status.html is headed up by > the title CM3 v5.1. Is this page up-to-date? It would be helpful to > know where we stand wrt each package on each supported platform relative > to the current source tree. Again, I think an automated scoreboard > could make this possible. No, the package status hasn't been updated for a long time. There are lots of things that would need updating. Volunteers are welcome. Once we've got automated tests, this page could be generated, too. > Sorry to ramble on so much in this post. My main interest is in > getting the current sources built and running on Windows XP. As soon as > I am successful, I will run tests using my code base. I have a number > of programs that were built using cm3 v4.1 that are still in use. These > use a lot of features, including pickles, netobj, trestle, etc. So, my > tests should help uncover Broken #2 problems on Windows. IIRC, the main problems we at Elego had with Windows years ago were mostly GUI-related; the base stuff was working well. Unfortunately, there was noone with Windows GUI programming experience at that time :-( > Finally, once I get a working cm3 system on Windows, I'll provide the > new cm3-IDE (aka Reactor) package. This will be great and long-awaited indeed. I hope you succeed, Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From hendrik at topoi.pooq.com Sat Jan 5 19:54:30 2008 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Sat, 5 Jan 2008 13:54:30 -0500 Subject: [M3devel] 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> <20080105013307.GB5064@topoi.pooq.com> Message-ID: <20080105185430.GA6402@topoi.pooq.com> On Sat, Jan 05, 2008 at 09:44:40AM +0100, Henning Thielemann wrote: > > On Fri, 4 Jan 2008 hendrik at topoi.pooq.com wrote: > > > gravityboy (http://gravityboy.livejournal.com/39755.html) has a few > > things to say about people who compare svn with cvs: essentially, he > > says cvs is so obsolete no one should even be comparing things with it > > any more. Saying something is better than CVS is like saying that > > a new model of automatic washing machines work better than rocks by the > > side of the river. > > When I was moving from CVS to Darcs, a popular distributed versioning > software in the Haskell world, one of my colleagues gave a talk about RCS. > I wondered why he still uses and promotes RCS, when even CVS was too > restricted for me. However after the talk many of my colleagues seconded > his attitude, because CVS was already too complicated for them. > To be honest, I still use CVS for small projects, when other machines are > invoked, where I can't install Darcs. CVS has the charme, that you have > the versioning data in a readable form. You could even repair small > damages manually, if it is necessary. What I like about monotone is its absolute paranoia about losing data. When it is syncing different "copies" of the repository, apparently much of the time is spent making sure that the ancient history hasn't been corrupted, and that the data being transferred from one to the other hasn't been corrupted either. And having multiple repositories really does make it hard to lose data. The original CVS, I'm told, was a set of scripts operating on top of RCS. I don't know what it is now. -- hendrik From dabenavidesd at yahoo.es Sat Jan 5 20:06:41 2008 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Sat, 5 Jan 2008 20:06:41 +0100 (CET) Subject: [M3devel] cvsup fix latest cm3 (Scheduler.DisableSwitching, EnableSwitching) Message-ID: <835827.15730.qm@web27109.mail.ukl.yahoo.com> H all: I get some error compiling cvsup (sublib) because of the change on the Scheduler interface of Pthread, It's not hard to fix (importing Scheduler instead of SchedulerPosix). This for your knowledge, with this fixes it compiles and runs well. "../src/Ugzip.m3", line 63: unknown qualification '.' (DisableSwitching) "../src/Ugzip.m3", line 67: unknown qualification '.' (EnableSwitching) "../src/Ugzip.m3", line 74: unknown qualification '.' (DisableSwitching) "../src/Ugzip.m3", line 78: unknown qualification '.' (EnableSwitching) 4 errors encountered new source -> compiling Umd5.i3 new source -> compiling StatusFile.m3 new source -> compiling CVTree.i3 new source -> compiling CVTree.m3 "../src/CVTree.m3", line 315: unknown qualification '.' (DisableSwitching) "../src/CVTree.m3", line 319: unknown qualification '.' (EnableSwitching) "../src/CVTree.m3", line 325: unknown qualification '.' (DisableSwitching) "../src/CVTree.m3", line 329: unknown qualification '.' (EnableSwitching) "../src/CVTree.m3", line 335: unknown qualification '.' (DisableSwitching) "../src/CVTree.m3", line 339: unknown qualification '.' (EnableSwitching) 6 errors encountered --------------------------------- Web Revelaci?n Yahoo! 2007: Premio Favorita del P?blico - ?Vota tu preferida! -------------- next part -------------- An HTML attachment was scrubbed... URL: From hendrik at topoi.pooq.com Sat Jan 5 20:12:43 2008 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Sat, 5 Jan 2008 14:12:43 -0500 Subject: [M3devel] M3 concerns In-Reply-To: <20080105143235.ujed2tl3ksogws8k@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> Message-ID: <20080105191243.GB6402@topoi.pooq.com> On Sat, Jan 05, 2008 at 02:32:35PM +0100, Olaf Wagner wrote: > Discussions seem to loose their focus quiet easy on this list :-/ > > I'd strongly prefer if we could keep the discussion of alternative > version control systems out of this. It won't help us, and you can > trust this opinion as I really know many version control systems > (SCCS, RCS, CVS, Subversion, ClearCase, PVCS Dimensions, Perforce, > AccuRev, OpenCM, Vesta,...). I can assure you that CVS is quite > adequate for the simple purposes and requirements we have. Changing > will make things different, but not better, and cost a lot of efforts > we should rather invest into other topics. I quite agree. But if you have this experience, it would be useful to see a rundown of the advantages and disadvantages of each. I've seen a table of features against version control systems, but it doesn't give any feel for what it's like to use them. Such an essay would be useful for those involved in other projects. It probably won't help Modula 3 itself. Or might you know of such an essay elsewhere? -- hendrik > > I'd like to get back to the original topic. How do we need to improve > the CM3 development process to ensure and increase the overall quality > of the CM3 code base? Could everybody interested in this discussion > please just comment on the following items to state his opinion: > > 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). > > Technical details should be discussed in a different thread. > > o Do we need / want to restrict the commit access for the CM3 > code repositories? At the very least, you should keep spammers out. > > If so, only for certain areas, or for everything? This would > be a distinction based on packages. > > Should we allow or prefer committing new code to branches and > merge the resulting change sets based on reviews? (I could also > contribute automatic support for creating change sets on branches, > as this is part of the DCVS functionality elego developed some time > ago). This would be a distinction based on code lines. What's the 'D' of 'DVCS'? > Yesterday I had the impression that some members of this list > would prefer some access restriction, but I'm not really sure. The real questions are whether corrupt code is checked in often enough to cause trouble to other developers, whether check-in conflicts happen enough to be troublesome, and whether the red tape of lots of branches would be more trouble than it is worth. I don't know the answer to this. For preparing regular stable releases, it is probably worthwhile to freeze development on a release branch, but to keep fixing bugs on both the development and the release branches. As for reviews of changes, that should happen whether there's an access restriction or not. It may be the most important role of those who are knowledgeable with the code base. And they should probably happen before debugging. -- hendrik From wagner at elegosoft.com Sat Jan 5 21:00:05 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 05 Jan 2008 21:00:05 +0100 Subject: [M3devel] more m3tests failures Message-ID: <20080105210005.7iacdx5nkks84osk@mail.elegosoft.com> I've looked into some more failures of m3tests, which I'd like to present to the whole list: (All tests run on FreeBSD 6.3) p035 is a scoping problem which was Ok with /usr/local/cm3/bin/cm3cg-5.4.0 but /usr/local/cm3/bin/cm3cg-d5.5.1 fails, so it must be caused by recent gcc changes. The check that fails is PROCEDURE foo (p: P; same: BOOLEAN) = BEGIN checkB (bar = p, same); checkB (bar # p, NOT same); END foo; PROCEDURE bar (<*UNUSED*> t: Text.T) = BEGIN END bar; BEGIN msg ("group M"); foo (bar, TRUE); msg ("group N"); foo (dummy, FALSE); END; p040 fails due to differences in floating point precision; the numbers on FreeBSD seem to have a higher precision. +++ ../src/p0/p040/stdout.pgm 2003-03-08 11:14:03.000000000 +0100 @@ -964,85 +964,85 @@ ToLongFloat => 0.1 / 3 -0.001234567890123456 +0.0012345678901235 - FromLongFloat [Flo] => 0.001234567890123 - ToLongFloat => 0.001234567890123 / 17 - FromLongFloat [AltFlo] => 0.001234567890123 - ToLongFloat => 0.001234567890123 / 17 - FromLongFloat [Sci] => 1.234567890123456D-3 - ToLongFloat => 0.001234567890123456 / 20 - FromLongFloat [AltSci] => 1.234567890123456D-3 - ToLongFloat => 0.001234567890123456 / 20 - FromLongFloat [Mix] => 0.001234567890123 - ToLongFloat => 0.001234567890123 / 17 + FromLongFloat [Flo] => 0.001234567890124 + ToLongFloat => 0.001234567890124 / 17 + FromLongFloat [AltFlo] => 0.001234567890124 + ToLongFloat => 0.001234567890124 / 17 + FromLongFloat [Sci] => 1.234567890123500D-3 + ToLongFloat => 0.0012345678901235 / 20 + FromLongFloat [AltSci] => 1.2345678901235D-3 + ToLongFloat => 0.0012345678901235 / 18 + FromLongFloat [Mix] => 0.001234567890124 + ToLongFloat => 0.001234567890124 / 17 I'm not sure here what to do, as well as for p070, which tests fingerprints for procedures, and is not implemented in CM3. Do we need that? From RTProcedure.m3: PROCEDURE ToFingerprint (<*UNUSED*> p: Proc): Fingerprint.T = BEGIN <*ASSERT FALSE, "RTProcedure.ToFingerprint is not supported" *> RETURN Fingerprint.Zero; <*NOWARN*> END ToFingerprint; PROCEDURE FromFingerprint (<*UNUSED*> READONLY fp: Fingerprint.T): Proc = BEGIN <*ASSERT FALSE, "RTProcedure.FromFingerprint is not supported" *> RETURN NIL; <*NOWARN*> END FromFingerprint; Or should we deactivate that test? p096 fails with @@ -1,3 +1,2 @@ "../src/Main.m3", line 27: default is not a procedure constant (m) 1 error encountered -Fatal Error: package build failed --- p0/p096/stderr.build 2008-01-05 18:27:24.000000000 +0100 +++ ../src/p0/p096/stderr.build 2003-03-08 11:14:05.000000000 +0100 because of this code: MODULE Main; CONST K = T.m; L = Q; TYPE TProc = PROCEDURE(s: T); CONST A = ARRAY OF TProc{Q}; TYPE T = OBJECT METHODS m() := L; END; ST1 = T OBJECT OVERRIDES m := K END; (*** ILLEGAL *** ST2 = T OBJECT OVERRIDES m := TProc END; ***) ST3 = T OBJECT OVERRIDES m := A[0]; END; PROCEDURE Q(s: T) = BEGIN EVAL s END Q; VAR t: T; st1: ST1; st3: ST3; BEGIN EVAL t; EVAL st1; EVAL st3; END Main. I think I can somehow understand the compiler here. Did this ever work? p116 first fails because FlotMode procedures are not implemented by default: +++ ../src/p1/p116/stderr.pgm 2003-03-08 11:13:53.000000000 +0100 @@ -1,11 +1,3 @@ - - -*** -*** runtime error: -*** <*ASSERT*> failed: FloatMode.SetRounding not implemented -*** file "../src/float/IEEE-default/FloatMode.m3", line 14 -*** - ---------------------------- REAL --- 1.0/0.0 # 1.0/(-0.0) test OK 1.0/0.0 = 1.0/(- (-0.0)) test OK I think this should be tested conditionally depending on platform. But then more checks fail: @@ -25,14 +17,14 @@ Class (MaxFinite*ten) test OK Finite (MaxFinite*ten) test OK IsNaN (MaxFinite*ten) test OK -** Class (zero/zero) test not OK: FALSE should be TRUE + Class (zero/zero) test OK Finite (zero/zero) test OK IsNaN (zero/zero) test OK Sign (zero) test OK Sign (minusZero) test OK - Unordered (zero, NaN) test OK +** Unordered (zero, NaN) test not OK: FALSE should be TRUE Unordered (zero, zero) test OK - Unordered (NaN, NaN) test OK +** Unordered (NaN, NaN) test not OK: FALSE should be TRUE Differs (zero, NaN) test OK which refers to the test lines BCheck("Class (zero/zero)", RealFloat.Class(x) = IEEEClass.QuietNaN, TRUE); BCheck("Unordered (zero, NaN)", RealFloat.Unordered(zero, NaN), TRUE); BCheck("Unordered (NaN, NaN)", RealFloat.Unordered(NaN, NaN), TRUE); Especially the last one suprises me, but I'm no specialist in arithmetics. Is this to be expected? Should we tolerate or can we fix it? So far for now, I need to prepare dinner now, Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From dabenavidesd at yahoo.es Sun Jan 6 02:26:48 2008 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Sun, 6 Jan 2008 02:26:48 +0100 (CET) Subject: [M3devel] Problem with an exmaple of Modula-3 tutorial Message-ID: <316462.45428.qm@web27102.mail.ukl.yahoo.com> Hi all: I was showing an example to a friend of the Modula-3 tutorial, but we ran into an error with the first one: http://modula3.elegosoft.com/cm3/doc/tutorial/m3/m3_2.html#SEC2 MODULE Main ; IMPORT IO; (* So we can print things *) VAR name: TEXT; (* a string variable called "name" *) BEGIN IO.Put("Enter your name: "); IO.GetLine(name); IO.Put("Your name is: " & name & "\n"); END Main. "../src/Main.m3", line 9: incompatible types (rd) Well fortunately we have this great documentation of the interfaces, so a correct (not formally proved) code is: MODULE Main; IMPORT IO; (* So we can print things *) VAR name: TEXT; (* a string variable called "name" *) BEGIN IO.Put("Enter your name: "); name:=IO.GetLine(); IO.Put("Your name is: " & name & "\n"); END Main. I have a cvs account, I cancheck it also for prepare my knowledge and merge some modifications of m3-lectern packages to be able to compile them. Thanks for the great work you have done to keep this wonderful enviroment going on in so many platforms. Happy new years modula-3 developers !! Daniel Benavides --------------------------------- Web Revelaci?n Yahoo! 2007: Premio Favorita del P?blico - ?Vota tu preferida! -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.caltech.edu Sun Jan 6 02:59:23 2008 From: mika at async.caltech.edu (Mika Nystrom) Date: Sat, 05 Jan 2008 17:59:23 -0800 Subject: [M3devel] M3 concerns In-Reply-To: Your message of "Fri, 04 Jan 2008 21:12:24 EST." <477EA137.1E75.00D7.1@scires.com> Message-ID: <200801060159.m061xNjc047849@camembert.async.caltech.edu> "Randy Coleburn" writes: > > >> Date: Sat, 5 Jan 2008 01:13:35 +0100 >> From: wagner at elegosoft.com >> To: hosking at cs.purdue.edu; m3devel at elegosoft.com >> CC: m3-support at elegosoft.com >> Subject: Re: [M3devel] M3 concerns >> >> Quoting Tony Hosking : >> >> > My comments embedded: >> > >> > On Jan 4, 2008, at 4:10 PM, Olaf Wagner wrote: >> >> >> Ah well, Windows is a somewhat special topic. I even haven't a >system >> >> here for tests, and most of the other contributors don't use it >either. >> >> I was of the opinion that Jay Krell had fixes or workarounds for >most >> >> current problems (except for the missing LONGINT support), but I >haven't >> >> tried his distribution archives yet. It would indeed be very >helpful >> >> if we could setup regression tests on Windows, too. >> > >> > LONGINT = INTEGER on Windows, which is fine as far as it goes >> > (everything builds appropriately), but not particularly useful. >> >> I know that it should run this way, but pickles for example wouldn't >> be exchangeable then, would they? Has anybody tested pickle support >> for LONGINT yet? Well, I think this depends on exactly what you (not sure who said this originally) mean by "LONGINT = INTEGER". What you say is true if indeed LONGINT and INTEGER are the same type. If, however, they are different types (as they should be), which just happen to be of the same size (on Windows/i386), there should be no problem. The Pickle library (at least ver. 2) transparently performs endianness reordering and word-size adjustments. (Pickles *should* be exchangeable between 32- and 64-bit architectures, for example, and between big-endian sparcs and little-endian i386s and alphas---this latter property I use to exchange pickles between PPC_DARWIN and FreeBSD4.) Of course, have all the proper hooks been called to enable this? I don't know, I just know it's definitely possible to set things up so that Pickles are exchangeable even under these conditions. Mika From hosking at cs.purdue.edu Sun Jan 6 04:41:33 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 5 Jan 2008 22:41:33 -0500 Subject: [M3devel] M3 concerns In-Reply-To: <200801060159.m061xNjc047849@camembert.async.caltech.edu> References: <200801060159.m061xNjc047849@camembert.async.caltech.edu> Message-ID: <8C8CF668-F1C6-475B-B67A-EA3DCDC7509C@cs.purdue.edu> On Jan 5, 2008, at 8:59 PM, Mika Nystrom wrote: > "Randy Coleburn" writes: >> >> >>>> >>>> LONGINT = INTEGER on Windows, which is fine as far as it goes >>>> (everything builds appropriately), but not particularly useful. >>> >>> I know that it should run this way, but pickles for example wouldn't >>> be exchangeable then, would they? Has anybody tested pickle support >>> for LONGINT yet? > Sorry, yes, I was incorrect in saying LONGINT=INTEGER on WIN32. In fact, they are distinct types that just happen to have the same representation, so the backend can handle them. > Well, I think this depends on exactly what you (not sure who said > this originally) mean by "LONGINT = INTEGER". What you say is true > if indeed LONGINT and INTEGER are the same type. If, however, they > are different types (as they should be), which just happen to be > of the same size (on Windows/i386), there should be no problem. > The Pickle library (at least ver. 2) transparently performs endianness > reordering and word-size adjustments. (Pickles *should* be > exchangeable between 32- and 64-bit architectures, for example, and > between big-endian sparcs and little-endian i386s and alphas---this > latter property I use to exchange pickles between PPC_DARWIN and > FreeBSD4.) Of course, have all the proper hooks been called to > enable this? I don't know, I just know it's definitely possible > to set things up so that Pickles are exchangeable even under these > conditions. > > Mika From wagner at elegosoft.com Sun Jan 6 13:01:46 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Sun, 06 Jan 2008 13:01:46 +0100 Subject: [M3devel] Problem with an exmaple of Modula-3 tutorial In-Reply-To: <316462.45428.qm@web27102.mail.ukl.yahoo.com> References: <316462.45428.qm@web27102.mail.ukl.yahoo.com> Message-ID: <20080106130146.46qwab3808wkogwc@mail.elegosoft.com> Quoting "Daniel Alejandro Benavides D." : > Hi all: > I was showing an example to a friend of the Modula-3 tutorial, but > we ran into an error with the first one: > > http://modula3.elegosoft.com/cm3/doc/tutorial/m3/m3_2.html#SEC2 > > > MODULE Main ; > > IMPORT IO; (* So we can print things *) > > VAR name: TEXT; (* a string variable called "name" *) > > BEGIN > IO.Put("Enter your name: "); > IO.GetLine(name); > IO.Put("Your name is: " & name & "\n"); > END Main. > > "../src/Main.m3", line 9: incompatible types (rd) > > Well fortunately we have this great documentation of the interfaces, > so a correct (not formally proved) code is: > > MODULE Main; > > IMPORT IO; (* So we can print things *) > > VAR name: TEXT; (* a string variable called "name" *) > > BEGIN > IO.Put("Enter your name: "); > name:=IO.GetLine(); > IO.Put("Your name is: " & name & "\n"); > END Main. > > I have a cvs account, I cancheck it also for prepare my knowledge > and merge some modifications of m3-lectern packages to be able to > compile them. Please check in any corrections you'd care to do and let m3-support know about when to ship updates to the web server. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Jan 6 20:39:03 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Sun, 06 Jan 2008 20:39:03 +0100 Subject: [M3devel] M3 concerns / automated regression tests In-Reply-To: <477B7629.1E75.00D7.1@scires.com> References: <477B7629.1E75.00D7.1@scires.com> Message-ID: <20080106203903.tav3gl9c00ow8ggc@mail.elegosoft.com> Quoting Randy Coleburn : > Question: As various people make contributions and changes, is > there any group of folks who is verifying that the changes don't > break existing code or core principles? Another idea would be to > have a series of test batteries that have to be passed before > changes can be accepted. I know of a number of projects where many > people contribute, but the contributions have to be vetted by > passing some tests. > > Without these types of controls, I fear that good forward progress > will inevitably be hampered or compromised by changes made by > someone who hasn't completely thought out and tested the > ramifications of those changes. As announced in other mails, I'd like to get into some details of the regression test standardization I suggest. As you may have noticed, several scripts have been committed to cm3/scripts/regression/. There are some scripts for the integration of tests into the elego tinderbox framework, which are still work in progress. Kaspar Schleiser is working on this; it may take some days before everything works as expected. The main functions for test standardization are contained in the file defs.sh. This is a shell script which can be sourced and used in different contexts. It contains functions for CVS checkout, binary installation, and the actual tests. In my opinion, the most important thing that should be ensured is that the current sources can be compiled with the latest official release of the system. This can get tricky in case of incompatible changes in the compiler runtime, frontend, or configuration (cm3.cfg). So the main part of test_build_core_rel() is an upgrade performed by scripts/upgrade.sh based on the last release. In order to use this, it must of course be installed. This can be done with install_bin_dist(). The test framework uses three installations of CM3, located in INSTBASE, which defaults to ${HOME}/work/cm3-inst. There are rel-${LASTREL}, e.g. rel-5.4.0 current last-ok rel-x.x.x should contain at least a minimal installation of the last official release. It may have to be installed manually, as the installer was interactive until recently. (This has been changed in d5.5.1.) current always contains the CM3 installation which is used for actual shipping during test builds and is usually based on the current sources. last-ok is always updated with the last successfully built version. The workspaces which are used for checkout and compilation contain date stamps in their name, eg. ~/work/cm3-ws-2008-01-04-20-05-06/. They can be set with the variables DS and WS: DS=${DS:-`date -u +'%Y-%m-%d-%H-%M-%S' | tr -d '\\n'`} WS=${WS:-${HOME}/work/cm3-ws-${DS}} Apart from building with the latest release, there are currently the following tests automated: o building the core system with the last-ok version. This will work until anybody checks in an incompatible change for the runtime, frontend, or configuration. It may be used as an indicator that a full upgrade procedure is necessary from this point in time. As this is expected to fail eventually, it should not be considered fatal. This is performed by test_build_core_lastok(). o building the complete set of standard packages with the last-ok / current version. This excludes the compiler itself, and will give an indication if the second step of the bootstrap after initial installation works (installing all standard packages with the minimal system). This is done by test_build_std_lastok(). o building of a minimal binary installation archive. This will ensure that we can actually build a new release for the tested platform. It is done by test_make_bin_dist(). The produced archives can be distributed as current snapshots. o testall() and main() simply combine all tests into one run which might be done nightly. This is currently not compatible with the intended tinderbox integration though. Needed extensions: o The actual compiler regression tests (m3tests) need to be included. I've imported them 2003 from the PM3 distribution, but they are not in a good shape. I've started to work on them, but will need help of others; you will have noticed my messages. o There are many more package-related regression tests, which need to be added, too. I don't know about the status of most though, so this will be a tedious task, too. We could distinguish between tests for core packages work/cm3/m3-libs/binIO/test work/cm3/m3-libs/bitvector/test work/cm3/m3-libs/libm3/tests work/cm3/m3-libs/libm3/tests/rw/autotest work/cm3/m3-libs/m3core/tests work/cm3/m3-libs/patternmatching/tests work/cm3/m3-libs/slisp/tests work/cm3/m3-libs/sortedtableextras/tests and others work/cm3/caltech-parser/drawcontext/test work/cm3/caltech-parser/m3tmplhack/test work/cm3/caltech-parser/parserlib/parserlib/test work/cm3/caltech-parser/parserlib/parserlib/test_stdin work/cm3/m3-comm/events/tests work/cm3/m3-comm/events/tests/test work/cm3/m3-comm/netobj/tests work/cm3/m3-comm/rdwr/test work/cm3/m3-comm/serial/test work/cm3/m3-comm/sharedobj/tests work/cm3/m3-comm/sharedobj/tests/netobjtest work/cm3/m3-comm/sharedobjgen/test work/cm3/m3-comm/udp/test work/cm3/m3-db/db/test work/cm3/m3-db/odbc/test work/cm3/m3-db/pgodbc/test work/cm3/m3-db/postgres95/test work/cm3/m3-db/stable/test work/cm3/m3-libs/dps/test work/cm3/m3-libs/synthesizer/test work/cm3/m3-libs/tcl/test work/cm3/m3-libs/deepcopy/test work/cm3/m3-libs/plplot/test work/cm3/m3-libs/arithmetic/test work/cm3/m3-libs/fftw/test work/cm3/m3-libs/lapack/test work/cm3/m3-libs/unittest work/cm3/m3-libs/unittest-numeric work/cm3/m3-libs/wellfett/test work/cm3/m3-sys/m3modinittest work/cm3/m3-ui/juno-2/juno-app/juno-src/test work/cm3/m3-ui/juno-2/juno-app/juno-src/testRedundant work/cm3/m3-ui/juno-2/juno-compiler/tests work/cm3/m3-ui/ui/test work/cm3/m3-ui/motif/tests work/cm3/m3-ui/ui-tests work/cm3/m3-ui/vbtkit/src/vtext/testing I'll try these after m3tests are working. Of course, contributions of others are welcome for all these. As a start, it may be a good idea if those interested in running regular tests could try the core test framework. What needs to be done is o ( . ./scripts/regression/defs.sh; install_bin_dist ) once, potentially manuallly, or with overwriting the cminstall program to use something current: ( export CMINSTALL=...; . ./scripts/regression/defs.sh; install_bin_dist ) This expects the latest binary installation archive in your home directory. o Now tests should be able to run on a regular basis like this: ( . ./scripts/regression/defs.sh; main ) This will create a new workspace, checkout the current sources, and perform all the tests described above. I've tried this now on a FreeBSD 6.2 and Debian Linux system. It may well be that more adaptions and extensions to the scripts are necessary, but we have to try. If the above works for others, too, we can turn to the tinderbox integration to gather all the results in a database and display them. You may have a look at the results at http://tinderbox.elegosoft.com/ http://tinderbox.elegosoft.com/cm3/status.html Keep in mind that this work is not finished yet. Please let me know of any problems, improvements, or just comments. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From hosking at cs.purdue.edu Sun Jan 6 22:29:58 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 6 Jan 2008 16:29:58 -0500 Subject: [M3devel] more m3tests failures In-Reply-To: <20080105210005.7iacdx5nkks84osk@mail.elegosoft.com> References: <20080105210005.7iacdx5nkks84osk@mail.elegosoft.com> Message-ID: <5BED31CE-54AB-44CB-905A-E19ED6B0435A@cs.purdue.edu> On Jan 5, 2008, at 3:00 PM, Olaf Wagner wrote: > I've looked into some more failures of m3tests, which I'd like to > present to the whole list: (All tests run on FreeBSD 6.3) > > p035 is a scoping problem which was Ok with > > /usr/local/cm3/bin/cm3cg-5.4.0 > > but > > /usr/local/cm3/bin/cm3cg-d5.5.1 > > fails, so it must be caused by recent gcc changes. The check that > fails is > > PROCEDURE foo (p: P; same: BOOLEAN) = > BEGIN > checkB (bar = p, same); checkB (bar # p, NOT same); > END foo; > PROCEDURE bar (<*UNUSED*> t: Text.T) = > BEGIN > END bar; > BEGIN > msg ("group M"); foo (bar, TRUE); > msg ("group N"); foo (dummy, FALSE); > END; Hmm. Something is broken with load_static_link. I will look into it. > > p040 fails due to differences in floating point precision; the numbers > on FreeBSD seem to have a higher precision. > > +++ ../src/p0/p040/stdout.pgm 2003-03-08 11:14:03.000000000 +0100 > @@ -964,85 +964,85 @@ > ToLongFloat => 0.1 / 3 > > > -0.001234567890123456 > +0.0012345678901235 > > - FromLongFloat [Flo] => 0.001234567890123 > - ToLongFloat => 0.001234567890123 / 17 > - FromLongFloat [AltFlo] => 0.001234567890123 > - ToLongFloat => 0.001234567890123 / 17 > - FromLongFloat [Sci] => 1.234567890123456D-3 > - ToLongFloat => 0.001234567890123456 / 20 > - FromLongFloat [AltSci] => 1.234567890123456D-3 > - ToLongFloat => 0.001234567890123456 / 20 > - FromLongFloat [Mix] => 0.001234567890123 > - ToLongFloat => 0.001234567890123 / 17 > + FromLongFloat [Flo] => 0.001234567890124 > + ToLongFloat => 0.001234567890124 / 17 > + FromLongFloat [AltFlo] => 0.001234567890124 > + ToLongFloat => 0.001234567890124 / 17 > + FromLongFloat [Sci] => 1.234567890123500D-3 > + ToLongFloat => 0.0012345678901235 / 20 > + FromLongFloat [AltSci] => 1.2345678901235D-3 > + ToLongFloat => 0.0012345678901235 / 18 > + FromLongFloat [Mix] => 0.001234567890124 > + ToLongFloat => 0.001234567890124 / 17 > > I'm not sure here what to do, as well as for p070, which tests > fingerprints for procedures, and is not implemented in CM3. Do we > need that? From RTProcedure.m3: > > PROCEDURE ToFingerprint (<*UNUSED*> p: Proc): Fingerprint.T = > BEGIN > <*ASSERT FALSE, "RTProcedure.ToFingerprint is not supported" *> > RETURN Fingerprint.Zero; <*NOWARN*> > END ToFingerprint; > > PROCEDURE FromFingerprint (<*UNUSED*> READONLY fp: Fingerprint.T): > Proc = > BEGIN > <*ASSERT FALSE, "RTProcedure.FromFingerprint is not supported" *> > RETURN NIL; <*NOWARN*> > END FromFingerprint; > > Or should we deactivate that test? I suspect we should deactivate both of these for now. > > p096 fails with > > @@ -1,3 +1,2 @@ > "../src/Main.m3", line 27: default is not a procedure constant (m) > 1 error encountered > -Fatal Error: package build failed > --- p0/p096/stderr.build 2008-01-05 18:27:24.000000000 +0100 > +++ ../src/p0/p096/stderr.build 2003-03-08 11:14:05.000000000 +0100 > > because of this code: > > MODULE Main; > > CONST K = T.m; L = Q; > TYPE TProc = PROCEDURE(s: T); > CONST A = ARRAY OF TProc{Q}; > > TYPE T = OBJECT METHODS m() := L; END; > ST1 = T OBJECT OVERRIDES m := K END; > (*** ILLEGAL *** ST2 = T OBJECT OVERRIDES m := TProc END; ***) > ST3 = T OBJECT OVERRIDES m := A[0]; END; > > PROCEDURE Q(s: T) = BEGIN EVAL s END Q; > > VAR t: T; st1: ST1; st3: ST3; > BEGIN > EVAL t; EVAL st1; EVAL st3; > END Main. > > I think I can somehow understand the compiler here. Did this ever > work? Is "CONST K = T.m" not a procedure constant? In which case m := K should work! > > p116 first fails because FlotMode procedures are not implemented by > default: > > +++ ../src/p1/p116/stderr.pgm 2003-03-08 11:13:53.000000000 +0100 > @@ -1,11 +1,3 @@ > - > - > -*** > -*** runtime error: > -*** <*ASSERT*> failed: FloatMode.SetRounding not implemented > -*** file "../src/float/IEEE-default/FloatMode.m3", line 14 > -*** > - > ---------------------------- REAL --- > 1.0/0.0 # 1.0/(-0.0) test OK > 1.0/0.0 = 1.0/(- (-0.0)) test OK > > I think this should be tested conditionally depending on platform. Indeed. > But then more checks fail: > > @@ -25,14 +17,14 @@ > Class (MaxFinite*ten) test OK > Finite (MaxFinite*ten) test OK > IsNaN (MaxFinite*ten) test OK > -** Class (zero/zero) test not OK: FALSE should be TRUE > + Class (zero/zero) test OK > Finite (zero/zero) test OK > IsNaN (zero/zero) test OK > Sign (zero) test OK > Sign (minusZero) test OK > - Unordered (zero, NaN) test OK > +** Unordered (zero, NaN) test not OK: FALSE should be TRUE > Unordered (zero, zero) test OK > - Unordered (NaN, NaN) test OK > +** Unordered (NaN, NaN) test not OK: FALSE should be TRUE > Differs (zero, NaN) test OK > > which refers to the test lines > > BCheck("Class (zero/zero)", RealFloat.Class(x) = > IEEEClass.QuietNaN, TRUE); > BCheck("Unordered (zero, NaN)", RealFloat.Unordered(zero, NaN), > TRUE); > BCheck("Unordered (NaN, NaN)", RealFloat.Unordered(NaN, NaN), > TRUE); > > Especially the last one suprises me, but I'm no specialist in > arithmetics. > Is this to be expected? Should we tolerate or can we fix it? Not sure... > > So far for now, I need to prepare dinner now, > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, > Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 > 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: > Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > DE163214194 > From hosking at cs.purdue.edu Mon Jan 7 15:56:12 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 7 Jan 2008 09:56:12 -0500 Subject: [M3devel] more m3tests failures In-Reply-To: <20080105210005.7iacdx5nkks84osk@mail.elegosoft.com> References: <20080105210005.7iacdx5nkks84osk@mail.elegosoft.com> Message-ID: <145F79EF-1CFF-4393-9C81-7F15CD283674@cs.purdue.edu> On Jan 5, 2008, at 3:00 PM, Olaf Wagner wrote: > I've looked into some more failures of m3tests, which I'd like to > present to the whole list: (All tests run on FreeBSD 6.3) > > p035 is a scoping problem which was Ok with > > /usr/local/cm3/bin/cm3cg-5.4.0 > > but > > /usr/local/cm3/bin/cm3cg-d5.5.1 > > fails, so it must be caused by recent gcc changes. The check that > fails is > > PROCEDURE foo (p: P; same: BOOLEAN) = > BEGIN > checkB (bar = p, same); checkB (bar # p, NOT same); > END foo; > PROCEDURE bar (<*UNUSED*> t: Text.T) = > BEGIN > END bar; > BEGIN > msg ("group M"); foo (bar, TRUE); > msg ("group N"); foo (dummy, FALSE); > END; I think the issue is to do with the fact that we use gcc's automatic nested function support instead of m3cg's load_static_link and pop_static_link. I believe the fix is to make load_static_link load nil instead of an actual static chain value. > > p040 fails due to differences in floating point precision; the numbers > on FreeBSD seem to have a higher precision. > > +++ ../src/p0/p040/stdout.pgm 2003-03-08 11:14:03.000000000 +0100 > @@ -964,85 +964,85 @@ > ToLongFloat => 0.1 / 3 > > > -0.001234567890123456 > +0.0012345678901235 > > - FromLongFloat [Flo] => 0.001234567890123 > - ToLongFloat => 0.001234567890123 / 17 > - FromLongFloat [AltFlo] => 0.001234567890123 > - ToLongFloat => 0.001234567890123 / 17 > - FromLongFloat [Sci] => 1.234567890123456D-3 > - ToLongFloat => 0.001234567890123456 / 20 > - FromLongFloat [AltSci] => 1.234567890123456D-3 > - ToLongFloat => 0.001234567890123456 / 20 > - FromLongFloat [Mix] => 0.001234567890123 > - ToLongFloat => 0.001234567890123 / 17 > + FromLongFloat [Flo] => 0.001234567890124 > + ToLongFloat => 0.001234567890124 / 17 > + FromLongFloat [AltFlo] => 0.001234567890124 > + ToLongFloat => 0.001234567890124 / 17 > + FromLongFloat [Sci] => 1.234567890123500D-3 > + ToLongFloat => 0.0012345678901235 / 20 > + FromLongFloat [AltSci] => 1.2345678901235D-3 > + ToLongFloat => 0.0012345678901235 / 18 > + FromLongFloat [Mix] => 0.001234567890124 > + ToLongFloat => 0.001234567890124 / 17 > > I'm not sure here what to do, as well as for p070, which tests > fingerprints for procedures, and is not implemented in CM3. Do we > need that? From RTProcedure.m3: > > PROCEDURE ToFingerprint (<*UNUSED*> p: Proc): Fingerprint.T = > BEGIN > <*ASSERT FALSE, "RTProcedure.ToFingerprint is not supported" *> > RETURN Fingerprint.Zero; <*NOWARN*> > END ToFingerprint; > > PROCEDURE FromFingerprint (<*UNUSED*> READONLY fp: Fingerprint.T): > Proc = > BEGIN > <*ASSERT FALSE, "RTProcedure.FromFingerprint is not supported" *> > RETURN NIL; <*NOWARN*> > END FromFingerprint; > > Or should we deactivate that test? I suspect we should deactivate both of these for now. > > p096 fails with > > @@ -1,3 +1,2 @@ > "../src/Main.m3", line 27: default is not a procedure constant (m) > 1 error encountered > -Fatal Error: package build failed > --- p0/p096/stderr.build 2008-01-05 18:27:24.000000000 +0100 > +++ ../src/p0/p096/stderr.build 2003-03-08 11:14:05.000000000 +0100 > > because of this code: > > MODULE Main; > > CONST K = T.m; L = Q; > TYPE TProc = PROCEDURE(s: T); > CONST A = ARRAY OF TProc{Q}; > > TYPE T = OBJECT METHODS m() := L; END; > ST1 = T OBJECT OVERRIDES m := K END; > (*** ILLEGAL *** ST2 = T OBJECT OVERRIDES m := TProc END; ***) > ST3 = T OBJECT OVERRIDES m := A[0]; END; > > PROCEDURE Q(s: T) = BEGIN EVAL s END Q; > > VAR t: T; st1: ST1; st3: ST3; > BEGIN > EVAL t; EVAL st1; EVAL st3; > END Main. > > I think I can somehow understand the compiler here. Did this ever > work? Is "CONST K = T.m" not a procedure constant? In which case m := K should work! > > p116 first fails because FlotMode procedures are not implemented by > default: > > +++ ../src/p1/p116/stderr.pgm 2003-03-08 11:13:53.000000000 +0100 > @@ -1,11 +1,3 @@ > - > - > -*** > -*** runtime error: > -*** <*ASSERT*> failed: FloatMode.SetRounding not implemented > -*** file "../src/float/IEEE-default/FloatMode.m3", line 14 > -*** > - > ---------------------------- REAL --- > 1.0/0.0 # 1.0/(-0.0) test OK > 1.0/0.0 = 1.0/(- (-0.0)) test OK > > I think this should be tested conditionally depending on platform. Indeed. > But then more checks fail: > > @@ -25,14 +17,14 @@ > Class (MaxFinite*ten) test OK > Finite (MaxFinite*ten) test OK > IsNaN (MaxFinite*ten) test OK > -** Class (zero/zero) test not OK: FALSE should be TRUE > + Class (zero/zero) test OK > Finite (zero/zero) test OK > IsNaN (zero/zero) test OK > Sign (zero) test OK > Sign (minusZero) test OK > - Unordered (zero, NaN) test OK > +** Unordered (zero, NaN) test not OK: FALSE should be TRUE > Unordered (zero, zero) test OK > - Unordered (NaN, NaN) test OK > +** Unordered (NaN, NaN) test not OK: FALSE should be TRUE > Differs (zero, NaN) test OK > > which refers to the test lines > > BCheck("Class (zero/zero)", RealFloat.Class(x) = > IEEEClass.QuietNaN, TRUE); > BCheck("Unordered (zero, NaN)", RealFloat.Unordered(zero, NaN), > TRUE); > BCheck("Unordered (NaN, NaN)", RealFloat.Unordered(NaN, NaN), > TRUE); > > Especially the last one suprises me, but I'm no specialist in > arithmetics. > Is this to be expected? Should we tolerate or can we fix it? > > So far for now, I need to prepare dinner now, > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, > Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 > 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: > Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > DE163214194 > From darko at darko.org Mon Jan 7 19:12:35 2008 From: darko at darko.org (Darko) Date: Mon, 7 Jan 2008 10:12:35 -0800 Subject: [M3devel] CM3 on Leopard Message-ID: <6CD6F1AC-449E-421D-A26A-C50BA1DFC301@darko.org> Hi Tony, Are you using CM3 on Leopard, aka Mac OS X 10.5? It's stopped working since I upgraded, I get: cc -o parser -fPIC _m3main.o [ ... various libs, modules ... ] - lm3gcdefs -lm -multiply_defined suppress -bind_at_load -shared-libgcc /usr/bin/ld: /usr/lib/gcc/i686-apple-darwin8/4.0.1/../../../libm.dylib unknown flags (type) of section 6 (__TEXT,__dof_plockstat) in load command 0 /usr/bin/ld: can't locate file for: -lgcc_s.10.4 collect2: ld returned 1 exit status when trying to compile. Uname says: Darwin Lucifer.local 9.1.0 Darwin Kernel Version 9.1.0: Wed Oct 31 17:46:22 PDT 2007; root:xnu-1228.0.2~1/RELEASE_I386 i386 It would seem that i just needs to be nudged up to the right version, but I couldn't find anything in the cfg file. Any suggestions? Thanks, Darko. From hosking at cs.purdue.edu Mon Jan 7 20:08:08 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 7 Jan 2008 14:08:08 -0500 Subject: [M3devel] CM3 on Leopard In-Reply-To: <6CD6F1AC-449E-421D-A26A-C50BA1DFC301@darko.org> References: <6CD6F1AC-449E-421D-A26A-C50BA1DFC301@darko.org> Message-ID: On Jan 7, 2008, at 1:12 PM, Darko wrote: > Hi Tony, > > Are you using CM3 on Leopard, aka Mac OS X 10.5? No, I've deliberately *not* upgraded to Leopard until I am able to test CM3 on it. Generally, I avoid bleeding edge OS upgrades for precisely this reason. I don't know when I will have time to play with CM3 on Leopard. Right now, I am tracking down another issue related to the regression framework Olaf is putting together. > It's stopped working since I upgraded, I get: > > cc -o parser -fPIC _m3main.o [ ... various libs, modules ... ] - > lm3gcdefs -lm -multiply_defined suppress -bind_at_load -shared-libgcc At least this suggest your cm3 binary was able to run on Leopard, which is a good start. > > /usr/bin/ld: /usr/lib/gcc/i686-apple-darwin8/4.0.1/../../../ > libm.dylib unknown flags (type) of section 6 > (__TEXT,__dof_plockstat) in load command 0 > /usr/bin/ld: can't locate file for: -lgcc_s.10.4 > collect2: ld returned 1 exit status > > when trying to compile. Uname says: > > Darwin Lucifer.local 9.1.0 Darwin Kernel Version 9.1.0: Wed Oct 31 > 17:46:22 PDT 2007; root:xnu-1228.0.2~1/RELEASE_I386 i386 > > It would seem that i just needs to be nudged up to the right > version, but I couldn't find anything in the cfg file. Any > suggestions? I suspect that you need to rebuild the m3cg backend, but I have no idea how well it will play with Leopard. Also, I have heard there were changes to ucontexts and other thread state which may mean M3 exceptions break, but I have not verified yet. > > Thanks, > Darko. > From hosking at cs.purdue.edu Mon Jan 7 20:27:19 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 7 Jan 2008 14:27:19 -0500 Subject: [M3devel] more m3tests failures In-Reply-To: <20080105210005.7iacdx5nkks84osk@mail.elegosoft.com> References: <20080105210005.7iacdx5nkks84osk@mail.elegosoft.com> Message-ID: I just checked in the fix for p035, with changes to the gcc-based backend (tree-nested.c and parse.c). On Jan 5, 2008, at 3:00 PM, Olaf Wagner wrote: > I've looked into some more failures of m3tests, which I'd like to > present to the whole list: (All tests run on FreeBSD 6.3) > > p035 is a scoping problem which was Ok with > > /usr/local/cm3/bin/cm3cg-5.4.0 > > but > > /usr/local/cm3/bin/cm3cg-d5.5.1 > > fails, so it must be caused by recent gcc changes. The check that > fails is > > PROCEDURE foo (p: P; same: BOOLEAN) = > BEGIN > checkB (bar = p, same); checkB (bar # p, NOT same); > END foo; > PROCEDURE bar (<*UNUSED*> t: Text.T) = > BEGIN > END bar; > BEGIN > msg ("group M"); foo (bar, TRUE); > msg ("group N"); foo (dummy, FALSE); > END; From hosking at cs.purdue.edu Mon Jan 7 21:16:47 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 7 Jan 2008 15:16:47 -0500 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <20080107073815.DBCDD10D45C8@birch.elegosoft.com> References: <20080107073815.DBCDD10D45C8@birch.elegosoft.com> Message-ID: <4F88D761-5F3F-4891-B3BD-7490FC7E7A2A@cs.purdue.edu> Jay, I am very nervous about the pervasive nature of some of your recent commits. NT386GNU is usually configured with OS_TYPE="POSIX". Thus, the m3makefile for cm3, which contains the following: if equal (OS_TYPE, "POSIX") interface ("M3Backend") implementation ("M3BackPosix") implementation ("UtilsPosix") else import ("m3objfile") import ("m3back") interface ("M3Backend") implementation ("M3BackWin32") implementation ("UtilsWin32") end will build a POSIX backend for you on NT386GNU which should do the right thing in invoking the gcc-based backend. Your changes, which hardwire things in cm3 for NT386GNU are thus unnecessary. I suggest you back these changes out and reconsider things. Certainly, NT386GNU should be considered as an independent POSIX target from the NT386 WIN32 target. Thus, one need not make changes to M3BackWin32 for NT386GNU, since it is treated as a POSIX target. As far as threading goes, if user-level threading for NT386 does not work then I can imagine it would be OK to use native WIN32 threads. The switch for that is in m3core/src/thread/m3makefile, which would check for TARGET="NT386GNU" and choose sibdirectory WIN32 instead of using OS_TYPE to pick subdirectory POSIX. On Jan 7, 2008, at 8:38 AM, Jay Krell wrote: > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 08/01/07 08:38:15 > > Modified files: > cm3/m3-libs/m3core/src/unix/cygwin/: Umman.i3 Uresource.i3 > Utypes.m3 > cm3/m3-sys/cm3/src/: Builder.i3 Builder.m3 M3BackPosix.m3 > M3BackWin32.m3 M3Backend.i3 > cm3/m3-sys/cminstall/src/config/: NT386GNU > cm3/m3-sys/m3front/src/misc/: M3Front.m3 > > Log message: > some fixes for NT386GNU (cygwin) > > let win32 cm3 use the gcc backend if target == NT386GNU > might need a better interface here? > switching on target name is probably the wrong thing > need something called "use gcc backend" or somesuch > > loosen the check for file name vs. module name to account for > paths with both types of slashes > might need a better interface/implementation here? > should try to get the paths to line up instead? > > remove -fPIC since it warns that it is redundant (though the > warning is probably wrong > in other details -- not all code is position independent, merely > relocatable..) > > use configured ar, /usr/bin/ar doesn't work, just plain ar does > > update Umman.i3 MAP_ANONYMOUS to new shorter name MAP_ANON > > update Uresource.i3 from struct_rusage_start to VAR struct_rusage > > fix warning about unused import long in Utypes.m3 > > change SYSTEM_CC from cc to gcc because cc is something on my system, > that I have not investigated, and doesn't work; gcc is perfectly > ok here, though > cc lines up nicely with the other two character names -- ar and as > > now need to deal with threads to get m3core to build From darko at darko.org Mon Jan 7 21:23:14 2008 From: darko at darko.org (Darko) Date: Mon, 7 Jan 2008 12:23:14 -0800 Subject: [M3devel] CM3 on Leopard In-Reply-To: References: <6CD6F1AC-449E-421D-A26A-C50BA1DFC301@darko.org> Message-ID: <934FB1C7-75A5-4720-B14E-EFAF6CD52C46@darko.org> It seems that I just forgot to install the latest tools. I fixed it by installing XCode from the Leopard DVD. Exceptions seem to work ok, but I did a very basic test. Maybe I can run the regression test suite on 10.5 when it's finished. I'll report any problems meanwhile. Thanks, Darko. On 07/01/2008, at 11:08 AM, Tony Hosking wrote: > > On Jan 7, 2008, at 1:12 PM, Darko wrote: > >> Hi Tony, >> >> Are you using CM3 on Leopard, aka Mac OS X 10.5? > > No, I've deliberately *not* upgraded to Leopard until I am able to > test CM3 on it. Generally, I avoid bleeding edge OS upgrades for > precisely this reason. I don't know when I will have time to play > with CM3 on Leopard. Right now, I am tracking down another issue > related to the regression framework Olaf is putting together. > >> It's stopped working since I upgraded, I get: >> >> cc -o parser -fPIC _m3main.o [ ... various libs, modules ... ] - >> lm3gcdefs -lm -multiply_defined suppress -bind_at_load -shared-libgcc > > At least this suggest your cm3 binary was able to run on Leopard, > which is a good start. > >> >> /usr/bin/ld: /usr/lib/gcc/i686-apple-darwin8/4.0.1/../../../ >> libm.dylib unknown flags (type) of section 6 >> (__TEXT,__dof_plockstat) in load command 0 >> /usr/bin/ld: can't locate file for: -lgcc_s.10.4 >> collect2: ld returned 1 exit status >> >> when trying to compile. Uname says: >> >> Darwin Lucifer.local 9.1.0 Darwin Kernel Version 9.1.0: Wed Oct 31 >> 17:46:22 PDT 2007; root:xnu-1228.0.2~1/RELEASE_I386 i386 >> >> It would seem that i just needs to be nudged up to the right >> version, but I couldn't find anything in the cfg file. Any >> suggestions? > > I suspect that you need to rebuild the m3cg backend, but I have no > idea how well it will play with Leopard. > > Also, I have heard there were changes to ucontexts and other thread > state which may mean M3 exceptions break, but I have not verified yet. > >> >> Thanks, >> Darko. >> > From hosking at cs.purdue.edu Mon Jan 7 21:27:30 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 7 Jan 2008 15:27:30 -0500 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <4F88D761-5F3F-4891-B3BD-7490FC7E7A2A@cs.purdue.edu> References: <20080107073815.DBCDD10D45C8@birch.elegosoft.com> <4F88D761-5F3F-4891-B3BD-7490FC7E7A2A@cs.purdue.edu> Message-ID: Also, following up on your changes for the backend. I suggest you take a look at the way things are handled in the M3BackLinux.m3 code for PM3. You should be able to switch between the integrated backend and the gcc-based backend similarly, based on the value of the M3_BACKEND_MODE flag. Thus, controlling the backend is a simple matter of changing the cm3.cfg. On Jan 7, 2008, at 3:16 PM, Tony Hosking wrote: > Jay, I am very nervous about the pervasive nature of some of your > recent commits. NT386GNU is usually configured with > OS_TYPE="POSIX". Thus, the m3makefile for cm3, which contains the > following: > > if equal (OS_TYPE, "POSIX") > interface ("M3Backend") > implementation ("M3BackPosix") > implementation ("UtilsPosix") > else > import ("m3objfile") > import ("m3back") > interface ("M3Backend") > implementation ("M3BackWin32") > implementation ("UtilsWin32") > end > > will build a POSIX backend for you on NT386GNU which should do the > right thing in invoking the gcc-based backend. Your changes, which > hardwire things in cm3 for NT386GNU are thus unnecessary. I > suggest you back these changes out and reconsider things. > Certainly, NT386GNU should be considered as an independent POSIX > target from the NT386 WIN32 target. Thus, one need not make > changes to M3BackWin32 for NT386GNU, since it is treated as a POSIX > target. > > As far as threading goes, if user-level threading for NT386 does > not work then I can imagine it would be OK to use native WIN32 > threads. The switch for that is in m3core/src/thread/m3makefile, > which would check for TARGET="NT386GNU" and choose sibdirectory > WIN32 instead of using OS_TYPE to pick subdirectory POSIX. > > On Jan 7, 2008, at 8:38 AM, Jay Krell wrote: > >> CVSROOT: /usr/cvs >> Changes by: jkrell at birch. 08/01/07 08:38:15 >> >> Modified files: >> cm3/m3-libs/m3core/src/unix/cygwin/: Umman.i3 Uresource.i3 >> Utypes.m3 >> cm3/m3-sys/cm3/src/: Builder.i3 Builder.m3 M3BackPosix.m3 >> M3BackWin32.m3 M3Backend.i3 >> cm3/m3-sys/cminstall/src/config/: NT386GNU >> cm3/m3-sys/m3front/src/misc/: M3Front.m3 >> >> Log message: >> some fixes for NT386GNU (cygwin) >> >> let win32 cm3 use the gcc backend if target == NT386GNU >> might need a better interface here? >> switching on target name is probably the wrong thing >> need something called "use gcc backend" or somesuch >> >> loosen the check for file name vs. module name to account for >> paths with both types of slashes >> might need a better interface/implementation here? >> should try to get the paths to line up instead? >> >> remove -fPIC since it warns that it is redundant (though the >> warning is probably wrong >> in other details -- not all code is position independent, merely >> relocatable..) >> >> use configured ar, /usr/bin/ar doesn't work, just plain ar does >> >> update Umman.i3 MAP_ANONYMOUS to new shorter name MAP_ANON >> >> update Uresource.i3 from struct_rusage_start to VAR struct_rusage >> >> fix warning about unused import long in Utypes.m3 >> >> change SYSTEM_CC from cc to gcc because cc is something on my >> system, >> that I have not investigated, and doesn't work; gcc is perfectly >> ok here, though >> cc lines up nicely with the other two character names -- ar and as >> >> now need to deal with threads to get m3core to build > From hosking at cs.purdue.edu Mon Jan 7 21:28:59 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 7 Jan 2008 15:28:59 -0500 Subject: [M3devel] CM3 on Leopard In-Reply-To: <934FB1C7-75A5-4720-B14E-EFAF6CD52C46@darko.org> References: <6CD6F1AC-449E-421D-A26A-C50BA1DFC301@darko.org> <934FB1C7-75A5-4720-B14E-EFAF6CD52C46@darko.org> Message-ID: <2774155B-86E0-4F68-B1D6-AB1FCC9A8AB2@cs.purdue.edu> Very cool! I was thinking it was going to be more painful. Have you bootstrapped a new compiler? On Jan 7, 2008, at 3:23 PM, Darko wrote: > It seems that I just forgot to install the latest tools. I fixed it > by installing XCode from the Leopard DVD. > > Exceptions seem to work ok, but I did a very basic test. Maybe I > can run the regression test suite on 10.5 when it's finished. I'll > report any problems meanwhile. > > Thanks, > Darko. > > > > On 07/01/2008, at 11:08 AM, Tony Hosking wrote: > >> >> On Jan 7, 2008, at 1:12 PM, Darko wrote: >> >>> Hi Tony, >>> >>> Are you using CM3 on Leopard, aka Mac OS X 10.5? >> >> No, I've deliberately *not* upgraded to Leopard until I am able to >> test CM3 on it. Generally, I avoid bleeding edge OS upgrades for >> precisely this reason. I don't know when I will have time to play >> with CM3 on Leopard. Right now, I am tracking down another issue >> related to the regression framework Olaf is putting together. >> >>> It's stopped working since I upgraded, I get: >>> >>> cc -o parser -fPIC _m3main.o [ ... various libs, modules ... ] - >>> lm3gcdefs -lm -multiply_defined suppress -bind_at_load -shared- >>> libgcc >> >> At least this suggest your cm3 binary was able to run on Leopard, >> which is a good start. >> >>> >>> /usr/bin/ld: /usr/lib/gcc/i686-apple-darwin8/4.0.1/../../../ >>> libm.dylib unknown flags (type) of section 6 >>> (__TEXT,__dof_plockstat) in load command 0 >>> /usr/bin/ld: can't locate file for: -lgcc_s.10.4 >>> collect2: ld returned 1 exit status >>> >>> when trying to compile. Uname says: >>> >>> Darwin Lucifer.local 9.1.0 Darwin Kernel Version 9.1.0: Wed Oct >>> 31 17:46:22 PDT 2007; root:xnu-1228.0.2~1/RELEASE_I386 i386 >>> >>> It would seem that i just needs to be nudged up to the right >>> version, but I couldn't find anything in the cfg file. Any >>> suggestions? >> >> I suspect that you need to rebuild the m3cg backend, but I have no >> idea how well it will play with Leopard. >> >> Also, I have heard there were changes to ucontexts and other >> thread state which may mean M3 exceptions break, but I have not >> verified yet. >> >>> >>> Thanks, >>> Darko. >>> >> From darko at darko.org Mon Jan 7 21:41:48 2008 From: darko at darko.org (Darko) Date: Mon, 7 Jan 2008 12:41:48 -0800 Subject: [M3devel] CM3 on Leopard In-Reply-To: <2774155B-86E0-4F68-B1D6-AB1FCC9A8AB2@cs.purdue.edu> References: <6CD6F1AC-449E-421D-A26A-C50BA1DFC301@darko.org> <934FB1C7-75A5-4720-B14E-EFAF6CD52C46@darko.org> <2774155B-86E0-4F68-B1D6-AB1FCC9A8AB2@cs.purdue.edu> Message-ID: No, that's actually my idea of pain - the scripts never seem to work for me. But I'll give it a try because I need to have a go at the (byte) alignment problem evident with the current Intel Darwin compiler at some point. I've actually never really had a problem with Mac OS revisions beyond a cfg file tweak or a rollback of gcc versions. On 07/01/2008, at 12:28 PM, Tony Hosking wrote: > Very cool! I was thinking it was going to be more painful. Have > you bootstrapped a new compiler? > > > On Jan 7, 2008, at 3:23 PM, Darko wrote: > >> It seems that I just forgot to install the latest tools. I fixed it >> by installing XCode from the Leopard DVD. >> >> Exceptions seem to work ok, but I did a very basic test. Maybe I >> can run the regression test suite on 10.5 when it's finished. I'll >> report any problems meanwhile. >> >> Thanks, >> Darko. >> >> >> >> On 07/01/2008, at 11:08 AM, Tony Hosking wrote: >> >>> >>> On Jan 7, 2008, at 1:12 PM, Darko wrote: >>> >>>> Hi Tony, >>>> >>>> Are you using CM3 on Leopard, aka Mac OS X 10.5? >>> >>> No, I've deliberately *not* upgraded to Leopard until I am able to >>> test CM3 on it. Generally, I avoid bleeding edge OS upgrades for >>> precisely this reason. I don't know when I will have time to play >>> with CM3 on Leopard. Right now, I am tracking down another issue >>> related to the regression framework Olaf is putting together. >>> >>>> It's stopped working since I upgraded, I get: >>>> >>>> cc -o parser -fPIC _m3main.o [ ... various libs, modules ... ] - >>>> lm3gcdefs -lm -multiply_defined suppress -bind_at_load -shared- >>>> libgcc >>> >>> At least this suggest your cm3 binary was able to run on Leopard, >>> which is a good start. >>> >>>> >>>> /usr/bin/ld: /usr/lib/gcc/i686-apple-darwin8/4.0.1/../../../ >>>> libm.dylib unknown flags (type) of section 6 >>>> (__TEXT,__dof_plockstat) in load command 0 >>>> /usr/bin/ld: can't locate file for: -lgcc_s.10.4 >>>> collect2: ld returned 1 exit status >>>> >>>> when trying to compile. Uname says: >>>> >>>> Darwin Lucifer.local 9.1.0 Darwin Kernel Version 9.1.0: Wed Oct >>>> 31 17:46:22 PDT 2007; root:xnu-1228.0.2~1/RELEASE_I386 i386 >>>> >>>> It would seem that i just needs to be nudged up to the right >>>> version, but I couldn't find anything in the cfg file. Any >>>> suggestions? >>> >>> I suspect that you need to rebuild the m3cg backend, but I have no >>> idea how well it will play with Leopard. >>> >>> Also, I have heard there were changes to ucontexts and other >>> thread state which may mean M3 exceptions break, but I have not >>> verified yet. >>> >>>> >>>> Thanks, >>>> Darko. >>>> >>> > From jayk123 at hotmail.com Mon Jan 7 22:10:28 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 7 Jan 2008 21:10:28 +0000 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: References: <20080107073815.DBCDD10D45C8@birch.elegosoft.com> <4F88D761-5F3F-4891-B3BD-7490FC7E7A2A@cs.purdue.edu> Message-ID: > Thus, controlling the backend is a simple matter of changing the cm3.cfg Exactly. What I have right now is I build an NT386/Win32 cm3, and then I change the config file, and that one cm3 switches between gcc or not. It is a hybrid. I can already compile all of m3core with this cm3/m3cg, except for threading. I also copy the NT386 directories in pkg to NT386GNU, and possibly foo.lib to libfoo.a -- I have to try again to see if that was the key or not. This gives me an easier sort of "cross", on one machine/OS. I actually swap out the entire cm3.cfg, cm3/m3-sys/cminstall/config/NT386 vs. cm3/m3-sys/cminstall/config/NT386GNU, not just one line. I'll try the "mode" and look at pm3. Thanks. > threading Yeah I thought Win32 would work. I'll try/look again. Later. I think it was set for Posix/setjmp/longjmp and I think I tried pthreads, might not have tried Win32. - Jay > From: hosking at cs.purdue.edu > Date: Mon, 7 Jan 2008 15:27:30 -0500 > To: hosking at cs.purdue.edu > CC: m3devel at elegosoft.com; m3commit at elegosoft.com > Subject: Re: [M3commit] CVS Update: cm3 > > Also, following up on your changes for the backend. I suggest you > take a look at the way things are handled in the M3BackLinux.m3 code > for PM3. You should be able to switch between the integrated backend > and the gcc-based backend similarly, based on the value of the > M3_BACKEND_MODE flag. Thus, controlling the backend is a simple > matter of changing the cm3.cfg. > > > > On Jan 7, 2008, at 3:16 PM, Tony Hosking wrote: > > > Jay, I am very nervous about the pervasive nature of some of your > > recent commits. NT386GNU is usually configured with > > OS_TYPE="POSIX". Thus, the m3makefile for cm3, which contains the > > following: > > > > if equal (OS_TYPE, "POSIX") > > interface ("M3Backend") > > implementation ("M3BackPosix") > > implementation ("UtilsPosix") > > else > > import ("m3objfile") > > import ("m3back") > > interface ("M3Backend") > > implementation ("M3BackWin32") > > implementation ("UtilsWin32") > > end > > > > will build a POSIX backend for you on NT386GNU which should do the > > right thing in invoking the gcc-based backend. Your changes, which > > hardwire things in cm3 for NT386GNU are thus unnecessary. I > > suggest you back these changes out and reconsider things. > > Certainly, NT386GNU should be considered as an independent POSIX > > target from the NT386 WIN32 target. Thus, one need not make > > changes to M3BackWin32 for NT386GNU, since it is treated as a POSIX > > target. > > > > As far as threading goes, if user-level threading for NT386 does > > not work then I can imagine it would be OK to use native WIN32 > > threads. The switch for that is in m3core/src/thread/m3makefile, > > which would check for TARGET="NT386GNU" and choose sibdirectory > > WIN32 instead of using OS_TYPE to pick subdirectory POSIX. > > > > On Jan 7, 2008, at 8:38 AM, Jay Krell wrote: > > > >> CVSROOT: /usr/cvs > >> Changes by: jkrell at birch. 08/01/07 08:38:15 > >> > >> Modified files: > >> cm3/m3-libs/m3core/src/unix/cygwin/: Umman.i3 Uresource.i3 > >> Utypes.m3 > >> cm3/m3-sys/cm3/src/: Builder.i3 Builder.m3 M3BackPosix.m3 > >> M3BackWin32.m3 M3Backend.i3 > >> cm3/m3-sys/cminstall/src/config/: NT386GNU > >> cm3/m3-sys/m3front/src/misc/: M3Front.m3 > >> > >> Log message: > >> some fixes for NT386GNU (cygwin) > >> > >> let win32 cm3 use the gcc backend if target == NT386GNU > >> might need a better interface here? > >> switching on target name is probably the wrong thing > >> need something called "use gcc backend" or somesuch > >> > >> loosen the check for file name vs. module name to account for > >> paths with both types of slashes > >> might need a better interface/implementation here? > >> should try to get the paths to line up instead? > >> > >> remove -fPIC since it warns that it is redundant (though the > >> warning is probably wrong > >> in other details -- not all code is position independent, merely > >> relocatable..) > >> > >> use configured ar, /usr/bin/ar doesn't work, just plain ar does > >> > >> update Umman.i3 MAP_ANONYMOUS to new shorter name MAP_ANON > >> > >> update Uresource.i3 from struct_rusage_start to VAR struct_rusage > >> > >> fix warning about unused import long in Utypes.m3 > >> > >> change SYSTEM_CC from cc to gcc because cc is something on my > >> system, > >> that I have not investigated, and doesn't work; gcc is perfectly > >> ok here, though > >> cc lines up nicely with the other two character names -- ar and as > >> > >> now need to deal with threads to get m3core to build > > > _________________________________________________________________ Watch ?Cause Effect,? a show about real people making a real difference. http://im.live.com/Messenger/IM/MTV/?source=text_watchcause -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon Jan 7 22:21:37 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 7 Jan 2008 16:21:37 -0500 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: References: <20080107073815.DBCDD10D45C8@birch.elegosoft.com> <4F88D761-5F3F-4891-B3BD-7490FC7E7A2A@cs.purdue.edu> Message-ID: I'm about to check in a version that achieves what you want based on M3_BACKEND_MODE in cm3.cfg without the nasty hack of hardwiring cm3. On Jan 7, 2008, at 4:10 PM, Jay wrote: > > >> Thus, controlling the backend is a simple matter of changing the >> cm3.cfg > > > > Exactly. > > > What I have right now is I build an NT386/Win32 cm3, and then I > change the config file, and that one cm3 switches between gcc or not. > It is a hybrid. > I can already compile all of m3core with this cm3/m3cg, except for > threading. > I also copy the NT386 directories in pkg to NT386GNU, and possibly > foo.lib to libfoo.a -- I have to try again to see if that was the > key or not. > This gives me an easier sort of "cross", on one machine/OS. > > I actually swap out the entire cm3.cfg, cm3/m3-sys/cminstall/config/ > NT386 vs. cm3/m3-sys/cminstall/config/NT386GNU, not just one line. > > I'll try the "mode" and look at pm3. Thanks. > > >> threading > > Yeah I thought Win32 would work. I'll try/look again. Later. > I think it was set for Posix/setjmp/longjmp and I think I tried > pthreads, might not have tried Win32. > > - Jay > >> From: hosking at cs.purdue.edu >> Date: Mon, 7 Jan 2008 15:27:30 -0500 >> To: hosking at cs.purdue.edu >> CC: m3devel at elegosoft.com; m3commit at elegosoft.com >> Subject: Re: [M3commit] CVS Update: cm3 >> >> Also, following up on your changes for the backend. I suggest you >> take a look at the way things are handled in the M3BackLinux.m3 code >> for PM3. You should be able to switch between the integrated backend >> and the gcc-based backend similarly, based on the value of the >> M3_BACKEND_MODE flag. Thus, controlling the backend is a simple >> matter of changing the cm3.cfg. >> >> >> >> On Jan 7, 2008, at 3:16 PM, Tony Hosking wrote: >> >>> Jay, I am very nervous about the pervasive nature of some of your >>> recent commits. NT386GNU is usually configured with >>> OS_TYPE="POSIX". Thus, the m3makefile for cm3, which contains the >>> following: >>> >>> if equal (OS_TYPE, "POSIX") >>> interface ("M3Backend") >>> implementation ("M3BackPosix") >>> implementation ("UtilsPosix") >>> else >>> import ("m3objfile") >>> import ("m3back") >>> interface ("M3Backend") >>> implementation ("M3BackWin32") >>> implementation ("UtilsWin32") >>> end >>> >>> will build a POSIX backend for you on NT386GNU which should do the >>> right thing in invoking the gcc-based backend. Your changes, which >>> hardwire things in cm3 for NT386GNU are thus unnecessary. I >>> suggest you back these changes out and reconsider things. >>> Certainly, NT386GNU should be considered as an independent POSIX >>> target from the NT386 WIN32 target. Thus, one need not make >>> changes to M3BackWin32 for NT386GNU, since it is treated as a POSIX >>> target. >>> >>> As far as threading goes, if user-level threading for NT386 does >>> not work then I can imagine it would be OK to use native WIN32 >>> threads. The switch for that is in m3core/src/thread/m3makefile, >>> which would check for TARGET="NT386GNU" and choose sibdirectory >>> WIN32 instead of using OS_TYPE to pick subdirectory POSIX. >>> >>> On Jan 7, 2008, at 8:38 AM, Jay Krell wrote: >>> >>>> CVSROOT: /usr/cvs >>>> Changes by: jkrell at birch. 08/01/07 08:38:15 >>>> >>>> Modified files: >>>> cm3/m3-libs/m3core/src/unix/cygwin/: Umman.i3 Uresource.i3 >>>> Utypes.m3 >>>> cm3/m3-sys/cm3/src/: Builder.i3 Builder.m3 M3BackPosix.m3 >>>> M3BackWin32.m3 M3Backend.i3 >>>> cm3/m3-sys/cminstall/src/config/: NT386GNU >>>> cm3/m3-sys/m3front/src/misc/: M3Front.m3 >>>> >>>> Log message: >>>> some fixes for NT386GNU (cygwin) >>>> >>>> let win32 cm3 use the gcc backend if target == NT386GNU >>>> might need a better interface here? >>>> switching on target name is probably the wrong thing >>>> need something called "use gcc backend" or somesuch >>>> >>>> loosen the check for file name vs. module name to account for >>>> paths with both types of slashes >>>> might need a better interface/implementation here? >>>> should try to get the paths to line up instead? >>>> >>>> remove -fPIC since it warns that it is redundant (though the >>>> warning is probably wrong >>>> in other details -- not all code is position independent, merely >>>> relocatable..) >>>> >>>> use configured ar, /usr/bin/ar doesn't work, just plain ar does >>>> >>>> update Umman.i3 MAP_ANONYMOUS to new shorter name MAP_ANON >>>> >>>> update Uresource.i3 from struct_rusage_start to VAR struct_rusage >>>> >>>> fix warning about unused import long in Utypes.m3 >>>> >>>> change SYSTEM_CC from cc to gcc because cc is something on my >>>> system, >>>> that I have not investigated, and doesn't work; gcc is perfectly >>>> ok here, though >>>> cc lines up nicely with the other two character names -- ar and as >>>> >>>> now need to deal with threads to get m3core to build >>> >> > > _________________________________________________________________ > Watch ?Cause Effect,? a show about real people making a real > difference From kschleiser at elego.de Mon Jan 7 22:32:53 2008 From: kschleiser at elego.de (Kaspar Schleiser) Date: Mon, 07 Jan 2008 22:32:53 +0100 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <20080107192048.3FFBB10D461D@birch.elegosoft.com> References: <20080107192048.3FFBB10D461D@birch.elegosoft.com> Message-ID: <47829A85.4070609@elego.de> Hey, Antony Hosking wrote: > Log message: > Fix bug in procedure value comparison as revealed by p035 of m3tests. Is it possible that this breaks compilation on LINUXLIBC6? I'm getting the following compiler error using the 5.4.0 release compiler, which worked OK this morning: new source -> compiling RTCollector.m3 RTCollector.m3:1878: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. Cheers, Kaspar From hosking at cs.purdue.edu Mon Jan 7 23:28:09 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 7 Jan 2008 17:28:09 -0500 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: References: <20080107073815.DBCDD10D45C8@birch.elegosoft.com> <4F88D761-5F3F-4891-B3BD-7490FC7E7A2A@cs.purdue.edu> Message-ID: I went ahead and cleaned things up to be based on M3_BACKEND_MODE instead of the overly-hardwired approach you were using. On Jan 7, 2008, at 4:10 PM, Jay wrote: > > > Thus, controlling the backend is a simple matter of changing the > cm3.cfg > > Exactly. > > What I have right now is I build an NT386/Win32 cm3, and then I > change the config file, and that one cm3 switches between gcc or not. > It is a hybrid. > I can already compile all of m3core with this cm3/m3cg, except for > threading. > I also copy the NT386 directories in pkg to NT386GNU, and possibly > foo.lib to libfoo.a -- I have to try again to see if that was the > key or not. > This gives me an easier sort of "cross", on one machine/OS. > > I actually swap out the entire cm3.cfg, cm3/m3-sys/cminstall/config/ > NT386 vs. cm3/m3-sys/cminstall/config/NT386GNU, not just one line. > > I'll try the "mode" and look at pm3. Thanks. > > > threading > > Yeah I thought Win32 would work. I'll try/look again. Later. > I think it was set for Posix/setjmp/longjmp and I think I tried > pthreads, might not have tried Win32. > > - Jay > > > From: hosking at cs.purdue.edu > > Date: Mon, 7 Jan 2008 15:27:30 -0500 > > To: hosking at cs.purdue.edu > > CC: m3devel at elegosoft.com; m3commit at elegosoft.com > > Subject: Re: [M3commit] CVS Update: cm3 > > > > Also, following up on your changes for the backend. I suggest you > > take a look at the way things are handled in the M3BackLinux.m3 code > > for PM3. You should be able to switch between the integrated backend > > and the gcc-based backend similarly, based on the value of the > > M3_BACKEND_MODE flag. Thus, controlling the backend is a simple > > matter of changing the cm3.cfg. > > > > > > > > On Jan 7, 2008, at 3:16 PM, Tony Hosking wrote: > > > > > Jay, I am very nervous about the pervasive nature of some of your > > > recent commits. NT386GNU is usually configured with > > > OS_TYPE="POSIX". Thus, the m3makefile for cm3, which contains the > > > following: > > > > > > if equal (OS_TYPE, "POSIX") > > > interface ("M3Backend") > > > implementation ("M3BackPosix") > > > implementation ("UtilsPosix") > > > else > > > import ("m3objfile") > > > import ("m3back") > > > interface ("M3Backend") > > > implementation ("M3BackWin32") > > > implementation ("UtilsWin32") > > > end > > > > > > will build a POSIX backend for you on NT386GNU which should do the > > > right thing in invoking the gcc-based backend. Your changes, which > > > hardwire things in cm3 for NT386GNU are thus unnecessary. I > > > suggest you back these changes out and reconsider things. > > > Certainly, NT386GNU should be considered as an independent POSIX > > > target from the NT386 WIN32 target. Thus, one need not make > > > changes to M3BackWin32 for NT386GNU, since it is treated as a > POSIX > > > target. > > > > > > As far as threading goes, if user-level threading for NT386 does > > > not work then I can imagine it would be OK to use native WIN32 > > > threads. The switch for that is in m3core/src/thread/m3makefile, > > > which would check for TARGET="NT386GNU" and choose sibdirectory > > > WIN32 instead of using OS_TYPE to pick subdirectory POSIX. > > > > > > On Jan 7, 2008, at 8:38 AM, Jay Krell wrote: > > > > > >> CVSROOT: /usr/cvs > > >> Changes by: jkrell at birch. 08/01/07 08:38:15 > > >> > > >> Modified files: > > >> cm3/m3-libs/m3core/src/unix/cygwin/: Umman.i3 Uresource.i3 > > >> Utypes.m3 > > >> cm3/m3-sys/cm3/src/: Builder.i3 Builder.m3 M3BackPosix.m3 > > >> M3BackWin32.m3 M3Backend.i3 > > >> cm3/m3-sys/cminstall/src/config/: NT386GNU > > >> cm3/m3-sys/m3front/src/misc/: M3Front.m3 > > >> > > >> Log message: > > >> some fixes for NT386GNU (cygwin) > > >> > > >> let win32 cm3 use the gcc backend if target == NT386GNU > > >> might need a better interface here? > > >> switching on target name is probably the wrong thing > > >> need something called "use gcc backend" or somesuch > > >> > > >> loosen the check for file name vs. module name to account for > > >> paths with both types of slashes > > >> might need a better interface/implementation here? > > >> should try to get the paths to line up instead? > > >> > > >> remove -fPIC since it warns that it is redundant (though the > > >> warning is probably wrong > > >> in other details -- not all code is position independent, merely > > >> relocatable..) > > >> > > >> use configured ar, /usr/bin/ar doesn't work, just plain ar does > > >> > > >> update Umman.i3 MAP_ANONYMOUS to new shorter name MAP_ANON > > >> > > >> update Uresource.i3 from struct_rusage_start to VAR struct_rusage > > >> > > >> fix warning about unused import long in Utypes.m3 > > >> > > >> change SYSTEM_CC from cc to gcc because cc is something on my > > >> system, > > >> that I have not investigated, and doesn't work; gcc is perfectly > > >> ok here, though > > >> cc lines up nicely with the other two character names -- ar > and as > > >> > > >> now need to deal with threads to get m3core to build > > > > > > > Watch ?Cause Effect,? a show about real people making a real > difference. Learn more From hosking at cs.purdue.edu Mon Jan 7 23:29:04 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 7 Jan 2008 17:29:04 -0500 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: References: <20080107073815.DBCDD10D45C8@birch.elegosoft.com> <4F88D761-5F3F-4891-B3BD-7490FC7E7A2A@cs.purdue.edu> Message-ID: On Jan 7, 2008, at 4:10 PM, Jay wrote: > > >> Thus, controlling the backend is a simple matter of changing the >> cm3.cfg > > > > Exactly. > > > What I have right now is I build an NT386/Win32 cm3, and then I > change the config file, and that one cm3 switches between gcc or not. > It is a hybrid. The hybrid behavior can be controlled from cm3.cfg instead. See my latest checkin. > I can already compile all of m3core with this cm3/m3cg, except for > threading. > I also copy the NT386 directories in pkg to NT386GNU, and possibly > foo.lib to libfoo.a -- I have to try again to see if that was the > key or not. > This gives me an easier sort of "cross", on one machine/OS. > > I actually swap out the entire cm3.cfg, cm3/m3-sys/cminstall/config/ > NT386 vs. cm3/m3-sys/cminstall/config/NT386GNU, not just one line. > > I'll try the "mode" and look at pm3. Thanks. > > >> threading > > Yeah I thought Win32 would work. I'll try/look again. Later. > I think it was set for Posix/setjmp/longjmp and I think I tried > pthreads, might not have tried Win32. > > - Jay > >> From: hosking at cs.purdue.edu >> Date: Mon, 7 Jan 2008 15:27:30 -0500 >> To: hosking at cs.purdue.edu >> CC: m3devel at elegosoft.com; m3commit at elegosoft.com >> Subject: Re: [M3commit] CVS Update: cm3 >> >> Also, following up on your changes for the backend. I suggest you >> take a look at the way things are handled in the M3BackLinux.m3 code >> for PM3. You should be able to switch between the integrated backend >> and the gcc-based backend similarly, based on the value of the >> M3_BACKEND_MODE flag. Thus, controlling the backend is a simple >> matter of changing the cm3.cfg. >> >> >> >> On Jan 7, 2008, at 3:16 PM, Tony Hosking wrote: >> >>> Jay, I am very nervous about the pervasive nature of some of your >>> recent commits. NT386GNU is usually configured with >>> OS_TYPE="POSIX". Thus, the m3makefile for cm3, which contains the >>> following: >>> >>> if equal (OS_TYPE, "POSIX") >>> interface ("M3Backend") >>> implementation ("M3BackPosix") >>> implementation ("UtilsPosix") >>> else >>> import ("m3objfile") >>> import ("m3back") >>> interface ("M3Backend") >>> implementation ("M3BackWin32") >>> implementation ("UtilsWin32") >>> end >>> >>> will build a POSIX backend for you on NT386GNU which should do the >>> right thing in invoking the gcc-based backend. Your changes, which >>> hardwire things in cm3 for NT386GNU are thus unnecessary. I >>> suggest you back these changes out and reconsider things. >>> Certainly, NT386GNU should be considered as an independent POSIX >>> target from the NT386 WIN32 target. Thus, one need not make >>> changes to M3BackWin32 for NT386GNU, since it is treated as a POSIX >>> target. >>> >>> As far as threading goes, if user-level threading for NT386 does >>> not work then I can imagine it would be OK to use native WIN32 >>> threads. The switch for that is in m3core/src/thread/m3makefile, >>> which would check for TARGET="NT386GNU" and choose sibdirectory >>> WIN32 instead of using OS_TYPE to pick subdirectory POSIX. >>> >>> On Jan 7, 2008, at 8:38 AM, Jay Krell wrote: >>> >>>> CVSROOT: /usr/cvs >>>> Changes by: jkrell at birch. 08/01/07 08:38:15 >>>> >>>> Modified files: >>>> cm3/m3-libs/m3core/src/unix/cygwin/: Umman.i3 Uresource.i3 >>>> Utypes.m3 >>>> cm3/m3-sys/cm3/src/: Builder.i3 Builder.m3 M3BackPosix.m3 >>>> M3BackWin32.m3 M3Backend.i3 >>>> cm3/m3-sys/cminstall/src/config/: NT386GNU >>>> cm3/m3-sys/m3front/src/misc/: M3Front.m3 >>>> >>>> Log message: >>>> some fixes for NT386GNU (cygwin) >>>> >>>> let win32 cm3 use the gcc backend if target == NT386GNU >>>> might need a better interface here? >>>> switching on target name is probably the wrong thing >>>> need something called "use gcc backend" or somesuch >>>> >>>> loosen the check for file name vs. module name to account for >>>> paths with both types of slashes >>>> might need a better interface/implementation here? >>>> should try to get the paths to line up instead? >>>> >>>> remove -fPIC since it warns that it is redundant (though the >>>> warning is probably wrong >>>> in other details -- not all code is position independent, merely >>>> relocatable..) >>>> >>>> use configured ar, /usr/bin/ar doesn't work, just plain ar does >>>> >>>> update Umman.i3 MAP_ANONYMOUS to new shorter name MAP_ANON >>>> >>>> update Uresource.i3 from struct_rusage_start to VAR struct_rusage >>>> >>>> fix warning about unused import long in Utypes.m3 >>>> >>>> change SYSTEM_CC from cc to gcc because cc is something on my >>>> system, >>>> that I have not investigated, and doesn't work; gcc is perfectly >>>> ok here, though >>>> cc lines up nicely with the other two character names -- ar and as >>>> >>>> now need to deal with threads to get m3core to build >>> >> > > _________________________________________________________________ > Watch ?Cause Effect,? a show about real people making a real > difference From jayk123 at hotmail.com Tue Jan 8 00:40:49 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 7 Jan 2008 23:40:49 +0000 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: References: <20080107073815.DBCDD10D45C8@birch.elegosoft.com> <4F88D761-5F3F-4891-B3BD-7490FC7E7A2A@cs.purdue.edu> Message-ID: Right, thanks. Looks/sounds about right. Will try it "later". Except: http://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/cm3/src/M3BackWin32.m3.diff?r1=1.2;r2=1.3 Looks suspicious, just by visual inspection, haven't built it -- missing an import and comma vs. period. Style tangent: Have people heard the advise that boolean parameters are bad, because at the callsite esp. they don't give much meaning? What is TRUE? What is FALSE? Enums or named parameters are clearer. Furthermore, heck, the switch on small integers 0,1,2,3... (Not that my switching on targetname was good either.) And, more importantly, given a commit, how do I view it? Easily?Currently I hunt around to each file and view it, but I have to manually navigate to each file in cvs web. I want all the diffs associated with one checkin to be viewable together, no matter which all files were checked at the same time. - Jay > CC: m3devel at elegosoft.com; m3commit at elegosoft.com> From: hosking at cs.purdue.edu> Subject: Re: [M3commit] CVS Update: cm3> Date: Mon, 7 Jan 2008 17:29:04 -0500> To: jayk123 at hotmail.com> > > On Jan 7, 2008, at 4:10 PM, Jay wrote:> > >> >> >> Thus, controlling the backend is a simple matter of changing the > >> cm3.cfg> >> >> >> > Exactly.> >> >> > What I have right now is I build an NT386/Win32 cm3, and then I > > change the config file, and that one cm3 switches between gcc or not.> > It is a hybrid.> > The hybrid behavior can be controlled from cm3.cfg instead. See my > latest checkin.> > > I can already compile all of m3core with this cm3/m3cg, except for > > threading.> > I also copy the NT386 directories in pkg to NT386GNU, and possibly > > foo.lib to libfoo.a -- I have to try again to see if that was the > > key or not.> > This gives me an easier sort of "cross", on one machine/OS.> >> > I actually swap out the entire cm3.cfg, cm3/m3-sys/cminstall/config/ > > NT386 vs. cm3/m3-sys/cminstall/config/NT386GNU, not just one line.> >> > I'll try the "mode" and look at pm3. Thanks.> >> >> >> threading> >> > Yeah I thought Win32 would work. I'll try/look again. Later.> > I think it was set for Posix/setjmp/longjmp and I think I tried > > pthreads, might not have tried Win32.> >> > - Jay> >> >> From: hosking at cs.purdue.edu> >> Date: Mon, 7 Jan 2008 15:27:30 -0500> >> To: hosking at cs.purdue.edu> >> CC: m3devel at elegosoft.com; m3commit at elegosoft.com> >> Subject: Re: [M3commit] CVS Update: cm3> >>> >> Also, following up on your changes for the backend. I suggest you> >> take a look at the way things are handled in the M3BackLinux.m3 code> >> for PM3. You should be able to switch between the integrated backend> >> and the gcc-based backend similarly, based on the value of the> >> M3_BACKEND_MODE flag. Thus, controlling the backend is a simple> >> matter of changing the cm3.cfg.> >>> >>> >>> >> On Jan 7, 2008, at 3:16 PM, Tony Hosking wrote:> >>> >>> Jay, I am very nervous about the pervasive nature of some of your> >>> recent commits. NT386GNU is usually configured with> >>> OS_TYPE="POSIX". Thus, the m3makefile for cm3, which contains the> >>> following:> >>>> >>> if equal (OS_TYPE, "POSIX")> >>> interface ("M3Backend")> >>> implementation ("M3BackPosix")> >>> implementation ("UtilsPosix")> >>> else> >>> import ("m3objfile")> >>> import ("m3back")> >>> interface ("M3Backend")> >>> implementation ("M3BackWin32")> >>> implementation ("UtilsWin32")> >>> end> >>>> >>> will build a POSIX backend for you on NT386GNU which should do the> >>> right thing in invoking the gcc-based backend. Your changes, which> >>> hardwire things in cm3 for NT386GNU are thus unnecessary. I> >>> suggest you back these changes out and reconsider things.> >>> Certainly, NT386GNU should be considered as an independent POSIX> >>> target from the NT386 WIN32 target. Thus, one need not make> >>> changes to M3BackWin32 for NT386GNU, since it is treated as a POSIX> >>> target.> >>>> >>> As far as threading goes, if user-level threading for NT386 does> >>> not work then I can imagine it would be OK to use native WIN32> >>> threads. The switch for that is in m3core/src/thread/m3makefile,> >>> which would check for TARGET="NT386GNU" and choose sibdirectory> >>> WIN32 instead of using OS_TYPE to pick subdirectory POSIX.> >>>> >>> On Jan 7, 2008, at 8:38 AM, Jay Krell wrote:> >>>> >>>> CVSROOT: /usr/cvs> >>>> Changes by: jkrell at birch. 08/01/07 08:38:15> >>>>> >>>> Modified files:> >>>> cm3/m3-libs/m3core/src/unix/cygwin/: Umman.i3 Uresource.i3> >>>> Utypes.m3> >>>> cm3/m3-sys/cm3/src/: Builder.i3 Builder.m3 M3BackPosix.m3> >>>> M3BackWin32.m3 M3Backend.i3> >>>> cm3/m3-sys/cminstall/src/config/: NT386GNU> >>>> cm3/m3-sys/m3front/src/misc/: M3Front.m3> >>>>> >>>> Log message:> >>>> some fixes for NT386GNU (cygwin)> >>>> > >>>> let win32 cm3 use the gcc backend if target == NT386GNU> >>>> might need a better interface here?> >>>> switching on target name is probably the wrong thing> >>>> need something called "use gcc backend" or somesuch> >>>> > >>>> loosen the check for file name vs. module name to account for> >>>> paths with both types of slashes> >>>> might need a better interface/implementation here?> >>>> should try to get the paths to line up instead?> >>>> > >>>> remove -fPIC since it warns that it is redundant (though the> >>>> warning is probably wrong> >>>> in other details -- not all code is position independent, merely> >>>> relocatable..)> >>>> > >>>> use configured ar, /usr/bin/ar doesn't work, just plain ar does> >>>> > >>>> update Umman.i3 MAP_ANONYMOUS to new shorter name MAP_ANON> >>>> > >>>> update Uresource.i3 from struct_rusage_start to VAR struct_rusage> >>>> > >>>> fix warning about unused import long in Utypes.m3> >>>> > >>>> change SYSTEM_CC from cc to gcc because cc is something on my> >>>> system,> >>>> that I have not investigated, and doesn't work; gcc is perfectly> >>>> ok here, though> >>>> cc lines up nicely with the other two character names -- ar and as> >>>> > >>>> now need to deal with threads to get m3core to build> >>>> >>> >> > _________________________________________________________________> > Watch ?Cause Effect,? a show about real people making a real > > difference> _________________________________________________________________ Share life as it happens with the new Windows Live. http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Tue Jan 8 01:16:58 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 08 Jan 2008 01:16:58 +0100 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: References: <20080107073815.DBCDD10D45C8@birch.elegosoft.com> <4F88D761-5F3F-4891-B3BD-7490FC7E7A2A@cs.purdue.edu> Message-ID: <20080108011658.dp4d4zumw4wwkg88@mail.elegosoft.com> Quoting Jay : > Style tangent: Have people heard the advise that boolean parameters > are bad, because at the callsite esp. they don't give much meaning? > What is TRUE? What is FALSE? Enums or named parameters are clearer. I tend to agree, but this might get religious ;-) > And, more importantly, given a commit, how do I view it? > Easily?Currently I hunt around to each file and view it, but I have > to manually navigate to each file in cvs web. > I want all the diffs associated with one checkin to be viewable > together, no matter which all files were checked at the same time. You need two tags or dates to view changeset-like differences with CVS. For example cvs diff -u -r release_CM3_5_4_0 -r HEAD m3-libs will list all the changes in libraries between release 5.4.0 and the current HEAD. cvs diff -u -D yesterday -D now m3-sys Of course you can use other date formats, too, for example "1972-09-24 20:05" or "24 Sep 1972 20:05" or "1 hour ago". Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Jan 8 03:32:14 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 7 Jan 2008 21:32:14 -0500 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <47829A85.4070609@elego.de> References: <20080107192048.3FFBB10D461D@birch.elegosoft.com> <47829A85.4070609@elego.de> Message-ID: On Jan 7, 2008, at 4:32 PM, Kaspar Schleiser wrote: > Hey, > > Antony Hosking wrote: >> Log message: >> Fix bug in procedure value comparison as revealed by p035 of >> m3tests. > Is it possible that this breaks compilation on LINUXLIBC6? > I'm getting the following compiler error using the 5.4.0 release > compiler, which worked OK this morning: > > new source -> compiling RTCollector.m3 > RTCollector.m3:1878: internal compiler error: Segmentation fault > Please submit a full bug report, > with preprocessed source if appropriate. > See for instructions. Yeah, I have the same problem on I386_DARWIN. I will track down the problem tomorrow. Sorry for all the brokenness today -- it pays to compile and test before committing. It did fix the problem with p035 though. :-) > > Cheers, > Kaspar From hosking at cs.purdue.edu Tue Jan 8 04:02:34 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 7 Jan 2008 22:02:34 -0500 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <20080108011658.dp4d4zumw4wwkg88@mail.elegosoft.com> References: <20080107073815.DBCDD10D45C8@birch.elegosoft.com> <4F88D761-5F3F-4891-B3BD-7490FC7E7A2A@cs.purdue.edu> <20080108011658.dp4d4zumw4wwkg88@mail.elegosoft.com> Message-ID: On Jan 7, 2008, at 7:16 PM, Olaf Wagner wrote: > Quoting Jay : > >> Style tangent: Have people heard the advise that boolean >> parameters are bad, because at the callsite esp. they don't give >> much meaning? What is TRUE? What is FALSE? Enums or named >> parameters are clearer. > > I tend to agree, but this might get religious ;-) Indeed. I considered [0..3] but decided against it. :-) But seriously, an alternative would have been a new type in the interface I suppose. Given that it is a private module to the package I didn't feel overly compelled to be more obvious. From hosking at cs.purdue.edu Tue Jan 8 07:23:58 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 8 Jan 2008 01:23:58 -0500 Subject: [M3devel] more m3tests failures In-Reply-To: <20080108013027.jjutp2wnc48gwsk4@mail.elegosoft.com> References: <20080105210005.7iacdx5nkks84osk@mail.elegosoft.com> <20080108013027.jjutp2wnc48gwsk4@mail.elegosoft.com> Message-ID: <4E362486-79CE-4283-AA39-D18066C9E44F@cs.purdue.edu> Seems to be fixed now. Includes fix for p035. On Jan 7, 2008, at 7:30 PM, Olaf Wagner wrote: > Quoting Tony Hosking : > >> I just checked in the fix for p035, with changes to the gcc-based >> backend (tree-nested.c and parse.c). > > As Kaspar has already noticed, this seems to break compilation > of m3core: > > +++ cm3 -build -override -DROOT='/d/home/wagner/work/cm3' - > DCM3_VERSION_TEXT='d5.5.1' -DCM3_VERSION_NUMBER='050501' - > DCM3_LAST_CHANGED='2007-12-30' +++ > --- building in FreeBSD4 --- > > new source -> compiling RTCollector.m3 > RTCollector.m3:1878: internal compiler error: Segmentation fault: 11 > Please submit a full bug report, > with preprocessed source if appropriate. > See for instructions. > compilation failed => not building library "libm3core.a" > Fatal Error: package build failed > *** execution of failed *** > > Olaf >> >> On Jan 5, 2008, at 3:00 PM, Olaf Wagner wrote: >> >>> I've looked into some more failures of m3tests, which I'd like to >>> present to the whole list: (All tests run on FreeBSD 6.3) >>> >>> p035 is a scoping problem which was Ok with >>> >>> /usr/local/cm3/bin/cm3cg-5.4.0 >>> >>> but >>> >>> /usr/local/cm3/bin/cm3cg-d5.5.1 >>> >>> fails, so it must be caused by recent gcc changes. The check that >>> fails is >>> >>> PROCEDURE foo (p: P; same: BOOLEAN) = >>> BEGIN >>> checkB (bar = p, same); checkB (bar # p, NOT same); >>> END foo; >>> PROCEDURE bar (<*UNUSED*> t: Text.T) = >>> BEGIN >>> END bar; >>> BEGIN >>> msg ("group M"); foo (bar, TRUE); >>> msg ("group N"); foo (dummy, FALSE); >>> END; > > > > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, > Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Jan 8 09:13:22 2008 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Tue, 08 Jan 2008 09:13:22 +0100 Subject: [M3devel] Didn't happen for long time now... pthread related error while ./scripts/do-cm3-std.sh build Message-ID: <1199780002.11961.28.camel@faramir.m3w.org> I have Fedora6 on this box, and I've building cm3 for long time on it. Last night ago I've updated my local repo to CVS head, and tried this script.. It breaks on every package linking pthread, looks like. Then I cd to package folder, type "cm3", and it links ok. Example is at end of message. cm3.cfg changes? Here is what I think is relevant in my current. % grep -i pthread /usr/local/cm3/bin/cm3.cfg -A1 -B1 "LIBC" : [ "-lm" ], "PTHREAD" : ["-L/usr/lib", "-lpthread"], %-- not on most Linux platforms -- SYSTEM_LIBORDER = [ "OPENGL", "DECPEX", "MOTIF", "X11", "TCP", "ODBC", "POSTGRES95", "FLEX-BISON", "LEX-YACC", "LIBC", "PTHREAD" ] TIA, dd > === package m3-tools/m3totex === > +++ cm3 -DPTHREAD -build -override -DROOT='/home/dragisha/src/cm3-cvshead-0629/cm3' -DCM3_VERSION_TEXT='d5.5.1' -DCM3_VERSION_NUMBER='050501' -DCM3_LAST_CHANGED='2007-12-30' +++ > --- building in LINUXLIBC6 --- > > /home/dragisha/src/cm3-cvshead-0629/cm3/m3-tools/m3bundle/LINUXLIBC6/m3bundle -name B -F/var/tmp/qk > new source -> compiling B.i3 > new source -> compiling B.m3 > new source -> compiling m3totex.m3 > -> linking m3totex > /home/dragisha/src/cm3-cvshead-0629/cm3/m3-libs/m3core/LINUXLIBC6/libm3core.so: undefined reference to `sem_init' > /home/dragisha/src/cm3-cvshead-0629/cm3/m3-libs/m3core/LINUXLIBC6/libm3core.so: undefined reference to `pthread_key_create' > /home/dragisha/src/cm3-cvshead-0629/cm3/m3-libs/m3core/LINUXLIBC6/libm3core.so: undefined reference to `pthread_attr_setstacksize' > /home/dragisha/src/cm3-cvshead-0629/cm3/m3-libs/m3core/LINUXLIBC6/libm3core.so: undefined reference to `pthread_kill' > /home/dragisha/src/cm3-cvshead-0629/cm3/m3-libs/m3core/LINUXLIBC6/libm3core.so: undefined reference to `pthread_getspecific' > /home/dragisha/src/cm3-cvshead-0629/cm3/m3-libs/m3core/LINUXLIBC6/libm3core.so: undefined reference to `pthread_create' > /home/dragisha/src/cm3-cvshead-0629/cm3/m3-libs/m3core/LINUXLIBC6/libm3core.so: undefined reference to `pthread_attr_getstacksize' > /home/dragisha/src/cm3-cvshead-0629/cm3/m3-libs/m3core/LINUXLIBC6/libm3core.so: undefined reference to `sem_post' > /home/dragisha/src/cm3-cvshead-0629/cm3/m3-libs/m3core/LINUXLIBC6/libm3core.so: undefined reference to `pthread_detach' > /home/dragisha/src/cm3-cvshead-0629/cm3/m3-libs/m3core/LINUXLIBC6/libm3core.so: undefined reference to `sem_getvalue' > /home/dragisha/src/cm3-cvshead-0629/cm3/m3-libs/m3core/LINUXLIBC6/libm3core.so: undefined reference to `pthread_setspecific' > /home/dragisha/src/cm3-cvshead-0629/cm3/m3-libs/m3core/LINUXLIBC6/libm3core.so: undefined reference to `sem_wait' > collect2: ld returned 1 exit status > Fatal Error: package build failed > *** execution of failed *** > faramir:dragisha/pts/7: src/cm3-cvshead-0629/cm3% cd m3-tools/m3totex > faramir:dragisha/pts/7: cm3/m3-tools/m3totex% cm3 > --- building in LINUXLIBC6 --- > > ignoring ../src/m3overrides > > -> linking m3totex > faramir:dragisha/pts/7: cm3/m3-tools/m3totex% which cm3 > /usr/local/cm3/bin/cm3 > faramir:dragisha/pts/7: cm3/m3-tools/m3totex% echo $CM3 > cm3 -DPTHREAD > -- Dragi?a Duri? From lemming at henning-thielemann.de Tue Jan 8 12:29:30 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Tue, 08 Jan 2008 12:29:30 +0100 (CET) Subject: [M3devel] BOOLEAN (Was: CVS Update: cm3) In-Reply-To: <20080108011658.dp4d4zumw4wwkg88@mail.elegosoft.com> References: <20080107073815.DBCDD10D45C8@birch.elegosoft.com> <4F88D761-5F3F-4891-B3BD-7490FC7E7A2A@cs.purdue.edu> <20080108011658.dp4d4zumw4wwkg88@mail.elegosoft.com> Message-ID: On Tue, 8 Jan 2008, Olaf Wagner wrote: > Quoting Jay : > > > Style tangent: Have people heard the advise that boolean parameters > > are bad, because at the callsite esp. they don't give much meaning? > > What is TRUE? What is FALSE? Enums or named parameters are clearer. > > I tend to agree, but this might get religious ;-) In Modula-3 you can explicitly write f (switch := TRUE); Problem is of course, that you only can but you need not. Another advise I like to give about BOOLEANs is, that one should use positive flag names, e.g. not skipIntro := FALSE; but showIntro := TRUE; not disableGUI := TRUE; but enableGUI := FALSE; From jayk123 at hotmail.com Tue Jan 8 14:18:10 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 8 Jan 2008 13:18:10 +0000 Subject: [M3devel] BOOLEAN (Was: CVS Update: cm3) In-Reply-To: References: <20080107073815.DBCDD10D45C8@birch.elegosoft.com> <4F88D761-5F3F-4891-B3BD-7490FC7E7A2A@cs.purdue.edu> <20080108011658.dp4d4zumw4wwkg88@mail.elegosoft.com> Message-ID: Henning, agreed. I said named parameters help, understood that they are up to the caller to use though. Agreed about avoiding negative options, better to have an option that is positive, and leave the users as true and false, or..er..oops, that's what we are also saying not to use. I'm definitely a proponent of this second one. I actually haven't heard/used it for locals, but more for, uh, parameters. (I see I'm being hypocritical again -- don't use booleans...but if you do, use positive ones..), makes sense for locals too. On the other hand, I also like to default things to false/zero, globals, and locals, for easier/more efficient initialization, lately in C I write: void F() { type1 local1 = { 0 } type2 local2 = { 0 } .. } for all my small locals. A good compiler will optimize away at least some of them (as long as they aren't "out parameters") and I've been too burned by uninitialized locals too much, and the code is usually fairly efficient otherwise (again, the initialization can often be removed by the compiler), to desire optimizing them.. So sometimes name things to favor false being the default or more common value. For globals esp. that saves space in the resulting executable. For locals, well, if you initialize all your locals to zero, the compiler can optimize that, into a small loop for zeroing...if it was REALLY smart, it'd move the locals that are zero-initialized to be adjacent, but that could trade off with other factors so I don't assume it happens. - Jay > Date: Tue, 8 Jan 2008 12:29:30 +0100> From: lemming at henning-thielemann.de> Subject: BOOLEAN (Was: CVS Update: cm3)> To: wagner at elegosoft.com> CC: jayk123 at hotmail.com; m3devel at elegosoft.com> > > On Tue, 8 Jan 2008, Olaf Wagner wrote:> > > Quoting Jay :> >> > > Style tangent: Have people heard the advise that boolean parameters> > > are bad, because at the callsite esp. they don't give much meaning?> > > What is TRUE? What is FALSE? Enums or named parameters are clearer.> >> > I tend to agree, but this might get religious ;-)> > In Modula-3 you can explicitly write> f (switch := TRUE);> Problem is of course, that you only can but you need not.> > > Another advise I like to give about BOOLEANs is, that one should use> positive flag names, e.g. not> skipIntro := FALSE;> but> showIntro := TRUE;> > not> disableGUI := TRUE;> but> enableGUI := FALSE;> _________________________________________________________________ Make distant family not so distant with Windows Vista? + Windows Live?. http://www.microsoft.com/windows/digitallife/keepintouch.mspx?ocid=TXT_TAGLM_CPC_VideoChat_distantfamily_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Tue Jan 8 14:24:00 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 8 Jan 2008 13:24:00 +0000 Subject: [M3devel] Didn't happen for long time now... pthread related error while ./scripts/do-cm3-std.sh In-Reply-To: <1199780002.11961.28.camel@faramir.m3w.org> References: <1199780002.11961.28.camel@faramir.m3w.org> Message-ID: Not my area of expertise, but, try this: > "LIBC" : [ "-lm", "-L/usr/lib", "-lpthread" ], > "PTHREAD" : [ ], and look here: http://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/cminstall/src/config/LINUXLIBC6?rev=1.20;content-type=text%2Fplain or here: http://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/cminstall/src/config-no-install/LINUXLIBC6?rev=1.10;content-type=text%2Fplain ..ok, which suggests really, try this: "LIBC" : [ "-Xlinker", "-Bdynamic", "-L/usr/lib", "-lm", "-L/usr/lib", "-lpthread" ], and remove the PTHREAD line. (My suggest was from memory of -lpthread being on the LIBC line.) - Jay > From: dragisha at m3w.org> To: m3devel at elegosoft.com> Date: Tue, 8 Jan 2008 09:13:22 +0100> Subject: [M3devel] Didn't happen for long time now... pthread related error while ./scripts/do-cm3-std.sh build> > I have Fedora6 on this box, and I've building cm3 for long time on it.> Last night ago I've updated my local repo to CVS head, and tried this> script.. It breaks on every package linking pthread, looks like. Then I> cd to package folder, type "cm3", and it links ok. Example is at end of> message.> > cm3.cfg changes? Here is what I think is relevant in my current.> > > % grep -i pthread /usr/local/cm3/bin/cm3.cfg -A1 -B1> "LIBC" : [ "-lm" ],> "PTHREAD" : ["-L/usr/lib", "-lpthread"],> %-- not on most Linux platforms> --> SYSTEM_LIBORDER = [ "OPENGL", "DECPEX", "MOTIF", "X11", "TCP", "ODBC",> "POSTGRES95", "FLEX-BISON", "LEX-YACC", "LIBC",> "PTHREAD" ]> > TIA,> dd> > > > === package m3-tools/m3totex ===> > +++ cm3 -DPTHREAD -build -override -DROOT='/home/dragisha/src/cm3-cvshead-0629/cm3' -DCM3_VERSION_TEXT='d5.5.1' -DCM3_VERSION_NUMBER='050501' -DCM3_LAST_CHANGED='2007-12-30' +++> > --- building in LINUXLIBC6 ---> > > > /home/dragisha/src/cm3-cvshead-0629/cm3/m3-tools/m3bundle/LINUXLIBC6/m3bundle -name B -F/var/tmp/qk> > new source -> compiling B.i3> > new source -> compiling B.m3> > new source -> compiling m3totex.m3> > -> linking m3totex> > /home/dragisha/src/cm3-cvshead-0629/cm3/m3-libs/m3core/LINUXLIBC6/libm3core.so: undefined reference to `sem_init'> > /home/dragisha/src/cm3-cvshead-0629/cm3/m3-libs/m3core/LINUXLIBC6/libm3core.so: undefined reference to `pthread_key_create'> > /home/dragisha/src/cm3-cvshead-0629/cm3/m3-libs/m3core/LINUXLIBC6/libm3core.so: undefined reference to `pthread_attr_setstacksize'> > /home/dragisha/src/cm3-cvshead-0629/cm3/m3-libs/m3core/LINUXLIBC6/libm3core.so: undefined reference to `pthread_kill'> > /home/dragisha/src/cm3-cvshead-0629/cm3/m3-libs/m3core/LINUXLIBC6/libm3core.so: undefined reference to `pthread_getspecific'> > /home/dragisha/src/cm3-cvshead-0629/cm3/m3-libs/m3core/LINUXLIBC6/libm3core.so: undefined reference to `pthread_create'> > /home/dragisha/src/cm3-cvshead-0629/cm3/m3-libs/m3core/LINUXLIBC6/libm3core.so: undefined reference to `pthread_attr_getstacksize'> > /home/dragisha/src/cm3-cvshead-0629/cm3/m3-libs/m3core/LINUXLIBC6/libm3core.so: undefined reference to `sem_post'> > /home/dragisha/src/cm3-cvshead-0629/cm3/m3-libs/m3core/LINUXLIBC6/libm3core.so: undefined reference to `pthread_detach'> > /home/dragisha/src/cm3-cvshead-0629/cm3/m3-libs/m3core/LINUXLIBC6/libm3core.so: undefined reference to `sem_getvalue'> > /home/dragisha/src/cm3-cvshead-0629/cm3/m3-libs/m3core/LINUXLIBC6/libm3core.so: undefined reference to `pthread_setspecific'> > /home/dragisha/src/cm3-cvshead-0629/cm3/m3-libs/m3core/LINUXLIBC6/libm3core.so: undefined reference to `sem_wait'> > collect2: ld returned 1 exit status> > Fatal Error: package build failed> > *** execution of failed ***> > faramir:dragisha/pts/7: src/cm3-cvshead-0629/cm3% cd m3-tools/m3totex> > faramir:dragisha/pts/7: cm3/m3-tools/m3totex% cm3> > --- building in LINUXLIBC6 ---> > > > ignoring ../src/m3overrides> > > > -> linking m3totex> > faramir:dragisha/pts/7: cm3/m3-tools/m3totex% which cm3> > /usr/local/cm3/bin/cm3> > faramir:dragisha/pts/7: cm3/m3-tools/m3totex% echo $CM3> > cm3 -DPTHREAD> > > -- > Dragi?a Duri? > _________________________________________________________________ Watch "Cause Effect," a show about real people making a real difference. http://im.live.com/Messenger/IM/MTV/?source=text_watchcause -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Tue Jan 8 23:57:30 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 08 Jan 2008 23:57:30 +0100 Subject: [M3devel] pthread errors on FreeBSD In-Reply-To: References: <20080105195158.l0sirwku74k84o0s@mail.elegosoft.com> Message-ID: <20080108235730.kkfq44pjkc8s0s0o@mail.elegosoft.com> Quoting Tony Hosking : > On Jan 5, 2008, at 1:51 PM, Olaf Wagner wrote: > >> Hi Tony, >> >> I've today run the tests in m3-sys/m3tests (which were never completely >> adapted to CM3 since my initial import in 2003, I'm afraid), but there >> are two significant differences between UTHREADS and PTHREADS on >> FreeBSD. >> >> The first is the failure of p005: >> >> --- p005 --- a simple thread program >> --- p0/p005/stdout.pgm 2008-01-05 18:24:25.000000000 +0100 >> +++ ../src/p0/p005/stdout.pgm 2003-03-08 11:14:00.000000000 +0100 >> @@ -1,4 +1,4 @@ >> i = 12 >> -Changing i to 15 >> +Changing i to 19 >> Changing i to 22 >> i = 22 >> >> This concerns the order in which new threads are started. > > Whatever order they are started there is no guarantee they will reach > acquire the lock in any particular order. > >> I'm not >> sure if this is really specified, or just random; if so, the test >> should be changed. Programs which make assumptions about the order >> will of course fail then. > > The test needs changing to force a particular order. > >> The second failure shows up in p007, where `a whole bunch of threads' >> is started: >> +++ ../src/p0/p007/stderr.pgm 2003-03-08 11:14:01.000000000 +0100 >> @@ -218,11 +218,1798 @@ >> 218: 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 >> 219: 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 >> 220: 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 >> - 221: >> - >> -*** >> -*** runtime error: >> -*** Thread client error: Release failed with error: 1 >> -*** file "ThreadPThread.m3", line 174 >> -*** >> - >> + 221: 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 >> + 222: 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 >> + 223: 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 >> + 224: 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 >> + 225: 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 >> + 226: 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 >> + 227: 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 >> + 228: 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 >> + 229: 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 >> + 230: 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 >> + 231: 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 >> + 232: 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 >> + 233: 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 >> + 234: 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 >> + 235: 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 >> + 236: 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 >> >> Here a thread crashes when trying to unlock a mutex with EPERM, >> which I do not really understand. man errno says: > > I am unable to reproduce this on my I386_DARWIN machine. EPERM is the > error given if the thread trying to release the mutex does not actually > hold it. However, the ThreadPThread is already checking to make sure > the lock is held by the releasing thread, in this case claiming that > the thread *does* hold the lock. So, I suspect the EPERM error is a > result of some other problem, though I don't know what based on the > output you are showing. I wonder if you have encountered some system > limit. This seems to be caused by using the ThreadF interface to suspend other threads. If a mutex is used, the test passes: PROCEDURE Txt (t: TEXT) = BEGIN (* ThreadF.SuspendOthers (); *) LOCK iolock DO RTIO.PutText (t); END; (* ThreadF.ResumeOthers (); *) END Txt; Apart from the fact that a mutex is the correct thing to use, have you any idea why ThreadF procedures fail? It makes me a bit nervous, as they are used by the garbage collector, aren't they? Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Jan 9 00:16:36 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 8 Jan 2008 18:16:36 -0500 Subject: [M3devel] pthread errors on FreeBSD In-Reply-To: <20080108235730.kkfq44pjkc8s0s0o@mail.elegosoft.com> References: <20080105195158.l0sirwku74k84o0s@mail.elegosoft.com> <20080108235730.kkfq44pjkc8s0s0o@mail.elegosoft.com> Message-ID: Let me look into this one... On Jan 8, 2008, at 5:57 PM, Olaf Wagner wrote: > Quoting Tony Hosking : >> On Jan 5, 2008, at 1:51 PM, Olaf Wagner wrote: >> >>> The second failure shows up in p007, where `a whole bunch of >>> threads' >>> is started: >>> +++ ../src/p0/p007/stderr.pgm 2003-03-08 11:14:01.000000000 +0100 >>> @@ -218,11 +218,1798 @@ >>> 218: 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 >>> 219: 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 >>> 220: 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 >>> - 221: >>> - >>> -*** >>> -*** runtime error: >>> -*** Thread client error: Release failed with error: 1 >>> -*** file "ThreadPThread.m3", line 174 >>> -*** >>> - >>> + 221: 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 >>> + 222: 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 >>> + 223: 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 >>> + 224: 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 >>> + 225: 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 >>> + 226: 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 >>> + 227: 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 >>> + 228: 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 >>> + 229: 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 >>> + 230: 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 >>> + 231: 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 >>> + 232: 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 >>> + 233: 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 >>> + 234: 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 >>> + 235: 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 >>> + 236: 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 >>> >>> Here a thread crashes when trying to unlock a mutex with EPERM, >>> which I do not really understand. man errno says: >> >> I am unable to reproduce this on my I386_DARWIN machine. EPERM is >> the >> error given if the thread trying to release the mutex does not >> actually >> hold it. However, the ThreadPThread is already checking to make sure >> the lock is held by the releasing thread, in this case claiming that >> the thread *does* hold the lock. So, I suspect the EPERM error is a >> result of some other problem, though I don't know what based on the >> output you are showing. I wonder if you have encountered some system >> limit. > > This seems to be caused by using the ThreadF interface to suspend > other threads. If a mutex is used, the test passes: > > PROCEDURE Txt (t: TEXT) = > BEGIN > (* ThreadF.SuspendOthers (); *) > LOCK iolock DO > RTIO.PutText (t); > END; > (* ThreadF.ResumeOthers (); *) > END Txt; > > Apart from the fact that a mutex is the correct thing to use, > have you any idea why ThreadF procedures fail? It makes me a bit > nervous, as they are used by the garbage collector, aren't they? > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, > Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Wed Jan 9 04:48:25 2008 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Wed, 9 Jan 2008 04:48:25 +0100 (CET) Subject: [M3devel] Didn't happen for long time now... pthread related error while ./scripts/do-cm3-std.sh build In-Reply-To: <1199780002.11961.28.camel@faramir.m3w.org> Message-ID: <791321.83057.qm@web27112.mail.ukl.yahoo.com> Hi: Try putting "LIBC" : [ "-lm", "-lpthread" ], in cm3.cfg file I think in this Ubuntu it happened the same, so try and let we know what happens. Daniel Benavides Dragi??a Duri?? wrote: I have Fedora6 on this box, and I've building cm3 for long time on it. Last night ago I've updated my local repo to CVS head, and tried this script.. It breaks on every package linking pthread, looks like. Then I cd to package folder, type "cm3", and it links ok. Example is at end of message. cm3.cfg changes? Here is what I think is relevant in my current. % grep -i pthread /usr/local/cm3/bin/cm3.cfg -A1 -B1 "LIBC" : [ "-lm" ], "PTHREAD" : ["-L/usr/lib", "-lpthread"], %-- not on most Linux platforms -- SYSTEM_LIBORDER = [ "OPENGL", "DECPEX", "MOTIF", "X11", "TCP", "ODBC", "POSTGRES95", "FLEX-BISON", "LEX-YACC", "LIBC", "PTHREAD" ] TIA, dd > === package m3-tools/m3totex === > +++ cm3 -DPTHREAD -build -override -DROOT='/home/dragisha/src/cm3-cvshead-0629/cm3' -DCM3_VERSION_TEXT='d5.5.1' -DCM3_VERSION_NUMBER='050501' -DCM3_LAST_CHANGED='2007-12-30' +++ > --- building in LINUXLIBC6 --- > > /home/dragisha/src/cm3-cvshead-0629/cm3/m3-tools/m3bundle/LINUXLIBC6/m3bundle -name B -F/var/tmp/qk > new source -> compiling B.i3 > new source -> compiling B.m3 > new source -> compiling m3totex.m3 > -> linking m3totex > /home/dragisha/src/cm3-cvshead-0629/cm3/m3-libs/m3core/LINUXLIBC6/libm3core.so: undefined reference to `sem_init' > /home/dragisha/src/cm3-cvshead-0629/cm3/m3-libs/m3core/LINUXLIBC6/libm3core.so: undefined reference to `pthread_key_create' > /home/dragisha/src/cm3-cvshead-0629/cm3/m3-libs/m3core/LINUXLIBC6/libm3core.so: undefined reference to `pthread_attr_setstacksize' > /home/dragisha/src/cm3-cvshead-0629/cm3/m3-libs/m3core/LINUXLIBC6/libm3core.so: undefined reference to `pthread_kill' > /home/dragisha/src/cm3-cvshead-0629/cm3/m3-libs/m3core/LINUXLIBC6/libm3core.so: undefined reference to `pthread_getspecific' > /home/dragisha/src/cm3-cvshead-0629/cm3/m3-libs/m3core/LINUXLIBC6/libm3core.so: undefined reference to `pthread_create' > /home/dragisha/src/cm3-cvshead-0629/cm3/m3-libs/m3core/LINUXLIBC6/libm3core.so: undefined reference to `pthread_attr_getstacksize' > /home/dragisha/src/cm3-cvshead-0629/cm3/m3-libs/m3core/LINUXLIBC6/libm3core.so: undefined reference to `sem_post' > /home/dragisha/src/cm3-cvshead-0629/cm3/m3-libs/m3core/LINUXLIBC6/libm3core.so: undefined reference to `pthread_detach' > /home/dragisha/src/cm3-cvshead-0629/cm3/m3-libs/m3core/LINUXLIBC6/libm3core.so: undefined reference to `sem_getvalue' > /home/dragisha/src/cm3-cvshead-0629/cm3/m3-libs/m3core/LINUXLIBC6/libm3core.so: undefined reference to `pthread_setspecific' > /home/dragisha/src/cm3-cvshead-0629/cm3/m3-libs/m3core/LINUXLIBC6/libm3core.so: undefined reference to `sem_wait' > collect2: ld returned 1 exit status > Fatal Error: package build failed > *** execution of failed *** > faramir:dragisha/pts/7: src/cm3-cvshead-0629/cm3% cd m3-tools/m3totex > faramir:dragisha/pts/7: cm3/m3-tools/m3totex% cm3 > --- building in LINUXLIBC6 --- > > ignoring ../src/m3overrides > > -> linking m3totex > faramir:dragisha/pts/7: cm3/m3-tools/m3totex% which cm3 > /usr/local/cm3/bin/cm3 > faramir:dragisha/pts/7: cm3/m3-tools/m3totex% echo $CM3 > cm3 -DPTHREAD > -- Dragi??a Duri?? --------------------------------- Web Revelaci?n Yahoo! 2007: Premio Favorita del P?blico - ?Vota tu preferida! -------------- next part -------------- An HTML attachment was scrubbed... URL: From dabenavidesd at yahoo.es Wed Jan 9 05:10:17 2008 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Wed, 9 Jan 2008 05:10:17 +0100 (CET) Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: Message-ID: <909140.85424.qm@web27110.mail.ukl.yahoo.com> Hi: You can check what are the differences between a given set of files against a cvs repository with cvs and the diff option: In the below example of the directory of cm3/doc/turorial/m3 (Modula-3 tutorial), the current (in that bash session was revision 1.2), so the comparision is between my version (let's say the wanted to be commited) and the rev. 1.2: daniel at fbd-desktop:~/code/m3-devel$ cvs -d :ext:dbenavid at birch.elegosoft.com:/usr/cvs diff cm3/doc/tutorial/m3 Enter passphrase for key '/home/daniel/.ssh/id_dsa': cvs diff: Diffing cm3/doc/tutorial/m3 Index: cm3/doc/tutorial/m3/m3_2.html =================================================================== RCS file: /usr/cvs/cm3/doc/tutorial/m3/m3_2.html,v retrieving revision 1.2 diff -r1.2 m3_2.html 30c30 < IO.GetLine(name); --- > name:=IO.GetLine(); daniel at fbd-desktop:~/code/m3-devel$ The contents of the my current directory (me-devel) are: daniel at fbd-desktop:~/code/m3-devel$ ls -alh cm3/* cm3/CVS: total 20K drwxr-xr-x 2 daniel daniel 4,0K 2008-01-06 10:28 . drwxr-xr-x 4 daniel daniel 4,0K 2008-01-06 09:40 .. -rw-r--r-- 1 daniel daniel 10 2008-01-06 10:28 Entries -rw-r--r-- 1 daniel daniel 0 2008-01-06 09:40 Entries.Static -rw-r--r-- 1 daniel daniel 4 2008-01-06 09:40 Repository -rw-r--r-- 1 daniel daniel 43 2008-01-06 09:40 Root cm3/doc: total 16K drwxr-xr-x 4 daniel daniel 4,0K 2008-01-06 09:40 . drwxr-xr-x 4 daniel daniel 4,0K 2008-01-06 09:40 .. drwxr-xr-x 2 daniel daniel 4,0K 2008-01-06 10:28 CVS drwxr-xr-x 4 daniel daniel 4,0K 2008-01-06 09:40 tutorial daniel at fbd-desktop:~/code/m3-devel$ This is helpful if you want to compare them in a recursively way. Daniel Benavides Jay wrote: .hmmessage P { margin:0px; padding:0px } body.hmmessage { FONT-SIZE: 10pt; FONT-FAMILY:Tahoma } Right, thanks. Looks/sounds about right. Will try it "later". Except: http://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/cm3/src/M3BackWin32.m3.diff?r1=1.2;r2=1.3 Looks suspicious, just by visual inspection, haven't built it -- missing an import and comma vs. period. Style tangent: Have people heard the advise that boolean parameters are bad, because at the callsite esp. they don't give much meaning? What is TRUE? What is FALSE? Enums or named parameters are clearer. Furthermore, heck, the switch on small integers 0,1,2,3... (Not that my switching on targetname was good either.) And, more importantly, given a commit, how do I view it? Easily? Currently I hunt around to each file and view it, but I have to manually navigate to each file in cvs web. I want all the diffs associated with one checkin to be viewable together, no matter which all files were checked at the same time. - Jay --------------------------------- > CC: m3devel at elegosoft.com; m3commit at elegosoft.com > From: hosking at cs.purdue.edu > Subject: Re: [M3commit] CVS Update: cm3 > Date: Mon, 7 Jan 2008 17:29:04 -0500 > To: jayk123 at hotmail.com > > > On Jan 7, 2008, at 4:10 PM, Jay wrote: > > > > > > >> Thus, controlling the backend is a simple matter of changing the > >> cm3.cfg > > > > > > > > Exactly. > > > > > > What I have right now is I build an NT386/Win32 cm3, and then I > > change the config file, and that one cm3 switches between gcc or not. > > It is a hybrid. > > The hybrid behavior can be controlled from cm3.cfg instead. See my > latest checkin. > > > I can already compile all of m3core with this cm3/m3cg, except for > > threading. > > I also copy the NT386 directories in pkg to NT386GNU, and possibly > > foo.lib to libfoo.a -- I have to try again to see if that was the > > key or not. > > This gives me an easier sort of "cross", on one machine/OS. > > > > I actually swap out the entire cm3.cfg, cm3/m3-sys/cminstall/config/ > > NT386 vs. cm3/m3-sys/cminstall/config/NT386GNU, not just one line. > > > > I'll try the "mode" and look at pm3. Thanks. > > > > > >> threading > > > > Yeah I thought Win32 would work. I'll try/look again. Later. > > I think it was set for Posix/setjmp/longjmp and I think I tried > > pthreads, might not have tried Win32. > > > > - Jay > > > >> From: hosking at cs.purdue.edu > >> Date: Mon, 7 Jan 2008 15:27:30 -0500 > >> To: hosking at cs.purdue.edu > >> CC: m3devel at elegosoft.com; m3commit at elegosoft.com > >> Subject: Re: [M3commit] CVS Update: cm3 > >> > >> Also, following up on your changes for the backend. I suggest you > >> take a look at the way things are handled in the M3BackLinux.m3 code > >> for PM3. You should be able to switch between the integrated backend > >> and the gcc-based backend similarly, based on the value of the > >> M3_BACKEND_MODE flag. Thus, controlling the backend is a simple > >> matter of changing the cm3.cfg. > >> > >> > >> > >> On Jan 7, 2008, at 3:16 PM, Tony Hosking wrote: > >> > >>> Jay, I am very nervous about the pervasive nature of some of your > >>> recent commits. NT386GNU is usually configured with > >>> OS_TYPE="POSIX". Thus, the m3makefile for cm3, which contains the > >>> following: > >>> > >>> if equal (OS_TYPE, "POSIX") > >>> interface ("M3Backend") > >>> implementation ("M3BackPosix") > >>> implementation ("UtilsPosix") > >>> else > >>> import ("m3objfile") > >>> import ("m3back") > >>> interface ("M3Backend") > >>> implementation ("M3BackWin32") > >>> implementation ("UtilsWin32") > >>> end > >>> > >>> will build a POSIX backend for you on NT386GNU which should do the > >>> right thing in invoking the gcc-based backend. Your changes, which > >>> hardwire things in cm3 for NT386GNU are thus unnecessary. I > >>> suggest you back these changes out and reconsider things. > >>> Certainly, NT386GNU should be considered as an independent POSIX > >>> target from the NT386 WIN32 target. Thus, one need not make > >>> changes to M3BackWin32 for NT386GNU, since it is treated as a POSIX > >>> target. > >>> > >>> As far as threading goes, if user-level threading for NT386 does > >>> not work then I can imagine it would be OK to use native WIN32 > >>> threads. The switch for that is in m3core/src/thread/m3makefile, > >>> which would check for TARGET="NT386GNU" and choose sibdirectory > >>> WIN32 instead of using OS_TYPE to pick subdirectory POSIX. > >>> > >>> On Jan 7, 2008, at 8:38 AM, Jay Krell wrote: > >>> > >>>> CVSROOT: /usr/cvs > >>>> Changes by: jkrell at birch. 08/01/07 08:38:15 > >>>> > >>>> Modified files: > >>>> cm3/m3-libs/m3core/src/unix/cygwin/: Umman.i3 Uresource.i3 > >>>> Utypes.m3 > >>>> cm3/m3-sys/cm3/src/: Builder.i3 Builder.m3 M3BackPosix.m3 > >>>> M3BackWin32.m3 M3Backend.i3 > >>>> cm3/m3-sys/cminstall/src/config/: NT386GNU > >>>> cm3/m3-sys/m3front/src/misc/: M3Front.m3 > >>>> > >>>> Log message: > >>>> some fixes for NT386GNU (cygwin) > >>>> > >>>> let win32 cm3 use the gcc backend if target == NT386GNU > >>>> might need a better interface here? > >>>> switching on target name is probably the wrong thing > >>>> need something called "use gcc backend" or somesuch > >>>> > >>>> loosen the check for file name vs. module name to account for > >>>> paths with both types of slashes > >>>> might need a better interface/implementation here? > >>>> should try to get the paths to line up instead? > >>>> > >>>> remove -fPIC since it warns that it is redundant (though the > >>>> warning is probably wrong > >>>> in other details -- not all code is position independent, merely > >>>> relocatable..) > >>>> > >>>> use configured ar, /usr/bin/ar doesn't work, just plain ar does > >>>> > >>>> update Umman.i3 MAP_ANONYMOUS to new shorter name MAP_ANON > >>>> > >>>> update Uresource.i3 from struct_rusage_start to VAR struct_rusage > >>>> > >>>> fix warning about unused import long in Utypes.m3 > >>>> > >>>> change SYSTEM_CC from cc to gcc because cc is something on my > >>>> system, > >>>> that I have not investigated, and doesn't work; gcc is perfectly > >>>> ok here, though > >>>> cc lines up nicely with the other two character names -- ar and as > >>>> > >>>> now need to deal with threads to get m3core to build > >>> > >> > > > > _________________________________________________________________ > > Watch ?Cause Effect,? a show about real people making a real > > difference > --------------------------------- Share life as it happens with the new Windows Live. Start sharing! --------------------------------- Web Revelaci?n Yahoo! 2007: Premio Favorita del P?blico - ?Vota tu preferida! -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Wed Jan 9 11:29:48 2008 From: jayk123 at hotmail.com (Jay) Date: Wed, 9 Jan 2008 10:29:48 +0000 Subject: [M3devel] bunch of win32 archives available Message-ID: I can now readily create these, just via scripts\python\make-dist.Interesting? Note that that they are all now "rooted" in a directory correspondingto their "basename" (cm3-min-WIN32-NT386-d5.5.1, not just cm3, not one level below that)I'm still undecided on this. Rooting them at just "cm3" is much more convenient.Even if I setup a link/junction, cm3 to ...d.5.5.1, annoying then to upgradeit in place to 5.5.2 and still have the old directory name. Also note that "core" and "base" sound the same, and are almost the same. C:\DOCUME~1\Jay\LOCALS~1\Temp\cm3\make-dist\tmp4zutb8>dir /a-d Directory of C:\DOCUME~1\Jay\LOCALS~1\Temp\cm3\make-dist\tmp4zutb8 01/09/2008 12:08 AM 1,666,826 cm3-base-WIN32-NT386-d5.5.1-symbols.tar.bz201/09/2008 12:07 AM 1,939,273 cm3-base-WIN32-NT386-d5.5.1-symbols.zip01/09/2008 12:08 AM 7,388,174 cm3-base-WIN32-NT386-d5.5.1.exe01/09/2008 12:08 AM 5,941,364 cm3-base-WIN32-NT386-d5.5.1.tar.bz201/09/2008 12:08 AM 7,209,998 cm3-base-WIN32-NT386-d5.5.1.zip01/09/2008 12:07 AM 1,590,776 cm3-core-WIN32-NT386-d5.5.1-symbols.tar.bz201/09/2008 12:06 AM 1,943,429 cm3-core-WIN32-NT386-d5.5.1-symbols.zip01/09/2008 12:07 AM 7,388,037 cm3-core-WIN32-NT386-d5.5.1.exe01/09/2008 12:07 AM 5,942,837 cm3-core-WIN32-NT386-d5.5.1.tar.bz201/09/2008 12:07 AM 7,209,861 cm3-core-WIN32-NT386-d5.5.1.zip01/09/2008 12:02 AM 734,369 cm3-min-WIN32-NT386-d5.5.1-symbols.tar.bz201/09/2008 12:02 AM 891,409 cm3-min-WIN32-NT386-d5.5.1-symbols.zip01/09/2008 12:02 AM 3,346,742 cm3-min-WIN32-NT386-d5.5.1.exe01/09/2008 12:02 AM 2,642,419 cm3-min-WIN32-NT386-d5.5.1.tar.bz201/09/2008 12:02 AM 3,168,566 cm3-min-WIN32-NT386-d5.5.1.zip01/09/2008 12:04 AM 5,493,247 cm3-std-WIN32-NT386-d5.5.1-symbols.tar.bz201/09/2008 12:03 AM 6,617,011 cm3-std-WIN32-NT386-d5.5.1-symbols.zip01/09/2008 12:04 AM 19,373,554 cm3-std-WIN32-NT386-d5.5.1.exe01/09/2008 12:06 AM 15,826,615 cm3-std-WIN32-NT386-d5.5.1.tar.bz201/09/2008 12:04 AM 19,195,378 cm3-std-WIN32-NT386-d5.5.1.zip I guess just stick with .zip. Arguably symbols are for "power users/developers" that will have tar/bzip2, arguably not. - Jay _________________________________________________________________ Get the power of Windows + Web with the new Windows Live. http://www.windowslive.com?ocid=TXT_TAGHM_Wave2_powerofwindows_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Wed Jan 9 17:05:57 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 9 Jan 2008 11:05:57 -0500 Subject: [M3devel] Didn't happen for long time now... pthread related error while ./scripts/do-cm3-std.sh In-Reply-To: References: <1199780002.11961.28.camel@faramir.m3w.org> Message-ID: On Jan 8, 2008, at 8:24 AM, Jay wrote: > Not my area of expertise, but, try this: > > > "LIBC" : [ "-lm", "-L/usr/lib", "-lpthread" ], > > "PTHREAD" : [ ], PTHREAD is no longer used, so can safely be discarded. LIBC should indeed contain "-lpthread" where pthreads are not part of libc. > > > and look here: > > http://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/cminstall/ > src/config/LINUXLIBC6?rev=1.20;content-type=text%2Fplain > > or here: > > http://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/cminstall/ > src/config-no-install/LINUXLIBC6?rev=1.10;content-type=text%2Fplain > > ..ok, which suggests really, try this: > > "LIBC" : [ "-Xlinker", "-Bdynamic", "-L/usr/lib", "-lm", "- > L/usr/lib", "-lpthread" ], > > and remove the PTHREAD line. (My suggest was from memory of - > lpthread being on the LIBC line.) > > - Jay > > > > > From: dragisha at m3w.org > > To: m3devel at elegosoft.com > > Date: Tue, 8 Jan 2008 09:13:22 +0100 > > Subject: [M3devel] Didn't happen for long time now... pthread > related error while ./scripts/do-cm3-std.sh build > > > > I have Fedora6 on this box, and I've building cm3 for long time > on it. > > Last night ago I've updated my local repo to CVS head, and tried > this > > script.. It breaks on every package linking pthread, looks like. > Then I > > cd to package folder, type "cm3", and it links ok. Example is at > end of > > message. > > > > cm3.cfg changes? Here is what I think is relevant in my current. > > > > > > % grep -i pthread /usr/local/cm3/bin/cm3.cfg -A1 -B1 > > "LIBC" : [ "-lm" ], > > "PTHREAD" : ["-L/usr/lib", "-lpthread"], > > %-- not on most Linux platforms > > -- > > SYSTEM_LIBORDER = [ "OPENGL", "DECPEX", "MOTIF", "X11", "TCP", > "ODBC", > > "POSTGRES95", "FLEX-BISON", "LEX-YACC", "LI! BC", > > "PTHREAD" ] > > > > TIA, > > dd > > > > > > > === package m3-tools/m3totex === > > > +++ cm3 -DPTHREAD -build -override -DROOT='/home/dragisha/src/ > cm3-cvshead-0629/cm3' -DCM3_VERSION_TEXT='d5.5.1' - > DCM3_VERSION_NUMBER='050501' -DCM3_LAST_CHANGED='2007-12-30' +++ > > > --- building in LINUXLIBC6 --- > > > > > > /home/dragisha/src/cm3-cvshead-0629/cm3/m3-tools/m3bundle/ > LINUXLIBC6/m3bundle -name B -F/var/tmp/qk > > > new source -> compiling B.i3 > > > new source -> compiling B.m3 > > > new source -> compiling m3totex.m3 > > > -> linking m3totex > > > /home/dragisha/src/cm3-cvshead-0629/cm3/m3-libs/m3core/ > LINUXLIBC6/libm3core.so: undefined reference to `sem_init' > > > /home/dragisha/src/cm3-cvshead-0629/cm3/m3-libs/m3core/ > LINUXLIBC6/libm3core.so: undefined reference to `pthread_key_create' > > > /home/dragisha/src/cm3-cvshead-0629/cm3/m3-libs/m3c! ore/ > LINUXLIBC6/libm3core.so: undefined reference to `pthread_attr_sets > tacksize' > > > /home/dragisha/src/cm3-cvshead-0629/cm3/m3-libs/m3core/ > LINUXLIBC6/libm3core.so: undefined reference to `pthread_kill' > > > /home/dragisha/src/cm3-cvshead-0629/cm3/m3-libs/m3core/ > LINUXLIBC6/libm3core.so: undefined reference to `pthread_getspecific' > > > /home/dragisha/src/cm3-cvshead-0629/cm3/m3-libs/m3core/ > LINUXLIBC6/libm3core.so: undefined reference to `pthread_create' > > > /home/dragisha/src/cm3-cvshead-0629/cm3/m3-libs/m3core/ > LINUXLIBC6/libm3core.so: undefined reference to > `pthread_attr_getstacksize' > > > /home/dragisha/src/cm3-cvshead-0629/cm3/m3-libs/m3core/ > LINUXLIBC6/libm3core.so: undefined reference to `sem_post' > > > /home/dragisha/src/cm3-cvshead-0629/cm3/m3-libs/m3core/ > LINUXLIBC6/libm3core.so: undefined reference to `pthread_detach' > > > /home/dragisha/src/cm3-cvshead-0629/cm3/m3-libs/m3core/ > LINUXLIBC6/libm3core.so: undefined reference to `sem_getvalue' > > > /home/dragisha/src/cm3-cvshea! d-0629/cm3/m3-libs/m3core/ > LINUXLIBC6/libm3core.so: undefined reference to `pthread_setspecific' > > > /home/dragisha/src/cm3-cvshead-0629/cm3/m3-libs/m3core/ > LINUXLIBC6/libm3core.so: undefined reference to `sem_wait' > > > collect2: ld returned 1 exit status > > > Fatal Error: package build failed > > > *** execution of failed *** > > > faramir:dragisha/pts/7: src/cm3-cvshead-0629/cm3% cd m3-tools/ > m3totex > > > faramir:dragisha/pts/7: cm3/m3-tools/m3totex% cm3 > > > --- building in LINUXLIBC6 --- > > > > > > ignoring ../src/m3overrides > > > > > > -> linking m3totex > > > faramir:dragisha/pts/7: cm3/m3-tools/m3totex% which cm3 > > > /usr/local/cm3/bin/cm3 > > > faramir:dragisha/pts/7: cm3/m3-tools/m3totex% echo $CM3 > > > cm3 -DPTHREAD > > > > > -- > > Dragi?a Duri? > > > > > Watch "Cause Effect," a show abo! ut real people making a real > difference. Learn more From hosking at cs.purdue.edu Wed Jan 9 18:03:47 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 9 Jan 2008 12:03:47 -0500 Subject: [M3devel] pthread errors on FreeBSD In-Reply-To: <20080108235730.kkfq44pjkc8s0s0o@mail.elegosoft.com> References: <20080105195158.l0sirwku74k84o0s@mail.elegosoft.com> <20080108235730.kkfq44pjkc8s0s0o@mail.elegosoft.com> Message-ID: <0EF146EC-FC60-4467-BEA0-D2B18C608E3C@cs.purdue.edu> On Jan 8, 2008, at 5:57 PM, Olaf Wagner wrote: > Quoting Tony Hosking : >> On Jan 5, 2008, at 1:51 PM, Olaf Wagner wrote: >> >>> >>> The second failure shows up in p007, where `a whole bunch of >>> threads' >>> is started: >>> +++ ../src/p0/p007/stderr.pgm 2003-03-08 11:14:01.000000000 +0100 >>> @@ -218,11 +218,1798 @@ >>> 218: 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 >>> 219: 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 >>> 220: 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 >>> - 221: >>> - >>> -*** >>> -*** runtime error: >>> -*** Thread client error: Release failed with error: 1 >>> -*** file "ThreadPThread.m3", line 174 >>> -*** >>> - >>> + 221: 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 >>> + 222: 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 >>> + 223: 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 >>> + 224: 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 >>> + 225: 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 >>> + 226: 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 >>> + 227: 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 >>> + 228: 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 >>> + 229: 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 >>> + 230: 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 >>> + 231: 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 >>> + 232: 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 >>> + 233: 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 >>> + 234: 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 >>> + 235: 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 >>> + 236: 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 >>> >>> Here a thread crashes when trying to unlock a mutex with EPERM, >>> which I do not really understand. man errno says: >> >> I am unable to reproduce this on my I386_DARWIN machine. EPERM is >> the >> error given if the thread trying to release the mutex does not >> actually >> hold it. However, the ThreadPThread is already checking to make sure >> the lock is held by the releasing thread, in this case claiming that >> the thread *does* hold the lock. So, I suspect the EPERM error is a >> result of some other problem, though I don't know what based on the >> output you are showing. I wonder if you have encountered some system >> limit. > > This seems to be caused by using the ThreadF interface to suspend > other threads. If a mutex is used, the test passes: > > PROCEDURE Txt (t: TEXT) = > BEGIN > (* ThreadF.SuspendOthers (); *) > LOCK iolock DO > RTIO.PutText (t); > END; > (* ThreadF.ResumeOthers (); *) > END Txt; > > Apart from the fact that a mutex is the correct thing to use, > have you any idea why ThreadF procedures fail? It makes me a bit > nervous, as they are used by the garbage collector, aren't they? ThreadF.SuspendOthers/ResumeOthers are particularly dangerous operations that should not be used generally by user-level code, especially where multiple threads may simultaneously invoke SuspendOthers/ResumeOthers, as in this example. I suspect also that any call to SuspendOthers should only be made when RTOS.LockHeap has been called, based on the dependency between LockHeap and SuspendOthers in the ThreadPThread implementation. I could fix this by adding the necessary calls to SuspendOthers (since LockHeap is re- entrant), but would like you to confirm that the following change "works" (even though a lock really is the correct way to go): PROCEDURE Txt (t: TEXT) = BEGIN RTOS.LockHeap(); ThreadF.SuspendOthers (); RTIO.PutText (t); ThreadF.ResumeOthers (); RTOS.UnlockHeap(); END Txt; > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, > Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Jan 10 00:08:57 2008 From: jayk123 at hotmail.com (Jay) Date: Wed, 9 Jan 2008 23:08:57 +0000 Subject: [M3devel] nt386gnu is posix or win32? In-Reply-To: References: <20080107073815.DBCDD10D45C8@birch.elegosoft.com> <4F88D761-5F3F-4891-B3BD-7490FC7E7A2A@cs.purdue.edu> Message-ID: I'm going to be rude and just throw this out there at a time when I probably can't discuss it or yet have enough data/diffs to matter. However, in building NT386GNU -- I can build libm3 and m3core -- the question arises as to if this target is "win32" or "posix'. Currently in the tree it is setup to be "posix", with a fair amount of work already done in that direction -- in particular, the Unix interfaces. However, I think this target is potentially an odd beast. Potentially it is two targets. I guess this mimics cygwin vs. mingwin. Exactly. The "host" is gcc. In order to build this system, one needs "gmake", sh, gcc probably (I'm assuming Visual C++'s compiler/linker cannot build m3cg, but very maybe..). In order to build anything with this system, one needs "as", and most likely ld. (I quote "as" because it is an English word and confusing to read otherwise.) Changing it to output assembly for masm or even Visual C++'s inline __asm is probably actually viable, but not a tiny short term task. (Or maybe writing an as clone that outputs .objs? Maybe using nasm/yasm??? Not sure the point, maybe "as" is perfectly ok.) And then the question arises as to what it takes to run the output. As I've said in other topics, the C runtime dependency of Modula-3 is light -- startup code mainly, but, yeah, also important setjmp/longjmp, and multiplication/division helpers sometimes. This could perhaps all be statically linked. Certainly for Visual C++ it can be. (NOTE: The Cygwin jmp_buf is much larger than Visual C++'s. A THOUGHT is to grow them to the same, for object code compatibility, but probably not useful, and very wasteful, Cygwin's is much larger, the data in the existing code I verified is correct, like 0x40 vs. 0xD0 I think it was, I just did printf("%x", sizeof(jmp_buf)).) To get m3core to build, I switched NT386GNU to use Win32 threads. For THAT to build, I switched OSTYPE to Win32. Overkill perhaps, in order to get the Win32 *.i3 files. Overkill perhaps, but it does build. I fully suspect that old style Posix threads can work easily, and that pthreads can work easily, increasing the dependency on cygwin1.dll. While this is the "other" direction, given the dependency on as, and gcc to build m3cg, probably the horse is out of the barn. This is arguably a simpler answer, less hybrid. I think the analogy to cygwin/mingwin holds, possibly perfectly. Maybe this is two targets. NT386CYGWIN ? NT386MINGWIN ? (Which begs the point -- target naming.... NT386 vs. PPC_LINUX...OS+ARCH vs. ARCH + _ + OS, etc... but ARCH and OS aren't it, there is toolchain and C runtime in the mix..) Obviously SOMETHING is better than NOTHING and I have no useful binary distribution yet to show, so these questions are all very premature. I'm also unsure as to the "seriousness" of using the GNU tools. a) There don't seem to be many users of Modula-3 on Win32. b) Will such users accept/trust a non Microsoft toolchain? (Just what to do folks do with cygwin/mingwin? Build/ship real software?) >From my point of view, the attractive thing about m3cg is I get the int64 stuff arguably out of the way easier. :) Licensing wise..probably a dependency on cygwin1.dll is not desirable. When I'm further along, er, actually, with my existing libm3.dll/m3core.dll, I can see what the dependencies are. If it's just setjmp/lonjmp/memset, maybe try static linking (what is the licensing of that?) or link to msvcr*.dll. Maybe see if I can configure to use mingwin to compile/link except for m3cc. That sounds excellent. You would configure a CYGWIN_ROOT (gcc, ld, make, sh, libs) and a MINGWIN_ROOT (gcc, ld, libs). CYGWIN_ROOT would be required for building m3cc, and either could be used for building anything else. ?? That seems good, though I just thought of it, need more time to think and investigate. Later.. - Jay _________________________________________________________________ Share life as it happens with the new Windows Live. http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Thu Jan 10 01:16:03 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 10 Jan 2008 01:16:03 +0100 Subject: [M3devel] pthread errors on FreeBSD In-Reply-To: <0EF146EC-FC60-4467-BEA0-D2B18C608E3C@cs.purdue.edu> References: <20080105195158.l0sirwku74k84o0s@mail.elegosoft.com> <20080108235730.kkfq44pjkc8s0s0o@mail.elegosoft.com> <0EF146EC-FC60-4467-BEA0-D2B18C608E3C@cs.purdue.edu> Message-ID: <20080110011603.zwkknbh9z44gk40k@mail.elegosoft.com> Quoting Tony Hosking : > On Jan 8, 2008, at 5:57 PM, Olaf Wagner wrote: >> This seems to be caused by using the ThreadF interface to suspend >> other threads. If a mutex is used, the test passes: >> >> PROCEDURE Txt (t: TEXT) = >> BEGIN >> (* ThreadF.SuspendOthers (); *) >> LOCK iolock DO >> RTIO.PutText (t); >> END; >> (* ThreadF.ResumeOthers (); *) >> END Txt; >> >> Apart from the fact that a mutex is the correct thing to use, >> have you any idea why ThreadF procedures fail? It makes me a bit >> nervous, as they are used by the garbage collector, aren't they? > > ThreadF.SuspendOthers/ResumeOthers are particularly dangerous > operations that should not be used generally by user-level code, > especially where multiple threads may simultaneously invoke > SuspendOthers/ResumeOthers, as in this example. I suspect also that > any call to SuspendOthers should only be made when RTOS.LockHeap has > been called, based on the dependency between LockHeap and SuspendOthers > in the ThreadPThread implementation. I could fix this by adding the > necessary calls to SuspendOthers (since LockHeap is re-entrant), but > would like you to confirm that the following change "works" (even > though a lock really is the correct way to go): > > PROCEDURE Txt (t: TEXT) = > BEGIN > RTOS.LockHeap(); > ThreadF.SuspendOthers (); > RTIO.PutText (t); > ThreadF.ResumeOthers (); > RTOS.UnlockHeap(); > END Txt; Though it sounds very convincing, it cannot be completely right: I've run the test three times with mutual exclusion as suggested, and it crashed at three different counts, but never completed :-/ Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Jan 10 02:02:38 2008 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Wed, 9 Jan 2008 20:02:38 -0500 Subject: [M3devel] nt386gnu is posix or win32? In-Reply-To: References: <20080107073815.DBCDD10D45C8@birch.elegosoft.com> <4F88D761-5F3F-4891-B3BD-7490FC7E7A2A@cs.purdue.edu> Message-ID: <20080110010238.GA3891@topoi.pooq.com> On Wed, Jan 09, 2008 at 11:08:57PM +0000, Jay wrote: > I'm going to be rude and just throw this out there at a time when I probably can't discuss it or yet have enough data/diffs to matter. > > However, in building NT386GNU -- I can build libm3 and m3core -- the question arises as to if this target is "win32" or "posix'. > Currently in the tree it is setup to be "posix", with a fair amount of work already done in that direction -- in particular, the Unix interfaces. > > However, I think this target is potentially an odd beast. Potentially it is two targets. > I guess this mimics cygwin vs. mingwin. Exactly. > > The "host" is gcc. In order to build this system, one needs "gmake", sh, gcc probably (I'm assuming Visual C++'s compiler/linker cannot build m3cg, but very maybe..). > > In order to build anything with this system, one needs "as", and most likely ld. > (I quote "as" because it is an English word and confusing to read otherwise.) > Changing it to output assembly for masm or even Visual C++'s inline __asm is probably actually viable, but not a tiny short term task. > (Or maybe writing an as clone that outputs .objs? Maybe using nasm/yasm??? Not sure the point, maybe "as" is perfectly ok.) > > And then the question arises as to what it takes to run the output. > As I've said in other topics, the C runtime dependency of Modula-3 is light -- startup code mainly, but, yeah, also important setjmp/longjmp, and multiplication/division helpers sometimes. This could perhaps all be statically linked. Certainly for Visual C++ it can be. > (NOTE: The Cygwin jmp_buf is much larger than Visual C++'s. A THOUGHT is to grow them to the same, for object code compatibility, but probably not useful, and very wasteful, Cygwin's is much larger, the data in the existing code I verified is correct, like 0x40 vs. 0xD0 I think it was, I just did printf("%x", sizeof(jmp_buf)).) > > To get m3core to build, I switched NT386GNU to use Win32 threads. > For THAT to build, I switched OSTYPE to Win32. Overkill perhaps, in order to get the Win32 *.i3 files. > Overkill perhaps, but it does build. > > I fully suspect that old style Posix threads can work easily, and that pthreads can work easily, increasing the dependency on cygwin1.dll. > While this is the "other" direction, given the dependency on as, and gcc to build m3cg, probably the horse is out of the barn. > This is arguably a simpler answer, less hybrid. > > I think the analogy to cygwin/mingwin holds, possibly perfectly. > > Maybe this is two targets. > NT386CYGWIN ? > NT386MINGWIN ? > > (Which begs the point -- target naming.... NT386 vs. PPC_LINUX...OS+ARCH vs. ARCH + _ + OS, etc... but ARCH and OS aren't it, there is toolchain and C runtime in the mix..) > > Obviously SOMETHING is better than NOTHING and I have no useful binary distribution yet to show, so these questions are all very premature. > > I'm also unsure as to the "seriousness" of using the GNU tools. > a) There don't seem to be many users of Modula-3 on Win32. > b) Will such users accept/trust a non Microsoft toolchain? > (Just what to do folks do with cygwin/mingwin? Build/ship real software?) One of my reasons for using m3 long ago was that I could write programs that would run on both Linux and Windows *without* using the Microsoft tools, which I did not possess. -- hendrik From darko at darko.org Thu Jan 10 02:24:42 2008 From: darko at darko.org (Darko) Date: Wed, 9 Jan 2008 17:24:42 -0800 Subject: [M3devel] nt386gnu is posix or win32? In-Reply-To: References: <20080107073815.DBCDD10D45C8@birch.elegosoft.com> <4F88D761-5F3F-4891-B3BD-7490FC7E7A2A@cs.purdue.edu> Message-ID: <6B5887DD-C4CA-4A5F-9814-C59F9B5DCD87@darko.org> On 09/01/2008, at 3:08 PM, Jay wrote: > a) There don't seem to be many users of Modula-3 on Win32. > b) Will such users accept/trust a non Microsoft toolchain? I think there are as many users as any other CM3 platform. It's an important platform, so it should be supported for that reason I think. Being able to use the GCC back end is very useful. I'm not sure what your exact criteria for 'seriousness' is though. I'd like to see MinGW supported because of better performance and the permissive licence. Implementation issues aside, I don't see the point of loading up all the Cygwin junk onto Windows to make it look like Posix. Darko. From darko at darko.org Thu Jan 10 02:25:31 2008 From: darko at darko.org (Darko) Date: Wed, 9 Jan 2008 17:25:31 -0800 Subject: [M3devel] nt386gnu is posix or win32? In-Reply-To: <20080110010238.GA3891@topoi.pooq.com> References: <20080107073815.DBCDD10D45C8@birch.elegosoft.com> <4F88D761-5F3F-4891-B3BD-7490FC7E7A2A@cs.purdue.edu> <20080110010238.GA3891@topoi.pooq.com> Message-ID: On 09/01/2008, at 5:02 PM, hendrik at topoi.pooq.com wrote: > > One of my reasons for using m3 long ago was that I could write > programs > that would run on both Linux and Windows *without* using the Microsoft > tools, which I did not possess. > > -- hendrik There are free versions of the tools these days, if that makes any difference. Darko. From mika at async.caltech.edu Thu Jan 10 02:31:25 2008 From: mika at async.caltech.edu (Mika Nystrom) Date: Wed, 09 Jan 2008 17:31:25 -0800 Subject: [M3devel] nt386gnu is posix or win32? In-Reply-To: Your message of "Wed, 09 Jan 2008 17:25:31 PST." Message-ID: <200801100131.m0A1VQYS034516@camembert.async.caltech.edu> In this vein, I can tell you I am a frequent user of Modula-3 on Windows. I use PM3/Klagenfurt on a Win 2003 Server system, and occasionally on XP and Win2k. I use it this way because while I develop on Unix, I have users who insist on using Windows for their servers. What matters to me is that I can get an environment that (a) runs decently fast on Windows (b) looks as much as possible like Unix (also from the user point of view) (c) requires minimal code changes The combination of Cygwin and M3 takes care of this, more or less... It's also an easy download/install. Mika Darko writes: > >On 09/01/2008, at 5:02 PM, hendrik at topoi.pooq.com wrote: >> >> One of my reasons for using m3 long ago was that I could write >> programs >> that would run on both Linux and Windows *without* using the Microsoft >> tools, which I did not possess. >> >> -- hendrik > > >There are free versions of the tools these days, if that makes any >difference. > >Darko. From jayk123 at hotmail.com Thu Jan 10 08:11:11 2008 From: jayk123 at hotmail.com (Jay) Date: Thu, 10 Jan 2008 07:11:11 +0000 Subject: [M3devel] bad code on PPC_LINUX? Message-ID: Something is screwy I think. My gdb skills are um not good. On PPC_LINUX. /dev2/cm3/m3-sys/cm3/src/Utils.m3 PROCEDURE WriteFile (file: TEXT; proc: Emitter; append := FALSE) = VAR wr: Wr.T; BEGIN IF (append) THEN wr := AppendWriter (file, fatal := TRUE); ELSE wr := OpenWriter (file, fatal := TRUE); END; TRY (* line 78 *) TRY proc (wr); EXCEPT | Wr.Failure (ec) => Msg.FatalError (ec, "write failed on ", file); | Thread.Alerted => Msg.FatalError (NIL, "interrupted while writing ", file); END; FINALLY CloseWriter (wr, file); END; END WriteFile; I get a SEGV on line 78. I'm willing to believe, sadly, that some of these huge offsets are the price of TRY and saving the register context on anything other than x86 (for registers that aren't even used by the function?), however it crashes just after the call and notice there the huge 32k offset. And really? A 720 byte frame for any function with a TRY on PowerPC? Really? I guess I should look at what PPC_DARWIN does. If someone can give me a quick run down on PowerPC ABI, thanks. I'll search the web. Or maybe check my Mac docs. register 0 is 0 or general purpose? Stack is register ? I know that return address is in the link register. bl is branch and link -- call -- jump and save pc in link register. The code is: (gdb) disassemble Dump of assembler code for function Utils__WriteFile: 0x10024fbc : stwu r1,-720(r1) 0x10024fc0 : mflr r0 0x10024fc4 : mfcr r12 0x10024fc8 : stfd f14,576(r1) 0x10024fcc : stfd f15,584(r1) 0x10024fd0 : stfd f16,592(r1) 0x10024fd4 : stfd f17,600(r1) 0x10024fd8 : stfd f18,608(r1) 0x10024fdc : stfd f19,616(r1) 0x10024fe0 : stfd f20,624(r1) 0x10024fe4 : stfd f21,632(r1) 0x10024fe8 : stfd f22,640(r1) 0x10024fec : stfd f23,648(r1) 0x10024ff0 : stfd f24,656(r1) 0x10024ff4 : stfd f25,664(r1) 0x10024ff8 : stfd f26,672(r1) 0x10024ffc : stfd f27,680(r1) 0x10025000 : stfd f28,688(r1) 0x10025004 : stfd f29,696(r1) 0x10025008 : stfd f30,704(r1) 0x1002500c : stfd f31,712(r1) 0x10025010 : stw r14,504(r1) 0x10025014 : stw r15,508(r1) 0x10025018 : stw r16,512(r1) 0x1002501c : stw r17,516(r1) 0x10025020 : stw r18,520(r1) 0x10025024 : stw r19,524(r1) 0x10025028 : stw r20,528(r1) 0x1002502c : stw r21,532(r1) ---Type to continue, or q to quit--- 0x10025030 : stw r22,536(r1) 0x10025034 : stw r23,540(r1) 0x10025038 : stw r24,544(r1) 0x1002503c : stw r25,548(r1) 0x10025040 : stw r26,552(r1) 0x10025044 : stw r27,556(r1) 0x10025048 : stw r28,560(r1) 0x1002504c : stw r29,564(r1) 0x10025050 : stw r30,568(r1) 0x10025054 : stw r31,572(r1) 0x10025058 : stw r0,724(r1) 0x1002505c : stw r12,500(r1) 0x10025060 : mr r31,r1 0x10025064 : bl 0x10025068 0x10025068 : mflr r30 0x1002506c : lwz r0,-176(r30) 0x10025070 : add r30,r0,r30 0x10025074 : stw r3,8(r31) 0x10025078 : stw r4,12(r31) 0x1002507c : mr r0,r5 0x10025080 : stb r0,16(r31) 0x10025084 : li r0,0 0x10025088 : stw r0,20(r31) 0x1002508c : lbz r0,16(r31) 0x10025090 : clrlwi r0,r0,24 0x10025094 : cmpwi r0,0 0x10025098 : beq- 0x100250b8 0x1002509c : lwz r3,8(r31) 0x100250a0 : li r4,1 0x100250a4 : bl 0x100248a4 ---Type to continue, or q to quit--- 0x100250a8 : stw r3,476(r31) 0x100250ac : lwz r9,476(r31) 0x100250b0 : stw r9,20(r31) 0x100250b4 : b 0x100250d0 0x100250b8 : lwz r3,8(r31) 0x100250bc : li r4,1 0x100250c0 : bl 0x10024658 0x100250c4 : stw r3,476(r31) 0x100250c8 : lwz r9,476(r31) 0x100250cc : stw r9,20(r31) ** here I believe ** 0x100250d0 : lwz r0,-32760(r30) 0x100250d4 : stw r0,32(r31) 0x100250d8 : addi r0,r31,8 0x100250dc : stw r0,36(r31) 0x100250e0 : li r0,3 0x100250e4 : stw r0,28(r31) 0x100250e8 : lwz r9,-32764(r30) 0x100250ec : lwz r0,0(r9) 0x100250f0 : stw r0,24(r31) 0x100250f4 : lwz r9,-32764(r30) 0x100250f8 : addi r0,r31,24 0x100250fc : stw r0,0(r9) 0x10025100 : lwz r9,-32768(r30) 0x10025104 : addi r0,r9,76 0x10025108 : stw r0,64(r31) 0x1002510c : li r0,0 0x10025110 : stw r0,60(r31) 0x10025114 : lwz r9,-32764(r30) 0x10025118 : lwz r0,0(r9) 0x1002511c : stw r0,56(r31) ---Type to continue, or q to quit--- 0x10025120 : lwz r9,-32764(r30) 0x10025124 : addi r0,r31,56 0x10025128 : stw r0,0(r9) 0x1002512c : addi r9,r31,56 0x10025130 : addi r0,r9,48 0x10025134 : mr r3,r0 0x10025138 : bl 0x101bbf28 0x1002513c : mr r0,r3 0x10025140 : cmpwi r0,0 0x10025144 : bne- 0x100251ac 0x10025148 : lwz r9,12(r31) 0x1002514c : stw r9,476(r31) 0x10025150 : lwz r9,476(r31) 0x10025154 : cmpwi r9,0 0x10025158 : beq- 0x10025188 0x1002515c : lwz r9,476(r31) 0x10025160 : lwz r0,0(r9) 0x10025164 : li r9,-1 0x10025168 : cmpw r0,r9 0x1002516c : bne- 0x10025188 0x10025170 : lwz r9,476(r31) 0x10025174 : lwz r9,8(r9) 0x10025178 : stw r9,480(r31) 0x1002517c : lwz r9,476(r31) 0x10025180 : lwz r9,4(r9) 0x10025184 : stw r9,476(r31) 0x10025188 : lwz r11,480(r31) 0x1002518c : lwz r3,20(r31) 0x10025190 : lwz r0,476(r31) 0x10025194 : mtlr r0 ---Type to continue, or q to quit--- 0x10025198 : blrl 0x1002519c : lwz r9,-32764(r30) 0x100251a0 : lwz r0,56(r31) 0x100251a4 : stw r0,0(r9) 0x100251a8 : b 0x10025210 0x100251ac : lwz r9,68(r31) 0x100251b0 : lwz r9,0(r9) 0x100251b4 : lis r0,-15535 0x100251b8 : ori r0,r0,42454 0x100251bc : cmpw r9,r0 0x100251c0 : bne- 0x100251f0 0x100251c4 : lwz r0,72(r31) 0x100251c8 : stw r0,472(r31) 0x100251cc : lwz r9,-32768(r30) 0x100251d0 : addi r0,r9,180 0x100251d4 : lwz r3,472(r31) 0x100251d8 : mr r4,r0 0x100251dc : lwz r5,8(r31) 0x100251e0 : li r6,0 0x100251e4 : li r7,0 0x100251e8 : bl 0x10023b4c 0x100251ec : b 0x10025210 0x100251f0 : lwz r9,-32768(r30) 0x100251f4 : addi r0,r9,212 0x100251f8 : li r3,0 0x100251fc : mr r4,r0 0x10025200 : lwz r5,8(r31) 0x10025204 : li r6,0 0x10025208 : li r7,0 0x1002520c : bl 0x10023b4c ---Type to continue, or q to quit--- 0x10025210 : lwz r9,-32764(r30) 0x10025214 : lwz r0,24(r31) 0x10025218 : stw r0,0(r9) 0x1002521c : addi r11,r31,8 0x10025220 : bl 0x10024f74 0x10025224 : lwz r11,0(r1) 0x10025228 : lwz r0,4(r11) 0x1002522c : lwz r12,-220(r11) 0x10025230 : mtlr r0 0x10025234 : lwz r14,-216(r11) 0x10025238 : lwz r15,-212(r11) 0x1002523c : lwz r16,-208(r11) 0x10025240 : lwz r17,-204(r11) 0x10025244 : lwz r18,-200(r11) 0x10025248 : lwz r19,-196(r11) 0x1002524c : lwz r20,-192(r11) 0x10025250 : lwz r21,-188(r11) 0x10025254 : lwz r22,-184(r11) 0x10025258 : lwz r23,-180(r11) 0x1002525c : lwz r24,-176(r11) 0x10025260 : lwz r25,-172(r11) 0x10025264 : lwz r26,-168(r11) 0x10025268 : lwz r27,-164(r11) 0x1002526c : lwz r28,-160(r11) 0x10025270 : lwz r29,-156(r11) 0x10025274 : lwz r30,-152(r11) 0x10025278 : lwz r31,-148(r11) 0x1002527c : lfd f14,-144(r11) 0x10025280 : lfd f15,-136(r11) 0x10025284 : lfd f16,-128(r11) ---Type to continue, or q to quit--- 0x10025288 : lfd f17,-120(r11) 0x1002528c : lfd f18,-112(r11) 0x10025290 : lfd f19,-104(r11) 0x10025294 : lfd f20,-96(r11) 0x10025298 : lfd f21,-88(r11) 0x1002529c : lfd f22,-80(r11) 0x100252a0 : lfd f23,-72(r11) 0x100252a4 : lfd f24,-64(r11) 0x100252a8 : lfd f25,-56(r11) 0x100252ac : lfd f26,-48(r11) 0x100252b0 : lfd f27,-40(r11) 0x100252b4 : lfd f28,-32(r11) 0x100252b8 : lfd f29,-24(r11) 0x100252bc : lfd f30,-16(r11) 0x100252c0 : lfd f31,-8(r11) 0x100252c4 : mtcrf 56,r12 0x100252c8 : mr r1,r11 0x100252cc : blr 0x100252d0 : .long 0x24ebb0 End of assembler dump. (gdb) bt #0 Utils__WriteFile (M3_Bd56fi_file=0x10277ba0, M3_DmuccK_proc=0x7fb22210, M3_AicXUJ_append=0 '\0') at Utils.m3:78 #1 0x10020a10 in Makefile__Build (M3_Bd56fi_src_dir=0x102720ec) at Makefile.m3:101 #2 0x100292d4 in Main__DoIt () at Main.m3:71 #3 0x10029834 in Main_M3 (M3_AcxOUs_mode=1) at Main.m3:193 #4 0x10188f9c in RTLinker__RunMainBody (M3_DUuepq_m=0x10279b28) at RTLinker.m3:387 #5 0x101880bc in RTLinker__AddUnitI (M3_DUuepq_m=0x10279b28) at RTLinker.m3:100 #6 0x10188198 in RTLinker__AddUnit (M3_DUuepw_b=0x100297f8) at RTLinker.m3:110 #7 0x100002ec in main (argc=1, argv=0x7fb22834, envp=0x7fb2283c) at _m3main.mc:4 I haven't yet figured out how to get gdb to show me the details of the SEGV, like what address was referenced. I swear I think this was working better recently. Oh, I did change something. I will try to change it back. I added -fPIC. Dynamic linking was not working and I thought that might fix it. I'll definitely try without it now. Also, relevant aside -- what, if any, distributions/versions of Linux are people using on PowerPC? Specifically on PowerPC (to limit the religious explosion) I'm currently using Yellow Dog, I think 4.1, but only for Modula-3 purposes, not for anything else. ps: I'd like a SMALL forum of SMART programmers, to discuss GENERAL programming topics. This is it perhaps? - Jay _________________________________________________________________ Watch ?Cause Effect,? a show about real people making a real difference. http://im.live.com/Messenger/IM/MTV/?source=text_watchcause From jayk123 at hotmail.com Thu Jan 10 10:28:31 2008 From: jayk123 at hotmail.com (Jay) Date: Thu, 10 Jan 2008 09:28:31 +0000 Subject: [M3devel] FW: bad code on PPC_LINUX? Message-ID: My emails keep getting truncated for some reason.. :( > From: jayk123 at hotmail.com > To: m3devel at elegosoft.com > Subject: bad code on PPC_LINUX? > Date: Thu, 10 Jan 2008 07:11:11 +0000 > > > Something is screwy I think. > My gdb skills are um not good. > > On PPC_LINUX. > > /dev2/cm3/m3-sys/cm3/src/Utils.m3 > > PROCEDURE WriteFile (file: TEXT; proc: Emitter; append := FALSE) = > VAR wr: Wr.T; > BEGIN > IF (append) > THEN wr := AppendWriter (file, fatal := TRUE); > ELSE wr := OpenWriter (file, fatal := TRUE); > END; > TRY (* line 78 *) > TRY > proc (wr); > EXCEPT > | Wr.Failure (ec) => > Msg.FatalError (ec, "write failed on ", file); > | Thread.Alerted => > Msg.FatalError (NIL, "interrupted while writing ", file); > END; > FINALLY > CloseWriter (wr, file); > END; > END WriteFile; > > I get a SEGV on line 78. > > I'm willing to believe, sadly, that some of these huge offsets > are the price of TRY and saving the register context on anything > other than x86 (for registers that aren't even used by the function?), > however it crashes just after the call and notice there the huge 32k offset. > > And really? A 720 byte frame for any function with a TRY on PowerPC? > Really? > I guess I should look at what PPC_DARWIN does. > > If someone can give me a quick run down on PowerPC ABI, thanks. > I'll search the web. Or maybe check my Mac docs. > register 0 is 0 or general purpose? > Stack is register ? > I know that return address is in the link register. > bl is branch and link -- call -- jump and save pc in link register. > > The code is: > (gdb) disassemble > Dump of assembler code for function Utils__WriteFile: > 0x10024fbc : stwu r1,-720(r1) > 0x10024fc0 : mflr r0 > 0x10024fc4 : mfcr r12 > 0x10024fc8 : stfd f14,576(r1) > 0x10024fcc : stfd f15,584(r1) > 0x10024fd0 : stfd f16,592(r1) > 0x10024fd4 : stfd f17,600(r1) > 0x10024fd8 : stfd f18,608(r1) > 0x10024fdc : stfd f19,616(r1) > 0x10024fe0 : stfd f20,624(r1) > 0x10024fe4 : stfd f21,632(r1) > 0x10024fe8 : stfd f22,640(r1) > 0x10024fec : stfd f23,648(r1) > 0x10024ff0 : stfd f24,656(r1) > 0x10024ff4 : stfd f25,664(r1) > 0x10024ff8 : stfd f26,672(r1) > 0x10024ffc : stfd f27,680(r1) > 0x10025000 : stfd f28,688(r1) > 0x10025004 : stfd f29,696(r1) > 0x10025008 : stfd f30,704(r1) > 0x1002500c : stfd f31,712(r1) > 0x10025010 : stw r14,504(r1) > 0x10025014 : stw r15,508(r1) > 0x10025018 : stw r16,512(r1) > 0x1002501c : stw r17,516(r1) > 0x10025020 : stw r18,520(r1) > 0x10025024 : stw r19,524(r1) > 0x10025028 : stw r20,528(r1) > 0x1002502c : stw r21,532(r1) > ---Type to continue, or q to quit--- > 0x10025030 : stw r22,536(r1) > 0x10025034 : stw r23,540(r1) > 0x10025038 : stw r24,544(r1) > 0x1002503c : stw r25,548(r1) > 0x10025040 : stw r26,552(r1) > 0x10025044 : stw r27,556(r1) > 0x10025048 : stw r28,560(r1) > 0x1002504c : stw r29,564(r1) > 0x10025050 : stw r30,568(r1) > 0x10025054 : stw r31,572(r1) > 0x10025058 : stw r0,724(r1) > 0x1002505c : stw r12,500(r1) > 0x10025060 : mr r31,r1 > 0x10025064 : bl 0x10025068 > 0x10025068 : mflr r30 > 0x1002506c : lwz r0,-176(r30) > 0x10025070 : add r30,r0,r30 > 0x10025074 : stw r3,8(r31) > 0x10025078 : stw r4,12(r31) > 0x1002507c : mr r0,r5 > 0x10025080 : stb r0,16(r31) > 0x10025084 : li r0,0 > 0x10025088 : stw r0,20(r31) > 0x1002508c : lbz r0,16(r31) > 0x10025090 : clrlwi r0,r0,24 > 0x10025094 : cmpwi r0,0 > 0x10025098 : beq- 0x100250b8 > 0x1002509c : lwz r3,8(r31) > 0x100250a0 : li r4,1 > 0x100250a4 : bl 0x100248a4 > ---Type to continue, or q to quit--- > 0x100250a8 : stw r3,476(r31) > 0x100250ac : lwz r9,476(r31) > 0x100250b0 : stw r9,20(r31) > 0x100250b4 : b 0x100250d0 > 0x100250b8 : lwz r3,8(r31) > 0x100250bc : li r4,1 > 0x100250c0 : bl 0x10024658 > 0x100250c4 : stw r3,476(r31) > 0x100250c8 : lwz r9,476(r31) > 0x100250cc : stw r9,20(r31) > > ** here I believe ** > > 0x100250d0 : lwz r0,-32760(r30) > 0x100250d4 : stw r0,32(r31) > 0x100250d8 : addi r0,r31,8 > 0x100250dc : stw r0,36(r31) > 0x100250e0 : li r0,3 > 0x100250e4 : stw r0,28(r31) > 0x100250e8 : lwz r9,-32764(r30) > 0x100250ec : lwz r0,0(r9) > 0x100250f0 : stw r0,24(r31) > 0x100250f4 : lwz r9,-32764(r30) > 0x100250f8 : addi r0,r31,24 > 0x100250fc : stw r0,0(r9) > 0x10025100 : lwz r9,-32768(r30) > 0x10025104 : addi r0,r9,76 > 0x10025108 : stw r0,64(r31) > 0x1002510c : li r0,0 > 0x10025110 : stw r0,60(r31) > 0x10025114 : lwz r9,-32764(r30) > 0x10025118 : lwz r0,0(r9) > 0x1002511c : stw r0,56(r31) > ---Type to continue, or q to quit--- > 0x10025120 : lwz r9,-32764(r30) > 0x10025124 : addi r0,r31,56 > 0x10025128 : stw r0,0(r9) > 0x1002512c : addi r9,r31,56 > 0x10025130 : addi r0,r9,48 > 0x10025134 : mr r3,r0 > 0x10025138 : bl 0x101bbf28 > 0x1002513c : mr r0,r3 > 0x10025140 : cmpwi r0,0 > 0x10025144 : bne- 0x100251ac > 0x10025148 : lwz r9,12(r31) > 0x1002514c : stw r9,476(r31) > 0x10025150 : lwz r9,476(r31) > 0x10025154 : cmpwi r9,0 > 0x10025158 : beq- 0x10025188 > 0x1002515c : lwz r9,476(r31) > 0x10025160 : lwz r0,0(r9) > 0x10025164 : li r9,-1 > 0x10025168 : cmpw r0,r9 > 0x1002516c : bne- 0x10025188 > 0x10025170 : lwz r9,476(r31) > 0x10025174 : lwz r9,8(r9) > 0x10025178 : stw r9,480(r31) > 0x1002517c : lwz r9,476(r31) > 0x10025180 : lwz r9,4(r9) > 0x10025184 : stw r9,476(r31) > 0x10025188 : lwz r11,480(r31) > 0x1002518c : lwz r3,20(r31) > 0x10025190 : lwz r0,476(r31) > 0x10025194 : mtlr r0 > ---Type to continue, or q to quit--- > 0x10025198 : blrl > 0x1002519c : lwz r9,-32764(r30) > 0x100251a0 : lwz r0,56(r31) > 0x100251a4 : stw r0,0(r9) > 0x100251a8 : b 0x10025210 > 0x100251ac : lwz r9,68(r31) > 0x100251b0 : lwz r9,0(r9) > 0x100251b4 : lis r0,-15535 > 0x100251b8 : ori r0,r0,42454 > 0x100251bc : cmpw r9,r0 > 0x100251c0 : bne- 0x100251f0 > 0x100251c4 : lwz r0,72(r31) > 0x100251c8 : stw r0,472(r31) > 0x100251cc : lwz r9,-32768(r30) > 0x100251d0 : addi r0,r9,180 > 0x100251d4 : lwz r3,472(r31) > 0x100251d8 : mr r4,r0 > 0x100251dc : lwz r5,8(r31) > 0x100251e0 : li r6,0 > 0x100251e4 : li r7,0 > 0x100251e8 : bl 0x10023b4c > 0x100251ec : b 0x10025210 > 0x100251f0 : lwz r9,-32768(r30) > 0x100251f4 : addi r0,r9,212 > 0x100251f8 : li r3,0 > 0x100251fc : mr r4,r0 > 0x10025200 : lwz r5,8(r31) > 0x10025204 : li r6,0 > 0x10025208 : li r7,0 > 0x1002520c : bl 0x10023b4c > ---Type to continue, or q to quit--- > 0x10025210 : lwz r9,-32764(r30) > 0x10025214 : lwz r0,24(r31) > 0x10025218 : stw r0,0(r9) > 0x1002521c : addi r11,r31,8 > 0x10025220 : bl 0x10024f74 > 0x10025224 : lwz r11,0(r1) > 0x10025228 : lwz r0,4(r11) > 0x1002522c : lwz r12,-220(r11) > 0x10025230 : mtlr r0 > 0x10025234 : lwz r14,-216(r11) > 0x10025238 : lwz r15,-212(r11) > 0x1002523c : lwz r16,-208(r11) > 0x10025240 : lwz r17,-204(r11) > 0x10025244 : lwz r18,-200(r11) > 0x10025248 : lwz r19,-196(r11) > 0x1002524c : lwz r20,-192(r11) > 0x10025250 : lwz r21,-188(r11) > 0x10025254 : lwz r22,-184(r11) > 0x10025258 : lwz r23,-180(r11) > 0x1002525c : lwz r24,-176(r11) > 0x10025260 : lwz r25,-172(r11) > 0x10025264 : lwz r26,-168(r11) > 0x10025268 : lwz r27,-164(r11) > 0x1002526c : lwz r28,-160(r11) > 0x10025270 : lwz r29,-156(r11) > 0x10025274 : lwz r30,-152(r11) > 0x10025278 : lwz r31,-148(r11) > 0x1002527c : lfd f14,-144(r11) > 0x10025280 : lfd f15,-136(r11) > 0x10025284 : lfd f16,-128(r11) > ---Type to continue, or q to quit--- > 0x10025288 : lfd f17,-120(r11) > 0x1002528c : lfd f18,-112(r11) > 0x10025290 : lfd f19,-104(r11) > 0x10025294 : lfd f20,-96(r11) > 0x10025298 : lfd f21,-88(r11) > 0x1002529c : lfd f22,-80(r11) > 0x100252a0 : lfd f23,-72(r11) > 0x100252a4 : lfd f24,-64(r11) > 0x100252a8 : lfd f25,-56(r11) > 0x100252ac : lfd f26,-48(r11) > 0x100252b0 : lfd f27,-40(r11) > 0x100252b4 : lfd f28,-32(r11) > 0x100252b8 : lfd f29,-24(r11) > 0x100252bc : lfd f30,-16(r11) > 0x100252c0 : lfd f31,-8(r11) > 0x100252c4 : mtcrf 56,r12 > 0x100252c8 : mr r1,r11 > 0x100252cc : blr > 0x100252d0 : .long 0x24ebb0 > End of assembler dump. > > > (gdb) bt > #0 Utils__WriteFile (M3_Bd56fi_file=0x10277ba0, M3_DmuccK_proc=0x7fb22210, > M3_AicXUJ_append=0 '\0') at Utils.m3:78 > #1 0x10020a10 in Makefile__Build (M3_Bd56fi_src_dir=0x102720ec) > at Makefile.m3:101 > #2 0x100292d4 in Main__DoIt () at Main.m3:71 > #3 0x10029834 in Main_M3 (M3_AcxOUs_mode=1) at Main.m3:193 > #4 0x10188f9c in RTLinker__RunMainBody (M3_DUuepq_m=0x10279b28) > at RTLinker.m3:387 > #5 0x101880bc in RTLinker__AddUnitI (M3_DUuepq_m=0x10279b28) at RTLinker.m3:100 > #6 0x10188198 in RTLinker__AddUnit (M3_DUuepw_b=0x100297f8) at RTLinker.m3:110 > #7 0x100002ec in main (argc=1, argv=0x7fb22834, envp=0x7fb2283c) at _m3main.mc:4 > > I haven't yet figured out how to get gdb to show me the details of the SEGV, like what address was referenced. > > I swear I think this was working better recently. > > Oh, I did change something. I will try to change it back. > I added -fPIC. > Dynamic linking was not working and I thought that might fix it. > I'll definitely try without it now. > > Also, relevant aside -- what, if any, distributions/versions of Linux are people using on PowerPC? > Specifically on PowerPC (to limit the religious explosion) > I'm currently using Yellow Dog, I think 4.1, but only for Modula-3 purposes, not for anything else. > > ps: I'd like a SMALL forum of SMART programmers, to discuss GENERAL programming topics. > This is it perhaps? > > - Jay > _________________________________________________________________ > Watch ?Cause Effect,? a show about real people making a real difference. > http://im.live.com/Messenger/IM/MTV/?source=text_watchcause _________________________________________________________________ Make distant family not so distant with Windows Vista? + Windows Live?. http://www.microsoft.com/windows/digitallife/keepintouch.mspx?ocid=TXT_TAGLM_CPC_VideoChat_distantfamily_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Thu Jan 10 12:16:36 2008 From: jayk123 at hotmail.com (Jay) Date: Thu, 10 Jan 2008 11:16:36 +0000 Subject: [M3devel] nt386gnu is posix or win32? In-Reply-To: <200801100131.m0A1VQYS034516@camembert.async.caltech.edu> References: Your message of "Wed, 09 Jan 2008 17:25:31 PST." <200801100131.m0A1VQYS034516@camembert.async.caltech.edu> Message-ID: clarification/additional info Whatever MinGWin I have installed, is via the GPL Qt download. I did not realize MinGWin had the "MSYS" component -- sh, make, etc., enough for autoconf. Enough for gcc? http://www.mingw.org/mingwfaq.shtml#faq-usingwithmsys "How do I use MinGW with Cygwin?For those who would like to use the Cygwin environment for development, yet generatenon-Cygwin-dependant executables, a much easier option to "-mno-cygwin" does exist.Simply install Cygwin and the MinGW distribution in seperate directories (i.e. "C:\CYGWIN"and "C:\MINGW"), and make sure that the "/bin" subdirectory beneath your MinGW installationcomes before Cygwin's "/bin" subdirectory in your PATH environment variable(i.e. "PATH=%PATH%;C:\MINGW\BIN;C:\CYGWIN\BIN"). This will allow you accessto all the UNIX tools you want, while ensuring that the instance of GCC used is the MinGW version." Sounds good.So a possibly good easy answer is just one target -- "NT386GNU" configured probably always as I have it currently -- Win32 threads maybe a cm3 command line define, like -DPTHREAD to use pthreads, will require a tiny bit of work heck, maybe -DUSERTHREAD (and for other systems?) jmpbuf asis -- 0xd0 and will work linked either way. Whether or not mingw works alone, is to be determined.It probably does if not building m3cc, and it may very well even for building m3cc. Among those goals: (a) runs decently fast on Windows (b) looks as much as possible like Unix (also from the user point of view) (c) requires minimal code changes These are related and to some extent help each other, and to some extentare independent. In particular, the theory is, you get #c without requiring #b.Regarding #a, well, it's a question of one or two layers.Modula-3 already provides in many places, but certainly not all, a portability layer.And then another cygwin/posix portability layer? Maybe.These aren't necessarily thick layers and if your code is i/o bound anyway, doesn't matter. (While I'm sure it wasn't intended, "runs fast" can be interpreted as "fast to get it to run",as in ease of development/porting. :) ) Anyway, it seems like both camps (all camps?) can be satisfied. By "serious" I mean, "ship real software using it".Oh and the reference to "toolchains" was dodgy.Already Modula-3 on Windows involves an unusual codegenerator, though still a "normal" linker. - Jay..waiting for m3cc to build again as part of upgrade.sh...(my excuse for wasting time in email..) > To: darko at darko.org> Date: Wed, 9 Jan 2008 17:31:25 -0800> From: mika at async.caltech.edu> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] nt386gnu is posix or win32?> > > In this vein, I can tell you I am a frequent user of Modula-3 on Windows.> I use PM3/Klagenfurt on a Win 2003 Server system, and occasionally on XP and> Win2k.> > I use it this way because while I develop on Unix, I have users who insist on> using Windows for their servers. What matters to me is that I can get an> environment that> > (a) runs decently fast on Windows> (b) looks as much as possible like Unix (also from the user point of view)> (c) requires minimal code changes> > The combination of Cygwin and M3 takes care of this, more or less... It's> also an easy download/install.> > Mika> > > Darko writes:> >> >On 09/01/2008, at 5:02 PM, hendrik at topoi.pooq.com wrote:> >>> >> One of my reasons for using m3 long ago was that I could write > >> programs> >> that would run on both Linux and Windows *without* using the Microsoft> >> tools, which I did not possess.> >>> >> -- hendrik> >> >> >There are free versions of the tools these days, if that makes any > >difference.> >> >Darko. _________________________________________________________________ Put your friends on the big screen with Windows Vista? + Windows Live?. http://www.microsoft.com/windows/shop/specialoffers.mspx?ocid=TXT_TAGLM_CPC_MediaCtr_bigscreen_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Thu Jan 10 12:20:20 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 10 Jan 2008 12:20:20 +0100 Subject: [M3devel] (Offtopic) Some comments on SCM tools, was: Re: M3 concerns In-Reply-To: <20080105191243.GB6402@topoi.pooq.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> <20080105191243.GB6402@topoi.pooq.com> Message-ID: <20080110122020.zm4wc29e8044c0kw@mail.elegosoft.com> Quoting hendrik at topoi.pooq.com: > But if you have this experience, it would be useful to see a rundown > of the advantages and disadvantages of each. I've seen a table of > features against version control systems, but it doesn't give any feel > for what it's like to use them. > > Such an essay would be useful for those involved in other projects. It > probably won't help Modula 3 itself. That would easily become an open-ended task :-) It is not easy to compare different complex tools like SCM systems, which interact in various degrees with process control, workflow management, problem management, project management, general policies... We've tried to provide feature-oriented comparison lists some years ago, but even this needs too much efforts and is too fast out-of-date. There are some aspects that may currently be helpful as criterions though. I'd like to mention some of them o Traditionally, version control tools were centralized server systems. There is one central repository (which can in advanced setups be replicated to several sites for many systems. Replicas may even be partly writable. In case of replication there is one `logical' central repository which is physically distributed.). Systems in this group are CVS, ClearCase, PVCS, AccuRev, Perforce, Subversion, and many others. In recent years, peer-to-peer systems have become popular, because they correspond better to certain aspects of open software projects and are inherently distributed. There is no distinction between workspace and repository, and each workspace holds a partial or complete change history. Such systems are BitKeeper, git, Darcs, and others. As far as I know, these systems are not very popular in the commercial world (yet?). o An orthogonal criterion is the range of functionality that is addressed with the solution. Simple systems like CVS and Perforce do just version control and offer some hooks for further integration. On the other side are process-oriented systems like PVCS Dimensions or a complete ClearCase/ClearQuest setup for RUP. These systems are rather based on change management und workflow than on developer needs. Basic abstractions are baselines, changesets, tasks, projects, activities, functional roles. Of course, some tools are somewhere in between these extremes, like AccuRev, which supports kinds of long-running transactions for everything, called `streams'. (This one's very nice IMO.) o Then there are the costs of the use of the systems. There are always costs, even for open source solutions. You have to consider - server costs (hardware, energy, OS, database, licences, networks) - administration and maintenance (servers and user setup) - user license costs (from 0 to several thousand dollars per year) - use overhead (depending on tool usability and process) - instruction and training Again there are systems that are rather lightweight in this respect (like CVS and Perforce) and some tending to be more heavyweight (like ClearCase and PVCS). o The `end user experience' corresponds very much to the basic concepts needed in everyday use. File based ci/co is very simple, development lines are more or less a must have, change sets and baselines (like in DCVS, AccuRev or RUP) are very nice; diffs and merges seem to be too complex for many users (but are of course needed); conflict avoidance vs. conflict resolution (locking or optimistic approach) is often a religiously discussed topic. The other important issue here is the IDE integration (at least for developers). These are only some randomly picked topics that would need to be addressed in a useful tool comparison. There are very few situations in which you can evaluate and choose the best tool for your purpose; most of the time, you have to adapt and improve existing setups, as everything else would be too expensive and disrupting. Our company has supported several migration projects recently though, so it's not impossible to change ;-) As for CM3, I'm still of the opinion that there is no need to change the existing CVS infrastructure. > Or might you know of such an essay elsewhere? Well, the more interesting field studies and evaluations are not free; there are quite a lot of interesting articles though. I haven't any links here right now; CM crossroads or a Google search on `configuration management' should be a good starting point. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Jan 10 12:24:20 2008 From: jayk123 at hotmail.com (Jay) Date: Thu, 10 Jan 2008 11:24:20 +0000 Subject: [M3devel] win32 path separators -- support forward and backward in libm3? In-Reply-To: <200801100131.m0A1VQYS034516@camembert.async.caltech.edu> References: Your message of "Wed, 09 Jan 2008 17:25:31 PST." <200801100131.m0A1VQYS034516@camembert.async.caltech.edu> Message-ID: To a very large extent, Win32 accepts both / and \ equally as path delimiters. CreateFile, DeleteFile, CreateDirectory, MoveFile, CopyFile, FindFirstFile, GetFileAttributes, the C runtime wrappers fopen, unlink/remove, stat, etc., those all work either way, or with a mix. "Shell" functions like shlwapi.dll, commdlg32.dll, tend not to. In building NT386GNU, I run into places where cm3 is picking apart paths. For whatever reason, it is being given paths with a mix of forward and backward slashes. I find these paths ugly, but they work ok. I've been able to easily progress by changing m3-libs/libm3/src/os/WIN32/PathnameWin32.m3 to treat forward and backslashes the same. I have not yet rebuilt the normal NT386 target with this change. An ok change? Or go and fix NT386GNU a) to be consistent, b) use backward slashes, c) translate at some place. ? C:\dev2\cm3.2\m3-libs\libm3>cvs diffIndex: src/os/WIN32/PathnameWin32.m3===================================================================RCS file: /usr/cvs/cm3/m3-libs/libm3/src/os/WIN32/PathnameWin32.m3,vretrieving revision 1.3diff -r1.3 PathnameWin32.m313c13< DirSepChar = '\\'; DirSepText = "\\";---> DirSepText = "\\";17c17< CONST Legal = SET OF CHAR {'\001' .. '\177'} - SET OF CHAR {DirSepChar, ':'};---> CONST Legal = SET OF CHAR {'\001' .. '\177'} - SET OF CHAR {'\\', '/', ':', '?', '*'};21a22,26> PROCEDURE IsDirSepChar(ch: CHAR): BOOLEAN => BEGIN> RETURN (ch = '\\' OR ch = '/');> END IsDirSepChar;>53,54c58,59< IF Text.GetChar(t, 0) = DirSepChar AND< Text.GetChar(t, nRoot - 1) # DirSepChar THEN---> IF IsDirSepChar(Text.GetChar(t, 0)) AND> NOT IsDirSepChar(Text.GetChar(t, nRoot - 1)) THEN125c130< IF c # DirSepChar AND c # DriveSepChar THEN---> IF NOT IsDirSepChar(c) AND c # DriveSepChar THEN173,174c178,179< IF c = DirSepChar THEN< IF n = 1 OR Text.GetChar(t, 1) # DirSepChar THEN RETURN 1 END;---> IF IsDirSepChar(c) THEN> IF n = 1 OR NOT IsDirSepChar(Text.GetChar(t, 1)) THEN RETURN 1 END;178c183< IF cc = DirSepChar THEN---> IF IsDirSepChar(cc) THEN196c201< IF n > 2 AND Text.GetChar(t, 2) = DirSepChar THEN RETURN 3 END;---> IF n > 2 AND IsDirSepChar(Text.GetChar(t, 2)) THEN RETURN 3 END;218c223< IF c = DirSepChar THEN---> IF IsDirSepChar(c) THEN253c258< IF ch = DirSepChar OR ch = DriveSepChar THEN---> IF IsDirSepChar(ch) OR ch = DriveSepChar THEN - Jay _________________________________________________________________ Put your friends on the big screen with Windows Vista? + Windows Live?. http://www.microsoft.com/windows/shop/specialoffers.mspx?ocid=TXT_TAGLM_CPC_MediaCtr_bigscreen_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.caltech.edu Thu Jan 10 12:34:47 2008 From: mika at async.caltech.edu (Mika Nystrom) Date: Thu, 10 Jan 2008 03:34:47 -0800 Subject: [M3devel] win32 path separators -- support forward and backward in libm3? In-Reply-To: Your message of "Thu, 10 Jan 2008 11:24:20 GMT." Message-ID: <200801101134.m0ABYl2I053123@camembert.async.caltech.edu> With Cygwin, I think it's pretty much inevitable that you're going to get a mixture of / and \.... (and sometimes it's a real pain, yes). For your "edification", I include the file "README.CYGWIN" that I keep at the root of my software repository... I'm sure this doesn't all apply to CM3, but it's what I deal with to get things running with the Klagenfurt compiler... 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. From jayk123 at hotmail.com Thu Jan 10 13:40:22 2008 From: jayk123 at hotmail.com (Jay) Date: Thu, 10 Jan 2008 12:40:22 +0000 Subject: [M3devel] could someone add __stdcall name mangling to m3cc please? In-Reply-To: <200801100131.m0A1VQYS034516@camembert.async.caltech.edu> References: Your message of "Wed, 09 Jan 2008 17:25:31 PST." <200801100131.m0A1VQYS034516@camembert.async.caltech.edu> Message-ID: Could someone out there (Tony?) familiar with the gcc backendhave it not ignore call_conv and if call_conv is 1, appendan at symbol and the number of bytes of parameters to the function name? (Even for zero, e.g. Sleep at 0, GetFileAttributes at 4).This would be I guess at least for "imported" functions. Not clear about calling function pointers, probably needs modification.call_conv 0 is "__cdecl" is push right to left, caller cleans upcall_conv 1 is "__stdcall" is push right to left, callee cleans up There are various synonyms. With no command line switches, __cdecl is the compiler default. __stdcall is deemed more efficient, and is very widely used. Not clear about functions implemented in Modula-3.Probably won't occur? Maybe for callbacks? WindowProcs, thread entry point? This could/should be for NT386GNU only.The hypothetical other NT targets only have one calling convention each. I COULD do something sleazy here and generate little adapter functions, over in m3-win/import-libs esp. I'm still checking out pm3 to see what it does here.(as in cvs checkout, not "looking at") This'll clear up: RTOS.m3:27: undefined reference to `_FatalExit'RTOS.mo: In function `RTOS__GetMemory':RTOS.m3:75: undefined reference to `_VirtualAlloc'RTOS.m3:85: undefined reference to `_VirtualAlloc'RTOS.mo: In function `RTOS__InitMemory':RTOS.m3:96: undefined reference to `_VirtualAlloc'RTOS.m3:100: undefined reference to `_GetSystemInfo'RTOS.mo: In function `RTOS__Write':RTOS.m3:118: undefined reference to `_AllocConsole'RTOS.m3:119: undefined reference to `_GetStdHandle'RTOS.m3:122: undefined reference to `_WriteFile'RTPerfTool.mo: In function `RTPerfTool__Start':RTPerfTool.m3:19: undefined reference to `_ReadFile'RTPerfTool.m3:22: undefined reference to `_CloseHandle'RTPerfTool.mo: In function `RTPerfTool__Close':RTPerfTool.m3:28: undefined reference to `_CloseHandle'RTPerfTool.mo: In function `RTPerfTool__Send':RTPerfTool.m3:34: undefined reference to `_WriteFile'RTPerfTool.mo: In function `RTPerfTool__PrepHandle':RTPerfTool.m3:58: undefined reference to `_GetCurrentProcess'RTPerfTool.m3:59: undefined reference to `_DuplicateHandle'etc. I did think I was past these. I thought I built m3core and libm3 including linking (having even modified cm3.cfg)COULD be I'm using the wrong .libs, but: C:\cygwin\lib\w32api>nm libkernel32.a | findstr CreateFile00000000 I __imp__CreateFileW at 2800000000 T _CreateFileW at 2800000000 I __imp__CreateFileMappingW at 2400000000 T _CreateFileMappingW at 2400000000 I __imp__CreateFileMappingA at 2400000000 T _CreateFileMappingA at 2400000000 I __imp__CreateFileA at 2800000000 T _CreateFileA at 28 C:\cygwin\lib\w32api>cd \MinGW\lib C:\MinGW\lib>nm libkernel32.a | findstr CreateFile00000000 I __imp__CreateFileW at 2800000000 T _CreateFileW at 2800000000 I __imp__CreateFileMappingW at 2400000000 T _CreateFileMappingW at 2400000000 I __imp__CreateFileMappingA at 2400000000 T _CreateFileMappingA at 2400000000 I __imp__CreateFileA at 2800000000 T _CreateFileA at 28 I think at least THREE calling conventions should be supported -- __cdecl, __stdcall, __fastcall --but oh well. We can live without __fastcall.Watcom has another calling convention, "watcall", and they let you describe calling conventions with #pragmas, neat. Thanks, - Jay _________________________________________________________________ Share life as it happens with the new Windows Live. http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Thu Jan 10 13:42:58 2008 From: jayk123 at hotmail.com (Jay) Date: Thu, 10 Jan 2008 12:42:58 +0000 Subject: [M3devel] could someone add __stdcall name mangling to m3cc please? In-Reply-To: References: Your message of "Wed, 09 Jan 2008 17:25:31 PST." <200801100131.m0A1VQYS034516@camembert.async.caltech.edu> Message-ID: PM3 appears to ignore call_conv. Perhaps its NT386GNU uses usermode threads via cygwin1.dll and has no gui support, such as to not import any __stdcall functions??? http://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/m3/pm3/language/modula3/m3compiler/m3cc/gcc/gcc/m3cg/m3.c?rev=1.1;content-type=text%2Fx-cvsweb-markup;cvsroot=PM3 - Jay From: jayk123 at hotmail.comTo: m3devel at elegosoft.comDate: Thu, 10 Jan 2008 12:40:22 +0000Subject: [M3devel] could someone add __stdcall name mangling to m3cc please? Could someone out there (Tony?) familiar with the gcc backendhave it not ignore call_conv and if call_conv is 1, appendan at symbol and the number of bytes of parameters to the function name? (Even for zero, e.g. Sleep at 0, GetFileAttributes at 4).This would be I guess at least for "imported" functions.Not clear about calling function pointers, probably needs modification.call_conv 0 is "__cdecl" is push right to left, caller cleans upcall_conv 1 is "__stdcall" is push right to left, callee cleans up There are various synonyms. With no command line switches, __cdecl is the compiler default. __stdcall is deemed more efficient, and is very widely used.Not clear about functions implemented in Modula-3.Probably won't occur? Maybe for callbacks? WindowProcs, thread entry point?This could/should be for NT386GNU only.The hypothetical other NT targets only have one calling convention each.I COULD do something sleazy here and generate little adapter functions, over in m3-win/import-libs esp.I'm still checking out pm3 to see what it does here.(as in cvs checkout, not "looking at")This'll clear up:RTOS.m3:27: undefined reference to `_FatalExit'RTOS.mo: In function `RTOS__GetMemory':RTOS.m3:75: undefined reference to `_VirtualAlloc'RTOS.m3:85: undefined reference to `_VirtualAlloc'RTOS.mo: In function `RTOS__InitMemory':RTOS.m3:96: undefined reference to `_VirtualAlloc'RTOS.m3:100: undefined reference to `_GetSystemInfo'RTOS.mo: In function `RTOS__Write':RTOS.m3:118: undefined reference to `_AllocConsole'RTOS.m3:119: undefined reference to `_GetStdHandle'RTOS.m3:122: undefined reference to `_WriteFile'RTPerfTool.mo: In function `RTPerfTool__Start':RTPerfTool.m3:19: undefined reference to `_ReadFile'RTPerfTool.m3:22: undefined reference to `_CloseHandle'RTPerfTool.mo: In function `RTPerfTool__Close':RTPerfTool.m3:28: undefined reference to `_CloseHandle'RTPerfTool.mo: In function `RTPerfTool__Send':RTPerfTool.m3:34: undefined reference to `_WriteFile'RTPerfTool.mo: In function `RTPerfTool__PrepHandle':RTPerfTool.m3:58: undefined reference to `_GetCurrentProcess'RTPerfTool.m3:59: undefined reference to `_DuplicateHandle'etc.I did think I was past these. I thought I built m3core and libm3 including linking (having even modified cm3.cfg)COULD be I'm using the wrong .libs, but:C:\cygwin\lib\w32api>nm libkernel32.a | findstr CreateFile00000000 I __imp__CreateFileW at 2800000000 T _CreateFileW at 2800000000 I __imp__CreateFileMappingW at 2400000000 T _CreateFileMappingW at 2400000000 I __imp__CreateFileMappingA at 2400000000 T _CreateFileMappingA at 2400000000 I __imp__CreateFileA at 2800000000 T _CreateFileA at 28C:\cygwin\lib\w32api>cd \MinGW\libC:\MinGW\lib>nm libkernel32.a | findstr CreateFile00000000 I __imp__CreateFileW at 2800000000 T _CreateFileW at 2800000000 I __imp__CreateFileMappingW at 2400000000 T _CreateFileMappingW at 2400000000 I __imp__CreateFileMappingA at 2400000000 T _CreateFileMappingA at 2400000000 I __imp__CreateFileA at 2800000000 T _CreateFileA at 28 I think at least THREE calling conventions should be supported -- __cdecl, __stdcall, __fastcall --but oh well. We can live without __fastcall.Watcom has another calling convention, "watcall", and they let you describe calling conventions with #pragmas, neat.Thanks, - Jay Share life as it happens with the new Windows Live. Start sharing! _________________________________________________________________ Get the power of Windows + Web with the new Windows Live. http://www.windowslive.com?ocid=TXT_TAGHM_Wave2_powerofwindows_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Thu Jan 10 13:58:50 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 10 Jan 2008 13:58:50 +0100 Subject: [M3devel] win32 path separators -- support forward and backward in libm3? In-Reply-To: References: Your message of "Wed, 09 Jan 2008 17:25:31 PST." <200801100131.m0A1VQYS034516@camembert.async.caltech.edu> Message-ID: <20080110135850.g34emuxds0ogwwk4@mail.elegosoft.com> Quoting Jay : > To a very large extent, Win32 accepts both / and \ equally as path > delimiters. > CreateFile, DeleteFile, CreateDirectory, MoveFile, CopyFile, > FindFirstFile, GetFileAttributes, the C runtime wrappers fopen, > unlink/remove, stat, etc., those all work either way, or with a mix. > "Shell" functions like shlwapi.dll, commdlg32.dll, tend not to. > > In building NT386GNU, I run into places where cm3 is picking apart paths. > For whatever reason, it is being given paths with a mix of forward > and backward slashes. > I find these paths ugly, but they work ok. > > I've been able to easily progress by changing > m3-libs/libm3/src/os/WIN32/PathnameWin32.m3 to treat forward and > backslashes the same. > I have not yet rebuilt the normal NT386 target with this change. > > An ok change? > > Or go and fix NT386GNU a) to be consistent, b) use backward slashes, > c) translate at some place. > > ? In my opininion NT386GNU should be a POSIX target and thus use forward slashes as standard as POSIX defines. Offhand I wouldn't object to accept backward slashes as path delimiters, too. But you must heed that \ is used as an escape character almost everywhere (and so should it be in pathname denotations then: a\\b\\c) or you loose much compatibility. I still wonder if the decision to use \ on DOS/Windows was only made to be as incompatible as possible with Unix... Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Jan 10 14:11:33 2008 From: jayk123 at hotmail.com (Jay) Date: Thu, 10 Jan 2008 13:11:33 +0000 Subject: [M3devel] FW: bad code on PPC_LINUX? In-Reply-To: References: Message-ID: Removing -fPIC seems to fix this, though the code still stinks and the frame is still huge (700+ bytes). Even with -O, even without -gstabs (adding/removing -gstabs shouldn't matter but I tried anyway) - Jay ________________________________ > From: jayk123 at hotmail.com > To: m3devel at elegosoft.com > Date: Thu, 10 Jan 2008 09:28:31 +0000 > Subject: [M3devel] FW: bad code on PPC_LINUX? > > My emails keep getting truncated for some reason.. :( > > > ________________________________ >> From: jayk123 at hotmail.com >> To: m3devel at elegosoft.com >> Subject: bad code on PPC_LINUX? >> Date: Thu, 10 Jan 2008 07:11:11 +0000 >> >> >> Something is screwy I think. >> My gdb skills are um not good. >> >> On PPC_LINUX. >> >> /dev2/cm3/m3-sys/cm3/src/Utils.m3 >> >> PROCEDURE WriteFile (file: TEXT; proc: Emitter; append := FALSE) = >> VAR wr: Wr.T; >> BEGIN >> IF (append) >> THEN wr := AppendWriter (file, fatal := TRUE); >> ELSE wr := OpenWriter (file, fatal := TRUE); >> END; >> TRY (* line 78 *) >> TRY >> proc (wr); >> EXCEPT >> | Wr.Failure (ec) => >> Msg.FatalError (ec, "write failed on ", file); >> | Thread.Alerted => >> Msg.FatalError (NIL, "interrupted while writing ", file); >> END; >> FINALLY >> CloseWriter (wr, file); >> END; >> END WriteFile; >> >> I get a SEGV on line 78. >> >> I'm willing to believe, sadly, that some of these huge offsets >> are the price of TRY and saving the register context on anything >> other than x86 (for registers that aren't even used by the function?), >> however it crashes just after the call and notice there the huge 32k offset. >> >> And really? A 720 byte frame for any function with a TRY on PowerPC? >> Really? >> I guess I should look at what PPC_DARWIN does. >> >> If someone can give me a quick run down on PowerPC ABI, thanks. >> I'll search the web. Or maybe check my Mac docs. >> register 0 is 0 or general purpose? >> Stack is register ? >> I know that return address is in the link register. >> bl is branch and link -- call -- jump and save pc in link register. >> >> The code is: >> (gdb) disassemble >> Dump of assembler code for function Utils__WriteFile: >> 0x10024fbc : stwu r1,-720(r1) >> 0x10024fc0 : mflr r0 >> 0x10024fc4 : mfcr r12 >> 0x10024fc8 : stfd f14,576(r1) >> 0x10024fcc : stfd f15,584(r1) >> 0x10024fd0 : stfd f16,592(r1) >> 0x10024fd4 : stfd f17,600(r1) >> 0x10024fd8 : stfd f18,608(r1) >> 0x10024fdc : stfd f19,616(r1) >> 0x10024fe0 : stfd f20,624(r1) >> 0x10024fe4 : stfd f21,632(r1) >> 0x10024fe8 : stfd f22,640(r1) >> 0x10024fec : stfd f23,648(r1) >> 0x10024ff0 : stfd f24,656(r1) >> 0x10024ff4 : stfd f25,664(r1) >> 0x10024ff8 : stfd f26,672(r1) >> 0x10024ffc : stfd f27,680(r1) >> 0x10025000 : stfd f28,688(r1) >> 0x10025004 : stfd f29,696(r1) >> 0x10025008 : stfd f30,704(r1) >> 0x1002500c : stfd f31,712(r1) >> 0x10025010 : stw r14,504(r1) >> 0x10025014 : stw r15,508(r1) >> 0x10025018 : stw r16,512(r1) >> 0x1002501c : stw r17,516(r1) >> 0x10025020 : stw r18,520(r1) >> 0x10025024 : stw r19,524(r1) >> 0x10025028 : stw r20,528(r1) >> 0x1002502c : stw r21,532(r1) >> ---Type to continue, or q to quit--- >> 0x10025030 : stw r22,536(r1) >> 0x10025034 : stw r23,540(r1) >> 0x10025038 : stw r24,544(r1) >> 0x1002503c : stw r25,548(r1) >> 0x10025040 : stw r26,552(r1) >> 0x10025044 : stw r27,556(r1) >> 0x10025048 : stw r28,560(r1) >> 0x1002504c : stw r29,564(r1) >> 0x10025050 : stw r30,568(r1) >> 0x10025054 : stw r31,572(r1) >> 0x10025058 : stw r0,724(r1) >> 0x1002505c : stw r12,500(r1) >> 0x10025060 : mr r31,r1 >> 0x10025064 : bl 0x10025068 >> 0x10025068 : mflr r30 >> 0x1002506c : lwz r0,-176(r30) >> 0x10025070 : add r30,r0,r30 >> 0x10025074 : stw r3,8(r31) >> 0x10025078 : stw r4,12(r31) >> 0x1002507c : mr r0,r5 >> 0x10025080 : stb r0,16(r31) >> 0x10025084 : li r0,0 >> 0x10025088 : stw r0,20(r31) >> 0x1002508c : lbz r0,16(r31) >> 0x10025090 : clrlwi r0,r0,24 >> 0x10025094 : cmpwi r0,0 >> 0x10025098 : beq- 0x100250b8 >> 0x1002509c : lwz r3,8(r31) >> 0x100250a0 : li r4,1 >> 0x100250a4 : bl 0x100248a4 >> ---Type to continue, or q to quit--- >> 0x100250a8 : stw r3,476(r31) >> 0x100250ac : lwz r9,476(r31) >> 0x100250b0 : stw r9,20(r31) >> 0x100250b4 : b 0x100250d0 >> 0x100250b8 : lwz r3,8(r31) >> 0x100250bc : li r4,1 >> 0x100250c0 : bl 0x10024658 >> 0x100250c4 : stw r3,476(r31) >> 0x100250c8 : lwz r9,476(r31) >> 0x100250cc : stw r9,20(r31) >> >> ** here I believe ** >> >> 0x100250d0 : lwz r0,-32760(r30) >> 0x100250d4 : stw r0,32(r31) >> 0x100250d8 : addi r0,r31,8 >> 0x100250dc : stw r0,36(r31) >> 0x100250e0 : li r0,3 >> 0x100250e4 : stw r0,28(r31) >> 0x100250e8 : lwz r9,-32764(r30) >> 0x100250ec : lwz r0,0(r9) >> 0x100250f0 : stw r0,24(r31) >> 0x100250f4 : lwz r9,-32764(r30) >> 0x100250f8 : addi r0,r31,24 >> 0x100250fc : stw r0,0(r9) >> 0x10025100 : lwz r9,-32768(r30) >> 0x10025104 : addi r0,r9,76 >> 0x10025108 : stw r0,64(r31) >> 0x1002510c : li r0,0 >> 0x10025110 : stw r0,60(r31) >> 0x10025114 : lwz r9,-32764(r30) >> 0x10025118 : lwz r0,0(r9) >> 0x1002511c : stw r0,56(r31) >> ---Type to continue, or q to quit--- >> 0x10025120 : lwz r9,-32764(r30) >> 0x10025124 : addi r0,r31,56 >> 0x10025128 : stw r0,0(r9) >> 0x1002512c : addi r9,r31,56 >> 0x10025130 : addi r0,r9,48 >> 0x10025134 : mr r3,r0 >> 0x10025138 : bl 0x101bbf28 >> 0x1002513c : mr r0,r3 >> 0x10025140 : cmpwi r0,0 >> 0x10025144 : bne- 0x100251ac >> 0x10025148 : lwz r9,12(r31) >> 0x1002514c : stw r9,476(r31) >> 0x10025150 : lwz r9,476(r31) >> 0x10025154 : cmpwi r9,0 >> 0x10025158 : beq- 0x10025188 >> 0x1002515c : lwz r9,476(r31) >> 0x10025160 : lwz r0,0(r9) >> 0x10025164 : li r9,-1 >> 0x10025168 : cmpw r0,r9 >> 0x1002516c : bne- 0x10025188 >> 0x10025170 : lwz r9,476(r31) >> 0x10025174 : lwz r9,8(r9) >> 0x10025178 : stw r9,480(r31) >> 0x1002517c : lwz r9,476(r31) >> 0x10025180 : lwz r9,4(r9) >> 0x10025184 : stw r9,476(r31) >> 0x10025188 : lwz r11,480(r31) >> 0x1002518c : lwz r3,20(r31) >> 0x10025190 : lwz r0,476(r31) >> 0x10025194 : mtlr r0 >> ---Type to continue, or q to quit--- >> 0x10025198 : blrl >> 0x1002519c : lwz r9,-32764(r30) >> 0x100251a0 : lwz r0,56(r31) >> 0x100251a4 : stw r0,0(r9) >> 0x100251a8 : b 0x10025210 >> 0x100251ac : lwz r9,68(r31) >> 0x100251b0 : lwz r9,0(r9) >> 0x100251b4 : lis r0,-15535 >> 0x100251b8 : ori r0,r0,42454 >> 0x100251bc : cmpw r9,r0 >> 0x100251c0 : bne- 0x100251f0 >> 0x100251c4 : lwz r0,72(r31) >> 0x100251c8 : stw r0,472(r31) >> 0x100251cc : lwz r9,-32768(r30) >> 0x100251d0 : addi r0,r9,180 >> 0x100251d4 : lwz r3,472(r31) >> 0x100251d8 : mr r4,r0 >> 0x100251dc : lwz r5,8(r31) >> 0x100251e0 : li r6,0 >> 0x100251e4 : li r7,0 >> 0x100251e8 : bl 0x10023b4c >> 0x100251ec : b 0x10025210 >> 0x100251f0 : lwz r9,-32768(r30) >> 0x100251f4 : addi r0,r9,212 >> 0x100251f8 : li r3,0 >> 0x100251fc : mr r4,r0 >> 0x10025200 : lwz r5,8(r31) >> 0x10025204 : li r6,0 >> 0x10025208 : li r7,0 >> 0x1002520c : bl 0x10023b4c >> ---Type to continue, or q to quit--- >> 0x10025210 : lwz r9,-32764(r30) >> 0x10025214 : lwz r0,24(r31) >> 0x10025218 : stw r0,0(r9) >> 0x1002521c : addi r11,r31,8 >> 0x10025220 : bl 0x10024f74 >> 0x10025224 : lwz r11,0(r1) >> 0x10025228 : lwz r0,4(r11) >> 0x1002522c : lwz r12,-220(r11) >> 0x10025230 : mtlr r0 >> 0x10025234 : lwz r14,-216(r11) >> 0x10025238 : lwz r15,-212(r11) >> 0x1002523c : lwz r16,-208(r11) >> 0x10025240 : lwz r17,-204(r11) >> 0x10025244 : lwz r18,-200(r11) >> 0x10025248 : lwz r19,-196(r11) >> 0x1002524c : lwz r20,-192(r11) >> 0x10025250 : lwz r21,-188(r11) >> 0x10025254 : lwz r22,-184(r11) >> 0x10025258 : lwz r23,-180(r11) >> 0x1002525c : lwz r24,-176(r11) >> 0x10025260 : lwz r25,-172(r11) >> 0x10025264 : lwz r26,-168(r11) >> 0x10025268 : lwz r27,-164(r11) >> 0x1002526c : lwz r28,-160(r11) >> 0x10025270 : lwz r29,-156(r11) >> 0x10025274 : lwz r30,-152(r11) >> 0x10025278 : lwz r31,-148(r11) >> 0x1002527c : lfd f14,-144(r11) >> 0x10025280 : lfd f15,-136(r11) >> 0x10025284 : lfd f16,-128(r11) >> ---Type to continue, or q to quit--- >> 0x10025288 : lfd f17,-120(r11) >> 0x1002528c : lfd f18,-112(r11) >> 0x10025290 : lfd f19,-104(r11) >> 0x10025294 : lfd f20,-96(r11) >> 0x10025298 : lfd f21,-88(r11) >> 0x1002529c : lfd f22,-80(r11) >> 0x100252a0 : lfd f23,-72(r11) >> 0x100252a4 : lfd f24,-64(r11) >> 0x100252a8 : lfd f25,-56(r11) >> 0x100252ac : lfd f26,-48(r11) >> 0x100252b0 : lfd f27,-40(r11) >> 0x100252b4 : lfd f28,-32(r11) >> 0x100252b8 : lfd f29,-24(r11) >> 0x100252bc : lfd f30,-16(r11) >> 0x100252c0 : lfd f31,-8(r11) >> 0x100252c4 : mtcrf 56,r12 >> 0x100252c8 : mr r1,r11 >> 0x100252cc : blr >> 0x100252d0 : .long 0x24ebb0 >> End of assembler dump. >> >> >> (gdb) bt >> #0 Utils__WriteFile (M3_Bd56fi_file=0x10277ba0, M3_DmuccK_proc=0x7fb22210, >> M3_AicXUJ_append=0 '\0') at Utils.m3:78 >> #1 0x10020a10 in Makefile__Build (M3_Bd56fi_src_dir=0x102720ec) >> at Makefile.m3:101 >> #2 0x100292d4 in Main__DoIt () at Main.m3:71 >> #3 0x10029834 in Main_M3 (M3_AcxOUs_mode=1) at Main.m3:193 >> #4 0x10188f9c in RTLinker__RunMainBody (M3_DUuepq_m=0x10279b28) >> at RTLinker.m3:387 >> #5 0x101880bc in RTLinker__AddUnitI (M3_DUuepq_m=0x10279b28) at RTLinker.m3:100 >> #6 0x10188198 in RTLinker__AddUnit (M3_DUuepw_b=0x100297f8) at RTLinker.m3:110 >> #7 0x100002ec in main (argc=1, argv=0x7fb22834, envp=0x7fb2283c) at _m3main.mc:4 >> >> I haven't yet figured out how to get gdb to show me the details of the SEGV, like what address was referenced. >> >> I swear I think this was working better recently. >> >> Oh, I did change something. I will try to change it back. >> I added -fPIC. >> Dynamic linking was not working and I thought that might fix it. >> I'll definitely try without it now. >> >> Also, relevant aside -- what, if any, distributions/versions of Linux are people using on PowerPC? >> Specifically on PowerPC (to limit the religious explosion) >> I'm currently using Yellow Dog, I think 4.1, but only for Modula-3 purposes, not for anything else. >> >> ps: I'd like a SMALL forum of SMART programmers, to discuss GENERAL programming topics. >> This is it perhaps? >> >> - Jay >> _________________________________________________________________ >> Watch ?Cause Effect,? a show about real people making a real difference. >> http://im.live.com/Messenger/IM/MTV/?source=text_watchcause > > ________________________________ > Make distant family not so distant with Windows Vista? + Windows Live?. Start now! _________________________________________________________________ Put your friends on the big screen with Windows Vista? + Windows Live?. http://www.microsoft.com/windows/shop/specialoffers.mspx?ocid=TXT_TAGLM_CPC_MediaCtr_bigscreen_012008 From hendrik at topoi.pooq.com Thu Jan 10 15:28:12 2008 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Thu, 10 Jan 2008 09:28:12 -0500 Subject: [M3devel] (Offtopic) Some comments on SCM tools, was: Re: M3 concerns In-Reply-To: <20080110122020.zm4wc29e8044c0kw@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> <20080105191243.GB6402@topoi.pooq.com> <20080110122020.zm4wc29e8044c0kw@mail.elegosoft.com> Message-ID: <20080110142812.GA2503@topoi.pooq.com> On Thu, Jan 10, 2008 at 12:20:20PM +0100, Olaf Wagner wrote: > Quoting hendrik at topoi.pooq.com: > >But if you have this experience, it would be useful to see a rundown > >of the advantages and disadvantages of each. I've seen a table of > >features against version control systems, but it doesn't give any feel > >for what it's like to use them. > > > >Such an essay would be useful for those involved in other projects. It > >probably won't help Modula 3 itself. > > That would easily become an open-ended task :-) I was once asked to compare several programming languages with the intent of advising researchers in an institute which ones to use. A year into the project, I was sorry I ever started it. I learned a lot about CPU-time clocks running backward. I learned a lot about how different languages ended up with differences in floating-point behaviour, even though they were all running on the same hardware with one same set of floating-point instructions. > It is not easy to > compare different complex tools like SCM systems, which interact > in various degrees with process control, workflow management, problem > management, project management, general policies... Which is why a list of features really isn't enough. What's needed is poeple with hands-on experience with several. Which is hard to get. > > We've tried to provide feature-oriented comparison lists some years > ago, but even this needs too much efforts and is too fast out-of-date. > > There are some aspects that may currently be helpful as criterions > though. I'd like to mention some of them > > o Traditionally, version control tools were centralized server systems. > There is one central repository (which can in advanced setups be > replicated to several sites for many systems. Replicas may even be > partly writable. In case of replication there is one `logical' central > repository which is physically distributed.). Systems in this group > are CVS, ClearCase, PVCS, AccuRev, Perforce, Subversion, and many > others. > In recent years, peer-to-peer systems have become popular, because > they correspond better to certain aspects of open software projects > and are inherently distributed. There is no distinction between > workspace and repository, and each workspace holds a partial or > complete change history. > Such systems are BitKeeper, git, Darcs, and others. As far as I know, > these systems are not very popular in the commercial world (yet?). > > o An orthogonal criterion is the range of functionality that is addressed > with the solution. Simple systems like CVS and Perforce do just version > control and offer some hooks for further integration. > On the other side are process-oriented systems like PVCS Dimensions or a > complete ClearCase/ClearQuest setup for RUP. These systems are > rather based on change management und workflow than on developer > needs. Basic abstractions are baselines, changesets, tasks, projects, > activities, functional roles. > Of course, some tools are somewhere in between these extremes, like > AccuRev, which supports kinds of long-running transactions for > everything, called `streams'. (This one's very nice IMO.) > > o Then there are the costs of the use of the systems. There are always > costs, even for open source solutions. You have to consider > > - server costs (hardware, energy, OS, database, licences, networks) > - administration and maintenance (servers and user setup) > - user license costs (from 0 to several thousand dollars per year) > - use overhead (depending on tool usability and process) > - instruction and training > > Again there are systems that are rather lightweight in this respect > (like CVS and Perforce) and some tending to be more heavyweight > (like ClearCase and PVCS). > > o The `end user experience' corresponds very much to the basic > concepts needed in everyday use. File based ci/co is very > simple, development lines are more or less a must have, > change sets and baselines (like in DCVS, AccuRev or RUP) are very > nice; diffs and merges seem to be too complex for many users > (but are of course needed); conflict avoidance vs. conflict > resolution (locking or optimistic approach) is often a religiously > discussed topic. > The other important issue here is the IDE integration (at least > for developers). > > These are only some randomly picked topics that would need to be > addressed in a useful tool comparison. > > There are very few situations in which you can evaluate and choose > the best tool for your purpose; most of the time, you have to adapt > and improve existing setups, as everything else would be too > expensive and disrupting. Our company has supported several migration > projects recently though, so it's not impossible to change ;-) > > As for CM3, I'm still of the opinion that there is no need to > change the existing CVS infrastructure. > > >Or might you know of such an essay elsewhere? > > Well, the more interesting field studies and evaluations are not > free; there are quite a lot of interesting articles though. > I haven't any links here right now; CM crossroads or a Google > search on `configuration management' should be a good starting point. Thank you for this very brief review. I'm really not wanting you to take a year off from more urgent 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 hendrik at topoi.pooq.com Thu Jan 10 15:37:50 2008 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Thu, 10 Jan 2008 09:37:50 -0500 Subject: [M3devel] win32 path separators -- support forward and backward in libm3? In-Reply-To: <20080110135850.g34emuxds0ogwwk4@mail.elegosoft.com> References: <200801100131.m0A1VQYS034516@camembert.async.caltech.edu> <20080110135850.g34emuxds0ogwwk4@mail.elegosoft.com> Message-ID: <20080110143750.GB2503@topoi.pooq.com> On Thu, Jan 10, 2008 at 01:58:50PM +0100, Olaf Wagner wrote: > Quoting Jay : > > >To a very large extent, Win32 accepts both / and \ equally as path > >delimiters. > >CreateFile, DeleteFile, CreateDirectory, MoveFile, CopyFile, > >FindFirstFile, GetFileAttributes, the C runtime wrappers fopen, > >unlink/remove, stat, etc., those all work either way, or with a mix. > >"Shell" functions like shlwapi.dll, commdlg32.dll, tend not to. > > > >In building NT386GNU, I run into places where cm3 is picking apart paths. > >For whatever reason, it is being given paths with a mix of forward > >and backward slashes. > >I find these paths ugly, but they work ok. > > > >I've been able to easily progress by changing > >m3-libs/libm3/src/os/WIN32/PathnameWin32.m3 to treat forward and > >backslashes the same. > >I have not yet rebuilt the normal NT386 target with this change. > > > >An ok change? > > > >Or go and fix NT386GNU a) to be consistent, b) use backward slashes, > > c) translate at some place. > > > >? > > In my opininion NT386GNU should be a POSIX target and thus use forward > slashes as standard as POSIX defines. Offhand I wouldn't object to accept > backward slashes as path delimiters, too. But you must heed that \ > is used as an escape character almost everywhere (and so should it be > in pathname denotations then: a\\b\\c) or you loose much compatibility. > > I still wonder if the decision to use \ on DOS/Windows was only made to > be as incompatible as possible with Unix... In the early days, DOS did not have directories, so there was no need of a slash or anything as a pathname separator. Instead, it got used as a character to attach options to command names. I think is also got used to attach options to filenames sometimes. When someone got the bright idea that directories were a neat idea, it was too late. Incidentally, in those days, Unix wasn't yet the big deal it is now. There were lots of other OS's to be compatible with -- or not. -- hendrik From darko at darko.org Thu Jan 10 17:35:05 2008 From: darko at darko.org (Darko) Date: Thu, 10 Jan 2008 08:35:05 -0800 Subject: [M3devel] nt386gnu is posix or win32? In-Reply-To: References: Your message of "Wed, 09 Jan 2008 17:25:31 PST." <200801100131.m0A1VQYS034516@camembert.async.caltech.edu> Message-ID: <6A267174-E215-48A6-BD0D-CB9AF4C13FE5@darko.org> On 10/01/2008, at 3:16 AM, Jay wrote: > By "serious" I mean, "ship real software using it". Then the question is: what is' real' software. I've shipped commercial software (a smallish application) using the existing native back end, which doesn't produce very good code, but the performance was adequate. For many other applications this won't be the case. You should look at this issue the other way around: If it allows people to build 'serious' software, they will use it. If you have an interest in Windows and M3, this would be one of the most useful things you could do, IMHO. Darko. From hosking at cs.purdue.edu Thu Jan 10 18:41:55 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 10 Jan 2008 12:41:55 -0500 Subject: [M3devel] bad code on PPC_LINUX? In-Reply-To: References: Message-ID: <9E64639D-CF64-4E6E-A157-FB67D1AC0C9B@cs.purdue.edu> Is this an alignment problem? Or a mismatch between the compiler and runtime? I have no idea if the alignment specs and definitions for the jmp_buf used in exceptions are matched between the compiler and run-time properly. See Target.m3 in the compiler and RTMachine.i3 in the runtime. On Jan 10, 2008, at 2:11 AM, Jay wrote: > > Something is screwy I think. > My gdb skills are um not good. > > On PPC_LINUX. > > /dev2/cm3/m3-sys/cm3/src/Utils.m3 > > PROCEDURE WriteFile (file: TEXT; proc: Emitter; append := FALSE) = > VAR wr: Wr.T; > BEGIN > IF (append) > THEN wr := AppendWriter (file, fatal := TRUE); > ELSE wr := OpenWriter (file, fatal := TRUE); > END; > TRY (* line 78 *) > TRY > proc (wr); > EXCEPT > | Wr.Failure (ec) => > Msg.FatalError (ec, "write failed on ", file); > | Thread.Alerted => > Msg.FatalError (NIL, "interrupted while writing ", file); > END; > FINALLY > CloseWriter (wr, file); > END; > END WriteFile; > > I get a SEGV on line 78. > > I'm willing to believe, sadly, that some of these huge offsets > are the price of TRY and saving the register context on anything > other than x86 (for registers that aren't even used by the function?), > however it crashes just after the call and notice there the huge > 32k offset From hosking at cs.purdue.edu Thu Jan 10 18:52:35 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 10 Jan 2008 12:52:35 -0500 Subject: [M3devel] could someone add __stdcall name mangling to m3cc please? In-Reply-To: References: Your message of "Wed, 09 Jan 2008 17:25:31 PST." <200801100131.m0A1VQYS034516@camembert.async.caltech.edu> Message-ID: <6D677FCA-D704-4E84-BD58-893C71D97B59@cs.purdue.edu> On Jan 10, 2008, at 7:42 AM, Jay wrote: > PM3 appears to ignore call_conv. > Perhaps its NT386GNU uses usermode threads via cygwin1.dll and has > no gui support, such as to not import any __stdcall functions??? Probably, yes. CM3 were the ones who added gui support. Anyway, I think it is simply a matter of adding the appropriate attribute to the function decls in the gcc backend. I believe that it supports cdecl and stdcall. Are these all we need to specify? > http://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/m3/pm3/language/ > modula3/m3compiler/m3cc/gcc/gcc/m3cg/m3.c?rev=1.1;content-type=text% > 2Fx-cvsweb-markup;cvsroot=PM3 > > - Jay > > From: jayk123 at hotmail.com > To: m3devel at elegosoft.com > Date: Thu, 10 Jan 2008 12:40:22 +0000 > Subject: [M3devel] could someone add __stdcall name mangling to > m3cc please? > > Could someone out there (Tony?) familiar with the gcc backend > have it not ignore call_conv and if call_conv is 1, append > an at symbol and the number of bytes of parameters to the function > name? > (Even for zero, e.g. Sleep at 0, GetFileAttributes at 4). > This would be I guess at least for "imported" functions. > > Not clear about calling function pointers, probably needs > modification. > call_conv 0 is "__cdecl" is push right to left, caller cleans up > call_conv 1 is "__stdcall" is push right to left, callee cleans up > There are various synonyms. > With no command line switches, __cdecl is the compiler default. > __stdcall is deemed more efficient, and is very widely used. > > Not clear about functions implemented in Modula-3. > Probably won't occur? Maybe for callbacks? WindowProcs, thread > entry point? > > This could/should be for NT386GNU only. > The hypothetical other NT targets only have one calling convention > each. > > I COULD do something sleazy here and generate little adapter > functions, over in m3-win/import-libs esp. > > I'm still checking out pm3 to see what it does here. > (as in cvs checkout, not "looking at") > > This'll clear up: > > RTOS.m3:27: undefined reference to `_FatalExit' > RTOS.mo: In function `RTOS__GetMemory': > RTOS.m3:75: undefined reference to `_VirtualAlloc' > RTOS.m3:85: undefined reference to `_VirtualAlloc' > RTOS.mo: In function `RTOS__InitMemory': > RTOS.m3:96: undefined reference to `_VirtualAlloc' > RTOS.m3:100: undefined reference to `_GetSystemInfo' > RTOS.mo: In function `RTOS__Write': > RTOS.m3:118: undefined reference to `_AllocConsole' > RTOS.m3:119: undefined reference to `_GetStdHandle' > RTOS.m3:122: undefined reference to `_WriteFile' > RTPerfTool.mo: In function `RTPerfTool__Start': > RTPerfTool.m3:19: undefined reference to `_ReadFile' > RTPerfTool.m3:22: undefined reference to `_CloseHandle' > RTPerfTool.mo: In function `RTPerfTool__Close': > RTPerfTool.m3:28: undefined reference to `_CloseHandle' > RTPerfTool.mo: In function `RTPerfTool__Send': > RTPerfTool.m3:34: undefined reference to `_WriteFile' > RTPerfTool.mo: In function `RTPerfTool__PrepHandle': > RTPerfTool.m3:58: undefined reference to `_GetCurrentProcess' > RTPerfTool.m3:59: undefined reference to `_DuplicateHandle' > etc. > > I did think I was past these. I thought I built m3core and libm3 > including linking (having even modified cm3.cfg) > COULD be I'm using the wrong .libs, but: > > C:\cygwin\lib\w32api>nm libkernel32.a | findstr CreateFile > 00000000 I __imp__CreateFileW at 28 > 00000000 T _CreateFileW at 28 > 00000000 I __imp__CreateFileMappingW at 24 > 00000000 T _CreateFileMappingW at 24 > 00000000 I __imp__CreateFileMappingA at 24 > 00000000 T _CreateFileMappingA at 24 > 00000000 I __imp__CreateFileA at 28 > 00000000 T _CreateFileA at 28 > > C:\cygwin\lib\w32api>cd \MinGW\lib > > C:\MinGW\lib>nm libkernel32.a | findstr CreateFile > 00000000 I __imp__CreateFileW at 28 > 00000000 T _CreateFileW at 28 > 00000000 I __imp__CreateFileMappingW at 24 > 00000000 T _CreateFileMappingW at 24 > 00000000 I __imp__CreateFileMappingA at 24 > 00000000 T _CreateFileMappingA at 24 > 00000000 I __imp__CreateFileA at 28 > 00000000 T _CreateFileA at 28 > > I think at least THREE calling conventions should be supported -- > __cdecl, __stdcall, __fastcall -- > but oh well. We can live without __fastcall. > Watcom has another calling convention, "watcall", and they let you > describe calling conventions with #pragmas, neat. > > Thanks, > - Jay > > Share life as it happens with the new Windows Live. Start sharing! > Get the power of Windows + Web with the new Windows Live. Get it now! From hosking at cs.purdue.edu Thu Jan 10 18:57:47 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 10 Jan 2008 12:57:47 -0500 Subject: [M3devel] could someone add __stdcall name mangling to m3cc please? In-Reply-To: References: Your message of "Wed, 09 Jan 2008 17:25:31 PST." <200801100131.m0A1VQYS034516@camembert.async.caltech.edu> Message-ID: <70EC0898-EE63-4C19-8C28-EC72E2B73B31@cs.purdue.edu> Do we have a version of the gcc-based backend that *ever* supported the calling conventions? On Jan 10, 2008, at 7:40 AM, Jay wrote: > Could someone out there (Tony?) familiar with the gcc backend > have it not ignore call_conv and if call_conv is 1, append > an at symbol and the number of bytes of parameters to the function > name? > (Even for zero, e.g. Sleep at 0, GetFileAttributes at 4). > This would be I guess at least for "imported" functions. > > Not clear about calling function pointers, probably needs > modification. > call_conv 0 is "__cdecl" is push right to left, caller cleans up > call_conv 1 is "__stdcall" is push right to left, callee cleans up > There are various synonyms. > With no command line switches, __cdecl is the compiler default. > __stdcall is deemed more efficient, and is very widely used. > > Not clear about functions implemented in Modula-3. > Probably won't occur? Maybe for callbacks? WindowProcs, thread > entry point? > > This could/should be for NT386GNU only. > The hypothetical other NT targets only have one calling convention > each. > > I COULD do something sleazy here and generate little adapter > functions, over in m3-win/import-libs esp. > > I'm still checking out pm3 to see what it does here. > (as in cvs checkout, not "looking at") > > This'll clear up: > > RTOS.m3:27: undefined reference to `_FatalExit' > RTOS.mo: In function `RTOS__GetMemory': > RTOS.m3:75: undefined reference to `_VirtualAlloc' > RTOS.m3:85: undefined reference to `_VirtualAlloc' > RTOS.mo: In function `RTOS__InitMemory': > RTOS.m3:96: undefined reference to `_VirtualAlloc' > RTOS.m3:100: undefined reference to `_GetSystemInfo' > RTOS.mo: In function `RTOS__Write': > RTOS.m3:118: undefined reference to `_AllocConsole' > RTOS.m3:119: undefined reference to `_GetStdHandle' > RTOS.m3:122: undefined reference to `_WriteFile' > RTPerfTool.mo: In function `RTPerfTool__Start': > RTPerfTool.m3:19: undefined reference to `_ReadFile' > RTPerfTool.m3:22: undefined reference to `_CloseHandle' > RTPerfTool.mo: In function `RTPerfTool__Close': > RTPerfTool.m3:28: undefined reference to `_CloseHandle' > RTPerfTool.mo: In function `RTPerfTool__Send': > RTPerfTool.m3:34: undefined reference to `_WriteFile' > RTPerfTool.mo: In function `RTPerfTool__PrepHandle': > RTPerfTool.m3:58: undefined reference to `_GetCurrentProcess' > RTPerfTool.m3:59: undefined reference to `_DuplicateHandle' > etc. > > I did think I was past these. I thought I built m3core and libm3 > including linking (having even modified cm3.cfg) > COULD be I'm using the wrong .libs, but: > > C:\cygwin\lib\w32api>nm libkernel32.a | findstr CreateFile > 00000000 I __imp__CreateFileW at 28 > 00000000 T _CreateFileW at 28 > 00000000 I __imp__CreateFileMappingW at 24 > 00000000 T _CreateFileMappingW at 24 > 00000000 I __imp__CreateFileMappingA at 24 > 00000000 T _CreateFileMappingA at 24 > 00000000 I __imp__CreateFileA at 28 > 00000000 T _CreateFileA at 28 > > C:\cygwin\lib\w32api>cd \MinGW\lib > > C:\MinGW\lib>nm libkernel32.a | findstr CreateFile > 00000000 I __imp__CreateFileW at 28 > 00000000 T _CreateFileW at 28 > 00000000 I __imp__CreateFileMappingW at 24 > 00000000 T _CreateFileMappingW at 24 > 00000000 I __imp__CreateFileMappingA at 24 > 00000000 T _CreateFileMappingA at 24 > 00000000 I __imp__CreateFileA at 28 > 00000000 T _CreateFileA at 28 > > I think at least THREE calling conventions should be supported -- > __cdecl, __stdcall, __fastcall -- > but oh well. We can live without __fastcall. > Watcom has another calling convention, "watcall", and they let you > describe calling conventions with #pragmas, neat. > > Thanks, > - Jay > > Share life as it happens with the new Windows Live. Start sharing! From hosking at cs.purdue.edu Thu Jan 10 19:16:40 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 10 Jan 2008 13:16:40 -0500 Subject: [M3devel] FW: bad code on PPC_LINUX? In-Reply-To: References: Message-ID: <9D5186FA-9A91-4696-B6C6-CABC12DAE188@cs.purdue.edu> On Jan 10, 2008, at 4:28 AM, Jay wrote: > My emails keep getting truncated for some reason.. :( > > > > From: jayk123 at hotmail.com > > To: m3devel at elegosoft.com > > Subject: bad code on PPC_LINUX? > > Date: Thu, 10 Jan 2008 07:11:11 +0000 > > > > > > Something is screwy I think. > > My gdb skills are um not good. > > > > On PPC_LINUX. > > > > /dev2/cm3/m3-sys/cm3/src/Utils.m3 > > > > PROCEDURE WriteFile (file: TEXT; proc: Emitter; append := FALSE) = > > VAR wr: Wr.T; > > BEGIN > > IF (append) > > THEN wr := AppendWriter (file, fatal := TRUE); > > ELSE wr := OpenWriter (file, fatal := TRUE); > > END; > > TRY (* line 78 *) > > TRY > > proc (wr); > > EXCEPT > > | Wr.Failure (ec) => > > Msg.FatalError (ec, "write failed on ", file); > > | Thread.Alerted => > > Msg.FatalError (NIL, "interrupted while writing ", file); > > END; > > FINALLY > > CloseWriter (wr, file); > > END; > > END WriteFile; > > > > I get a SEGV on line 78. > > > > I'm willing to believe, sadly, that some of these huge offsets > > are the price of TRY and saving the register context on anything > > other than x86 (for registers that aren't even used by the > function?), > > however it crashes just after the call and notice there the huge > 32k offset. > > > > And really? A 720 byte frame for any function with a TRY on PowerPC? > > Really? Sounds odd, but maybe some struct in the frame is huge. What is the size of the jmp_buf? > > > I guess I should look at what PPC_DARWIN does. Sure. > > > > > If someone can give me a quick run down on PowerPC ABI, thanks. > > I'll search the web. Or maybe check my Mac docs. Mac docs do a reasonable job. It is similar for PPC Linux. http://developer.apple.com/documentation/DeveloperTools/ CompilersDebuggers-date.html > > > register 0 is 0 or general purpose? > > Stack is register ? > > I know that return address is in the link register. > > bl is branch and link -- call -- jump and save pc in link register. > > > > The code is: > > (gdb) disassemble > > Dump of assembler code for function Utils__WriteFile: > > 0x10024fbc : stwu r1,-720(r1) > > 0x10024fc0 : mflr r0 > > 0x10024fc4 : mfcr r12 > > 0x10024fc8 : stfd f14,576(r1) > > 0x10024fcc : stfd f15,584(r1) > > 0x10024fd0 : stfd f16,592(r1) > > 0x10024fd4 : stfd f17,600(r1) > > 0x10024fd8 : stfd f18,608(r1) > > 0x10024fdc : stfd f19,616(r1) > > 0x10024fe0 : stfd f20,624(r1) > > 0x10024fe4 : stfd f21,632(r1) > > 0x10024fe8 : stfd f22,640(r1) > > 0x10024fec : stfd f23,648(r1) > > 0x10024ff0 : stfd f24,656(r1) > > 0x10024ff4 : stfd f25,664(r1) > > 0x10024ff8 : stfd f26,672(r1) > > 0x10024ffc : stfd f27,680(r1) > > 0x10025000 : stfd f28,688(r1) > > 0x10025004 : stfd f29,696(r1) > > 0x10025008 : stfd f30,704(r1) > > 0x1002500c : stfd f31,712(r1) > > 0x10025010 : stw r14,504(r1) > > 0x10025014 : stw r15,508(r1) > > 0x10025018 : stw r16,512(r1) > > 0x1002501c : stw r17,516(r1) > > 0x10025020 : stw r18,520(r1) > > 0x10025024 : stw r19,524(r1) > > 0x10025028 : stw r20,528(r1) > > 0x1002502c : stw r21,532(r1) > > ---Type to continue, or q to quit--- > > 0x10025030 : stw r22,536(r1) > > 0x10025034 : stw r23,540(r1) > > 0x10025038 : stw r24,544(r1) > > 0x1002503c : stw r25,548(r1) > > 0x10025040 : stw r26,552(r1) > > 0x10025044 : stw r27,556(r1) > > 0x10025048 : stw r28,560(r1) > > 0x1002504c : stw r29,564(r1) > > 0x10025050 : stw r30,568(r1) > > 0x10025054 : stw r31,572(r1) > > 0x10025058 : stw r0,724(r1) > > 0x1002505c : stw r12,500(r1) > > 0x10025060 : mr r31,r1 > > 0x10025064 : bl 0x10025068 > > 0x10025068 : mflr r30 > > 0x1002506c : lwz r0,-176(r30) > > 0x10025070 : add r30,r0,r30 > > 0x10025074 : stw r3,8(r31) > > 0x10025078 : stw r4,12(r31) > > 0x1002507c : mr r0,r5 > > 0x10025080 : stb r0,16(r31) > > 0x10025084 : li r0,0 > > 0x10025088 : stw r0,20(r31) > > 0x1002508c : lbz r0,16(r31) > > 0x10025090 : clrlwi r0,r0,24 > > 0x10025094 : cmpwi r0,0 > > 0x10025098 : beq- 0x100250b8 > > 0x1002509c : lwz r3,8(r31) > > 0x100250a0 : li r4,1 > > 0x100250a4 : bl 0x100248a4 > > ---Type to continue, or q to quit--- > > 0x100250a8 : stw r3,476(r31) > > 0x100250ac : lwz r9,476(r31) > > 0x100250b0 : stw r9,20(r31) > > 0x100250b4 : b 0x100250d0 > > 0x100250b8 : lwz r3,8(r31) > > 0x100250bc : li r4,1 > > 0x100250c0 : bl 0x10024658 > > 0x100250c4 : stw r3,476(r31) > > 0x100250c8 : lwz r9,476(r31) > > 0x100250cc : stw r9,20(r31) > > > > ** here I believe ** > > > > 0x100250d0 : lwz r0,-32760(r30) > > 0x100250d4 : stw r0,32(r31) > > 0x100250d8 : addi r0,r31,8 > > 0x100250dc : stw r0,36(r31) > > 0x100250e0 : li r0,3 > > 0x100250e4 : stw r0,28(r31) > > 0x100250e8 : lwz r9,-32764(r30) > > 0x100250ec : lwz r0,0(r9) > > 0x100250f0 : stw r0,24(r31) > > 0x100250f4 : lwz r9,-32764(r30) > > 0x100250f8 : addi r0,r31,24 > > 0x100250fc : stw r0,0(r9) > > 0x10025100 : lwz r9,-32768(r30) > > 0x10025104 : addi r0,r9,76 > > 0x10025108 : stw r0,64(r31) > > 0x1002510c : li r0,0 > > 0x10025110 : stw r0,60(r31) > > 0x10025114 : lwz r9,-32764(r30) > > 0x10025118 : lwz r0,0(r9) > > 0x1002511c : stw r0,56(r31) > > ---Type to continue, or q to quit--- > > 0x10025120 : lwz r9,-32764(r30) > > 0x10025124 : addi r0,r31,56 > > 0x10025128 : stw r0,0(r9) > > 0x1002512c : addi r9,r31,56 > > 0x10025130 : addi r0,r9,48 > > 0x10025134 : mr r3,r0 > > 0x10025138 : bl 0x101bbf28 > > 0x1002513c : mr r0,r3 > > 0x10025140 : cmpwi r0,0 > > 0x10025144 : bne- 0x100251ac > > 0x10025148 : lwz r9,12(r31) > > 0x1002514c : stw r9,476(r31) > > 0x10025150 : lwz r9,476(r31) > > 0x10025154 : cmpwi r9,0 > > 0x10025158 : beq- 0x10025188 > > 0x1002515c : lwz r9,476(r31) > > 0x10025160 : lwz r0,0(r9) > > 0x10025164 : li r9,-1 > > 0x10025168 : cmpw r0,r9 > > 0x1002516c : bne- 0x10025188 > > 0x10025170 : lwz r9,476(r31) > > 0x10025174 : lwz r9,8(r9) > > 0x10025178 : stw r9,480(r31) > > 0x1002517c : lwz r9,476(r31) > > 0x10025180 : lwz r9,4(r9) > > 0x10025184 : stw r9,476(r31) > > 0x10025188 : lwz r11,480(r31) > > 0x1002518c : lwz r3,20(r31) > > 0x10025190 : lwz r0,476(r31) > > 0x10025194 : mtlr r0 > > ---Type to continue, or q to quit--- > > 0x10025198 : blrl > > 0x1002519c : lwz r9,-32764(r30) > > 0x100251a0 : lwz r0,56(r31) > > 0x100251a4 : stw r0,0(r9) > > 0x100251a8 : b 0x10025210 > > 0x100251ac : lwz r9,68(r31) > > 0x100251b0 : lwz r9,0(r9) > > 0x100251b4 : lis r0,-15535 > > 0x100251b8 : ori r0,r0,42454 > > 0x100251bc : cmpw r9,r0 > > 0x100251c0 : bne- 0x100251f0 > > 0x100251c4 : lwz r0,72(r31) > > 0x100251c8 : stw r0,472(r31) > > 0x100251cc : lwz r9,-32768(r30) > > 0x100251d0 : addi r0,r9,180 > > 0x100251d4 : lwz r3,472(r31) > > 0x100251d8 : mr r4,r0 > > 0x100251dc : lwz r5,8(r31) > > 0x100251e0 : li r6,0 > > 0x100251e4 : li r7,0 > > 0x100251e8 : bl 0x10023b4c > > 0x100251ec : b 0x10025210 > > 0x100251f0 : lwz r9,-32768(r30) > > 0x100251f4 : addi r0,r9,212 > > 0x100251f8 : li r3,0 > > 0x100251fc : mr r4,r0 > > 0x10025200 : lwz r5,8(r31) > > 0x10025204 : li r6,0 > > 0x10025208 : li r7,0 > > 0x1002520c : bl 0x10023b4c > > ---Type to continue, or q to quit--- > > 0x10025210 : lwz r9,-32764(r30) > > 0x10025214 : lwz r0,24(r31) > > 0x10025218 : stw r0,0(r9) > > 0x1002521c : addi r11,r31,8 > > 0x10025220 : bl 0x10024f74 > > 0x10025224 : lwz r11,0(r1) > > 0x10025228 : lwz r0,4(r11) > > 0x1002522c : lwz r12,-220(r11) > > 0x10025230 : mtlr r0 > > 0x10025234 : lwz r14,-216(r11) > > 0x10025238 : lwz r15,-212(r11) > > 0x1002523c : lwz r16,-208(r11) > > 0x10025240 : lwz r17,-204(r11) > > 0x10025244 : lwz r18,-200(r11) > > 0x10025248 : lwz r19,-196(r11) > > 0x1002524c : lwz r20,-192(r11) > > 0x10025250 : lwz r21,-188(r11) > > 0x10025254 : lwz r22,-184(r11) > > 0x10025258 : lwz r23,-180(r11) > > 0x1002525c : lwz r24,-176(r11) > > 0x10025260 : lwz r25,-172(r11) > > 0x10025264 : lwz r26,-168(r11) > > 0x10025268 : lwz r27,-164(r11) > > 0x1002526c : lwz r28,-160(r11) > > 0x10025270 : lwz r29,-156(r11) > > 0x10025274 : lwz r30,-152(r11) > > 0x10025278 : lwz r31,-148(r11) > > 0x1002527c : lfd f14,-144(r11) > > 0x10025280 : lfd f15,-136(r11) > > 0x10025284 : lfd f16,-128(r11) > > ---Type to continue, or q to quit--- > > 0x10025288 : lfd f17,-120(r11) > > 0x1002528c : lfd f18,-112(r11) > > 0x10025290 : lfd f19,-104(r11) > > 0x10025294 : lfd f20,-96(r11) > > 0x10025298 : lfd f21,-88(r11) > > 0x1002529c : lfd f22,-80(r11) > > 0x100252a0 : lfd f23,-72(r11) > > 0x100252a4 : lfd f24,-64(r11) > > 0x100252a8 : lfd f25,-56(r11) > > 0x100252ac : lfd f26,-48(r11) > > 0x100252b0 : lfd f27,-40(r11) > > 0x100252b4 : lfd f28,-32(r11) > > 0x100252b8 : lfd f29,-24(r11) > > 0x100252bc : lfd f30,-16(r11) > > 0x100252c0 : lfd f31,-8(r11) > > 0x100252c4 : mtcrf 56,r12 > > 0x100252c8 : mr r1,r11 > > 0x100252cc : blr > > 0x100252d0 : .long 0x24ebb0 > > End of assembler dump. > > > > > > (gdb) bt > > #0 Utils__WriteFile (M3_Bd56fi_file=0x10277ba0, > M3_DmuccK_proc=0x7fb22210, > > M3_AicXUJ_append=0 '\0') at Utils.m3:78 > > #1 0x10020a10 in Makefile__Build (M3_Bd56fi_src_dir=0x102720ec) > > at Makefile.m3:101 > > #2 0x100292d4 in Main__DoIt () at Main.m3:71 > > #3 0x10029834 in Main_M3 (M3_AcxOUs_mode=1) at Main.m3:193 > > #4 0x10188f9c in RTLinker__RunMainBody (M3_DUuepq_m=0x10279b28) > > at RTLinker.m3:387 > > #5 0x101880bc in RTLinker__AddUnitI (M3_DUuepq_m=0x10279b28) at > RTLinker.m3:100 > > #6 0x10188198 in RTLinker__AddUnit (M3_DUuepw_b=0x100297f8) at > RTLinker.m3:110 > > #7 0x100002ec in main (argc=1, argv=0x7fb22834, envp=0x7fb2283c) > at _m3main.mc:4 > > > > I haven't yet figured out how to get gdb to show me the details > of the SEGV, like what address was referenced. > > > > I swear I think this was working better recently. > > > > Oh, I did change something. I will try to change it back. > > I added -fPIC. > > Dynamic linking was not working and I thought that might fix it. > > I'll definitely try without it now. > > > > Also, relevant aside -- what, if any, distributions/versions of > Linux are people using on PowerPC? > > Specifically on PowerPC (to limit the religious explosion) > > I'm currently using Yellow Dog, I think 4.1, but only for > Modula-3 purposes, not for anything else. > > > > ps: I'd like a SMALL forum of SMART programmers, to discuss > GENERAL programming topics. > > This is it perhaps? > > > > - Jay > > _________________________________________________________________ > > Watch ?Cause Effect,? a show about real people making a real > difference. > > http://im.live.com/Messenger/IM/MTV/?source=text_watchcause > > Make distant family not so distant with Windows Vista? + Windows > Live?. Start now! From hosking at cs.purdue.edu Thu Jan 10 19:30:55 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 10 Jan 2008 13:30:55 -0500 Subject: [M3devel] nt386gnu is posix or win32? In-Reply-To: References: <20080107073815.DBCDD10D45C8@birch.elegosoft.com> <4F88D761-5F3F-4891-B3BD-7490FC7E7A2A@cs.purdue.edu> Message-ID: On Jan 9, 2008, at 6:08 PM, Jay wrote: > I'm going to be rude and just throw this out there at a time when I > probably can't discuss it or yet have enough data/diffs to matter. > > However, in building NT386GNU -- I can build libm3 and m3core -- > the question arises as to if this target is "win32" or "posix'. > Currently in the tree it is setup to be "posix", with a fair amount > of work already done in that direction -- in particular, the Unix > interfaces. > > However, I think this target is potentially an odd beast. > Potentially it is two targets. > I guess this mimics cygwin vs. mingwin. Exactly. > > The "host" is gcc. In order to build this system, one needs > "gmake", sh, gcc probably (I'm assuming Visual C++'s compiler/ > linker cannot build m3cg, but very maybe..). > > In order to build anything with this system, one needs "as", and > most likely ld. > (I quote "as" because it is an English word and confusing to read > otherwise.) > Changing it to output assembly for masm or even Visual C++'s inline > __asm is probably actually viable, but not a tiny short term task. > (Or maybe writing an as clone that outputs .objs? Maybe using nasm/ > yasm??? Not sure the point, maybe "as" is perfectly ok.) > > And then the question arises as to what it takes to run the output. > As I've said in other topics, the C runtime dependency of Modula-3 > is light -- startup code mainly, but, yeah, also important setjmp/ > longjmp, and multiplication/division helpers sometimes. This could > perhaps all be statically linked. Certainly for Visual C++ it can be. > (NOTE: The Cygwin jmp_buf is much larger than Visual C++'s. A > THOUGHT is to grow them to the same, for object code compatibility, > but probably not useful, and very wasteful, Cygwin's is much > larger, the data in the existing code I verified is correct, like > 0x40 vs. 0xD0 I think it was, I just did printf("%x", sizeof > (jmp_buf)).) > > To get m3core to build, I switched NT386GNU to use Win32 threads. > For THAT to build, I switched OSTYPE to Win32. Overkill perhaps, in > order to get the Win32 *.i3 files. > Overkill perhaps, but it does build. > > I fully suspect that old style Posix threads can work easily, and > that pthreads can work easily, increasing the dependency on > cygwin1.dll. User-level (ThreadPosix) threads might work (using setjmp/longjmp for thread switching -- I guess that is what PM3 used to do). Or did it use ThreadWin32? I doubt ThreadPThread will work since I don't think there is a pthreads binding for Win32 threads on NT, or is there? > While this is the "other" direction, given the dependency on as, > and gcc to build m3cg, probably the horse is out of the barn. > This is arguably a simpler answer, less hybrid. My strong preference is to tread NT386GNU (i.e., Cygwin based) as a POSIX target, which might happen to use ThreadWin32. That way, the usual POSIX/Cygwin flavor of things is preserved. > > > I think the analogy to cygwin/mingwin holds, possibly perfectly. > > Maybe this is two targets. > NT386CYGWIN ? > NT386MINGWIN ? > > (Which begs the point -- target naming.... NT386 vs. PPC_LINUX...OS > +ARCH vs. ARCH + _ + OS, etc... but ARCH and OS aren't it, there is > toolchain and C runtime in the mix..) > > Obviously SOMETHING is better than NOTHING and I have no useful > binary distribution yet to show, so these questions are all very > premature. > > I'm also unsure as to the "seriousness" of using the GNU tools. > a) There don't seem to be many users of Modula-3 on Win32. > b) Will such users accept/trust a non Microsoft toolchain? > (Just what to do folks do with cygwin/mingwin? Build/ship real > software?) > > From my point of view, the attractive thing about m3cg is I get the > int64 stuff arguably out of the way easier. :) > > Licensing wise..probably a dependency on cygwin1.dll is not desirable. > > When I'm further along, er, actually, with my existing libm3.dll/ > m3core.dll, I can see what the dependencies are. > If it's just setjmp/lonjmp/memset, maybe try static linking (what > is the licensing of that?) or link to msvcr*.dll. > > Maybe see if I can configure to use mingwin to compile/link except > for m3cc. That sounds excellent. > You would configure a CYGWIN_ROOT (gcc, ld, make, sh, libs) and a > MINGWIN_ROOT (gcc, ld, libs). CYGWIN_ROOT would be required for > building m3cc, and either could be used for building anything > else. ?? That seems good, though I just thought of it, need more > time to think and investigate. > > Later.. > - Jay > > > Share life as it happens with the new Windows Live. Start sharing! From hosking at cs.purdue.edu Thu Jan 10 19:32:04 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 10 Jan 2008 13:32:04 -0500 Subject: [M3devel] nt386gnu is posix or win32? In-Reply-To: <20080110010238.GA3891@topoi.pooq.com> References: <20080107073815.DBCDD10D45C8@birch.elegosoft.com> <4F88D761-5F3F-4891-B3BD-7490FC7E7A2A@cs.purdue.edu> <20080110010238.GA3891@topoi.pooq.com> Message-ID: This echoes my desire that NT386GNU/Cygwin rely mostly on the POSIX personality of Cygwin, though threading might use win32.dll. On Jan 9, 2008, at 8:02 PM, hendrik at topoi.pooq.com wrote: > On Wed, Jan 09, 2008 at 11:08:57PM +0000, Jay wrote: >> I'm going to be rude and just throw this out there at a time when >> I probably can't discuss it or yet have enough data/diffs to matter. >> >> However, in building NT386GNU -- I can build libm3 and m3core -- >> the question arises as to if this target is "win32" or "posix'. >> Currently in the tree it is setup to be "posix", with a fair >> amount of work already done in that direction -- in particular, >> the Unix interfaces. >> >> However, I think this target is potentially an odd beast. >> Potentially it is two targets. >> I guess this mimics cygwin vs. mingwin. Exactly. >> >> The "host" is gcc. In order to build this system, one needs >> "gmake", sh, gcc probably (I'm assuming Visual C++'s compiler/ >> linker cannot build m3cg, but very maybe..). >> >> In order to build anything with this system, one needs "as", and >> most likely ld. >> (I quote "as" because it is an English word and confusing to >> read otherwise.) >> Changing it to output assembly for masm or even Visual C++'s >> inline __asm is probably actually viable, but not a tiny short >> term task. >> (Or maybe writing an as clone that outputs .objs? Maybe using nasm/ >> yasm??? Not sure the point, maybe "as" is perfectly ok.) >> >> And then the question arises as to what it takes to run the output. >> As I've said in other topics, the C runtime dependency of Modula-3 >> is light -- startup code mainly, but, yeah, also important setjmp/ >> longjmp, and multiplication/division helpers sometimes. This could >> perhaps all be statically linked. Certainly for Visual C++ it can be. >> (NOTE: The Cygwin jmp_buf is much larger than Visual C++'s. A >> THOUGHT is to grow them to the same, for object code >> compatibility, but probably not useful, and very wasteful, >> Cygwin's is much larger, the data in the existing code I verified >> is correct, like 0x40 vs. 0xD0 I think it was, I just did printf("% >> x", sizeof(jmp_buf)).) >> >> To get m3core to build, I switched NT386GNU to use Win32 threads. >> For THAT to build, I switched OSTYPE to Win32. Overkill perhaps, >> in order to get the Win32 *.i3 files. >> Overkill perhaps, but it does build. >> >> I fully suspect that old style Posix threads can work easily, and >> that pthreads can work easily, increasing the dependency on >> cygwin1.dll. >> While this is the "other" direction, given the dependency on as, >> and gcc to build m3cg, probably the horse is out of the barn. >> This is arguably a simpler answer, less hybrid. >> >> I think the analogy to cygwin/mingwin holds, possibly perfectly. >> >> Maybe this is two targets. >> NT386CYGWIN ? >> NT386MINGWIN ? >> >> (Which begs the point -- target naming.... NT386 vs. PPC_LINUX...OS >> +ARCH vs. ARCH + _ + OS, etc... but ARCH and OS aren't it, there >> is toolchain and C runtime in the mix..) >> >> Obviously SOMETHING is better than NOTHING and I have no useful >> binary distribution yet to show, so these questions are all very >> premature. >> >> I'm also unsure as to the "seriousness" of using the GNU tools. >> a) There don't seem to be many users of Modula-3 on Win32. >> b) Will such users accept/trust a non Microsoft toolchain? >> (Just what to do folks do with cygwin/mingwin? Build/ship real >> software?) > > One of my reasons for using m3 long ago was that I could write > programs > that would run on both Linux and Windows *without* using the Microsoft > tools, which I did not possess. > > -- hendrik From jayk123 at hotmail.com Thu Jan 10 20:48:15 2008 From: jayk123 at hotmail.com (Jay) Date: Thu, 10 Jan 2008 19:48:15 +0000 Subject: [M3devel] could someone add __stdcall name mangling to m3cc please? In-Reply-To: <70EC0898-EE63-4C19-8C28-EC72E2B73B31@cs.purdue.edu> References: Your message of "Wed, 09 Jan 2008 17:25:31 PST." <200801100131.m0A1VQYS034516@camembert.async.caltech.edu> <70EC0898-EE63-4C19-8C28-EC72E2B73B31@cs.purdue.edu> Message-ID: > CC: m3devel at elegosoft.com > From: hosking at cs.purdue.edu > > Do we have a version of the gcc-based backend that *ever* supported > the calling conventions? I don't know, but I theorize no. - Jay _________________________________________________________________ Share life as it happens with the new Windows Live. http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Thu Jan 10 20:55:15 2008 From: jayk123 at hotmail.com (Jay) Date: Thu, 10 Jan 2008 19:55:15 +0000 Subject: [M3devel] could someone add __stdcall name mangling to m3cc please? In-Reply-To: <6D677FCA-D704-4E84-BD58-893C71D97B59@cs.purdue.edu> References: Your message of "Wed, 09 Jan 2008 17:25:31 PST." <200801100131.m0A1VQYS034516@camembert.async.caltech.edu> <6D677FCA-D704-4E84-BD58-893C71D97B59@cs.purdue.edu> Message-ID: > CC: m3devel at elegosoft.com > From: hosking at cs.purdue.edu > > On Jan 10, 2008, at 7:42 AM, Jay wrote: > > > PM3 appears to ignore call_conv. > > Perhaps its NT386GNU uses usermode threads via cygwin1.dll and has > > no gui support, such as to not import any __stdcall functions??? > > Probably, yes. CM3 were the ones who added gui support. Anyway, I > think it is simply a matter of adding the appropriate attribute to > the function decls in the gcc backend. I believe that it supports > cdecl and stdcall. Are these all we need to specify? Digital added GUI support, but that doesn't necessary matter. PM3 might have dropped or broken it -- well, at least the NT386GNU target, not NT386. Good point, attributes, not name. __cdecl and __stdcall will suffice, yes. There is __fastcall but the M3 front end doesn't support it. The M3 front end only supports __cdecl and __stdcall, and various synonyms thereof, but it just resolves to 0 and 1, I think 0 is __cdecl. Look for "NTCall" in the source, or "stdcall" on the front end. It's pretty clear. If I knew how to easily "build things properly" "but get a preprocessed file", that is, add -E to the proper place, I would have preprocessed parse.c to get an idea how to...well...add the stuff to the name, which isn't the right fix anyway. As two where the char* or char[] is is buried in macros.. (e.g. CodeWarrior implements this well, right click a file and say "preprocess" or "disassemble") - Jay _________________________________________________________________ Put your friends on the big screen with Windows Vista? + Windows Live?. http://www.microsoft.com/windows/shop/specialoffers.mspx?ocid=TXT_TAGLM_CPC_MediaCtr_bigscreen_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney.bates at wichita.edu Thu Jan 10 22:39:57 2008 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Thu, 10 Jan 2008 15:39:57 -0600 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <20080108011658.dp4d4zumw4wwkg88@mail.elegosoft.com> References: <20080107073815.DBCDD10D45C8@birch.elegosoft.com> <4F88D761-5F3F-4891-B3BD-7490FC7E7A2A@cs.purdue.edu> <20080108011658.dp4d4zumw4wwkg88@mail.elegosoft.com> Message-ID: <478690AD.5000104@wichita.edu> My practice is to let the actual expression do the explaining to the reader, if it can do that, otherwise, give the formal name in a keyword binding. For example, if the actual is a (boolean-typed) variable named "IsEmpty", that alone probably suggests what the meaning of the parameter is. OTOH, if the actual is "TRUE", then I would code "IsEmpty := TRUE". > Quoting Jay : > >> Style tangent: Have people heard the advise that boolean parameters >> are bad, because at the callsite esp. they don't give much meaning? >> What is TRUE? What is FALSE? Enums or named parameters are clearer. > > -- ------------------------------------------------------------- Rodney 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 Thu Jan 10 22:31:16 2008 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Thu, 10 Jan 2008 15:31:16 -0600 Subject: [M3devel] M3 concerns In-Reply-To: <20080105011335.n767h3zbz4gcgk4k@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> Message-ID: <47868EA4.6090407@wichita.edu> I have been inside pickles a few times, so I might be the logical person to do this. All the infrastructure is there to convert integer sizes, but I expect detection of the fingerprint for LONGINT and determining its size will need a bit of work. Olaf Wagner wrote: > I know that it should run this way, but pickles for example wouldn't > be exchangeable then, would they? Has anybody tested pickle support > for LONGINT yet? > -- ------------------------------------------------------------- Rodney 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 Thu Jan 10 22:58:36 2008 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Thu, 10 Jan 2008 15:58:36 -0600 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <20080107192048.3FFBB10D461D@birch.elegosoft.com> References: <20080107192048.3FFBB10D461D@birch.elegosoft.com> Message-ID: <4786950C.6020502@wichita.edu> Antony, I can' tell from your posts whether this is what you did or not, but: m3gdb really needs for there to be a static link allocated space and stored, for _every_ nested procedure, even if there is nothing in the compiled code that uses it. m3gdb accesses/passes static links in several situations, e.g., a user-typed call on a nested procedure constant, user-typed assignment of a nested procedure value to a procedure variable, user-typed call on a procedure variable (whose value might be nested or top-level), and just access to a variable that is nonlocal to the current frame. All of this has been implemented for some time, although it is distressingly fragile. I have a number of times gone back in and fixed some case I thought I had working earlier. I recently started seeing "invalid static link" messages again from m3gdb, after a hiatus. The variable access function is particularly important to me, as I often use nested procedures, especially a recursive nested procedure inside a parent that holds variables that are local to the whole recursive (dynamic) nest but not fully global. Especially when the recursion is umpteen levels deep, it is a real pain to have to figure out how many levels to go "up" in the dynamic chain just to get to the immediate static parent to print one of its variables. And if you want to type a expression that mixes a local and a nonlocal variable, the feature is almost essential. So, I propose static links be there always, with the possible exception of at very high optimization levels. Antony Hosking wrote: > CVSROOT: /usr/cvs > Changes by: hosking at birch. 08/01/07 20:20:48 > > Modified files: > cm3/m3-sys/m3cc/gcc/gcc/: tree-nested.c > cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c > > Log message: > Fix bug in procedure value comparison as revealed by p035 of m3tests. > The problem was that convert_all_function_calls was marking nested function > decls as *not* needing a static chain (DECL_NO_STATIC_CHAIN) when their bodies > and other nested procedures within them did not refer to any of their > variables. In Modula-3 we still need the static chain (ie, procedure > environment) for procedure values so that they can be compared (tested > for equality) properly. See the M3 language specification for details of > procedure types, which define a procedure as a triple, including its > environment. The fix makes use of DECL_NONLOCAL on function decls to mark > them as needing the static chain to be preserved whenever a STATIC_CHAIN_EXPR > is created for the decl. > > -- ------------------------------------------------------------- Rodney 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 Jan 11 02:39:33 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 10 Jan 2008 20:39:33 -0500 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <4786950C.6020502@wichita.edu> References: <20080107192048.3FFBB10D461D@birch.elegosoft.com> <4786950C.6020502@wichita.edu> Message-ID: <79F0BFF3-15DB-48BF-A7D4-B5C6CEA3FF7A@cs.purdue.edu> This is easy enough to fix. I'll get to it tomorrow. On Jan 10, 2008, at 4:58 PM, Rodney M. Bates wrote: > Antony, I can' tell from your posts whether this is what you did or > not, but: > > m3gdb really needs for there to be a static link allocated space > and stored, for > _every_ nested procedure, even if there is nothing in the compiled > code that uses > it. m3gdb accesses/passes static links in several situations, > e.g., a user-typed > call on a nested procedure constant, user-typed assignment of a > nested procedure > value to a procedure variable, user-typed call on a procedure > variable (whose > value might be nested or top-level), and just access to a variable > that is nonlocal > to the current frame. > > All of this has been implemented for some time, although it is > distressingly > fragile. I have a number of times gone back in and fixed some case > I thought > I had working earlier. I recently started seeing "invalid static > link" messages > again from m3gdb, after a hiatus. > > The variable access function is particularly important to me, as I > often use nested > procedures, especially a recursive nested procedure inside a parent > that holds variables > that are local to the whole recursive (dynamic) nest but not fully > global. Especially when > the recursion is umpteen levels deep, it is a real pain to have to > figure out how > many levels to go "up" in the dynamic chain just to get to the > immediate static parent > to print one of its variables. And if you want to type a expression > that mixes a local > and a nonlocal variable, the feature is almost essential. > > So, I propose static links be there always, with the possible > exception of at very > high optimization levels. > > > > Antony Hosking wrote: >> CVSROOT: /usr/cvs >> Changes by: hosking at birch. 08/01/07 20:20:48 >> Modified files: >> cm3/m3-sys/m3cc/gcc/gcc/: tree-nested.c cm3/m3-sys/m3cc/gcc/gcc/ >> m3cg/: parse.c Log message: >> Fix bug in procedure value comparison as revealed by p035 of >> m3tests. >> The problem was that convert_all_function_calls was marking >> nested function >> decls as *not* needing a static chain (DECL_NO_STATIC_CHAIN) when >> their bodies >> and other nested procedures within them did not refer to any of >> their >> variables. In Modula-3 we still need the static chain (ie, >> procedure >> environment) for procedure values so that they can be compared >> (tested >> for equality) properly. See the M3 language specification for >> details of >> procedure types, which define a procedure as a triple, including its >> environment. The fix makes use of DECL_NONLOCAL on function >> decls to mark >> them as needing the static chain to be preserved whenever a >> STATIC_CHAIN_EXPR >> is created for the decl. > > -- > ------------------------------------------------------------- > Rodney 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 Jan 11 08:36:20 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 11 Jan 2008 08:36:20 +0100 Subject: [M3devel] CVS repo changed, was: Re: scripts/pkgs In-Reply-To: References: Message-ID: <20080111083620.zxhq9ylw08ogw0oc@mail.elegosoft.com> Quoting Jay : > Please do "something" about this directory I created. > Like very much delete/obliterate it. If the history can be renamed > to another directory, say, pkginfo maybe, ok. > The files are all deleted but might be worth bringing back at some > point, maybe. > > On a case insensitive file system, this directory conflicts with the > PKGS file. > This was totally my fault and stupid. I was thinking "PKGS" was > named "PKGSDB", but that's just the variable name, and I should have > checked. I've moved cm3/scripts/pkgs to cm3/scripts/pkgs-obsolete on birch. This will break existing workspaces which contain it; you'll have to remove and update it, or edit CVS/Entries. If you use -P for checkout and update, empty directories will be removed on-the-fly. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Fri Jan 11 09:18:23 2008 From: mika at async.caltech.edu (Mika Nystrom) Date: Fri, 11 Jan 2008 00:18:23 -0800 Subject: [M3devel] nt386gnu is posix or win32? In-Reply-To: Your message of "Thu, 10 Jan 2008 08:35:05 PST." <6A267174-E215-48A6-BD0D-CB9AF4C13FE5@darko.org> Message-ID: <200801110818.m0B8IN44005691@camembert.async.caltech.edu> That program I talked about that I build under PM3/Klagenfurt, NT386GNU, is a multi-threaded real-time financial application that, at times, trades over a million dollars an hour's worth of stocks. It doesn't run on Windows for any technical reason. If it were completely up to me, it wouldn't. But I am still glad that Modula-3 works on Windows. Mika Darko writes: > >On 10/01/2008, at 3:16 AM, Jay wrote: >> By "serious" I mean, "ship real software using it". > >Then the question is: what is' real' software. I've shipped commercial >software (a smallish application) using the existing native back end, >which doesn't produce very good code, but the performance was >adequate. For many other applications this won't be the case. > >You should look at this issue the other way around: If it allows >people to build 'serious' software, they will use it. If you have an >interest in Windows and M3, this would be one of the most useful >things you could do, IMHO. > >Darko. From mika at async.caltech.edu Fri Jan 11 09:23:42 2008 From: mika at async.caltech.edu (Mika Nystrom) Date: Fri, 11 Jan 2008 00:23:42 -0800 Subject: [M3devel] could someone add __stdcall name mangling to m3cc please? In-Reply-To: Your message of "Thu, 10 Jan 2008 12:52:35 EST." <6D677FCA-D704-4E84-BD58-893C71D97B59@cs.purdue.edu> Message-ID: <200801110823.m0B8NgIn005977@camembert.async.caltech.edu> Hmm my Klagenfurt distribution of PM3 has a bunch of Trestle things in it. mentor even works sometimes. But I am not sure exactly when it came out or what kinds of tricks they were doing in the backend. One can track it down by following the link in an email I sent yesterday or the day before, but it's a binary distribution. Mika Tony Hosking writes: > >On Jan 10, 2008, at 7:42 AM, Jay wrote: > >> PM3 appears to ignore call_conv. >> Perhaps its NT386GNU uses usermode threads via cygwin1.dll and has >> no gui support, such as to not import any __stdcall functions??? > >Probably, yes. CM3 were the ones who added gui support. Anyway, I >think it is simply a matter of adding the appropriate attribute to >the function decls in the gcc backend. I believe that it supports >cdecl and stdcall. Are these all we need to specify? > >> http://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/m3/pm3/language/ >> modula3/m3compiler/m3cc/gcc/gcc/m3cg/m3.c?rev=1.1;content-type=text% >> 2Fx-cvsweb-markup;cvsroot=PM3 >> >> - Jay >> >> From: jayk123 at hotmail.com >> To: m3devel at elegosoft.com >> Date: Thu, 10 Jan 2008 12:40:22 +0000 >> Subject: [M3devel] could someone add __stdcall name mangling to >> m3cc please? >> >> Could someone out there (Tony?) familiar with the gcc backend >> have it not ignore call_conv and if call_conv is 1, append >> an at symbol and the number of bytes of parameters to the function >> name? >> (Even for zero, e.g. Sleep at 0, GetFileAttributes at 4). >> This would be I guess at least for "imported" functions. >> >> Not clear about calling function pointers, probably needs >> modification. >> call_conv 0 is "__cdecl" is push right to left, caller cleans up >> call_conv 1 is "__stdcall" is push right to left, callee cleans up >> There are various synonyms. >> With no command line switches, __cdecl is the compiler default. >> __stdcall is deemed more efficient, and is very widely used. >> >> Not clear about functions implemented in Modula-3. >> Probably won't occur? Maybe for callbacks? WindowProcs, thread >> entry point? >> >> This could/should be for NT386GNU only. >> The hypothetical other NT targets only have one calling convention >> each. >> >> I COULD do something sleazy here and generate little adapter >> functions, over in m3-win/import-libs esp. >> >> I'm still checking out pm3 to see what it does here. >> (as in cvs checkout, not "looking at") >> >> This'll clear up: >> >> RTOS.m3:27: undefined reference to `_FatalExit' >> RTOS.mo: In function `RTOS__GetMemory': >> RTOS.m3:75: undefined reference to `_VirtualAlloc' >> RTOS.m3:85: undefined reference to `_VirtualAlloc' >> RTOS.mo: In function `RTOS__InitMemory': >> RTOS.m3:96: undefined reference to `_VirtualAlloc' >> RTOS.m3:100: undefined reference to `_GetSystemInfo' >> RTOS.mo: In function `RTOS__Write': >> RTOS.m3:118: undefined reference to `_AllocConsole' >> RTOS.m3:119: undefined reference to `_GetStdHandle' >> RTOS.m3:122: undefined reference to `_WriteFile' >> RTPerfTool.mo: In function `RTPerfTool__Start': >> RTPerfTool.m3:19: undefined reference to `_ReadFile' >> RTPerfTool.m3:22: undefined reference to `_CloseHandle' >> RTPerfTool.mo: In function `RTPerfTool__Close': >> RTPerfTool.m3:28: undefined reference to `_CloseHandle' >> RTPerfTool.mo: In function `RTPerfTool__Send': >> RTPerfTool.m3:34: undefined reference to `_WriteFile' >> RTPerfTool.mo: In function `RTPerfTool__PrepHandle': >> RTPerfTool.m3:58: undefined reference to `_GetCurrentProcess' >> RTPerfTool.m3:59: undefined reference to `_DuplicateHandle' >> etc. >> >> I did think I was past these. I thought I built m3core and libm3 >> including linking (having even modified cm3.cfg) >> COULD be I'm using the wrong .libs, but: >> >> C:\cygwin\lib\w32api>nm libkernel32.a | findstr CreateFile >> 00000000 I __imp__CreateFileW at 28 >> 00000000 T _CreateFileW at 28 >> 00000000 I __imp__CreateFileMappingW at 24 >> 00000000 T _CreateFileMappingW at 24 >> 00000000 I __imp__CreateFileMappingA at 24 >> 00000000 T _CreateFileMappingA at 24 >> 00000000 I __imp__CreateFileA at 28 >> 00000000 T _CreateFileA at 28 >> >> C:\cygwin\lib\w32api>cd \MinGW\lib >> >> C:\MinGW\lib>nm libkernel32.a | findstr CreateFile >> 00000000 I __imp__CreateFileW at 28 >> 00000000 T _CreateFileW at 28 >> 00000000 I __imp__CreateFileMappingW at 24 >> 00000000 T _CreateFileMappingW at 24 >> 00000000 I __imp__CreateFileMappingA at 24 >> 00000000 T _CreateFileMappingA at 24 >> 00000000 I __imp__CreateFileA at 28 >> 00000000 T _CreateFileA at 28 >> >> I think at least THREE calling conventions should be supported -- >> __cdecl, __stdcall, __fastcall -- >> but oh well. We can live without __fastcall. >> Watcom has another calling convention, "watcall", and they let you >> describe calling conventions with #pragmas, neat. >> >> Thanks, >> - Jay >> >> Share life as it happens with the new Windows Live. Start sharing! >> Get the power of Windows + Web with the new Windows Live. Get it now! From mika at async.caltech.edu Fri Jan 11 09:25:22 2008 From: mika at async.caltech.edu (Mika Nystrom) Date: Fri, 11 Jan 2008 00:25:22 -0800 Subject: [M3devel] nt386gnu is posix or win32? In-Reply-To: Your message of "Thu, 10 Jan 2008 13:30:55 EST." Message-ID: <200801110825.m0B8PMSW006110@camembert.async.caltech.edu> ThreadWin32, I think. That's supposed to be one of the benefits of using Modula-3 under Windows :-) Tony Hosking writes: > >On Jan 9, 2008, at 6:08 PM, Jay wrote: ... >> that pthreads can work easily, increasing the dependency on >> cygwin1.dll. > >User-level (ThreadPosix) threads might work (using setjmp/longjmp for >thread switching -- I guess that is what PM3 used to do). Or did it >use ThreadWin32? I doubt ThreadPThread will work since I don't >think there is a pthreads binding for Win32 threads on NT, or is there? > >> While this is the "other" direction, given the dependency on as, >> and gcc to build m3cg, probably the horse is out of the barn. >> This is arguably a simpler answer, less hybrid. > >My strong preference is to tread NT386GNU (i.e., Cygwin based) as a >POSIX target, which might happen to use ThreadWin32. That way, the >usual POSIX/Cygwin flavor of things is preserved. > >> >> >> I think the analogy to cygwin/mingwin holds, possibly perfectly. >> >> Maybe this is two targets. >> NT386CYGWIN ? >> NT386MINGWIN ? >> >> (Which begs the point -- target naming.... NT386 vs. PPC_LINUX...OS >> +ARCH vs. ARCH + _ + OS, etc... but ARCH and OS aren't it, there is >> toolchain and C runtime in the mix..) >> >> Obviously SOMETHING is better than NOTHING and I have no useful >> binary distribution yet to show, so these questions are all very >> premature. >> >> I'm also unsure as to the "seriousness" of using the GNU tools. >> a) There don't seem to be many users of Modula-3 on Win32. >> b) Will such users accept/trust a non Microsoft toolchain? >> (Just what to do folks do with cygwin/mingwin? Build/ship real >> software?) >> >> From my point of view, the attractive thing about m3cg is I get the >> int64 stuff arguably out of the way easier. :) >> >> Licensing wise..probably a dependency on cygwin1.dll is not desirable. >> >> When I'm further along, er, actually, with my existing libm3.dll/ >> m3core.dll, I can see what the dependencies are. >> If it's just setjmp/lonjmp/memset, maybe try static linking (what >> is the licensing of that?) or link to msvcr*.dll. >> >> Maybe see if I can configure to use mingwin to compile/link except >> for m3cc. That sounds excellent. >> You would configure a CYGWIN_ROOT (gcc, ld, make, sh, libs) and a >> MINGWIN_ROOT (gcc, ld, libs). CYGWIN_ROOT would be required for >> building m3cc, and either could be used for building anything >> else. ?? That seems good, though I just thought of it, need more >> time to think and investigate. >> >> Later.. >> - Jay >> >> >> Share life as it happens with the new Windows Live. Start sharing! From mika at async.caltech.edu Fri Jan 11 09:32:56 2008 From: mika at async.caltech.edu (Mika Nystrom) Date: Fri, 11 Jan 2008 00:32:56 -0800 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: Your message of "Thu, 10 Jan 2008 15:58:36 CST." <4786950C.6020502@wichita.edu> Message-ID: <200801110832.m0B8Wuwg006472@camembert.async.caltech.edu> This reminds me, there used to be a bug in PM3... has it been fixed? This code was unreliable: PROCEDURE P() = VAR a : T; PROCEDURE Q(b : U) = BEGIN a := saveSomethingAbout(b) END Q; BEGIN CallVisitor(Q) END P; (Note that the M3 report says that while inner procedures may not be assigned to variables, they may be passed as procedure parameters. The workaround for the compiler bug is to use something called "object-oriented programming".) "Rodney M. Bates" writes: >Antony, I can' tell from your posts whether this is what you did or not, but: > >m3gdb really needs for there to be a static link allocated space and stored, for >_every_ nested procedure, even if there is nothing in the compiled code that uses >it. m3gdb accesses/passes static links in several situations, e.g., a user-typed >call on a nested procedure constant, user-typed assignment of a nested procedure >value to a procedure variable, user-typed call on a procedure variable (whose >value might be nested or top-level), and just access to a variable that is nonlocal >to the current frame. > >All of this has been implemented for some time, although it is distressingly >fragile. I have a number of times gone back in and fixed some case I thought >I had working earlier. I recently started seeing "invalid static link" messages >again from m3gdb, after a hiatus. > >The variable access function is particularly important to me, as I often use nested >procedures, especially a recursive nested procedure inside a parent that holds variables >that are local to the whole recursive (dynamic) nest but not fully global. Especially when >the recursion is umpteen levels deep, it is a real pain to have to figure out how >many levels to go "up" in the dynamic chain just to get to the immediate static parent >to print one of its variables. And if you want to type a expression that mixes a local >and a nonlocal variable, the feature is almost essential. > >So, I propose static links be there always, with the possible exception of at very >high optimization levels. > > > >Antony Hosking wrote: >> CVSROOT: /usr/cvs >> Changes by: hosking at birch. 08/01/07 20:20:48 >> >> Modified files: >> cm3/m3-sys/m3cc/gcc/gcc/: tree-nested.c >> cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c >> >> Log message: >> Fix bug in procedure value comparison as revealed by p035 of m3tests. >> The problem was that convert_all_function_calls was marking nested function >> decls as *not* needing a static chain (DECL_NO_STATIC_CHAIN) when their bodies >> and other nested procedures within them did not refer to any of their >> variables. In Modula-3 we still need the static chain (ie, procedure >> environment) for procedure values so that they can be compared (tested >> for equality) properly. See the M3 language specification for details of >> procedure types, which define a procedure as a triple, including its >> environment. The fix makes use of DECL_NONLOCAL on function decls to mark >> them as needing the static chain to be preserved whenever a STATIC_CHAIN_EXPR >> is created for the decl. >> >> > >-- >------------------------------------------------------------- >Rodney 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 Jan 11 12:36:14 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 11 Jan 2008 12:36:14 +0100 Subject: [M3devel] M3 project references, was: Re: nt386gnu is posix or win32? In-Reply-To: <200801110818.m0B8IN44005691@camembert.async.caltech.edu> References: <200801110818.m0B8IN44005691@camembert.async.caltech.edu> Message-ID: <20080111123614.txul50nyqs80oowg@mail.elegosoft.com> Quoting Mika Nystrom : > That program I talked about that I build under PM3/Klagenfurt, > NT386GNU, is a multi-threaded real-time financial application that, > at times, trades over a million dollars an hour's worth of stocks. > It doesn't run on Windows for any technical reason. If it were > completely up to me, it wouldn't. But I am still glad that Modula-3 > works on Windows. Cool. I didn't know that M3 was really used in such commercial projects. It would be great if we had a list of such projects on our web site as references. Would that be possible with your program/customer? Are there other commercial projects we could mention? Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Fri Jan 11 13:32:24 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 11 Jan 2008 13:32:24 +0100 Subject: [M3devel] Darwin upgrade/fingerprint error In-Reply-To: References: <20080104141523.GC1459@ted.stsp.lan> <65C183A8-6102-49E9-9C38-8D59C966E42D@cs.purdue.edu> Message-ID: <20080111133224.kpsd1ehwso4go048@mail.elegosoft.com> Quoting Jay : > (probably OMIT_GCC=1 on the second clean and build; I assume it has > no dependency into the tree and it'd just be building the same thing > a second time, slowly) Late answer, but I can hardly catch up with all the mail I get. Even CM3 is so active these days (which is a good thing :). You are right, m3cc does not depend on any other CM3 package and needs to be built just once. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From hosking at cs.purdue.edu Fri Jan 11 16:17:00 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 11 Jan 2008 10:17:00 -0500 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <200801110832.m0B8Wuwg006472@camembert.async.caltech.edu> References: <200801110832.m0B8Wuwg006472@camembert.async.caltech.edu> Message-ID: <85B79C0A-B69E-4E12-B938-6A374398568D@cs.purdue.edu> Certainly fixed in CM3. On Jan 11, 2008, at 3:32 AM, Mika Nystrom wrote: > This reminds me, there used to be a bug in PM3... has it been > fixed? This code > was unreliable: > > PROCEDURE P() = > > VAR a : T; > > PROCEDURE Q(b : U) = > BEGIN a := saveSomethingAbout(b) END Q; > > BEGIN CallVisitor(Q) END P; > > (Note that the M3 report says that while inner procedures may not > be assigned to variables, they may be passed as procedure parameters. > The workaround for the compiler bug is to use something called > "object-oriented programming".) > > "Rodney M. Bates" writes: >> Antony, I can' tell from your posts whether this is what you did >> or not, but: >> >> m3gdb really needs for there to be a static link allocated space >> and stored, for >> _every_ nested procedure, even if there is nothing in the compiled >> code that uses >> it. m3gdb accesses/passes static links in several situations, >> e.g., a user-typed >> call on a nested procedure constant, user-typed assignment of a >> nested procedure >> value to a procedure variable, user-typed call on a procedure >> variable (whose >> value might be nested or top-level), and just access to a variable >> that is nonlocal >> to the current frame. >> >> All of this has been implemented for some time, although it is >> distressingly >> fragile. I have a number of times gone back in and fixed some >> case I thought >> I had working earlier. I recently started seeing "invalid static >> link" messages >> again from m3gdb, after a hiatus. >> >> The variable access function is particularly important to me, as I >> often use nested >> procedures, especially a recursive nested procedure inside a >> parent that holds variables >> that are local to the whole recursive (dynamic) nest but not fully >> global. Especially when >> the recursion is umpteen levels deep, it is a real pain to have to >> figure out how >> many levels to go "up" in the dynamic chain just to get to the >> immediate static parent >> to print one of its variables. And if you want to type a >> expression that mixes a local >> and a nonlocal variable, the feature is almost essential. >> >> So, I propose static links be there always, with the possible >> exception of at very >> high optimization levels. >> >> >> >> Antony Hosking wrote: >>> CVSROOT: /usr/cvs >>> Changes by: hosking at birch. 08/01/07 20:20:48 >>> >>> Modified files: >>> cm3/m3-sys/m3cc/gcc/gcc/: tree-nested.c >>> cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c >>> >>> Log message: >>> Fix bug in procedure value comparison as revealed by p035 of >>> m3tests. >>> The problem was that convert_all_function_calls was marking >>> nested function >>> decls as *not* needing a static chain (DECL_NO_STATIC_CHAIN) >>> when their bodies >>> and other nested procedures within them did not refer to any of >>> their >>> variables. In Modula-3 we still need the static chain (ie, >>> procedure >>> environment) for procedure values so that they can be compared >>> (tested >>> for equality) properly. See the M3 language specification for >>> details of >>> procedure types, which define a procedure as a triple, including >>> its >>> environment. The fix makes use of DECL_NONLOCAL on function >>> decls to mark >>> them as needing the static chain to be preserved whenever a >>> STATIC_CHAIN_EXPR >>> is created for the decl. >>> >>> >> >> -- >> ------------------------------------------------------------- >> Rodney 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 Jan 11 18:10:36 2008 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Fri, 11 Jan 2008 11:10:36 -0600 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <200801110832.m0B8Wuwg006472@camembert.async.caltech.edu> References: <200801110832.m0B8Wuwg006472@camembert.async.caltech.edu> Message-ID: <4787A30C.3060709@wichita.edu> I use what I think is the pattern you refer to regularly. A callback "visit" procedure (which is nested) is passed as a parameter and it accesses nonlocal variables. I just reran a test driver main program that does massive tests of a particular module and uses this pattern extensively. No problems showed up, using PM3 integrated backend, PM3 with gcc backend, and a recent CM3. I still run a lot of stuff PM3-compiled, but my PM3 has somehow diverged significantly from the official distribution, and every time I start to resolve this, it quickly gets a lot deeper than I want to take time for. Mika Nystrom wrote: > This reminds me, there used to be a bug in PM3... has it been fixed? This code > was unreliable: > > PROCEDURE P() = > > VAR a : T; > > PROCEDURE Q(b : U) = > BEGIN a := saveSomethingAbout(b) END Q; > > BEGIN CallVisitor(Q) END P; > > (Note that the M3 report says that while inner procedures may not > be assigned to variables, they may be passed as procedure parameters. > The workaround for the compiler bug is to use something called > "object-oriented programming".) > -- ------------------------------------------------------------- Rodney 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 Jan 11 19:16:44 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 11 Jan 2008 13:16:44 -0500 Subject: [M3devel] could someone add __stdcall name mangling to m3cc please? In-Reply-To: References: Your message of "Wed, 09 Jan 2008 17:25:31 PST." <200801100131.m0A1VQYS034516@camembert.async.caltech.edu> Message-ID: <6D467648-44A7-48DC-AB8D-27B3AC19EBB0@cs.purdue.edu> I just added support for this. Let me know if it seems to work (or not! :-) ). On Jan 10, 2008, at 7:40 AM, Jay wrote: > Could someone out there (Tony?) familiar with the gcc backend > have it not ignore call_conv and if call_conv is 1, append > an at symbol and the number of bytes of parameters to the function > name? > (Even for zero, e.g. Sleep at 0, GetFileAttributes at 4). > This would be I guess at least for "imported" functions. > > Not clear about calling function pointers, probably needs > modification. > call_conv 0 is "__cdecl" is push right to left, caller cleans up > call_conv 1 is "__stdcall" is push right to left, callee cleans up > There are various synonyms. > With no command line switches, __cdecl is the compiler default. > __stdcall is deemed more efficient, and is very widely used. > > Not clear about functions implemented in Modula-3. > Probably won't occur? Maybe for callbacks? WindowProcs, thread > entry point? > > This could/should be for NT386GNU only. > The hypothetical other NT targets only have one calling convention > each. > > I COULD do something sleazy here and generate little adapter > functions, over in m3-win/import-libs esp. > > I'm still checking out pm3 to see what it does here. > (as in cvs checkout, not "looking at") > > This'll clear up: > > RTOS.m3:27: undefined reference to `_FatalExit' > RTOS.mo: In function `RTOS__GetMemory': > RTOS.m3:75: undefined reference to `_VirtualAlloc' > RTOS.m3:85: undefined reference to `_VirtualAlloc' > RTOS.mo: In function `RTOS__InitMemory': > RTOS.m3:96: undefined reference to `_VirtualAlloc' > RTOS.m3:100: undefined reference to `_GetSystemInfo' > RTOS.mo: In function `RTOS__Write': > RTOS.m3:118: undefined reference to `_AllocConsole' > RTOS.m3:119: undefined reference to `_GetStdHandle' > RTOS.m3:122: undefined reference to `_WriteFile' > RTPerfTool.mo: In function `RTPerfTool__Start': > RTPerfTool.m3:19: undefined reference to `_ReadFile' > RTPerfTool.m3:22: undefined reference to `_CloseHandle' > RTPerfTool.mo: In function `RTPerfTool__Close': > RTPerfTool.m3:28: undefined reference to `_CloseHandle' > RTPerfTool.mo: In function `RTPerfTool__Send': > RTPerfTool.m3:34: undefined reference to `_WriteFile' > RTPerfTool.mo: In function `RTPerfTool__PrepHandle': > RTPerfTool.m3:58: undefined reference to `_GetCurrentProcess' > RTPerfTool.m3:59: undefined reference to `_DuplicateHandle' > etc. > > I did think I was past these. I thought I built m3core and libm3 > including linking (having even modified cm3.cfg) > COULD be I'm using the wrong .libs, but: > > C:\cygwin\lib\w32api>nm libkernel32.a | findstr CreateFile > 00000000 I __imp__CreateFileW at 28 > 00000000 T _CreateFileW at 28 > 00000000 I __imp__CreateFileMappingW at 24 > 00000000 T _CreateFileMappingW at 24 > 00000000 I __imp__CreateFileMappingA at 24 > 00000000 T _CreateFileMappingA at 24 > 00000000 I __imp__CreateFileA at 28 > 00000000 T _CreateFileA at 28 > > C:\cygwin\lib\w32api>cd \MinGW\lib > > C:\MinGW\lib>nm libkernel32.a | findstr CreateFile > 00000000 I __imp__CreateFileW at 28 > 00000000 T _CreateFileW at 28 > 00000000 I __imp__CreateFileMappingW at 24 > 00000000 T _CreateFileMappingW at 24 > 00000000 I __imp__CreateFileMappingA at 24 > 00000000 T _CreateFileMappingA at 24 > 00000000 I __imp__CreateFileA at 28 > 00000000 T _CreateFileA at 28 > > I think at least THREE calling conventions should be supported -- > __cdecl, __stdcall, __fastcall -- > but oh well. We can live without __fastcall. > Watcom has another calling convention, "watcall", and they let you > describe calling conventions with #pragmas, neat. > > Thanks, > - Jay > > Share life as it happens with the new Windows Live. Start sharing! From hosking at cs.purdue.edu Fri Jan 11 19:24:49 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 11 Jan 2008 13:24:49 -0500 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <4786950C.6020502@wichita.edu> References: <20080107192048.3FFBB10D461D@birch.elegosoft.com> <4786950C.6020502@wichita.edu> Message-ID: Rodney, Can you confirm that the static chains are now there for your purposes with the latest m3cc? As far as I know, *any* nested procedure that might be called *will* now have a static chain generated for it. I don't think I need to make any other changes to support this. The reasoning is as follows: load_static_link is generated by the M3 front-end compiler whenever a nested function is called, and whenever a procedure value is created from a nested function -- ie, when passing a nested procedure as an actual -- since the value includes the static link as its environment. This is what fixed p035 of m3tests. -- Tony On Jan 10, 2008, at 4:58 PM, Rodney M. Bates wrote: > Antony, I can' tell from your posts whether this is what you did or > not, but: > > m3gdb really needs for there to be a static link allocated space > and stored, for > _every_ nested procedure, even if there is nothing in the compiled > code that uses > it. m3gdb accesses/passes static links in several situations, > e.g., a user-typed > call on a nested procedure constant, user-typed assignment of a > nested procedure > value to a procedure variable, user-typed call on a procedure > variable (whose > value might be nested or top-level), and just access to a variable > that is nonlocal > to the current frame. > > All of this has been implemented for some time, although it is > distressingly > fragile. I have a number of times gone back in and fixed some case > I thought > I had working earlier. I recently started seeing "invalid static > link" messages > again from m3gdb, after a hiatus. > > The variable access function is particularly important to me, as I > often use nested > procedures, especially a recursive nested procedure inside a parent > that holds variables > that are local to the whole recursive (dynamic) nest but not fully > global. Especially when > the recursion is umpteen levels deep, it is a real pain to have to > figure out how > many levels to go "up" in the dynamic chain just to get to the > immediate static parent > to print one of its variables. And if you want to type a expression > that mixes a local > and a nonlocal variable, the feature is almost essential. > > So, I propose static links be there always, with the possible > exception of at very > high optimization levels. > > > > Antony Hosking wrote: >> CVSROOT: /usr/cvs >> Changes by: hosking at birch. 08/01/07 20:20:48 >> Modified files: >> cm3/m3-sys/m3cc/gcc/gcc/: tree-nested.c cm3/m3-sys/m3cc/gcc/gcc/ >> m3cg/: parse.c Log message: >> Fix bug in procedure value comparison as revealed by p035 of >> m3tests. >> The problem was that convert_all_function_calls was marking >> nested function >> decls as *not* needing a static chain (DECL_NO_STATIC_CHAIN) when >> their bodies >> and other nested procedures within them did not refer to any of >> their >> variables. In Modula-3 we still need the static chain (ie, >> procedure >> environment) for procedure values so that they can be compared >> (tested >> for equality) properly. See the M3 language specification for >> details of >> procedure types, which define a procedure as a triple, including its >> environment. The fix makes use of DECL_NONLOCAL on function >> decls to mark >> them as needing the static chain to be preserved whenever a >> STATIC_CHAIN_EXPR >> is created for the decl. > > -- > ------------------------------------------------------------- > Rodney 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 Jan 12 01:20:04 2008 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Fri, 11 Jan 2008 18:20:04 -0600 Subject: [M3devel] I need CVS help again Message-ID: <478807B4.2080100@wichita.edu> I have gotten myself into this jam before, as a result of trying to develop/test on more than one local machine with more than one M3 installation. I have more questions on how to figure out what happened and how to fix it. I did a cvs update when, I guess, I had local uncommitted edits. I got messages saying that changes were being merged and there were conflicts. For example, I now have local files named: .#m3-eval.c.1.12 m3-eval.c and in CVS/Entries, the line: /m3-eval.c/1.14/Result of merge... Have I correctly surmised that this all means 1) prior to the update, CVS/Entries would have said: /m3-eval/c/1.12... meaning 1.12 was the last version cvs knew I had, 2) But my local m3-eval.c had local changes relative to 1.12, 3) And .#m3-eval.c.1.12 is a copy of that locally changed m3-eval.c, as it was prior to the cvs update, 4) The latest version cvs has in its repository is 1.14, and 5) My current local m3-eval.c was generated by merging version 1.14 from the repository with what is now in .#m3-eval.c.1.12? Is there a simple way to get cvs to diff between its stored version 1.12 and my .#m3-eval.1.12? -- ------------------------------------------------------------- Rodney 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 Sat Jan 12 01:22:16 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 12 Jan 2008 01:22:16 +0100 Subject: [M3devel] I need CVS help again In-Reply-To: <478807B4.2080100@wichita.edu> References: <478807B4.2080100@wichita.edu> Message-ID: <20080112012216.k4d438pquc0sw8os@mail.elegosoft.com> Quoting "Rodney M. Bates" : > I have gotten myself into this jam before, as a result of trying to > develop/test on more than one local machine with more than one M3 > installation. I have more questions on how to figure out what happened > and how to fix it. > > I did a cvs update when, I guess, I had local uncommitted edits. > I got messages saying that changes were being merged and there were > conflicts. For example, I now have local files named: > > .#m3-eval.c.1.12 > m3-eval.c > > and in CVS/Entries, the line: > > /m3-eval.c/1.14/Result of merge... > > Have I correctly surmised that this all means > > 1) prior to the update, CVS/Entries would have said: > > /m3-eval/c/1.12... > > meaning 1.12 was the last version cvs knew I had, > > 2) But my local m3-eval.c had local changes relative to 1.12, > > 3) And .#m3-eval.c.1.12 is a copy of that locally changed > m3-eval.c, as it was prior to the cvs update, Yes, this should be your original file. > 4) The latest version cvs has in its repository is 1.14, and Yes. > 5) My current local m3-eval.c was generated by merging version > 1.14 from the repository with what is now in .#m3-eval.c.1.12? Yes. You should simply find the comflicts in m3-eval.c by looking for lines with <<<< and ===== and >>>>. Often they are easy to edit manually. > Is there a simple way to get cvs to diff between its stored > version 1.12 and my .#m3-eval.1.12? You can checkout any version into your workspace and compare locally: cvs up -p -r 1.12 m3-eval.c > m3-eval.c.1.12 cvs up -p -r 1.14 m3-eval.c > m3-eval.c.1.14 diff -u .m3-eval.c.1.12 \#m3-eval.1.12 ... HTH, Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Jan 12 14:27:23 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 12 Jan 2008 13:27:23 +0000 Subject: [M3devel] could someone add __stdcall name mangling to m3cc please? In-Reply-To: <6D467648-44A7-48DC-AB8D-27B3AC19EBB0@cs.purdue.edu> References: Your message of "Wed, 09 Jan 2008 17:25:31 PST." <200801100131.m0A1VQYS034516@camembert.async.caltech.edu> <6D467648-44A7-48DC-AB8D-27B3AC19EBB0@cs.purdue.edu> Message-ID: Thanks, but not quite. The number of parameters times four needs to be appended to the name, in decimal. But I'm just getting 0. That is, gcc is handling the underlying detail, but you aren't giving it enough infomrmation. I'll see if I can bang out those temporary wrappers automatically.. (a Quake programming challenge, that I've already invented the hard part of I think -- Quake can't do math..) - Jay > CC: m3devel at elegosoft.com> From: hosking at cs.purdue.edu> Subject: Re: [M3devel] could someone add __stdcall name mangling to m3cc please?> Date: Fri, 11 Jan 2008 13:16:44 -0500> To: jayk123 at hotmail.com> > I just added support for this. Let me know if it seems to work (or > not! :-) ).> > > On Jan 10, 2008, at 7:40 AM, Jay wrote:> > > Could someone out there (Tony?) familiar with the gcc backend> > have it not ignore call_conv and if call_conv is 1, append> > an at symbol and the number of bytes of parameters to the function > > name?> > (Even for zero, e.g. Sleep at 0, GetFileAttributes at 4).> > This would be I guess at least for "imported" functions.> >> > Not clear about calling function pointers, probably needs > > modification.> > call_conv 0 is "__cdecl" is push right to left, caller cleans up> > call_conv 1 is "__stdcall" is push right to left, callee cleans up> > There are various synonyms.> > With no command line switches, __cdecl is the compiler default.> > __stdcall is deemed more efficient, and is very widely used.> >> > Not clear about functions implemented in Modula-3.> > Probably won't occur? Maybe for callbacks? WindowProcs, thread > > entry point?> >> > This could/should be for NT386GNU only.> > The hypothetical other NT targets only have one calling convention > > each.> >> > I COULD do something sleazy here and generate little adapter > > functions, over in m3-win/import-libs esp.> >> > I'm still checking out pm3 to see what it does here.> > (as in cvs checkout, not "looking at")> >> > This'll clear up:> >> > RTOS.m3:27: undefined reference to `_FatalExit'> > RTOS.mo: In function `RTOS__GetMemory':> > RTOS.m3:75: undefined reference to `_VirtualAlloc'> > RTOS.m3:85: undefined reference to `_VirtualAlloc'> > RTOS.mo: In function `RTOS__InitMemory':> > RTOS.m3:96: undefined reference to `_VirtualAlloc'> > RTOS.m3:100: undefined reference to `_GetSystemInfo'> > RTOS.mo: In function `RTOS__Write':> > RTOS.m3:118: undefined reference to `_AllocConsole'> > RTOS.m3:119: undefined reference to `_GetStdHandle'> > RTOS.m3:122: undefined reference to `_WriteFile'> > RTPerfTool.mo: In function `RTPerfTool__Start':> > RTPerfTool.m3:19: undefined reference to `_ReadFile'> > RTPerfTool.m3:22: undefined reference to `_CloseHandle'> > RTPerfTool.mo: In function `RTPerfTool__Close':> > RTPerfTool.m3:28: undefined reference to `_CloseHandle'> > RTPerfTool.mo: In function `RTPerfTool__Send':> > RTPerfTool.m3:34: undefined reference to `_WriteFile'> > RTPerfTool.mo: In function `RTPerfTool__PrepHandle':> > RTPerfTool.m3:58: undefined reference to `_GetCurrentProcess'> > RTPerfTool.m3:59: undefined reference to `_DuplicateHandle'> > etc.> >> > I did think I was past these. I thought I built m3core and libm3 > > including linking (having even modified cm3.cfg)> > COULD be I'm using the wrong .libs, but:> >> > C:\cygwin\lib\w32api>nm libkernel32.a | findstr CreateFile> > 00000000 I __imp__CreateFileW at 28> > 00000000 T _CreateFileW at 28> > 00000000 I __imp__CreateFileMappingW at 24> > 00000000 T _CreateFileMappingW at 24> > 00000000 I __imp__CreateFileMappingA at 24> > 00000000 T _CreateFileMappingA at 24> > 00000000 I __imp__CreateFileA at 28> > 00000000 T _CreateFileA at 28> >> > C:\cygwin\lib\w32api>cd \MinGW\lib> >> > C:\MinGW\lib>nm libkernel32.a | findstr CreateFile> > 00000000 I __imp__CreateFileW at 28> > 00000000 T _CreateFileW at 28> > 00000000 I __imp__CreateFileMappingW at 24> > 00000000 T _CreateFileMappingW at 24> > 00000000 I __imp__CreateFileMappingA at 24> > 00000000 T _CreateFileMappingA at 24> > 00000000 I __imp__CreateFileA at 28> > 00000000 T _CreateFileA at 28> >> > I think at least THREE calling conventions should be supported -- > > __cdecl, __stdcall, __fastcall --> > but oh well. We can live without __fastcall.> > Watcom has another calling convention, "watcall", and they let you > > describe calling conventions with #pragmas, neat.> >> > Thanks,> > - Jay> >> > Share life as it happens with the new Windows Live. Start sharing!> _________________________________________________________________ Make distant family not so distant with Windows Vista? + Windows Live?. http://www.microsoft.com/windows/digitallife/keepintouch.mspx?ocid=TXT_TAGLM_CPC_VideoChat_distantfamily_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sat Jan 12 16:41:26 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 12 Jan 2008 10:41:26 -0500 Subject: [M3devel] could someone add __stdcall name mangling to m3cc please? In-Reply-To: References: Your message of "Wed, 09 Jan 2008 17:25:31 PST." <200801100131.m0A1VQYS034516@camembert.async.caltech.edu> <6D467648-44A7-48DC-AB8D-27B3AC19EBB0@cs.purdue.edu> Message-ID: I'm not sure what you were trying to do with parse.c by adding a parameter (nargs*4) to the stdcall attribute, but that probably doesn't do anything interesting. The problem appears to be because on external function decls the parameter decls are currently being ignored by cm3cg. If I fix parse.c to add the params for those then it should work properly with the stdcall attribute. On Jan 12, 2008, at 8:27 AM, Jay wrote: > Thanks, but not quite. The number of parameters times four needs to > be appended to the name, in decimal. > But I'm just getting 0. > That is, gcc is handling the underlying detail, but you aren't > giving it enough infomrmation. > I'll see if I can bang out those temporary wrappers automatically.. > (a Quake programming challenge, that I've already invented the hard > part of I think -- Quake can't do math..) > > - Jay > > > > CC: m3devel at elegosoft.com > > From: hosking at cs.purdue.edu > > Subject: Re: [M3devel] could someone add __stdcall name mangling > to m3cc please? > > Date: Fri, 11 Jan 2008 13:16:44 -0500 > > To: jayk123 at hotmail.com > > > > I just added support for this. Let me know if it seems to work (or > > not! :-) ). > > > > > > On Jan 10, 2008, at 7:40 AM, Jay wrote: > > > > > Could someone out there (Tony?) familiar with the gcc backend > > > have it not ignore call_conv and if call_conv is 1, append > > > an at symbol and the number of bytes of parameters to the function > > > name? > > > (Even for zero, e.g. Sleep at 0, GetFileAttributes at 4). > > > This would be I guess at least for "imported" functions. > > > > > > Not clear about calling function pointers, probably needs > > > modification. > > > call_conv 0 is "__cdecl" is push right to left, caller cleans up > > > call_conv 1 is "__stdcall" is push right to left, callee cleans up > > > There are various synonyms. > > > With no command line switches, __cdecl is the compiler default. > > > __stdcall is deemed more efficient, and is very widely used. > > > > > > Not clear about functions implemented in Modula-3. > > > Probably won't occur? Maybe for callbacks? WindowProcs, thread > > > entry point? > > > > > > This could/should be for NT386GNU only. > > > The hypothetical other NT targets only have one calling convention > > > each. > > > > > > I COULD do something sleazy here and generate little adapter > > > functions, over in m3-win/import-libs esp. > > > > > > I'm still checking out pm3 to see what it does here. > > > (as in cvs checkout, not "looking at") > > > > > > This'll clear up: > > > > > > RTOS.m3:27: undefined reference to `_FatalExit' > > > RTOS.mo: In function `RTOS__GetMemory': > > > RTOS.m3:75: undefined reference to `_VirtualAlloc' > > > RTOS.m3:85: undefined reference to `_VirtualAlloc' > > > RTOS.mo: In function `RTOS__InitMemory': > > > RTOS.m3:96: undefined reference to `_VirtualAlloc' > > > RTOS.m3:100: undefined reference to `_GetSystemInfo' > > > RTOS.mo: In function `RTOS__Write': > > > RTOS.m3:118: undefined reference to `_AllocConsole' > > > RTOS.m3:119: undefined reference to `_GetStdHandle' > > > RTOS.m3:122: undefined reference to `_WriteFile' > > > RTPerfTool.mo: In function `RTPerfTool__Start': > > > RTPerfTool.m3:19: undefined reference to `_ReadFile' > > > RTPerfTool.m3:22: undefined reference to `_CloseHandle' > > > RTPerfTool.mo: In function `RTPerfTool__Close': > > > RTPerfTool.m3:28: undefined reference to `_CloseHandle' > > > RTPerfTool.mo: In function `RTPerfTool__Send': > > > RTPerfTool.m3:34: undefined reference to `_WriteFile' > > > RTPerfTool.mo: In function `RTPerfTool__PrepHandle': > > > RTPerfTool.m3:58: undefined reference to `_GetCurrentProcess' > > > RTPerfTool.m3:59: undefined reference to `_DuplicateHandle' > > > etc. > > > > > > I did think I was past these. I thought I built m3core and libm3 > > > including linking (having even modified cm3.cfg) > > > COULD be I'm using the wrong .libs, but: > > > > > > C:\cygwin\lib\w32api>nm libkernel32.a | findstr CreateFile > > > 00000000 I __imp__CreateFileW at 28 > > > 00000000 T _CreateFileW at 28 > > > 00000000 I __imp__CreateFileMappingW at 24 > > > 00000000 T _CreateFileMappingW at 24 > > > 00000000 I __imp__CreateFileMappingA at 24 > > > 00000000 T _CreateFileMappingA at 24 > > > 00000000 I __imp__CreateFileA at 28 > > > 00000000 T _CreateFileA at 28 > > > > > > C:\cygwin\lib\w32api>cd \MinGW\lib > > > > > > C:\MinGW\lib>nm libkernel32.a | findstr CreateFile > > > 00000000 I __imp__CreateFileW at 28 > > > 00000000 T _CreateFileW at 28 > > > 00000000 I __imp__CreateFileMappingW at 24 > > > 00000000 T _CreateFileMappingW at 24 > > > 00000000 I __imp__CreateFileMappingA at 24 > > > 00000000 T _CreateFileMappingA at 24 > > > 00000000 I __imp__CreateFileA at 28 > > > 00000000 T _CreateFileA at 28 > > > > > > I think at least THREE calling conventions should be supported -- > > > __cdecl, __stdcall, __fastcall -- > > > but oh well. We can live without __fastcall. > > > Watcom has another calling convention, "watcall", and they let you > > > describe calling conventions with #pragmas, neat. > > > > > > Thanks, > > > - Jay > > > > > > Share life as it happens with the new Windows Live. Start sharing! > > > > > Make distant family not so distant with Windows Vista? + Windows > Live?. Start now! From jayk123 at hotmail.com Sat Jan 12 19:13:27 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 12 Jan 2008 18:13:27 +0000 Subject: [M3devel] could someone add __stdcall name mangling to m3cc please? In-Reply-To: References: Your message of "Wed, 09 Jan 2008 17:25:31 PST." <200801100131.m0A1VQYS034516@camembert.async.caltech.edu> <6D467648-44A7-48DC-AB8D-27B3AC19EBB0@cs.purdue.edu> Message-ID: Tony, Sorry, I didn't mean to check those in. Those were wild guesses that I hadn't tested yet.I put it back. Thanks for catching that. - Jay > CC: m3devel at elegosoft.com> From: hosking at cs.purdue.edu> Subject: Re: [M3devel] could someone add __stdcall name mangling to m3cc please?> Date: Sat, 12 Jan 2008 10:41:26 -0500> To: jayk123 at hotmail.com> > I'm not sure what you were trying to do with parse.c by adding a > parameter (nargs*4) to the stdcall attribute, but that probably > doesn't do anything interesting. The problem appears to be because > on external function decls the parameter decls are currently being > ignored by cm3cg. If I fix parse.c to add the params for those then > it should work properly with the stdcall attribute.> > On Jan 12, 2008, at 8:27 AM, Jay wrote:> > > Thanks, but not quite. The number of parameters times four needs to > > be appended to the name, in decimal.> > But I'm just getting 0.> > That is, gcc is handling the underlying detail, but you aren't > > giving it enough infomrmation.> > I'll see if I can bang out those temporary wrappers automatically.. > > (a Quake programming challenge, that I've already invented the hard > > part of I think -- Quake can't do math..)> >> > - Jay> >> >> > > CC: m3devel at elegosoft.com> > > From: hosking at cs.purdue.edu> > > Subject: Re: [M3devel] could someone add __stdcall name mangling > > to m3cc please?> > > Date: Fri, 11 Jan 2008 13:16:44 -0500> > > To: jayk123 at hotmail.com> > >> > > I just added support for this. Let me know if it seems to work (or> > > not! :-) ).> > >> > >> > > On Jan 10, 2008, at 7:40 AM, Jay wrote:> > >> > > > Could someone out there (Tony?) familiar with the gcc backend> > > > have it not ignore call_conv and if call_conv is 1, append> > > > an at symbol and the number of bytes of parameters to the function> > > > name?> > > > (Even for zero, e.g. Sleep at 0, GetFileAttributes at 4).> > > > This would be I guess at least for "imported" functions.> > > >> > > > Not clear about calling function pointers, probably needs> > > > modification.> > > > call_conv 0 is "__cdecl" is push right to left, caller cleans up> > > > call_conv 1 is "__stdcall" is push right to left, callee cleans up> > > > There are various synonyms.> > > > With no command line switches, __cdecl is the compiler default.> > > > __stdcall is deemed more efficient, and is very widely used.> > > >> > > > Not clear about functions implemented in Modula-3.> > > > Probably won't occur? Maybe for callbacks? WindowProcs, thread> > > > entry point?> > > >> > > > This could/should be for NT386GNU only.> > > > The hypothetical other NT targets only have one calling convention> > > > each.> > > >> > > > I COULD do something sleazy here and generate little adapter> > > > functions, over in m3-win/import-libs esp.> > > >> > > > I'm still checking out pm3 to see what it does here.> > > > (as in cvs checkout, not "looking at")> > > >> > > > This'll clear up:> > > >> > > > RTOS.m3:27: undefined reference to `_FatalExit'> > > > RTOS.mo: In function `RTOS__GetMemory':> > > > RTOS.m3:75: undefined reference to `_VirtualAlloc'> > > > RTOS.m3:85: undefined reference to `_VirtualAlloc'> > > > RTOS.mo: In function `RTOS__InitMemory':> > > > RTOS.m3:96: undefined reference to `_VirtualAlloc'> > > > RTOS.m3:100: undefined reference to `_GetSystemInfo'> > > > RTOS.mo: In function `RTOS__Write':> > > > RTOS.m3:118: undefined reference to `_AllocConsole'> > > > RTOS.m3:119: undefined reference to `_GetStdHandle'> > > > RTOS.m3:122: undefined reference to `_WriteFile'> > > > RTPerfTool.mo: In function `RTPerfTool__Start':> > > > RTPerfTool.m3:19: undefined reference to `_ReadFile'> > > > RTPerfTool.m3:22: undefined reference to `_CloseHandle'> > > > RTPerfTool.mo: In function `RTPerfTool__Close':> > > > RTPerfTool.m3:28: undefined reference to `_CloseHandle'> > > > RTPerfTool.mo: In function `RTPerfTool__Send':> > > > RTPerfTool.m3:34: undefined reference to `_WriteFile'> > > > RTPerfTool.mo: In function `RTPerfTool__PrepHandle':> > > > RTPerfTool.m3:58: undefined reference to `_GetCurrentProcess'> > > > RTPerfTool.m3:59: undefined reference to `_DuplicateHandle'> > > > etc.> > > >> > > > I did think I was past these. I thought I built m3core and libm3> > > > including linking (having even modified cm3.cfg)> > > > COULD be I'm using the wrong .libs, but:> > > >> > > > C:\cygwin\lib\w32api>nm libkernel32.a | findstr CreateFile> > > > 00000000 I __imp__CreateFileW at 28> > > > 00000000 T _CreateFileW at 28> > > > 00000000 I __imp__CreateFileMappingW at 24> > > > 00000000 T _CreateFileMappingW at 24> > > > 00000000 I __imp__CreateFileMappingA at 24> > > > 00000000 T _CreateFileMappingA at 24> > > > 00000000 I __imp__CreateFileA at 28> > > > 00000000 T _CreateFileA at 28> > > >> > > > C:\cygwin\lib\w32api>cd \MinGW\lib> > > >> > > > C:\MinGW\lib>nm libkernel32.a | findstr CreateFile> > > > 00000000 I __imp__CreateFileW at 28> > > > 00000000 T _CreateFileW at 28> > > > 00000000 I __imp__CreateFileMappingW at 24> > > > 00000000 T _CreateFileMappingW at 24> > > > 00000000 I __imp__CreateFileMappingA at 24> > > > 00000000 T _CreateFileMappingA at 24> > > > 00000000 I __imp__CreateFileA at 28> > > > 00000000 T _CreateFileA at 28> > > >> > > > I think at least THREE calling conventions should be supported --> > > > __cdecl, __stdcall, __fastcall --> > > > but oh well. We can live without __fastcall.> > > > Watcom has another calling convention, "watcall", and they let you> > > > describe calling conventions with #pragmas, neat.> > > >> > > > Thanks,> > > > - Jay> > > >> > > > Share life as it happens with the new Windows Live. Start sharing!> > >> >> >> > Make distant family not so distant with Windows Vista? + Windows > > Live?. Start now!> _________________________________________________________________ Watch ?Cause Effect,? a show about real people making a real difference. http://im.live.com/Messenger/IM/MTV/?source=text_watchcause -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Sat Jan 12 20:57:49 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 12 Jan 2008 19:57:49 +0000 Subject: [M3devel] could someone add __stdcall name mangling to m3cc please? In-Reply-To: References: Your message of "Wed, 09 Jan 2008 17:25:31 PST." <200801100131.m0A1VQYS034516@camembert.async.caltech.edu> <6D467648-44A7-48DC-AB8D-27B3AC19EBB0@cs.purdue.edu> Message-ID: Something like this????? ===================================================================RCS file: /usr/cvs/cm3/m3-sys/m3cc/gcc/gcc/m3cg/parse.c,vretrieving revision 1.41diff -r1.41 parse.c3066a3070> tree atypes = NULL_TREE);3091c3095,3102< TREE_TYPE (p) = build_function_type (return_type, NULL_TREE);---> /* for NT386 __stdcall, we just need to declare the right number> of parameters> */> if (--n_params== 0) {> atypes = tree_cons (NULL_TREE, t_word, atypes);> }>> TREE_TYPE (p) = build_function_type (return_type, atypes); haven't even compiled it yet.. - Jay > From: jayk123 at hotmail.com> To: hosking at cs.purdue.edu> Date: Sat, 12 Jan 2008 18:13:27 +0000> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] could someone add __stdcall name mangling to m3cc please?> > Tony, Sorry, I didn't mean to check those in. Those were wild guesses that I hadn't tested yet.I put it back. Thanks for catching that.> > - Jay> > > > > CC: m3devel at elegosoft.com> From: hosking at cs.purdue.edu> Subject: Re: [M3devel] could someone add __stdcall name mangling to m3cc please?> Date: Sat, 12 Jan 2008 10:41:26 -0500> To: jayk123 at hotmail.com> > I'm not sure what you were trying to do with parse.c by adding a > parameter (nargs*4) to the stdcall attribute, but that probably > doesn't do anything interesting. The problem appears to be because > on external function decls the parameter decls are currently being > ignored by cm3cg. If I fix parse.c to add the params for those then > it should work properly with the stdcall attribute.> > On Jan 12, 2008, at 8:27 AM, Jay wrote:> > > Thanks, but not quite. The number of parameters times four needs to > > be appended to the name, in decimal.> > But I'm just getting 0.> > That is, gcc is handling the underlying detail, but you aren't > > giving it enough infomrmation.> > I'll see if I can bang out those temporary wrappers automatically.. > > (a Quake programming challenge, that I've already invented the hard > > part of I think -- Quake can't do math..)> >> > - Jay> >> >> > > CC: m3devel at elegosoft.com> > > From: hosking at cs.purdue.edu> > > Subject: Re: [M3devel] could someone add __stdcall name mangling > > to m3cc please?> > > Date: Fri, 11 Jan 2008 13:16:44 -0500> > > To: jayk123 at hotmail.com> > >> > > I just added support for this. Let me know if it seems to work (or> > > not! :-) ).> > >> > >> > > On Jan 10, 2008, at 7:40 AM, Jay wrote:> > >> > > > Could someone out there (Tony?) familiar with the gcc backend> > > > have it not ignore call_conv and if call_conv is 1, append> > > > an at symbol and the number of bytes of parameters to the function> > > > name?> > > > (Even for zero, e.g. Sleep at 0, GetFileAttributes at 4).> > > > This would be I guess at least for "imported" functions.> > > >> > > > Not clear about calling function pointers, probably needs> > > > modification.> > > > call_conv 0 is "__cdecl" is push right to left, caller cleans up> > > > call_conv 1 is "__stdcall" is push right to left, callee cleans up> > > > There are various synonyms.> > > > With no command line switches, __cdecl is the compiler default.> > > > __stdcall is deemed more efficient, and is very widely used.> > > >> > > > Not clear about functions implemented in Modula-3.> > > > Probably won't occur? Maybe for callbacks? WindowProcs, thread> > > > entry point?> > > >> > > > This could/should be for NT386GNU only.> > > > The hypothetical other NT targets only have one calling convention> > > > each.> > > >> > > > I COULD do something sleazy here and generate little adapter> > > > functions, over in m3-win/import-libs esp.> > > >> > > > I'm still checking out pm3 to see what it does here.> > > > (as in cvs checkout, not "looking at")> > > >> > > > This'll clear up:> > > >> > > > RTOS.m3:27: undefined reference to `_FatalExit'> > > > RTOS.mo: In function `RTOS__GetMemory':> > > > RTOS.m3:75: undefined reference to `_VirtualAlloc'> > > > RTOS.m3:85: undefined reference to `_VirtualAlloc'> > > > RTOS.mo: In function `RTOS__InitMemory':> > > > RTOS.m3:96: undefined reference to `_VirtualAlloc'> > > > RTOS.m3:100: undefined reference to `_GetSystemInfo'> > > > RTOS.mo: In function `RTOS__Write':> > > > RTOS.m3:118: undefined reference to `_AllocConsole'> > > > RTOS.m3:119: undefined reference to `_GetStdHandle'> > > > RTOS.m3:122: undefined reference to `_WriteFile'> > > > RTPerfTool.mo: In function `RTPerfTool__Start':> > > > RTPerfTool.m3:19: undefined reference to `_ReadFile'> > > > RTPerfTool.m3:22: undefined reference to `_CloseHandle'> > > > RTPerfTool.mo: In function `RTPerfTool__Close':> > > > RTPerfTool.m3:28: undefined reference to `_CloseHandle'> > > > RTPerfTool.mo: In function `RTPerfTool__Send':> > > > RTPerfTool.m3:34: undefined reference to `_WriteFile'> > > > RTPerfTool.mo: In function `RTPerfTool__PrepHandle':> > > > RTPerfTool.m3:58: undefined reference to `_GetCurrentProcess'> > > > RTPerfTool.m3:59: undefined reference to `_DuplicateHandle'> > > > etc.> > > >> > > > I did think I was past these. I thought I built m3core and libm3> > > > including linking (having even modified cm3.cfg)> > > > COULD be I'm using the wrong .libs, but:> > > >> > > > C:\cygwin\lib\w32api>nm libkernel32.a | findstr CreateFile> > > > 00000000 I __imp__CreateFileW at 28> > > > 00000000 T _CreateFileW at 28> > > > 00000000 I __imp__CreateFileMappingW at 24> > > > 00000000 T _CreateFileMappingW at 24> > > > 00000000 I __imp__CreateFileMappingA at 24> > > > 00000000 T _CreateFileMappingA at 24> > > > 00000000 I __imp__CreateFileA at 28> > > > 00000000 T _CreateFileA at 28> > > >> > > > C:\cygwin\lib\w32api>cd \MinGW\lib> > > >> > > > C:\MinGW\lib>nm libkernel32.a | findstr CreateFile> > > > 00000000 I __imp__CreateFileW at 28> > > > 00000000 T _CreateFileW at 28> > > > 00000000 I __imp__CreateFileMappingW at 24> > > > 00000000 T _CreateFileMappingW at 24> > > > 00000000 I __imp__CreateFileMappingA at 24> > > > 00000000 T _CreateFileMappingA at 24> > > > 00000000 I __imp__CreateFileA at 28> > > > 00000000 T _CreateFileA at 28> > > >> > > > I think at least THREE calling conventions should be supported --> > > > __cdecl, __stdcall, __fastcall --> > > > but oh well. We can live without __fastcall.> > > > Watcom has another calling convention, "watcall", and they let you> > > > describe calling conventions with #pragmas, neat.> > > >> > > > Thanks,> > > > - Jay> > > >> > > > Share life as it happens with the new Windows Live. Start sharing!> > >> >> >> > Make distant family not so distant with Windows Vista? + Windows > > Live?. Start now!> > _________________________________________________________________> Watch ?Cause Effect,? a show about real people making a real difference _________________________________________________________________ Get the power of Windows + Web with the new Windows Live. http://www.windowslive.com?ocid=TXT_TAGHM_Wave2_powerofwindows_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sun Jan 13 01:04:12 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 12 Jan 2008 19:04:12 -0500 Subject: [M3devel] could someone add __stdcall name mangling to m3cc please? In-Reply-To: References: Your message of "Wed, 09 Jan 2008 17:25:31 PST." <200801100131.m0A1VQYS034516@camembert.async.caltech.edu> <6D467648-44A7-48DC-AB8D-27B3AC19EBB0@cs.purdue.edu> Message-ID: I will be able to get m3cc to spit out the appropriate stdcall function names. Needs a little work, but nothing too drastic. On Jan 12, 2008, at 1:13 PM, Jay wrote: > Tony, Sorry, I didn't mean to check those in. Those were wild > guesses that I hadn't tested yet. > I put it back. Thanks for catching that. > > - Jay > > > > > CC: m3devel at elegosoft.com > > From: hosking at cs.purdue.edu > > Subject: Re: [M3devel] could someone add __stdcall name mangling > to m3cc please? > > Date: Sat, 12 Jan 2008 10:41:26 -0500 > > To: jayk123 at hotmail.com > > > > I'm not sure what you were trying to do with parse.c by adding a > > parameter (nargs*4) to the stdcall attribute, but that probably > > doesn't do anything interesting. The problem appears to be because > > on external function decls the parameter decls are currently being > > ignored by cm3cg. If I fix parse.c to add the params for those then > > it should work properly with the stdcall attribute. > > > > On Jan 12, 2008, at 8:27 AM, Jay wrote: > > > > > Thanks, but not quite. The number of parameters times four > needs to > > > be appended to the name, in decimal. > > > But I'm just getting 0. > > > That is, gcc is handling the underlying detail, but you aren't > > > giving it enough infomrmation. > > > I'll see if I can bang out those temporary wrappers > automatically.. > > > (a Quake programming challenge, that I've already invented the > hard > > > part of I think -- Quake can't do math..) > > > > > > - Jay > > > > > > > > > > CC: m3devel at elegosoft.com > > > > From: hosking at cs.purdue.edu > > > > Subject: Re: [M3devel] could someone add __stdcall name mangling > > > to m3cc please? > > > > Date: Fri, 11 Jan 2008 13:16:44 -0500 > > > > To: jayk123 at hotmail.com > > > > > > > > I just added support for this. Let me know if it seems to > work (or > > > > not! :-) ). > > > > > > > > > > > > On Jan 10, 2008, at 7:40 AM, Jay wrote: > > > > > > > > > Could someone out there (Tony?) familiar with the gcc backend > > > > > have it not ignore call_conv and if call_conv is 1, append > > > > > an at symbol and the number of bytes of parameters to the > function > > > > > name? > > > > > (Even for zero, e.g. Sleep at 0, GetFileAttributes at 4). > > > > > This would be I guess at least for "imported" functions. > > > > > > > > > > Not clear about calling function pointers, probably needs > > > > > modification. > > > > > call_conv 0 is "__cdecl" is push right to left, caller > cleans up > > > > > call_conv 1 is "__stdcall" is push right to left, callee > cleans up > > > > > There are various synonyms. > > > > > With no command line switches, __cdecl is the compiler > default. > > > > > __stdcall is deemed more efficient, and is very widely used. > > > > > > > > > > Not clear about functions implemented in Modula-3. > > > > > Probably won't occur? Maybe for callbacks? WindowProcs, thread > > > > > entry point? > > > > > > > > > > This could/should be for NT386GNU only. > > > > > The hypothetical other NT targets only have one calling > convention > > > > > each. > > > > > > > > > > I COULD do something sleazy here and generate little adapter > > > > > functions, over in m3-win/import-libs esp. > > > > > > > > > > I'm still checking out pm3 to see what it does here. > > > > > (as in cvs checkout, not "looking at") > > > > > > > > > > This'll clear up: > > > > > > > > > > RTOS.m3:27: undefined reference to `_FatalExit' > > > > > RTOS.mo: In function `RTOS__GetMemory': > > > > > RTOS.m3:75: undefined reference to `_VirtualAlloc' > > > > > RTOS.m3:85: undefined reference to `_VirtualAlloc' > > > > > RTOS.mo: In function `RTOS__InitMemory': > > > > > RTOS.m3:96: undefined reference to `_VirtualAlloc' > > > > > RTOS.m3:100: undefined reference to `_GetSystemInfo' > > > > > RTOS.mo: In function `RTOS__Write': > > > > > RTOS.m3:118: undefined reference to `_AllocConsole' > > > > > RTOS.m3:119: undefined reference to `_GetStdHandle' > > > > > RTOS.m3:122: undefined reference to `_WriteFile' > > > > > RTPerfTool.mo: In function `RTPerfTool__Start': > > > > > RTPerfTool.m3:19: undefined reference to `_ReadFile' > > > > > RTPerfTool.m3:22: undefined reference to `_CloseHandle' > > > > > RTPerfTool.mo: In function `RTPerfTool__Close': > > > > > RTPerfTool.m3:28: undefined reference to `_CloseHandle' > > > > > RTPerfTool.mo: In function `RTPerfTool__Send': > > > > > RTPerfTool.m3:34: undefined reference to `_WriteFile' > > > > > RTPerfTool.mo: In function `RTPerfTool__PrepHandle': > > > > > RTPerfTool.m3:58: undefined reference to `_GetCurrentProcess' > > > > > RTPerfTool.m3:59: undefined reference to `_DuplicateHandle' > > > > > etc. > > > > > > > > > > I did think I was past these. I thought I built m3core and > libm3 > > > > > including linking (having even modified cm3.cfg) > > > > > COULD be I'm using the wrong .libs, but: > > > > > > > > > > C:\cygwin\lib\w32api>nm libkernel32.a | findstr CreateFile > > > > > 00000000 I __imp__CreateFileW at 28 > > > > > 00000000 T _CreateFileW at 28 > > > > > 00000000 I __imp__CreateFileMappingW at 24 > > > > > 00000000 T _CreateFileMappingW at 24 > > > > > 00000000 I __imp__CreateFileMappingA at 24 > > > > > 00000000 T _CreateFileMappingA at 24 > > > > > 00000000 I __imp__CreateFileA at 28 > > > > > 00000000 T _CreateFileA at 28 > > > > > > > > > > C:\cygwin\lib\w32api>cd \MinGW\lib > > > > > > > > > > C:\MinGW\lib>nm libkernel32.a | findstr CreateFile > > > > > 00000000 I __imp__CreateFileW at 28 > > > > > 00000000 T _CreateFileW at 28 > > > > > 00000000 I __imp__CreateFileMappingW at 24 > > > > > 00000000 T _CreateFileMappingW at 24 > > > > > 00000000 I __imp__CreateFileMappingA at 24 > > > > > 00000000 T _CreateFileMappingA at 24 > > > > > 00000000 I __imp__CreateFileA at 28 > > > > > 00000000 T _CreateFileA at 28 > > > > > > > > > > I think at least THREE calling conventions should be > supported -- > > > > > __cdecl, __stdcall, __fastcall -- > > > > > but oh well. We can live without __fastcall. > > > > > Watcom has another calling convention, "watcall", and they > let you > > > > > describe calling conventions with #pragmas, neat. > > > > > > > > > > Thanks, > > > > > - Jay > > > > > > > > > > Share life as it happens with the new Windows Live. Start > sharing! > > > > > > > > > > > > > Make distant family not so distant with Windows Vista? + Windows > > > Live?. Start now! > > > > > Watch ?Cause Effect,? a show about real people making a real > difference. Learn more From hosking at cs.purdue.edu Sun Jan 13 01:06:35 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 12 Jan 2008 19:06:35 -0500 Subject: [M3devel] could someone add __stdcall name mangling to m3cc please? In-Reply-To: References: Your message of "Wed, 09 Jan 2008 17:25:31 PST." <200801100131.m0A1VQYS034516@camembert.async.caltech.edu> <6D467648-44A7-48DC-AB8D-27B3AC19EBB0@cs.purdue.edu> Message-ID: <80BC3E7C-2DA6-4765-9053-A52950700404@cs.purdue.edu> It will need to be a little cleaner than that -- I'd rather gather the parameters as declared and enter them into the function type. It means not ignoring the parameter decls: see m3cg_declare_param check for current_param_count==0. To do this it needs to be a little bit smarter about managing current_function_decl -- probably a stack. On Jan 12, 2008, at 2:57 PM, Jay wrote: > Something like this????? > > =================================================================== > RCS file: /usr/cvs/cm3/m3-sys/m3cc/gcc/gcc/m3cg/parse.c,v > retrieving revision 1.41 > diff -r1.41 parse.c > 3066a3070 > > tree atypes = NULL_TREE); > 3091c3095,3102 > < TREE_TYPE (p) = build_function_type (return_type, NULL_TREE); > --- > > /* for NT386 __stdcall, we just need to declare the right number > > of parameters > > */ > > if (--n_params== 0) { > > atypes = tree_cons (NULL_TREE, t_word, atypes); > > } > > > > TREE_TYPE (p) = build_function_type (return_type, atypes); > > haven't even compiled it yet.. > > - Jay > > > > > > > > From: jayk123 at hotmail.com > > To: hosking at cs.purdue.edu > > Date: Sat, 12 Jan 2008 18:13:27 +0000 > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] could someone add __stdcall name mangling > to m3cc please? > > > > Tony, Sorry, I didn't mean to check those in. Those were wild > guesses that I hadn't tested yet.I put it back. Thanks for catching > that. > > > > - Jay > > > > > > > > > CC: m3devel at elegosoft.com> From: hosking at cs.purdue.edu> > Subject: Re: [M3devel] could someone add __stdcall name mangling to > m3cc please?> Date: Sat, 12 Jan 2008 10:41:26 -0500> To: > jayk123 at hotmail.com> > I'm not sure what you were trying to do with > parse.c by adding a > parameter (nargs*4) to the stdcall attribute, > but that probably > doesn't do anything interesting. The problem > appears to be because > on external function decls the parameter > decls are currently being > ignored by cm3cg. If I fix parse.c to > add the params for those then > it should work properly with the > stdcall attribute.> > On Jan 12, 2008, at 8:27 AM, Jay wrote:> > > > Thanks, but not quite. The number of parameters times four needs to > > > be appended to the name, in decimal.> > But I'm just getting > 0.> > That is, gcc is handling the underlying detail, but you > aren't > > giving it enough infomrmation.> > I'll see if I can bang > out those temporary wrappers automatically.. > > (a Quake > programming challenge, that I've already invented the hard > > part > of I think -- Quake can't do math..)> >> > - Jay> >> >> > > CC: > m3devel at elegosoft.com> > > From: hosking at cs.purdue.edu> > > > Subject: Re: [M3devel] could someone add __stdcall name mangling > > > to m3cc please?> > > Date: Fri, 11 Jan 2008 13:16:44 -0500> > > > To: jayk123 at hotmail.com> > >> > > I just added support for this. > Let me know if it seems to work (or> > > not! :-) ).> > >> > >> > > > On Jan 10, 2008, at 7:40 AM, Jay wrote:> > >> > > > Could someone > out there (Tony?) familiar with the gcc backend> > > > have it not > ignore call_conv and if call_conv is 1, append> > > > an at symbol > and the number of bytes of parameters to the function> > > > name?> > > > > (Even for zero, e.g. Sleep at 0, GetFileAttributes at 4).> > > > > This would be I guess at least for "imported" functions.> > > >> > > > > Not clear about calling function pointers, probably needs> > > > > modification.> > > > call_conv 0 is "__cdecl" is push right to > left, caller cleans up> > > > call_conv 1 is "__stdcall" is push > right to left, callee cleans up> > > > There are various synonyms.> > > > > With no command line switches, __cdecl is the compiler > default.> > > > __stdcall is deemed more efficient, and is very > widely used.> > > >> > > > Not clear about functions implemented in > Modula-3.> > > > Probably won't occur? Maybe for callbacks? > WindowProcs, thread> > > > entry point?> > > >> > > > This could/ > should be for NT386GNU only.> > > > The hypothetical other NT > targets only have one calling convention> > > > each.> > > >> > > > > I COULD do something sleazy here and generate little adapter> > > > > functions, over in m3-win/import-libs esp.> > > >> > > > I'm still > checking out pm3 to see what it does here.> > > > (as in cvs > checkout, not "looking at")> > > >> > > > This'll clear up:> > > >> > > > > RTOS.m3:27: undefined reference to `_FatalExit'> > > > > RTOS.mo: In function `RTOS__GetMemory':> > > > RTOS.m3:75: > undefined reference to `_VirtualAlloc'> > > > RTOS.m3:85: undefined > reference to `_VirtualAlloc'> > > > RTOS.mo: In function > `RTOS__InitMemory':> > > > RTOS.m3:96: undefined reference to > `_VirtualAlloc'> > > > RTOS.m3:100: undefined reference to > `_GetSystemInfo'> > > > RTOS.mo: In function `RTOS__Write':> > > > > RTOS.m3:118: undefined reference to `_AllocConsole'> > > > > RTOS.m3:119: undefined reference to `_GetStdHandle'> > > > > RTOS.m3:122: undefined reference to `_WriteFile'> > > > > RTPerfTool.mo: In function `RTPerfTool__Start':> > > > > RTPerfTool.m3:19: undefined reference to `_ReadFile'> > > > > RTPerfTool.m3:22: undefined reference to `_CloseHandle'> > > > > RTPerfTool.mo: In function `RTPerfTool__Close':> > > > > RTPerfTool.m3:28: undefined reference to `_CloseHandle'> > > > > RTPerfTool.mo: In function `RTPerfTool__Send':> > > > > RTPerfTool.m3:34: undefined reference to `_WriteFile'> > > > > RTPerfTool.mo: In function `RTPerfTool__PrepHandle':> > > > > RTPerfTool.m3:58: undefined reference to `_GetCurrentProcess'> > > > > RTPerfTool.m3:59: undefined reference to `_DuplicateHandle'> > > > > etc.> > > >> > > > I did think I was past these. I thought I > built m3core and libm3> > > > including linking (having even > modified cm3.cfg)> > > > COULD be I'm using the wrong .libs, but:> > > > >> > > > C:\cygwin\lib\w32api>nm libkernel32.a | findstr > CreateFile> > > > 00000000 I __imp__CreateFileW at 28> > > > 00000000 > T _CreateFileW at 28> > > > 00000000 I __imp__CreateFileMappingW at 24> > > > > 00000000 T _CreateFileMappingW at 24> > > > 00000000 I > __imp__CreateFileMappingA at 24> > > > 00000000 T > _CreateFileMappingA at 24> > > > 00000000 I __imp__CreateFileA at 28> > > > > 00000000 T _CreateFileA at 28> > > >> > > > C:\cygwin\lib\w32api>cd > \MinGW\lib> > > >> > > > C:\MinGW\lib>nm libkernel32.a | findstr > CreateFile> > > > 00000000 I __imp__CreateFileW at 28> > > > 00000000 > T _CreateFileW at 28> > > > 00000000 I __imp__CreateFileMappingW at 24> > > > > 00000000 T _CreateFileMappingW at 24> > > > 00000000 I > __imp__CreateFileMappingA at 24> > > > 00000000 T > _CreateFileMappingA at 24> > > > 00000000 I __imp__CreateFileA at 28> > > > > 00000000 T _CreateFileA at 28> > > >> > > > I think at least THREE > calling conventions should be supported --> > > > __cdecl, > __stdcall, __fastcall --> > > > but oh well. We can live without > __fastcall.> > > > Watcom has another calling convention, > "watcall", and they let you> > > > describe calling conventions > with #pragmas, neat.> > > >> > > > Thanks,> > > > - Jay> > > >> > > > > Share life as it happens with the new Windows Live. Start sharing! > > > >> >> >> > Make distant family not so distant with Windows > Vista? + Windows > > Live?. Start now!> > > _________________________________________________________________ > > Watch ?Cause Effect,? a show about real people making a real > difference > > > Get the power of Windows + Web with the new Windows Live. Get it now! From jayk123 at hotmail.com Sun Jan 13 01:49:10 2008 From: jayk123 at hotmail.com (Jay) Date: Sun, 13 Jan 2008 00:49:10 +0000 Subject: [M3devel] could someone add __stdcall name mangling to m3cc please? In-Reply-To: <80BC3E7C-2DA6-4765-9053-A52950700404@cs.purdue.edu> References: Your message of "Wed, 09 Jan 2008 17:25:31 PST." <200801100131.m0A1VQYS034516@camembert.async.caltech.edu> <6D467648-44A7-48DC-AB8D-27B3AC19EBB0@cs.purdue.edu> <80BC3E7C-2DA6-4765-9053-A52950700404@cs.purdue.edu> Message-ID: I commited something LIKE this, that lets m3core.dll link. (The below had several errors. Failing to loop, failing to terminate the list correctly, only getting function pointers or functions instead of both, for some reason the Windows *.i3 files use a mix.) libm3.dll has a boring pathname format problem, ld doesn't like c:\foo\../bar.lib and I got sidetracked.. It MIGHT not work for SOME functions, a link error -- if taking __int64 or small structs by value, in a __stdcall function. I'll see if that comes up as I progress through the system slowly. - Jay > CC: m3devel at elegosoft.com> From: hosking at cs.purdue.edu> Subject: Re: [M3devel] could someone add __stdcall name mangling to m3cc please?> Date: Sat, 12 Jan 2008 19:06:35 -0500> To: jayk123 at hotmail.com> > It will need to be a little cleaner than that -- I'd rather gather > the parameters as declared and enter them into the function type. It > means not ignoring the parameter decls: see m3cg_declare_param check > for current_param_count==0. To do this it needs to be a little bit > smarter about managing current_function_decl -- probably a stack.> > On Jan 12, 2008, at 2:57 PM, Jay wrote:> > > Something like this?????> >> > ===================================================================> > RCS file: /usr/cvs/cm3/m3-sys/m3cc/gcc/gcc/m3cg/parse.c,v> > retrieving revision 1.41> > diff -r1.41 parse.c> > 3066a3070> > > tree atypes = NULL_TREE);> > 3091c3095,3102> > < TREE_TYPE (p) = build_function_type (return_type, NULL_TREE);> > ---> > > /* for NT386 __stdcall, we just need to declare the right number> > > of parameters> > > */> > > if (--n_params== 0) {> > > atypes = tree_cons (NULL_TREE, t_word, atypes);> > > }> > >> > > TREE_TYPE (p) = build_function_type (return_type, atypes);> >> > haven't even compiled it yet..> >> > - Jay> >> >> >> >> >> >> > > From: jayk123 at hotmail.com> > > To: hosking at cs.purdue.edu> > > Date: Sat, 12 Jan 2008 18:13:27 +0000> > > CC: m3devel at elegosoft.com> > > Subject: Re: [M3devel] could someone add __stdcall name mangling > > to m3cc please?> > >> > > Tony, Sorry, I didn't mean to check those in. Those were wild > > guesses that I hadn't tested yet.I put it back. Thanks for catching > > that.> > >> > > - Jay> > >> > >> > >> > > > CC: m3devel at elegosoft.com> From: hosking at cs.purdue.edu> > > Subject: Re: [M3devel] could someone add __stdcall name mangling to > > m3cc please?> Date: Sat, 12 Jan 2008 10:41:26 -0500> To: > > jayk123 at hotmail.com> > I'm not sure what you were trying to do with > > parse.c by adding a > parameter (nargs*4) to the stdcall attribute, > > but that probably > doesn't do anything interesting. The problem > > appears to be because > on external function decls the parameter > > decls are currently being > ignored by cm3cg. If I fix parse.c to > > add the params for those then > it should work properly with the > > stdcall attribute.> > On Jan 12, 2008, at 8:27 AM, Jay wrote:> > > > > Thanks, but not quite. The number of parameters times four needs to > > > > be appended to the name, in decimal.> > But I'm just getting > > 0.> > That is, gcc is handling the underlying detail, but you > > aren't > > giving it enough infomrmation.> > I'll see if I can bang > > out those temporary wrappers automatically.. > > (a Quake > > programming challenge, that I've already invented the hard > > part > > of I think -- Quake can't do math..)> >> > - Jay> >> >> > > CC: > > m3devel at elegosoft.com> > > From: hosking at cs.purdue.edu> > > > > Subject: Re: [M3devel] could someone add __stdcall name mangling > > > > to m3cc please?> > > Date: Fri, 11 Jan 2008 13:16:44 -0500> > > > > To: jayk123 at hotmail.com> > >> > > I just added support for this. > > Let me know if it seems to work (or> > > not! :-) ).> > >> > >> > > > > On Jan 10, 2008, at 7:40 AM, Jay wrote:> > >> > > > Could someone > > out there (Tony?) familiar with the gcc backend> > > > have it not > > ignore call_conv and if call_conv is 1, append> > > > an at symbol > > and the number of bytes of parameters to the function> > > > name?> > > > > > (Even for zero, e.g. Sleep at 0, GetFileAttributes at 4).> > > > > > This would be I guess at least for "imported" functions.> > > >> > > > > > Not clear about calling function pointers, probably needs> > > > > > modification.> > > > call_conv 0 is "__cdecl" is push right to > > left, caller cleans up> > > > call_conv 1 is "__stdcall" is push > > right to left, callee cleans up> > > > There are various synonyms.> > > > > > With no command line switches, __cdecl is the compiler > > default.> > > > __stdcall is deemed more efficient, and is very > > widely used.> > > >> > > > Not clear about functions implemented in > > Modula-3.> > > > Probably won't occur? Maybe for callbacks? > > WindowProcs, thread> > > > entry point?> > > >> > > > This could/ > > should be for NT386GNU only.> > > > The hypothetical other NT > > targets only have one calling convention> > > > each.> > > >> > > > > > I COULD do something sleazy here and generate little adapter> > > > > > functions, over in m3-win/import-libs esp.> > > >> > > > I'm still > > checking out pm3 to see what it does here.> > > > (as in cvs > > checkout, not "looking at")> > > >> > > > This'll clear up:> > > >> > > > > > RTOS.m3:27: undefined reference to `_FatalExit'> > > > > > RTOS.mo: In function `RTOS__GetMemory':> > > > RTOS.m3:75: > > undefined reference to `_VirtualAlloc'> > > > RTOS.m3:85: undefined > > reference to `_VirtualAlloc'> > > > RTOS.mo: In function > > `RTOS__InitMemory':> > > > RTOS.m3:96: undefined reference to > > `_VirtualAlloc'> > > > RTOS.m3:100: undefined reference to > > `_GetSystemInfo'> > > > RTOS.mo: In function `RTOS__Write':> > > > > > RTOS.m3:118: undefined reference to `_AllocConsole'> > > > > > RTOS.m3:119: undefined reference to `_GetStdHandle'> > > > > > RTOS.m3:122: undefined reference to `_WriteFile'> > > > > > RTPerfTool.mo: In function `RTPerfTool__Start':> > > > > > RTPerfTool.m3:19: undefined reference to `_ReadFile'> > > > > > RTPerfTool.m3:22: undefined reference to `_CloseHandle'> > > > > > RTPerfTool.mo: In function `RTPerfTool__Close':> > > > > > RTPerfTool.m3:28: undefined reference to `_CloseHandle'> > > > > > RTPerfTool.mo: In function `RTPerfTool__Send':> > > > > > RTPerfTool.m3:34: undefined reference to `_WriteFile'> > > > > > RTPerfTool.mo: In function `RTPerfTool__PrepHandle':> > > > > > RTPerfTool.m3:58: undefined reference to `_GetCurrentProcess'> > > > > > RTPerfTool.m3:59: undefined reference to `_DuplicateHandle'> > > > > > etc.> > > >> > > > I did think I was past these. I thought I > > built m3core and libm3> > > > including linking (having even > > modified cm3.cfg)> > > > COULD be I'm using the wrong .libs, but:> > > > > >> > > > C:\cygwin\lib\w32api>nm libkernel32.a | findstr > > CreateFile> > > > 00000000 I __imp__CreateFileW at 28> > > > 00000000 > > T _CreateFileW at 28> > > > 00000000 I __imp__CreateFileMappingW at 24> > > > > > 00000000 T _CreateFileMappingW at 24> > > > 00000000 I > > __imp__CreateFileMappingA at 24> > > > 00000000 T > > _CreateFileMappingA at 24> > > > 00000000 I __imp__CreateFileA at 28> > > > > > 00000000 T _CreateFileA at 28> > > >> > > > C:\cygwin\lib\w32api>cd > > \MinGW\lib> > > >> > > > C:\MinGW\lib>nm libkernel32.a | findstr > > CreateFile> > > > 00000000 I __imp__CreateFileW at 28> > > > 00000000 > > T _CreateFileW at 28> > > > 00000000 I __imp__CreateFileMappingW at 24> > > > > > 00000000 T _CreateFileMappingW at 24> > > > 00000000 I > > __imp__CreateFileMappingA at 24> > > > 00000000 T > > _CreateFileMappingA at 24> > > > 00000000 I __imp__CreateFileA at 28> > > > > > 00000000 T _CreateFileA at 28> > > >> > > > I think at least THREE > > calling conventions should be supported --> > > > __cdecl, > > __stdcall, __fastcall --> > > > but oh well. We can live without > > __fastcall.> > > > Watcom has another calling convention, > > "watcall", and they let you> > > > describe calling conventions > > with #pragmas, neat.> > > >> > > > Thanks,> > > > - Jay> > > >> > > > > > Share life as it happens with the new Windows Live. Start sharing! > > > > >> >> >> > Make distant family not so distant with Windows > > Vista? + Windows > > Live?. Start now!>> > > _________________________________________________________________> > > Watch ?Cause Effect,? a show about real people making a real > > difference> >> >> > Get the power of Windows + Web with the new Windows Live. Get it now!> _________________________________________________________________ Watch ?Cause Effect,? a show about real people making a real difference. http://im.live.com/Messenger/IM/MTV/?source=text_watchcause -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Jan 13 01:51:15 2008 From: jay.krell at cornell.edu (Jay) Date: Sun, 13 Jan 2008 00:51:15 +0000 Subject: [M3devel] could someone add __stdcall name mangling to m3cc please? In-Reply-To: <80BC3E7C-2DA6-4765-9053-A52950700404@cs.purdue.edu> References: Your message of "Wed, 09 Jan 2008 17:25:31 PST." <200801100131.m0A1VQYS034516@camembert.async.caltech.edu> <6D467648-44A7-48DC-AB8D-27B3AC19EBB0@cs.purdue.edu> <80BC3E7C-2DA6-4765-9053-A52950700404@cs.purdue.edu> Message-ID: > current_param_count Must this code use globals? - Jay From: jayk123 at hotmail.comTo: hosking at cs.purdue.eduCC: m3devel at elegosoft.comSubject: RE: [M3devel] could someone add __stdcall name mangling to m3cc please?Date: Sun, 13 Jan 2008 00:49:10 +0000 I commited something LIKE this, that lets m3core.dll link. (The below had several errors. Failing to loop, failing to terminate the list correctly, only getting function pointers or functions instead of both, for some reason the Windows *.i3 files use a mix.) libm3.dll has a boring pathname format problem, ld doesn't like c:\foo\../bar.lib and I got sidetracked.. It MIGHT not work for SOME functions, a link error -- if taking __int64 or small structs by value, in a __stdcall function.I'll see if that comes up as I progress through the system slowly. - Jay > CC: m3devel at elegosoft.com> From: hosking at cs.purdue.edu> Subject: Re: [M3devel] could someone add __stdcall name mangling to m3cc please?> Date: Sat, 12 Jan 2008 19:06:35 -0500> To: jayk123 at hotmail.com> > It will need to be a little cleaner than that -- I'd rather gather > the parameters as declared and enter them into the function type. It > means not ignoring the parameter decls: see m3cg_declare_param check > for current_param_count==0. To do this it needs to be a little bit > smarter about managing current_function_decl -- probably a stack.> > On Jan 12, 2008, at 2:57 PM, Jay wrote:> > > Something like this?????> >> > ===================================================================> > RCS file: /usr/cvs/cm3/m3-sys/m3cc/gcc/gcc/m3cg/parse.c,v> > retrieving revision 1.41> > diff -r1.41 parse.c> > 3066a3070> > > tree atypes = NULL_TREE);> > 3091c3095,3102> > < TREE_TYPE (p) = build_function_type (return_type, NULL_TREE);> > ---> > > /* for NT386 __stdcall, we just need to declare the right number> > > of parameters> > > */> > > if (--n_params== 0) {> > > atypes = tree_cons (NULL_TREE, t_word, atypes);> > > }> > >> > > TREE_TYPE (p) = build_function_type (return_type, atypes);> >> > haven't even compiled it yet..> >> > - Jay> >> >> >> >> >> >> > > From: jayk123 at hotmail.com> > > To: hosking at cs.purdue.edu> > > Date: Sat, 12 Jan 2008 18:13:27 +0000> > > CC: m3devel at elegosoft.com> > > Subject: Re: [M3devel] could someone add __stdcall name mangling > > to m3cc please?> > >> > > Tony, Sorry, I didn't mean to check those in. Those were wild > > guesses that I hadn't tested yet.I put it back. Thanks for catching > > that.> > >> > > - Jay> > >> > >> > >> > > > CC: m3devel at elegosoft.com> From: hosking at cs.purdue.edu> > > Subject: Re: [M3devel] could someone add __stdcall name mangling to > > m3cc please?> Date: Sat, 12 Jan 2008 10:41:26 -0500> To: > > jayk123 at hotmail.com> > I'm not sure what you were trying to do with > > parse.c by adding a > parameter (nargs*4) to the stdcall attribute, > > but that probably > doesn't do anything interesting. The problem > > appears to be because > on external function decls the parameter > > decls are currently being > ignored by cm3cg. If I fix parse.c to > > add the params for those then > it should work properly with the > > stdcall attribute.> > On Jan 12, 2008, at 8:27 AM, Jay wrote:> > > > > Thanks, but not quite. The number of parameters times four needs to > > > > be appended to the name, in decimal.> > But I'm just getting > > 0.> > That is, gcc is handling the underlying detail, but you > > aren't > > giving it enough infomrmation.> > I'll see if I can bang > > out those temporary wrappers automatically.. > > (a Quake > > programming challenge, that I've already invented the hard > > part > > of I think -- Quake can't do math..)> >> > - Jay> >> >> > > CC: > > m3devel at elegosoft.com> > > From: hosking at cs.purdue.edu> > > > > Subject: Re: [M3devel] could someone add __stdcall name mangling > > > > to m3cc please?> > > Date: Fri, 11 Jan 2008 13:16:44 -0500> > > > > To: jayk123 at hotmail.com> > >> > > I just added support for this. > > Let me know if it seems to work (or> > > not! :-) ).> > >> > >> > > > > On Jan 10, 2008, at 7:40 AM, Jay wrote:> > >> > > > Could someone > > out there (Tony?) familiar with the gcc backend> > > > have it not > > ignore call_conv and if call_conv is 1, append> > > > an at symbol > > and the number of bytes of parameters to the function> > > > name?> > > > > > (Even for zero, e.g. Sleep at 0, GetFileAttributes at 4).> > > > > > This would be I guess at least for "imported" functions.> > > >> > > > > > Not clear about calling function pointers, probably needs> > > > > > modification.> > > > call_conv 0 is "__cdecl" is push right to > > left, caller cleans up> > > > call_conv 1 is "__stdcall" is push > > right to left, callee cleans up> > > > There are various synonyms.> > > > > > With no command line switches, __cdecl is the compiler > > default.> > > > __stdcall is deemed more efficient, and is very > > widely used.> > > >> > > > Not clear about functions implemented in > > Modula-3.> > > > Probably won't occur? Maybe for callbacks? > > WindowProcs, thread> > > > entry point?> > > >> > > > This could/ > > should be for NT386GNU only.> > > > The hypothetical other NT > > targets only have one calling convention> > > > each.> > > >> > > > > > I COULD do something sleazy here and generate little adapter> > > > > > functions, over in m3-win/import-libs esp.> > > >> > > > I'm still > > checking out pm3 to see what it does here.> > > > (as in cvs > > checkout, not "looking at")> > > >> > > > This'll clear up:> > > >> > > > > > RTOS.m3:27: undefined reference to `_FatalExit'> > > > > > RTOS.mo: In function `RTOS__GetMemory':> > > > RTOS.m3:75: > > undefined reference to `_VirtualAlloc'> > > > RTOS.m3:85: undefined > > reference to `_VirtualAlloc'> > > > RTOS.mo: In function > > `RTOS__InitMemory':> > > > RTOS.m3:96: undefined reference to > > `_VirtualAlloc'> > > > RTOS.m3:100: undefined reference to > > `_GetSystemInfo'> > > > RTOS.mo: In function `RTOS__Write':> > > > > > RTOS.m3:118: undefined reference to `_AllocConsole'> > > > > > RTOS.m3:119: undefined reference to `_GetStdHandle'> > > > > > RTOS.m3:122: undefined reference to `_WriteFile'> > > > > > RTPerfTool.mo: In function `RTPerfTool__Start':> > > > > > RTPerfTool.m3:19: undefined reference to `_ReadFile'> > > > > > RTPerfTool.m3:22: undefined reference to `_CloseHandle'> > > > > > RTPerfTool.mo: In function `RTPerfTool__Close':> > > > > > RTPerfTool.m3:28: undefined reference to `_CloseHandle'> > > > > > RTPerfTool.mo: In function `RTPerfTool__Send':> > > > > > RTPerfTool.m3:34: undefined reference to `_WriteFile'> > > > > > RTPerfTool.mo: In function `RTPerfTool__PrepHandle':> > > > > > RTPerfTool.m3:58: undefined reference to `_GetCurrentProcess'> > > > > > RTPerfTool.m3:59: undefined reference to `_DuplicateHandle'> > > > > > etc.> > > >> > > > I did think I was past these. I thought I > > built m3core and libm3> > > > including linking (having even > > modified cm3.cfg)> > > > COULD be I'm using the wrong .libs, but:> > > > > >> > > > C:\cygwin\lib\w32api>nm libkernel32.a | findstr > > CreateFile> > > > 00000000 I __imp__CreateFileW at 28> > > > 00000000 > > T _CreateFileW at 28> > > > 00000000 I __imp__CreateFileMappingW at 24> > > > > > 00000000 T _CreateFileMappingW at 24> > > > 00000000 I > > __imp__CreateFileMappingA at 24> > > > 00000000 T > > _CreateFileMappingA at 24> > > > 00000000 I __imp__CreateFileA at 28> > > > > > 00000000 T _CreateFileA at 28> > > >> > > > C:\cygwin\lib\w32api>cd > > \MinGW\lib> > > >> > > > C:\MinGW\lib>nm libkernel32.a | findstr > > CreateFile> > > > 00000000 I __imp__CreateFileW at 28> > > > 00000000 > > T _CreateFileW at 28> > > > 00000000 I __imp__CreateFileMappingW at 24> > > > > > 00000000 T _CreateFileMappingW at 24> > > > 00000000 I > > __imp__CreateFileMappingA at 24> > > > 00000000 T > > _CreateFileMappingA at 24> > > > 00000000 I __imp__CreateFileA at 28> > > > > > 00000000 T _CreateFileA at 28> > > >> > > > I think at least THREE > > calling conventions should be supported --> > > > __cdecl, > > __stdcall, __fastcall --> > > > but oh well. We can live without > > __fastcall.> > > > Watcom has another calling convention, > > "watcall", and they let you> > > > describe calling conventions > > with #pragmas, neat.> > > >> > > > Thanks,> > > > - Jay> > > >> > > > > > Share life as it happens with the new Windows Live. Start sharing! > > > > >> >> >> > Make distant family not so distant with Windows > > Vista? + Windows > > Live?. Start now!>> > > _________________________________________________________________> > > Watch ?Cause Effect,? a show about real people making a real > > difference> >> >> > Get the power of Windows + Web with the new Windows Live. Get it now!> Watch ?Cause Effect,? a show about real people making a real difference. Learn more _________________________________________________________________ Watch ?Cause Effect,? a show about real people making a real difference. http://im.live.com/Messenger/IM/MTV/?source=text_watchcause -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Sun Jan 13 16:05:23 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Sun, 13 Jan 2008 16:05:23 +0100 Subject: [M3devel] M3 concerns In-Reply-To: <20080105143235.ujed2tl3ksogws8k@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> Message-ID: <20080113160523.7ih7rpkusogsook8@mail.elegosoft.com> Quoting myself: > Discussions seem to loose their focus quiet easy on this list :-/ It might seem that I've scared everybody away from further discussing, or indeed nobody else is interested in this topic. As I'd promised to write a resume, here are some comments / suggestions: > How do we need to improve > the CM3 development process to ensure and increase the overall quality > of the CM3 code base? Could everybody interested in this discussion > please just comment on the following items to state his opinion: > > 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). > > Technical details should be discussed in a different thread. There has been some progress on CM3 regression test automation. The tinderbox setup by Kaspar is working and quite usable, though some things still need to be improved or fixed. Have a look at http://tinderbox.elegosoft.com/tinderbox/cm3/status.html to view the current build results (from FreeBSD and Linux systems; two test runs every day for every platform). We're now at the stage that others could contribute their daily build results, so that the platform coverage gets better. Some details (mostly security related) still have to be resolved (with out administrators); I'll follow up on this in a separate mail. I've also invested a considerable amount of time to review all the failures and problems in the m3-sys/m3tests regression test package, which is now run as part of the daily tests. The short result is that there still _are_ several problems with the current compiler and/or runtime which may need attention. I'll post another summary for this; volunteers for closer inspection are welcome. > o Do we need / want to restrict the commit access for the CM3 > code repositories? > > If so, only for certain areas, or for everything? This would > be a distinction based on packages. > > Should we allow or prefer committing new code to branches and > merge the resulting change sets based on reviews? (I could also > contribute automatic support for creating change sets on branches, > as this is part of the DCVS functionality elego developed some time > ago). This would be a distinction based on code lines. > > Yesterday I had the impression that some members of this list > would prefer some access restriction, but I'm not really sure. As there have been no more comments / opninions I'd suggest that we leave things as they currently are, unless there are good objections to this. > o I'm not sure if and how we should include the Windows target > problems here. They were part of the original mail, but seem > to belong to another category to me, at least have different > causes. Suggestions what exactly to discuss are welcome. I don't know if Randy was successful in getting the current CM3 system to run on Windows; some problems and solutions have been posted to m3devel since last week. There also seems to be progress in resurrecting the NT386GNU target, but this is obviously work in progress. So far for this (intermediate?) summary of CM3 QA :-) Please let me know what you think about the recent additions and changes, Olaf PS: I won't be able to continue to spare as much time on CM3 as I've done during the last three weeks, so I'd like to encourage everybody who'd like to help, improve or take responsibility for (some of) the started tasks. -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Jan 14 00:36:40 2008 From: jayk123 at hotmail.com (Jay) Date: Sun, 13 Jan 2008 23:36:40 +0000 Subject: [M3devel] religion, philosophy, Posix vs. Win32 In-Reply-To: <280102.76351.qm@web27105.mail.ukl.yahoo.com> References: <280102.76351.qm@web27105.mail.ukl.yahoo.com> Message-ID: The conclusion here is: Just try to convince me otherwise. :) The gist of the question is: Just what characteristics of "Posix" and "Win32" should "NT386GNU" have? Just what characteristics of "Posix" do people notice and like? You can't say "the whole thing". :) Restated: What is Posix? I don't mean, where is the standard document web site. I mean what is it TO YOU? Is it open/read/write/close? Is it fork? Is it sbrk? On these previous ones, they are interesting to many programmers, but Modula-3 already layers over all this, so these are unlikely defining characteristics here. Is it sh? Probably somewhat. But if have you sat in Cygwin sh much vs. cmd? It is annoying. Command line history is flaky. Paths are munged to say /cygdrive. You lose the critical F8 command line completion against history feature. You lose a lot of editing capability, but do gain some alternate possibly "portable" similar. Is it Perl? No. Is it X Windows. I doubt it. Is it pthreads? Probably not. Or at least vtalarm? Maybe? Or setjmp/longjmp? Ok. Longjmp to the same buffer multiple times? Not likely. Longjmp to a place that has already returned? Not likely. All full paths starting with a forward slash? Maybe. Backward slash being a valid non-seperator path character? Maybe. Think about that last one. It is valid and occurs in Win32 code to treat forward slash and backward slash the same. Some code does, some code does not. What if you just did that unconditionally, like even in Posix? What is the role of backward slash in Posix paths? It either just doesn't occur, or is an escape character, or is a regular character. Something at a low level could replace the backward slashes with forward slashes. I would like to change the code in m3-sys/cm3/m3path.m3 to treat backward slashes and forward slashes the same. Backward slashes just won't occur on Posix, right? So far I have managed without this change, but not having it has bitten me a few times. I do have the analogous change to the Win32 path code in m3core. It is the redundant filenames libfoo.a instead of foo.lib and libfoo.so instead of foo.so? Perhaps. This seems dumb, redundant to me. Why have prefixes and suffixes? Don't suffixes suffice? That all said, I remain convinced that a useful intermediate or probably endpoint is a toolset that targets Windows using cm3cg, ld, as, but otherwise looks like NT386 as much as possible. MAYBE alter the library names to libfoo.*. sh and make are needed for building cm3cg. I did use Cygwin for that. MinGWin sounds promising here too but I haven't tried. - Jay _________________________________________________________________ Get the power of Windows + Web with the new Windows Live. http://www.windowslive.com?ocid=TXT_TAGHM_Wave2_powerofwindows_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Mon Jan 14 00:43:41 2008 From: jayk123 at hotmail.com (Jay) Date: Sun, 13 Jan 2008 23:43:41 +0000 Subject: [M3devel] dynamic linking, stanalone()? In-Reply-To: <280102.76351.qm@web27105.mail.ukl.yahoo.com> References: <280102.76351.qm@web27105.mail.ukl.yahoo.com> Message-ID: Dynamic linking vs. "standalone". How does that work? On Posix, with ld, etc.? I understand fully how it works on NT386 and will explain, as a jumping off point for explanation and analogies. Windows has "import .libs" and regular old "static .libs". In reality it has import .objs and regular .objs, and a .lib is a collection of .objs, and can contain a mix, but this is not well known. Usually a .lib only has all one type or all the other type. Actually older import .libs are just kind of wierd and drive the linker in odd roundabout ways that end up doing the right thing, I guess without the linker knowing much. Current Cygwin/Mingwin ld/dlltool import libs I think are still odd. And large. And besides, they seem buggy but tht's a tangent. Look at msvcrt.lib. It contains static startup code and imports. There is no seperate crt0.o file on Windows. USUALLY people only build one .lib type or another. However the Modula-3 system has a clever innovation. It always builds both. This retains flexibility in how the clients are built. cm3.exe links to m3core/libm3 statically, most other folks dynamically. It is ROUGHLY like so: lib /out:foo.lib.sa objects... sa for standalone link /out:foo.dll objects... as a by-product of the link, foo.lib an import .lib is produced When you go to link, you give the linker, well, let's say, full paths. To foo.lib or foo.lib.sa, or whatever mix. (or leaf only paths and the LIB environment variable is searched, kind of like $PATH) In "Posix" I know there is foo.a and foo.so. But an .so is a .dll. An .a is? Either? And the third one is? To some extent, no matter. I THINK it goes like this for Cygwin/MinGWin: ar foo.lib.sa objects ld -o foo.dll --out-imlib foo.lib but it's not quite working for me currently. I'm backtracking to get to an earlier version of my config file that was. I should probably break down and use dlltool. And I can read the docs, of course. I do so. And search the web. I have avoided using anything that isn't already a configuration variable. That is, I use gcc instead of ld for example. This is dumb of me I realize. ld gave me fits also on MacOSX but on Windows it should be more viable, fewer arcane details as to what to link in. e.g. I believe on "Posix", the entry point of a file is whatever .o is linked first. Chose carefully. On Windows it is seperately specified and the order of the link command doesn't affect it (though still has other subtle affects). And it is usually buried in a .lib, fewer files to chose between. - Jay _________________________________________________________________ Share life as it happens with the new Windows Live. http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Mon Jan 14 00:53:58 2008 From: jayk123 at hotmail.com (Jay) Date: Sun, 13 Jan 2008 23:53:58 +0000 Subject: [M3devel] dynamic linking, stanalone()? In-Reply-To: References: <280102.76351.qm@web27105.mail.ukl.yahoo.com> Message-ID: Nevermind, I'll figure it out. I am going to try dlltool. Currently it SEEMS like references are to _Foo but defintions are Foo. Of course, leading underscores always confuse. Sometimes they are added, sometimes they are removed, sometimes they must match. It stinks a little bit. At least on x86 Windows. Usually it is well hidden. COULD be a disagreement between Cygwin cm3cg and mingwin as/ld..though given that things were working..I don't know. I should try the mingwin sh/make/sed... - Jay From: jayk123 at hotmail.com To: m3devel at elegosoft.com Date: Sun, 13 Jan 2008 23:43:41 +0000 Subject: [M3devel] dynamic linking, stanalone()? Dynamic linking vs. "standalone". How does that work? On Posix, with ld, etc.? I understand fully how it works on NT386 and will explain, as a jumping off point for explanation and analogies. Windows has "import .libs" and regular old "static .libs". In reality it has import .objs and regular .objs, and a .lib is a collection of .objs, and can contain a mix, but this is not well known. Usually a .lib only has all one type or all the other type. Actually older import .libs are just kind of wierd and drive the linker in odd roundabout ways that end up doing the right thing, I guess without the linker knowing much. Current Cygwin/Mingwin ld/dlltool import libs I think are still odd. And large. And besides, they seem buggy but tht's a tangent. Look at msvcrt.lib. It contains static startup code and imports. There is no seperate crt0.o file on Windows. USUALLY people only build one .lib type or another. However the Modula-3 system has a clever innovation. It always builds both. This retains flexibility in how the clients are built. cm3.exe links to m3core/libm3 statically, most other folks dynamically. It is ROUGHLY like so: lib /out:foo.lib.sa objects... sa for standalone link /out:foo.dll objects... as a by-product of the link, foo.lib an import .lib is produced When you go to link, you give the linker, well, let's say, full paths. To foo.lib or foo.lib.sa, or whatever mix. (or leaf only paths and the LIB environment variable is searched, kind of like $PATH) In "Posix" I know there is foo.a and foo.so. But an .so is a .dll. An .a is? Either? And the third one is? To some extent, no matter. I THINK it goes like this for Cygwin/MinGWin: ar foo.lib.sa objects ld -o foo.dll --out-imlib foo.lib but it's not quite working for me currently. I'm backtracking to get to an earlier version of my config file that was. I should probably break down and use dlltool. And I can read the docs, of course. I do so. And search the web. I have avoided using anything that isn't already a configuration variable. That is, I use gcc instead of ld for example. This is dumb of me I realize. ld gave me fits also on MacOSX but on Windows it should be more viable, fewer arcane details as to what to link in. e.g. I believe on "Posix", the entry point of a file is whatever .o is linked first. Chose carefully. On Windows it is seperately specified and the order of the link command doesn't affect it (though still has other subtle affects). And it is usually buried in a .lib, fewer files to chose between. - Jay Share life as it happens with the new Windows Live. Start sharing! _________________________________________________________________ Put your friends on the big screen with Windows Vista? + Windows Live?. http://www.microsoft.com/windows/shop/specialoffers.mspx?ocid=TXT_TAGLM_CPC_MediaCtr_bigscreen_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon Jan 14 01:13:17 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 13 Jan 2008 19:13:17 -0500 Subject: [M3devel] religion, philosophy, Posix vs. Win32 In-Reply-To: References: <280102.76351.qm@web27105.mail.ukl.yahoo.com> Message-ID: I really don't know enough about Windows to answer these questions properly. My take on it is: since Cygwin is intended to give a Linux-like environment on Windows, then it should behave more like a Linux system than a Windows system. That is, CM3 will look like it is running on some (strange) flavor of Linux. That said, the threading sub-system might be implemented as ThreadWin32 instead of ThreadPosix just to get system-level thread scheduling (ie, good for multi-core), similarly to the way ThreadPThread is used on some POSIX targets. The rest of things with Cygwin should behave like any other POSIX target. Perhaps someone else out there with better Windows knowledge can respond more intelligently than I have. On Jan 13, 2008, at 6:36 PM, Jay wrote: > The conclusion here is: > Just try to convince me otherwise. :) > > The gist of the question is: > Just what characteristics of "Posix" and "Win32" should > "NT386GNU" have? > > Just what characteristics of "Posix" do people notice and like? > You can't say "the whole thing". :) > > Restated: > > What is Posix? I don't mean, where is the standard document web site. > I mean what is it TO YOU? > > Is it open/read/write/close? > Is it fork? > Is it sbrk? > On these previous ones, they are interesting to many programmers, > but Modula-3 already layers over all this, so these are unlikely > defining > characteristics here. > > Is it sh? Probably somewhat. But if have you sat in Cygwin sh much > vs. cmd? > It is annoying. Command line history is flaky. Paths are munged to > say /cygdrive. > You lose the critical F8 command line completion against history > feature. > You lose a lot of editing capability, but do gain some alternate > possibly "portable" > similar. > > Is it Perl? No. > Is it X Windows. I doubt it. > Is it pthreads? Probably not. > Or at least vtalarm? Maybe? > Or setjmp/longjmp? Ok. > Longjmp to the same buffer multiple times? Not likely. > Longjmp to a place that has already returned? Not likely. > All full paths starting with a forward slash? Maybe. > Backward slash being a valid non-seperator path character? Maybe. > > Think about that last one. > It is valid and occurs in Win32 code to treat forward slash and > backward slash the same. > Some code does, some code does not. > What if you just did that unconditionally, like even in Posix? > What is the role of backward slash in Posix paths? It either just > doesn't occur, > or is an escape character, or is a regular character. Something at > a low level > could replace the backward slashes with forward slashes. > > I would like to change the code in m3-sys/cm3/m3path.m3 to treat > backward slashes > and forward slashes the same. Backward slashes just won't occur on > Posix, right? > So far I have managed without this change, but not having it has > bitten me a few times. > I do have the analogous change to the Win32 path code in m3core. > > It is the redundant filenames libfoo.a instead of foo.lib and > libfoo.so instead of foo.so? > Perhaps. This seems dumb, redundant to me. Why have prefixes and > suffixes? > Don't suffixes suffice? > > That all said, I remain convinced that a useful intermediate or > probably endpoint > is a toolset that targets Windows using cm3cg, ld, as, but > otherwise looks like > NT386 as much as possible. MAYBE alter the library names to libfoo.*. > > sh and make are needed for building cm3cg. > I did use Cygwin for that. MinGWin sounds promising here too but I > haven't tried. > > - Jay > > > Get the power of Windows + Web with the new Windows Live. Get it now! From mika at async.caltech.edu Mon Jan 14 01:40:17 2008 From: mika at async.caltech.edu (Mika Nystrom) Date: Sun, 13 Jan 2008 16:40:17 -0800 Subject: [M3devel] religion, philosophy, Posix vs. Win32 In-Reply-To: Your message of "Sun, 13 Jan 2008 23:36:40 GMT." Message-ID: <200801140040.m0E0eHs7046272@camembert.async.caltech.edu> Jay, I don't know if this is completely responsive to your question, and take it with a grain of salt because I have never programmed on a "pure" Windows system (and God willing, I never shall). I expect the NT386GNU target, Cygwin, Windows-POSIX, whatever you call it, to look as much as Unix "as possible." (Obviously not, but as "reasonable".) The main things are (1) yes, /bin/sh, and (2) Unix (POSIX?) libc---Modula-3 does a good job of covering up the basic stuff so you don't need to worry about it for the most part, but sometimes, just sometimes, you need to get, say, some system information that doesn't have an existing M3 interface (say the amount of free diskspace or something like that). Then you should be able to call C code that is portable between Unix and Windows. One thing that is bizarre about the old NT386GNU PM3 that doesn't conform to the above description: it uses Windows Time.T. It's all the more bizarre because Cygwin uses Unix time_t. (Time.Now and time(3) are off by a couple of hundred years on NT386GNU, whereas they are the same on all Unixes.) I am sure there are other things. Oh yes, the open-file (default) locking semantics are different too. Those two are actually the only differences that I noticed in the programming environments. Mika Jay writes: >--_d0659847-2f20-454a-9665-5df3b5ce2832_ >Content-Type: text/plain; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > >The conclusion here is: > Just try to convince me otherwise. :) > >The gist of the question is: > Just what characteristics of "Posix" and "Win32" should "NT386GNU" have? > > Just what characteristics of "Posix" do people notice and like? >You can't say "the whole thing". :) > >Restated: > >What is Posix? I don't mean, where is the standard document web site. >I mean what is it TO YOU? > >Is it open/read/write/close? >Is it fork? >Is it sbrk? > On these previous ones, they are interesting to many programmers, > but Modula-3 already layers over all this, so these are unlikely defining >characteristics here. > >Is it sh? Probably somewhat. But if have you sat in Cygwin sh much vs. cmd? > It is annoying. Command line history is flaky. Paths are munged to say /cy= >gdrive. > You lose the critical F8 command line completion against history feature. > You lose a lot of editing capability, but do gain some alternate possibly= > "portable" > similar. > >Is it Perl? No. >Is it X Windows. I doubt it. >Is it pthreads? Probably not. > Or at least vtalarm? Maybe? > Or setjmp/longjmp? Ok. > Longjmp to the same buffer multiple times? Not likely. > Longjmp to a place that has already returned? Not likely. >All full paths starting with a forward slash? Maybe. > Backward slash being a valid non-seperator path character? Maybe. > >Think about that last one. >It is valid and occurs in Win32 code to treat forward slash and backward sl= >ash the same. >Some code does, some code does not. >What if you just did that unconditionally, like even in Posix? >What is the role of backward slash in Posix paths? It either just doesn't o= >ccur, >or is an escape character, or is a regular character. Something at a low le= >vel >could replace the backward slashes with forward slashes. > >I would like to change the code in m3-sys/cm3/m3path.m3 to treat backward s= >lashes >and forward slashes the same. Backward slashes just won't occur on Posix, r= >ight? >So far I have managed without this change, but not having it has bitten me = >a few times. >I do have the analogous change to the Win32 path code in m3core. > >It is the redundant filenames libfoo.a instead of foo.lib and libfoo.so ins= >tead of foo.so? >Perhaps. This seems dumb, redundant to me. Why have prefixes and suffixes? >Don't suffixes suffice? > >That all said, I remain convinced that a useful intermediate or probably en= >dpoint >is a toolset that targets Windows using cm3cg, ld, as, but otherwise looks = >like >NT386 as much as possible. MAYBE alter the library names to libfoo.*. > >sh and make are needed for building cm3cg. >I did use Cygwin for that. MinGWin sounds promising here too but I haven't = >tried. > > - Jay > > >_________________________________________________________________ >Get the power of Windows + Web with the new Windows Live. >http://www.windowslive.com?ocid=3DTXT_TAGHM_Wave2_powerofwindows_012008= > >--_d0659847-2f20-454a-9665-5df3b5ce2832_ >Content-Type: text/html; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > > > > >The conclusion here is:
 Just try to conv= >ince me otherwise. :)

The gist of the question is:
  Just wh= >at characteristics of "Posix" and "Win32" should "NT386GNU" have?

&n= >bsp;Just what characteristics of "Posix" do people notice and like?
You = >can't say "the whole thing". :)

Restated:

What is Posix? I do= >n't mean, where is the standard document web site.
I mean what is it TO = >YOU?

Is it open/read/write/close?
Is it fork?
Is it sbrk?
&= >nbsp; On these previous ones, they are interesting to many programmers,
= > but Modula-3 already layers over all this, so these are unlikely defi= >ning
characteristics here.

Is it sh? Probably somewhat. But if ha= >ve you sat in Cygwin sh much vs. cmd?
 It is annoying. Command line= > history is flaky. Paths are munged to say /cygdrive.
 You lose the= > critical F8 command line completion against history feature.
  You= > lose a lot of editing capability, but do gain some alternate possibly "por= >table"
  similar.

Is it Perl? No.
Is it X Windows. I doub= >t it.
Is it pthreads? Probably not.
  Or at least vtalarm? Maybe= >?
  Or setjmp/longjmp? Ok.
    Longjmp to the sam= >e buffer multiple times? Not likely.
    Longjmp to a pla= >ce that has already returned? Not likely.
All full paths starting with a= > forward slash? Maybe.
  Backward slash being a valid non-seperator= > path character? Maybe.

Think about that last one.
It is valid an= >d occurs in Win32 code to treat forward slash and backward slash the same.<= >br>Some code does, some code does not.
What if you just did that uncondi= >tionally, like even in Posix?
What is the role of backward slash in Posi= >x paths? It either just doesn't occur,
or is an escape character, or is = >a regular character. Something at a low level
could replace the backward= > slashes with forward slashes.

I would like to change the code in m3= >-sys/cm3/m3path.m3 to treat backward slashes
and forward slashes the sam= >e. Backward slashes just won't occur on Posix, right?
So far I have mana= >ged without this change, but not having it has bitten me a few times.
I = >do have the analogous change to the Win32 path code in m3core.

It is= > the redundant filenames libfoo.a instead of foo.lib and libfoo.so instead = >of foo.so?
Perhaps. This seems dumb, redundant to me. Why have prefixes = >and suffixes?
Don't suffixes suffice?

That all said, I remain con= >vinced that a useful intermediate or probably endpoint
is a toolset that= > targets Windows using cm3cg, ld, as, but otherwise looks like
NT386 as = >much as possible. MAYBE alter the library names to libfoo.*.

sh and = >make are needed for building cm3cg.
I did use Cygwin for that. MinGWin s= >ounds promising here too but I haven't tried.

 - Jay

/>
Get the power of Windows + Web with the new Windows Live. =3D'http://www.windowslive.com?ocid=3DTXT_TAGHM_Wave2_powerofwindows_012008= >' target=3D'_new'>Get it now! >= > >--_d0659847-2f20-454a-9665-5df3b5ce2832_-- From jayk123 at hotmail.com Mon Jan 14 02:20:25 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 14 Jan 2008 01:20:25 +0000 Subject: [M3devel] "shared" vs. "standalone" Message-ID: I was experimenting with gcc/ld flags and I realized: There are two bits for shared/dynamic/standalone, sort of. It looks like cm3 only exposes one. They are: I am "shared", I am a .dll, I am an .so, code can link to me and "share" me. There is, I am "standalone", I have limited dependencies, I link to static .libs where possible, even if I am "shared". The same might not be true of my clients. AKA, same as previous, perhaps I am "dynamic" -- I link dynamically to stuff at runtime. IF I am dynamic, then my clients are. But if I am not, they might not be, and, actually, given CM3's provision for .sa files (on Windows at least), I can have it both ways. I can build a "dynamic" file and my clients can chose to use that or not. It looks like CM3 equates these.That is, you cannot build "standalone" .dlls/.sos..dlls/.sos are implicitly not standalone by virtue of being shared. - Jay _________________________________________________________________ Get the power of Windows + Web with the new Windows Live. http://www.windowslive.com?ocid=TXT_TAGHM_Wave2_powerofwindows_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Mon Jan 14 02:30:58 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 14 Jan 2008 01:30:58 +0000 Subject: [M3devel] religion, philosophy, Posix vs. Win32 In-Reply-To: <200801140040.m0E0eHs7046272@camembert.async.caltech.edu> References: Your message of "Sun, 13 Jan 2008 23:36:40 GMT." <200801140040.m0E0eHs7046272@camembert.async.caltech.edu> Message-ID: ok..well...some provision I guess eventually should be made for those who agree with you and Tony. What will come first is something else. :) A system that is Win32 as much as possible, EXCEPT that it uses the gcc-based backend, and as, and ld, and maybe throws around some forward slashes here and there. I weakly propose: NT386GNU be deleted and NT386MINGWIN (NT386MING? I386_MINGWIN? X86_MINGWIN?) and NT386CYGWIN (NT386CYG? I386_CYGWIN? X86_CYGWIN?) takes its place. but not right now. However, it still might be one target, and you edit the config file. It depends on what people define as a "target" and what it means for two "different" things to be the same "target". The same target can link with same target. To a huge extent, NT386 can link with NT386GNU. Different targets get installed to different pkg directories. SOLgnu and SOLsun might provide a similar set of questions/answers, not that I know anything about it. :) Anyway, I'm in a practical mode now, so I'll stop rambling in email. :) There's also the matter of X Windows or not... - Jay > To: jayk123 at hotmail.com> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] religion, philosophy, Posix vs. Win32 > Date: Sun, 13 Jan 2008 16:40:17 -0800> From: mika at async.caltech.edu> > Jay,> > I don't know if this is completely responsive to your question, and> take it with a grain of salt because I have never programmed on a> "pure" Windows system (and God willing, I never shall).> > I expect the NT386GNU target, Cygwin, Windows-POSIX, whatever you> call it, to look as much as Unix "as possible." (Obviously not,> but as "reasonable".) The main things are (1) yes, /bin/sh, and> (2) Unix (POSIX?) libc---Modula-3 does a good job of covering up> the basic stuff so you don't need to worry about it for the most> part, but sometimes, just sometimes, you need to get, say, some> system information that doesn't have an existing M3 interface (say> the amount of free diskspace or something like that). Then you> should be able to call C code that is portable between Unix and> Windows.> > One thing that is bizarre about the old NT386GNU PM3 that doesn't> conform to the above description: it uses Windows Time.T. It's all> the more bizarre because Cygwin uses Unix time_t. (Time.Now and> time(3) are off by a couple of hundred years on NT386GNU, whereas> they are the same on all Unixes.) I am sure there are other things.> Oh yes, the open-file (default) locking semantics are different> too. Those two are actually the only differences that I noticed> in the programming environments.> > Mika> > Jay writes:> >--_d0659847-2f20-454a-9665-5df3b5ce2832_> >Content-Type: text/plain; charset="iso-8859-1"> >Content-Transfer-Encoding: quoted-printable> >> >The conclusion here is:> > Just try to convince me otherwise. :)> >> >The gist of the question is:> > Just what characteristics of "Posix" and "Win32" should "NT386GNU" have?> >> > Just what characteristics of "Posix" do people notice and like?> >You can't say "the whole thing". :)> >> >Restated:> >> >What is Posix? I don't mean, where is the standard document web site.> >I mean what is it TO YOU?> >> >Is it open/read/write/close?> >Is it fork?> >Is it sbrk?> > On these previous ones, they are interesting to many programmers,> > but Modula-3 already layers over all this, so these are unlikely defining> >characteristics here.> >> >Is it sh? Probably somewhat. But if have you sat in Cygwin sh much vs. cmd?> > It is annoying. Command line history is flaky. Paths are munged to say /cy=> >gdrive.> > You lose the critical F8 command line completion against history feature.> > You lose a lot of editing capability, but do gain some alternate possibly=> > "portable"> > similar.> >> >Is it Perl? No.> >Is it X Windows. I doubt it.> >Is it pthreads? Probably not.> > Or at least vtalarm? Maybe?> > Or setjmp/longjmp? Ok.> > Longjmp to the same buffer multiple times? Not likely.> > Longjmp to a place that has already returned? Not likely.> >All full paths starting with a forward slash? Maybe.> > Backward slash being a valid non-seperator path character? Maybe.> >> >Think about that last one.> >It is valid and occurs in Win32 code to treat forward slash and backward sl=> >ash the same.> >Some code does, some code does not.> >What if you just did that unconditionally, like even in Posix?> >What is the role of backward slash in Posix paths? It either just doesn't o=> >ccur,> >or is an escape character, or is a regular character. Something at a low le=> >vel> >could replace the backward slashes with forward slashes.> >> >I would like to change the code in m3-sys/cm3/m3path.m3 to treat backward s=> >lashes> >and forward slashes the same. Backward slashes just won't occur on Posix, r=> >ight?> >So far I have managed without this change, but not having it has bitten me => >a few times.> >I do have the analogous change to the Win32 path code in m3core.> >> >It is the redundant filenames libfoo.a instead of foo.lib and libfoo.so ins=> >tead of foo.so?> >Perhaps. This seems dumb, redundant to me. Why have prefixes and suffixes?> >Don't suffixes suffice?> >> >That all said, I remain convinced that a useful intermediate or probably en=> >dpoint> >is a toolset that targets Windows using cm3cg, ld, as, but otherwise looks => >like> >NT386 as much as possible. MAYBE alter the library names to libfoo.*.> >> >sh and make are needed for building cm3cg.> >I did use Cygwin for that. MinGWin sounds promising here too but I haven't => >tried.> >> > - Jay> >> >> >_________________________________________________________________> >Get the power of Windows + Web with the new Windows Live.> >http://www.windowslive.com?ocid=3DTXT_TAGHM_Wave2_powerofwindows_012008=> >> >--_d0659847-2f20-454a-9665-5df3b5ce2832_> >Content-Type: text/html; charset="iso-8859-1"> >Content-Transfer-Encoding: quoted-printable> >> >> >> >> >> >The conclusion here is:
 Just try to conv=> >ince me otherwise. :)

The gist of the question is:
  Just wh=> >at characteristics of "Posix" and "Win32" should "NT386GNU" have?

&n=> >bsp;Just what characteristics of "Posix" do people notice and like?
You => >can't say "the whole thing". :)

Restated:

What is Posix? I do=> >n't mean, where is the standard document web site.
I mean what is it TO => >YOU?

Is it open/read/write/close?
Is it fork?
Is it sbrk?
&=> >nbsp; On these previous ones, they are interesting to many programmers,
=> > but Modula-3 already layers over all this, so these are unlikely defi=> >ning
characteristics here.

Is it sh? Probably somewhat. But if ha=> >ve you sat in Cygwin sh much vs. cmd?
 It is annoying. Command line=> > history is flaky. Paths are munged to say /cygdrive.
 You lose the=> > critical F8 command line completion against history feature.
  You=> > lose a lot of editing capability, but do gain some alternate possibly "por=> >table"
  similar.

Is it Perl? No.
Is it X Windows. I doub=> >t it.
Is it pthreads? Probably not.
  Or at least vtalarm? Maybe=> >?
  Or setjmp/longjmp? Ok.
    Longjmp to the sam=> >e buffer multiple times? Not likely.
    Longjmp to a pla=> >ce that has already returned? Not likely.
All full paths starting with a=> > forward slash? Maybe.
  Backward slash being a valid non-seperator=> > path character? Maybe.

Think about that last one.
It is valid an=> >d occurs in Win32 code to treat forward slash and backward slash the same.<=> >br>Some code does, some code does not.
What if you just did that uncondi=> >tionally, like even in Posix?
What is the role of backward slash in Posi=> >x paths? It either just doesn't occur,
or is an escape character, or is => >a regular character. Something at a low level
could replace the backward=> > slashes with forward slashes.

I would like to change the code in m3=> >-sys/cm3/m3path.m3 to treat backward slashes
and forward slashes the sam=> >e. Backward slashes just won't occur on Posix, right?
So far I have mana=> >ged without this change, but not having it has bitten me a few times.
I => >do have the analogous change to the Win32 path code in m3core.

It is=> > the redundant filenames libfoo.a instead of foo.lib and libfoo.so instead => >of foo.so?
Perhaps. This seems dumb, redundant to me. Why have prefixes => >and suffixes?
Don't suffixes suffice?

That all said, I remain con=> >vinced that a useful intermediate or probably endpoint
is a toolset that=> > targets Windows using cm3cg, ld, as, but otherwise looks like
NT386 as => >much as possible. MAYBE alter the library names to libfoo.*.

sh and => >make are needed for building cm3cg.
I did use Cygwin for that. MinGWin s=> >ounds promising here too but I haven't tried.

 - Jay

> />
Get the power of Windows + Web with the new Windows Live. >=3D'http://www.windowslive.com?ocid=3DTXT_TAGHM_Wave2_powerofwindows_012008=> >' target=3D'_new'>Get it now!> >=> >> >--_d0659847-2f20-454a-9665-5df3b5ce2832_-- _________________________________________________________________ Put your friends on the big screen with Windows Vista? + Windows Live?. http://www.microsoft.com/windows/shop/specialoffers.mspx?ocid=TXT_TAGLM_CPC_MediaCtr_bigscreen_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.caltech.edu Mon Jan 14 02:55:21 2008 From: mika at async.caltech.edu (Mika Nystrom) Date: Sun, 13 Jan 2008 17:55:21 -0800 Subject: [M3devel] religion, philosophy, Posix vs. Win32 In-Reply-To: Your message of "Mon, 14 Jan 2008 01:30:58 GMT." Message-ID: <200801140155.m0E1tLxU048776@camembert.async.caltech.edu> Well Unix compatibility is what Cygwin "is for"... it's a little odd to have Cygwin pretend to be Windows---if you want Windows, you don't need Cygwin! The old PM3 doesn't use X for its Trestle. It uses native Windows things. Note there is no contradiction between using Windows UI for Trestle and what I said before. Under Cygwin, you want to be able to use X, just like on Unix. But if M3 doesn't use it, well no matter. Although if you want to extend wish lists, sure, it might be nice to be able to build Trestle under X on Cygwin, too. (I mean, why not? It ought to be "trivial", right?) Mika Jay writes: >--_5cf007a7-8622-47c5-8550-283b4142bb52_ >Content-Type: text/plain; charset="Windows-1252" >Content-Transfer-Encoding: quoted-printable > >ok..well...some provision I guess eventually should be made for those who a= >gree with you and Tony. >What will come first is something else. :) > A system that is Win32 as much as possible, EXCEPT that it uses the gcc-ba= >sed backend, and as, and ld, and maybe throws around some forward slashes h= >ere and there. >=20 >I weakly propose: > NT386GNU be deleted > and NT386MINGWIN (NT386MING? I386_MINGWIN? X86_MINGWIN?) > and NT386CYGWIN (NT386CYG? I386_CYGWIN? X86_CYGWIN?) > takes its place. >=20 >but not right now. >=20 >However, it still might be one target, and you edit the config file. >It depends on what people define as a "target" and what it means for two "d= >ifferent" things to be the same "target". >The same target can link with same target. To a huge extent, NT386 can link= > with NT386GNU. >Different targets get installed to different pkg directories. >=20 >SOLgnu and SOLsun might provide a similar set of questions/answers, not tha= >t I know anything about it. :) >=20 >Anyway, I'm in a practical mode now, so I'll stop rambling in email. :) >=20 >There's also the matter of X Windows or not... >=20 > - Jay > >> To: jayk123 at hotmail.com> CC: m3devel at elegosoft.com> Subject: Re: [M3devel= >] religion, philosophy, Posix vs. Win32 > Date: Sun, 13 Jan 2008 16:40:17 -= >0800> From: mika at async.caltech.edu> > Jay,> > I don't know if this is compl= >etely responsive to your question, and> take it with a grain of salt becaus= >e I have never programmed on a> "pure" Windows system (and God willing, I n= >ever shall).> > I expect the NT386GNU target, Cygwin, Windows-POSIX, whatev= >er you> call it, to look as much as Unix "as possible." (Obviously not,> bu= >t as "reasonable".) The main things are (1) yes, /bin/sh, and> (2) Unix (PO= >SIX?) libc---Modula-3 does a good job of covering up> the basic stuff so yo= >u don't need to worry about it for the most> part, but sometimes, just some= >times, you need to get, say, some> system information that doesn't have an = >existing M3 interface (say> the amount of free diskspace or something like = >that). Then you> should be able to call C code that is portable between Uni= >x and> Windows.> > One thing that is bizarre about the old NT386GNU PM3 tha= >t doesn't> conform to the above description: it uses Windows Time.T. It's a= >ll> the more bizarre because Cygwin uses Unix time_t. (Time.Now and> time(3= >) are off by a couple of hundred years on NT386GNU, whereas> they are the s= >ame on all Unixes.) I am sure there are other things.> Oh yes, the open-fil= >e (default) locking semantics are different> too. Those two are actually th= >e only differences that I noticed> in the programming environments.> > Mika= >> > Jay writes:> >--_d0659847-2f20-454a-9665-5df3b5ce2832_> >Content-Type: = >text/plain; charset=3D"iso-8859-1"> >Content-Transfer-Encoding: quoted-prin= >table> >> >The conclusion here is:> > Just try to convince me otherwise. :)= >> >> >The gist of the question is:> > Just what characteristics of "Posix" = >and "Win32" should "NT386GNU" have?> >> > Just what characteristics of "Pos= >ix" do people notice and like?> >You can't say "the whole thing". :)> >> >R= >estated:> >> >What is Posix? I don't mean, where is the standard document w= >eb site.> >I mean what is it TO YOU?> >> >Is it open/read/write/close?> >Is= > it fork?> >Is it sbrk?> > On these previous ones, they are interesting to = >many programmers,> > but Modula-3 already layers over all this, so these ar= >e unlikely defining> >characteristics here.> >> >Is it sh? Probably somewha= >t. But if have you sat in Cygwin sh much vs. cmd?> > It is annoying. Comman= >d line history is flaky. Paths are munged to say /cy=3D> >gdrive.> > You lo= >se the critical F8 command line completion against history feature.> > You = >lose a lot of editing capability, but do gain some alternate possibly=3D> >= > "portable"> > similar.> >> >Is it Perl? No.> >Is it X Windows. I doubt it.= >> >Is it pthreads? Probably not.> > Or at least vtalarm? Maybe?> > Or setjm= >p/longjmp? Ok.> > Longjmp to the same buffer multiple times? Not likely.> >= > Longjmp to a place that has already returned? Not likely.> >All full paths= > starting with a forward slash? Maybe.> > Backward slash being a valid non-= >seperator path character? Maybe.> >> >Think about that last one.> >It is va= >lid and occurs in Win32 code to treat forward slash and backward sl=3D> >as= >h the same.> >Some code does, some code does not.> >What if you just did th= >at unconditionally, like even in Posix?> >What is the role of backward slas= >h in Posix paths? It either just doesn't o=3D> >ccur,> >or is an escape cha= >racter, or is a regular character. Something at a low le=3D> >vel> >could r= >eplace the backward slashes with forward slashes.> >> >I would like to chan= >ge the code in m3-sys/cm3/m3path.m3 to treat backward s=3D> >lashes> >and f= >orward slashes the same. Backward slashes just won't occur on Posix, r=3D> = >>ight?> >So far I have managed without this change, but not having it has b= >itten me =3D> >a few times.> >I do have the analogous change to the Win32 p= >ath code in m3core.> >> >It is the redundant filenames libfoo.a instead of = >foo.lib and libfoo.so ins=3D> >tead of foo.so?> >Perhaps. This seems dumb, = >redundant to me. Why have prefixes and suffixes?> >Don't suffixes suffice?>= > >> >That all said, I remain convinced that a useful intermediate or probab= >ly en=3D> >dpoint> >is a toolset that targets Windows using cm3cg, ld, as, = >but otherwise looks =3D> >like> >NT386 as much as possible. MAYBE alter the= > library names to libfoo.*.> >> >sh and make are needed for building cm3cg.= >> >I did use Cygwin for that. MinGWin sounds promising here too but I haven= >'t =3D> >tried.> >> > - Jay> >> >> >_______________________________________= >__________________________> >Get the power of Windows + Web with the new Wi= >ndows Live.> >http://www.windowslive.com?ocid=3D3DTXT_TAGHM_Wave2_powerofwi= >ndows_012008=3D> >> >--_d0659847-2f20-454a-9665-5df3b5ce2832_> >Content-Typ= >e: text/html; charset=3D"iso-8859-1"> >Content-Transfer-Encoding: quoted-pr= >intable> >> >> >> >> >> >The conclusion here= > is:
 Just try to conv=3D> >ince me otherwise. :)

The gist o= >f the question is:
  Just wh=3D> >at characteristics of "Posix" and= > "Win32" should "NT386GNU" have?

&n=3D> >bsp;Just what characteristi= >cs of "Posix" do people notice and like?
You =3D> >can't say "the whole = >thing". :)

Restated:

What is Posix? I do=3D> >n't mean, where= > is the standard document web site.
I mean what is it TO =3D> >YOU?
<= >br>Is it open/read/write/close?
Is it fork?
Is it sbrk?
&=3D> >nbs= >p; On these previous ones, they are interesting to many programmers,
=3D= >> > but Modula-3 already layers over all this, so these are unlikely d= >efi=3D> >ning
characteristics here.

Is it sh? Probably somewhat. = >But if ha=3D> >ve you sat in Cygwin sh much vs. cmd?
 It is annoyin= >g. Command line=3D> > history is flaky. Paths are munged to say /cygdrive.<= >br> You lose the=3D> > critical F8 command line completion against his= >tory feature.
  You=3D> > lose a lot of editing capability, but do = >gain some alternate possibly "por=3D> >table"
  similar.

Is = >it Perl? No.
Is it X Windows. I doub=3D> >t it.
Is it pthreads? Proba= >bly not.
  Or at least vtalarm? Maybe=3D> >?
  Or setjmp/lo= >ngjmp? Ok.
    Longjmp to the sam=3D> >e buffer multiple = >times? Not likely.
    Longjmp to a pla=3D> >ce that has = >already returned? Not likely.
All full paths starting with a=3D> > forwa= >rd slash? Maybe.
  Backward slash being a valid non-seperator=3D> >= > path character? Maybe.

Think about that last one.
It is valid an= >=3D> >d occurs in Win32 code to treat forward slash and backward slash the = >same.<=3D> >br>Some code does, some code does not.
What if you just did = >that uncondi=3D> >tionally, like even in Posix?
What is the role of back= >ward slash in Posi=3D> >x paths? It either just doesn't occur,
or is an = >escape character, or is =3D> >a regular character. Something at a low level= >
could replace the backward=3D> > slashes with forward slashes.

I= > would like to change the code in m3=3D> >-sys/cm3/m3path.m3 to treat backw= >ard slashes
and forward slashes the sam=3D> >e. Backward slashes just wo= >n't occur on Posix, right?
So far I have mana=3D> >ged without this chan= >ge, but not having it has bitten me a few times.
I =3D> >do have the ana= >logous change to the Win32 path code in m3core.

It is=3D> > the redu= >ndant filenames libfoo.a instead of foo.lib and libfoo.so instead =3D> >of = >foo.so?
Perhaps. This seems dumb, redundant to me. Why have prefixes =3D= >> >and suffixes?
Don't suffixes suffice?

That all said, I remain = >con=3D> >vinced that a useful intermediate or probably endpoint
is a too= >lset that=3D> > targets Windows using cm3cg, ld, as, but otherwise looks li= >ke
NT386 as =3D> >much as possible. MAYBE alter the library names to lib= >foo.*.

sh and =3D> >make are needed for building cm3cg.
I did use= > Cygwin for that. MinGWin s=3D> >ounds promising here too but I haven't tri= >ed.

 - Jay

> />
Get the power of Windows + = >Web with the new Windows Live. >=3D3D'http://www.windowslive.co= >m?ocid=3D3DTXT_TAGHM_Wave2_powerofwindows_012008=3D> >' target=3D3D'_new'>G= >et it now!> >=3D> >> >--_d0659847-2f20-454a-9665-5df3b5ce= >2832_-- >_________________________________________________________________ >Put your friends on the big screen with Windows Vista=AE + Windows Live=99. >http://www.microsoft.com/windows/shop/specialoffers.mspx?ocid=3DTXT_TAGLM_C= >PC_MediaCtr_bigscreen_012008= > >--_5cf007a7-8622-47c5-8550-283b4142bb52_ >Content-Type: text/html; charset="Windows-1252" >Content-Transfer-Encoding: quoted-printable > > > > > >ok..well...some provision I guess eventually shou= >ld be made for those who agree with you and Tony.
>What will come first is something else. :)
> A system that is Win32 as much as possible, EXCEPT that it uses the g= >cc-based backend, and as, and ld, and maybe throws around some forward slas= >hes here and there.
> 
>I weakly propose:
>  NT386GNU be deleted
>  and NT386MINGWIN (NT386MING? I386_MINGWIN? X86_MINGWIN?)
>  and NT386CYGWIN (NT386CYG? I386_CYGWIN? X86_CYGWIN?)
> takes its place.
> 
>but not right now.
> 
>However, it still might be one target, and you edit the config file.
>It depends on what people define as a "target" and what it means for two "d= >ifferent" things to be the same "target".
>The same target can link with same target. To a huge extent, NT386 can link= > with NT386GNU.
>Different targets get installed to different pkg directories.
> 
>SOLgnu and SOLsun might provide a similar set of questions/answers, not tha= >t I know anything about it. :)
> 
>Anyway, I'm in a practical mode now, so I'll stop rambling in email. :)
> 
>There's also the matter of X Windows or not...
> 
> - Jay

>
>> To: jayk123 at hotmail.com
> CC: m3devel at elegosoft.com
> Subj= >ect: Re: [M3devel] religion, philosophy, Posix vs. Win32
> Date: Sun= >, 13 Jan 2008 16:40:17 -0800
> From: mika at async.caltech.edu
> <= >BR>> Jay,
>
> I don't know if this is completely responsive= > to your question, and
> take it with a grain of salt because I have = >never programmed on a
> "pure" Windows system (and God willing, I nev= >er shall).
>
> I expect the NT386GNU target, Cygwin, Windows-P= >OSIX, whatever you
> call it, to look as much as Unix "as possible." = >(Obviously not,
> but as "reasonable".) The main things are (1) yes, = >/bin/sh, and
> (2) Unix (POSIX?) libc---Modula-3 does a good job of c= >overing up
> the basic stuff so you don't need to worry about it for = >the most
> part, but sometimes, just sometimes, you need to get, say,= > some
> system information that doesn't have an existing M3 interface= > (say
> the amount of free diskspace or something like that). Then yo= >u
> should be able to call C code that is portable between Unix andR>> Windows.
>
> One thing that is bizarre about the old NT= >386GNU PM3 that doesn't
> conform to the above description: it uses W= >indows Time.T. It's all
> the more bizarre because Cygwin uses Unix t= >ime_t. (Time.Now and
> time(3) are off by a couple of hundred years o= >n NT386GNU, whereas
> they are the same on all Unixes.) I am sure the= >re are other things.
> Oh yes, the open-file (default) locking semant= >ics are different
> too. Those two are actually the only differences = >that I noticed
> in the programming environments.
>
> Mi= >ka
>
> Jay writes:
> >--_d0659847-2f20-454a-9665-5df3= >b5ce2832_
> >Content-Type: text/plain; charset=3D"iso-8859-1"
&= >gt; >Content-Transfer-Encoding: quoted-printable
> >
> &g= >t;The conclusion here is:
> > Just try to convince me otherwise. := >)
> >
> >The gist of the question is:
> > Just w= >hat characteristics of "Posix" and "Win32" should "NT386GNU" have?
> = >>
> > Just what characteristics of "Posix" do people notice and= > like?
> >You can't say "the whole thing". :)
> >
>= > >Restated:
> >
> >What is Posix? I don't mean, where = >is the standard document web site.
> >I mean what is it TO YOU?>> >
> >Is it open/read/write/close?
> >Is it fork?= >
> >Is it sbrk?
> > On these previous ones, they are inte= >resting to many programmers,
> > but Modula-3 already layers over = >all this, so these are unlikely defining
> >characteristics here.<= >BR>> >
> >Is it sh? Probably somewhat. But if have you sat i= >n Cygwin sh much vs. cmd?
> > It is annoying. Command line history= > is flaky. Paths are munged to say /cy=3D
> >gdrive.
> > = >You lose the critical F8 command line completion against history feature.R>> > You lose a lot of editing capability, but do gain some alternat= >e possibly=3D
> > "portable"
> > similar.
> >>> >Is it Perl? No.
> >Is it X Windows. I doubt it.
> = >>Is it pthreads? Probably not.
> > Or at least vtalarm? Maybe?<= >BR>> > Or setjmp/longjmp? Ok.
> > Longjmp to the same buffer= > multiple times? Not likely.
> > Longjmp to a place that has alrea= >dy returned? Not likely.
> >All full paths starting with a forward= > slash? Maybe.
> > Backward slash being a valid non-seperator path= > character? Maybe.
> >
> >Think about that last one.
&= >gt; >It is valid and occurs in Win32 code to treat forward slash and bac= >kward sl=3D
> >ash the same.
> >Some code does, some code= > does not.
> >What if you just did that unconditionally, like even= > in Posix?
> >What is the role of backward slash in Posix paths? I= >t either just doesn't o=3D
> >ccur,
> >or is an escape ch= >aracter, or is a regular character. Something at a low le=3D
> >ve= >l
> >could replace the backward slashes with forward slashes.
&= >gt; >
> >I would like to change the code in m3-sys/cm3/m3path.m= >3 to treat backward s=3D
> >lashes
> >and forward slashes= > the same. Backward slashes just won't occur on Posix, r=3D
> >igh= >t?
> >So far I have managed without this change, but not having it= > has bitten me =3D
> >a few times.
> >I do have the analo= >gous change to the Win32 path code in m3core.
> >
> >It i= >s the redundant filenames libfoo.a instead of foo.lib and libfoo.so ins=3D<= >BR>> >tead of foo.so?
> >Perhaps. This seems dumb, redundant= > to me. Why have prefixes and suffixes?
> >Don't suffixes suffice?= >
> >
> >That all said, I remain convinced that a useful i= >ntermediate or probably en=3D
> >dpoint
> >is a toolset t= >hat targets Windows using cm3cg, ld, as, but otherwise looks =3D
> &g= >t;like
> >NT386 as much as possible. MAYBE alter the library names= > to libfoo.*.
> >
> >sh and make are needed for building = >cm3cg.
> >I did use Cygwin for that. MinGWin sounds promising here= > too but I haven't =3D
> >tried.
> >
> > - JayR>> >
> >
> >______________________________________= >___________________________
> >Get the power of Windows + Web with= > the new Windows Live.
> >http://www.windowslive.com?ocid=3D3DTXT_= >TAGHM_Wave2_powerofwindows_012008=3D
> >
> >--_d0659847-2= >f20-454a-9665-5df3b5ce2832_
> >Content-Type: text/html; charset=3D= >"iso-8859-1"
> >Content-Transfer-Encoding: quoted-printable
>= >; >
> ><html>
> ><head>
> ><st= >yle>
> >.hmmessage P
> >{
> >margin:0px;
&= >gt; >padding:0px
> >}
> >body.hmmessage
> >{<= >BR>> >FONT-SIZE: 10pt;
> >FONT-FAMILY:Tahoma
> >}R>> ></style>
> ></head>
> ><body cl= >ass=3D3D'hmmessage'>The conclusion here is:<br>&nbsp;Just try = >to conv=3D
> >ince me otherwise. :)<br><br>The gist of= > the question is:<br>&nbsp; Just wh=3D
> >at characteris= >tics of "Posix" and "Win32" should "NT386GNU" have?<br><br>&= >;n=3D
> >bsp;Just what characteristics of "Posix" do people notice= > and like?<br>You =3D
> >can't say "the whole thing". :)<= >br><br>Restated:<br><br>What is Posix? I do=3D
>= > >n't mean, where is the standard document web site.<br>I mean wha= >t is it TO =3D
> >YOU?<br><br>Is it open/read/write/cl= >ose?<br>Is it fork?<br>Is it sbrk?<br>&=3D
> &g= >t;nbsp; On these previous ones, they are interesting to many programmers,&l= >t;br>=3D
> >&nbsp;but Modula-3 already layers over all this= >, so these are unlikely defi=3D
> >ning<br>characteristics h= >ere.<br><br>Is it sh? Probably somewhat. But if ha=3D
> &= >gt;ve you sat in Cygwin sh much vs. cmd?<br>&nbsp;It is annoying.= > Command line=3D
> > history is flaky. Paths are munged to say /cy= >gdrive.<br>&nbsp;You lose the=3D
> > critical F8 command= > line completion against history feature.<br>&nbsp; You=3D
>= >; > lose a lot of editing capability, but do gain some alternate possibl= >y "por=3D
> >table"<br>&nbsp; similar.<br><br&g= >t;Is it Perl? No.<br>Is it X Windows. I doub=3D
> >t it.<= >br>Is it pthreads? Probably not.<br>&nbsp; Or at least vtalarm= >? Maybe=3D
> >?<br>&nbsp; Or setjmp/longjmp? Ok.<br&g= >t;&nbsp;&nbsp;&nbsp; Longjmp to the sam=3D
> >e buffer= > multiple times? Not likely.<br>&nbsp;&nbsp;&nbsp; Longjm= >p to a pla=3D
> >ce that has already returned? Not likely.<br&g= >t;All full paths starting with a=3D
> > forward slash? Maybe.<b= >r>&nbsp; Backward slash being a valid non-seperator=3D
> > = >path character? Maybe.<br><br>Think about that last one.<br&= >gt;It is valid an=3D
> >d occurs in Win32 code to treat forward sl= >ash and backward slash the same.<=3D
> >br>Some code does, s= >ome code does not.<br>What if you just did that uncondi=3D
> &g= >t;tionally, like even in Posix?<br>What is the role of backward slash= > in Posi=3D
> >x paths? It either just doesn't occur,<br>or = >is an escape character, or is =3D
> >a regular character. Somethin= >g at a low level<br>could replace the backward=3D
> > slashe= >s with forward slashes.<br><br>I would like to change the code = >in m3=3D
> >-sys/cm3/m3path.m3 to treat backward slashes<br>= >and forward slashes the sam=3D
> >e. Backward slashes just won't o= >ccur on Posix, right?<br>So far I have mana=3D
> >ged withou= >t this change, but not having it has bitten me a few times.<br>I =3D<= >BR>> >do have the analogous change to the Win32 path code in m3core.&= >lt;br><br>It is=3D
> > the redundant filenames libfoo.a i= >nstead of foo.lib and libfoo.so instead =3D
> >of foo.so?<br>= >;Perhaps. This seems dumb, redundant to me. Why have prefixes =3D
> &= >gt;and suffixes?<br>Don't suffixes suffice?<br><br>That a= >ll said, I remain con=3D
> >vinced that a useful intermediate or p= >robably endpoint<br>is a toolset that=3D
> > targets Windows= > using cm3cg, ld, as, but otherwise looks like<br>NT386 as =3D
>= >; >much as possible. MAYBE alter the library names to libfoo.*.<br>= >;<br>sh and =3D
> >make are needed for building cm3cg.<br= >>I did use Cygwin for that. MinGWin s=3D
> >ounds promising her= >e too but I haven't tried.<br><br>&nbsp;- Jay<br><= >br><br=3D
> > /><hr />Get the power of Windows + We= >b with the new Windows Live. <a href=3D
> >=3D3D'http://www.win= >dowslive.com?ocid=3D3DTXT_TAGHM_Wave2_powerofwindows_012008=3D
> >= >' target=3D3D'_new'>Get it now!</a></body>
> ></= >html>=3D
> >
> >--_d0659847-2f20-454a-9665-5df3b5ce283= >2_--


Put your friends on the big screen with Windows Vis= >ta=AE + Windows Live=99. pecialoffers.mspx?ocid=3DTXT_TAGLM_CPC_MediaCtr_bigscreen_012008' target=3D= >'_new'>Start now! >= > >--_5cf007a7-8622-47c5-8550-283b4142bb52_-- From dabenavidesd at yahoo.es Mon Jan 14 03:32:37 2008 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Mon, 14 Jan 2008 03:32:37 +0100 (CET) Subject: [M3devel] religion, philosophy, Posix vs. Win32 In-Reply-To: <200801140040.m0E0eHs7046272@camembert.async.caltech.edu> Message-ID: <17920.29413.qm@web27103.mail.ukl.yahoo.com> Hi all, Yes, I also noticed the Time.T issue in pm3 1.1.15 because I was trying to get compiled m3browser and I finally arranged to do that, but the program just broke, and I didn't know about cygwin differences against a real UNIX platform. Also in that pm3 NT386GNU, the winvbt implementation was the one of dec-src not like current cm3 winvbt (that use WIDECHAR as I remember) I tried to have the same interfaces to be able to use from m3browser. Now fortunately you can compile m3browser with NT386 cm3 platform. I just liked very much the way one can make a bootstrap from pm3 from one platform to another and make a minimal compiler for NT386GNU: http://tkb.mpl.com/~tkb/software/misc/pm3-NT386GNU.patch I couldn't repeat the above link instructions in a Debian Sarge machine, with all the pm3 Debian packages installed (available in the Debian Woody http://archive.debian.org/pool/main/p/pm3/ ) I think the reason was I was unable to do all the bootstrap process http://archive.debian.org/pool/main/p/pm3-i386 I would like to have that kind of posix to cygwin capability of port at least a minimal compiler/runtime system. Also, talking about the topic of port NT386 to NT386GNU (more than a year ago) I got some answer from Bert Laverman, Daniel Benavides wrote: > What if we use the cygwin platform to run cm3, an use its runtime > of linker and c Compiler? "Normally this involves a speed penalty, because cygwin will emulate a UNIX environment, and has to translate this to Windows calls. The advantage is of course that you can ignore most differences between Windows and UNIX. If you don't want the speed penalty, and can take care of the platform differences, then you can use the -mno-cygwin flag. However, make sure you use only "real" Windows API calls." Bert Laverman Thanks Mika Nystrom escribi?: Jay, I don't know if this is completely responsive to your question, and take it with a grain of salt because I have never programmed on a "pure" Windows system (and God willing, I never shall). I expect the NT386GNU target, Cygwin, Windows-POSIX, whatever you call it, to look as much as Unix "as possible." (Obviously not, but as "reasonable".) The main things are (1) yes, /bin/sh, and (2) Unix (POSIX?) libc---Modula-3 does a good job of covering up the basic stuff so you don't need to worry about it for the most part, but sometimes, just sometimes, you need to get, say, some system information that doesn't have an existing M3 interface (say the amount of free diskspace or something like that). Then you should be able to call C code that is portable between Unix and Windows. One thing that is bizarre about the old NT386GNU PM3 that doesn't conform to the above description: it uses Windows Time.T. It's all the more bizarre because Cygwin uses Unix time_t. (Time.Now and time(3) are off by a couple of hundred years on NT386GNU, whereas they are the same on all Unixes.) I am sure there are other things. Oh yes, the open-file (default) locking semantics are different too. Those two are actually the only differences that I noticed in the programming environments. Mika Jay writes: >--_d0659847-2f20-454a-9665-5df3b5ce2832_ >Content-Type: text/plain; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > >The conclusion here is: > Just try to convince me otherwise. :) > >The gist of the question is: > Just what characteristics of "Posix" and "Win32" should "NT386GNU" have? > > Just what characteristics of "Posix" do people notice and like? >You can't say "the whole thing". :) > >Restated: > >What is Posix? I don't mean, where is the standard document web site. >I mean what is it TO YOU? > >Is it open/read/write/close? >Is it fork? >Is it sbrk? > On these previous ones, they are interesting to many programmers, > but Modula-3 already layers over all this, so these are unlikely defining >characteristics here. > >Is it sh? Probably somewhat. But if have you sat in Cygwin sh much vs. cmd? > It is annoying. Command line history is flaky. Paths are munged to say /cy= >gdrive. > You lose the critical F8 command line completion against history feature. > You lose a lot of editing capability, but do gain some alternate possibly= > "portable" > similar. > >Is it Perl? No. >Is it X Windows. I doubt it. >Is it pthreads? Probably not. > Or at least vtalarm? Maybe? > Or setjmp/longjmp? Ok. > Longjmp to the same buffer multiple times? Not likely. > Longjmp to a place that has already returned? Not likely. >All full paths starting with a forward slash? Maybe. > Backward slash being a valid non-seperator path character? Maybe. > >Think about that last one. >It is valid and occurs in Win32 code to treat forward slash and backward sl= >ash the same. >Some code does, some code does not. >What if you just did that unconditionally, like even in Posix? >What is the role of backward slash in Posix paths? It either just doesn't o= >ccur, >or is an escape character, or is a regular character. Something at a low le= >vel >could replace the backward slashes with forward slashes. > >I would like to change the code in m3-sys/cm3/m3path.m3 to treat backward s= >lashes >and forward slashes the same. Backward slashes just won't occur on Posix, r= >ight? >So far I have managed without this change, but not having it has bitten me = >a few times. >I do have the analogous change to the Win32 path code in m3core. > >It is the redundant filenames libfoo.a instead of foo.lib and libfoo.so ins= >tead of foo.so? >Perhaps. This seems dumb, redundant to me. Why have prefixes and suffixes? >Don't suffixes suffice? > >That all said, I remain convinced that a useful intermediate or probably en= >dpoint >is a toolset that targets Windows using cm3cg, ld, as, but otherwise looks = >like >NT386 as much as possible. MAYBE alter the library names to libfoo.*. > >sh and make are needed for building cm3cg. >I did use Cygwin for that. MinGWin sounds promising here too but I haven't = >tried. > > - Jay > > >_________________________________________________________________ >Get the power of Windows + Web with the new Windows Live. >http://www.windowslive.com?ocid=3DTXT_TAGHM_Wave2_powerofwindows_012008= > >--_d0659847-2f20-454a-9665-5df3b5ce2832_ >Content-Type: text/html; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > > > >.hmmessage P >{ >margin:0px; >padding:0px >} >body.hmmessage >{ >FONT-SIZE: 10pt; >FONT-FAMILY:Tahoma >} > > >The conclusion here is: Just try to conv= >ince me otherwise. :) The gist of the question is: Just wh= >at characteristics of "Posix" and "Win32" should "NT386GNU" have? &n= >bsp;Just what characteristics of "Posix" do people notice and like? You = >can't say "the whole thing". :) Restated: What is Posix? I do= >n't mean, where is the standard document web site. I mean what is it TO = >YOU? Is it open/read/write/close? Is it fork? Is it sbrk? &= >nbsp; On these previous ones, they are interesting to many programmers, = > but Modula-3 already layers over all this, so these are unlikely defi= >ning characteristics here. Is it sh? Probably somewhat. But if ha= >ve you sat in Cygwin sh much vs. cmd? It is annoying. Command line= > history is flaky. Paths are munged to say /cygdrive. You lose the= > critical F8 command line completion against history feature. You= > lose a lot of editing capability, but do gain some alternate possibly "por= >table" similar. Is it Perl? No. Is it X Windows. I doub= >t it. Is it pthreads? Probably not. Or at least vtalarm? Maybe= >? Or setjmp/longjmp? Ok. Longjmp to the sam= >e buffer multiple times? Not likely. Longjmp to a pla= >ce that has already returned? Not likely. All full paths starting with a= > forward slash? Maybe. Backward slash being a valid non-seperator= > path character? Maybe. Think about that last one. It is valid an= >d occurs in Win32 code to treat forward slash and backward slash the same.<= >br>Some code does, some code does not. What if you just did that uncondi= >tionally, like even in Posix? What is the role of backward slash in Posi= >x paths? It either just doesn't occur, or is an escape character, or is = >a regular character. Something at a low level could replace the backward= > slashes with forward slashes. I would like to change the code in m3= >-sys/cm3/m3path.m3 to treat backward slashes and forward slashes the sam= >e. Backward slashes just won't occur on Posix, right? So far I have mana= >ged without this change, but not having it has bitten me a few times. I = >do have the analogous change to the Win32 path code in m3core. It is= > the redundant filenames libfoo.a instead of foo.lib and libfoo.so instead = >of foo.so? Perhaps. This seems dumb, redundant to me. Why have prefixes = >and suffixes? Don't suffixes suffice? That all said, I remain con= >vinced that a useful intermediate or probably endpoint is a toolset that= > targets Windows using cm3cg, ld, as, but otherwise looks like NT386 as = >much as possible. MAYBE alter the library names to libfoo.*. sh and = >make are needed for building cm3cg. I did use Cygwin for that. MinGWin s= >ounds promising here too but I haven't tried. - Jay > /> --------------------------------- Get the power of Windows + Web with the new Windows Live. >=3D'http://www.windowslive.com?ocid=3DTXT_TAGHM_Wave2_powerofwindows_012008= >' target=3D'_new'>Get it now! >= > >--_d0659847-2f20-454a-9665-5df3b5ce2832_-- --------------------------------- Web Revelaci?n Yahoo! 2007: Premio Favorita del P?blico - ?Vota tu preferida! -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Mon Jan 14 05:39:19 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 14 Jan 2008 04:39:19 +0000 Subject: [M3devel] religion, philosophy, Posix vs. Win32 In-Reply-To: <17920.29413.qm@web27103.mail.ukl.yahoo.com> References: <200801140040.m0E0eHs7046272@camembert.async.caltech.edu> <17920.29413.qm@web27103.mail.ukl.yahoo.com> Message-ID: I agree cross-buildability is nice. That is something NT-non-GNU will never have to the extent that NT-GNU would have, other than cross building from Windows x86 <=> Windows AMD64, etc., or NT => CE, or NT <=> 9x, which is all a fairly large set of cross combinations that do work.. You can have portability at one or more layers..and all that. How many/much do you want? At the Modula-3 level and at the C level and at the command line human interface/"scripting" level (for scripting, just use Quake or Perl or Python, really). For now my priority is using the gcc backend and the associated as and ld and possibly dlltool. And buildability of the gcc backend which requires much more, but is easy enough, I cross that bridge days ago. For some reason the gcc produced mklib.exe crashes at startup, I believe here:C:\dev2\cm3.2\m3-libs\m3core\src\runtime\common\RTLinker.m3(81): IF (imp.import = NIL) THEN imp.import := imp.binder (0); END;or here: C:\dev2\cm3.2\m3-libs\m3core\src\runtime\common\RTLinker.m3(182): IF (imp.import = NIL) THEN imp.import := imp.binder (0); END; imp.binder is NULL. I'm sure there was a check for NULL followed by a jump to NULL and recall the callstack was to around here. You can actually debug it with gdb. :) That was kind of nice. I'm not sure about looking at globals -- info globals just said I had void pointers, but at least I could see the stack. Not that I must use mklib, but I was considering it, and it should work.... 32 bit time_t is a nightmare waiting to happen. Have folks upgraded to 64 bit time_t? Win32, depending on the layer, supports 32 bit time_t seconds since 1970, 64 bit time_t I assume with the same start, and 64 bit time since 1601 something like 100's of nanoseconds, low enough precision to have a plenty large range (i.e. it isn't measuring 4 billionths of seconds and therefore would have already run out. :) ) Having time start at 1970 can be a bit inconenient. It is fine for the timestamps on files, but, e.g. for birthdays? Admittedly 1601 isn't adequate either for historical purposes, and eventually, if you are dealing with history, the Gregorian calendar runs out back in time and things get even much more complicated. :) - Jay Date: Mon, 14 Jan 2008 03:32:37 +0100From: dabenavidesd at yahoo.esSubject: Re: [M3devel] religion, philosophy, Posix vs. Win32To: mika at async.caltech.edu; jayk123 at hotmail.comCC: m3devel at elegosoft.comHi all,Yes, I also noticed the Time.T issue in pm3 1.1.15 because I was trying to get compiled m3browser and I finally arranged to do that, but the program just broke, and I didn't know about cygwin differences against a real UNIX platform.Also in that pm3 NT386GNU, the winvbt implementation was the one of dec-src not like current cm3 winvbt (that use WIDECHAR as I remember)I tried to have the same interfaces to be able to use from m3browser.Now fortunately you can compile m3browser with NT386 cm3 platform.I just liked very much the way one can make a bootstrap from pm3 from one platform to another and make a minimal compiler for NT386GNU:http://tkb.mpl.com/~tkb/software/misc/pm3-NT386GNU.patchI couldn't repeat the above link instructions in a Debian Sarge machine, with all the pm3 Debian packages installed (available in the Debian Woody http://archive.debian.org/pool/main/p/pm3/ ) I think the reason was I was unable to do all the bootstrap process http://archive.debian.org/pool/main/p/pm3-i386I would like to have that kind of posix to cygwin capability of port at least a minimal compiler/runtime system.Also, talking about the topic of port NT386 to NT386GNU (more than a year ago) I got some answer from Bert Laverman, Daniel Benavides wrote: > What if we use the cygwin platform to run cm3, an use its runtime > of linker and c Compiler? "Normally this involves a speed penalty, because cygwin will emulate a UNIX environment, and has to translate this to Windows calls. The advantage is of course that you can ignore most differences between Windows and UNIX. If you don't want the speed penalty, and can take care of the platform differences, then you can use the -mno-cygwin flag. However, make sure you use only "real" Windows API calls." Bert LavermanThanksMika Nystrom escribi?: Jay,I don't know if this is completely responsive to your question, andtake it with a grain of salt because I have never programmed on a"pure" Windows system (and God willing, I never shall).I expect the NT386GNU target, Cygwin, Windows-POSIX, whatever youcall it, to look as much as Unix "as possible." (Obviously not,but as "reasonable".) The main things are (1) yes, /bin/sh, and(2) Unix (POSIX?) libc---Modula-3 does a good job of covering upthe basic stuff so you don't need to worry about it for the mostpart, but sometimes, just sometimes, you need to get, say, somesystem information that doesn't have an existing M3 interface (saythe amount of free diskspace or something like that). Then youshould be able to call C code that is portable between Unix andWindows.One thing that is bizarre about the old NT386GNU PM3 that doesn'tconform to the above description: it uses Windows Time.T. It's allthe more bizarre because Cygwin uses Unix time_t. (Time.Now andtime(3) are off by a couple of hundred years on NT386GNU, whereasthey are the same on all Unixes.) I am sure there are other things.Oh yes, the open-file (default) locking semantics are differenttoo. Those two are actually the only differences that I noticedin the programming environments.MikaJay writes:>--_d0659847-2f20-454a-9665-5df3b5ce2832_>Content-Type: text/plain; charset="iso-8859-1">Content-Transfer-Encoding: quoted-printable>>The conclusion here is:> Just try to convince me otherwise. :)>>The gist of the question is:> Just what characteristics of "Posix" and "Win32" should "NT386GNU" have?>> Just what characteristics of "Posix" do people notice and like?>You can't say "the whole thing". :)>>Restated:>>What is Posix? I don't mean, where is the standard document web site.>I mean what is it TO YOU?>>Is it open/read/write/close?>Is it fork?>Is it sbrk?> On these previous ones, they are interesting to many programmers,> but Modula-3 already layers over all this, so these are unlikely defining>characteristics here.>>Is it sh? Probably somewhat. But if have you sat in Cygwin sh much vs. cmd?> It is annoying. Command line history is flaky. Paths are munged to say /cy=>gdrive.> You lose the critical F8 command line completion against history feature.> You lose a lot of editing capability, but do gain some alternate possibly=> "portable"> similar.>>Is it Perl? No.>Is it X Windows. I doubt it.>Is it pthreads? Probably not.> Or at least vtalarm? Maybe?> Or setjmp/longjmp? Ok.> Longjmp to the same buffer multiple times? Not likely.> Longjmp to a place that has already returned? Not likely.>All full paths starting with a forward slash? Maybe.> Backward slash being a valid non-seperator path character? Maybe.>>Think about that last one.>It is valid and occurs in Win32 code to treat forward slash and backward sl=>ash the same.>Some code does, some code does not.>What if you just did that unconditionally, like even in Posix?>What is the role of backward slash in Posix paths? It either just doesn't o=>ccur,>or is an escape character, or is a regular character. Something at a low le=>vel>could replace the backward slashes with forward slashes.>>I would like to change the code in m3-sys/cm3/m3path.m3 to treat backward s=>lashes>and forward slashes the same. Backward slashes just won't occur on Posix, r=>ight?>So far I have managed without this change, but not having it has bitten me =>a few times.>I do have the analogous change to the Win32 path code in m3core.>>It is the redundant filenames libfoo.a instead of foo.lib and libfoo.so ins=>tead of foo.so?>Perhaps. This seems dumb, redundant to me. Why have prefixes and suffixes?>Don't suffixes suffice?>>That all said, I remain convinced that a useful intermediate or probably en=>dpoint>is a toolset that targets Windows using cm3cg, ld, as, but otherwise looks =>like>NT386 as much as possible. MAYBE alter the library names to libfoo.*.>>sh and make are needed for building cm3cg.>I did use Cygwin for that. MinGWin sounds promising here too but I haven't =>tried.>> - Jay>>>_________________________________________________________________>Get the power of Windows + Web with the new Windows Live.>http://www.windowslive.com?ocid=3DTXT_TAGHM_Wave2_powerofwindows_012008=>>--_d0659847-2f20-454a-9665-5df3b5ce2832_>Content-Type: text/html; charset="iso-8859-1">Content-Transfer-Encoding: quoted-printable>>>> >>The conclusion here is: Just try to conv=>ince me otherwise. :)The gist of the question is: Just wh=>at characteristics of "Posix" and "Win32" should "NT386GNU" have?&n=>bsp;Just what characteristics of "Posix" do people notice and like?You =>can't say "the whole thing". :)Restated:What is Posix? I do=>n't mean, where is the standard document web site.I mean what is it TO =>YOU?Is it open/read/write/close?Is it fork?Is it sbrk?&=>nbsp; On these previous ones, they are interesting to many programmers,=> but Modula-3 already layers over all this, so these are unlikely defi=>ningcharacteristics here.Is it sh? Probably somewhat. But if ha=>ve you sat in Cygwin sh much vs. cmd? It is annoying. Command line=> history is flaky. Paths are munged to say /cygdrive. You lose the=> critical F8 command line completion against history feature. You=> lose a lot of editing capability, but do gain some alternate possibly "por=>table" similar.Is it Perl? No.Is it X Windows. I doub=>t it.Is it pthreads? Probably not. Or at least vtalarm? Maybe=>? Or setjmp/longjmp? Ok. Longjmp to the sam=>e buffer multiple times? Not likely. Longjmp to a pla=>ce that has already returned? Not likely.All full paths starting with a=> forward slash? Maybe. Backward slash being a valid non-seperator=> path character? Maybe.Think about that last one.It is valid an=>d occurs in Win32 code to treat forward slash and backward slash the same.<=>br>Some code does, some code does not.What if you just did that uncondi=>tionally, like even in Posix?What is the role of backward slash in Posi=>x paths? It either just doesn't occur,or is an escape character, or is =>a regular character. Something at a low levelcould replace the backward=> slashes with forward slashes.I would like to change the code in m3=>-sys/cm3/m3path.m3 to treat backward slashesand forward slashes the sam=>e. Backward slashes just won't occur on Posix, right?So far I have mana=>ged without this change, but not having it has bitten me a few times.I =>do have the analogous change to the Win32 path code in m3core.It is=> the redundant filenames libfoo.a instead of foo.lib and libfoo.so instead =>of foo.so?Perhaps. This seems dumb, redundant to me. Why have prefixes =>and suffixes?Don't suffixes suffice?That all said, I remain con=>vinced that a useful intermediate or probably endpointis a toolset that=> targets Windows using cm3cg, ld, as, but otherwise looks likeNT386 as =>much as possible. MAYBE alter the library names to libfoo.*.sh and =>make are needed for building cm3cg.I did use Cygwin for that. MinGWin s=>ounds promising here too but I haven't tried. - Jay> /> Get the power of Windows + Web with the new Windows Live. >=3D'http://www.windowslive.com?ocid=3DTXT_TAGHM_Wave2_powerofwindows_012008=>' target=3D'_new'>Get it now!>=>>--_d0659847-2f20-454a-9665-5df3b5ce2832_-- Web Revelaci?n Yahoo! 2007:Premio Favorita del P?blico - ?Vota tu preferida! _________________________________________________________________ Watch ?Cause Effect,? a show about real people making a real difference. http://im.live.com/Messenger/IM/MTV/?source=text_watchcause -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon Jan 14 16:47:28 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 14 Jan 2008 10:47:28 -0500 Subject: [M3devel] Static chains Message-ID: Rodney, I just realised that the static chains variables are *not* always being set up for nested function internal use. i.e., callers will pass them, but nested functions that don't explicitly use them will not have a static chain. Is this something essential for you? Why would you need a static chain from within a nested function that doesn't use any outer scope variables? Since it doesn't use any outer scope variables they cannot affect its execution, so debugging the value of those variables seems unnecessary. This is the default behavior of gcc for static chains. -- Tony From hendrik at topoi.pooq.com Mon Jan 14 18:19:50 2008 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Mon, 14 Jan 2008 12:19:50 -0500 Subject: [M3devel] Static chains In-Reply-To: References: Message-ID: <20080114171950.GB20313@topoi.pooq.com> On Mon, Jan 14, 2008 at 10:47:28AM -0500, Tony Hosking wrote: > Rodney, > > I just realised that the static chains variables are *not* always > being set up for nested function internal use. i.e., callers will > pass them, but nested functions that don't explicitly use them will > not have a static chain. Is this something essential for you? Why > would you need a static chain from within a nested function that > doesn't use any outer scope variables? Since it doesn't use any > outer scope variables they cannot affect its execution, so debugging > the value of those variables seems unnecessary. This is the default > behavior of gcc for static chains. And having them could break languages where it's possible to export procedures to places where their nonlocal procedures are still in existence but the intermediate lexical levels which they don't use are not. (Algol 68 is a case in point) -- hendrik > > -- Tony > From hosking at cs.purdue.edu Mon Jan 14 19:36:31 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 14 Jan 2008 13:36:31 -0500 Subject: [M3devel] Static chains In-Reply-To: <20080114171950.GB20313@topoi.pooq.com> References: <20080114171950.GB20313@topoi.pooq.com> Message-ID: <4C674DDA-00B2-4AFF-B78F-597C7ACC0E73@cs.purdue.edu> I believe Modula-3's downward-only (ie, only to callee's) exposure rules for procedure values will avoid this issue. On Jan 14, 2008, at 12:19 PM, hendrik at topoi.pooq.com wrote: > On Mon, Jan 14, 2008 at 10:47:28AM -0500, Tony Hosking wrote: >> Rodney, >> >> I just realised that the static chains variables are *not* always >> being set up for nested function internal use. i.e., callers will >> pass them, but nested functions that don't explicitly use them will >> not have a static chain. Is this something essential for you? Why >> would you need a static chain from within a nested function that >> doesn't use any outer scope variables? Since it doesn't use any >> outer scope variables they cannot affect its execution, so debugging >> the value of those variables seems unnecessary. This is the default >> behavior of gcc for static chains. > > And having them could break languages where it's possible to export > procedures to places where their nonlocal procedures are still in > existence but the intermediate lexical levels which they don't use are > not. (Algol 68 is a case in point) > > -- hendrik > >> >> -- Tony >> From darko at darko.org Mon Jan 14 21:35:45 2008 From: darko at darko.org (Darko) Date: Mon, 14 Jan 2008 12:35:45 -0800 Subject: [M3devel] GC question Message-ID: <9BB575E4-75B0-432D-BDEF-49F8F8644D80@darko.org> Tony, I imagine you're intimately familiar with the garbage collector implementation. If I wanted to implement a 'reallocate' function that preserved references to an object although the object was reallocated, ie change all existing references from the old object to the new object, would this be straight forward using the code of the current GC implementation? Is there any existing function that might do something like this already? Thanks, Darko. From mika at async.caltech.edu Mon Jan 14 21:53:18 2008 From: mika at async.caltech.edu (Mika Nystrom) Date: Mon, 14 Jan 2008 12:53:18 -0800 Subject: [M3devel] GC question In-Reply-To: Your message of "Mon, 14 Jan 2008 12:35:45 PST." <9BB575E4-75B0-432D-BDEF-49F8F8644D80@darko.org> Message-ID: <200801142053.m0EKrIMi087093@camembert.async.caltech.edu> It would have to be able to return an error, no? If there's an ambiguous root pointing to the object... Darko writes: >Tony, > >I imagine you're intimately familiar with the garbage collector >implementation. If I wanted to implement a 'reallocate' function that >preserved references to an object although the object was reallocated, >ie change all existing references from the old object to the new >object, would this be straight forward using the code of the current >GC implementation? Is there any existing function that might do >something like this already? > >Thanks, >Darko. From ndantam at purdue.edu Mon Jan 14 22:05:34 2008 From: ndantam at purdue.edu (Neil T. Dantam) Date: Mon, 14 Jan 2008 16:05:34 -0500 Subject: [M3devel] GC question In-Reply-To: <9BB575E4-75B0-432D-BDEF-49F8F8644D80@darko.org> References: <9BB575E4-75B0-432D-BDEF-49F8F8644D80@darko.org> Message-ID: <478BCE9E.70504@purdue.edu> Darko wrote: > If I wanted to implement a 'reallocate' function that preserved > references to an object although the object was reallocated, ie > change all existing references from the old object to the new > object, would this be straight forward using the code of the > current GC implementation? Probably not. Because precise pointer locations are not known for the stacks, they are treated conservatively, and any objects potentially referenced from the stacks are pinned in place by the GC. It would be impossible to update references to your reallocated object if those references live in the stack because we do not have precise information for stack pointer locations. -- Neil T. Dantam From ndantam at purdue.edu Mon Jan 14 22:09:30 2008 From: ndantam at purdue.edu (Neil T. Dantam) Date: Mon, 14 Jan 2008 16:09:30 -0500 Subject: [M3devel] GC question In-Reply-To: <200801142053.m0EKrIMi087093@camembert.async.caltech.edu> References: <200801142053.m0EKrIMi087093@camembert.async.caltech.edu> Message-ID: <478BCF8A.7090409@purdue.edu> Mika Nystrom wrote: > It would have to be able to return an error, no? If there's > an ambiguous root pointing to the object... If you have a reference to the object that you are reallocating which you must pass to this procedure, then you have a reference on the stack creating an ambiguous root. Also, the GC doesn't just pin objects, it pins entire pages because there may be a derived pointer referring to some object in that page. So if your object to reallocate is on the same page as anything referenced from the stack, you couldn't automatically update pointers. Now if you only want to update pointers in heap, maybe there's a way to make that work. -- Neil T. Dantam From hosking at cs.purdue.edu Mon Jan 14 22:17:11 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 14 Jan 2008 16:17:11 -0500 Subject: [M3devel] GC question In-Reply-To: <200801142053.m0EKrIMi087093@camembert.async.caltech.edu> References: <200801142053.m0EKrIMi087093@camembert.async.caltech.edu> Message-ID: <425DF106-9200-4E49-86FE-DCF377FEC631@cs.purdue.edu> I'm not sure what your purpose here might be. You shouldn't assume anything about an object's precise location since the collector is free to move it around. What are you trying to do? If you are trying to *replace* one object with another and have all references to the old object refer to the new object, then, yes, you really need to get intimately involved with the GC, since it will need to go through the whole heap and redirect those references. It is doable, but messy, and probably requires that all threads in the system be stopped while you pull off the switch. To do it without stopping all the threads requires that you do something much smarter (see papers on replicating GC...). On Jan 14, 2008, at 3:53 PM, Mika Nystrom wrote: > It would have to be able to return an error, no? If there's > an ambiguous root pointing to the object... > > > Darko writes: >> Tony, >> >> I imagine you're intimately familiar with the garbage collector >> implementation. If I wanted to implement a 'reallocate' function that >> preserved references to an object although the object was >> reallocated, >> ie change all existing references from the old object to the new >> object, would this be straight forward using the code of the current >> GC implementation? Is there any existing function that might do >> something like this already? >> >> Thanks, >> Darko. From hosking at cs.purdue.edu Mon Jan 14 22:17:46 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 14 Jan 2008 16:17:46 -0500 Subject: [M3devel] GC question In-Reply-To: <200801142053.m0EKrIMi087093@camembert.async.caltech.edu> References: <200801142053.m0EKrIMi087093@camembert.async.caltech.edu> Message-ID: PS Yes, if there is an ambiguous root pointing at the object then you are stuck. On Jan 14, 2008, at 3:53 PM, Mika Nystrom wrote: > It would have to be able to return an error, no? If there's > an ambiguous root pointing to the object... > > > Darko writes: >> Tony, >> >> I imagine you're intimately familiar with the garbage collector >> implementation. If I wanted to implement a 'reallocate' function that >> preserved references to an object although the object was >> reallocated, >> ie change all existing references from the old object to the new >> object, would this be straight forward using the code of the current >> GC implementation? Is there any existing function that might do >> something like this already? >> >> Thanks, >> Darko. From darko at darko.org Mon Jan 14 22:28:18 2008 From: darko at darko.org (Darko) Date: Mon, 14 Jan 2008 13:28:18 -0800 Subject: [M3devel] GC question In-Reply-To: <425DF106-9200-4E49-86FE-DCF377FEC631@cs.purdue.edu> References: <200801142053.m0EKrIMi087093@camembert.async.caltech.edu> <425DF106-9200-4E49-86FE-DCF377FEC631@cs.purdue.edu> Message-ID: <1AD34A8D-A9A6-464A-B8A1-792B74355528@darko.org> Yep, I want to replace one object with another. One application is to expand open arrays without searching large data structures for references to replace. Maybe a simpler question is can you increase the size of an allocated object without getting messy? On 14/01/2008, at 1:17 PM, Tony Hosking wrote: > I'm not sure what your purpose here might be. You shouldn't assume > anything about an object's precise location since the collector is > free to move it around. What are you trying to do? If you are > trying to *replace* one object with another and have all references > to the old object refer to the new object, then, yes, you really > need to get intimately involved with the GC, since it will need to > go through the whole heap and redirect those references. It is > doable, but messy, and probably requires that all threads in the > system be stopped while you pull off the switch. To do it without > stopping all the threads requires that you do something much smarter > (see papers on replicating GC...). > > On Jan 14, 2008, at 3:53 PM, Mika Nystrom wrote: > >> It would have to be able to return an error, no? If there's >> an ambiguous root pointing to the object... >> >> >> Darko writes: >>> Tony, >>> >>> I imagine you're intimately familiar with the garbage collector >>> implementation. If I wanted to implement a 'reallocate' function >>> that >>> preserved references to an object although the object was >>> reallocated, >>> ie change all existing references from the old object to the new >>> object, would this be straight forward using the code of the current >>> GC implementation? Is there any existing function that might do >>> something like this already? >>> >>> Thanks, >>> Darko. > From rodney.bates at wichita.edu Tue Jan 15 00:24:35 2008 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Mon, 14 Jan 2008 17:24:35 -0600 Subject: [M3devel] Static chains In-Reply-To: References: Message-ID: <478BEF33.2050203@wichita.edu> Think of the debugger as an interpreter for a substantial subset of the language. When the program is stopped at some point, m3gdb can, in effect, inject code to evaluate an arbitrary expression, typed by the debugger user, or execute an arbitrary assignment or call statement. Although there are a number of gaps yet in the implementation, m3gdb is approaching fitting this description. The user-typed code can both create and use static link values that do not occur in the original code that the compiler saws. The simplest example is, when stopped in a nested procedure, the user types 'print NonLocalVariable'. This works fine right now, unless the compiler has not stored the SL in the current proc's activation record, which a compiler might well do if the nested proc, as coded, has no references to any nonlocal variables. (Or keeps the SL only in a register, etc.) You could say this is only a convenience, as the user could work around it by just typing 'up' the exact number of times to get to the static parent's frame (which is, of course, also a dynamic ancestor). But that can slow down debugging a great deal, and I often find it a very important convenience. Anyway, you could say that to a degree about much of what a debugger does. A more complex example might be 'print Nested1(Nested2,NonlocalVar)', where Nested1 and Nested2 are nested procedures. Here, the debugger has create and pass the appropriate SL value in order to call Nested1, which, unless Nested1 is one scope deeper than the current stop point, also entails m3gdb's fetching the SL that was given to some procedure on the current dynamic call chain. The same things are required of m3gdb to construct the closure for Nested2, which it must pass to Nested1. And if NonlocalVar is in an outer scope where Nested1 and/or Nested2 aren't visible, there would be no workaround possible at all. Tony, I haven't been able to try out your latest change anyway, as I seem to have once again regressed to not being able to get CM3 to link to a working version of libpthread on Mandriva. Also, I am about to travel for a week, so may be out of this discussion for a while. Tony Hosking wrote: > Rodney, > > I just realised that the static chains variables are *not* always being > set up for nested function internal use. i.e., callers will pass them, > but nested functions that don't explicitly use them will not have a > static chain. Is this something essential for you? Why would you need > a static chain from within a nested function that doesn't use any outer > scope variables? Since it doesn't use any outer scope variables they > cannot affect its execution, so debugging the value of those variables > seems unnecessary. This is the default behavior of gcc for static chains. > > -- Tony > > -- ------------------------------------------------------------- Rodney 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 Jan 15 00:09:08 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 14 Jan 2008 18:09:08 -0500 Subject: [M3devel] GC question In-Reply-To: <1AD34A8D-A9A6-464A-B8A1-792B74355528@darko.org> References: <200801142053.m0EKrIMi087093@camembert.async.caltech.edu> <425DF106-9200-4E49-86FE-DCF377FEC631@cs.purdue.edu> <1AD34A8D-A9A6-464A-B8A1-792B74355528@darko.org> Message-ID: <5D72E480-17E4-4394-B617-83A7A8AF2F66@cs.purdue.edu> On Jan 14, 2008, at 4:28 PM, Darko wrote: > Yep, I want to replace one object with another. One application is > to expand open arrays without searching large data structures for > references to replace. Maybe a simpler question is can you increase > the size of an allocated object without getting messy? Not easily. Old-time Smalltalk systems had an "Object become:" method that you could use to reallocate in this way, but a level of indirection was used to avoid having to scan the heap. How about using an explicit level of indirection of your own? The WeakRef interface may be useful to you here too, so that you can discard indirection state when there are no other references to the object. > > > On 14/01/2008, at 1:17 PM, Tony Hosking wrote: > >> I'm not sure what your purpose here might be. You shouldn't >> assume anything about an object's precise location since the >> collector is free to move it around. What are you trying to do? >> If you are trying to *replace* one object with another and have >> all references to the old object refer to the new object, then, >> yes, you really need to get intimately involved with the GC, since >> it will need to go through the whole heap and redirect those >> references. It is doable, but messy, and probably requires that >> all threads in the system be stopped while you pull off the >> switch. To do it without stopping all the threads requires that >> you do something much smarter (see papers on replicating GC...). >> >> On Jan 14, 2008, at 3:53 PM, Mika Nystrom wrote: >> >>> It would have to be able to return an error, no? If there's >>> an ambiguous root pointing to the object... >>> >>> >>> Darko writes: >>>> Tony, >>>> >>>> I imagine you're intimately familiar with the garbage collector >>>> implementation. If I wanted to implement a 'reallocate' function >>>> that >>>> preserved references to an object although the object was >>>> reallocated, >>>> ie change all existing references from the old object to the new >>>> object, would this be straight forward using the code of the >>>> current >>>> GC implementation? Is there any existing function that might do >>>> something like this already? >>>> >>>> Thanks, >>>> Darko. >> From hendrik at topoi.pooq.com Tue Jan 15 00:30:47 2008 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Mon, 14 Jan 2008 18:30:47 -0500 Subject: [M3devel] Static chains In-Reply-To: <4C674DDA-00B2-4AFF-B78F-597C7ACC0E73@cs.purdue.edu> References: <20080114171950.GB20313@topoi.pooq.com> <4C674DDA-00B2-4AFF-B78F-597C7ACC0E73@cs.purdue.edu> Message-ID: <20080114233047.GC20313@topoi.pooq.com> On Mon, Jan 14, 2008 at 01:36:31PM -0500, Tony Hosking wrote: > I believe Modula-3's downward-only (ie, only to callee's) exposure > rules for procedure values will avoid this issue. Yes, that's true. But you mentioned static links i the context o gcc: > >>the value of those variables seems unnecessary. This is the default > >>behavior of gcc for static chains. so perhaps there was still some relevance. -- hendrik From darko at darko.org Tue Jan 15 01:39:23 2008 From: darko at darko.org (Darko) Date: Mon, 14 Jan 2008 16:39:23 -0800 Subject: [M3devel] GC question In-Reply-To: <5D72E480-17E4-4394-B617-83A7A8AF2F66@cs.purdue.edu> References: <200801142053.m0EKrIMi087093@camembert.async.caltech.edu> <425DF106-9200-4E49-86FE-DCF377FEC631@cs.purdue.edu> <1AD34A8D-A9A6-464A-B8A1-792B74355528@darko.org> <5D72E480-17E4-4394-B617-83A7A8AF2F66@cs.purdue.edu> Message-ID: <44DE2F53-50D6-4A32-AD7E-F8716E425D7B@darko.org> Yes, I was considering that and other options, I was just hoping to move the complexity to the compiler, where I thought it might already be implemented. I have to try keep my code very clean and simple. On 14/01/2008, at 3:09 PM, Tony Hosking wrote: > > On Jan 14, 2008, at 4:28 PM, Darko wrote: > >> Yep, I want to replace one object with another. One application is >> to expand open arrays without searching large data structures for >> references to replace. Maybe a simpler question is can you increase >> the size of an allocated object without getting messy? > > Not easily. > > Old-time Smalltalk systems had an "Object become:" method that you > could use to reallocate in this way, but a level of indirection was > used to avoid having to scan the heap. How about using an explicit > level of indirection of your own? The WeakRef interface may be > useful to you here too, so that you can discard indirection state > when there are no other references to the object. > >> >> >> On 14/01/2008, at 1:17 PM, Tony Hosking wrote: >> >>> I'm not sure what your purpose here might be. You shouldn't >>> assume anything about an object's precise location since the >>> collector is free to move it around. What are you trying to do? >>> If you are trying to *replace* one object with another and have >>> all references to the old object refer to the new object, then, >>> yes, you really need to get intimately involved with the GC, since >>> it will need to go through the whole heap and redirect those >>> references. It is doable, but messy, and probably requires that >>> all threads in the system be stopped while you pull off the >>> switch. To do it without stopping all the threads requires that >>> you do something much smarter (see papers on replicating GC...). >>> >>> On Jan 14, 2008, at 3:53 PM, Mika Nystrom wrote: >>> >>>> It would have to be able to return an error, no? If there's >>>> an ambiguous root pointing to the object... >>>> >>>> >>>> Darko writes: >>>>> Tony, >>>>> >>>>> I imagine you're intimately familiar with the garbage collector >>>>> implementation. If I wanted to implement a 'reallocate' function >>>>> that >>>>> preserved references to an object although the object was >>>>> reallocated, >>>>> ie change all existing references from the old object to the new >>>>> object, would this be straight forward using the code of the >>>>> current >>>>> GC implementation? Is there any existing function that might do >>>>> something like this already? >>>>> >>>>> Thanks, >>>>> Darko. >>> > From rodney.bates at wichita.edu Tue Jan 15 02:56:05 2008 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Mon, 14 Jan 2008 19:56:05 -0600 Subject: [M3devel] Static chains In-Reply-To: <20080114171950.GB20313@topoi.pooq.com> References: <20080114171950.GB20313@topoi.pooq.com> Message-ID: <478C12B5.4050908@wichita.edu> Modula-3 prevents the dangling environment problem with a rule that, while a nested procedure can indeed be passed as a parameter, it can not be assigned to a variable. Only a top-level procedure value can be assigned to a variable. In general, this has to be checked at runtime, at the time of an assignment. The compilers all do this by making the RT representation of a procedure value explicitly denote whether it is nested or top-level. hendrik at topoi.pooq.com wrote: > On Mon, Jan 14, 2008 at 10:47:28AM -0500, Tony Hosking wrote: > >>Rodney, >> >>I just realised that the static chains variables are *not* always >>being set up for nested function internal use. i.e., callers will >>pass them, but nested functions that don't explicitly use them will >>not have a static chain. Is this something essential for you? Why >>would you need a static chain from within a nested function that >>doesn't use any outer scope variables? Since it doesn't use any >>outer scope variables they cannot affect its execution, so debugging >>the value of those variables seems unnecessary. This is the default >>behavior of gcc for static chains. > > > And having them could break languages where it's possible to export > procedures to places where their nonlocal procedures are still in > existence but the intermediate lexical levels which they don't use are > not. (Algol 68 is a case in point) > > -- hendrik > > >>-- Tony >> > > -- ------------------------------------------------------------- Rodney 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 Jan 15 03:13:39 2008 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Mon, 14 Jan 2008 20:13:39 -0600 Subject: [M3devel] Static chains In-Reply-To: <478BEF33.2050203@wichita.edu> References: <478BEF33.2050203@wichita.edu> Message-ID: <478C16D3.6040405@wichita.edu> See embedded corrections I (Rodney M. Bates) wrote: > Think of the debugger as an interpreter for a substantial subset of the > language. When the program is stopped at some point, m3gdb can, in effect, > inject code to evaluate an arbitrary expression, typed by the debugger > user, or execute an arbitrary assignment or call statement. Although > there are a number of gaps yet in the implementation, m3gdb is approaching > fitting this description. > > The user-typed code can both create and use static link values that do > not occur in the original code that the compiler saws. The simplest ^saw > example is, when stopped in a nested procedure, the user types > 'print NonLocalVariable'. This works fine right now, unless the compiler > has not stored the SL in the current proc's activation record, which a > compiler might well do if the nested proc, as coded, has no references > to any nonlocal variables. (Or keeps the SL only in a register, etc.) > > You could say this is only a convenience, as the user could work around > it by just typing 'up' the exact number of times to get to the static > parent's frame (which is, of course, also a dynamic ancestor). But that > can slow down debugging a great deal, and I often find it a very important > convenience. Anyway, you could say that to a degree about much of what a > debugger does. > > A more complex example might be 'print Nested1(Nested2,NonlocalVar)', > where Nested1 and Nested2 are nested procedures. Here, the debugger > has create and pass the appropriate SL value in order to call Nested1, > which, unless Nested1 is one scope deeper than the current stop point, > also entails m3gdb's fetching the SL that was given to some procedure > on the current dynamic call chain. The same things are required of ^static chain. Although it is true that the proc is also on the dynamic chain, that is not what I meant and is confusing at best. > m3gdb to construct the closure for Nested2, which it must pass to Nested1. > And if NonlocalVar is in an outer scope where Nested1 and/or Nested2 > aren't visible, there would be no workaround possible at all. > > Tony, I haven't been able to try out your latest change anyway, as > I seem to have once again regressed to not being able to get CM3 to > link to a working version of libpthread on Mandriva. Also, I am about > to travel for a week, so may be out of this discussion for a while. > > > Tony Hosking wrote: > >> Rodney, >> >> I just realised that the static chains variables are *not* always >> being set up for nested function internal use. i.e., callers will >> pass them, but nested functions that don't explicitly use them will >> not have a static chain. Is this something essential for you? Why >> would you need a static chain from within a nested function that >> doesn't use any outer scope variables? Since it doesn't use any >> outer scope variables they cannot affect its execution, so debugging >> the value of those variables seems unnecessary. This is the default >> behavior of gcc for static chains. >> >> -- Tony >> >> > -- ------------------------------------------------------------- Rodney 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 Jan 15 06:54:05 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 15 Jan 2008 05:54:05 +0000 Subject: [M3devel] Static chains In-Reply-To: <478BEF33.2050203@wichita.edu> References: <478BEF33.2050203@wichita.edu> Message-ID: I really don't think an optimizing compiler should be passing around unused static links just for the debugger to use. The debugger should look up the stack itself. Optimizing compilers remove locals, remove parameters, remove functions, create custom calling conventions, etc. An non-optimizing compiler, sure, I guess. Though it seems some level of optimization should be always on. It pains me to think that every little function call I write might be made, and not inlined. Microsoft compilers now do inlining across static lib boundaries. Or that constant arithmetic like:#define A 1 #define B 2 int c = (A + B) might be computed at runtime. Or that while(1) .. .. if ... break; might generate a runtime check if 1 is not zero (along with the code bloat). Microsoft has "__forceinline", and it is a warning or error if the compiler is unable to inline such a function. - Jay> Date: Mon, 14 Jan 2008 17:24:35 -0600> From: rodney.bates at wichita.edu> To: hosking at cs.purdue.edu> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] Static chains> > Think of the debugger as an interpreter for a substantial subset of the> language. When the program is stopped at some point, m3gdb can, in effect,> inject code to evaluate an arbitrary expression, typed by the debugger> user, or execute an arbitrary assignment or call statement. Although> there are a number of gaps yet in the implementation, m3gdb is approaching> fitting this description.> > The user-typed code can both create and use static link values that do> not occur in the original code that the compiler saws. The simplest> example is, when stopped in a nested procedure, the user types> 'print NonLocalVariable'. This works fine right now, unless the compiler> has not stored the SL in the current proc's activation record, which a> compiler might well do if the nested proc, as coded, has no references> to any nonlocal variables. (Or keeps the SL only in a register, etc.)> > You could say this is only a convenience, as the user could work around> it by just typing 'up' the exact number of times to get to the static> parent's frame (which is, of course, also a dynamic ancestor). But that> can slow down debugging a great deal, and I often find it a very important> convenience. Anyway, you could say that to a degree about much of what a> debugger does.> > A more complex example might be 'print Nested1(Nested2,NonlocalVar)',> where Nested1 and Nested2 are nested procedures. Here, the debugger> has create and pass the appropriate SL value in order to call Nested1,> which, unless Nested1 is one scope deeper than the current stop point,> also entails m3gdb's fetching the SL that was given to some procedure> on the current dynamic call chain. The same things are required of> m3gdb to construct the closure for Nested2, which it must pass to Nested1.> And if NonlocalVar is in an outer scope where Nested1 and/or Nested2> aren't visible, there would be no workaround possible at all.> > Tony, I haven't been able to try out your latest change anyway, as> I seem to have once again regressed to not being able to get CM3 to> link to a working version of libpthread on Mandriva. Also, I am about> to travel for a week, so may be out of this discussion for a while.> > > Tony Hosking wrote:> > Rodney,> > > > I just realised that the static chains variables are *not* always being > > set up for nested function internal use. i.e., callers will pass them, > > but nested functions that don't explicitly use them will not have a > > static chain. Is this something essential for you? Why would you need > > a static chain from within a nested function that doesn't use any outer > > scope variables? Since it doesn't use any outer scope variables they > > cannot affect its execution, so debugging the value of those variables > > seems unnecessary. This is the default behavior of gcc for static chains.> > > > -- Tony> > > > > > -- > -------------------------------------------------------------> Rodney M. Bates, retired assistant professor> Dept. of Computer Science, Wichita State University> Wichita, KS 67260-0083> 316-978-3922> rodney.bates at wichita.edu _________________________________________________________________ Put your friends on the big screen with Windows Vista? + Windows Live?. http://www.microsoft.com/windows/shop/specialoffers.mspx?ocid=TXT_TAGLM_CPC_MediaCtr_bigscreen_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Tue Jan 15 07:00:48 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 15 Jan 2008 06:00:48 +0000 Subject: [M3devel] Static chains In-Reply-To: <478BEF33.2050203@wichita.edu> References: <478BEF33.2050203@wichita.edu> Message-ID: ps: I "like" nested functions, and even the ability for them to capture their outer context, like in Scheme: (define make-adder (lambda x) (lambda y) (x + y)) (define add5 (make-adder 5)) (add 5 4) => 9 but I've lived without this long enough. Capturing just the right amount of context manually is also easy. Otherwise the compiler/runtime either has to a) heap allocate and garbage collect all stack frames b) do the analysis to decide what to heap allocate. I believe Java and C# do b. They don't necessarily have nested "functions", but nested classes with functions, same thing. Java might make you declare captured state as "final" (aka const aka readonly). That said, heap allocated stack frames are a powerful measure in preventing stack exhaustion, which is an otherwise seemingly difficult and ignored problem. The stack is not infinite yet most programmers rarely think about its size. - Jay From: jayk123 at hotmail.comTo: rodney.bates at wichita.edu; hosking at cs.purdue.eduCC: m3devel at elegosoft.comSubject: RE: [M3devel] Static chainsDate: Tue, 15 Jan 2008 05:54:05 +0000 I really don't think an optimizing compiler should be passing around unused static links just for the debugger to use. The debugger should look up the stack itself. Optimizing compilers remove locals, remove parameters, remove functions, create custom calling conventions, etc. An non-optimizing compiler, sure, I guess. Though it seems some level of optimization should be always on.It pains me to think that every little function call I write might be made, and not inlined.Microsoft compilers now do inlining across static lib boundaries.Or that constant arithmetic like:#define A 1#define B 2int c = (A + B) might be computed at runtime. Or that while(1) .. .. if ... break; might generate a runtime check if 1 is not zero (along with the code bloat). Microsoft has "__forceinline", and it is a warning or error if the compiler is unable to inline such a function. - Jay> Date: Mon, 14 Jan 2008 17:24:35 -0600> From: rodney.bates at wichita.edu> To: hosking at cs.purdue.edu> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] Static chains> > Think of the debugger as an interpreter for a substantial subset of the> language. When the program is stopped at some point, m3gdb can, in effect,> inject code to evaluate an arbitrary expression, typed by the debugger> user, or execute an arbitrary assignment or call statement. Although> there are a number of gaps yet in the implementation, m3gdb is approaching> fitting this description.> > The user-typed code can both create and use static link values that do> not occur in the original code that the compiler saws. The simplest> example is, when stopped in a nested procedure, the user types> 'print NonLocalVariable'. This works fine right now, unless the compiler> has not stored the SL in the current proc's activation record, which a> compiler might well do if the nested proc, as coded, has no references> to any nonlocal variables. (Or keeps the SL only in a register, etc.)> > You could say this is only a convenience, as the user could work around> it by just typing 'up' the exact number of times to get to the static> parent's frame (which is, of course, also a dynamic ancestor). But that> can slow down debugging a great deal, and I often find it a very important> convenience. Anyway, you could say that to a degree about much of what a> debugger does.> > A more complex example might be 'print Nested1(Nested2,NonlocalVar)',> where Nested1 and Nested2 are nested procedures. Here, the debugger> has create and pass the appropriate SL value in order to call Nested1,> which, unless Nested1 is one scope deeper than the current stop point,> also entails m3gdb's fetching the SL that was given to some procedure> on the current dynamic call chain. The same things are required of> m3gdb to construct the closure for Nested2, which it must pass to Nested1.> And if NonlocalVar is in an outer scope where Nested1 and/or Nested2> aren't visible, there would be no workaround possible at all.> > Tony, I haven't been able to try out your latest change anyway, as> I seem to have once again regressed to not being able to get CM3 to> link to a working version of libpthread on Mandriva. Also, I am about> to travel for a week, so may be out of this discussion for a while.> > > Tony Hosking wrote:> > Rodney,> > > > I just realised that the static chains variables are *not* always being > > set up for nested function internal use. i.e., callers will pass them, > > but nested functions that don't explicitly use them will not have a > > static chain. Is this something essential for you? Why would you need > > a static chain from within a nested function that doesn't use any outer > > scope variables? Since it doesn't use any outer scope variables they > > cannot affect its execution, so debugging the value of those variables > > seems unnecessary. This is the default behavior of gcc for static chains.> > > > -- Tony> > > > > > -- > -------------------------------------------------------------> Rodney M. Bates, retired assistant professor> Dept. of Computer Science, Wichita State University> Wichita, KS 67260-0083> 316-978-3922> rodney.bates at wichita.edu Put your friends on the big screen with Windows Vista? + Windows Live?. Start now! _________________________________________________________________ Share life as it happens with the new Windows Live. http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Tue Jan 15 08:00:13 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 15 Jan 2008 07:00:13 +0000 Subject: [M3devel] "crazy cross" In-Reply-To: <20080105011335.n767h3zbz4gcgk4k@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> Message-ID: It looks like at least cm3 is "always" target-independent. Whatever target is defined to in cm3.cfg, if it is one of the built in known ones, cm3 will generate code for. Except maybe NT386, though it need not be -- cm3 could have both the .obj and "gcc tree" writing backends both linked into it and dynamically chose between them. Maybe it already does. cm3 operates at a fairly high level when using gcc, and the target specific stuff is just some data about the name of setjmp, the sizeof jmp_buf, etc..The "only" "problem" is then m3cg/as/ld/link.m3cg could be moved to $CM3_INSTALL/pkg/x/HOST/TARGET. cm3, along with everything else, could be $CM3_INSTALL/pkg/x/HOST leaving $CM3_INSTALL/bin/cm3 that is sh and $CM3_INSTALL/bin/cm3.py or cm3.cmd that calls out to cm3. "Fixing" as/ld, well, I don't suppose they tend to be target neutral do they? You'd have to import them like gcc and build them n times. Gaining a much slower build, much larger tree. I suppose anyone could do this themselves, and change cm3.cfg appropriately. Doing things "officially" this way for one "big" distribution, probably folks would not go for. - Jay From: jayk123 at hotmail.comTo: m3devel at elegosoft.comSubject: "crazy cross"Date: Sat, 5 Jan 2008 01:22:13 +0000 You've all heard of "Canadian cross"?It is cross-building a cross-compiler.I'm sitting in Windows. I'm going to build a compiler that is going to run on Linux that is going to target Solaris.For one example.You've all seen that Apple has switches like so:gcc -arch i386 ppc ppc64 x86_64 hello.cand poof out comes a binary that runs natively on four architecturesI don't like the "inconvenience" of non cross systems and having to have all the machines/OSes just to build the binaries.I realize that you hit the wall if you actually want to test the results. So cross building only gets so much.Of course I also don't want to multiply out build times for tools...Ok, well what is the possibility of:cm3 -target NT386cm3 -target NT386 -target PPC_DARWIN? In my crazy imagination, you have: \cm3\bin\cm3.cmd %~dp0..\libexec\%processor_architecture%\%TARGET%\cm3.exe %* \cm3\bin\cm3 #!/bin/sh dirname(dirname($0))/libexec/`uname whatever`/$TARGET/cm3 $@Thus it becomes POSSIBLE to have an n x m matrix, host x target, and be able to build"anything" from one environment.Actually the targets could all be merged into one .exe or be .dll/.sos.Except the code isn't setup for that.Interesting?I guess the hard part is the C code and linking?The Modula-3 stuff is already setup to do most of this? (partly by virtue of all that header rewriting that I labeled sleazy) - Jay Share life as it happens with the new Windows Live. Start sharing! _________________________________________________________________ Share life as it happens with the new Windows Live. http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Tue Jan 15 14:34:25 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 15 Jan 2008 13:34:25 +0000 Subject: [M3devel] NT386GNU status Message-ID: I can build a lot of std, at least up to m3ui. However..nothing works. Everything crashes. In order to build std, I copied back the NT386 cm3 and mklib, though the config sets TARGET=NT386GNU and runs cm3cg. (i.e. I'm not just using the NT386 backend!) The crash is what I mentioned the other day: D:\>\cygwin\bin\gdb \dev2\cm3.2\m3-sys\cm3\NT386GNU\cm3.exeGNU gdb 6.5.50.20060706-cvs (cygwin-special)Copyright (C) 2006 Free Software Foundation, Inc.GDB is free software, covered by the GNU General Public License, and you arewelcome to change it and/or distribute copies of it under certain conditions.Type "show copying" to see the conditions.There is absolutely no warranty for GDB. Type "show warranty" for details.This GDB was configured as "i686-pc-cygwin"...(gdb) runStarting program: D:/dev2/cm3.2/m3-sys/cm3/NT386GNU/cm3.exeLoaded symbols for /cygdrive/d/WINDOWS/system32/ntdll.dllLoaded symbols for /cygdrive/d/WINDOWS/system32/kernel32.dllLoaded symbols for /cygdrive/d/WINDOWS/system32/advapi32.dllLoaded symbols for /cygdrive/d/WINDOWS/system32/rpcrt4.dllLoaded symbols for /cygdrive/d/WINDOWS/system32/gdi32.dllLoaded symbols for /cygdrive/d/WINDOWS/system32/user32.dllLoaded symbols for /cygdrive/d/WINDOWS/system32/msvcrt.dllLoaded symbols for /cygdrive/d/WINDOWS/system32/wsock32.dllLoaded symbols for /cygdrive/d/WINDOWS/system32/ws2_32.dllLoaded symbols for /cygdrive/d/WINDOWS/system32/ws2help.dll Program received signal SIGSEGV, Segmentation fault.0x00000000 in ?? ()(gdb) bt#0 0x00000000 in ?? ()#1 0x005de831 in RTLinker__FindModules (M3_DjPxE3_m=0x682340) at RTLinker.m3:182#2 0x005de5fb in RTLinker__AddUnitI (M3_DjPxE3_m=0x682340) at RTLinker.m3:111#3 0x005de6b0 in RTLinker__AddUnit (M3_DjPxE5_b=0x603fd0) at RTLinker.m3:122#4 0x005de34d in RTLinker__InitRuntime (M3_AcxOUs_p_argc=0, M3_AJWxb1_p_argv=0x3f2bf0, M3_AJWxb1_p_envp=0x3f24c0, M3_AJWxb1_p_instance=0x1) at RTLinker.m3:42#5 0x00401315 in main (argc=1, argv=0x3f24c0, envp=0x3f2bf0) at _m3main.mc:3(gdb) qThe program is running. Exit anyway? (y or n) y D:\> Oh, m3ui and related are broken due to: D:\dev2\cm3.2\m3-tools\m3bundle\NT386GNU\m3bundle -name formseditBundle -FD:\DOCUME~1\Jay\LOCALS~1\Temp\qknew source -> compiling FormsEditVBT.i3new source -> compiling formseditBundle.i3new source -> compiling FormsEditVBT.m3new source -> compiling FormsEdit.m3new source -> compiling formseditBundle.m3 -> linking formsedit.exeD:\dev2\cm3.2/m3-ui\ui\NT386GNU\m3ui.lib.sa(WinTrestle.mo): In function `WinTrestle__ButtonEvent':WinTrestle.m3:1843: undefined reference to `WindowFromPoint at 4'collect2: ld returned 1 exit status"D:\\dev2\\cm3.2\m3-sys\cminstall\src\config\NT386GNU", line 583: quake runtimeerror: link failed, see D:\dev2\cm3.2\m3-ui\formsedit\NT386GNU\formsedit.lst for more information \mingw\bin\nm \MinGW\lib\libuser32.a | findstr WindowFromPoint00000000 T _WindowFromPoint at 800000000 I __imp__WindowFromPoint at 8 Maybe Tony will fix my __stdcall work. :)Or maybe the problem is the declaration.Or maybe I can confirm it is passing a small struct by pointer instead of by referenceand just write a little translation thunk. But also see why NT386 works.Not a big deal. Trestle can wait. If anyone wants to try this stuff out, debug, I can either share diffs or commit them.They are actually pretty small.I just have to look into the definitions of the runtime linker/binder stuff and/orthe assembly, see if there's some disconnect somewhere. Other gdb above, this is all with mingwin + msys. They are enough to build cm3cg. mingwin should suffice for the rest. The ld that comes with the mingwin that free Qt gives you is too old, from around 2004. It doesn't support "response files", which are needed for building some packages due to command line length. The change was made circa 2005. Current "released" Mingwin works (I didn't use "technology preview") Probably I'll take a break for now. - Jay _________________________________________________________________ Share life as it happens with the new Windows Live. http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Tue Jan 15 14:41:49 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 15 Jan 2008 08:41:49 -0500 Subject: [M3devel] Static chains In-Reply-To: References: <478BEF33.2050203@wichita.edu> Message-ID: <8E6886FC-DAD4-452A-9771-F40640045A74@cs.purdue.edu> Yes, I am leery myself of much the same. Gcc is very careful about when a nested procedure is allocated a static link. On Jan 15, 2008, at 12:54 AM, Jay wrote: > I really don't think an optimizing compiler should be passing > around unused static links just for the debugger to use. The > debugger should look up the stack itself. > > Optimizing compilers remove locals, remove parameters, remove > functions, create custom calling conventions, etc. > > An non-optimizing compiler, sure, I guess. > > Though it seems some level of optimization should be always on. > It pains me to think that every little function call I write might > be made, and not inlined. > Microsoft compilers now do inlining across static lib boundaries. > Or that constant arithmetic like: > #define A 1 > #define B 2 > int c = (A + B) > > might be computed at runtime. > > Or that > while(1) > .. > .. if ... break; > > might generate a runtime check if 1 is not zero (along with the > code bloat). > > Microsoft has "__forceinline", and it is a warning or error if the > compiler is unable to inline such a function. > > - Jay > > > > Date: Mon, 14 Jan 2008 17:24:35 -0600 > > From: rodney.bates at wichita.edu > > To: hosking at cs.purdue.edu > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] Static chains > > > > Think of the debugger as an interpreter for a substantial subset > of the > > language. When the program is stopped at some point, m3gdb can, > in effect, > > inject code to evaluate an arbitrary expression, typed by the > debugger > > user, or execute an arbitrary assignment or call statement. Although > > there are a number of gaps yet in the implementation, m3gdb is > approaching > > fitting this description. > > > > The user-typed code can both create and use static link values > that do > > not occur in the original code that the compiler saws. The simplest > > example is, when stopped in a nested procedure, the user types > > 'print NonLocalVariable'. This works fine right now, unless the > compiler > > has not stored the SL in the current proc's activation record, > which a > > compiler might well do if the nested proc, as coded, has no > references > > to any nonlocal variables. (Or keeps the SL only in a register, > etc.) > > > > You could say this is only a convenience, as the user could work > around > > it by just typing 'up' the exact number of times to get to the > static > > parent's frame (which is, of course, also a dynamic ancestor). > But that > > can slow down debugging a great deal, and I often find it a very > important > > convenience. Anyway, you could say that to a degree about much of > what a > > debugger does. > > > > A more complex example might be 'print Nested1 > (Nested2,NonlocalVar)', > > where Nested1 and Nested2 are nested procedures. Here, the debugger > > has create and pass the appropriate SL value in order to call > Nested1, > > which, unless Nested1 is one scope deeper than the current stop > point, > > also entails m3gdb's fetching the SL that was given to some > procedure > > on the current dynamic call chain. The same things are required of > > m3gdb to construct the closure for Nested2, which it must pass to > Nested1. > > And if NonlocalVar is in an outer scope where Nested1 and/or Nested2 > > aren't visible, there would be no workaround possible at all. > > > > Tony, I haven't been able to try out your latest change anyway, as > > I seem to have once again regressed to not being able to get CM3 to > > link to a working version of libpthread on Mandriva. Also, I am > about > > to travel for a week, so may be out of this discussion for a while. > > > > > > Tony Hosking wrote: > > > Rodney, > > > > > > I just realised that the static chains variables are *not* > always being > > > set up for nested function internal use. i.e., callers will > pass them, > > > but nested functions that don't explicitly use them will not > have a > > > static chain. Is this something essential for you? Why would > you need > > > a static chain from within a nested function that doesn't use > any outer > > > scope variables? Since it doesn't use any outer scope variables > they > > > cannot affect its execution, so debugging the value of those > variables > > > seems unnecessary. This is the default behavior of gcc for > static chains. > > > > > > -- Tony > > > > > > > > > > -- > > ------------------------------------------------------------- > > Rodney M. Bates, retired assistant professor > > Dept. of Computer Science, Wichita State University > > Wichita, KS 67260-0083 > > 316-978-3922 > > rodney.bates at wichita.edu > > > Put your friends on the big screen with Windows Vista? + Windows > Live?. Start now! From hosking at cs.purdue.edu Tue Jan 15 14:47:13 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 15 Jan 2008 08:47:13 -0500 Subject: [M3devel] "crazy cross" 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> Message-ID: On Jan 15, 2008, at 2:00 AM, Jay wrote: > It looks like at least cm3 is "always" target-independent. > Whatever target is defined to in cm3.cfg, if it is one of the built > in known ones, cm3 will generate code for. Except maybe NT386, > though it need not be -- cm3 could have both the .obj and "gcc > tree" writing backends both linked into it and dynamically chose > between them. Yes, the cm3 front-end will generate .mo/.io files for any target on any other host. The gcc-based backend runs as a separate process (there are license issues with linking the gcc-based backend directly with the front-end). > Maybe it already does. > cm3 operates at a fairly high level when using gcc, and the target > specific stuff is just some data about the name of setjmp, the > sizeof jmp_buf, etc.. > > The "only" "problem" is then m3cg/as/ld/link. > m3cg could be moved to $CM3_INSTALL/pkg/x/HOST/TARGET. True! > cm3, along with everything else, could be $CM3_INSTALL/pkg/x/HOST > leaving $CM3_INSTALL/bin/cm3 that is sh and $CM3_INSTALL/bin/cm3.py > or cm3.cmd that calls out to cm3. Possibly. > "Fixing" as/ld, well, I don't suppose they tend to be target > neutral do they? You'd have to import them like gcc and build them > n times. Gaining a much slower build, much larger tree. Indeed. > I suppose anyone could do this themselves, and change cm3.cfg > appropriately. Doing things "officially" this way for one "big" > distribution, probably folks would not go for. This is how bootstraps to other targets typically go: cm3 *.m3- >*.mo. Copy .mo files to target. Build cm3cg for target. cm3cg *.mo->*.ms as *.ms->*.o ld *.o->libs/execs. > > > - Jay > > > > From: jayk123 at hotmail.com > To: m3devel at elegosoft.com > Subject: "crazy cross" > Date: Sat, 5 Jan 2008 01:22:13 +0000 > > You've all heard of "Canadian cross"? > > It is cross-building a cross-compiler. > I'm sitting in Windows. I'm going to build a compiler that is going > to run on Linux that is going to target Solaris. > For one example. > > You've all seen that Apple has switches like so: > > gcc -arch i386 ppc ppc64 x86_64 hello.c > and poof out comes a binary that runs natively on four architectures > > I don't like the "inconvenience" of non cross systems and having to > have all the machines/OSes just to build the binaries. > I realize that you hit the wall if you actually want to test the > results. So cross building only gets so much. > Of course I also don't want to multiply out build times for tools... > > Ok, well what is the possibility of: > > cm3 -target NT386 > cm3 -target NT386 -target PPC_DARWIN > > ? In my crazy imagination, you have: > > \cm3\bin\cm3.cmd > %~dp0..\libexec\%processor_architecture%\%TARGET%\cm3.exe %* > > \cm3\bin\cm3 > #!/bin/sh > dirname(dirname($0))/libexec/`uname whatever`/$TARGET/cm3 $@ > > Thus it becomes POSSIBLE to have an n x m matrix, host x target, > and be able to build > "anything" from one environment. > > Actually the targets could all be merged into one .exe or > be .dll/.sos. > Except the code isn't setup for that. > > Interesting? > > I guess the hard part is the C code and linking? > The Modula-3 stuff is already setup to do most of this? > (partly by virtue of all that header rewriting that I labeled > sleazy) > > - Jay > > > > Share life as it happens with the new Windows Live. Start sharing! > > Share life as it happens with the new Windows Live. Start sharing! From hosking at cs.purdue.edu Tue Jan 15 14:54:50 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 15 Jan 2008 08:54:50 -0500 Subject: [M3devel] NT386GNU status In-Reply-To: References: Message-ID: <6D01FCB8-D43D-4927-BA3C-23C566E818E6@cs.purdue.edu> On Jan 15, 2008, at 8:34 AM, Jay wrote: > I can build a lot of std, at least up to m3ui. > > However..nothing works. > > Everything crashes. > > In order to build std, I copied back the NT386 cm3 and mklib, > though the config sets TARGET=NT386GNU and runs cm3cg. > (i.e. I'm not just using the NT386 backend!) > > The crash is what I mentioned the other day: > > D:\>\cygwin\bin\gdb \dev2\cm3.2\m3-sys\cm3\NT386GNU\cm3.exe > GNU gdb 6.5.50.20060706-cvs (cygwin-special) > Copyright (C) 2006 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, > and you are > welcome to change it and/or distribute copies of it under certain > conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for > details. > This GDB was configured as "i686-pc-cygwin"... > (gdb) run > Starting program: D:/dev2/cm3.2/m3-sys/cm3/NT386GNU/cm3.exe > Loaded symbols for /cygdrive/d/WINDOWS/system32/ntdll.dll > Loaded symbols for /cygdrive/d/WINDOWS/system32/kernel32.dll > Loaded symbols for /cygdrive/d/WINDOWS/system32/advapi32.dll > Loaded symbols for /cygdrive/d/WINDOWS/system32/rpcrt4.dll > Loaded symbols for /cygdrive/d/WINDOWS/system32/gdi32.dll > Loaded symbols for /cygdrive/d/WINDOWS/system32/user32.dll > Loaded symbols for /cygdrive/d/WINDOWS/system32/msvcrt.dll > Loaded symbols for /cygdrive/d/WINDOWS/system32/wsock32.dll > Loaded symbols for /cygdrive/d/WINDOWS/system32/ws2_32.dll > Loaded symbols for /cygdrive/d/WINDOWS/system32/ws2help.dll > > Program received signal SIGSEGV, Segmentation fault. > 0x00000000 in ?? () > (gdb) bt > #0 0x00000000 in ?? () > #1 0x005de831 in RTLinker__FindModules (M3_DjPxE3_m=0x682340) > at RTLinker.m3:182 > #2 0x005de5fb in RTLinker__AddUnitI (M3_DjPxE3_m=0x682340) at > RTLinker.m3:111 > #3 0x005de6b0 in RTLinker__AddUnit (M3_DjPxE5_b=0x603fd0) at > RTLinker.m3:122 > #4 0x005de34d in RTLinker__InitRuntime (M3_AcxOUs_p_argc=0, > M3_AJWxb1_p_argv=0x3f2bf0, M3_AJWxb1_p_envp=0x3f24c0, > M3_AJWxb1_p_instance=0x1) at RTLinker.m3:42 > #5 0x00401315 in main (argc=1, argv=0x3f24c0, envp=0x3f2bf0) at > _m3main.mc:3 > (gdb) q > The program is running. Exit anyway? (y or n) y > D:\> Looks like a problem with the run-time linker. Something must be broken in the compiler-generated link info. Not sure why... > Oh, m3ui and related are broken due to: > > D:\dev2\cm3.2\m3-tools\m3bundle\NT386GNU\m3bundle -name > formseditBundle -FD:\DOC > UME~1\Jay\LOCALS~1\Temp\qk > new source -> compiling FormsEditVBT.i3 > new source -> compiling formseditBundle.i3 > new source -> compiling FormsEditVBT.m3 > new source -> compiling FormsEdit.m3 > new source -> compiling formseditBundle.m3 > -> linking formsedit.exe > D:\dev2\cm3.2/m3-ui\ui\NT386GNU\m3ui.lib.sa(WinTrestle.mo): In > function `WinTres > tle__ButtonEvent': > WinTrestle.m3:1843: undefined reference to `WindowFromPoint at 4' > collect2: ld returned 1 exit status > "D:\\dev2\\cm3.2\m3-sys\cminstall\src\config\NT386GNU", line 583: > quake runtime > error: link failed, see D:\dev2\cm3.2\m3-ui\formsedit\NT386GNU > \formsedit.lst for > more information > > \mingw\bin\nm \MinGW\lib\libuser32.a | findstr WindowFromPoint > 00000000 T _WindowFromPoint at 8 > 00000000 I __imp__WindowFromPoint at 8 > > Maybe Tony will fix my __stdcall work. :) Yes, I know what needs doing to m3cc(cm3cg). Just need to do it. > Or maybe the problem is the declaration. > Or maybe I can confirm it is passing a small struct by pointer > instead of by reference > and just write a little translation thunk. But also see why NT386 > works. > Not a big deal. Trestle can wait. > > If anyone wants to try this stuff out, debug, I can either share > diffs or commit them. > They are actually pretty small. > I just have to look into the definitions of the runtime linker/ > binder stuff and/or > the assembly, see if there's some disconnect somewhere. > > Other gdb above, this is all with mingwin + msys. > They are enough to build cm3cg. > mingwin should suffice for the rest. > > The ld that comes with the mingwin that free Qt gives you is too > old, from around 2004. > It doesn't support "response files", which are needed for building > some packages due to command line length. > The change was made circa 2005. Current "released" Mingwin works (I > didn't use "technology preview") > > Probably I'll take a break for now. > > - Jay > > Share life as it happens with the new Windows Live. Start sharing! From jayk123 at hotmail.com Wed Jan 16 00:24:50 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 15 Jan 2008 23:24:50 +0000 Subject: [M3devel] "crazy cross" 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> Message-ID: I forgot some vaguely related things. Do people worry about optimizing away creating new processes? Could m3cg be built as an .so/.dll? Probably. And ok license-wise? Could m3cg be run once per package instead of once per source? gcc and cl both can be: cl -c foo.c bar.c gcc -c foo.c bar.c Currently in NT386GNU I depend on -o, gcc -c foo.c -o foo.obj Would need to handle that, not a big deal. Also, in the scheme below, either cm3.sh/cm3.cmd would have a switch to merely print the "real" cm3's path, or, just as well, sysinfo.sh et. al. would know how to find it, save that process. Furthermore -- multithreaded build? I believe, maybe absent bootstrapping, that cm3 could read "all" the m3makefiles, work out the dependency graph trivially, and build things in parallel. Bootstrappinging works too. It builds only what you say, in the right order. The Python scripts can implement this easily enough. - Jay ---------------------------------------- > CC: m3devel at elegosoft.com > From: hosking at cs.purdue.edu > Subject: Re: [M3devel] "crazy cross" > Date: Tue, 15 Jan 2008 08:47:13 -0500 > To: jayk123 at hotmail.com > > > On Jan 15, 2008, at 2:00 AM, Jay wrote: > >> It looks like at least cm3 is "always" target-independent. >> Whatever target is defined to in cm3.cfg, if it is one of the built >> in known ones, cm3 will generate code for. Except maybe NT386, >> though it need not be -- cm3 could have both the .obj and "gcc >> tree" writing backends both linked into it and dynamically chose >> between them. > > Yes, the cm3 front-end will generate .mo/.io files for any target on > any other host. The gcc-based backend runs as a separate process > (there are license issues with linking the gcc-based backend directly > with the front-end). > >> Maybe it already does. >> cm3 operates at a fairly high level when using gcc, and the target >> specific stuff is just some data about the name of setjmp, the >> sizeof jmp_buf, etc.. >> >> The "only" "problem" is then m3cg/as/ld/link. >> m3cg could be moved to $CM3_INSTALL/pkg/x/HOST/TARGET. > > True! > >> cm3, along with everything else, could be $CM3_INSTALL/pkg/x/HOST >> leaving $CM3_INSTALL/bin/cm3 that is sh and $CM3_INSTALL/bin/cm3.py >> or cm3.cmd that calls out to cm3. > > Possibly. > >> "Fixing" as/ld, well, I don't suppose they tend to be target >> neutral do they? You'd have to import them like gcc and build them >> n times. Gaining a much slower build, much larger tree. > > Indeed. > >> I suppose anyone could do this themselves, and change cm3.cfg >> appropriately. Doing things "officially" this way for one "big" >> distribution, probably folks would not go for. > > This is how bootstraps to other targets typically go: cm3 *.m3- > >*.mo. Copy .mo files to target. Build cm3cg for target. cm3cg > *.mo->*.ms as *.ms->*.o ld *.o->libs/execs. > > >> >> >> - Jay >> >> >> >> From: jayk123 at hotmail.com >> To: m3devel at elegosoft.com >> Subject: "crazy cross" >> Date: Sat, 5 Jan 2008 01:22:13 +0000 >> >> You've all heard of "Canadian cross"? >> >> It is cross-building a cross-compiler. >> I'm sitting in Windows. I'm going to build a compiler that is going >> to run on Linux that is going to target Solaris. >> For one example. >> >> You've all seen that Apple has switches like so: >> >> gcc -arch i386 ppc ppc64 x86_64 hello.c >> and poof out comes a binary that runs natively on four architectures >> >> I don't like the "inconvenience" of non cross systems and having to >> have all the machines/OSes just to build the binaries. >> I realize that you hit the wall if you actually want to test the >> results. So cross building only gets so much. >> Of course I also don't want to multiply out build times for tools... >> >> Ok, well what is the possibility of: >> >> cm3 -target NT386 >> cm3 -target NT386 -target PPC_DARWIN >> >> ? In my crazy imagination, you have: >> >> \cm3\bin\cm3.cmd >> %~dp0..\libexec\%processor_architecture%\%TARGET%\cm3.exe %* >> >> \cm3\bin\cm3 >> #!/bin/sh >> dirname(dirname($0))/libexec/`uname whatever`/$TARGET/cm3 $@ >> >> Thus it becomes POSSIBLE to have an n x m matrix, host x target, >> and be able to build >> "anything" from one environment. >> >> Actually the targets could all be merged into one .exe or >> be .dll/.sos. >> Except the code isn't setup for that. >> >> Interesting? >> >> I guess the hard part is the C code and linking? >> The Modula-3 stuff is already setup to do most of this? >> (partly by virtue of all that header rewriting that I labeled >> sleazy) >> >> - Jay >> >> >> >> Share life as it happens with the new Windows Live. Start sharing! >> >> Share life as it happens with the new Windows Live. Start sharing! > _________________________________________________________________ Watch ?Cause Effect,? a show about real people making a real difference. http://im.live.com/Messenger/IM/MTV/?source=text_watchcause From hosking at cs.purdue.edu Wed Jan 16 00:51:44 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 15 Jan 2008 18:51:44 -0500 Subject: [M3devel] "crazy cross" 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> Message-ID: <1DDFAB54-77B6-4593-B309-2C767D4F1FAC@cs.purdue.edu> On Jan 15, 2008, at 6:24 PM, Jay wrote: > > I forgot some vaguely related things. > > Do people worry about optimizing away creating new processes? Perhaps. > Could m3cg be built as an .so/.dll? Probably. Tricky given gcc's nature. But, m3middle could be glued to gcc to build gcc's trees directly...though I strongly prefer the current arrangement. > And ok license-wise? Um, no. FSF have been generally opposed to the way the Modula-3 backend is a thin front-end veneer over gcc, since we get to use their compiler without infecting M3 with the GPL/LGPL. Of course, it would probably be preferable to have CM3 under the GPL/LGPL > Could m3cg be run once per package instead of once per source? Possibly, though right now m3cg does not use the gcc front-end driver. To be honest, I prefer the separation of concerns between m3middle and the gcc-based backend. It is much easier for debugging and development. > gcc and cl both can be: > cl -c foo.c bar.c > gcc -c foo.c bar.c > Currently in NT386GNU I depend on -o, > gcc -c foo.c -o foo.obj > Would need to handle that, not a big deal. > > Also, in the scheme below, either cm3.sh/cm3.cmd would have a > switch to merely print the "real" cm3's path, or, just as well, > sysinfo.sh et. al. would know how to find it, save that process. > > Furthermore -- multithreaded build? > > I believe, maybe absent bootstrapping, that cm3 could read "all" > the m3makefiles, work out the dependency graph trivially, and build > things in parallel. Bootstrappinging works too. It builds only what > you say, in the right order. The Python scripts can implement this > easily enough. I would strongly prefer to see functionality remain decomposed as it currently is. Tangled balls of string are tough to understand, maintain, and develop. > > - Jay > > ---------------------------------------- >> CC: m3devel at elegosoft.com >> From: hosking at cs.purdue.edu >> Subject: Re: [M3devel] "crazy cross" >> Date: Tue, 15 Jan 2008 08:47:13 -0500 >> To: jayk123 at hotmail.com >> >> >> On Jan 15, 2008, at 2:00 AM, Jay wrote: >> >>> It looks like at least cm3 is "always" target-independent. >>> Whatever target is defined to in cm3.cfg, if it is one of the built >>> in known ones, cm3 will generate code for. Except maybe NT386, >>> though it need not be -- cm3 could have both the .obj and "gcc >>> tree" writing backends both linked into it and dynamically chose >>> between them. >> >> Yes, the cm3 front-end will generate .mo/.io files for any target on >> any other host. The gcc-based backend runs as a separate process >> (there are license issues with linking the gcc-based backend directly >> with the front-end). >> >>> Maybe it already does. >>> cm3 operates at a fairly high level when using gcc, and the target >>> specific stuff is just some data about the name of setjmp, the >>> sizeof jmp_buf, etc.. >>> >>> The "only" "problem" is then m3cg/as/ld/link. >>> m3cg could be moved to $CM3_INSTALL/pkg/x/HOST/TARGET. >> >> True! >> >>> cm3, along with everything else, could be $CM3_INSTALL/pkg/x/HOST >>> leaving $CM3_INSTALL/bin/cm3 that is sh and $CM3_INSTALL/bin/cm3.py >>> or cm3.cmd that calls out to cm3. >> >> Possibly. >> >>> "Fixing" as/ld, well, I don't suppose they tend to be target >>> neutral do they? You'd have to import them like gcc and build them >>> n times. Gaining a much slower build, much larger tree. >> >> Indeed. >> >>> I suppose anyone could do this themselves, and change cm3.cfg >>> appropriately. Doing things "officially" this way for one "big" >>> distribution, probably folks would not go for. >> >> This is how bootstraps to other targets typically go: cm3 *.m3- >>> *.mo. Copy .mo files to target. Build cm3cg for target. cm3cg >> *.mo->*.ms as *.ms->*.o ld *.o->libs/execs. >> >> >>> >>> >>> - Jay >>> >>> >>> >>> From: jayk123 at hotmail.com >>> To: m3devel at elegosoft.com >>> Subject: "crazy cross" >>> Date: Sat, 5 Jan 2008 01:22:13 +0000 >>> >>> You've all heard of "Canadian cross"? >>> >>> It is cross-building a cross-compiler. >>> I'm sitting in Windows. I'm going to build a compiler that is going >>> to run on Linux that is going to target Solaris. >>> For one example. >>> >>> You've all seen that Apple has switches like so: >>> >>> gcc -arch i386 ppc ppc64 x86_64 hello.c >>> and poof out comes a binary that runs natively on four architectures >>> >>> I don't like the "inconvenience" of non cross systems and having to >>> have all the machines/OSes just to build the binaries. >>> I realize that you hit the wall if you actually want to test the >>> results. So cross building only gets so much. >>> Of course I also don't want to multiply out build times for tools... >>> >>> Ok, well what is the possibility of: >>> >>> cm3 -target NT386 >>> cm3 -target NT386 -target PPC_DARWIN >>> >>> ? In my crazy imagination, you have: >>> >>> \cm3\bin\cm3.cmd >>> %~dp0..\libexec\%processor_architecture%\%TARGET%\cm3.exe %* >>> >>> \cm3\bin\cm3 >>> #!/bin/sh >>> dirname(dirname($0))/libexec/`uname whatever`/$TARGET/cm3 $@ >>> >>> Thus it becomes POSSIBLE to have an n x m matrix, host x target, >>> and be able to build >>> "anything" from one environment. >>> >>> Actually the targets could all be merged into one .exe or >>> be .dll/.sos. >>> Except the code isn't setup for that. >>> >>> Interesting? >>> >>> I guess the hard part is the C code and linking? >>> The Modula-3 stuff is already setup to do most of this? >>> (partly by virtue of all that header rewriting that I labeled >>> sleazy) >>> >>> - Jay >>> >>> >>> >>> Share life as it happens with the new Windows Live. Start sharing! >>> >>> Share life as it happens with the new Windows Live. Start sharing! >> > > _________________________________________________________________ > Watch ?Cause Effect,? a show about real people making a real > difference. > http://im.live.com/Messenger/IM/MTV/?source=text_watchcause From jayk123 at hotmail.com Wed Jan 16 04:57:13 2008 From: jayk123 at hotmail.com (Jay) Date: Wed, 16 Jan 2008 03:57:13 +0000 Subject: [M3devel] NT386GNU status In-Reply-To: <6D01FCB8-D43D-4927-BA3C-23C566E818E6@cs.purdue.edu> References: <6D01FCB8-D43D-4927-BA3C-23C566E818E6@cs.purdue.edu> Message-ID: I believe you are perfectly capable of finding this, but fyi: http://msdn2.microsoft.com/en-us/library/ms633558.aspx HWND WindowFromPoint(POINT Point); http://msdn2.microsoft.com/en-us/library/ms536119(VS.85).aspx typedef struct tagPOINT { LONG x; LONG y; } POINT, *PPOINT; http://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/m3core/src/win32/WinUser.i3?rev=1.2;content-type=text%2Fplain <*EXTERNAL WindowFromPoint:WINAPI*>PROCEDURE WindowFromPoint (Point: POINT): HWND; http://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/m3core/src/win32/WinDef.i3 POINT = RECORD x: LONG; y: LONG; END; so 8 byte structs are passed by value.Other small sizes might be an issue as well. Oh.. //#pragma pack(1) made no difference #define X(n) typedef struct { char a[n]; } A ## n; void __stdcall F ## n( A##n a) { } X(1) X(2) X(3) X(4) X(5) X(6) X(7) X(8)X(9) X(10) X(11) X(12) X(13) X(14) X(15)X(16) X(17) X(18) X(19) X(20) X(30) X(90)X(900) X(901) X(902) Y:\>link /dump /symbols t.obj Dump of file t.obj COFF SYMBOL TABLE008 00000000 SECT3 notype () External | _F1 at 4009 00000010 SECT3 notype () External | _F2 at 400A 00000020 SECT3 notype () External | _F3 at 400B 00000030 SECT3 notype () External | _F4 at 400C 00000040 SECT3 notype () External | _F5 at 800D 00000050 SECT3 notype () External | _F6 at 800E 00000060 SECT3 notype () External | _F7 at 800F 00000070 SECT3 notype () External | _F8 at 8010 00000080 SECT3 notype () External | _F9 at 12011 00000090 SECT3 notype () External | _F10 at 12012 000000A0 SECT3 notype () External | _F11 at 12013 000000B0 SECT3 notype () External | _F12 at 12014 000000C0 SECT3 notype () External | _F13 at 16015 000000D0 SECT3 notype () External | _F14 at 16016 000000E0 SECT3 notype () External | _F15 at 16017 000000F0 SECT3 notype () External | _F16 at 16018 00000100 SECT3 notype () External | _F17 at 20019 00000110 SECT3 notype () External | _F18 at 2001A 00000120 SECT3 notype () External | _F19 at 2001B 00000130 SECT3 notype () External | _F20 at 2001C 00000140 SECT3 notype () External | _F30 at 3201D 00000150 SECT3 notype () External | _F90 at 9201E 00000160 SECT3 notype () External | _F900 at 90001F 00000170 SECT3 notype () External | _F901 at 904020 00000180 SECT3 notype () External | _F902 at 904 so, really, pass by value is pass by value, no matter the size.Round struct sizes up to a multiple of 4 (or word size, but this naming stuff and multiple calling conventions is only x86). I thought beyond some small number they'd be passed by pointer and the callee would copy to its local stack..which /might/ still be the case, but it's not how the function naming works at least. I'll check what the code should and does look like. - Jay > From: hosking at cs.purdue.edu> > > Oh, m3ui and related are broken due to:> >> > -> linking formsedit.exe> > WinTrestle.m3:1843: undefined reference to `WindowFromPoint at 4'> >> > \mingw\bin\nm \MinGW\lib\libuser32.a | findstr WindowFromPoint> > 00000000 T _WindowFromPoint at 8> > 00000000 I __imp__WindowFromPoint at 8> >> > Maybe Tony will fix my __stdcall work. :)> > Yes, I know what needs doing to m3cc(cm3cg). Just need to do it. _________________________________________________________________ Make distant family not so distant with Windows Vista? + Windows Live?. http://www.microsoft.com/windows/digitallife/keepintouch.mspx?ocid=TXT_TAGLM_CPC_VideoChat_distantfamily_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcoleburn at scires.com Wed Jan 16 04:52:59 2008 From: rcoleburn at scires.com (Randy Coleburn) Date: Tue, 15 Jan 2008 22:52:59 -0500 Subject: [M3devel] my status on win32 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> <477EA137.1E75.00D7.1@scires.com> Message-ID: <478D394B.1E75.00D7.1@scires.com> Jay et al: I've listed below the steps I've undertaken to try and build the current sources on Windows XP. I've also attached a text file showing the output I got when trying to build everything using Jay's upgrade.cmd script. Unfortunately, I'm getting a build error (see below). Please advise on how to resolve. STEPS I TOOK: ========= 1. Download Microsoft Visual Studio 2008 Express Edition All-in-One .ISO file and burn to DVD. http://www.microsoft.com/express/download/ 2. Install Microsoft Visual C++ 2008 Express Edition from DVD. 3. Use "Microsoft Update" service to check for updates / service packs. 4. Download cygwin setup program from http://cygwin.com/ 5. Ran cygwin setup.exe program to install cygwin for all users. Under "Devel" category, make certain to select "cvs" for installation. 6. Launch cygwin from desktop icon. 7. In cygwin command shell window, execute following two commands, making sure to give email as password when prompted for login: cvs -d :pserver:anonymous at modula3.elegosoft.com:/usr/cvs login cvs -d :pserver:anonymous at modula3.elegosoft.com:/usr/cvs checkout cm3 8. Moved resulting C:\cygwin\home\rcoleburn\cm3 to C:\CM3_CVS_SourceTree Note that you should replace "rcoleburn" above with your Windows login username. 9. Download cm3-min-WIN32-NT386-d5.5.0.zip and cm3-min-WIN32-NT386-d5.5.0-symbols.zip from http://modula3.elegosoft.com/cm3/download.html 10. Unzipped cm3-min-WIN32-NT386-d5.5.0.zip and stored resulting cm3 folder at C:\cm3 11. Unzipped cm3-min-WIN32-NT386-d5.5.0-symbols.zip and stored resulting symbols folder at C:\cm3\symbols 12. Launch Windows Command Prompt shell. The following steps represent commands executed within this shell. 13. path %path%;c:\cm3\bin 14. "C:\Program Files\Microsoft Visual Studio 9.0\VC\vcvarsall.bat" 15. cd C:\CM3_CVS_SourceTree\scripts\win 16. upgrade.cmd ERROR I'M GETTING: ============= === package C:\CM3_CVS_SourceTree\m3-sys\cm3 === +++ "cm3 -build -DROOT=C:\\CM3_CVS_SourceTree -DCM3_VERSION_TEXT=d5.5.1 -DCM3_V ERSION_NUMBER=050501 -DCM3_LAST_CHANGED=2007-12-30 && cm3 -ship -DROOT=C:\\CM3_C VS_SourceTree -DCM3_VERSION_TEXT=d5.5.1 -DCM3_VERSION_NUMBER=050501 -DCM3_LAST_C HANGED=2007-12-30" +++ --- building in NT386 --- ignoring ..\src\m3overrides "C:\CM3_CVS_SourceTree\m3-sys\cm3\src\version.quake", line 136: quake runtime er ror: unable to open "C:\CM3_CVS_SourceTree\m3-sys\cm3\src\../NT386.datenow" for reading --procedure-- -line- -file--- include -- version_impl 136 C:\CM3_CVS_SourceTree\m3-sys\cm3\src\version.quake include_dir 20 C:\CM3_CVS_SourceTree\m3-sys\cm3\src\m3makefile 8 C:\CM3_CVS_SourceTree\m3-sys\cm3\NT386\m3make.args Fatal Error: package build failed ERROR: "cm3 -build -DROOT=C:\\CM3_CVS_SourceTree -DCM3_VERSION_TEXT=d5.5.1 -DCM 3_VERSION_NUMBER=050501 -DCM3_LAST_CHANGED=2007-12-30 && cm3 -ship -DROOT=C:\\CM 3_CVS_SourceTree -DCM3_VERSION_TEXT=d5.5.1 -DCM3_VERSION_NUMBER=050501 -DCM3_LAS T_CHANGED=2007-12-30" ERROR: cd C:\CM3_CVS_SourceTree\m3-sys\cm3 ERROR: set INSTALLROOT=c:\cm3 Regards, Randy -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: cm3setup.txt URL: From jayk123 at hotmail.com Wed Jan 16 05:03:24 2008 From: jayk123 at hotmail.com (Jay) Date: Wed, 16 Jan 2008 04:03:24 +0000 Subject: [M3devel] my status on win32 In-Reply-To: <478D394B.1E75.00D7.1@scires.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> <477EA137.1E75.00D7.1@scires.com> <478D394B.1E75.00D7.1@scires.com> Message-ID: That's not too bad really. 1) I'd recommend putting cm3 at the start of the path instead of the end. 2) Just comment out the offending code to make progress. It's not critical. >> C:\CM3_CVS_SourceTree\m3-sys\cm3\src\../NT386.datenow The code is: C:\CM3_CVS_SourceTree\m3-sys\cm3\src\version.quake or such, included by cm3\src\m3makefile. Does the file exist? Does version.quake use "/" or "SL"? If it uses "/", try replacing with SL (and ampersand for string concat). Could be that a newer binary distributions works better with forward slashes. > 4. > 5. > 6. Launch cygwin from desktop icon. Cygwin is only needed for cvs, I think you realize. Could you send me offline the result of just running "set" after running vcvarsall? I'd like to adapt pylib.py to it maybe. (I can start from 5.1.6 and will try 4.1 at some point.) - Jay Date: Tue, 15 Jan 2008 22:52:59 -0500From: rcoleburn at scires.comTo: m3devel at elegosoft.com; jayk123 at hotmail.comSubject: my status on win32 Jay et al: I've listed below the steps I've undertaken to try and build the current sources on Windows XP. I've also attached a text file showing the output I got when trying to build everything using Jay's upgrade.cmd script. Unfortunately, I'm getting a build error (see below). Please advise on how to resolve. STEPS I TOOK: ========= 1. Download Microsoft Visual Studio 2008 Express Edition All-in-One .ISO file and burn to DVD. http://www.microsoft.com/express/download/ 2. Install Microsoft Visual C++ 2008 Express Edition from DVD. 3. Use "Microsoft Update" service to check for updates / service packs. 4. Download cygwin setup program from http://cygwin.com/ 5. Ran cygwin setup.exe program to install cygwin for all users. Under "Devel" category, make certain to select "cvs" for installation. 6. Launch cygwin from desktop icon. 7. In cygwin command shell window, execute following two commands, making sure to give email as password when prompted for login: cvs -d :pserver:anonymous at modula3.elegosoft.com:/usr/cvs login cvs -d :pserver:anonymous at modula3.elegosoft.com:/usr/cvs checkout cm3 8. Moved resulting C:\cygwin\home\rcoleburn\cm3 to C:\CM3_CVS_SourceTree Note that you should replace "rcoleburn" above with your Windows login username. 9. Download cm3-min-WIN32-NT386-d5.5.0.zip and cm3-min-WIN32-NT386-d5.5.0-symbols.zip from http://modula3.elegosoft.com/cm3/download.html 10. Unzipped cm3-min-WIN32-NT386-d5.5.0.zip and stored resulting cm3 folder at C:\cm3 11. Unzipped cm3-min-WIN32-NT386-d5.5.0-symbols.zip and stored resulting symbols folder at C:\cm3\symbols 12. Launch Windows Command Prompt shell. The following steps represent commands executed within this shell. 13. path %path%;c:\cm3\bin 14. "C:\Program Files\Microsoft Visual Studio 9.0\VC\vcvarsall.bat" 15. cd C:\CM3_CVS_SourceTree\scripts\win 16. upgrade.cmd ERROR I'M GETTING: ============= === package C:\CM3_CVS_SourceTree\m3-sys\cm3 ===+++ "cm3 -build -DROOT=C:\\CM3_CVS_SourceTree -DCM3_VERSION_TEXT=d5.5.1 -DCM3_VERSION_NUMBER=050501 -DCM3_LAST_CHANGED=2007-12-30 && cm3 -ship -DROOT=C:\\CM3_CVS_SourceTree -DCM3_VERSION_TEXT=d5.5.1 -DCM3_VERSION_NUMBER=050501 -DCM3_LAST_CHANGED=2007-12-30" +++--- building in NT386 --- ignoring ..\src\m3overrides "C:\CM3_CVS_SourceTree\m3-sys\cm3\src\version.quake", line 136: quake runtime error: unable to open "C:\CM3_CVS_SourceTree\m3-sys\cm3\src\../NT386.datenow" forreading --procedure-- -line- -file---include -- version_impl 136 C:\CM3_CVS_SourceTree\m3-sys\cm3\src\version.quakeinclude_dir 20 C:\CM3_CVS_SourceTree\m3-sys\cm3\src\m3makefile 8 C:\CM3_CVS_SourceTree\m3-sys\cm3\NT386\m3make.args Fatal Error: package build failedERROR: "cm3 -build -DROOT=C:\\CM3_CVS_SourceTree -DCM3_VERSION_TEXT=d5.5.1 -DCM3_VERSION_NUMBER=050501 -DCM3_LAST_CHANGED=2007-12-30 && cm3 -ship -DROOT=C:\\CM3_CVS_SourceTree -DCM3_VERSION_TEXT=d5.5.1 -DCM3_VERSION_NUMBER=050501 -DCM3_LAST_CHANGED=2007-12-30"ERROR: cd C:\CM3_CVS_SourceTree\m3-sys\cm3ERROR: set INSTALLROOT=c:\cm3 Regards, Randy _________________________________________________________________ Share life as it happens with the new Windows Live. http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcoleburn at scires.com Wed Jan 16 05:30:01 2008 From: rcoleburn at scires.com (Randy Coleburn) Date: Tue, 15 Jan 2008 23:30:01 -0500 Subject: [M3devel] my status on win32 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> <477EA137.1E75.00D7.1@scires.com> <478D394B.1E75.00D7.1@scires.com> Message-ID: <478D41F9.1E75.00D7.1@scires.com> Jay: The file version.quake does exist in m3-sys\cm3\src I'm not much of a quake programmer, so not sure exactly how to alter this file. I did a search for "SL" but did not find it. Regards, Randy >>> Jay 1/15/2008 11:03 PM >>> That's not too bad really. 1) I'd recommend putting cm3 at the start of the path instead of the end. 2) Just comment out the offending code to make progress. It's not critical. >> C:\CM3_CVS_SourceTree\m3-sys\cm3\src\../NT386.datenow The code is: C:\CM3_CVS_SourceTree\m3-sys\cm3\src\version.quake or such, included by cm3\src\m3makefile. Does the file exist? Does version.quake use "/" or "SL"? If it uses "/", try replacing with SL (and ampersand for string concat). Could be that a newer binary distributions works better with forward slashes. > 4. > 5. > 6. Launch cygwin from desktop icon. Cygwin is only needed for cvs, I think you realize. Could you send me offline the result of just running "set" after running vcvarsall? I'd like to adapt pylib.py to it maybe. (I can start from 5.1.6 and will try 4.1 at some point.) - Jay Date: Tue, 15 Jan 2008 22:52:59 -0500 From: rcoleburn at scires.com To: m3devel at elegosoft.com; jayk123 at hotmail.com Subject: my status on win32 Jay et al: I've listed below the steps I've undertaken to try and build the current sources on Windows XP. I've also attached a text file showing the output I got when trying to build everything using Jay's upgrade.cmd script. Unfortunately, I'm getting a build error (see below). Please advise on how to resolve. STEPS I TOOK: ========= 1. Download Microsoft Visual Studio 2008 Express Edition All-in-One .ISO file and burn to DVD. http://www.microsoft.com/express/download/ 2. Install Microsoft Visual C++ 2008 Express Edition from DVD. 3. Use "Microsoft Update" service to check for updates / service packs. 4. Download cygwin setup program from http://cygwin.com/ 5. Ran cygwin setup.exe program to install cygwin for all users. Under "Devel" category, make certain to select "cvs" for installation. 6. Launch cygwin from desktop icon. 7. In cygwin command shell window, execute following two commands, making sure to give email as password when prompted for login: cvs -d :pserver:anonymous at modula3.elegosoft.com:/usr/cvs login cvs -d :pserver:anonymous at modula3.elegosoft.com:/usr/cvs checkout cm3 8. Moved resulting C:\cygwin\home\rcoleburn\cm3 to C:\CM3_CVS_SourceTree Note that you should replace "rcoleburn" above with your Windows login username. 9. Download cm3-min-WIN32-NT386-d5.5.0.zip and cm3-min-WIN32-NT386-d5.5.0-symbols.zip from http://modula3.elegosoft.com/cm3/download.html 10. Unzipped cm3-min-WIN32-NT386-d5.5.0.zip and stored resulting cm3 folder at C:\cm3 11. Unzipped cm3-min-WIN32-NT386-d5.5.0-symbols.zip and stored resulting symbols folder at C:\cm3\symbols 12. Launch Windows Command Prompt shell. The following steps represent commands executed within this shell. 13. path %path%;c:\cm3\bin 14. "C:\Program Files\Microsoft Visual Studio 9.0\VC\vcvarsall.bat" 15. cd C:\CM3_CVS_SourceTree\scripts\win 16. upgrade.cmd ERROR I'M GETTING: ============= === package C:\CM3_CVS_SourceTree\m3-sys\cm3 === +++ "cm3 -build -DROOT=C:\\CM3_CVS_SourceTree -DCM3_VERSION_TEXT=d5.5.1 -DCM3_V ERSION_NUMBER=050501 -DCM3_LAST_CHANGED=2007-12-30 && cm3 -ship -DROOT=C:\\CM3_C VS_SourceTree -DCM3_VERSION_TEXT=d5.5.1 -DCM3_VERSION_NUMBER=050501 -DCM3_LAST_C HANGED=2007-12-30" +++ --- building in NT386 --- ignoring ..\src\m3overrides "C:\CM3_CVS_SourceTree\m3-sys\cm3\src\version.quake", line 136: quake runtime er ror: unable to open "C:\CM3_CVS_SourceTree\m3-sys\cm3\src\../NT386.datenow" for reading --procedure-- -line- -file--- include -- version_impl 136 C:\CM3_CVS_SourceTree\m3-sys\cm3\src\version.quake include_dir 20 C:\CM3_CVS_SourceTree\m3-sys\cm3\src\m3makefile 8 C:\CM3_CVS_SourceTree\m3-sys\cm3\NT386\m3make.args Fatal Error: package build failed ERROR: "cm3 -build -DROOT=C:\\CM3_CVS_SourceTree -DCM3_VERSION_TEXT=d5.5.1 -DCM 3_VERSION_NUMBER=050501 -DCM3_LAST_CHANGED=2007-12-30 && cm3 -ship -DROOT=C:\\CM 3_CVS_SourceTree -DCM3_VERSION_TEXT=d5.5.1 -DCM3_VERSION_NUMBER=050501 -DCM3_LAS T_CHANGED=2007-12-30" ERROR: cd C:\CM3_CVS_SourceTree\m3-sys\cm3 ERROR: set INSTALLROOT=c:\cm3 Regards, Randy Share life as it happens with the new Windows Live. Start sharing! ( 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 Wed Jan 16 05:55:39 2008 From: rcoleburn at scires.com (Randy Coleburn) Date: Tue, 15 Jan 2008 23:55:39 -0500 Subject: [M3devel] my status on win32 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> <477EA137.1E75.00D7.1@scires.com> <478D394B.1E75.00D7.1@scires.com> Message-ID: <478D47FB.1E75.00D7.1@scires.com> Jay: In the file version.quake, I made the following edit: changed line: local datefn = "../" & TARGET & ".datenow" to: local datefn = ".." & SL & TARGET & ".datenow" This change has the effect of putting a backward slash in the pathname instead of a forward slash, so we get C:\CM3_CVS_SourceTree\m3-sys\cm3\src\..\NT386.datenow So from that perspective, the change seems good. Unfortunately, I still get the error that this file can't be opened. A quick check of C:\CM3_CVS_SourceTree\m3-sys\cm3\NT386 shows that the file .datenow does not exist. Regards, Randy >>> Jay 1/15/2008 11:03 PM >>> That's not too bad really. 1) I'd recommend putting cm3 at the start of the path instead of the end. 2) Just comment out the offending code to make progress. It's not critical. >> C:\CM3_CVS_SourceTree\m3-sys\cm3\src\../NT386.datenow The code is: C:\CM3_CVS_SourceTree\m3-sys\cm3\src\version.quake or such, included by cm3\src\m3makefile. Does the file exist? Does version.quake use "/" or "SL"? If it uses "/", try replacing with SL (and ampersand for string concat). Could be that a newer binary distributions works better with forward slashes. > 4. > 5. > 6. Launch cygwin from desktop icon. Cygwin is only needed for cvs, I think you realize. Could you send me offline the result of just running "set" after running vcvarsall? I'd like to adapt pylib.py to it maybe. (I can start from 5.1.6 and will try 4.1 at some point.) - Jay Date: Tue, 15 Jan 2008 22:52:59 -0500 From: rcoleburn at scires.com To: m3devel at elegosoft.com; jayk123 at hotmail.com Subject: my status on win32 Jay et al: I've listed below the steps I've undertaken to try and build the current sources on Windows XP. I've also attached a text file showing the output I got when trying to build everything using Jay's upgrade.cmd script. Unfortunately, I'm getting a build error (see below). Please advise on how to resolve. STEPS I TOOK: ========= 1. Download Microsoft Visual Studio 2008 Express Edition All-in-One .ISO file and burn to DVD. http://www.microsoft.com/express/download/ 2. Install Microsoft Visual C++ 2008 Express Edition from DVD. 3. Use "Microsoft Update" service to check for updates / service packs. 4. Download cygwin setup program from http://cygwin.com/ 5. Ran cygwin setup.exe program to install cygwin for all users. Under "Devel" category, make certain to select "cvs" for installation. 6. Launch cygwin from desktop icon. 7. In cygwin command shell window, execute following two commands, making sure to give email as password when prompted for login: cvs -d :pserver:anonymous at modula3.elegosoft.com:/usr/cvs login cvs -d :pserver:anonymous at modula3.elegosoft.com:/usr/cvs checkout cm3 8. Moved resulting C:\cygwin\home\rcoleburn\cm3 to C:\CM3_CVS_SourceTree Note that you should replace "rcoleburn" above with your Windows login username. 9. Download cm3-min-WIN32-NT386-d5.5.0.zip and cm3-min-WIN32-NT386-d5.5.0-symbols.zip from http://modula3.elegosoft.com/cm3/download.html 10. Unzipped cm3-min-WIN32-NT386-d5.5.0.zip and stored resulting cm3 folder at C:\cm3 11. Unzipped cm3-min-WIN32-NT386-d5.5.0-symbols.zip and stored resulting symbols folder at C:\cm3\symbols 12. Launch Windows Command Prompt shell. The following steps represent commands executed within this shell. 13. path %path%;c:\cm3\bin 14. "C:\Program Files\Microsoft Visual Studio 9.0\VC\vcvarsall.bat" 15. cd C:\CM3_CVS_SourceTree\scripts\win 16. upgrade.cmd ERROR I'M GETTING: ============= === package C:\CM3_CVS_SourceTree\m3-sys\cm3 === +++ "cm3 -build -DROOT=C:\\CM3_CVS_SourceTree -DCM3_VERSION_TEXT=d5.5.1 -DCM3_V ERSION_NUMBER=050501 -DCM3_LAST_CHANGED=2007-12-30 && cm3 -ship -DROOT=C:\\CM3_C VS_SourceTree -DCM3_VERSION_TEXT=d5.5.1 -DCM3_VERSION_NUMBER=050501 -DCM3_LAST_C HANGED=2007-12-30" +++ --- building in NT386 --- ignoring ..\src\m3overrides "C:\CM3_CVS_SourceTree\m3-sys\cm3\src\version.quake", line 136: quake runtime er ror: unable to open "C:\CM3_CVS_SourceTree\m3-sys\cm3\src\../NT386.datenow" for reading --procedure-- -line- -file--- include -- version_impl 136 C:\CM3_CVS_SourceTree\m3-sys\cm3\src\version.quake include_dir 20 C:\CM3_CVS_SourceTree\m3-sys\cm3\src\m3makefile 8 C:\CM3_CVS_SourceTree\m3-sys\cm3\NT386\m3make.args Fatal Error: package build failed ERROR: "cm3 -build -DROOT=C:\\CM3_CVS_SourceTree -DCM3_VERSION_TEXT=d5.5.1 -DCM 3_VERSION_NUMBER=050501 -DCM3_LAST_CHANGED=2007-12-30 && cm3 -ship -DROOT=C:\\CM 3_CVS_SourceTree -DCM3_VERSION_TEXT=d5.5.1 -DCM3_VERSION_NUMBER=050501 -DCM3_LAS T_CHANGED=2007-12-30" ERROR: cd C:\CM3_CVS_SourceTree\m3-sys\cm3 ERROR: set INSTALLROOT=c:\cm3 Regards, Randy Share life as it happens with the new Windows Live. Start sharing! ( 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 Jan 16 07:01:42 2008 From: jayk123 at hotmail.com (Jay) Date: Wed, 16 Jan 2008 06:01:42 +0000 Subject: [M3devel] my status on win32 In-Reply-To: <478D47FB.1E75.00D7.1@scires.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> <477EA137.1E75.00D7.1@scires.com> <478D394B.1E75.00D7.1@scires.com> <478D47FB.1E75.00D7.1@scires.com> Message-ID: I think I see the problem. in cm3\src\m3makefile, make this change > if not defined("NOW") include(datefn) > end datefn is only created if certain other variables aren't defined, and do-pkg defines them. I don't know why I don't see this. Later. Could be that the Python scripts have a typo and don't define them.I've been using them more than cmd. If the host is NT, "NOW" is either gotten from an updated cm3.exe, or left to "not available". So the initial cm3 built from older cm3 can't report when it was built, but cm3 built from current cm3 can. I need to change that: 1) to be a function for niceness 2) to make it that way for Posix, for any host but I haven't been using Posix as much lately so not testing it. - Jay Date: Tue, 15 Jan 2008 23:55:39 -0500From: rcoleburn at scires.comTo: m3devel at elegosoft.com; jayk123 at hotmail.comSubject: RE: my status on win32 Jay: In the file version.quake, I made the following edit: changed line: local datefn = "../" & TARGET & ".datenow" to: local datefn = ".." & SL & TARGET & ".datenow" This change has the effect of putting a backward slash in the pathname instead of a forward slash, so we getC:\CM3_CVS_SourceTree\m3-sys\cm3\src\..\NT386.datenow So from that perspective, the change seems good. Unfortunately, I still get the error that this file can't be opened. A quick check of C:\CM3_CVS_SourceTree\m3-sys\cm3\NT386 shows that the file .datenow does not exist. Regards, Randy>>> Jay 1/15/2008 11:03 PM >>>That's not too bad really. 1) I'd recommend putting cm3 at the start of the path instead of the end. 2) Just comment out the offending code to make progress. It's not critical. >> C:\CM3_CVS_SourceTree\m3-sys\cm3\src\../NT386.datenow The code is: C:\CM3_CVS_SourceTree\m3-sys\cm3\src\version.quake or such, included by cm3\src\m3makefile. Does the file exist?Does version.quake use "/" or "SL"? If it uses "/", try replacing with SL (and ampersand for string concat). Could be that a newer binary distributions works better with forward slashes. > 4. > 5. > 6. Launch cygwin from desktop icon. Cygwin is only needed for cvs, I think you realize. Could you send me offline the result of just running "set" after running vcvarsall? I'd like to adapt pylib.py to it maybe. (I can start from 5.1.6 and will try 4.1 at some point.) - Jay Date: Tue, 15 Jan 2008 22:52:59 -0500From: rcoleburn at scires.comTo: m3devel at elegosoft.com; jayk123 at hotmail.comSubject: my status on win32 Jay et al: I've listed below the steps I've undertaken to try and build the current sources on Windows XP. I've also attached a text file showing the output I got when trying to build everything using Jay's upgrade.cmd script. Unfortunately, I'm getting a build error (see below). Please advise on how to resolve. STEPS I TOOK: ========= 1. Download Microsoft Visual Studio 2008 Express Edition All-in-One .ISO file and burn to DVD. http://www.microsoft.com/express/download/ 2. Install Microsoft Visual C++ 2008 Express Edition from DVD. 3. Use "Microsoft Update" service to check for updates / service packs. 4. Download cygwin setup program from http://cygwin.com/ 5. Ran cygwin setup.exe program to install cygwin for all users. Under "Devel" category, make certain to select "cvs" for installation. 6. Launch cygwin from desktop icon. 7. In cygwin command shell window, execute following two commands, making sure to give email as password when prompted for login: cvs -d :pserver:anonymous at modula3.elegosoft.com:/usr/cvs login cvs -d :pserver:anonymous at modula3.elegosoft.com:/usr/cvs checkout cm3 8. Moved resulting C:\cygwin\home\rcoleburn\cm3 to C:\CM3_CVS_SourceTree Note that you should replace "rcoleburn" above with your Windows login username. 9. Download cm3-min-WIN32-NT386-d5.5.0.zip and cm3-min-WIN32-NT386-d5.5.0-symbols.zip from http://modula3.elegosoft.com/cm3/download.html 10. Unzipped cm3-min-WIN32-NT386-d5.5.0.zip and stored resulting cm3 folder at C:\cm3 11. Unzipped cm3-min-WIN32-NT386-d5.5.0-symbols.zip and stored resulting symbols folder at C:\cm3\symbols 12. Launch Windows Command Prompt shell. The following steps represent commands executed within this shell. 13. path %path%;c:\cm3\bin 14. "C:\Program Files\Microsoft Visual Studio 9.0\VC\vcvarsall.bat" 15. cd C:\CM3_CVS_SourceTree\scripts\win 16. upgrade.cmd ERROR I'M GETTING: ============= === package C:\CM3_CVS_SourceTree\m3-sys\cm3 ===+++ "cm3 -build -DROOT=C:\\CM3_CVS_SourceTree -DCM3_VERSION_TEXT=d5.5.1 -DCM3_VERSION_NUMBER=050501 -DCM3_LAST_CHANGED=2007-12-30 && cm3 -ship -DROOT=C:\\CM3_CVS_SourceTree -DCM3_VERSION_TEXT=d5.5.1 -DCM3_VERSION_NUMBER=050501 -DCM3_LAST_CHANGED=2007-12-30" +++--- building in NT386 --- ignoring ..\src\m3overrides "C:\CM3_CVS_SourceTree\m3-sys\cm3\src\version.quake", line 136: quake runtime error: unable to open "C:\CM3_CVS_SourceTree\m3-sys\cm3\src\../NT386.datenow" forreading --procedure-- -line- -file---include -- version_impl 136 C:\CM3_CVS_SourceTree\m3-sys\cm3\src\version.quakeinclude_dir 20 C:\CM3_CVS_SourceTree\m3-sys\cm3\src\m3makefile 8 C:\CM3_CVS_SourceTree\m3-sys\cm3\NT386\m3make.args Fatal Error: package build failedERROR: "cm3 -build -DROOT=C:\\CM3_CVS_SourceTree -DCM3_VERSION_TEXT=d5.5.1 -DCM3_VERSION_NUMBER=050501 -DCM3_LAST_CHANGED=2007-12-30 && cm3 -ship -DROOT=C:\\CM3_CVS_SourceTree -DCM3_VERSION_TEXT=d5.5.1 -DCM3_VERSION_NUMBER=050501 -DCM3_LAST_CHANGED=2007-12-30"ERROR: cd C:\CM3_CVS_SourceTree\m3-sys\cm3ERROR: set INSTALLROOT=c:\cm3 Regards, Randy Share life as it happens with the new Windows Live. Start sharing! _________________________________________________________________ Put your friends on the big screen with Windows Vista? + Windows Live?. http://www.microsoft.com/windows/shop/specialoffers.mspx?ocid=TXT_TAGLM_CPC_MediaCtr_bigscreen_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Wed Jan 16 07:04:48 2008 From: jayk123 at hotmail.com (Jay) Date: Wed, 16 Jan 2008 06:04:48 +0000 Subject: [M3devel] my status on win32 In-Reply-To: <478D47FB.1E75.00D7.1@scires.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> <477EA137.1E75.00D7.1@scires.com> <478D394B.1E75.00D7.1@scires.com> <478D47FB.1E75.00D7.1@scires.com> Message-ID: Note that the file is called "NT386.datenow" in the cm3 directory. I will be changing that too. Outputs don't belong outside of the target directory, unless there is some deliberate need to shield from the frequency of "clean" / "realclean", like if only some other "really really clean" event should cause them to be regenerated. I believe Olaf oked this privately but like I said, I want to change a bit more here, and need to test on Posix. Also there's another file with a dot in front of it, and I generally oppose all "hiding" of files -- Unix dot, or Windows attrib -h. - Jay Date: Tue, 15 Jan 2008 23:55:39 -0500From: rcoleburn at scires.comTo: m3devel at elegosoft.com; jayk123 at hotmail.comSubject: RE: my status on win32 Jay: In the file version.quake, I made the following edit: changed line: local datefn = "../" & TARGET & ".datenow" to: local datefn = ".." & SL & TARGET & ".datenow" This change has the effect of putting a backward slash in the pathname instead of a forward slash, so we getC:\CM3_CVS_SourceTree\m3-sys\cm3\src\..\NT386.datenow So from that perspective, the change seems good. Unfortunately, I still get the error that this file can't be opened. A quick check of C:\CM3_CVS_SourceTree\m3-sys\cm3\NT386 shows that the file .datenow does not exist. Regards, Randy>>> Jay 1/15/2008 11:03 PM >>>That's not too bad really. 1) I'd recommend putting cm3 at the start of the path instead of the end. 2) Just comment out the offending code to make progress. It's not critical. >> C:\CM3_CVS_SourceTree\m3-sys\cm3\src\../NT386.datenow The code is: C:\CM3_CVS_SourceTree\m3-sys\cm3\src\version.quake or such, included by cm3\src\m3makefile. Does the file exist?Does version.quake use "/" or "SL"? If it uses "/", try replacing with SL (and ampersand for string concat). Could be that a newer binary distributions works better with forward slashes. > 4. > 5. > 6. Launch cygwin from desktop icon. Cygwin is only needed for cvs, I think you realize. Could you send me offline the result of just running "set" after running vcvarsall? I'd like to adapt pylib.py to it maybe. (I can start from 5.1.6 and will try 4.1 at some point.) - Jay Date: Tue, 15 Jan 2008 22:52:59 -0500From: rcoleburn at scires.comTo: m3devel at elegosoft.com; jayk123 at hotmail.comSubject: my status on win32 Jay et al: I've listed below the steps I've undertaken to try and build the current sources on Windows XP. I've also attached a text file showing the output I got when trying to build everything using Jay's upgrade.cmd script. Unfortunately, I'm getting a build error (see below). Please advise on how to resolve. STEPS I TOOK: ========= 1. Download Microsoft Visual Studio 2008 Express Edition All-in-One .ISO file and burn to DVD. http://www.microsoft.com/express/download/ 2. Install Microsoft Visual C++ 2008 Express Edition from DVD. 3. Use "Microsoft Update" service to check for updates / service packs. 4. Download cygwin setup program from http://cygwin.com/ 5. Ran cygwin setup.exe program to install cygwin for all users. Under "Devel" category, make certain to select "cvs" for installation. 6. Launch cygwin from desktop icon. 7. In cygwin command shell window, execute following two commands, making sure to give email as password when prompted for login: cvs -d :pserver:anonymous at modula3.elegosoft.com:/usr/cvs login cvs -d :pserver:anonymous at modula3.elegosoft.com:/usr/cvs checkout cm3 8. Moved resulting C:\cygwin\home\rcoleburn\cm3 to C:\CM3_CVS_SourceTree Note that you should replace "rcoleburn" above with your Windows login username. 9. Download cm3-min-WIN32-NT386-d5.5.0.zip and cm3-min-WIN32-NT386-d5.5.0-symbols.zip from http://modula3.elegosoft.com/cm3/download.html 10. Unzipped cm3-min-WIN32-NT386-d5.5.0.zip and stored resulting cm3 folder at C:\cm3 11. Unzipped cm3-min-WIN32-NT386-d5.5.0-symbols.zip and stored resulting symbols folder at C:\cm3\symbols 12. Launch Windows Command Prompt shell. The following steps represent commands executed within this shell. 13. path %path%;c:\cm3\bin 14. "C:\Program Files\Microsoft Visual Studio 9.0\VC\vcvarsall.bat" 15. cd C:\CM3_CVS_SourceTree\scripts\win 16. upgrade.cmd ERROR I'M GETTING: ============= === package C:\CM3_CVS_SourceTree\m3-sys\cm3 ===+++ "cm3 -build -DROOT=C:\\CM3_CVS_SourceTree -DCM3_VERSION_TEXT=d5.5.1 -DCM3_VERSION_NUMBER=050501 -DCM3_LAST_CHANGED=2007-12-30 && cm3 -ship -DROOT=C:\\CM3_CVS_SourceTree -DCM3_VERSION_TEXT=d5.5.1 -DCM3_VERSION_NUMBER=050501 -DCM3_LAST_CHANGED=2007-12-30" +++--- building in NT386 --- ignoring ..\src\m3overrides "C:\CM3_CVS_SourceTree\m3-sys\cm3\src\version.quake", line 136: quake runtime error: unable to open "C:\CM3_CVS_SourceTree\m3-sys\cm3\src\../NT386.datenow" forreading --procedure-- -line- -file---include -- version_impl 136 C:\CM3_CVS_SourceTree\m3-sys\cm3\src\version.quakeinclude_dir 20 C:\CM3_CVS_SourceTree\m3-sys\cm3\src\m3makefile 8 C:\CM3_CVS_SourceTree\m3-sys\cm3\NT386\m3make.args Fatal Error: package build failedERROR: "cm3 -build -DROOT=C:\\CM3_CVS_SourceTree -DCM3_VERSION_TEXT=d5.5.1 -DCM3_VERSION_NUMBER=050501 -DCM3_LAST_CHANGED=2007-12-30 && cm3 -ship -DROOT=C:\\CM3_CVS_SourceTree -DCM3_VERSION_TEXT=d5.5.1 -DCM3_VERSION_NUMBER=050501 -DCM3_LAST_CHANGED=2007-12-30"ERROR: cd C:\CM3_CVS_SourceTree\m3-sys\cm3ERROR: set INSTALLROOT=c:\cm3 Regards, Randy Share life as it happens with the new Windows Live. Start sharing! _________________________________________________________________ Get the power of Windows + Web with the new Windows Live. http://www.windowslive.com?ocid=TXT_TAGHM_Wave2_powerofwindows_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.caltech.edu Wed Jan 16 09:45:47 2008 From: mika at async.caltech.edu (Mika Nystrom) Date: Wed, 16 Jan 2008 00:45:47 -0800 Subject: [M3devel] m3tests, pickles Message-ID: <200801160845.m0G8jlKE064314@camembert.async.caltech.edu> Can I add something tricky to a wish list on regression testing? Tricky because I don't know the best way to go about it. I have spent quite some time with various versions of Modula-3 tracking down issues with Pickles. Usually the problem is that Pickles aren't transferrable between systems, and it turns out that I have included some type, somewhere, that doesn't translate. MUTEX is a good example. First of all it would be very nice if such system dependencies were kept out (for instance, don't know if it's possible, but something like this...) TYPE RealMutex = OBJECT END; TYPE WinMutex = RealMutex OBJECT (* windows fields *) END; TYPE PosixMutex = RealMutex OBJECT (* POSIX fields *) END; TYPE MUTEX = RealMutex; and of course all that a client sees is MUTEX which is the same across systems. However I realize that what I say above may not be possible or practical in all cases. This brings me to the fact that Pickles are sensitive to certain types of bugs (I think), and it would be very nice to check that all OS/processor builds of M3 make compatible Pickles, with the possible exception of things like MUTEX. Of course this can't be done within a single build... Mika From wagner at elegosoft.com Wed Jan 16 10:11:31 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 16 Jan 2008 10:11:31 +0100 Subject: [M3devel] m3tests, pickles In-Reply-To: <200801160845.m0G8jlKE064314@camembert.async.caltech.edu> References: <200801160845.m0G8jlKE064314@camembert.async.caltech.edu> Message-ID: <20080116101131.reooi2rou8swg84k@mail.elegosoft.com> Quoting Mika Nystrom : > > Can I add something tricky to a wish list on regression testing? > Tricky because I don't know the best way to go about it. > > I have spent quite some time with various versions of Modula-3 > tracking down issues with Pickles. Usually the problem is that > Pickles aren't transferrable between systems, and it turns out that > I have included some type, somewhere, that doesn't translate. > MUTEX is a good example. First of all it would be very nice if > such system dependencies were kept out (for instance, don't know > if it's possible, but something like this...) > > TYPE RealMutex = OBJECT END; > > TYPE WinMutex = RealMutex OBJECT (* windows fields *) END; > TYPE PosixMutex = RealMutex OBJECT (* POSIX fields *) END; > > TYPE MUTEX = RealMutex; > > and of course all that a client sees is MUTEX which is the same > across systems. > > However I realize that what I say above may not be possible or > practical in all cases. > > This brings me to the fact that Pickles are sensitive to certain > types of bugs (I think), and it would be very nice to check that > all OS/processor builds of M3 make compatible Pickles, with the > possible exception of things like MUTEX. Of course this can't be > done within a single build... Sure this can and should be done. We just need reference data for all pickles and check them in for comparison somewhere below m3tests. Would you care to add such a test to the m3tests package? The Modula-3 part should could either just output pickles of various structures and leave the comparison to the existing quake code (simple solution) or run the comparison itself and return proper error messages and return codes (preferred solution). Or have I missed something important that makes this approach fail? Of course it will take some time until we've covered all target platforms with out tinderbox setup. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Jan 16 13:59:03 2008 From: rcoleburn at scires.com (Randy Coleburn) Date: Wed, 16 Jan 2008 07:59:03 -0500 Subject: [M3devel] m3tests, pickles In-Reply-To: <200801160845.m0G8jlKE064314@camembert.async.caltech.edu> References: <200801160845.m0G8jlKE064314@camembert.async.caltech.edu> Message-ID: <478DB947.1E75.00D7.1@scires.com> Mika: I've used pickles between various platforms in the past. I use the Pickle2 variant. In my code, I've registered special picklers to deal with mutexes. Since it doesn't make sense to transfer the state of a mutex between computers, I simply recreate/reinitialize the mutex on the receiving computer. Here is an example of an interface and a module that defines a type ServerConfig.T that I transfer between computers using Pickle2 and network objects. I've omitted some of the detail just to show the important stuff about the special pickling definitions and procedures: INTERFACE ServerConfig; CONST Brand = "ServerConfig"; (* prefix for all branded references *) TYPE T <: Public; Public = ConfigSettings.T OBJECT METHODS init (): T; (* initialize to default settings *) ... END; (* Public *) END ServerConfig. MODULE ServerConfig EXPORTS ServerConfig; IMPORT Pickle2 AS Pickle; TYPE PrivateMutex = MUTEX BRANDED Brand & ".PrivateMutex" OBJECT END; REVEAL T = Public BRANDED Brand & ".T" OBJECT mutex: PrivateMutex := NIL; ... METHODS OVERRIDES init := Init; ... END; (* T *) (*-------------------*) (* Pickle Procedures *) (*-------------------*) TYPE Special = Pickle.Special OBJECT OVERRIDES write := WriteSpecial; read := ReadSpecial; END; (* Special *) PROCEDURE WriteSpecial (self: Special; <*UNUSED*>ref: REFANY; <*UNUSED*>writer: Pickle.Writer ) RAISES {Pickle.Error, <*NOWARN*>Wr.Failure, Thread.Alerted} = (* Special pickle writer for ServerConfig.PrivateMutex objects. *) BEGIN (* WriteSpecial *) IF self.sc = TYPECODE(PrivateMutex) THEN (* omit writing the mutex field *) ELSE RAISE Pickle.Error("ServerConfig.WriteSpecial asked to process unrecognized typecode."); (* should never happen *) END; (* if *) END WriteSpecial; PROCEDURE ReadSpecial (self: Special; reader: Pickle.Reader; id: Pickle.RefID ): REFANY RAISES {Pickle.Error, <*NOWARN*>Rd.EndOfFile, Rd.Failure, Thread.Alerted} = (* Special pickle reader for ServerConfig.PrivateMutex objects. *) BEGIN (* ReadSpecial *) IF self.sc = TYPECODE(PrivateMutex) THEN WITH m = NEW(PrivateMutex) DO reader.noteRef(m, id); RETURN m; END; (* with *) ELSE RAISE Pickle.Error("ServerConfig.ReadSpecial asked to process unrecognized typecode."); (* should never happen *) END; (* if *) END ReadSpecial; BEGIN (* ServerConfig module initialization *) Pickle.RegisterSpecial(NEW(Special, sc := TYPECODE(PrivateMutex))); END ServerConfig. Regards, Randy >>> Mika Nystrom 1/16/2008 3:45 AM >>> Can I add something tricky to a wish list on regression testing? Tricky because I don't know the best way to go about it. I have spent quite some time with various versions of Modula-3 tracking down issues with Pickles. Usually the problem is that Pickles aren't transferrable between systems, and it turns out that I have included some type, somewhere, that doesn't translate. MUTEX is a good example. First of all it would be very nice if such system dependencies were kept out (for instance, don't know if it's possible, but something like this...) TYPE RealMutex = OBJECT END; TYPE WinMutex = RealMutex OBJECT (* windows fields *) END; TYPE PosixMutex = RealMutex OBJECT (* POSIX fields *) END; TYPE MUTEX = RealMutex; and of course all that a client sees is MUTEX which is the same across systems. However I realize that what I say above may not be possible or practical in all cases. This brings me to the fact that Pickles are sensitive to certain types of bugs (I think), and it would be very nice to check that all OS/processor builds of M3 make compatible Pickles, with the possible exception of things like MUTEX. Of course this can't be done within a single build... Mika -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcoleburn at scires.com Wed Jan 16 14:25:49 2008 From: rcoleburn at scires.com (Randy Coleburn) Date: Wed, 16 Jan 2008 08:25:49 -0500 Subject: [M3devel] my status on win32 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> <477EA137.1E75.00D7.1@scires.com> <478D394B.1E75.00D7.1@scires.com> <478D47FB.1E75.00D7.1@scires.com> Message-ID: <478DBF8D.1E75.00D7.1@scires.com> Jay: There is no line in the m3makefile dealing with datefn, so I added the whole statement just before the line include("version.quake") Now, I get an error saying that the variable datefn is not defined. If you change to put quotes around datefn in the include statement, you get an error saying it can't open the file. You made a reference in one of your earlier posts about trying 5.1.6 or 4.1, but note that I started with your cm3-min-WIN32-NT386-d5.5.0.zip , not the 5.1.6 or 4.1 versions. Thus, using d5.5.0 as a base, I am trying to run your "upgrade.cmd" to rebuild the sources I checked out from CVS. Since this doesn't work "out-of-the-box", again I say this fits into the "Broken #1" category. If I can get this to work, I don't mind putting together a Windows installer program that will install the whole thing. That way, folks won't have to install cygwin just to get CVS so that they can install a working cm3. Folks will need to install the free Microsoft Visual C as a prerequisite, but then that's not too bad. Having an installer program would make cm3 more friendly to Windows folks. The current 16-step method is too laborious and error-prone for the person just getting started and they will not give cm3 a second try. As the cm3 system evolves and new releases are made, we will need to keep the installer program up-to-date and I don't mind doing that. After someone gets familiar with cm3 they might want to delve into some of the scripts for rebuilding the system, but until then, I think the installer program is the way to go. Regards, Randy >>> Jay 1/16/2008 1:01 AM >>> I think I see the problem. in cm3\src\m3makefile, make this change > if not defined("NOW") include(datefn) > end datefn is only created if certain other variables aren't defined, and do-pkg defines them. I don't know why I don't see this. Later. Could be that the Python scripts have a typo and don't define them. I've been using them more than cmd. If the host is NT, "NOW" is either gotten from an updated cm3.exe, or left to "not available". So the initial cm3 built from older cm3 can't report when it was built, but cm3 built from current cm3 can. I need to change that: 1) to be a function for niceness 2) to make it that way for Posix, for any host but I haven't been using Posix as much lately so not testing it. - Jay Date: Tue, 15 Jan 2008 23:55:39 -0500 From: rcoleburn at scires.com To: m3devel at elegosoft.com; jayk123 at hotmail.com Subject: RE: my status on win32 Jay: In the file version.quake, I made the following edit: changed line: local datefn = "../" & TARGET & ".datenow" to: local datefn = ".." & SL & TARGET & ".datenow" This change has the effect of putting a backward slash in the pathname instead of a forward slash, so we get C:\CM3_CVS_SourceTree\m3-sys\cm3\src\..\NT386.datenow So from that perspective, the change seems good. Unfortunately, I still get the error that this file can't be opened. A quick check of C:\CM3_CVS_SourceTree\m3-sys\cm3\NT386 shows that the file .datenow does not exist. Regards, Randy >>> Jay 1/15/2008 11:03 PM >>> That's not too bad really. 1) I'd recommend putting cm3 at the start of the path instead of the end. 2) Just comment out the offending code to make progress. It's not critical. >> C:\CM3_CVS_SourceTree\m3-sys\cm3\src\../NT386.datenow The code is: C:\CM3_CVS_SourceTree\m3-sys\cm3\src\version.quake or such, included by cm3\src\m3makefile. Does the file exist? Does version.quake use "/" or "SL"? If it uses "/", try replacing with SL (and ampersand for string concat). Could be that a newer binary distributions works better with forward slashes. > 4. > 5. > 6. Launch cygwin from desktop icon. Cygwin is only needed for cvs, I think you realize. Could you send me offline the result of just running "set" after running vcvarsall? I'd like to adapt pylib.py to it maybe. (I can start from 5.1.6 and will try 4.1 at some point.) - Jay Date: Tue, 15 Jan 2008 22:52:59 -0500 From: rcoleburn at scires.com To: m3devel at elegosoft.com; jayk123 at hotmail.com Subject: my status on win32 Jay et al: I've listed below the steps I've undertaken to try and build the current sources on Windows XP. I've also attached a text file showing the output I got when trying to build everything using Jay's upgrade.cmd script. Unfortunately, I'm getting a build error (see below). Please advise on how to resolve. STEPS I TOOK: ========= 1. Download Microsoft Visual Studio 2008 Express Edition All-in-One .ISO file and burn to DVD. http://www.microsoft.com/express/download/ 2. Install Microsoft Visual C++ 2008 Express Edition from DVD. 3. Use "Microsoft Update" service to check for updates / service packs. 4. Download cygwin setup program from http://cygwin.com/ 5. Ran cygwin setup.exe program to install cygwin for all users. Under "Devel" category, make certain to select "cvs" for installation. 6. Launch cygwin from desktop icon. 7. In cygwin command shell window, execute following two commands, making sure to give email as password when prompted for login: cvs -d :pserver:anonymous at modula3.elegosoft.com:/usr/cvs login cvs -d :pserver:anonymous at modula3.elegosoft.com:/usr/cvs checkout cm3 8. Moved resulting C:\cygwin\home\rcoleburn\cm3 to C:\CM3_CVS_SourceTree Note that you should replace "rcoleburn" above with your Windows login username. 9. Download cm3-min-WIN32-NT386-d5.5.0.zip and cm3-min-WIN32-NT386-d5.5.0-symbols.zip from http://modula3.elegosoft.com/cm3/download.html 10. Unzipped cm3-min-WIN32-NT386-d5.5.0.zip and stored resulting cm3 folder at C:\cm3 11. Unzipped cm3-min-WIN32-NT386-d5.5.0-symbols.zip and stored resulting symbols folder at C:\cm3\symbols 12. Launch Windows Command Prompt shell. The following steps represent commands executed within this shell. 13. path %path%;c:\cm3\bin 14. "C:\Program Files\Microsoft Visual Studio 9.0\VC\vcvarsall.bat" 15. cd C:\CM3_CVS_SourceTree\scripts\win 16. upgrade.cmd ERROR I'M GETTING: ============= === package C:\CM3_CVS_SourceTree\m3-sys\cm3 === +++ "cm3 -build -DROOT=C:\\CM3_CVS_SourceTree -DCM3_VERSION_TEXT=d5.5.1 -DCM3_V ERSION_NUMBER=050501 -DCM3_LAST_CHANGED=2007-12-30 && cm3 -ship -DROOT=C:\\CM3_C VS_SourceTree -DCM3_VERSION_TEXT=d5.5.1 -DCM3_VERSION_NUMBER=050501 -DCM3_LAST_C HANGED=2007-12-30" +++ --- building in NT386 --- ignoring ..\src\m3overrides "C:\CM3_CVS_SourceTree\m3-sys\cm3\src\version.quake", line 136: quake runtime er ror: unable to open "C:\CM3_CVS_SourceTree\m3-sys\cm3\src\../NT386.datenow" for reading --procedure-- -line- -file--- include -- version_impl 136 C:\CM3_CVS_SourceTree\m3-sys\cm3\src\version.quake include_dir 20 C:\CM3_CVS_SourceTree\m3-sys\cm3\src\m3makefile 8 C:\CM3_CVS_SourceTree\m3-sys\cm3\NT386\m3make.args Fatal Error: package build failed ERROR: "cm3 -build -DROOT=C:\\CM3_CVS_SourceTree -DCM3_VERSION_TEXT=d5.5.1 -DCM 3_VERSION_NUMBER=050501 -DCM3_LAST_CHANGED=2007-12-30 && cm3 -ship -DROOT=C:\\CM 3_CVS_SourceTree -DCM3_VERSION_TEXT=d5.5.1 -DCM3_VERSION_NUMBER=050501 -DCM3_LAS T_CHANGED=2007-12-30" ERROR: cd C:\CM3_CVS_SourceTree\m3-sys\cm3 ERROR: set INSTALLROOT=c:\cm3 Regards, Randy Share life as it happens with the new Windows Live. Start sharing! ( http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_012008 ) Put your friends on the big screen with Windows Vista* + Windows Live*. Start now! ( http://www.microsoft.com/windows/shop/specialoffers.mspx?ocid=TXT_TAGLM_CPC_MediaCtr_bigscreen_012008 ) -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Wed Jan 16 15:17:16 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 16 Jan 2008 09:17:16 -0500 Subject: [M3devel] m3tests, pickles In-Reply-To: <478DB947.1E75.00D7.1@scires.com> References: <200801160845.m0G8jlKE064314@camembert.async.caltech.edu> <478DB947.1E75.00D7.1@scires.com> Message-ID: <9C071234-4343-4AEB-B4BF-463FEEDFE831@cs.purdue.edu> Perhaps we just need some builtin specials for types like MUTEX that need different handling. Of course, what does it mean to transfer a MUTEX or a thread anyway?! On Jan 16, 2008, at 7:59 AM, Randy Coleburn wrote: > Mika: > > I've used pickles between various platforms in the past. I use the > Pickle2 variant. > > In my code, I've registered special picklers to deal with mutexes. > Since it doesn't make sense to transfer the state of a mutex > between computers, I simply recreate/reinitialize the mutex on the > receiving computer. Here is an example of an interface and a > module that defines a type ServerConfig.T that I transfer between > computers using Pickle2 and network objects. I've omitted some of > the detail just to show the important stuff about the special > pickling definitions and procedures: > > > INTERFACE ServerConfig; > > CONST > Brand = "ServerConfig"; (* prefix for all branded references *) > TYPE > T <: Public; > > Public = ConfigSettings.T OBJECT > METHODS > init (): T; > (* initialize to default settings *) > ... > END; (* Public *) > END ServerConfig. > > > > MODULE ServerConfig EXPORTS ServerConfig; > > IMPORT > Pickle2 AS Pickle; > TYPE > PrivateMutex = MUTEX BRANDED Brand & ".PrivateMutex" OBJECT END; > REVEAL > T = Public BRANDED Brand & ".T" OBJECT > mutex: PrivateMutex := NIL; > ... > METHODS > OVERRIDES > init := Init; > ... > END; (* T *) > > (*-------------------*) > (* Pickle Procedures *) > (*-------------------*) > > TYPE > Special = Pickle.Special OBJECT > OVERRIDES > write := WriteSpecial; > read := ReadSpecial; > END; (* Special *) > > PROCEDURE WriteSpecial (self: Special; > <*UNUSED*>ref: REFANY; > <*UNUSED*>writer: Pickle.Writer > ) > RAISES {Pickle.Error, > <*NOWARN*>Wr.Failure, Thread.Alerted} = > (* Special pickle writer for ServerConfig.PrivateMutex objects. *) > BEGIN (* WriteSpecial *) > IF self.sc = TYPECODE(PrivateMutex) > THEN > (* omit writing the mutex field *) > ELSE > RAISE Pickle.Error("ServerConfig.WriteSpecial asked to > process unrecognized typecode."); (* should never happen *) > END; (* if *) > END WriteSpecial; > > > > PROCEDURE ReadSpecial (self: Special; > reader: Pickle.Reader; > id: Pickle.RefID > ): REFANY > RAISES {Pickle.Error, > <*NOWARN*>Rd.EndOfFile, Rd.Failure, Thread.Alerted} = > (* Special pickle reader for ServerConfig.PrivateMutex objects. *) > BEGIN (* ReadSpecial *) > IF self.sc = TYPECODE(PrivateMutex) > THEN > WITH m = NEW(PrivateMutex) > DO > reader.noteRef(m, id); > RETURN m; > END; (* with *) > ELSE > RAISE Pickle.Error("ServerConfig.ReadSpecial asked to process > unrecognized typecode."); (* should never happen *) > END; (* if *) > END ReadSpecial; > > > > BEGIN (* ServerConfig module initialization *) > Pickle.RegisterSpecial(NEW(Special, sc := TYPECODE(PrivateMutex))); > END ServerConfig. > > Regards, > Randy > > >>> Mika Nystrom 1/16/2008 3:45 AM >>> > > Can I add something tricky to a wish list on regression testing? > Tricky because I don't know the best way to go about it. > > I have spent quite some time with various versions of Modula-3 > tracking down issues with Pickles. Usually the problem is that > Pickles aren't transferrable between systems, and it turns out that > I have included some type, somewhere, that doesn't translate. > MUTEX is a good example. First of all it would be very nice if > such system dependencies were kept out (for instance, don't know > if it's possible, but something like this...) > > TYPE RealMutex = OBJECT END; > > TYPE WinMutex = RealMutex OBJECT (* windows fields *) END; > TYPE PosixMutex = RealMutex OBJECT (* POSIX fields *) END; > > TYPE MUTEX = RealMutex; > > and of course all that a client sees is MUTEX which is the same > across systems. > > However I realize that what I say above may not be possible or > practical in all cases. > > This brings me to the fact that Pickles are sensitive to certain > types of bugs (I think), and it would be very nice to check that > all OS/processor builds of M3 make compatible Pickles, with the > possible exception of things like MUTEX. Of course this can't be > done within a single build... > > Mika > From jayk123 at hotmail.com Wed Jan 16 16:28:52 2008 From: jayk123 at hotmail.com (Jay) Date: Wed, 16 Jan 2008 15:28:52 +0000 Subject: [M3devel] my status on win32 In-Reply-To: <478DBF8D.1E75.00D7.1@scires.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> <477EA137.1E75.00D7.1@scires.com> <478D394B.1E75.00D7.1@scires.com> <478D47FB.1E75.00D7.1@scires.com> <478DBF8D.1E75.00D7.1@scires.com> Message-ID: Randy, yes and no and clarifications. I mention starting with 5.1.6 as a "worst" or "worse" case. The earlier you start, the harder things are -- for me, to ensure it will work. If you merely start with my 5.5.0, well, what are you rebuilding from source for? Heck, you can use any binary distribution, 4.1, 5.1.6, and just use it. They should work. The n steps you/I give are really actually geared for people who WANT to build from source, it is not what people HAVE to do. As well there have been can be source distributions, to cut out CVS. I'll look into the datefn stuff shortly. As to the installer, well, again, yes and no. The need for the installer is very small. All you have to do today is unzip the .zip somewhere and set the path, and possibly the vcvars thing. That's it. I should..now that you are "pressuring" me for ease of use, teach cm3 about the various %devenvdir%, %vcinstalldir% variables, etc. That way as long as the user installed the tools, even if they elected not to change path/lib/include, cm3 can find the compiler and linker. I know everyone wants to preserve the flexibility of quake/cm3.cfg but...besides, cm3 can be pretty darn smart here. IF cm3.cfg defines SYSTEM_CC, leave things along (NT386 cm3.cfg does not today do that). However if there is now SYSTEM_CC and there is no cl.exe/link.exe in %PATH%, it could go on a quick hunt for them. On the lib and include part, well, the dependency on %include% might only be for errno..maybe not worth it. It has been whatever it is forever, like int* _errno(void); #define errno (*_errno)()). Modula-3 engages in rampant header cloning and CErrnoC was only introduced where that was deemed more fragile than usual, and for Windows it probably wasn't actually fragile -- the fragility, if I may be so rudely judgemental, is because so many other systems are so Johnny-come-lately to arriving at the obviously correct threading model that Windows has had all along (since Win95/NT, can't say anything good about Win3.1; I think OS/2 might have had it correct all along too.). Funny, everyone has FINALLY arrived at the correct threading model, only to have start changing again, since the number of cores and machines is set to be much greater than anticipated, the obvious threading model has been deemed too difficult for anyone to use (Win32, Modula-3, Java, .NET, Python, all the same supposedly too difficult model btw), and so some new one is needed, and well, truthfully, the difficulty is not just for dummies on relatively small multiproc boxes not having simple race conditions, the problem is scaling way way up. Sorry that was my usual tangential. Even the unzip and set path would benefit slightly from a GUI installer. I believe there is some easy thing you can do where you write your GUI installer and you put it in the .zip and then you prepend the GUI self extracting .zip/.exe stub, and you can tell it to run a particular command after the extraction. I guess you might use a fancier thing though? That is, are you going to, say, write a gui installer from scratch in Modula-3? It might be a fun exercise. :) And then you could build the self extracting prefix from source etc. This is the hard way I guess, but more interesing. If you can build an msi or use InstallShield or Wix or something, go ahead. If you use widely availabe free as in beer tools, that can be rolled into whatever automation there is to produce distributions, keeping it up to date shouldn't be a problem. I do have to bring up some annoying questions: 1) Does anyone besides me have the capacity to produce distributions? i.e.: Any Win32 machines left at Elego? 2) I know I ramble. So one of my many tangents/questions went unanswered. Say, in the absence of a gui installer, should .zips/.tar.bz files look like cm3-min-/bin/cm3 or bin/cm3 or cm3/bin/cm3 The last one is more directly usable. The first one is very common. This reminds me though Randy, the distribution I made available was "min", so yeah, like if you are doing any gui programming, using any "standard" library besides m3core or libm3, you'd need to build more from source. I can readily provide you a "std" distribution though. It's "always" been a "problem" to make my files available -- no web site hosting for me -- but recently that wasn't a problem, someone picked the files out of ~jkrell on birch and put them on the web site. Good. One more thing -- Olaf, please confirm repeat yourself, 'cause I admit I wasn't sure it was the right thing, but if you insist, ok. "std" should be "all"? I should not continue to imagine there is a new larger group called "all"? And wherever things are missing from std but do build ok, add them? m3cc should be in std? (I admit some big indecisiveness around m3cc. It is far and away the longest thing to build and so the one you really want to skip the most and leave out of whatever package group. I also wonder if on Windows, there should be some check where if sh is not in the $PATH, just silently skip m3cc? You only need MingWin to build what I have on my system for NT386GNU, except you also need msys just for m3cc. msys is actually quite small, like only 20 files..) Oh, sorry, yet another question. The non-gcc backend is excluded from the build on systems that use the gcc backend. For minimization, that is appropriate. For maximizing cross build capability, it is wrong. The packages build fine. I suspect they work. I am not a user of cross build capability yet, so I don't really care. (What I do for NT386/NT386GNU /might/ be considered sort of a cross build, but it is different/easier). They are small packages. - Jay Date: Wed, 16 Jan 2008 08:25:49 -0500From: rcoleburn at scires.comTo: m3devel at elegosoft.com; jayk123 at hotmail.comSubject: Re: [M3devel] my status on win32 Jay: There is no line in the m3makefile dealing with datefn, so I added the whole statement just before the line include("version.quake") Now, I get an error saying that the variable datefn is not defined. If you change to put quotes around datefn in the include statement, you get an error saying it can't open the file. You made a reference in one of your earlier posts about trying 5.1.6 or 4.1, but note that I started with your cm3-min-WIN32-NT386-d5.5.0.zip , not the 5.1.6 or 4.1 versions. Thus, using d5.5.0 as a base, I am trying to run your "upgrade.cmd" to rebuild the sources I checked out from CVS. Since this doesn't work "out-of-the-box", again I say this fits into the "Broken #1" category. If I can get this to work, I don't mind putting together a Windows installer program that will install the whole thing. That way, folks won't have to install cygwin just to get CVS so that they can install a working cm3. Folks will need to install the free Microsoft Visual C as a prerequisite, but then that's not too bad. Having an installer program would make cm3 more friendly to Windows folks. The current 16-step method is too laborious and error-prone for the person just getting started and they will not give cm3 a second try. As the cm3 system evolves and new releases are made, we will need to keep the installer program up-to-date and I don't mind doing that. After someone gets familiar with cm3 they might want to delve into some of the scripts for rebuilding the system, but until then, I think the installer program is the way to go. Regards, Randy>>> Jay 1/16/2008 1:01 AM >>>I think I see the problem. in cm3\src\m3makefile, make this change > if not defined("NOW") include(datefn) > end datefn is only created if certain other variables aren't defined, and do-pkg defines them.I don't know why I don't see this. Later.Could be that the Python scripts have a typo and don't define them.I've been using them more than cmd. If the host is NT, "NOW" is either gotten from an updated cm3.exe, or left to "not available". So the initial cm3 built from older cm3 can't report when it was built, but cm3 built from current cm3 can. I need to change that: 1) to be a function for niceness 2) to make it that way for Posix, for any host but I haven't been using Posix as much lately so not testing it. - Jay Date: Tue, 15 Jan 2008 23:55:39 -0500From: rcoleburn at scires.comTo: m3devel at elegosoft.com; jayk123 at hotmail.comSubject: RE: my status on win32 Jay: In the file version.quake, I made the following edit: changed line: local datefn = "../" & TARGET & ".datenow" to: local datefn = ".." & SL & TARGET & ".datenow" This change has the effect of putting a backward slash in the pathname instead of a forward slash, so we getC:\CM3_CVS_SourceTree\m3-sys\cm3\src\..\NT386.datenow So from that perspective, the change seems good. Unfortunately, I still get the error that this file can't be opened. A quick check of C:\CM3_CVS_SourceTree\m3-sys\cm3\NT386 shows that the file .datenow does not exist. Regards, Randy>>> Jay 1/15/2008 11:03 PM >>>That's not too bad really. 1) I'd recommend putting cm3 at the start of the path instead of the end. 2) Just comment out the offending code to make progress. It's not critical. >> C:\CM3_CVS_SourceTree\m3-sys\cm3\src\../NT386.datenow The code is: C:\CM3_CVS_SourceTree\m3-sys\cm3\src\version.quake or such, included by cm3\src\m3makefile. Does the file exist?Does version.quake use "/" or "SL"? If it uses "/", try replacing with SL (and ampersand for string concat). Could be that a newer binary distributions works better with forward slashes. > 4. > 5. > 6. Launch cygwin from desktop icon. Cygwin is only needed for cvs, I think you realize. Could you send me offline the result of just running "set" after running vcvarsall? I'd like to adapt pylib.py to it maybe. (I can start from 5.1.6 and will try 4.1 at some point.) - Jay Date: Tue, 15 Jan 2008 22:52:59 -0500From: rcoleburn at scires.comTo: m3devel at elegosoft.com; jayk123 at hotmail.comSubject: my status on win32 Jay et al: I've listed below the steps I've undertaken to try and build the current sources on Windows XP. I've also attached a text file showing the output I got when trying to build everything using Jay's upgrade.cmd script. Unfortunately, I'm getting a build error (see below). Please advise on how to resolve. STEPS I TOOK: ========= 1. Download Microsoft Visual Studio 2008 Express Edition All-in-One .ISO file and burn to DVD. http://www.microsoft.com/express/download/ 2. Install Microsoft Visual C++ 2008 Express Edition from DVD. 3. Use "Microsoft Update" service to check for updates / service packs. 4. Download cygwin setup program from http://cygwin.com/ 5. Ran cygwin setup.exe program to install cygwin for all users. Under "Devel" category, make certain to select "cvs" for installation. 6. Launch cygwin from desktop icon. 7. In cygwin command shell window, execute following two commands, making sure to give email as password when prompted for login: cvs -d :pserver:anonymous at modula3.elegosoft.com:/usr/cvs login cvs -d :pserver:anonymous at modula3.elegosoft.com:/usr/cvs checkout cm3 8. Moved resulting C:\cygwin\home\rcoleburn\cm3 to C:\CM3_CVS_SourceTree Note that you should replace "rcoleburn" above with your Windows login username. 9. Download cm3-min-WIN32-NT386-d5.5.0.zip and cm3-min-WIN32-NT386-d5.5.0-symbols.zip from http://modula3.elegosoft.com/cm3/download.html 10. Unzipped cm3-min-WIN32-NT386-d5.5.0.zip and stored resulting cm3 folder at C:\cm3 11. Unzipped cm3-min-WIN32-NT386-d5.5.0-symbols.zip and stored resulting symbols folder at C:\cm3\symbols 12. Launch Windows Command Prompt shell. The following steps represent commands executed within this shell. 13. path %path%;c:\cm3\bin 14. "C:\Program Files\Microsoft Visual Studio 9.0\VC\vcvarsall.bat" 15. cd C:\CM3_CVS_SourceTree\scripts\win 16. upgrade.cmd ERROR I'M GETTING: ============= === package C:\CM3_CVS_SourceTree\m3-sys\cm3 ===+++ "cm3 -build -DROOT=C:\\CM3_CVS_SourceTree -DCM3_VERSION_TEXT=d5.5.1 -DCM3_VERSION_NUMBER=050501 -DCM3_LAST_CHANGED=2007-12-30 && cm3 -ship -DROOT=C:\\CM3_CVS_SourceTree -DCM3_VERSION_TEXT=d5.5.1 -DCM3_VERSION_NUMBER=050501 -DCM3_LAST_CHANGED=2007-12-30" +++--- building in NT386 --- ignoring ..\src\m3overrides "C:\CM3_CVS_SourceTree\m3-sys\cm3\src\version.quake", line 136: quake runtime error: unable to open "C:\CM3_CVS_SourceTree\m3-sys\cm3\src\../NT386.datenow" forreading --procedure-- -line- -file---include -- version_impl 136 C:\CM3_CVS_SourceTree\m3-sys\cm3\src\version.quakeinclude_dir 20 C:\CM3_CVS_SourceTree\m3-sys\cm3\src\m3makefile 8 C:\CM3_CVS_SourceTree\m3-sys\cm3\NT386\m3make.args Fatal Error: package build failedERROR: "cm3 -build -DROOT=C:\\CM3_CVS_SourceTree -DCM3_VERSION_TEXT=d5.5.1 -DCM3_VERSION_NUMBER=050501 -DCM3_LAST_CHANGED=2007-12-30 && cm3 -ship -DROOT=C:\\CM3_CVS_SourceTree -DCM3_VERSION_TEXT=d5.5.1 -DCM3_VERSION_NUMBER=050501 -DCM3_LAST_CHANGED=2007-12-30"ERROR: cd C:\CM3_CVS_SourceTree\m3-sys\cm3ERROR: set INSTALLROOT=c:\cm3 Regards, Randy Share life as it happens with the new Windows Live. Start sharing! Put your friends on the big screen with Windows Vista? + Windows LiveT. Start now! _________________________________________________________________ Get the power of Windows + Web with the new Windows Live. http://www.windowslive.com?ocid=TXT_TAGHM_Wave2_powerofwindows_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Wed Jan 16 16:29:32 2008 From: jayk123 at hotmail.com (Jay) Date: Wed, 16 Jan 2008 15:29:32 +0000 Subject: [M3devel] my status on win32 In-Reply-To: <478DBF8D.1E75.00D7.1@scires.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> <477EA137.1E75.00D7.1@scires.com> <478D394B.1E75.00D7.1@scires.com> <478D47FB.1E75.00D7.1@scires.com> <478DBF8D.1E75.00D7.1@scires.com> Message-ID: Yes I agree it is "broken #1" and shouldn't be this way, but I assure you, really, your results are 99% there. What isn't working is minor and easy to fix and much is working. - Jay Date: Wed, 16 Jan 2008 08:25:49 -0500From: rcoleburn at scires.comTo: m3devel at elegosoft.com; jayk123 at hotmail.comSubject: Re: [M3devel] my status on win32 Jay: There is no line in the m3makefile dealing with datefn, so I added the whole statement just before the line include("version.quake") Now, I get an error saying that the variable datefn is not defined. If you change to put quotes around datefn in the include statement, you get an error saying it can't open the file. You made a reference in one of your earlier posts about trying 5.1.6 or 4.1, but note that I started with your cm3-min-WIN32-NT386-d5.5.0.zip , not the 5.1.6 or 4.1 versions. Thus, using d5.5.0 as a base, I am trying to run your "upgrade.cmd" to rebuild the sources I checked out from CVS. Since this doesn't work "out-of-the-box", again I say this fits into the "Broken #1" category. If I can get this to work, I don't mind putting together a Windows installer program that will install the whole thing. That way, folks won't have to install cygwin just to get CVS so that they can install a working cm3. Folks will need to install the free Microsoft Visual C as a prerequisite, but then that's not too bad. Having an installer program would make cm3 more friendly to Windows folks. The current 16-step method is too laborious and error-prone for the person just getting started and they will not give cm3 a second try. As the cm3 system evolves and new releases are made, we will need to keep the installer program up-to-date and I don't mind doing that. After someone gets familiar with cm3 they might want to delve into some of the scripts for rebuilding the system, but until then, I think the installer program is the way to go. Regards, Randy>>> Jay 1/16/2008 1:01 AM >>>I think I see the problem. in cm3\src\m3makefile, make this change > if not defined("NOW") include(datefn) > end datefn is only created if certain other variables aren't defined, and do-pkg defines them.I don't know why I don't see this. Later.Could be that the Python scripts have a typo and don't define them.I've been using them more than cmd. If the host is NT, "NOW" is either gotten from an updated cm3.exe, or left to "not available". So the initial cm3 built from older cm3 can't report when it was built, but cm3 built from current cm3 can. I need to change that: 1) to be a function for niceness 2) to make it that way for Posix, for any host but I haven't been using Posix as much lately so not testing it. - Jay Date: Tue, 15 Jan 2008 23:55:39 -0500From: rcoleburn at scires.comTo: m3devel at elegosoft.com; jayk123 at hotmail.comSubject: RE: my status on win32 Jay: In the file version.quake, I made the following edit: changed line: local datefn = "../" & TARGET & ".datenow" to: local datefn = ".." & SL & TARGET & ".datenow" This change has the effect of putting a backward slash in the pathname instead of a forward slash, so we getC:\CM3_CVS_SourceTree\m3-sys\cm3\src\..\NT386.datenow So from that perspective, the change seems good. Unfortunately, I still get the error that this file can't be opened. A quick check of C:\CM3_CVS_SourceTree\m3-sys\cm3\NT386 shows that the file .datenow does not exist. Regards, Randy>>> Jay 1/15/2008 11:03 PM >>>That's not too bad really. 1) I'd recommend putting cm3 at the start of the path instead of the end. 2) Just comment out the offending code to make progress. It's not critical. >> C:\CM3_CVS_SourceTree\m3-sys\cm3\src\../NT386.datenow The code is: C:\CM3_CVS_SourceTree\m3-sys\cm3\src\version.quake or such, included by cm3\src\m3makefile. Does the file exist?Does version.quake use "/" or "SL"? If it uses "/", try replacing with SL (and ampersand for string concat). Could be that a newer binary distributions works better with forward slashes. > 4. > 5. > 6. Launch cygwin from desktop icon. Cygwin is only needed for cvs, I think you realize. Could you send me offline the result of just running "set" after running vcvarsall? I'd like to adapt pylib.py to it maybe. (I can start from 5.1.6 and will try 4.1 at some point.) - Jay Date: Tue, 15 Jan 2008 22:52:59 -0500From: rcoleburn at scires.comTo: m3devel at elegosoft.com; jayk123 at hotmail.comSubject: my status on win32 Jay et al: I've listed below the steps I've undertaken to try and build the current sources on Windows XP. I've also attached a text file showing the output I got when trying to build everything using Jay's upgrade.cmd script. Unfortunately, I'm getting a build error (see below). Please advise on how to resolve. STEPS I TOOK: ========= 1. Download Microsoft Visual Studio 2008 Express Edition All-in-One .ISO file and burn to DVD. http://www.microsoft.com/express/download/ 2. Install Microsoft Visual C++ 2008 Express Edition from DVD. 3. Use "Microsoft Update" service to check for updates / service packs. 4. Download cygwin setup program from http://cygwin.com/ 5. Ran cygwin setup.exe program to install cygwin for all users. Under "Devel" category, make certain to select "cvs" for installation. 6. Launch cygwin from desktop icon. 7. In cygwin command shell window, execute following two commands, making sure to give email as password when prompted for login: cvs -d :pserver:anonymous at modula3.elegosoft.com:/usr/cvs login cvs -d :pserver:anonymous at modula3.elegosoft.com:/usr/cvs checkout cm3 8. Moved resulting C:\cygwin\home\rcoleburn\cm3 to C:\CM3_CVS_SourceTree Note that you should replace "rcoleburn" above with your Windows login username. 9. Download cm3-min-WIN32-NT386-d5.5.0.zip and cm3-min-WIN32-NT386-d5.5.0-symbols.zip from http://modula3.elegosoft.com/cm3/download.html 10. Unzipped cm3-min-WIN32-NT386-d5.5.0.zip and stored resulting cm3 folder at C:\cm3 11. Unzipped cm3-min-WIN32-NT386-d5.5.0-symbols.zip and stored resulting symbols folder at C:\cm3\symbols 12. Launch Windows Command Prompt shell. The following steps represent commands executed within this shell. 13. path %path%;c:\cm3\bin 14. "C:\Program Files\Microsoft Visual Studio 9.0\VC\vcvarsall.bat" 15. cd C:\CM3_CVS_SourceTree\scripts\win 16. upgrade.cmd ERROR I'M GETTING: ============= === package C:\CM3_CVS_SourceTree\m3-sys\cm3 ===+++ "cm3 -build -DROOT=C:\\CM3_CVS_SourceTree -DCM3_VERSION_TEXT=d5.5.1 -DCM3_VERSION_NUMBER=050501 -DCM3_LAST_CHANGED=2007-12-30 && cm3 -ship -DROOT=C:\\CM3_CVS_SourceTree -DCM3_VERSION_TEXT=d5.5.1 -DCM3_VERSION_NUMBER=050501 -DCM3_LAST_CHANGED=2007-12-30" +++--- building in NT386 --- ignoring ..\src\m3overrides "C:\CM3_CVS_SourceTree\m3-sys\cm3\src\version.quake", line 136: quake runtime error: unable to open "C:\CM3_CVS_SourceTree\m3-sys\cm3\src\../NT386.datenow" forreading --procedure-- -line- -file---include -- version_impl 136 C:\CM3_CVS_SourceTree\m3-sys\cm3\src\version.quakeinclude_dir 20 C:\CM3_CVS_SourceTree\m3-sys\cm3\src\m3makefile 8 C:\CM3_CVS_SourceTree\m3-sys\cm3\NT386\m3make.args Fatal Error: package build failedERROR: "cm3 -build -DROOT=C:\\CM3_CVS_SourceTree -DCM3_VERSION_TEXT=d5.5.1 -DCM3_VERSION_NUMBER=050501 -DCM3_LAST_CHANGED=2007-12-30 && cm3 -ship -DROOT=C:\\CM3_CVS_SourceTree -DCM3_VERSION_TEXT=d5.5.1 -DCM3_VERSION_NUMBER=050501 -DCM3_LAST_CHANGED=2007-12-30"ERROR: cd C:\CM3_CVS_SourceTree\m3-sys\cm3ERROR: set INSTALLROOT=c:\cm3 Regards, Randy Share life as it happens with the new Windows Live. Start sharing! Put your friends on the big screen with Windows Vista? + Windows LiveT. Start now! _________________________________________________________________ Watch ?Cause Effect,? a show about real people making a real difference. http://im.live.com/Messenger/IM/MTV/?source=text_watchcause -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcoleburn at scires.com Wed Jan 16 17:24:34 2008 From: rcoleburn at scires.com (Randy Coleburn) Date: Wed, 16 Jan 2008 11:24:34 -0500 Subject: [M3devel] my status on win32 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> <477EA137.1E75.00D7.1@scires.com> <478D394B.1E75.00D7.1@scires.com> <478D47FB.1E75.00D7.1@scires.com> <478DBF8D.1E75.00D7.1@scires.com> Message-ID: <478DE973.1E75.00D7.1@scires.com> Jay: Not sure I've clued in to all of your dialog. Sorry. I have in the past used a free tool to build an installer package and I was thinking of using it again. Since the tool is free, we could put all the work I do into the CVS repository so that others could also maintain it. What I am looking to achieve is to have a way where a "normal" Windows user could download a program, run it, and have all of the cm3 packages installed without having to use the MIN distribution to build it up or any other tools to get the sources (like cvs). You could achieve the same thing by having a big ZIP file also I suppose, but having the installer would also let us easily put something in the start menu to launch a command line with all the environment variables set properly via automatic call to vcvars et al. When I get "Reactor" working, it too could be put into the start menu. That just makes it fit in better with the Windows user culture I think. The reason I wanted to rebuild everything is two-fold: 1) ensure it can be done (i.e., test for "Broken #1"), and 2) get all of the rest of the packages built so I could then use cm3 to build "reactor" and my own programs and test them to see if there are any "Broken #2" issues. The MIN distribution is really insufficient to do much of anything except to build the rest of the packages you need. My understanding is that I needed to use CVS to get the current sources, because if I went back to the source archive, it was old and known to be Broken #1 on Windows. I'm glad that you believe the current "Broken #1" situation is easy to fix. Let me know what to do and I'll give it another try. My experience in the past has been that there are 3 conditions to getting cm3 to work properly on windows after it has been installed: 1) make sure your environment variables are set up by vcvars to point to the compiler/linker/libraries (of course if you used a non-Microsoft C compiler/linker you would need to use something other than vcvars); 2) make sure cm3.cfg has the right paths in place to find all the libraries and tools using DOS style short names (no embedded spaces); and 3) make sure C:\cm3\bin is in your path. Of these, #2 & #3 are essentially one-time events, and #1 can be set up by a invoking a batch/command file via a shortcut, so no big deal for me. You could even make #1 a one-time event by modifying the system-level (vice user-level) environment variables. The old cm3install program seemed to do a decent job of #2 for me. Also, I've noted some of your past dialog about accepting either '/' or '\' as a path separator. I'm sure you are aware that on Windows '/' is used often for switches (arguments). Plus Windows also allows spaces to be embedded in the command line, so whatever solution you propose needs to take into account that a valid command line might look like this: C:\My Program Folder\My Program.exe /myArg1 /myArg2 In some situations, this command line would have to be quoted and rendered as: "C:\My Program Folder\My Program.exe" /myArg1 /myArg2 and in places where the backslash is an escape character, I've seen "C:\\My Program Folder\\My Program.exe" /myArg1 /myArg2 Alas, I seem to have rambled a bit also. Sorry. The immediate need for me now is to solve the Broken #1 condition, so please let me know how to fix it and proceed. Regards, Randy >>> Jay 1/16/2008 10:28 AM >>> Randy, yes and no and clarifications. I mention starting with 5.1.6 as a "worst" or "worse" case. The earlier you start, the harder things are -- for me, to ensure it will work. If you merely start with my 5.5.0, well, what are you rebuilding from source for? Heck, you can use any binary distribution, 4.1, 5.1.6, and just use it. They should work. The n steps you/I give are really actually geared for people who WANT to build from source, it is not what people HAVE to do. As well there have been can be source distributions, to cut out CVS. I'll look into the datefn stuff shortly. As to the installer, well, again, yes and no. The need for the installer is very small. All you have to do today is unzip the .zip somewhere and set the path, and possibly the vcvars thing. That's it. I should..now that you are "pressuring" me for ease of use, teach cm3 about the various %devenvdir%, %vcinstalldir% variables, etc. That way as long as the user installed the tools, even if they elected not to change path/lib/include, cm3 can find the compiler and linker. I know everyone wants to preserve the flexibility of quake/cm3.cfg but...besides, cm3 can be pretty darn smart here. IF cm3.cfg defines SYSTEM_CC, leave things along (NT386 cm3.cfg does not today do that). However if there is now SYSTEM_CC and there is no cl.exe/link.exe in %PATH%, it could go on a quick hunt for them. On the lib and include part, well, the dependency on %include% might only be for errno..maybe not worth it. It has been whatever it is forever, like int* _errno(void); #define errno (*_errno)()). Modula-3 engages in rampant header cloning and CErrnoC was only introduced where that was deemed more fragile than usual, and for Windows it probably wasn't actually fragile -- the fragility, if I may be so rudely judgemental, is because so many other systems are so Johnny-come-lately to arriving at the obviously correct threading model that Windows has had all along (since Win95/NT, can't say anything good about Win3.1; I think OS/2 might have had it correct all along too.). Funny, everyone has FINALLY arrived at the correct threading model, only to have start changing again, since the number of cores and machines is set to be much greater than anticipated, the obvious threading model has been deemed too difficult for anyone to use (Win32, Modula-3, Java, .NET, Python, all the same supposedly too difficult model btw), and so some new one is needed, and well, truthfully, the difficulty is not just for dummies on relatively small multiproc boxes not having simple race conditions, the problem is scaling way way up. Sorry that was my usual tangential. Even the unzip and set path would benefit slightly from a GUI installer. I believe there is some easy thing you can do where you write your GUI installer and you put it in the .zip and then you prepend the GUI self extracting .zip/.exe stub, and you can tell it to run a particular command after the extraction. I guess you might use a fancier thing though? That is, are you going to, say, write a gui installer from scratch in Modula-3? It might be a fun exercise. :) And then you could build the self extracting prefix from source etc. This is the hard way I guess, but more interesing. If you can build an msi or use InstallShield or Wix or something, go ahead. If you use widely availabe free as in beer tools, that can be rolled into whatever automation there is to produce distributions, keeping it up to date shouldn't be a problem. I do have to bring up some annoying questions: 1) Does anyone besides me have the capacity to produce distributions? i.e.: Any Win32 machines left at Elego? 2) I know I ramble. So one of my many tangents/questions went unanswered. Say, in the absence of a gui installer, should .zips/.tar.bz files look like cm3-min-/bin/cm3 or bin/cm3 or cm3/bin/cm3 The last one is more directly usable. The first one is very common. This reminds me though Randy, the distribution I made available was "min", so yeah, like if you are doing any gui programming, using any "standard" library besides m3core or libm3, you'd need to build more from source. I can readily provide you a "std" distribution though. It's "always" been a "problem" to make my files available -- no web site hosting for me -- but recently that wasn't a problem, someone picked the files out of ~jkrell on birch and put them on the web site. Good. One more thing -- Olaf, please confirm repeat yourself, 'cause I admit I wasn't sure it was the right thing, but if you insist, ok. "std" should be "all"? I should not continue to imagine there is a new larger group called "all"? And wherever things are missing from std but do build ok, add them? m3cc should be in std? (I admit some big indecisiveness around m3cc. It is far and away the longest thing to build and so the one you really want to skip the most and leave out of whatever package group. I also wonder if on Windows, there should be some check where if sh is not in the $PATH, just silently skip m3cc? You only need MingWin to build what I have on my system for NT386GNU, except you also need msys just for m3cc. msys is actually quite small, like only 20 files..) Oh, sorry, yet another question. The non-gcc backend is excluded from the build on systems that use the gcc backend. For minimization, that is appropriate. For maximizing cross build capability, it is wrong. The packages build fine. I suspect they work. I am not a user of cross build capability yet, so I don't really care. (What I do for NT386/NT386GNU /might/ be considered sort of a cross build, but it is different/easier). They are small packages. - Jay Date: Wed, 16 Jan 2008 08:25:49 -0500 From: rcoleburn at scires.com To: m3devel at elegosoft.com; jayk123 at hotmail.com Subject: Re: [M3devel] my status on win32 Jay: There is no line in the m3makefile dealing with datefn, so I added the whole statement just before the line include("version.quake") Now, I get an error saying that the variable datefn is not defined. If you change to put quotes around datefn in the include statement, you get an error saying it can't open the file. You made a reference in one of your earlier posts about trying 5.1.6 or 4.1, but note that I started with your cm3-min-WIN32-NT386-d5.5.0.zip , not the 5.1.6 or 4.1 versions. Thus, using d5.5.0 as a base, I am trying to run your "upgrade.cmd" to rebuild the sources I checked out from CVS. Since this doesn't work "out-of-the-box", again I say this fits into the "Broken #1" category. If I can get this to work, I don't mind putting together a Windows installer program that will install the whole thing. That way, folks won't have to install cygwin just to get CVS so that they can install a working cm3. Folks will need to install the free Microsoft Visual C as a prerequisite, but then that's not too bad. Having an installer program would make cm3 more friendly to Windows folks. The current 16-step method is too laborious and error-prone for the person just getting started and they will not give cm3 a second try. As the cm3 system evolves and new releases are made, we will need to keep the installer program up-to-date and I don't mind doing that. After someone gets familiar with cm3 they might want to delve into some of the scripts for rebuilding the system, but until then, I think the installer program is the way to go. Regards, Randy >>> Jay 1/16/2008 1:01 AM >>> I think I see the problem. in cm3\src\m3makefile, make this change > if not defined("NOW") include(datefn) > end datefn is only created if certain other variables aren't defined, and do-pkg defines them. I don't know why I don't see this. Later. Could be that the Python scripts have a typo and don't define them. I've been using them more than cmd. If the host is NT, "NOW" is either gotten from an updated cm3.exe, or left to "not available". So the initial cm3 built from older cm3 can't report when it was built, but cm3 built from current cm3 can. I need to change that: 1) to be a function for niceness 2) to make it that way for Posix, for any host but I haven't been using Posix as much lately so not testing it. - Jay Date: Tue, 15 Jan 2008 23:55:39 -0500 From: rcoleburn at scires.com To: m3devel at elegosoft.com; jayk123 at hotmail.com Subject: RE: my status on win32 Jay: In the file version.quake, I made the following edit: changed line: local datefn = "../" & TARGET & ".datenow" to: local datefn = ".." & SL & TARGET & ".datenow" This change has the effect of putting a backward slash in the pathname instead of a forward slash, so we get C:\CM3_CVS_SourceTree\m3-sys\cm3\src\..\NT386.datenow So from that perspective, the change seems good. Unfortunately, I still get the error that this file can't be opened. A quick check of C:\CM3_CVS_SourceTree\m3-sys\cm3\NT386 shows that the file .datenow does not exist. Regards, Randy >>> Jay 1/15/2008 11:03 PM >>> That's not too bad really. 1) I'd recommend putting cm3 at the start of the path instead of the end. 2) Just comment out the offending code to make progress. It's not critical. >> C:\CM3_CVS_SourceTree\m3-sys\cm3\src\../NT386.datenow The code is: C:\CM3_CVS_SourceTree\m3-sys\cm3\src\version.quake or such, included by cm3\src\m3makefile. Does the file exist? Does version.quake use "/" or "SL"? If it uses "/", try replacing with SL (and ampersand for string concat). Could be that a newer binary distributions works better with forward slashes. > 4. > 5. > 6. Launch cygwin from desktop icon. Cygwin is only needed for cvs, I think you realize. Could you send me offline the result of just running "set" after running vcvarsall? I'd like to adapt pylib.py to it maybe. (I can start from 5.1.6 and will try 4.1 at some point.) - Jay Date: Tue, 15 Jan 2008 22:52:59 -0500 From: rcoleburn at scires.com To: m3devel at elegosoft.com; jayk123 at hotmail.com Subject: my status on win32 Jay et al: I've listed below the steps I've undertaken to try and build the current sources on Windows XP. I've also attached a text file showing the output I got when trying to build everything using Jay's upgrade.cmd script. Unfortunately, I'm getting a build error (see below). Please advise on how to resolve. STEPS I TOOK: ========= 1. Download Microsoft Visual Studio 2008 Express Edition All-in-One .ISO file and burn to DVD. http://www.microsoft.com/express/download/ 2. Install Microsoft Visual C++ 2008 Express Edition from DVD. 3. Use "Microsoft Update" service to check for updates / service packs. 4. Download cygwin setup program from http://cygwin.com/ 5. Ran cygwin setup.exe program to install cygwin for all users. Under "Devel" category, make certain to select "cvs" for installation. 6. Launch cygwin from desktop icon. 7. In cygwin command shell window, execute following two commands, making sure to give email as password when prompted for login: cvs -d :pserver:anonymous at modula3.elegosoft.com:/usr/cvs login cvs -d :pserver:anonymous at modula3.elegosoft.com:/usr/cvs checkout cm3 8. Moved resulting C:\cygwin\home\rcoleburn\cm3 to C:\CM3_CVS_SourceTree Note that you should replace "rcoleburn" above with your Windows login username. 9. Download cm3-min-WIN32-NT386-d5.5.0.zip and cm3-min-WIN32-NT386-d5.5.0-symbols.zip from http://modula3.elegosoft.com/cm3/download.html 10. Unzipped cm3-min-WIN32-NT386-d5.5.0.zip and stored resulting cm3 folder at C:\cm3 11. Unzipped cm3-min-WIN32-NT386-d5.5.0-symbols.zip and stored resulting symbols folder at C:\cm3\symbols 12. Launch Windows Command Prompt shell. The following steps represent commands executed within this shell. 13. path %path%;c:\cm3\bin 14. "C:\Program Files\Microsoft Visual Studio 9.0\VC\vcvarsall.bat" 15. cd C:\CM3_CVS_SourceTree\scripts\win 16. upgrade.cmd ERROR I'M GETTING: ============= === package C:\CM3_CVS_SourceTree\m3-sys\cm3 === +++ "cm3 -build -DROOT=C:\\CM3_CVS_SourceTree -DCM3_VERSION_TEXT=d5.5.1 -DCM3_V ERSION_NUMBER=050501 -DCM3_LAST_CHANGED=2007-12-30 && cm3 -ship -DROOT=C:\\CM3_C VS_SourceTree -DCM3_VERSION_TEXT=d5.5.1 -DCM3_VERSION_NUMBER=050501 -DCM3_LAST_C HANGED=2007-12-30" +++ --- building in NT386 --- ignoring ..\src\m3overrides "C:\CM3_CVS_SourceTree\m3-sys\cm3\src\version.quake", line 136: quake runtime er ror: unable to open "C:\CM3_CVS_SourceTree\m3-sys\cm3\src\../NT386.datenow" for reading --procedure-- -line- -file--- include -- version_impl 136 C:\CM3_CVS_SourceTree\m3-sys\cm3\src\version.quake include_dir 20 C:\CM3_CVS_SourceTree\m3-sys\cm3\src\m3makefile 8 C:\CM3_CVS_SourceTree\m3-sys\cm3\NT386\m3make.args Fatal Error: package build failed ERROR: "cm3 -build -DROOT=C:\\CM3_CVS_SourceTree -DCM3_VERSION_TEXT=d5.5.1 -DCM 3_VERSION_NUMBER=050501 -DCM3_LAST_CHANGED=2007-12-30 && cm3 -ship -DROOT=C:\\CM 3_CVS_SourceTree -DCM3_VERSION_TEXT=d5.5.1 -DCM3_VERSION_NUMBER=050501 -DCM3_LAS T_CHANGED=2007-12-30" ERROR: cd C:\CM3_CVS_SourceTree\m3-sys\cm3 ERROR: set INSTALLROOT=c:\cm3 Regards, Randy Share life as it happens with the new Windows Live. Start sharing! ( http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_012008 ) Put your friends on the big screen with Windows Vista* + Windows LiveT. Start now! ( http://www.microsoft.com/windows/shop/specialoffers.mspx?ocid=TXT_TAGLM_CPC_MediaCtr_bigscreen_012008 ) Get the power of Windows + Web with the new Windows Live. Get it now! ( http://www.windowslive.com/?ocid=TXT_TAGHM_Wave2_powerofwindows_012008 ) -------------- next part -------------- An HTML attachment was scrubbed... URL: From darko at darko.org Wed Jan 16 19:28:48 2008 From: darko at darko.org (Darko) Date: Wed, 16 Jan 2008 10:28:48 -0800 Subject: [M3devel] GC question version 2 Message-ID: Ok, a slightly different approach: Can the GC give me a list of all the objects that contain a reference to an object? Would it be thorough (ie not miss any objects)? False positives might be ok. Then I could check the type of each object and update the references myself. It would be reasonable to assume that the references in question were not being changed by any thread during the checking process. Thanks, Darko. From jayk123 at hotmail.com Wed Jan 16 20:13:21 2008 From: jayk123 at hotmail.com (Jay) Date: Wed, 16 Jan 2008 19:13:21 +0000 Subject: [M3devel] my status on win32 In-Reply-To: <478DE973.1E75.00D7.1@scires.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> <477EA137.1E75.00D7.1@scires.com> <478D394B.1E75.00D7.1@scires.com> <478D47FB.1E75.00D7.1@scires.com> <478DBF8D.1E75.00D7.1@scires.com> <478DE973.1E75.00D7.1@scires.com> Message-ID: Hi Randy. I mostly agree and understand. Go ahead with your installer work. :) #2 is no longer needed. The cm3.cfg I use, that is checked in, that is in the newer distributions, just runs plain "cl" and links to plain "kernel32.dll", and doesn't pass any /I switches to cl => therefore it depends on %PATH%, %LIB%, and %INCLUDE%. As I was saying/rambling, we/I can probably teach cm3 a bit so as to not need vcvars. As I recall, but I need to check, when you install VC, there are some variables it sets unconditionally, and some it asks the user if they should be set. The ones it asks about are PATH, LIB, INCLUDE. The ones it sets unconditionally are the "root" of the install. PATH / LIB / INCLUDE are more invasive, more impactful, have more potential to break things. They are also easily derived from the "root". Similarly, the CM3 installer could ask the user if it is ok to modify their %PATH%, and do it in the registry and set the WM_INI_CHANGED or such message so that Explorer picks it up. Need to check MSDN on this. Forward slashes are fine for options. I take a dim view of these space, quoting, escaping issues. I have very mixed experience here. In SOME situations, your command lines pass through various layers of code, with various attempts to handle or ignore the various issues. The result is in my opinion an unpredictable mess. The problem is that people have confused "an array of strings" with "one flat string". At this point the confusion is widespread and deeply ingrained. On Unix I believe people just ignore the issue by not using spaces (or quotes?) on the command line, though escaping issues still remain for other characters. You just have to read the documenation on CreateProcess to realize how messed up this is. c:\program files\foo I believe is interpreted multiple ways until something works. It can be running c:\program with the parameter files\foo, or it can be running c:\program files\foo. Reliable interprocess communication should not be via command lines but via something more strongly typed such as RPC or shared memory or reading/writing a Pickle. I use the command line a lot, and I frequently copy paths from the command line and paste them into the file open dialog, which does not accept forward slashes nor nested double slashes. It should but oh well. Therefore I have goal before much longer to ensure that every path generated and probably reported by cm3 is in the "normal" form. If the user types in a forward slash, perhaps that should be reported back though. And forward slashes should be ok to enter and then get used internally. The need to configure short file names are gone, along with the need to quote them, by virtue of the dependency on environment variables. Paths with spaces can still come in other ways, but not via SYSTEM_CC in a "normal" cm3, for my newfangled revisionist version of "normal". :) Short names really stink, in so many ways. First, they aren't necessary even shorter, they are just of a limited character set. They can be up to twice as long as "long". Try this: mkdir \1.1.1. dir /x 1* Also, wildcard matching "always" (in FindFirstFile/FindNextFile) operates against both long and short, and since short are unpredcitable, wildcard matching therefore is. An example, probably, is: echo > foo.bar echo > food.barf dir *.bar Will probably, but not necessarily, match both files, though you would only expect one match. As well, I don't believe short file names have always been backed up and restored -- for anyone that uses any backup softwre (not me!). So you determine your short name, you backup and restore, and it changes. Or more clearly, recreating files, might get a different name. It's a mess. I would discourage you from persisting short names ever. Names with spaces I discourage but not as strong. For example, in some contexts, there is just one name and there is no ambiguity. Actually in %PATH% there is no ambiguity because the sepArator is the semicolon.I think Win9x different though, sigh. I agree from my "min" distribution, you need to build the rest. I have to admit, I thought the "culture" on this list was to want to and actually build the system from source. I will put a "std" distribution up on birch this week hopefully and hopefully someone will put it on the web page. Maintaining the installer should not be a problem. As long as the licensing and cost and all is right. I have not fixed the build yet, sorry. - Jay Date: Wed, 16 Jan 2008 11:24:34 -0500From: rcoleburn at scires.comTo: m3devel at elegosoft.com; jayk123 at hotmail.comSubject: Re: [M3devel] my status on win32 Jay: Not sure I've clued in to all of your dialog. Sorry. I have in the past used a free tool to build an installer package and I was thinking of using it again. Since the tool is free, we could put all the work I do into the CVS repository so that others could also maintain it. What I am looking to achieve is to have a way where a "normal" Windows user could download a program, run it, and have all of the cm3 packages installed without having to use the MIN distribution to build it up or any other tools to get the sources (like cvs). You could achieve the same thing by having a big ZIP file also I suppose, but having the installer would also let us easily put something in the start menu to launch a command line with all the environment variables set properly via automatic call to vcvars et al. When I get "Reactor" working, it too could be put into the start menu. That just makes it fit in better with the Windows user culture I think. The reason I wanted to rebuild everything is two-fold: 1) ensure it can be done (i.e., test for "Broken #1"), and 2) get all of the rest of the packages built so I could then use cm3 to build "reactor" and my own programs and test them to see if there are any "Broken #2" issues. The MIN distribution is really insufficient to do much of anything except to build the rest of the packages you need. My understanding is that I needed to use CVS to get the current sources, because if I went back to the source archive, it was old and known to be Broken #1 on Windows. I'm glad that you believe the current "Broken #1" situation is easy to fix. Let me know what to do and I'll give it another try. My experience in the past has been that there are 3 conditions to getting cm3 to work properly on windows after it has been installed: 1) make sure your environment variables are set up by vcvars to point to the compiler/linker/libraries (of course if you used a non-Microsoft C compiler/linker you would need to use something other than vcvars); 2) make sure cm3.cfg has the right paths in place to find all the libraries and tools using DOS style short names (no embedded spaces); and 3) make sure C:\cm3\bin is in your path. Of these, #2 & #3 are essentially one-time events, and #1 can be set up by a invoking a batch/command file via a shortcut, so no big deal for me. You could even make #1 a one-time event by modifying the system-level (vice user-level) environment variables. The old cm3install program seemed to do a decent job of #2 for me. Also, I've noted some of your past dialog about accepting either '/' or '\' as a path separator. I'm sure you are aware that on Windows '/' is used often for switches (arguments). Plus Windows also allows spaces to be embedded in the command line, so whatever solution you propose needs to take into account that a valid command line might look like this: C:\My Program Folder\My Program.exe /myArg1 /myArg2 In some situations, this command line would have to be quoted and rendered as: "C:\My Program Folder\My Program.exe" /myArg1 /myArg2 and in places where the backslash is an escape character, I've seen "C:\\My Program Folder\\My Program.exe" /myArg1 /myArg2 Alas, I seem to have rambled a bit also. Sorry. The immediate need for me now is to solve the Broken #1 condition, so please let me know how to fix it and proceed. Regards, Randy>>> Jay 1/16/2008 10:28 AM >>>Randy, yes and no and clarifications. I mention starting with 5.1.6 as a "worst" or "worse" case.The earlier you start, the harder things are -- for me, to ensure it will work. If you merely start with my 5.5.0, well, what are you rebuilding from source for?Heck, you can use any binary distribution, 4.1, 5.1.6, and just use it. They should work. The n steps you/I give are really actually geared for people who WANT to build from source, it is not what people HAVE to do.As well there have been can be source distributions, to cut out CVS. I'll look into the datefn stuff shortly. As to the installer, well, again, yes and no.The need for the installer is very small. All you have to do today is unzip the .zip somewhere and set the path, and possibly the vcvars thing. That's it. I should..now that you are "pressuring" me for ease of use, teach cm3 about the various ?venvdir%, %vcinstalldir% variables, etc. That way as long as the user installed the tools, even if they elected not to change path/lib/include, cm3 can find the compiler and linker. I know everyone wants to preserve the flexibility of quake/cm3.cfg but...besides, cm3 can be pretty darn smart here. IF cm3.cfg defines SYSTEM_CC, leave things along (NT386 cm3.cfg does not today do that). However if there is now SYSTEM_CC and there is no cl.exe/link.exe in %PATH%, it could go on a quick hunt for them. On the lib and include part, well, the dependency on %include% might only be for errno..maybe not worth it. It has been whatever it is forever, like int* _errno(void); #define errno (*_errno)()). Modula-3 engages in rampant header cloning and CErrnoC was only introduced where that was deemed more fragile than usual, and for Windows it probably wasn't actually fragile -- the fragility, if I may be so rudely judgemental, is because so many other systems are so Johnny-come-lately to arriving at the obviously correct threading model that Windows has had all along (since Win95/NT, can't say anything good about Win3.1; I think OS/2 might have had it correct all along too.). Funny, everyone has FINALLY arrived at the correct threading model, only to have start changing again, since the number of cores and machines is set to be much greater than anticipated, the obvious threading model has been deemed too difficult for anyone to use (Win32, Modula-3, Java, .NET, Python, all the same supposedly too difficult model btw), and so some new one is needed, and well, truthfully, the difficulty is not just for dummies on relatively small multiproc boxes not having simple race conditions, the problem is scaling way way up. Sorry that was my usual tangential. Even the unzip and set path would benefit slightly from a GUI installer.I believe there is some easy thing you can do where you write your GUI installer and you put it in the .zip and then you prepend the GUI self extracting .zip/.exe stub, and you can tell it to run a particular command after the extraction. I guess you might use a fancier thing though?That is, are you going to, say, write a gui installer from scratch in Modula-3? It might be a fun exercise. :)And then you could build the self extracting prefix from source etc.This is the hard way I guess, but more interesing.If you can build an msi or use InstallShield or Wix or something, go ahead.If you use widely availabe free as in beer tools, that can be rolled into whatever automation there is to produce distributions, keeping it up to date shouldn't be a problem. I do have to bring up some annoying questions: 1) Does anyone besides me have the capacity to produce distributions? i.e.: Any Win32 machines left at Elego? 2) I know I ramble. So one of my many tangents/questions went unanswered.Say, in the absence of a gui installer, should .zips/.tar.bz files look like cm3-min-/bin/cm3orbin/cm3orcm3/bin/cm3 The last one is more directly usable. The first one is very common. This reminds me though Randy, the distribution I made available was "min", so yeah, like if you are doing any gui programming, using any "standard" library besides m3core or libm3, you'd need to build more from source. I can readily provide you a "std" distribution though.It's "always" been a "problem" to make my files available -- no web site hosting for me -- but recently that wasn't a problem, someone picked the files out of ~jkrell on birch and put them on the web site. Good. One more thing -- Olaf, please confirm repeat yourself, 'cause I admit I wasn't sure it was the right thing, but if you insist, ok. "std" should be "all"? I should not continue to imagine there is a new larger group called "all"? And wherever things are missing from std but do build ok, add them?m3cc should be in std?(I admit some big indecisiveness around m3cc. It is far and away the longest thing to build and so the one you really want to skip the most and leave out of whatever package group. I also wonder if on Windows, there should be some check where if sh is not in the $PATH, just silently skip m3cc? You only need MingWin to build what I have on my system for NT386GNU, except you also need msys just for m3cc. msys is actually quite small, like only 20 files..) Oh, sorry, yet another question.The non-gcc backend is excluded from the build on systems that use the gcc backend.For minimization, that is appropriate.For maximizing cross build capability, it is wrong.The packages build fine. I suspect they work.I am not a user of cross build capability yet, so I don't really care. (What I do for NT386/NT386GNU /might/ be considered sort of a cross build, but it is different/easier).They are small packages. - Jay Date: Wed, 16 Jan 2008 08:25:49 -0500From: rcoleburn at scires.comTo: m3devel at elegosoft.com; jayk123 at hotmail.comSubject: Re: [M3devel] my status on win32 Jay: There is no line in the m3makefile dealing with datefn, so I added the whole statement just before the line include("version.quake") Now, I get an error saying that the variable datefn is not defined. If you change to put quotes around datefn in the include statement, you get an error saying it can't open the file. You made a reference in one of your earlier posts about trying 5.1.6 or 4.1, but note that I started with your cm3-min-WIN32-NT386-d5.5.0.zip , not the 5.1.6 or 4.1 versions. Thus, using d5.5.0 as a base, I am trying to run your "upgrade.cmd" to rebuild the sources I checked out from CVS. Since this doesn't work "out-of-the-box", again I say this fits into the "Broken #1" category. If I can get this to work, I don't mind putting together a Windows installer program that will install the whole thing. That way, folks won't have to install cygwin just to get CVS so that they can install a working cm3. Folks will need to install the free Microsoft Visual C as a prerequisite, but then that's not too bad. Having an installer program would make cm3 more friendly to Windows folks. The current 16-step method is too laborious and error-prone for the person just getting started and they will not give cm3 a second try. As the cm3 system evolves and new releases are made, we will need to keep the installer program up-to-date and I don't mind doing that. After someone gets familiar with cm3 they might want to delve into some of the scripts for rebuilding the system, but until then, I think the installer program is the way to go. Regards, Randy>>> Jay 1/16/2008 1:01 AM >>>I think I see the problem. in cm3\src\m3makefile, make this change > if not defined("NOW") include(datefn) > end datefn is only created if certain other variables aren't defined, and do-pkg defines them.I don't know why I don't see this. Later.Could be that the Python scripts have a typo and don't define them.I've been using them more than cmd. If the host is NT, "NOW" is either gotten from an updated cm3.exe, or left to "not available". So the initial cm3 built from older cm3 can't report when it was built, but cm3 built from current cm3 can. I need to change that: 1) to be a function for niceness 2) to make it that way for Posix, for any host but I haven't been using Posix as much lately so not testing it. - Jay Date: Tue, 15 Jan 2008 23:55:39 -0500From: rcoleburn at scires.comTo: m3devel at elegosoft.com; jayk123 at hotmail.comSubject: RE: my status on win32 Jay: In the file version.quake, I made the following edit: changed line: local datefn = "../" & TARGET & ".datenow" to: local datefn = ".." & SL & TARGET & ".datenow" This change has the effect of putting a backward slash in the pathname instead of a forward slash, so we getC:\CM3_CVS_SourceTree\m3-sys\cm3\src\..\NT386.datenow So from that perspective, the change seems good. Unfortunately, I still get the error that this file can't be opened. A quick check of C:\CM3_CVS_SourceTree\m3-sys\cm3\NT386 shows that the file .datenow does not exist. Regards, Randy>>> Jay 1/15/2008 11:03 PM >>>That's not too bad really. 1) I'd recommend putting cm3 at the start of the path instead of the end. 2) Just comment out the offending code to make progress. It's not critical. >> C:\CM3_CVS_SourceTree\m3-sys\cm3\src\../NT386.datenow The code is: C:\CM3_CVS_SourceTree\m3-sys\cm3\src\version.quake or such, included by cm3\src\m3makefile. Does the file exist?Does version.quake use "/" or "SL"? If it uses "/", try replacing with SL (and ampersand for string concat). Could be that a newer binary distributions works better with forward slashes. > 4. > 5. > 6. Launch cygwin from desktop icon. Cygwin is only needed for cvs, I think you realize. Could you send me offline the result of just running "set" after running vcvarsall? I'd like to adapt pylib.py to it maybe. (I can start from 5.1.6 and will try 4.1 at some point.) - Jay Date: Tue, 15 Jan 2008 22:52:59 -0500From: rcoleburn at scires.comTo: m3devel at elegosoft.com; jayk123 at hotmail.comSubject: my status on win32 Jay et al: I've listed below the steps I've undertaken to try and build the current sources on Windows XP. I've also attached a text file showing the output I got when trying to build everything using Jay's upgrade.cmd script. Unfortunately, I'm getting a build error (see below). Please advise on how to resolve. STEPS I TOOK: ========= 1. Download Microsoft Visual Studio 2008 Express Edition All-in-One .ISO file and burn to DVD. http://www.microsoft.com/express/download/ 2. Install Microsoft Visual C++ 2008 Express Edition from DVD. 3. Use "Microsoft Update" service to check for updates / service packs. 4. Download cygwin setup program from http://cygwin.com/ 5. Ran cygwin setup.exe program to install cygwin for all users. Under "Devel" category, make certain to select "cvs" for installation. 6. Launch cygwin from desktop icon. 7. In cygwin command shell window, execute following two commands, making sure to give email as password when prompted for login: cvs -d :pserver:anonymous at modula3.elegosoft.com:/usr/cvs login cvs -d :pserver:anonymous at modula3.elegosoft.com:/usr/cvs checkout cm3 8. Moved resulting C:\cygwin\home\rcoleburn\cm3 to C:\CM3_CVS_SourceTree Note that you should replace "rcoleburn" above with your Windows login username. 9. Download cm3-min-WIN32-NT386-d5.5.0.zip and cm3-min-WIN32-NT386-d5.5.0-symbols.zip from http://modula3.elegosoft.com/cm3/download.html 10. Unzipped cm3-min-WIN32-NT386-d5.5.0.zip and stored resulting cm3 folder at C:\cm3 11. Unzipped cm3-min-WIN32-NT386-d5.5.0-symbols.zip and stored resulting symbols folder at C:\cm3\symbols 12. Launch Windows Command Prompt shell. The following steps represent commands executed within this shell. 13. path %path%;c:\cm3\bin 14. "C:\Program Files\Microsoft Visual Studio 9.0\VC\vcvarsall.bat" 15. cd C:\CM3_CVS_SourceTree\scripts\win 16. upgrade.cmd ERROR I'M GETTING: ============= === package C:\CM3_CVS_SourceTree\m3-sys\cm3 ===+++ "cm3 -build -DROOT=C:\\CM3_CVS_SourceTree -DCM3_VERSION_TEXT=d5.5.1 -DCM3_VERSION_NUMBER=050501 -DCM3_LAST_CHANGED=2007-12-30 && cm3 -ship -DROOT=C:\\CM3_CVS_SourceTree -DCM3_VERSION_TEXT=d5.5.1 -DCM3_VERSION_NUMBER=050501 -DCM3_LAST_CHANGED=2007-12-30" +++--- building in NT386 --- ignoring ..\src\m3overrides "C:\CM3_CVS_SourceTree\m3-sys\cm3\src\version.quake", line 136: quake runtime error: unable to open "C:\CM3_CVS_SourceTree\m3-sys\cm3\src\../NT386.datenow" forreading --procedure-- -line- -file---include -- version_impl 136 C:\CM3_CVS_SourceTree\m3-sys\cm3\src\version.quakeinclude_dir 20 C:\CM3_CVS_SourceTree\m3-sys\cm3\src\m3makefile 8 C:\CM3_CVS_SourceTree\m3-sys\cm3\NT386\m3make.args Fatal Error: package build failedERROR: "cm3 -build -DROOT=C:\\CM3_CVS_SourceTree -DCM3_VERSION_TEXT=d5.5.1 -DCM3_VERSION_NUMBER=050501 -DCM3_LAST_CHANGED=2007-12-30 && cm3 -ship -DROOT=C:\\CM3_CVS_SourceTree -DCM3_VERSION_TEXT=d5.5.1 -DCM3_VERSION_NUMBER=050501 -DCM3_LAST_CHANGED=2007-12-30"ERROR: cd C:\CM3_CVS_SourceTree\m3-sys\cm3ERROR: set INSTALLROOT=c:\cm3 Regards, Randy Share life as it happens with the new Windows Live. Start sharing! Put your friends on the big screen with Windows Vista? + Windows LiveT. Start now! Get the power of Windows + Web with the new Windows Live. Get it now! _________________________________________________________________ Make distant family not so distant with Windows Vista? + Windows Live?. http://www.microsoft.com/windows/digitallife/keepintouch.mspx?ocid=TXT_TAGLM_CPC_VideoChat_distantfamily_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Wed Jan 16 21:27:40 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 16 Jan 2008 15:27:40 -0500 Subject: [M3devel] GC question version 2 In-Reply-To: References: Message-ID: This might be possible, but probably would force completion of the current GC to get all the references. Again, not a particularly nice thing to be doing. Once again, why not use indirection and weak references. Probably cheaper, more flexible and portable. On Jan 16, 2008, at 1:28 PM, Darko wrote: > Ok, a slightly different approach: Can the GC give me a list of all > the objects that contain a reference to an object? Would it be > thorough (ie not miss any objects)? False positives might be ok. > Then I could check the type of each object and update the > references myself. It would be reasonable to assume that the > references in question were not being changed by any thread during > the checking process. > > Thanks, > Darko. From darko at darko.org Wed Jan 16 21:52:31 2008 From: darko at darko.org (Darko) Date: Wed, 16 Jan 2008 12:52:31 -0800 Subject: [M3devel] GC question version 2 In-Reply-To: References: Message-ID: <96E7F2FE-D050-4B3C-8918-258FE5CE690F@darko.org> Thanks, I probably will have to use some combination of encapsulation and indirection, but that solution isn't cheaper in terms of memory, which might be a problem in what is an all-allocated data structure (ie, every field value is allocated). I'm basically investigating all possible approaches and not against the solution you've suggested. On 16/01/2008, at 12:27 PM, Tony Hosking wrote: > This might be possible, but probably would force completion of the > current GC to get all the references. Again, not a particularly > nice thing to be doing. Once again, why not use indirection and > weak references. Probably cheaper, more flexible and portable. > > On Jan 16, 2008, at 1:28 PM, Darko wrote: > >> Ok, a slightly different approach: Can the GC give me a list of all >> the objects that contain a reference to an object? Would it be >> thorough (ie not miss any objects)? False positives might be ok. >> Then I could check the type of each object and update the >> references myself. It would be reasonable to assume that the >> references in question were not being changed by any thread during >> the checking process. >> >> Thanks, >> Darko. > From wagner at elegosoft.com Wed Jan 16 21:53:32 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 16 Jan 2008 21:53:32 +0100 Subject: [M3devel] my status on win32 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> <477EA137.1E75.00D7.1@scires.com> <478D394B.1E75.00D7.1@scires.com> <478D47FB.1E75.00D7.1@scires.com> <478DBF8D.1E75.00D7.1@scires.com> Message-ID: <20080116215332.ds4sfixao84g4wk4@mail.elegosoft.com> Quoting Jay : > Yes I agree it is "broken #1" and shouldn't be this way, but I > assure you, really, your results are 99% there. What isn't working > is minor and easy to fix and much is working. Jay, could you please just fix the cm3 package so that it compiles without problems in NT386(GNU), too? It should not be too difficult; there are no problems on the POSIX platforms. As for other installers or installation packages, I'm not against them, it is just that somebody must take responsibility and maintain them and keep them up-to-date. I for sure cannot contribute the efforts needed to maintain different installation variants for different targets. It has been much work to get everything working as it is. I'd be very careful with any changes that might have impacts on the system and installation structures. Everything will have to be tested on every platform afterwards, and my experience says that at least half will break regardless how careful you tried to be. For the integrity of the system itself, the regression test suite we've now setup will be a great help in my opinion. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Jan 16 21:55:51 2008 From: rcoleburn at scires.com (Randy Coleburn) Date: Wed, 16 Jan 2008 15:55:51 -0500 Subject: [M3devel] my status on win32 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> <477EA137.1E75.00D7.1@scires.com> <478D394B.1E75.00D7.1@scires.com> <478D47FB.1E75.00D7.1@scires.com> <478DBF8D.1E75.00D7.1@scires.com> <478DE973.1E75.00D7.1@scires.com> Message-ID: <478E2908.1E75.00D7.1@scires.com> Jay: Thanks for your reply. I think most of your goals seem reasonable and I concur that there are nasty problems introduced by spaces and short names. It's a messy situation that neither you nor I created. I was just relaying some of my prior experience in getting things to work. Indeed, for me, I try to avoid spaces always. That's one reason I root my cm3 at "C:\cm3" instead of in "C:\Program Files\cm3" or "C:\Documents and Settings\userhome\cm3". I've noted that with the various Visual Studio and Visual C tools going back for some time now that after you install it, your environment vars for TEMP and TMP get changed to use short names without spaces, so I guess even Microsoft has trouble with spaces. I also recall in the past with cm3 having trouble if my TEMP and TMP vars included spaces, so having Microsoft switch them to use short names without spaces seemed to solve that cm3 problem at least. As for the VC installation, I too recall that on some prior versions it asked you whether you wanted to set the environment vars permanently or to use vcvars. This time, when I installed Visual Studio 2008, it did not ask this question, so I guess it is version dependant. I'm not at the machine right now where I did the install, but later tonight I'll check to see if the VS2008 install set any permanent environment vars. Again, for me, I would like to be able to build everything as the first step in my series of tests. As soon as you can give me a fix to make things build, I can move on to make more progress. Thanks for your help. Regards, Randy >>> Jay 1/16/2008 2:13 PM >>> Hi Randy. I mostly agree and understand. Go ahead with your installer work. :) #2 is no longer needed. The cm3.cfg I use, that is checked in, that is in the newer distributions, just runs plain "cl" and links to plain "kernel32.dll", and doesn't pass any /I switches to cl => therefore it depends on %PATH%, %LIB%, and %INCLUDE%. As I was saying/rambling, we/I can probably teach cm3 a bit so as to not need vcvars. As I recall, but I need to check, when you install VC, there are some variables it sets unconditionally, and some it asks the user if they should be set. The ones it asks about are PATH, LIB, INCLUDE. The ones it sets unconditionally are the "root" of the install. PATH / LIB / INCLUDE are more invasive, more impactful, have more potential to break things. They are also easily derived from the "root". Similarly, the CM3 installer could ask the user if it is ok to modify their %PATH%, and do it in the registry and set the WM_INI_CHANGED or such message so that Explorer picks it up. Need to check MSDN on this. Forward slashes are fine for options. I take a dim view of these space, quoting, escaping issues. I have very mixed experience here. In SOME situations, your command lines pass through various layers of code, with various attempts to handle or ignore the various issues. The result is in my opinion an unpredictable mess. The problem is that people have confused "an array of strings" with "one flat string". At this point the confusion is widespread and deeply ingrained. On Unix I believe people just ignore the issue by not using spaces (or quotes?) on the command line, though escaping issues still remain for other characters. You just have to read the documenation on CreateProcess to realize how messed up this is. c:\program files\foo I believe is interpreted multiple ways until something works. It can be running c:\program with the parameter files\foo, or it can be running c:\program files\foo. Reliable interprocess communication should not be via command lines but via something more strongly typed such as RPC or shared memory or reading/writing a Pickle. I use the command line a lot, and I frequently copy paths from the command line and paste them into the file open dialog, which does not accept forward slashes nor nested double slashes. It should but oh well. Therefore I have goal before much longer to ensure that every path generated and probably reported by cm3 is in the "normal" form. If the user types in a forward slash, perhaps that should be reported back though. And forward slashes should be ok to enter and then get used internally. The need to configure short file names are gone, along with the need to quote them, by virtue of the dependency on environment variables. Paths with spaces can still come in other ways, but not via SYSTEM_CC in a "normal" cm3, for my newfangled revisionist version of "normal". :) Short names really stink, in so many ways. First, they aren't necessary even shorter, they are just of a limited character set. They can be up to twice as long as "long". Try this: mkdir \1.1.1. dir /x 1* Also, wildcard matching "always" (in FindFirstFile/FindNextFile) operates against both long and short, and since short are unpredcitable, wildcard matching therefore is. An example, probably, is: echo > foo.bar echo > food.barf dir *.bar Will probably, but not necessarily, match both files, though you would only expect one match. As well, I don't believe short file names have always been backed up and restored -- for anyone that uses any backup softwre (not me!). So you determine your short name, you backup and restore, and it changes. Or more clearly, recreating files, might get a different name. It's a mess. I would discourage you from persisting short names ever. Names with spaces I discourage but not as strong. For example, in some contexts, there is just one name and there is no ambiguity. Actually in %PATH% there is no ambiguity because the sepArator is the semicolon. I think Win9x different though, sigh. I agree from my "min" distribution, you need to build the rest. I have to admit, I thought the "culture" on this list was to want to and actually build the system from source. I will put a "std" distribution up on birch this week hopefully and hopefully someone will put it on the web page. Maintaining the installer should not be a problem. As long as the licensing and cost and all is right. I have not fixed the build yet, sorry. - Jay Date: Wed, 16 Jan 2008 11:24:34 -0500 From: rcoleburn at scires.com To: m3devel at elegosoft.com; jayk123 at hotmail.com Subject: Re: [M3devel] my status on win32 Jay: Not sure I've clued in to all of your dialog. Sorry. I have in the past used a free tool to build an installer package and I was thinking of using it again. Since the tool is free, we could put all the work I do into the CVS repository so that others could also maintain it. What I am looking to achieve is to have a way where a "normal" Windows user could download a program, run it, and have all of the cm3 packages installed without having to use the MIN distribution to build it up or any other tools to get the sources (like cvs). You could achieve the same thing by having a big ZIP file also I suppose, but having the installer would also let us easily put something in the start menu to launch a command line with all the environment variables set properly via automatic call to vcvars et al. When I get "Reactor" working, it too could be put into the start menu. That just makes it fit in better with the Windows user culture I think. The reason I wanted to rebuild everything is two-fold: 1) ensure it can be done (i.e., test for "Broken #1"), and 2) get all of the rest of the packages built so I could then use cm3 to build "reactor" and my own programs and test them to see if there are any "Broken #2" issues. The MIN distribution is really insufficient to do much of anything except to build the rest of the packages you need. My understanding is that I needed to use CVS to get the current sources, because if I went back to the source archive, it was old and known to be Broken #1 on Windows. I'm glad that you believe the current "Broken #1" situation is easy to fix. Let me know what to do and I'll give it another try. My experience in the past has been that there are 3 conditions to getting cm3 to work properly on windows after it has been installed: 1) make sure your environment variables are set up by vcvars to point to the compiler/linker/libraries (of course if you used a non-Microsoft C compiler/linker you would need to use something other than vcvars); 2) make sure cm3.cfg has the right paths in place to find all the libraries and tools using DOS style short names (no embedded spaces); and 3) make sure C:\cm3\bin is in your path. Of these, #2 & #3 are essentially one-time events, and #1 can be set up by a invoking a batch/command file via a shortcut, so no big deal for me. You could even make #1 a one-time event by modifying the system-level (vice user-level) environment variables. The old cm3install program seemed to do a decent job of #2 for me. Also, I've noted some of your past dialog about accepting either '/' or '\' as a path separator. I'm sure you are aware that on Windows '/' is used often for switches (arguments). Plus Windows also allows spaces to be embedded in the command line, so whatever solution you propose needs to take into account that a valid command line might look like this: C:\My Program Folder\My Program.exe /myArg1 /myArg2 In some situations, this command line would have to be quoted and rendered as: "C:\My Program Folder\My Program.exe" /myArg1 /myArg2 and in places where the backslash is an escape character, I've seen "C:\\My Program Folder\\My Program.exe" /myArg1 /myArg2 Alas, I seem to have rambled a bit also. Sorry. The immediate need for me now is to solve the Broken #1 condition, so please let me know how to fix it and proceed. Regards, Randy >>> Jay 1/16/2008 10:28 AM >>> Randy, yes and no and clarifications. I mention starting with 5.1.6 as a "worst" or "worse" case. The earlier you start, the harder things are -- for me, to ensure it will work. If you merely start with my 5.5.0, well, what are you rebuilding from source for? Heck, you can use any binary distribution, 4.1, 5.1.6, and just use it. They should work. The n steps you/I give are really actually geared for people who WANT to build from source, it is not what people HAVE to do. As well there have been can be source distributions, to cut out CVS. I'll look into the datefn stuff shortly. As to the installer, well, again, yes and no. The need for the installer is very small. All you have to do today is unzip the .zip somewhere and set the path, and possibly the vcvars thing. That's it. I should..now that you are "pressuring" me for ease of use, teach cm3 about the various ?venvdir%, %vcinstalldir% variables, etc. That way as long as the user installed the tools, even if they elected not to change path/lib/include, cm3 can find the compiler and linker. I know everyone wants to preserve the flexibility of quake/cm3.cfg but...besides, cm3 can be pretty darn smart here. IF cm3.cfg defines SYSTEM_CC, leave things along (NT386 cm3.cfg does not today do that). However if there is now SYSTEM_CC and there is no cl.exe/link.exe in %PATH%, it could go on a quick hunt for them. On the lib and include part, well, the dependency on %include% might only be for errno..maybe not worth it. It has been whatever it is forever, like int* _errno(void); #define errno (*_errno)()). Modula-3 engages in rampant header cloning and CErrnoC was only introduced where that was deemed more fragile than usual, and for Windows it probably wasn't actually fragile -- the fragility, if I may be so rudely judgemental, is because so many other systems are so Johnny-come-lately to arriving at the obviously correct threading model that Windows has had all along (since Win95/NT, can't say anything good about Win3.1; I think OS/2 might have had it correct all along too.). Funny, everyone has FINALLY arrived at the correct threading model, only to have start changing again, since the number of cores and machines is set to be much greater than anticipated, the obvious threading model has been deemed too difficult for anyone to use (Win32, Modula-3, Java, .NET, Python, all the same supposedly too difficult model btw), and so some new one is needed, and well, truthfully, the difficulty is not just for dummies on relatively small multiproc boxes not having simple race conditions, the problem is scaling way way up. Sorry that was my usual tangential. Even the unzip and set path would benefit slightly from a GUI installer. I believe there is some easy thing you can do where you write your GUI installer and you put it in the .zip and then you prepend the GUI self extracting .zip/.exe stub, and you can tell it to run a particular command after the extraction. I guess you might use a fancier thing though? That is, are you going to, say, write a gui installer from scratch in Modula-3? It might be a fun exercise. :) And then you could build the self extracting prefix from source etc. This is the hard way I guess, but more interesing. If you can build an msi or use InstallShield or Wix or something, go ahead. If you use widely availabe free as in beer tools, that can be rolled into whatever automation there is to produce distributions, keeping it up to date shouldn't be a problem. I do have to bring up some annoying questions: 1) Does anyone besides me have the capacity to produce distributions? i.e.: Any Win32 machines left at Elego? 2) I know I ramble. So one of my many tangents/questions went unanswered. Say, in the absence of a gui installer, should .zips/.tar.bz files look like cm3-min-/bin/cm3 or bin/cm3 or cm3/bin/cm3 The last one is more directly usable. The first one is very common. This reminds me though Randy, the distribution I made available was "min", so yeah, like if you are doing any gui programming, using any "standard" library besides m3core or libm3, you'd need to build more from source. I can readily provide you a "std" distribution though. It's "always" been a "problem" to make my files available -- no web site hosting for me -- but recently that wasn't a problem, someone picked the files out of ~jkrell on birch and put them on the web site. Good. One more thing -- Olaf, please confirm repeat yourself, 'cause I admit I wasn't sure it was the right thing, but if you insist, ok. "std" should be "all"? I should not continue to imagine there is a new larger group called "all"? And wherever things are missing from std but do build ok, add them? m3cc should be in std? (I admit some big indecisiveness around m3cc. It is far and away the longest thing to build and so the one you really want to skip the most and leave out of whatever package group. I also wonder if on Windows, there should be some check where if sh is not in the $PATH, just silently skip m3cc? You only need MingWin to build what I have on my system for NT386GNU, except you also need msys just for m3cc. msys is actually quite small, like only 20 files..) Oh, sorry, yet another question. The non-gcc backend is excluded from the build on systems that use the gcc backend. For minimization, that is appropriate. For maximizing cross build capability, it is wrong. The packages build fine. I suspect they work. I am not a user of cross build capability yet, so I don't really care. (What I do for NT386/NT386GNU /might/ be considered sort of a cross build, but it is different/easier). They are small packages. - Jay Date: Wed, 16 Jan 2008 08:25:49 -0500 From: rcoleburn at scires.com To: m3devel at elegosoft.com; jayk123 at hotmail.com Subject: Re: [M3devel] my status on win32 Jay: There is no line in the m3makefile dealing with datefn, so I added the whole statement just before the line include("version.quake") Now, I get an error saying that the variable datefn is not defined. If you change to put quotes around datefn in the include statement, you get an error saying it can't open the file. You made a reference in one of your earlier posts about trying 5.1.6 or 4.1, but note that I started with your cm3-min-WIN32-NT386-d5.5.0.zip , not the 5.1.6 or 4.1 versions. Thus, using d5.5.0 as a base, I am trying to run your "upgrade.cmd" to rebuild the sources I checked out from CVS. Since this doesn't work "out-of-the-box", again I say this fits into the "Broken #1" category. If I can get this to work, I don't mind putting together a Windows installer program that will install the whole thing. That way, folks won't have to install cygwin just to get CVS so that they can install a working cm3. Folks will need to install the free Microsoft Visual C as a prerequisite, but then that's not too bad. Having an installer program would make cm3 more friendly to Windows folks. The current 16-step method is too laborious and error-prone for the person just getting started and they will not give cm3 a second try. As the cm3 system evolves and new releases are made, we will need to keep the installer program up-to-date and I don't mind doing that. After someone gets familiar with cm3 they might want to delve into some of the scripts for rebuilding the system, but until then, I think the installer program is the way to go. Regards, Randy >>> Jay 1/16/2008 1:01 AM >>> I think I see the problem. in cm3\src\m3makefile, make this change > if not defined("NOW") include(datefn) > end datefn is only created if certain other variables aren't defined, and do-pkg defines them. I don't know why I don't see this. Later. Could be that the Python scripts have a typo and don't define them. I've been using them more than cmd. If the host is NT, "NOW" is either gotten from an updated cm3.exe, or left to "not available". So the initial cm3 built from older cm3 can't report when it was built, but cm3 built from current cm3 can. I need to change that: 1) to be a function for niceness 2) to make it that way for Posix, for any host but I haven't been using Posix as much lately so not testing it. - Jay Date: Tue, 15 Jan 2008 23:55:39 -0500 From: rcoleburn at scires.com To: m3devel at elegosoft.com; jayk123 at hotmail.com Subject: RE: my status on win32 Jay: In the file version.quake, I made the following edit: changed line: local datefn = "../" & TARGET & ".datenow" to: local datefn = ".." & SL & TARGET & ".datenow" This change has the effect of putting a backward slash in the pathname instead of a forward slash, so we get C:\CM3_CVS_SourceTree\m3-sys\cm3\src\..\NT386.datenow So from that perspective, the change seems good. Unfortunately, I still get the error that this file can't be opened. A quick check of C:\CM3_CVS_SourceTree\m3-sys\cm3\NT386 shows that the file .datenow does not exist. Regards, Randy >>> Jay 1/15/2008 11:03 PM >>> That's not too bad really. 1) I'd recommend putting cm3 at the start of the path instead of the end. 2) Just comment out the offending code to make progress. It's not critical. >> C:\CM3_CVS_SourceTree\m3-sys\cm3\src\../NT386.datenow The code is: C:\CM3_CVS_SourceTree\m3-sys\cm3\src\version.quake or such, included by cm3\src\m3makefile. Does the file exist? Does version.quake use "/" or "SL"? If it uses "/", try replacing with SL (and ampersand for string concat). Could be that a newer binary distributions works better with forward slashes. > 4. > 5. > 6. Launch cygwin from desktop icon. Cygwin is only needed for cvs, I think you realize. Could you send me offline the result of just running "set" after running vcvarsall? I'd like to adapt pylib.py to it maybe. (I can start from 5.1.6 and will try 4.1 at some point.) - Jay Date: Tue, 15 Jan 2008 22:52:59 -0500 From: rcoleburn at scires.com To: m3devel at elegosoft.com; jayk123 at hotmail.com Subject: my status on win32 Jay et al: I've listed below the steps I've undertaken to try and build the current sources on Windows XP. I've also attached a text file showing the output I got when trying to build everything using Jay's upgrade.cmd script. Unfortunately, I'm getting a build error (see below). Please advise on how to resolve. STEPS I TOOK: ========= 1. Download Microsoft Visual Studio 2008 Express Edition All-in-One .ISO file and burn to DVD. http://www.microsoft.com/express/download/ 2. Install Microsoft Visual C++ 2008 Express Edition from DVD. 3. Use "Microsoft Update" service to check for updates / service packs. 4. Download cygwin setup program from http://cygwin.com/ 5. Ran cygwin setup.exe program to install cygwin for all users. Under "Devel" category, make certain to select "cvs" for installation. 6. Launch cygwin from desktop icon. 7. In cygwin command shell window, execute following two commands, making sure to give email as password when prompted for login: cvs -d :pserver:anonymous at modula3.elegosoft.com:/usr/cvs login cvs -d :pserver:anonymous at modula3.elegosoft.com:/usr/cvs checkout cm3 8. Moved resulting C:\cygwin\home\rcoleburn\cm3 to C:\CM3_CVS_SourceTree Note that you should replace "rcoleburn" above with your Windows login username. 9. Download cm3-min-WIN32-NT386-d5.5.0.zip and cm3-min-WIN32-NT386-d5.5.0-symbols.zip from http://modula3.elegosoft.com/cm3/download.html 10. Unzipped cm3-min-WIN32-NT386-d5.5.0.zip and stored resulting cm3 folder at C:\cm3 11. Unzipped cm3-min-WIN32-NT386-d5.5.0-symbols.zip and stored resulting symbols folder at C:\cm3\symbols 12. Launch Windows Command Prompt shell. The following steps represent commands executed within this shell. 13. path %path%;c:\cm3\bin 14. "C:\Program Files\Microsoft Visual Studio 9.0\VC\vcvarsall.bat" 15. cd C:\CM3_CVS_SourceTree\scripts\win 16. upgrade.cmd ERROR I'M GETTING: ============= === package C:\CM3_CVS_SourceTree\m3-sys\cm3 === +++ "cm3 -build -DROOT=C:\\CM3_CVS_SourceTree -DCM3_VERSION_TEXT=d5.5.1 -DCM3_V ERSION_NUMBER=050501 -DCM3_LAST_CHANGED=2007-12-30 && cm3 -ship -DROOT=C:\\CM3_C VS_SourceTree -DCM3_VERSION_TEXT=d5.5.1 -DCM3_VERSION_NUMBER=050501 -DCM3_LAST_C HANGED=2007-12-30" +++ --- building in NT386 --- ignoring ..\src\m3overrides "C:\CM3_CVS_SourceTree\m3-sys\cm3\src\version.quake", line 136: quake runtime er ror: unable to open "C:\CM3_CVS_SourceTree\m3-sys\cm3\src\../NT386.datenow" for reading --procedure-- -line- -file--- include -- version_impl 136 C:\CM3_CVS_SourceTree\m3-sys\cm3\src\version.quake include_dir 20 C:\CM3_CVS_SourceTree\m3-sys\cm3\src\m3makefile 8 C:\CM3_CVS_SourceTree\m3-sys\cm3\NT386\m3make.args Fatal Error: package build failed ERROR: "cm3 -build -DROOT=C:\\CM3_CVS_SourceTree -DCM3_VERSION_TEXT=d5.5.1 -DCM 3_VERSION_NUMBER=050501 -DCM3_LAST_CHANGED=2007-12-30 && cm3 -ship -DROOT=C:\\CM 3_CVS_SourceTree -DCM3_VERSION_TEXT=d5.5.1 -DCM3_VERSION_NUMBER=050501 -DCM3_LAS T_CHANGED=2007-12-30" ERROR: cd C:\CM3_CVS_SourceTree\m3-sys\cm3 ERROR: set INSTALLROOT=c:\cm3 Regards, Randy Share life as it happens with the new Windows Live. Start sharing! ( http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_012008 ) Put your friends on the big screen with Windows Vista* + Windows LiveT. Start now! ( http://www.microsoft.com/windows/shop/specialoffers.mspx?ocid=TXT_TAGLM_CPC_MediaCtr_bigscreen_012008 ) Get the power of Windows + Web with the new Windows Live. Get it now! ( http://www.windowslive.com/?ocid=TXT_TAGHM_Wave2_powerofwindows_012008 ) Make distant family not so distant with Windows Vista* + Windows Live*. Start now! ( http://www.microsoft.com/windows/digitallife/keepintouch.mspx?ocid=TXT_TAGLM_CPC_VideoChat_distantfamily_012008 ) -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Wed Jan 16 22:42:04 2008 From: jayk123 at hotmail.com (Jay) Date: Wed, 16 Jan 2008 21:42:04 +0000 Subject: [M3devel] my status on win32 In-Reply-To: <478E2908.1E75.00D7.1@scires.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> <477EA137.1E75.00D7.1@scires.com> <478D394B.1E75.00D7.1@scires.com> <478D47FB.1E75.00D7.1@scires.com> <478DBF8D.1E75.00D7.1@scires.com> <478DE973.1E75.00D7.1@scires.com> <478E2908.1E75.00D7.1@scires.com> Message-ID: Regarding temp, I find that cm3 doesn't delete the response files qk, qk_1, etc. so I have modified cm3.cfg/NT386/NT386GNU to write the response files into the output directory, so they will be reliably cleaned up at some point. That /might/ divorce cm3 from all interactions with TEMP/TMP. It was tricky, because mklib demands newlines in the response file, spaces aren't adequate, and arglist doesn't always write a response file, such as for short command lines, and the command lines are nested lists, which don't seem to flatten like the docs say, I could find no way to flatten them. When I get back home I think I'll send all my diffs and hope for one big approval and then submit them. Maybe I'll figure out the NT386GNU runtime crash before that. - Jay Date: Wed, 16 Jan 2008 15:55:51 -0500From: rcoleburn at scires.comTo: m3devel at elegosoft.com; jayk123 at hotmail.comSubject: RE: [M3devel] my status on win32 Jay: Thanks for your reply. I think most of your goals seem reasonable and I concur that there are nasty problems introduced by spaces and short names. It's a messy situation that neither you nor I created. I was just relaying some of my prior experience in getting things to work. Indeed, for me, I try to avoid spaces always. That's one reason I root my cm3 at "C:\cm3" instead of in "C:\Program Files\cm3" or "C:\Documents and Settings\userhome\cm3". I've noted that with the various Visual Studio and Visual C tools going back for some time now that after you install it, your environment vars for TEMP and TMP get changed to use short names without spaces, so I guess even Microsoft has trouble with spaces. I also recall in the past with cm3 having trouble if my TEMP and TMP vars included spaces, so having Microsoft switch them to use short names without spaces seemed to solve that cm3 problem at least. As for the VC installation, I too recall that on some prior versions it asked you whether you wanted to set the environment vars permanently or to use vcvars. This time, when I installed Visual Studio 2008, it did not ask this question, so I guess it is version dependant. I'm not at the machine right now where I did the install, but later tonight I'll check to see if the VS2008 install set any permanent environment vars. Again, for me, I would like to be able to build everything as the first step in my series of tests. As soon as you can give me a fix to make things build, I can move on to make more progress. Thanks for your help. Regards, Randy>>> Jay 1/16/2008 2:13 PM >>>Hi Randy. I mostly agree and understand.Go ahead with your installer work. :) #2 is no longer needed. The cm3.cfg I use, that is checked in, that is in the newer distributions, just runs plain "cl" and links to plain "kernel32.dll", and doesn't pass any /I switches to cl => therefore it depends on %PATH%, %LIB%, and %INCLUDE%. As I was saying/rambling, we/I can probably teach cm3 a bit so as to not need vcvars.As I recall, but I need to check, when you install VC, there are some variables it sets unconditionally, and some it asks the user if they should be set. The ones it asks about are PATH, LIB, INCLUDE. The ones it sets unconditionally are the "root" of the install. PATH / LIB / INCLUDE are more invasive, more impactful, have more potential to break things. They are also easily derived from the "root". Similarly, the CM3 installer could ask the user if it is ok to modify their %PATH%, and do it in the registry and set the WM_INI_CHANGED or such message so that Explorer picks it up. Need to check MSDN on this. Forward slashes are fine for options. I take a dim view of these space, quoting, escaping issues.I have very mixed experience here. In SOME situations, your command lines pass through various layers of code, with various attempts to handle or ignore the various issues. The result is in my opinion an unpredictable mess.The problem is that people have confused "an array of strings" with "one flat string". At this point the confusion is widespread and deeply ingrained. On Unix I believe people just ignore the issue by not using spaces (or quotes?) on the command line, though escaping issues still remain for other characters. You just have to read the documenation on CreateProcess to realize how messed up this is.c:\program files\foo I believe is interpreted multiple ways until something works.It can be running c:\program with the parameter files\foo, or it can be running c:\program files\foo. Reliable interprocess communication should not be via command lines but via something more strongly typed such as RPC or shared memory or reading/writing a Pickle. I use the command line a lot, and I frequently copy paths from the command line and paste them into the file open dialog, which does not accept forward slashes nor nested double slashes. It should but oh well. Therefore I have goal before much longer to ensure that every path generated and probably reported by cm3 is in the "normal" form. If the user types in a forward slash, perhaps that should be reported back though. And forward slashes should be ok to enter and then get used internally. The need to configure short file names are gone, along with the need to quote them, by virtue of the dependency on environment variables. Paths with spaces can still come in other ways, but not via SYSTEM_CC in a "normal" cm3, for my newfangled revisionist version of "normal". :) Short names really stink, in so many ways.First, they aren't necessary even shorter, they are just of a limited character set.They can be up to twice as long as "long".Try this: mkdir \1.1.1. dir /x 1* Also, wildcard matching "always" (in FindFirstFile/FindNextFile) operates against both long and short, and since short are unpredcitable, wildcard matching therefore is. An example, probably, is: echo > foo.barecho > food.barfdir *.bar Will probably, but not necessarily, match both files, though you would only expect one match. As well, I don't believe short file names have always been backed up and restored -- for anyone that uses any backup softwre (not me!). So you determine your short name, you backup and restore, and it changes. Or more clearly, recreating files, might get a different name.It's a mess. I would discourage you from persisting short names ever.Names with spaces I discourage but not as strong.For example, in some contexts, there is just one name and there is no ambiguity.Actually in %PATH% there is no ambiguity because the sepArator is the semicolon.I think Win9x different though, sigh. I agree from my "min" distribution, you need to build the rest.I have to admit, I thought the "culture" on this list was to want to and actually build the system from source.I will put a "std" distribution up on birch this week hopefully and hopefully someone will put it on the web page. Maintaining the installer should not be a problem.As long as the licensing and cost and all is right. I have not fixed the build yet, sorry. - Jay Date: Wed, 16 Jan 2008 11:24:34 -0500From: rcoleburn at scires.comTo: m3devel at elegosoft.com; jayk123 at hotmail.comSubject: Re: [M3devel] my status on win32 Jay: Not sure I've clued in to all of your dialog. Sorry. I have in the past used a free tool to build an installer package and I was thinking of using it again. Since the tool is free, we could put all the work I do into the CVS repository so that others could also maintain it. What I am looking to achieve is to have a way where a "normal" Windows user could download a program, run it, and have all of the cm3 packages installed without having to use the MIN distribution to build it up or any other tools to get the sources (like cvs). You could achieve the same thing by having a big ZIP file also I suppose, but having the installer would also let us easily put something in the start menu to launch a command line with all the environment variables set properly via automatic call to vcvars et al. When I get "Reactor" working, it too could be put into the start menu. That just makes it fit in better with the Windows user culture I think. The reason I wanted to rebuild everything is two-fold: 1) ensure it can be done (i.e., test for "Broken #1"), and 2) get all of the rest of the packages built so I could then use cm3 to build "reactor" and my own programs and test them to see if there are any "Broken #2" issues. The MIN distribution is really insufficient to do much of anything except to build the rest of the packages you need. My understanding is that I needed to use CVS to get the current sources, because if I went back to the source archive, it was old and known to be Broken #1 on Windows. I'm glad that you believe the current "Broken #1" situation is easy to fix. Let me know what to do and I'll give it another try. My experience in the past has been that there are 3 conditions to getting cm3 to work properly on windows after it has been installed: 1) make sure your environment variables are set up by vcvars to point to the compiler/linker/libraries (of course if you used a non-Microsoft C compiler/linker you would need to use something other than vcvars); 2) make sure cm3.cfg has the right paths in place to find all the libraries and tools using DOS style short names (no embedded spaces); and 3) make sure C:\cm3\bin is in your path. Of these, #2 & #3 are essentially one-time events, and #1 can be set up by a invoking a batch/command file via a shortcut, so no big deal for me. You could even make #1 a one-time event by modifying the system-level (vice user-level) environment variables. The old cm3install program seemed to do a decent job of #2 for me. Also, I've noted some of your past dialog about accepting either '/' or '\' as a path separator. I'm sure you are aware that on Windows '/' is used often for switches (arguments). Plus Windows also allows spaces to be embedded in the command line, so whatever solution you propose needs to take into account that a valid command line might look like this: C:\My Program Folder\My Program.exe /myArg1 /myArg2 In some situations, this command line would have to be quoted and rendered as: "C:\My Program Folder\My Program.exe" /myArg1 /myArg2 and in places where the backslash is an escape character, I've seen "C:\\My Program Folder\\My Program.exe" /myArg1 /myArg2 Alas, I seem to have rambled a bit also. Sorry. The immediate need for me now is to solve the Broken #1 condition, so please let me know how to fix it and proceed. Regards, Randy>>> Jay 1/16/2008 10:28 AM >>>Randy, yes and no and clarifications. I mention starting with 5.1.6 as a "worst" or "worse" case.The earlier you start, the harder things are -- for me, to ensure it will work. If you merely start with my 5.5.0, well, what are you rebuilding from source for?Heck, you can use any binary distribution, 4.1, 5.1.6, and just use it. They should work. The n steps you/I give are really actually geared for people who WANT to build from source, it is not what people HAVE to do.As well there have been can be source distributions, to cut out CVS. I'll look into the datefn stuff shortly. As to the installer, well, again, yes and no.The need for the installer is very small. All you have to do today is unzip the .zip somewhere and set the path, and possibly the vcvars thing. That's it. I should..now that you are "pressuring" me for ease of use, teach cm3 about the various ?venvdir%, %vcinstalldir% variables, etc. That way as long as the user installed the tools, even if they elected not to change path/lib/include, cm3 can find the compiler and linker. I know everyone wants to preserve the flexibility of quake/cm3.cfg but...besides, cm3 can be pretty darn smart here. IF cm3.cfg defines SYSTEM_CC, leave things along (NT386 cm3.cfg does not today do that). However if there is now SYSTEM_CC and there is no cl.exe/link.exe in %PATH%, it could go on a quick hunt for them. On the lib and include part, well, the dependency on %include% might only be for errno..maybe not worth it. It has been whatever it is forever, like int* _errno(void); #define errno (*_errno)()). Modula-3 engages in rampant header cloning and CErrnoC was only introduced where that was deemed more fragile than usual, and for Windows it probably wasn't actually fragile -- the fragility, if I may be so rudely judgemental, is because so many other systems are so Johnny-come-lately to arriving at the obviously correct threading model that Windows has had all along (since Win95/NT, can't say anything good about Win3.1; I think OS/2 might have had it correct all along too.). Funny, everyone has FINALLY arrived at the correct threading model, only to have start changing again, since the number of cores and machines is set to be much greater than anticipated, the obvious threading model has been deemed too difficult for anyone to use (Win32, Modula-3, Java, .NET, Python, all the same supposedly too difficult model btw), and so some new one is needed, and well, truthfully, the difficulty is not just for dummies on relatively small multiproc boxes not having simple race conditions, the problem is scaling way way up. Sorry that was my usual tangential. Even the unzip and set path would benefit slightly from a GUI installer.I believe there is some easy thing you can do where you write your GUI installer and you put it in the .zip and then you prepend the GUI self extracting .zip/.exe stub, and you can tell it to run a particular command after the extraction. I guess you might use a fancier thing though?That is, are you going to, say, write a gui installer from scratch in Modula-3? It might be a fun exercise. :)And then you could build the self extracting prefix from source etc.This is the hard way I guess, but more interesing.If you can build an msi or use InstallShield or Wix or something, go ahead.If you use widely availabe free as in beer tools, that can be rolled into whatever automation there is to produce distributions, keeping it up to date shouldn't be a problem. I do have to bring up some annoying questions: 1) Does anyone besides me have the capacity to produce distributions? i.e.: Any Win32 machines left at Elego? 2) I know I ramble. So one of my many tangents/questions went unanswered.Say, in the absence of a gui installer, should .zips/.tar.bz files look like cm3-min-/bin/cm3orbin/cm3orcm3/bin/cm3 The last one is more directly usable. The first one is very common. This reminds me though Randy, the distribution I made available was "min", so yeah, like if you are doing any gui programming, using any "standard" library besides m3core or libm3, you'd need to build more from source. I can readily provide you a "std" distribution though.It's "always" been a "problem" to make my files available -- no web site hosting for me -- but recently that wasn't a problem, someone picked the files out of ~jkrell on birch and put them on the web site. Good. One more thing -- Olaf, please confirm repeat yourself, 'cause I admit I wasn't sure it was the right thing, but if you insist, ok. "std" should be "all"? I should not continue to imagine there is a new larger group called "all"? And wherever things are missing from std but do build ok, add them?m3cc should be in std?(I admit some big indecisiveness around m3cc. It is far and away the longest thing to build and so the one you really want to skip the most and leave out of whatever package group. I also wonder if on Windows, there should be some check where if sh is not in the $PATH, just silently skip m3cc? You only need MingWin to build what I have on my system for NT386GNU, except you also need msys just for m3cc. msys is actually quite small, like only 20 files..) Oh, sorry, yet another question.The non-gcc backend is excluded from the build on systems that use the gcc backend.For minimization, that is appropriate.For maximizing cross build capability, it is wrong.The packages build fine. I suspect they work.I am not a user of cross build capability yet, so I don't really care. (What I do for NT386/NT386GNU /might/ be considered sort of a cross build, but it is different/easier).They are small packages. - Jay Date: Wed, 16 Jan 2008 08:25:49 -0500From: rcoleburn at scires.comTo: m3devel at elegosoft.com; jayk123 at hotmail.comSubject: Re: [M3devel] my status on win32 Jay: There is no line in the m3makefile dealing with datefn, so I added the whole statement just before the line include("version.quake") Now, I get an error saying that the variable datefn is not defined. If you change to put quotes around datefn in the include statement, you get an error saying it can't open the file. You made a reference in one of your earlier posts about trying 5.1.6 or 4.1, but note that I started with your cm3-min-WIN32-NT386-d5.5.0.zip , not the 5.1.6 or 4.1 versions. Thus, using d5.5.0 as a base, I am trying to run your "upgrade.cmd" to rebuild the sources I checked out from CVS. Since this doesn't work "out-of-the-box", again I say this fits into the "Broken #1" category. If I can get this to work, I don't mind putting together a Windows installer program that will install the whole thing. That way, folks won't have to install cygwin just to get CVS so that they can install a working cm3. Folks will need to install the free Microsoft Visual C as a prerequisite, but then that's not too bad. Having an installer program would make cm3 more friendly to Windows folks. The current 16-step method is too laborious and error-prone for the person just getting started and they will not give cm3 a second try. As the cm3 system evolves and new releases are made, we will need to keep the installer program up-to-date and I don't mind doing that. After someone gets familiar with cm3 they might want to delve into some of the scripts for rebuilding the system, but until then, I think the installer program is the way to go. Regards, Randy>>> Jay 1/16/2008 1:01 AM >>>I think I see the problem. in cm3\src\m3makefile, make this change > if not defined("NOW") include(datefn) > end datefn is only created if certain other variables aren't defined, and do-pkg defines them.I don't know why I don't see this. Later.Could be that the Python scripts have a typo and don't define them.I've been using them more than cmd. If the host is NT, "NOW" is either gotten from an updated cm3.exe, or left to "not available". So the initial cm3 built from older cm3 can't report when it was built, but cm3 built from current cm3 can. I need to change that: 1) to be a function for niceness 2) to make it that way for Posix, for any host but I haven't been using Posix as much lately so not testing it. - Jay Date: Tue, 15 Jan 2008 23:55:39 -0500From: rcoleburn at scires.comTo: m3devel at elegosoft.com; jayk123 at hotmail.comSubject: RE: my status on win32 Jay: In the file version.quake, I made the following edit: changed line: local datefn = "../" & TARGET & ".datenow" to: local datefn = ".." & SL & TARGET & ".datenow" This change has the effect of putting a backward slash in the pathname instead of a forward slash, so we getC:\CM3_CVS_SourceTree\m3-sys\cm3\src\..\NT386.datenow So from that perspective, the change seems good. Unfortunately, I still get the error that this file can't be opened. A quick check of C:\CM3_CVS_SourceTree\m3-sys\cm3\NT386 shows that the file .datenow does not exist. Regards, Randy>>> Jay 1/15/2008 11:03 PM >>>That's not too bad really. 1) I'd recommend putting cm3 at the start of the path instead of the end. 2) Just comment out the offending code to make progress. It's not critical. >> C:\CM3_CVS_SourceTree\m3-sys\cm3\src\../NT386.datenow The code is: C:\CM3_CVS_SourceTree\m3-sys\cm3\src\version.quake or such, included by cm3\src\m3makefile. Does the file exist?Does version.quake use "/" or "SL"? If it uses "/", try replacing with SL (and ampersand for string concat). Could be that a newer binary distributions works better with forward slashes. > 4. > 5. > 6. Launch cygwin from desktop icon. Cygwin is only needed for cvs, I think you realize. Could you send me offline the result of just running "set" after running vcvarsall? I'd like to adapt pylib.py to it maybe. (I can start from 5.1.6 and will try 4.1 at some point.) - Jay Date: Tue, 15 Jan 2008 22:52:59 -0500From: rcoleburn at scires.comTo: m3devel at elegosoft.com; jayk123 at hotmail.comSubject: my status on win32 Jay et al: I've listed below the steps I've undertaken to try and build the current sources on Windows XP. I've also attached a text file showing the output I got when trying to build everything using Jay's upgrade.cmd script. Unfortunately, I'm getting a build error (see below). Please advise on how to resolve. STEPS I TOOK: ========= 1. Download Microsoft Visual Studio 2008 Express Edition All-in-One .ISO file and burn to DVD. http://www.microsoft.com/express/download/ 2. Install Microsoft Visual C++ 2008 Express Edition from DVD. 3. Use "Microsoft Update" service to check for updates / service packs. 4. Download cygwin setup program from http://cygwin.com/ 5. Ran cygwin setup.exe program to install cygwin for all users. Under "Devel" category, make certain to select "cvs" for installation. 6. Launch cygwin from desktop icon. 7. In cygwin command shell window, execute following two commands, making sure to give email as password when prompted for login: cvs -d :pserver:anonymous at modula3.elegosoft.com:/usr/cvs login cvs -d :pserver:anonymous at modula3.elegosoft.com:/usr/cvs checkout cm3 8. Moved resulting C:\cygwin\home\rcoleburn\cm3 to C:\CM3_CVS_SourceTree Note that you should replace "rcoleburn" above with your Windows login username. 9. Download cm3-min-WIN32-NT386-d5.5.0.zip and cm3-min-WIN32-NT386-d5.5.0-symbols.zip from http://modula3.elegosoft.com/cm3/download.html 10. Unzipped cm3-min-WIN32-NT386-d5.5.0.zip and stored resulting cm3 folder at C:\cm3 11. Unzipped cm3-min-WIN32-NT386-d5.5.0-symbols.zip and stored resulting symbols folder at C:\cm3\symbols 12. Launch Windows Command Prompt shell. The following steps represent commands executed within this shell. 13. path %path%;c:\cm3\bin 14. "C:\Program Files\Microsoft Visual Studio 9.0\VC\vcvarsall.bat" 15. cd C:\CM3_CVS_SourceTree\scripts\win 16. upgrade.cmd ERROR I'M GETTING: ============= === package C:\CM3_CVS_SourceTree\m3-sys\cm3 ===+++ "cm3 -build -DROOT=C:\\CM3_CVS_SourceTree -DCM3_VERSION_TEXT=d5.5.1 -DCM3_VERSION_NUMBER=050501 -DCM3_LAST_CHANGED=2007-12-30 && cm3 -ship -DROOT=C:\\CM3_CVS_SourceTree -DCM3_VERSION_TEXT=d5.5.1 -DCM3_VERSION_NUMBER=050501 -DCM3_LAST_CHANGED=2007-12-30" +++--- building in NT386 --- ignoring ..\src\m3overrides "C:\CM3_CVS_SourceTree\m3-sys\cm3\src\version.quake", line 136: quake runtime error: unable to open "C:\CM3_CVS_SourceTree\m3-sys\cm3\src\../NT386.datenow" forreading --procedure-- -line- -file---include -- version_impl 136 C:\CM3_CVS_SourceTree\m3-sys\cm3\src\version.quakeinclude_dir 20 C:\CM3_CVS_SourceTree\m3-sys\cm3\src\m3makefile 8 C:\CM3_CVS_SourceTree\m3-sys\cm3\NT386\m3make.args Fatal Error: package build failedERROR: "cm3 -build -DROOT=C:\\CM3_CVS_SourceTree -DCM3_VERSION_TEXT=d5.5.1 -DCM3_VERSION_NUMBER=050501 -DCM3_LAST_CHANGED=2007-12-30 && cm3 -ship -DROOT=C:\\CM3_CVS_SourceTree -DCM3_VERSION_TEXT=d5.5.1 -DCM3_VERSION_NUMBER=050501 -DCM3_LAST_CHANGED=2007-12-30"ERROR: cd C:\CM3_CVS_SourceTree\m3-sys\cm3ERROR: set INSTALLROOT=c:\cm3 Regards, Randy Share life as it happens with the new Windows Live. Start sharing! Put your friends on the big screen with Windows Vista? + Windows LiveT. Start now! Get the power of Windows + Web with the new Windows Live. Get it now! Make distant family not so distant with Windows Vista? + Windows LiveT. Start now! _________________________________________________________________ Put your friends on the big screen with Windows Vista? + Windows Live?. http://www.microsoft.com/windows/shop/specialoffers.mspx?ocid=TXT_TAGLM_CPC_MediaCtr_bigscreen_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Wed Jan 16 22:44:02 2008 From: jayk123 at hotmail.com (Jay) Date: Wed, 16 Jan 2008 21:44:02 +0000 Subject: [M3devel] my status on win32 In-Reply-To: <20080116215332.ds4sfixao84g4wk4@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> <477EA137.1E75.00D7.1@scires.com> <478D394B.1E75.00D7.1@scires.com> <478D47FB.1E75.00D7.1@scires.com> <478DBF8D.1E75.00D7.1@scires.com> <20080116215332.ds4sfixao84g4wk4@mail.elegosoft.com> Message-ID: When I get home I don't fall right to sleep... It's been building fine for me... Which reminds me. Randy, just cd over to m3-sys\cm3 and run either: cm3 or cm3 -DROOT= That might work. More likely the second. The problem is possibly related to "scripts". - Jay > Date: Wed, 16 Jan 2008 21:53:32 +0100> From: wagner at elegosoft.com> To: jayk123 at hotmail.com> CC: rcoleburn at scires.com; m3devel at elegosoft.com; m3-support at elego.de> Subject: Re: [M3devel] my status on win32> > Quoting Jay :> > > Yes I agree it is "broken #1" and shouldn't be this way, but I > > assure you, really, your results are 99% there. What isn't working > > is minor and easy to fix and much is working.> > Jay, could you please just fix the cm3 package so that it compiles> without problems in NT386(GNU), too? It should not be too difficult;> there are no problems on the POSIX platforms.> > As for other installers or installation packages, I'm not against them,> it is just that somebody must take responsibility and maintain them> and keep them up-to-date. I for sure cannot contribute the efforts> needed to maintain different installation variants for different> targets. It has been much work to get everything working as it is.> I'd be very careful with any changes that might have impacts on the> system and installation structures. Everything will have to be tested> on every platform afterwards, and my experience says that at least> half will break regardless how careful you tried to be.> > For the integrity of the system itself, the regression test suite> we've now setup will be a great help in my opinion.> > Olaf> -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194> _________________________________________________________________ Get the power of Windows + Web with the new Windows Live. http://www.windowslive.com?ocid=TXT_TAGHM_Wave2_powerofwindows_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Thu Jan 17 12:35:00 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 17 Jan 2008 12:35:00 +0100 Subject: [M3devel] About permissions on sources in the case of sources with permissions for owner only In-Reply-To: References: <998919.97099.qm@web27103.mail.ukl.yahoo.com> Message-ID: <20080117123500.hdmex004is48wook@mail.elegosoft.com> Late follow-up: Quoting Henning Thielemann : > On Wed, 17 Oct 2007, Daniel Alejandro Benavides D. wrote: > >> I got a commentary about files produced by the compiler and the >> files exported to the repository (ship) >> When compiling a package (bilist present on directory list of >> http://users.informatik.uni-halle.de/~thielema/Research/datastruct.tar.bz2 >> ) that has read and write permissions only for the owner >> I got files in LINUXLIBC6 that are readable for the group and other users. >> But when shipped on the 'src' directory they 're just readable for >> the owner (root). > > This is a general problem, not bound to BiList. > > As a work-around I wrote a script which corrects permissions after the > installation. > > $ more cm3ship > cm3 -ship > (chmod -R a+r /usr/local/cm3/pkg ; chmod a+x `find > /usr/local/cm3/pkg -type d`) & > > However, I do not want to call it 'solution'. This has bothered me several times, too. If the user's umask is set wrong, other's won't be able to change his installations. It can both be seen as a bug or a feature though. Today we leave all the permission settings to the OS. At least on POSIX the builder could set the group bit or just apply its own umask (defined in cm3.cfg). I don't know what to do on Windows, though; and on POSIX systems ACLs are used more and more. What do other's think: do we want to add some support for permissions wrt. team working? Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From lemming at henning-thielemann.de Thu Jan 17 12:38:15 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Thu, 17 Jan 2008 12:38:15 +0100 (MET) Subject: [M3devel] About permissions on sources in the case of sources with permissions for owner only In-Reply-To: <20080117123500.hdmex004is48wook@mail.elegosoft.com> References: <998919.97099.qm@web27103.mail.ukl.yahoo.com> <20080117123500.hdmex004is48wook@mail.elegosoft.com> Message-ID: On Thu, 17 Jan 2008, Olaf Wagner wrote: > Late follow-up: > > Quoting Henning Thielemann : > > On Wed, 17 Oct 2007, Daniel Alejandro Benavides D. wrote: > > > >> I got a commentary about files produced by the compiler and the > >> files exported to the repository (ship) > >> When compiling a package (bilist present on directory list of > >> http://users.informatik.uni-halle.de/~thielema/Research/datastruct.tar.bz2 > >> ) that has read and write permissions only for the owner > >> I got files in LINUXLIBC6 that are readable for the group and other users Is this a problem specific to my datastruct package? From wagner at elegosoft.com Thu Jan 17 13:34:46 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 17 Jan 2008 13:34:46 +0100 Subject: [M3devel] About permissions on sources in the case of sources with permissions for owner only In-Reply-To: References: <998919.97099.qm@web27103.mail.ukl.yahoo.com> <20080117123500.hdmex004is48wook@mail.elegosoft.com> Message-ID: <20080117133446.c0klnluuqs08wc48@mail.elegosoft.com> Quoting Henning Thielemann : > On Thu, 17 Jan 2008, Olaf Wagner wrote: > >> Late follow-up: >> >> Quoting Henning Thielemann : >> > On Wed, 17 Oct 2007, Daniel Alejandro Benavides D. wrote: >> > >> >> I got a commentary about files produced by the compiler and the >> >> files exported to the repository (ship) >> >> When compiling a package (bilist present on directory list of >> >> >> http://users.informatik.uni-halle.de/~thielema/Research/datastruct.tar.bz2 >> >> ) that has read and write permissions only for the owner >> >> I got files in LINUXLIBC6 that are readable for the group and other users > > Is this a problem specific to my datastruct package? No, it's a general problem; I was just following up to an old mail. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Jan 18 16:32:21 2008 From: jayk123 at hotmail.com (Jay) Date: Fri, 18 Jan 2008 15:32:21 +0000 Subject: [M3devel] my status on win32 In-Reply-To: <478DE973.1E75.00D7.1@scires.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> <477EA137.1E75.00D7.1@scires.com> <478D394B.1E75.00D7.1@scires.com> <478D47FB.1E75.00D7.1@scires.com> <478DBF8D.1E75.00D7.1@scires.com> <478DE973.1E75.00D7.1@scires.com> Message-ID: Randy, please try with an updated m3-sys/cm3/src/version.quake and report back, thanks. I understand why I wasn't seeing this. - Jay Date: Wed, 16 Jan 2008 11:24:34 -0500From: rcoleburn at scires.comTo: m3devel at elegosoft.com; jayk123 at hotmail.comSubject: Re: [M3devel] my status on win32 Jay: Not sure I've clued in to all of your dialog. Sorry. I have in the past used a free tool to build an installer package and I was thinking of using it again. Since the tool is free, we could put all the work I do into the CVS repository so that others could also maintain it. What I am looking to achieve is to have a way where a "normal" Windows user could download a program, run it, and have all of the cm3 packages installed without having to use the MIN distribution to build it up or any other tools to get the sources (like cvs). You could achieve the same thing by having a big ZIP file also I suppose, but having the installer would also let us easily put something in the start menu to launch a command line with all the environment variables set properly via automatic call to vcvars et al. When I get "Reactor" working, it too could be put into the start menu. That just makes it fit in better with the Windows user culture I think. The reason I wanted to rebuild everything is two-fold: 1) ensure it can be done (i.e., test for "Broken #1"), and 2) get all of the rest of the packages built so I could then use cm3 to build "reactor" and my own programs and test them to see if there are any "Broken #2" issues. The MIN distribution is really insufficient to do much of anything except to build the rest of the packages you need. My understanding is that I needed to use CVS to get the current sources, because if I went back to the source archive, it was old and known to be Broken #1 on Windows. I'm glad that you believe the current "Broken #1" situation is easy to fix. Let me know what to do and I'll give it another try. My experience in the past has been that there are 3 conditions to getting cm3 to work properly on windows after it has been installed: 1) make sure your environment variables are set up by vcvars to point to the compiler/linker/libraries (of course if you used a non-Microsoft C compiler/linker you would need to use something other than vcvars); 2) make sure cm3.cfg has the right paths in place to find all the libraries and tools using DOS style short names (no embedded spaces); and 3) make sure C:\cm3\bin is in your path. Of these, #2 & #3 are essentially one-time events, and #1 can be set up by a invoking a batch/command file via a shortcut, so no big deal for me. You could even make #1 a one-time event by modifying the system-level (vice user-level) environment variables. The old cm3install program seemed to do a decent job of #2 for me. Also, I've noted some of your past dialog about accepting either '/' or '\' as a path separator. I'm sure you are aware that on Windows '/' is used often for switches (arguments). Plus Windows also allows spaces to be embedded in the command line, so whatever solution you propose needs to take into account that a valid command line might look like this: C:\My Program Folder\My Program.exe /myArg1 /myArg2 In some situations, this command line would have to be quoted and rendered as: "C:\My Program Folder\My Program.exe" /myArg1 /myArg2 and in places where the backslash is an escape character, I've seen "C:\\My Program Folder\\My Program.exe" /myArg1 /myArg2 Alas, I seem to have rambled a bit also. Sorry. The immediate need for me now is to solve the Broken #1 condition, so please let me know how to fix it and proceed. Regards, Randy>>> Jay 1/16/2008 10:28 AM >>>Randy, yes and no and clarifications. I mention starting with 5.1.6 as a "worst" or "worse" case.The earlier you start, the harder things are -- for me, to ensure it will work. If you merely start with my 5.5.0, well, what are you rebuilding from source for?Heck, you can use any binary distribution, 4.1, 5.1.6, and just use it. They should work. The n steps you/I give are really actually geared for people who WANT to build from source, it is not what people HAVE to do.As well there have been can be source distributions, to cut out CVS. I'll look into the datefn stuff shortly. As to the installer, well, again, yes and no.The need for the installer is very small. All you have to do today is unzip the .zip somewhere and set the path, and possibly the vcvars thing. That's it. I should..now that you are "pressuring" me for ease of use, teach cm3 about the various ?venvdir%, %vcinstalldir% variables, etc. That way as long as the user installed the tools, even if they elected not to change path/lib/include, cm3 can find the compiler and linker. I know everyone wants to preserve the flexibility of quake/cm3.cfg but...besides, cm3 can be pretty darn smart here. IF cm3.cfg defines SYSTEM_CC, leave things along (NT386 cm3.cfg does not today do that). However if there is now SYSTEM_CC and there is no cl.exe/link.exe in %PATH%, it could go on a quick hunt for them. On the lib and include part, well, the dependency on %include% might only be for errno..maybe not worth it. It has been whatever it is forever, like int* _errno(void); #define errno (*_errno)()). Modula-3 engages in rampant header cloning and CErrnoC was only introduced where that was deemed more fragile than usual, and for Windows it probably wasn't actually fragile -- the fragility, if I may be so rudely judgemental, is because so many other systems are so Johnny-come-lately to arriving at the obviously correct threading model that Windows has had all along (since Win95/NT, can't say anything good about Win3.1; I think OS/2 might have had it correct all along too.). Funny, everyone has FINALLY arrived at the correct threading model, only to have start changing again, since the number of cores and machines is set to be much greater than anticipated, the obvious threading model has been deemed too difficult for anyone to use (Win32, Modula-3, Java, .NET, Python, all the same supposedly too difficult model btw), and so some new one is needed, and well, truthfully, the difficulty is not just for dummies on relatively small multiproc boxes not having simple race conditions, the problem is scaling way way up. Sorry that was my usual tangential. Even the unzip and set path would benefit slightly from a GUI installer.I believe there is some easy thing you can do where you write your GUI installer and you put it in the .zip and then you prepend the GUI self extracting .zip/.exe stub, and you can tell it to run a particular command after the extraction. I guess you might use a fancier thing though?That is, are you going to, say, write a gui installer from scratch in Modula-3? It might be a fun exercise. :)And then you could build the self extracting prefix from source etc.This is the hard way I guess, but more interesing.If you can build an msi or use InstallShield or Wix or something, go ahead.If you use widely availabe free as in beer tools, that can be rolled into whatever automation there is to produce distributions, keeping it up to date shouldn't be a problem. I do have to bring up some annoying questions: 1) Does anyone besides me have the capacity to produce distributions? i.e.: Any Win32 machines left at Elego? 2) I know I ramble. So one of my many tangents/questions went unanswered.Say, in the absence of a gui installer, should .zips/.tar.bz files look like cm3-min-/bin/cm3orbin/cm3orcm3/bin/cm3 The last one is more directly usable. The first one is very common. This reminds me though Randy, the distribution I made available was "min", so yeah, like if you are doing any gui programming, using any "standard" library besides m3core or libm3, you'd need to build more from source. I can readily provide you a "std" distribution though.It's "always" been a "problem" to make my files available -- no web site hosting for me -- but recently that wasn't a problem, someone picked the files out of ~jkrell on birch and put them on the web site. Good. One more thing -- Olaf, please confirm repeat yourself, 'cause I admit I wasn't sure it was the right thing, but if you insist, ok. "std" should be "all"? I should not continue to imagine there is a new larger group called "all"? And wherever things are missing from std but do build ok, add them?m3cc should be in std?(I admit some big indecisiveness around m3cc. It is far and away the longest thing to build and so the one you really want to skip the most and leave out of whatever package group. I also wonder if on Windows, there should be some check where if sh is not in the $PATH, just silently skip m3cc? You only need MingWin to build what I have on my system for NT386GNU, except you also need msys just for m3cc. msys is actually quite small, like only 20 files..) Oh, sorry, yet another question.The non-gcc backend is excluded from the build on systems that use the gcc backend.For minimization, that is appropriate.For maximizing cross build capability, it is wrong.The packages build fine. I suspect they work.I am not a user of cross build capability yet, so I don't really care. (What I do for NT386/NT386GNU /might/ be considered sort of a cross build, but it is different/easier).They are small packages. - Jay Date: Wed, 16 Jan 2008 08:25:49 -0500From: rcoleburn at scires.comTo: m3devel at elegosoft.com; jayk123 at hotmail.comSubject: Re: [M3devel] my status on win32 Jay: There is no line in the m3makefile dealing with datefn, so I added the whole statement just before the line include("version.quake") Now, I get an error saying that the variable datefn is not defined. If you change to put quotes around datefn in the include statement, you get an error saying it can't open the file. You made a reference in one of your earlier posts about trying 5.1.6 or 4.1, but note that I started with your cm3-min-WIN32-NT386-d5.5.0.zip , not the 5.1.6 or 4.1 versions. Thus, using d5.5.0 as a base, I am trying to run your "upgrade.cmd" to rebuild the sources I checked out from CVS. Since this doesn't work "out-of-the-box", again I say this fits into the "Broken #1" category. If I can get this to work, I don't mind putting together a Windows installer program that will install the whole thing. That way, folks won't have to install cygwin just to get CVS so that they can install a working cm3. Folks will need to install the free Microsoft Visual C as a prerequisite, but then that's not too bad. Having an installer program would make cm3 more friendly to Windows folks. The current 16-step method is too laborious and error-prone for the person just getting started and they will not give cm3 a second try. As the cm3 system evolves and new releases are made, we will need to keep the installer program up-to-date and I don't mind doing that. After someone gets familiar with cm3 they might want to delve into some of the scripts for rebuilding the system, but until then, I think the installer program is the way to go. Regards, Randy>>> Jay 1/16/2008 1:01 AM >>>I think I see the problem. in cm3\src\m3makefile, make this change > if not defined("NOW") include(datefn) > end datefn is only created if certain other variables aren't defined, and do-pkg defines them.I don't know why I don't see this. Later.Could be that the Python scripts have a typo and don't define them.I've been using them more than cmd. If the host is NT, "NOW" is either gotten from an updated cm3.exe, or left to "not available". So the initial cm3 built from older cm3 can't report when it was built, but cm3 built from current cm3 can. I need to change that: 1) to be a function for niceness 2) to make it that way for Posix, for any host but I haven't been using Posix as much lately so not testing it. - Jay Date: Tue, 15 Jan 2008 23:55:39 -0500From: rcoleburn at scires.comTo: m3devel at elegosoft.com; jayk123 at hotmail.comSubject: RE: my status on win32 Jay: In the file version.quake, I made the following edit: changed line: local datefn = "../" & TARGET & ".datenow" to: local datefn = ".." & SL & TARGET & ".datenow" This change has the effect of putting a backward slash in the pathname instead of a forward slash, so we getC:\CM3_CVS_SourceTree\m3-sys\cm3\src\..\NT386.datenow So from that perspective, the change seems good. Unfortunately, I still get the error that this file can't be opened. A quick check of C:\CM3_CVS_SourceTree\m3-sys\cm3\NT386 shows that the file .datenow does not exist. Regards, Randy>>> Jay 1/15/2008 11:03 PM >>>That's not too bad really. 1) I'd recommend putting cm3 at the start of the path instead of the end. 2) Just comment out the offending code to make progress. It's not critical. >> C:\CM3_CVS_SourceTree\m3-sys\cm3\src\../NT386.datenow The code is: C:\CM3_CVS_SourceTree\m3-sys\cm3\src\version.quake or such, included by cm3\src\m3makefile. Does the file exist?Does version.quake use "/" or "SL"? If it uses "/", try replacing with SL (and ampersand for string concat). Could be that a newer binary distributions works better with forward slashes. > 4. > 5. > 6. Launch cygwin from desktop icon. Cygwin is only needed for cvs, I think you realize. Could you send me offline the result of just running "set" after running vcvarsall? I'd like to adapt pylib.py to it maybe. (I can start from 5.1.6 and will try 4.1 at some point.) - Jay Date: Tue, 15 Jan 2008 22:52:59 -0500From: rcoleburn at scires.comTo: m3devel at elegosoft.com; jayk123 at hotmail.comSubject: my status on win32 Jay et al: I've listed below the steps I've undertaken to try and build the current sources on Windows XP. I've also attached a text file showing the output I got when trying to build everything using Jay's upgrade.cmd script. Unfortunately, I'm getting a build error (see below). Please advise on how to resolve. STEPS I TOOK: ========= 1. Download Microsoft Visual Studio 2008 Express Edition All-in-One .ISO file and burn to DVD. http://www.microsoft.com/express/download/ 2. Install Microsoft Visual C++ 2008 Express Edition from DVD. 3. Use "Microsoft Update" service to check for updates / service packs. 4. Download cygwin setup program from http://cygwin.com/ 5. Ran cygwin setup.exe program to install cygwin for all users. Under "Devel" category, make certain to select "cvs" for installation. 6. Launch cygwin from desktop icon. 7. In cygwin command shell window, execute following two commands, making sure to give email as password when prompted for login: cvs -d :pserver:anonymous at modula3.elegosoft.com:/usr/cvs login cvs -d :pserver:anonymous at modula3.elegosoft.com:/usr/cvs checkout cm3 8. Moved resulting C:\cygwin\home\rcoleburn\cm3 to C:\CM3_CVS_SourceTree Note that you should replace "rcoleburn" above with your Windows login username. 9. Download cm3-min-WIN32-NT386-d5.5.0.zip and cm3-min-WIN32-NT386-d5.5.0-symbols.zip from http://modula3.elegosoft.com/cm3/download.html 10. Unzipped cm3-min-WIN32-NT386-d5.5.0.zip and stored resulting cm3 folder at C:\cm3 11. Unzipped cm3-min-WIN32-NT386-d5.5.0-symbols.zip and stored resulting symbols folder at C:\cm3\symbols 12. Launch Windows Command Prompt shell. The following steps represent commands executed within this shell. 13. path %path%;c:\cm3\bin 14. "C:\Program Files\Microsoft Visual Studio 9.0\VC\vcvarsall.bat" 15. cd C:\CM3_CVS_SourceTree\scripts\win 16. upgrade.cmd ERROR I'M GETTING: ============= === package C:\CM3_CVS_SourceTree\m3-sys\cm3 ===+++ "cm3 -build -DROOT=C:\\CM3_CVS_SourceTree -DCM3_VERSION_TEXT=d5.5.1 -DCM3_VERSION_NUMBER=050501 -DCM3_LAST_CHANGED=2007-12-30 && cm3 -ship -DROOT=C:\\CM3_CVS_SourceTree -DCM3_VERSION_TEXT=d5.5.1 -DCM3_VERSION_NUMBER=050501 -DCM3_LAST_CHANGED=2007-12-30" +++--- building in NT386 --- ignoring ..\src\m3overrides "C:\CM3_CVS_SourceTree\m3-sys\cm3\src\version.quake", line 136: quake runtime error: unable to open "C:\CM3_CVS_SourceTree\m3-sys\cm3\src\../NT386.datenow" forreading --procedure-- -line- -file---include -- version_impl 136 C:\CM3_CVS_SourceTree\m3-sys\cm3\src\version.quakeinclude_dir 20 C:\CM3_CVS_SourceTree\m3-sys\cm3\src\m3makefile 8 C:\CM3_CVS_SourceTree\m3-sys\cm3\NT386\m3make.args Fatal Error: package build failedERROR: "cm3 -build -DROOT=C:\\CM3_CVS_SourceTree -DCM3_VERSION_TEXT=d5.5.1 -DCM3_VERSION_NUMBER=050501 -DCM3_LAST_CHANGED=2007-12-30 && cm3 -ship -DROOT=C:\\CM3_CVS_SourceTree -DCM3_VERSION_TEXT=d5.5.1 -DCM3_VERSION_NUMBER=050501 -DCM3_LAST_CHANGED=2007-12-30"ERROR: cd C:\CM3_CVS_SourceTree\m3-sys\cm3ERROR: set INSTALLROOT=c:\cm3 Regards, Randy Share life as it happens with the new Windows Live. Start sharing! Put your friends on the big screen with Windows Vista? + Windows LiveT. Start now! Get the power of Windows + Web with the new 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 rcoleburn at scires.com Fri Jan 18 16:58:36 2008 From: rcoleburn at scires.com (Randy Coleburn) Date: Fri, 18 Jan 2008 10:58:36 -0500 Subject: [M3devel] my status on win32 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> <477EA137.1E75.00D7.1@scires.com> <478D394B.1E75.00D7.1@scires.com> <478D47FB.1E75.00D7.1@scires.com> <478DBF8D.1E75.00D7.1@scires.com> <478DE973.1E75.00D7.1@scires.com> Message-ID: <47908659.1E75.00D7.1@scires.com> Jay: Ok. It will be later tonight before I can try again. Thanks! BTW, can you point me to a document/file somewhere that describes the various options for your windows command file scripts? I did experiment further with using the do-cm3-std.cmd and was finally able to get most everything to build, but of course this doesn't rebuild the compiler and core. Had problems with mentor and m3zume not wanting to build/run, so I commented these out in the cmd file to get it to work. Then I had trouble because everything was built with overrides by default, so I had to mess around with changing parameters and rebuilding clean. I've tried building some of my programs and, of course, have run into a few problems due to changes in the system. I've overcome most of these, but I am seeing some strange behavior: 1. pixmaps aren't rendered properly on the screen. They look really bad. I recall having this problem a while back with one of the early 5.x releases, so I guess it was never solved. I've got some old test programs I try to dig out and see if I can find out what is going on. I seem to recall that building standalone in the past seemed to fix the problem, so this is a real mystery. 2. I'm having trouble with bundles not returning all of the data. In the "reactor" program, bundles are used to provide input to the web browser for the page source. I'm seeing cases where not all of the HTML source is making it to the browser. Not sure if this is an I/O problem (maybe buffers not flushed) or if it is something else. It may be that this problem has some impact on #1 above because pixmaps are sometimes stored in the bundles. For the above #1 and #2, these things worked properly on cm3 v4.1. I have the sources to 4.1, so maybe I can use them to figure out what is wrong. On a side note, I found and fixed a major bug in the "reactor" program, so that is good. Now, for another topic that we should probably move to a new email thread: Back in the early days, my company paid Critical Mass, Inc., to customize the Trestle/FormsVBT look and feel to more closely resemble Windows. I have the sources for this work, but of course it is based on v4.1 and the repository code has moved on since then. I am curious if anyone would be interested in me trying to integrate these customizations back into the current source tree, perhaps on a different branch? If we go this route, I may need a little refresher tutorial on the use of branches in CVS. We would want to make it so that the main branch and the customized branch could evolve in sync. That is, if a bug was found in either branch, the fix should be incorporated into both. Regards, Randy >>> Jay 1/18/2008 10:32 AM >>> Randy, please try with an updated m3-sys/cm3/src/version.quake and report back, thanks. I understand why I wasn't seeing this. - Jay Date: Wed, 16 Jan 2008 11:24:34 -0500 From: rcoleburn at scires.com To: m3devel at elegosoft.com; jayk123 at hotmail.com Subject: Re: [M3devel] my status on win32 Jay: Not sure I've clued in to all of your dialog. Sorry. I have in the past used a free tool to build an installer package and I was thinking of using it again. Since the tool is free, we could put all the work I do into the CVS repository so that others could also maintain it. What I am looking to achieve is to have a way where a "normal" Windows user could download a program, run it, and have all of the cm3 packages installed without having to use the MIN distribution to build it up or any other tools to get the sources (like cvs). You could achieve the same thing by having a big ZIP file also I suppose, but having the installer would also let us easily put something in the start menu to launch a command line with all the environment variables set properly via automatic call to vcvars et al. When I get "Reactor" working, it too could be put into the start menu. That just makes it fit in better with the Windows user culture I think. The reason I wanted to rebuild everything is two-fold: 1) ensure it can be done (i.e., test for "Broken #1"), and 2) get all of the rest of the packages built so I could then use cm3 to build "reactor" and my own programs and test them to see if there are any "Broken #2" issues. The MIN distribution is really insufficient to do much of anything except to build the rest of the packages you need. My understanding is that I needed to use CVS to get the current sources, because if I went back to the source archive, it was old and known to be Broken #1 on Windows. I'm glad that you believe the current "Broken #1" situation is easy to fix. Let me know what to do and I'll give it another try. My experience in the past has been that there are 3 conditions to getting cm3 to work properly on windows after it has been installed: 1) make sure your environment variables are set up by vcvars to point to the compiler/linker/libraries (of course if you used a non-Microsoft C compiler/linker you would need to use something other than vcvars); 2) make sure cm3.cfg has the right paths in place to find all the libraries and tools using DOS style short names (no embedded spaces); and 3) make sure C:\cm3\bin is in your path. Of these, #2 & #3 are essentially one-time events, and #1 can be set up by a invoking a batch/command file via a shortcut, so no big deal for me. You could even make #1 a one-time event by modifying the system-level (vice user-level) environment variables. The old cm3install program seemed to do a decent job of #2 for me. Also, I've noted some of your past dialog about accepting either '/' or '\' as a path separator. I'm sure you are aware that on Windows '/' is used often for switches (arguments). Plus Windows also allows spaces to be embedded in the command line, so whatever solution you propose needs to take into account that a valid command line might look like this: C:\My Program Folder\My Program.exe /myArg1 /myArg2 In some situations, this command line would have to be quoted and rendered as: "C:\My Program Folder\My Program.exe" /myArg1 /myArg2 and in places where the backslash is an escape character, I've seen "C:\\My Program Folder\\My Program.exe" /myArg1 /myArg2 Alas, I seem to have rambled a bit also. Sorry. The immediate need for me now is to solve the Broken #1 condition, so please let me know how to fix it and proceed. Regards, Randy >>> Jay 1/16/2008 10:28 AM >>> Randy, yes and no and clarifications. I mention starting with 5.1.6 as a "worst" or "worse" case. The earlier you start, the harder things are -- for me, to ensure it will work. If you merely start with my 5.5.0, well, what are you rebuilding from source for? Heck, you can use any binary distribution, 4.1, 5.1.6, and just use it. They should work. The n steps you/I give are really actually geared for people who WANT to build from source, it is not what people HAVE to do. As well there have been can be source distributions, to cut out CVS. I'll look into the datefn stuff shortly. As to the installer, well, again, yes and no. The need for the installer is very small. All you have to do today is unzip the .zip somewhere and set the path, and possibly the vcvars thing. That's it. I should..now that you are "pressuring" me for ease of use, teach cm3 about the various ?venvdir%, %vcinstalldir% variables, etc. That way as long as the user installed the tools, even if they elected not to change path/lib/include, cm3 can find the compiler and linker. I know everyone wants to preserve the flexibility of quake/cm3.cfg but...besides, cm3 can be pretty darn smart here. IF cm3.cfg defines SYSTEM_CC, leave things along (NT386 cm3.cfg does not today do that). However if there is now SYSTEM_CC and there is no cl.exe/link.exe in %PATH%, it could go on a quick hunt for them. On the lib and include part, well, the dependency on %include% might only be for errno..maybe not worth it. It has been whatever it is forever, like int* _errno(void); #define errno (*_errno)()). Modula-3 engages in rampant header cloning and CErrnoC was only introduced where that was deemed more fragile than usual, and for Windows it probably wasn't actually fragile -- the fragility, if I may be so rudely judgemental, is because so many other systems are so Johnny-come-lately to arriving at the obviously correct threading model that Windows has had all along (since Win95/NT, can't say anything good about Win3.1; I think OS/2 might have had it correct all along too.). Funny, everyone has FINALLY arrived at the correct threading model, only to have start changing again, since the number of cores and machines is set to be much greater than anticipated, the obvious threading model has been deemed too difficult for anyone to use (Win32, Modula-3, Java, .NET, Python, all the same supposedly too difficult model btw), and so some new one is needed, and well, truthfully, the difficulty is not just for dummies on relatively small multiproc boxes not having simple race conditions, the problem is scaling way way up. Sorry that was my usual tangential. Even the unzip and set path would benefit slightly from a GUI installer. I believe there is some easy thing you can do where you write your GUI installer and you put it in the .zip and then you prepend the GUI self extracting .zip/.exe stub, and you can tell it to run a particular command after the extraction. I guess you might use a fancier thing though? That is, are you going to, say, write a gui installer from scratch in Modula-3? It might be a fun exercise. :) And then you could build the self extracting prefix from source etc. This is the hard way I guess, but more interesing. If you can build an msi or use InstallShield or Wix or something, go ahead. If you use widely availabe free as in beer tools, that can be rolled into whatever automation there is to produce distributions, keeping it up to date shouldn't be a problem. I do have to bring up some annoying questions: 1) Does anyone besides me have the capacity to produce distributions? i.e.: Any Win32 machines left at Elego? 2) I know I ramble. So one of my many tangents/questions went unanswered. Say, in the absence of a gui installer, should .zips/.tar.bz files look like cm3-min-/bin/cm3 or bin/cm3 or cm3/bin/cm3 The last one is more directly usable. The first one is very common. This reminds me though Randy, the distribution I made available was "min", so yeah, like if you are doing any gui programming, using any "standard" library besides m3core or libm3, you'd need to build more from source. I can readily provide you a "std" distribution though. It's "always" been a "problem" to make my files available -- no web site hosting for me -- but recently that wasn't a problem, someone picked the files out of ~jkrell on birch and put them on the web site. Good. One more thing -- Olaf, please confirm repeat yourself, 'cause I admit I wasn't sure it was the right thing, but if you insist, ok. "std" should be "all"? I should not continue to imagine there is a new larger group called "all"? And wherever things are missing from std but do build ok, add them? m3cc should be in std? (I admit some big indecisiveness around m3cc. It is far and away the longest thing to build and so the one you really want to skip the most and leave out of whatever package group. I also wonder if on Windows, there should be some check where if sh is not in the $PATH, just silently skip m3cc? You only need MingWin to build what I have on my system for NT386GNU, except you also need msys just for m3cc. msys is actually quite small, like only 20 files..) Oh, sorry, yet another question. The non-gcc backend is excluded from the build on systems that use the gcc backend. For minimization, that is appropriate. For maximizing cross build capability, it is wrong. The packages build fine. I suspect they work. I am not a user of cross build capability yet, so I don't really care. (What I do for NT386/NT386GNU /might/ be considered sort of a cross build, but it is different/easier). They are small packages. - Jay Date: Wed, 16 Jan 2008 08:25:49 -0500 From: rcoleburn at scires.com To: m3devel at elegosoft.com; jayk123 at hotmail.com Subject: Re: [M3devel] my status on win32 Jay: There is no line in the m3makefile dealing with datefn, so I added the whole statement just before the line include("version.quake") Now, I get an error saying that the variable datefn is not defined. If you change to put quotes around datefn in the include statement, you get an error saying it can't open the file. You made a reference in one of your earlier posts about trying 5.1.6 or 4.1, but note that I started with your cm3-min-WIN32-NT386-d5.5.0.zip , not the 5.1.6 or 4.1 versions. Thus, using d5.5.0 as a base, I am trying to run your "upgrade.cmd" to rebuild the sources I checked out from CVS. Since this doesn't work "out-of-the-box", again I say this fits into the "Broken #1" category. If I can get this to work, I don't mind putting together a Windows installer program that will install the whole thing. That way, folks won't have to install cygwin just to get CVS so that they can install a working cm3. Folks will need to install the free Microsoft Visual C as a prerequisite, but then that's not too bad. Having an installer program would make cm3 more friendly to Windows folks. The current 16-step method is too laborious and error-prone for the person just getting started and they will not give cm3 a second try. As the cm3 system evolves and new releases are made, we will need to keep the installer program up-to-date and I don't mind doing that. After someone gets familiar with cm3 they might want to delve into some of the scripts for rebuilding the system, but until then, I think the installer program is the way to go. Regards, Randy >>> Jay 1/16/2008 1:01 AM >>> I think I see the problem. in cm3\src\m3makefile, make this change > if not defined("NOW") include(datefn) > end datefn is only created if certain other variables aren't defined, and do-pkg defines them. I don't know why I don't see this. Later. Could be that the Python scripts have a typo and don't define them. I've been using them more than cmd. If the host is NT, "NOW" is either gotten from an updated cm3.exe, or left to "not available". So the initial cm3 built from older cm3 can't report when it was built, but cm3 built from current cm3 can. I need to change that: 1) to be a function for niceness 2) to make it that way for Posix, for any host but I haven't been using Posix as much lately so not testing it. - Jay Date: Tue, 15 Jan 2008 23:55:39 -0500 From: rcoleburn at scires.com To: m3devel at elegosoft.com; jayk123 at hotmail.com Subject: RE: my status on win32 Jay: In the file version.quake, I made the following edit: changed line: local datefn = "../" & TARGET & ".datenow" to: local datefn = ".." & SL & TARGET & ".datenow" This change has the effect of putting a backward slash in the pathname instead of a forward slash, so we get C:\CM3_CVS_SourceTree\m3-sys\cm3\src\..\NT386.datenow So from that perspective, the change seems good. Unfortunately, I still get the error that this file can't be opened. A quick check of C:\CM3_CVS_SourceTree\m3-sys\cm3\NT386 shows that the file .datenow does not exist. Regards, Randy >>> Jay 1/15/2008 11:03 PM >>> That's not too bad really. 1) I'd recommend putting cm3 at the start of the path instead of the end. 2) Just comment out the offending code to make progress. It's not critical. >> C:\CM3_CVS_SourceTree\m3-sys\cm3\src\../NT386.datenow The code is: C:\CM3_CVS_SourceTree\m3-sys\cm3\src\version.quake or such, included by cm3\src\m3makefile. Does the file exist? Does version.quake use "/" or "SL"? If it uses "/", try replacing with SL (and ampersand for string concat). Could be that a newer binary distributions works better with forward slashes. > 4. > 5. > 6. Launch cygwin from desktop icon. Cygwin is only needed for cvs, I think you realize. Could you send me offline the result of just running "set" after running vcvarsall? I'd like to adapt pylib.py to it maybe. (I can start from 5.1.6 and will try 4.1 at some point.) - Jay Date: Tue, 15 Jan 2008 22:52:59 -0500 From: rcoleburn at scires.com To: m3devel at elegosoft.com; jayk123 at hotmail.com Subject: my status on win32 Jay et al: I've listed below the steps I've undertaken to try and build the current sources on Windows XP. I've also attached a text file showing the output I got when trying to build everything using Jay's upgrade.cmd script. Unfortunately, I'm getting a build error (see below). Please advise on how to resolve. STEPS I TOOK: ========= 1. Download Microsoft Visual Studio 2008 Express Edition All-in-One .ISO file and burn to DVD. http://www.microsoft.com/express/download/ 2. Install Microsoft Visual C++ 2008 Express Edition from DVD. 3. Use "Microsoft Update" service to check for updates / service packs. 4. Download cygwin setup program from http://cygwin.com/ 5. Ran cygwin setup.exe program to install cygwin for all users. Under "Devel" category, make certain to select "cvs" for installation. 6. Launch cygwin from desktop icon. 7. In cygwin command shell window, execute following two commands, making sure to give email as password when prompted for login: cvs -d :pserver:anonymous at modula3.elegosoft.com:/usr/cvs login cvs -d :pserver:anonymous at modula3.elegosoft.com:/usr/cvs checkout cm3 8. Moved resulting C:\cygwin\home\rcoleburn\cm3 to C:\CM3_CVS_SourceTree Note that you should replace "rcoleburn" above with your Windows login username. 9. Download cm3-min-WIN32-NT386-d5.5.0.zip and cm3-min-WIN32-NT386-d5.5.0-symbols.zip from http://modula3.elegosoft.com/cm3/download.html 10. Unzipped cm3-min-WIN32-NT386-d5.5.0.zip and stored resulting cm3 folder at C:\cm3 11. Unzipped cm3-min-WIN32-NT386-d5.5.0-symbols.zip and stored resulting symbols folder at C:\cm3\symbols 12. Launch Windows Command Prompt shell. The following steps represent commands executed within this shell. 13. path %path%;c:\cm3\bin 14. "C:\Program Files\Microsoft Visual Studio 9.0\VC\vcvarsall.bat" 15. cd C:\CM3_CVS_SourceTree\scripts\win 16. upgrade.cmd ERROR I'M GETTING: ============= === package C:\CM3_CVS_SourceTree\m3-sys\cm3 === +++ "cm3 -build -DROOT=C:\\CM3_CVS_SourceTree -DCM3_VERSION_TEXT=d5.5.1 -DCM3_V ERSION_NUMBER=050501 -DCM3_LAST_CHANGED=2007-12-30 && cm3 -ship -DROOT=C:\\CM3_C VS_SourceTree -DCM3_VERSION_TEXT=d5.5.1 -DCM3_VERSION_NUMBER=050501 -DCM3_LAST_C HANGED=2007-12-30" +++ --- building in NT386 --- ignoring ..\src\m3overrides "C:\CM3_CVS_SourceTree\m3-sys\cm3\src\version.quake", line 136: quake runtime er ror: unable to open "C:\CM3_CVS_SourceTree\m3-sys\cm3\src\../NT386.datenow" for reading --procedure-- -line- -file--- include -- version_impl 136 C:\CM3_CVS_SourceTree\m3-sys\cm3\src\version.quake include_dir 20 C:\CM3_CVS_SourceTree\m3-sys\cm3\src\m3makefile 8 C:\CM3_CVS_SourceTree\m3-sys\cm3\NT386\m3make.args Fatal Error: package build failed ERROR: "cm3 -build -DROOT=C:\\CM3_CVS_SourceTree -DCM3_VERSION_TEXT=d5.5.1 -DCM 3_VERSION_NUMBER=050501 -DCM3_LAST_CHANGED=2007-12-30 && cm3 -ship -DROOT=C:\\CM 3_CVS_SourceTree -DCM3_VERSION_TEXT=d5.5.1 -DCM3_VERSION_NUMBER=050501 -DCM3_LAS T_CHANGED=2007-12-30" ERROR: cd C:\CM3_CVS_SourceTree\m3-sys\cm3 ERROR: set INSTALLROOT=c:\cm3 Regards, Randy Share life as it happens with the new Windows Live. Start sharing! ( http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_012008 ) Put your friends on the big screen with Windows Vista* + Windows LiveT. Start now! ( http://www.microsoft.com/windows/shop/specialoffers.mspx?ocid=TXT_TAGLM_CPC_MediaCtr_bigscreen_012008 ) Get the power of Windows + Web with the new Windows Live. Get it now! ( http://www.windowslive.com/?ocid=TXT_TAGHM_Wave2_powerofwindows_012008 ) 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 ) -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcoleburn at scires.com Fri Jan 18 17:10:38 2008 From: rcoleburn at scires.com (Randy Coleburn) Date: Fri, 18 Jan 2008 11:10:38 -0500 Subject: [M3devel] new name for "reactor" Message-ID: <4790892B.1E75.00D7.1@scires.com> I thought I should ask for input from the community before finalizing the new name for "reactor." One of the conditions imposed on making the "reactor" source available is that I have to rename the product and remove all trademarked references. Originally, I chose the name "CM3-IDE" for CM3 Integrated Development Environment, but this name isn't very catchy. I thought about possibly using the name "Catalyst" since a catalyst is something used to accelerate a process and "reactor" certainly fits this definition. A brief search on the web turned up a some other uses of the name, but we may not have a problem if we don't try to trademark the name, or perhaps we could differentiate by calling it "CM3-Catalyst" or "M3-Catalyst". For those that don't know, "reactor" uses a web browser to present its interface. It allows you to quickly browse through all of your source code, create new packages, build and run programs, invoke your favorite editor, run tutorials, browse documentation, etc., etc. With the advent of tabbed browsing, it really makes it nice to understand what is going on when examining your code and when writing code it makes it easy to look up interface definitions etc. If anyone has suggestions on the name to use, please let me know. I'd like to finalize the name within the next few days so I can finalize the code for submission to the repository. Regards, Randy Coleburn -------------- next part -------------- An HTML attachment was scrubbed... URL: From lemming at henning-thielemann.de Fri Jan 18 17:50:42 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Fri, 18 Jan 2008 17:50:42 +0100 (MET) Subject: [M3devel] new name for "reactor" In-Reply-To: <4790892B.1E75.00D7.1@scires.com> References: <4790892B.1E75.00D7.1@scires.com> Message-ID: On Fri, 18 Jan 2008, Randy Coleburn wrote: > I thought about possibly using the name "Catalyst" since a catalyst is > something used to accelerate a process and "reactor" certainly fits this > definition. A brief search on the web turned up a some other uses of > the name, but we may not have a problem if we don't try to trademark the > name, or perhaps we could differentiate by calling it "CM3-Catalyst" or > "M3-Catalyst". I like the name. From jayk123 at hotmail.com Fri Jan 18 22:50:23 2008 From: jayk123 at hotmail.com (Jay) Date: Fri, 18 Jan 2008 21:50:23 +0000 Subject: [M3devel] my status on win32 In-Reply-To: <47908659.1E75.00D7.1@scires.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> <477EA137.1E75.00D7.1@scires.com> <478D394B.1E75.00D7.1@scires.com> <478D47FB.1E75.00D7.1@scires.com> <478DBF8D.1E75.00D7.1@scires.com> <478DE973.1E75.00D7.1@scires.com> <47908659.1E75.00D7.1@scires.com> Message-ID: I'll see about adding usage statements. Basically all the do* scripts accept a "command" and a list of packages. The commands are: realclean clean -- pretty useless imho buildlocal -- the default ship buildship -- build and shpi buildglobal The .sh and .py have a usage explaining this but .cmd is missing it, probably because I didn't fully understand at the time the functionality of the code I was blindy porting. do-* except for do-pkg have an implied list of packages. Maybe you can add to it, would have to check the source. do-pkg requires a list. Most of the rest are not meant to be user-callable -- sysinfo, pkginfo, pkgcmds. make-dist its its own thing. Oh, right -- environment variables. Many things are overridable with them, and need documentation the same. What do folks think of deleting all of scripts\win and having only scripts\python? I guess you have to try them out first, at least.Scripts\python achieves parity pretty much, except for the more logging to files, less logging to the console, that win\make-dist has. Furthermore, out on a limb, what do folks think of deleting most of scripts\*.sh and having just Python? I doubt this will fly and I will try resist mentioning it often. :) In the interest of consensus here, though I doubt it will help, I'd be open to rewriting python in Perl, or possiby even Tcl. I am also willing/interested in discussing the merits of these languages, or an as yet undeveloped one "ideal language" (Modula-3 I don't think is it, sorry), but probably most people will find it a waste of time. Where is the geek-out-really-badly mailing list? :) - Jay Date: Fri, 18 Jan 2008 10:58:36 -0500From: rcoleburn at scires.comTo: m3devel at elegosoft.com; jayk123 at hotmail.comSubject: Re: [M3devel] my status on win32 Jay: Ok. It will be later tonight before I can try again. Thanks! BTW, can you point me to a document/file somewhere that describes the various options for your windows command file scripts? I did experiment further with using the do-cm3-std.cmd and was finally able to get most everything to build, but of course this doesn't rebuild the compiler and core. Had problems with mentor and m3zume not wanting to build/run, so I commented these out in the cmd file to get it to work. Then I had trouble because everything was built with overrides by default, so I had to mess around with changing parameters and rebuilding clean. I've tried building some of my programs and, of course, have run into a few problems due to changes in the system. I've overcome most of these, but I am seeing some strange behavior: 1. pixmaps aren't rendered properly on the screen. They look really bad. I recall having this problem a while back with one of the early 5.x releases, so I guess it was never solved. I've got some old test programs I try to dig out and see if I can find out what is going on. I seem to recall that building standalone in the past seemed to fix the problem, so this is a real mystery. 2. I'm having trouble with bundles not returning all of the data. In the "reactor" program, bundles are used to provide input to the web browser for the page source. I'm seeing cases where not all of the HTML source is making it to the browser. Not sure if this is an I/O problem (maybe buffers not flushed) or if it is something else. It may be that this problem has some impact on #1 above because pixmaps are sometimes stored in the bundles. For the above #1 and #2, these things worked properly on cm3 v4.1. I have the sources to 4.1, so maybe I can use them to figure out what is wrong. On a side note, I found and fixed a major bug in the "reactor" program, so that is good. Now, for another topic that we should probably move to a new email thread: Back in the early days, my company paid Critical Mass, Inc., to customize the Trestle/FormsVBT look and feel to more closely resemble Windows. I have the sources for this work, but of course it is based on v4.1 and the repository code has moved on since then. I am curious if anyone would be interested in me trying to integrate these customizations back into the current source tree, perhaps on a different branch? If we go this route, I may need a little refresher tutorial on the use of branches in CVS. We would want to make it so that the main branch and the customized branch could evolve in sync. That is, if a bug was found in either branch, the fix should be incorporated into both. Regards, Randy>>> Jay 1/18/2008 10:32 AM >>>Randy, please try with an updated m3-sys/cm3/src/version.quake and report back, thanks.I understand why I wasn't seeing this. - Jay Date: Wed, 16 Jan 2008 11:24:34 -0500From: rcoleburn at scires.comTo: m3devel at elegosoft.com; jayk123 at hotmail.comSubject: Re: [M3devel] my status on win32 Jay: Not sure I've clued in to all of your dialog. Sorry. I have in the past used a free tool to build an installer package and I was thinking of using it again. Since the tool is free, we could put all the work I do into the CVS repository so that others could also maintain it. What I am looking to achieve is to have a way where a "normal" Windows user could download a program, run it, and have all of the cm3 packages installed without having to use the MIN distribution to build it up or any other tools to get the sources (like cvs). You could achieve the same thing by having a big ZIP file also I suppose, but having the installer would also let us easily put something in the start menu to launch a command line with all the environment variables set properly via automatic call to vcvars et al. When I get "Reactor" working, it too could be put into the start menu. That just makes it fit in better with the Windows user culture I think. The reason I wanted to rebuild everything is two-fold: 1) ensure it can be done (i.e., test for "Broken #1"), and 2) get all of the rest of the packages built so I could then use cm3 to build "reactor" and my own programs and test them to see if there are any "Broken #2" issues. The MIN distribution is really insufficient to do much of anything except to build the rest of the packages you need. My understanding is that I needed to use CVS to get the current sources, because if I went back to the source archive, it was old and known to be Broken #1 on Windows. I'm glad that you believe the current "Broken #1" situation is easy to fix. Let me know what to do and I'll give it another try. My experience in the past has been that there are 3 conditions to getting cm3 to work properly on windows after it has been installed: 1) make sure your environment variables are set up by vcvars to point to the compiler/linker/libraries (of course if you used a non-Microsoft C compiler/linker you would need to use something other than vcvars); 2) make sure cm3.cfg has the right paths in place to find all the libraries and tools using DOS style short names (no embedded spaces); and 3) make sure C:\cm3\bin is in your path. Of these, #2 & #3 are essentially one-time events, and #1 can be set up by a invoking a batch/command file via a shortcut, so no big deal for me. You could even make #1 a one-time event by modifying the system-level (vice user-level) environment variables. The old cm3install program seemed to do a decent job of #2 for me. Also, I've noted some of your past dialog about accepting either '/' or '\' as a path separator. I'm sure you are aware that on Windows '/' is used often for switches (arguments). Plus Windows also allows spaces to be embedded in the command line, so whatever solution you propose needs to take into account that a valid command line might look like this: C:\My Program Folder\My Program.exe /myArg1 /myArg2 In some situations, this command line would have to be quoted and rendered as: "C:\My Program Folder\My Program.exe" /myArg1 /myArg2 and in places where the backslash is an escape character, I've seen "C:\\My Program Folder\\My Program.exe" /myArg1 /myArg2 Alas, I seem to have rambled a bit also. Sorry. The immediate need for me now is to solve the Broken #1 condition, so please let me know how to fix it and proceed. Regards, Randy>>> Jay 1/16/2008 10:28 AM >>>Randy, yes and no and clarifications. I mention starting with 5.1.6 as a "worst" or "worse" case.The earlier you start, the harder things are -- for me, to ensure it will work. If you merely start with my 5.5.0, well, what are you rebuilding from source for?Heck, you can use any binary distribution, 4.1, 5.1.6, and just use it. They should work. The n steps you/I give are really actually geared for people who WANT to build from source, it is not what people HAVE to do.As well there have been can be source distributions, to cut out CVS. I'll look into the datefn stuff shortly. As to the installer, well, again, yes and no.The need for the installer is very small. All you have to do today is unzip the .zip somewhere and set the path, and possibly the vcvars thing. That's it. I should..now that you are "pressuring" me for ease of use, teach cm3 about the various ?venvdir%, %vcinstalldir% variables, etc. That way as long as the user installed the tools, even if they elected not to change path/lib/include, cm3 can find the compiler and linker. I know everyone wants to preserve the flexibility of quake/cm3.cfg but...besides, cm3 can be pretty darn smart here. IF cm3.cfg defines SYSTEM_CC, leave things along (NT386 cm3.cfg does not today do that). However if there is now SYSTEM_CC and there is no cl.exe/link.exe in %PATH%, it could go on a quick hunt for them. On the lib and include part, well, the dependency on %include% might only be for errno..maybe not worth it. It has been whatever it is forever, like int* _errno(void); #define errno (*_errno)()). Modula-3 engages in rampant header cloning and CErrnoC was only introduced where that was deemed more fragile than usual, and for Windows it probably wasn't actually fragile -- the fragility, if I may be so rudely judgemental, is because so many other systems are so Johnny-come-lately to arriving at the obviously correct threading model that Windows has had all along (since Win95/NT, can't say anything good about Win3.1; I think OS/2 might have had it correct all along too.). Funny, everyone has FINALLY arrived at the correct threading model, only to have start changing again, since the number of cores and machines is set to be much greater than anticipated, the obvious threading model has been deemed too difficult for anyone to use (Win32, Modula-3, Java, .NET, Python, all the same supposedly too difficult model btw), and so some new one is needed, and well, truthfully, the difficulty is not just for dummies on relatively small multiproc boxes not having simple race conditions, the problem is scaling way way up. Sorry that was my usual tangential. Even the unzip and set path would benefit slightly from a GUI installer.I believe there is some easy thing you can do where you write your GUI installer and you put it in the .zip and then you prepend the GUI self extracting .zip/.exe stub, and you can tell it to run a particular command after the extraction. I guess you might use a fancier thing though?That is, are you going to, say, write a gui installer from scratch in Modula-3? It might be a fun exercise. :)And then you could build the self extracting prefix from source etc.This is the hard way I guess, but more interesing.If you can build an msi or use InstallShield or Wix or something, go ahead.If you use widely availabe free as in beer tools, that can be rolled into whatever automation there is to produce distributions, keeping it up to date shouldn't be a problem. I do have to bring up some annoying questions: 1) Does anyone besides me have the capacity to produce distributions? i.e.: Any Win32 machines left at Elego? 2) I know I ramble. So one of my many tangents/questions went unanswered.Say, in the absence of a gui installer, should .zips/.tar.bz files look like cm3-min-/bin/cm3orbin/cm3orcm3/bin/cm3 The last one is more directly usable. The first one is very common. This reminds me though Randy, the distribution I made available was "min", so yeah, like if you are doing any gui programming, using any "standard" library besides m3core or libm3, you'd need to build more from source. I can readily provide you a "std" distribution though.It's "always" been a "problem" to make my files available -- no web site hosting for me -- but recently that wasn't a problem, someone picked the files out of ~jkrell on birch and put them on the web site. Good. One more thing -- Olaf, please confirm repeat yourself, 'cause I admit I wasn't sure it was the right thing, but if you insist, ok. "std" should be "all"? I should not continue to imagine there is a new larger group called "all"? And wherever things are missing from std but do build ok, add them?m3cc should be in std?(I admit some big indecisiveness around m3cc. It is far and away the longest thing to build and so the one you really want to skip the most and leave out of whatever package group. I also wonder if on Windows, there should be some check where if sh is not in the $PATH, just silently skip m3cc? You only need MingWin to build what I have on my system for NT386GNU, except you also need msys just for m3cc. msys is actually quite small, like only 20 files..) Oh, sorry, yet another question.The non-gcc backend is excluded from the build on systems that use the gcc backend.For minimization, that is appropriate.For maximizing cross build capability, it is wrong.The packages build fine. I suspect they work.I am not a user of cross build capability yet, so I don't really care. (What I do for NT386/NT386GNU /might/ be considered sort of a cross build, but it is different/easier).They are small packages. - Jay Date: Wed, 16 Jan 2008 08:25:49 -0500From: rcoleburn at scires.comTo: m3devel at elegosoft.com; jayk123 at hotmail.comSubject: Re: [M3devel] my status on win32 Jay: There is no line in the m3makefile dealing with datefn, so I added the whole statement just before the line include("version.quake") Now, I get an error saying that the variable datefn is not defined. If you change to put quotes around datefn in the include statement, you get an error saying it can't open the file. You made a reference in one of your earlier posts about trying 5.1.6 or 4.1, but note that I started with your cm3-min-WIN32-NT386-d5.5.0.zip , not the 5.1.6 or 4.1 versions. Thus, using d5.5.0 as a base, I am trying to run your "upgrade.cmd" to rebuild the sources I checked out from CVS. Since this doesn't work "out-of-the-box", again I say this fits into the "Broken #1" category. If I can get this to work, I don't mind putting together a Windows installer program that will install the whole thing. That way, folks won't have to install cygwin just to get CVS so that they can install a working cm3. Folks will need to install the free Microsoft Visual C as a prerequisite, but then that's not too bad. Having an installer program would make cm3 more friendly to Windows folks. The current 16-step method is too laborious and error-prone for the person just getting started and they will not give cm3 a second try. As the cm3 system evolves and new releases are made, we will need to keep the installer program up-to-date and I don't mind doing that. After someone gets familiar with cm3 they might want to delve into some of the scripts for rebuilding the system, but until then, I think the installer program is the way to go. Regards, Randy>>> Jay 1/16/2008 1:01 AM >>>I think I see the problem. in cm3\src\m3makefile, make this change > if not defined("NOW") include(datefn) > end datefn is only created if certain other variables aren't defined, and do-pkg defines them.I don't know why I don't see this. Later.Could be that the Python scripts have a typo and don't define them.I've been using them more than cmd. If the host is NT, "NOW" is either gotten from an updated cm3.exe, or left to "not available". So the initial cm3 built from older cm3 can't report when it was built, but cm3 built from current cm3 can. I need to change that: 1) to be a function for niceness 2) to make it that way for Posix, for any host but I haven't been using Posix as much lately so not testing it. - Jay Date: Tue, 15 Jan 2008 23:55:39 -0500From: rcoleburn at scires.comTo: m3devel at elegosoft.com; jayk123 at hotmail.comSubject: RE: my status on win32 Jay: In the file version.quake, I made the following edit: changed line: local datefn = "../" & TARGET & ".datenow" to: local datefn = ".." & SL & TARGET & ".datenow" This change has the effect of putting a backward slash in the pathname instead of a forward slash, so we getC:\CM3_CVS_SourceTree\m3-sys\cm3\src\..\NT386.datenow So from that perspective, the change seems good. Unfortunately, I still get the error that this file can't be opened. A quick check of C:\CM3_CVS_SourceTree\m3-sys\cm3\NT386 shows that the file .datenow does not exist. Regards, Randy>>> Jay 1/15/2008 11:03 PM >>>That's not too bad really. 1) I'd recommend putting cm3 at the start of the path instead of the end. 2) Just comment out the offending code to make progress. It's not critical. >> C:\CM3_CVS_SourceTree\m3-sys\cm3\src\../NT386.datenow The code is: C:\CM3_CVS_SourceTree\m3-sys\cm3\src\version.quake or such, included by cm3\src\m3makefile. Does the file exist?Does version.quake use "/" or "SL"? If it uses "/", try replacing with SL (and ampersand for string concat). Could be that a newer binary distributions works better with forward slashes. > 4. > 5. > 6. Launch cygwin from desktop icon. Cygwin is only needed for cvs, I think you realize. Could you send me offline the result of just running "set" after running vcvarsall? I'd like to adapt pylib.py to it maybe. (I can start from 5.1.6 and will try 4.1 at some point.) - Jay Date: Tue, 15 Jan 2008 22:52:59 -0500From: rcoleburn at scires.comTo: m3devel at elegosoft.com; jayk123 at hotmail.comSubject: my status on win32 Jay et al: I've listed below the steps I've undertaken to try and build the current sources on Windows XP. I've also attached a text file showing the output I got when trying to build everything using Jay's upgrade.cmd script. Unfortunately, I'm getting a build error (see below). Please advise on how to resolve. STEPS I TOOK: ========= 1. Download Microsoft Visual Studio 2008 Express Edition All-in-One .ISO file and burn to DVD. http://www.microsoft.com/express/download/ 2. Install Microsoft Visual C++ 2008 Express Edition from DVD. 3. Use "Microsoft Update" service to check for updates / service packs. 4. Download cygwin setup program from http://cygwin.com/ 5. Ran cygwin setup.exe program to install cygwin for all users. Under "Devel" category, make certain to select "cvs" for installation. 6. Launch cygwin from desktop icon. 7. In cygwin command shell window, execute following two commands, making sure to give email as password when prompted for login: cvs -d :pserver:anonymous at modula3.elegosoft.com:/usr/cvs login cvs -d :pserver:anonymous at modula3.elegosoft.com:/usr/cvs checkout cm3 8. Moved resulting C:\cygwin\home\rcoleburn\cm3 to C:\CM3_CVS_SourceTree Note that you should replace "rcoleburn" above with your Windows login username. 9. Download cm3-min-WIN32-NT386-d5.5.0.zip and cm3-min-WIN32-NT386-d5.5.0-symbols.zip from http://modula3.elegosoft.com/cm3/download.html 10. Unzipped cm3-min-WIN32-NT386-d5.5.0.zip and stored resulting cm3 folder at C:\cm3 11. Unzipped cm3-min-WIN32-NT386-d5.5.0-symbols.zip and stored resulting symbols folder at C:\cm3\symbols 12. Launch Windows Command Prompt shell. The following steps represent commands executed within this shell. 13. path %path%;c:\cm3\bin 14. "C:\Program Files\Microsoft Visual Studio 9.0\VC\vcvarsall.bat" 15. cd C:\CM3_CVS_SourceTree\scripts\win 16. upgrade.cmd ERROR I'M GETTING: ============= === package C:\CM3_CVS_SourceTree\m3-sys\cm3 ===+++ "cm3 -build -DROOT=C:\\CM3_CVS_SourceTree -DCM3_VERSION_TEXT=d5.5.1 -DCM3_VERSION_NUMBER=050501 -DCM3_LAST_CHANGED=2007-12-30 && cm3 -ship -DROOT=C:\\CM3_CVS_SourceTree -DCM3_VERSION_TEXT=d5.5.1 -DCM3_VERSION_NUMBER=050501 -DCM3_LAST_CHANGED=2007-12-30" +++--- building in NT386 --- ignoring ..\src\m3overrides "C:\CM3_CVS_SourceTree\m3-sys\cm3\src\version.quake", line 136: quake runtime error: unable to open "C:\CM3_CVS_SourceTree\m3-sys\cm3\src\../NT386.datenow" forreading --procedure-- -line- -file---include -- version_impl 136 C:\CM3_CVS_SourceTree\m3-sys\cm3\src\version.quakeinclude_dir 20 C:\CM3_CVS_SourceTree\m3-sys\cm3\src\m3makefile 8 C:\CM3_CVS_SourceTree\m3-sys\cm3\NT386\m3make.args Fatal Error: package build failedERROR: "cm3 -build -DROOT=C:\\CM3_CVS_SourceTree -DCM3_VERSION_TEXT=d5.5.1 -DCM3_VERSION_NUMBER=050501 -DCM3_LAST_CHANGED=2007-12-30 && cm3 -ship -DROOT=C:\\CM3_CVS_SourceTree -DCM3_VERSION_TEXT=d5.5.1 -DCM3_VERSION_NUMBER=050501 -DCM3_LAST_CHANGED=2007-12-30"ERROR: cd C:\CM3_CVS_SourceTree\m3-sys\cm3ERROR: set INSTALLROOT=c:\cm3 Regards, Randy Share life as it happens with the new Windows Live. Start sharing! Put your friends on the big screen with Windows Vista? + Windows LiveT. Start now! Get the power of Windows + Web with the new Windows Live. Get it now! 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 jayk123 at hotmail.com Fri Jan 18 23:28:14 2008 From: jayk123 at hotmail.com (Jay) Date: Fri, 18 Jan 2008 22:28:14 +0000 Subject: [M3devel] incremental build always rebuilds cm3, never produces the same thing -- what time is "now"? In-Reply-To: <47908659.1E75.00D7.1@scires.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> <477EA137.1E75.00D7.1@scires.com> <478D394B.1E75.00D7.1@scires.com> <478D47FB.1E75.00D7.1@scires.com> <478DBF8D.1E75.00D7.1@scires.com> <478DE973.1E75.00D7.1@scires.com> <47908659.1E75.00D7.1@scires.com> Message-ID: In m3-sys\cm3, incremental build always rebuilds cm3, never produces the same thing. I know exactly why. My modification to Olaf's timestamping (which I think he approved, but perhaps didn't realize this outcome). Because we generate a source file with the current time, and it always changes. Is this ok with people?I know it has downsides, but it might be ok. You know: 1) incremental build should really never do anything, never writing anything, fast which is important -- never write, or be fast? both? 2) You might want to compare two full builds and determine they are identical; the less of this sort of thing the better If not, what do people suggest for a way to determine when to update the time? The logic before I think was essentially never, unless you went and deleted a specific file. Perhaps that is right, once it is discovered and publicized. Perhaps another output directory is needed -- say / -- that upgrade and make-dist, perhaps, know to delete, and maybe realclean...of cm3? deletes? Hey, maybe just declare an output, with "..", in the m3makefile, so merely clean and realclean update the time, but incremental builds do not? This seems obviously the way to go right now, but still slightly debatable. Like, maybe an accurate timestamp is needed. Maybe if any other source or .lib changes, the timestamp should change -- so, like, m3_back/m3_link could regenerate the file, except that might be too late. Should "now" be less granular than a second? That mitigates the problem but i think is not satisfactory.Should "now" be overridable on the command line or with an environment variable? - 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 Fri Jan 18 23:42:26 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 18 Jan 2008 23:42:26 +0100 Subject: [M3devel] my status on win32 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> <477EA137.1E75.00D7.1@scires.com> <478D394B.1E75.00D7.1@scires.com> <478D47FB.1E75.00D7.1@scires.com> <478DBF8D.1E75.00D7.1@scires.com> <478DE973.1E75.00D7.1@scires.com> <47908659.1E75.00D7.1@scires.com> Message-ID: <20080118234226.8g4fi0mkgwgscwww@mail.elegosoft.com> Quoting Jay : > I'll see about adding usage statements. > Basically all the do* scripts accept a "command" and a list of packages. > The commands are: > realclean > clean -- pretty useless imho > buildlocal -- the default > ship > buildship -- build and shpi > buildglobal Actually, the more useful commands are build -- build with overrides to ROOT buildship (same as buildglobal) -- build with global package pool realclean -- completely delete derived target files > do-pkg requires a list. If you're doing you're own project, this may be what is most useful -- if you use the scripts at all. > What do folks think of deleting all of scripts\win and having only > scripts\python? > I guess you have to try them out first, at least.Scripts\python > achieves parity pretty much, except for the more logging to files, > less logging to the console, that win\make-dist has. > > Furthermore, out on a limb, what do folks think of deleting most of > scripts\*.sh and having just Python? I'd object to this. Shell is POSIX standard, and most of the infrastructure is built on it; Python is nice to have, but should not be a prerequisite to CM3. > I doubt this will fly and I will try resist mentioning it often. :) > In the interest of consensus here, though I doubt it will help, I'd > be open to rewriting python in Perl, or possiby even Tcl. Why? > I am also willing/interested in discussing the merits of these > languages, or an as yet undeveloped one "ideal language" (Modula-3 I > don't think is it, sorry), but probably most people will find it a > waste of time. Where is the geek-out-really-badly mailing list? :) I don't see the point in rewriting the scripts in yet other languages. The purpose of the scripts is to support the installation, administration and maintenance of the CM3 distribution. They were not intended as a general purpose build or automation environment, though they can be used for this purpose to a certain extent. But the main point is that they are useful for the people maintaining the distribution. We could think about rewriting everything in M3 to further reduce the system dependencies, but this would not be as flexible as a general scripting language. Quake would need to be substantially extended, and Python is nice, but a huge software distribution in itself, that should be independent of CM3. POSIX shell is the one common interpreter I have found to be available on almost all systems. (Even when we were programming point-of-sale solutions on DOS in the early 90s we had ksh and other POSIX tools there to emulate the Sun development environment we used on the servers.) OK, on Windows you have to install it (e.g. in form of Cygwin) like Python, but it's still the best choice wrt. availability and portability I've found. For general discussions of the advantages and disadvantage of programming languages, some of the comp.lang.* newsgroups may be the better choice, though I haven't read them for years now and don't know if they're still alive. As for the ideal language -- I don't think that there is any language that could claim this. The advantages and disadvantages depend heavily on the usage context, environment, and skills and understanding of the programmers. (M3 is pretty good 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 rcoleburn at scires.com Fri Jan 18 23:53:45 2008 From: rcoleburn at scires.com (Randy Coleburn) Date: Fri, 18 Jan 2008 17:53:45 -0500 Subject: [M3devel] my status on win32 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> <477EA137.1E75.00D7.1@scires.com> <478D394B.1E75.00D7.1@scires.com> <478D47FB.1E75.00D7.1@scires.com> <478DBF8D.1E75.00D7.1@scires.com> <478DE973.1E75.00D7.1@scires.com> <47908659.1E75.00D7.1@scires.com> Message-ID: <4790E7A7.1E75.00D7.1@scires.com> Jay: What does "buildglobal" mean? How is it different from "buildship"? As far as "scripts" go, I'm an old guy that started out with computers that had real core memory. When the IBM PC revolution hit, I was already a professional and had mastered large computers with network operating systems and even micro-computers with CP/M. I learned DOS and became a good "BAT" batch file programmer (we didn't call them scripting languages back then). I'm still pretty good with Windows CMD files, but have not tackled python. My vote for cm3 on Windows is to avoid making the end user (customer) have to learn or acquire things that aren't native to his environment. Thus, I would argue for use of CMD files on Windows instead of some other scripting language. This same reasoning is why I was pushing for the all-in-one installation program for cm3 on Windows. If all a "Windows person" has to do to get cm3 modula-3 up and running on his box is to run an install program and possibly tweak a few CMD scripts to his/her liking, then it is "easy". Forcing acquisition and installation of other tools/environments just to get started makes things complicated and increases the barrier to startup and acceptance. Just my 2 cents worth. A few years ago, I contributed some BAT/CMD files that could be used to build the entire system on Windows. The only issue is that as the system evolves, you have to keep the package build order up to date. I don't mind trying to help out further in this area. You seem to be very technically capable, so perhaps what I can offer pales in comparison. Thanks for all you are doing. Let me know if/how I can help. Regards, Randy >>> Jay 1/18/2008 4:50 PM >>> I'll see about adding usage statements. Basically all the do* scripts accept a "command" and a list of packages. The commands are: realclean clean -- pretty useless imho buildlocal -- the default ship buildship -- build and shpi buildglobal The .sh and .py have a usage explaining this but .cmd is missing it, probably because I didn't fully understand at the time the functionality of the code I was blindy porting. do-* except for do-pkg have an implied list of packages. Maybe you can add to it, would have to check the source. do-pkg requires a list. Most of the rest are not meant to be user-callable -- sysinfo, pkginfo, pkgcmds. make-dist its its own thing. Oh, right -- environment variables. Many things are overridable with them, and need documentation the same. What do folks think of deleting all of scripts\win and having only scripts\python? I guess you have to try them out first, at least. Scripts\python achieves parity pretty much, except for the more logging to files, less logging to the console, that win\make-dist has. Furthermore, out on a limb, what do folks think of deleting most of scripts\*.sh and having just Python? I doubt this will fly and I will try resist mentioning it often. :) In the interest of consensus here, though I doubt it will help, I'd be open to rewriting python in Perl, or possiby even Tcl. I am also willing/interested in discussing the merits of these languages, or an as yet undeveloped one "ideal language" (Modula-3 I don't think is it, sorry), but probably most people will find it a waste of time. Where is the geek-out-really-badly mailing list? :) - Jay Date: Fri, 18 Jan 2008 10:58:36 -0500 From: rcoleburn at scires.com To: m3devel at elegosoft.com; jayk123 at hotmail.com Subject: Re: [M3devel] my status on win32 Jay: Ok. It will be later tonight before I can try again. Thanks! BTW, can you point me to a document/file somewhere that describes the various options for your windows command file scripts? I did experiment further with using the do-cm3-std.cmd and was finally able to get most everything to build, but of course this doesn't rebuild the compiler and core. Had problems with mentor and m3zume not wanting to build/run, so I commented these out in the cmd file to get it to work. Then I had trouble because everything was built with overrides by default, so I had to mess around with changing parameters and rebuilding clean. I've tried building some of my programs and, of course, have run into a few problems due to changes in the system. I've overcome most of these, but I am seeing some strange behavior: 1. pixmaps aren't rendered properly on the screen. They look really bad. I recall having this problem a while back with one of the early 5.x releases, so I guess it was never solved. I've got some old test programs I try to dig out and see if I can find out what is going on. I seem to recall that building standalone in the past seemed to fix the problem, so this is a real mystery. 2. I'm having trouble with bundles not returning all of the data. In the "reactor" program, bundles are used to provide input to the web browser for the page source. I'm seeing cases where not all of the HTML source is making it to the browser. Not sure if this is an I/O problem (maybe buffers not flushed) or if it is something else. It may be that this problem has some impact on #1 above because pixmaps are sometimes stored in the bundles. For the above #1 and #2, these things worked properly on cm3 v4.1. I have the sources to 4.1, so maybe I can use them to figure out what is wrong. On a side note, I found and fixed a major bug in the "reactor" program, so that is good. Now, for another topic that we should probably move to a new email thread: Back in the early days, my company paid Critical Mass, Inc., to customize the Trestle/FormsVBT look and feel to more closely resemble Windows. I have the sources for this work, but of course it is based on v4.1 and the repository code has moved on since then. I am curious if anyone would be interested in me trying to integrate these customizations back into the current source tree, perhaps on a different branch? If we go this route, I may need a little refresher tutorial on the use of branches in CVS. We would want to make it so that the main branch and the customized branch could evolve in sync. That is, if a bug was found in either branch, the fix should be incorporated into both. Regards, Randy >>> Jay 1/18/2008 10:32 AM >>> Randy, please try with an updated m3-sys/cm3/src/version.quake and report back, thanks. I understand why I wasn't seeing this. - Jay Date: Wed, 16 Jan 2008 11:24:34 -0500 From: rcoleburn at scires.com To: m3devel at elegosoft.com; jayk123 at hotmail.com Subject: Re: [M3devel] my status on win32 Jay: Not sure I've clued in to all of your dialog. Sorry. I have in the past used a free tool to build an installer package and I was thinking of using it again. Since the tool is free, we could put all the work I do into the CVS repository so that others could also maintain it. What I am looking to achieve is to have a way where a "normal" Windows user could download a program, run it, and have all of the cm3 packages installed without having to use the MIN distribution to build it up or any other tools to get the sources (like cvs). You could achieve the same thing by having a big ZIP file also I suppose, but having the installer would also let us easily put something in the start menu to launch a command line with all the environment variables set properly via automatic call to vcvars et al. When I get "Reactor" working, it too could be put into the start menu. That just makes it fit in better with the Windows user culture I think. The reason I wanted to rebuild everything is two-fold: 1) ensure it can be done (i.e., test for "Broken #1"), and 2) get all of the rest of the packages built so I could then use cm3 to build "reactor" and my own programs and test them to see if there are any "Broken #2" issues. The MIN distribution is really insufficient to do much of anything except to build the rest of the packages you need. My understanding is that I needed to use CVS to get the current sources, because if I went back to the source archive, it was old and known to be Broken #1 on Windows. I'm glad that you believe the current "Broken #1" situation is easy to fix. Let me know what to do and I'll give it another try. My experience in the past has been that there are 3 conditions to getting cm3 to work properly on windows after it has been installed: 1) make sure your environment variables are set up by vcvars to point to the compiler/linker/libraries (of course if you used a non-Microsoft C compiler/linker you would need to use something other than vcvars); 2) make sure cm3.cfg has the right paths in place to find all the libraries and tools using DOS style short names (no embedded spaces); and 3) make sure C:\cm3\bin is in your path. Of these, #2 & #3 are essentially one-time events, and #1 can be set up by a invoking a batch/command file via a shortcut, so no big deal for me. You could even make #1 a one-time event by modifying the system-level (vice user-level) environment variables. The old cm3install program seemed to do a decent job of #2 for me. Also, I've noted some of your past dialog about accepting either '/' or '\' as a path separator. I'm sure you are aware that on Windows '/' is used often for switches (arguments). Plus Windows also allows spaces to be embedded in the command line, so whatever solution you propose needs to take into account that a valid command line might look like this: C:\My Program Folder\My Program.exe /myArg1 /myArg2 In some situations, this command line would have to be quoted and rendered as: "C:\My Program Folder\My Program.exe" /myArg1 /myArg2 and in places where the backslash is an escape character, I've seen "C:\\My Program Folder\\My Program.exe" /myArg1 /myArg2 Alas, I seem to have rambled a bit also. Sorry. The immediate need for me now is to solve the Broken #1 condition, so please let me know how to fix it and proceed. Regards, Randy >>> Jay 1/16/2008 10:28 AM >>> Randy, yes and no and clarifications. I mention starting with 5.1.6 as a "worst" or "worse" case. The earlier you start, the harder things are -- for me, to ensure it will work. If you merely start with my 5.5.0, well, what are you rebuilding from source for? Heck, you can use any binary distribution, 4.1, 5.1.6, and just use it. They should work. The n steps you/I give are really actually geared for people who WANT to build from source, it is not what people HAVE to do. As well there have been can be source distributions, to cut out CVS. I'll look into the datefn stuff shortly. As to the installer, well, again, yes and no. The need for the installer is very small. All you have to do today is unzip the .zip somewhere and set the path, and possibly the vcvars thing. That's it. I should..now that you are "pressuring" me for ease of use, teach cm3 about the various ?venvdir%, %vcinstalldir% variables, etc. That way as long as the user installed the tools, even if they elected not to change path/lib/include, cm3 can find the compiler and linker. I know everyone wants to preserve the flexibility of quake/cm3.cfg but...besides, cm3 can be pretty darn smart here. IF cm3.cfg defines SYSTEM_CC, leave things along (NT386 cm3.cfg does not today do that). However if there is now SYSTEM_CC and there is no cl.exe/link.exe in %PATH%, it could go on a quick hunt for them. On the lib and include part, well, the dependency on %include% might only be for errno..maybe not worth it. It has been whatever it is forever, like int* _errno(void); #define errno (*_errno)()). Modula-3 engages in rampant header cloning and CErrnoC was only introduced where that was deemed more fragile than usual, and for Windows it probably wasn't actually fragile -- the fragility, if I may be so rudely judgemental, is because so many other systems are so Johnny-come-lately to arriving at the obviously correct threading model that Windows has had all along (since Win95/NT, can't say anything good about Win3.1; I think OS/2 might have had it correct all along too.). Funny, everyone has FINALLY arrived at the correct threading model, only to have start changing again, since the number of cores and machines is set to be much greater than anticipated, the obvious threading model has been deemed too difficult for anyone to use (Win32, Modula-3, Java, .NET, Python, all the same supposedly too difficult model btw), and so some new one is needed, and well, truthfully, the difficulty is not just for dummies on relatively small multiproc boxes not having simple race conditions, the problem is scaling way way up. Sorry that was my usual tangential. Even the unzip and set path would benefit slightly from a GUI installer. I believe there is some easy thing you can do where you write your GUI installer and you put it in the .zip and then you prepend the GUI self extracting .zip/.exe stub, and you can tell it to run a particular command after the extraction. I guess you might use a fancier thing though? That is, are you going to, say, write a gui installer from scratch in Modula-3? It might be a fun exercise. :) And then you could build the self extracting prefix from source etc. This is the hard way I guess, but more interesing. If you can build an msi or use InstallShield or Wix or something, go ahead. If you use widely availabe free as in beer tools, that can be rolled into whatever automation there is to produce distributions, keeping it up to date shouldn't be a problem. I do have to bring up some annoying questions: 1) Does anyone besides me have the capacity to produce distributions? i.e.: Any Win32 machines left at Elego? 2) I know I ramble. So one of my many tangents/questions went unanswered. Say, in the absence of a gui installer, should .zips/.tar.bz files look like cm3-min-/bin/cm3 or bin/cm3 or cm3/bin/cm3 The last one is more directly usable. The first one is very common. This reminds me though Randy, the distribution I made available was "min", so yeah, like if you are doing any gui programming, using any "standard" library besides m3core or libm3, you'd need to build more from source. I can readily provide you a "std" distribution though. It's "always" been a "problem" to make my files available -- no web site hosting for me -- but recently that wasn't a problem, someone picked the files out of ~jkrell on birch and put them on the web site. Good. One more thing -- Olaf, please confirm repeat yourself, 'cause I admit I wasn't sure it was the right thing, but if you insist, ok. "std" should be "all"? I should not continue to imagine there is a new larger group called "all"? And wherever things are missing from std but do build ok, add them? m3cc should be in std? (I admit some big indecisiveness around m3cc. It is far and away the longest thing to build and so the one you really want to skip the most and leave out of whatever package group. I also wonder if on Windows, there should be some check where if sh is not in the $PATH, just silently skip m3cc? You only need MingWin to build what I have on my system for NT386GNU, except you also need msys just for m3cc. msys is actually quite small, like only 20 files..) Oh, sorry, yet another question. The non-gcc backend is excluded from the build on systems that use the gcc backend. For minimization, that is appropriate. For maximizing cross build capability, it is wrong. The packages build fine. I suspect they work. I am not a user of cross build capability yet, so I don't really care. (What I do for NT386/NT386GNU /might/ be considered sort of a cross build, but it is different/easier). They are small packages. - Jay Date: Wed, 16 Jan 2008 08:25:49 -0500 From: rcoleburn at scires.com To: m3devel at elegosoft.com; jayk123 at hotmail.com Subject: Re: [M3devel] my status on win32 Jay: There is no line in the m3makefile dealing with datefn, so I added the whole statement just before the line include("version.quake") Now, I get an error saying that the variable datefn is not defined. If you change to put quotes around datefn in the include statement, you get an error saying it can't open the file. You made a reference in one of your earlier posts about trying 5.1.6 or 4.1, but note that I started with your cm3-min-WIN32-NT386-d5.5.0.zip , not the 5.1.6 or 4.1 versions. Thus, using d5.5.0 as a base, I am trying to run your "upgrade.cmd" to rebuild the sources I checked out from CVS. Since this doesn't work "out-of-the-box", again I say this fits into the "Broken #1" category. If I can get this to work, I don't mind putting together a Windows installer program that will install the whole thing. That way, folks won't have to install cygwin just to get CVS so that they can install a working cm3. Folks will need to install the free Microsoft Visual C as a prerequisite, but then that's not too bad. Having an installer program would make cm3 more friendly to Windows folks. The current 16-step method is too laborious and error-prone for the person just getting started and they will not give cm3 a second try. As the cm3 system evolves and new releases are made, we will need to keep the installer program up-to-date and I don't mind doing that. After someone gets familiar with cm3 they might want to delve into some of the scripts for rebuilding the system, but until then, I think the installer program is the way to go. Regards, Randy >>> Jay 1/16/2008 1:01 AM >>> I think I see the problem. in cm3\src\m3makefile, make this change > if not defined("NOW") include(datefn) > end datefn is only created if certain other variables aren't defined, and do-pkg defines them. I don't know why I don't see this. Later. Could be that the Python scripts have a typo and don't define them. I've been using them more than cmd. If the host is NT, "NOW" is either gotten from an updated cm3.exe, or left to "not available". So the initial cm3 built from older cm3 can't report when it was built, but cm3 built from current cm3 can. I need to change that: 1) to be a function for niceness 2) to make it that way for Posix, for any host but I haven't been using Posix as much lately so not testing it. - Jay Date: Tue, 15 Jan 2008 23:55:39 -0500 From: rcoleburn at scires.com To: m3devel at elegosoft.com; jayk123 at hotmail.com Subject: RE: my status on win32 Jay: In the file version.quake, I made the following edit: changed line: local datefn = "../" & TARGET & ".datenow" to: local datefn = ".." & SL & TARGET & ".datenow" This change has the effect of putting a backward slash in the pathname instead of a forward slash, so we get C:\CM3_CVS_SourceTree\m3-sys\cm3\src\..\NT386.datenow So from that perspective, the change seems good. Unfortunately, I still get the error that this file can't be opened. A quick check of C:\CM3_CVS_SourceTree\m3-sys\cm3\NT386 shows that the file .datenow does not exist. Regards, Randy >>> Jay 1/15/2008 11:03 PM >>> That's not too bad really. 1) I'd recommend putting cm3 at the start of the path instead of the end. 2) Just comment out the offending code to make progress. It's not critical. >> C:\CM3_CVS_SourceTree\m3-sys\cm3\src\../NT386.datenow The code is: C:\CM3_CVS_SourceTree\m3-sys\cm3\src\version.quake or such, included by cm3\src\m3makefile. Does the file exist? Does version.quake use "/" or "SL"? If it uses "/", try replacing with SL (and ampersand for string concat). Could be that a newer binary distributions works better with forward slashes. > 4. > 5. > 6. Launch cygwin from desktop icon. Cygwin is only needed for cvs, I think you realize. Could you send me offline the result of just running "set" after running vcvarsall? I'd like to adapt pylib.py to it maybe. (I can start from 5.1.6 and will try 4.1 at some point.) - Jay Date: Tue, 15 Jan 2008 22:52:59 -0500 From: rcoleburn at scires.com To: m3devel at elegosoft.com; jayk123 at hotmail.com Subject: my status on win32 Jay et al: I've listed below the steps I've undertaken to try and build the current sources on Windows XP. I've also attached a text file showing the output I got when trying to build everything using Jay's upgrade.cmd script. Unfortunately, I'm getting a build error (see below). Please advise on how to resolve. STEPS I TOOK: ========= 1. Download Microsoft Visual Studio 2008 Express Edition All-in-One .ISO file and burn to DVD. http://www.microsoft.com/express/download/ 2. Install Microsoft Visual C++ 2008 Express Edition from DVD. 3. Use "Microsoft Update" service to check for updates / service packs. 4. Download cygwin setup program from http://cygwin.com/ 5. Ran cygwin setup.exe program to install cygwin for all users. Under "Devel" category, make certain to select "cvs" for installation. 6. Launch cygwin from desktop icon. 7. In cygwin command shell window, execute following two commands, making sure to give email as password when prompted for login: cvs -d :pserver:anonymous at modula3.elegosoft.com:/usr/cvs login cvs -d :pserver:anonymous at modula3.elegosoft.com:/usr/cvs checkout cm3 8. Moved resulting C:\cygwin\home\rcoleburn\cm3 to C:\CM3_CVS_SourceTree Note that you should replace "rcoleburn" above with your Windows login username. 9. Download cm3-min-WIN32-NT386-d5.5.0.zip and cm3-min-WIN32-NT386-d5.5.0-symbols.zip from http://modula3.elegosoft.com/cm3/download.html 10. Unzipped cm3-min-WIN32-NT386-d5.5.0.zip and stored resulting cm3 folder at C:\cm3 11. Unzipped cm3-min-WIN32-NT386-d5.5.0-symbols.zip and stored resulting symbols folder at C:\cm3\symbols 12. Launch Windows Command Prompt shell. The following steps represent commands executed within this shell. 13. path %path%;c:\cm3\bin 14. "C:\Program Files\Microsoft Visual Studio 9.0\VC\vcvarsall.bat" 15. cd C:\CM3_CVS_SourceTree\scripts\win 16. upgrade.cmd ERROR I'M GETTING: ============= === package C:\CM3_CVS_SourceTree\m3-sys\cm3 === +++ "cm3 -build -DROOT=C:\\CM3_CVS_SourceTree -DCM3_VERSION_TEXT=d5.5.1 -DCM3_V ERSION_NUMBER=050501 -DCM3_LAST_CHANGED=2007-12-30 && cm3 -ship -DROOT=C:\\CM3_C VS_SourceTree -DCM3_VERSION_TEXT=d5.5.1 -DCM3_VERSION_NUMBER=050501 -DCM3_LAST_C HANGED=2007-12-30" +++ --- building in NT386 --- ignoring ..\src\m3overrides "C:\CM3_CVS_SourceTree\m3-sys\cm3\src\version.quake", line 136: quake runtime er ror: unable to open "C:\CM3_CVS_SourceTree\m3-sys\cm3\src\../NT386.datenow" for reading --procedure-- -line- -file--- include -- version_impl 136 C:\CM3_CVS_SourceTree\m3-sys\cm3\src\version.quake include_dir 20 C:\CM3_CVS_SourceTree\m3-sys\cm3\src\m3makefile 8 C:\CM3_CVS_SourceTree\m3-sys\cm3\NT386\m3make.args Fatal Error: package build failed ERROR: "cm3 -build -DROOT=C:\\CM3_CVS_SourceTree -DCM3_VERSION_TEXT=d5.5.1 -DCM 3_VERSION_NUMBER=050501 -DCM3_LAST_CHANGED=2007-12-30 && cm3 -ship -DROOT=C:\\CM 3_CVS_SourceTree -DCM3_VERSION_TEXT=d5.5.1 -DCM3_VERSION_NUMBER=050501 -DCM3_LAS T_CHANGED=2007-12-30" ERROR: cd C:\CM3_CVS_SourceTree\m3-sys\cm3 ERROR: set INSTALLROOT=c:\cm3 Regards, Randy Share life as it happens with the new Windows Live. Start sharing! ( http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_012008 ) Put your friends on the big screen with Windows Vista* + Windows LiveT. Start now! ( http://www.microsoft.com/windows/shop/specialoffers.mspx?ocid=TXT_TAGLM_CPC_MediaCtr_bigscreen_012008 ) Get the power of Windows + Web with the new Windows Live. Get it now! ( http://www.windowslive.com/?ocid=TXT_TAGHM_Wave2_powerofwindows_012008 ) 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 ) Helping your favorite cause is as easy as instant messaging. You IM, we give. Learn more. ( http://im.live.com/Messenger/IM/Home/?source=text_hotmail_join ) -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Fri Jan 18 23:57:31 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 18 Jan 2008 23:57:31 +0100 Subject: [M3devel] incremental build always rebuilds cm3, never produces the same thing -- what time is "now"? 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> <477EA137.1E75.00D7.1@scires.com> <478D394B.1E75.00D7.1@scires.com> <478D47FB.1E75.00D7.1@scires.com> <478DBF8D.1E75.00D7.1@scires.com> <478DE973.1E75.00D7.1@scires.com> <47908659.1E75.00D7.1@scires.com> Message-ID: <20080118235731.i77fhwy4ys8k0og4@mail.elegosoft.com> Quoting Jay : > In m3-sys\cm3, incremental build always rebuilds cm3, never produces > the same thing. > > I know exactly why. My modification to Olaf's timestamping (which I > think he approved, > but perhaps didn't realize this outcome). I know of this problem and don't think it's of much importance. > Because we generate a source file with the current time, and it > always changes. It's not only that: we could fix the time and it would still rebuild, because the Version module is always generated, regardless if it's needed or not. Of course this could be fixed, too. > Is this ok with people?I know it has downsides, but it might be ok. > You know: > 1) incremental build should really never do anything, never > writing anything, fast > which is important -- never write, or be fast? both? > 2) You might want to compare two full builds and determine they > are identical; the less of this sort of thing the better > If not, what do people suggest for a way to determine when to update > the time? > The logic before I think was essentially never, unless you went and > deleted a specific file. > Perhaps that is right, once it is discovered and publicized. > Perhaps another output directory is needed -- say / > -- that upgrade and make-dist, perhaps, know to delete, and maybe > realclean...of cm3? deletes? Hey, maybe just declare an output, with > "..", in the m3makefile, so merely clean and realclean update the > time, but incremental builds do not? This seems obviously the way to > go right now, but still slightly debatable. Like, maybe an accurate > timestamp is needed. Maybe if any other source or .lib changes, the > timestamp should change -- so, like, m3_back/m3_link could > regenerate the file, except that might be too late. > > Should "now" be less granular than a second? That mitigates the > problem but i think is not satisfactory.Should "now" be overridable > on the command line or with an environment variable? Again I think it's not worth bothering about. The cm3 package will only be rebuilt by its developers and maintainers, and they can easily disable the mechanism if they want to. Or by end users performing an upgrade, but they should do it based on a script. The correct time to use would indeed be the last modification time of all the sources files compiled and linked into cm3. I've thought about this for half a day, but it would be a hell of an effort to program based on CVS. (If anybody finds an easy solution to do this, I'd be very interested.) The time stamp is just to imprint in releases and snapshots when the compiler was actually built and helps to relate problem reports to system releases. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Jan 19 00:03:18 2008 From: jayk123 at hotmail.com (Jay) Date: Fri, 18 Jan 2008 23:03:18 +0000 Subject: [M3devel] my status on win32 In-Reply-To: <20080118234226.8g4fi0mkgwgscwww@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> <477EA137.1E75.00D7.1@scires.com> <478D394B.1E75.00D7.1@scires.com> <478D47FB.1E75.00D7.1@scires.com> <478DBF8D.1E75.00D7.1@scires.com> <478DE973.1E75.00D7.1@scires.com> <47908659.1E75.00D7.1@scires.com> <20080118234226.8g4fi0mkgwgscwww@mail.elegosoft.com> Message-ID: Ok, that shuts me up well. I will continue to party in the *.py files and mostly avoid the *.sh files. And then, still, *.cmd vs. *.py? I suspect the answer is "The Windows folks, Jay being the most vocal/active at the moment, can do what they want" (which is partly why I am here -- to be in the "partially independent minority". :) ) I stopped reading usenet years ago but from time to time wonder if it might be "useful". I have at least two problems with using Modula-3 here but I might be somewhat or wrong or very wrong. 1) I have been unable to aquire a taste for it. 2) What about bootstrapping? This is a more general and relevant question that I have . >>>> From what version are you expected to be able to boot what version? Is it ok for merely version n to only be bootrappable, or upgradable, from version n (for upgrade) or n - 1 (bootstrap)? Or downgrade from anything > n? "Version n" isn't even well defined..or is that because I don't know about pkgtags? Any increased dependency on Quake worries me here, until I understand this. Yet, unless you can be clever and a) make all new things optional b) write all new things in both M3 and Quake, or M3 and SH, or M3 and whatever, forward progress is entirely blocked in Quake, and that probably can't be the right answer. Arguably either way -- required changes must be possible at any point in the stack at any time. Nothing is unchangable. Don't go crazy. Don't change things for no reason. But if a change is needed, it can be done. OR, alternatively, some things really cannot be changed, as they would require rewriting all or at least a whole heck of a lot of code. The world is round, and that cannot change, until such time as the world is gone, and all of us with it, for example. Modula-3 files have the extensions .m3 and .i3. I could be wrong, but there will never ever be a reason to change that, for example. I can bootstrap on Windows from 5.1.3. I have 4.1 and 3.6 but haven't tried yet. I believe 3.6 won't work since I /think/ cm3 uses WIDECHAR or such. 3.6 definitely still "works" on its own, nice. I am not sure there is any point to those exercises. Having them working independently may be useful for comparison and history, but that is different than booting. - Jay > Date: Fri, 18 Jan 2008 23:42:26 +0100> From: wagner at elegosoft.com> To: jayk123 at hotmail.com> CC: rcoleburn at scires.com; m3devel at elegosoft.com> Subject: Re: [M3devel] my status on win32> > Quoting Jay :> > > I'll see about adding usage statements.> > Basically all the do* scripts accept a "command" and a list of packages.> > The commands are:> > realclean> > clean -- pretty useless imho> > buildlocal -- the default> > ship> > buildship -- build and shpi> > buildglobal> > Actually, the more useful commands are> > build -- build with overrides to ROOT> buildship (same as buildglobal) -- build with global package pool> realclean -- completely delete derived target files> > > do-pkg requires a list.> > If you're doing you're own project, this may be what is most useful> -- if you use the scripts at all.> > > What do folks think of deleting all of scripts\win and having only > > scripts\python?> > I guess you have to try them out first, at least.Scripts\python > > achieves parity pretty much, except for the more logging to files, > > less logging to the console, that win\make-dist has.> >> > Furthermore, out on a limb, what do folks think of deleting most of > > scripts\*.sh and having just Python?> > I'd object to this. Shell is POSIX standard, and most of the> infrastructure is built on it; Python is nice to have, but should> not be a prerequisite to CM3.> > > I doubt this will fly and I will try resist mentioning it often. :)> > In the interest of consensus here, though I doubt it will help, I'd > > be open to rewriting python in Perl, or possiby even Tcl.> > Why?> > > I am also willing/interested in discussing the merits of these > > languages, or an as yet undeveloped one "ideal language" (Modula-3 I > > don't think is it, sorry), but probably most people will find it a > > waste of time. Where is the geek-out-really-badly mailing list? :)> > I don't see the point in rewriting the scripts in yet other languages.> The purpose of the scripts is to support the installation, administration> and maintenance of the CM3 distribution. They were not intended as> a general purpose build or automation environment, though they can> be used for this purpose to a certain extent. But the main point is> that they are useful for the people maintaining the distribution.> > We could think about rewriting everything in M3 to further reduce> the system dependencies, but this would not be as flexible as a> general scripting language. Quake would need to be substantially> extended, and Python is nice, but a huge software distribution in> itself, that should be independent of CM3.> > POSIX shell is the one common interpreter I have found to be available> on almost all systems. (Even when we were programming point-of-sale> solutions on DOS in the early 90s we had ksh and other POSIX tools there> to emulate the Sun development environment we used on the servers.)> OK, on Windows you have to install it (e.g. in form of Cygwin) like> Python, but it's still the best choice wrt. availability and portability> I've found.> > For general discussions of the advantages and disadvantage of> programming languages, some of the comp.lang.* newsgroups may> be the better choice, though I haven't read them for years now> and don't know if they're still alive.> > As for the ideal language -- I don't think that there is any language> that could claim this. The advantages and disadvantages depend heavily> on the usage context, environment, and skills and understanding of the> programmers.> > (M3 is pretty good 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> _________________________________________________________________ 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 Jan 19 00:25:33 2008 From: jayk123 at hotmail.com (Jay) Date: Fri, 18 Jan 2008 23:25:33 +0000 Subject: [M3devel] my status on win32 In-Reply-To: <4790E7A7.1E75.00D7.1@scires.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> <477EA137.1E75.00D7.1@scires.com> <478D394B.1E75.00D7.1@scires.com> <478D47FB.1E75.00D7.1@scires.com> <478DBF8D.1E75.00D7.1@scires.com> <478DE973.1E75.00D7.1@scires.com> <47908659.1E75.00D7.1@scires.com> <4790E7A7.1E75.00D7.1@scires.com> Message-ID: I'm an old guy that started with 143k floppies. :) I don't like calling them "scripts" either. They are "programs", in varying languages, needing "compilation" or not. cmd is an awful language and deserves some derisive label, but Perl and Python seem to strive to be pretty complete and large maintainable well *engineered* systems have been built with them. If I may stretch the point, they are "systems" programming languages, for "system" meaning "large well engineered modular maintainable long lived reliable blah blah system", not "operating system" or in particular "kernel". Perl has some problems. Python has some problems. They both have some "magic" "developer productivity" improvements, and that can be a bad thing, it can lead to programming faster with less design/engineering. Olaf I didn't answer your question "why?" And it is moot. For whatever temporary or permanent condition, I don't like "sh". I have tried to learn it several times and always get lost in a haze of special things to keep in mind, portability concerns, inability to build data structures perhaps. Not that "special things to keep in mind" prevented *.cmd from being created, maybe I put more persistance there, or a younger self. I have run MS-DOS relatively recently and been amazed at how limited command.com is. I don't think portability to .bat is feasible while accomplishing much approaching the *.sh. (Dare I mention a DJGPP port? No such thing exists, but, hey, gcc, consider making garbage collection and threading optional pending further research.., the djgpp posix-ish runtime....seems feasible, not sure what people do with this environment though....and besides, Python exists built with djgpp so whil djgpp might be a viable interesting port, command.com remains irrelevant..) Randy I kind of agree with your sentiment about the "native environment", and reducing dependencies, it is a common one, HOWEVER I believe it is a gray one, and the pay off to compromising it can be substantial. There will be a NT386GNU target, and unless we import ld, as, (and I'm not going to do so) and more, it will likely always require getting cm*.tar.gz and at least one other file onto your system to build m3cc. There was work on a linker written in Modula-3, so in fact, using the system might be possible without gcc/ld/as, or even without Visual C++. However m3core has some C code, so building it, for the forseeable future, will continue to require a C compiler. (I think this C code is cutable, that I have seen -- hand/dtoa, and at least Win32 Errno). It is possible that the cm3 gui installer will prompt "Do you want to be able to build the ENTIRE system, including the compiler from source", and if so, for NT386GNU look for the local installs, else get and install them, or for NT386 plop you in IE's at microsoft.com (EULAs and all that..)." Try installing the free/open Qt for example. It will get MingW for you. In this model, what is extra? Where does one download/dependency end and the next begin? In terms of the user experience, not clear. I am aware of your programs and while they appear well designed/documented/developed, I like to do things myself. I have been tempted to ask "Mind if I delete yours and move mine up into that directory" but thought it maybe too rude. Thanks for the compliment, and you should keep at it (the contributions, not the compliments, or both. :) ) If you want an explanation of something I did, ask. Buildship, buildlocal, buildglobal..uh oh, you did ask.and I doubt I can explain this well, not sure I understand it well. Will try later maybe, or see what anyone else says first. - Jay Date: Fri, 18 Jan 2008 17:53:45 -0500From: rcoleburn at scires.comTo: m3devel at elegosoft.com; jayk123 at hotmail.comSubject: RE: [M3devel] my status on win32 Jay: What does "buildglobal" mean? How is it different from "buildship"? As far as "scripts" go, I'm an old guy that started out with computers that had real core memory. When the IBM PC revolution hit, I was already a professional and had mastered large computers with network operating systems and even micro-computers with CP/M. I learned DOS and became a good "BAT" batch file programmer (we didn't call them scripting languages back then). I'm still pretty good with Windows CMD files, but have not tackled python. My vote for cm3 on Windows is to avoid making the end user (customer) have to learn or acquire things that aren't native to his environment. Thus, I would argue for use of CMD files on Windows instead of some other scripting language. This same reasoning is why I was pushing for the all-in-one installation program for cm3 on Windows. If all a "Windows person" has to do to get cm3 modula-3 up and running on his box is to run an install program and possibly tweak a few CMD scripts to his/her liking, then it is "easy". Forcing acquisition and installation of other tools/environments just to get started makes things complicated and increases the barrier to startup and acceptance. Just my 2 cents worth. A few years ago, I contributed some BAT/CMD files that could be used to build the entire system on Windows. The only issue is that as the system evolves, you have to keep the package build order up to date. I don't mind trying to help out further in this area. You seem to be very technically capable, so perhaps what I can offer pales in comparison. Thanks for all you are doing. Let me know if/how I can help. Regards, Randy>>> Jay 1/18/2008 4:50 PM >>>I'll see about adding usage statements.Basically all the do* scripts accept a "command" and a list of packages.The commands are: realclean clean -- pretty useless imho buildlocal -- the default ship buildship -- build and shpi buildglobal The .sh and .py have a usage explaining this but .cmd is missing it, probably because I didn't fully understand at the time the functionality of the code I was blindy porting. do-* except for do-pkg have an implied list of packages. Maybe you can add to it, would have to check the source. do-pkg requires a list. Most of the rest are not meant to be user-callable -- sysinfo, pkginfo, pkgcmds. make-dist its its own thing. Oh, right -- environment variables. Many things are overridable with them, and need documentation the same. What do folks think of deleting all of scripts\win and having only scripts\python?I guess you have to try them out first, at least.Scripts\python achieves parity pretty much, except for the more logging to files, less logging to the console, that win\make-dist has. Furthermore, out on a limb, what do folks think of deleting most of scripts\*.sh and having just Python?I doubt this will fly and I will try resist mentioning it often. :)In the interest of consensus here, though I doubt it will help, I'd be open to rewriting python in Perl, or possiby even Tcl. I am also willing/interested in discussing the merits of these languages, or an as yet undeveloped one "ideal language" (Modula-3 I don't think is it, sorry), but probably most people will find it a waste of time. Where is the geek-out-really-badly mailing list? :) - Jay Date: Fri, 18 Jan 2008 10:58:36 -0500From: rcoleburn at scires.comTo: m3devel at elegosoft.com; jayk123 at hotmail.comSubject: Re: [M3devel] my status on win32 Jay: Ok. It will be later tonight before I can try again. Thanks! BTW, can you point me to a document/file somewhere that describes the various options for your windows command file scripts? I did experiment further with using the do-cm3-std.cmd and was finally able to get most everything to build, but of course this doesn't rebuild the compiler and core. Had problems with mentor and m3zume not wanting to build/run, so I commented these out in the cmd file to get it to work. Then I had trouble because everything was built with overrides by default, so I had to mess around with changing parameters and rebuilding clean. I've tried building some of my programs and, of course, have run into a few problems due to changes in the system. I've overcome most of these, but I am seeing some strange behavior: 1. pixmaps aren't rendered properly on the screen. They look really bad. I recall having this problem a while back with one of the early 5.x releases, so I guess it was never solved. I've got some old test programs I try to dig out and see if I can find out what is going on. I seem to recall that building standalone in the past seemed to fix the problem, so this is a real mystery. 2. I'm having trouble with bundles not returning all of the data. In the "reactor" program, bundles are used to provide input to the web browser for the page source. I'm seeing cases where not all of the HTML source is making it to the browser. Not sure if this is an I/O problem (maybe buffers not flushed) or if it is something else. It may be that this problem has some impact on #1 above because pixmaps are sometimes stored in the bundles. For the above #1 and #2, these things worked properly on cm3 v4.1. I have the sources to 4.1, so maybe I can use them to figure out what is wrong. On a side note, I found and fixed a major bug in the "reactor" program, so that is good. Now, for another topic that we should probably move to a new email thread: Back in the early days, my company paid Critical Mass, Inc., to customize the Trestle/FormsVBT look and feel to more closely resemble Windows. I have the sources for this work, but of course it is based on v4.1 and the repository code has moved on since then. I am curious if anyone would be interested in me trying to integrate these customizations back into the current source tree, perhaps on a different branch? If we go this route, I may need a little refresher tutorial on the use of branches in CVS. We would want to make it so that the main branch and the customized branch could evolve in sync. That is, if a bug was found in either branch, the fix should be incorporated into both. Regards, Randy>>> Jay 1/18/2008 10:32 AM >>>Randy, please try with an updated m3-sys/cm3/src/version.quake and report back, thanks.I understand why I wasn't seeing this. - Jay Date: Wed, 16 Jan 2008 11:24:34 -0500From: rcoleburn at scires.comTo: m3devel at elegosoft.com; jayk123 at hotmail.comSubject: Re: [M3devel] my status on win32 Jay: Not sure I've clued in to all of your dialog. Sorry. I have in the past used a free tool to build an installer package and I was thinking of using it again. Since the tool is free, we could put all the work I do into the CVS repository so that others could also maintain it. What I am looking to achieve is to have a way where a "normal" Windows user could download a program, run it, and have all of the cm3 packages installed without having to use the MIN distribution to build it up or any other tools to get the sources (like cvs). You could achieve the same thing by having a big ZIP file also I suppose, but having the installer would also let us easily put something in the start menu to launch a command line with all the environment variables set properly via automatic call to vcvars et al. When I get "Reactor" working, it too could be put into the start menu. That just makes it fit in better with the Windows user culture I think. The reason I wanted to rebuild everything is two-fold: 1) ensure it can be done (i.e., test for "Broken #1"), and 2) get all of the rest of the packages built so I could then use cm3 to build "reactor" and my own programs and test them to see if there are any "Broken #2" issues. The MIN distribution is really insufficient to do much of anything except to build the rest of the packages you need. My understanding is that I needed to use CVS to get the current sources, because if I went back to the source archive, it was old and known to be Broken #1 on Windows. I'm glad that you believe the current "Broken #1" situation is easy to fix. Let me know what to do and I'll give it another try. My experience in the past has been that there are 3 conditions to getting cm3 to work properly on windows after it has been installed: 1) make sure your environment variables are set up by vcvars to point to the compiler/linker/libraries (of course if you used a non-Microsoft C compiler/linker you would need to use something other than vcvars); 2) make sure cm3.cfg has the right paths in place to find all the libraries and tools using DOS style short names (no embedded spaces); and 3) make sure C:\cm3\bin is in your path. Of these, #2 & #3 are essentially one-time events, and #1 can be set up by a invoking a batch/command file via a shortcut, so no big deal for me. You could even make #1 a one-time event by modifying the system-level (vice user-level) environment variables. The old cm3install program seemed to do a decent job of #2 for me. Also, I've noted some of your past dialog about accepting either '/' or '\' as a path separator. I'm sure you are aware that on Windows '/' is used often for switches (arguments). Plus Windows also allows spaces to be embedded in the command line, so whatever solution you propose needs to take into account that a valid command line might look like this: C:\My Program Folder\My Program.exe /myArg1 /myArg2 In some situations, this command line would have to be quoted and rendered as: "C:\My Program Folder\My Program.exe" /myArg1 /myArg2 and in places where the backslash is an escape character, I've seen "C:\\My Program Folder\\My Program.exe" /myArg1 /myArg2 Alas, I seem to have rambled a bit also. Sorry. The immediate need for me now is to solve the Broken #1 condition, so please let me know how to fix it and proceed. Regards, Randy>>> Jay 1/16/2008 10:28 AM >>>Randy, yes and no and clarifications. I mention starting with 5.1.6 as a "worst" or "worse" case.The earlier you start, the harder things are -- for me, to ensure it will work. If you merely start with my 5.5.0, well, what are you rebuilding from source for?Heck, you can use any binary distribution, 4.1, 5.1.6, and just use it. They should work. The n steps you/I give are really actually geared for people who WANT to build from source, it is not what people HAVE to do.As well there have been can be source distributions, to cut out CVS. I'll look into the datefn stuff shortly. As to the installer, well, again, yes and no.The need for the installer is very small. All you have to do today is unzip the .zip somewhere and set the path, and possibly the vcvars thing. That's it. I should..now that you are "pressuring" me for ease of use, teach cm3 about the various ?venvdir%, %vcinstalldir% variables, etc. That way as long as the user installed the tools, even if they elected not to change path/lib/include, cm3 can find the compiler and linker. I know everyone wants to preserve the flexibility of quake/cm3.cfg but...besides, cm3 can be pretty darn smart here. IF cm3.cfg defines SYSTEM_CC, leave things along (NT386 cm3.cfg does not today do that). However if there is now SYSTEM_CC and there is no cl.exe/link.exe in %PATH%, it could go on a quick hunt for them. On the lib and include part, well, the dependency on %include% might only be for errno..maybe not worth it. It has been whatever it is forever, like int* _errno(void); #define errno (*_errno)()). Modula-3 engages in rampant header cloning and CErrnoC was only introduced where that was deemed more fragile than usual, and for Windows it probably wasn't actually fragile -- the fragility, if I may be so rudely judgemental, is because so many other systems are so Johnny-come-lately to arriving at the obviously correct threading model that Windows has had all along (since Win95/NT, can't say anything good about Win3.1; I think OS/2 might have had it correct all along too.). Funny, everyone has FINALLY arrived at the correct threading model, only to have start changing again, since the number of cores and machines is set to be much greater than anticipated, the obvious threading model has been deemed too difficult for anyone to use (Win32, Modula-3, Java, .NET, Python, all the same supposedly too difficult model btw), and so some new one is needed, and well, truthfully, the difficulty is not just for dummies on relatively small multiproc boxes not having simple race conditions, the problem is scaling way way up. Sorry that was my usual tangential. Even the unzip and set path would benefit slightly from a GUI installer.I believe there is some easy thing you can do where you write your GUI installer and you put it in the .zip and then you prepend the GUI self extracting .zip/.exe stub, and you can tell it to run a particular command after the extraction. I guess you might use a fancier thing though?That is, are you going to, say, write a gui installer from scratch in Modula-3? It might be a fun exercise. :)And then you could build the self extracting prefix from source etc.This is the hard way I guess, but more interesing.If you can build an msi or use InstallShield or Wix or something, go ahead.If you use widely availabe free as in beer tools, that can be rolled into whatever automation there is to produce distributions, keeping it up to date shouldn't be a problem. I do have to bring up some annoying questions: 1) Does anyone besides me have the capacity to produce distributions? i.e.: Any Win32 machines left at Elego? 2) I know I ramble. So one of my many tangents/questions went unanswered.Say, in the absence of a gui installer, should .zips/.tar.bz files look like cm3-min-/bin/cm3orbin/cm3orcm3/bin/cm3 The last one is more directly usable. The first one is very common. This reminds me though Randy, the distribution I made available was "min", so yeah, like if you are doing any gui programming, using any "standard" library besides m3core or libm3, you'd need to build more from source. I can readily provide you a "std" distribution though.It's "always" been a "problem" to make my files available -- no web site hosting for me -- but recently that wasn't a problem, someone picked the files out of ~jkrell on birch and put them on the web site. Good. One more thing -- Olaf, please confirm repeat yourself, 'cause I admit I wasn't sure it was the right thing, but if you insist, ok. "std" should be "all"? I should not continue to imagine there is a new larger group called "all"? And wherever things are missing from std but do build ok, add them?m3cc should be in std?(I admit some big indecisiveness around m3cc. It is far and away the longest thing to build and so the one you really want to skip the most and leave out of whatever package group. I also wonder if on Windows, there should be some check where if sh is not in the $PATH, just silently skip m3cc? You only need MingWin to build what I have on my system for NT386GNU, except you also need msys just for m3cc. msys is actually quite small, like only 20 files..) Oh, sorry, yet another question.The non-gcc backend is excluded from the build on systems that use the gcc backend.For minimization, that is appropriate.For maximizing cross build capability, it is wrong.The packages build fine. I suspect they work.I am not a user of cross build capability yet, so I don't really care. (What I do for NT386/NT386GNU /might/ be considered sort of a cross build, but it is different/easier).They are small packages. - Jay Date: Wed, 16 Jan 2008 08:25:49 -0500From: rcoleburn at scires.comTo: m3devel at elegosoft.com; jayk123 at hotmail.comSubject: Re: [M3devel] my status on win32 Jay: There is no line in the m3makefile dealing with datefn, so I added the whole statement just before the line include("version.quake") Now, I get an error saying that the variable datefn is not defined. If you change to put quotes around datefn in the include statement, you get an error saying it can't open the file. You made a reference in one of your earlier posts about trying 5.1.6 or 4.1, but note that I started with your cm3-min-WIN32-NT386-d5.5.0.zip , not the 5.1.6 or 4.1 versions. Thus, using d5.5.0 as a base, I am trying to run your "upgrade.cmd" to rebuild the sources I checked out from CVS. Since this doesn't work "out-of-the-box", again I say this fits into the "Broken #1" category. If I can get this to work, I don't mind putting together a Windows installer program that will install the whole thing. That way, folks won't have to install cygwin just to get CVS so that they can install a working cm3. Folks will need to install the free Microsoft Visual C as a prerequisite, but then that's not too bad. Having an installer program would make cm3 more friendly to Windows folks. The current 16-step method is too laborious and error-prone for the person just getting started and they will not give cm3 a second try. As the cm3 system evolves and new releases are made, we will need to keep the installer program up-to-date and I don't mind doing that. After someone gets familiar with cm3 they might want to delve into some of the scripts for rebuilding the system, but until then, I think the installer program is the way to go. Regards, Randy>>> Jay 1/16/2008 1:01 AM >>>I think I see the problem. in cm3\src\m3makefile, make this change > if not defined("NOW") include(datefn) > end datefn is only created if certain other variables aren't defined, and do-pkg defines them.I don't know why I don't see this. Later.Could be that the Python scripts have a typo and don't define them.I've been using them more than cmd. If the host is NT, "NOW" is either gotten from an updated cm3.exe, or left to "not available". So the initial cm3 built from older cm3 can't report when it was built, but cm3 built from current cm3 can. I need to change that: 1) to be a function for niceness 2) to make it that way for Posix, for any host but I haven't been using Posix as much lately so not testing it. - Jay Date: Tue, 15 Jan 2008 23:55:39 -0500From: rcoleburn at scires.comTo: m3devel at elegosoft.com; jayk123 at hotmail.comSubject: RE: my status on win32 Jay: In the file version.quake, I made the following edit: changed line: local datefn = "../" & TARGET & ".datenow" to: local datefn = ".." & SL & TARGET & ".datenow" This change has the effect of putting a backward slash in the pathname instead of a forward slash, so we getC:\CM3_CVS_SourceTree\m3-sys\cm3\src\..\NT386.datenow So from that perspective, the change seems good. Unfortunately, I still get the error that this file can't be opened. A quick check of C:\CM3_CVS_SourceTree\m3-sys\cm3\NT386 shows that the file .datenow does not exist. Regards, Randy>>> Jay 1/15/2008 11:03 PM >>>That's not too bad really. 1) I'd recommend putting cm3 at the start of the path instead of the end. 2) Just comment out the offending code to make progress. It's not critical. >> C:\CM3_CVS_SourceTree\m3-sys\cm3\src\../NT386.datenow The code is: C:\CM3_CVS_SourceTree\m3-sys\cm3\src\version.quake or such, included by cm3\src\m3makefile. Does the file exist?Does version.quake use "/" or "SL"? If it uses "/", try replacing with SL (and ampersand for string concat). Could be that a newer binary distributions works better with forward slashes. > 4. > 5. > 6. Launch cygwin from desktop icon. Cygwin is only needed for cvs, I think you realize. Could you send me offline the result of just running "set" after running vcvarsall? I'd like to adapt pylib.py to it maybe. (I can start from 5.1.6 and will try 4.1 at some point.) - Jay Date: Tue, 15 Jan 2008 22:52:59 -0500From: rcoleburn at scires.comTo: m3devel at elegosoft.com; jayk123 at hotmail.comSubject: my status on win32 Jay et al: I've listed below the steps I've undertaken to try and build the current sources on Windows XP. I've also attached a text file showing the output I got when trying to build everything using Jay's upgrade.cmd script. Unfortunately, I'm getting a build error (see below). Please advise on how to resolve. STEPS I TOOK: ========= 1. Download Microsoft Visual Studio 2008 Express Edition All-in-One .ISO file and burn to DVD. http://www.microsoft.com/express/download/ 2. Install Microsoft Visual C++ 2008 Express Edition from DVD. 3. Use "Microsoft Update" service to check for updates / service packs. 4. Download cygwin setup program from http://cygwin.com/ 5. Ran cygwin setup.exe program to install cygwin for all users. Under "Devel" category, make certain to select "cvs" for installation. 6. Launch cygwin from desktop icon. 7. In cygwin command shell window, execute following two commands, making sure to give email as password when prompted for login: cvs -d :pserver:anonymous at modula3.elegosoft.com:/usr/cvs login cvs -d :pserver:anonymous at modula3.elegosoft.com:/usr/cvs checkout cm3 8. Moved resulting C:\cygwin\home\rcoleburn\cm3 to C:\CM3_CVS_SourceTree Note that you should replace "rcoleburn" above with your Windows login username. 9. Download cm3-min-WIN32-NT386-d5.5.0.zip and cm3-min-WIN32-NT386-d5.5.0-symbols.zip from http://modula3.elegosoft.com/cm3/download.html 10. Unzipped cm3-min-WIN32-NT386-d5.5.0.zip and stored resulting cm3 folder at C:\cm3 11. Unzipped cm3-min-WIN32-NT386-d5.5.0-symbols.zip and stored resulting symbols folder at C:\cm3\symbols 12. Launch Windows Command Prompt shell. The following steps represent commands executed within this shell. 13. path %path%;c:\cm3\bin 14. "C:\Program Files\Microsoft Visual Studio 9.0\VC\vcvarsall.bat" 15. cd C:\CM3_CVS_SourceTree\scripts\win 16. upgrade.cmd ERROR I'M GETTING: ============= === package C:\CM3_CVS_SourceTree\m3-sys\cm3 ===+++ "cm3 -build -DROOT=C:\\CM3_CVS_SourceTree -DCM3_VERSION_TEXT=d5.5.1 -DCM3_VERSION_NUMBER=050501 -DCM3_LAST_CHANGED=2007-12-30 && cm3 -ship -DROOT=C:\\CM3_CVS_SourceTree -DCM3_VERSION_TEXT=d5.5.1 -DCM3_VERSION_NUMBER=050501 -DCM3_LAST_CHANGED=2007-12-30" +++--- building in NT386 --- ignoring ..\src\m3overrides "C:\CM3_CVS_SourceTree\m3-sys\cm3\src\version.quake", line 136: quake runtime error: unable to open "C:\CM3_CVS_SourceTree\m3-sys\cm3\src\../NT386.datenow" forreading --procedure-- -line- -file---include -- version_impl 136 C:\CM3_CVS_SourceTree\m3-sys\cm3\src\version.quakeinclude_dir 20 C:\CM3_CVS_SourceTree\m3-sys\cm3\src\m3makefile 8 C:\CM3_CVS_SourceTree\m3-sys\cm3\NT386\m3make.args Fatal Error: package build failedERROR: "cm3 -build -DROOT=C:\\CM3_CVS_SourceTree -DCM3_VERSION_TEXT=d5.5.1 -DCM3_VERSION_NUMBER=050501 -DCM3_LAST_CHANGED=2007-12-30 && cm3 -ship -DROOT=C:\\CM3_CVS_SourceTree -DCM3_VERSION_TEXT=d5.5.1 -DCM3_VERSION_NUMBER=050501 -DCM3_LAST_CHANGED=2007-12-30"ERROR: cd C:\CM3_CVS_SourceTree\m3-sys\cm3ERROR: set INSTALLROOT=c:\cm3 Regards, Randy Share life as it happens with the new Windows Live. Start sharing! Put your friends on the big screen with Windows Vista? + Windows LiveT. Start now! Get the power of Windows + Web with the new Windows Live. Get it now! 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. _________________________________________________________________ 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 Sat Jan 19 00:38:45 2008 From: jayk123 at hotmail.com (Jay) Date: Fri, 18 Jan 2008 23:38:45 +0000 Subject: [M3devel] NT386GNU diffs In-Reply-To: <4790E7A7.1E75.00D7.1@scires.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> <477EA137.1E75.00D7.1@scires.com> <478D394B.1E75.00D7.1@scires.com> <478D47FB.1E75.00D7.1@scires.com> <478DBF8D.1E75.00D7.1@scires.com> <478DE973.1E75.00D7.1@scires.com> <47908659.1E75.00D7.1@scires.com> <4790E7A7.1E75.00D7.1@scires.com> Message-ID: I think attached is all the diffs I have for NT386GNU. They are: "rewrite" NT386GNU config fileThe diff and result are present.It almost exactly matches NT386.In fact, the targets can perhaps be merged into one configurable target,and NT386GNU be "reclaimed" for the more Posix port people want.But not right now. setjmp to _setjmpThis "works" with Cygwin and MinGW, whereas setjmp doesn't."Works" as in links. I should double check this. Maybe not needed. Just one line.. Changes NT386GNU from Posix to Win32. Any objects to commiting? The result is you can build a lot of NT386GNU, but it won't run.I would say it won't "quite" run, but I can't claim to know all that is wrong. Yes, I understand, getting it to run is very important. This may be progress,but isn't useful yet. - 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 Sat Jan 19 00:42:56 2008 From: jayk123 at hotmail.com (Jay) Date: Fri, 18 Jan 2008 23:42:56 +0000 Subject: [M3devel] m3cc/fopen("rb") In-Reply-To: <4790E7A7.1E75.00D7.1@scires.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> <477EA137.1E75.00D7.1@scires.com> <478D394B.1E75.00D7.1@scires.com> <478D47FB.1E75.00D7.1@scires.com> <478DBF8D.1E75.00D7.1@scires.com> <478DE973.1E75.00D7.1@scires.com> <47908659.1E75.00D7.1@scires.com> <4790E7A7.1E75.00D7.1@scires.com> Message-ID: I changed m3cc to use fopen("rb") instead of fopen("r"), needed for NT386GNU. Yet I just found this: C:\cm3-4.1\binutils-2.7\gas\config\go32.cfg /* Some operating systems, for example DOS, require the use of "wb" mode when opening a binary file for writing. If only "w" is used, the file will not be correct. However, some other systems reject such a mode. This indicates which ../include/fopen-*.h header file we want to include, so that we can get macros that'll do the right thing for this system. */#define WANT_FOPEN_BIN 1 Does it matter? - 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 Jan 19 00:43:51 2008 From: jayk123 at hotmail.com (Jay) Date: Fri, 18 Jan 2008 23:43:51 +0000 Subject: [M3devel] NT386GNU diffs 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> <477EA137.1E75.00D7.1@scires.com> <478D394B.1E75.00D7.1@scires.com> <478D47FB.1E75.00D7.1@scires.com> <478DBF8D.1E75.00D7.1@scires.com> <478DE973.1E75.00D7.1@scires.com> <47908659.1E75.00D7.1@scires.com> <4790E7A7.1E75.00D7.1@scires.com> Message-ID: attached this time.. From: jayk123 at hotmail.comTo: m3devel at elegosoft.comDate: Fri, 18 Jan 2008 23:38:45 +0000Subject: [M3devel] NT386GNU diffs I think attached is all the diffs I have for NT386GNU.They are:"rewrite" NT386GNU config fileThe diff and result are present.It almost exactly matches NT386.In fact, the targets can perhaps be merged into one configurable target,and NT386GNU be "reclaimed" for the more Posix port people want.But not right now.setjmp to _setjmpThis "works" with Cygwin and MinGW, whereas setjmp doesn't."Works" as in links. I should double check this. Maybe not needed.Just one line..Changes NT386GNU from Posix to Win32.Any objects to commiting?The result is you can build a lot of NT386GNU, but it won't run.I would say it won't "quite" run, but I can't claim to know all that is wrong.Yes, I understand, getting it to run is very important. This may be progress,but isn't useful yet. - 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: diff.zip Type: application/x-zip-compressed Size: 11639 bytes Desc: not available URL: From rcoleburn at scires.com Sat Jan 19 01:05:38 2008 From: rcoleburn at scires.com (Randy Coleburn) Date: Fri, 18 Jan 2008 19:05:38 -0500 Subject: [M3devel] my status on win32 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> <477EA137.1E75.00D7.1@scires.com> <478D394B.1E75.00D7.1@scires.com> <478D47FB.1E75.00D7.1@scires.com> <478DBF8D.1E75.00D7.1@scires.com> <478DE973.1E75.00D7.1@scires.com> <47908659.1E75.00D7.1@scires.com> <4790E7A7.1E75.00D7.1@scires.com> Message-ID: <4790F880.1E75.00D7.1@scires.com> >>> Jay 1/18/2008 6:25 PM >>> >>> I'm an old guy that started with 143k floppies. :) Floppies, what a luxury! I had to deal with paper tape, punched cards, and hard-wired plug boards to program old IBM tabulating machines. I've found no better finger muscle exercise than "typing" for hours on an old ITT canary-yellow roll paper teletype machine with a paper tape punch. And no, I don't long for the "good 'ol days" because in many ways they weren't so good... Regards, Randy -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Sat Jan 19 01:29:19 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 19 Jan 2008 00:29:19 +0000 Subject: [M3devel] FW: my status on win32 In-Reply-To: <20080118234226.8g4fi0mkgwgscwww@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> <477EA137.1E75.00D7.1@scires.com> <478D394B.1E75.00D7.1@scires.com> <478D47FB.1E75.00D7.1@scires.com> <478DBF8D.1E75.00D7.1@scires.com> <478DE973.1E75.00D7.1@scires.com> <47908659.1E75.00D7.1@scires.com> <20080118234226.8g4fi0mkgwgscwww@mail.elegosoft.com> Message-ID: darnit something keeps truncating my email. From: jayk123 at hotmail.comTo: wagner at elegosoft.comCC: rcoleburn at scires.com; m3devel at elegosoft.comSubject: RE: [M3devel] my status on win32Date: Fri, 18 Jan 2008 23:03:18 +0000 Ok, that shuts me up well. I will continue to party in the *.py files and mostly avoid the *.sh files. And then, still, *.cmd vs. *.py? I suspect the answer is "The Windows folks, Jay being the most vocal/active at the moment, can do what they want" (which is partly why I am here -- to be in the "partially independent minority". :) )I stopped reading usenet years ago but from time to time wonder if it might be "useful". I have at least two problems with using Modula-3 here but I might be somewhat or wrong or very wrong. 1) I have been unable to aquire a taste for it. 2) What about bootstrapping? This is a more general and relevant question that I have. >>>> From what version are you expected to be able to boot what version? Is it ok for merely version n to only be bootrappable, or upgradable, from version n (for upgrade) or n - 1 (bootstrap)?Or downgrade from anything > n?"Version n" isn't even well defined..or is that because I don't know about pkgtags? Any increased dependency on Quake worries me here, until I understand this. Yet, unless you can be clever and a) make all new things optional b) write all new things in both M3 and Quake, or M3 and SH, or M3 and whatever, forward progress is entirely blocked in Quake, and that probably can't be the right answer. Arguably either way -- required changes must be possible at any point in the stack at any time. Nothing is unchangable. Don't go crazy. Don't change things for no reason. But if a change is needed, it can be done. OR, alternatively, some things really cannot be changed, as they would require rewriting all or at least a whole heck of a lot of code. The world is round, and that cannot change, until such time as the world is gone, and all of us with it, for example. Modula-3 files have the extensions .m3 and .i3. I could be wrong, but there will never ever be a reason to change that, for example. I can bootstrap on Windows from 5.1.3.I have 4.1 and 3.6 but haven't tried yet.I believe 3.6 won't work since I /think/ cm3 uses WIDECHAR or such.3.6 definitely still "works" on its own, nice.I am not sure there is any point to those exercises.Having them working independently may be useful for comparison and history, but that is different than booting. - Jay [snip, deliberate] _________________________________________________________________ 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 Jan 19 01:47:11 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 19 Jan 2008 00:47:11 +0000 Subject: [M3devel] buildlocal vs. buildglobal vs. buildship explanation Message-ID: I'm not sure I can explain this well or if I fully understand it. "Ship" means "Install" Let's say your install is at c:\cm3 and your source is at c:\dev2\cm3 (I would use dev, but Unix took it.) Depending on the state of things, you probably two of many things: c:\cm3\pkg\libm3\nt386\libm3.libc:\cm3\pkg\libm3\nt386\libm3.dllc:\dev2\cm3\m3-libs\libm3\nt386\libm3.libc:\dev2\cm3\m3-libs\libm3\nt386\libm3.dll You will have more in \dev2\cm3\m3-libs\libm3\nt386. When you build stuff, you can use the installed dependencies or the just built dependencies. buildlocal uses the just built dependencies. buildglobal uses the installed dependencies buildship build and ships (installs) each directoryIt does it in one pass: buildship pkg1 pkg1 => build pkg1 ship pkg1 build pkg2 ship pkg2 and NOT build pkg1 build pkg2 ship pkg1 ship pkg2 You may only ship/install outputs that are builtglobal.Outputs are presumed to only be valid if "amidst" dependencies thatmatch the declarations and such they were built against -- i.e. the headers, in C. If you are starting with a minimal install, with just m3core and libm3, then you mustbuildship and you must do it in dependency order. (I just derived this rule, might be wrong.) It only matters for certain types of changes, and then it can really matter. You might change the format of some compiler-produced runtime-consumed data. You might have a bunch of .sos/.dlls. They can only work with each other if they match in certain ways. Again, ways which don't change that often, but sometimes do -- like changing public types. This is why you can get "fingerprint mismatches" -- when code has different notions as to a type definition. I guess that is when the "ship checking" is either inadequate or circumvented. It makes me wonder. What if there was a compilation mode in which all types were opaque. If all record field access to records defined in other packages were implemented by non-inlined dynamically linked getter/setter functions. It would be slow. It would be much more amenable to type changes -- removal/renaming/retyping of existing fields being the remaining "problems". Actually adding would be a problem too, clients of the new could not run against the old. - 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 Sat Jan 19 01:50:35 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 19 Jan 2008 00:50:35 +0000 Subject: [M3devel] FW: buildlocal vs. buildglobal vs. buildship explanation Message-ID: Besides getting truncated, newlines often get stripped from my emails. I wish for working email.. From: jayk123 at hotmail.comTo: m3devel at elegosoft.comSubject: buildlocal vs. buildglobal vs. buildship explanationDate: Sat, 19 Jan 2008 00:47:11 +0000 I'm not sure I can explain this well or if I fully understand it. "Ship" means "Install" Let's say your install is atc:\cm3 and your source is at c:\dev2\cm3 (I would use dev, but Unix took it.) Depending on the state of things, you probably two of many things: c:\cm3\pkg\libm3\nt386\libm3.libc:\cm3\pkg\libm3\nt386\libm3.dllc:\dev2\cm3\m3-libs\libm3\nt386\libm3.libc:\dev2\cm3\m3-libs\libm3\nt386\libm3.dll You will have more in \dev2\cm3\m3-libs\libm3\nt386. When you build stuff, you can use the installed dependencies or the just built dependencies. buildlocal uses the just built dependencies. buildglobal uses the installed dependencies buildship build and ships (installs) each directoryIt does it in one pass: buildship pkg1 pkg1 => build pkg1 ship pkg1 build pkg2 ship pkg2 and NOT build pkg1 build pkg2 ship pkg1 ship pkg2 You may only ship/install outputs that are builtglobal.Outputs are presumed to only be valid if "amidst" dependencies thatmatch the declarations and such they were built against -- i.e. the headers, in C. If you are starting with a minimal install, with just m3core and libm3, then you mustbuildship and you must do it in dependency order. (I just derived this rule, might be wrong.) It only matters for certain types of changes, and then it can really matter. You might change the format of some compiler-produced runtime-consumed data. You might have a bunch of .sos/.dlls. They can only work with each other if they match in certain ways. Again, ways which don't change that often, but sometimes do -- like changing public types. This is why you can get "fingerprint mismatches" -- when code has different notions as to a type definition.I guess that is when the "ship checking" is either inadequate or circumvented. It makes me wonder.What if there was a compilation mode in which all types were opaque.If all record field access to records defined in other packages were implementedby non-inlined dynamically linked getter/setter functions.It would be slow. It would be much more amenable to type changes -- removal/renaming/retyping ofexisting fields being the remaining "problems".Actually adding would be a problem too, clients of the new could not run against the old. - 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 Jan 19 01:56:57 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 19 Jan 2008 00:56:57 +0000 Subject: [M3devel] FW: buildlocal vs. buildglobal vs. buildship explanation Message-ID: one more try darnit.... From: jayk123 at hotmail.comTo: jayk123 at hotmail.comSubject: buildlocal vs.Date: Sat, 19 Jan 2008 00:55:31 +0000 "Ship" means "Install" Let's say your install is at c:\cm3 and your source is at c:\dev2\cm3 (I would use dev, but Unix took it.) Depending on the state of things, you probably two of many things: c:\cm3\pkg\libm3\nt386\libm3.lib c:\cm3\pkg\libm3\nt386\libm3.dll c:\dev2\cm3\m3-libs\libm3\nt386\libm3.lib c:\dev2\cm3\m3-libs\libm3\nt386\libm3.dll You will have much more in \dev2\cm3\m3-libs\libm3\nt386. When you build stuff, you can use the installed dependencies or the just built dependencies. buildlocal uses the just built dependencies. buildglobal uses the installed dependencies buildship build and ships (installs) each directory It does it one pass: buildship pkg1 pkg1 => build pkg1 ship pkg1 build pkg2 ship pkg2 and NOT build pkg1 build pkg2 ship pkg1 ship pkg2 You may only ship/install outputs that are builtglobal. Outputs are presumed to only be valid if "amidst" dependencies that match the declarations and such they were built against -- i.e. the headers, in C. If you are starting with a minimal install, with just m3core and libm3, then you must buildship and you must do it in dependncy order. It only matters for certain types of changes, and then it can really matter. You might change the format of some compiler-produced runtime-consumed data. You might have a bunch of .sos/.dlls. They can only work with each other if they match in certain ways. Again, ways which don't change that often, but sometimes do -- like changing public types. - 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 rcoleburn at scires.com Sat Jan 19 02:35:55 2008 From: rcoleburn at scires.com (Randy Coleburn) Date: Fri, 18 Jan 2008 20:35:55 -0500 Subject: [M3devel] FW: buildlocal vs. buildglobal vs. buildship explanation In-Reply-To: References: Message-ID: <47910DA8.1E75.00D7.1@scires.com> Jay: I understand the cm3 package and build system. I just didn't know what "buildglobal" meant. >From your explanation, I take it that buildglobal = (cm3 -build) + (cm3 -ship) together on a per package basis. If this is true, then buildglobal == buildship; i.e., there is no difference. You stated that the default of the script is buildlocal and I gather buildlocal = (cm3 -build -override). If so, I now see why I was confused. The default for the compiler is not to include the overrides file (at least that is my recollection from the 4.1 days--maybe its different now). So in my way of thinking, buildlocal = (cm3 -build) without doing any shipping. Perhaps a more self-explanatory option name for (cm3 -build -override) would be "buildoverrides". The system won't let you ship a package built with overrides, so that is why I ran into trouble trying to get everything installed using do-cm3-std without passing the buildship or buildglobal option. I've always liked the cm3 way of having a private source package tree where folks work on the code and then having a separate public package tree where folks "ship" their finished product. Yes, I know you wind up having the code in two places, but then you can "clean" up the derived files in your private tree to save space if needed. The old "reactor" documentation did a fairly good job of explaining the cm3 package concept and the idea of public and private repositories. I'm attempting to convert this document into something we can put back in the cvs repository. I have to take out all the trademarks and replace the graphics etc so it is a painful process without the original electronic source. I've resorted to scanning it in via a scanner and making edits. Regards, Randy >>> Jay 1/18/2008 7:56 PM >>> one more try darnit.... From: jayk123 at hotmail.com To: jayk123 at hotmail.com Subject: buildlocal vs. Date: Sat, 19 Jan 2008 00:55:31 +0000 "Ship" means "Install" Let's say your install is at c:\cm3 and your source is at c:\dev2\cm3 (I would use dev, but Unix took it.) Depending on the state of things, you probably two of many things: c:\cm3\pkg\libm3\nt386\libm3.lib c:\cm3\pkg\libm3\nt386\libm3.dll c:\dev2\cm3\m3-libs\libm3\nt386\libm3.lib c:\dev2\cm3\m3-libs\libm3\nt386\libm3.dll You will have much more in \dev2\cm3\m3-libs\libm3\nt386. When you build stuff, you can use the installed dependencies or the just built dependencies. buildlocal uses the just built dependencies. buildglobal uses the installed dependencies buildship build and ships (installs) each directory It does it one pass: buildship pkg1 pkg1 => build pkg1 ship pkg1 build pkg2 ship pkg2 and NOT build pkg1 build pkg2 ship pkg1 ship pkg2 You may only ship/install outputs that are builtglobal. Outputs are presumed to only be valid if "amidst" dependencies that match the declarations and such they were built against -- i.e. the headers, in C. If you are starting with a minimal install, with just m3core and libm3, then you must buildship and you must do it in dependncy order. It only matters for certain types of changes, and then it can really matter. You might change the format of some compiler-produced runtime-consumed data. You might have a bunch of .sos/.dlls. They can only work with each other if they match in certain ways. Again, ways which don't change that often, but sometimes do -- like changing public types. - Jay 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 jayk123 at hotmail.com Sat Jan 19 03:03:00 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 19 Jan 2008 02:03:00 +0000 Subject: [M3devel] FW: buildlocal vs. buildglobal vs. buildship explanation In-Reply-To: <47910DA8.1E75.00D7.1@scires.com> References: <47910DA8.1E75.00D7.1@scires.com> Message-ID: No electronic source? Wow that stinks. cm3 = cm3 -build = "buildglobal" buildglobal != buildship buildglobal means to build against global, but not to ship It is the normal thing to do, I think, when you aren't changing "too much". If you are building something for which all dependencies have already shipped and aren't changing, a typical little utility. Or if you aren't changing the fingerprints of any public types, I think. Certainly if you are only changing code. Not sure about changing the revelations of partially opaque types. But maybe that's a gross simplification of what kind of development occurs. The doubling is mostly good. It fixes a problem well. However, I have some criticism, perhaps rooted in an inadequate understanding, I admit. 1) the ban on shipping having used overrides seems overly strict -- what if the fingerprints match? 2) perhaps some global fingerprint (hash) can be inserted after TARGET, enabling multiple versions to coexist in the same install root? But maybe that's just what you create a seperate install root for, since, I guess bin has to match pkg, so the whole tree is "ruined" anyway. x/* vs. */x in terms of directory layout. And maybe such a fingerprint would need too many bits to be reliable and then be annoyingly long. 3) This is the one I have the most confident understanding of -- as long as you are shipping "everything" all at once, I think shipping with overrides is just fine. There is a question as to what "everything" is. - Jay Date: Fri, 18 Jan 2008 20:35:55 -0500From: rcoleburn at scires.comTo: m3devel at elegosoft.com; jayk123 at hotmail.comSubject: Re: [M3devel] FW: buildlocal vs. buildglobal vs. buildship explanation Jay: I understand the cm3 package and build system. I just didn't know what "buildglobal" meant. >From your explanation, I take it that buildglobal = (cm3 -build) + (cm3 -ship) together on a per package basis. If this is true, then buildglobal == buildship; i.e., there is no difference. You stated that the default of the script is buildlocal and I gather buildlocal = (cm3 -build -override). If so, I now see why I was confused. The default for the compiler is not to include the overrides file (at least that is my recollection from the 4.1 days--maybe its different now). So in my way of thinking, buildlocal = (cm3 -build) without doing any shipping. Perhaps a more self-explanatory option name for (cm3 -build -override) would be "buildoverrides". The system won't let you ship a package built with overrides, so that is why I ran into trouble trying to get everything installed using do-cm3-std without passing the buildship or buildglobal option. I've always liked the cm3 way of having a private source package tree where folks work on the code and then having a separate public package tree where folks "ship" their finished product. Yes, I know you wind up having the code in two places, but then you can "clean" up the derived files in your private tree to save space if needed. The old "reactor" documentation did a fairly good job of explaining the cm3 package concept and the idea of public and private repositories. I'm attempting to convert this document into something we can put back in the cvs repository. I have to take out all the trademarks and replace the graphics etc so it is a painful process without the original electronic source. I've resorted to scanning it in via a scanner and making edits. Regards, Randy>>> Jay 1/18/2008 7:56 PM >>>one more try darnit.... From: jayk123 at hotmail.comTo: jayk123 at hotmail.comSubject: buildlocal vs.Date: Sat, 19 Jan 2008 00:55:31 +0000 "Ship" means "Install" Let's say your install is at c:\cm3 and your source is at c:\dev2\cm3 (I would use dev, but Unix took it.) Depending on the state of things, you probably two of many things: c:\cm3\pkg\libm3\nt386\libm3.lib c:\cm3\pkg\libm3\nt386\libm3.dll c:\dev2\cm3\m3-libs\libm3\nt386\libm3.lib c:\dev2\cm3\m3-libs\libm3\nt386\libm3.dll You will have much more in \dev2\cm3\m3-libs\libm3\nt386. When you build stuff, you can use the installed dependencies or the just built dependencies. buildlocal uses the just built dependencies. buildglobal uses the installed dependencies buildship build and ships (installs) each directory It does it one pass: buildship pkg1 pkg1 => build pkg1 ship pkg1 build pkg2 ship pkg2 and NOT build pkg1 build pkg2 ship pkg1 ship pkg2 You may only ship/install outputs that are builtglobal. Outputs are presumed to only be valid if "amidst" dependencies that match the declarations and such they were built against -- i.e. the headers, in C. If you are starting with a minimal install, with just m3core and libm3, then you must buildship and you must do it in dependncy order. It only matters for certain types of changes, and then it can really matter. You might change the format of some compiler-produced runtime-consumed data. You might have a bunch of .sos/.dlls. They can only work with each other if they match in certain ways. Again, ways which don't change that often, but sometimes do -- like changing public types. - Jay 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 jayk123 at hotmail.com Sat Jan 19 04:18:16 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 19 Jan 2008 03:18:16 +0000 Subject: [M3devel] NT386GNU diffs In-Reply-To: <4790E7A7.1E75.00D7.1@scires.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> <477EA137.1E75.00D7.1@scires.com> <478D394B.1E75.00D7.1@scires.com> <478D47FB.1E75.00D7.1@scires.com> <478DBF8D.1E75.00D7.1@scires.com> <478DE973.1E75.00D7.1@scires.com> <47908659.1E75.00D7.1@scires.com> <4790E7A7.1E75.00D7.1@scires.com> Message-ID: eh, the diffs are small enough - I commited them. The commit includes a stab at documenting how to build this stuff, but importantly, again, the results don't work.. - Jay From: jayk123 at hotmail.comTo: m3devel at elegosoft.comSubject: NT386GNU diffsDate: Fri, 18 Jan 2008 23:38:45 +0000 I think attached is all the diffs I have for NT386GNU.They are:"rewrite" NT386GNU config fileThe diff and result are present.It almost exactly matches NT386.In fact, the targets can perhaps be merged into one configurable target,and NT386GNU be "reclaimed" for the more Posix port people want.But not right now.setjmp to _setjmpThis "works" with Cygwin and MinGW, whereas setjmp doesn't."Works" as in links. I should double check this. Maybe not needed.Just one line..Changes NT386GNU from Posix to Win32.Any objects to commiting?The result is you can build a lot of NT386GNU, but it won't run.I would say it won't "quite" run, but I can't claim to know all that is wrong.Yes, I understand, getting it to run is very important. This may be progress,but isn't useful yet. - Jay 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 Sat Jan 19 04:29:11 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 19 Jan 2008 03:29:11 +0000 Subject: [M3devel] environment variable names? In-Reply-To: <4790E7A7.1E75.00D7.1@scires.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> <477EA137.1E75.00D7.1@scires.com> <478D394B.1E75.00D7.1@scires.com> <478D47FB.1E75.00D7.1@scires.com> <478DBF8D.1E75.00D7.1@scires.com> <478DE973.1E75.00D7.1@scires.com> <47908659.1E75.00D7.1@scires.com> <4790E7A7.1E75.00D7.1@scires.com> Message-ID: Approximately one of these I introduced an therefore might not be in the *.sh.Otherwise I believe these are all NOT my invention, and supported same/similarfor *.sh and *.py. *.cmd lags behind maybe. CM3_ROOT or ROOT is the root of the sourcescripts figures this out basedDOes anyone mind that it doesn't say "SOURCE", e.g. CM3_SOURCE_ROOT? I just introduced this recently: OPTIONALLY there is one generic cm3.cfg, m3-sys\cminstall\src\config\cm3.cfg, that delegates back to the live configuration files in that same directory. That file cannot determine this itself. If you cd around and run cm3, without using do-pkg etc., and you use this new cm3.cfg, you need to set CM3_ROOT or ROOT. CM3_INSTALL or INSTALLROOT are the root of the installed CM3. DOes any mind that the first one doesn't say "ROOT"? e.g. CM3_INSTALL_ROOT? CM3_TARGET or TARGET The target, duh. cm3.cfg sniffs this if $OS == NT386, otherwise not. Does any else mind that such generic global environment variables are queried? ROOT, INSTALLROOT, TARGET? It SEEMS TO ME, the ideal choices would be: CM3_INSTALL_ROOT CM3_SOURCE_ROOT or maybe just CM3_ROOT asis, hey, source is king, source is implied CM3_TARGET and no others. The Quake/.sh/.py code can use whatever it wants internally. It should probably just be left alone but I have to express my perfectionist opinion. :) I am tempted to drop the shorter names from the *.py though, which does make *.py and *.sh a bit less compatible. The scripts could/should also copy one to other for compat (esp. with older builds), reducing any affect here, but that saves people from polluting their global environment at least. ?? - 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 rcoleburn at scires.com Sat Jan 19 06:31:21 2008 From: rcoleburn at scires.com (Randy Coleburn) Date: Sat, 19 Jan 2008 00:31:21 -0500 Subject: [M3devel] pixmap problem Message-ID: <479144D6.1E75.00D7.1@scires.com> I've attached a small zip file containing a simple test program. On Windows XP using the current cm3 from the repository I get the following behavior: a) when the buildstandalone() line is commented out in the m3makefile, the pixmap is rendered poorly on the screen. It has gray streaked lines through it. b) when the buildstandalone() directive is used in the m3makefile, the pixmap is rendered properly on the screen. This program uses pixmaps and bundles. I'm also seeing some problems with bundles, so the two problems may be related, but I'm not sure. Would some of the other developers mind running this simple test program on their platforms and reporting the results. I'd like to know if the problem is limited to Windows NT386 platform, or if it occurs on others. Thanks, Randy Coleburn -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: TestPixmap.zip Type: application/x-zip-compressed Size: 4870 bytes Desc: not available URL: From jayk123 at hotmail.com Sat Jan 19 06:46:37 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 19 Jan 2008 05:46:37 +0000 Subject: [M3devel] strange code? Message-ID: I'm comparing the output of the two backends, since I haven't figured out many gdb commands yet. Well darn the code looks semantically the same around the crash so I'll have to dig differently. Still, why does it bump the stack extra like this: subl $8, %esp <== pushl %eax pushl %edx call _RTLinker__TraceModule addl $16, %esp <== the other backend uses 8 here subl $12, %esp <== pushl $0 call *%eax addl $16, %esp <== the other uses 4 Is it trying to keep the stack 16-aligned? - 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 hosking at cs.purdue.edu Sat Jan 19 09:09:47 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 19 Jan 2008 03:09:47 -0500 Subject: [M3devel] pixmap problem In-Reply-To: <479144D6.1E75.00D7.1@scires.com> References: <479144D6.1E75.00D7.1@scires.com> Message-ID: <0CF197B5-1ADA-4955-904A-7B4ABACE7652@cs.purdue.edu> Looks fine to me on I386_DARWIN. On Jan 19, 2008, at 12:31 AM, Randy Coleburn wrote: > From hosking at cs.purdue.edu Sat Jan 19 09:12:12 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 19 Jan 2008 03:12:12 -0500 Subject: [M3devel] strange code? In-Reply-To: References: Message-ID: Yes, indeed. I believe gcc will try to keep the stack 16-byte aligned. I seem to recall that there are alignment configuration values in the compiler that might cause a crash if set wrong. On Jan 19, 2008, at 12:46 AM, Jay wrote: > I'm comparing the output of the two backends, since I haven't > figured out many gdb commands yet. > Well darn the code looks semantically the same around the crash so > I'll have to dig differently. > > Still, why does it bump the stack extra like this: > > subl $8, %esp <== > pushl %eax > pushl %edx > call _RTLinker__TraceModule > addl $16, %esp <== the other backend uses 8 here > > > subl $12, %esp <== > pushl $0 > call *%eax > addl $16, %esp <== the other uses 4 > > Is it trying to keep the stack 16-aligned? > > - 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 Sat Jan 19 09:52:08 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 19 Jan 2008 08:52:08 +0000 Subject: [M3devel] pixmap problem In-Reply-To: <0CF197B5-1ADA-4955-904A-7B4ABACE7652@cs.purdue.edu> References: <479144D6.1E75.00D7.1@scires.com> <0CF197B5-1ADA-4955-904A-7B4ABACE7652@cs.purdue.edu> Message-ID: I can repro the two different behaviors on XP. I was going to try on PPC_DARWIN but I guess Tony's info suffices. I tried rolling hand.c back to before I changed (months/year ago), since it is involved in bit twiddling, no change, phew. Debugging here is a big humungous pain. NT386 has good stacks and line numbers, but no locals or type info, I'd really sometime like to get Codeview info into those .objs...I think it is documented well enough, but still not necessarily easy, or maybe have a C generating backend partly for this reason (and to bring up more targets, using native tools), and function calls in disassembly I think don't resolve; NT386GNU can't yet build this, though it will soon, but I'm not familiar with gdb and there appears to be no type info. I'm building m3gdb right now, I don't know if it will work, I hope it has type info, and I'm not familiar with the relevant code. In gdb I struggle just to view bytes in memory, add numbers to addresses and see those, etc. I think for MY problem, I'm going to link in C code to dump the structs. There is tracing code and I enabled it, but even it crashes in Text_Length. At least MY problem crashes, hopefully near the problem, whereas your problem goes all the way through to completion with no stopping to hint where the problem is. Darn it. :) on the mock rudeness and :( on the lack of a crash. You write the bundle out and it matches, so that doesn't rule out bundles as being the problem? (darn) And bundles look pretty simple, a bundle is just a generated source file with a constant in it. Maybe newline problems? That wouldn't make sense. I just downloaded some program that might let me separately view the ppm, maybe it'll reveal something. The bad behavior has like regularly spaced solid color veritical bars a few pixels side across the whole picture, and regularly spaced vertical stripes from the correct picture alternating with that. Perhaps someone with ppm/bitmap/graphics experience has seen this behavior and it results from some common pixmap mismanagement we could look for? I have to say this is very surprising. I always wondered, and now I pretty much assume -- Modula-3 never imports/exports data in its dynamic linking, right? It alway imports/exports functions, right? On Windows, functions have an optional optimization, but data must be handled differently at compile time if it is going to be dynamically imported. For functions, if you don't apply the optimization at compile time, the linker will just generate a single instruction thunk instead. That is, given a symbol Foo, there is a symbol __imp__Foo that is a pointer to the actual foo in another .dll/.so. The loader only patches pointers, one per import if you build your .dll correctly, it doesn't patch instructions or code strewn throughout a .dll, just one contiguous array of pointers. MAYBE they don't have to be contiguous for each .dl you import from. That is, if call msvcrt!fopen, msvcrt!fclose, kernel32!Sleep, my .dll/.exe typically has an array: pointer to msvcrt!fopen pointer to msvcrt!fclose null pointer to kernel32!Sleep But perhaps kernel32.dll's pointers and msvcrt.dll's pointers need not be adjacent. So, going back, my point/question is that, if the compiler knows the function is imported, it can call through __imp__Foo instead of calling Foo. But if it calls Foo and you import Foo, the linker will create the function Foo that just jmps through __imp__Foo. That doesn't work for data though. There's no ability to intervenve like that. So for imported data, the compiler must generated a read and dereference of the pointer __imp__Foo for accesses to Foo, if Foo is to be imported. Data imports may be faster when appropriate, but for this reason, I'd say they aren't worth it. And for this reason, I HOPE Modula-3 never imports/exports data. Oh, you could, for data, always reference the pointer __imp_Foo, and if non materializes, create one. However that would suck perf in order to make an uncommon case work. I hope Modula-3 doesn't do that either. :) Though I guess since this global data in question...maybe it is rare??? Later, - Jay > From: hosking at cs.purdue.edu> Date: Sat, 19 Jan 2008 03:09:47 -0500> To: rcoleburn at scires.com> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] pixmap problem> > Looks fine to me on I386_DARWIN.> > On Jan 19, 2008, at 12:31 AM, Randy Coleburn wrote:> > > > _________________________________________________________________ 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 Jan 19 09:55:12 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 19 Jan 2008 08:55:12 +0000 Subject: [M3devel] pixmap problem In-Reply-To: References: <479144D6.1E75.00D7.1@scires.com> <0CF197B5-1ADA-4955-904A-7B4ABACE7652@cs.purdue.edu> Message-ID: and then wouldn't you know...the end of gdb building looks like: Info: resolving _LINES by linking to __imp__LINES (auto-import)Info: resolving _COLS by linking to __imp__COLS (auto-import)Info: resolving _stdscr by linking to __imp__stdscr (auto-import)Info: resolving _curscr by linking to __imp__curscr (auto-import)make[3]: Entering directory `/cygdrive/c/dev2/cm3.2/m3-sys/m3gdb/NT386GNU/gdb'make[4]: Entering directory `/cygdrive/c/dev2/cm3.2/m3-sys/m3gdb/NT386GNU/gdb/doc'make[4]: Nothing to be done for `all'.make[4]: Leaving directory `/cygdrive/c/dev2/cm3.2/m3-sys/m3gdb/NT386GNU/gdb/doc'make[3]: Leaving directory `/cygdrive/c/dev2/cm3.2/m3-sys/m3gdb/NT386GNU/gdb'make[2]: Leaving directory `/cygdrive/c/dev2/cm3.2/m3-sys/m3gdb/NT386GNU/gdb'make[1]: Leaving directory `/cygdrive/c/dev2/cm3.2/m3-sys/m3gdb/NT386GNU'make[1]: Entering directory `/cygdrive/c/dev2/cm3.2/m3-sys/m3gdb/NT386GNU'make[1]: Nothing to be done for `all-target'.make[1]: Leaving directory `/cygdrive/c/dev2/cm3.2/m3-sys/m3gdb/NT386GNU' Fatal Error: unable to copy "gdb/gdb" to "m3gdb": ErrorCode=2: The system cannot find the file specified. ###################### LINK_FILE: ################## But I don't see any errros before that...I think I'm just forgetting to append .exe. - Jay From: jayk123 at hotmail.comSo for imported data, the compiler must generated a read and dereference of the pointer __imp__Foo for accesses to Foo, if Foo is to be imported.Data imports may be faster when appropriate, but for this reason, I'd say they aren't worth it.And for this reason, I HOPE Modula-3 never imports/exports data. Oh, you could, for data, always reference the pointer __imp_Foo, and if non materializes, create one.However that would suck perf in order to make an uncommon case work.I hope Modula-3 doesn't do that either. :)Though I guess since this global data in question...maybe it is rare??? Later, - 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 Sat Jan 19 12:02:59 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 19 Jan 2008 11:02:59 +0000 Subject: [M3devel] more assembly symbols please? Message-ID: Any chance the m3cg output could have, um, some symbols for the global data? It's kind of a pain to decode.. The module/import info is ok a lot, lots of runtime links ok. I think the bad one might be RTHeapInfo but I have to decode the very bare of symbols assembly.. or comments? Like for record fields? Still thinking of sticking a call out to C code...Even OutputDebugString since RTIO isn't working... I looked through the m3cg --help, didn't find anything. Tony? _MM_RTHeapInfo:0 .long _L_1+224 4 .long _MM_RTHeapInfo+528 .long _MM_RTHeapInfo+30812,16 .space 820 .long _L_1+15224 .space 428 .long _L_1+22032 .long _L_1+22036 .long _MM_RTHeapInfo+16040 .space 4 .long _RTHeapInfo_M3 I get to count out to 160 bytes from here..: _L_1:0 .byte 481 .byte 492 .byte 503 .byte 514 .byte 525 .byte 536 .byte 547 .byte 558 .byte 569 .byte 57a .byte 97b .byte 98c .byte 99d .byte 100e .byte 101f .byte 10210 .long _RTHooks__TextLitInfo14 .long _RTHooks__TextLitGetChar18 .long _RTHooks__TextLitGetWideChar1c .long _RTHooks__TextLitGetChars20 .long _RTHooks__TextLitGetWideChars24 .long 228 .long _L_1+162c .long 730 .ascii "shownew"37 .space 138 .long 23c .long _L_1+1640 .long 644 .ascii "update"4a .space 24c .ascii "RTHeapInfo_M3"50 .space 1 .ascii "Init" .space 1 I'll try the C code.. - 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 Sat Jan 19 12:08:19 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 19 Jan 2008 11:08:19 +0000 Subject: [M3devel] more assembly symbols please? In-Reply-To: References: Message-ID: oh I've got two better ideas 1) move RTIO ahead of RTHeapInfo, or earlier, in the unit list 2) paste the RTIO code into RTLinker so calling it doesn't depend on linking!And now I see the command line check for tracing comes after some linking, for good reason. I had set the global to true in the source, and that is probably bad. I'm not sure though within a module if the linking is needed, or if it is only for cross-module references.. - Jay From: jayk123 at hotmail.comTo: m3devel at elegosoft.comDate: Sat, 19 Jan 2008 11:02:59 +0000Subject: [M3devel] more assembly symbols please? Any chance the m3cg output could have, um, some symbols for the global data?It's kind of a pain to decode.. The module/import info is ok a lot, lots of runtime links ok.I think the bad one might be RTHeapInfo but I have to decode the very bare of symbols assembly..or comments? Like for record fields?Still thinking of sticking a call out to C code...Even OutputDebugString since RTIO isn't working... I looked through the m3cg --help, didn't find anything. Tony? _MM_RTHeapInfo:0 .long _L_1+224 4 .long _MM_RTHeapInfo+528 .long _MM_RTHeapInfo+30812,16 .space 820 .long _L_1+15224 .space 428 .long _L_1+22032 .long _L_1+22036 .long _MM_RTHeapInfo+16040 .space 4 .long _RTHeapInfo_M3I get to count out to 160 bytes from here..: _L_1:0 .byte 481 .byte 492 .byte 503 .byte 514 .byte 525 .byte 536 .byte 547 .byte 558 .byte 569 .byte 57a .byte 97b .byte 98c .byte 99d .byte 100e .byte 101f .byte 10210 .long _RTHooks__TextLitInfo14 .long _RTHooks__TextLitGetChar18 .long _RTHooks__TextLitGetWideChar1c .long _RTHooks__TextLitGetChars20 .long _RTHooks__TextLitGetWideChars24 .long 228 .long _L_1+162c .long 730 .ascii "shownew"37 .space 138 .long 23c .long _L_1+1640 .long 644 .ascii "update"4a .space 24c .ascii "RTHeapInfo_M3"50 .space 1 .ascii "Init" .space 1I'll try the C code.. - Jay Connect and share in new ways with Windows Live. Get it 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 jayk123 at hotmail.com Sat Jan 19 12:32:21 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 19 Jan 2008 11:32:21 +0000 Subject: [M3devel] more assembly symbols please? In-Reply-To: References: Message-ID: duh, finally, got it. parameters being passed in the wrong order -- left to right instead of right to left. should have read the assembly of some multi parameter function calls... PROCEDURE RTLinker_PutInt (i: INTEGER; width := 0) = VAR num : ARRAY [0..30] OF CHAR; len := FromInt (ADR (num[0]), i, 10); BEGIN FOR i := 1 TO width - len DO PutChar (' ') END; PutChars (ADR (num[0]), len); END RTLinker_PutInt;Dump of assembler code for function RTLinker__RTLinker_PutInt:0x005de25f : push %ebp0x005de260 : mov %esp,%ebp0x005de262 : sub $0x38,%esp0x005de265 : mov 0x8(%ebp),%edx0x005de268 : sub $0x4,%esp0x005de26b : lea 0xffffffd9(%ebp),%eax0x005de26e : push %eax0x005de26f : push %edx0x005de270 : push $0xa0x005de272 : call 0x5de345 and I AVed writing to the address 0xA.. - 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 Sat Jan 19 15:33:08 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 19 Jan 2008 14:33:08 +0000 Subject: [M3devel] link info still bad. In-Reply-To: References: Message-ID: clarification -- RTLinker still crashes. I put in C code to dump, since it crashes before its own printing would work.A bunch works and then: Module 00682020 ..\src\runtime\common\RTHeapInfo.m3 Imports 006820C0{Import 00000000, Binder 00000000, Next 00603FD0} and then the dumper AV's because the next pointer is bad. 0:000> dc 00603FD000603fd0 8be58955 c0b80845 c900682a 909090c3 U...E...*h......00603fe0 8be58955 80b80845 c900682b e58955c3 U...E...+h...U..00603ff0 ec835657 08458b20 8904c083 2be8a1c2 WV.. .E........+00604000 f4050068 8b000000 dc7d8d00 b8fcc689 h.........}.....00604010 00000007 a5f3c189 758dd789 07b8fcdc ...........u....00604020 89000000 83a5f3c1 5f5e20c4 9090c3c9 ......... ^_....00604030 8be58955 60b80845 c900682c 909090c3 U...E..`,h......00604040 8be58955 00b80845 c900682d 909090c3 U...E...-h...... anything over 0x80000000, or depending on configuration, 0xc0000000, is an invalid user mode pointer on 32bit NT. The address space is usually split 2gig/2gig, the upper 2gig is the kernel memory, the same mappings system side. There is an option to make it 3gig/1gig. If anyone has any hints, please tell me, thanks. If anyone else can build this stuff...? I can commit the printing to be only on this platform... The assembly code output by cm3cg is much harder to read than it should be, even for assembly language.. :( Attached. - Jay From: jayk123 at hotmail.comTo: m3devel at elegosoft.comSubject: RE: [M3devel] more assembly symbols please?Date: Sat, 19 Jan 2008 11:32:21 +0000 duh, finally, got it. parameters being passed in the wrong order -- left to right instead of right to left.should have read the assembly of some multi parameter function calls... PROCEDURE RTLinker_PutInt (i: INTEGER; width := 0) = VAR num : ARRAY [0..30] OF CHAR; len := FromInt (ADR (num[0]), i, 10); BEGIN FOR i := 1 TO width - len DO PutChar (' ') END; PutChars (ADR (num[0]), len); END RTLinker_PutInt;Dump of assembler code for function RTLinker__RTLinker_PutInt:0x005de25f : push %ebp0x005de260 : mov %esp,%ebp0x005de262 : sub $0x38,%esp0x005de265 : mov 0x8(%ebp),%edx0x005de268 : sub $0x4,%esp0x005de26b : lea 0xffffffd9(%ebp),%eax0x005de26e : push %eax0x005de26f : push %edx0x005de270 : push $0xa0x005de272 : call 0x5de345 and I AVed writing to the address 0xA.. - 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: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: RTHeapIn.ms URL: From dabenavidesd at yahoo.es Sat Jan 19 17:54:00 2008 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Sat, 19 Jan 2008 17:54:00 +0100 (CET) Subject: [M3devel] pixmap problem In-Reply-To: Message-ID: <235688.77597.qm@web27110.mail.ukl.yahoo.com> Hi: The TestPixmap does show a nice battery on LINUXLIBC6, Ubuntu Gutsy 2.6.22-14-386, 32 bits machine. Thanks Jay wrote: .hmmessage P { margin:0px; padding:0px } body.hmmessage { FONT-SIZE: 10pt; FONT-FAMILY:Tahoma } I can repro the two different behaviors on XP. I was going to try on PPC_DARWIN but I guess Tony's info suffices. I tried rolling hand.c back to before I changed (months/year ago), since it is involved in bit twiddling, no change, phew. Debugging here is a big humungous pain. NT386 has good stacks and line numbers, but no locals or type info, I'd really sometime like to get Codeview info into those .objs...I think it is documented well enough, but still not necessarily easy, or maybe have a C generating backend partly for this reason (and to bring up more targets, using native tools), and function calls in disassembly I think don't resolve; NT386GNU can't yet build this, though it will soon, but I'm not familiar with gdb and there appears to be no type info. I'm building m3gdb right now, I don't know if it will work, I hope it has type info, and I'm not familiar with the relevant code. In gdb I struggle just to view bytes in memory, add numbers to addresses and see those, etc. I think for MY problem, I'm going to link in C code to dump the structs. There is tracing code and I enabled it, but even it crashes in Text_Length. At least MY problem crashes, hopefully near the problem, whereas your problem goes all the way through to completion with no stopping to hint where the problem is. Darn it. :) on the mock rudeness and :( on the lack of a crash. You write the bundle out and it matches, so that doesn't rule out bundles as being the problem? (darn) And bundles look pretty simple, a bundle is just a generated source file with a constant in it. Maybe newline problems? That wouldn't make sense. I just downloaded some program that might let me separately view the ppm, maybe it'll reveal something. The bad behavior has like regularly spaced solid color veritical bars a few pixels side across the whole picture, and regularly spaced vertical stripes from the correct picture alternating with that. Perhaps someone with ppm/bitmap/graphics experience has seen this behavior and it results from some common pixmap mismanagement we could look for? I have to say this is very surprising. I always wondered, and now I pretty much assume -- Modula-3 never imports/exports data in its dynamic linking, right? It alway imports/exports functions, right? On Windows, functions have an optional optimization, but data must be handled differently at compile time if it is going to be dynamically imported. For functions, if you don't apply the optimization at compile time, the linker will just generate a single instruction thunk instead. That is, given a symbol Foo, there is a symbol __imp__Foo that is a pointer to the actual foo in another .dll/.so. The loader only patches pointers, one per import if you build your .dll correctly, it doesn't patch instructions or code strewn throughout a .dll, just one contiguous array of pointers. MAYBE they don't have to be contiguous for each .dl you import from. That is, if call msvcrt!fopen, msvcrt!fclose, kernel32!Sleep, my .dll/.exe typically has an array: pointer to msvcrt!fopen pointer to msvcrt!fclose null pointer to kernel32!Sleep But perhaps kernel32.dll's pointers and msvcrt.dll's pointers need not be adjacent. So, going back, my point/question is that, if the compiler knows the function is imported, it can call through __imp__Foo instead of calling Foo. But if it calls Foo and you import Foo, the linker will create the function Foo that just jmps through __imp__Foo. That doesn't work for data though. There's no ability to intervenve like that. So for imported data, the compiler must generated a read and dereference of the pointer __imp__Foo for accesses to Foo, if Foo is to be imported. Data imports may be faster when appropriate, but for this reason, I'd say they aren't worth it. And for this reason, I HOPE Modula-3 never imports/exports data. Oh, you could, for data, always reference the pointer __imp_Foo, and if non materializes, create one. However that would suck perf in order to make an uncommon case work. I hope Modula-3 doesn't do that either. :) Though I guess since this global data in question...maybe it is rare??? Later, - Jay --------------------------------- > From: hosking at cs.purdue.edu > Date: Sat, 19 Jan 2008 03:09:47 -0500 > To: rcoleburn at scires.com > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] pixmap problem > > Looks fine to me on I386_DARWIN. > > On Jan 19, 2008, at 12:31 AM, Randy Coleburn wrote: > > > > --------------------------------- Need to know the score, the latest news, or you need your Hotmail?-get your "fix" Check it out. --------------------------------- Web Revelaci?n Yahoo! 2007: Premio Favorita del P?blico - ?Vota tu preferida! -------------- next part -------------- An HTML attachment was scrubbed... URL: From hendrik at topoi.pooq.com Sat Jan 19 18:30:02 2008 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Sat, 19 Jan 2008 12:30:02 -0500 Subject: [M3devel] new name for "reactor" In-Reply-To: <4790892B.1E75.00D7.1@scires.com> References: <4790892B.1E75.00D7.1@scires.com> Message-ID: <20080119173002.GB32561@topoi.pooq.com> On Fri, Jan 18, 2008 at 11:10:38AM -0500, Randy Coleburn wrote: > > Originally, I chose the name "CM3-IDE" for CM3 Integrated Development Environment, but this name isn't very catchy. Actually, CM3-IDE (or perhaps better cm3-ide) isn't bad -- it makes it completely clear what the package is. cm3-catalyst makes people wonder what it does, whether they need it, and whether they should spend disk space to install it. -- hendrik From hosking at cs.purdue.edu Sat Jan 19 18:33:08 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 19 Jan 2008 12:33:08 -0500 Subject: [M3devel] more assembly symbols please? In-Reply-To: References: Message-ID: <2717B275-2548-41BC-BD1E-8742BCE6FA51@cs.purdue.edu> Take a look at the .mc intermediate code output if you want to see that section of the data. There are at least comments. Use m3cgcat - binary < x.mc > x.mo to view it (You can run m3cgcat on any other CM3 install). On Jan 19, 2008, at 6:02 AM, Jay wrote: > Any chance the m3cg output could have, um, some symbols for the > global data? > It's kind of a pain to decode.. > > The module/import info is ok a lot, lots of runtime links ok. > I think the bad one might be RTHeapInfo but I have to decode the > very bare of symbols assembly.. > or comments? Like for record fields? > Still thinking of sticking a call out to C code...Even > OutputDebugString since RTIO isn't working... > > I looked through the m3cg --help, didn't find anything. > > Tony? > > _MM_RTHeapInfo: > 0 .long _L_1+224 > 4 .long _MM_RTHeapInfo+52 > 8 .long _MM_RTHeapInfo+308 > 12,16 .space 8 > 20 .long _L_1+152 > 24 .space 4 > 28 .long _L_1+220 > 32 .long _L_1+220 > 36 .long _MM_RTHeapInfo+160 > 40 .space 4 > .long _RTHeapInfo_M3 > > I get to count out to 160 bytes from here..: > > _L_1: > 0 .byte 48 > 1 .byte 49 > 2 .byte 50 > 3 .byte 51 > 4 .byte 52 > 5 .byte 53 > 6 .byte 54 > 7 .byte 55 > 8 .byte 56 > 9 .byte 57 > a .byte 97 > b .byte 98 > c .byte 99 > d .byte 100 > e .byte 101 > f .byte 102 > 10 .long _RTHooks__TextLitInfo > 14 .long _RTHooks__TextLitGetChar > 18 .long _RTHooks__TextLitGetWideChar > 1c .long _RTHooks__TextLitGetChars > 20 .long _RTHooks__TextLitGetWideChars > 24 .long 2 > 28 .long _L_1+16 > 2c .long 7 > 30 .ascii "shownew" > 37 .space 1 > 38 .long 2 > 3c .long _L_1+16 > 40 .long 6 > 44 .ascii "update" > 4a .space 2 > 4c .ascii "RTHeapInfo_M3" > 50 .space 1 > .ascii "Init" > .space 1 > > I'll try the C code.. > > - Jay > > > > > > Connect and share in new ways with Windows Live. Get it now! From hosking at cs.purdue.edu Sat Jan 19 18:43:16 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 19 Jan 2008 12:43:16 -0500 Subject: [M3devel] new name for "reactor" In-Reply-To: <20080119173002.GB32561@topoi.pooq.com> References: <4790892B.1E75.00D7.1@scires.com> <20080119173002.GB32561@topoi.pooq.com> Message-ID: <8BE9BB1C-5120-4D4E-AEC1-FE1BBF729AA4@cs.purdue.edu> I second this opinion: On Jan 19, 2008, at 12:30 PM, hendrik at topoi.pooq.com wrote: >> Actually, CM3-IDE (or perhaps better cm3-ide) isn't bad -- it >> makes it > completely clear what the package is. cm3-catalyst makes people > wonder > what it does, whether they need it, and whether they should spend disk > space to install it. > > -- hendrik From hosking at cs.purdue.edu Sat Jan 19 18:48:06 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 19 Jan 2008 12:48:06 -0500 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <20080119031134.4B6A510D4625@birch.elegosoft.com> References: <20080119031134.4B6A510D4625@birch.elegosoft.com> Message-ID: So, I am very confused now. Does NT386GNU no longer mean use of the full set of GNU tools m3cc/ld/as, as would be available under Cygwin? I thought the point of this was to be able to run in as much of a GNU environment as possible. GNU to me means the whole toolsuite not just m3cc. To me, a GNU-based environment on Windows holds great attraction, since it consists of tools that I generally always install on Windows, that I know, and are similar to the other platforms I use. On Jan 19, 2008, at 4:11 AM, Jay Krell wrote: > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 08/01/19 04:11:34 > > Modified files: > cm3/m3-libs/m3core/src/runtime/: m3makefile > cm3/m3-sys/cminstall/src/config/: NT386GNU > cm3/m3-sys/m3front/src/builtinInfo/: InfoModule.m3 > cm3/m3-sys/m3middle/src/: Target.m3 > > Log message: > m3-sys/m3middle/src/Target.m3 > m3-libs/m3core/src/runtime/m3makefile > m3-sys\m3front\src\builtinInfo\InfoModule.m3 > > switch NT386GNU to be Win32 instead of POSIX > switch NT386GNU to _setjmp instead of setjmp > jmp_buf size still big like Cygwin > rewrite NT386GNU config file -- almost identical to NT386 > mingwin required for building Modula-3 programs > mingwin AND msys required for building m3cc > > To boot: > > install Python (www.activestate.com) > > have a working NT386 system > get current source > Mine is at c:\dev2\cm3.2 (cm3 is has other paused work, dev was > taken by Unix) > > get and install binary distribution (5.1.3 works, anything newer > should work) > I install to c:\cm3 > copy %CVSROOT%\m3-sys\cminstall\src\config\cm3.cfg to \cm3\bin > \cm3.cfg > > Have a Visual C++ toolset (cl and link) > and run the vcvars link on the start menu (this can/will be made > easier) > Almost any version should work. > if you are using Visual C++ 8.0 (RTM?), rename away its mt.exe > and get a newer from such as from the Platform SDK. Otherwise it > crashes. > This is not specific to NT386GNU, just that I recently removed the > Platform SDK > from my %PATH%. > > cd %CVSROOT%\scripts\python > .\upgrade > > install msys and mingwin from http://www.mingw.org (links to > SourceForge) > for mingwin, you only need the "base" > msys tells you to avoid mingwin make, in favor of msys make, and I > did that > > I install to the defaults > c:\msys\1.0 > c:\mingw > > if you don't install to the defaults, add > \bin and to the start, but which order between the two?) > > if you do install to the defaults, scripts\python will fix path > for you, > if there is no gcc/as/sh on our $PATH > > cd %CVSROOT%\scripts\python > upgrade && bootntgnu > > NOTE THE RESULTING BINARIES DO NOT YET WORK, but this is still > progress. > > These instructions inevitably to be further tested and refined and > placed elsewhere! From jayk123 at hotmail.com Sat Jan 19 19:32:35 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 19 Jan 2008 18:32:35 +0000 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: References: <20080119031134.4B6A510D4625@birch.elegosoft.com> Message-ID: It DOES use m3cc/ld/as, and mklib for building static .libs, though that could probably be gcc/ar/dlltools if I figured it out. "Everything" except m3cc/m3gdb can be built with just MinGWin. Building m3cc requires MSys as well. Building m3gdb requires Cygwin. m3cg is not dependent on cygwin1.dll, nor are any other Modula-3 outputs. m3gdb is dependent on cygwin1.dll. Using Cygwin probably would work..and I could try it to see if it resolves the RTLinker problem. As well, we could have something like, in cm3.cfg you could set MINGWIN_ROOT, MSYS_ROOT, and/or CYGWIN_ROOT, to guide what tools are used, OR we can have some variable: GNU_MODE = 0 % Do not use GNU tools at all -- today's NT386 GNU_MODE = 1 % Use GNU tools minimally -- today's NT386GNU GNU_MODE = 2 % Use GNU tools maximally -- not existant but probably easy Eh..I know, not great.. what do "minimally" and "maximally" mean. I think we have the problem of a) many viable choices b) want to make several of them available c) just don't know what to call things and what the interface should be. As well as an interop question, since jmpbuf does vary in size between cygwin1.dl and everything else. Further down the line, there are other linkers, other compilers, other runtimes. The design here and now might take them into consideration. Gasp..I just realized, there is also another good backend option. parse.c's approach could probably be adapted to Open Watcom AND they might even take the changes (not that I have asked, I just thought of this). And that would net you progress toward a) 32 bit MS-DOS target b) OS/2 target, c) Netware target d) gcc-free Linux target, since the support all of them. Other target possibilities include Digital Mars compiler/linker, CodeWarrior (I know, dead and all), etc. Open Watcom is probably the most interesting since it is open source... - Jay > From: hosking at cs.purdue.edu> Date: Sat, 19 Jan 2008 12:48:06 -0500> To: jkrell at elego.de> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] [M3commit] CVS Update: cm3> > So, I am very confused now. Does NT386GNU no longer mean use of the > full set of GNU tools m3cc/ld/as, as would be available under > Cygwin? I thought the point of this was to be able to run in as much > of a GNU environment as possible. GNU to me means the whole > toolsuite not just m3cc. To me, a GNU-based environment on Windows > holds great attraction, since it consists of tools that I generally > always install on Windows, that I know, and are similar to the other > platforms I use.> > On Jan 19, 2008, at 4:11 AM, Jay Krell wrote:> > > CVSROOT: /usr/cvs> > Changes by: jkrell at birch. 08/01/19 04:11:34> >> > Modified files:> > cm3/m3-libs/m3core/src/runtime/: m3makefile> > cm3/m3-sys/cminstall/src/config/: NT386GNU> > cm3/m3-sys/m3front/src/builtinInfo/: InfoModule.m3> > cm3/m3-sys/m3middle/src/: Target.m3> >> > Log message:> > m3-sys/m3middle/src/Target.m3> > m3-libs/m3core/src/runtime/m3makefile> > m3-sys\m3front\src\builtinInfo\InfoModule.m3> > > > switch NT386GNU to be Win32 instead of POSIX> > switch NT386GNU to _setjmp instead of setjmp> > jmp_buf size still big like Cygwin> > rewrite NT386GNU config file -- almost identical to NT386> > mingwin required for building Modula-3 programs> > mingwin AND msys required for building m3cc> > > > To boot:> > > > install Python (www.activestate.com)> > > > have a working NT386 system> > get current source> > Mine is at c:\dev2\cm3.2 (cm3 is has other paused work, dev was > > taken by Unix)> > > > get and install binary distribution (5.1.3 works, anything newer > > should work)> > I install to c:\cm3> > copy %CVSROOT%\m3-sys\cminstall\src\config\cm3.cfg to \cm3\bin > > \cm3.cfg> > > > Have a Visual C++ toolset (cl and link)> > and run the vcvars link on the start menu (this can/will be made > > easier)> > Almost any version should work.> > if you are using Visual C++ 8.0 (RTM?), rename away its mt.exe> > and get a newer from such as from the Platform SDK. Otherwise it > > crashes.> > This is not specific to NT386GNU, just that I recently removed the > > Platform SDK> > from my %PATH%.> > > > cd %CVSROOT%\scripts\python> > .\upgrade> > > > install msys and mingwin from http://www.mingw.org (links to > > SourceForge)> > for mingwin, you only need the "base"> > msys tells you to avoid mingwin make, in favor of msys make, and I > > did that> > > > I install to the defaults> > c:\msys\1.0> > c:\mingw> > > > if you don't install to the defaults, add> > \bin and > to the start, but which order between the two?)> > > > if you do install to the defaults, scripts\python will fix path > > for you,> > if there is no gcc/as/sh on our $PATH> > > > cd %CVSROOT%\scripts\python> > upgrade && bootntgnu> > > > NOTE THE RESULTING BINARIES DO NOT YET WORK, but this is still > > progress.> > > > These instructions inevitably to be further tested and refined and > > placed elsewhere!> _________________________________________________________________ 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 Jan 19 19:35:09 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 19 Jan 2008 18:35:09 +0000 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: References: <20080119031134.4B6A510D4625@birch.elegosoft.com> Message-ID: ps -- look at m3-sys/cminstall/src/config/NT386GNU. While it is very very similar to NT386, and even outputs foo.lib and foo.lib.sa like NT386, it uses gcc for C compilation, linking, and m3cg for the backend. It is very "GNU" in tools, but not runtime. - Jay From: jayk123 at hotmail.comTo: hosking at cs.purdue.edu; jkrell at elego.deCC: m3devel at elegosoft.comSubject: RE: [M3devel] [M3commit] CVS Update: cm3Date: Sat, 19 Jan 2008 18:32:35 +0000 It DOES use m3cc/ld/as, and mklib for building static .libs, though that could probably be gcc/ar/dlltools if I figured it out."Everything" except m3cc/m3gdb can be built with just MinGWin.Building m3cc requires MSys as well.Building m3gdb requires Cygwin.m3cg is not dependent on cygwin1.dll, nor are any other Modula-3 outputs. m3gdb is dependent on cygwin1.dll. Using Cygwin probably would work..and I could try it to see if it resolves the RTLinker problem. As well, we could have something like, in cm3.cfg you could set MINGWIN_ROOT, MSYS_ROOT, and/or CYGWIN_ROOT, to guide what tools are used, OR we can have some variable: GNU_MODE = 0 % Do not use GNU tools at all -- today's NT386GNU_MODE = 1 % Use GNU tools minimally -- today's NT386GNUGNU_MODE = 2 % Use GNU tools maximally -- not existant but probably easy Eh..I know, not great.. what do "minimally" and "maximally" mean. I think we have the problem of a) many viable choices b) want to make several of them available c) just don't know what to call things and what the interface should be. As well as an interop question, since jmpbuf does vary in size between cygwin1.dl and everything else. Further down the line, there are other linkers, other compilers, other runtimes. The design here and now might take them into consideration.Gasp..I just realized, there is also another good backend option. parse.c's approach could probably be adapted to Open Watcom AND they might even take the changes (not that I have asked, I just thought of this). And that would net you progress toward a) 32 bit MS-DOS target b) OS/2 target, c) Netware target d) gcc-free Linux target, since the support all of them.Other target possibilities include Digital Mars compiler/linker, CodeWarrior (I know, dead and all), etc. Open Watcom is probably the most interesting since it is open source... - Jay > From: hosking at cs.purdue.edu> Date: Sat, 19 Jan 2008 12:48:06 -0500> To: jkrell at elego.de> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] [M3commit] CVS Update: cm3> > So, I am very confused now. Does NT386GNU no longer mean use of the > full set of GNU tools m3cc/ld/as, as would be available under > Cygwin? I thought the point of this was to be able to run in as much > of a GNU environment as possible. GNU to me means the whole > toolsuite not just m3cc. To me, a GNU-based environment on Windows > holds great attraction, since it consists of tools that I generally > always install on Windows, that I know, and are similar to the other > platforms I use.> > On Jan 19, 2008, at 4:11 AM, Jay Krell wrote:> > > CVSROOT: /usr/cvs> > Changes by: jkrell at birch. 08/01/19 04:11:34> >> > Modified files:> > cm3/m3-libs/m3core/src/runtime/: m3makefile> > cm3/m3-sys/cminstall/src/config/: NT386GNU> > cm3/m3-sys/m3front/src/builtinInfo/: InfoModule.m3> > cm3/m3-sys/m3middle/src/: Target.m3> >> > Log message:> > m3-sys/m3middle/src/Target.m3> > m3-libs/m3core/src/runtime/m3makefile> > m3-sys\m3front\src\builtinInfo\InfoModule.m3> > > > switch NT386GNU to be Win32 instead of POSIX> > switch NT386GNU to _setjmp instead of setjmp> > jmp_buf size still big like Cygwin> > rewrite NT386GNU config file -- almost identical to NT386> > mingwin required for building Modula-3 programs> > mingwin AND msys required for building m3cc> > > > To boot:> > > > install Python (www.activestate.com)> > > > have a working NT386 system> > get current source> > Mine is at c:\dev2\cm3.2 (cm3 is has other paused work, dev was > > taken by Unix)> > > > get and install binary distribution (5.1.3 works, anything newer > > should work)> > I install to c:\cm3> > copy %CVSROOT%\m3-sys\cminstall\src\config\cm3.cfg to \cm3\bin > > \cm3.cfg> > > > Have a Visual C++ toolset (cl and link)> > and run the vcvars link on the start menu (this can/will be made > > easier)> > Almost any version should work.> > if you are using Visual C++ 8.0 (RTM?), rename away its mt.exe> > and get a newer from such as from the Platform SDK. Otherwise it > > crashes.> > This is not specific to NT386GNU, just that I recently removed the > > Platform SDK> > from my %PATH%.> > > > cd %CVSROOT%\scripts\python> > .\upgrade> > > > install msys and mingwin from http://www.mingw.org (links to > > SourceForge)> > for mingwin, you only need the "base"> > msys tells you to avoid mingwin make, in favor of msys make, and I > > did that> > > > I install to the defaults> > c:\msys\1.0> > c:\mingw> > > > if you don't install to the defaults, add> > \bin and > to the start, but which order between the two?)> > > > if you do install to the defaults, scripts\python will fix path > > for you,> > if there is no gcc/as/sh on our $PATH> > > > cd %CVSROOT%\scripts\python> > upgrade && bootntgnu> > > > NOTE THE RESULTING BINARIES DO NOT YET WORK, but this is still > > progress.> > > > These instructions inevitably to be further tested and refined and > > placed elsewhere!> 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 Jan 19 19:45:27 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 19 Jan 2008 18:45:27 +0000 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: References: <20080119031134.4B6A510D4625@birch.elegosoft.com> Message-ID: ps -- the need or Visual C++ referenced in the checkin coment is to "boot" -- to build a current cm3 to build the NT386GNU stuff. Just like you need cm3 to do cross builds, except in this case both Modula-3 targets can be fully built on the same machine. Once you build the first time, IF it was working, no Visual C++/SDK requirement. Once a working binary distribution is available, ditto. - Jay From: jayk123 at hotmail.comTo: hosking at cs.purdue.edu; jkrell at elego.deCC: m3devel at elegosoft.comSubject: RE: [M3devel] [M3commit] CVS Update: cm3Date: Sat, 19 Jan 2008 18:35:09 +0000 ps -- look at m3-sys/cminstall/src/config/NT386GNU.While it is very very similar to NT386, and even outputs foo.lib and foo.lib.sa like NT386, it uses gcc for C compilation, linking, and m3cg for the backend.It is very "GNU" in tools, but not runtime. - Jay From: jayk123 at hotmail.comTo: hosking at cs.purdue.edu; jkrell at elego.deCC: m3devel at elegosoft.comSubject: RE: [M3devel] [M3commit] CVS Update: cm3Date: Sat, 19 Jan 2008 18:32:35 +0000 It DOES use m3cc/ld/as, and mklib for building static .libs, though that could probably be gcc/ar/dlltools if I figured it out."Everything" except m3cc/m3gdb can be built with just MinGWin.Building m3cc requires MSys as well.Building m3gdb requires Cygwin.m3cg is not dependent on cygwin1.dll, nor are any other Modula-3 outputs. m3gdb is dependent on cygwin1.dll. Using Cygwin probably would work..and I could try it to see if it resolves the RTLinker problem. As well, we could have something like, in cm3.cfg you could set MINGWIN_ROOT, MSYS_ROOT, and/or CYGWIN_ROOT, to guide what tools are used, OR we can have some variable: GNU_MODE = 0 % Do not use GNU tools at all -- today's NT386GNU_MODE = 1 % Use GNU tools minimally -- today's NT386GNUGNU_MODE = 2 % Use GNU tools maximally -- not existant but probably easy Eh..I know, not great.. what do "minimally" and "maximally" mean. I think we have the problem of a) many viable choices b) want to make several of them available c) just don't know what to call things and what the interface should be. As well as an interop question, since jmpbuf does vary in size between cygwin1.dl and everything else. Further down the line, there are other linkers, other compilers, other runtimes. The design here and now might take them into consideration.Gasp..I just realized, there is also another good backend option. parse.c's approach could probably be adapted to Open Watcom AND they might even take the changes (not that I have asked, I just thought of this). And that would net you progress toward a) 32 bit MS-DOS target b) OS/2 target, c) Netware target d) gcc-free Linux target, since the support all of them.Other target possibilities include Digital Mars compiler/linker, CodeWarrior (I know, dead and all), etc. Open Watcom is probably the most interesting since it is open source... - Jay > From: hosking at cs.purdue.edu> Date: Sat, 19 Jan 2008 12:48:06 -0500> To: jkrell at elego.de> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] [M3commit] CVS Update: cm3> > So, I am very confused now. Does NT386GNU no longer mean use of the > full set of GNU tools m3cc/ld/as, as would be available under > Cygwin? I thought the point of this was to be able to run in as much > of a GNU environment as possible. GNU to me means the whole > toolsuite not just m3cc. To me, a GNU-based environment on Windows > holds great attraction, since it consists of tools that I generally > always install on Windows, that I know, and are similar to the other > platforms I use.> > On Jan 19, 2008, at 4:11 AM, Jay Krell wrote:> > > CVSROOT: /usr/cvs> > Changes by: jkrell at birch. 08/01/19 04:11:34> >> > Modified files:> > cm3/m3-libs/m3core/src/runtime/: m3makefile> > cm3/m3-sys/cminstall/src/config/: NT386GNU> > cm3/m3-sys/m3front/src/builtinInfo/: InfoModule.m3> > cm3/m3-sys/m3middle/src/: Target.m3> >> > Log message:> > m3-sys/m3middle/src/Target.m3> > m3-libs/m3core/src/runtime/m3makefile> > m3-sys\m3front\src\builtinInfo\InfoModule.m3> > > > switch NT386GNU to be Win32 instead of POSIX> > switch NT386GNU to _setjmp instead of setjmp> > jmp_buf size still big like Cygwin> > rewrite NT386GNU config file -- almost identical to NT386> > mingwin required for building Modula-3 programs> > mingwin AND msys required for building m3cc> > > > To boot:> > > > install Python (www.activestate.com)> > > > have a working NT386 system> > get current source> > Mine is at c:\dev2\cm3.2 (cm3 is has other paused work, dev was > > taken by Unix)> > > > get and install binary distribution (5.1.3 works, anything newer > > should work)> > I install to c:\cm3> > copy %CVSROOT%\m3-sys\cminstall\src\config\cm3.cfg to \cm3\bin > > \cm3.cfg> > > > Have a Visual C++ toolset (cl and link)> > and run the vcvars link on the start menu (this can/will be made > > easier)> > Almost any version should work.> > if you are using Visual C++ 8.0 (RTM?), rename away its mt.exe> > and get a newer from such as from the Platform SDK. Otherwise it > > crashes.> > This is not specific to NT386GNU, just that I recently removed the > > Platform SDK> > from my %PATH%.> > > > cd %CVSROOT%\scripts\python> > .\upgrade> > > > install msys and mingwin from http://www.mingw.org (links to > > SourceForge)> > for mingwin, you only need the "base"> > msys tells you to avoid mingwin make, in favor of msys make, and I > > did that> > > > I install to the defaults> > c:\msys\1.0> > c:\mingw> > > > if you don't install to the defaults, add> > \bin and > to the start, but which order between the two?)> > > > if you do install to the defaults, scripts\python will fix path > > for you,> > if there is no gcc/as/sh on our $PATH> > > > cd %CVSROOT%\scripts\python> > upgrade && bootntgnu> > > > NOTE THE RESULTING BINARIES DO NOT YET WORK, but this is still > > progress.> > > > These instructions inevitably to be further tested and refined and > > placed elsewhere!> 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! _________________________________________________________________ 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 Sat Jan 19 19:49:32 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 19 Jan 2008 18:49:32 +0000 Subject: [M3devel] more assembly symbols please? In-Reply-To: <2717B275-2548-41BC-BD1E-8742BCE6FA51@cs.purdue.edu> References: <2717B275-2548-41BC-BD1E-8742BCE6FA51@cs.purdue.edu> Message-ID: Thanks. m3cg -y for full tracing also dumps relevant stuff at the end. I'll try m3cgcat too. I should just be able to build/run an NT386 version. My C tracing does "prove" the problem is RTHeapInfo, but I still haven't figured out why. I've started skimming the code that builds that data...still a ways off from solving this I think. I have some suspicion the linker is moving things around that were otherwise correct, but I am far from proving that or fixing it. I'd like to first verify that the "m3front" / m3cg output is correct. The lack of labels in the as actually is a counter point to the movement theory, hard for linker to get a handle on anything to move around, it's just one blob. - Jay > CC: m3devel at elegosoft.com> From: hosking at cs.purdue.edu> Subject: Re: [M3devel] more assembly symbols please?> Date: Sat, 19 Jan 2008 12:33:08 -0500> To: jayk123 at hotmail.com> > Take a look at the .mc intermediate code output if you want to see > that section of the data. There are at least comments. Use m3cgcat - > binary < x.mc > x.mo to view it (You can run m3cgcat on any other CM3 > install).> > On Jan 19, 2008, at 6:02 AM, Jay wrote:> > > Any chance the m3cg output could have, um, some symbols for the > > global data?> > It's kind of a pain to decode..> >> > The module/import info is ok a lot, lots of runtime links ok.> > I think the bad one might be RTHeapInfo but I have to decode the > > very bare of symbols assembly..> > or comments? Like for record fields?> > Still thinking of sticking a call out to C code...Even > > OutputDebugString since RTIO isn't working...> >> > I looked through the m3cg --help, didn't find anything.> >> > Tony?> >> > _MM_RTHeapInfo:> > 0 .long _L_1+224> > 4 .long _MM_RTHeapInfo+52> > 8 .long _MM_RTHeapInfo+308> > 12,16 .space 8> > 20 .long _L_1+152> > 24 .space 4> > 28 .long _L_1+220> > 32 .long _L_1+220> > 36 .long _MM_RTHeapInfo+160> > 40 .space 4> > .long _RTHeapInfo_M3> >> > I get to count out to 160 bytes from here..:> >> > _L_1:> > 0 .byte 48> > 1 .byte 49> > 2 .byte 50> > 3 .byte 51> > 4 .byte 52> > 5 .byte 53> > 6 .byte 54> > 7 .byte 55> > 8 .byte 56> > 9 .byte 57> > a .byte 97> > b .byte 98> > c .byte 99> > d .byte 100> > e .byte 101> > f .byte 102> > 10 .long _RTHooks__TextLitInfo> > 14 .long _RTHooks__TextLitGetChar> > 18 .long _RTHooks__TextLitGetWideChar> > 1c .long _RTHooks__TextLitGetChars> > 20 .long _RTHooks__TextLitGetWideChars> > 24 .long 2> > 28 .long _L_1+16> > 2c .long 7> > 30 .ascii "shownew"> > 37 .space 1> > 38 .long 2> > 3c .long _L_1+16> > 40 .long 6> > 44 .ascii "update"> > 4a .space 2> > 4c .ascii "RTHeapInfo_M3"> > 50 .space 1> > .ascii "Init"> > .space 1> >> > I'll try the C code..> >> > - Jay> >> >> >> >> >> > 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 wagner at elegosoft.com Sat Jan 19 20:48:10 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 19 Jan 2008 20:48:10 +0100 Subject: [M3devel] my status on win32 In-Reply-To: <47908659.1E75.00D7.1@scires.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> <477EA137.1E75.00D7.1@scires.com> <478D394B.1E75.00D7.1@scires.com> <478D47FB.1E75.00D7.1@scires.com> <478DBF8D.1E75.00D7.1@scires.com> <478DE973.1E75.00D7.1@scires.com> <47908659.1E75.00D7.1@scires.com> Message-ID: <20080119204810.3wmumqgms88sccw4@mail.elegosoft.com> Quoting Randy Coleburn : > 1. pixmaps aren't rendered properly on the screen. They look really > bad. I recall having this problem a while back with one of the early > 5.x releases, so I guess it was never solved. I've got some old test > programs I try to dig out and see if I can find out what is going on. I > seem to recall that building standalone in the past seemed to fix the > problem, so this is a real mystery. Hi Randy, I'm afraid I wasn't able to solve it directly some years ago and then forgot about it due to more urgent tasks. I think we should try to narrow down the location of the problem (i.e. is it in the runtime, code generation, linker, or windows libraries). As you still have the 4.1 code of the Windows libraries, could you first try to build them with the new compiler and see if it makes a difference if you link against them? It may also be worthwhile to compare the commands actually used for linking (use -commands). That is, before we turn to the actual generated code... I still haven't got Windows access here, so I can just suggest what to do... Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From rcoleburn at scires.com Sat Jan 19 22:22:06 2008 From: rcoleburn at scires.com (Randy Coleburn) Date: Sat, 19 Jan 2008 16:22:06 -0500 Subject: [M3devel] reactor: catalyst vs cm3-ide Message-ID: <479223AC.1E75.00D7.1@scires.com> Ok, I've gotten some feedback on the new name for reactor. I've attached a PDF that has two pages: one depicts use of Catalyst, the other CM3-IDE. Please let me know which you prefer. BTW, if anyone else can draw up something better, go for it. I'm not a graphic artist. Regards, Randy -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: newReactor.pdf Type: application/pdf Size: 84104 bytes Desc: not available URL: From rcoleburn at scires.com Sat Jan 19 22:27:09 2008 From: rcoleburn at scires.com (Randy Coleburn) Date: Sat, 19 Jan 2008 16:27:09 -0500 Subject: [M3devel] success with upgrade on NT386 Message-ID: <479224DB.1E75.00D7.1@scires.com> Jay: Thanks for all your help. I checked out your updates last night and was able to do a complete rebuild of the compiler and all packages using the upgrade and do-cmd-std scripts on Windows XP. Regards, Randy -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sun Jan 20 00:46:59 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 19 Jan 2008 18:46:59 -0500 Subject: [M3devel] more assembly symbols please? In-Reply-To: References: <2717B275-2548-41BC-BD1E-8742BCE6FA51@cs.purdue.edu> Message-ID: <1A973B4E-23DD-4B85-B42F-9070E93429BB@cs.purdue.edu> Which linker are you using? Could that be a factor? On Jan 19, 2008, at 1:49 PM, Jay wrote: > Thanks. m3cg -y for full tracing also dumps relevant stuff at the end. > I'll try m3cgcat too. I should just be able to build/run an NT386 > version. > My C tracing does "prove" the problem is RTHeapInfo, but I still > haven't figured out why. > I've started skimming the code that builds that data...still a ways > off from solving this I think. > I have some suspicion the linker is moving things around that were > otherwise correct, but I am far from proving that or fixing it. > I'd like to first verify that the "m3front" / m3cg output is correct. > The lack of labels in the as actually is a counter point to the > movement theory, hard for linker to get a handle on anything to > move around, it's just one blob. > > - Jay > > > > > CC: m3devel at elegosoft.com > > From: hosking at cs.purdue.edu > > Subject: Re: [M3devel] more assembly symbols please? > > Date: Sat, 19 Jan 2008 12:33:08 -0500 > > To: jayk123 at hotmail.com > > > > Take a look at the .mc intermediate code output if you want to see > > that section of the data. There are at least comments. Use m3cgcat - > > binary < x.mc > x.mo to view it (You can run m3cgcat on any other > CM3 > > install). > > > > On Jan 19, 2008, at 6:02 AM, Jay wrote: > > > > > Any chance the m3cg output could have, um, some symbols for the > > > global data? > > > It's kind of a pain to decode.. > > > > > > The module/import info is ok a lot, lots of runtime links ok. > > > I think the bad one might be RTHeapInfo but I have to decode the > > > very bare of symbols assembly.. > > > or comments? Like for record fields? > > > Still thinking of sticking a call out to C code...Even > > > OutputDebugString since RTIO isn't working... > > > > > > I looked through the m3cg --help, didn't find anything. > > > > > > Tony? > > > > > > _MM_RTHeapInfo: > > > 0 .long _L_1+224 > > > 4 .long _MM_RTHeapInfo+52 > > > 8 .long _MM_RTHeapInfo+308 > > > 12,16 .space 8 > > > 20 .long _L_1+152 > > > 24 .space 4 > > > 28 .long _L_1+220 > > > 32 .long _L_1+220 > > > 36 .long _MM_RTHeapInfo+160 > > > 40 .space 4 > > > .long _RTHeapInfo_M3 > > > > > > I get to count out to 160 bytes from here..: > > > > > > _L_1: > > > 0 .byte 48 > > > 1 .byte 49 > > > 2 .byte 50 > > > 3 .byte 51 > > > 4 .byte 52 > > > 5 .byte 53 > > > 6 .byte 54 > > > 7 .byte 55 > > > 8 .byte 56 > > > 9 .byte 57 > > > a .byte 97 > > > b .byte 98 > > > c .byte 99 > > > d .byte 100 > > > e .byte 101 > > > f .byte 102 > > > 10 .long _RTHooks__TextLitInfo > > > 14 .long _RTHooks__TextLitGetChar > > > 18 .long _RTHooks__TextLitGetWideChar > > > 1c .long _RTHooks__TextLitGetChars > > > 20 .long _RTHooks__TextLitGetWideChars > > > 24 .long 2 > > > 28 .long _L_1+16 > > > 2c .long 7 > > > 30 .ascii "shownew" > > > 37 .space 1 > > > 38 .long 2 > > > 3c .long _L_1+16 > > > 40 .long 6 > > > 44 .ascii "update" > > > 4a .space 2 > > > 4c .ascii "RTHeapInfo_M3" > > > 50 .space 1 > > > .ascii "Init" > > > .space 1 > > > > > > I'll try the C code.. > > > > > > - Jay > > > > > > > > > > > > > > > > > > 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 hosking at cs.purdue.edu Sun Jan 20 00:47:41 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 19 Jan 2008 18:47:41 -0500 Subject: [M3devel] my status on win32 In-Reply-To: <20080119204810.3wmumqgms88sccw4@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> <477EA137.1E75.00D7.1@scires.com> <478D394B.1E75.00D7.1@scires.com> <478D47FB.1E75.00D7.1@scires.com> <478DBF8D.1E75.00D7.1@scires.com> <478DE973.1E75.00D7.1@scires.com> <47908659.1E75.00D7.1@scires.com> <20080119204810.3wmumqgms88sccw4@mail.elegosoft.com> Message-ID: I would perhaps suspect a bad library mapping. On Jan 19, 2008, at 2:48 PM, Olaf Wagner wrote: > Quoting Randy Coleburn : >> 1. pixmaps aren't rendered properly on the screen. They look really >> bad. I recall having this problem a while back with one of the early >> 5.x releases, so I guess it was never solved. I've got some old test >> programs I try to dig out and see if I can find out what is going >> on. I >> seem to recall that building standalone in the past seemed to fix the >> problem, so this is a real mystery. > > Hi Randy, > > I'm afraid I wasn't able to solve it directly some years ago and > then forgot about it due to more urgent tasks. > > I think we should try to narrow down the location of the problem > (i.e. is it in the runtime, code generation, linker, or windows > libraries). > > As you still have the 4.1 code of the Windows libraries, could you > first try to build them with the new compiler and see if it makes > a difference if you link against them? > > It may also be worthwhile to compare the commands actually used > for linking (use -commands). That is, before we turn to the actual > generated code... > > I still haven't got Windows access here, so I can just suggest what > to do... > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, > Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Jan 20 00:51:41 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 19 Jan 2008 18:51:41 -0500 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: References: <20080119031134.4B6A510D4625@birch.elegosoft.com> Message-ID: <5BFBD626-F492-4058-9A7A-6CB295753585@cs.purdue.edu> On Jan 19, 2008, at 1:32 PM, Jay wrote: > Gasp..I just realized, there is also another good backend option. > parse.c's approach could probably be adapted to Open Watcom AND > they might even take the changes (not that I have asked, I just > thought of this). And that would net you progress toward a) 32 bit > MS-DOS target b) OS/2 target, c) Netware target d) gcc-free Linux > target, since the support all of them. I would plump for llvm. Apple is using it heavily these days and may be pushing it into their Mac compiler toolchain. > > Other target possibilities include Digital Mars compiler/linker, > CodeWarrior (I know, dead and all), etc. Open Watcom is probably > the most interesting since it is open source... > > - Jay > > > > > From: hosking at cs.purdue.edu > > Date: Sat, 19 Jan 2008 12:48:06 -0500 > > To: jkrell at elego.de > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > > > So, I am very confused now. Does NT386GNU no longer mean use of the > > full set of GNU tools m3cc/ld/as, as would be available under > > Cygwin? I thought the point of this was to be able to run in as much > > of a GNU environment as possible. GNU to me means the whole > > toolsuite not just m3cc. To me, a GNU-based environment on Windows > > holds great attraction, since it consists of tools that I generally > > always install on Windows, that I know, and are similar to the other > > platforms I use. > > > > On Jan 19, 2008, at 4:11 AM, Jay Krell wrote: > > > > > CVSROOT: /usr/cvs > > > Changes by: jkrell at birch. 08/01/19 04:11:34 > > > > > > Modified files: > > > cm3/m3-libs/m3core/src/runtime/: m3makefile > > > cm3/m3-sys/cminstall/src/config/: NT386GNU > > > cm3/m3-sys/m3front/src/builtinInfo/: InfoModule.m3 > > > cm3/m3-sys/m3middle/src/: Target.m3 > > > > > > Log message: > > > m3-sys/m3middle/src/Target.m3 > > > m3-libs/m3core/src/runtime/m3makefile > > > m3-sys\m3front\src\builtinInfo\InfoModule.m3 > > > > > > switch NT386GNU to be Win32 instead of POSIX > > > switch NT386GNU to _setjmp instead of setjmp > > > jmp_buf size still big like Cygwin > > > rewrite NT386GNU config file -- almost identical to NT386 > > > mingwin required for building Modula-3 programs > > > mingwin AND msys required for building m3cc > > > > > > To boot: > > > > > > install Python (www.activestate.com) > > > > > > have a working NT386 system > > > get current source > > > Mine is at c:\dev2\cm3.2 (cm3 is has other paused work, dev was > > > taken by Unix) > > > > > > get and install binary distribution (5.1.3 works, anything newer > > > should work) > > > I install to c:\cm3 > > > copy %CVSROOT%\m3-sys\cminstall\src\config\cm3.cfg to \cm3\bin > > > \cm3.cfg > > > > > > Have a Visual C++ toolset (cl and link) > > > and run the vcvars link on the start menu (this can/will be made > > > easier) > > > Almost any version should work. > > > if you are using Visual C++ 8.0 (RTM?), rename away its mt.exe > > > and get a newer from such as from the Platform SDK. Otherwise it > > > crashes. > > > This is not specific to NT386GNU, just that I recently removed the > > > Platform SDK > > > from my %PATH%. > > > > > > cd %CVSROOT%\scripts\python > > > .\upgrade > > > > > > install msys and mingwin from http://www.mingw.org (links to > > > SourceForge) > > > for mingwin, you only need the "base" > > > msys tells you to avoid mingwin make, in favor of msys make, and I > > > did that > > > > > > I install to the defaults > > > c:\msys\1.0 > > > c:\mingw > > > > > > if you don't install to the defaults, add > > > \bin and > > to the start, but which order between the two?) > > > > > > if you do install to the defaults, scripts\python will fix path > > > for you, > > > if there is no gcc/as/sh on our $PATH > > > > > > cd %CVSROOT%\scripts\python > > > upgrade && bootntgnu > > > > > > NOTE THE RESULTING BINARIES DO NOT YET WORK, but this is still > > > progress. > > > > > > These instructions inevitably to be further tested and refined and > > > placed elsewhere! > > > > > 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 Sun Jan 20 00:52:12 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 19 Jan 2008 18:52:12 -0500 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: References: <20080119031134.4B6A510D4625@birch.elegosoft.com> Message-ID: OK, that's what I had hoped. Sounds good! On Jan 19, 2008, at 1:35 PM, Jay wrote: > ps -- look at m3-sys/cminstall/src/config/NT386GNU. > While it is very very similar to NT386, and even outputs foo.lib > and foo.lib.sa like NT386, it uses gcc for C compilation, linking, > and m3cg for the backend. > It is very "GNU" in tools, but not runtime. > > - Jay > > From: jayk123 at hotmail.com > To: hosking at cs.purdue.edu; jkrell at elego.de > CC: m3devel at elegosoft.com > Subject: RE: [M3devel] [M3commit] CVS Update: cm3 > Date: Sat, 19 Jan 2008 18:32:35 +0000 > > It DOES use m3cc/ld/as, and mklib for building static .libs, though > that could probably be gcc/ar/dlltools if I figured it out. > "Everything" except m3cc/m3gdb can be built with just MinGWin. > Building m3cc requires MSys as well. > Building m3gdb requires Cygwin. > m3cg is not dependent on cygwin1.dll, nor are any other Modula-3 > outputs. m3gdb is dependent on cygwin1.dll. > > Using Cygwin probably would work..and I could try it to see if it > resolves the RTLinker problem. > > As well, we could have something like, in cm3.cfg you could set > MINGWIN_ROOT, MSYS_ROOT, and/or CYGWIN_ROOT, to guide what tools > are used, OR we can have some variable: > > GNU_MODE = 0 % Do not use GNU tools at all -- today's NT386 > GNU_MODE = 1 % Use GNU tools minimally -- today's NT386GNU > GNU_MODE = 2 % Use GNU tools maximally -- not existant but probably > easy > > Eh..I know, not great.. what do "minimally" and "maximally" mean. > > I think we have the problem of a) many viable choices b) want to > make several of them available c) just don't know what to call > things and what the interface should be. As well as an interop > question, since jmpbuf does vary in size between cygwin1.dl and > everything else. > > Further down the line, there are other linkers, other compilers, > other runtimes. The design here and now might take them into > consideration. > Gasp..I just realized, there is also another good backend option. > parse.c's approach could probably be adapted to Open Watcom AND > they might even take the changes (not that I have asked, I just > thought of this). And that would net you progress toward a) 32 bit > MS-DOS target b) OS/2 target, c) Netware target d) gcc-free Linux > target, since the support all of them. > Other target possibilities include Digital Mars compiler/linker, > CodeWarrior (I know, dead and all), etc. Open Watcom is probably > the most interesting since it is open source... > > - Jay > > > > > From: hosking at cs.purdue.edu > > Date: Sat, 19 Jan 2008 12:48:06 -0500 > > To: jkrell at elego.de > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > > > So, I am very confused now. Does NT386GNU no longer mean use of the > > full set of GNU tools m3cc/ld/as, as would be available under > > Cygwin? I thought the point of this was to be able to run in as much > > of a GNU environment as possible. GNU to me means the whole > > toolsuite not just m3cc. To me, a GNU-based environment on Windows > > holds great attraction, since it consists of tools that I generally > > always install on Windows, that I know, and are similar to the other > > platforms I use. > > > > On Jan 19, 2008, at 4:11 AM, Jay Krell wrote: > > > > > CVSROOT: /usr/cvs > > > Changes by: jkrell at birch. 08/01/19 04:11:34 > > > > > > Modified files: > > > cm3/m3-libs/m3core/src/runtime/: m3makefile > > > cm3/m3-sys/cminstall/src/config/: NT386GNU > > > cm3/m3-sys/m3front/src/builtinInfo/: InfoModule.m3 > > > cm3/m3-sys/m3middle/src/: Target.m3 > > > > > > Log message: > > > m3-sys/m3middle/src/Target.m3 > > > m3-libs/m3core/src/runtime/m3makefile > > > m3-sys\m3front\src\builtinInfo\InfoModule.m3 > > > > > > switch NT386GNU to be Win32 instead of POSIX > > > switch NT386GNU to _setjmp instead of setjmp > > > jmp_buf size still big like Cygwin > > > rewrite NT386GNU config file -- almost identical to NT386 > > > mingwin required for building Modula-3 programs > > > mingwin AND msys required for building m3cc > > > > > > To boot: > > > > > > install Python (www.activestate.com) > > > > > > have a working NT386 system > > > get current source > > > Mine is at c:\dev2\cm3.2 (cm3 is has other paused work, dev was > > > taken by Unix) > > > > > > get and install binary distribution (5.1.3 works, anything newer > > > should work) > > > I install to c:\cm3 > > > copy %CVSROOT%\m3-sys\cminstall\src\config\cm3.cfg to \cm3\bin > > > \cm3.cfg > > > > > > Have a Visual C++ toolset (cl and link) > > > and run the vcvars link on the start menu (this can/will be made > > > easier) > > > Almost any version should work. > > > if you are using Visual C++ 8.0 (RTM?), rename away its mt.exe > > > and get a newer from such as from the Platform SDK. Otherwise it > > > crashes. > > > This is not specific to NT386GNU, just that I recently removed the > > > Platform SDK > > > from my %PATH%. > > > > > > cd %CVSROOT%\scripts\python > > > .\upgrade > > > > > > install msys and mingwin from http://www.mingw.org (links to > > > SourceForge) > > > for mingwin, you only need the "base" > > > msys tells you to avoid mingwin make, in favor of msys make, and I > > > did that > > > > > > I install to the defaults > > > c:\msys\1.0 > > > c:\mingw > > > > > > if you don't install to the defaults, add > > > \bin and > > to the start, but which order between the two?) > > > > > > if you do install to the defaults, scripts\python will fix path > > > for you, > > > if there is no gcc/as/sh on our $PATH > > > > > > cd %CVSROOT%\scripts\python > > > upgrade && bootntgnu > > > > > > NOTE THE RESULTING BINARIES DO NOT YET WORK, but this is still > > > progress. > > > > > > These instructions inevitably to be further tested and refined and > > > placed elsewhere! > > > > > 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! From rcoleburn at scires.com Sun Jan 20 03:12:37 2008 From: rcoleburn at scires.com (Randy Coleburn) Date: Sat, 19 Jan 2008 21:12:37 -0500 Subject: [M3devel] my status on win32 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> <477EA137.1E75.00D7.1@scires.com> <478D394B.1E75.00D7.1@scires.com> <478D47FB.1E75.00D7.1@scires.com> <478DBF8D.1E75.00D7.1@scires.com> <478DE973.1E75.00D7.1@scires.com> <47908659.1E75.00D7.1@scires.com> <20080119204810.3wmumqgms88sccw4@mail.elegosoft.com> Message-ID: <479267C2.1E75.00D7.1@scires.com> Hi Tony: Are you suggesting that when the program is built standalone it maps libraries differently? I know there is a difference between dynamic vs. static libraries, but are you suggesting that a different library is being mapped than the vendor's equivalent of the dynamic library? How would I check for this situation? Your suggestion seems plausible since the source is not recompiled; instead, the linker is used to change the way the EXE is put together and that seems to cause the difference in operation as far as pixmaps are concerned. Regards, Randy >>> Tony Hosking 1/19/2008 6:47 PM >>> I would perhaps suspect a bad library mapping. On Jan 19, 2008, at 2:48 PM, Olaf Wagner wrote: > Quoting Randy Coleburn : >> 1. pixmaps aren't rendered properly on the screen. They look really >> bad. I recall having this problem a while back with one of the early >> 5.x releases, so I guess it was never solved. I've got some old test >> programs I try to dig out and see if I can find out what is going >> on. I >> seem to recall that building standalone in the past seemed to fix the >> problem, so this is a real mystery. > > Hi Randy, > > I'm afraid I wasn't able to solve it directly some years ago and > then forgot about it due to more urgent tasks. > > I think we should try to narrow down the location of the problem > (i.e. is it in the runtime, code generation, linker, or windows > libraries). > > As you still have the 4.1 code of the Windows libraries, could you > first try to build them with the new compiler and see if it makes > a difference if you link against them? > > It may also be worthwhile to compare the commands actually used > for linking (use -commands). That is, before we turn to the actual > generated code... > > I still haven't got Windows access here, so I can just suggest what > to do... > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, > Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 > 45 86 95 > http://www.elegosoft.com ( http://www.elegosoft.com/ ) | Gesch?ftsf?hrer: Olaf Wagner | Sitz: > Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > DE163214194 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Sun Jan 20 05:27:43 2008 From: jayk123 at hotmail.com (Jay) Date: Sun, 20 Jan 2008 04:27:43 +0000 Subject: [M3devel] my status on win32 In-Reply-To: <479267C2.1E75.00D7.1@scires.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> <477EA137.1E75.00D7.1@scires.com> <478D394B.1E75.00D7.1@scires.com> <478D47FB.1E75.00D7.1@scires.com> <478DBF8D.1E75.00D7.1@scires.com> <478DE973.1E75.00D7.1@scires.com> <47908659.1E75.00D7.1@scires.com> <20080119204810.3wmumqgms88sccw4@mail.elegosoft.com> <479267C2.1E75.00D7.1@scires.com> Message-ID: What does "mapped" mean here? The way it works, on Modula-3 NT386, and I haven't seen this done quite this way ever on Win32, not so systematically/mechanically/automatically, and I don't know how Posixish systems work here, but the way it works is that for every .dll, CM3 NT386 builds foo.lib and foo.lib.sa. foo.lib is an "import lib", just containing essentially function names and a file name. foo.lib.sa is a regular old static .lib, sa for standalone. You can also just build a static .lib -- for stuff that is never a .dll, for stuff that is only used once, but is broken up into multiple directories. For example m3quake, m3middle, m3objfile, m3back, etc. They are only used by cm3 so are just static .libs, just foo.lib, are built. (If we fix cm3.exe to be copy over itself, and I have some new clever ideas here, it might be profitable, for "developer productivity", to turn these into .dlls -- just so I can cd around and rebuild/reship less.) When you ask to build a standalone executable, we have a list of .libs, foo.lib, bar.lib. They are full paths. For each one, we see if foo.lib.sa exists, and if so, we use that instead of foo.lib. It is all rather simple and clever, but at least to me, it was surprising and new, so I explain it here. Perhaps Posixish systems work very similarly and this is old hat? I know cm3 doesn't implement this for Posix, but ar/ld/gcc could be handling things this way underneath for it. For example, I know on Mac OS X, if you link to a full path to a file, that's what you get. But if you say -Ldirectory -lfoo, ld probes for directory/foo.dylib and then directory/foo.a. So modulo the extensions and unknown to me how you build the things in the first place, same thing. You have to be sure to use the setting to split lib paths like that, otherwise you break dynamic linking. CM3 makes foo.sa.lib with its own mklib. This is also unusual. Normally one would use lib.exe or link.exe /lib for this, or ar/ld/gcc/dlltools. But the CM3 folks were obviously, openly en route to cutting dependencies through reimplementation. I had some initial trouble on NT385GNU building static .libs with ar/ld/gcc/dlltool, so, heck, I just do what NT386 does, and it seems to be working (modulo that SOMETHING is not working :) ). I don't want to stop anyone else from debugging this but if nobody else figures it out I will try. I can repro it easily, thanks for the good repro Randy! (though I wish it would crash instead of mis-display :) ) There is no "vendor's equivalent library" here, it is all just Modula-3 foo.lib or foo.lib.sa. Look at NT386/*.txt, by the .exe. Build one way. Rename away NT386. Build the other way. Compare the directories. You will see what I am talking about. - Jay Date: Sat, 19 Jan 2008 21:12:37 -0500 From: rcoleburn at scires.com To: hosking at cs.purdue.edu; wagner at elegosoft.com CC: m3devel at elegosoft.com Subject: Re: [M3devel] my status on win32 Hi Tony: Are you suggesting that when the program is built standalone it maps libraries differently? I know there is a difference between dynamic vs. static libraries, but are you suggesting that a different library is being mapped than the vendor's equivalent of the dynamic library? How would I check for this situation? Your suggestion seems plausible since the source is not recompiled; instead, the linker is used to change the way the EXE is put together and that seems to cause the difference in operation as far as pixmaps are concerned. Regards, Randy >>> Tony Hosking 1/19/2008 6:47 PM >>> I would perhaps suspect a bad library mapping. On Jan 19, 2008, at 2:48 PM, Olaf Wagner wrote: > Quoting Randy Coleburn : >> 1. pixmaps aren't rendered properly on the screen. They look really >> bad. I recall having this problem a while back with one of the early >> 5.x releases, so I guess it was never solved. I've got some old test >> programs I try to dig out and see if I can find out what is going >> on. I >> seem to recall that building standalone in the past seemed to fix the >> problem, so this is a real mystery. > > Hi Randy, > > I'm afraid I wasn't able to solve it directly some years ago and > then forgot about it due to more urgent tasks. > > I think we should try to narrow down the location of the problem > (i.e. is it in the runtime, code generation, linker, or windows > libraries). > > As you still have the 4.1 code of the Windows libraries, could you > first try to build them with the new compiler and see if it makes > a difference if you link against them? > > It may also be worthwhile to compare the commands actually used > for linking (use -commands). That is, before we turn to the actual > generated code... > > I still haven't got Windows access here, so I can just suggest what > to do... > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, > Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 Jan 20 04:46:03 2008 From: mika at async.caltech.edu (Mika Nystrom) Date: Sat, 19 Jan 2008 19:46:03 -0800 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: Your message of "Sat, 19 Jan 2008 12:48:06 EST." Message-ID: <200801200346.m0K3k3Em023728@camembert.async.caltech.edu> Can I add a perhaps obvious observation? NT386GNU must, of all things, mean that the code will compile and link cleanly, with a minimum of fuss, against Cygwin's headers and libraries. I have never used MS's C tools so I don't know if this is the case with them. It is of course the case when you use GNU ld, etc. When building large software in Modula-3 it's almost inevitable that, since the language is used by so few people, you will have a need to call out to C code (or Fortran code, or some other compiled code, with C interfaces). If you develop on Unix and use Cygwin to port to Windows, it makes no sense to distinguish between NT386 and NT386GNU unless the latter has pretty much the same environment as the Unix system. Mika Tony Hosking writes: >So, I am very confused now. Does NT386GNU no longer mean use of the >full set of GNU tools m3cc/ld/as, as would be available under >Cygwin? I thought the point of this was to be able to run in as much >of a GNU environment as possible. GNU to me means the whole >toolsuite not just m3cc. To me, a GNU-based environment on Windows >holds great attraction, since it consists of tools that I generally >always install on Windows, that I know, and are similar to the other >platforms I use. > >On Jan 19, 2008, at 4:11 AM, Jay Krell wrote: > >> CVSROOT: /usr/cvs >> Changes by: jkrell at birch. 08/01/19 04:11:34 >> >> Modified files: >> cm3/m3-libs/m3core/src/runtime/: m3makefile >> cm3/m3-sys/cminstall/src/config/: NT386GNU >> cm3/m3-sys/m3front/src/builtinInfo/: InfoModule.m3 >> cm3/m3-sys/m3middle/src/: Target.m3 >> >> Log message: >> m3-sys/m3middle/src/Target.m3 >> m3-libs/m3core/src/runtime/m3makefile >> m3-sys\m3front\src\builtinInfo\InfoModule.m3 >> >> switch NT386GNU to be Win32 instead of POSIX >> switch NT386GNU to _setjmp instead of setjmp >> jmp_buf size still big like Cygwin >> rewrite NT386GNU config file -- almost identical to NT386 >> mingwin required for building Modula-3 programs >> mingwin AND msys required for building m3cc >> >> To boot: >> >> install Python (www.activestate.com) >> >> have a working NT386 system >> get current source >> Mine is at c:\dev2\cm3.2 (cm3 is has other paused work, dev was >> taken by Unix) >> >> get and install binary distribution (5.1.3 works, anything newer >> should work) >> I install to c:\cm3 >> copy %CVSROOT%\m3-sys\cminstall\src\config\cm3.cfg to \cm3\bin >> \cm3.cfg >> >> Have a Visual C++ toolset (cl and link) >> and run the vcvars link on the start menu (this can/will be made >> easier) >> Almost any version should work. >> if you are using Visual C++ 8.0 (RTM?), rename away its mt.exe >> and get a newer from such as from the Platform SDK. Otherwise it >> crashes. >> This is not specific to NT386GNU, just that I recently removed the >> Platform SDK >> from my %PATH%. >> >> cd %CVSROOT%\scripts\python >> .\upgrade >> >> install msys and mingwin from http://www.mingw.org (links to >> SourceForge) >> for mingwin, you only need the "base" >> msys tells you to avoid mingwin make, in favor of msys make, and I >> did that >> >> I install to the defaults >> c:\msys\1.0 >> c:\mingw >> >> if you don't install to the defaults, add >> \bin and > to the start, but which order between the two?) >> >> if you do install to the defaults, scripts\python will fix path >> for you, >> if there is no gcc/as/sh on our $PATH >> >> cd %CVSROOT%\scripts\python >> upgrade && bootntgnu >> >> NOTE THE RESULTING BINARIES DO NOT YET WORK, but this is still >> progress. >> >> These instructions inevitably to be further tested and refined and >> placed elsewhere! From jayk123 at hotmail.com Sun Jan 20 05:52:55 2008 From: jayk123 at hotmail.com (Jay) Date: Sun, 20 Jan 2008 04:52:55 +0000 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: References: <20080119031134.4B6A510D4625@birch.elegosoft.com> Message-ID: Good, a happy customer. :) > GNU_MODE = 0 % Do not use GNU tools at all -- today's NT386 > GNU_MODE = 1 % Use GNU tools minimally -- today's NT386GNU > GNU_MODE = 2 % Use GNU tools maximally -- not existant but probably > easy > > Eh..I know, not great.. what do "minimally" and "maximally" mean. I'm still fishing for anyone to provide answers to these less important decisions that I have trouble with. Otherwise maybe no NT Cygwin system. TARGETs = { NT386, NT386GNU, NT386CYGWIN }? TARGETs = { NT386, NT386MINGWIN, NT386CYGWIN }? TARGETs = { NT386 + GNU_MODE }? The one reason I don't favor NT386 + GNU_MODE is that Cygwin has a much larger jmpbuf than the others. I think same TARGET implies code can be linked together, and I think varying jmpbuf implies otherwise. So NT386 and NT386MINGWIN should rarely cross paths with NT386CYGWIN. I also do NOT like this ad-hoc naming style. PPC_DARWIN, I386_DARWIN are much more to my style. The names should be somehow hierarchical, except, I realize, there isn't necessarily one "path" of stuff which to name platforms, though the GNU folks have settled on a way or two. They have triples or quadruples -- processor-hardware-os or such, however this doesn't clearly suffice. Something that accomodates: NT386 + LLVM NT386 + Watcom, linker and/or backend and/or runtime NT386 + Digital Mars linker and/or backend and/or runtime A C generating backend, and then linker/runtime and similar IA64, AMD64 variants would be good. To a large extent, these can be few platforms, subject to configuration, like if all the linkers consume a common file format (not clear), and if all the jmpbufs are the same size (known to be partly true, partly false). Oh and another thing, the runtime dependency is very likely cuttable, however PRESUMABLY real world applications (if there are any) link in a substantial amount of C or C++, in which case, it isn't necessarily cuttable. As well, if I can figure out a good way to do it, switching NT386 from awful slow frequent TlsGetValue/TlsSetValue to manipulating the linked list in fs:0, that would be nice, and might incur a C runtime dependency, but well worth it. The way Modula-3 works here is terrible. Another compromise option is probably __declspec(thread), though there is trickiness there in terms of being in a .dll that isn't used by the .exe. - Jay > CC: jkrell at elego.de; m3devel at elegosoft.com > From: hosking at cs.purdue.edu > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > Date: Sat, 19 Jan 2008 18:52:12 -0500 > To: jayk123 at hotmail.com > > OK, that's what I had hoped. > > Sounds good! > > On Jan 19, 2008, at 1:35 PM, Jay wrote: > > > ps -- look at m3-sys/cminstall/src/config/NT386GNU. > > While it is very very similar to NT386, and even outputs foo.lib > > and foo.lib.sa like NT386, it uses gcc for C compilation, linking, > > and m3cg for the backend. > > It is very "GNU" in tools, but not runtime. > > > > - Jay > > > > From: jayk123 at hotmail.com > > To: hosking at cs.purdue.edu; jkrell at elego.de > > CC: m3devel at elegosoft.com > > Subject: RE: [M3devel] [M3commit] CVS Update: cm3 > > Date: Sat, 19 Jan 2008 18:32:35 +0000 > > > > It DOES use m3cc/ld/as, and mklib for building static .libs, though > > that could probably be gcc/ar/dlltools if I figured it out. > > "Everything" except m3cc/m3gdb can be built with just MinGWin. > > Building m3cc requires MSys as well. > > Building m3gdb requires Cygwin. > > m3cg is not dependent on cygwin1.dll, nor are any other Modula-3 > > outputs. m3gdb is dependent on cygwin1.dll. > > > > Using Cygwin probably would work..and I could try it to see if it > > resolves the RTLinker problem. > > > > As well, we could have something like, in cm3.cfg you could set > > MINGWIN_ROOT, MSYS_ROOT, and/or CYGWIN_ROOT, to guide what tools > > are used, OR we can have some variable: > > > > GNU_MODE = 0 % Do not use GNU tools at all -- today's NT386 > > GNU_MODE = 1 % Use GNU tools minimally -- today's NT386GNU > > GNU_MODE = 2 % Use GNU tools maximally -- not existant but probably > > easy > > > > Eh..I know, not great.. what do "minimally" and "maximally" mean. > > > > I think we have the problem of a) many viable choices b) want to > > make several of them available c) just don't know what to call > > things and what the interface should be. As well as an interop > > question, since jmpbuf does vary in size between cygwin1.dl and > > everything else. > > > > Further down the line, there are other linkers, other compilers, > > other runtimes. The design here and now might take them into > > consideration. > > Gasp..I just realized, there is also another good backend option. > > parse.c's approach could probably be adapted to Open Watcom AND > > they might even take the changes (not that I have asked, I just > > thought of this). And that would net you progress toward a) 32 bit > > MS-DOS target b) OS/2 target, c) Netware target d) gcc-free Linux > > target, since the support all of them. > > Other target possibilities include Digital Mars compiler/linker, > > CodeWarrior (I know, dead and all), etc. Open Watcom is probably > > the most interesting since it is open source... > > > > - Jay > > > > > > > > > From: hosking at cs.purdue.edu > > > Date: Sat, 19 Jan 2008 12:48:06 -0500 > > > To: jkrell at elego.de > > > CC: m3devel at elegosoft.com > > > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > > > > > So, I am very confused now. Does NT386GNU no longer mean use of the > > > full set of GNU tools m3cc/ld/as, as would be available under > > > Cygwin? I thought the point of this was to be able to run in as much > > > of a GNU environment as possible. GNU to me means the whole > > > toolsuite not just m3cc. To me, a GNU-based environment on Windows > > > holds great attraction, since it consists of tools that I generally > > > always install on Windows, that I know, and are similar to the other > > > platforms I use. > > > > > > On Jan 19, 2008, at 4:11 AM, Jay Krell wrote: > > > > > > > CVSROOT: /usr/cvs > > > > Changes by: jkrell at birch. 08/01/19 04:11:34 > > > > > > > > Modified files: > > > > cm3/m3-libs/m3core/src/runtime/: m3makefile > > > > cm3/m3-sys/cminstall/src/config/: NT386GNU > > > > cm3/m3-sys/m3front/src/builtinInfo/: InfoModule.m3 > > > > cm3/m3-sys/m3middle/src/: Target.m3 > > > > > > > > Log message: > > > > m3-sys/m3middle/src/Target.m3 > > > > m3-libs/m3core/src/runtime/m3makefile > > > > m3-sys\m3front\src\builtinInfo\InfoModule.m3 > > > > > > > > switch NT386GNU to be Win32 instead of POSIX > > > > switch NT386GNU to _setjmp instead of setjmp > > > > jmp_buf size still big like Cygwin > > > > rewrite NT386GNU config file -- almost identical to NT386 > > > > mingwin required for building Modula-3 programs > > > > mingwin AND msys required for building m3cc > > > > > > > > To boot: > > > > > > > > install Python (www.activestate.com) > > > > > > > > have a working NT386 system > > > > get current source > > > > Mine is at c:\dev2\cm3.2 (cm3 is has other paused work, dev was > > > > taken by Unix) > > > > > > > > get and install binary distribution (5.1.3 works, anything newer > > > > should work) > > > > I install to c:\cm3 > > > > copy %CVSROOT%\m3-sys\cminstall\src\config\cm3.cfg to \cm3\bin > > > > \cm3.cfg > > > > > > > > Have a Visual C++ toolset (cl and link) > > > > and run the vcvars link on the start menu (this can/will be made > > > > easier) > > > > Almost any version should work. > > > > if you are using Visual C++ 8.0 (RTM?), rename away its mt.exe > > > > and get a newer from such as from the Platform SDK. Otherwise it > > > > crashes. > > > > This is not specific to NT386GNU, just that I recently removed the > > > > Platform SDK > > > > from my %PATH%. > > > > > > > > cd %CVSROOT%\scripts\python > > > > .\upgrade > > > > > > > > install msys and mingwin from http://www.mingw.org (links to > > > > SourceForge) > > > > for mingwin, you only need the "base" > > > > msys tells you to avoid mingwin make, in favor of msys make, and I > > > > did that > > > > > > > > I install to the defaults > > > > c:\msys\1.0 > > > > c:\mingw > > > > > > > > if you don't install to the defaults, add > > > > \bin and > > > to the start, but which order between the two?) > > > > > > > > if you do install to the defaults, scripts\python will fix path > > > > for you, > > > > if there is no gcc/as/sh on our $PATH > > > > > > > > cd %CVSROOT%\scripts\python > > > > upgrade && bootntgnu > > > > > > > > NOTE THE RESULTING BINARIES DO NOT YET WORK, but this is still > > > > progress. > > > > > > > > These instructions inevitably to be further tested and refined and > > > > placed elsewhere! > > > > > > > > > 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 jayk123 at hotmail.com Sun Jan 20 05:56:00 2008 From: jayk123 at hotmail.com (Jay) Date: Sun, 20 Jan 2008 04:56:00 +0000 Subject: [M3devel] more assembly symbols please? In-Reply-To: <1A973B4E-23DD-4B85-B42F-9070E93429BB@cs.purdue.edu> References: <2717B275-2548-41BC-BD1E-8742BCE6FA51@cs.purdue.edu> <1A973B4E-23DD-4B85-B42F-9070E93429BB@cs.purdue.edu> Message-ID: MinGWin (GNU ld) I might try putting together a totally Cygwin system to see if that works, to try to understand where the problem is. This really shouldn't be so hard from the information I have though.. :( Fishing with Cygwin should not be needed.. I can dump the ModuleInfo from C and I can see where the bad one is, I just need to trace through its creation to find where it goes bad... I assume it is NOT related to the fact that assembly/object file names get truncated to 8 characters, RTHeapInfo.m3 => RTHeapIn.m3 but so far that's all I see to "what is special about RTHeapInfo?". - Jay > CC: m3devel at elegosoft.com > From: hosking at cs.purdue.edu > Subject: Re: [M3devel] more assembly symbols please? > Date: Sat, 19 Jan 2008 18:46:59 -0500 > To: jayk123 at hotmail.com > > Which linker are you using? Could that be a factor? > > On Jan 19, 2008, at 1:49 PM, Jay wrote: > > > Thanks. m3cg -y for full tracing also dumps relevant stuff at the end. > > I'll try m3cgcat too. I should just be able to build/run an NT386 > > version. > > My C tracing does "prove" the problem is RTHeapInfo, but I still > > haven't figured out why. > > I've started skimming the code that builds that data...still a ways > > off from solving this I think. > > I have some suspicion the linker is moving things around that were > > otherwise correct, but I am far from proving that or fixing it. > > I'd like to first verify that the "m3front" / m3cg output is correct. > > The lack of labels in the as actually is a counter point to the > > movement theory, hard for linker to get a handle on anything to > > move around, it's just one blob. > > > > - Jay > > > > > > > > > CC: m3devel at elegosoft.com > > > From: hosking at cs.purdue.edu > > > Subject: Re: [M3devel] more assembly symbols please? > > > Date: Sat, 19 Jan 2008 12:33:08 -0500 > > > To: jayk123 at hotmail.com > > > > > > Take a look at the .mc intermediate code output if you want to see > > > that section of the data. There are at least comments. Use m3cgcat - > > > binary < x.mc > x.mo to view it (You can run m3cgcat on any other > > CM3 > > > install). > > > > > > On Jan 19, 2008, at 6:02 AM, Jay wrote: > > > > > > > Any chance the m3cg output could have, um, some symbols for the > > > > global data? > > > > It's kind of a pain to decode.. > > > > > > > > The module/import info is ok a lot, lots of runtime links ok. > > > > I think the bad one might be RTHeapInfo but I have to decode the > > > > very bare of symbols assembly.. > > > > or comments? Like for record fields? > > > > Still thinking of sticking a call out to C code...Even > > > > OutputDebugString since RTIO isn't working... > > > > > > > > I looked through the m3cg --help, didn't find anything. > > > > > > > > Tony? > > > > > > > > _MM_RTHeapInfo: > > > > 0 .long _L_1+224 > > > > 4 .long _MM_RTHeapInfo+52 > > > > 8 .long _MM_RTHeapInfo+308 > > > > 12,16 .space 8 > > > > 20 .long _L_1+152 > > > > 24 .space 4 > > > > 28 .long _L_1+220 > > > > 32 .long _L_1+220 > > > > 36 .long _MM_RTHeapInfo+160 > > > > 40 .space 4 > > > > .long _RTHeapInfo_M3 > > > > > > > > I get to count out to 160 bytes from here..: > > > > > > > > _L_1: > > > > 0 .byte 48 > > > > 1 .byte 49 > > > > 2 .byte 50 > > > > 3 .byte 51 > > > > 4 .byte 52 > > > > 5 .byte 53 > > > > 6 .byte 54 > > > > 7 .byte 55 > > > > 8 .byte 56 > > > > 9 .byte 57 > > > > a .byte 97 > > > > b .byte 98 > > > > c .byte 99 > > > > d .byte 100 > > > > e .byte 101 > > > > f .byte 102 > > > > 10 .long _RTHooks__TextLitInfo > > > > 14 .long _RTHooks__TextLitGetChar > > > > 18 .long _RTHooks__TextLitGetWideChar > > > > 1c .long _RTHooks__TextLitGetChars > > > > 20 .long _RTHooks__TextLitGetWideChars > > > > 24 .long 2 > > > > 28 .long _L_1+16 > > > > 2c .long 7 > > > > 30 .ascii "shownew" > > > > 37 .space 1 > > > > 38 .long 2 > > > > 3c .long _L_1+16 > > > > 40 .long 6 > > > > 44 .ascii "update" > > > > 4a .space 2 > > > > 4c .ascii "RTHeapInfo_M3" > > > > 50 .space 1 > > > > .ascii "Init" > > > > .space 1 > > > > > > > > I'll try the C code.. > > > > > > > > - Jay > > > > > > > > > > > > > > > > > > > > > > > > Connect and share in new ways with Windows Live. Get it now! > > > > > > > > > Shed those extra pounds with MSN and The Biggest Loser! Learn more. > _________________________________________________________________ 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 Jan 20 05:57:49 2008 From: jayk123 at hotmail.com (Jay) Date: Sun, 20 Jan 2008 04:57:49 +0000 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <5BFBD626-F492-4058-9A7A-6CB295753585@cs.purdue.edu> References: <20080119031134.4B6A510D4625@birch.elegosoft.com> <5BFBD626-F492-4058-9A7A-6CB295753585@cs.purdue.edu> Message-ID: Right, agreed, thanks for the reminder. - Jay > CC: jkrell at elego.de; m3devel at elegosoft.com > From: hosking at cs.purdue.edu > > On Jan 19, 2008, at 1:32 PM, Jay wrote: > > > Gasp..I just realized, there is also another good backend option. > > parse.c's approach could probably be adapted to Open Watcom AND > > they might even take the changes (not that I have asked, I just > > thought of this). And that would net you progress toward a) 32 bit > > MS-DOS target b) OS/2 target, c) Netware target d) gcc-free Linux > > target, since the support all of them. > > I would plump for llvm. Apple is using it heavily these days and may > be pushing it into their Mac compiler toolchain. _________________________________________________________________ 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 Jan 20 07:34:14 2008 From: jayk123 at hotmail.com (Jay) Date: Sun, 20 Jan 2008 06:34:14 +0000 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <200801200346.m0K3k3Em023728@camembert.async.caltech.edu> References: Your message of "Sat, 19 Jan 2008 12:48:06 EST." <200801200346.m0K3k3Em023728@camembert.async.caltech.edu> Message-ID: Mika, while I agree such a target might be interesting, and might just about work now, there is another target that is also definitely interesting, and more interesting to some folks, and perhaps more efficient, smaller, faster. There needs to be a way to ask for one or the other. People want one. People want the other. I think I've seen about two people ask for each. Wow a small number. There are tools and there is runtime, and you can pick and chose. But too many choices and people get confused, so there's a need to prepackage some combinations under small names. At the moment, NT386GNU means use GNU tools, but otherwise be like NT386. There are really several variables in all this. There are three threading models available, and they probably all work or could be easily made to. There are two underlying GUI libraries, ditto. There is PERHAPS Win9x compatibility to consider. Cygwin is dropping that in newer versions. What is a "target"? vs. what is a "configuration"? Odds are fairly good that if you merely alter $PATH one way or the other, and undo my small changes below to what m3makefile includes what, and what cm3 assumes OSTYPE is, Cygwin will work, at least as well as I have NT386GNU otherwise working. That is, all three of these targets are so darn similar that is almost just a matter of "configuration" and could perhaps be made so. I am reluctant to blow up the size of jmpbuf to enable arbitrary mixing however. The tricky part is not so much making it work, but what to call it, how to expose it to users, as well as perhaps streamlining the setup. I am better at "making it work" however and am open to suggestions all around. There is yet another direction and it is obviously the direction things were going -- neither GNU nor MS tools. There is already the x86 backend written in Modula-3. It is noticably very much faster than the gcc backend. There is very little C code in the system and it could probably all be rewritten in Modula-3..the beauty of its "optional safety"...though your point is very valid as to outside the system. There is already a start of a runtime linker that loads .objs. The C runtime dependency is very very minimal already. Finish those last two points and you have a "self contained" system , from a certain point of view, a common point of view, though there is still the dependency on kernel32.dll, user32.dll, gdi32.dll, the "OS" as people like to label it, though it is really just another bunch of code in most respects and not something as "special" as people think, and you can be more or less dependent on it as well -- remember that Modula-3 when using the vtalarm threads does its own scheduling (I think), a task people normally think of as provided by an "OS". (I believe Mary Fernandez already wrote a relatively easily retargetable linker and debugger in Modula-3, but I could be wrong.) I just realized another target -- NT386-Interix or such, these days known as "Services for Unix" and I think a free download. This is YET ANOTHER very Posixish environment. As well, there is the question from earlier of "What is Posix?" It's not like Microsoft doesn't provide open/read/write/close. They do. What all is in the Cygwin headers that people want? The availability of sh should have little impact on your Modula-3 code, right? You aren't running command lines in it, right? It's not like portable standard C and C++ can't be compiled just as well, if not better and faster, by the Microsoft compiler. It can be. I realize there are details, levels of ANSI conformity, and there are language extensions on both sides. Now, since I have been debugging stuff lately, I realize there could be a big question as to debuggers. More importantly, debug information format. My experience lately is that this is an either/or choice, and you can't have it both ways. If you are very used to gdb/m3gdb, you must use the GNU tools. But you don't need Cygwin (except to build m3gdb or acquire gdb). If you are very used to windbg/ntsd/cdb/Visual Studio, well you must use the non-gcc backend, the Microsoft C compiler for the little bit of C/C++ if you want to debug it, the Microsoft linker I assume, however you aren't going to be likely happy. The non-gcc backend only outputs line number information, no types, no locals. It's not a pleasant experience, but at least you can see the stack. You can also to some extent use both. You can build your code for either platform and flit around between the two. Or you can flit around between debuggers and deal with a lack of symbols in one, and just poke around in memory, using information gleaned from the other. But again, this doesn't have much to do with Cygwin or not Cygwin. I've only been going at this a short time, so maybe gdb does better with the Cygwin output. I don't know. Sorry for the tone. We are actually in agreement, essentially. I have been largely on the fence and just asking what to call things, and everyone else is clearly on one side or the other. I personally will not use Cygwin if I can help it, but I do use it for cvs and ssh at least. I actually hardlink swaths of it into my Windows directory, the useful command line utilities, that which likely one non-configurable version would suffice -- ie: not gcc/ld/ar/as. If there was one true gcc/ld/ar/as, I would hardlink it in too. Likewise with cl/link. e.g. I have windiff in there, but not cl/link. I don't want that cygwin1.dll dependency and then have to understand the licensing... So the non-Cygwin target came first. It is easier. It is faster. It is what I prefer. Maybe there will be a Cygwin target. Maybe someone else will provide it? It should be clear btw that the real work here was all done for us in gcc/ld, and cm3. The rest is easier. Besides..who is going to do the work here, and who is going to use it? Are Windows users asking for a more Posixish system or are Posix users saying what Windows should be like? Will they move to it? Bah humbug. - Jay > To: hosking at cs.purdue.edu> To: m3devel at elegosoft.com> Date: Sat, 19 Jan 2008 19:46:03 -0800> From: mika at async.caltech.edu> Subject: Re: [M3devel] [M3commit] CVS Update: cm3> > Can I add a perhaps obvious observation?> > NT386GNU must, of all things, mean that the code will compile and> link cleanly, with a minimum of fuss, against Cygwin's headers> and libraries. I have never used MS's C tools so I don't know> if this is the case with them. It is of course the case when> you use GNU ld, etc.> > When building large software in Modula-3 it's almost inevitable> that, since the language is used by so few people, you will have a> need to call out to C code (or Fortran code, or some other compiled> code, with C interfaces). If you develop on Unix and use Cygwin> to port to Windows, it makes no sense to distinguish between NT386> and NT386GNU unless the latter has pretty much the same environment> as the Unix system.> > Mika> > Tony Hosking writes:> >So, I am very confused now. Does NT386GNU no longer mean use of the > >full set of GNU tools m3cc/ld/as, as would be available under > >Cygwin? I thought the point of this was to be able to run in as much > >of a GNU environment as possible. GNU to me means the whole > >toolsuite not just m3cc. To me, a GNU-based environment on Windows > >holds great attraction, since it consists of tools that I generally > >always install on Windows, that I know, and are similar to the other > >platforms I use.> >> >On Jan 19, 2008, at 4:11 AM, Jay Krell wrote:> >> >> CVSROOT: /usr/cvs> >> Changes by: jkrell at birch. 08/01/19 04:11:34> >>> >> Modified files:> >> cm3/m3-libs/m3core/src/runtime/: m3makefile> >> cm3/m3-sys/cminstall/src/config/: NT386GNU> >> cm3/m3-sys/m3front/src/builtinInfo/: InfoModule.m3> >> cm3/m3-sys/m3middle/src/: Target.m3> >>> >> Log message:> >> m3-sys/m3middle/src/Target.m3> >> m3-libs/m3core/src/runtime/m3makefile> >> m3-sys\m3front\src\builtinInfo\InfoModule.m3> >> > >> switch NT386GNU to be Win32 instead of POSIX> >> switch NT386GNU to _setjmp instead of setjmp> >> jmp_buf size still big like Cygwin> >> rewrite NT386GNU config file -- almost identical to NT386> >> mingwin required for building Modula-3 programs> >> mingwin AND msys required for building m3cc> >> > >> To boot:> >> > >> install Python (www.activestate.com)> >> > >> have a working NT386 system> >> get current source> >> Mine is at c:\dev2\cm3.2 (cm3 is has other paused work, dev was > >> taken by Unix)> >> > >> get and install binary distribution (5.1.3 works, anything newer > >> should work)> >> I install to c:\cm3> >> copy %CVSROOT%\m3-sys\cminstall\src\config\cm3.cfg to \cm3\bin > >> \cm3.cfg> >> > >> Have a Visual C++ toolset (cl and link)> >> and run the vcvars link on the start menu (this can/will be made > >> easier)> >> Almost any version should work.> >> if you are using Visual C++ 8.0 (RTM?), rename away its mt.exe> >> and get a newer from such as from the Platform SDK. Otherwise it > >> crashes.> >> This is not specific to NT386GNU, just that I recently removed the > >> Platform SDK> >> from my %PATH%.> >> > >> cd %CVSROOT%\scripts\python> >> .\upgrade> >> > >> install msys and mingwin from http://www.mingw.org (links to > >> SourceForge)> >> for mingwin, you only need the "base"> >> msys tells you to avoid mingwin make, in favor of msys make, and I > >> did that> >> > >> I install to the defaults> >> c:\msys\1.0> >> c:\mingw> >> > >> if you don't install to the defaults, add> >> \bin and >> to the start, but which order between the two?)> >> > >> if you do install to the defaults, scripts\python will fix path > >> for you,> >> if there is no gcc/as/sh on our $PATH> >> > >> cd %CVSROOT%\scripts\python> >> upgrade && bootntgnu> >> > >> NOTE THE RESULTING BINARIES DO NOT YET WORK, but this is still > >> progress.> >> > >> These instructions inevitably to be further tested and refined and > >> placed elsewhere! _________________________________________________________________ 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 Jan 20 13:08:20 2008 From: jayk123 at hotmail.com (Jay) Date: Sun, 20 Jan 2008 12:08:20 +0000 Subject: [M3devel] more assembly symbols please? In-Reply-To: <1A973B4E-23DD-4B85-B42F-9070E93429BB@cs.purdue.edu> References: <2717B275-2548-41BC-BD1E-8742BCE6FA51@cs.purdue.edu> <1A973B4E-23DD-4B85-B42F-9070E93429BB@cs.purdue.edu> Message-ID: Exact same result with MS link. Quite the succesful interop. :) I copied in all the relevant *o and *obj files (avoiding mklib/*.lib as a factor) to C:\dev2\cm3.2\m3-sys\cm3\NT386GNU and selectively from \mingw\lib (like just in the end libcgcc.a for arithmetic helpers) and then link -out:cm3.exe *.io *.mo *.obj comctl32.lib gdi32.lib user32.lib wsock32.lib netapi32.lib libgcc.a kernel32.lib advapi32.lib msvcrt.lib prints the same thing, crashes due to the same data. Which is to say, in the great toolset debate, you can use the gcc back end (and as) for Modula-3, but then either ld or link and probably cl or gcc. :) Except..it still doesn't quite work.. I guess "collect2" is a synonym for ld? - Jay From: jayk123 at hotmail.comTo: hosking at cs.purdue.eduCC: m3devel at elegosoft.comSubject: RE: [M3devel] more assembly symbols please?Date: Sun, 20 Jan 2008 04:56:00 +0000 MinGWin (GNU ld)I might try putting together a totally Cygwin system to see if that works, to try to understand where the problem is.This really shouldn't be so hard from the information I have though.. :(Fishing with Cygwin should not be needed..I can dump the ModuleInfo from C and I can see where the bad one is, I just need to trace through its creation to find where it goes bad...I assume it is NOT related to the fact that assembly/object file names get truncated to 8 characters, RTHeapInfo.m3 => RTHeapIn.m3 but so far that's all I see to "what is special about RTHeapInfo?". - Jay > CC: m3devel at elegosoft.com> From: hosking at cs.purdue.edu> Subject: Re: [M3devel] more assembly symbols please?> Date: Sat, 19 Jan 2008 18:46:59 -0500> To: jayk123 at hotmail.com> > Which linker are you using? Could that be a factor?> > On Jan 19, 2008, at 1:49 PM, Jay wrote:> > > Thanks. m3cg -y for full tracing also dumps relevant stuff at the end.> > I'll try m3cgcat too. I should just be able to build/run an NT386 > > version.> > My C tracing does "prove" the problem is RTHeapInfo, but I still > > haven't figured out why.> > I've started skimming the code that builds that data...still a ways > > off from solving this I think.> > I have some suspicion the linker is moving things around that were > > otherwise correct, but I am far from proving that or fixing it.> > I'd like to first verify that the "m3front" / m3cg output is correct.> > The lack of labels in the as actually is a counter point to the > > movement theory, hard for linker to get a handle on anything to > > move around, it's just one blob.> >> > - Jay> >> >> >> > > CC: m3devel at elegosoft.com> > > From: hosking at cs.purdue.edu> > > Subject: Re: [M3devel] more assembly symbols please?> > > Date: Sat, 19 Jan 2008 12:33:08 -0500> > > To: jayk123 at hotmail.com> > >> > > Take a look at the .mc intermediate code output if you want to see> > > that section of the data. There are at least comments. Use m3cgcat -> > > binary < x.mc > x.mo to view it (You can run m3cgcat on any other > > CM3> > > install).> > >> > > On Jan 19, 2008, at 6:02 AM, Jay wrote:> > >> > > > Any chance the m3cg output could have, um, some symbols for the> > > > global data?> > > > It's kind of a pain to decode..> > > >> > > > The module/import info is ok a lot, lots of runtime links ok.> > > > I think the bad one might be RTHeapInfo but I have to decode the> > > > very bare of symbols assembly..> > > > or comments? Like for record fields?> > > > Still thinking of sticking a call out to C code...Even> > > > OutputDebugString since RTIO isn't working...> > > >> > > > I looked through the m3cg --help, didn't find anything.> > > >> > > > Tony?> > > >> > > > _MM_RTHeapInfo:> > > > 0 .long _L_1+224> > > > 4 .long _MM_RTHeapInfo+52> > > > 8 .long _MM_RTHeapInfo+308> > > > 12,16 .space 8> > > > 20 .long _L_1+152> > > > 24 .space 4> > > > 28 .long _L_1+220> > > > 32 .long _L_1+220> > > > 36 .long _MM_RTHeapInfo+160> > > > 40 .space 4> > > > .long _RTHeapInfo_M3> > > >> > > > I get to count out to 160 bytes from here..:> > > >> > > > _L_1:> > > > 0 .byte 48> > > > 1 .byte 49> > > > 2 .byte 50> > > > 3 .byte 51> > > > 4 .byte 52> > > > 5 .byte 53> > > > 6 .byte 54> > > > 7 .byte 55> > > > 8 .byte 56> > > > 9 .byte 57> > > > a .byte 97> > > > b .byte 98> > > > c .byte 99> > > > d .byte 100> > > > e .byte 101> > > > f .byte 102> > > > 10 .long _RTHooks__TextLitInfo> > > > 14 .long _RTHooks__TextLitGetChar> > > > 18 .long _RTHooks__TextLitGetWideChar> > > > 1c .long _RTHooks__TextLitGetChars> > > > 20 .long _RTHooks__TextLitGetWideChars> > > > 24 .long 2> > > > 28 .long _L_1+16> > > > 2c .long 7> > > > 30 .ascii "shownew"> > > > 37 .space 1> > > > 38 .long 2> > > > 3c .long _L_1+16> > > > 40 .long 6> > > > 44 .ascii "update"> > > > 4a .space 2> > > > 4c .ascii "RTHeapInfo_M3"> > > > 50 .space 1> > > > .ascii "Init"> > > > .space 1> > > >> > > > I'll try the C code..> > > >> > > > - Jay> > > >> > > >> > > >> > > >> > > >> > > > Connect and share in new ways with Windows Live. Get it now!> > >> >> >> > Shed those extra pounds with MSN and The Biggest Loser! Learn more.> 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 wagner at elegosoft.com Sun Jan 20 15:56:49 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Sun, 20 Jan 2008 15:56:49 +0100 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: References: <20080119031134.4B6A510D4625@birch.elegosoft.com> Message-ID: <20080120155649.tl5ghxhnl8o0g4cs@mail.elegosoft.com> Quoting Jay : > Good, a happy customer. :) > >> GNU_MODE = 0 % Do not use GNU tools at all -- today's NT386 >> GNU_MODE = 1 % Use GNU tools minimally -- today's NT386GNU >> GNU_MODE = 2 % Use GNU tools maximally -- not existant but probably >> easy >> >> Eh..I know, not great.. what do "minimally" and "maximally" mean. > > I'm still fishing for anyone to provide answers to these > less important decisions that I have trouble with. > Otherwise maybe no NT Cygwin system. > > TARGETs = { NT386, NT386GNU, NT386CYGWIN }? > TARGETs = { NT386, NT386MINGWIN, NT386CYGWIN }? > TARGETs = { NT386 + GNU_MODE }? > > The one reason I don't favor NT386 + GNU_MODE is that Cygwin has a > much larger jmpbuf than the others. > I think same TARGET implies code can be linked together, and I think > varying jmpbuf implies otherwise. > So NT386 and NT386MINGWIN should rarely cross paths with NT386CYGWIN. I think a new target is called for if I have understood everything right. We need one pure native target (NT386), one pure-Cygwin-based target (NT386_CYGWIN?) and one mix of runtime, gnu tools and mingwin (NT386_MINGWIN?). As NT386GNU already exists, we must decide if we want to use it as we traditionally did (all Cygwin) or the mixed implementation (Mingwin and much Windows RT). > I also do NOT like this ad-hoc naming style. > PPC_DARWIN, I386_DARWIN are much more to my style. > The names should be somehow hierarchical, except, I realize, there > isn't necessarily one "path" of > stuff which to name platforms, though the GNU folks have settled on > a way or two. > They have triples or quadruples -- processor-hardware-os or such, > however this doesn't > clearly suffice. Well, yes, something more systematic would have been better, but to break with the history will cause much trouble for all users and the infrastructure. So I'd rather vote that only new targets get more systematic names. > Something that accomodates: > NT386 + LLVM > NT386 + Watcom, linker and/or backend and/or runtime > NT386 + Digital Mars linker and/or backend and/or runtime > A C generating backend, and then linker/runtime > and similar IA64, AMD64 variants would be good. I'm not sure that a C generating backend would really help matters. This was done in the first implementation of DEC, and they soon abandoned it as C had proven to be a bad choice as intermediate language. I agree it would be great for cross-compilation etc. As far as C and RT dependencies of native Windows compilers go, I don't see why this couldn't be just a question of another cm3.cfg setup. > To a large extent, these can be few platforms, subject to > configuration, like if all > the linkers consume a common file format (not clear), and if all the > jmpbufs are the same > size (known to be partly true, partly false). Yes, jmpbuf is always a problem for user threads and exceptions. On Unix systems the jmpbuf and other important low-level structures are always defined by the system headers and independent of compilers AFAIK, so I'm a bit surprised that it should be different on Windows. But maybe I'm just wrong and haven't just seen the right counter examples... > Oh and another thing, the runtime dependency is very likely cuttable, however > PRESUMABLY real world applications (if there are any) link in a > substantial amount of > C or C++, in which case, it isn't necessarily cuttable. Yes. Real world applications tend to link other libraries (C, C++, Fortran, ...) and even often call other applications like sh etc. > As well, if I can figure out a good way to do it, switching NT386 > from awful slow > frequent TlsGetValue/TlsSetValue to manipulating the linked list in > fs:0, that would be nice, > and might incur a C runtime dependency, but well worth it. The way > Modula-3 works here > is terrible. Another compromise option is probably > __declspec(thread), though there is trickiness there > in terms of being in a .dll that isn't used by the .exe. Such optimizations should be done depending on the target. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Jan 20 17:26:28 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 20 Jan 2008 11:26:28 -0500 Subject: [M3devel] my status on win32 In-Reply-To: <479267C2.1E75.00D7.1@scires.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> <477EA137.1E75.00D7.1@scires.com> <478D394B.1E75.00D7.1@scires.com> <478D47FB.1E75.00D7.1@scires.com> <478DBF8D.1E75.00D7.1@scires.com> <478DE973.1E75.00D7.1@scires.com> <47908659.1E75.00D7.1@scires.com> <20080119204810.3wmumqgms88sccw4@mail.elegosoft.com> <479267C2.1E75.00D7.1@scires.com> Message-ID: I'm not sure what I mean since I am a Windows ignoramus. Jay? On Jan 19, 2008, at 9:12 PM, Randy Coleburn wrote: > Hi Tony: > > Are you suggesting that when the program is built standalone it > maps libraries differently? I know there is a difference between > dynamic vs. static libraries, but are you suggesting that a > different library is being mapped than the vendor's equivalent of > the dynamic library? How would I check for this situation? > > Your suggestion seems plausible since the source is not recompiled; > instead, the linker is used to change the way the EXE is put > together and that seems to cause the difference in operation as far > as pixmaps are concerned. > > Regards, > Randy > > >>> Tony Hosking 1/19/2008 6:47 PM >>> > I would perhaps suspect a bad library mapping. > > On Jan 19, 2008, at 2:48 PM, Olaf Wagner wrote: > > > Quoting Randy Coleburn : > >> 1. pixmaps aren't rendered properly on the screen. They look > really > >> bad. I recall having this problem a while back with one of the > early > >> 5.x releases, so I guess it was never solved. I've got some old > test > >> programs I try to dig out and see if I can find out what is going > >> on. I > >> seem to recall that building standalone in the past seemed to > fix the > >> problem, so this is a real mystery. > > > > Hi Randy, > > > > I'm afraid I wasn't able to solve it directly some years ago and > > then forgot about it due to more urgent tasks. > > > > I think we should try to narrow down the location of the problem > > (i.e. is it in the runtime, code generation, linker, or windows > > libraries). > > > > As you still have the 4.1 code of the Windows libraries, could you > > first try to build them with the new compiler and see if it makes > > a difference if you link against them? > > > > It may also be worthwhile to compare the commands actually used > > for linking (use -commands). That is, before we turn to the actual > > generated code... > > > > I still haven't got Windows access here, so I can just suggest what > > to do... > > > > Olaf > > -- > > Olaf Wagner -- elego Software Solutions GmbH > > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, > > Germany > > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Jan 20 17:48:26 2008 From: jayk123 at hotmail.com (Jay) Date: Sun, 20 Jan 2008 16:48:26 +0000 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <20080120155649.tl5ghxhnl8o0g4cs@mail.elegosoft.com> References: <20080119031134.4B6A510D4625@birch.elegosoft.com> <20080120155649.tl5ghxhnl8o0g4cs@mail.elegosoft.com> Message-ID: > the infrastructure. So I'd rather vote that only new targets get> more systematic names. Of course, though the existing names suggest new names, and not clear the value of the existing NT386GNU. Ie. is there a benefit to keep it in use with some meaning or not? Cygwin does have a larger jmpbuf than msvcr*.dll/mingwin. I think it holds sigaction state besides register state. "NT" and "Win" seem redundant. I386_MINGWIN? I386_CYGWIN? NT386_GNU? NT386_MINGNU? Ok, I admit that NT386_CYGWIN NT386_MINGWIN despite the redundancy, clearly point to existing projects that probably have name recognition. And building from NT386 is reasonable -- as was I saying about existing names influencing new names. A C generating backend gets you perhaps easier retargeting as well. I do see there is "MINGWIN64" out there, for AMD64. Not sure what the state of IA64 is though... (See -- you should avoid saying "32" or "64" in stuff, Win32 => Win, Win64 => Win.) I also would agree that creating one target instead of two is probably a good idea -- seems easier. I am not sure if current state is relevant. I mean, is NT386GNU really working and in use anywhere? Is PM3 in use? If so, then matching their meaning would be good. Or even going beyond that -- to Trestle on X Windows. :) (Though CygwinX doesn't exactly appear active.) And thus the precedent for no underscore. NT386MINGWIN ? NT386MINGNU ? I don't know if "MSYS" needs a place in this name. It is needed for building m3cc. I wonder if a hybrid/adaptive approach will be desired -- if Cygwin is available, the MinGWin target could use it to build m3gdb, since it can't otherwise. Hint for anyone trying out Cygwin and getting an odd mix of paths: mkdir \cygdrive get junction.exe from the former www.sysinternals.com junction \cygdrive\c c:\ now when some Cygwin code passes /cygdrive/c to Win32 code, it will just work, no translation needed. If you have multiple drives, I guess just fully populate each one c:\cygdrive\c => c:\ c:\cygdrive\d => d:\ d:\cygdrive\c => c:\ d:\cygdrive\d => d:\ etc. but I haven't tried that. Or, to reduce the multiplication, set them all up on c: and have d:\cygdrive => c:\cygdrive, e:\cygdrive => c:\cygdrive, etc. - Jay > Date: Sun, 20 Jan 2008 15:56:49 +0100> From: wagner at elegosoft.com> To: m3devel at elegosoft.com> Subject: Re: [M3devel] [M3commit] CVS Update: cm3> > Quoting Jay :> > > Good, a happy customer. :)> >> >> GNU_MODE = 0 % Do not use GNU tools at all -- today's NT386> >> GNU_MODE = 1 % Use GNU tools minimally -- today's NT386GNU> >> GNU_MODE = 2 % Use GNU tools maximally -- not existant but probably> >> easy> >>> >> Eh..I know, not great.. what do "minimally" and "maximally" mean.> >> > I'm still fishing for anyone to provide answers to these> > less important decisions that I have trouble with.> > Otherwise maybe no NT Cygwin system.> >> > TARGETs = { NT386, NT386GNU, NT386CYGWIN }?> > TARGETs = { NT386, NT386MINGWIN, NT386CYGWIN }?> > TARGETs = { NT386 + GNU_MODE }?> >> > The one reason I don't favor NT386 + GNU_MODE is that Cygwin has a > > much larger jmpbuf than the others.> > I think same TARGET implies code can be linked together, and I think > > varying jmpbuf implies otherwise.> > So NT386 and NT386MINGWIN should rarely cross paths with NT386CYGWIN.> > I think a new target is called for if I have understood everything right.> We need one pure native target (NT386), one pure-Cygwin-based target> (NT386_CYGWIN?) and one mix of runtime, gnu tools and mingwin> (NT386_MINGWIN?).> > As NT386GNU already exists, we must decide if we want to use it as> we traditionally did (all Cygwin) or the mixed implementation> (Mingwin and much Windows RT).> > > I also do NOT like this ad-hoc naming style.> > PPC_DARWIN, I386_DARWIN are much more to my style.> > The names should be somehow hierarchical, except, I realize, there > > isn't necessarily one "path" of> > stuff which to name platforms, though the GNU folks have settled on > > a way or two.> > They have triples or quadruples -- processor-hardware-os or such, > > however this doesn't> > clearly suffice.> > Well, yes, something more systematic would have been better, but> to break with the history will cause much trouble for all users and> the infrastructure. So I'd rather vote that only new targets get> more systematic names.> > > Something that accomodates:> > NT386 + LLVM> > NT386 + Watcom, linker and/or backend and/or runtime> > NT386 + Digital Mars linker and/or backend and/or runtime> > A C generating backend, and then linker/runtime> > and similar IA64, AMD64 variants would be good.> > I'm not sure that a C generating backend would really help matters.> This was done in the first implementation of DEC, and they soon> abandoned it as C had proven to be a bad choice as intermediate language.> I agree it would be great for cross-compilation etc.> > As far as C and RT dependencies of native Windows compilers go, I don't> see why this couldn't be just a question of another cm3.cfg setup.> > > To a large extent, these can be few platforms, subject to > > configuration, like if all> > the linkers consume a common file format (not clear), and if all the > > jmpbufs are the same> > size (known to be partly true, partly false).> > Yes, jmpbuf is always a problem for user threads and exceptions.> On Unix systems the jmpbuf and other important low-level structures> are always defined by the system headers and independent of compilers> AFAIK, so I'm a bit surprised that it should be different on Windows.> But maybe I'm just wrong and haven't just seen the right counter> examples...> > > Oh and another thing, the runtime dependency is very likely cuttable, however> > PRESUMABLY real world applications (if there are any) link in a > > substantial amount of> > C or C++, in which case, it isn't necessarily cuttable.> > Yes. Real world applications tend to link other libraries (C, C++,> Fortran, ...) and even often call other applications like sh etc.> > > As well, if I can figure out a good way to do it, switching NT386 > > from awful slow> > frequent TlsGetValue/TlsSetValue to manipulating the linked list in > > fs:0, that would be nice,> > and might incur a C runtime dependency, but well worth it. The way > > Modula-3 works here> > is terrible. Another compromise option is probably > > __declspec(thread), though there is trickiness there> > in terms of being in a .dll that isn't used by the .exe.> > Such optimizations should be done depending on the target.> > Olaf> -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 hosking at cs.purdue.edu Sun Jan 20 18:02:32 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 20 Jan 2008 12:02:32 -0500 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <20080120110109.92CCC10D4628@birch.elegosoft.com> References: <20080120110109.92CCC10D4628@birch.elegosoft.com> Message-ID: Jay, I am particularly disturbed by these changes you just committed because of the nasty reliance they impose on C in this part of the run-time library. Part of the beauty of M3 is that its compiler and libraries are almost entirely programmed in Modula-3. Your change here has been made to satisfy a need to debug a severely broken run- time system. Better in such situations to use a standard debugger rather than pollute the Modula-3 code with nasty reliance on C. If you need to use such hacks in your debugging please do so in your privately checked out working directories rather than imposing them on the rest of us by checking into the main tree. If you need a debugging source tree in which to play then there is ample provision using CVS to fork a development branch that is off the main trunk. Shall I undo these hacks or will you? It is important in a collaborative effort such as this to make sure that we all play nicely in the shared CVS space. In this case I think you have regressed the code base by adding these C-based hacks. Best, -- Tony On Jan 20, 2008, at 12:01 PM, Jay Krell wrote: > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 08/01/20 12:01:09 > > Modified files: > cm3/m3-libs/m3core/src/runtime/common/: RTLinker.i3 RTLinker.m3 > m3makefile > Added files: > cm3/m3-libs/m3core/src/runtime/common/: RTLinkerC.c > > Log message: > allow RTLinker's tracing to work when things are more broken > the default behavior is unchanged, and the behavior with > @M3tracelinker > is preserved > a change in behavior requires modifying RTLinkerC.c and rebuilding > this also enables more verbose tracing From hosking at cs.purdue.edu Sun Jan 20 18:06:03 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 20 Jan 2008 12:06:03 -0500 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: References: <20080119031134.4B6A510D4625@birch.elegosoft.com> <20080120155649.tl5ghxhnl8o0g4cs@mail.elegosoft.com> Message-ID: On Jan 20, 2008, at 11:48 AM, Jay wrote: > > the infrastructure. So I'd rather vote that only new targets get > > more systematic names. > > Of course, though the existing names suggest new names, and > not clear the value of the existing NT386GNU. Ie. is there a benefit > to keep it in use with some meaning or not? Since others have made historic associations for the names we should probably keep their original meaning. I agree with Olaf here. From jayk123 at hotmail.com Sun Jan 20 18:13:52 2008 From: jayk123 at hotmail.com (Jay) Date: Sun, 20 Jan 2008 17:13:52 +0000 Subject: [M3devel] my status on win32 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> <477EA137.1E75.00D7.1@scires.com> <478D394B.1E75.00D7.1@scires.com> <478D47FB.1E75.00D7.1@scires.com> <478DBF8D.1E75.00D7.1@scires.com> <478DE973.1E75.00D7.1@scires.com> <47908659.1E75.00D7.1@scires.com> <20080119204810.3wmumqgms88sccw4@mail.elegosoft.com> <479267C2.1E75.00D7.1@scires.com> Message-ID: I'm not sure what you mean either Tony. :) But you got me thinking. Standalone vs. non standalone are mostly a transparent size optimization. But there is the state sharing vs. not. If there is some: static int i; int GetGlobal(void) { return i; } void SetGlobal(int j) { return i = j; } in a dll then there is just one i process wide. With a static .lib, each client .dll/.so/.exe would get its own i. However Modula-3 doesn't offer standalone .dlls so some of that is moot. The repro is so easy, I'm sure we'll get it before much longer, but I'd like to fix the GNU ModuleInfo first. - Jay > From: hosking at cs.purdue.edu> Date: Sun, 20 Jan 2008 11:26:28 -0500> To: rcoleburn at scires.com> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] my status on win32> > I'm not sure what I mean since I am a Windows ignoramus. Jay?> > On Jan 19, 2008, at 9:12 PM, Randy Coleburn wrote:> > > Hi Tony:> >> > Are you suggesting that when the program is built standalone it > > maps libraries differently? I know there is a difference between > > dynamic vs. static libraries, but are you suggesting that a > > different library is being mapped than the vendor's equivalent of > > the dynamic library? How would I check for this situation?> >> > Your suggestion seems plausible since the source is not recompiled; > > instead, the linker is used to change the way the EXE is put > > together and that seems to cause the difference in operation as far > > as pixmaps are concerned.> >> > Regards,> > Randy> >> > >>> Tony Hosking 1/19/2008 6:47 PM >>>> > I would perhaps suspect a bad library mapping.> >> > On Jan 19, 2008, at 2:48 PM, Olaf Wagner wrote:> >> > > Quoting Randy Coleburn :> > >> 1. pixmaps aren't rendered properly on the screen. They look > > really> > >> bad. I recall having this problem a while back with one of the > > early> > >> 5.x releases, so I guess it was never solved. I've got some old > > test> > >> programs I try to dig out and see if I can find out what is going> > >> on. I> > >> seem to recall that building standalone in the past seemed to > > fix the> > >> problem, so this is a real mystery.> > >> > > Hi Randy,> > >> > > I'm afraid I wasn't able to solve it directly some years ago and> > > then forgot about it due to more urgent tasks.> > >> > > I think we should try to narrow down the location of the problem> > > (i.e. is it in the runtime, code generation, linker, or windows> > > libraries).> > >> > > As you still have the 4.1 code of the Windows libraries, could you> > > first try to build them with the new compiler and see if it makes> > > a difference if you link against them?> > >> > > It may also be worthwhile to compare the commands actually used> > > for linking (use -commands). That is, before we turn to the actual> > > generated code...> > >> > > I still haven't got Windows access here, so I can just suggest what> > > to do...> > >> > > Olaf> > > --> > > Olaf Wagner -- elego Software Solutions GmbH> > > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin,> > > Germany> > > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 Sun Jan 20 18:24:10 2008 From: jayk123 at hotmail.com (Jay) Date: Sun, 20 Jan 2008 17:24:10 +0000 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: References: <20080120110109.92CCC10D4628@birch.elegosoft.com> Message-ID: You guys REALLY don't like C, eh? It's not a hack, any more so than the tracing that was there, and the existing tracing could be not turned on until "much" later in startup, and the debuggers have no type information, even gdb and I think m3gdb just seem to have void* everywhere, true, I could just dump the memory. Either way. I have a contrary view, in that if something is particularly gnarly such that someone had to write printing code, someone might need it in the future, maybe better to leave it available. However, on the other hand..I write this sort of printing all the time and leaving it all in would really blow up the size of the code base, even while most stuff usually works. In this case, printing code has been left there all along, an entire module dedicated to reduce-depending printing. Making it work much better, drastically cutting the dependency, seems reasonable. Actually RTIO should probably be rewritten in C instead of lumping the logging into RTLinker. It is a hack in that respect. I found it kind of disturbing how much RTIO reinvents, integer formating, buffering... (and yes I realize I have both such features under my code in stdio) Anyway, I'm not wedded to it. I wish it were easier to interface C with Modula-3. The type declarations I had to clone should be output by the Modula-3 compiler, and the names I chose should be either the default or easier to get, since they are the names used for Modula-3 code... (I'm not going to jump for a fork. My CVS skills stink. I'll just leave the files uncommited.) - Jay > From: hosking at cs.purdue.edu> Date: Sun, 20 Jan 2008 12:02:32 -0500> To: jkrell at elego.de> CC: m3devel at elegosoft.com; m3commit at elegosoft.com> Subject: Re: [M3devel] [M3commit] CVS Update: cm3> > Jay,> > I am particularly disturbed by these changes you just committed > because of the nasty reliance they impose on C in this part of the > run-time library. Part of the beauty of M3 is that its compiler and > libraries are almost entirely programmed in Modula-3. Your change > here has been made to satisfy a need to debug a severely broken run- > time system. Better in such situations to use a standard debugger > rather than pollute the Modula-3 code with nasty reliance on C. If > you need to use such hacks in your debugging please do so in your > privately checked out working directories rather than imposing them > on the rest of us by checking into the main tree. If you need a > debugging source tree in which to play then there is ample provision > using CVS to fork a development branch that is off the main trunk. > Shall I undo these hacks or will you?> > It is important in a collaborative effort such as this to make sure > that we all play nicely in the shared CVS space. In this case I > think you have regressed the code base by adding these C-based hacks.> > Best,> > -- Tony> > On Jan 20, 2008, at 12:01 PM, Jay Krell wrote:> > > CVSROOT: /usr/cvs> > Changes by: jkrell at birch. 08/01/20 12:01:09> >> > Modified files:> > cm3/m3-libs/m3core/src/runtime/common/: RTLinker.i3 RTLinker.m3> > m3makefile> > Added files:> > cm3/m3-libs/m3core/src/runtime/common/: RTLinkerC.c> >> > Log message:> > allow RTLinker's tracing to work when things are more broken> > the default behavior is unchanged, and the behavior with > > @M3tracelinker> > is preserved> > a change in behavior requires modifying RTLinkerC.c and rebuilding> > this also enables more verbose tracing> _________________________________________________________________ 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 Sun Jan 20 18:52:38 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 20 Jan 2008 12:52:38 -0500 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: References: <20080120110109.92CCC10D4628@birch.elegosoft.com> Message-ID: On Jan 20, 2008, at 12:24 PM, Jay wrote: > You guys REALLY don't like C, eh? > It's not a hack, any more so than the tracing that was there, and > the existing tracing could be not turned on until "much" later in > startup, and the debuggers have no type information, even gdb and I > think m3gdb just seem to have void* everywhere, true, I could just > dump the memory. The debuggers do have most type information on POSIX platforms. It's not that I don't like C, just that your use of it here was a little gratuitous. For this sort of low-level debugging memory dumps are your friend -- if you want to read something a little more symbolic put in a temporary hack in your private space. Just don't make the rest of us swallow it. Jay, I'm not trying to be hypercritical, just trying to preserve some cleanliness in the core library code. Please keep up your great work! Best regards, Tony > > > Either way. > > I have a contrary view, in that if something is particularly gnarly > such that someone had to write printing code, someone might need it > in the future, maybe better to leave it available. However, on the > other hand..I write this sort of printing all the time and leaving > it all in would really blow up the size of the code base, even > while most stuff usually works. > In this case, printing code has been left there all along, an > entire module dedicated to reduce-depending printing. Making it > work much better, drastically cutting the dependency, seems > reasonable. Actually RTIO should probably be rewritten in C instead > of lumping the logging into RTLinker. It is a hack in that respect. > I found it kind of disturbing how much RTIO reinvents, integer > formating, buffering... (and yes I realize I have both such > features under my code in stdio) > > Anyway, I'm not wedded to it. > I wish it were easier to interface C with Modula-3. The type > declarations I had to clone should be output by the Modula-3 > compiler, and the names I chose should be either the default or > easier to get, since they are the names used for Modula-3 code... > > (I'm not going to jump for a fork. My CVS skills stink. I'll just > leave the files uncommited.) > > - Jay > > > > > > From: hosking at cs.purdue.edu > > Date: Sun, 20 Jan 2008 12:02:32 -0500 > > To: jkrell at elego.de > > CC: m3devel at elegosoft.com; m3commit at elegosoft.com > > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > > > Jay, > > > > I am particularly disturbed by these changes you just committed > > because of the nasty reliance they impose on C in this part of the > > run-time library. Part of the beauty of M3 is that its compiler and > > libraries are almost entirely programmed in Modula-3. Your change > > here has been made to satisfy a need to debug a severely broken run- > > time system. Better in such situations to use a standard debugger > > rather than pollute the Modula-3 code with nasty reliance on C. If > > you need to use such hacks in your debugging please do so in your > > privately checked out working directories rather than imposing them > > on the rest of us by checking into the main tree. If you need a > > debugging source tree in which to play then there is ample provision > > using CVS to fork a development branch that is off the main trunk. > > Shall I undo these hacks or will you? > > > > It is important in a collaborative effort such as this to make sure > > that we all play nicely in the shared CVS space. In this case I > > think you have regressed the code base by adding these C-based > hacks. > > > > Best, > > > > -- Tony > > > > On Jan 20, 2008, at 12:01 PM, Jay Krell wrote: > > > > > CVSROOT: /usr/cvs > > > Changes by: jkrell at birch. 08/01/20 12:01:09 > > > > > > Modified files: > > > cm3/m3-libs/m3core/src/runtime/common/: RTLinker.i3 RTLinker.m3 > > > m3makefile > > > Added files: > > > cm3/m3-libs/m3core/src/runtime/common/: RTLinkerC.c > > > > > > Log message: > > > allow RTLinker's tracing to work when things are more broken > > > the default behavior is unchanged, and the behavior with > > > @M3tracelinker > > > is preserved > > > a change in behavior requires modifying RTLinkerC.c and rebuilding > > > this also enables more verbose tracing > > > > > Need to know the score, the latest news, or you need your Hotmail?- > get your "fix". Check it out. From jayk123 at hotmail.com Sun Jan 20 19:13:08 2008 From: jayk123 at hotmail.com (Jay) Date: Sun, 20 Jan 2008 18:13:08 +0000 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: References: <20080120110109.92CCC10D4628@birch.elegosoft.com> Message-ID: Hey I almost have this figured out. I compared RTHeapInfo.ms's MM_RTHeapInfo PPC_DARWIN vs. NT386GNU. They are almost the same. Ok, anyway, I decided, duh, let's disassembly the garbage data and see if it is code. It is. That roughly matches the PPC_DARWIN vs. NT386GNU diff where some numbers were off by 4. Therefore: The module info is this: 0:000> dc 0068113800681138 00681138 00000000 00603de0 00681144 when it should be: 0:000> dc 0068113800681138 xxxxx 00603de0 00681144 Two problems. One clear, one less clear. TYPE (* one of these is generated for each imported interface reference *) ImportInfo = RECORD import : ModulePtr; binder : Binder; (* returns "import" pointer *) next : ImportPtr; END; 4 bytes of padding are between import and binder. Making binder be used for next. Making a pointer to code vs. a pointer to data mixed up. That's a big problem. I understand. What I don't understand is the value of import. I walked the whole list of imports and in every case, the back pointer to the module was actually to the import itself. Huh? Perhaps I went wrong earlier and am off in the weeds..but I don't think so. I mean, the pointers are to self in any case and that's seldom correct data, unless they are empty circular singly linked lists.. I'll dig a bit more.. - Jay full debugging session...email is going to remove the newlines and make it unreadable probably.. Module 0x681020 ..\src\runtime\common\RTHeapInfo.m3 Imports 0x6810c0{Import 0x0, Binder 0x0, Next 0x603d60} (f88.aec): Access violation - code c0000005 (first chance) First chance exceptions are reported before any exception handling. This exception may be expected and handled. eax=8be58955 ebx=00000001 ecx=611030e8 edx=00008889 esi=611021a0 edi=006147e0 eip=006006a0 esp=0022cb70 ebp=0022cba8 iopl=0 nv up ei ng nz na pe nc cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00010286 *** ERROR: Module load completed but symbols could not be loaded for image00400000 image00400000+0x2006a0: 006006a0 8b00 mov eax,dword ptr [eax] ds:0023:8be58955=???????? 0:000> dc 0x681020 00681020 00680fe0 00681054 00681154 00000000 ..h.T.h.T.h..... 00681030 00000000 00680f98 00000000 00680fdc ......h.......h. 00681040 00680fdc 006810c0 00000000 0060053f ..h...h.....?.`. 00681050 00000003 00000000 6c810e28 72d376bc ........(..l.v.r 00681060 1e527894 01000201 00000000 00000000 .xR............. 00681070 00000000 00681004 00000000 00000000 ......h......... 00681080 0068100c 00000000 e545939d 00000000 ..h.......E..... 00681090 00000000 00000000 00000000 00681008 ..............h. 0:000> dc 006810c0 006810c0 00000000 00000000 00603d60 006810cc ........`=`...h. 006810d0 00000000 005fb070 006810d8 00000000 ....p._...h..... 006810e0 005fb4a0 006810e4 00000000 005f1c00 .._...h......._. 006810f0 006810f0 00000000 005f58d0 006810fc ..h......X_...h. 00681100 00000000 00606500 00681108 00000000 .....e`...h..... 00681110 006064f0 00681114 00000000 005f8790 .d`...h......._. 00681120 00681120 00000000 00605350 0068112c .h.....PS`.,.h. 00681130 00000000 00606520 00681138 00000000 .... e`.8.h..... oops, code not data, let's try the next one 0:000> dc 00603d60 00603d60 8be58955 d0b80845 c900681a 909090c3 U...E....h...... 00603d70 8be58955 90b80845 c900681b e58955c3 U...E....h...U.. 00603d80 ec835657 08458b20 8904c083 1bf8a1c2 WV.. .E......... 00603d90 f4050068 8b000000 dc7d8d00 b8fcc689 h.........}..... 00603da0 00000007 a5f3c189 758dd789 07b8fcdc ...........u.... 00603db0 89000000 83a5f3c1 5f5e20c4 9090c3c9 ......... ^_.... 00603dc0 8be58955 70b80845 c900681c 909090c3 U...E..p.h...... 00603dd0 8be58955 10b80845 c900681d 909090c3 U...E....h...... 0:000> dc 006810cc 006810cc 006810cc 00000000 005fb070 006810d8 ..h.....p._...h. 006810dc 00000000 005fb4a0 006810e4 00000000 ......_...h..... 006810ec 005f1c00 006810f0 00000000 005f58d0 .._...h......X_. 006810fc 006810fc 00000000 00606500 00681108 ..h......e`...h. 0068110c 00000000 006064f0 00681114 00000000 .....d`...h..... 0068111c 005f8790 00681120 00000000 00605350 .._. .h.....PS`. 0068112c 0068112c 00000000 00606520 00681138 ,.h..... e`.8.h. 0068113c 00000000 00603de0 00681144 00000000 .....=`.D.h..... 0:000> dc 006810d8 006810d8 006810d8 00000000 005fb4a0 006810e4 ..h......._...h. 006810e8 00000000 005f1c00 006810f0 00000000 ......_...h..... 006810f8 005f58d0 006810fc 00000000 00606500 .X_...h......e`. 00681108 00681108 00000000 006064f0 00681114 ..h......d`...h. 00681118 00000000 005f8790 00681120 00000000 ......_. .h..... 00681128 00605350 0068112c 00000000 00606520 PS`.,.h..... e`. 00681138 00681138 00000000 00603de0 00681144 8.h......=`.D.h. 00681148 00000000 005dfc00 00000000 00680f00 ......].......h. oops, this is code not data 0:000> dc 005fb4a0 005fb4a0 8be58955 80b80845 c90067af 909090c3 U...E....g......005fb4b0 8be58955 40b80845 c90067b1 909090c3 U...E.. at .g......005fb4c0 83e58955 45c738ec 000000dc 08458b00 U....8.E......E.005fb4d0 8b04c083 d8458900 83d8458b 1d7f0ff8 ......E..E......005fb4e0 8308458b e8500cec 00011e94 8910c483 .E....P.........005fb4f0 458be045 cc4589e0 0000f9e9 d8458b00 E..E..E.......E.005fb500 500cec83 0000f2e8 10c48300 8be04589 ...P.........E..005fb510 4589e045 d8458bdc 8e0fc085 000000d0 E..E..E......... let's try the next one 0:000> dc 006810e4 006810e4 006810e4 00000000 005f1c00 006810f0 ..h......._...h.006810f4 00000000 005f58d0 006810fc 00000000 .....X_...h.....00681104 00606500 00681108 00000000 006064f0 .e`...h......d`.00681114 00681114 00000000 005f8790 00681120 ..h......._. .h.00681124 00000000 00605350 0068112c 00000000 ....PS`.,.h.....00681134 00606520 00681138 00000000 00603de0 e`.8.h......=`.00681144 00681144 00000000 005dfc00 00000000 D.h.......].....00681154 00680f00 00000000 6c810e28 00000002 ..h.....(..l.... 0:000> dc 006810e4 006810e4 006810e4 00000000 005f1c00 006810f0 ..h......._...h.006810f4 00000000 005f58d0 006810fc 00000000 .....X_...h.....00681104 00606500 00681108 00000000 006064f0 .e`...h......d`.00681114 00681114 00000000 005f8790 00681120 ..h......._. .h.00681124 00000000 00605350 0068112c 00000000 ....PS`.,.h.....00681134 00606520 00681138 00000000 00603de0 e`.8.h......=`.00681144 00681144 00000000 005dfc00 00000000 D.h.......].....00681154 00680f00 00000000 6c810e28 00000002 ..h.....(..l.... show it to be code btw (I did this earlier, not sure what happened in the log;I cannot represent byte patterns as x86 code by sight, but the disassembly is spot on) 0:000> u 005f1c00 image00400000+0x1f1c00:005f1c00 55 push ebp005f1c01 89e5 mov ebp,esp005f1c03 8b4508 mov eax,dword ptr [ebp+8]005f1c06 b8a0906700 mov eax,offset image00400000+0x2790a0 (006790a0)005f1c0b c9 leave005f1c0c c3 ret005f1c0d 90 nop005f1c0e 90 nop ok, so again let's try the next 0:000> dc 006810f0 006810f0 006810f0 00000000 005f58d0 006810fc ..h......X_...h.00681100 00000000 00606500 00681108 00000000 .....e`...h.....00681110 006064f0 00681114 00000000 005f8790 .d`...h......._.00681120 00681120 00000000 00605350 0068112c .h.....PS`.,.h.00681130 00000000 00606520 00681138 00000000 .... e`.8.h.....00681140 00603de0 00681144 00000000 005dfc00 .=`.D.h.......].00681150 00000000 00680f00 00000000 6c810e28 ......h.....(..l00681160 00000002 00000000 00000000 00000000 ................ 0:000> dc 006810fc 006810fc 006810fc 00000000 00606500 00681108 ..h......e`...h.0068110c 00000000 006064f0 00681114 00000000 .....d`...h.....0068111c 005f8790 00681120 00000000 00605350 .._. .h.....PS`.0068112c 0068112c 00000000 00606520 00681138 ,.h..... e`.8.h.0068113c 00000000 00603de0 00681144 00000000 .....=`.D.h.....0068114c 005dfc00 00000000 00680f00 00000000 ..].......h.....0068115c 6c810e28 00000002 00000000 00000000 (..l............0068116c 00000000 79545452 52536570 33495f43 ....RTTypeSRC_I3 0:000> dc 00681108 00681108 00681108 00000000 006064f0 00681114 ..h......d`...h.00681118 00000000 005f8790 00681120 00000000 ......_. .h.....00681128 00605350 0068112c 00000000 00606520 PS`.,.h..... e`.00681138 00681138 00000000 00603de0 00681144 8.h......=`.D.h.00681148 00000000 005dfc00 00000000 00680f00 ......].......h.00681158 00000000 6c810e28 00000002 00000000 ....(..l........00681168 00000000 00000000 79545452 52536570 ........RTTypeSR00681178 33495f43 00000000 00600750 00681170 C_I3....P.`.p.h. it just keeps going, a pretty good linked listEXCEPT for the padding and the first pointer always looks wrong 0:000> dc 00681114 00681114 00681114 00000000 005f8790 00681120 ..h......._. .h.00681124 00000000 00605350 0068112c 00000000 ....PS`.,.h.....00681134 00606520 00681138 00000000 00603de0 e`.8.h......=`.00681144 00681144 00000000 005dfc00 00000000 D.h.......].....00681154 00680f00 00000000 6c810e28 00000002 ..h.....(..l....00681164 00000000 00000000 00000000 79545452 ............RTTy00681174 52536570 33495f43 00000000 00600750 peSRC_I3....P.`.00681184 00681170 00000000 735c2e2e 725c6372 p.h.......\src\r 0:000> dc 00681120 00681120 00681120 00000000 00605350 0068112c .h.....PS`.,.h.00681130 00000000 00606520 00681138 00000000 .... e`.8.h.....00681140 00603de0 00681144 00000000 005dfc00 .=`.D.h.......].00681150 00000000 00680f00 00000000 6c810e28 ......h.....(..l00681160 00000002 00000000 00000000 00000000 ................00681170 79545452 52536570 33495f43 00000000 RTTypeSRC_I3....00681180 00600750 00681170 00000000 735c2e2e P.`.p.h.......\s00681190 725c6372 69746e75 635c656d 6f6d6d6f rc\runtime\commo 0:000> dc 0068112c 0068112c 0068112c 00000000 00606520 00681138 ,.h..... e`.8.h.0068113c 00000000 00603de0 00681144 00000000 .....=`.D.h.....0068114c 005dfc00 00000000 00680f00 00000000 ..].......h.....0068115c 6c810e28 00000002 00000000 00000000 (..l............0068116c 00000000 79545452 52536570 33495f43 ....RTTypeSRC_I30068117c 00000000 00600750 00681170 00000000 ....P.`.p.h.....0068118c 735c2e2e 725c6372 69746e75 635c656d ..\src\runtime\c0068119c 6f6d6d6f 54525c6e 65707954 2e435253 ommon\RTTypeSRC. 0:000> dc 00681138 00681138 00681138 00000000 00603de0 00681144 8.h......=`.D.h.00681148 00000000 005dfc00 00000000 00680f00 ......].......h.00681158 00000000 6c810e28 00000002 00000000 ....(..l........00681168 00000000 00000000 79545452 52536570 ........RTTypeSR00681178 33495f43 00000000 00600750 00681170 C_I3....P.`.p.h.00681188 00000000 735c2e2e 725c6372 69746e75 ......\src\runti00681198 635c656d 6f6d6d6f 54525c6e 65707954 me\common\RTType006811a8 2e435253 00003369 0068118c 00000000 SRC.i3....h..... 0:000> dc 00681144 00681144 00681144 00000000 005dfc00 00000000 D.h.......]..... 00681154 00680f00 00000000 6c810e28 00000002 ..h.....(..l.... 00681164 00000000 00000000 00000000 79545452 ............RTTy 00681174 52536570 33495f43 00000000 00600750 peSRC_I3....P.`. 00681184 00681170 00000000 735c2e2e 725c6372 p.h.......\src\r 00681194 69746e75 635c656d 6f6d6d6f 54525c6e untime\common\RT 006811a4 65707954 2e435253 00003369 0068118c TypeSRC.i3....h. 006811b4 00000000 00000000 00000000 00000000 ................ another confirmation of a code pointer 0:000> u 005dfc00 image00400000+0x1dfc00: 005dfc00 55 push ebp 005dfc01 89e5 mov ebp,esp 005dfc03 8b4508 mov eax,dword ptr [ebp+8] 005dfc06 b800516700 mov eax,offset image00400000+0x275100 (00675100) 005dfc0b c9 leave 005dfc0c c3 ret 005dfc0d 90 nop 005dfc0e 90 nop 0:000> This is the nice thing about command line debuggers, a textual log. _________________________________________________________________ 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 rcoleburn at scires.com Sun Jan 20 20:10:46 2008 From: rcoleburn at scires.com (Randy Coleburn) Date: Sun, 20 Jan 2008 14:10:46 -0500 Subject: [M3devel] pixmap problem In-Reply-To: <200801200341.m0K3feKM023564@camembert.async.caltech.edu> References: Your message of "Sat, 19 Jan 2008 17:54:00 +0100." <235688.77597.qm@web27110.mail.ukl.yahoo.com> <200801200341.m0K3feKM023564@camembert.async.caltech.edu> Message-ID: <47935664.1E75.00D7.1@scires.com> Mika / Daniel: Thanks for the test info! Well, based on what ya'll are reporting, I think the problem has to do with the NT386 platform. I also don't think it has to do necessarily with the source code. So, there must be something fishy going on in the NT386 world in the linkage step to cause this type of situation when switching between regular and buildstandalone(). Unfortunately, I'm probably not the right person to figure out what is wrong and fix it either. Hey, but at least I produced a short test program that reproduces the problem. Maybe Jay or someone can offer another suggestion on how to fix it. I do know for sure that the TestPixmap program does build and run correctly on cm3 v4.1 for both buildstandalone() and regular. So, there must be something that has changed since then to cause this behavior. Maybe there is some different argument set that needs to get passed to the linker. I don't know. Regards, Randy >>> Mika Nystrom 1/19/2008 10:41 PM >>> It works great on NT386GNU, PM3/Klagenfurt, as well, without the build_standalone. Mika "Daniel Alejandro Benavides D." writes: >--0-1095273535-1200761640=:77597 >Content-Type: text/plain; charset=iso-8859-1 >Content-Transfer-Encoding: 8bit > >Hi: >The TestPixmap does show a nice battery on LINUXLIBC6, Ubuntu Gutsy 2.6.22-14-386, 32 bits machine. > >Thanks > > >Jay wrote: .hmmessage P { margin:0px; padding:0px } body.hmmessage { FONT-SIZE: 10pt; FONT-FAMILY:Tahoma } I can repro > the two different behaviors on XP. > I was going to try on PPC_DARWIN but I guess Tony's info suffices. > > I tried rolling hand.c back to before I changed (months/year ago), since it is involved in bit twiddling, no change, phew. > > Debugging here is a big humungous pain. > NT386 has good stacks and line numbers, but no locals or type info, I'd really sometime like to get Codeview info into those .objs...I think it > is documented well enough, but still not necessarily easy, or maybe have a C generating backend partly for this reason (and to bring up more ta >rgets, using native tools), and function calls in disassembly I think don't resolve; NT386GNU can't yet build this, though it will soon, but I'm > not familiar with gdb and there appears to be no type info. I'm building m3gdb right now, I don't know if it will work, I hope it has type info >, and I'm not familiar with the relevant code. In gdb I struggle just to view bytes in memory, add numbers to addresses and see those, etc. I th >ink for MY problem, I'm going to link in C code to dump the structs. There is tracing code and I enabled it, but even it crashes in Text_Length. > At least MY problem crashes, hopefully near the problem, whereas your problem goes all the way through to completion with > no stopping to hint where the problem is. Darn it. :) on the mock rudeness and :( on the lack of a crash. > > You write the bundle out and it matches, so that doesn't rule out bundles as being the problem? (darn) > And bundles look pretty simple, a bundle is just a generated source file with a constant in it. > Maybe newline problems? That wouldn't make sense. I just downloaded some program that might let me separately view the ppm, maybe it'll reveal >something. > > The bad behavior has like regularly spaced solid color veritical bars a few pixels side across the whole picture, and regularly spaced vertical > stripes from the correct picture alternating with that. Perhaps someone with ppm/bitmap/graphics experience has seen this behavior and it resul >ts from some common pixmap mismanagement we could look for? > > I have to say this is very surprising. > > I always wondered, and now I pretty much assume -- Modula-3 never imports/exports data in its dynamic linking, right? It alway imports/exports >functions, right? > On Windows, functions have an optional optimization, but data must be handled differently at compile time if it is going to be dynamically impo >rted. > For functions, if you don't apply the optimization at compile time, the linker will just generate a single instruction thunk instead. > > That is, given a symbol Foo, there is a symbol __imp__Foo that is a pointer to the actual foo in another .dll/.so. > The loader only patches pointers, one per import if you build your .dll correctly, it doesn't patch instructions or code strewn throughout a .d >ll, just one contiguous array of pointers. MAYBE they don't have to be contiguous for each .dl you import from. > > That is, if call msvcrt!fopen, msvcrt!fclose, kernel32!Sleep, my .dll/.exe typically has an array: > > pointer to msvcrt!fopen > pointer to msvcrt!fclose > null > pointer to kernel32!Sleep > > But perhaps kernel32.dll's pointers and msvcrt.dll's pointers need not be adjacent. > > So, going back, my point/question is that, if the compiler knows the function is imported, it can call through __imp__Foo instead of calling Fo >o. > But if it calls Foo and you import Foo, the linker will create the function Foo that just jmps through __imp__Foo. > That doesn't work for data though. There's no ability to intervenve like that. > So for imported data, the compiler must generated a read and dereference of the pointer __imp__Foo for accesses to Foo, if Foo is to be importe >d. > Data imports may be faster when appropriate, but for this reason, I'd say they aren't worth it. > And for this reason, I HOPE Modula-3 never imports/exports data. > > Oh, you could, for data, always reference the pointer __imp_Foo, and if non materializes, create one. > However that would suck perf in order to make an uncommon case work. > I hope Modula-3 doesn't do that either. :) > Though I guess since this global data in question...maybe it is rare??? > > Later, > - Jay > > > >--------------------------------- > > > From: hosking at cs.purdue.edu >> Date: Sat, 19 Jan 2008 03:09:47 -0500 >> To: rcoleburn at scires.com >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] pixmap problem >> >> Looks fine to me on I386_DARWIN. >> >> On Jan 19, 2008, at 12:31 AM, Randy Coleburn wrote: >> >> > >> > > > >--------------------------------- >Need to know the score, the latest news, or you need your Hotmail*-get your "fix" Check it out. > > >--------------------------------- > >Web Revelaci*n Yahoo! 2007: > Premio Favorita del P*blico - ?Vota tu preferida! >--0-1095273535-1200761640=:77597 >Content-Type: text/html; charset=iso-8859-1 >Content-Transfer-Encoding: 8bit > >Hi:
The TestPixmap does show a nice battery on LINUXLIBC6, Ubuntu Gutsy 2.6.22-14-386, 32 bits machine.

Thanks


Jay &l >t;jayk123 at hotmail.com> wrote:
I can repro the two > different behaviors on XP.
I was going to try on PPC_DARWIN but I guess Tony's info suffices.
 
I tried rolling hand.c back to > before I changed (months/year ago), since it is involved in bit twiddling, no change, phew.
 
Debugging here is a big humungous&nb >sp;pain.
NT386 has good stacks and line numbers, but no locals or type info, I'd really sometime like to get Codeview info into those .objs. >..I think it is documented well enough, but still not necessarily easy, or maybe have a C generating backend partly for this > reason (and to bring up more targets, using native tools), and function calls in disassembly I think don't resolve; NT386GNU can't yet bui >ld this, though it will soon, but I'm not familiar with gdb and there appears to be no type info. I'm building m3gdb right now, I don't know if >it will work, I hope it has type info, and I'm not familiar with the relevant code. In gdb I struggle just to view bytes in memory, add numbers >to addresses and see those, etc. I think for MY problem, I'm going to link in C code to dump the structs. There is tracing code and I enabled it >, but even it crashes in Text_Length. At least MY problem crashes, hopefully near the problem, whereas your problem goes all the way through to >completion with no stopping to hint where the problem is. Darn it. :) on the mock rudeness and :( on the lack of a crash.
 
You wri >te the bundle out and it matches, so that doesn't rule out bundles as being the problem? (darn)
And bundles look pretty > simple, a bundle is just a generated source file with a constant in it.
Maybe newline problems? That wouldn't make sense. I just downl >oaded some program that might let me separately view the ppm, maybe it'll reveal something.
 
The bad behavior has like regularly s >paced solid color veritical bars a few pixels side across the whole picture, and regularly spaced vertical stripes from the correct picture alte >rnating with that. Perhaps someone with ppm/bitmap/graphics experience has seen this behavior and it results from some common pixmap mismanageme >nt we could look for?
 
I have to say this is very surprising.
 
I always wondered, and now I pretty much assume -- Mo >dula-3 never imports/exports data in its dynamic linking, right? It alway imports/exports functions, right?
On Windows, functions have an op >tional optimization, but data must be handled differently at compile time if it is going to be dynamically imported.
For > functions, if you don't apply the optimization at compile time, the linker will just generate a single instruction thunk instead.
 
> That is, given a symbol Foo, there is a symbol __imp__Foo that is a pointer to the actual foo in another .dll/.so.
Th >e loader only patches pointers, one per import if you build your .dll correctly, it doesn't patch instructions or code strewn throughout a >.dll, just one contiguous array of pointers. MAYBE they don't have to be contiguous for each .dl you import from.
 
That is, if cal >l msvcrt!fopen, msvcrt!fclose, kernel32!Sleep, my .dll/.exe typically has an array:
 
pointer to msvcrt!fopen
pointer to msvcrt >!fclose
null
pointer to kernel32!Sleep
 
But perhaps kernel32.dll's pointers and msvcrt.dll's pointers need not be adjacent >.
 
So, going back, my point/question is that, if the compiler knows the function is imported, it can call > through __imp__Foo instead of calling Foo.
But if it calls Foo and you import Foo, the linker will create the function Foo that just jmps t >hrough __imp__Foo.
That doesn't work for data though. There's no ability to intervenve like that.
So for imported data, the compiler mus >t generated a read and dereference of the pointer __imp__Foo for accesses to Foo, if Foo is to be imported.
Data import >s may be faster when appropriate, but for this reason, I'd say they aren't worth it.
And for this reason, I HOPE Modula-3 never imports/expo >rts data.
 
Oh, you could, for data, always reference the pointer __imp_Foo, and if non materializes, create one.
However that >would suck perf in order to make an uncommon case work.
I hope Modula-3 doesn't do that either. :)
Though I guess since this global data > in question...maybe it is rare???
 
Later,
 - Jay



> From: > hosking at cs.purdue.edu
> Date: Sat, 19 Jan 2008 03:09:47 -0500
> To: rcoleburn at scires.com
> CC: m3devel at elegosoft.com
> >Subject: Re: [M3devel] pixmap problem
>
> Looks fine to me on I386_DARWIN.
>
> On Jan 19, 2008, at 12:31 AM, Randy Col >eburn wrote:
>
> > <TestPixmap.zip>
>


Need to know the score, the latest news, or you need your Hotm >ail*-get your "fix" Check it out.

> > >


Web Revelaci*n Yahoo! 2007:
Premio Favorita del P*blico - ?Vota tu preferida! >--0-1095273535-1200761640=:77597-- -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcoleburn at scires.com Sun Jan 20 20:12:45 2008 From: rcoleburn at scires.com (Randy Coleburn) Date: Sun, 20 Jan 2008 14:12:45 -0500 Subject: [M3devel] my status on win32 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> <477EA137.1E75.00D7.1@scires.com> <478D394B.1E75.00D7.1@scires.com> <478D47FB.1E75.00D7.1@scires.com> <478DBF8D.1E75.00D7.1@scires.com> <478DE973.1E75.00D7.1@scires.com> <47908659.1E75.00D7.1@scires.com> <20080119204810.3wmumqgms88sccw4@mail.elegosoft.com> <479267C2.1E75.00D7.1@scires.com><479267C2.1E75.00D7.1@scires.com> Message-ID: <479356DB.1E75.00D7.1@scires.com> "mapped" is probably a poor choice of words here. Sorry. --Randy >>> Jay 1/19/2008 11:27 PM >>> What does "mapped" mean here? The way it works, on Modula-3 NT386, and I haven't seen this done quite this way ever on Win32, not so systematically/mechanically/automatically, and I don't know how Posixish systems work here, but the way it works is that for every .dll, CM3 NT386 builds foo.lib and foo.lib.sa. foo.lib is an "import lib", just containing essentially function names and a file name. foo.lib.sa is a regular old static .lib, sa for standalone. You can also just build a static .lib -- for stuff that is never a .dll, for stuff that is only used once, but is broken up into multiple directories. For example m3quake, m3middle, m3objfile, m3back, etc. They are only used by cm3 so are just static .libs, just foo.lib, are built. (If we fix cm3.exe to be copy over itself, and I have some new clever ideas here, it might be profitable, for "developer productivity", to turn these into .dlls -- just so I can cd around and rebuild/reship less.) When you ask to build a standalone executable, we have a list of .libs, foo.lib, bar.lib. They are full paths. For each one, we see if foo.lib.sa exists, and if so, we use that instead of foo.lib. It is all rather simple and clever, but at least to me, it was surprising and new, so I explain it here. Perhaps Posixish systems work very similarly and this is old hat? I know cm3 doesn't implement this for Posix, but ar/ld/gcc could be handling things this way underneath for it. For example, I know on Mac OS X, if you link to a full path to a file, that's what you get. But if you say -Ldirectory -lfoo, ld probes for directory/foo.dylib and then directory/foo.a. So modulo the extensions and unknown to me how you build the things in the first place, same thing. You have to be sure to use the setting to split lib paths like that, otherwise you break dynamic linking. CM3 makes foo.sa.lib with its own mklib. This is also unusual. Normally one would use lib.exe or link.exe /lib for this, or ar/ld/gcc/dlltools. But the CM3 folks were obviously, openly en route to cutting dependencies through reimplementation. I had some initial trouble on NT385GNU building static .libs with ar/ld/gcc/dlltool, so, heck, I just do what NT386 does, and it seems to be working (modulo that SOMETHING is not working :) ). I don't want to stop anyone else from debugging this but if nobody else figures it out I will try. I can repro it easily, thanks for the good repro Randy! (though I wish it would crash instead of mis-display :) ) There is no "vendor's equivalent library" here, it is all just Modula-3 foo.lib or foo.lib.sa. Look at NT386/*.txt, by the .exe. Build one way. Rename away NT386. Build the other way. Compare the directories. You will see what I am talking about. - Jay Date: Sat, 19 Jan 2008 21:12:37 -0500 From: rcoleburn at scires.com To: hosking at cs.purdue.edu; wagner at elegosoft.com CC: m3devel at elegosoft.com Subject: Re: [M3devel] my status on win32 Hi Tony: Are you suggesting that when the program is built standalone it maps libraries differently? I know there is a difference between dynamic vs. static libraries, but are you suggesting that a different library is being mapped than the vendor's equivalent of the dynamic library? How would I check for this situation? Your suggestion seems plausible since the source is not recompiled; instead, the linker is used to change the way the EXE is put together and that seems to cause the difference in operation as far as pixmaps are concerned. Regards, Randy >>> Tony Hosking 1/19/2008 6:47 PM >>> I would perhaps suspect a bad library mapping. On Jan 19, 2008, at 2:48 PM, Olaf Wagner wrote: > Quoting Randy Coleburn : >> 1. pixmaps aren't rendered properly on the screen. They look really >> bad. I recall having this problem a while back with one of the early >> 5.x releases, so I guess it was never solved. I've got some old test >> programs I try to dig out and see if I can find out what is going >> on. I >> seem to recall that building standalone in the past seemed to fix the >> problem, so this is a real mystery. > > Hi Randy, > > I'm afraid I wasn't able to solve it directly some years ago and > then forgot about it due to more urgent tasks. > > I think we should try to narrow down the location of the problem > (i.e. is it in the runtime, code generation, linker, or windows > libraries). > > As you still have the 4.1 code of the Windows libraries, could you > first try to build them with the new compiler and see if it makes > a difference if you link against them? > > It may also be worthwhile to compare the commands actually used > for linking (use -commands). That is, before we turn to the actual > generated code... > > I still haven't got Windows access here, so I can just suggest what > to do... > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, > Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 > 45 86 95 > http://www.elegosoft.com ( http://www.elegosoft.com/ ) | Gesch?ftsf?hrer: Olaf Wagner | Sitz: > Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > DE163214194 > Helping your favorite cause is as easy as instant messaging. You IM, we give. Learn more. ( http://im.live.com/Messenger/IM/Home/?source=text_hotmail_join ) -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Sun Jan 20 20:48:31 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Sun, 20 Jan 2008 20:48:31 +0100 Subject: [M3devel] pixmap problem In-Reply-To: <47935664.1E75.00D7.1@scires.com> References: Your message of "Sat, 19 Jan 2008 17:54:00 +0100." <235688.77597.qm@web27110.mail.ukl.yahoo.com> <200801200341.m0K3feKM023564@camembert.async.caltech.edu> <47935664.1E75.00D7.1@scires.com> Message-ID: <20080120204831.81poj3gg0084o0g0@mail.elegosoft.com> Quoting Randy Coleburn : > Mika / Daniel: Thanks for the test info! > > Well, based on what ya'll are reporting, I think the problem has to do > with the NT386 platform. I also don't think it has to do necessarily > with the source code. So, there must be something fishy going on in the > NT386 world in the linkage step to cause this type of situation when > switching between regular and buildstandalone(). I must have missed that, browsing the lots of mails on this list recently ;-) > Unfortunately, I'm probably not the right person to figure out what is > wrong and fix it either. Hey, but at least I produced a short test > program that reproduces the problem. This is often the more difficult part. > Maybe Jay or someone can offer another suggestion on how to fix it. I think Jay is the well capable of finding out what's going wrong there. Let's wait for him. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Sun Jan 20 21:41:23 2008 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Sun, 20 Jan 2008 21:41:23 +0100 (CET) Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: Message-ID: <862972.55026.qm@web27105.mail.ukl.yahoo.com> Hi: I think for all the users that maybe NT386GNU is more thought like NT386cygwin, but if we see that GNU tools are used in projects like Mingw, that is a fork of cygwin and with the aim of programs running without the dependency on cygwin dll, that maybe guide us to say that the "old target" NT386GNU should be run with a cygwin enviroment. The NT386_MINGW seems to be a nice name/description for the platform which no depends on cygwin.dll but a MinGW/MSYS enviroment. Certainly I think the gnu toolchain is highly used by both the projects, and as I remember, when installing gcc on cygwin it also offers the mingw tool set to the cygwin enviroment to be installed. So let's say that projects are very related and cooperative, but are not the same. So Jay, m3cc could be built on a cygwin enviroment and m3gdb? If so, we can think in those two separeted platforms? although cooperative for m3 developers. I would like to see m3-lectern packages running on NT386GNU using the filesystem /dev, which is something that I wouldn't expect to be on the proposed NT386_MINGW platform. Thanks Jay wrote: .hmmessage P { margin:0px; padding:0px } body.hmmessage { FONT-SIZE: 10pt; FONT-FAMILY:Tahoma } > the infrastructure. So I'd rather vote that only new targets get > more systematic names. Of course, though the existing names suggest new names, and not clear the value of the existing NT386GNU. Ie. is there a benefit to keep it in use with some meaning or not? Cygwin does have a larger jmpbuf than msvcr*.dll/mingwin. I think it holds sigaction state besides register state. "NT" and "Win" seem redundant. I386_MINGWIN? I386_CYGWIN? NT386_GNU? NT386_MINGNU? Ok, I admit that NT386_CYGWIN NT386_MINGWIN despite the redundancy, clearly point to existing projects that probably have name recognition. And building from NT386 is reasonable -- as was I saying about existing names influencing new names. A C generating backend gets you perhaps easier retargeting as well. I do see there is "MINGWIN64" out there, for AMD64. Not sure what the state of IA64 is though... (See -- you should avoid saying "32" or "64" in stuff, Win32 => Win, Win64 => Win.) I also would agree that creating one target instead of two is probably a good idea -- seems easier. I am not sure if current state is relevant. I mean, is NT386GNU really working and in use anywhere? Is PM3 in use? If so, then matching their meaning would be good. Or even going beyond that -- to Trestle on X Windows. :) (Though CygwinX doesn't exactly appear active.) And thus the precedent for no underscore. NT386MINGWIN ? NT386MINGNU ? I don't know if "MSYS" needs a place in this name. It is needed for building m3cc. I wonder if a hybrid/adaptive approach will be desired -- if Cygwin is available, the MinGWin target could use it to build m3gdb, since it can't otherwise. Hint for anyone trying out Cygwin and getting an odd mix of paths: mkdir \cygdrive get junction.exe from the former www.sysinternals.com junction \cygdrive\c c:\ now when some Cygwin code passes /cygdrive/c to Win32 code, it will just work, no translation needed. If you have multiple drives, I guess just fully populate each one c:\cygdrive\c => c:\ c:\cygdrive\d => d:\ d:\cygdrive\c => c:\ d:\cygdrive\d => d:\ etc. but I haven't tried that. Or, to reduce the multiplication, set them all up on c: and have d:\cygdrive => c:\cygdrive, e:\cygdrive => c:\cygdrive, etc. - Jay --------------------------------- > Date: Sun, 20 Jan 2008 15:56:49 +0100 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > Quoting Jay : > > > Good, a happy customer. :) > > > >> GNU_MODE = 0 % Do not use GNU tools at all -- today's NT386 > >> GNU_MODE = 1 % Use GNU tools minimally -- today's NT386GNU > >> GNU_MODE = 2 % Use GNU tools maximally -- not existant but probably > >> easy > >> > >> Eh..I know, not great.. what do "minimally" and "maximally" mean. > > > > I'm still fishing for anyone to provide answers to these > > less important decisions that I have trouble with. > > Otherwise maybe no NT Cygwin system. > > > > TARGETs = { NT386, NT386GNU, NT386CYGWIN }? > > TARGETs = { NT386, NT386MINGWIN, NT386CYGWIN }? > > TARGETs = { NT386 + GNU_MODE }? > > > > The one reason I don't favor NT386 + GNU_MODE is that Cygwin has a > > much larger jmpbuf than the others. > > I think same TARGET implies code can be linked together, and I think > > varying jmpbuf implies otherwise. > > So NT386 and NT386MINGWIN should rarely cross paths with NT386CYGWIN. > > I think a new target is called for if I have understood everything right. > We need one pure native target (NT386), one pure-Cygwin-based target > (NT386_CYGWIN?) and one mix of runtime, gnu tools and mingwin > (NT386_MINGWIN?). > > As NT386GNU already exists, we must decide if we want to use it as > we traditionally did (all Cygwin) or the mixed implementation > (Mingwin and much Windows RT). > > > I also do NOT like this ad-hoc naming style. > > PPC_DARWIN, I386_DARWIN are much more to my style. > > The names should be somehow hierarchical, except, I realize, there > > isn't necessarily one "path" of > > stuff which to name platforms, though the GNU folks have settled on > > a way or two. > > They have triples or quadruples -- processor-hardware-os or such, > > however this doesn't > > clearly suffice. > > Well, yes, something more systematic would have been better, but > to break with the history will cause much trouble for all users and > the infrastructure. So I'd rather vote that only new targets get > more systematic names. > > > Something that accomodates: > > NT386 + LLVM > > NT386 + Watcom, linker and/or backend and/or runtime > > NT386 + Digital Mars linker and/or backend and/or runtime > > A C generating backend, and then linker/runtime > > and similar IA64, AMD64 variants would be good. > > I'm not sure that a C generating backend would really help matters. > This was done in the first implementation of DEC, and they soon > abandoned it as C had proven to be a bad choice as intermediate language. > I agree it would be great for cross-compilation etc. > > As far as C and RT dependencies of native Windows compilers go, I don't > see why this couldn't be just a question of another cm3.cfg setup. > > > To a large extent, these can be few platforms, subject to > > configuration, like if all > > the linkers consume a common file format (not clear), and if all the > > jmpbufs are the same > > size (known to be partly true, partly false). > > Yes, jmpbuf is always a problem for user threads and exceptions. > On Unix systems the jmpbuf and other important low-level structures > are always defined by the system headers and independent of compilers > AFAIK, so I'm a bit surprised that it should be different on Windows. > But maybe I'm just wrong and haven't just seen the right counter > examples... > > > Oh and another thing, the runtime dependency is very likely cuttable, however > > PRESUMABLY real world applications (if there are any) link in a > > substantial amount of > > C or C++, in which case, it isn't necessarily cuttable. > > Yes. Real world applications tend to link other libraries (C, C++, > Fortran, ...) and even often call other applications like sh etc. > > > As well, if I can figure out a good way to do it, switching NT386 > > from awful slow > > frequent TlsGetValue/TlsSetValue to manipulating the linked list in > > fs:0, that would be nice, > > and might incur a C runtime dependency, but well worth it. The way > > Modula-3 works here > > is terrible. Another compromise option is probably > > __declspec(thread), though there is trickiness there > > in terms of being in a .dll that isn't used by the .exe. > > Such optimizations should be done depending on the target. > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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! --------------------------------- Web Revelaci?n Yahoo! 2007: Premio Favorita del P?blico - ?Vota tu preferida! -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Sun Jan 20 22:03:12 2008 From: jayk123 at hotmail.com (Jay) Date: Sun, 20 Jan 2008 21:03:12 +0000 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <862972.55026.qm@web27105.mail.ukl.yahoo.com> References: <862972.55026.qm@web27105.mail.ukl.yahoo.com> Message-ID: Daniel, yes it's true cygwin has like -mno-cygwin or something. I will have to try that.Currently msys is required to build m3cc and cygwin is required to build m3gdb. m3gdb didn't have any type information anyway, so if you install cygwin, you can just use its gdb. (Note that cygwin is highly modular/package-based, so you can pick and chose what you install, there are many many many choices, so you don't automatically get gdb, you don't automatically even get gcc or ld/binutils.) Otherwise just MinGWin is required. Cygwin might just work. I'll try it before much longer. Is someone going to go ahead and create a new target? I guess I'm about able to. I think I finally fixed the major crash so can..take a break and then continue. Wow that was tedious. Once I can get a MinGWin distribution, I want to look at the pixmap bug, before looking into this new target.. Maybe someone will beat me to it though? /dev does not appear in Cygwin, at least not with cd and ls on my system. I expect /dev/null will work. I do have a very limited installed of Cygwin now, as I was trying to understand roughly what is needed. I don't know what to expect from /dev in Cygwin. You might be asking for too much. $ ls /dev/null/dev/null Jay at jay-win1 /$ ls /proc1312 cpuinfo meminfo registry stat version3936 loadavg partitions self uptime Jay at jay-win1 /$ ls /devls: cannot access /dev: No such file or directory $ ls /dev/tty/dev/tty $ ls /dev/conls: cannot access /dev/con: No such file or directory Jay at jay-win1 /$ ls /dev/fd0/dev/fd0 Jay at jay-win1 /$ ls /dev/fd*ls: cannot access /dev/fd*: No such file or directory Jay at jay-win1 /$ ls /dev/hd0ls: cannot access /dev/hd0: No such file or directory Jay at jay-win1 /$ ls /dev/sc*ls: cannot access /dev/sc*: No such file or directory I'm not sure what all to guess here. fd0 appears but I don't have a floppy disk. $ cat /proc/uptime41101.28 32423.71 Jay at jay-win1 /$ cat /proc/versionCYGWIN_NT-5.1 1.5.25(0.156/4/2) 2007-12-14 19:21 I'm inclined not to make any cygwin binary distributions until further reading of the license... There's still the X Windows vs. Win32 question... - Jay Date: Sun, 20 Jan 2008 21:41:23 +0100From: dabenavidesd at yahoo.esSubject: Re: [M3devel] [M3commit] CVS Update: cm3To: jayk123 at hotmail.com; wagner at elegosoft.com; m3devel at elegosoft.comHi:I think for all the users that maybe NT386GNU is more thought like NT386cygwin, but if we see that GNU tools are used in projects like Mingw, that is a fork of cygwin and with the aim of programs running without the dependency on cygwin dll, that maybe guide us to say that the "old target" NT386GNU should be run with a cygwin enviroment.The NT386_MINGW seems to be a nice name/description for the platform which no depends on cygwin.dll but a MinGW/MSYS enviroment.Certainly I think the gnu toolchain is highly used by both the projects, and as I remember, when installing gcc on cygwin it also offers the mingw tool set to the cygwin enviroment to be installed. So let's say that projects are very related and cooperative, but are not the same.So Jay, m3cc could be built on a cygwin enviroment and m3gdb?If so, we can think in those two separeted platforms? although cooperative for m3 developers.I would like to see m3-lectern packages running on NT386GNU using the filesystem /dev, which is something that I wouldn't expect to be on the proposed NT386_MINGW platform.ThanksJay wrote: > the infrastructure. So I'd rather vote that only new targets get> more systematic names.Of course, though the existing names suggest new names, andnot clear the value of the existing NT386GNU. Ie. is there a benefitto keep it in use with some meaning or not? Cygwin does have a larger jmpbuf than msvcr*.dll/mingwin.I think it holds sigaction state besides register state. "NT" and "Win" seem redundant. I386_MINGWIN? I386_CYGWIN? NT386_GNU? NT386_MINGNU? Ok, I admit that NT386_CYGWIN NT386_MINGWIN despite the redundancy, clearly point to existing projects that probably have name recognition.And building from NT386 is reasonable -- as was I saying about existing names influencing new names. A C generating backend gets you perhaps easier retargeting as well.I do see there is "MINGWIN64" out there, for AMD64.Not sure what the state of IA64 is though...(See -- you should avoid saying "32" or "64" in stuff, Win32 => Win, Win64 => Win.) I also would agree that creating one target instead of two is probably a good idea -- seems easier. I am not sure if current state is relevant. I mean, is NT386GNU really working and in use anywhere? Is PM3 in use?If so, then matching their meaning would be good. Or even going beyond that -- to Trestle on X Windows. :) (Though CygwinX doesn't exactly appear active.) And thus the precedent for no underscore.NT386MINGWIN ?NT386MINGNU ? I don't know if "MSYS" needs a place in this name.It is needed for building m3cc. I wonder if a hybrid/adaptive approach will be desired -- if Cygwin is available, the MinGWin target could use it to build m3gdb, since it can't otherwise. Hint for anyone trying out Cygwin and getting an odd mix of paths:mkdir \cygdriveget junction.exe from the former www.sysinternals.comjunction \cygdrive\c c:\now when some Cygwin code passes /cygdrive/c to Win32 code, it will just work, no translation needed.If you have multiple drives, I guess just fully populate each onec:\cygdrive\c => c:\c:\cygdrive\d => d:\d:\cygdrive\c => c:\d:\cygdrive\d => d:\ etc. but I haven't tried that.Or, to reduce the multiplication, set them all up on c: and have d:\cygdrive => c:\cygdrive, e:\cygdrive => c:\cygdrive, etc. - Jay > Date: Sun, 20 Jan 2008 15:56:49 +0100> From: wagner at elegosoft.com> To: m3devel at elegosoft.com> Subject: Re: [M3devel] [M3commit] CVS Update: cm3> > Quoting Jay :> > > Good, a happy customer. :)> >> >> GNU_MODE = 0 % Do not use GNU tools at all -- today's NT386> >> GNU_MODE = 1 % Use GNU tools minimally -- today's NT386GNU> >> GNU_MODE = 2 % Use GNU tools maximally -- not existant but probably> >> easy> >>> >> Eh..I know, not great.. what do "minimally" and "maximally" mean.> >> > I'm still fishing for anyone to provide answers to these> > less important decisions that I have trouble with.> > Otherwise maybe no NT Cygwin system.> >> > TARGETs = { NT386, NT386GNU, NT386CYGWIN }?> > TARGETs = { NT386, NT386MINGWIN, NT386CYGWIN }?> > TARGETs = { NT386 + GNU_MODE }?> >> > The one reason I don't favor NT386 + GNU_MODE is that Cygwin has a > > much larger jmpbuf than the others.> > I think same TARGET implies code can be linked together, and I think > > varying jmpbuf implies otherwise.> > So NT386 and NT386MINGWIN should rarely cross paths with NT386CYGWIN.> > I think a new target is called for if I have understood everything right.> We need one pure native target (NT386), one pure-Cygwin-based target> (NT386_CYGWIN?) and one mix of runtime, gnu tools and mingwin> (NT386_MINGWIN?).> > As NT386GNU already exists, we must decide if we want to use it as> we traditionally did (all Cygwin) or the mixed implementation> (Mingwin and much Windows RT).> > > I also do NOT like this ad-hoc naming style.> > PPC_DARWIN, I386_DARWIN are much more to my style.> > The names should be somehow hierarchical, except, I realize, there > > isn't necessarily one "path" of> > stuff which to name platforms, though the GNU folks have settled on > > a way or two.> > They have triples or quadruples -- processor-hardware-os or such, > > however this doesn't> > clearly suffice.> > Well, yes, something more systematic would have been better, but> to break with the history will cause much trouble for all users and> the infrastructure. So I'd rather vote that only new targets get> more systematic names.> > > Something that accomodates:> > NT386 + LLVM> > NT386 + Watcom, linker and/or backend and/or runtime> > NT386 + Digital Mars linker and/or backend and/or runtime> > A C generating backend, and then linker/runtime> > and similar IA64, AMD64 variants would be good.> > I'm not sure that a C generating backend would really help matters.> This was done in the first implementation of DEC, and they soon> abandoned it as C had proven to be a bad choice as intermediate language.> I agree it would be great for cross-compilation etc.> > As far as C and RT dependencies of native Windows compilers go, I don't> see why this couldn't be just a question of another cm3.cfg setup.> > > To a large extent, these can be few platforms, subject to > > configuration, like if all> > the linkers consume a common file format (not clear), and if all the > > jmpbufs are the same> > size (known to be partly true, partly false).> > Yes, jmpbuf is always a problem for user threads and exceptions.> On Unix systems the jmpbuf and other important low-level structures> are always defined by the system headers and independent of compilers> AFAIK, so I'm a bit surprised that it should be different on Windows.> But maybe I'm just wrong and haven't just seen the right counter> examples...> > > Oh and another thing, the runtime dependency is very likely cuttable, however> > PRESUMABLY real world applications (if there are any) link in a > > substantial amount of> > C or C++, in which case, it isn't necessarily cuttable.> > Yes. Real world applications tend to link other libraries (C, C++,> Fortran, ...) and even often call other applications like sh etc.> > > As well, if I can figure out a good way to do it, switching NT386 > > from awful slow> > frequent TlsGetValue/TlsSetValue to manipulating the linked list in > > fs:0, that would be nice,> > and might incur a C runtime dependency, but well worth it. The way > > Modula-3 works here> > is terrible. Another compromise option is probably > > __declspec(thread), though there is trickiness there> > in terms of being in a .dll that isn't used by the .exe.> > Such optimizations should be done depending on the target.> > Olaf> -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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! Web Revelaci?n Yahoo! 2007:Premio Favorita del P?blico - ?Vota tu preferida! _________________________________________________________________ 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 Jan 20 22:09:42 2008 From: jayk123 at hotmail.com (Jay) Date: Sun, 20 Jan 2008 21:09:42 +0000 Subject: [M3devel] cygwin users? In-Reply-To: <862972.55026.qm@web27105.mail.ukl.yahoo.com> References: <862972.55026.qm@web27105.mail.ukl.yahoo.com> Message-ID: Does anyone who is asking for Cygwin support actually use it? Or you are all just Unix users? (And MinGW users either?) I mean, are we hearing what people want and will use, or just what ought to exist in some ideal world? - 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 wagner at elegosoft.com Sun Jan 20 22:18:32 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Sun, 20 Jan 2008 22:18:32 +0100 Subject: [M3devel] Open CM3 regression tests Message-ID: <20080120211832.GA26993@elegosoft.com> Hi again everybody, I got a little bit side-tracked during recent days while trying to set up a sensible interface for test status reporting by the poor state of the CM3 WWW presentation. So I tried to improve the presentation and structure of the site. It's still all simple hand-crafted HTML and nothing very fancy, though I think it looks better now than before. Let me know what you think. And I know, the colours will be the most interesting discussion topic ;-) But back to more important issues. There are still a number of problems in the CM3 compiler regression tests that I'd like to discuss and close: either adapt the test, fix the compiler, or document the issue as intended or erroneous behaviour of CM3. Though I've thrown in some names here and there, nobody should hesitate to voice his opinion. Here's the extract of the test run log: CM3_TARGET=FreeBSD4 BINDISTMIN=/home/wagner/cm3-min-POSIX-FreeBSD4-5.4.0.tgz === 2008-01-19 23:43:24 run cm3 compiler and runtime regression test suite in /home/wagner/work/cm3-ws/luthien-2008-01-19-02-30-01 with lastok version Critical Mass Modula-3 version d5.5.1 last updated: 2007-12-30 compiled: 2008-01-19 17:27:13 configuration: /home/wagner/work/cm3-inst/luthien/current/bin/cm3.cfg --- building in FreeBSD4 --- > no errors for p1 to p115 --- p116b --- default IEEE floating point tests from Xerox PARC --- p1/p116b/stderr.pgm 2008-01-20 00:47:20.000000000 +0100 +++ ../src/p1/p116b/stderr.pgm 2008-01-13 00:55:55.000000000 +0100 @@ -17,7 +17,7 @@ Class (MaxFinite*ten) test OK Finite (MaxFinite*ten) test OK IsNaN (MaxFinite*ten) test OK -** Class (zero/zero) test not OK: FALSE should be TRUE + Class (zero/zero) test OK Finite (zero/zero) test OK IsNaN (zero/zero) test OK Sign (zero) test OK @@ -58,7 +58,7 @@ Class MaxFinite*ten test OK Finite MaxFinite*ten test OK IsNaN MaxFinite*ten test OK -** Class zero/zero test not OK: FALSE should be TRUE + Class zero/zero test OK Finite zero/zero test OK IsNaN zero/zero test OK Sign (zero) test OK > Some arithmetic problems. Perhaps Henning Thielemann could have > a look at this? --- p117 --- SUBARRAY (LOOPHOLE) OK again --- p155 --- operations on small sets --- p1/p155/stderr.pgm 2008-01-20 00:48:16.000000000 +0100 +++ ../src/p1/p155/stderr.pgm 2008-01-13 00:55:56.000000000 +0100 @@ -2,7 +2,6 @@ check set q = {} check set r = {a, b} check set x = {a, b, e} -************************ ERROR: check (NOT (p >= x)) failed > This concerns the >= operation on sets. The language definition > says: > > infix <=, >= (x,y: Ordinal) : BOOLEAN > (x,y: Float) : BOOLEAN > (x,y: ADDRESS) : BOOLEAN > (x,y: Set) : BOOLEAN > > In the first three cases, <= returns TRUE if x is at most as large as > y. In the last case, <= returns TRUE if every element of x is an > element of y. In all cases, it is a static error if the type of x is > not assignable to the type of y, or vice versa. The expression x >= y > is equivalent to y <= x. > > So the implementation seems to be plainly wrong. I think the test > for the previous operation <= only succeeds accidentally. --- p156 --- operations on medium-sized sets > OK > until --- p172 --- REAL vs. C's float --- p1/p172/stdout.pgm 2008-01-20 00:49:10.000000000 +0100 +++ ../src/p1/p172/stdout.pgm 2003-03-08 23:36:48.000000000 +0100 @@ -0,0 +1 @@ +23 23 --- p1/p172/stderr.pgm 2008-01-20 00:49:10.000000000 +0100 +++ ../src/p1/p172/stderr.pgm 2003-03-08 23:36:48.000000000 +0100 @@ -1,5 +1,3 @@ -23.4 23 -************************ ERROR: 23.4 instead of 23 > result too exact? > Perhaps Henning again? And Tony? --- p173 --- LONGREAL vs. C's double > OK again until --- p185 --- REAL vs. C float --- p1/p185/stderr.pgm 2008-01-20 00:49:32.000000000 +0100 +++ ../src/p1/p185/stderr.pgm 2003-03-08 23:36:50.000000000 +0100 @@ -1,4 +1,3 @@ -************************ ERROR: 53 instead of 24 > This is another effect of the precision problem. Expression evaluation > seems always to be done with 53 bits of precision (double), and never > with pure reals (23 bits). I assume it will be the same for C on > all PC hardware at least. Should we consider this to be an error or > just document the behaviour? > > I assume it cannot easily be changed, can it? --- p186 --- case statement with large labels > Just some output differences; I seem to have switched core dumps > off in one environment... > > So we can probably ignore these ones. --- r0/r001/stdout.build 2008-01-20 00:50:07.000000000 +0100 +++ ../src/r0/r001/stdout.build 2008-01-13 00:55:57.000000000 +0100 @@ -1,3 +1,3 @@ "../src/Main.m3", line 13: warning: potentially unhandled exception: Main.a 1 warning encountered -Abort trap (core dumped) +Abort trap --- r002 --- stack overflow in the main thread --- r0/r002/stdout.build 2008-01-20 00:50:09.000000000 +0100 +++ ../src/r0/r002/stdout.build 2008-01-13 00:55:57.000000000 +0100 @@ -1 +1 @@ -Bus error (core dumped) +Bus error --- r003 --- b3tests/b002 - improper size for an open array parameter --- r0/r003/stdout.build 2008-01-20 00:50:11.000000000 +0100 +++ ../src/r0/r003/stdout.build 2008-01-13 00:55:57.000000000 +0100 @@ -1,4 +1,4 @@ "../src/Main.m3", line 11: warning: open array passed by value (x) "../src/Main.m3", line 13: warning: large parameter passed by value (40 bytes) (x) 2 warnings encountered -Abort trap (core dumped) +Abort trap --- r004 --- negative size for an open array --- r0/r004/stdout.build 2008-01-20 00:50:13.000000000 +0100 +++ ../src/r0/r004/stdout.build 2008-01-13 00:55:57.000000000 +0100 @@ -1 +1 @@ -Abort trap (core dumped) +Abort trap > That were all the functional tests. Following is only error detection > and handling: > > There seems to be a problem recognizing some recursive declarations: --- e0/e020/stdout.build 2008-01-20 00:50:32.000000000 +0100 +++ ../src/e0/e020/stdout.build 2008-01-09 02:15:42.000000000 +0100 @@ -1 +1 @@ -Bus error (core dumped) +Fatal Error: package build failed --- e021 --- illegal recursive declaration > OK until --- e026 --- two types with the same brand --- e0/e026/stdout.build 2008-01-20 00:50:38.000000000 +0100 +++ ../src/e0/e026/stdout.build 2003-03-08 23:36:13.000000000 +0100 @@ -0,0 +1,3 @@ +"../src/Main.m3", line 8: string: duplicate brand +"../src/Main.m3", line 7: string: duplicate brand +2 errors encountered > This seems to be just different/missing error output. > > Another more obvious example of this is here: --- e029 --- use type instead of value as an initializer --- e0/e029/stdout.build 2008-01-20 00:50:41.000000000 +0100 +++ ../src/e0/e029/stdout.build 2008-01-09 02:15:44.000000000 +0100 @@ -1,11 +1,4 @@ "../src/Main.m3", line 24: warning: variable has type NULL (r) -"../src/Main.m3", line 24: ** INTERNAL CG ERROR *** stack not empty, depth (1) -"../src/Main.m3", line 25: ** INTERNAL CG ERROR *** stack not empty, depth (1) -"../src/Main.m3", line 26: ** INTERNAL CG ERROR *** unaligned load_indirect type=11 s/a=0/8 -"../src/Main.m3", line 26: ** INTERNAL CG ERROR *** unaligned store_indirect type=11 s/a=0/8 -"../src/Main.m3", line 26: ** INTERNAL CG ERROR *** stack not empty, depth (1) -"../src/Main.m3", line 26: ** INTERNAL CG ERROR *** stack not empty, depth (1) -"../src/Main.m3", line 22: ** INTERNAL CG ERROR *** stack not empty, depth (1) -"../src/Main.m3", line 22: 2 code generation errors -8 errors and 1 warning encountered +"../src/Main.m3", line 24: types are not assignable +1 error and 1 warning encountered Fatal Error: package build failed > Just ignore it? > > For reference, here's the extract of the programs' stderr output: >>> test_m3tests error extract: FreeBSD4/p1/p116b/stderr.pgm:** Class (zero/zero) test not OK: FALSE should be TRUE FreeBSD4/p1/p116b/stderr.pgm:** Class zero/zero test not OK: FALSE should be TRUE FreeBSD4/p1/p155/stderr.pgm:************************ ERROR: check (NOT (p >= x)) failed FreeBSD4/p1/p155/stderr.pgm:1 error(s) and 0 warning(s) detected FreeBSD4/p1/p172/stderr.pgm:************************ ERROR: 23.4 instead of 23 FreeBSD4/p1/p172/stderr.pgm:1 error(s) and 0 warning(s) detected FreeBSD4/p1/p185/stderr.pgm:************************ ERROR: 53 instead of 24 FreeBSD4/p1/p185/stderr.pgm:1 error(s) and 0 warning(s) detected FreeBSD4/r0/r001/stderr.pgm:*** FreeBSD4/r0/r001/stderr.pgm:*** runtime error: FreeBSD4/r0/r001/stderr.pgm:*** Unhandled exception: Main.a FreeBSD4/r0/r001/stderr.pgm:*** file "../src/Main.m3", line 13 FreeBSD4/r0/r001/stderr.pgm:*** FreeBSD4/r0/r003/stderr.pgm:*** FreeBSD4/r0/r003/stderr.pgm:*** runtime error: FreeBSD4/r0/r003/stderr.pgm:*** An open array had the wrong shape. FreeBSD4/r0/r003/stderr.pgm:*** file "../src/Main.m3", line 19 FreeBSD4/r0/r003/stderr.pgm:*** FreeBSD4/r0/r004/stderr.pgm:*** FreeBSD4/r0/r004/stderr.pgm:*** runtime error: FreeBSD4/r0/r004/stderr.pgm:*** An enumeration or subrange value was out of range. FreeBSD4/r0/r004/stderr.pgm:*** file "../src/runtime/common/RTAllocator.m3", line 309 FreeBSD4/r0/r004/stderr.pgm:*** >>> 7 in test_m3tests 2008-01-19-02-30-01 /home/wagner/work/cm3-ws/luthien-2008-01-19-02-30-01 === 2008-01-19 23:50:47 cm3 m3tests run done Thanks in advance for your comments, Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From hosking at cs.purdue.edu Sun Jan 20 22:30:11 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 20 Jan 2008 16:30:11 -0500 Subject: [M3devel] cygwin users? In-Reply-To: References: <862972.55026.qm@web27105.mail.ukl.yahoo.com> Message-ID: <8FB801EB-62E4-4DC6-905A-320E4366E011@cs.purdue.edu> On Jan 20, 2008, at 4:09 PM, Jay wrote: > Does anyone who is asking for Cygwin support actually use it? Or > you are all just Unix users? > (And MinGW users either?) I am principally a Unix user, but I am comfortable with Windows when using Cygwin. Thus, I would probably be more comfortable with running CM3 under Cygwin than running under some other Windows configuration. i.e., installing via .sh under Cygwin (same as I do on Unix targets) makes for a more uniform experience for me. > I mean, are we hearing what people want and will use, or just what > ought to exist in some ideal world? > > - Jay > > Climb to the top of the charts! Play the word scramble challenge > with star power. Play now! From hosking at cs.purdue.edu Sun Jan 20 22:38:16 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 20 Jan 2008 16:38:16 -0500 Subject: [M3devel] Open CM3 regression tests In-Reply-To: <20080120211832.GA26993@elegosoft.com> References: <20080120211832.GA26993@elegosoft.com> Message-ID: <9C00EA97-9B43-43BE-9CDF-EEAC9C1321D5@cs.purdue.edu> The set operations are all coded as external C functions -- should be easy enough to fix those. Or are there type issues too? On Jan 20, 2008, at 4:18 PM, Olaf Wagner wrote: > Hi again everybody, > > I got a little bit side-tracked during recent days while trying > to set up a sensible interface for test status reporting > by the poor state of the CM3 WWW presentation. So I tried to improve > the presentation and structure of the site. It's still all simple > hand-crafted HTML and nothing very fancy, though I think it looks > better now than before. Let me know what you think. And I know, > the colours will be the most interesting discussion topic ;-) > > But back to more important issues. There are still a number of > problems in the CM3 compiler regression tests that I'd like to > discuss and close: either adapt the test, fix the compiler, or > document the issue as intended or erroneous behaviour of CM3. > Though I've thrown in some names here and there, nobody should > hesitate to voice his opinion. Here's the extract of the test run > log: > > CM3_TARGET=FreeBSD4 > BINDISTMIN=/home/wagner/cm3-min-POSIX-FreeBSD4-5.4.0.tgz > === 2008-01-19 23:43:24 run cm3 compiler and runtime regression > test suite in /home/wagner/work/cm3-ws/luthien-2008-01-19-02-30-01 > with lastok version > Critical Mass Modula-3 version d5.5.1 > last updated: 2007-12-30 > compiled: 2008-01-19 17:27:13 > configuration: /home/wagner/work/cm3-inst/luthien/current/bin/ > cm3.cfg > > --- building in FreeBSD4 --- > >> no errors for p1 to p115 > > --- p116b --- default IEEE floating point tests from Xerox PARC > --- p1/p116b/stderr.pgm 2008-01-20 00:47:20.000000000 +0100 > +++ ../src/p1/p116b/stderr.pgm 2008-01-13 00:55:55.000000000 +0100 > @@ -17,7 +17,7 @@ > Class (MaxFinite*ten) test OK > Finite (MaxFinite*ten) test OK > IsNaN (MaxFinite*ten) test OK > -** Class (zero/zero) test not OK: FALSE should be TRUE > + Class (zero/zero) test OK > Finite (zero/zero) test OK > IsNaN (zero/zero) test OK > Sign (zero) test OK > @@ -58,7 +58,7 @@ > Class MaxFinite*ten test OK > Finite MaxFinite*ten test OK > IsNaN MaxFinite*ten test OK > -** Class zero/zero test not OK: FALSE should be TRUE > + Class zero/zero test OK > Finite zero/zero test OK > IsNaN zero/zero test OK > Sign (zero) test OK > >> Some arithmetic problems. Perhaps Henning Thielemann could have >> a look at this? > > --- p117 --- SUBARRAY (LOOPHOLE) > OK again > --- p155 --- operations on small sets > --- p1/p155/stderr.pgm 2008-01-20 00:48:16.000000000 +0100 > +++ ../src/p1/p155/stderr.pgm 2008-01-13 00:55:56.000000000 +0100 > @@ -2,7 +2,6 @@ > check set q = {} > check set r = {a, b} > check set x = {a, b, e} > -************************ ERROR: check (NOT (p >= x)) failed > >> This concerns the >= operation on sets. The language definition >> says: >> >> infix <=, >= (x,y: Ordinal) : BOOLEAN >> (x,y: Float) : BOOLEAN >> (x,y: ADDRESS) : BOOLEAN >> (x,y: Set) : BOOLEAN >> >> In the first three cases, <= returns TRUE if x is at most as large as >> y. In the last case, <= returns TRUE if every element of x is an >> element of y. In all cases, it is a static error if the type of x is >> not assignable to the type of y, or vice versa. The expression x >= y >> is equivalent to y <= x. >> >> So the implementation seems to be plainly wrong. I think the test >> for the previous operation <= only succeeds accidentally. > > > --- p156 --- operations on medium-sized sets >> OK >> until > > --- p172 --- REAL vs. C's float > --- p1/p172/stdout.pgm 2008-01-20 00:49:10.000000000 +0100 > +++ ../src/p1/p172/stdout.pgm 2003-03-08 23:36:48.000000000 +0100 > @@ -0,0 +1 @@ > +23 23 > --- p1/p172/stderr.pgm 2008-01-20 00:49:10.000000000 +0100 > +++ ../src/p1/p172/stderr.pgm 2003-03-08 23:36:48.000000000 +0100 > @@ -1,5 +1,3 @@ > -23.4 23 > -************************ ERROR: 23.4 instead of 23 >> result too exact? >> Perhaps Henning again? And Tony? > > --- p173 --- LONGREAL vs. C's double >> OK again until > > --- p185 --- REAL vs. C float > --- p1/p185/stderr.pgm 2008-01-20 00:49:32.000000000 +0100 > +++ ../src/p1/p185/stderr.pgm 2003-03-08 23:36:50.000000000 +0100 > @@ -1,4 +1,3 @@ > -************************ ERROR: 53 instead of 24 > >> This is another effect of the precision problem. Expression >> evaluation >> seems always to be done with 53 bits of precision (double), and never >> with pure reals (23 bits). I assume it will be the same for C on >> all PC hardware at least. Should we consider this to be an error or >> just document the behaviour? >> >> I assume it cannot easily be changed, can it? > > --- p186 --- case statement with large labels >> Just some output differences; I seem to have switched core dumps >> off in one environment... >> >> So we can probably ignore these ones. > > --- r0/r001/stdout.build 2008-01-20 00:50:07.000000000 +0100 > +++ ../src/r0/r001/stdout.build 2008-01-13 00:55:57.000000000 +0100 > @@ -1,3 +1,3 @@ > "../src/Main.m3", line 13: warning: potentially unhandled > exception: Main.a > 1 warning encountered > -Abort trap (core dumped) > +Abort trap > --- r002 --- stack overflow in the main thread > --- r0/r002/stdout.build 2008-01-20 00:50:09.000000000 +0100 > +++ ../src/r0/r002/stdout.build 2008-01-13 00:55:57.000000000 +0100 > @@ -1 +1 @@ > -Bus error (core dumped) > +Bus error > --- r003 --- b3tests/b002 - improper size for an open array parameter > --- r0/r003/stdout.build 2008-01-20 00:50:11.000000000 +0100 > +++ ../src/r0/r003/stdout.build 2008-01-13 00:55:57.000000000 +0100 > @@ -1,4 +1,4 @@ > "../src/Main.m3", line 11: warning: open array passed by value (x) > "../src/Main.m3", line 13: warning: large parameter passed by > value (40 bytes) (x) > 2 warnings encountered > -Abort trap (core dumped) > +Abort trap > --- r004 --- negative size for an open array > --- r0/r004/stdout.build 2008-01-20 00:50:13.000000000 +0100 > +++ ../src/r0/r004/stdout.build 2008-01-13 00:55:57.000000000 +0100 > @@ -1 +1 @@ > -Abort trap (core dumped) > +Abort trap > >> That were all the functional tests. Following is only error detection >> and handling: >> >> There seems to be a problem recognizing some recursive declarations: > > --- e0/e020/stdout.build 2008-01-20 00:50:32.000000000 +0100 > +++ ../src/e0/e020/stdout.build 2008-01-09 02:15:42.000000000 +0100 > @@ -1 +1 @@ > -Bus error (core dumped) > +Fatal Error: package build failed > > --- e021 --- illegal recursive declaration >> OK until > > --- e026 --- two types with the same brand > --- e0/e026/stdout.build 2008-01-20 00:50:38.000000000 +0100 > +++ ../src/e0/e026/stdout.build 2003-03-08 23:36:13.000000000 +0100 > @@ -0,0 +1,3 @@ > +"../src/Main.m3", line 8: string: duplicate brand > +"../src/Main.m3", line 7: string: duplicate brand > +2 errors encountered > >> This seems to be just different/missing error output. >> >> Another more obvious example of this is here: > > --- e029 --- use type instead of value as an initializer > --- e0/e029/stdout.build 2008-01-20 00:50:41.000000000 +0100 > +++ ../src/e0/e029/stdout.build 2008-01-09 02:15:44.000000000 +0100 > @@ -1,11 +1,4 @@ > "../src/Main.m3", line 24: warning: variable has type NULL (r) > -"../src/Main.m3", line 24: ** INTERNAL CG ERROR *** stack not > empty, depth (1) > -"../src/Main.m3", line 25: ** INTERNAL CG ERROR *** stack not > empty, depth (1) > -"../src/Main.m3", line 26: ** INTERNAL CG ERROR *** unaligned > load_indirect type=11 s/a=0/8 > -"../src/Main.m3", line 26: ** INTERNAL CG ERROR *** unaligned > store_indirect type=11 s/a=0/8 > -"../src/Main.m3", line 26: ** INTERNAL CG ERROR *** stack not > empty, depth (1) > -"../src/Main.m3", line 26: ** INTERNAL CG ERROR *** stack not > empty, depth (1) > -"../src/Main.m3", line 22: ** INTERNAL CG ERROR *** stack not > empty, depth (1) > -"../src/Main.m3", line 22: 2 code generation errors > -8 errors and 1 warning encountered > +"../src/Main.m3", line 24: types are not assignable > +1 error and 1 warning encountered > Fatal Error: package build failed > >> Just ignore it? >> >> For reference, here's the extract of the programs' stderr output: > >>>> test_m3tests error extract: > FreeBSD4/p1/p116b/stderr.pgm:** Class (zero/zero) test not OK: > FALSE should be TRUE > FreeBSD4/p1/p116b/stderr.pgm:** Class zero/zero test not OK: FALSE > should be TRUE > FreeBSD4/p1/p155/stderr.pgm:************************ ERROR: check > (NOT (p >= x)) failed > FreeBSD4/p1/p155/stderr.pgm:1 error(s) and 0 warning(s) detected > FreeBSD4/p1/p172/stderr.pgm:************************ ERROR: 23.4 > instead of 23 > FreeBSD4/p1/p172/stderr.pgm:1 error(s) and 0 warning(s) detected > FreeBSD4/p1/p185/stderr.pgm:************************ ERROR: 53 > instead of 24 > FreeBSD4/p1/p185/stderr.pgm:1 error(s) and 0 warning(s) detected > FreeBSD4/r0/r001/stderr.pgm:*** > FreeBSD4/r0/r001/stderr.pgm:*** runtime error: > FreeBSD4/r0/r001/stderr.pgm:*** Unhandled exception: Main.a > FreeBSD4/r0/r001/stderr.pgm:*** file "../src/Main.m3", line 13 > FreeBSD4/r0/r001/stderr.pgm:*** > FreeBSD4/r0/r003/stderr.pgm:*** > FreeBSD4/r0/r003/stderr.pgm:*** runtime error: > FreeBSD4/r0/r003/stderr.pgm:*** An open array had the wrong shape. > FreeBSD4/r0/r003/stderr.pgm:*** file "../src/Main.m3", line 19 > FreeBSD4/r0/r003/stderr.pgm:*** > FreeBSD4/r0/r004/stderr.pgm:*** > FreeBSD4/r0/r004/stderr.pgm:*** runtime error: > FreeBSD4/r0/r004/stderr.pgm:*** An enumeration or subrange value > was out of range. > FreeBSD4/r0/r004/stderr.pgm:*** file "../src/runtime/common/ > RTAllocator.m3", line 309 > FreeBSD4/r0/r004/stderr.pgm:*** >>>> 7 in test_m3tests 2008-01-19-02-30-01 /home/wagner/work/cm3-ws/ >>>> luthien-2008-01-19-02-30-01 > === 2008-01-19 23:50:47 cm3 m3tests run done > > Thanks in advance for your comments, > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, > Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 > 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: > Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > DE163214194 From dabenavidesd at yahoo.es Sun Jan 20 23:30:59 2008 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Sun, 20 Jan 2008 23:30:59 +0100 (CET) Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: Message-ID: <651689.4797.qm@web27107.mail.ukl.yahoo.com> Hi: Yes, there is some kind of support for /dev file system, though I have not used it, I think this documentation is reliable: http://www.cygwin.com/cygwin-ug-net/using-specialnames.html Well after all the things you are right because the license issues maybe affect the decision of some users of making use of cygwin (NT386GNU): Let's suppose that there is some user(s) interested more in WIN32 platform so we can expose a better support for that on NT386_MINGW or in current NT386. The NT386GNU user(s) would be more appropriate for those interested in using more tools of a POSIX enviroment, let's say grep, gaw, POSIX functions of time, x server/client enviroment and all the stuff you can get to work on cygwin. So the second user has to pay (if he needs) attention on the licensing issues of all of the used tools. Thanks for the comments. Daniel Benavides Jay wrote: .hmmessage P { margin:0px; padding:0px } body.hmmessage { FONT-SIZE: 10pt; FONT-FAMILY:Tahoma } Daniel, yes it's true cygwin has like -mno-cygwin or something. I will have to try that. Currently msys is required to build m3cc and cygwin is required to build m3gdb. m3gdb didn't have any type information anyway, so if you install cygwin, you can just use its gdb. (Note that cygwin is highly modular/package-based, so you can pick and chose what you install, there are many many many choices, so you don't automatically get gdb, you don't automatically even get gcc or ld/binutils.) Otherwise just MinGWin is required. Cygwin might just work. I'll try it before much longer. Is someone going to go ahead and create a new target? I guess I'm about able to. I think I finally fixed the major crash so can..take a break and then continue. Wow that was tedious. Once I can get a MinGWin distribution, I want to look at the pixmap bug, before looking into this new target.. Maybe someone will beat me to it though? /dev does not appear in Cygwin, at least not with cd and ls on my system. I expect /dev/null will work. I do have a very limited installed of Cygwin now, as I was trying to understand roughly what is needed. I don't know what to expect from /dev in Cygwin. You might be asking for too much. $ ls /dev/null /dev/null Jay at jay-win1 / $ ls /proc 1312 cpuinfo meminfo registry stat version 3936 loadavg partitions self uptime Jay at jay-win1 / $ ls /dev ls: cannot access /dev: No such file or directory $ ls /dev/tty /dev/tty $ ls /dev/con ls: cannot access /dev/con: No such file or directory Jay at jay-win1 / $ ls /dev/fd0 /dev/fd0 Jay at jay-win1 / $ ls /dev/fd* ls: cannot access /dev/fd*: No such file or directory Jay at jay-win1 / $ ls /dev/hd0 ls: cannot access /dev/hd0: No such file or directory Jay at jay-win1 / $ ls /dev/sc* ls: cannot access /dev/sc*: No such file or directory I'm not sure what all to guess here. fd0 appears but I don't have a floppy disk. $ cat /proc/uptime 41101.28 32423.71 Jay at jay-win1 / $ cat /proc/version CYGWIN_NT-5.1 1.5.25(0.156/4/2) 2007-12-14 19:21 I'm inclined not to make any cygwin binary distributions until further reading of the license... There's still the X Windows vs. Win32 question... - Jay --------------------------------- Date: Sun, 20 Jan 2008 21:41:23 +0100 From: dabenavidesd at yahoo.es Subject: Re: [M3devel] [M3commit] CVS Update: cm3 To: jayk123 at hotmail.com; wagner at elegosoft.com; m3devel at elegosoft.com Hi: I think for all the users that maybe NT386GNU is more thought like NT386cygwin, but if we see that GNU tools are used in projects like Mingw, that is a fork of cygwin and with the aim of programs running without the dependency on cygwin dll, that maybe guide us to say that the "old target" NT386GNU should be run with a cygwin enviroment. The NT386_MINGW seems to be a nice name/description for the platform which no depends on cygwin.dll but a MinGW/MSYS enviroment. Certainly I think the gnu toolchain is highly used by both the projects, and as I remember, when installing gcc on cygwin it also offers the mingw tool set to the cygwin enviroment to be installed. So let's say that projects are very related and cooperative, but are not the same. So Jay, m3cc could be built on a cygwin enviroment and m3gdb? If so, we can think in those two separeted platforms? although cooperative for m3 developers. I would like to see m3-lectern packages running on NT386GNU using the filesystem /dev, which is something that I wouldn't expect to be on the proposed NT386_MINGW platform. Thanks Jay wrote: .ExternalClass .EC_hmmessage P {padding:0px;} .ExternalClass EC_body.hmmessage {font-size:10pt;font-family:Tahoma;} > the infrastructure. So I'd rather vote that only new targets get > more systematic names. Of course, though the existing names suggest new names, and not clear the value of the existing NT386GNU. Ie. is there a benefit to keep it in use with some meaning or not? Cygwin does have a larger jmpbuf than msvcr*.dll/mingwin. I think it holds sigaction state besides register state. "NT" and "Win" seem redundant. I386_MINGWIN? I386_CYGWIN? NT386_GNU? NT386_MINGNU? Ok, I admit that NT386_CYGWIN NT386_MINGWIN despite the redundancy, clearly point to existing projects that probably have name recognition. And building from NT386 is reasonable -- as was I saying about existing names influencing new names. A C generating backend gets you perhaps easier retargeting as well. I do see there is "MINGWIN64" out there, for AMD64. Not sure what the state of IA64 is though... (See -- you should avoid saying "32" or "64" in stuff, Win32 => Win, Win64 => Win.) I also would agree that creating one target instead of two is probably a good idea -- seems easier. I am not sure if current state is relevant. I mean, is NT386GNU really working and in use anywhere? Is PM3 in use? If so, then matching their meaning would be good. Or even going beyond that -- to Trestle on X Windows. :) (Though CygwinX doesn't exactly appear active.) And thus the precedent for no underscore. NT386MINGWIN ? NT386MINGNU ? I don't know if "MSYS" needs a place in this name. It is needed for building m3cc. I wonder if a hybrid/adaptive approach will be desired -- if Cygwin is available, the MinGWin target could use it to build m3gdb, since it can't otherwise. Hint for anyone trying out Cygwin and getting an odd mix of paths: mkdir \cygdrive get junction.exe from the former www.sysinternals.com junction \cygdrive\c c:\ now when some Cygwin code passes /cygdrive/c to Win32 code, it will just work, no translation needed. If you have multiple drives, I guess just fully populate each one c:\cygdrive\c => c:\ c:\cygdrive\d => d:\ d:\cygdrive\c => c:\ d:\cygdrive\d => d:\ etc. but I haven't tried that. Or, to reduce the multiplication, set them all up on c: and have d:\cygdrive => c:\cygdrive, e:\cygdrive => c:\cygdrive, etc. - Jay --------------------------------- > Date: Sun, 20 Jan 2008 15:56:49 +0100 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > Quoting Jay : > > > Good, a happy customer. :) > > > >> GNU_MODE = 0 % Do not use GNU tools at all -- today's NT386 > >> GNU_MODE = 1 % Use GNU tools minimally -- today's NT386GNU > >> GNU_MODE = 2 % Use GNU tools maximally -- not existant but probably > >> easy > >> > >> Eh..I know, not great.. what do "minimally" and "maximally" mean. > > > > I'm still fishing for anyone to provide answers to these > > less important decisions that I have trouble with. > > Otherwise maybe no NT Cygwin system. > > > > TARGETs = { NT386, NT386GNU, NT386CYGWIN }? > > TARGETs = { NT386, NT386MINGWIN, NT386CYGWIN }? > > TARGETs = { NT386 + GNU_MODE }? > > > > The one reason I don't favor NT386 + GNU_MODE is that Cygwin has a > > much larger jmpbuf than the others. > > I think same TARGET implies code can be linked together, and I think > > varying jmpbuf implies otherwise. > > So NT386 and NT386MINGWIN should rarely cross paths with NT386CYGWIN. > > I think a new target is called for if I have understood everything right. > We need one pure native target (NT386), one pure-Cygwin-based target > (NT386_CYGWIN?) and one mix of runtime, gnu tools and mingwin > (NT386_MINGWIN?). > > As NT386GNU already exists, we must decide if we want to use it as > we traditionally did (all Cygwin) or the mixed implementation > (Mingwin and much Windows RT). > > > I also do NOT like this ad-hoc naming style. > > PPC_DARWIN, I386_DARWIN are much more to my style. > > The names should be somehow hierarchical, except, I realize, there > > isn't necessarily one "path" of > > stuff which to name platforms, though the GNU folks have settled on > > a way or two. > > They have triples or quadruples -- processor-hardware-os or such, > > however this doesn't > > clearly suffice. > > Well, yes, something more systematic would have been better, but > to break with the history will cause much trouble for all users and > the infrastructure. So I'd rather vote that only new targets get > more systematic names. > > > Something that accomodates: > > NT386 + LLVM > > NT386 + Watcom, linker and/or backend and/or runtime > > NT386 + Digital Mars linker and/or backend and/or runtime > > A C generating backend, and then linker/runtime > > and similar IA64, AMD64 variants would be good. > > I'm not sure that a C generating backend would really help matters. > This was done in the first implementation of DEC, and they soon > abandoned it as C had proven to be a bad choice as intermediate language. > I agree it would be great for cross-compilation etc. > > As far as C and RT dependencies of native Windows compilers go, I don't > see why this couldn't be just a question of another cm3.cfg setup. > > > To a large extent, these can be few platforms, subject to > > configuration, like if all > > the linkers consume a common file format (not clear), and if all the > > jmpbufs are the same > > size (known to be partly true, partly false). > > Yes, jmpbuf is always a problem for user threads and exceptions. > On Unix systems the jmpbuf and other important low-level structures > are always defined by the system headers and independent of compilers > AFAIK, so I'm a bit surprised that it should be different on Windows. > But maybe I'm just wrong and haven't just seen the right counter > examples... > > > Oh and another thing, the runtime dependency is very likely cuttable, however > > PRESUMABLY real world applications (if there are any) link in a > > substantial amount of > > C or C++, in which case, it isn't necessarily cuttable. > > Yes. Real world applications tend to link other libraries (C, C++, > Fortran, ...) and even often call other applications like sh etc. > > > As well, if I can figure out a good way to do it, switching NT386 > > from awful slow > > frequent TlsGetValue/TlsSetValue to manipulating the linked list in > > fs:0, that would be nice, > > and might incur a C runtime dependency, but well worth it. The way > > Modula-3 works here > > is terrible. Another compromise option is probably > > __declspec(thread), though there is trickiness there > > in terms of being in a .dll that isn't used by the .exe. > > Such optimizations should be done depending on the target. > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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! --------------------------------- Web Revelaci?n Yahoo! 2007: Premio Favorita del P?blico - ?Vota tu preferida! --------------------------------- Shed those extra pounds with MSN and The Biggest Loser! Learn more. --------------------------------- Web Revelaci?n Yahoo! 2007: Premio Favorita del P?blico - ?Vota tu preferida! -------------- next part -------------- An HTML attachment was scrubbed... URL: From dabenavidesd at yahoo.es Sun Jan 20 23:35:02 2008 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Sun, 20 Jan 2008 23:35:02 +0100 (CET) Subject: [M3devel] cygwin users? In-Reply-To: Message-ID: <786049.83427.qm@web27111.mail.ukl.yahoo.com> I guess my discussion is more about of an ideal world for programmers :) that has a lot of discussion, but also for all the users that want to port more easily applications from a (~)Unix platforms to Windows like I would like to do it with m3-lectern packages. Thanks again, Daniel Benavides Jay escribi?: .hmmessage P { margin:0px; padding:0px } body.hmmessage { FONT-SIZE: 10pt; FONT-FAMILY:Tahoma } Does anyone who is asking for Cygwin support actually use it? Or you are all just Unix users? (And MinGW users either?) I mean, are we hearing what people want and will use, or just what ought to exist in some ideal world? - Jay --------------------------------- Climb to the top of the charts! Play the word scramble challenge with star power. Play now! --------------------------------- Web Revelaci?n Yahoo! 2007: Premio Favorita del P?blico - ?Vota tu preferida! -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Sun Jan 20 23:45:32 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Sun, 20 Jan 2008 23:45:32 +0100 Subject: [M3devel] cygwin users? In-Reply-To: References: <862972.55026.qm@web27105.mail.ukl.yahoo.com> Message-ID: <20080120234532.1dstrrusisoscc0s@mail.elegosoft.com> Quoting Jay : > Does anyone who is asking for Cygwin support actually use it? Or you > are all just Unix users? > (And MinGW users either?) > I mean, are we hearing what people want and will use, or just what > ought to exist in some ideal world? I haven been using Cygwin several years ago, and would do so again. Whenever I have to use a Windows system, one of the first things I do is install Cygwin to have a comfortable command line environment I am familiar with. I'd be especially interested in M3-XWindows programs running on Cygwin, as the native Trestle implementation was never complete, IIRC. And X-Servers are really common and easy to install nowadays even on 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 darko at darko.org Mon Jan 21 01:18:59 2008 From: darko at darko.org (Darko) Date: Sun, 20 Jan 2008 16:18:59 -0800 Subject: [M3devel] cygwin users? In-Reply-To: References: <862972.55026.qm@web27105.mail.ukl.yahoo.com> Message-ID: <7EEE72F7-B0D1-42FB-B5D7-4C2E3533F16E@darko.org> I don't use Cygwin, but I use a Unix command line under Windows (I found the basic bash tools compiled to be used standalone under Windows, they might be MinGW based, but I'm not sure). I generally use GUI tools, CodeWarrior on my Mac generally, but also the MS IDE for its debugging tool. I'm interested in the NT/GNU platform mostly for the optimised code generation. I guess I represent the other side to the Unix geeks - it's just another platform to me and I'd like to keep it distinct from Windows, mainly for performance, compatibility and simplicity. I think there are many potential users like me out there, who don't particularly care about Unix. M3's Unix heritage has hindered M3 a little I think. One of the reasons M3 isn't more popular is because there are no simple installers for common "user" platforms. One of the things I'd like to do is create a installer for Windows and Mac OS X with full native API interfaces, a full set of relevant compiled libraries, and a little bit of documentation. That way people can give it a try with the minimum of time invested. People will discover M3 is a great language to program in if people actually get a chance to use it. Thanks for doing all the work you've been doing on the NT platform, Jay, it is much appreciated and has the potential to bring may more users to M3. Darko. On 20/01/2008, at 1:09 PM, Jay wrote: > Does anyone who is asking for Cygwin support actually use it? Or you > are all just Unix users? > (And MinGW users either?) > I mean, are we hearing what people want and will use, or just what > ought to exist in some ideal world? > > - Jay > > Climb to the top of the charts! Play the word scramble challenge > with star power. Play now! From jayk123 at hotmail.com Mon Jan 21 05:45:43 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 21 Jan 2008 04:45:43 +0000 Subject: [M3devel] "one more time before I give in" :) Message-ID: Should the mingwin/msys method just be a configuration of NT386? A command line option to cm3 and/or an environment variable? The targets are nearly the same. The difference just needs to be exposed somehow, so the config file can switch betwen two implementations of a few functions -- compile_c, m3_link, make_lib. If Windows cminstall/src/config/NT386 and cminstall/src/config/NT386GNU, you see very very similar. Maybe they vary just in BUILD_DIR? Or does that break things?Profiling changes BUILD_DIR so I figure it might be ok. I tried making BUILD_DIR not readonly and setting it with cm3 -D, doesn't work. It can probably be set conditionally in the config file based on another variable though, I'd have to check. Besides, it might be nice for a notion of a set of build_dirs that are probed. In particular, you might have some C or C++ code that uses GCC (or Microsoft) extensions. That could also be handled by a different variable, like compile_with_gcc() and compile_with_msvc() in the m3makefile and then cm3 would switch between compile_gcc and compile_msvc instead of the usual compile_c functoin. There is a high degree of interoperabilty between these two or even all three platforms. Perhaps this is a can of worms though. Much potential utility but too complicated to think about? Perhaps I too desperate to have fewer platforms? I do need multiple build_dirs, like three, that is certain. - 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 Mon Jan 21 06:05:03 2008 From: darko at darko.org (Darko) Date: Sun, 20 Jan 2008 21:05:03 -0800 Subject: [M3devel] "one more time before I give in" :) In-Reply-To: References: Message-ID: <1E4B5D9E-F0B1-4E2F-90E6-34385C5CDFB6@darko.org> Can we just have them as separate config files and anyone who wants to switch between them can do so in a script or other method on their own platform? Most people would just choose one and stick to it. We should try to keep it simple and move the complexity to people who want a more complex setup. On 20/01/2008, at 8:45 PM, Jay wrote: > Should the mingwin/msys method just be a configuration of NT386? > A command line option to cm3 and/or an environment variable? > > The targets are nearly the same. > The difference just needs to be exposed somehow, so the config file > can switch betwen two implementations of a few functions -- > compile_c, m3_link, make_lib. > If Windows cminstall/src/config/NT386 and cminstall/src/config/ > NT386GNU, you see very very similar. > > Maybe they vary just in BUILD_DIR? Or does that break things? > Profiling changes BUILD_DIR so I figure it might be ok. > I tried making BUILD_DIR not readonly and setting it with cm3 -D, > doesn't work. > It can probably be set conditionally in the config file based on > another variable though, I'd have to check. > > Besides, it might be nice for a notion of a set of build_dirs that > are probed. > In particular, you might have some C or C++ code that uses GCC (or > Microsoft) extensions. > That could also be handled by a different variable, like > compile_with_gcc() and compile_with_msvc() in the m3makefile and > then cm3 would switch between compile_gcc and compile_msvc instead > of the usual compile_c functoin. > > There is a high degree of interoperabilty between these two or even > all three platforms. > > Perhaps this is a can of worms though. Much potential utility but > too complicated to think about? > > Perhaps I too desperate to have fewer platforms? > I do need multiple build_dirs, like three, that is certain. > > - Jay > > Helping your favorite cause is as easy as instant messaging. You IM, > we give. Learn more. From jayk123 at hotmail.com Mon Jan 21 06:47:28 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 21 Jan 2008 05:47:28 +0000 Subject: [M3devel] next problem (NT386GNU) Message-ID: M3File.m3 PROCEDURE IsReadable (path: TEXT): BOOLEAN = (* We don't really check for readablitiy, just for existence *) BEGIN TRY EVAL FS.Status (path); line 82 RETURN TRUE; EXCEPT OSError.E => RETURN FALSE; END; END IsReadable; -----LINE 82 ----- start_call_direct p.25 0 Struct load_address v.25 0 pop_param Addr load v.26 0 Addr Addr pop_param Addr call_direct p.25 Struct pop StructI'm guessing you only see an import for the first call on purpose, but I will compare with PPC_DARWIN: -----LINE 46 ----- import_procedure FS__Status 2 Struct 0 p.25 declare_indirect 2078421550 -2078421551 declare_param _return 4 4 Addr 2078421550 F F 50 v.62 declare_param p 4 4 Addr 1358456180 F F 50 v.63 start_call_direct p.25 0 Struct load_address v.13 0 pop_param Addr load v.14 0 Addr Addr pop_param Addr call_direct p.25 Struct pop Struct .globl _M3File__IsReadable .def _M3File__IsReadable; .scl 2; .type 32; .endef_M3File__IsReadable: .stabn 68,0,178,LM93-_M3File__IsReadableLM93: pushl %ebp movl %esp, %ebp pushl %edi pushl %esi pushl %ebx subl $300, %espLBB15: .stabn 68,0,181,LM94-_M3File__IsReadableLM94:L157: movl -280(%ebp), %eax andl $0, %eax orl $_L_1, %eax movl %eax, -280(%ebp) movl -284(%ebp), %eax andl $0, %eax movl %eax, -284(%ebp) subl $12, %esp leal -288(%ebp), %eax pushl %eax call _RTHooks__PushEFrame addl $16, %esp leal -288(%ebp), %eax addl $48, %eax subl $12, %esp pushl %eax call __setjmp addl $16, %esp testb %al, %al jne L158 .stabn 68,0,183,LM95-_M3File__IsReadableLM95: movl -288(%ebp), %eax subl $12, %esp pushl %eax call _RTHooks__PopEFrame addl $16, %esp movl $1, -304(%ebp) jmp L159L158: .stabn 68,0,185,LM96-_M3File__IsReadableLM96: movl $0, -304(%ebp)L159:LBE15: movl -304(%ebp), %eax leal -12(%ebp), %esp popl %ebx popl %esi popl %edi leave ret M3File.IsReadable's call to FS.Status is omitted, all files are readable, even if they are not openable, therefore it "finds" cm3.cfg in the current directory and then fails to open it.. later.. ..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 wagner at elegosoft.com Mon Jan 21 08:20:53 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 21 Jan 2008 08:20:53 +0100 Subject: [M3devel] "one more time before I give in" :) In-Reply-To: References: Message-ID: <20080121082053.2ph7hxo5esw0wk0g@mail.elegosoft.com> Quoting Jay : > Should the mingwin/msys method just be a configuration of NT386? > A command line option to cm3 and/or an environment variable? > > The targets are nearly the same. > The difference just needs to be exposed somehow, so the config file > can switch betwen two implementations of a few functions -- > compile_c, m3_link, make_lib. > If Windows cminstall/src/config/NT386 and > cminstall/src/config/NT386GNU, you see very very similar. As long as the M3 and C code is all the same, I'm not against having just different cm3.cfg files. > Maybe they vary just in BUILD_DIR? Or does that break > things?Profiling changes BUILD_DIR so I figure it might be ok. > I tried making BUILD_DIR not readonly and setting it with cm3 -D, > doesn't work. > It can probably be set conditionally in the config file based on > another variable though, I'd have to check. > > Besides, it might be nice for a notion of a set of build_dirs that > are probed. > In particular, you might have some C or C++ code that uses GCC (or > Microsoft) extensions. > That could also be handled by a different variable, like > compile_with_gcc() and compile_with_msvc() in the m3makefile and > then cm3 would switch between compile_gcc and compile_msvc instead > of the usual compile_c functoin. > > There is a high degree of interoperabilty between these two or even > all three platforms. > > Perhaps this is a can of worms though. Much potential utility but > too complicated to think about? > > Perhaps I too desperate to have fewer platforms? > I do need multiple build_dirs, like three, that is certain. Using other build_dirs for derived target files from cm3.cfg should work, too; but we should not diverge too much from the staandard; perhaps just add a _MINGWIN or _CYGWIN suffix? Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Jan 21 08:43:53 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 21 Jan 2008 07:43:53 +0000 Subject: [M3devel] next problem (NT386GNU) Message-ID: I haven't tested a fix but I see the problem. This function returns a struct. There are two struct returning calling conventions. In one, the backend handles it. Which includes the backend knowing there is a return value and its type (or at least its size?). In the other, the front end handles it. In this case, the front end generates passing an extra pointer parameter to the function, and the function's return type is void. The NT calling conventions, all of them, are marked as front end handling it. I assume that is correct, could check. Everything else is marked as back end handling. Now then, somewhere along the line, gcc figures out that the return value isn't used here. The point of the function call is to see if it generates an exception.Gcc removes the function because its return value isn't used, and, well, somehow it doesn't know about the exceptions here. I'll have to see how "raise" is implemented. I think it's by a call to a function that gets the jmpbuf from a thread local and calls longjmp. (Did I mention it is very inefficient?) There are few possible fixes, but nothing completely satisfactory yet in mind. One is have parse.c mark all function calls as having side affects. This is easy, but overly pessimistic. Another is for the front end to mark struct returning functions as having side affects. Better, but still overly pessimistic. Another is for the front end to mark any function that can raise as having side affects. Getting better still. I don't know how to do that but I'll look. This is still a bit overly pessimistic, since what you really want to know is, not the function's side affects, but whether or not it raised. If the function is inlined, the side affects could be optimized away, or if there are enough callers who don't care about the side affects to warrant an optimization, and depending on the cost of computing the side affects, another instance of the function could be made that only raises or not, but no side affects otherwise. This is "advanced" optimization the sort of which tends never to be implemented. I think the best option is anything that can raise is marked as having side affects. I'll see if I can figure that out. You can figure this out by looking at m3cgcat -binary < M3File.mc > 1.txt on PPC_DARWIN and NT386GNU and comparing. Maybe marking all or nearly functions as having side effects isn't so bad. Or at least anything returning a struct. That gets parity with other platforms, even if it is a bit pessimistic. I think I'll do that, and ignore figuring out if raise is called and using that as a filter. The parity angle is good. The good news for all you Unix lovers :) is this bug is relatively portable to Cygwin. True, it is specific to NT386GNU having multiple "calling conventions", which no other platform has. Which again, jokingly, strikes at the question -- What is Posix? What do you want from Cygwin? One thing Cygwin does NOT give you is just one calling convention, alas, this calling convention business stinks. It's not even an NT thing, only an NT386 thing. All the other NT platforms had/have only one calling convention. You can't get far on NT386 without needing to support two calling conventions. The "OS" uses mostly __stdcall -- callee pops -- smaller, faster. But anything that is varargs, such as printf -- pretty much must use caller pops -- __cdecl. As well, __cdecl is the default, so prevalent, and used in most C runtime functions. There is also __fastcall that uses like up to two registers for parameters. I have seen a platform in which printf did the pop, and it depended on the number/size of parameters matching the format string. On most platforms, printf("", 1, 2, 3, 4) just does nothing, but on that platform, it'd unbalance the stack and crash. - Jay From: jayk123 at hotmail.comTo: hosking at cs.purdue.eduCC: m3devel at elegosoft.comSubject: next problem (NT386GNU)Date: Mon, 21 Jan 2008 05:47:28 +0000 M3File.m3 PROCEDURE IsReadable (path: TEXT): BOOLEAN = (* We don't really check for readablitiy, just for existence *) BEGIN TRY EVAL FS.Status (path); line 82 RETURN TRUE; EXCEPT OSError.E => RETURN FALSE; END; END IsReadable; -----LINE 82 ----- start_call_direct p.25 0 Struct load_address v.25 0 pop_param Addr load v.26 0 Addr Addr pop_param Addr call_direct p.25 Struct pop StructI'm guessing you only see an import for the first call on purpose, but I will compare with PPC_DARWIN: -----LINE 46 ----- import_procedure FS__Status 2 Struct 0 p.25 declare_indirect 2078421550 -2078421551 declare_param _return 4 4 Addr 2078421550 F F 50 v.62 declare_param p 4 4 Addr 1358456180 F F 50 v.63 start_call_direct p.25 0 Struct load_address v.13 0 pop_param Addr load v.14 0 Addr Addr pop_param Addr call_direct p.25 Struct pop Struct .globl _M3File__IsReadable .def _M3File__IsReadable; .scl 2; .type 32; .endef_M3File__IsReadable: .stabn 68,0,178,LM93-_M3File__IsReadableLM93: pushl %ebp movl %esp, %ebp pushl %edi pushl %esi pushl %ebx subl $300, %espLBB15: .stabn 68,0,181,LM94-_M3File__IsReadableLM94:L157: movl -280(%ebp), %eax andl $0, %eax orl $_L_1, %eax movl %eax, -280(%ebp) movl -284(%ebp), %eax andl $0, %eax movl %eax, -284(%ebp) subl $12, %esp leal -288(%ebp), %eax pushl %eax call _RTHooks__PushEFrame addl $16, %esp leal -288(%ebp), %eax addl $48, %eax subl $12, %esp pushl %eax call __setjmp addl $16, %esp testb %al, %al jne L158 .stabn 68,0,183,LM95-_M3File__IsReadableLM95: movl -288(%ebp), %eax subl $12, %esp pushl %eax call _RTHooks__PopEFrame addl $16, %esp movl $1, -304(%ebp) jmp L159L158: .stabn 68,0,185,LM96-_M3File__IsReadableLM96: movl $0, -304(%ebp)L159:LBE15: movl -304(%ebp), %eax leal -12(%ebp), %esp popl %ebx popl %esi popl %edi leave ret M3File.IsReadable's call to FS.Status is omitted, all files are readable, even if they are not openable, therefore it "finds" cm3.cfg in the current directory and then fails to open it.. later.. ..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 Mon Jan 21 09:03:44 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 21 Jan 2008 08:03:44 +0000 Subject: [M3devel] FW: next problem (NT386GNU) Message-ID: and again my mail got truncated..Clearly the best option, despite the pessimism, is to mark all struct returning functions has having side affects, as that achieves parity with all the other gcc-based platforms. Optimizing this can be left for later target-independent work that'll probably never happen. Changing the calling convention is almost an option, as there are so few functions in the world foolhardy enough to return structs. If they are all written in Modula-3, then there'd be enough consistency. Sleazy though.I'll see what PM3 does first. - Jay Which again, jokingly, strikes at the question -- What is Posix? What do you want from Cygwin?One thing Cygwin does NOT give you is just one calling convention, alas, this calling convention business stinks. It's not even an NT thing, only an NT386 thing. All the other NT platforms had/have only one calling convention. You can't get far on NT386 without needing to support two calling conventions.The "OS" uses mostly __stdcall -- callee pops -- smaller, faster.But anything that is varargs, such as printf -- pretty much must use caller pops -- __cdecl.As well, __cdecl is the default, so prevalent, and used in most C runtime functions.There is also __fastcall that uses like up to two registers for parameters. I have seen a platform in which printf did the pop, and it depended on the number/size of parameters matching the format string. On most platforms, printf("", 1, 2, 3, 4) just does nothing, but on that platform, it'd unbalance the stack and crash. - Jay From: jayk123 at hotmail.comTo: hosking at cs.purdue.eduCC: m3devel at elegosoft.comSubject: next problem (NT386GNU)Date: Mon, 21 Jan 2008 05:47:28 +0000 M3File.m3 PROCEDURE IsReadable (path: TEXT): BOOLEAN = (* We don't really check for readablitiy, just for existence *) BEGIN TRY EVAL FS.Status (path); line 82 RETURN TRUE; EXCEPT OSError.E => RETURN FALSE; END; END IsReadable; -----LINE 82 ----- start_call_direct p.25 0 Struct load_address v.25 0 pop_param Addr load v.26 0 Addr Addr pop_param Addr call_direct p.25 Struct pop StructI'm guessing you only see an import for the first call on purpose, but I will compare with PPC_DARWIN: -----LINE 46 ----- import_procedure FS__Status 2 Struct 0 p.25 declare_indirect 2078421550 -2078421551 declare_param _return 4 4 Addr 2078421550 F F 50 v.62 declare_param p 4 4 Addr 1358456180 F F 50 v.63 start_call_direct p.25 0 Struct load_address v.13 0 pop_param Addr load v.14 0 Addr Addr pop_param Addr call_direct p.25 Struct pop Struct .globl _M3File__IsReadable .def _M3File__IsReadable; .scl 2; .type 32; .endef_M3File__IsReadable: .stabn 68,0,178,LM93-_M3File__IsReadableLM93: pushl %ebp movl %esp, %ebp pushl %edi pushl %esi pushl %ebx subl $300, %espLBB15: .stabn 68,0,181,LM94-_M3File__IsReadableLM94:L157: movl -280(%ebp), %eax andl $0, %eax orl $_L_1, %eax movl %eax, -280(%ebp) movl -284(%ebp), %eax andl $0, %eax movl %eax, -284(%ebp) subl $12, %esp leal -288(%ebp), %eax pushl %eax call _RTHooks__PushEFrame addl $16, %esp leal -288(%ebp), %eax addl $48, %eax subl $12, %esp pushl %eax call __setjmp addl $16, %esp testb %al, %al jne L158 .stabn 68,0,183,LM95-_M3File__IsReadableLM95: movl -288(%ebp), %eax subl $12, %esp pushl %eax call _RTHooks__PopEFrame addl $16, %esp movl $1, -304(%ebp) jmp L159L158: .stabn 68,0,185,LM96-_M3File__IsReadableLM96: movl $0, -304(%ebp)L159:LBE15: movl -304(%ebp), %eax leal -12(%ebp), %esp popl %ebx popl %esi popl %edi leave ret M3File.IsReadable's call to FS.Status is omitted, all files are readable, even if they are not openable, therefore it "finds" cm3.cfg in the current directory and then fails to open it.. later.. ..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! 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 Jan 21 09:05:32 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 21 Jan 2008 08:05:32 +0000 Subject: [M3devel] next problem (NT386GNU) Message-ID: pm3: IF gnuWin32 THEN CCs[x].args_left_to_right := TRUE; CCs[x].results_on_left := TRUE; CCs[x].standard_structs := TRUE; END;Duh, maybe the backend handles it correctly. I'll try.. - Jay From: jayk123 at hotmail.comTo: m3devel at elegosoft.comSubject: FW: next problem (NT386GNU)Date: Mon, 21 Jan 2008 08:03:44 +0000 and again my mail got truncated..Clearly the best option, despite the pessimism, is to mark all struct returning functions has having side affects, as that achieves parity with all the other gcc-based platforms. Optimizing this can be left for later target-independent work that'll probably never happen. Changing the calling convention is almost an option, as there are so few functions in the world foolhardy enough to return structs. If they are all written in Modula-3, then there'd be enough consistency. Sleazy though.I'll see what PM3 does first. - Jay Which again, jokingly, strikes at the question -- What is Posix? What do you want from Cygwin?One thing Cygwin does NOT give you is just one calling convention, alas, this calling convention business stinks. It's not even an NT thing, only an NT386 thing. All the other NT platforms had/have only one calling convention. You can't get far on NT386 without needing to support two calling conventions.The "OS" uses mostly __stdcall -- callee pops -- smaller, faster.But anything that is varargs, such as printf -- pretty much must use caller pops -- __cdecl.As well, __cdecl is the default, so prevalent, and used in most C runtime functions.There is also __fastcall that uses like up to two registers for parameters. I have seen a platform in which printf did the pop, and it depended on the number/size of parameters matching the format string. On most platforms, printf("", 1, 2, 3, 4) just does nothing, but on that platform, it'd unbalance the stack and crash. - Jay From: jayk123 at hotmail.comTo: hosking at cs.purdue.eduCC: m3devel at elegosoft.comSubject: next problem (NT386GNU)Date: Mon, 21 Jan 2008 05:47:28 +0000 M3File.m3 PROCEDURE IsReadable (path: TEXT): BOOLEAN = (* We don't really check for readablitiy, just for existence *) BEGIN TRY EVAL FS.Status (path); line 82 RETURN TRUE; EXCEPT OSError.E => RETURN FALSE; END; END IsReadable; -----LINE 82 ----- start_call_direct p.25 0 Struct load_address v.25 0 pop_param Addr load v.26 0 Addr Addr pop_param Addr call_direct p.25 Struct pop StructI'm guessing you only see an import for the first call on purpose, but I will compare with PPC_DARWIN: -----LINE 46 ----- import_procedure FS__Status 2 Struct 0 p.25 declare_indirect 2078421550 -2078421551 declare_param _return 4 4 Addr 2078421550 F F 50 v.62 declare_param p 4 4 Addr 1358456180 F F 50 v.63 start_call_direct p.25 0 Struct load_address v.13 0 pop_param Addr load v.14 0 Addr Addr pop_param Addr call_direct p.25 Struct pop Struct .globl _M3File__IsReadable .def _M3File__IsReadable; .scl 2; .type 32; .endef_M3File__IsReadable: .stabn 68,0,178,LM93-_M3File__IsReadableLM93: pushl %ebp movl %esp, %ebp pushl %edi pushl %esi pushl %ebx subl $300, %espLBB15: .stabn 68,0,181,LM94-_M3File__IsReadableLM94:L157: movl -280(%ebp), %eax andl $0, %eax orl $_L_1, %eax movl %eax, -280(%ebp) movl -284(%ebp), %eax andl $0, %eax movl %eax, -284(%ebp) subl $12, %esp leal -288(%ebp), %eax pushl %eax call _RTHooks__PushEFrame addl $16, %esp leal -288(%ebp), %eax addl $48, %eax subl $12, %esp pushl %eax call __setjmp addl $16, %esp testb %al, %al jne L158 .stabn 68,0,183,LM95-_M3File__IsReadableLM95: movl -288(%ebp), %eax subl $12, %esp pushl %eax call _RTHooks__PopEFrame addl $16, %esp movl $1, -304(%ebp) jmp L159L158: .stabn 68,0,185,LM96-_M3File__IsReadableLM96: movl $0, -304(%ebp)L159:LBE15: movl -304(%ebp), %eax leal -12(%ebp), %esp popl %ebx popl %esi popl %edi leave ret M3File.IsReadable's call to FS.Status is omitted, all files are readable, even if they are not openable, therefore it "finds" cm3.cfg in the current directory and then fails to open it.. later.. ..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! Learn more. 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 jayk123 at hotmail.com Mon Jan 21 11:50:28 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 21 Jan 2008 10:50:28 +0000 Subject: [M3devel] gcc/eh/setjmp Message-ID: Folks, try adding -Wunreachable-code to your m3back options and tell me if you don't get loads of warnings. for stuff like: TRY return Foo(); ELSE return FALSE; I get them on NT386GNU and PPC_DARWIN. Functions with TRY need, in gcc parlance: calls_setjmp and the exception/finally blocks need: has_nonlocal_label and functions with RAISE might need: has_nonlocal_goto Luckily, gcc doesn't seem to act on what it figure out. - 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 mika at async.caltech.edu Mon Jan 21 11:54:26 2008 From: mika at async.caltech.edu (Mika Nystrom) Date: Mon, 21 Jan 2008 02:54:26 -0800 Subject: [M3devel] cygwin users? In-Reply-To: Your message of "Sun, 20 Jan 2008 21:09:42 GMT." Message-ID: <200801211054.m0LAsQbx067355@camembert.async.caltech.edu> I develop on FreeBSD but my production system runs under Cygwin. It links with libpq.a, plus various C and Fortran code I wrote myself under Unix. It also builds with make, uses readline, calls /bin/sh, etc., etc., etc. I'm using PM3/Klagenfurt for this, and I'm just DYING to shift it to CM3 one day, because since I need Pickles to work across all architectures I'm using I'm currently in the situation that I can't use Linux in our clustered system (no PM3), nor can I use MacOS (also no PM3). One of my business partners uses Ubuntu, so his computer can't talk to mine, and I have a Mac laptop, so my laptop can't talk to my main systems. Etc. Cygwin is the only of five or six environments that I have to use that can't run CM3. Yes it is probably possible for me to port my code to native Windows (anything is possible), but the beauty of Cygwin is that I can be fairly confident that any code that works on FreeBSD, no matter how weird and Unix-specific, will also work on Cygwin. (Once you know about the pitfalls in Time.T and file semantics.) I am a bona fide "Windows hater". To me, Windows is an especially bloated program loader that for some bizarre reason people have chosen to load the most useful web browsers and music players. I haven't found anything else useful that it does. I have seen people use something called "Visual Studio" on it. Oh yes, I even used it myself once, but I couldn't figure out how to transport the program I wrote to the computer of someone who didn't have "Visual Studio" to run (even after asking some of my former students, who are now programmers at Microsoft), so I gave up on it. I think it is for people like me that Cygwin was invented. Mika Jay writes: >--_674d79e8-e259-4230-8419-f52e99d90089_ >Content-Type: text/plain; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > >Does anyone who is asking for Cygwin support actually use it? Or you are al= >l just Unix users? >(And MinGW users either?) >I mean, are we hearing what people want and will use, or just what ought to= > exist in some ideal world? >=20 > - Jay >_________________________________________________________________ >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= > >--_674d79e8-e259-4230-8419-f52e99d90089_ >Content-Type: text/html; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > > > > >Does anyone who is asking for Cygwin support actu= >ally use it? Or you are all just Unix users?
>(And MinGW users either?)
>I mean, are we hearing what people want and will use, or just what ought to= > exist in some ideal world?
> 
> - Jay

Climb to the top of the charts!=A0Play the word = >scramble challenge with star power. uffle.aspx?icid=3Dstarshuffle_wlmailtextlink_jan' target=3D'_new'>Play now!= > >= > >--_674d79e8-e259-4230-8419-f52e99d90089_-- From lemming at henning-thielemann.de Mon Jan 21 12:51:48 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Mon, 21 Jan 2008 12:51:48 +0100 (MET) Subject: [M3devel] Open CM3 regression tests In-Reply-To: <20080120211832.GA26993@elegosoft.com> References: <20080120211832.GA26993@elegosoft.com> Message-ID: On Sun, 20 Jan 2008, Olaf Wagner wrote: > > no errors for p1 to p115 > > --- p116b --- default IEEE floating point tests from Xerox PARC > --- p1/p116b/stderr.pgm 2008-01-20 00:47:20.000000000 +0100 > +++ ../src/p1/p116b/stderr.pgm 2008-01-13 00:55:55.000000000 +0100 My compiler complains about LONGINT type in src/Test.i3 . I assume that this is the 64 bit support. Seems that I have to upgrade my compiler. In general floating point is a strange issue. You cannot rely on that your machine supports IEEE format, although most machines do. The precision of the same float type can be different on different machines. However, the Float modules shall reflect that. Computation with NaN and Infinity is broken, it should be avoided and in most cases continueing the computation with NaN or Infinity only hides the precise error location. It would be better to abort with an error for a division by zero, overflow and so on. I think one can enable this with FloatModes. From jayk123 at hotmail.com Mon Jan 21 14:19:41 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 21 Jan 2008 13:19:41 +0000 Subject: [M3devel] gcc/eh/setjmp Message-ID: I've been trying sprinkling these bits around, to no avail. I realize another larger step is to communicate much try/except/finally information down, in order to use the native support (which still stinks on Windows). I stupidly plumbed the depths of "CG" to communicate the bits down before seeing what was needed.. - Jay From: jayk123 at hotmail.comTo: m3devel at elegosoft.comSubject: gcc/eh/setjmpDate: Mon, 21 Jan 2008 10:50:28 +0000 Folks, try adding -Wunreachable-code to your m3back options and tell me if you don't get loads of warnings.for stuff like: TRY return Foo();ELSE return FALSE; I get them on NT386GNU and PPC_DARWIN. Functions with TRY need, in gcc parlance: calls_setjmp and the exception/finally blocks need: has_nonlocal_label and functions with RAISE might need: has_nonlocal_goto Luckily, gcc doesn't seem to act on what it figure out. - Jay Helping your favorite cause is as easy as instant messaging. You IM, we give. Learn more. _________________________________________________________________ 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 Jan 21 15:50:06 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 21 Jan 2008 14:50:06 +0000 Subject: [M3devel] code quality.. Message-ID: Unoptimized code quality is really bad, even compared to unoptimized C, even compared to gcc, and optimized code quality isn't great. I have this made up C code. I was verifyingthe struct return calling convention. typedef struct { unsigned a; unsigned b; unsigned c;} d; d F2(unsigned a, unsigned b, unsigned c){ d e; e.a = a * b * c; e.b = 123; e.c = a - b - c; return e;} and then the equivalent Modula-3: INTERFACE T; TYPE T1 = RECORD a,b,c : INTEGEREND; PROCEDURE F2(a,b,c : INTEGER) : T1; END T. MODULE T; PROCEDURE F2(a,b,c : INTEGER) : T1 =VAR e : T1;BEGIN e.a := (a * b * c); e.b := 123; e.c := (a - b - c); RETURN e;END F2; BEGINEND T. Unoptimized Visual C++ 8.0: _F2: 00000000: 55 push ebp 00000001: 8B EC mov ebp,esp 00000003: 83 EC 0C sub esp,0Ch 00000006: 8B 45 0C mov eax,dword ptr [ebp+0Ch] 00000009: 0F AF 45 10 imul eax,dword ptr [ebp+10h] 0000000D: 0F AF 45 14 imul eax,dword ptr [ebp+14h] 00000011: 89 45 F4 mov dword ptr [ebp-0Ch],eax 00000014: C7 45 F8 7B 00 00 mov dword ptr [ebp-8],7Bh 00 0000001B: 8B 4D 0C mov ecx,dword ptr [ebp+0Ch] 0000001E: 2B 4D 10 sub ecx,dword ptr [ebp+10h] 00000021: 2B 4D 14 sub ecx,dword ptr [ebp+14h] 00000024: 89 4D FC mov dword ptr [ebp-4],ecx 00000027: 8B 55 08 mov edx,dword ptr [ebp+8] 0000002A: 8B 45 F4 mov eax,dword ptr [ebp-0Ch] 0000002D: 89 02 mov dword ptr [edx],eax 0000002F: 8B 4D F8 mov ecx,dword ptr [ebp-8] 00000032: 89 4A 04 mov dword ptr [edx+4],ecx 00000035: 8B 45 FC mov eax,dword ptr [ebp-4] 00000038: 89 42 08 mov dword ptr [edx+8],eax 0000003B: 8B 45 08 mov eax,dword ptr [ebp+8] 0000003E: 8B E5 mov esp,ebp 00000040: 5D pop ebp 00000041: C3 ret Visual C++ 8.0 with /O1 It writes the results right into the output. _F2: 00000000: 55 push ebp 00000001: 8B EC mov ebp,esp 00000003: 8B 4D 0C mov ecx,dword ptr [ebp+0Ch] 00000006: 8B 45 08 mov eax,dword ptr [ebp+8] 00000009: 8B D1 mov edx,ecx 0000000B: 0F AF 55 10 imul edx,dword ptr [ebp+10h] 0000000F: 0F AF 55 14 imul edx,dword ptr [ebp+14h] 00000013: 2B 4D 10 sub ecx,dword ptr [ebp+10h] 00000016: 89 10 mov dword ptr [eax],edx 00000018: 2B 4D 14 sub ecx,dword ptr [ebp+14h] 0000001B: C7 40 04 7B 00 00 mov dword ptr [eax+4],7Bh 00 00000022: 89 48 08 mov dword ptr [eax+8],ecx 00000025: 5D pop ebp 00000026: C3 ret with /O2 _F2: 00000000: 8B 4C 24 08 mov ecx,dword ptr [esp+8] 00000004: 8B 54 24 0C mov edx,dword ptr [esp+0Ch] 00000008: 8B 44 24 04 mov eax,dword ptr [esp+4] 0000000C: 56 push esi 0000000D: 8B 74 24 14 mov esi,dword ptr [esp+14h] 00000011: 57 push edi 00000012: 8B F9 mov edi,ecx 00000014: 0F AF FA imul edi,edx 00000017: 0F AF FE imul edi,esi 0000001A: 2B CA sub ecx,edx 0000001C: 89 38 mov dword ptr [eax],edi 0000001E: 2B CE sub ecx,esi 00000020: 5F pop edi 00000021: C7 40 04 7B 00 00 mov dword ptr [eax+4],7Bh 00 00000028: 89 48 08 mov dword ptr [eax+8],ecx 0000002B: 5E pop esi 0000002C: C3 ret gcc 3.4.5 unoptimized _F2: 00000000: 55 push ebp 00000001: 89 E5 mov ebp,esp 00000003: 83 EC 18 sub esp,18h 00000006: 8B 4D 08 mov ecx,dword ptr [ebp+8] 00000009: 8B 45 0C mov eax,dword ptr [ebp+0Ch] 0000000C: 0F AF 45 10 imul eax,dword ptr [ebp+10h] 00000010: 0F AF 45 14 imul eax,dword ptr [ebp+14h] 00000014: 89 45 E8 mov dword ptr [ebp-18h],eax 00000017: C7 45 EC 7B 00 00 mov dword ptr [ebp-14h],7Bh 00 0000001E: 8B 55 10 mov edx,dword ptr [ebp+10h] 00000021: 8B 45 0C mov eax,dword ptr [ebp+0Ch] 00000024: 29 D0 sub eax,edx 00000026: 2B 45 14 sub eax,dword ptr [ebp+14h] 00000029: 89 45 F0 mov dword ptr [ebp-10h],eax 0000002C: 8B 45 E8 mov eax,dword ptr [ebp-18h] 0000002F: 89 01 mov dword ptr [ecx],eax 00000031: 8B 45 EC mov eax,dword ptr [ebp-14h] 00000034: 89 41 04 mov dword ptr [ecx+4],eax 00000037: 8B 45 F0 mov eax,dword ptr [ebp-10h] 0000003A: 89 41 08 mov dword ptr [ecx+8],eax 0000003D: 89 C8 mov eax,ecx 0000003F: C9 leave 00000040: C2 04 00 ret 4 00000043: 90 nop 00000044: 90 nop ...more nops for padding... gcc -O1 _F2: 00000000: 55 push ebp 00000001: 89 E5 mov ebp,esp 00000003: 83 EC 18 sub esp,18h 00000006: 89 5D F8 mov dword ptr [ebp-8],ebx 00000009: 89 75 FC mov dword ptr [ebp-4],esi 0000000C: 8B 45 08 mov eax,dword ptr [ebp+8] 0000000F: 8B 4D 0C mov ecx,dword ptr [ebp+0Ch] 00000012: 8B 5D 10 mov ebx,dword ptr [ebp+10h] 00000015: 8B 75 14 mov esi,dword ptr [ebp+14h] 00000018: 89 CA mov edx,ecx 0000001A: 0F AF D3 imul edx,ebx 0000001D: 0F AF D6 imul edx,esi 00000020: 29 D9 sub ecx,ebx 00000022: 29 F1 sub ecx,esi 00000024: 89 10 mov dword ptr [eax],edx 00000026: C7 40 04 7B 00 00 mov dword ptr [eax+4],7Bh 00 0000002D: 89 48 08 mov dword ptr [eax+8],ecx 00000030: 8B 5D F8 mov ebx,dword ptr [ebp-8] 00000033: 8B 75 FC mov esi,dword ptr [ebp-4] 00000036: 89 EC mov esp,ebp 00000038: 5D pop ebp 00000039: C2 04 00 ret 4 0000003C: 90 nop 0000003D: 90 nop 0000003E: 90 nop 0000003F: 90 nop I didn't investigate all the switches much and simple -O vs. -O1 vs. -O2 vs. -o3all do the same. -O1 -fomit-frame-pointer netted: _F2: 00000000: 83 EC 1C sub esp,1Ch 00000003: 89 5C 24 14 mov dword ptr [esp+14h],ebx 00000007: 89 74 24 18 mov dword ptr [esp+18h],esi 0000000B: 8B 44 24 20 mov eax,dword ptr [esp+20h] 0000000F: 8B 4C 24 24 mov ecx,dword ptr [esp+24h] 00000013: 8B 5C 24 28 mov ebx,dword ptr [esp+28h] 00000017: 8B 74 24 2C mov esi,dword ptr [esp+2Ch] 0000001B: 89 CA mov edx,ecx 0000001D: 0F AF D3 imul edx,ebx 00000020: 0F AF D6 imul edx,esi 00000023: 29 D9 sub ecx,ebx 00000025: 29 F1 sub ecx,esi 00000027: 89 10 mov dword ptr [eax],edx 00000029: C7 40 04 7B 00 00 mov dword ptr [eax+4],7Bh 00 00000030: 89 48 08 mov dword ptr [eax+8],ecx 00000033: 8B 5C 24 14 mov ebx,dword ptr [esp+14h] 00000037: 8B 74 24 18 mov esi,dword ptr [esp+18h] 0000003B: 83 C4 1C add esp,1Ch 0000003E: C2 04 00 ret 4 00000041: 90 nop .. more nops .. Ok, ready, here goes the unoptimized Modula-3.Notice the duplicate copying of the return value and the *doubling* in code size. _T__F2: 00000000: 55 push ebp 00000001: 89 E5 mov ebp,esp 00000003: 57 push edi 00000004: 56 push esi 00000005: 83 EC 30 sub esp,30h 00000008: 8B 55 0C mov edx,dword ptr [ebp+0Ch] 0000000B: 8B 45 10 mov eax,dword ptr [ebp+10h] 0000000E: 0F AF D0 imul edx,eax 00000011: 8B 45 14 mov eax,dword ptr [ebp+14h] 00000014: 0F AF D0 imul edx,eax 00000017: 8B 45 D4 mov eax,dword ptr [ebp-2Ch] 0000001A: 83 E0 00 and eax,0 0000001D: 09 D0 or eax,edx 0000001F: 89 45 D4 mov dword ptr [ebp-2Ch],eax 00000022: 8B 45 D8 mov eax,dword ptr [ebp-28h] 00000025: 83 E0 00 and eax,0 00000028: 83 C8 7B or eax,7Bh 0000002B: 89 45 D8 mov dword ptr [ebp-28h],eax 0000002E: 8B 55 0C mov edx,dword ptr [ebp+0Ch] 00000031: 8B 45 10 mov eax,dword ptr [ebp+10h] 00000034: 29 C2 sub edx,eax 00000036: 8B 45 14 mov eax,dword ptr [ebp+14h] 00000039: 29 C2 sub edx,eax 0000003B: 8B 45 DC mov eax,dword ptr [ebp-24h] 0000003E: 83 E0 00 and eax,0 00000041: 09 D0 or eax,edx 00000043: 89 45 DC mov dword ptr [ebp-24h],eax 00000046: 8B 45 08 mov eax,dword ptr [ebp+8] 00000049: 89 C2 mov edx,eax 0000004B: 8D 45 D4 lea eax,[ebp-2Ch] 0000004E: 8D 7D EC lea edi,[ebp-14h] 00000051: 89 C6 mov esi,eax 00000053: FC cld 00000054: A5 movs dword ptr es:[edi],dword ptr [esi] 00000055: A5 movs dword ptr es:[edi],dword ptr [esi] 00000056: A5 movs dword ptr es:[edi],dword ptr [esi] 00000057: 89 D7 mov edi,edx 00000059: 8D 75 EC lea esi,[ebp-14h] 0000005C: FC cld 0000005D: A5 movs dword ptr es:[edi],dword ptr [esi] 0000005E: A5 movs dword ptr es:[edi],dword ptr [esi] 0000005F: A5 movs dword ptr es:[edi],dword ptr [esi] 00000060: 83 C4 30 add esp,30h 00000063: 5E pop esi 00000064: 5F pop edi 00000065: C9 leave 00000066: C3 ret optimized Modula-3 is better, saves the extra copy, but still not great: _T__F2: 00000000: 55 push ebp 00000001: 89 E5 mov ebp,esp 00000003: 57 push edi 00000004: 56 push esi 00000005: 53 push ebx 00000006: 83 EC 10 sub esp,10h 00000009: 8B 55 0C mov edx,dword ptr [ebp+0Ch] 0000000C: 8B 4D 10 mov ecx,dword ptr [ebp+10h] 0000000F: 8B 5D 14 mov ebx,dword ptr [ebp+14h] 00000012: 89 D0 mov eax,edx 00000014: 0F AF C1 imul eax,ecx 00000017: 0F AF C3 imul eax,ebx 0000001A: 8B 75 E8 mov esi,dword ptr [ebp-18h] 0000001D: 89 45 E8 mov dword ptr [ebp-18h],eax 00000020: 8B 45 EC mov eax,dword ptr [ebp-14h] 00000023: C7 45 EC 7B 00 00 mov dword ptr [ebp-14h],7Bh 00 0000002A: 29 CA sub edx,ecx 0000002C: 29 DA sub edx,ebx Huh what does this next instruction achieve? 0000002E: 8B 45 F0 mov eax,dword ptr [ebp-10h] 00000031: 89 55 F0 mov dword ptr [ebp-10h],edx 00000034: 8B 7D 08 mov edi,dword ptr [ebp+8] 00000037: 8D 75 E8 lea esi,[ebp-18h] 0000003A: FC cld 0000003B: A5 movs dword ptr es:[edi],dword ptr [esi] 0000003C: A5 movs dword ptr es:[edi],dword ptr [esi] 0000003D: A5 movs dword ptr es:[edi],dword ptr [esi] 0000003E: 83 C4 10 add esp,10h 00000041: 5B pop ebx 00000042: 5E pop esi 00000043: 5F pop edi 00000044: C9 leave 00000045: C3 ret and lastly the integrated backend, which runs much faster, and I believe has just one mode,somewhat optimized (but still lacks int64 support): _T__F2: 00000000: 55 push ebp 00000001: 8B EC mov ebp,esp 00000003: 81 EC 18 00 00 00 sub esp,18h 00000009: 53 push ebx 0000000A: 56 push esi 0000000B: 57 push edi 0000000C: 8B 5D 10 mov ebx,dword ptr [ebp+10h] 0000000F: 0F AF 5D 0C imul ebx,dword ptr [ebp+0Ch] 00000013: 0F AF 5D 14 imul ebx,dword ptr [ebp+14h] 00000017: 89 5D F4 mov dword ptr [ebp-0Ch],ebx 0000001A: C7 45 F8 7B 00 00 mov dword ptr [ebp-8],7Bh 00 00000021: 8B 55 0C mov edx,dword ptr [ebp+0Ch] 00000024: 2B 55 10 sub edx,dword ptr [ebp+10h] 00000027: 2B 55 14 sub edx,dword ptr [ebp+14h] 0000002A: 89 55 FC mov dword ptr [ebp-4],edx 0000002D: 8D 75 F4 lea esi,[ebp-0Ch] 00000030: 8B 7D 08 mov edi,dword ptr [ebp+8] 00000033: 8B 4E 00 mov ecx,dword ptr [esi] 00000036: 89 4F 00 mov dword ptr [edi],ecx 00000039: 8B 4E 04 mov ecx,dword ptr [esi+4] 0000003C: 89 4F 04 mov dword ptr [edi+4],ecx 0000003F: 8B 4E 08 mov ecx,dword ptr [esi+8] 00000042: 89 4F 08 mov dword ptr [edi+8],ecx 00000045: 8B C7 mov eax,edi 00000047: 5F pop edi 00000048: 5E pop esi 00000049: 5B pop ebx 0000004A: C9 leave 0000004B: C3 ret I haven't looked at all this in depth, but the doubling in size, the extra copy, that the integrated backend's code is fairly small... - 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 Jan 21 16:22:32 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 21 Jan 2008 15:22:32 +0000 Subject: [M3devel] safety vs. capacity vs. reinvention? Message-ID: I'm constantly noticing fixed sized buffers in the Modula-3 code and reinvention of basic data types and algorithms, such as growable arrays. Something seems off, eh? Here's the latest: -> linking cm3.exec:\\docume~1\\jay\\locals~1\\temp\\cm3\\make-dist\\tmpukymas\\cm3-core-WIN32-NT386GNU-d5.5.1\\pkg\\m3back\\NT386GNU\\m3back.lib c:\\docume~1\\jay\\locals~1\\temp\\cm3\\make-dist\\tmpukymas\\cm3-core-WIN32-NT386GNU-d5.5.1\\pkg\\m3objfile\\NT386GNU\\m3objfile.lib c:\\docume~1\\jay\\locals~1\\temp\\cm3\\make-dist\\tmpukymas\\cm3-core-WIN32-NT386GNU-d5.5.1\\pkg\\m3quake\\NT386GNU\\m3quake.lib c:\\docume~1\\jay\\locals~1\\temp\\cm3\\make-dist\\tmpukymas\\cm3-core-WIN32-NT386GNU-d5.5.1\\pkg\\m3front\\NT386GNU\\m3front.lib c:\\docume~1\\jay\\locals~1\\temp\\cm3\\make-dist\\tmpukymas\\cm3-core-WIN32-NT386GNU-d5.5.1\\pkg\\m3linker\\NT386GNU\\m3link.lib c:\\docume~1\\jay\\locals~1\\temp\\cm3\\make-dist\\tmpukymas\\cm3-core-WIN32-NT386GNU-d5.5.1\\pkg\\m3middle\\NT386GNU\\m3middle.lib c:\\docume~1\\jay\\locals~1\\temp\\cm3\\make-dist\\tmpukymas\\cm3-core-WIN32-NT386GNU-d5.5.1\\pkg\\libm3\\NT386GNU\\m3.lib.sa c:\\docume~1\\jay\\locals~1\\temp\\cm3\\make-dist\\tmpukymas\\cm3-core-WIN32-NT386GNU-d5.5.1\\pkg\\m3core\\NT386GNU\\m3core.lib.sa -lcomctl32 -lwsock32 -lnetapi32 -lgdi32 -luser32 ****** runtime error:*** <*ASSERT*> failed.*** file "..\src\M3ID.m3", line 58*** Stack trace: FP PC Procedure--------- --------- ------------------------------- 0x22f198 0x59e9c3 Add + 0x53 in ..\src\M3ID.m3 0x22f1c8 0x4209cb Txt2ID + 0x14 in ..\src\M3Build.m3 0x22f208 0x478f9f PushText + 0x97 in ..\src\QMachine.m3 0x22f418 0x47c38f DoEscape + 0x341 in ..\src\QMachine.m3 0x22f478 0x476a37 DoCall + 0x568 in ..\src\QMachine.m3 0x22f558 0x475a49 Eval + 0x1845(!) in ..\src\QMachine.m3 0x22f578 0x4764ca CallProc + 0x2b in ..\src\QMachine.m3 0x22f6e8 0x413717 CallProc + 0x156 in ..\src\Builder.m3 0x22f758 0x40e96a BuildProgram + 0x66a in ..\src\Builder.m3 0x22f788 0x402282 BuildPgm + 0x62 in ..\src\Builder.m3......... ......... ... more frames ... PROCEDURE Add (x: TEXT; class: [0..255]): T = VAR t : T; len := Text.Length (x); buf : ARRAY [0..1024] OF CHAR; BEGIN IF len > NUMBER(buf) THEN IO.Put(x); END; <*ASSERT len <= NUMBER (buf) *> Text.SetChars (buf, x); t := FromStr (buf, len); IF (class # 0) THEN classes [t] := class; END; IF (ids[t].text = NIL) THEN ids[t].text := x; END; RETURN t; END Add;The code is escaping imported .libs in order to write them into a response file, since gcc needs the doubled slashes.. I'm using a response file BECAUSE I have a long string.. - 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 Jan 21 16:54:10 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 21 Jan 2008 10:54:10 -0500 Subject: [M3devel] next problem (NT386GNU) In-Reply-To: References: Message-ID: <6E1E4409-F3D9-4982-B179-2D4C9648FDD0@cs.purdue.edu> Surely, when using the gcc-based backend then we should make the backend handle it. The front end handling it is only need for the integrated x86 backend. On Jan 21, 2008, at 2:43 AM, Jay wrote: > I haven't tested a fix but I see the problem. > > This function returns a struct. > There are two struct returning calling conventions. > In one, the backend handles it. Which includes the backend knowing > there is a return value and its type (or at least its size?). > In the other, the front end handles it. In this case, the front end > generates passing an extra pointer parameter to the function, and > the function's return type is void. > > The NT calling conventions, all of them, are marked as front end > handling it. I assume that is correct, could check. > Everything else is marked as back end handling. > > Now then, somewhere along the line, gcc figures out that the return > value isn't used here. > The point of the function call is to see if it generates an exception. > > Gcc removes the function because its return value isn't used, and, > well, somehow it doesn't know about the exceptions here. I'll have > to see how "raise" is implemented. I think it's by a call to a > function that gets the jmpbuf from a thread local and calls > longjmp. (Did I mention it is very inefficient?) > > There are few possible fixes, but nothing completely satisfactory > yet in mind. > > One is have parse.c mark all function calls as having side affects. > This is easy, but overly pessimistic. > Another is for the front end to mark struct returning functions as > having side affects. Better, but still overly pessimistic. > Another is for the front end to mark any function that can raise as > having side affects. Getting better still. I don't know how to do > that but I'll look. This is still a bit overly pessimistic, since > what you really want to know is, not the function's side affects, > but whether or not it raised. If the function is inlined, the side > affects could be optimized away, or if there are enough callers who > don't care about the side affects to warrant an optimization, and > depending on the cost of computing the side affects, another > instance of the function could be made that only raises or not, but > no side affects otherwise. This is "advanced" optimization the sort > of which tends never to be implemented. > > I think the best option is anything that can raise is marked as > having side affects. > I'll see if I can figure that out. > > You can figure this out by looking at m3cgcat -binary < M3File.mc > > 1.txt on PPC_DARWIN and NT386GNU and comparing. > > Maybe marking all or nearly functions as having side effects isn't > so bad. > Or at least anything returning a struct. That gets parity with > other platforms, even if it is a bit pessimistic. > I think I'll do that, and ignore figuring out if raise is called > and using that as a filter. > The parity angle is good. > > The good news for all you Unix lovers :) is this bug is relatively > portable to Cygwin. > True, it is specific to NT386GNU having multiple "calling > conventions", which no other platform has. > Which again, jokingly, strikes at the question -- What is Posix? > What do you want from Cygwin? > One thing Cygwin does NOT give you is just one calling convention, > alas, this calling convention business stinks. It's not even an NT > thing, only an NT386 thing. All the other NT platforms had/have > only one calling convention. > > You can't get far on NT386 without needing to support two calling > conventions. > The "OS" uses mostly __stdcall -- callee pops -- smaller, faster. > But anything that is varargs, such as printf -- pretty much must > use caller pops -- __cdecl. > As well, __cdecl is the default, so prevalent, and used in most C > runtime functions. > There is also __fastcall that uses like up to two registers for > parameters. > > I have seen a platform in which printf did the pop, and it depended > on the number/size of parameters matching the format string. On > most platforms, printf("", 1, 2, 3, 4) just does nothing, but on > that platform, it'd unbalance the stack and crash. > > - Jay > > From: jayk123 at hotmail.com > To: hosking at cs.purdue.edu > CC: m3devel at elegosoft.com > Subject: next problem (NT386GNU) > Date: Mon, 21 Jan 2008 05:47:28 +0000 > > M3File.m3 > > PROCEDURE IsReadable (path: TEXT): BOOLEAN = > (* We don't really check for readablitiy, just for existence *) > BEGIN > TRY > EVAL FS.Status (path); line 82 > RETURN TRUE; > EXCEPT OSError.E => > RETURN FALSE; > END; > END IsReadable; > > -----LINE 82 ----- > start_call_direct p.25 0 Struct > load_address v.25 0 > pop_param Addr > load v.26 0 Addr Addr > pop_param Addr > call_direct p.25 Struct > pop Struct > > > > I'm guessing you only see an import for the first call on purpose, > but I will compare with PPC_DARWIN: > > -----LINE 46 ----- > import_procedure FS__Status 2 Struct 0 p.25 > declare_indirect 2078421550 -2078421551 > declare_param _return 4 4 Addr 2078421550 F F 50 v.62 > declare_param p 4 4 Addr 1358456180 F F 50 v.63 > start_call_direct p.25 0 Struct > load_address v.13 0 > pop_param Addr > load v.14 0 Addr Addr > pop_param Addr > call_direct p.25 Struct > pop Struct > > > .globl _M3File__IsReadable > .def _M3File__IsReadable; .scl 2; .type 32; .endef > _M3File__IsReadable: > .stabn 68,0,178,LM93-_M3File__IsReadable > LM93: > pushl %ebp > movl %esp, %ebp > pushl %edi > pushl %esi > pushl %ebx > subl $300, %esp > LBB15: > .stabn 68,0,181,LM94-_M3File__IsReadable > LM94: > L157: > movl -280(%ebp), %eax > andl $0, %eax > orl $_L_1, %eax > movl %eax, -280(%ebp) > movl -284(%ebp), %eax > andl $0, %eax > movl %eax, -284(%ebp) > subl $12, %esp > leal -288(%ebp), %eax > pushl %eax > call _RTHooks__PushEFrame > addl $16, %esp > leal -288(%ebp), %eax > addl $48, %eax > subl $12, %esp > pushl %eax > call __setjmp > addl $16, %esp > testb %al, %al > jne L158 > .stabn 68,0,183,LM95-_M3File__IsReadable > LM95: > movl -288(%ebp), %eax > subl $12, %esp > pushl %eax > call _RTHooks__PopEFrame > addl $16, %esp > movl $1, -304(%ebp) > jmp L159 > L158: > .stabn 68,0,185,LM96-_M3File__IsReadable > LM96: > movl $0, -304(%ebp) > L159: > LBE15: > movl -304(%ebp), %eax > leal -12(%ebp), %esp > popl %ebx > popl %esi > popl %edi > leave > ret > > > M3File.IsReadable's call to FS.Status is omitted, all files are > readable, even if they are not openable, therefore it "finds" > cm3.cfg in the current directory and then fails to open it.. > > later.. > ..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! Learn more. From hosking at cs.purdue.edu Mon Jan 21 17:01:52 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 21 Jan 2008 11:01:52 -0500 Subject: [M3devel] code quality.. In-Reply-To: References: Message-ID: <241EF32F-F814-4EB0-88A8-B3E413D1F4BE@cs.purdue.edu> Is this having the front-end handle return of structs or the backend? On Jan 21, 2008, at 9:50 AM, Jay wrote: > Unoptimized code quality is really bad, > even compared to unoptimized C, even compared > to gcc, and optimized code quality isn't great. > > I have this made up C code. I was verifying > the struct return calling convention. > > typedef struct { > unsigned a; > unsigned b; > unsigned c; > } d; > > d F2(unsigned a, unsigned b, unsigned c) > { > d e; > e.a = a * b * c; > e.b = 123; > e.c = a - b - c; > return e; > } > > and then the equivalent Modula-3: > > INTERFACE T; > > TYPE T1 = RECORD > a,b,c : INTEGER > END; > > PROCEDURE F2(a,b,c : INTEGER) : T1; > > END T. > > MODULE T; > > PROCEDURE F2(a,b,c : INTEGER) : T1 = > VAR > e : T1; > BEGIN > e.a := (a * b * c); > e.b := 123; > e.c := (a - b - c); > RETURN e; > END F2; > > BEGIN > END T. > > Unoptimized Visual C++ 8.0: > > _F2: > 00000000: 55 push ebp > 00000001: 8B EC mov ebp,esp > 00000003: 83 EC 0C sub esp,0Ch > 00000006: 8B 45 0C mov eax,dword ptr [ebp+0Ch] > 00000009: 0F AF 45 10 imul eax,dword ptr [ebp+10h] > 0000000D: 0F AF 45 14 imul eax,dword ptr [ebp+14h] > 00000011: 89 45 F4 mov dword ptr [ebp-0Ch],eax > 00000014: C7 45 F8 7B 00 00 mov dword ptr [ebp-8],7Bh > 00 > 0000001B: 8B 4D 0C mov ecx,dword ptr [ebp+0Ch] > 0000001E: 2B 4D 10 sub ecx,dword ptr [ebp+10h] > 00000021: 2B 4D 14 sub ecx,dword ptr [ebp+14h] > 00000024: 89 4D FC mov dword ptr [ebp-4],ecx > 00000027: 8B 55 08 mov edx,dword ptr [ebp+8] > 0000002A: 8B 45 F4 mov eax,dword ptr [ebp-0Ch] > 0000002D: 89 02 mov dword ptr [edx],eax > 0000002F: 8B 4D F8 mov ecx,dword ptr [ebp-8] > 00000032: 89 4A 04 mov dword ptr [edx+4],ecx > 00000035: 8B 45 FC mov eax,dword ptr [ebp-4] > 00000038: 89 42 08 mov dword ptr [edx+8],eax > 0000003B: 8B 45 08 mov eax,dword ptr [ebp+8] > 0000003E: 8B E5 mov esp,ebp > 00000040: 5D pop ebp > 00000041: C3 ret > > Visual C++ 8.0 with /O1 > > It writes the results right into the output. > _F2: > 00000000: 55 push ebp > 00000001: 8B EC mov ebp,esp > 00000003: 8B 4D 0C mov ecx,dword ptr [ebp+0Ch] > 00000006: 8B 45 08 mov eax,dword ptr [ebp+8] > 00000009: 8B D1 mov edx,ecx > 0000000B: 0F AF 55 10 imul edx,dword ptr [ebp+10h] > 0000000F: 0F AF 55 14 imul edx,dword ptr [ebp+14h] > 00000013: 2B 4D 10 sub ecx,dword ptr [ebp+10h] > 00000016: 89 10 mov dword ptr [eax],edx > 00000018: 2B 4D 14 sub ecx,dword ptr [ebp+14h] > 0000001B: C7 40 04 7B 00 00 mov dword ptr [eax+4],7Bh > 00 > 00000022: 89 48 08 mov dword ptr [eax+8],ecx > 00000025: 5D pop ebp > 00000026: C3 ret > > with /O2 > > _F2: > 00000000: 8B 4C 24 08 mov ecx,dword ptr [esp+8] > 00000004: 8B 54 24 0C mov edx,dword ptr [esp+0Ch] > 00000008: 8B 44 24 04 mov eax,dword ptr [esp+4] > 0000000C: 56 push esi > 0000000D: 8B 74 24 14 mov esi,dword ptr [esp+14h] > 00000011: 57 push edi > 00000012: 8B F9 mov edi,ecx > 00000014: 0F AF FA imul edi,edx > 00000017: 0F AF FE imul edi,esi > 0000001A: 2B CA sub ecx,edx > 0000001C: 89 38 mov dword ptr [eax],edi > 0000001E: 2B CE sub ecx,esi > 00000020: 5F pop edi > 00000021: C7 40 04 7B 00 00 mov dword ptr [eax+4],7Bh > 00 > 00000028: 89 48 08 mov dword ptr [eax+8],ecx > 0000002B: 5E pop esi > 0000002C: C3 ret > > gcc 3.4.5 unoptimized > > _F2: > 00000000: 55 push ebp > 00000001: 89 E5 mov ebp,esp > 00000003: 83 EC 18 sub esp,18h > 00000006: 8B 4D 08 mov ecx,dword ptr [ebp+8] > 00000009: 8B 45 0C mov eax,dword ptr [ebp+0Ch] > 0000000C: 0F AF 45 10 imul eax,dword ptr [ebp+10h] > 00000010: 0F AF 45 14 imul eax,dword ptr [ebp+14h] > 00000014: 89 45 E8 mov dword ptr [ebp-18h],eax > 00000017: C7 45 EC 7B 00 00 mov dword ptr [ebp-14h],7Bh > 00 > 0000001E: 8B 55 10 mov edx,dword ptr [ebp+10h] > 00000021: 8B 45 0C mov eax,dword ptr [ebp+0Ch] > 00000024: 29 D0 sub eax,edx > 00000026: 2B 45 14 sub eax,dword ptr [ebp+14h] > 00000029: 89 45 F0 mov dword ptr [ebp-10h],eax > 0000002C: 8B 45 E8 mov eax,dword ptr [ebp-18h] > 0000002F: 89 01 mov dword ptr [ecx],eax > 00000031: 8B 45 EC mov eax,dword ptr [ebp-14h] > 00000034: 89 41 04 mov dword ptr [ecx+4],eax > 00000037: 8B 45 F0 mov eax,dword ptr [ebp-10h] > 0000003A: 89 41 08 mov dword ptr [ecx+8],eax > 0000003D: 89 C8 mov eax,ecx > 0000003F: C9 leave > 00000040: C2 04 00 ret 4 > 00000043: 90 nop > 00000044: 90 nop > ...more nops for padding... > > gcc -O1 > > _F2: > 00000000: 55 push ebp > 00000001: 89 E5 mov ebp,esp > 00000003: 83 EC 18 sub esp,18h > 00000006: 89 5D F8 mov dword ptr [ebp-8],ebx > 00000009: 89 75 FC mov dword ptr [ebp-4],esi > 0000000C: 8B 45 08 mov eax,dword ptr [ebp+8] > 0000000F: 8B 4D 0C mov ecx,dword ptr [ebp+0Ch] > 00000012: 8B 5D 10 mov ebx,dword ptr [ebp+10h] > 00000015: 8B 75 14 mov esi,dword ptr [ebp+14h] > 00000018: 89 CA mov edx,ecx > 0000001A: 0F AF D3 imul edx,ebx > 0000001D: 0F AF D6 imul edx,esi > 00000020: 29 D9 sub ecx,ebx > 00000022: 29 F1 sub ecx,esi > 00000024: 89 10 mov dword ptr [eax],edx > 00000026: C7 40 04 7B 00 00 mov dword ptr [eax+4],7Bh > 00 > 0000002D: 89 48 08 mov dword ptr [eax+8],ecx > 00000030: 8B 5D F8 mov ebx,dword ptr [ebp-8] > 00000033: 8B 75 FC mov esi,dword ptr [ebp-4] > 00000036: 89 EC mov esp,ebp > 00000038: 5D pop ebp > 00000039: C2 04 00 ret 4 > 0000003C: 90 nop > 0000003D: 90 nop > 0000003E: 90 nop > 0000003F: 90 nop > > I didn't investigate all the switches much and simple -O vs. -O1 > vs. -O2 vs. -o3 > all do the same. > > -O1 -fomit-frame-pointer netted: > > _F2: > 00000000: 83 EC 1C sub esp,1Ch > 00000003: 89 5C 24 14 mov dword ptr [esp+14h],ebx > 00000007: 89 74 24 18 mov dword ptr [esp+18h],esi > 0000000B: 8B 44 24 20 mov eax,dword ptr [esp+20h] > 0000000F: 8B 4C 24 24 mov ecx,dword ptr [esp+24h] > 00000013: 8B 5C 24 28 mov ebx,dword ptr [esp+28h] > 00000017: 8B 74 24 2C mov esi,dword ptr [esp+2Ch] > 0000001B: 89 CA mov edx,ecx > 0000001D: 0F AF D3 imul edx,ebx > 00000020: 0F AF D6 imul edx,esi > 00000023: 29 D9 sub ecx,ebx > 00000025: 29 F1 sub ecx,esi > 00000027: 89 10 mov dword ptr [eax],edx > 00000029: C7 40 04 7B 00 00 mov dword ptr [eax+4],7Bh > 00 > 00000030: 89 48 08 mov dword ptr [eax+8],ecx > 00000033: 8B 5C 24 14 mov ebx,dword ptr [esp+14h] > 00000037: 8B 74 24 18 mov esi,dword ptr [esp+18h] > 0000003B: 83 C4 1C add esp,1Ch > 0000003E: C2 04 00 ret 4 > 00000041: 90 nop > .. more nops .. > > Ok, ready, here goes the unoptimized Modula-3. > Notice the duplicate copying of the return value and the *doubling* > in code size. > > _T__F2: > 00000000: 55 push ebp > 00000001: 89 E5 mov ebp,esp > 00000003: 57 push edi > 00000004: 56 push esi > 00000005: 83 EC 30 sub esp,30h > 00000008: 8B 55 0C mov edx,dword ptr [ebp+0Ch] > 0000000B: 8B 45 10 mov eax,dword ptr [ebp+10h] > 0000000E: 0F AF D0 imul edx,eax > 00000011: 8B 45 14 mov eax,dword ptr [ebp+14h] > 00000014: 0F AF D0 imul edx,eax > 00000017: 8B 45 D4 mov eax,dword ptr [ebp-2Ch] > 0000001A: 83 E0 00 and eax,0 > 0000001D: 09 D0 or eax,edx > 0000001F: 89 45 D4 mov dword ptr [ebp-2Ch],eax > 00000022: 8B 45 D8 mov eax,dword ptr [ebp-28h] > 00000025: 83 E0 00 and eax,0 > 00000028: 83 C8 7B or eax,7Bh > 0000002B: 89 45 D8 mov dword ptr [ebp-28h],eax > 0000002E: 8B 55 0C mov edx,dword ptr [ebp+0Ch] > 00000031: 8B 45 10 mov eax,dword ptr [ebp+10h] > 00000034: 29 C2 sub edx,eax > 00000036: 8B 45 14 mov eax,dword ptr [ebp+14h] > 00000039: 29 C2 sub edx,eax > 0000003B: 8B 45 DC mov eax,dword ptr [ebp-24h] > 0000003E: 83 E0 00 and eax,0 > 00000041: 09 D0 or eax,edx > 00000043: 89 45 DC mov dword ptr [ebp-24h],eax > 00000046: 8B 45 08 mov eax,dword ptr [ebp+8] > 00000049: 89 C2 mov edx,eax > 0000004B: 8D 45 D4 lea eax,[ebp-2Ch] > 0000004E: 8D 7D EC lea edi,[ebp-14h] > 00000051: 89 C6 mov esi,eax > 00000053: FC cld > 00000054: A5 movs dword ptr es:[edi],dword > ptr [esi] > 00000055: A5 movs dword ptr es:[edi],dword > ptr [esi] > 00000056: A5 movs dword ptr es:[edi],dword > ptr [esi] > 00000057: 89 D7 mov edi,edx > 00000059: 8D 75 EC lea esi,[ebp-14h] > 0000005C: FC cld > 0000005D: A5 movs dword ptr es:[edi],dword > ptr [esi] > 0000005E: A5 movs dword ptr es:[edi],dword > ptr [esi] > 0000005F: A5 movs dword ptr es:[edi],dword > ptr [esi] > 00000060: 83 C4 30 add esp,30h > 00000063: 5E pop esi > 00000064: 5F pop edi > 00000065: C9 leave > 00000066: C3 ret > > optimized Modula-3 is better, saves the extra copy, but still not > great: > > _T__F2: > 00000000: 55 push ebp > 00000001: 89 E5 mov ebp,esp > 00000003: 57 push edi > 00000004: 56 push esi > 00000005: 53 push ebx > 00000006: 83 EC 10 sub esp,10h > 00000009: 8B 55 0C mov edx,dword ptr [ebp+0Ch] > 0000000C: 8B 4D 10 mov ecx,dword ptr [ebp+10h] > 0000000F: 8B 5D 14 mov ebx,dword ptr [ebp+14h] > 00000012: 89 D0 mov eax,edx > 00000014: 0F AF C1 imul eax,ecx > 00000017: 0F AF C3 imul eax,ebx > 0000001A: 8B 75 E8 mov esi,dword ptr [ebp-18h] > 0000001D: 89 45 E8 mov dword ptr [ebp-18h],eax > 00000020: 8B 45 EC mov eax,dword ptr [ebp-14h] > 00000023: C7 45 EC 7B 00 00 mov dword ptr [ebp-14h],7Bh > 00 > 0000002A: 29 CA sub edx,ecx > 0000002C: 29 DA sub edx,ebx > > Huh what does this next instruction achieve? > 0000002E: 8B 45 F0 mov eax,dword ptr [ebp-10h] > 00000031: 89 55 F0 mov dword ptr [ebp-10h],edx > 00000034: 8B 7D 08 mov edi,dword ptr [ebp+8] > 00000037: 8D 75 E8 lea esi,[ebp-18h] > 0000003A: FC cld > 0000003B: A5 movs dword ptr es:[edi],dword > ptr [esi] > 0000003C: A5 movs dword ptr es:[edi],dword > ptr [esi] > 0000003D: A5 movs dword ptr es:[edi],dword > ptr [esi] > 0000003E: 83 C4 10 add esp,10h > 00000041: 5B pop ebx > 00000042: 5E pop esi > 00000043: 5F pop edi > 00000044: C9 leave > 00000045: C3 ret > > and lastly the integrated backend, which runs much faster, and I > believe has just one mode, > somewhat optimized (but still lacks int64 support): > > _T__F2: > 00000000: 55 push ebp > 00000001: 8B EC mov ebp,esp > 00000003: 81 EC 18 00 00 00 sub esp,18h > 00000009: 53 push ebx > 0000000A: 56 push esi > 0000000B: 57 push edi > 0000000C: 8B 5D 10 mov ebx,dword ptr [ebp+10h] > 0000000F: 0F AF 5D 0C imul ebx,dword ptr [ebp+0Ch] > 00000013: 0F AF 5D 14 imul ebx,dword ptr [ebp+14h] > 00000017: 89 5D F4 mov dword ptr [ebp-0Ch],ebx > 0000001A: C7 45 F8 7B 00 00 mov dword ptr [ebp-8],7Bh > 00 > 00000021: 8B 55 0C mov edx,dword ptr [ebp+0Ch] > 00000024: 2B 55 10 sub edx,dword ptr [ebp+10h] > 00000027: 2B 55 14 sub edx,dword ptr [ebp+14h] > 0000002A: 89 55 FC mov dword ptr [ebp-4],edx > 0000002D: 8D 75 F4 lea esi,[ebp-0Ch] > 00000030: 8B 7D 08 mov edi,dword ptr [ebp+8] > 00000033: 8B 4E 00 mov ecx,dword ptr [esi] > 00000036: 89 4F 00 mov dword ptr [edi],ecx > 00000039: 8B 4E 04 mov ecx,dword ptr [esi+4] > 0000003C: 89 4F 04 mov dword ptr [edi+4],ecx > 0000003F: 8B 4E 08 mov ecx,dword ptr [esi+8] > 00000042: 89 4F 08 mov dword ptr [edi+8],ecx > 00000045: 8B C7 mov eax,edi > 00000047: 5F pop edi > 00000048: 5E pop esi > 00000049: 5B pop ebx > 0000004A: C9 leave > 0000004B: C3 ret > > I haven't looked at all this in depth, but the doubling in size, > the extra copy, > that the integrated backend's code is fairly small... > > - Jay > > Shed those extra pounds with MSN and The Biggest Loser! Learn more. From hosking at cs.purdue.edu Mon Jan 21 16:59:35 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 21 Jan 2008 10:59:35 -0500 Subject: [M3devel] gcc/eh/setjmp In-Reply-To: References: Message-ID: I think gcc was forced not to act on it by use of LABEL_PRESERVE_P and FORCED_LABEL as well as making the function containing the TRY non-inlinable, plus lots of other goop to let the flow analyser know that funky stuff was going on at labels for TRY scopes. Take a look at the lines of parse.c that deal with "set_label" when "barrier=TRUE". On Jan 21, 2008, at 5:50 AM, Jay wrote: > Folks, try adding -Wunreachable-code to your m3back options and > tell me if you don't get loads of warnings. > for stuff like: > > TRY > return Foo(); > ELSE > return FALSE; > > I get them on NT386GNU and PPC_DARWIN. > > Functions with TRY need, in gcc parlance: > calls_setjmp > > and the exception/finally blocks need: > has_nonlocal_label > > and functions with RAISE might need: > has_nonlocal_goto > > Luckily, gcc doesn't seem to act on what it figure out. > > - Jay > > > > > > Helping your favorite cause is as easy as instant messaging. You > IM, we give. Learn more. From jayk123 at hotmail.com Mon Jan 21 17:06:37 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 21 Jan 2008 16:06:37 +0000 Subject: [M3devel] gcc/eh/setjmp In-Reply-To: References: Message-ID: Any chance of giving gcc enough or the right information so that -Wunreachable-code can be used without hitting a bunch of false positives? It's not being dumb, not that sort of false positive. It reports every except block and anything after a try { return } except { } as unreachable. - Jay > CC: m3devel at elegosoft.com> From: hosking at cs.purdue.edu> Subject: Re: [M3devel] gcc/eh/setjmp> Date: Mon, 21 Jan 2008 10:59:35 -0500> To: jayk123 at hotmail.com> > I think gcc was forced not to act on it by use of LABEL_PRESERVE_P > and FORCED_LABEL as well as making the function containing the TRY > non-inlinable, plus lots of other goop to let the flow analyser know > that funky stuff was going on at labels for TRY scopes. Take a look > at the lines of parse.c that deal with "set_label" when "barrier=TRUE".> > On Jan 21, 2008, at 5:50 AM, Jay wrote:> > > Folks, try adding -Wunreachable-code to your m3back options and > > tell me if you don't get loads of warnings.> > for stuff like:> >> > TRY> > return Foo();> > ELSE> > return FALSE;> >> > I get them on NT386GNU and PPC_DARWIN.> >> > Functions with TRY need, in gcc parlance:> > calls_setjmp> >> > and the exception/finally blocks need:> > has_nonlocal_label> >> > and functions with RAISE might need:> > has_nonlocal_goto> >> > Luckily, gcc doesn't seem to act on what it figure out.> >> > - Jay> >> >> >> >> >> > Helping your favorite cause is as easy as instant messaging. You > > IM, we give. 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 jayk123 at hotmail.com Mon Jan 21 17:04:45 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 21 Jan 2008 16:04:45 +0000 Subject: [M3devel] code quality.. In-Reply-To: <241EF32F-F814-4EB0-88A8-B3E413D1F4BE@cs.purdue.edu> References: <241EF32F-F814-4EB0-88A8-B3E413D1F4BE@cs.purdue.edu> Message-ID: backend. I think it is correct, if inefficient. - Jay > CC: m3devel at elegosoft.com> From: hosking at cs.purdue.edu> Subject: Re: [M3devel] code quality..> Date: Mon, 21 Jan 2008 11:01:52 -0500> To: jayk123 at hotmail.com> > Is this having the front-end handle return of structs or the backend?> > On Jan 21, 2008, at 9:50 AM, Jay wrote:> > > Unoptimized code quality is really bad,> > even compared to unoptimized C, even compared> > to gcc, and optimized code quality isn't great.> >> > I have this made up C code. I was verifying> > the struct return calling convention.> >> > typedef struct {> > unsigned a;> > unsigned b;> > unsigned c;> > } d;> >> > d F2(unsigned a, unsigned b, unsigned c)> > {> > d e;> > e.a = a * b * c;> > e.b = 123;> > e.c = a - b - c;> > return e;> > }> >> > and then the equivalent Modula-3:> >> > INTERFACE T;> >> > TYPE T1 = RECORD> > a,b,c : INTEGER> > END;> >> > PROCEDURE F2(a,b,c : INTEGER) : T1;> >> > END T.> >> > MODULE T;> >> > PROCEDURE F2(a,b,c : INTEGER) : T1 => > VAR> > e : T1;> > BEGIN> > e.a := (a * b * c);> > e.b := 123;> > e.c := (a - b - c);> > RETURN e;> > END F2;> >> > BEGIN> > END T.> >> > Unoptimized Visual C++ 8.0:> >> > _F2:> > 00000000: 55 push ebp> > 00000001: 8B EC mov ebp,esp> > 00000003: 83 EC 0C sub esp,0Ch> > 00000006: 8B 45 0C mov eax,dword ptr [ebp+0Ch]> > 00000009: 0F AF 45 10 imul eax,dword ptr [ebp+10h]> > 0000000D: 0F AF 45 14 imul eax,dword ptr [ebp+14h]> > 00000011: 89 45 F4 mov dword ptr [ebp-0Ch],eax> > 00000014: C7 45 F8 7B 00 00 mov dword ptr [ebp-8],7Bh> > 00> > 0000001B: 8B 4D 0C mov ecx,dword ptr [ebp+0Ch]> > 0000001E: 2B 4D 10 sub ecx,dword ptr [ebp+10h]> > 00000021: 2B 4D 14 sub ecx,dword ptr [ebp+14h]> > 00000024: 89 4D FC mov dword ptr [ebp-4],ecx> > 00000027: 8B 55 08 mov edx,dword ptr [ebp+8]> > 0000002A: 8B 45 F4 mov eax,dword ptr [ebp-0Ch]> > 0000002D: 89 02 mov dword ptr [edx],eax> > 0000002F: 8B 4D F8 mov ecx,dword ptr [ebp-8]> > 00000032: 89 4A 04 mov dword ptr [edx+4],ecx> > 00000035: 8B 45 FC mov eax,dword ptr [ebp-4]> > 00000038: 89 42 08 mov dword ptr [edx+8],eax> > 0000003B: 8B 45 08 mov eax,dword ptr [ebp+8]> > 0000003E: 8B E5 mov esp,ebp> > 00000040: 5D pop ebp> > 00000041: C3 ret> >> > Visual C++ 8.0 with /O1> >> > It writes the results right into the output.> > _F2:> > 00000000: 55 push ebp> > 00000001: 8B EC mov ebp,esp> > 00000003: 8B 4D 0C mov ecx,dword ptr [ebp+0Ch]> > 00000006: 8B 45 08 mov eax,dword ptr [ebp+8]> > 00000009: 8B D1 mov edx,ecx> > 0000000B: 0F AF 55 10 imul edx,dword ptr [ebp+10h]> > 0000000F: 0F AF 55 14 imul edx,dword ptr [ebp+14h]> > 00000013: 2B 4D 10 sub ecx,dword ptr [ebp+10h]> > 00000016: 89 10 mov dword ptr [eax],edx> > 00000018: 2B 4D 14 sub ecx,dword ptr [ebp+14h]> > 0000001B: C7 40 04 7B 00 00 mov dword ptr [eax+4],7Bh> > 00> > 00000022: 89 48 08 mov dword ptr [eax+8],ecx> > 00000025: 5D pop ebp> > 00000026: C3 ret> >> > with /O2> >> > _F2:> > 00000000: 8B 4C 24 08 mov ecx,dword ptr [esp+8]> > 00000004: 8B 54 24 0C mov edx,dword ptr [esp+0Ch]> > 00000008: 8B 44 24 04 mov eax,dword ptr [esp+4]> > 0000000C: 56 push esi> > 0000000D: 8B 74 24 14 mov esi,dword ptr [esp+14h]> > 00000011: 57 push edi> > 00000012: 8B F9 mov edi,ecx> > 00000014: 0F AF FA imul edi,edx> > 00000017: 0F AF FE imul edi,esi> > 0000001A: 2B CA sub ecx,edx> > 0000001C: 89 38 mov dword ptr [eax],edi> > 0000001E: 2B CE sub ecx,esi> > 00000020: 5F pop edi> > 00000021: C7 40 04 7B 00 00 mov dword ptr [eax+4],7Bh> > 00> > 00000028: 89 48 08 mov dword ptr [eax+8],ecx> > 0000002B: 5E pop esi> > 0000002C: C3 ret> >> > gcc 3.4.5 unoptimized> >> > _F2:> > 00000000: 55 push ebp> > 00000001: 89 E5 mov ebp,esp> > 00000003: 83 EC 18 sub esp,18h> > 00000006: 8B 4D 08 mov ecx,dword ptr [ebp+8]> > 00000009: 8B 45 0C mov eax,dword ptr [ebp+0Ch]> > 0000000C: 0F AF 45 10 imul eax,dword ptr [ebp+10h]> > 00000010: 0F AF 45 14 imul eax,dword ptr [ebp+14h]> > 00000014: 89 45 E8 mov dword ptr [ebp-18h],eax> > 00000017: C7 45 EC 7B 00 00 mov dword ptr [ebp-14h],7Bh> > 00> > 0000001E: 8B 55 10 mov edx,dword ptr [ebp+10h]> > 00000021: 8B 45 0C mov eax,dword ptr [ebp+0Ch]> > 00000024: 29 D0 sub eax,edx> > 00000026: 2B 45 14 sub eax,dword ptr [ebp+14h]> > 00000029: 89 45 F0 mov dword ptr [ebp-10h],eax> > 0000002C: 8B 45 E8 mov eax,dword ptr [ebp-18h]> > 0000002F: 89 01 mov dword ptr [ecx],eax> > 00000031: 8B 45 EC mov eax,dword ptr [ebp-14h]> > 00000034: 89 41 04 mov dword ptr [ecx+4],eax> > 00000037: 8B 45 F0 mov eax,dword ptr [ebp-10h]> > 0000003A: 89 41 08 mov dword ptr [ecx+8],eax> > 0000003D: 89 C8 mov eax,ecx> > 0000003F: C9 leave> > 00000040: C2 04 00 ret 4> > 00000043: 90 nop> > 00000044: 90 nop> > ...more nops for padding...> >> > gcc -O1> >> > _F2:> > 00000000: 55 push ebp> > 00000001: 89 E5 mov ebp,esp> > 00000003: 83 EC 18 sub esp,18h> > 00000006: 89 5D F8 mov dword ptr [ebp-8],ebx> > 00000009: 89 75 FC mov dword ptr [ebp-4],esi> > 0000000C: 8B 45 08 mov eax,dword ptr [ebp+8]> > 0000000F: 8B 4D 0C mov ecx,dword ptr [ebp+0Ch]> > 00000012: 8B 5D 10 mov ebx,dword ptr [ebp+10h]> > 00000015: 8B 75 14 mov esi,dword ptr [ebp+14h]> > 00000018: 89 CA mov edx,ecx> > 0000001A: 0F AF D3 imul edx,ebx> > 0000001D: 0F AF D6 imul edx,esi> > 00000020: 29 D9 sub ecx,ebx> > 00000022: 29 F1 sub ecx,esi> > 00000024: 89 10 mov dword ptr [eax],edx> > 00000026: C7 40 04 7B 00 00 mov dword ptr [eax+4],7Bh> > 00> > 0000002D: 89 48 08 mov dword ptr [eax+8],ecx> > 00000030: 8B 5D F8 mov ebx,dword ptr [ebp-8]> > 00000033: 8B 75 FC mov esi,dword ptr [ebp-4]> > 00000036: 89 EC mov esp,ebp> > 00000038: 5D pop ebp> > 00000039: C2 04 00 ret 4> > 0000003C: 90 nop> > 0000003D: 90 nop> > 0000003E: 90 nop> > 0000003F: 90 nop> >> > I didn't investigate all the switches much and simple -O vs. -O1 > > vs. -O2 vs. -o3> > all do the same.> >> > -O1 -fomit-frame-pointer netted:> >> > _F2:> > 00000000: 83 EC 1C sub esp,1Ch> > 00000003: 89 5C 24 14 mov dword ptr [esp+14h],ebx> > 00000007: 89 74 24 18 mov dword ptr [esp+18h],esi> > 0000000B: 8B 44 24 20 mov eax,dword ptr [esp+20h]> > 0000000F: 8B 4C 24 24 mov ecx,dword ptr [esp+24h]> > 00000013: 8B 5C 24 28 mov ebx,dword ptr [esp+28h]> > 00000017: 8B 74 24 2C mov esi,dword ptr [esp+2Ch]> > 0000001B: 89 CA mov edx,ecx> > 0000001D: 0F AF D3 imul edx,ebx> > 00000020: 0F AF D6 imul edx,esi> > 00000023: 29 D9 sub ecx,ebx> > 00000025: 29 F1 sub ecx,esi> > 00000027: 89 10 mov dword ptr [eax],edx> > 00000029: C7 40 04 7B 00 00 mov dword ptr [eax+4],7Bh> > 00> > 00000030: 89 48 08 mov dword ptr [eax+8],ecx> > 00000033: 8B 5C 24 14 mov ebx,dword ptr [esp+14h]> > 00000037: 8B 74 24 18 mov esi,dword ptr [esp+18h]> > 0000003B: 83 C4 1C add esp,1Ch> > 0000003E: C2 04 00 ret 4> > 00000041: 90 nop> > .. more nops ..> >> > Ok, ready, here goes the unoptimized Modula-3.> > Notice the duplicate copying of the return value and the *doubling* > > in code size.> >> > _T__F2:> > 00000000: 55 push ebp> > 00000001: 89 E5 mov ebp,esp> > 00000003: 57 push edi> > 00000004: 56 push esi> > 00000005: 83 EC 30 sub esp,30h> > 00000008: 8B 55 0C mov edx,dword ptr [ebp+0Ch]> > 0000000B: 8B 45 10 mov eax,dword ptr [ebp+10h]> > 0000000E: 0F AF D0 imul edx,eax> > 00000011: 8B 45 14 mov eax,dword ptr [ebp+14h]> > 00000014: 0F AF D0 imul edx,eax> > 00000017: 8B 45 D4 mov eax,dword ptr [ebp-2Ch]> > 0000001A: 83 E0 00 and eax,0> > 0000001D: 09 D0 or eax,edx> > 0000001F: 89 45 D4 mov dword ptr [ebp-2Ch],eax> > 00000022: 8B 45 D8 mov eax,dword ptr [ebp-28h]> > 00000025: 83 E0 00 and eax,0> > 00000028: 83 C8 7B or eax,7Bh> > 0000002B: 89 45 D8 mov dword ptr [ebp-28h],eax> > 0000002E: 8B 55 0C mov edx,dword ptr [ebp+0Ch]> > 00000031: 8B 45 10 mov eax,dword ptr [ebp+10h]> > 00000034: 29 C2 sub edx,eax> > 00000036: 8B 45 14 mov eax,dword ptr [ebp+14h]> > 00000039: 29 C2 sub edx,eax> > 0000003B: 8B 45 DC mov eax,dword ptr [ebp-24h]> > 0000003E: 83 E0 00 and eax,0> > 00000041: 09 D0 or eax,edx> > 00000043: 89 45 DC mov dword ptr [ebp-24h],eax> > 00000046: 8B 45 08 mov eax,dword ptr [ebp+8]> > 00000049: 89 C2 mov edx,eax> > 0000004B: 8D 45 D4 lea eax,[ebp-2Ch]> > 0000004E: 8D 7D EC lea edi,[ebp-14h]> > 00000051: 89 C6 mov esi,eax> > 00000053: FC cld> > 00000054: A5 movs dword ptr es:[edi],dword > > ptr [esi]> > 00000055: A5 movs dword ptr es:[edi],dword > > ptr [esi]> > 00000056: A5 movs dword ptr es:[edi],dword > > ptr [esi]> > 00000057: 89 D7 mov edi,edx> > 00000059: 8D 75 EC lea esi,[ebp-14h]> > 0000005C: FC cld> > 0000005D: A5 movs dword ptr es:[edi],dword > > ptr [esi]> > 0000005E: A5 movs dword ptr es:[edi],dword > > ptr [esi]> > 0000005F: A5 movs dword ptr es:[edi],dword > > ptr [esi]> > 00000060: 83 C4 30 add esp,30h> > 00000063: 5E pop esi> > 00000064: 5F pop edi> > 00000065: C9 leave> > 00000066: C3 ret> >> > optimized Modula-3 is better, saves the extra copy, but still not > > great:> >> > _T__F2:> > 00000000: 55 push ebp> > 00000001: 89 E5 mov ebp,esp> > 00000003: 57 push edi> > 00000004: 56 push esi> > 00000005: 53 push ebx> > 00000006: 83 EC 10 sub esp,10h> > 00000009: 8B 55 0C mov edx,dword ptr [ebp+0Ch]> > 0000000C: 8B 4D 10 mov ecx,dword ptr [ebp+10h]> > 0000000F: 8B 5D 14 mov ebx,dword ptr [ebp+14h]> > 00000012: 89 D0 mov eax,edx> > 00000014: 0F AF C1 imul eax,ecx> > 00000017: 0F AF C3 imul eax,ebx> > 0000001A: 8B 75 E8 mov esi,dword ptr [ebp-18h]> > 0000001D: 89 45 E8 mov dword ptr [ebp-18h],eax> > 00000020: 8B 45 EC mov eax,dword ptr [ebp-14h]> > 00000023: C7 45 EC 7B 00 00 mov dword ptr [ebp-14h],7Bh> > 00> > 0000002A: 29 CA sub edx,ecx> > 0000002C: 29 DA sub edx,ebx> >> > Huh what does this next instruction achieve?> > 0000002E: 8B 45 F0 mov eax,dword ptr [ebp-10h]> > 00000031: 89 55 F0 mov dword ptr [ebp-10h],edx> > 00000034: 8B 7D 08 mov edi,dword ptr [ebp+8]> > 00000037: 8D 75 E8 lea esi,[ebp-18h]> > 0000003A: FC cld> > 0000003B: A5 movs dword ptr es:[edi],dword > > ptr [esi]> > 0000003C: A5 movs dword ptr es:[edi],dword > > ptr [esi]> > 0000003D: A5 movs dword ptr es:[edi],dword > > ptr [esi]> > 0000003E: 83 C4 10 add esp,10h> > 00000041: 5B pop ebx> > 00000042: 5E pop esi> > 00000043: 5F pop edi> > 00000044: C9 leave> > 00000045: C3 ret> >> > and lastly the integrated backend, which runs much faster, and I > > believe has just one mode,> > somewhat optimized (but still lacks int64 support):> >> > _T__F2:> > 00000000: 55 push ebp> > 00000001: 8B EC mov ebp,esp> > 00000003: 81 EC 18 00 00 00 sub esp,18h> > 00000009: 53 push ebx> > 0000000A: 56 push esi> > 0000000B: 57 push edi> > 0000000C: 8B 5D 10 mov ebx,dword ptr [ebp+10h]> > 0000000F: 0F AF 5D 0C imul ebx,dword ptr [ebp+0Ch]> > 00000013: 0F AF 5D 14 imul ebx,dword ptr [ebp+14h]> > 00000017: 89 5D F4 mov dword ptr [ebp-0Ch],ebx> > 0000001A: C7 45 F8 7B 00 00 mov dword ptr [ebp-8],7Bh> > 00> > 00000021: 8B 55 0C mov edx,dword ptr [ebp+0Ch]> > 00000024: 2B 55 10 sub edx,dword ptr [ebp+10h]> > 00000027: 2B 55 14 sub edx,dword ptr [ebp+14h]> > 0000002A: 89 55 FC mov dword ptr [ebp-4],edx> > 0000002D: 8D 75 F4 lea esi,[ebp-0Ch]> > 00000030: 8B 7D 08 mov edi,dword ptr [ebp+8]> > 00000033: 8B 4E 00 mov ecx,dword ptr [esi]> > 00000036: 89 4F 00 mov dword ptr [edi],ecx> > 00000039: 8B 4E 04 mov ecx,dword ptr [esi+4]> > 0000003C: 89 4F 04 mov dword ptr [edi+4],ecx> > 0000003F: 8B 4E 08 mov ecx,dword ptr [esi+8]> > 00000042: 89 4F 08 mov dword ptr [edi+8],ecx> > 00000045: 8B C7 mov eax,edi> > 00000047: 5F pop edi> > 00000048: 5E pop esi> > 00000049: 5B pop ebx> > 0000004A: C9 leave> > 0000004B: C3 ret> >> > I haven't looked at all this in depth, but the doubling in size, > > the extra copy,> > that the integrated backend's code is fairly small...> >> > - Jay> >> > 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 Mon Jan 21 17:10:19 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 21 Jan 2008 16:10:19 +0000 Subject: [M3devel] next problem (NT386GNU) In-Reply-To: <6E1E4409-F3D9-4982-B179-2D4C9648FDD0@cs.purdue.edu> References: <6E1E4409-F3D9-4982-B179-2D4C9648FDD0@cs.purdue.edu> Message-ID: agreed once I thought about it I guess that explains left to right as well. Parameters are always left to right from a higher level point of view, and if that is wrong, the compiler will reorder. "everything" works now - Jay > CC: m3devel at elegosoft.com> From: hosking at cs.purdue.edu> Subject: Re: next problem (NT386GNU)> Date: Mon, 21 Jan 2008 10:54:10 -0500> To: jayk123 at hotmail.com> > Surely, when using the gcc-based backend then we should make the > backend handle it. The front end handling it is only need for the > integrated x86 backend.> > On Jan 21, 2008, at 2:43 AM, Jay wrote:> > > I haven't tested a fix but I see the problem.> >> > This function returns a struct.> > There are two struct returning calling conventions.> > In one, the backend handles it. Which includes the backend knowing > > there is a return value and its type (or at least its size?).> > In the other, the front end handles it. In this case, the front end > > generates passing an extra pointer parameter to the function, and > > the function's return type is void.> >> > The NT calling conventions, all of them, are marked as front end > > handling it. I assume that is correct, could check.> > Everything else is marked as back end handling.> >> > Now then, somewhere along the line, gcc figures out that the return > > value isn't used here.> > The point of the function call is to see if it generates an exception.> >> > Gcc removes the function because its return value isn't used, and, > > well, somehow it doesn't know about the exceptions here. I'll have > > to see how "raise" is implemented. I think it's by a call to a > > function that gets the jmpbuf from a thread local and calls > > longjmp. (Did I mention it is very inefficient?)> >> > There are few possible fixes, but nothing completely satisfactory > > yet in mind.> >> > One is have parse.c mark all function calls as having side affects. > > This is easy, but overly pessimistic.> > Another is for the front end to mark struct returning functions as > > having side affects. Better, but still overly pessimistic.> > Another is for the front end to mark any function that can raise as > > having side affects. Getting better still. I don't know how to do > > that but I'll look. This is still a bit overly pessimistic, since > > what you really want to know is, not the function's side affects, > > but whether or not it raised. If the function is inlined, the side > > affects could be optimized away, or if there are enough callers who > > don't care about the side affects to warrant an optimization, and > > depending on the cost of computing the side affects, another > > instance of the function could be made that only raises or not, but > > no side affects otherwise. This is "advanced" optimization the sort > > of which tends never to be implemented.> >> > I think the best option is anything that can raise is marked as > > having side affects.> > I'll see if I can figure that out.> >> > You can figure this out by looking at m3cgcat -binary < M3File.mc > > > 1.txt on PPC_DARWIN and NT386GNU and comparing.> >> > Maybe marking all or nearly functions as having side effects isn't > > so bad.> > Or at least anything returning a struct. That gets parity with > > other platforms, even if it is a bit pessimistic.> > I think I'll do that, and ignore figuring out if raise is called > > and using that as a filter.> > The parity angle is good.> >> > The good news for all you Unix lovers :) is this bug is relatively > > portable to Cygwin.> > True, it is specific to NT386GNU having multiple "calling > > conventions", which no other platform has.> > Which again, jokingly, strikes at the question -- What is Posix? > > What do you want from Cygwin?> > One thing Cygwin does NOT give you is just one calling convention, > > alas, this calling convention business stinks. It's not even an NT > > thing, only an NT386 thing. All the other NT platforms had/have > > only one calling convention.> >> > You can't get far on NT386 without needing to support two calling > > conventions.> > The "OS" uses mostly __stdcall -- callee pops -- smaller, faster.> > But anything that is varargs, such as printf -- pretty much must > > use caller pops -- __cdecl.> > As well, __cdecl is the default, so prevalent, and used in most C > > runtime functions.> > There is also __fastcall that uses like up to two registers for > > parameters.> >> > I have seen a platform in which printf did the pop, and it depended > > on the number/size of parameters matching the format string. On > > most platforms, printf("", 1, 2, 3, 4) just does nothing, but on > > that platform, it'd unbalance the stack and crash.> >> > - Jay> >> > From: jayk123 at hotmail.com> > To: hosking at cs.purdue.edu> > CC: m3devel at elegosoft.com> > Subject: next problem (NT386GNU)> > Date: Mon, 21 Jan 2008 05:47:28 +0000> >> > M3File.m3> >> > PROCEDURE IsReadable (path: TEXT): BOOLEAN => > (* We don't really check for readablitiy, just for existence *)> > BEGIN> > TRY> > EVAL FS.Status (path); line 82> > RETURN TRUE;> > EXCEPT OSError.E =>> > RETURN FALSE;> > END;> > END IsReadable;> >> > -----LINE 82 -----> > start_call_direct p.25 0 Struct> > load_address v.25 0> > pop_param Addr> > load v.26 0 Addr Addr> > pop_param Addr> > call_direct p.25 Struct> > pop Struct> >> >> >> > I'm guessing you only see an import for the first call on purpose, > > but I will compare with PPC_DARWIN:> >> > -----LINE 46 -----> > import_procedure FS__Status 2 Struct 0 p.25> > declare_indirect 2078421550 -2078421551> > declare_param _return 4 4 Addr 2078421550 F F 50 v.62> > declare_param p 4 4 Addr 1358456180 F F 50 v.63> > start_call_direct p.25 0 Struct> > load_address v.13 0> > pop_param Addr> > load v.14 0 Addr Addr> > pop_param Addr> > call_direct p.25 Struct> > pop Struct> >> >> > .globl _M3File__IsReadable> > .def _M3File__IsReadable; .scl 2; .type 32; .endef> > _M3File__IsReadable:> > .stabn 68,0,178,LM93-_M3File__IsReadable> > LM93:> > pushl %ebp> > movl %esp, %ebp> > pushl %edi> > pushl %esi> > pushl %ebx> > subl $300, %esp> > LBB15:> > .stabn 68,0,181,LM94-_M3File__IsReadable> > LM94:> > L157:> > movl -280(%ebp), %eax> > andl $0, %eax> > orl $_L_1, %eax> > movl %eax, -280(%ebp)> > movl -284(%ebp), %eax> > andl $0, %eax> > movl %eax, -284(%ebp)> > subl $12, %esp> > leal -288(%ebp), %eax> > pushl %eax> > call _RTHooks__PushEFrame> > addl $16, %esp> > leal -288(%ebp), %eax> > addl $48, %eax> > subl $12, %esp> > pushl %eax> > call __setjmp> > addl $16, %esp> > testb %al, %al> > jne L158> > .stabn 68,0,183,LM95-_M3File__IsReadable> > LM95:> > movl -288(%ebp), %eax> > subl $12, %esp> > pushl %eax> > call _RTHooks__PopEFrame> > addl $16, %esp> > movl $1, -304(%ebp)> > jmp L159> > L158:> > .stabn 68,0,185,LM96-_M3File__IsReadable> > LM96:> > movl $0, -304(%ebp)> > L159:> > LBE15:> > movl -304(%ebp), %eax> > leal -12(%ebp), %esp> > popl %ebx> > popl %esi> > popl %edi> > leave> > ret> >> >> > M3File.IsReadable's call to FS.Status is omitted, all files are > > readable, even if they are not openable, therefore it "finds" > > cm3.cfg in the current directory and then fails to open it..> >> > later..> > ..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! 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 jayk123 at hotmail.com Mon Jan 21 17:36:47 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 21 Jan 2008 16:36:47 +0000 Subject: [M3devel] broken record... Message-ID: Looking at the file names I'm about to announce are available... User could set OS_TYPE in config file or environment variable CM3_OSTYPE, to Posix or Win32, and everything else could go along.. POSIX-NT386GNU => paths all start with forward slash, Trestle is on X Windows, threads might be pthreads; WIN32-NT386GNU => paths tend toward backslashes, Trestle on Win32, threads are native, tools are GNU. Oh, and I guess people like libfoo.a, even though "lib" and ".a" seem redundant? Or don't care? - 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 Mon Jan 21 17:41:48 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 21 Jan 2008 16:41:48 +0000 Subject: [M3devel] NT386GNU distribution available Message-ID: Here, in my user directory on birch, is the first CM3 NT386GNU release.It is MinGWin based FOR NOW.This needs to be changed SOON. Install MinGWin. (Search the web for it.)set PATH=c:\MinGW\bin;%PATH% (The default install location is c:\MinGW, not MinGWin.) The MinGWin that Qt gives you is too old, from around 2004.It doesn't support "response files" (aka long command lines). If you want to rebuild m3cg: Install MSys. It is at the same place as MinGWin. set PATH=c:\msys\1.0\bin;%PATH% else consider set OMIT_GCC=yes depending on if you run the various scripts. If you install to these exact paths, scripts\python\pylib.py will use them automatically. Optionally install Python. I recommend it. Extract one or more of the archives. They will extract to like: cm3-min-WIN32-NT386GNU-d5.5.1\bin\cm3.exe You can rename it cm3, or for purposes of backup/restore, xcopy /fivery \cm3-min-WIN32-NT386GNU-d5.5.1 \cm3 (For extra good testing, first rmdir /q/s \cm3.) set PATH=c:\cm3\bin;%PATH% This is important, since various code will tend to assume NT386 unless overridden. set CM3_TARGET=NT386GNU Someone please weigh in on zip vs. tar.bz2 on the other Win32 platforms.For reference, MinGWin doesn't include tar/bzip2, MSys does, Cygwinhas tons of optional stuff, they are in there, probably the base. And then go to scripts\python and run whatever: upgrade or make-dist or do-cm3-core or do-cm3-base but not currently do-cm3-std scripts\win\upgrade works too. Do remember to set CM3_TARGET=NT386GNU. You will probably at some point be prompted to set CM3_ROOT to the root of the sourcetree as well. If you run "scripts", it will be set for you.If you cd around and run cm3, it won't. \cm3\bin\cm3.cfg delegates out to the source tree.Except the one in the distributions do not.But if you run upgrade, you'll have such a thing. If you want to rebuild cm3cg from source: cd m3-sys\m3cc\gcc\gcc\m3cg cvs update -j 1.46 -j 1.45 parse.c or thereabouts to get back enough of a __stdcall fix to build a lot. If you want to bootstrap without a previous NT386GNU distribution but with a previous NT386 build, try like this: Get a working NT386 system. Get current source (except parse.c). If your system is not current, scripts\python\upgrade This will work as far back as cm3-min-WIN32-NT386-5.1.3. scripts\python\bootntgnu which is really just roughly: do-pkg realclean m3core libm3 m3cc do-pkg buildship m3core libm3 m3cc set CM3_TARGET=NT386GNU Now you have the equivalent of the minimum distribution and can build whatever. do-pkg .... If you want to rollback a bit but not completely, scripts\win\pkggnu_clean.cmd is very simple and just deletes all the NT386GNU directories under $INSTALLROOT\pkg. There are "min", "core", and "base" distributions.Kind of subtle names, eh?"min" is sufficient.The binaries are all not "strippped". Last minute errata: There is bin\cm3.cfg and bin\NT386GNU. They are identical. The intent was only to have cm3.cfg there. The system builds itself, so that's pretty good. I forgot to include m3gdb, but it should probably be in a separate "GNU" archive? Someone move the files to a web download place? (and you can move, not copy, I can easily recreate the files) - Jay _________________________________________________________________ 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 Mon Jan 21 17:57:29 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 21 Jan 2008 11:57:29 -0500 Subject: [M3devel] gcc/eh/setjmp In-Reply-To: References: Message-ID: <0ECB2F81-C843-409C-AB24-A837EA93F083@cs.purdue.edu> Yeah, we should be able to do that. I wonder if setting DECL_NONLOCAL on barrier labels will do the trick? On Jan 21, 2008, at 11:06 AM, Jay wrote: > Any chance of giving gcc enough or the right information so that - > Wunreachable-code can be used without hitting a bunch of false > positives? It's not being dumb, not that sort of false positive. It > reports every except block and anything after a try { return } > except { } as unreachable. > > - Jay > > > > > CC: m3devel at elegosoft.com > > From: hosking at cs.purdue.edu > > Subject: Re: [M3devel] gcc/eh/setjmp > > Date: Mon, 21 Jan 2008 10:59:35 -0500 > > To: jayk123 at hotmail.com > > > > I think gcc was forced not to act on it by use of LABEL_PRESERVE_P > > and FORCED_LABEL as well as making the function containing the TRY > > non-inlinable, plus lots of other goop to let the flow analyser know > > that funky stuff was going on at labels for TRY scopes. Take a look > > at the lines of parse.c that deal with "set_label" when > "barrier=TRUE". > > > > On Jan 21, 2008, at 5:50 AM, Jay wrote: > > > > > Folks, try adding -Wunreachable-code to your m3back options and > > > tell me if you don't get loads of warnings. > > > for stuff like: > > > > > > TRY > > > return Foo(); > > > ELSE > > > return FALSE; > > > > > > I get them on NT386GNU and PPC_DARWIN. > > > > > > Functions with TRY need, in gcc parlance: > > > calls_setjmp > > > > > > and the exception/finally blocks need: > > > has_nonlocal_label > > > > > > and functions with RAISE might need: > > > has_nonlocal_goto > > > > > > Luckily, gcc doesn't seem to act on what it figure out. > > > > > > - Jay > > > > > > > > > > > > > > > > > > Helping your favorite cause is as easy as instant messaging. You > > > IM, we give. Learn more. > > > > > Shed those extra pounds with MSN and The Biggest Loser! Learn more. From hosking at cs.purdue.edu Mon Jan 21 18:01:28 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 21 Jan 2008 12:01:28 -0500 Subject: [M3devel] next problem (NT386GNU) In-Reply-To: References: <6E1E4409-F3D9-4982-B179-2D4C9648FDD0@cs.purdue.edu> Message-ID: I just need to fix m3cc/cm3cg to emit the stdcall parameter information for imported procedures. It is simply a matter of not ignoring declare_param for import_procedure chunks. This means maintaining a current_function_decl (and possibly a current_param_count) stack (since import_procedure can occur inside a declare_procedure chunk). I know what needs doing, but have not much free time right now... On Jan 21, 2008, at 11:10 AM, Jay wrote: > agreed once I thought about it > I guess that explains left to right as well. > Parameters are always left to right from a higher level point of > view, and if that is wrong, the compiler will reorder. > > "everything" works now > > - Jay > > > > > CC: m3devel at elegosoft.com > > From: hosking at cs.purdue.edu > > Subject: Re: next problem (NT386GNU) > > Date: Mon, 21 Jan 2008 10:54:10 -0500 > > To: jayk123 at hotmail.com > > > > Surely, when using the gcc-based backend then we should make the > > backend handle it. The front end handling it is only need for the > > integrated x86 backend. > > > > On Jan 21, 2008, at 2:43 AM, Jay wrote: > > > > > I haven't tested a fix but I see the problem. > > > > > > This function returns a struct. > > > There are two struct returning calling conventions. > > > In one, the backend handles it. Which includes the backend knowing > > > there is a return value and its type (or at least its size?). > > > In the other, the front end handles it. In this case, the front > end > > > generates passing an extra pointer parameter to the function, and > > > the function's return type is void. > > > > > > The NT calling conventions, all of them, are marked as front end > > > handling it. I assume that is correct, could check. > > > Everything else is marked as back end handling. > > > > > > Now then, somewhere along the line, gcc figures out that the > return > > > value isn't used here. > > > The point of the function call is to see if it generates an > exception. > > > > > > Gcc removes the function because its return value isn't used, and, > > > well, somehow it doesn't know about the exceptions here. I'll have > > > to see how "raise" is implemented. I think it's by a call to a > > > function that gets the jmpbuf from a thread local and calls > > > longjmp. (Did I mention it is very inefficient?) > > > > > > There are few possible fixes, but nothing completely satisfactory > > > yet in mind. > > > > > > One is have parse.c mark all function calls as having side > affects. > > > This is easy, but overly pessimistic. > > > Another is for the front end to mark struct returning functions as > > > having side affects. Better, but still overly pessimistic. > > > Another is for the front end to mark any function that can > raise as > > > having side affects. Getting better still. I don't know how to do > > > that but I'll look. This is still a bit overly pessimistic, since > > > what you really want to know is, not the function's side affects, > > > but whether or not it raised. If the function is inlined, the side > > > affects could be optimized away, or if there are enough callers > who > > > don't care about the side affects to warrant an optimization, and > > > depending on the cost of computing the side affects, another > > > instance of the function could be made that only raises or not, > but > > > no side affects otherwise. This is "advanced" optimization the > sort > > > of which tends never to be implemented. > > > > > > I think the best option is anything that can raise is marked as > > > having side affects. > > > I'll see if I can figure that out. > > > > > > You can figure this out by looking at m3cgcat -binary < > M3File.mc > > > > 1.txt on PPC_DARWIN and NT386GNU and comparing. > > > > > > Maybe marking all or nearly functions as having side effects isn't > > > so bad. > > > Or at least anything returning a struct. That gets parity with > > > other platforms, even if it is a bit pessimistic. > > > I think I'll do that, and ignore figuring out if raise is called > > > and using that as a filter. > > > The parity angle is good. > > > > > > The good news for all you Unix lovers :) is this bug is relatively > > > portable to Cygwin. > > > True, it is specific to NT386GNU having multiple "calling > > > conventions", which no other platform has. > > > Which again, jokingly, strikes at the question -- What is Posix? > > > What do you want from Cygwin? > > > One thing Cygwin does NOT give you is just one calling convention, > > > alas, this calling convention business stinks. It's not even an NT > > > thing, only an NT386 thing. All the other NT platforms had/have > > > only one calling convention. > > > > > > You can't get far on NT386 without needing to support two calling > > > conventions. > > > The "OS" uses mostly __stdcall -- callee pops -- smaller, faster. > > > But anything that is varargs, such as printf -- pretty much must > > > use caller pops -- __cdecl. > > > As well, __cdecl is the default, so prevalent, and used in most C > > > runtime functions. > > > There is also __fastcall that uses like up to two registers for > > > parameters. > > > > > > I have seen a platform in which printf did the pop, and it > depended > > > on the number/size of parameters matching the format string. On > > > most platforms, printf("", 1, 2, 3, 4) just does nothing, but on > > > that platform, it'd unbalance the stack and crash. > > > > > > - Jay > > > > > > From: jayk123 at hotmail.com > > > To: hosking at cs.purdue.edu > > > CC: m3devel at elegosoft.com > > > Subject: next problem (NT386GNU) > > > Date: Mon, 21 Jan 2008 05:47:28 +0000 > > > > > > M3File.m3 > > > > > > PROCEDURE IsReadable (path: TEXT): BOOLEAN = > > > (* We don't really check for readablitiy, just for existence *) > > > BEGIN > > > TRY > > > EVAL FS.Status (path); line 82 > > > RETURN TRUE; > > > EXCEPT OSError.E => > > > RETURN FALSE; > > > END; > > > END IsReadable; > > > > > > -----LINE 82 ----- > > > start_call_direct p.25 0 Struct > > > load_address v.25 0 > > > pop_param Addr > > > load v.26 0 Addr Addr > > > pop_param Addr > > > call_direct p.25 Struct > > > pop Struct > > > > > > > > > > > > I'm guessing you only see an import for the first call on purpose, > > > but I will compare with PPC_DARWIN: > > > > > > -----LINE 46 ----- > > > import_procedure FS__Status 2 Struct 0 p.25 > > > declare_indirect 2078421550 -2078421551 > > > declare_param _return 4 4 Addr 2078421550 F F 50 v.62 > > > declare_param p 4 4 Addr 1358456180 F F 50 v.63 > > > start_call_direct p.25 0 Struct > > > load_address v.13 0 > > > pop_param Addr > > > load v.14 0 Addr Addr > > > pop_param Addr > > > call_direct p.25 Struct > > > pop Struct > > > > > > > > > .globl _M3File__IsReadable > > > .def _M3File__IsReadable; .scl 2; .type 32; .endef > > > _M3File__IsReadable: > > > .stabn 68,0,178,LM93-_M3File__IsReadable > > > LM93: > > > pushl %ebp > > > movl %esp, %ebp > > > pushl %edi > > > pushl %esi > > > pushl %ebx > > > subl $300, %esp > > > LBB15: > > > .stabn 68,0,181,LM94-_M3File__IsReadable > > > LM94: > > > L157: > > > movl -280(%ebp), %eax > > > andl $0, %eax > > > orl $_L_1, %eax > > > movl %eax, -280(%ebp) > > > movl -284(%ebp), %eax > > > andl $0, %eax > > > movl %eax, -284(%ebp) > > > subl $12, %esp > > > leal -288(%ebp), %eax > > > pushl %eax > > > call _RTHooks__PushEFrame > > > addl $16, %esp > > > leal -288(%ebp), %eax > > > addl $48, %eax > > > subl $12, %esp > > > pushl %eax > > > call __setjmp > > > addl $16, %esp > > > testb %al, %al > > > jne L158 > > > .stabn 68,0,183,LM95-_M3File__IsReadable > > > LM95: > > > movl -288(%ebp), %eax > > > subl $12, %esp > > > pushl %eax > > > call _RTHooks__PopEFrame > > > addl $16, %esp > > > movl $1, -304(%ebp) > > > jmp L159 > > > L158: > > > .stabn 68,0,185,LM96-_M3File__IsReadable > > > LM96: > > > movl $0, -304(%ebp) > > > L159: > > > LBE15: > > > movl -304(%ebp), %eax > > > leal -12(%ebp), %esp > > > popl %ebx > > > popl %esi > > > popl %edi > > > leave > > > ret > > > > > > > > > M3File.IsReadable's call to FS.Status is omitted, all files are > > > readable, even if they are not openable, therefore it "finds" > > > cm3.cfg in the current directory and then fails to open it.. > > > > > > later.. > > > ..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! Learn > more. > > > > > Shed those extra pounds with MSN and The Biggest Loser! Learn more. From hosking at cs.purdue.edu Mon Jan 21 18:02:12 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 21 Jan 2008 12:02:12 -0500 Subject: [M3devel] broken record... In-Reply-To: References: Message-ID: <659E4F4F-3A52-4269-9F4F-790613E14530@cs.purdue.edu> On Jan 21, 2008, at 11:36 AM, Jay wrote: > Looking at the file names I'm about to announce are available... > > User could set OS_TYPE in config file or environment variable > CM3_OSTYPE, to Posix or Win32, and everything else could go along.. > POSIX-NT386GNU => paths all start with forward slash, Trestle is on > X Windows, threads might be pthreads; WIN32-NT386GNU => paths tend > toward backslashes, Trestle on Win32, threads are native, tools are > GNU. > > Oh, and I guess people like libfoo.a, even though "lib" and ".a" > seem redundant? Don't care really. Standard on Unix is lib*.a. > > Or don't care? > > - Jay > > > > > > Climb to the top of the charts! Play the word scramble challenge > with star power. Play now! From jayk123 at hotmail.com Mon Jan 21 23:16:54 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 21 Jan 2008 22:16:54 +0000 Subject: [M3devel] next problem (NT386GNU) In-Reply-To: References: <6E1E4409-F3D9-4982-B179-2D4C9648FDD0@cs.purdue.edu> Message-ID: Understood. Put back my parse.c in the meantime? Also, the front end could do this, right? And probably without a stack? It could compute "effective parameter size" and pass that down. Backend could then divide by 4 and claim that is the signature, that number of parameters. Would have to see how passing a struct works out anyway -- one parameter or one per field. - Jay > CC: m3devel at elegosoft.com > From: hosking at cs.purdue.edu > Subject: Re: next problem (NT386GNU) > Date: Mon, 21 Jan 2008 12:01:28 -0500 > To: jayk123 at hotmail.com > > I just need to fix m3cc/cm3cg to emit the stdcall parameter > information for imported procedures. It is simply a matter of not > ignoring declare_param for import_procedure chunks. This means > maintaining a current_function_decl (and possibly a > current_param_count) stack (since import_procedure can occur inside a > declare_procedure chunk). I know what needs doing, but have not much > free time right now... > > On Jan 21, 2008, at 11:10 AM, Jay wrote: > > > agreed once I thought about it > > I guess that explains left to right as well. > > Parameters are always left to right from a higher level point of > > view, and if that is wrong, the compiler will reorder. > > > > "everything" works now > > > > - Jay > > > > > > > > > CC: m3devel at elegosoft.com > > > From: hosking at cs.purdue.edu > > > Subject: Re: next problem (NT386GNU) > > > Date: Mon, 21 Jan 2008 10:54:10 -0500 > > > To: jayk123 at hotmail.com > > > > > > Surely, when using the gcc-based backend then we should make the > > > backend handle it. The front end handling it is only need for the > > > integrated x86 backend. > > > > > > On Jan 21, 2008, at 2:43 AM, Jay wrote: > > > > > > > I haven't tested a fix but I see the problem. > > > > > > > > This function returns a struct. > > > > There are two struct returning calling conventions. > > > > In one, the backend handles it. Which includes the backend knowing > > > > there is a return value and its type (or at least its size?). > > > > In the other, the front end handles it. In this case, the front > > end > > > > generates passing an extra pointer parameter to the function, and > > > > the function's return type is void. > > > > > > > > The NT calling conventions, all of them, are marked as front end > > > > handling it. I assume that is correct, could check. > > > > Everything else is marked as back end handling. > > > > > > > > Now then, somewhere along the line, gcc figures out that the > > return > > > > value isn't used here. > > > > The point of the function call is to see if it generates an > > exception. > > > > > > > > Gcc removes the function because its return value isn't used, and, > > > > well, somehow it doesn't know about the exceptions here. I'll have > > > > to see how "raise" is implemented. I think it's by a call to a > > > > function that gets the jmpbuf from a thread local and calls > > > > longjmp. (Did I mention it is very inefficient?) > > > > > > > > There are few possible fixes, but nothing completely satisfactory > > > > yet in mind. > > > > > > > > One is have parse.c mark all function calls as having side > > affects. > > > > This is easy, but overly pessimistic. > > > > Another is for the front end to mark struct returning functions as > > > > having side affects. Better, but still overly pessimistic. > > > > Another is for the front end to mark any function that can > > raise as > > > > having side affects. Getting better still. I don't know how to do > > > > that but I'll look. This is still a bit overly pessimistic, since > > > > what you really want to know is, not the function's side affects, > > > > but whether or not it raised. If the function is inlined, the side > > > > affects could be optimized away, or if there are enough callers > > who > > > > don't care about the side affects to warrant an optimization, and > > > > depending on the cost of computing the side affects, another > > > > instance of the function could be made that only raises or not, > > but > > > > no side affects otherwise. This is "advanced" optimization the > > sort > > > > of which tends never to be implemented. > > > > > > > > I think the best option is anything that can raise is marked as > > > > having side affects. > > > > I'll see if I can figure that out. > > > > > > > > You can figure this out by looking at m3cgcat -binary < > > M3File.mc > > > > > 1.txt on PPC_DARWIN and NT386GNU and comparing. > > > > > > > > Maybe marking all or nearly functions as having side effects isn't > > > > so bad. > > > > Or at least anything returning a struct. That gets parity with > > > > other platforms, even if it is a bit pessimistic. > > > > I think I'll do that, and ignore figuring out if raise is called > > > > and using that as a filter. > > > > The parity angle is good. > > > > > > > > The good news for all you Unix lovers :) is this bug is relatively > > > > portable to Cygwin. > > > > True, it is specific to NT386GNU having multiple "calling > > > > conventions", which no other platform has. > > > > Which again, jokingly, strikes at the question -- What is Posix? > > > > What do you want from Cygwin? > > > > One thing Cygwin does NOT give you is just one calling convention, > > > > alas, this calling convention business stinks. It's not even an NT > > > > thing, only an NT386 thing. All the other NT platforms had/have > > > > only one calling convention. > > > > > > > > You can't get far on NT386 without needing to support two calling > > > > conventions. > > > > The "OS" uses mostly __stdcall -- callee pops -- smaller, faster. > > > > But anything that is varargs, such as printf -- pretty much must > > > > use caller pops -- __cdecl. > > > > As well, __cdecl is the default, so prevalent, and used in most C > > > > runtime functions. > > > > There is also __fastcall that uses like up to two registers for > > > > parameters. > > > > > > > > I have seen a platform in which printf did the pop, and it > > depended > > > > on the number/size of parameters matching the format string. On > > > > most platforms, printf("", 1, 2, 3, 4) just does nothing, but on > > > > that platform, it'd unbalance the stack and crash. > > > > > > > > - Jay > > > > > > > > From: jayk123 at hotmail.com > > > > To: hosking at cs.purdue.edu > > > > CC: m3devel at elegosoft.com > > > > Subject: next problem (NT386GNU) > > > > Date: Mon, 21 Jan 2008 05:47:28 +0000 > > > > > > > > M3File.m3 > > > > > > > > PROCEDURE IsReadable (path: TEXT): BOOLEAN = > > > > (* We don't really check for readablitiy, just for existence *) > > > > BEGIN > > > > TRY > > > > EVAL FS.Status (path); line 82 > > > > RETURN TRUE; > > > > EXCEPT OSError.E => > > > > RETURN FALSE; > > > > END; > > > > END IsReadable; > > > > > > > > -----LINE 82 ----- > > > > start_call_direct p.25 0 Struct > > > > load_address v.25 0 > > > > pop_param Addr > > > > load v.26 0 Addr Addr > > > > pop_param Addr > > > > call_direct p.25 Struct > > > > pop Struct > > > > > > > > > > > > > > > > I'm guessing you only see an import for the first call on purpose, > > > > but I will compare with PPC_DARWIN: > > > > > > > > -----LINE 46 ----- > > > > import_procedure FS__Status 2 Struct 0 p.25 > > > > declare_indirect 2078421550 -2078421551 > > > > declare_param _return 4 4 Addr 2078421550 F F 50 v.62 > > > > declare_param p 4 4 Addr 1358456180 F F 50 v.63 > > > > start_call_direct p.25 0 Struct > > > > load_address v.13 0 > > > > pop_param Addr > > > > load v.14 0 Addr Addr > > > > pop_param Addr > > > > call_direct p.25 Struct > > > > pop Struct > > > > > > > > > > > > .globl _M3File__IsReadable > > > > .def _M3File__IsReadable; .scl 2; .type 32; .endef > > > > _M3File__IsReadable: > > > > .stabn 68,0,178,LM93-_M3File__IsReadable > > > > LM93: > > > > pushl %ebp > > > > movl %esp, %ebp > > > > pushl %edi > > > > pushl %esi > > > > pushl %ebx > > > > subl $300, %esp > > > > LBB15: > > > > .stabn 68,0,181,LM94-_M3File__IsReadable > > > > LM94: > > > > L157: > > > > movl -280(%ebp), %eax > > > > andl $0, %eax > > > > orl $_L_1, %eax > > > > movl %eax, -280(%ebp) > > > > movl -284(%ebp), %eax > > > > andl $0, %eax > > > > movl %eax, -284(%ebp) > > > > subl $12, %esp > > > > leal -288(%ebp), %eax > > > > pushl %eax > > > > call _RTHooks__PushEFrame > > > > addl $16, %esp > > > > leal -288(%ebp), %eax > > > > addl $48, %eax > > > > subl $12, %esp > > > > pushl %eax > > > > call __setjmp > > > > addl $16, %esp > > > > testb %al, %al > > > > jne L158 > > > > .stabn 68,0,183,LM95-_M3File__IsReadable > > > > LM95: > > > > movl -288(%ebp), %eax > > > > subl $12, %esp > > > > pushl %eax > > > > call _RTHooks__PopEFrame > > > > addl $16, %esp > > > > movl $1, -304(%ebp) > > > > jmp L159 > > > > L158: > > > > .stabn 68,0,185,LM96-_M3File__IsReadable > > > > LM96: > > > > movl $0, -304(%ebp) > > > > L159: > > > > LBE15: > > > > movl -304(%ebp), %eax > > > > leal -12(%ebp), %esp > > > > popl %ebx > > > > popl %esi > > > > popl %edi > > > > leave > > > > ret > > > > > > > > > > > > M3File.IsReadable's call to FS.Status is omitted, all files are > > > > readable, even if they are not openable, therefore it "finds" > > > > cm3.cfg in the current directory and then fails to open it.. > > > > > > > > later.. > > > > ..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! Learn > > more. > > > > > > > > > Shed those extra pounds with MSN and The Biggest Loser! Learn more. > _________________________________________________________________ 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 Jan 21 23:32:32 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 21 Jan 2008 17:32:32 -0500 Subject: [M3devel] next problem (NT386GNU) In-Reply-To: References: <6E1E4409-F3D9-4982-B179-2D4C9648FDD0@cs.purdue.edu> Message-ID: <1A6EC7D6-32B2-44AD-933F-6976040A7D7F@cs.purdue.edu> I'd prefer to have the backend do it properly based on properly declared types. I'd prefer to keep this code out of the current mainline of parse.c -- you could fork a temporary branch if necessary. On Jan 21, 2008, at 5:16 PM, Jay wrote: > Understood. Put back my parse.c in the meantime? > > Also, the front end could do this, right? And probably without a > stack? > It could compute "effective parameter size" and pass that down. > Backend could then divide by 4 and claim that is the signature, > that number of parameters. > > Would have to see how passing a struct works out anyway -- one > parameter > or one per field. > > - Jay > > > > CC: m3devel at elegosoft.com > > From: hosking at cs.purdue.edu > > Subject: Re: next problem (NT386GNU) > > Date: Mon, 21 Jan 2008 12:01:28 -0500 > > To: jayk123 at hotmail.com > > > > I just need to fix m3cc/cm3cg to emit the stdcall parameter > > information for imported procedures. It is simply a matter of not > > ignoring declare_param for import_procedure chunks. This means > > maintaining a current_function_decl (and possibly a > > current_param_count) stack (since import_procedure can occur > inside a > > declare_procedure chunk). I know what needs doing, but have not much > > free time right now... > > > > On Jan 21, 2008, at 11:10 AM, Jay wrote: > > > > > agreed once I thought about it > > > I guess that explains left to right as well. > > > Parameters are always left to right from a higher level point of > > > view, and if that is wrong, the compiler will reorder. > > > > > > "everything" works now > > > > > > - Jay > > > > > > > > > > > > > CC: m3devel at elegosoft.com > > > > From: hosking at cs.purdue.edu > > > > Subject: Re: next problem (NT386GNU) > > > > Date: Mon, 21 Jan 2008 10:54:10 -0500 > > > > To: jayk123 at hotmail.com > > > > > > > > Surely, when using the gcc-based backend then we should make the > > > > backend handle it. The front end handling it is only need for > the > > > > integrated x86 backend. > > > > > > > > On Jan 21, 2008, at 2:43 AM, Jay wrote: > > > > > > > > > I haven't tested a fix but I see the problem. > > > > > > > > > > This function returns a struct. > > > > > There are two struct returning calling conventions. > > > > > In one, the backend handles it. Which includes the backend > knowing > > > > > there is a return value and its type (or at least its size?). > > > > > In the other, the front end handles it. In this case, the > front > > > end > > > > > generates passing an extra pointer parameter to the > function, and > > > > > the function's return type is void. > > > > > > > > > > The NT calling conventions, all of them, are marked as > front end > > > > > handling it. I assume that is correct, could check. > > > > > Everything else is marked as back end handling. > > > > > > > > > > Now then, somewhere along the line, gcc figures out that the > > > return > > > > > value isn't used here. > > > > > The point of the function call is to see if it generates an > > > exception. > > > > > > > > > > Gcc removes the function because its return value isn't > used, and, > > > > > well, somehow it doesn't know about the exceptions here. > I'll have > > > > > to see how "raise" is implemented. I think it's by a call to a > > > > > function that gets the jmpbuf from a thread local and calls > > > > > longjmp. (Did I mention it is very inefficient?) > > > > > > > > > > There are few possible fixes, but nothing completely > satisfactory > > > > > yet in mind. > > > > > > > > > > One is have parse.c mark all function calls as having side > > > affects. > > > > > This is easy, but overly pessimistic. > > > > > Another is for the front end to mark struct returning > functions as > > > > > having side affects. Better, but still overly pessimistic. > > > > > Another is for the front end to mark any function that can > > > raise as > > > > > having side affects. Getting better still. I don't know how > to do > > > > > that but I'll look. This is still a bit overly pessimistic, > since > > > > > what you really want to know is, not the function's side > affects, > > > > > but whether or not it raised. If the function is inlined, > the side > > > > > affects could be optimized away, or if there are enough > callers > > > who > > > > > don't care about the side affects to warrant an > optimization, and > > > > > depending on the cost of computing the side affects, another > > > > > instance of the function could be made that only raises or > not, > > > but > > > > > no side affects otherwise. This is "advanced" optimization the > > > sort > > > > > of which tends never to be implemented. > > > > > > > > > > I think the best option is anything that can raise is > marked as > > > > > having side affects. > > > > > I'll see if I can figure that out. > > > > > > > > > > You can figure this out by looking at m3cgcat -binary < > > > M3File.mc > > > > > > 1.txt on PPC_DARWIN and NT386GNU and comparing. > > > > > > > > > > Maybe marking all or nearly functions as having side > effects isn't > > > > > so bad. > > > > > Or at least anything returning a struct. That gets parity with > > > > > other platforms, even if it is a bit pessimistic. > > > > > I think I'll do that, and ignore figuring out if raise is > called > > > > > and using that as a filter. > > > > > The parity angle is good. > > > > > > > > > > The good news for all you Unix lovers :) is this bug is > relatively > > > > > portable to Cygwin. > > > > > True, it is specific to NT386GNU having multiple "calling > > > > > conventions", which no other platform has. > > > > > Which again, jokingly, strikes at the question -- What is > Posix? > > > > > What do you want from Cygwin? > > > > > One thing Cygwin does NOT give you is just one calling > convention, > > > > > alas, this calling convention business stinks. It's not > even an NT > > > > > thing, only an NT386 thing. All the other NT platforms had/ > have > > > > > only one calling convention. > > > > > > > > > > You can't get far on NT386 without needing to support two > calling > > > > > conventions. > > > > > The "OS" uses mostly __stdcall -- callee pops -- smaller, > faster. > > > > > But anything that is varargs, such as printf -- pretty much > must > > > > > use caller pops -- __cdecl. > > > > > As well, __cdecl is the default, so prevalent, and used in > most C > > > > > runtime functions. > > > > > There is also __fastcall that uses like up to two registers > for > > > > > parameters. > > > > > > > > > > I have seen a platform in which printf did the pop, and it > > > depended > > > > > on the number/size of parameters matching the format > string. On > > > > > most platforms, printf("", 1, 2, 3, 4) just does nothing, > but on > > > > > that platform, it'd unbalance the stack and crash. > > > > > > > > > > - Jay > > > > > > > > > > From: jayk123 at hotmail.com > > > > > To: hosking at cs.purdue.edu > > > > > CC: m3devel at elegosoft.com > > > > > Subject: next problem (NT386GNU) > > > > > Date: Mon, 21 Jan 2008 05:47:28 +0000 > > > > > > > > > > M3File.m3 > > > > > > > > > > PROCEDURE IsReadable (path: TEXT): BOOLEAN = > > > > > (* We don't really check for readablitiy, just for > existence *) > > > > > BEGIN > > > > > TRY > > > > > EVAL FS.Status (path); line 82 > > > > > RETURN TRUE; > > > > > EXCEPT OSError.E => > > > > > RETURN FALSE; > > > > > END; > > > > > END IsReadable; > > > > > > > > > > -----LINE 82 ----- > > > > > start_call_direct p.25 0 Struct > > > > > load_address v.25 0 > > > > > pop_param Addr > > > > > load v.26 0 Addr Addr > > > > > pop_param Addr > > > > > call_direct p.25 Struct > > > > > pop Struct > > > > > > > > > > > > > > > > > > > > I'm guessing you only see an import for the first call on > purpose, > > > > > but I will compare with PPC_DARWIN: > > > > > > > > > > -----LINE 46 ----- > > > > > import_procedure FS__Status 2 Struct 0 p.25 > > > > > declare_indirect 2078421550 -2078421551 > > > > > declare_param _return 4 4 Addr 2078421550 F F 50 v.62 > > > > > declare_param p 4 4 Addr 1358456180 F F 50 v.63 > > > > > start_call_direct p.25 0 Struct > > > > > load_address v.13 0 > > > > > pop_param Addr > > > > > load v.14 0 Addr Addr > > > > > pop_param Addr > > > > > call_direct p.25 Struct > > > > > pop Struct > > > > > > > > > > > > > > > .globl _M3File__IsReadable > > > > > .def _M3File__IsReadable; .scl 2; .type 32; .endef > > > > > _M3File__IsReadable: > > > > > .stabn 68,0,178,LM93-_M3File__IsReadable > > > > > LM93: > > > > > pushl %ebp > > > > > movl %esp, %ebp > > > > > pushl %edi > > > > > pushl %esi > > > > > pushl %ebx > > > > > subl $300, %esp > > > > > LBB15: > > > > > .stabn 68,0,181,LM94-_M3File__IsReadable > > > > > LM94: > > > > > L157: > > > > > movl -280(%ebp), %eax > > > > > andl $0, %eax > > > > > orl $_L_1, %eax > > > > > movl %eax, -280(%ebp) > > > > > movl -284(%ebp), %eax > > > > > andl $0, %eax > > > > > movl %eax, -284(%ebp) > > > > > subl $12, %esp > > > > > leal -288(%ebp), %eax > > > > > pushl %eax > > > > > call _RTHooks__PushEFrame > > > > > addl $16, %esp > > > > > leal -288(%ebp), %eax > > > > > addl $48, %eax > > > > > subl $12, %esp > > > > > pushl %eax > > > > > call __setjmp > > > > > addl $16, %esp > > > > > testb %al, %al > > > > > jne L158 > > > > > .stabn 68,0,183,LM95-_M3File__IsReadable > > > > > LM95: > > > > > movl -288(%ebp), %eax > > > > > subl $12, %esp > > > > > pushl %eax > > > > > call _RTHooks__PopEFrame > > > > > addl $16, %esp > > > > > movl $1, -304(%ebp) > > > > > jmp L159 > > > > > L158: > > > > > .stabn 68,0,185,LM96-_M3File__IsReadable > > > > > LM96: > > > > > movl $0, -304(%ebp) > > > > > L159: > > > > > LBE15: > > > > > movl -304(%ebp), %eax > > > > > leal -12(%ebp), %esp > > > > > popl %ebx > > > > > popl %esi > > > > > popl %edi > > > > > leave > > > > > ret > > > > > > > > > > > > > > > M3File.IsReadable's call to FS.Status is omitted, all files > are > > > > > readable, even if they are not openable, therefore it "finds" > > > > > cm3.cfg in the current directory and then fails to open it.. > > > > > > > > > > later.. > > > > > ..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! Learn > > > more. > > > > > > > > > > > > > Shed those extra pounds with MSN and The Biggest Loser! Learn > more. > > > > Climb to the top of the charts! Play the word scramble challenge > with star power. Play now! From jayk123 at hotmail.com Tue Jan 22 00:01:44 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 21 Jan 2008 23:01:44 +0000 Subject: [M3devel] platform/build_dir is a big tuple? Message-ID: I just realized... As I said, there are several variables. "platform" is a big tuple architecture -- x86, ppc, sparc OS -- NT, Linux, Darwin, Solaris ostype -- win32, posix This probably not -- embodied instead by C runtime and threading model C compiler -- Visual C++, gcc, Sun, Watcom, DigitalMars, Metrowerks and version thereof Linker -- Visual C++, gcc/ld, C runtime -- msvc*, linuxlibc6, cygwin (newline) executable format -- aout, elf, pe (witness the three Linux x86 targets; yes, I know aout is dead and the elf target probably also) oh..maybe object file format -- coff, elf, mach-o Threading model -- vtalarm, pthreads, Win32 backend -- integrated, gcc, C generating Windows library -- X Windows, Windows naming convention -- Unix/Posix, Windows, grumpy Unix Many combinations make sense and work -- two threading models on most systems. Many combinations do not -- Win32 threads on most. Maybe call this "native" threads. Many combinations interoperate -- gcc and Visual C++ output the same .obj file format But you don't want to mix jmpbuf size with the wrong C runtime Naming conventions are sometimes arbitrary, sometimes not, depending on if the linker is given precise paths or like on Mac it probes (is that how a bunch work?). Each variable could contribute a little bit to BUILD_DIR OS -- n, l, d, s This would probably come first and be spelled out. NT, Linux, Solaris architecture -- x, p, s, mi (mips), a (alpha), m6 (m68k or just 6), a (amd64) This might be longer too -- x86, PPC, SPARC C compiler -- ms6, ms7,ms71, ms8, g2, g3, g4, mw6, mw7, mw8, w Linker -- g, m C runtime -- m, g (glibc), c Executable format -- a, e, p (or w for Windows), m (mach-o), pef obj format -- c, e, m threading model -- v, p, w; or v and n (native) backend -- i, g, c Windowing library -- x, w naming convention -- u or p, m (Microsoft) or w (windows), g Ok, I know, crazy, unwieldy, crazy long directory names, but somehow seems true. Imagine there was an "integrated linker". It could consume at least three different obj formats and output at least three different executable formats (elf, pe/coff, mach-o). A smaller version of this however is to let the user set OSTYPE and NAMING_CONVENTION, and perhaps a few other variables (Windowing library is one obviously missing), in the config, honor them, and possibly build up BUILD_DIR in this way. Several variables can be omited..well mainly obj format. That seems to vary the least or vary along with compiler/linker. - 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 Jan 22 00:06:41 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 21 Jan 2008 23:06:41 +0000 Subject: [M3devel] next problem (NT386GNU) In-Reply-To: <1A6EC7D6-32B2-44AD-933F-6976040A7D7F@cs.purdue.edu> References: <6E1E4409-F3D9-4982-B179-2D4C9648FDD0@cs.purdue.edu> <1A6EC7D6-32B2-44AD-933F-6976040A7D7F@cs.purdue.edu> Message-ID: I don't want to deal with learning about CVS branches, please. I can try the __cdecl thunk hack I had nearly working, over in m3-win\import-libs. It's lame compared to my parse.c though. Given void __stdcall Foo(int a, struct {int a, b}), or rather Foo 12, it would generate one source file/.obj void __stdcall F(int a, int b, int c); void __stdcall Fstdcall(int a, int b, int c) { return Fstdcall(a b c); } another source file/.obj void __stdcall Fstdcall(int a, int b, int c); void __cdecl F(int a, int b, int c) { return Fstdcall(a b c); } If I could put parse.c back, I could limit this to functions that take structs. Or at least one function in particular that I know is a current problem. Limiting this hack would be good. - Jay > CC: m3devel at elegosoft.com > From: hosking at cs.purdue.edu > Subject: Re: next problem (NT386GNU) > Date: Mon, 21 Jan 2008 17:32:32 -0500 > To: jayk123 at hotmail.com > > I'd prefer to have the backend do it properly based on properly > declared types. I'd prefer to keep this code out of the current > mainline of parse.c -- you could fork a temporary branch if necessary. > > On Jan 21, 2008, at 5:16 PM, Jay wrote: > > > Understood. Put back my parse.c in the meantime? > > > > Also, the front end could do this, right? And probably without a > > stack? > > It could compute "effective parameter size" and pass that down. > > Backend could then divide by 4 and claim that is the signature, > > that number of parameters. > > > > Would have to see how passing a struct works out anyway -- one > > parameter > > or one per field. > > > > - Jay > > > > > > > CC: m3devel at elegosoft.com > > > From: hosking at cs.purdue.edu > > > Subject: Re: next problem (NT386GNU) > > > Date: Mon, 21 Jan 2008 12:01:28 -0500 > > > To: jayk123 at hotmail.com > > > > > > I just need to fix m3cc/cm3cg to emit the stdcall parameter > > > information for imported procedures. It is simply a matter of not > > > ignoring declare_param for import_procedure chunks. This means > > > maintaining a current_function_decl (and possibly a > > > current_param_count) stack (since import_procedure can occur > > inside a > > > declare_procedure chunk). I know what needs doing, but have not much > > > free time right now... > > > > > > On Jan 21, 2008, at 11:10 AM, Jay wrote: > > > > > > > agreed once I thought about it > > > > I guess that explains left to right as well. > > > > Parameters are always left to right from a higher level point of > > > > view, and if that is wrong, the compiler will reorder. > > > > > > > > "everything" works now > > > > > > > > - Jay > > > > > > > > > > > > > > > > > CC: m3devel at elegosoft.com > > > > > From: hosking at cs.purdue.edu > > > > > Subject: Re: next problem (NT386GNU) > > > > > Date: Mon, 21 Jan 2008 10:54:10 -0500 > > > > > To: jayk123 at hotmail.com > > > > > > > > > > Surely, when using the gcc-based backend then we should make the > > > > > backend handle it. The front end handling it is only need for > > the > > > > > integrated x86 backend. > > > > > > > > > > On Jan 21, 2008, at 2:43 AM, Jay wrote: > > > > > > > > > > > I haven't tested a fix but I see the problem. > > > > > > > > > > > > This function returns a struct. > > > > > > There are two struct returning calling conventions. > > > > > > In one, the backend handles it. Which includes the backend > > knowing > > > > > > there is a return value and its type (or at least its size?). > > > > > > In the other, the front end handles it. In this case, the > > front > > > > end > > > > > > generates passing an extra pointer parameter to the > > function, and > > > > > > the function's return type is void. > > > > > > > > > > > > The NT calling conventions, all of them, are marked as > > front end > > > > > > handling it. I assume that is correct, could check. > > > > > > Everything else is marked as back end handling. > > > > > > > > > > > > Now then, somewhere along the line, gcc figures out that the > > > > return > > > > > > value isn't used here. > > > > > > The point of the function call is to see if it generates an > > > > exception. > > > > > > > > > > > > Gcc removes the function because its return value isn't > > used, and, > > > > > > well, somehow it doesn't know about the exceptions here. > > I'll have > > > > > > to see how "raise" is implemented. I think it's by a call to a > > > > > > function that gets the jmpbuf from a thread local and calls > > > > > > longjmp. (Did I mention it is very inefficient?) > > > > > > > > > > > > There are few possible fixes, but nothing completely > > satisfactory > > > > > > yet in mind. > > > > > > > > > > > > One is have parse.c mark all function calls as having side > > > > affects. > > > > > > This is easy, but overly pessimistic. > > > > > > Another is for the front end to mark struct returning > > functions as > > > > > > having side affects. Better, but still overly pessimistic. > > > > > > Another is for the front end to mark any function that can > > > > raise as > > > > > > having side affects. Getting better still. I don't know how > > to do > > > > > > that but I'll look. This is still a bit overly pessimistic, > > since > > > > > > what you really want to know is, not the function's side > > affects, > > > > > > but whether or not it raised. If the function is inlined, > > the side > > > > > > affects could be optimized away, or if there are enough > > callers > > > > who > > > > > > don't care about the side affects to warrant an > > optimization, and > > > > > > depending on the cost of computing the side affects, another > > > > > > instance of the function could be made that only raises or > > not, > > > > but > > > > > > no side affects otherwise. This is "advanced" optimization the > > > > sort > > > > > > of which tends never to be implemented. > > > > > > > > > > > > I think the best option is anything that can raise is > > marked as > > > > > > having side affects. > > > > > > I'll see if I can figure that out. > > > > > > > > > > > > You can figure this out by looking at m3cgcat -binary < > > > > M3File.mc > > > > > > > 1.txt on PPC_DARWIN and NT386GNU and comparing. > > > > > > > > > > > > Maybe marking all or nearly functions as having side > > effects isn't > > > > > > so bad. > > > > > > Or at least anything returning a struct. That gets parity with > > > > > > other platforms, even if it is a bit pessimistic. > > > > > > I think I'll do that, and ignore figuring out if raise is > > called > > > > > > and using that as a filter. > > > > > > The parity angle is good. > > > > > > > > > > > > The good news for all you Unix lovers :) is this bug is > > relatively > > > > > > portable to Cygwin. > > > > > > True, it is specific to NT386GNU having multiple "calling > > > > > > conventions", which no other platform has. > > > > > > Which again, jokingly, strikes at the question -- What is > > Posix? > > > > > > What do you want from Cygwin? > > > > > > One thing Cygwin does NOT give you is just one calling > > convention, > > > > > > alas, this calling convention business stinks. It's not > > even an NT > > > > > > thing, only an NT386 thing. All the other NT platforms had/ > > have > > > > > > only one calling convention. > > > > > > > > > > > > You can't get far on NT386 without needing to support two > > calling > > > > > > conventions. > > > > > > The "OS" uses mostly __stdcall -- callee pops -- smaller, > > faster. > > > > > > But anything that is varargs, such as printf -- pretty much > > must > > > > > > use caller pops -- __cdecl. > > > > > > As well, __cdecl is the default, so prevalent, and used in > > most C > > > > > > runtime functions. > > > > > > There is also __fastcall that uses like up to two registers > > for > > > > > > parameters. > > > > > > > > > > > > I have seen a platform in which printf did the pop, and it > > > > depended > > > > > > on the number/size of parameters matching the format > > string. On > > > > > > most platforms, printf("", 1, 2, 3, 4) just does nothing, > > but on > > > > > > that platform, it'd unbalance the stack and crash. > > > > > > > > > > > > - Jay > > > > > > > > > > > > From: jayk123 at hotmail.com > > > > > > To: hosking at cs.purdue.edu > > > > > > CC: m3devel at elegosoft.com > > > > > > Subject: next problem (NT386GNU) > > > > > > Date: Mon, 21 Jan 2008 05:47:28 +0000 > > > > > > > > > > > > M3File.m3 > > > > > > > > > > > > PROCEDURE IsReadable (path: TEXT): BOOLEAN = > > > > > > (* We don't really check for readablitiy, just for > > existence *) > > > > > > BEGIN > > > > > > TRY > > > > > > EVAL FS.Status (path); line 82 > > > > > > RETURN TRUE; > > > > > > EXCEPT OSError.E => > > > > > > RETURN FALSE; > > > > > > END; > > > > > > END IsReadable; > > > > > > > > > > > > -----LINE 82 ----- > > > > > > start_call_direct p.25 0 Struct > > > > > > load_address v.25 0 > > > > > > pop_param Addr > > > > > > load v.26 0 Addr Addr > > > > > > pop_param Addr > > > > > > call_direct p.25 Struct > > > > > > pop Struct > > > > > > > > > > > > > > > > > > > > > > > > I'm guessing you only see an import for the first call on > > purpose, > > > > > > but I will compare with PPC_DARWIN: > > > > > > > > > > > > -----LINE 46 ----- > > > > > > import_procedure FS__Status 2 Struct 0 p.25 > > > > > > declare_indirect 2078421550 -2078421551 > > > > > > declare_param _return 4 4 Addr 2078421550 F F 50 v.62 > > > > > > declare_param p 4 4 Addr 1358456180 F F 50 v.63 > > > > > > start_call_direct p.25 0 Struct > > > > > > load_address v.13 0 > > > > > > pop_param Addr > > > > > > load v.14 0 Addr Addr > > > > > > pop_param Addr > > > > > > call_direct p.25 Struct > > > > > > pop Struct > > > > > > > > > > > > > > > > > > .globl _M3File__IsReadable > > > > > > .def _M3File__IsReadable; .scl 2; .type 32; .endef > > > > > > _M3File__IsReadable: > > > > > > .stabn 68,0,178,LM93-_M3File__IsReadable > > > > > > LM93: > > > > > > pushl %ebp > > > > > > movl %esp, %ebp > > > > > > pushl %edi > > > > > > pushl %esi > > > > > > pushl %ebx > > > > > > subl $300, %esp > > > > > > LBB15: > > > > > > .stabn 68,0,181,LM94-_M3File__IsReadable > > > > > > LM94: > > > > > > L157: > > > > > > movl -280(%ebp), %eax > > > > > > andl $0, %eax > > > > > > orl $_L_1, %eax > > > > > > movl %eax, -280(%ebp) > > > > > > movl -284(%ebp), %eax > > > > > > andl $0, %eax > > > > > > movl %eax, -284(%ebp) > > > > > > subl $12, %esp > > > > > > leal -288(%ebp), %eax > > > > > > pushl %eax > > > > > > call _RTHooks__PushEFrame > > > > > > addl $16, %esp > > > > > > leal -288(%ebp), %eax > > > > > > addl $48, %eax > > > > > > subl $12, %esp > > > > > > pushl %eax > > > > > > call __setjmp > > > > > > addl $16, %esp > > > > > > testb %al, %al > > > > > > jne L158 > > > > > > .stabn 68,0,183,LM95-_M3File__IsReadable > > > > > > LM95: > > > > > > movl -288(%ebp), %eax > > > > > > subl $12, %esp > > > > > > pushl %eax > > > > > > call _RTHooks__PopEFrame > > > > > > addl $16, %esp > > > > > > movl $1, -304(%ebp) > > > > > > jmp L159 > > > > > > L158: > > > > > > .stabn 68,0,185,LM96-_M3File__IsReadable > > > > > > LM96: > > > > > > movl $0, -304(%ebp) > > > > > > L159: > > > > > > LBE15: > > > > > > movl -304(%ebp), %eax > > > > > > leal -12(%ebp), %esp > > > > > > popl %ebx > > > > > > popl %esi > > > > > > popl %edi > > > > > > leave > > > > > > ret > > > > > > > > > > > > > > > > > > M3File.IsReadable's call to FS.Status is omitted, all files > > are > > > > > > readable, even if they are not openable, therefore it "finds" > > > > > > cm3.cfg in the current directory and then fails to open it.. > > > > > > > > > > > > later.. > > > > > > ..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! Learn > > > > more. > > > > > > > > > > > > > > > > > Shed those extra pounds with MSN and The Biggest Loser! Learn > > more. > > > > > > > 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 jayk123 at hotmail.com Tue Jan 22 00:17:32 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 21 Jan 2008 23:17:32 +0000 Subject: [M3devel] branching a file? In-Reply-To: <1A6EC7D6-32B2-44AD-933F-6976040A7D7F@cs.purdue.edu> References: <6E1E4409-F3D9-4982-B179-2D4C9648FDD0@cs.purdue.edu> <1A6EC7D6-32B2-44AD-933F-6976040A7D7F@cs.purdue.edu> Message-ID: In Perforce, if you want to make a file that starts out as a copy of another, but then diverges, NOT in a different branch, but one that will coexist in a different file name or path, you can use "integrate" to create the file initially. Does CVS have that? Or just copy and be done? e.g.: p4 integrate NT386GNU NT386_MINGWIN or p4 integrate NT386 NT386_MINGWIN (The first is more accurate, these files are almost identical, and really I'd like to have less duplication here somehow, like by copying all of the config files to bin\config and having them include bits and pieces -- reasonable? It used to look something like that, right?) (Integrate is also the command for merging branches. I little strange naming there all around.) - 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 Jan 22 00:56:27 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 21 Jan 2008 18:56:27 -0500 Subject: [M3devel] next problem (NT386GNU) In-Reply-To: References: <6E1E4409-F3D9-4982-B179-2D4C9648FDD0@cs.purdue.edu> <1A6EC7D6-32B2-44AD-933F-6976040A7D7F@cs.purdue.edu> Message-ID: I should be able to get cm3cg doing the right thing by the end of the week. On Jan 21, 2008, at 6:06 PM, Jay wrote: > I don't want to deal with learning about CVS branches, please. > > I can try the __cdecl thunk hack I had nearly working, over in m3- > win\import-libs. > It's lame compared to my parse.c though. > > Given void __stdcall Foo(int a, struct {int a, b}), or rather Foo 12, > > it would generate > > one source file/.obj > void __stdcall F(int a, int b, int c); > void __stdcall Fstdcall(int a, int b, int c) { return Fstdcall > (a b c); } > > another source file/.obj > void __stdcall Fstdcall(int a, int b, int c); > void __cdecl F(int a, int b, int c) { return Fstdcall(a b c); } > > If I could put parse.c back, I could limit this to functions that > take structs. > Or at least one function in particular that I know is a current > problem. > Limiting this hack would be good. > > - Jay > > > > CC: m3devel at elegosoft.com > > From: hosking at cs.purdue.edu > > Subject: Re: next problem (NT386GNU) > > Date: Mon, 21 Jan 2008 17:32:32 -0500 > > To: jayk123 at hotmail.com > > > > I'd prefer to have the backend do it properly based on properly > > declared types. I'd prefer to keep this code out of the current > > mainline of parse.c -- you could fork a temporary branch if > necessary. > > > > On Jan 21, 2008, at 5:16 PM, Jay wrote: > > > > > Understood. Put back my parse.c in the meantime? > > > > > > Also, the front end could do this, right? And probably without a > > > stack? > > > It could compute "effective parameter size" and pass that down. > > > Backend could then divide by 4 and claim that is the signature, > > > that number of parameters. > > > > > > Would have to see how passing a struct works out anyway -- one > > > parameter > > > or one per field. > > > > > > - Jay > > > > > > > > > > CC: m3devel at elegosoft.com > > > > From: hosking at cs.purdue.edu > > > > Subject: Re: next problem (NT386GNU) > > > > Date: Mon, 21 Jan 2008 12:01:28 -0500 > > > > To: jayk123 at hotmail.com > > > > > > > > I just need to fix m3cc/cm3cg to emit the stdcall parameter > > > > information for imported procedures. It is simply a matter of > not > > > > ignoring declare_param for import_procedure chunks. This means > > > > maintaining a current_function_decl (and possibly a > > > > current_param_count) stack (since import_procedure can occur > > > inside a > > > > declare_procedure chunk). I know what needs doing, but have > not much > > > > free time right now... > > > > > > > > On Jan 21, 2008, at 11:10 AM, Jay wrote: > > > > > > > > > agreed once I thought about it > > > > > I guess that explains left to right as well. > > > > > Parameters are always left to right from a higher level > point of > > > > > view, and if that is wrong, the compiler will reorder. > > > > > > > > > > "everything" works now > > > > > > > > > > - Jay > > > > > > > > > > > > > > > > > > > > > CC: m3devel at elegosoft.com > > > > > > From: hosking at cs.purdue.edu > > > > > > Subject: Re: next problem (NT386GNU) > > > > > > Date: Mon, 21 Jan 2008 10:54:10 -0500 > > > > > > To: jayk123 at hotmail.com > > > > > > > > > > > > Surely, when using the gcc-based backend then we should > make the > > > > > > backend handle it. The front end handling it is only need > for > > > the > > > > > > integrated x86 backend. > > > > > > > > > > > > On Jan 21, 2008, at 2:43 AM, Jay wrote: > > > > > > > > > > > > > I haven't tested a fix but I see the problem. > > > > > > > > > > > > > > This function returns a struct. > > > > > > > There are two struct returning calling conventions. > > > > > > > In one, the backend handles it. Which includes the backend > > > knowing > > > > > > > there is a return value and its type (or at least its > size?). > > > > > > > In the other, the front end handles it. In this case, the > > > front > > > > > end > > > > > > > generates passing an extra pointer parameter to the > > > function, and > > > > > > > the function's return type is void. > > > > > > > > > > > > > > The NT calling conventions, all of them, are marked as > > > front end > > > > > > > handling it. I assume that is correct, could check. > > > > > > > Everything else is marked as back end handling. > > > > > > > > > > > > > > Now then, somewhere along the line, gcc figures out > that the > > > > > return > > > > > > > value isn't used here. > > > > > > > The point of the function call is to see if it > generates an > > > > > exception. > > > > > > > > > > > > > > Gcc removes the function because its return value isn't > > > used, and, > > > > > > > well, somehow it doesn't know about the exceptions here. > > > I'll have > > > > > > > to see how "raise" is implemented. I think it's by a > call to a > > > > > > > function that gets the jmpbuf from a thread local and > calls > > > > > > > longjmp. (Did I mention it is very inefficient?) > > > > > > > > > > > > > > There are few possible fixes, but nothing completely > > > satisfactory > > > > > > > yet in mind. > > > > > > > > > > > > > > One is have parse.c mark all function calls as having side > > > > > affects. > > > > > > > This is easy, but overly pessimistic. > > > > > > > Another is for the front end to mark struct returning > > > functions as > > > > > > > having side affects. Better, but still overly pessimistic. > > > > > > > Another is for the front end to mark any function that can > > > > > raise as > > > > > > > having side affects. Getting better still. I don't know > how > > > to do > > > > > > > that but I'll look. This is still a bit overly > pessimistic, > > > since > > > > > > > what you really want to know is, not the function's side > > > affects, > > > > > > > but whether or not it raised. If the function is inlined, > > > the side > > > > > > > affects could be optimized away, or if there are enough > > > callers > > > > > who > > > > > > > don't care about the side affects to warrant an > > > optimization, and > > > > > > > depending on the cost of computing the side affects, > another > > > > > > > instance of the function could be made that only raises or > > > not, > > > > > but > > > > > > > no side affects otherwise. This is "advanced" > optimization the > > > > > sort > > > > > > > of which tends never to be implemented. > > > > > > > > > > > > > > I think the best option is anything that can raise is > > > marked as > > > > > > > having side affects. > > > > > > > I'll see if I can figure that out. > > > > > > > > > > > > > > You can figure this out by looking at m3cgcat -binary < > > > > > M3File.mc > > > > > > > > 1.txt on PPC_DARWIN and NT386GNU and comparing. > > > > > > > > > > > > > > Maybe marking all or nearly functions as having side > > > effects isn't > > > > > > > so bad. > > > > > > > Or at least anything returning a struct. That gets > parity with > > > > > > > other platforms, even if it is a bit pessimistic. > > > > > > > I think I'll do that, and ignore figuring out if raise is > > > called > > > > > > > and using that as a filter. > > > > > > > The parity angle is good. > > > > > > > > > > > > > > The good news for all you Unix lovers :) is this bug is > > > relatively > > > > > > > portable to Cygwin. > > > > > > > True, it is specific to NT386GNU having multiple "calling > > > > > > > conventions", which no other platform has. > > > > > > > Which again, jokingly, strikes at the question -- What is > > > Posix? > > > > > > > What do you want from Cygwin? > > > > > > > One thing Cygwin does NOT give you is just one calling > > > convention, > > > > > > > alas, this calling convention business stinks. It's not > > > even an NT > > > > > > > thing, only an NT386 thing. All the other NT platforms > had/ > > > have > > > > > > > only one calling convention. > > > > > > > > > > > > > > You can't get far on NT386 without needing to support two > > > calling > > > > > > > conventions. > > > > > > > The "OS" uses mostly __stdcall -- callee pops -- smaller, > > > faster. > > > > > > > But anything that is varargs, such as printf -- pretty > much > > > must > > > > > > > use caller pops -- __cdecl. > > > > > > > As well, __cdecl is the default, so prevalent, and used in > > > most C > > > > > > > runtime functions. > > > > > > > There is also __fastcall that uses like up to two > registers > > > for > > > > > > > parameters. > > > > > > > > > > > > > > I have seen a platform in which printf did the pop, and it > > > > > depended > > > > > > > on the number/size of parameters matching the format > > > string. On > > > > > > > most platforms, printf("", 1, 2, 3, 4) just does nothing, > > > but on > > > > > > > that platform, it'd unbalance the stack and crash. > > > > > > > > > > > > > > - Jay > > > > > > > > > > > > > > From: jayk123 at hotmail.com > > > > > > > To: hosking at cs.purdue.edu > > > > > > > CC: m3devel at elegosoft.com > > > > > > > Subject: next problem (NT386GNU) > > > > > > > Date: Mon, 21 Jan 2008 05:47:28 +0000 > > > > > > > > > > > > > > M3File.m3 > > > > > > > > > > > > > > PROCEDURE IsReadable (path: TEXT): BOOLEAN = > > > > > > > (* We don't really check for readablitiy, just for > > > existence *) > > > > > > > BEGIN > > > > > > > TRY > > > > > > > EVAL FS.Status (path); line 82 > > > > > > > RETURN TRUE; > > > > > > > EXCEPT OSError.E => > > > > > > > RETURN FALSE; > > > > > > > END; > > > > > > > END IsReadable; > > > > > > > > > > > > > > -----LINE 82 ----- > > > > > > > start_call_direct p.25 0 Struct > > > > > > > load_address v.25 0 > > > > > > > pop_param Addr > > > > > > > load v.26 0 Addr Addr > > > > > > > pop_param Addr > > > > > > > call_direct p.25 Struct > > > > > > > pop Struct > > > > > > > > > > > > > > > > > > > > > > > > > > > > I'm guessing you only see an import for the first call on > > > purpose, > > > > > > > but I will compare with PPC_DARWIN: > > > > > > > > > > > > > > -----LINE 46 ----- > > > > > > > import_procedure FS__Status 2 Struct 0 p.25 > > > > > > > declare_indirect 2078421550 -2078421551 > > > > > > > declare_param _return 4 4 Addr 2078421550 F F 50 v.62 > > > > > > > declare_param p 4 4 Addr 1358456180 F F 50 v.63 > > > > > > > start_call_direct p.25 0 Struct > > > > > > > load_address v.13 0 > > > > > > > pop_param Addr > > > > > > > load v.14 0 Addr Addr > > > > > > > pop_param Addr > > > > > > > call_direct p.25 Struct > > > > > > > pop Struct > > > > > > > > > > > > > > > > > > > > > .globl _M3File__IsReadable > > > > > > > .def _M3File__IsReadable; .scl 2; .type 32; .endef > > > > > > > _M3File__IsReadable: > > > > > > > .stabn 68,0,178,LM93-_M3File__IsReadable > > > > > > > LM93: > > > > > > > pushl %ebp > > > > > > > movl %esp, %ebp > > > > > > > pushl %edi > > > > > > > pushl %esi > > > > > > > pushl %ebx > > > > > > > subl $300, %esp > > > > > > > LBB15: > > > > > > > .stabn 68,0,181,LM94-_M3File__IsReadable > > > > > > > LM94: > > > > > > > L157: > > > > > > > movl -280(%ebp), %eax > > > > > > > andl $0, %eax > > > > > > > orl $_L_1, %eax > > > > > > > movl %eax, -280(%ebp) > > > > > > > movl -284(%ebp), %eax > > > > > > > andl $0, %eax > > > > > > > movl %eax, -284(%ebp) > > > > > > > subl $12, %esp > > > > > > > leal -288(%ebp), %eax > > > > > > > pushl %eax > > > > > > > call _RTHooks__PushEFrame > > > > > > > addl $16, %esp > > > > > > > leal -288(%ebp), %eax > > > > > > > addl $48, %eax > > > > > > > subl $12, %esp > > > > > > > pushl %eax > > > > > > > call __setjmp > > > > > > > addl $16, %esp > > > > > > > testb %al, %al > > > > > > > jne L158 > > > > > > > .stabn 68,0,183,LM95-_M3File__IsReadable > > > > > > > LM95: > > > > > > > movl -288(%ebp), %eax > > > > > > > subl $12, %esp > > > > > > > pushl %eax > > > > > > > call _RTHooks__PopEFrame > > > > > > > addl $16, %esp > > > > > > > movl $1, -304(%ebp) > > > > > > > jmp L159 > > > > > > > L158: > > > > > > > .stabn 68,0,185,LM96-_M3File__IsReadable > > > > > > > LM96: > > > > > > > movl $0, -304(%ebp) > > > > > > > L159: > > > > > > > LBE15: > > > > > > > movl -304(%ebp), %eax > > > > > > > leal -12(%ebp), %esp > > > > > > > popl %ebx > > > > > > > popl %esi > > > > > > > popl %edi > > > > > > > leave > > > > > > > ret > > > > > > > > > > > > > > > > > > > > > M3File.IsReadable's call to FS.Status is omitted, all > files > > > are > > > > > > > readable, even if they are not openable, therefore it > "finds" > > > > > > > cm3.cfg in the current directory and then fails to open > it.. > > > > > > > > > > > > > > later.. > > > > > > > ..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! > Learn > > > > > more. > > > > > > > > > > > > > > > > > > > > > Shed those extra pounds with MSN and The Biggest Loser! Learn > > > more. > > > > > > > > > > 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". Check it out. From darko at darko.org Tue Jan 22 06:37:40 2008 From: darko at darko.org (Darko) Date: Mon, 21 Jan 2008 21:37:40 -0800 Subject: [M3devel] NT386GNU distribution available In-Reply-To: References: Message-ID: <54D13F89-4394-4508-AA47-531956BC43F3@darko.org> Do you have a link for the distribution, or did I miss something? - Darko On 21/01/2008, at 8:41 AM, Jay wrote: > Here, in my user directory on birch, is the first CM3 NT386GNU > release. > It is MinGWin based FOR NOW. > This needs to be changed SOON. > > Install MinGWin. (Search the web for it.) > set PATH=c:\MinGW\bin;%PATH% > > (The default install location is c:\MinGW, not MinGWin.) > > The MinGWin that Qt gives you is too old, from around 2004. > It doesn't support "response files" (aka long command lines). > > If you want to rebuild m3cg: > > Install MSys. It is at the same place as MinGWin. > set PATH=c:\msys\1.0\bin;%PATH% > > else consider > > set OMIT_GCC=yes > > depending on if you run the various scripts. > > If you install to these exact paths, scripts\python\pylib.py > will use them automatically. > > Optionally install Python. I recommend it. > > Extract one or more of the archives. > They will extract to like: > > cm3-min-WIN32-NT386GNU-d5.5.1\bin\cm3.exe > > You can rename it cm3, or for purposes of backup/restore, > xcopy /fivery \cm3-min-WIN32-NT386GNU-d5.5.1 \cm3 > > (For extra good testing, first rmdir /q/s \cm3.) > > set PATH=c:\cm3\bin;%PATH% > > This is important, since various code will tend to assume NT386 > unless overridden. > > set CM3_TARGET=NT386GNU > > Someone please weigh in on zip vs. tar.bz2 on the other Win32 > platforms. > For reference, MinGWin doesn't include tar/bzip2, MSys does, Cygwin > has tons of optional stuff, they are in there, probably the base. > > And then go to scripts\python and run whatever: > upgrade > or make-dist > or do-cm3-core > or do-cm3-base > but not currently do-cm3-std > > scripts\win\upgrade works too. > > Do remember to set CM3_TARGET=NT386GNU. > > You will probably at some point be prompted to set CM3_ROOT to the > root of the source > tree as well. If you run "scripts", it will be set for you. > If you cd around and run cm3, it won't. > > \cm3\bin\cm3.cfg delegates out to the source tree. > Except the one in the distributions do not. > But if you run upgrade, you'll have such a thing. > > If you want to rebuild cm3cg from source: > cd m3-sys\m3cc\gcc\gcc\m3cg > cvs update -j 1.46 -j 1.45 parse.c > > or thereabouts to get back enough of a __stdcall fix to build a lot. > > If you want to bootstrap without a previous NT386GNU distribution > but with > a previous NT386 build, try like this: > > Get a working NT386 system. > Get current source (except parse.c). > If your system is not current, > scripts\python\upgrade > This will work as far back as cm3-min-WIN32-NT386-5.1.3. > scripts\python\bootntgnu > which is really just roughly: > do-pkg realclean m3core libm3 m3cc > do-pkg buildship m3core libm3 m3cc > set CM3_TARGET=NT386GNU > Now you have the equivalent of the minimum distribution and > can build whatever. > do-pkg .... > > If you want to rollback a bit but not completely, scripts\win > \pkggnu_clean.cmd is > very simple and just deletes all the NT386GNU directories under > $INSTALLROOT\pkg. > > There are "min", "core", and "base" distributions. > Kind of subtle names, eh? > "min" is sufficient. > The binaries are all not "strippped". > > Last minute errata: > There is bin\cm3.cfg and bin\NT386GNU. They are identical. > The intent was only to have cm3.cfg there. > > The system builds itself, so that's pretty good. > > I forgot to include m3gdb, but it should probably be in a separate > "GNU" archive? > > Someone move the files to a web download place? > (and you can move, not copy, I can easily recreate the files) > > - Jay > > Shed those extra pounds with MSN and The Biggest Loser! Learn more. From wagner at elegosoft.com Tue Jan 22 08:10:49 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 22 Jan 2008 08:10:49 +0100 Subject: [M3devel] next problem (NT386GNU) In-Reply-To: References: <6E1E4409-F3D9-4982-B179-2D4C9648FDD0@cs.purdue.edu> <1A6EC7D6-32B2-44AD-933F-6976040A7D7F@cs.purdue.edu> Message-ID: <20080122081049.74tzfvozwo4wwwow@mail.elegosoft.com> Quoting Jay : > I don't want to deal with learning about CVS branches, please. I don't understand the problems some people seem to have with CVS. Creating a branch is really simple: o create a branch tag, for example: cvs tag -b devel_nt386gnu_gcc_opt files(s) o update to that branch: cvs up -r devel_nt386gnu_gcc_opt files(s) That's it. The tag is now `sticky' on the files, i.e. remembered in the CVS/Entries files in your workspace. From now on you're using the branch for the mentioned files. To restore them to the latest main trunk version, use cvs up -A files(s) And Jay, as a Windows user you probably don't like to use the cvs commandline in Cygwin; just install CVS-NT and tortoise (Randy did, too). It may be more convenient for you. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Jan 22 08:26:25 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 22 Jan 2008 07:26:25 +0000 Subject: [M3devel] NT386GNU distribution available In-Reply-To: <54D13F89-4394-4508-AA47-531956BC43F3@darko.org> References: <54D13F89-4394-4508-AA47-531956BC43F3@darko.org> Message-ID: Sorry I do not. All I can do is scp the files to my home directory on birch and have "someone else" make them available otherwise. I made them world readable. If you have access to birch, look in ~jkrell. I'm not an ssh/scp expert, but this might work: scp yourname at m3.elegosoft.com:~jkrell/*.bz2 . I don't now if ~ works here. I should have listed the file names, sorry. Later. I think I deleted all the native Win32 files so that will net you three files all relevant. Or if you can ls in the directory...the "min" one imho is the most interesting, you can build the others easily from it. Maybe try bootstrapping as kind of detailed below? :) (That should be tested as well.) Maybe Trestle tonight, we'll see.. - Jay > CC: m3devel at elegosoft.com> From: darko at darko.org> To: jayk123 at hotmail.com> Subject: Re: [M3devel] NT386GNU distribution available> Date: Mon, 21 Jan 2008 21:37:40 -0800> > Do you have a link for the distribution, or did I miss something?> > - Darko> > On 21/01/2008, at 8:41 AM, Jay wrote:> > > Here, in my user directory on birch, is the first CM3 NT386GNU > > release.> > It is MinGWin based FOR NOW.> > This needs to be changed SOON.> >> > Install MinGWin. (Search the web for it.)> > set PATH=c:\MinGW\bin;%PATH%> >> > (The default install location is c:\MinGW, not MinGWin.)> >> > The MinGWin that Qt gives you is too old, from around 2004.> > It doesn't support "response files" (aka long command lines).> >> > If you want to rebuild m3cg:> >> > Install MSys. It is at the same place as MinGWin.> > set PATH=c:\msys\1.0\bin;%PATH%> >> > else consider> >> > set OMIT_GCC=yes> >> > depending on if you run the various scripts.> >> > If you install to these exact paths, scripts\python\pylib.py> > will use them automatically.> >> > Optionally install Python. I recommend it.> >> > Extract one or more of the archives.> > They will extract to like:> >> > cm3-min-WIN32-NT386GNU-d5.5.1\bin\cm3.exe> >> > You can rename it cm3, or for purposes of backup/restore,> > xcopy /fivery \cm3-min-WIN32-NT386GNU-d5.5.1 \cm3> >> > (For extra good testing, first rmdir /q/s \cm3.)> >> > set PATH=c:\cm3\bin;%PATH%> >> > This is important, since various code will tend to assume NT386 > > unless overridden.> >> > set CM3_TARGET=NT386GNU> >> > Someone please weigh in on zip vs. tar.bz2 on the other Win32 > > platforms.> > For reference, MinGWin doesn't include tar/bzip2, MSys does, Cygwin> > has tons of optional stuff, they are in there, probably the base.> >> > And then go to scripts\python and run whatever:> > upgrade> > or make-dist> > or do-cm3-core> > or do-cm3-base> > but not currently do-cm3-std> >> > scripts\win\upgrade works too.> >> > Do remember to set CM3_TARGET=NT386GNU.> >> > You will probably at some point be prompted to set CM3_ROOT to the > > root of the source> > tree as well. If you run "scripts", it will be set for you.> > If you cd around and run cm3, it won't.> >> > \cm3\bin\cm3.cfg delegates out to the source tree.> > Except the one in the distributions do not.> > But if you run upgrade, you'll have such a thing.> >> > If you want to rebuild cm3cg from source:> > cd m3-sys\m3cc\gcc\gcc\m3cg> > cvs update -j 1.46 -j 1.45 parse.c> >> > or thereabouts to get back enough of a __stdcall fix to build a lot.> >> > If you want to bootstrap without a previous NT386GNU distribution > > but with> > a previous NT386 build, try like this:> >> > Get a working NT386 system.> > Get current source (except parse.c).> > If your system is not current,> > scripts\python\upgrade> > This will work as far back as cm3-min-WIN32-NT386-5.1.3.> > scripts\python\bootntgnu> > which is really just roughly:> > do-pkg realclean m3core libm3 m3cc> > do-pkg buildship m3core libm3 m3cc> > set CM3_TARGET=NT386GNU> > Now you have the equivalent of the minimum distribution and > > can build whatever.> > do-pkg ....> >> > If you want to rollback a bit but not completely, scripts\win > > \pkggnu_clean.cmd is> > very simple and just deletes all the NT386GNU directories under > > $INSTALLROOT\pkg.> >> > There are "min", "core", and "base" distributions.> > Kind of subtle names, eh?> > "min" is sufficient.> > The binaries are all not "strippped".> >> > Last minute errata:> > There is bin\cm3.cfg and bin\NT386GNU. They are identical.> > The intent was only to have cm3.cfg there.> >> > The system builds itself, so that's pretty good.> >> > I forgot to include m3gdb, but it should probably be in a separate > > "GNU" archive?> >> > Someone move the files to a web download place?> > (and you can move, not copy, I can easily recreate the files)> >> > - Jay> >> > 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 jayk123 at hotmail.com Tue Jan 22 08:34:35 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 22 Jan 2008 07:34:35 +0000 Subject: [M3devel] next problem (NT386GNU) In-Reply-To: <20080122081049.74tzfvozwo4wwwow@mail.elegosoft.com> References: <6E1E4409-F3D9-4982-B179-2D4C9648FDD0@cs.purdue.edu> <1A6EC7D6-32B2-44AD-933F-6976040A7D7F@cs.purdue.edu> <20080122081049.74tzfvozwo4wwwow@mail.elegosoft.com> Message-ID: Olaf, yes and no. How do I then bring the files into mainline? Which Tinderbox is testing them? This is impossible question probably, because Tinderbox for private changes probably doesn't scale well. But it would be nice. And other than private branches, submitting diffs would be nice. Or, as well, these can be crutches for bad changes, and people can abuse the Tinderbox. It's tough though, because a multi machine Tinderbox can always easily do much more diligence than one developer and his local machines. (What's the Win32 Tinderbox story, I wonder? I guess first I can see if Mozilla has one, and if not, it probably doesn't exist, if so, it does :) ) I don't mind the command line, but I'm a bit slow learning new tools. I find new source control systems daunting. I'm quite expert with Perforce though including branching, integrating, resolving, etc.. You don't have to be in Cygwin (sh) to use cvs, but it's true, one very annoying thing about all these forward-slash-requiring tools is I lose the usefulness of command line completion in cmd. Cmd is quite good at editing command lines, keeping output and command line history (set the scrollback to 9999), copy/paste, and is very fast, nothing else that I have tried competes. Most are even merely slower on their video output except maybe the actual text ones. The F8 feature, command line completion against history, which I can't explain well, is really great. MSys comes up with awful colors that I couldn't figure out how to change. Cygwin makes all your paths be /cygdrive/c/... which is just ugly and long. MSys/MinGWin are much nicer with merely /c... I installed TortoiseCVS but it didn't work..I need to look into how to get it to use ssh. But as well, if my work doesn't suck too much, it should be fine for mainline. Look at diffs is really also slow. I've done best by always saving away an .orig file and then windiff. Otherwise 1) is very slow 2) textual diffs...I use the command line all the time, but for viewing diffs...it's really insufficient. - Jay > Date: Tue, 22 Jan 2008 08:10:49 +0100> From: wagner at elegosoft.com> To: m3devel at elegosoft.com> Subject: Re: [M3devel] next problem (NT386GNU)> > Quoting Jay :> > > I don't want to deal with learning about CVS branches, please.> > I don't understand the problems some people seem to have with CVS.> Creating a branch is really simple:> > o create a branch tag, for example:> > cvs tag -b devel_nt386gnu_gcc_opt files(s)> > o update to that branch:> > cvs up -r devel_nt386gnu_gcc_opt files(s)> > That's it. The tag is now `sticky' on the files, i.e. remembered> in the CVS/Entries files in your workspace. From now on you're> using the branch for the mentioned files. To restore them to the> latest main trunk version, use> > cvs up -A files(s)> > And Jay, as a Windows user you probably don't like to use the cvs> commandline in Cygwin; just install CVS-NT and tortoise (Randy did,> too). It may be more convenient for you.> > Olaf> -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 Tue Jan 22 08:53:03 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 22 Jan 2008 08:53:03 +0100 Subject: [M3devel] NT386GNU distribution available In-Reply-To: References: <54D13F89-4394-4508-AA47-531956BC43F3@darko.org> Message-ID: <20080122085303.zxbo59ixickk4gos@mail.elegosoft.com> Quoting Jay : > Sorry I do not. All I can do is scp the files to my home directory > on birch and have "someone else" make them available otherwise. > I made them world readable. You could at least make the appropriate entries to the www/download.html page in the same format as the others are. Perhaps we should just add a directory with an automatic index generation for this kind of new archives like for the generated snapshots. I've now added the links. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Jan 22 09:20:52 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 22 Jan 2008 09:20:52 +0100 Subject: [M3devel] next problem (NT386GNU) In-Reply-To: References: <6E1E4409-F3D9-4982-B179-2D4C9648FDD0@cs.purdue.edu> <1A6EC7D6-32B2-44AD-933F-6976040A7D7F@cs.purdue.edu> <20080122081049.74tzfvozwo4wwwow@mail.elegosoft.com> Message-ID: <20080122092052.4osfqyffkkggcs48@mail.elegosoft.com> Quoting Jay : > Olaf, yes and no. > > How do I then bring the files into mainline? A merge is done by using -j (join) insted of -r during update: cvs up -j tag1 [-j tag2] file(s) > Which Tinderbox is testing them? Currently no platforms except for FreeBSD 6 and Debian Linux are tested and displayed in the tinderbox. Unless you or Randy set up a build host running the regression test scripts, it may take a little bit longer for daily test results on Windows to be available. But I'm still waiting for the result shipping implementation and procedure description anyway. Should be available soon, I've heard ;-) Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Jan 22 09:32:52 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 22 Jan 2008 08:32:52 +0000 Subject: [M3devel] NT386GNU distribution available In-Reply-To: <20080122085303.zxbo59ixickk4gos@mail.elegosoft.com> References: <54D13F89-4394-4508-AA47-531956BC43F3@darko.org> <20080122085303.zxbo59ixickk4gos@mail.elegosoft.com> Message-ID: I add entries in download.html and they say ~jkrell/foo or /usr/home/jkrell/foo and the machine updates download.html every so often and done? I didn't/don't know if I could do anything from my end, or what it would be. Thanks! - Jay > Date: Tue, 22 Jan 2008 08:53:03 +0100> From: wagner at elegosoft.com> To: m3devel at elegosoft.com> Subject: Re: [M3devel] NT386GNU distribution available> > Quoting Jay :> > > Sorry I do not. All I can do is scp the files to my home directory > > on birch and have "someone else" make them available otherwise.> > I made them world readable.> > You could at least make the appropriate entries to the www/download.html> page in the same format as the others are.> > Perhaps we should just add a directory with an automatic index generation> for this kind of new archives like for the generated snapshots.> > I've now added the links.> > Olaf> -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 Jan 22 09:43:20 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 22 Jan 2008 08:43:20 +0000 Subject: [M3devel] next problem (NT386GNU) In-Reply-To: <20080122092052.4osfqyffkkggcs48@mail.elegosoft.com> References: <6E1E4409-F3D9-4982-B179-2D4C9648FDD0@cs.purdue.edu> <1A6EC7D6-32B2-44AD-933F-6976040A7D7F@cs.purdue.edu> <20080122081049.74tzfvozwo4wwwow@mail.elegosoft.com> <20080122092052.4osfqyffkkggcs48@mail.elegosoft.com> Message-ID: Any idea how? Oh I see...sounds easier than expected..I was thinking of doing cross builds on your machines or finding some Win32 hosting/colocation, but.. http://en.wikipedia.org/wiki/Tinderbox_%28software%29 >> Mozilla's tinderbox is written in Perl >> Tinderbox is composed of a server with clients running builds and reporting status via mail. probably easy enough to just run it on a machine of mine.. http://www.mozilla.org/projects/tinderbox/index.html -- version 2 http://www.johnkeiser.com/mozilla/tbox3.html -- version 3 - Jay > Date: Tue, 22 Jan 2008 09:20:52 +0100> From: wagner at elegosoft.com> To: jayk123 at hotmail.com> CC: m3devel at elegosoft.com> Subject: RE: [M3devel] next problem (NT386GNU)> > Quoting Jay :> > > Olaf, yes and no.> >> > How do I then bring the files into mainline?> > A merge is done by using -j (join) insted of -r during update:> > cvs up -j tag1 [-j tag2] file(s)> > > Which Tinderbox is testing them?> > Currently no platforms except for FreeBSD 6 and Debian Linux are> tested and displayed in the tinderbox.> > Unless you or Randy set up a build host running the regression test> scripts, it may take a little bit longer for daily test results on> Windows to be available.> > But I'm still waiting for the result shipping implementation and> procedure description anyway. Should be available soon, I've heard ;-)> > Olaf> -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 Tue Jan 22 11:48:56 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 22 Jan 2008 10:48:56 +0000 Subject: [M3devel] platform/build_dir is a big tuple? In-Reply-To: References: Message-ID: Final answer? I played around with this but just can't accept platforms/build_dirs like: ntx86msmsmscm3msn ntx86gccgcccm3cgmsn ntx86gccgcccm3cgxn ntx86-gggggmn ntx86-ggixn ntx86_mmmimm Ok, I have one more name here, and then a bit of a change, or a stronger statement of something I had already said. NT386MINGNU Ok, I think we (me!) are confusing host and target, MOSTLY. And cm3 might not have them quite divided appropriately. What is a "host"? What is a "target"? MinGWin and Visual C++ output similar results, targetingthe same runtime (usually), threading library, windowing library.There is a chance for exception handling to diverge however.Well, speaking of Visual C++ the C/C++ compiler and MinGWinthe gcc environment, yes, very different, not interoperable.MinGWin uses what gcc calls "sjlj" -- setjmp/longjmp exceptions.Very inefficient. But heck, gcc doesn't support __try/__except/__finally,only C++ exceptions, and interop of C++ is often not great,what with name mangling and all. NT386GNU's OUTPUT uses a different runtime, unless you trim dependencies, possibly a different threading library, possibly a different windowing library. All this probably configurable. Again exception handling is a sore point in that it is the primary C runtime dependency of Modula-3. If you use Cygwin but say -mno-cygwin, that means you are targeting NT386. (and don't use pthreads or X Windows; behavior of exceptions/setjmp/longjmp TBD -- really, need to not use the -mno-cygwin headers in that case; I'll check). Perhaps m3core.dll should export m3_setjmp/m3_longjmp.. Either one can do a cross build to the other.Two cm3.exes, two sets of outputs, that either can produce. NT386 can use gcc or the integrated backend. And the gcc it uses can be MinGWin or Cygwin. (theoretically and probably soon reality) NT386GNU can use either as well! (also currently theory, but a real possibility) It isn't GNU tools, it is GNU runtime. One small area with cm3 might fall down just slightly is that of cross builds where host and target have different naming conventions. -lfoo vs. foo.lib, foo.o vs. foo.obj are an aspect of the host and I vaguely recall that cm3 ties naming convention to ostype. The appending of .exe is a target characteristics, but the others are not really. Naming convention is really a host thing and not a target thing. The config files are a mix of host and target information, mostly actually host, except for the one line that says TARGET. Most of the target variation is in cm3, which always can do any, and cm3cg (which might be nice to be similar, but that's another matter and not likely to ever change, except when AMD64 is the last architecture standing. :) ) If Windows had "rpath", then SL would be split between HOST_SL and TARGET_SL.As it stands, SL is HOST_SL. Consider as well the various versions of Visual C++.They output mostly the same, very interoperable. Consider optimization switches. Host or target?Consider version of gcc or Visual C++? Host or target?Well, inevitably, the host has an affect on the target. If not the for the host, the target would not even exist. Bugs in the host produce bugs in the target. etc. (And realize that Cygwin runs on top of an OS built witha Microsoft compiler, so really there is interop, but sometimes through a layer.) So there's a risk of saying there is six+ combinations. (host cygwin, host mingwin, host native) x (target nt386, target nt386gnu) But generally the host is assumed not a factor. I guess "LIBC" could be seperated into several options... You could actually have code that needs one runtime or another, and they could link together, depending on what they do.. This is something I don't know if cm3 handles, or anything I have seen. I should be able to build a static .lib, that includes some C code, that imbues its clients with build time dependencies. Well, I guess #pragma comment(linker) is this. So the next tasks are roughly: Merge my NT386 and NT386GNU files. Switching on a variable such as backend mode. Introduce a "new" (old) NT386GNU file, perhaps more like what was already there. Change NT386GNU back to Posix. Build NT386GNU. oh, one more point...while these are two targets from cm3's point of view, they are PROBABLY the same target to cm3cg and so only one is needed. I have to check if configure differentiates between i686-pc-cygwin and i686-pc-mingwin... but I guess it should... It might actually be profitable to have two bloated cm3cg.exe's. And they should ship to \cm3\pkg\m3cc\target\host or host\target and cm3 should know which to run. Blech..four of them when one would suffice? The detail being mainly what the paths to .libs look like, unfortunate. Possibly cm3 can bridge this gap using that "broken" feature that symlinks libs into the target directory, using NTFS hard links, if installroot and root are on the same volume... (or symlinks on Vista). Or maybe convert the paths as appropriate, hacky, but saves an extra cm3cg.exe which is good to avoid. (all the more reason to lump all targets into one file, so that the host x target matrix collapses to just one axis, host; and then you can write stuff in Perl/Python/Java/C# to collapse that to just one, except for the underlying runtime/interpreter...) Oh, cm3cg isn't the issue. It is always sitting in the correct directory and reads one file and writes one file, no slashes. The issue is gcc as the linker. Again, this is a host issue..and cm3 or the config file definitely should do the translation. - Jay From: jayk123 at hotmail.comTo: m3devel at elegosoft.comDate: Mon, 21 Jan 2008 23:01:44 +0000Subject: [M3devel] platform/build_dir is a big tuple? _________________________________________________________________ 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 Tue Jan 22 14:00:12 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 22 Jan 2008 13:00:12 +0000 Subject: [M3devel] platform/build_dir is a big tuple? In-Reply-To: References: Message-ID: I'm still torn over that any NT386 target could have a choice of three threading models (win32, pthread, vtalarm), two windowing libraries (ms, x), two (three) compilers (ms, mingwin, cygwin), two (three) linkers (ms, mingwn, cygwin), various runtimes (msvc various versions, cygwin, mingwin (discouraged)) etc. Appending a short string of unreadable bits to BUILD_DIR is very temptingin order to easily generate and test the combinatorial possibilities. backend: 0 integrated, 1 gcc already a setting (with four values) ccompiler/linker: 0 ms, 1 gcc (these could be split, and could allocate more bits...) maybe 00 ms, 01 cygwin, 10 ming maybe define enum up front that allows for watcom, metrowerks, digitalmars, llvm etc. maybe use a decimal digit for all these, and 0 is reserved, maybe. threading: 0 win32, 1 pthreads drop vtalarm, or use two bits? windowing: 0 ms, 1 x cruntime: 0 ms, 1 cyg There is also a ming runtime, discouraged There also really N ms runtimes, ming offers several: msvcrt.dll, msvcr70.dll, msvcr71.dll, msvcr80.dll, msvcr90.dll... but jmpbuf presumbly doesn't change again could allocate multiple bits.. cruntime I guess determines oSTYPE Win32 or Posix, thoughit loses its meaning mostly, and X vs. not-X is usually decide the same... The three most common combinations: 00000 -- NT386 11111 -- NT386GNU 11000 -- NT386MINGNU but several others would work 11101 -- cygwin with native windowing 11011 -- cygwin with native threads 11001 -- cygwin with native threads and native windowing BUILD_DIR would be NT386-$(config)as a special case perhaps, the three commoncases could be translated to the above strings. But the underlying implementation would be a few bools/enums,and iterating through them would be easy, while special casingand skipping deemed invalid combinations, like ms runtime and pthreads,and possibly ms runtime and x windows. Really, it might surprise folks, but really, basically every single combination works. Compilers are very independent of headers and libs and headers and libs are very independent of compilers, aside from a few language extensions like __stdcall. You can generally mix runtimes in the same process, just as you can mix them on the same machine, you just need to be careful about what you pass to what. If you call fopen, be sure pass the result back to the matching fclose, malloc/free, etc. Startup code, to the extent that it matters, might be a problem, but really, just avoid C++ globals with constructors/destructors anyway, they are always a problem. Modula-3 has its own startup code, and if you were to write "main" in C and link in Modula-3 static .libs, that probably doesn't work...might actually be better to play into whatever the platform's C++ constructor story is, as problematic as they (probably always?) are -- i.e. unpredictable/hard-to-control ordering. (bad editing...and maybe use hex for compression..) Bringing back cminstall is almost interesting, to promptthe user, or probe their system, though Quake/cm3 can probe at runtime.if os == windows_nt system_cc | findstr version | findstr gcc else system_cc | findstr visual c++else system_cc | grep version | grep gcc else system_cc | grep visual c++end inefficient. anyway, I'll merge current NT386GNU into NT386 and make it chosehow to compile/link which are the main variables today. and then decide about cygwin, but probably do like the above, sinceit'll totally share code with NT386 except the naming conventionsand the removal of the -mno-cygwin switch.. I know this seems overly complicated, but it should be exposableeasily enough to users by hiding the choices, presenting three basic ones,and still allow all the obvious and perhaps useful knobs, and iterating throughthe combinations, without creating a combinatorial explosion of source filesor Modula-3 or Quake code. ...Jay From: jayk123 at hotmail.comTo: m3devel at elegosoft.comDate: Tue, 22 Jan 2008 10:48:56 +0000Subject: Re: [M3devel] platform/build_dir is a big tuple? Final answer? I played around with this but just can't accept platforms/build_dirs like: ntx86msmsmscm3msn ntx86gccgcccm3cgmsn ntx86gccgcccm3cgxn ntx86-gggggmn ntx86-ggixn ntx86_mmmimmOk, I have one more name here, and then a bit of a change, or a stronger statement of something I had already said.NT386MINGNUOk, I think we (me!) are confusing host and target, MOSTLY.And cm3 might not have them quite divided appropriately.What is a "host"? What is a "target"?MinGWin and Visual C++ output similar results, targetingthe same runtime (usually), threading library, windowing library.There is a chance for exception handling to diverge however.Well, speaking of Visual C++ the C/C++ compiler and MinGWinthe gcc environment, yes, very different, not interoperable.MinGWin uses what gcc calls "sjlj" -- setjmp/longjmp exceptions.Very inefficient. But heck, gcc doesn't support __try/__except/__finally,only C++ exceptions, and interop of C++ is often not great,what with name mangling and all.NT386GNU's OUTPUT uses a different runtime, unless you trim dependencies, possibly a different threading library, possibly a different windowing library. All this probably configurable. Again exception handling is a sore point in that it is the primary C runtime dependency of Modula-3. If you use Cygwin but say -mno-cygwin, that means you are targeting NT386. (and don't use pthreads or X Windows; behavior of exceptions/setjmp/longjmp TBD -- really, need to not use the -mno-cygwin headers in that case; I'll check).Perhaps m3core.dll should export m3_setjmp/m3_longjmp..Either one can do a cross build to the other.Two cm3.exes, two sets of outputs, that either can produce.NT386 can use gcc or the integrated backend. And the gcc it uses can be MinGWin or Cygwin. (theoretically and probably soon reality) NT386GNU can use either as well! (also currently theory, but a real possibility) It isn't GNU tools, it is GNU runtime.One small area with cm3 might fall down just slightly is that of cross builds where host and target have different naming conventions. -lfoo vs. foo.lib, foo.o vs. foo.obj are an aspect of the host and I vaguely recall that cm3 ties naming convention to ostype. The appending of .exe is a target characteristics, but the others are not really. Naming convention is really a host thing and not a target thing.The config files are a mix of host and target information, mostly actually host, except for the one line that says TARGET. Most of the target variation is in cm3, which always can do any, and cm3cg (which might be nice to be similar, but that's another matter and not likely to ever change, except when AMD64 is the last architecture standing. :) )If Windows had "rpath", then SL would be split between HOST_SL and TARGET_SL.As it stands, SL is HOST_SL.Consider as well the various versions of Visual C++.They output mostly the same, very interoperable.Consider optimization switches. Host or target?Consider version of gcc or Visual C++? Host or target?Well, inevitably, the host has an affect on the target. If not the for the host, the target would not even exist. Bugs in the host produce bugs in the target. etc.(And realize that Cygwin runs on top of an OS built witha Microsoft compiler, so really there is interop, but sometimes through a layer.) So there's a risk of saying there is six+ combinations.(host cygwin, host mingwin, host native) x (target nt386, target nt386gnu) But generally the host is assumed not a factor. I guess "LIBC" could be seperated into several options...You could actually have code that needs one runtime or another, and they couldlink together, depending on what they do.. This is something I don't know if cm3 handles, or anything I have seen. I should be able to build a static .lib, that includes some C code, that imbues its clients with build time dependencies. Well, I guess #pragma comment(linker) is this.So the next tasks are roughly: Merge my NT386 and NT386GNU files. Switching on a variable such as backend mode. Introduce a "new" (old) NT386GNU file, perhaps more like what was already there. Change NT386GNU back to Posix. Build NT386GNU. oh, one more point...while these are two targets from cm3's point of view, they are PROBABLY the same target to cm3cgand so only one is needed. I have to check if configure differentiates between i686-pc-cygwin and i686-pc-mingwin...but I guess it should...It might actually be profitable to have two bloated cm3cg.exe's.And they should ship to \cm3\pkg\m3cc\target\host or host\target and cm3 should know which to run.Blech..four of them when one would suffice?The detail being mainly what the paths to .libs look like, unfortunate.Possibly cm3 can bridge this gap using that "broken" feature that symlinks libs into the target directory,using NTFS hard links, if installroot and root are on the same volume... (or symlinks on Vista).Or maybe convert the paths as appropriate, hacky, but saves an extra cm3cg.exe which is good to avoid. (all the more reason to lump all targets into one file, so that the host x target matrix collapses to just one axis, host; andthen you can write stuff in Perl/Python/Java/C# to collapse that to just one, except for the underlying runtime/interpreter...) Oh, cm3cg isn't the issue. It is always sitting in the correct directory and reads one file and writes one file, no slashes.The issue is gcc as the linker. Again, this is a host issue..and cm3 or the config file definitely should do the translation. - Jay From: jayk123 at hotmail.comTo: m3devel at elegosoft.comDate: Mon, 21 Jan 2008 23:01:44 +0000Subject: [M3devel] platform/build_dir is a big tuple? 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 wagner at elegosoft.com Tue Jan 22 14:29:22 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 22 Jan 2008 14:29:22 +0100 Subject: [M3devel] platform/build_dir is a big tuple? In-Reply-To: References: Message-ID: <20080122142922.k73w5es5j4gckso4@mail.elegosoft.com> All this may be useful during development, but it is not really useful for a software distribution to our users, I think. Nobody will understand it :-( We need to keep things more simple. We don't need to support everything out of the box. Instead, we should offer some sensible default combinations of everyhing you describe. First of all: we don't distribute cross compilers (at least until now). This is a special topic reserved for adding new platforms. Runtime and compilers used do not necessarily need to be distinguished by target or build dir, in many cases different cm3.cfg may suffice. Until now, threading models are also no choice that needs to be visible at this level. There's one default model for every target, and the user can change it by recompiling. And if we should really agree that changing the target naming scheme is a good idea, we should o use a systematic one with not more than 4 elements (better still, 3 (e.g. --)) o don't use cryptic abbreviations that will confuse most people Just my 2 cents, Olaf Quoting Jay : > I'm still torn over that any NT386 target could have a choice of > three threading models (win32, pthread, vtalarm), two windowing > libraries (ms, x), two (three) compilers (ms, mingwin, cygwin), two > (three) linkers (ms, mingwn, cygwin), various runtimes (msvc various > versions, cygwin, mingwin (discouraged)) etc. > > Appending a short string of unreadable bits to BUILD_DIR is very > temptingin order to easily generate and test the combinatorial > possibilities. > > backend: 0 integrated, 1 gcc already a setting (with four values) > > ccompiler/linker: 0 ms, 1 gcc (these could be split, and could > allocate more bits...) maybe 00 ms, 01 cygwin, 10 ming maybe define > enum up front that allows for watcom, metrowerks, digitalmars, llvm > etc. > maybe use a decimal digit for all these, and 0 is reserved, maybe. > > threading: 0 win32, 1 pthreads drop vtalarm, or use two bits? > > windowing: 0 ms, 1 x > > cruntime: 0 ms, 1 cyg There is also a ming runtime, discouraged > There also really N ms runtimes, ming offers several: msvcrt.dll, > msvcr70.dll, msvcr71.dll, msvcr80.dll, msvcr90.dll... but jmpbuf > presumbly doesn't change again could allocate multiple bits.. > > cruntime I guess determines oSTYPE Win32 or Posix, thoughit loses > its meaning mostly, and X vs. not-X is usually decide the same... > > The three most common combinations: 00000 -- NT386 11111 -- > NT386GNU 11000 -- NT386MINGNU > > but several others would work 11101 -- cygwin with native windowing > 11011 -- cygwin with native threads 11001 -- cygwin with native > threads and native windowing > BUILD_DIR would be NT386-$(config)as a special case perhaps, the > three commoncases could be translated to the above strings. > > But the underlying implementation would be a few bools/enums,and > iterating through them would be easy, while special casingand > skipping deemed invalid combinations, like ms runtime and > pthreads,and possibly ms runtime and x windows. > Really, it might surprise folks, but really, basically every single > combination works. > Compilers are very independent of headers and libs and headers and > libs are very independent of compilers, aside from a few language > extensions like __stdcall. You can generally mix runtimes in the > same process, just as you can mix them on the same machine, you just > need to be careful about what you pass to what. If you call fopen, > be sure pass the result back to the matching fclose, malloc/free, > etc. Startup code, to the extent that it matters, might be a > problem, but really, just avoid C++ globals with > constructors/destructors anyway, they are always a problem. Modula-3 > has its own startup code, and if you were to write "main" in C and > link in Modula-3 static .libs, that probably doesn't work...might > actually be better to play into whatever the platform's C++ > constructor story is, as problematic as they (probably always?) are > -- i.e. unpredictable/hard-to-control ordering. > > (bad editing...and maybe use hex for compression..) > > Bringing back cminstall is almost interesting, to promptthe user, or > probe their system, though Quake/cm3 can probe at runtime.if os == > windows_nt system_cc | findstr version | findstr gcc else > system_cc | findstr visual c++else system_cc | grep version | grep > gcc else system_cc | grep visual c++end > > inefficient. > > anyway, I'll merge current NT386GNU into NT386 and make it chosehow > to compile/link which are the main variables today. > and then decide about cygwin, but probably do like the above, > sinceit'll totally share code with NT386 except the naming > conventionsand the removal of the -mno-cygwin switch.. > > I know this seems overly complicated, but it should be > exposableeasily enough to users by hiding the choices, presenting > three basic ones,and still allow all the obvious and perhaps useful > knobs, and iterating throughthe combinations, without creating a > combinatorial explosion of source filesor Modula-3 or Quake code. > ...Jay > > > From: jayk123 at hotmail.comTo: m3devel at elegosoft.comDate: Tue, 22 Jan > 2008 10:48:56 +0000Subject: Re: [M3devel] platform/build_dir is a > big tuple? > > > Final answer? I played around with this but just can't accept > platforms/build_dirs like: ntx86msmsmscm3msn ntx86gccgcccm3cgmsn > ntx86gccgcccm3cgxn ntx86-gggggmn ntx86-ggixn ntx86_mmmimmOk, I > have one more name here, and then a bit of a change, or a stronger > statement of something I had already said.NT386MINGNUOk, I think we > (me!) are confusing host and target, MOSTLY.And cm3 might not have > them quite divided appropriately.What is a "host"? What is a > "target"?MinGWin and Visual C++ output similar results, targetingthe > same runtime (usually), threading library, windowing library.There > is a chance for exception handling to diverge however.Well, speaking > of Visual C++ the C/C++ compiler and MinGWinthe gcc environment, > yes, very different, not interoperable.MinGWin uses what gcc calls > "sjlj" -- setjmp/longjmp exceptions.Very inefficient. But heck, gcc > doesn't support __try/__except/__finally,only C++ exceptions, and > interop of C++ is often not great,what with name mangling and > all.NT386GNU's OUTPUT uses a different runtime, unless you trim > dependencies, possibly a different threading library, possibly a > different windowing library. All this probably configurable. Again > exception handling is a sore point in that it is the primary C > runtime dependency of Modula-3. If you use Cygwin but say > -mno-cygwin, that means you are targeting NT386. (and don't use > pthreads or X Windows; behavior of exceptions/setjmp/longjmp TBD -- > really, need to not use the -mno-cygwin headers in that case; I'll > check).Perhaps m3core.dll should export > m3_setjmp/m3_longjmp..Either one can do a cross build to the > other.Two cm3.exes, two sets of outputs, that either can > produce.NT386 can use gcc or the integrated backend. And the gcc > it uses can be MinGWin or Cygwin. (theoretically and probably soon > reality) NT386GNU can use either as well! (also currently theory, > but a real possibility) It isn't GNU tools, it is GNU runtime.One > small area with cm3 might fall down just slightly is that of > cross builds where host and target have different naming > conventions. -lfoo vs. foo.lib, foo.o vs. foo.obj are an aspect > of the host and I vaguely recall that cm3 ties naming convention > to ostype. The appending of .exe is a target characteristics, but > the others are not really. Naming convention is really a host > thing and not a target thing.The config files are a mix of host and > target information, mostly actually host, except for the one line > that says TARGET. Most of the target variation is in cm3, which > always can do any, and cm3cg (which might be nice to be similar, > but that's another matter and not likely to ever change, except > when AMD64 is the last architecture standing. :) )If Windows had > "rpath", then SL would be split between HOST_SL and TARGET_SL.As it > stands, SL is HOST_SL.Consider as well the various versions of > Visual C++.They output mostly the same, very interoperable.Consider > optimization switches. Host or target?Consider version of gcc or > Visual C++? Host or target?Well, inevitably, the host has an affect > on the target. If not the for the host, the target would not even > exist. Bugs in the host produce bugs in the target. etc.(And > realize that Cygwin runs on top of an OS built witha Microsoft > compiler, so really there is interop, but sometimes through a > layer.) So there's a risk of saying there is six+ > combinations.(host cygwin, host mingwin, host native) x (target > nt386, target nt386gnu) But generally the host is assumed not a > factor. I guess "LIBC" could be seperated into several options...You > could actually have code that needs one runtime or another, and > they couldlink together, depending on what they do.. This is > something I don't know if cm3 handles, or anything I have seen. I > should be able to build a static .lib, that includes some C code, > that imbues its clients with build time dependencies. Well, I > guess #pragma comment(linker) is this.So the next tasks are > roughly: Merge my NT386 and NT386GNU files. Switching on a > variable such as backend mode. Introduce a "new" (old) NT386GNU > file, perhaps more like what was already there. Change NT386GNU > back to Posix. Build NT386GNU. oh, one more point...while these > are two targets from cm3's point of view, they are PROBABLY the > same target to cm3cgand so only one is needed. I have to check if > configure differentiates between i686-pc-cygwin and > i686-pc-mingwin...but I guess it should...It might actually be > profitable to have two bloated cm3cg.exe's.And they should ship to > \cm3\pkg\m3cc\target\host or host\target and cm3 should know which > to run.Blech..four of them when one would suffice?The detail being > mainly what the paths to .libs look like, unfortunate.Possibly cm3 > can bridge this gap using that "broken" feature that symlinks libs > into the target directory,using NTFS hard links, if installroot and > root are on the same volume... (or symlinks on Vista).Or maybe > convert the paths as appropriate, hacky, but saves an extra > cm3cg.exe which is good to avoid. (all the more reason to lump all > targets into one file, so that the host x target matrix collapses > to just one axis, host; andthen you can write stuff in > Perl/Python/Java/C# to collapse that to just one, except for the > underlying runtime/interpreter...) Oh, cm3cg isn't the issue. It is > always sitting in the correct directory and reads one file and > writes one file, no slashes.The issue is gcc as the linker. Again, > this is a host issue..and cm3 or the config file definitely should > do the translation. - Jay > > > From: jayk123 at hotmail.comTo: m3devel at elegosoft.comDate: Mon, 21 Jan > 2008 23:01:44 +0000Subject: [M3devel] platform/build_dir is a big > tuple? > > 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 -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Jan 22 15:29:04 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 22 Jan 2008 14:29:04 +0000 Subject: [M3devel] platform/build_dir is a big tuple? In-Reply-To: <20080122142922.k73w5es5j4gckso4@mail.elegosoft.com> References: <20080122142922.k73w5es5j4gckso4@mail.elegosoft.com> Message-ID: I know, I've heard it many times from smart people, but sorry I can't resist. I will strive for a balance. In particular I'm thinking NT386 sets a few globals as described include NT386.commonNT386GNU sets a few globals as described include NT386.commonNT386MINGNU sets a few globals as described include NT386.common NT386.common will not be the simplest. CM3 might know about a few more of these globals than it already does. Under the covers, there is already lots and lots and lots of complexity and always will be (look at the stuff I debugged, which I admit was half stupid since PM3 had half the diffs -- I didn't find their config file to see about the double alignment though, so I was stuck debugging that afaik). - Jay > Date: Tue, 22 Jan 2008 14:29:22 +0100> From: wagner at elegosoft.com> To: m3devel at elegosoft.com> Subject: Re: [M3devel] platform/build_dir is a big tuple?> > All this may be useful during development, but it is not really> useful for a software distribution to our users, I think.> > Nobody will understand it :-( We need to keep things more simple.> > We don't need to support everything out of the box. Instead, we should> offer some sensible default combinations of everyhing you describe.> > First of all: we don't distribute cross compilers (at least until now).> This is a special topic reserved for adding new platforms.> > Runtime and compilers used do not necessarily need to be distinguished> by target or build dir, in many cases different cm3.cfg may suffice.> > Until now, threading models are also no choice that needs to be> visible at this level. There's one default model for every target,> and the user can change it by recompiling.> > And if we should really agree that changing the target naming scheme> is a good idea, we should> > o use a systematic one with not more than 4 elements (better still,> 3 (e.g. --))> o don't use cryptic abbreviations that will confuse most people> > Just my 2 cents,> > Olaf> > Quoting Jay :> > I'm still torn over that any NT386 target could have a choice of > > three threading models (win32, pthread, vtalarm), two windowing > > libraries (ms, x), two (three) compilers (ms, mingwin, cygwin), two > > (three) linkers (ms, mingwn, cygwin), various runtimes (msvc various > > versions, cygwin, mingwin (discouraged)) etc.> >> > Appending a short string of unreadable bits to BUILD_DIR is very > > temptingin order to easily generate and test the combinatorial > > possibilities.> >> > backend: 0 integrated, 1 gcc already a setting (with four values)> >> > ccompiler/linker: 0 ms, 1 gcc (these could be split, and could > > allocate more bits...) maybe 00 ms, 01 cygwin, 10 ming maybe define > > enum up front that allows for watcom, metrowerks, digitalmars, llvm > > etc.> > maybe use a decimal digit for all these, and 0 is reserved, maybe.> >> > threading: 0 win32, 1 pthreads drop vtalarm, or use two bits?> >> > windowing: 0 ms, 1 x> >> > cruntime: 0 ms, 1 cyg There is also a ming runtime, discouraged > > There also really N ms runtimes, ming offers several: msvcrt.dll, > > msvcr70.dll, msvcr71.dll, msvcr80.dll, msvcr90.dll... but jmpbuf > > presumbly doesn't change again could allocate multiple bits..> >> > cruntime I guess determines oSTYPE Win32 or Posix, thoughit loses > > its meaning mostly, and X vs. not-X is usually decide the same...> >> > The three most common combinations: 00000 -- NT386 11111 -- > > NT386GNU 11000 -- NT386MINGNU> >> > but several others would work 11101 -- cygwin with native windowing > > 11011 -- cygwin with native threads 11001 -- cygwin with native > > threads and native windowing> > BUILD_DIR would be NT386-$(config)as a special case perhaps, the > > three commoncases could be translated to the above strings.> >> > But the underlying implementation would be a few bools/enums,and > > iterating through them would be easy, while special casingand > > skipping deemed invalid combinations, like ms runtime and > > pthreads,and possibly ms runtime and x windows.> > Really, it might surprise folks, but really, basically every single > > combination works.> > Compilers are very independent of headers and libs and headers and > > libs are very independent of compilers, aside from a few language > > extensions like __stdcall. You can generally mix runtimes in the > > same process, just as you can mix them on the same machine, you just > > need to be careful about what you pass to what. If you call fopen, > > be sure pass the result back to the matching fclose, malloc/free, > > etc. Startup code, to the extent that it matters, might be a > > problem, but really, just avoid C++ globals with > > constructors/destructors anyway, they are always a problem. Modula-3 > > has its own startup code, and if you were to write "main" in C and > > link in Modula-3 static .libs, that probably doesn't work...might > > actually be better to play into whatever the platform's C++ > > constructor story is, as problematic as they (probably always?) are > > -- i.e. unpredictable/hard-to-control ordering.> >> > (bad editing...and maybe use hex for compression..)> >> > Bringing back cminstall is almost interesting, to promptthe user, or > > probe their system, though Quake/cm3 can probe at runtime.if os == > > windows_nt system_cc | findstr version | findstr gcc else > > system_cc | findstr visual c++else system_cc | grep version | grep > > gcc else system_cc | grep visual c++end> >> > inefficient.> >> > anyway, I'll merge current NT386GNU into NT386 and make it chosehow > > to compile/link which are the main variables today.> > and then decide about cygwin, but probably do like the above, > > sinceit'll totally share code with NT386 except the naming > > conventionsand the removal of the -mno-cygwin switch..> >> > I know this seems overly complicated, but it should be > > exposableeasily enough to users by hiding the choices, presenting > > three basic ones,and still allow all the obvious and perhaps useful > > knobs, and iterating throughthe combinations, without creating a > > combinatorial explosion of source filesor Modula-3 or Quake code.> > ...Jay> >> >> > From: jayk123 at hotmail.comTo: m3devel at elegosoft.comDate: Tue, 22 Jan > > 2008 10:48:56 +0000Subject: Re: [M3devel] platform/build_dir is a > > big tuple?> >> >> > Final answer? I played around with this but just can't accept > > platforms/build_dirs like: ntx86msmsmscm3msn ntx86gccgcccm3cgmsn > > ntx86gccgcccm3cgxn ntx86-gggggmn ntx86-ggixn ntx86_mmmimmOk, I > > have one more name here, and then a bit of a change, or a stronger > > statement of something I had already said.NT386MINGNUOk, I think we > > (me!) are confusing host and target, MOSTLY.And cm3 might not have > > them quite divided appropriately.What is a "host"? What is a > > "target"?MinGWin and Visual C++ output similar results, targetingthe > > same runtime (usually), threading library, windowing library.There > > is a chance for exception handling to diverge however.Well, speaking > > of Visual C++ the C/C++ compiler and MinGWinthe gcc environment, > > yes, very different, not interoperable.MinGWin uses what gcc calls > > "sjlj" -- setjmp/longjmp exceptions.Very inefficient. But heck, gcc > > doesn't support __try/__except/__finally,only C++ exceptions, and > > interop of C++ is often not great,what with name mangling and > > all.NT386GNU's OUTPUT uses a different runtime, unless you trim > > dependencies, possibly a different threading library, possibly a > > different windowing library. All this probably configurable. Again > > exception handling is a sore point in that it is the primary C > > runtime dependency of Modula-3. If you use Cygwin but say > > -mno-cygwin, that means you are targeting NT386. (and don't use > > pthreads or X Windows; behavior of exceptions/setjmp/longjmp TBD -- > > really, need to not use the -mno-cygwin headers in that case; I'll > > check).Perhaps m3core.dll should export > > m3_setjmp/m3_longjmp..Either one can do a cross build to the > > other.Two cm3.exes, two sets of outputs, that either can > > produce.NT386 can use gcc or the integrated backend. And the gcc > > it uses can be MinGWin or Cygwin. (theoretically and probably soon > > reality) NT386GNU can use either as well! (also currently theory, > > but a real possibility) It isn't GNU tools, it is GNU runtime.One > > small area with cm3 might fall down just slightly is that of > > cross builds where host and target have different naming > > conventions. -lfoo vs. foo.lib, foo.o vs. foo.obj are an aspect > > of the host and I vaguely recall that cm3 ties naming convention > > to ostype. The appending of .exe is a target characteristics, but > > the others are not really. Naming convention is really a host > > thing and not a target thing.The config files are a mix of host and > > target information, mostly actually host, except for the one line > > that says TARGET. Most of the target variation is in cm3, which > > always can do any, and cm3cg (which might be nice to be similar, > > but that's another matter and not likely to ever change, except > > when AMD64 is the last architecture standing. :) )If Windows had > > "rpath", then SL would be split between HOST_SL and TARGET_SL.As it > > stands, SL is HOST_SL.Consider as well the various versions of > > Visual C++.They output mostly the same, very interoperable.Consider > > optimization switches. Host or target?Consider version of gcc or > > Visual C++? Host or target?Well, inevitably, the host has an affect > > on the target. If not the for the host, the target would not even > > exist. Bugs in the host produce bugs in the target. etc.(And > > realize that Cygwin runs on top of an OS built witha Microsoft > > compiler, so really there is interop, but sometimes through a > > layer.) So there's a risk of saying there is six+ > > combinations.(host cygwin, host mingwin, host native) x (target > > nt386, target nt386gnu) But generally the host is assumed not a > > factor. I guess "LIBC" could be seperated into several options...You > > could actually have code that needs one runtime or another, and > > they couldlink together, depending on what they do.. This is > > something I don't know if cm3 handles, or anything I have seen. I > > should be able to build a static .lib, that includes some C code, > > that imbues its clients with build time dependencies. Well, I > > guess #pragma comment(linker) is this.So the next tasks are > > roughly: Merge my NT386 and NT386GNU files. Switching on a > > variable such as backend mode. Introduce a "new" (old) NT386GNU > > file, perhaps more like what was already there. Change NT386GNU > > back to Posix. Build NT386GNU. oh, one more point...while these > > are two targets from cm3's point of view, they are PROBABLY the > > same target to cm3cgand so only one is needed. I have to check if > > configure differentiates between i686-pc-cygwin and > > i686-pc-mingwin...but I guess it should...It might actually be > > profitable to have two bloated cm3cg.exe's.And they should ship to > > \cm3\pkg\m3cc\target\host or host\target and cm3 should know which > > to run.Blech..four of them when one would suffice?The detail being > > mainly what the paths to .libs look like, unfortunate.Possibly cm3 > > can bridge this gap using that "broken" feature that symlinks libs > > into the target directory,using NTFS hard links, if installroot and > > root are on the same volume... (or symlinks on Vista).Or maybe > > convert the paths as appropriate, hacky, but saves an extra > > cm3cg.exe which is good to avoid. (all the more reason to lump all > > targets into one file, so that the host x target matrix collapses > > to just one axis, host; andthen you can write stuff in > > Perl/Python/Java/C# to collapse that to just one, except for the > > underlying runtime/interpreter...) Oh, cm3cg isn't the issue. It is > > always sitting in the correct directory and reads one file and > > writes one file, no slashes.The issue is gcc as the linker. Again, > > this is a host issue..and cm3 or the config file definitely should > > do the translation. - Jay> >> >> > From: jayk123 at hotmail.comTo: m3devel at elegosoft.comDate: Mon, 21 Jan > > 2008 23:01:44 +0000Subject: [M3devel] platform/build_dir is a big > > tuple?> >> > 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> > > > -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 Jan 22 17:54:37 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 22 Jan 2008 16:54:37 +0000 Subject: [M3devel] platform/build_dir is a big tuple? In-Reply-To: References: <20080122142922.k73w5es5j4gckso4@mail.elegosoft.com> Message-ID: This is essentially in now. I understand all those points, but there are pluses and minuses either way. Including: > 3 (e.g. --)) "variant", that's space for arbitrary variation, it's not one variable. This scheme acknowledges two common variables and leaves slush to try to cope with what else there is. Of course, it would be a big advance over what is there. And yes I realize you lose somehow one way or another. Anyway, if what I have is acceptable, or shows an acceptable direction that is *almost* complete (it is definitely not quite complete, since Cygwin isn't active yet), I can start winding down this topic. :) The scheme I have..I kind of already said this..TARGET will always be NT386, and it is configurable. Three of the configurations are recognized and given made up short readable build_dir.To me, from the user perspective, build_dir is a critical aspect of target, so you can kind of give the appearance of targets without adding full scale new targets, which I realize would be "ok". The rest, if you try them, get mechnical build_dir. What I haven't worked out yet is, like..before there was the TARGET/CM3_TARGET environment variables. Those should probably remain and get translated..which actually pretty much already works -- the environment variable will map not to a target, but to a config file name, and it will handle everything. I haven't tried this. I left the old targets for temporary compat. Later... arch-os-variant is fine I'd like to check what the four element gnu configurations. arch-os-variant won't apply for the two "new" targets I'm working on presumably, since they derive from the existing NT386. I assume given NT386, and essentially NT386GNU, nobody would argue for introducing I386_NT_MINGWIN or I386_NT_CYGWIN, but maybe. And yes I know, sorry, I'm being a bit of a jerk, asking for something, getting it, and then not taking it. If people do want I386_NT_MINGIN or X86_NT_MINGNU, ok with me. - Jay From: jayk123 at hotmail.comTo: wagner at elegosoft.com; m3devel at elegosoft.comDate: Tue, 22 Jan 2008 14:29:04 +0000Subject: Re: [M3devel] platform/build_dir is a big tuple? I know, I've heard it many times from smart people, but sorry I can't resist. I will strive for a balance. In particular I'm thinking NT386 sets a few globals as described include NT386.commonNT386GNU sets a few globals as described include NT386.commonNT386MINGNU sets a few globals as described include NT386.commonNT386.common will not be the simplest. CM3 might know about a few more of these globals than it already does. Under the covers, there is already lots and lots and lots of complexity and always will be (look at the stuff I debugged, which I admit was half stupid since PM3 had half the diffs -- I didn't find their config file to see about the double alignment though, so I was stuck debugging that afaik). - Jay > Date: Tue, 22 Jan 2008 14:29:22 +0100> From: wagner at elegosoft.com> To: m3devel at elegosoft.com> Subject: Re: [M3devel] platform/build_dir is a big tuple?> > All this may be useful during development, but it is not really> useful for a software distribution to our users, I think.> > Nobody will understand it :-( We need to keep things more simple.> > We don't need to support everything out of the box. Instead, we should> offer some sensible default combinations of everyhing you describe.> > First of all: we don't distribute cross compilers (at least until now).> This is a special topic reserved for adding new platforms.> > Runtime and compilers used do not necessarily need to be distinguished> by target or build dir, in many cases different cm3.cfg may suffice.> > Until now, threading models are also no choice that needs to be> visible at this level. There's one default model for every target,> and the user can change it by recompiling.> > And if we should really agree that changing the target naming scheme> is a good idea, we should> > o use a systematic one with not more than 4 elements (better still,> 3 (e.g. --))> o don't use cryptic abbreviations that will confuse most people> > Just my 2 cents,> > Olaf> > Quoting Jay :> > I'm still torn over that any NT386 target could have a choice of > > three threading models (win32, pthread, vtalarm), two windowing > > libraries (ms, x), two (three) compilers (ms, mingwin, cygwin), two > > (three) linkers (ms, mingwn, cygwin), various runtimes (msvc various > > versions, cygwin, mingwin (discouraged)) etc.> >> > Appending a short string of unreadable bits to BUILD_DIR is very > > temptingin order to easily generate and test the combinatorial > > possibilities.> >> > backend: 0 integrated, 1 gcc already a setting (with four values)> >> > ccompiler/linker: 0 ms, 1 gcc (these could be split, and could > > allocate more bits...) maybe 00 ms, 01 cygwin, 10 ming maybe define > > enum up front that allows for watcom, metrowerks, digitalmars, llvm > > etc.> > maybe use a decimal digit for all these, and 0 is reserved, maybe.> >> > threading: 0 win32, 1 pthreads drop vtalarm, or use two bits?> >> > windowing: 0 ms, 1 x> >> > cruntime: 0 ms, 1 cyg There is also a ming runtime, discouraged > > There also really N ms runtimes, ming offers several: msvcrt.dll, > > msvcr70.dll, msvcr71.dll, msvcr80.dll, msvcr90.dll... but jmpbuf > > presumbly doesn't change again could allocate multiple bits..> >> > cruntime I guess determines oSTYPE Win32 or Posix, thoughit loses > > its meaning mostly, and X vs. not-X is usually decide the same...> >> > The three most common combinations: 00000 -- NT386 11111 -- > > NT386GNU 11000 -- NT386MINGNU> >> > but several others would work 11101 -- cygwin with native windowing > > 11011 -- cygwin with native threads 11001 -- cygwin with native > > threads and native windowing> > BUILD_DIR would be NT386-$(config)as a special case perhaps, the > > three commoncases could be translated to the above strings.> >> > But the underlying implementation would be a few bools/enums,and > > iterating through them would be easy, while special casingand > > skipping deemed invalid combinations, like ms runtime and > > pthreads,and possibly ms runtime and x windows.> > Really, it might surprise folks, but really, basically every single > > combination works.> > Compilers are very independent of headers and libs and headers and > > libs are very independent of compilers, aside from a few language > > extensions like __stdcall. You can generally mix runtimes in the > > same process, just as you can mix them on the same machine, you just > > need to be careful about what you pass to what. If you call fopen, > > be sure pass the result back to the matching fclose, malloc/free, > > etc. Startup code, to the extent that it matters, might be a > > problem, but really, just avoid C++ globals with > > constructors/destructors anyway, they are always a problem. Modula-3 > > has its own startup code, and if you were to write "main" in C and > > link in Modula-3 static .libs, that probably doesn't work...might > > actually be better to play into whatever the platform's C++ > > constructor story is, as problematic as they (probably always?) are > > -- i.e. unpredictable/hard-to-control ordering.> >> > (bad editing...and maybe use hex for compression..)> >> > Bringing back cminstall is almost interesting, to promptthe user, or > > probe their system, though Quake/cm3 can probe at runtime.if os == > > windows_nt system_cc | findstr version | findstr gcc else > > system_cc | findstr visual c++else system_cc | grep version | grep > > gcc else system_cc | grep visual c++end> >> > inefficient.> >> > anyway, I'll merge current NT386GNU into NT386 and make it chosehow > > to compile/link which are the main variables today.> > and then decide about cygwin, but probably do like the above, > > sinceit'll totally share code with NT386 except the naming > > conventionsand the removal of the -mno-cygwin switch..> >> > I know this seems overly complicated, but it should be > > exposableeasily enough to users by hiding the choices, presenting > > three basic ones,and still allow all the obvious and perhaps useful > > knobs, and iterating throughthe combinations, without creating a > > combinatorial explosion of source filesor Modula-3 or Quake code.> > ...Jay> >> >> > From: jayk123 at hotmail.comTo: m3devel at elegosoft.comDate: Tue, 22 Jan > > 2008 10:48:56 +0000Subject: Re: [M3devel] platform/build_dir is a > > big tuple?> >> >> > Final answer? I played around with this but just can't accept > > platforms/build_dirs like: ntx86msmsmscm3msn ntx86gccgcccm3cgmsn > > ntx86gccgcccm3cgxn ntx86-gggggmn ntx86-ggixn ntx86_mmmimmOk, I > > have one more name here, and then a bit of a change, or a stronger > > statement of something I had already said.NT386MINGNUOk, I think we > > (me!) are confusing host and target, MOSTLY.And cm3 might not have > > them quite divided appropriately.What is a "host"? What is a > > "target"?MinGWin and Visual C++ output similar results, targetingthe > > same runtime (usually), threading library, windowing library.There > > is a chance for exception handling to diverge however.Well, speaking > > of Visual C++ the C/C++ compiler and MinGWinthe gcc environment, > > yes, very different, not interoperable.MinGWin uses what gcc calls > > "sjlj" -- setjmp/longjmp exceptions.Very inefficient. But heck, gcc > > doesn't support __try/__except/__finally,only C++ exceptions, and > > interop of C++ is often not great,what with name mangling and > > all.NT386GNU's OUTPUT uses a different runtime, unless you trim > > dependencies, possibly a different threading library, possibly a > > different windowing library. All this probably configurable. Again > > exception handling is a sore point in that it is the primary C > > runtime dependency of Modula-3. If you use Cygwin but say > > -mno-cygwin, that means you are targeting NT386. (and don't use > > pthreads or X Windows; behavior of exceptions/setjmp/longjmp TBD -- > > really, need to not use the -mno-cygwin headers in that case; I'll > > check).Perhaps m3core.dll should export > > m3_setjmp/m3_longjmp..Either one can do a cross build to the > > other.Two cm3.exes, two sets of outputs, that either can > > produce.NT386 can use gcc or the integrated backend. And the gcc > > it uses can be MinGWin or Cygwin. (theoretically and probably soon > > reality) NT386GNU can use either as well! (also currently theory, > > but a real possibility) It isn't GNU tools, it is GNU runtime.One > > small area with cm3 might fall down just slightly is that of > > cross builds where host and target have different naming > > conventions. -lfoo vs. foo.lib, foo.o vs. foo.obj are an aspect > > of the host and I vaguely recall that cm3 ties naming convention > > to ostype. The appending of .exe is a target characteristics, but > > the others are not really. Naming convention is really a host > > thing and not a target thing.The config files are a mix of host and > > target information, mostly actually host, except for the one line > > that says TARGET. Most of the target variation is in cm3, which > > always can do any, and cm3cg (which might be nice to be similar, > > but that's another matter and not likely to ever change, except > > when AMD64 is the last architecture standing. :) )If Windows had > > "rpath", then SL would be split between HOST_SL and TARGET_SL.As it > > stands, SL is HOST_SL.Consider as well the various versions of > > Visual C++.They output mostly the same, very interoperable.Consider > > optimization switches. Host or target?Consider version of gcc or > > Visual C++? Host or target?Well, inevitably, the host has an affect > > on the target. If not the for the host, the target would not even > > exist. Bugs in the host produce bugs in the target. etc.(And > > realize that Cygwin runs on top of an OS built witha Microsoft > > compiler, so really there is interop, but sometimes through a > > layer.) So there's a risk of saying there is six+ > > combinations.(host cygwin, host mingwin, host native) x (target > > nt386, target nt386gnu) But generally the host is assumed not a > > factor. I guess "LIBC" could be seperated into several options...You > > could actually have code that needs one runtime or another, and > > they couldlink together, depending on what they do.. This is > > something I don't know if cm3 handles, or anything I have seen. I > > should be able to build a static .lib, that includes some C code, > > that imbues its clients with build time dependencies. Well, I > > guess #pragma comment(linker) is this.So the next tasks are > > roughly: Merge my NT386 and NT386GNU files. Switching on a > > variable such as backend mode. Introduce a "new" (old) NT386GNU > > file, perhaps more like what was already there. Change NT386GNU > > back to Posix. Build NT386GNU. oh, one more point...while these > > are two targets from cm3's point of view, they are PROBABLY the > > same target to cm3cgand so only one is needed. I have to check if > > configure differentiates between i686-pc-cygwin and > > i686-pc-mingwin...but I guess it should...It might actually be > > profitable to have two bloated cm3cg.exe's.And they should ship to > > \cm3\pkg\m3cc\target\host or host\target and cm3 should know which > > to run.Blech..four of them when one would suffice?The detail being > > mainly what the paths to .libs look like, unfortunate.Possibly cm3 > > can bridge this gap using that "broken" feature that symlinks libs > > into the target directory,using NTFS hard links, if installroot and > > root are on the same volume... (or symlinks on Vista).Or maybe > > convert the paths as appropriate, hacky, but saves an extra > > cm3cg.exe which is good to avoid. (all the more reason to lump all > > targets into one file, so that the host x target matrix collapses > > to just one axis, host; andthen you can write stuff in > > Perl/Python/Java/C# to collapse that to just one, except for the > > underlying runtime/interpreter...) Oh, cm3cg isn't the issue. It is > > always sitting in the correct directory and reads one file and > > writes one file, no slashes.The issue is gcc as the linker. Again, > > this is a host issue..and cm3 or the config file definitely should > > do the translation. - Jay> >> >> > From: jayk123 at hotmail.comTo: m3devel at elegosoft.comDate: Mon, 21 Jan > > 2008 23:01:44 +0000Subject: [M3devel] platform/build_dir is a big > > tuple?> >> > 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> > > > -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 hosking at cs.purdue.edu Tue Jan 22 18:50:44 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 22 Jan 2008 12:50:44 -0500 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <20080122163601.6245410D4608@birch.elegosoft.com> References: <20080122163601.6245410D4608@birch.elegosoft.com> Message-ID: <9C3615E5-FEDB-4AAB-BFC7-AFE867C94241@cs.purdue.edu> Do we really want to build all the Windows interfaces even on non- Windows hosts? Yuck. On Jan 22, 2008, at 5:36 PM, Jay Krell wrote: > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 08/01/22 17:36:01 > > Modified files: > cm3/m3-sys/cm3/src/: M3Backend.m3 m3makefile > cm3/scripts/: backup-pkgs.sh boot-cm3-build-on-target.sh > boot-cm3-core.sh boot-cm3-with-m3.sh > copy-bootarchives.sh do-cm3-core.sh > make-bin-dist-min.sh pack-crossbuild.sh pkginfo.sh > Removed files: > cm3/m3-sys/cm3/src/: M3BackPosix.m3 M3BackWin32.m3 > > Log message: > put integrated backend into all hosts, so that cross builds work > a bit more; built on PPC_DARWIN (ie: built on Posix, where it's > an actual diff; what this will enable for me is a "semi-cros" > from a NT386GNU cm3.exe to NT386/NT386MINGNU. And it's fairly cheap, > the integrated backend is nothing compared to cm3cg. > did not run all the .sh files, just upgrade.sh > Note that m3staloneback is relatively unused, probably for > debugging, left alone. > mklib should come in as well for cross purposes but left that > alone too. > There are warnings in WinDef.m3 about <*WINAPI*> on function pointer > types. Perhaps they can be deferred and only trigger if the types > are used? If the types are called? ie: make the pragma understood, > but > don't support calling using calling conventions not supported by > target From hosking at cs.purdue.edu Tue Jan 22 18:54:04 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 22 Jan 2008 12:54:04 -0500 Subject: [M3devel] platform/build_dir is a big tuple? In-Reply-To: <20080122142922.k73w5es5j4gckso4@mail.elegosoft.com> References: <20080122142922.k73w5es5j4gckso4@mail.elegosoft.com> Message-ID: <2AB0D273-C3B8-4D46-BCC1-4D032692DCB0@cs.purdue.edu> On Jan 22, 2008, at 8:29 AM, Olaf Wagner wrote: > All this may be useful during development, but it is not really > useful for a software distribution to our users, I think. > > Nobody will understand it :-( We need to keep things more simple. > > We don't need to support everything out of the box. Instead, we should > offer some sensible default combinations of everyhing you describe. > > First of all: we don't distribute cross compilers (at least until > now). > This is a special topic reserved for adding new platforms. Precisely why I don't like many of the recent changes. I don't want to build Windows interfaces and gorp for a non-Windows platform. Jay, can you *please* back these changes out? > > Runtime and compilers used do not necessarily need to be distinguished > by target or build dir, in many cases different cm3.cfg may suffice. > > Until now, threading models are also no choice that needs to be > visible at this level. There's one default model for every target, > and the user can change it by recompiling. > > And if we should really agree that changing the target naming scheme > is a good idea, we should > > o use a systematic one with not more than 4 elements (better still, > 3 (e.g. --)) > o don't use cryptic abbreviations that will confuse most people > > Just my 2 cents, > > Olaf > > Quoting Jay : >> I'm still torn over that any NT386 target could have a choice of >> three threading models (win32, pthread, vtalarm), two windowing >> libraries (ms, x), two (three) compilers (ms, mingwin, cygwin), >> two (three) linkers (ms, mingwn, cygwin), various runtimes (msvc >> various versions, cygwin, mingwin (discouraged)) etc. >> >> Appending a short string of unreadable bits to BUILD_DIR is very >> temptingin order to easily generate and test the combinatorial >> possibilities. >> >> backend: 0 integrated, 1 gcc already a setting (with four values) >> >> ccompiler/linker: 0 ms, 1 gcc (these could be split, and could >> allocate more bits...) maybe 00 ms, 01 cygwin, 10 ming maybe >> define enum up front that allows for watcom, metrowerks, >> digitalmars, llvm etc. >> maybe use a decimal digit for all these, and 0 is reserved, maybe. >> >> threading: 0 win32, 1 pthreads drop vtalarm, or use two bits? >> >> windowing: 0 ms, 1 x >> >> cruntime: 0 ms, 1 cyg There is also a ming runtime, discouraged >> There also really N ms runtimes, ming offers several: >> msvcrt.dll, msvcr70.dll, msvcr71.dll, msvcr80.dll, >> msvcr90.dll... but jmpbuf presumbly doesn't change again could >> allocate multiple bits.. >> >> cruntime I guess determines oSTYPE Win32 or Posix, thoughit loses >> its meaning mostly, and X vs. not-X is usually decide the same... >> >> The three most common combinations: 00000 -- NT386 11111 -- >> NT386GNU 11000 -- NT386MINGNU >> >> but several others would work 11101 -- cygwin with native >> windowing 11011 -- cygwin with native threads 11001 -- cygwin >> with native threads and native windowing >> BUILD_DIR would be NT386-$(config)as a special case perhaps, the >> three commoncases could be translated to the above strings. >> >> But the underlying implementation would be a few bools/enums,and >> iterating through them would be easy, while special casingand >> skipping deemed invalid combinations, like ms runtime and >> pthreads,and possibly ms runtime and x windows. >> Really, it might surprise folks, but really, basically every >> single combination works. >> Compilers are very independent of headers and libs and headers >> and libs are very independent of compilers, aside from a few >> language extensions like __stdcall. You can generally mix >> runtimes in the same process, just as you can mix them on the >> same machine, you just need to be careful about what you pass to >> what. If you call fopen, be sure pass the result back to the >> matching fclose, malloc/free, etc. Startup code, to the extent >> that it matters, might be a problem, but really, just avoid C++ >> globals with constructors/destructors anyway, they are always a >> problem. Modula-3 has its own startup code, and if you were to >> write "main" in C and link in Modula-3 static .libs, that >> probably doesn't work...might actually be better to play into >> whatever the platform's C++ constructor story is, as problematic >> as they (probably always?) are -- i.e. unpredictable/hard-to- >> control ordering. >> >> (bad editing...and maybe use hex for compression..) >> >> Bringing back cminstall is almost interesting, to promptthe user, >> or probe their system, though Quake/cm3 can probe at runtime.if >> os == windows_nt system_cc | findstr version | findstr gcc >> else system_cc | findstr visual c++else system_cc | grep >> version | grep gcc else system_cc | grep visual c++end >> >> inefficient. >> >> anyway, I'll merge current NT386GNU into NT386 and make it >> chosehow to compile/link which are the main variables today. >> and then decide about cygwin, but probably do like the above, >> sinceit'll totally share code with NT386 except the naming >> conventionsand the removal of the -mno-cygwin switch.. >> >> I know this seems overly complicated, but it should be >> exposableeasily enough to users by hiding the choices, presenting >> three basic ones,and still allow all the obvious and perhaps >> useful knobs, and iterating throughthe combinations, without >> creating a combinatorial explosion of source filesor Modula-3 or >> Quake code. >> ...Jay >> >> >> From: jayk123 at hotmail.comTo: m3devel at elegosoft.comDate: Tue, 22 >> Jan 2008 10:48:56 +0000Subject: Re: [M3devel] platform/build_dir >> is a big tuple? >> >> >> Final answer? I played around with this but just can't accept >> platforms/build_dirs like: ntx86msmsmscm3msn >> ntx86gccgcccm3cgmsn ntx86gccgcccm3cgxn ntx86-gggggmn ntx86- >> ggixn ntx86_mmmimmOk, I have one more name here, and then a bit >> of a change, or a stronger statement of something I had already >> said.NT386MINGNUOk, I think we (me!) are confusing host and >> target, MOSTLY.And cm3 might not have them quite divided >> appropriately.What is a "host"? What is a "target"?MinGWin and >> Visual C++ output similar results, targetingthe same runtime >> (usually), threading library, windowing library.There is a chance >> for exception handling to diverge however.Well, speaking of >> Visual C++ the C/C++ compiler and MinGWinthe gcc environment, >> yes, very different, not interoperable.MinGWin uses what gcc >> calls "sjlj" -- setjmp/longjmp exceptions.Very inefficient. But >> heck, gcc doesn't support __try/__except/__finally,only C++ >> exceptions, and interop of C++ is often not great,what with name >> mangling and all.NT386GNU's OUTPUT uses a different runtime, >> unless you trim dependencies, possibly a different threading >> library, possibly a different windowing library. All this >> probably configurable. Again exception handling is a sore point >> in that it is the primary C runtime dependency of Modula-3. If >> you use Cygwin but say -mno-cygwin, that means you are targeting >> NT386. (and don't use pthreads or X Windows; behavior of >> exceptions/setjmp/longjmp TBD -- really, need to not use the - >> mno-cygwin headers in that case; I'll check).Perhaps m3core.dll >> should export m3_setjmp/m3_longjmp..Either one can do a cross >> build to the other.Two cm3.exes, two sets of outputs, that either >> can produce.NT386 can use gcc or the integrated backend. And the >> gcc it uses can be MinGWin or Cygwin. (theoretically and probably >> soon reality) NT386GNU can use either as well! (also currently >> theory, but a real possibility) It isn't GNU tools, it is GNU >> runtime.One small area with cm3 might fall down just slightly is >> that of cross builds where host and target have different >> naming conventions. -lfoo vs. foo.lib, foo.o vs. foo.obj are an >> aspect of the host and I vaguely recall that cm3 ties naming >> convention to ostype. The appending of .exe is a target >> characteristics, but the others are not really. Naming >> convention is really a host thing and not a target thing.The >> config files are a mix of host and target information, mostly >> actually host, except for the one line that says TARGET. Most of >> the target variation is in cm3, which always can do any, and >> cm3cg (which might be nice to be similar, but that's another >> matter and not likely to ever change, except when AMD64 is the >> last architecture standing. :) )If Windows had "rpath", then SL >> would be split between HOST_SL and TARGET_SL.As it stands, SL is >> HOST_SL.Consider as well the various versions of Visual C++.They >> output mostly the same, very interoperable.Consider optimization >> switches. Host or target?Consider version of gcc or Visual C++? >> Host or target?Well, inevitably, the host has an affect on the >> target. If not the for the host, the target would not even >> exist. Bugs in the host produce bugs in the target. etc.(And >> realize that Cygwin runs on top of an OS built witha Microsoft >> compiler, so really there is interop, but sometimes through a >> layer.) So there's a risk of saying there is six+ combinations. >> (host cygwin, host mingwin, host native) x (target nt386, target >> nt386gnu) But generally the host is assumed not a factor. I >> guess "LIBC" could be seperated into several options...You could >> actually have code that needs one runtime or another, and they >> couldlink together, depending on what they do.. This is something >> I don't know if cm3 handles, or anything I have seen. I should be >> able to build a static .lib, that includes some C code, that >> imbues its clients with build time dependencies. Well, I guess >> #pragma comment(linker) is this.So the next tasks are roughly: >> Merge my NT386 and NT386GNU files. Switching on a variable such >> as backend mode. Introduce a "new" (old) NT386GNU file, >> perhaps more like what was already there. Change NT386GNU back >> to Posix. Build NT386GNU. oh, one more point...while these are >> two targets from cm3's point of view, they are PROBABLY the same >> target to cm3cgand so only one is needed. I have to check if >> configure differentiates between i686-pc-cygwin and i686-pc- >> mingwin...but I guess it should...It might actually be profitable >> to have two bloated cm3cg.exe's.And they should ship to \cm3\pkg >> \m3cc\target\host or host\target and cm3 should know which to >> run.Blech..four of them when one would suffice?The detail being >> mainly what the paths to .libs look like, unfortunate.Possibly >> cm3 can bridge this gap using that "broken" feature that symlinks >> libs into the target directory,using NTFS hard links, if >> installroot and root are on the same volume... (or symlinks on >> Vista).Or maybe convert the paths as appropriate, hacky, but >> saves an extra cm3cg.exe which is good to avoid. (all the more >> reason to lump all targets into one file, so that the host x >> target matrix collapses to just one axis, host; andthen you can >> write stuff in Perl/Python/Java/C# to collapse that to just one, >> except for the underlying runtime/interpreter...) Oh, cm3cg isn't >> the issue. It is always sitting in the correct directory and >> reads one file and writes one file, no slashes.The issue is gcc >> as the linker. Again, this is a host issue..and cm3 or the config >> file definitely should do the translation. - Jay >> >> >> From: jayk123 at hotmail.comTo: m3devel at elegosoft.comDate: Mon, 21 >> Jan 2008 23:01:44 +0000Subject: [M3devel] platform/build_dir is a >> big tuple? >> >> 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 > > > > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, > Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 > 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: > Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > DE163214194 > From rcoleburn at scires.com Tue Jan 22 20:48:38 2008 From: rcoleburn at scires.com (Randy Coleburn) Date: Tue, 22 Jan 2008 14:48:38 -0500 Subject: [M3devel] next problem (NT386GNU) In-Reply-To: References: <6E1E4409-F3D9-4982-B179-2D4C9648FDD0@cs.purdue.edu> <1A6EC7D6-32B2-44AD-933F-6976040A7D7F@cs.purdue.edu> <20080122081049.74tzfvozwo4wwwow@mail.elegosoft.com> Message-ID: <47960244.1E75.00D7.1@scires.com> Jay / Olaf: I installed CVSNT and TortoiseCVS. I am having some trouble with "update" however. When I try to update the whole tree, it begins working, but after a little while I start seeing messages that checksums didn't match on certain files and that it will refetch. Then, after just a little longer, it stops responding. I've left it running for hours, but no new lines scroll by saying it is doing anything. Finally, I just hit cancel and it promptly stops and informs me it aborted the operation, as if it been waiting all along for me to tell it to give up. Now, if I update individual files or selected files, it seems to work no problem. And, I've been able to check out the whole repository, and yes it does take some time to pull everything down. I can also do diffs on selected files. I've also used it to commit a few files to the repository. So, it is working fine, except for update. Either something is amiss, or I'm not doing something just right. I am about to consider going back to cygwin and running its version of cvs on my tree to see if it will do the update, but I seem to recall reading somewhere that is not good to mix between cvs and cvsnt on the same tree. Jay, I too have used WinDiff for a long time. But, with the CVSNT and Tortoise installs, I also installed WinMerge. ( http://winmerge.org/ ) I'm still learning more about it, but so far, I have enjoyed it better than WinDiff because in addition to letting you see the diffs, it also lets you selectively merge diffs between the files using a GUI. It also integrates nicely with TortoiseCVS. Jay, you can get command line completion in Windows, but you have to make a registry tweak. There are actually two tweaks: one for filename completion and one for pathname completion. They are quite simple. See instructions below: Enable automatic completion for the computer as follows: a. Click Start, click Run, type regedit, and then click OK. b. Locate and click the HKEY_LOCAL_MACHINE\Software\Microsoft\Command Processor key c. Double-click the CompletionChar value and type 9 as the value; Windows converts it to hexadecimal. d. Double-click the PathCompletionChar value and type 9 as the value; Windows converts it to hexadecimal. e. Quit Registry Editor. Note that this modification allows you to press the TAB key while in a command prompt window in order to perform automatic filename and pathname completion. (You may have to restart or log in again before this modification will take affect.) Regards, Randy >>> Jay 1/22/2008 2:34 AM >>> Olaf, yes and no. How do I then bring the files into mainline? Which Tinderbox is testing them? This is impossible question probably, because Tinderbox for private changes probably doesn't scale well. But it would be nice. And other than private branches, submitting diffs would be nice. Or, as well, these can be crutches for bad changes, and people can abuse the Tinderbox. It's tough though, because a multi machine Tinderbox can always easily do much more diligence than one developer and his local machines. (What's the Win32 Tinderbox story, I wonder? I guess first I can see if Mozilla has one, and if not, it probably doesn't exist, if so, it does :) ) I don't mind the command line, but I'm a bit slow learning new tools. I find new source control systems daunting. I'm quite expert with Perforce though including branching, integrating, resolving, etc.. You don't have to be in Cygwin (sh) to use cvs, but it's true, one very annoying thing about all these forward-slash-requiring tools is I lose the usefulness of command line completion in cmd. Cmd is quite good at editing command lines, keeping output and command line history (set the scrollback to 9999), copy/paste, and is very fast, nothing else that I have tried competes. Most are even merely slower on their video output except maybe the actual text ones. The F8 feature, command line completion against history, which I can't explain well, is really great. MSys comes up with awful colors that I couldn't figure out how to change. Cygwin makes all your paths be /cygdrive/c/... which is just ugly and long. MSys/MinGWin are much nicer with merely /c... I installed TortoiseCVS but it didn't work..I need to look into how to get it to use ssh. But as well, if my work doesn't suck too much, it should be fine for mainline. Look at diffs is really also slow. I've done best by always saving away an .orig file and then windiff. Otherwise 1) is very slow 2) textual diffs...I use the command line all the time, but for viewing diffs...it's really insufficient. - Jay > Date: Tue, 22 Jan 2008 08:10:49 +0100 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] next problem (NT386GNU) > > Quoting Jay : > > > I don't want to deal with learning about CVS branches, please. > > I don't understand the problems some people seem to have with CVS. > Creating a branch is really simple: > > o create a branch tag, for example: > > cvs tag -b devel_nt386gnu_gcc_opt files(s) > > o update to that branch: > > cvs up -r devel_nt386gnu_gcc_opt files(s) > > That's it. The tag is now `sticky' on the files, i.e. remembered > in the CVS/Entries files in your workspace. From now on you're > using the branch for the mentioned files. To restore them to the > latest main trunk version, use > > cvs up -A files(s) > > And Jay, as a Windows user you probably don't like to use the cvs > commandline in Cygwin; just install CVS-NT and tortoise (Randy did, > too). It may be more convenient for you. > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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". Check it out. ( http://www.msnmobilefix.com/Default.aspx ) -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcoleburn at scires.com Tue Jan 22 21:03:45 2008 From: rcoleburn at scires.com (Randy Coleburn) Date: Tue, 22 Jan 2008 15:03:45 -0500 Subject: [M3devel] platform/build_dir is a big tuple? In-Reply-To: References: Message-ID: <479605CF.1E75.00D7.1@scires.com> Jay: For my part on Windows, I am happy to stay with the underlying OS, the native windows threading, the integrated backend, and use the free Microsoft Visual Studio tools. I don't really want to have to install/use cygwin or any of the other variants. When I see target = NT386, this list is what I am expecting. For the cm3 newbie coming from a Microsoft Windows environment, I think this list would be the most appealing and pose the least barrier to getting starting. Yes, I still will work on the installer program once I'm satisfied that I have a good working cm3 on Windows. Of course, I am just one voice. If you can and want to provide for all of the other variants on windows, that is ok with me. Just don't do away with what I have now. Regards, Randy >>> Jay 1/22/2008 8:00 AM >>> I'm still torn over that any NT386 target could have a choice of three threading models (win32, pthread, vtalarm), two windowing libraries (ms, x), two (three) compilers (ms, mingwin, cygwin), two (three) linkers (ms, mingwn, cygwin), various runtimes (msvc various versions, cygwin, mingwin (discouraged)) etc. Appending a short string of unreadable bits to BUILD_DIR is very tempting in order to easily generate and test the combinatorial possibilities. backend: 0 integrated, 1 gcc already a setting (with four values) ccompiler/linker: 0 ms, 1 gcc (these could be split, and could allocate more bits...) maybe 00 ms, 01 cygwin, 10 ming maybe define enum up front that allows for watcom, metrowerks, digitalmars, llvm etc. maybe use a decimal digit for all these, and 0 is reserved, maybe. threading: 0 win32, 1 pthreads drop vtalarm, or use two bits? windowing: 0 ms, 1 x cruntime: 0 ms, 1 cyg There is also a ming runtime, discouraged There also really N ms runtimes, ming offers several: msvcrt.dll, msvcr70.dll, msvcr71.dll, msvcr80.dll, msvcr90.dll... but jmpbuf presumbly doesn't change again could allocate multiple bits.. cruntime I guess determines oSTYPE Win32 or Posix, though it loses its meaning mostly, and X vs. not-X is usually decide the same... The three most common combinations: 00000 -- NT386 11111 -- NT386GNU 11000 -- NT386MINGNU but several others would work 11101 -- cygwin with native windowing 11011 -- cygwin with native threads 11001 -- cygwin with native threads and native windowing BUILD_DIR would be NT386-$(config) as a special case perhaps, the three common cases could be translated to the above strings. But the underlying implementation would be a few bools/enums, and iterating through them would be easy, while special casing and skipping deemed invalid combinations, like ms runtime and pthreads, and possibly ms runtime and x windows. Really, it might surprise folks, but really, basically every single combination works. Compilers are very independent of headers and libs and headers and libs are very independent of compilers, aside from a few language extensions like __stdcall. You can generally mix runtimes in the same process, just as you can mix them on the same machine, you just need to be careful about what you pass to what. If you call fopen, be sure pass the result back to the matching fclose, malloc/free, etc. Startup code, to the extent that it matters, might be a problem, but really, just avoid C++ globals with constructors/destructors anyway, they are always a problem. Modula-3 has its own startup code, and if you were to write "main" in C and link in Modula-3 static .libs, that probably doesn't work...might actually be better to play into whatever the platform's C++ constructor story is, as problematic as they (probably always?) are -- i.e. unpredictable/hard-to-control ordering. (bad editing...and maybe use hex for compression..) Bringing back cminstall is almost interesting, to prompt the user, or probe their system, though Quake/cm3 can probe at runtime. if os == windows_nt system_cc | findstr version | findstr gcc else system_cc | findstr visual c++ else system_cc | grep version | grep gcc else system_cc | grep visual c++ end inefficient. anyway, I'll merge current NT386GNU into NT386 and make it chose how to compile/link which are the main variables today. and then decide about cygwin, but probably do like the above, since it'll totally share code with NT386 except the naming conventions and the removal of the -mno-cygwin switch.. I know this seems overly complicated, but it should be exposable easily enough to users by hiding the choices, presenting three basic ones, and still allow all the obvious and perhaps useful knobs, and iterating through the combinations, without creating a combinatorial explosion of source files or Modula-3 or Quake code. ...Jay From: jayk123 at hotmail.com To: m3devel at elegosoft.com Date: Tue, 22 Jan 2008 10:48:56 +0000 Subject: Re: [M3devel] platform/build_dir is a big tuple? Final answer? I played around with this but just can't accept platforms/build_dirs like: ntx86msmsmscm3msn ntx86gccgcccm3cgmsn ntx86gccgcccm3cgxn ntx86-gggggmn ntx86-ggixn ntx86_mmmimm Ok, I have one more name here, and then a bit of a change, or a stronger statement of something I had already said. NT386MINGNU Ok, I think we (me!) are confusing host and target, MOSTLY. And cm3 might not have them quite divided appropriately. What is a "host"? What is a "target"? MinGWin and Visual C++ output similar results, targeting the same runtime (usually), threading library, windowing library. There is a chance for exception handling to diverge however. Well, speaking of Visual C++ the C/C++ compiler and MinGWin the gcc environment, yes, very different, not interoperable. MinGWin uses what gcc calls "sjlj" -- setjmp/longjmp exceptions. Very inefficient. But heck, gcc doesn't support __try/__except/__finally, only C++ exceptions, and interop of C++ is often not great, what with name mangling and all. NT386GNU's OUTPUT uses a different runtime, unless you trim dependencies, possibly a different threading library, possibly a different windowing library. All this probably configurable. Again exception handling is a sore point in that it is the primary C runtime dependency of Modula-3. If you use Cygwin but say -mno-cygwin, that means you are targeting NT386. (and don't use pthreads or X Windows; behavior of exceptions/setjmp/longjmp TBD -- really, need to not use the -mno-cygwin headers in that case; I'll check). Perhaps m3core.dll should export m3_setjmp/m3_longjmp.. Either one can do a cross build to the other. Two cm3.exes, two sets of outputs, that either can produce. NT386 can use gcc or the integrated backend. And the gcc it uses can be MinGWin or Cygwin. (theoretically and probably soon reality) NT386GNU can use either as well! (also currently theory, but a real possibility) It isn't GNU tools, it is GNU runtime. One small area with cm3 might fall down just slightly is that of cross builds where host and target have different naming conventions. -lfoo vs. foo.lib, foo.o vs. foo.obj are an aspect of the host and I vaguely recall that cm3 ties naming convention to ostype. The appending of .exe is a target characteristics, but the others are not really. Naming convention is really a host thing and not a target thing. The config files are a mix of host and target information, mostly actually host, except for the one line that says TARGET. Most of the target variation is in cm3, which always can do any, and cm3cg (which might be nice to be similar, but that's another matter and not likely to ever change, except when AMD64 is the last architecture standing. :) ) If Windows had "rpath", then SL would be split between HOST_SL and TARGET_SL. As it stands, SL is HOST_SL. Consider as well the various versions of Visual C++. They output mostly the same, very interoperable. Consider optimization switches. Host or target? Consider version of gcc or Visual C++? Host or target? Well, inevitably, the host has an affect on the target. If not the for the host, the target would not even exist. Bugs in the host produce bugs in the target. etc. (And realize that Cygwin runs on top of an OS built with a Microsoft compiler, so really there is interop, but sometimes through a layer.) So there's a risk of saying there is six+ combinations. (host cygwin, host mingwin, host native) x (target nt386, target nt386gnu) But generally the host is assumed not a factor. I guess "LIBC" could be seperated into several options... You could actually have code that needs one runtime or another, and they could link together, depending on what they do.. This is something I don't know if cm3 handles, or anything I have seen. I should be able to build a static .lib, that includes some C code, that imbues its clients with build time dependencies. Well, I guess #pragma comment(linker) is this. So the next tasks are roughly: Merge my NT386 and NT386GNU files. Switching on a variable such as backend mode. Introduce a "new" (old) NT386GNU file, perhaps more like what was already there. Change NT386GNU back to Posix. Build NT386GNU. oh, one more point...while these are two targets from cm3's point of view, they are PROBABLY the same target to cm3cg and so only one is needed. I have to check if configure differentiates between i686-pc-cygwin and i686-pc-mingwin... but I guess it should... It might actually be profitable to have two bloated cm3cg.exe's. And they should ship to \cm3\pkg\m3cc\target\host or host\target and cm3 should know which to run. Blech..four of them when one would suffice? The detail being mainly what the paths to .libs look like, unfortunate. Possibly cm3 can bridge this gap using that "broken" feature that symlinks libs into the target directory, using NTFS hard links, if installroot and root are on the same volume... (or symlinks on Vista). Or maybe convert the paths as appropriate, hacky, but saves an extra cm3cg.exe which is good to avoid. (all the more reason to lump all targets into one file, so that the host x target matrix collapses to just one axis, host; and then you can write stuff in Perl/Python/Java/C# to collapse that to just one, except for the underlying runtime/interpreter...) Oh, cm3cg isn't the issue. It is always sitting in the correct directory and reads one file and writes one file, no slashes. The issue is gcc as the linker. Again, this is a host issue..and cm3 or the config file definitely should do the translation. - Jay From: jayk123 at hotmail.com To: m3devel at elegosoft.com Date: Mon, 21 Jan 2008 23:01:44 +0000 Subject: [M3devel] platform/build_dir is a big tuple? 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 wagner at elegosoft.com Tue Jan 22 23:48:06 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 22 Jan 2008 23:48:06 +0100 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <9C3615E5-FEDB-4AAB-BFC7-AFE867C94241@cs.purdue.edu> References: <20080122163601.6245410D4608@birch.elegosoft.com> <9C3615E5-FEDB-4AAB-BFC7-AFE867C94241@cs.purdue.edu> Message-ID: <20080122234806.me1n09816o08gc80@mail.elegosoft.com> Quoting Tony Hosking : > Do we really want to build all the Windows interfaces even on > non-Windows hosts? Yuck. I'd suggest to build that conditional, Jay. Olaf > On Jan 22, 2008, at 5:36 PM, Jay Krell wrote: > >> CVSROOT: /usr/cvs >> Changes by: jkrell at birch. 08/01/22 17:36:01 >> >> Modified files: >> cm3/m3-sys/cm3/src/: M3Backend.m3 m3makefile >> cm3/scripts/: backup-pkgs.sh boot-cm3-build-on-target.sh >> boot-cm3-core.sh boot-cm3-with-m3.sh >> copy-bootarchives.sh do-cm3-core.sh >> make-bin-dist-min.sh pack-crossbuild.sh pkginfo.sh >> Removed files: >> cm3/m3-sys/cm3/src/: M3BackPosix.m3 M3BackWin32.m3 >> >> Log message: >> put integrated backend into all hosts, so that cross builds work >> a bit more; built on PPC_DARWIN (ie: built on Posix, where it's >> an actual diff; what this will enable for me is a "semi-cros" >> from a NT386GNU cm3.exe to NT386/NT386MINGNU. And it's fairly cheap, >> the integrated backend is nothing compared to cm3cg. >> did not run all the .sh files, just upgrade.sh >> Note that m3staloneback is relatively unused, probably for >> debugging, left alone. >> mklib should come in as well for cross purposes but left that alone too. >> There are warnings in WinDef.m3 about <*WINAPI*> on function pointer >> types. Perhaps they can be deferred and only trigger if the types >> are used? If the types are called? ie: make the pragma understood, but >> don't support calling using calling conventions not supported by target -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Jan 23 00:04:35 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 23 Jan 2008 00:04:35 +0100 Subject: [M3devel] next problem (NT386GNU) In-Reply-To: <47960244.1E75.00D7.1@scires.com> References: <6E1E4409-F3D9-4982-B179-2D4C9648FDD0@cs.purdue.edu> <1A6EC7D6-32B2-44AD-933F-6976040A7D7F@cs.purdue.edu> <20080122081049.74tzfvozwo4wwwow@mail.elegosoft.com> <47960244.1E75.00D7.1@scires.com> Message-ID: <20080123000435.kjtci5bewwcss448@mail.elegosoft.com> Quoting Randy Coleburn : > Jay / Olaf: > > I installed CVSNT and TortoiseCVS. I am having some trouble with > "update" however. When I try to update the whole tree, it begins > working, but after a little while I start seeing messages that checksums > didn't match on certain files and that it will refetch. Then, after > just a little longer, it stops responding. I've left it running for > hours, but no new lines scroll by saying it is doing anything. Finally, > I just hit cancel and it promptly stops and informs me it aborted the > operation, as if it been waiting all along for me to tell it to give > up. > > Now, if I update individual files or selected files, it seems to work > no problem. And, I've been able to check out the whole repository, and > yes it does take some time to pull everything down. I can also do diffs > on selected files. I've also used it to commit a few files to the > repository. > > So, it is working fine, except for update. Either something is amiss, > or I'm not doing something just right. I am about to consider going > back to cygwin and running its version of cvs on my tree to see if it > will do the update, but I seem to recall reading somewhere that is not > good to mix between cvs and cvsnt on the same tree. This is strange. I've never seen that myself before. A complete update or checkout should take several minutes via encrypted TCP/IP, but not longer (depending on the line bandwidth and latency, of course). Just today I've heard of a customer who suffers from random connection problems with Subversion and Windows 2000 workstations; the theory there being that some TCP/IP parameters are set very strange and the whole protocol stack is not up to the task in its default configuration. This does not happen on XT or Vista, though, who seem to have incorporated significant improvements. (It's all rather strange to me, since I'm a Unix person myself and used to stable networking.) So depending on your OS you might want to tweak the TCP parameters a little bit to see if it improves. Hard-core debugging of this problem will need careful use of tcpdump and produce megabytes of logs; but perhaps just using the cvs trace option (cvs -t up ...) will give some indication if there's another problem than the underlying connection. There's also nothing against checking out a different workspace with the Cygwin cvs to see if that works better. We've made good experiences with CVSNT though. If the problem persists, we could also try to do some tcpdumping on the server side (Ronny Forberger would be the one to do it), but this will take some preparation time. @Ronny, perhaps you've got another idea? 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 ronny.forberger at elegosoft.com Wed Jan 23 00:53:02 2008 From: ronny.forberger at elegosoft.com (Ronny Forberger) Date: Wed, 23 Jan 2008 00:53:02 +0100 Subject: [M3devel] next problem (NT386GNU) In-Reply-To: <20080123000435.kjtci5bewwcss448@mail.elegosoft.com> References: <6E1E4409-F3D9-4982-B179-2D4C9648FDD0@cs.purdue.edu> <1A6EC7D6-32B2-44AD-933F-6976040A7D7F@cs.purdue.edu> <20080122081049.74tzfvozwo4wwwow@mail.elegosoft.com> <47960244.1E75.00D7.1@scires.com> <20080123000435.kjtci5bewwcss448@mail.elegosoft.com> Message-ID: <479681DE.8020104@elegosoft.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Olaf Wagner schrieb: > Quoting Randy Coleburn : > >> Jay / Olaf: >> >> I installed CVSNT and TortoiseCVS. I am having some trouble with >> "update" however. When I try to update the whole tree, it begins >> working, but after a little while I start seeing messages that >> checksums >> didn't match on certain files and that it will refetch. Then, after >> just a little longer, it stops responding. I've left it running for >> hours, but no new lines scroll by saying it is doing anything. >> Finally, >> I just hit cancel and it promptly stops and informs me it aborted the >> operation, as if it been waiting all along for me to tell it to give >> up. >> >> Now, if I update individual files or selected files, it seems to work >> no problem. And, I've been able to check out the whole repository, >> and >> yes it does take some time to pull everything down. I can also do >> diffs >> on selected files. I've also used it to commit a few files to the >> repository. >> >> So, it is working fine, except for update. Either something is amiss, >> or I'm not doing something just right. I am about to consider going >> back to cygwin and running its version of cvs on my tree to see if it >> will do the update, but I seem to recall reading somewhere that is not >> good to mix between cvs and cvsnt on the same tree. > > This is strange. I've never seen that myself before. A complete > update or checkout should take several minutes via encrypted > TCP/IP, but not longer (depending on the line bandwidth and latency, > of course). > > Just today I've heard of a customer who suffers from random connection > problems with Subversion and Windows 2000 workstations; the theory > there > being that some TCP/IP parameters are set very strange and the whole > protocol stack is not up to the task in its default configuration. > This does not happen on XT or Vista, though, who seem to have > incorporated > significant improvements. (It's all rather strange to me, since I'm a > Unix person myself and used to stable networking.) > > So depending on your OS you might want to tweak the TCP parameters a > little bit to see if it improves. Hard-core debugging of this problem > will need careful use of tcpdump and produce megabytes of logs; > but perhaps just using the cvs trace option (cvs -t up ...) will > give some indication if there's another problem than the underlying > connection. > > There's also nothing against checking out a different workspace > with the Cygwin cvs to see if that works better. We've made good > experiences with CVSNT though. > > If the problem persists, we could also try to do some tcpdumping on > the server side (Ronny Forberger would be the one to do it), but this > will take some preparation time. > > @Ronny, perhaps you've got another idea? Maybe try to enable debug mode on the cvs core programme (cvsnt). Not sure if dumping network traffic might help. You can also watch the cvs command running by logging on to modula3.elegosoft.com via ssh. You should really first check quality of your network connection to modula3.elegosoft.com and possibly try if update works with other implentations of cvs. Cheers, 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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHloHdXa9RCz+1wnMRAi7uAKCLvz8DqU/SeiHr/2FGum0BWOLHNACgl6R8 mk+bxc060/81T2l4IUwpEQU= =Xe1T -----END PGP SIGNATURE----- From jayk123 at hotmail.com Wed Jan 23 03:49:26 2008 From: jayk123 at hotmail.com (Jay) Date: Wed, 23 Jan 2008 02:49:26 +0000 Subject: [M3devel] enum for backend mode? In-Reply-To: <2AB0D273-C3B8-4D46-BCC1-4D032692DCB0@cs.purdue.edu> References: <20080122142922.k73w5es5j4gckso4@mail.elegosoft.com> <2AB0D273-C3B8-4D46-BCC1-4D032692DCB0@cs.purdue.edu> Message-ID: I'll be passing around backend mode a little more. Should we make it an enum? Good names are hard to come up with here. Here's my lame strawman: BackendMode = { IntegratedProducesObject, IntegratedProducedAssembly, QuakeProducesObject, QuakeProducesAssembly }; I have these changes almost done but am going to remove them pending discussion. I don't really like these names. They are long and still not all clear. Long would be ok if they were perfectly clear, imho. These names do correlate well with the nearby comments, which get roughly repeated for every use of the magic numbers. "quake" is usually called "m3back" or such, the name of the Quake function. I find both descriptions a bit short and therefore unclear. I don't think IntegratedProducingAssembly and QuakeProducingObject "really" exist. There is m3staloneback -- QuakeProducingObject or Assembly, and the code is available for IntegratedProducingAssembly, I guess esp. for debugging, but you can just as well link /dump /disasm -- but I don't think these are really in use. Therefore, perhaps merely Object and Assembly, though Integrated vs. not is a significant aspect not represented.. - 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 Wed Jan 23 04:33:24 2008 From: jayk123 at hotmail.com (Jay) Date: Wed, 23 Jan 2008 03:33:24 +0000 Subject: [M3devel] platform/build_dir is a big tuple? In-Reply-To: <2AB0D273-C3B8-4D46-BCC1-4D032692DCB0@cs.purdue.edu> References: <20080122142922.k73w5es5j4gckso4@mail.elegosoft.com> <2AB0D273-C3B8-4D46-BCC1-4D032692DCB0@cs.purdue.edu> Message-ID: Ok now? It's just types and the warnings should be gone. ps: I think all compilers should be cross-capable in one executable if that is easy. CM3 is, except for the missing integrated backend and mklib. Others like Java are. Not easy with gcc/cm3cg darn which makes some of CM3's functionality moot. And the missing linker... - Jay > From: hosking at cs.purdue.edu> > Precisely why I don't like many of the recent changes. I don't want > to build Windows interfaces and gorp for a non-Windows platform. > Jay, can you *please* back these changes 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 jayk123 at hotmail.com Wed Jan 23 04:45:44 2008 From: jayk123 at hotmail.com (Jay) Date: Wed, 23 Jan 2008 03:45:44 +0000 Subject: [M3devel] pixmap problem In-Reply-To: <20080120204831.81poj3gg0084o0g0@mail.elegosoft.com> References: Your message of "Sat, 19 Jan 2008 17:54:00 +0100." <235688.77597.qm@web27110.mail.ukl.yahoo.com> <200801200341.m0K3feKM023564@camembert.async.caltech.edu> <47935664.1E75.00D7.1@scires.com> <20080120204831.81poj3gg0084o0g0@mail.elegosoft.com> Message-ID: Please give me a few days on the NT386/GNU stuff first, thanks. - Jay > Date: Sun, 20 Jan 2008 20:48:31 +0100> From: wagner at elegosoft.com> To: m3devel at elegosoft.com> Subject: Re: [M3devel] pixmap problem> > Quoting Randy Coleburn :> > > Mika / Daniel: Thanks for the test info!> >> > Well, based on what ya'll are reporting, I think the problem has to do> > with the NT386 platform. I also don't think it has to do necessarily> > with the source code. So, there must be something fishy going on in the> > NT386 world in the linkage step to cause this type of situation when> > switching between regular and buildstandalone().> > I must have missed that, browsing the lots of mails on this list> recently ;-)> > > Unfortunately, I'm probably not the right person to figure out what is> > wrong and fix it either. Hey, but at least I produced a short test> > program that reproduces the problem.> > This is often the more difficult part.> > > Maybe Jay or someone can offer another suggestion on how to fix it.> > I think Jay is the well capable of finding out what's going wrong there.> Let's wait for him.> > Olaf> -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 hosking at cs.purdue.edu Wed Jan 23 05:51:48 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 22 Jan 2008 23:51:48 -0500 Subject: [M3devel] platform/build_dir is a big tuple? In-Reply-To: References: <20080122142922.k73w5es5j4gckso4@mail.elegosoft.com> <2AB0D273-C3B8-4D46-BCC1-4D032692DCB0@cs.purdue.edu> Message-ID: <4BF6B109-55C1-4B71-830D-3B61219CF66F@cs.purdue.edu> Hmm, perhaps I overreacted. :-) On Jan 22, 2008, at 10:33 PM, Jay wrote: > Ok now? It's just types and the warnings should be gone. > > ps: I think all compilers should be cross-capable in one executable > if that is easy. CM3 is, except > for the missing integrated backend and mklib. > Others like Java are. Not easy with gcc/cm3cg darn which makes some > of CM3's functionality moot. > And the missing linker... > > - Jay > > From: hosking at cs.purdue.edu > > > > Precisely why I don't like many of the recent changes. I don't want > > to build Windows interfaces and gorp for a non-Windows platform. > > Jay, can you *please* back these changes out? > > Need to know the score, the latest news, or you need your Hotmail?- > get your "fix". Check it out. From jayk123 at hotmail.com Wed Jan 23 06:26:06 2008 From: jayk123 at hotmail.com (Jay) Date: Wed, 23 Jan 2008 05:26:06 +0000 Subject: [M3devel] next problem (NT386GNU) In-Reply-To: <479681DE.8020104@elegosoft.com> References: <6E1E4409-F3D9-4982-B179-2D4C9648FDD0@cs.purdue.edu> <1A6EC7D6-32B2-44AD-933F-6976040A7D7F@cs.purdue.edu> <20080122081049.74tzfvozwo4wwwow@mail.elegosoft.com> <47960244.1E75.00D7.1@scires.com> <20080123000435.kjtci5bewwcss448@mail.elegosoft.com> <479681DE.8020104@elegosoft.com> Message-ID: Here's a little Windows hack?trick?technique from memory for dividing down long running commands that might help. in_each_dir.cmd for /f %%a in ('dir /b /ad') do cd %%a && %* cd %CVSROOT% in_each_dir cvs update -dAP If the problem is one that you merely want to parallelize with a possible loss in logging, because it is actually a reliable but slow and parallelizable operation, you can do like: in_each_dir start cvs update -dAP or in_each_dir start /min cvs update -dAP That doesn't seem the case here so just use it serially. I'm quite proud of this one line of cmd. :) (while at the time..cmd stinks...) Could it be newlines vs. carriagereturn-newlines? I find checkouts takes a while, but heck, I'm using wireless and often forget -z3. My CVS knowledge continues to be lame..something like cvs -z3 checkout cm3/scripts as a way to limit the initial checkout and then cd %CM3_ROOT% for %a in (m3-sys m3-libs m3-ui etc.) do cvs update -dAP %a to do it piecemeal. See, what I'd like is to get either all the toplevel directories but empty, or all the directories but no files, so I can use in_each_dir to enumerate. A more complete solution that logs each command to its own file and combines the exit codes is left as an exercise. :) I've never debugged networking stuff and hope never to. I recently installed the Windows network tracing free download thingy for the first time, I forget why, didn't use it much, and have since reinstalled the OS and don't plan on reinstalling the tracer. It did appear quite nice, flexible, great gui for forming filters and such, etc... TortoiseSVN has worked fine for me, on a small tree. I will try TortoiseCVS again some time. I think I didn't tell it about ssh. - Jay > Date: Wed, 23 Jan 2008 00:53:02 +0100> From: ronny.forberger at elegosoft.com> To: rcoleburn at scires.com> CC: m3devel at elegosoft.com; jayk123 at hotmail.com> Subject: Re: [M3devel] next problem (NT386GNU)> > -----BEGIN PGP SIGNED MESSAGE-----> Hash: SHA1> > Olaf Wagner schrieb:> > Quoting Randy Coleburn :> >> >> Jay / Olaf:> >>> >> I installed CVSNT and TortoiseCVS. I am having some trouble with> >> "update" however. When I try to update the whole tree, it begins> >> working, but after a little while I start seeing messages that> >> checksums> >> didn't match on certain files and that it will refetch. Then, after> >> just a little longer, it stops responding. I've left it running for> >> hours, but no new lines scroll by saying it is doing anything.> >> Finally,> >> I just hit cancel and it promptly stops and informs me it aborted the> >> operation, as if it been waiting all along for me to tell it to give> >> up.> >>> >> Now, if I update individual files or selected files, it seems to work> >> no problem. And, I've been able to check out the whole repository,> >> and> >> yes it does take some time to pull everything down. I can also do> >> diffs> >> on selected files. I've also used it to commit a few files to the> >> repository.> >>> >> So, it is working fine, except for update. Either something is amiss,> >> or I'm not doing something just right. I am about to consider going> >> back to cygwin and running its version of cvs on my tree to see if it> >> will do the update, but I seem to recall reading somewhere that is not> >> good to mix between cvs and cvsnt on the same tree.> >> > This is strange. I've never seen that myself before. A complete> > update or checkout should take several minutes via encrypted> > TCP/IP, but not longer (depending on the line bandwidth and latency,> > of course).> >> > Just today I've heard of a customer who suffers from random connection> > problems with Subversion and Windows 2000 workstations; the theory> > there> > being that some TCP/IP parameters are set very strange and the whole> > protocol stack is not up to the task in its default configuration.> > This does not happen on XT or Vista, though, who seem to have> > incorporated> > significant improvements. (It's all rather strange to me, since I'm a> > Unix person myself and used to stable networking.)> >> > So depending on your OS you might want to tweak the TCP parameters a> > little bit to see if it improves. Hard-core debugging of this problem> > will need careful use of tcpdump and produce megabytes of logs;> > but perhaps just using the cvs trace option (cvs -t up ...) will> > give some indication if there's another problem than the underlying> > connection.> >> > There's also nothing against checking out a different workspace> > with the Cygwin cvs to see if that works better. We've made good> > experiences with CVSNT though.> >> > If the problem persists, we could also try to do some tcpdumping on> > the server side (Ronny Forberger would be the one to do it), but this> > will take some preparation time.> >> > @Ronny, perhaps you've got another idea?> Maybe try to enable debug mode on the cvs core programme (cvsnt). Not> sure if dumping network traffic might help. You can also watch the cvs> command running by logging on to modula3.elegosoft.com via ssh.> > You should really first check quality of your network connection to> modula3.elegosoft.com and possibly try if update works with other> implentations of cvs.> > Cheers,> > 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> -----BEGIN PGP SIGNATURE-----> Version: GnuPG v1.4.6 (GNU/Linux)> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org> > iD8DBQFHloHdXa9RCz+1wnMRAi7uAKCLvz8DqU/SeiHr/2FGum0BWOLHNACgl6R8> mk+bxc060/81T2l4IUwpEQU=> =Xe1T> -----END PGP SIGNATURE-----> _________________________________________________________________ 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 Jan 23 06:58:55 2008 From: mika at async.caltech.edu (Mika Nystrom) Date: Tue, 22 Jan 2008 21:58:55 -0800 Subject: [M3devel] next problem (NT386GNU) In-Reply-To: Your message of "Wed, 23 Jan 2008 00:04:35 +0100." <20080123000435.kjtci5bewwcss448@mail.elegosoft.com> Message-ID: <200801230558.m0N5wtQ4034198@camembert.async.caltech.edu> I think Windows 2000 is well known for having some exceptionally nasty bugs in its TCP implementation. In fact my Modula-3 code has special workarounds for win2k: it doesn't download more than a few kilobytes at a time---if you try more, the network card sometimes goes catatonic. There are some notes on it here and there on the Internet. Not sure what the cause is. Mika Olaf Wagner writes: >Quoting Randy Coleburn : > >> Jay / Olaf: >> >> I installed CVSNT and TortoiseCVS. I am having some trouble with >> "update" however. When I try to update the whole tree, it begins >> working, but after a little while I start seeing messages that checksums >> didn't match on certain files and that it will refetch. Then, after >> just a little longer, it stops responding. I've left it running for >> hours, but no new lines scroll by saying it is doing anything. Finally, >> I just hit cancel and it promptly stops and informs me it aborted the >> operation, as if it been waiting all along for me to tell it to give >> up. >> >> Now, if I update individual files or selected files, it seems to work >> no problem. And, I've been able to check out the whole repository, and >> yes it does take some time to pull everything down. I can also do diffs >> on selected files. I've also used it to commit a few files to the >> repository. >> >> So, it is working fine, except for update. Either something is amiss, >> or I'm not doing something just right. I am about to consider going >> back to cygwin and running its version of cvs on my tree to see if it >> will do the update, but I seem to recall reading somewhere that is not >> good to mix between cvs and cvsnt on the same tree. > >This is strange. I've never seen that myself before. A complete >update or checkout should take several minutes via encrypted >TCP/IP, but not longer (depending on the line bandwidth and latency, >of course). > >Just today I've heard of a customer who suffers from random connection >problems with Subversion and Windows 2000 workstations; the theory there >being that some TCP/IP parameters are set very strange and the whole >protocol stack is not up to the task in its default configuration. >This does not happen on XT or Vista, though, who seem to have incorporated >significant improvements. (It's all rather strange to me, since I'm a >Unix person myself and used to stable networking.) > >So depending on your OS you might want to tweak the TCP parameters a >little bit to see if it improves. Hard-core debugging of this problem >will need careful use of tcpdump and produce megabytes of logs; >but perhaps just using the cvs trace option (cvs -t up ...) will >give some indication if there's another problem than the underlying >connection. > >There's also nothing against checking out a different workspace >with the Cygwin cvs to see if that works better. We've made good >experiences with CVSNT though. > >If the problem persists, we could also try to do some tcpdumping on >the server side (Ronny Forberger would be the one to do it), but this >will take some preparation time. > >@Ronny, perhaps you've got another idea? > >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 jayk123 at hotmail.com Wed Jan 23 07:28:01 2008 From: jayk123 at hotmail.com (Jay) Date: Wed, 23 Jan 2008 06:28:01 +0000 Subject: [M3devel] next problem (NT386GNU) In-Reply-To: <200801230558.m0N5wtQ4034198@camembert.async.caltech.edu> References: Your message of "Wed, 23 Jan 2008 00:04:35 +0100." <20080123000435.kjtci5bewwcss448@mail.elegosoft.com> <200801230558.m0N5wtQ4034198@camembert.async.caltech.edu> Message-ID: (I never used Windows 2000 much, but NT 4 worked solidly for a long time (didn't use CVS on it), hard to imagine Windows 2000 regressed much. XP and 2003 are solid, Vista I think is holding up in /this area/. There is the whole IPv4 vs. IPv6 transition still ongoing around the world. I really think Windows is better than its given credit for. Not Win9x, but NT. The Apple BS about being on a solid Unix foundation and all that..it's not like NT doesn't have same model, the same user/kernel isolation.....) Besides..if Cygwin CVS works fine (for me and I think for Randy), either a) it's not the network, or 2) Cygwin has workarounds and TortoiseCVS/CVSNT do not. I doubt #2, but almost anything is possible. Granted, I don't have TortoiseCVS/CVSNT working yet, didn't configure ssh for it. At some hypothetical point I install Win95/98/NT3.x/NT4/Win2000 in virtual machines and see how Modula-3 fairs.. I know the current binaries won't work on Win95/NT3.x due to Interlocked stuff, and some dependency on new processors, same thing (ie: you could inline or statically link such functions, and work on older OS but not on a 386). People should speak up if they expect pre-XP or 386/486/regular old Pentium support. And even then, the processors continue to progress at a surprising-to-me rate, MMX, SSE, SSE2, etc. (Not to mention AMD64..I have an unfortunate hardware situation at home there, might need to get another machine soon...or swap machines in a way I'd rather not..but this is getting ahead of things) - Jay > To: wagner at elegosoft.com> Date: Tue, 22 Jan 2008 21:58:55 -0800> From: mika at async.caltech.edu> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] next problem (NT386GNU)> > > I think Windows 2000 is well known for having some exceptionally> nasty bugs in its TCP implementation. In fact my Modula-3 code has> special workarounds for win2k: it doesn't download more than a few> kilobytes at a time---if you try more, the network card sometimes> goes catatonic. There are some notes on it here and there on the> Internet. Not sure what the cause is.> > Mika > > Olaf Wagner writes:> >Quoting Randy Coleburn :> >> >> Jay / Olaf:> >>> >> I installed CVSNT and TortoiseCVS. I am having some trouble with> >> "update" however. When I try to update the whole tree, it begins> >> working, but after a little while I start seeing messages that checksums> >> didn't match on certain files and that it will refetch. Then, after> >> just a little longer, it stops responding. I've left it running for> >> hours, but no new lines scroll by saying it is doing anything. Finally,> >> I just hit cancel and it promptly stops and informs me it aborted the> >> operation, as if it been waiting all along for me to tell it to give> >> up.> >>> >> Now, if I update individual files or selected files, it seems to work> >> no problem. And, I've been able to check out the whole repository, and> >> yes it does take some time to pull everything down. I can also do diffs> >> on selected files. I've also used it to commit a few files to the> >> repository.> >>> >> So, it is working fine, except for update. Either something is amiss,> >> or I'm not doing something just right. I am about to consider going> >> back to cygwin and running its version of cvs on my tree to see if it> >> will do the update, but I seem to recall reading somewhere that is not> >> good to mix between cvs and cvsnt on the same tree.> >> >This is strange. I've never seen that myself before. A complete> >update or checkout should take several minutes via encrypted> >TCP/IP, but not longer (depending on the line bandwidth and latency,> >of course).> >> >Just today I've heard of a customer who suffers from random connection> >problems with Subversion and Windows 2000 workstations; the theory there> >being that some TCP/IP parameters are set very strange and the whole> >protocol stack is not up to the task in its default configuration.> >This does not happen on XT or Vista, though, who seem to have incorporated> >significant improvements. (It's all rather strange to me, since I'm a> >Unix person myself and used to stable networking.)> >> >So depending on your OS you might want to tweak the TCP parameters a> >little bit to see if it improves. Hard-core debugging of this problem> >will need careful use of tcpdump and produce megabytes of logs;> >but perhaps just using the cvs trace option (cvs -t up ...) will> >give some indication if there's another problem than the underlying> >connection.> >> >There's also nothing against checking out a different workspace> >with the Cygwin cvs to see if that works better. We've made good> >experiences with CVSNT though.> >> >If the problem persists, we could also try to do some tcpdumping on> >the server side (Ronny Forberger would be the one to do it), but this> >will take some preparation time.> >> >@Ronny, perhaps you've got another idea?> >> >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 _________________________________________________________________ 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 Wed Jan 23 08:06:20 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Wed, 23 Jan 2008 08:06:20 +0100 (MET) Subject: [M3devel] platform/build_dir is a big tuple? In-Reply-To: <479605CF.1E75.00D7.1@scires.com> References: <479605CF.1E75.00D7.1@scires.com> Message-ID: On Tue, 22 Jan 2008, Randy Coleburn wrote: > Jay: > > For my part on Windows, I am happy to stay with the underlying OS, the > native windows threading, the integrated backend, and use the free > Microsoft Visual Studio tools. I don't really want to have to > install/use cygwin or any of the other variants. When I see target = > NT386, this list is what I am expecting. For the cm3 newbie coming from > a Microsoft Windows environment, I think this list would be the most > appealing and pose the least barrier to getting starting. Yes, I still > will work on the installer program once I'm satisfied that I have a good > working cm3 on Windows. One year ago I was in the situation to port one of my Modula-3 programs from Linux to Windows in order to hand it over to a Windows user. As I never use Windows, I have only a plain Windows installation on my machine with almost no tools other than cm3. I was glad to be able to run cm3 immediately and to find all libraries that I needed in binary form without Cygwin dependencies - otherwise not only I had to install that on my machine but I also would have to persuade the other Windows guy to install it as well. Summarized I strongly vote for NT386 being Windows with least dependencies on other packages. From jayk123 at hotmail.com Wed Jan 23 08:37:28 2008 From: jayk123 at hotmail.com (Jay) Date: Wed, 23 Jan 2008 07:37:28 +0000 Subject: [M3devel] platform/build_dir is a big tuple? In-Reply-To: References: <479605CF.1E75.00D7.1@scires.com> Message-ID: Let me cut to the chase, again: Everyone will probably be satisfied. For a very small "everyone". :) The underlying implementation shall be "heavily" parameterized. There shall be three visible pre packaged configurations. Power users, and clever and crazy people can experiment beyond those three. The EXACT three configurations is SLIGHTLY up in the air, but is likely to be: NT386 same as today, integrated backend, Win32 GUI, msvc*.dll, native win32 kernel threads, native backslashy paths (and perhaps increased compat with forward slashes, some of that is already in, m3core, but not yet cm3), Visual C++ compiler and linker. NT386MINGNU same as today's (recent) NT386GNU, but with Trestle-on-Win32 also working external backend, gcc compiler and linker, but otherwise same as NT386 One small wrinkle here is there is no m3gdb, but you can use the m3gdb from the next one, or Cygwin's gdb. NT386GNU As GNU as possible. pthreads (uncertain), X Windows (CygwinX), Cygwin C library, stupid looking paths that start /cygdrive, wierdo symlinks that don't interoperate well with the rest of the system (attempting to run cc.exe crashes ntvdm.exe, for example), "link" makes file system links (or at least strange files) instead of linking programs, a slow and perhaps fragile copy-immediately implementation of fork, problems running one type of program from another because you don't know which command line parameters and which environment variables represent paths or lists of paths and therefore how to translate them, etc. The underlying parameters, which are largely independent and which you can change individually, but which you will actually just ignore usually, shall be: modula-3 backend integrated 0 cm3cg 1 This might be replaced by the existing 0-3 variable. C compiler Visual C++ cl 0 gcc 1 In future this could be redefined as decimal digit or a character to accomodate other choices. linker Visual C++ link 0 gcc 1 In future this could be redefined as decimal digit or a character to accomodate other choices. Threading library Native Win32 kernel threads 0 Cygwin pthreads which are probably layered on native Win32 kernel threads 1 This is the one area where people have suggested using native Win32 functionality instead of Cygwin vtalaram user threads probably not available fiber user threads probably not available This would have been better than vtalaram, but not Win9x compatible If anyone wanted user vtlaram or fiber, this could be extended. It probably always should have been fibers instead of setjmp/longjmp where fibers are available... Window library Native Win32 gui 0 (hopefully with bugs to be worked out) X Windows via CygwinX 1 (hopefully the binaries are X server agnostic, and even work against a remote Unix machine?) C library native msvcr* through Visual C++ or MinGWin 0 Cygwin and its path oddities 1 The current notion of "OSTYPE" becomes much less useful here, as it previously embodied multiple factors. It wasn't all that useful anyway, imho, but as a way to reduce the matrix of targets down to two, the same two in multiple places. Now, in a few places, you check a more specific variable. Theoretically, I don't have to change cm3 here, just the config file and some m3makefiles. Because, tricky tricky, the main thing cm3 cares about is the backend "mode", and that does match up above with the 0/1. There are actually 4 modes and I should maybe hoist that up to be the variable, very maybe. A few m3makefiles will have to change, in small ways. Therefore, NT386 is all 0s, NT386GNU shall be all 1s, except maybe threading, and NT386MINGNU shall be a mix -- backend, C compiler, linker 1, the rest 0. Besides that, what I haven't in my head yet, is that individual m3makefiles should be able to ask for one compiler or the other. The base system won't do that, but user systems could, if they have some code that depends on one compiler or the other and they are going to link it together. For this purpose, for exposing these features to users, possibly values other than "0" and "1" are needed. If the configuration is one of these three combinations, build_dir is translated as shown. Otherwise, it is "NT386-" plus the unreadable string of 0s and 1s. This is essentially already commited. NT386 works this way. NT386MINGNU works this, but is for now called NT386GNU, and doesn't have any Trestle yet. The new/old Cygwin NT386GNU isn't active yet, but easily should be. There are three config files, NT386, NT386MINGNU, NT386GNU, they are all just a few lines and then include NT386.common. Oh, one more thing I haven't worked out is how the user asks for one target or another. It is probably via the environment variable CM3_TARGET, though in reality, "TARGET" for all of these shall be NT386. Any questions? Don't ask me when Cygwin NT386GNU will be active or when the names will flip. I will try it soon. This is essentiallyalready in the tree, with a little bit of "temporary, for compat" sprinkled in to avoid renaming NT386GNU/MINGNU just yet, and the Cygwinish stuff not active, no X Windows on NT386 yet..groundwork is laid, I think I've stopped thinking through the indecisiveness, I just keep hearing the two extreme sides, the Windows users who want Windows (do you even care about the gcc backend? It's slow. It generates inefficient code. It supports Longint) and a few Unix users who might reluctantly use Windows a little more if their backend slowed down and their libraries changed... Personally my main goal here is to not feel guilty about not finishing the LONGINT support yet in the integrated backend. I'd still like to finish that, but it was taking embarassingly long. I'd also like an uber-cross build environment, where I can build anything from anything. Getting cm3cg working was part of that. I'm not sure I have the patience to build gcc and ld/binutils that many times though. - Jay > Date: Wed, 23 Jan 2008 08:06:20 +0100> From: lemming at henning-thielemann.de> Subject: Re: [M3devel] platform/build_dir is a big tuple?> To: rcoleburn at scires.com> CC: m3devel at elegosoft.com; jayk123 at hotmail.com> > > On Tue, 22 Jan 2008, Randy Coleburn wrote:> > > Jay:> >> > For my part on Windows, I am happy to stay with the underlying OS, the> > native windows threading, the integrated backend, and use the free> > Microsoft Visual Studio tools. I don't really want to have to> > install/use cygwin or any of the other variants. When I see target => > NT386, this list is what I am expecting. For the cm3 newbie coming from> > a Microsoft Windows environment, I think this list would be the most> > appealing and pose the least barrier to getting starting. Yes, I still> > will work on the installer program once I'm satisfied that I have a good> > working cm3 on Windows.> > One year ago I was in the situation to port one of my Modula-3 programs> from Linux to Windows in order to hand it over to a Windows user. As I> never use Windows, I have only a plain Windows installation on my machine> with almost no tools other than cm3. I was glad to be able to run cm3> immediately and to find all libraries that I needed in binary form without> Cygwin dependencies - otherwise not only I had to install that on my> machine but I also would have to persuade the other Windows guy to install> it as well. Summarized I strongly vote for NT386 being Windows with least> dependencies on other packages. _________________________________________________________________ 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 Jan 23 08:22:54 2008 From: mika at async.caltech.edu (Mika Nystrom) Date: Tue, 22 Jan 2008 23:22:54 -0800 Subject: [M3devel] platform/build_dir is a big tuple? In-Reply-To: Your message of "Wed, 23 Jan 2008 08:06:20 +0100." Message-ID: <200801230722.m0N7Msbc036278@camembert.async.caltech.edu> Henning Thielemann writes: > >On Tue, 22 Jan 2008, Randy Coleburn wrote: > >> Jay: >> >> For my part on Windows, I am happy to stay with the underlying OS, the >> native windows threading, the integrated backend, and use the free >> Microsoft Visual Studio tools. I don't really want to have to >> install/use cygwin or any of the other variants. When I see target = >> NT386, this list is what I am expecting. For the cm3 newbie coming from >> a Microsoft Windows environment, I think this list would be the most >> appealing and pose the least barrier to getting starting. Yes, I still >> will work on the installer program once I'm satisfied that I have a good >> working cm3 on Windows. > >One year ago I was in the situation to port one of my Modula-3 programs >from Linux to Windows in order to hand it over to a Windows user. As I >never use Windows, I have only a plain Windows installation on my machine >with almost no tools other than cm3. I was glad to be able to run cm3 >immediately and to find all libraries that I needed in binary form without >Cygwin dependencies - otherwise not only I had to install that on my >machine but I also would have to persuade the other Windows guy to install >it as well. Summarized I strongly vote for NT386 being Windows with least >dependencies on other packages. My experience was almost the opposite. I had a complicated system running on Unix, using Modula-3 for most of its implementation but all sorts of other dirty glue to run properly, and various calls to libc routines. A couple of Windows people told me "please run this stuff on our machine [we don't care how you do it]". I promptly installed Cygwin and got the whole thing running with a fairly small amount of fuss. Accordingly, I vote for NT386GNU being a Cygwin thing that looks as much like Unix as possible! I can certainly see the other point of view, but is there a great need for something between these two extremes? If I were the one putting together Modula-3 compilers for Windows, I'd do those two (not sure which one first) and not worry about all the other permutations of threading libraries, compilers, etc. Mika From jayk123 at hotmail.com Wed Jan 23 08:49:28 2008 From: jayk123 at hotmail.com (Jay) Date: Wed, 23 Jan 2008 07:49:28 +0000 Subject: [M3devel] platform/build_dir is a big tuple? In-Reply-To: References: <479605CF.1E75.00D7.1@scires.com> Message-ID: > If anyone wanted user vtlaram or fiber, this could be extended. > It probably always should have been fibers instead of setjmp/longjmp where fibers are available... Oh, sorry, Modula-3 has never to my knowledge used user/vtalarm threads. If anyone does want to take over their own scheduling and have an N:M model, fibers are perhaps the way to go, unless you need Win9x. Fibers take care of creating a stack and swapping register context, whereas setjmp/longjmp only swap register context and I suspect Modula-3 uses them in a non-conformant but generally-compatible way. I haven't looked into this yet. For exceptions, ok. For thread switching, probably not. But I'd have to look at how it's implemented.. user mode threads, fibers..are problematic. For example Win32 critical sections can be taken recursively, on the same thread. Fibers can move around between threads and therefore cannot take them recursively. All in all, as said below, I'm inclined to omit support for user mode threads on Windows. I ASSUME the Cygwin pthreads are a thin wrapper over Windows, except...except there is the condition variables...not sure they can be layered over thinly... As I said, this is one bit I am uncertan of. Maybe just always use native Win32 threads. It would be a perhaps interesting curiosity to see if cygwin binaries tend to only depend on cygwin .dlls and not win32 .dlls, as a "proof" of the "completeness" of the layer/wrapping. (though as to the quality, see below.) Of course, cygwin code can still use win32..your m3makefile might actually check target==nt386 to know "the truth". But I doubt anyone would use this flexibility. - Jay From: jayk123 at hotmail.comTo: lemming at henning-thielemann.de; rcoleburn at scires.comCC: m3devel at elegosoft.comSubject: RE: [M3devel] platform/build_dir is a big tuple?Date: Wed, 23 Jan 2008 07:37:28 +0000 Let me cut to the chase, again: Everyone will probably be satisfied. For a very small "everyone". :) The underlying implementation shall be "heavily" parameterized.There shall be three visible pre packaged configurations.Power users, and clever and crazy people can experiment beyond those three.The EXACT three configurations is SLIGHTLY up in the air, but is likely to be: NT386 same as today, integrated backend, Win32 GUI, msvc*.dll, native win32 kernel threads, native backslashy paths (and perhaps increased compat with forward slashes, some of that is already in, m3core, but not yet cm3), Visual C++ compiler and linker. NT386MINGNU same as today's (recent) NT386GNU, but with Trestle-on-Win32 also working external backend, gcc compiler and linker, but otherwise same as NT386 One small wrinkle here is there is no m3gdb, but you can use the m3gdb from the next one, or Cygwin's gdb. NT386GNU As GNU as possible. pthreads (uncertain), X Windows (CygwinX), Cygwin C library, stupid looking paths that start /cygdrive, wierdo symlinks that don't interoperate well with the rest of the system (attempting to run cc.exe crashes ntvdm.exe, for example), "link" makes file system links (or at least strange files) instead of linking programs, a slow and perhaps fragile copy-immediately implementation of fork, problems running one type of program from another because you don't know which command line parameters and which environment variables represent paths or lists of paths and therefore how to translate them, etc. The underlying parameters, which are largely independent and which you can change individually, but which you will actually just ignore usually, shall be: modula-3 backend integrated 0 cm3cg 1 This might be replaced by the existing 0-3 variable. C compiler Visual C++ cl 0 gcc 1 In future this could be redefined as decimal digit or a character to accomodate other choices. linker Visual C++ link 0 gcc 1 In future this could be redefined as decimal digit or a character to accomodate other choices. Threading library Native Win32 kernel threads 0 Cygwin pthreads which are probably layered on native Win32 kernel threads 1 This is the one area where people have suggested using native Win32 functionality instead of Cygwin vtalaram user threads probably not available fiber user threads probably not available This would have been better than vtalaram, but not Win9x compatible If anyone wanted user vtlaram or fiber, this could be extended. It probably always should have been fibers instead of setjmp/longjmp where fibers are available... Window library Native Win32 gui 0 (hopefully with bugs to be worked out) X Windows via CygwinX 1 (hopefully the binaries are X server agnostic, and even work against a remote Unix machine?) C library native msvcr* through Visual C++ or MinGWin 0 Cygwin and its path oddities 1 The current notion of "OSTYPE" becomes much less useful here, as it previously embodied multiple factors. It wasn't all that useful anyway, imho, but as a way to reduce the matrix of targets down to two, the same two in multiple places. Now, in a few places, you check a more specific variable. Theoretically, I don't have to change cm3 here, just the config file and some m3makefiles. Because, tricky tricky, the main thing cm3 cares about is the backend "mode", and that does match up above with the 0/1. There are actually 4 modes and I should maybe hoist that up to be the variable, very maybe. A few m3makefiles will have to change, in small ways. Therefore, NT386 is all 0s, NT386GNU shall be all 1s, except maybe threading, and NT386MINGNU shall be a mix -- backend, C compiler, linker 1, the rest 0. Besides that, what I haven't in my head yet, is that individual m3makefiles should be able to ask for one compiler or the other. The base system won't do that, but user systems could, if they have some code that depends on one compiler or the other and they are going to link it together. For this purpose, for exposing these features to users, possibly values other than "0" and "1" are needed. If the configuration is one of these three combinations, build_dir is translated as shown.Otherwise, it is "NT386-" plus the unreadable string of 0s and 1s. This is essentially already commited. NT386 works this way. NT386MINGNU works this, but is for now called NT386GNU, and doesn't have any Trestle yet. The new/old Cygwin NT386GNU isn't active yet, but easily should be. There are three config files, NT386, NT386MINGNU, NT386GNU, they are all just a few lines and then include NT386.common. Oh, one more thing I haven't worked out is how the user asks for one target or another.It is probably via the environment variable CM3_TARGET, though in reality, "TARGET" for all of these shall be NT386. Any questions?Don't ask me when Cygwin NT386GNU will be active or when the names will flip. I will try it soon. This is essentiallyalready in the tree, with a little bit of "temporary, for compat" sprinkled in to avoid renaming NT386GNU/MINGNU just yet, and the Cygwinish stuff not active, no X Windows on NT386 yet..groundwork is laid, I think I've stopped thinking through the indecisiveness, I just keep hearing the two extreme sides, the Windows users who want Windows (do you even care about the gcc backend? It's slow. It generates inefficient code. It supports Longint) and a few Unix users who might reluctantly use Windows a little more if their backend slowed down and their libraries changed... Personally my main goal here is to not feel guilty about not finishing the LONGINT support yet in the integrated backend.I'd still like to finish that, but it was taking embarassingly long. I'd also like an uber-cross build environment, where I can build anything from anything. Getting cm3cg working was part of that. I'm not sure I have the patience to build gcc and ld/binutils that many times though. - Jay > Date: Wed, 23 Jan 2008 08:06:20 +0100> From: lemming at henning-thielemann.de> Subject: Re: [M3devel] platform/build_dir is a big tuple?> To: rcoleburn at scires.com> CC: m3devel at elegosoft.com; jayk123 at hotmail.com> > > On Tue, 22 Jan 2008, Randy Coleburn wrote:> > > Jay:> >> > For my part on Windows, I am happy to stay with the underlying OS, the> > native windows threading, the integrated backend, and use the free> > Microsoft Visual Studio tools. I don't really want to have to> > install/use cygwin or any of the other variants. When I see target => > NT386, this list is what I am expecting. For the cm3 newbie coming from> > a Microsoft Windows environment, I think this list would be the most> > appealing and pose the least barrier to getting starting. Yes, I still> > will work on the installer program once I'm satisfied that I have a good> > working cm3 on Windows.> > One year ago I was in the situation to port one of my Modula-3 programs> from Linux to Windows in order to hand it over to a Windows user. As I> never use Windows, I have only a plain Windows installation on my machine> with almost no tools other than cm3. I was glad to be able to run cm3> immediately and to find all libraries that I needed in binary form without> Cygwin dependencies - otherwise not only I had to install that on my> machine but I also would have to persuade the other Windows guy to install> it as well. Summarized I strongly vote for NT386 being Windows with least> dependencies on other packages. 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 mika at async.caltech.edu Wed Jan 23 08:50:49 2008 From: mika at async.caltech.edu (Mika Nystrom) Date: Tue, 22 Jan 2008 23:50:49 -0800 Subject: [M3devel] platform/build_dir is a big tuple? In-Reply-To: Your message of "Wed, 23 Jan 2008 07:37:28 GMT." Message-ID: <200801230750.m0N7onlw036945@camembert.async.caltech.edu> This sounds wonderful!! Mika P.S. Personally I don't care about pthreads, user threads, or any other kind of threads. I think Modula-3 threads are beautiful (one of the real strengths of the language, in fact), and good as never see a need to delve any lower than that. Win32 threads work fine on the old NT386GNU. There were no pthreads back then, and probably Win32 threads are better than user threads anyhow... (in the sense of requiring fewest "anti-blocking" hacks). Of course there might be someone out there who doesn't agree, and needs Modula-3 threads to be built on pthreads for some reason... Jay writes: >--_6a1e3166-9b30-4149-b10d-8b7fe22a1ec0_ >Content-Type: text/plain; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > >Let me cut to the chase, again: >=20 > Everyone will probably be satisfied.=20 > For a very small "everyone". :)=20 >=20 >The underlying implementation shall be "heavily" parameterized. >There shall be three visible pre packaged configurations. >Power users, and clever and crazy people can experiment beyond those three. >The EXACT three configurations is SLIGHTLY up in the air, but is likely to = >be: >=20 >NT386 > same as today, integrated backend, Win32 GUI, msvc*.dll, native win32 ker= >nel threads, native backslashy paths (and perhaps increased compat with for= >ward slashes, some of that is already in, m3core, but not yet cm3), Visual = >C++ compiler and linker. >=20 >NT386MINGNU > same as today's (recent) NT386GNU, but with Trestle-on-Win32 also working= >=20 > external backend, gcc compiler and linker, but otherwise same as NT386 > One small wrinkle here is there is no m3gdb, but you can use the m3gdb fr= >om the next one, or Cygwin's gdb. >=20 >NT386GNU > As GNU as possible. pthreads (uncertain), X Windows (CygwinX), Cygwin C l= >ibrary, stupid looking paths that start /cygdrive, wierdo symlinks that don= >'t interoperate well with the rest of the system (attempting to run cc.exe = >crashes ntvdm.exe, for example), "link" makes file system links (or at leas= >t strange files) instead of linking programs, a slow and perhaps fragile co= >py-immediately implementation of fork, problems running one type of program= > from another because you don't know which command line parameters and whic= >h environment variables represent paths or lists of paths and therefore how= > to translate them, etc.=20 >The underlying parameters, which are largely independent and which you can = >change individually, but which you will actually just ignore usually, shall= > be: >=20 > modula-3 backend > integrated 0 > cm3cg 1 > This might be replaced by the existing 0-3 variable. >=20 > C compiler =20 > Visual C++ cl 0 > gcc 1 > In future this could be redefined as decimal digit or a character to ac= >comodate other choices. >=20 > linker > Visual C++ link 0 > gcc 1 > In future this could be redefined as decimal digit or a character to ac= >comodate other choices. >=20 > Threading library > Native Win32 kernel threads 0 > Cygwin pthreads which are probably layered on native Win32 kernel thre= >ads 1 > This is the one area where people have suggested using native Win32 fu= >nctionality instead of Cygwin > vtalaram user threads probably not available > fiber user threads probably not available > This would have been better than vtalaram, but not Win9x compatib= >le > If anyone wanted user vtlaram or fiber, this could be extended. It pro= >bably always should have been fibers instead of setjmp/longjmp where fibers= > are available... >=20 > Window library > Native Win32 gui 0 (hopefully with bugs to be worked out)=20 > X Windows via CygwinX 1 (hopefully the binaries are X server agnostic= >, and even work against a remote Unix machine?) >=20 > C library > native msvcr* through Visual C++ or MinGWin 0 > Cygwin and its path oddities 1=20 >=20 >The current notion of "OSTYPE" becomes much less useful here, as it previou= >sly embodied multiple factors. > It wasn't all that useful anyway, imho, but as a way to reduce the matrix = >of targets down to two, the same two in multiple places. Now, in a few plac= >es, you check a more specific variable. Theoretically, I don't have to chan= >ge cm3 here, just the config file and some m3makefiles. Because, tricky tri= >cky, the main thing cm3 cares about is the backend "mode", and that does ma= >tch up above with the 0/1. There are actually 4 modes and I should maybe ho= >ist that up to be the variable, very maybe. A few m3makefiles will have to = >change, in small ways. >=20 > Therefore, NT386 is all 0s, NT386GNU shall be all 1s, except maybe thread= >ing, and NT386MINGNU shall be a mix -- backend, C compiler, linker 1, the r= >est 0. Besides that, what I haven't in my head yet, is that individual m3ma= >kefiles should be able to ask for one compiler or the other. The base syste= >m won't do that, but user systems could, if they have some code that depend= >s on one compiler or the other and they are going to link it together. For = >this purpose, for exposing these features to users, possibly values other t= >han "0" and "1" are needed. >=20 >If the configuration is one of these three combinations, build_dir is trans= >lated as shown. >Otherwise, it is "NT386-" plus the unreadable string of 0s and 1s. >=20 >This is essentially already commited. NT386 works this way. NT386MINGNU wor= >ks this, but is for now called NT386GNU, and doesn't have any Trestle yet. = >The new/old Cygwin NT386GNU isn't active yet, but easily should be. >=20 >There are three config files, NT386, NT386MINGNU, NT386GNU, they are all ju= >st a few lines and then include NT386.common. >=20 >Oh, one more thing I haven't worked out is how the user asks for one target= > or another. >It is probably via the environment variable CM3_TARGET, though in reality, = >"TARGET" for all of these shall be NT386. >=20 >Any questions? >Don't ask me when Cygwin NT386GNU will be active or when the names will fli= >p. I will try it soon. >=20 >This is essentiallyalready in the tree, with a little bit of "temporary, fo= >r compat" sprinkled in to avoid renaming NT386GNU/MINGNU just yet, and the = >Cygwinish stuff not active, no X Windows on NT386 yet..groundwork is laid, = >I think I've stopped thinking through the indecisiveness, I just keep heari= >ng the two extreme sides, the Windows users who want Windows (do you even c= >are about the gcc backend? It's slow. It generates inefficient code. It sup= >ports Longint) and a few Unix users who might reluctantly use Windows a lit= >tle more if their backend slowed down and their libraries changed... >=20 >Personally my main goal here is to not feel guilty about not finishing the = >LONGINT support yet in the integrated backend. >I'd still like to finish that, but it was taking embarassingly long. >=20 >I'd also like an uber-cross build environment, where I can build anything f= >rom anything. Getting cm3cg working was part of that. I'm not sure I have t= >he patience to build gcc and ld/binutils that many times though. >=20 > - Jay > > > >> Date: Wed, 23 Jan 2008 08:06:20 +0100> From: lemming at henning-thielemann.d= >e> Subject: Re: [M3devel] platform/build_dir is a big tuple?> To: rcoleburn= >@scires.com> CC: m3devel at elegosoft.com; jayk123 at hotmail.com> > > On Tue, 22= > Jan 2008, Randy Coleburn wrote:> > > Jay:> >> > For my part on Windows, I = >am happy to stay with the underlying OS, the> > native windows threading, t= >he integrated backend, and use the free> > Microsoft Visual Studio tools. I= > don't really want to have to> > install/use cygwin or any of the other var= >iants. When I see target =3D> > NT386, this list is what I am expecting. Fo= >r the cm3 newbie coming from> > a Microsoft Windows environment, I think th= >is list would be the most> > appealing and pose the least barrier to gettin= >g starting. Yes, I still> > will work on the installer program once I'm sat= >isfied that I have a good> > working cm3 on Windows.> > One year ago I was = >in the situation to port one of my Modula-3 programs> from Linux to Windows= > in order to hand it over to a Windows user. As I> never use Windows, I hav= >e only a plain Windows installation on my machine> with almost no tools oth= >er than cm3. I was glad to be able to run cm3> immediately and to find all = >libraries that I needed in binary form without> Cygwin dependencies - other= >wise not only I had to install that on my> machine but I also would have to= > persuade the other Windows guy to install> it as well. Summarized I strong= >ly vote for NT386 being Windows with least> dependencies on other packages. >_________________________________________________________________ >Connect and share in new ways with Windows Live. >http://www.windowslive.com/share.html?ocid=3DTXT_TAGHM_Wave2_sharelife_0120= >08= > >--_6a1e3166-9b30-4149-b10d-8b7fe22a1ec0_ >Content-Type: text/html; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > > > > >Let me cut to the chase, again:
> 
> Everyone will probably be satisfied.
> For a very small "everyone". :)
> 
>The underlying implementation shall be "heavily" parameterized.
>There shall be three visible pre packaged configurations.
>Power users, and clever and crazy people can experiment beyond those three.= >
>The EXACT three configurations is SLIGHTLY up in the air, but is likely to = >be:
> 
>NT386
>  same as today, integrated backend, Win32 GUI, msvc*.dll, native win3= >2 kernel threads, native backslashy paths (and perhaps increased compat wit= >h forward slashes, some of that is already in, m3core, but not yet cm3), Vi= >sual C++ compiler and linker.
> 
>NT386MINGNU
>  same as today's (recent) NT386GNU, but with Trestle-on-Win32 al= >so working
>   external backend, gcc compiler and linker, but otherwise same = >as NT386
>  One small wrinkle here is there is no m3gdb, but you can use the m3g= >db from the next one, or Cygwin's gdb.
> 
>NT386GNU
>  As GNU as possible. pthreads (uncertain), X Windows (CygwinX), Cygwi= >n C library, stupid looking paths that start /cygdrive, wierdo symlinks tha= >t don't interoperate well with the rest of the system (attempting to run cc= >.exe crashes ntvdm.exe, for example), "link" makes file system links (or at= > least strange files) instead of linking programs, a slow and perhaps = >fragile copy-immediately implementation of fork, problems running one type = >of program from another because you don't know which command line parameter= >s and which environment variables represent paths or lists of paths and the= >refore how to translate them, etc.

>The underlying parameters, which are largely independent and which you can = >change individually, but which you will actually just ignore usually, = >shall be:
> 
>  modula-3 backend
>     integrated 0
>     cm3cg 1
>   This might be replaced by the existing 0-3 variable.
> 
>  C compiler 
>    Visual C++ cl 0
>    gcc 1
>    In future this could be redefined as decimal digit or a = >character to accomodate other choices.
> 
>  linker
>     Visual C++ link 0
>     gcc 1
>    In future this could be redefined as decimal digit or a = >character to accomodate other choices.
> 
>   Threading library
>     Native Win32 kernel threads 0
>     Cygwin pthreads which are probably layered on nati= >ve Win32 kernel threads 1
>     This is the one area where people have suggested u= >sing native Win32 functionality instead of Cygwin
>     vtalaram user threads probably not available
>     fiber user threads probably not available
>          This would have been= > better than vtalaram, but not Win9x compatible
>     If anyone wanted user vtlaram or fiber, this could= > be extended. It probably always should have been fibers instead of setjmp/= >longjmp where fibers are available...
> 
>   Window library
>      Native Win32 gui 0 (hopefully with bugs to b= >e worked out)
>      X Windows via CygwinX 1 (hopefully the binar= >ies are X server agnostic, and even work against a remote Unix machine?)> > 
>    C library
>      native msvcr* through Visual C++ or MinGWin = >0
>      Cygwin and its path oddities 1
> 
>The current notion of "OSTYPE" becomes much less useful here, as it previou= >sly embodied multiple factors.
> It wasn't all that useful anyway, imho, but as a way to reduce the ma= >trix of targets down to two, the same two in multiple places. Now, in a few= > places, you check a more specific variable. Theoretically, I don't have to= > change cm3 here, just the config file and some m3makefiles. Because, trick= >y tricky, the main thing cm3 cares about is the backend "mode", and that do= >es match up above with the 0/1. There are actually 4 modes and I should may= >be hoist that up to be the variable, very maybe. A few m3makefiles will hav= >e to change, in small ways.
> 
>  Therefore, NT386 is all 0s, NT386GNU shall be all 1s, exce= >pt maybe threading, and NT386MINGNU shall be a mix -- backend, C = >compiler, linker 1, the rest 0. Besides that, what I haven't in my head yet= >, is that individual m3makefiles should be able to ask for one compiler or = >the other. The base system won't do that, but user systems could, if they h= >ave some code that depends on one compiler or the other and they are going = >to link it together. For this purpose, for exposing these features to users= >, possibly values other than "0" and "1" are needed.
> 
>If the configuration is one of these three combinations, build_dir is trans= >lated as shown.
>Otherwise, it is "NT386-" plus the unreadable string of 0s and 1s.
> 
>This is essentially already commited. NT386 works this way. NT386MINGNU wor= >ks this, but is for now called NT386GNU, and doesn't have any Trestle yet. = >The new/old Cygwin NT386GNU isn't active yet, but easily should be.
> 
>There are three config files, NT386, NT386MINGNU, NT386GNU, they are all ju= >st a few lines and then include NT386.common.
> 
>Oh, one more thing I haven't worked out is how the user asks for one target= > or another.
>It is probably via the environment variable CM3_TARGET, though in reality, = >"TARGET" for all of these shall be NT386.
> 
>Any questions?
>Don't ask me when Cygwin NT386GNU will be active or when the names will fli= >p. I will try it soon.
> 
>This is essentiallyalready in the tree, with a little bit of "temp= >orary, for compat" sprinkled in to avoid renaming NT386GNU/MINGNU just yet,= > and the Cygwinish stuff not active, no X Windows on NT386 yet..groundwork = >is laid, I think I've stopped thinking through the indecisiveness, I just k= >eep hearing the two extreme sides, the Windows users who want Windows (do y= >ou even care about the gcc backend? It's slow. It generates inefficient cod= >e. It supports Longint) and a few Unix users who might reluctantly use Wind= >ows a little more if their backend slowed down and their libraries changed.= >..
> 
>Personally my main goal here is to not feel guilty about not finishing the = >LONGINT support yet in the integrated backend.
>I'd still like to finish that, but it was taking embarassingly long.
> 
>I'd also like an uber-cross build environment, where I can build anything f= >rom anything. Getting cm3cg working was part of that. I'm not sure I have t= >he patience to build gcc and ld/binutils that many times though.
> 
>   - Jay


> >
>
>> Date: Wed, 23 Jan 2008 08:06:20 +0100
> From: lemming at henning-th= >ielemann.de
> Subject: Re: [M3devel] platform/build_dir is a big tupl= >e?
> To: rcoleburn at scires.com
> CC: m3devel at elegosoft.com; jayk= >123 at hotmail.com
>
>
> On Tue, 22 Jan 2008, Randy Colebu= >rn wrote:
>
> > Jay:
> >
> > For my part = >on Windows, I am happy to stay with the underlying OS, the
> > nat= >ive windows threading, the integrated backend, and use the free
> >= >; Microsoft Visual Studio tools. I don't really want to have to
> >= >; install/use cygwin or any of the other variants. When I see target =3D>> > NT386, this list is what I am expecting. For the cm3 newbie comi= >ng from
> > a Microsoft Windows environment, I think this list wou= >ld be the most
> > appealing and pose the least barrier to getting= > starting. Yes, I still
> > will work on the installer program onc= >e I'm satisfied that I have a good
> > working cm3 on Windows.
= >>
> One year ago I was in the situation to port one of my Modula-= >3 programs
> from Linux to Windows in order to hand it over to a Wind= >ows user. As I
> never use Windows, I have only a plain Windows insta= llation on my machine
> with almost no tools other than cm3. I was gl= >ad to be able to run cm3
> immediately and to find all libraries that= > I needed in binary form without
> Cygwin dependencies - otherwise no= >t only I had to install that on my
> machine but I also would have to= > persuade the other Windows guy to install
> it as well. Summarized I= > strongly vote for NT386 being Windows with least
> dependencies on o= >ther packages.


Connect and share in new ways with Window= >s Live. ave2_sharelife_012008' target=3D'_new'>Get it now! >= > >--_6a1e3166-9b30-4149-b10d-8b7fe22a1ec0_-- From jayk123 at hotmail.com Wed Jan 23 09:11:21 2008 From: jayk123 at hotmail.com (Jay) Date: Wed, 23 Jan 2008 08:11:21 +0000 Subject: [M3devel] ABIs and combinatorial configuration explosion in another project Message-ID: Our main concern here is jmpbuf size. And possibly exception interop. C++ throw should run Modula-3 finally en route to the C++ catch, and vice versa. Bonus points if each language can catch each other's exceptions, by type. Oh and interop with other Modula-3 compilers. :) Btw, you can see how profiling munges build_dir, same thing. http://www.boost.org/more/separate_compilation.html#static_or_dynamic Preventing Compiler ABI Clashes There are some compilers (mostly Microsoft Windows compilers again!), which feature a range of compiler switches that alter the ABI of C++ classes and functions. By way of example, consider Borland's compiler which has the following options:-b (on or off - effects enum sizes). -Vx (on or off - empty members). -Ve (on or off - empty base classes). -aX (alignment - 5 options). -pX (Calling convention - 4 options). -VmX (member pointer size and layout - 5 options). -VC (on or off, changes name mangling). -Vl (on or off, changes struct layout). These options are provided in addition to those affecting which runtime library is used (more on which later); the total number of combinations of options can be obtained by multiplying together the individual options above, so that gives 2*2*2*5*4*5*2*2 = 3200 combinations! The problem is that users often expect to be able to build the Boost libraries and then just link to them and have everything just plain work, no matter what their project settings are. Irrespective of whether this is a reasonable expectation or not, without some means of managing this issue, the user may well find that their program will experience strange and hard to track down crashes at runtime unless the library they link to was built with the same options as their project (changes to the default alignment setting are a prime culprit). One way to manage this is with "prefix and suffix" headers: these headers invoke compiler specific #pragma directives to instruct the compiler that whatever code follows was built (or is to be built) with a specific set of compiler ABI settings. .... For example the regex libraries get named as follows when built with Visual Studio .NET 2003:boost_regex-vc71-mt-1_31.lib boost_regex-vc71-mt-gd-1_31.lib libboost_regex-vc71-mt-1_31.lib libboost_regex-vc71-mt-gd-1_31.lib libboost_regex-vc71-mt-s-1_31.lib libboost_regex-vc71-mt-sgd-1_31.lib libboost_regex-vc71-s-1_31.lib libboost_regex-vc71-sgd-1_31.lib The difficulty now is selecting which of these the user should link his or her code to. _________________________________________________________________ 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 Wed Jan 23 09:27:55 2008 From: jayk123 at hotmail.com (Jay) Date: Wed, 23 Jan 2008 08:27:55 +0000 Subject: [M3devel] platform/build_dir is a big tuple? In-Reply-To: <200801230722.m0N7Msbc036278@camembert.async.caltech.edu> References: Your message of "Wed, 23 Jan 2008 08:06:20 +0100." <200801230722.m0N7Msbc036278@camembert.async.caltech.edu> Message-ID: > but is there a great need for something between these two extremes? Unclear I agree. It was useful as a stepping stone to the other extreme. The problems with it were "portable", though PM3 already solved one of them. It's the closest thing *today* to NT386 that supports LONGINT and mitigates my guilt about that. :) IN FACT, oh crap I thought I was done thinking about this. In fact the NT386 distribution could include cm3cg/as and whenever source uses LONGINT, compile it with it. Hacky. Hopefully to be avoided by really fixing the integrated backend. There do exist MinGWin and MSys, so I'm not the one who thought of this in-between.There is even "GCW" but it seems stillborn. Anyway, I'm pretty sure this discusion can wind down now. :) (I didn't say end, I said wind down. :) ) Unless anyone really dislikes how I've structured the config files and my upcoming cm3 changes that I think will be very very very small. I'm thinking..TARGET will remain NT386, NT386GNU will all but go away, as a target, it will live on as a "configuration", of which cm3 knows nothing, OS_TYPE will vary, and it will determine jmpbuf size..is that sleazy? Integrated backend vs. non integrated backend will determine the calling convention issues. Backend mode is correct asis. Alternatives to keying off of OS_TYPE in cm3: 1) Key off a new variable called currently "CLibrary", usually ignored. But on NT386 has the values 0 and 1. 2) Have the config file set jmpbuf size itself, and have cm3 know about that new variable. Hard to argue with that. The config file already has the power to subtley destroy things through script, witness double alignment. 3) look into why cygwin has a larger jmpbuf, if msvc*dll setjmp can be used instead, or m3core.dll can have its own m3_setjmp and export it. Might be better to call it something more abstract, like m3_try_for_except and m3_try_for_finally. 4) Blow up the jmpbuf size unconditionally on NT386. Bigger than necessary should work fine, but is wasteful. #3 Looking into the cygwin jmpbuf is pretty much an absolute. Heck, maybe it's just padding for the future, or maybe only used depending on something... 5) Abandon 386 and move on to AMD64. :) - Jay _________________________________________________________________ Shed those extra pounds with MSN and The Biggest Loser! http://biggestloser.msn.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcoleburn at scires.com Wed Jan 23 09:50:10 2008 From: rcoleburn at scires.com (Randy Coleburn) Date: Wed, 23 Jan 2008 03:50:10 -0500 Subject: [M3devel] new problem on NT386 Message-ID: <4796B970.1E75.00D7.1@scires.com> As you know, I am working to finalize the new Reactor. I've run into a new problem that did not exist on cm3 v5.2.6 or on cm3 v4.1, so I am hoping someone, perhaps Jay, can shed some light. Reactor uses quake function calls to invoke operations like build, clean, ship, etc. I have determined that the change directory (cd) call is not working properly. Here is an example quake function used by Reactor to build a package: proc build_package (pkg, options) is exec ("cd", pkg, "| cm3", options) end If I had a package "Hello" located in C:\MyPkgs\Hello, here is what the exec call looks like: exec ("cd C:\MyPkgs\Hello | cm3") What is happening is that the "cd" is ignored and "cm3" is being called in the current directory (whichever that happens to be). Thus, the cm3.exe can't find the sources for the package. I've gone back to the old v5.2.6, and this wrong behavior does not occur. Instead, everything works as it should. So something has changed since that point in time that is causing a problem. Any ideas? Regards, Randy -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Wed Jan 23 10:11:15 2008 From: jayk123 at hotmail.com (Jay) Date: Wed, 23 Jan 2008 09:11:15 +0000 Subject: [M3devel] new problem on NT386 In-Reply-To: <4796B970.1E75.00D7.1@scires.com> References: <4796B970.1E75.00D7.1@scires.com> Message-ID: Surprising, but I'm sure it is trivial. For now try this: exec ("cmd", "/c \"", pkg, "| cm3", options, "\"") and if that doesn't work > "foo.cmd" in write(pkg, "| cm3", options) end exec("foo.cmd") or in the very unlikely change THAT doesn't work, exec("cmd /c foo.cmd") or exec("cmd", "/c", "foo.cmd") See version.quake for examples. cd %cvsroot% dir /s/b version.quake I'm embarrased about my proficiency with cmd and Quake. :) Actually for an even better related example maybe, look at m3cc\m3makefile and m3gdb\m3makefile. dir /s/b %cvsroot%\m3makefile | findstr /i m3cc have quick edit turned on in your cmd double click the output, right click once maybe (it's hard to remember verbally the muscle memory here) and then file.open, paste the Windows command line is nice! until you to start "programming it" with cmd (and then it can be nice, but not for long).... You will be sitting in the target directory likely so you don't need a unique file name. I have been prepending "private" temporary files with "_m3", like "_m3responsefile.txt", "_m3something.cmd". CM3 uses ".M3" but I don't like hidden files as that achieves on Unix, they just hide stuff that inevitably should be visible. (I keep going back and forth about the "@" characters in config files. For now, I have revealed the once per directory mklib and link/gcc, and the occasional C compilation, but kept hidden the repeated runs of m3cg and as; don't worry, this only applies to NT386 and my config-no-install directory.) What, Reactor is implemented in Quake instead of Modula-3? :) Later, - Jay Date: Wed, 23 Jan 2008 03:50:10 -0500From: rcoleburn at scires.comTo: m3devel at elegosoft.comSubject: [M3devel] new problem on NT386 As you know, I am working to finalize the new Reactor. I've run into a new problem that did not exist on cm3 v5.2.6 or on cm3 v4.1, so I am hoping someone, perhaps Jay, can shed some light. Reactor uses quake function calls to invoke operations like build, clean, ship, etc. I have determined that the change directory (cd) call is not working properly. Here is an example quake function used by Reactor to build a package: proc build_package (pkg, options) is exec ("cd", pkg, "| cm3", options)end If I had a package "Hello" located in C:\MyPkgs\Hello, here is what the exec call looks like: exec ("cd C:\MyPkgs\Hello | cm3") What is happening is that the "cd" is ignored and "cm3" is being called in the current directory (whichever that happens to be). Thus, the cm3.exe can't find the sources for the package. I've gone back to the old v5.2.6, and this wrong behavior does not occur. Instead, everything works as it should. So something has changed since that point in time that is causing a problem. Any ideas? Regards, Randy _________________________________________________________________ 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 rcoleburn at scires.com Wed Jan 23 11:29:31 2008 From: rcoleburn at scires.com (Randy Coleburn) Date: Wed, 23 Jan 2008 05:29:31 -0500 Subject: [M3devel] new problem on NT386 In-Reply-To: <4796B970.1E75.00D7.1@scires.com> References: <4796B970.1E75.00D7.1@scires.com> Message-ID: <4796D0BA.1E75.00D7.1@scires.com> OK, scratch what I said in my prior message about the "cd" not working. I ran some more tests and I'm not sure anymore. Jay, what has changed in the way quake, cm3, and cm3.cfg interact since v5.2.6? What I am seeing is that when Reactor is built using the current cm3, the output that should be going to the web browser is instead going to the console log. This is strange. The same exact code compiled under 5.2.6 works correctly (output goes to browser). Also, there are some strange differences in the output and the results are different. Not only are the results different, they are wrong under the new system, while they are correct under 5.2.6. Indeed, the build operation on the new system does not even find the correct package. Reactor is written in Modula-3, but it does use some quake helper functions. Here are the quake sources that Reactor is using for the clean and build procedures: proc clean_package (pkg) is exec ("cd", pkg, "| cm3 -verbose -clean") end proc build_package (pkg, options) is exec ("cd", pkg, "| cm3 -verbose", options) end As you can see, I've turned on the -verbose cm3 option to make the differences clear. Now, what I present next is the verbose output of 4 different operations, in the following order: 1. clean_package on 5.2.6 2. build_package on 5.2.6 3. clean_package on current cm3 4. build_package on current cm3 #1 and #2 work fine, while #3 and #4 do not. The source code for the Reactor package is the exact same in all 4 runs, the difference is that in 1 & 2 the source is built on v5.2.6, while in #3 & #4 it is built on the current cm3 checked out from the repository a few days ago. ==================================================================================== #1: Here is the result of running a clean operation followed by a build operation on the 5.2.6 cm3 system. (This version is correct!) cd C:\DOCUME~1\rcolebur\MYDOCU~1\CM3_ID~1\hello | cm3 -verbose -clean EVAL ("m3make.args") rm .M3SHIP rm .M3OVERRIDES rm Hello.mc rm Hello.ms rm Hello.mo rm Hello_m.o rm .M3EXPORTS rm hello.exe rm hello.mx rm .M3WEB rm hello.map rm hello.lst rm _m3main.c rm _m3main.o rm _m3main.obj rm .M3WEB seconds #times operation 0.02 16 removing temporary files 0.03 other --------------------------------------------------- 0.05 TOTAL rm m3make.args cd .. ================================================================================= #2: Now, the build operation on 5.2.6 (again, this is correct): cd C:\DOCUME~1\rcolebur\MYDOCU~1\CM3_ID~1\hello | cm3 -verbose EVAL ("m3make.args") rm .M3SHIP rm .M3OVERRIDES inhale hello.mx inhale c:\cm3\pkg\m3core\NT386\m3core.lib reading "c:\cm3\pkg\m3core\NT386\m3core.m3x": 0 seconds no source to match imported link unit M3_BUILTIN.i3 inhale c:\cm3\pkg\libm3\NT386\m3.lib reading "c:\cm3\pkg\libm3\NT386\m3.m3x": 0 seconds checking Hello.m3 checking IO.i3 in library c:\cm3\pkg\libm3\NT386\m3.lib checking Wr.i3 in library c:\cm3\pkg\libm3\NT386\m3.lib checking Thread.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking RTHooks.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking TextCat.m3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking TextLiteral.m3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking RTThread.m3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking RTType.m3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking RTDebug.m3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking RTAllocator.m3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking RTHooks.m3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking ThreadWin32.m3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking OSConfig.i3 in library c:\cm3\pkg\libm3\NT386\m3.lib checking OSConfigWin32.m3 in library c:\cm3\pkg\libm3\NT386\m3.lib checking AtomList.i3 in library c:\cm3\pkg\libm3\NT386\m3.lib checking Atom.i3 in library c:\cm3\pkg\libm3\NT386\m3.lib checking Atom.m3 in library c:\cm3\pkg\libm3\NT386\m3.lib checking AtomList.m3 in library c:\cm3\pkg\libm3\NT386\m3.lib checking Wr.m3 in library c:\cm3\pkg\libm3\NT386\m3.lib checking Rd.i3 in library c:\cm3\pkg\libm3\NT386\m3.lib checking Rd.m3 in library c:\cm3\pkg\libm3\NT386\m3.lib checking IO.m3 in library c:\cm3\pkg\libm3\NT386\m3.lib checking Main.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking FloatMode.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking FloatMode.m3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking Lex.i3 in library c:\cm3\pkg\libm3\NT386\m3.lib checking Word.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking Word.m3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking Lex.m3 in library c:\cm3\pkg\libm3\NT386\m3.lib checking OSError.i3 in library c:\cm3\pkg\libm3\NT386\m3.lib checking OSErrorWin32.m3 in library c:\cm3\pkg\libm3\NT386\m3.lib checking Fmt.i3 in library c:\cm3\pkg\libm3\NT386\m3.lib checking Extended.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking Extended.m3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking LongReal.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking LongReal.m3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking Real.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking Real.m3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking Fmt.m3 in library c:\cm3\pkg\libm3\NT386\m3.lib checking FileWr.i3 in library c:\cm3\pkg\libm3\NT386\m3.lib checking Pathname.i3 in library c:\cm3\pkg\libm3\NT386\m3.lib checking TextSeq.i3 in library c:\cm3\pkg\libm3\NT386\m3.lib checking Text.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking TextClass.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking M3_BUILTIN.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking TextClass.m3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking TextSub.m3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking Text.m3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking TextSeq.m3 in library c:\cm3\pkg\libm3\NT386\m3.lib checking PathnameWin32.m3 in library c:\cm3\pkg\libm3\NT386\m3.lib checking File.i3 in library c:\cm3\pkg\libm3\NT386\m3.lib checking Time.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking TimeWin32.m3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking FileWr.m3 in library c:\cm3\pkg\libm3\NT386\m3.lib checking FileRd.i3 in library c:\cm3\pkg\libm3\NT386\m3.lib checking FileRd.m3 in library c:\cm3\pkg\libm3\NT386\m3.lib checking Stdio.i3 in library c:\cm3\pkg\libm3\NT386\m3.lib checking Stdio.m3 in library c:\cm3\pkg\libm3\NT386\m3.lib checking WrClass.i3 in library c:\cm3\pkg\libm3\NT386\m3.lib checking Process.i3 in library c:\cm3\pkg\libm3\NT386\m3.lib checking ProcessWin32.m3 in library c:\cm3\pkg\libm3\NT386\m3.lib checking WinBase.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking Ctypes.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking BasicCtypes.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking WinDef.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking WinBaseTypes.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking WinDef.m3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking WinNT.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking WinNT.m3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking RTProcess.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking RTProcess.m3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking OSErrorWin32.i3 in library c:\cm3\pkg\libm3\NT386\m3.lib checking M3toC.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking M3toC.m3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking LazyConsole.i3 in library c:\cm3\pkg\libm3\NT386\m3.lib checking FileWin32.i3 in library c:\cm3\pkg\libm3\NT386\m3.lib checking Pipe.i3 in library c:\cm3\pkg\libm3\NT386\m3.lib checking PipeWin32.m3 in library c:\cm3\pkg\libm3\NT386\m3.lib checking Pipe.m3 in library c:\cm3\pkg\libm3\NT386\m3.lib checking FileWin32.m3 in library c:\cm3\pkg\libm3\NT386\m3.lib checking LazyConsole.m3 in library c:\cm3\pkg\libm3\NT386\m3.lib checking WinCon.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking Terminal.i3 in library c:\cm3\pkg\libm3\NT386\m3.lib checking Terminal.m3 in library c:\cm3\pkg\libm3\NT386\m3.lib checking TimeWin32.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking WinError.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking RegularFile.i3 in library c:\cm3\pkg\libm3\NT386\m3.lib checking RegularFile.m3 in library c:\cm3\pkg\libm3\NT386\m3.lib checking Text8CString.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking Text8CString.m3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking Text8.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking Text8.m3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking Cstring.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking Cstdlib.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking Cstddef.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking Text8Short.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking Text8Short.m3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking RTOS.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking RTOS.m3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking RTIO.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking RTIO.m3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking RTException.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking RT0.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking RT0.m3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking RTExFrame.m3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking RTException.m3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking RTHeapRep.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking RTHeapDep.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking RTMachine.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking Csetjmp.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking RTHeapDep.m3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking RTCollector.m3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking RTHeapRep.m3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking RTType.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking TextLiteral.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking RuntimeError.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking RuntimeError.m3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking ThreadF.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking RTPerfTool.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking RTPerfTool.m3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking RTParams.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking RTParams.m3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking RTMisc.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking RTMisc.m3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking RTVM.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking RTHeapMap.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking RTHeapMap.m3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking RTHeapEvent.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking RTWeakRef.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking RTCollectorSRC.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking RTCollector.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking RTMapOp.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking RTTypeMap.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking RTTypeMap.m3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking RTMapOp.m3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking RTModule.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking RTLinker.m3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking RTLinkerX.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking RTHeapInfo.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking RTHeapInfo.m3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking RTThreadInit.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking RTSignal.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking RTSignal.m3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking RTTypeSRC.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking RTLinker.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking ThreadContext.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking RTError.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking RTError.m3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking RTMachInfo.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking RTMachInfo.m3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking RTProcedureSRC.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking RTProcedure.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking Fingerprint.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking Fingerprint.m3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking RTProcedure.m3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking Poly.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking Poly.m3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking PolyBasis.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking PolyBasis.m3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking RTAllocCnts.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking RTArgs.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking RTArgs.m3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking Compiler.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking Compiler.m3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking RTThread.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking RTExFrame.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking RdClass.i3 in library c:\cm3\pkg\libm3\NT386\m3.lib checking FS.i3 in library c:\cm3\pkg\libm3\NT386\m3.lib checking FSWin32.m3 in library c:\cm3\pkg\libm3\NT386\m3.lib checking FS.m3 in library c:\cm3\pkg\libm3\NT386\m3.lib checking OSWin32.i3 in library c:\cm3\pkg\libm3\NT386\m3.lib checking OSWin32.m3 in library c:\cm3\pkg\libm3\NT386\m3.lib checking TextSeqRep.i3 in library c:\cm3\pkg\libm3\NT386\m3.lib checking String16.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking String16.m3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking String8.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking String8.m3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking Text16.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking Text16.m3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking Text16Short.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking Text16Short.m3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking TextCat.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking TextSub.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking ExtendedFloat.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking ExtendedFloat.m3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking LongFloat.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking LongFloat.m3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking RealFloat.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking RealFloat.m3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking FmtBufF.i3 in library c:\cm3\pkg\libm3\NT386\m3.lib checking FmtBuf.i3 in library c:\cm3\pkg\libm3\NT386\m3.lib checking FmtBuf.m3 in library c:\cm3\pkg\libm3\NT386\m3.lib checking Convert.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking Convert.m3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking CConvert.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking CConvert.m3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking FmtBufTest.i3 in library c:\cm3\pkg\libm3\NT386\m3.lib checking FPU.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking FPU.m3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking DragonT.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking DragonT.m3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking RealRep.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking DragonInt.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking DragonInt.m3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking LongRealRep.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking IEEESpecial.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking IEEESpecial.m3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking UnsafeRd.i3 in library c:\cm3\pkg\libm3\NT386\m3.lib checking UnsafeWr.i3 in library c:\cm3\pkg\libm3\NT386\m3.lib checking AtomAtomTbl.i3 in library c:\cm3\pkg\libm3\NT386\m3.lib checking AtomAtomTbl.m3 in library c:\cm3\pkg\libm3\NT386\m3.lib checking WinSock.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking WinSock.m3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking Env.i3 in library c:\cm3\pkg\libm3\NT386\m3.lib checking Env.m3 in library c:\cm3\pkg\libm3\NT386\m3.lib checking MutexRep.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking WinGDI.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking WinGDI.m3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking Scheduler.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking RTHeap.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking RTHeap.m3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking RTAllocator.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking RTDebug.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib Compiling Hello.m3 (new source) m3front ..\src\Hello.m3 -unfold_nested_procs -check_procs -w1 exhale hello.mx linking hello.exe generate _m3main.obj C:\PROGRA~1\MID05A~1\VC\bin\LINK @C:\DOCUME~1\rcolebur\LOCALS~1\Temp\qk > hello.lst m3_link => 0 seconds #times operation 0.02 3 inhaling library link info 0.03 224 merging new link info 0.02 1 generating _m3main.c 0.11 1 linking 0.02 3 garbage collection --------------------------------------------------- 0.19 TOTAL rm m3make.args cd .. ================================================================================= #3: Here is the clean operation on the current cm3 system (this is different, and wrong): calling clean_package("C:\DOCUME~1\cm3\MYDOCU~1\CM3_ID~1\hello") EVAL ("cm3.cfg") mkdir NT386 --- cleaning NT386 --- cd NT386 Looking in .. ignoring ..\anim3D.dll (not a directory) ignoring ..\anim3D.pdb (not a directory) ignoring ..\binIO.dll (not a directory) ignoring ..\binIO.pdb (not a directory) ignoring ..\BitVector.dll (not a directory) ignoring ..\BitVector.pdb (not a directory) ignoring ..\Calculator.exe (not a directory) ignoring ..\Calculator.pdb (not a directory) ignoring ..\CheckForNetObjD.exe (not a directory) ignoring ..\CheckForNetObjD.pdb (not a directory) ignoring ..\cm3-d5.5.0.exe (not a directory) ignoring ..\cm3-d5.5.0.pdb (not a directory) ignoring ..\cm3-d5.5.1.exe (not a directory) ignoring ..\cm3-d5.5.1.pdb (not a directory) ignoring ..\cm3.cfg (not a directory) ignoring ..\cm3.exe (not a directory) ignoring ..\cm3.pdb (not a directory) ignoring ..\cm3ide.exe (not a directory) ignoring ..\cm3ide.pdb (not a directory) ignoring ..\cm3Proj.CMD (not a directory) ignoring ..\cm3SetupCmdEnv.CMD (not a directory) ignoring ..\cm3StartIDE.CMD (not a directory) ignoring ..\cm3v41.cfg (not a directory) ignoring ..\cmpdir.exe (not a directory) ignoring ..\cmpdir.pdb (not a directory) ignoring ..\cmpfp.pdb (not a directory) ignoring ..\cmvbt.dll (not a directory) ignoring ..\cmvbt.pdb (not a directory) ignoring ..\Cube.exe (not a directory) ignoring ..\Cube.pdb (not a directory) ignoring ..\CV_Banner.exe (not a directory) ignoring ..\CV_Banner.pdb (not a directory) ignoring ..\CV_Client.exe (not a directory) ignoring ..\CV_Client.pdb (not a directory) ignoring ..\CV_ListConfigDefns.exe (not a directory) ignoring ..\CV_ListConfigDefns.pdb (not a directory) ignoring ..\CV_MessageTool.exe (not a directory) ignoring ..\CV_MessageTool.pdb (not a directory) ignoring ..\CV_Server.exe (not a directory) ignoring ..\CV_Server.pdb (not a directory) ignoring ..\CV_Shutdown.exe (not a directory) ignoring ..\CV_Shutdown.pdb (not a directory) ignoring ..\cygwin1.dll (not a directory) ignoring ..\db.dll (not a directory) ignoring ..\db.pdb (not a directory) ignoring ..\debug.dll (not a directory) ignoring ..\debug.pdb (not a directory) ignoring ..\deepcopy.dll (not a directory) ignoring ..\deepcopy.pdb (not a directory) ignoring ..\DiGraph.dll (not a directory) ignoring ..\DiGraph.pdb (not a directory) ignoring ..\dirfp.exe (not a directory) ignoring ..\dirfp.pdb (not a directory) ignoring ..\Documentation_cm3Proj.htm (not a directory) ignoring ..\Documentation_cm3Proj.pdf (not a directory) ignoring ..\Documentation_CM3SetupCmdEnv.htm (not a directory) ignoring ..\Documentation_CM3SetupCmdEnv.pdf (not a directory) ignoring ..\Documentation_CM3StartIDE.htm (not a directory) ignoring ..\Documentation_CM3StartIDE.pdf (not a directory) ignoring ..\DummyNavServer.exe (not a directory) ignoring ..\DummyNavServer.pdb (not a directory) ignoring ..\embutils.dll (not a directory) ignoring ..\embutils.pdb (not a directory) ignoring ..\events.dll (not a directory) ignoring ..\events.pdb (not a directory) ignoring ..\fisheye.exe (not a directory) ignoring ..\fisheye.pdb (not a directory) ignoring ..\fix_nl.exe (not a directory) ignoring ..\fix_nl.pdb (not a directory) ignoring ..\foo2.pdb (not a directory) ignoring ..\formsedit.exe (not a directory) ignoring ..\formsedit.pdb (not a directory) ignoring ..\formsview.pdb (not a directory) ignoring ..\Geometry.dll (not a directory) ignoring ..\Geometry.pdb (not a directory) ignoring ..\gzip.exe (not a directory) ignoring ..\http.dll (not a directory) ignoring ..\http.pdb (not a directory) ignoring ..\juno-compiler.dll (not a directory) ignoring ..\juno-compiler.pdb (not a directory) ignoring ..\juno-machine.dll (not a directory) ignoring ..\juno-machine.pdb (not a directory) ignoring ..\Juno.exe (not a directory) ignoring ..\Juno.pdb (not a directory) ignoring ..\jvideo.dll (not a directory) ignoring ..\jvideo.pdb (not a directory) ignoring ..\libbuf.dll (not a directory) ignoring ..\libbuf.pdb (not a directory) ignoring ..\libCV.dll (not a directory) ignoring ..\libCV.pdb (not a directory) ignoring ..\libdump.pdb (not a directory) ignoring ..\libGUI.dll (not a directory) ignoring ..\libGUI.pdb (not a directory) ignoring ..\libSciRes3.dll (not a directory) ignoring ..\libSciRes3.pdb (not a directory) ignoring ..\libsio.dll (not a directory) ignoring ..\libsio.pdb (not a directory) ignoring ..\listfuncs.dll (not a directory) ignoring ..\listfuncs.pdb (not a directory) ignoring ..\m3.dll (not a directory) ignoring ..\m3.pdb (not a directory) ignoring ..\m3back.pdb (not a directory) ignoring ..\m3browser.exe (not a directory) ignoring ..\m3browser.pdb (not a directory) ignoring ..\m3bundle.exe (not a directory) ignoring ..\m3bundle.pdb (not a directory) ignoring ..\m3cgcat.pdb (not a directory) ignoring ..\m3cggen.pdb (not a directory) ignoring ..\m3codeview.dll (not a directory) ignoring ..\m3codeview.pdb (not a directory) ignoring ..\m3core.dll (not a directory) ignoring ..\m3core.pdb (not a directory) ignoring ..\m3formsvbt.dll (not a directory) ignoring ..\m3formsvbt.pdb (not a directory) ignoring ..\m3formsvbtpixmaps.dll (not a directory) ignoring ..\m3formsvbtpixmaps.pdb (not a directory) ignoring ..\m3markup.dll (not a directory) ignoring ..\m3markup.pdb (not a directory) ignoring ..\m3mg.dll (not a directory) ignoring ..\m3mg.pdb (not a directory) ignoring ..\m3mgkit.dll (not a directory) ignoring ..\m3mgkit.pdb (not a directory) ignoring ..\m3netobj.dll (not a directory) ignoring ..\m3netobj.pdb (not a directory) ignoring ..\m3parseparams.dll (not a directory) ignoring ..\m3parseparams.pdb (not a directory) ignoring ..\m3scan.dll (not a directory) ignoring ..\m3scan.pdb (not a directory) ignoring ..\m3slisp.dll (not a directory) ignoring ..\m3slisp.pdb (not a directory) ignoring ..\m3smalldb.dll (not a directory) ignoring ..\m3smalldb.pdb (not a directory) ignoring ..\m3tcl.dll (not a directory) ignoring ..\m3tcl.pdb (not a directory) ignoring ..\m3tcp.dll (not a directory) ignoring ..\m3tcp.pdb (not a directory) ignoring ..\m3tk-misc.dll (not a directory) ignoring ..\m3tk-misc.pdb (not a directory) ignoring ..\m3tk.dll (not a directory) ignoring ..\m3tk.pdb (not a directory) ignoring ..\m3tohtml.exe (not a directory) ignoring ..\m3tohtml.pdb (not a directory) ignoring ..\m3totex.exe (not a directory) ignoring ..\m3totex.pdb (not a directory) ignoring ..\m3ui.dll (not a directory) ignoring ..\m3ui.pdb (not a directory) ignoring ..\m3vbtkit.dll (not a directory) ignoring ..\m3vbtkit.pdb (not a directory) ignoring ..\m3zeus.dll (not a directory) ignoring ..\m3zeus.pdb (not a directory) ignoring ..\m3zume.exe (not a directory) ignoring ..\m3zume.pdb (not a directory) ignoring ..\MakeShortPath.cmd (not a directory) ignoring ..\mentor.exe (not a directory) ignoring ..\mentor.pdb (not a directory) ignoring ..\metasyn.dll (not a directory) ignoring ..\metasyn.pdb (not a directory) ignoring ..\mklib.exe (not a directory) ignoring ..\mklib.pdb (not a directory) ignoring ..\netobjd.exe (not a directory) ignoring ..\netobjd.pdb (not a directory) ignoring ..\NT386 (derived object directory) ignoring ..\obliq (not a directory) ignoring ..\obliq-anim.exe (not a directory) ignoring ..\obliq-anim.pdb (not a directory) ignoring ..\obliq-min.exe (not a directory) ignoring ..\obliq-min.pdb (not a directory) ignoring ..\obliq-std.exe (not a directory) ignoring ..\obliq-std.pdb (not a directory) ignoring ..\obliq-ui.exe (not a directory) ignoring ..\obliq-ui.pdb (not a directory) ignoring ..\obliq.dll (not a directory) ignoring ..\obliq.pdb (not a directory) ignoring ..\obliqlibanim.dll (not a directory) ignoring ..\obliqlibanim.pdb (not a directory) ignoring ..\obliqlibemb.dll (not a directory) ignoring ..\obliqlibemb.pdb (not a directory) ignoring ..\obliqlibm3.dll (not a directory) ignoring ..\obliqlibm3.pdb (not a directory) ignoring ..\obliqlibui.dll (not a directory) ignoring ..\obliqlibui.pdb (not a directory) ignoring ..\obliqparse.dll (not a directory) ignoring ..\obliqparse.pdb (not a directory) ignoring ..\obliqprint.dll (not a directory) ignoring ..\obliqprint.pdb (not a directory) ignoring ..\obliqrt.dll (not a directory) ignoring ..\obliqrt.pdb (not a directory) ignoring ..\obliqsrv (not a directory) ignoring ..\obliqsrv-std.exe (not a directory) ignoring ..\obliqsrv-std.pdb (not a directory) ignoring ..\obliqsrv-ui.exe (not a directory) ignoring ..\obliqsrv-ui.pdb (not a directory) ignoring ..\odbc.dll (not a directory) ignoring ..\odbc.pdb (not a directory) ignoring ..\opengl.dll (not a directory) ignoring ..\opengl.pdb (not a directory) ignoring ..\patternmatching.dll (not a directory) ignoring ..\patternmatching.pdb (not a directory) ignoring ..\PklFonts.pdb (not a directory) ignoring ..\rdwr.dll (not a directory) ignoring ..\rdwr.pdb (not a directory) ignoring ..\recordheap (not a directory) ignoring ..\RehearseCode.exe (not a directory) ignoring ..\RehearseCode.pdb (not a directory) ignoring ..\replayheap.exe (not a directory) ignoring ..\replayheap.pdb (not a directory) ignoring ..\serial2.dll (not a directory) ignoring ..\serial2.pdb (not a directory) ignoring ..\serialio.dll (not a directory) ignoring ..\serialio.pdb (not a directory) ignoring ..\set.dll (not a directory) ignoring ..\set.pdb (not a directory) ignoring ..\sgml.dll (not a directory) ignoring ..\sgml.pdb (not a directory) ignoring ..\sharedobj.dll (not a directory) ignoring ..\sharedobj.pdb (not a directory) ignoring ..\shobjcodegen.exe (not a directory) ignoring ..\shobjcodegen.pdb (not a directory) ignoring ..\showheap.exe (not a directory) ignoring ..\showheap.pdb (not a directory) ignoring ..\shownew.exe (not a directory) ignoring ..\shownew.pdb (not a directory) ignoring ..\showthread.exe (not a directory) ignoring ..\showthread.pdb (not a directory) ignoring ..\SortedTableExtras.dll (not a directory) ignoring ..\SortedTableExtras.pdb (not a directory) ignoring ..\stable.dll (not a directory) ignoring ..\stable.pdb (not a directory) ignoring ..\stablegen.exe (not a directory) ignoring ..\stablegen.pdb (not a directory) ignoring ..\stubgen.exe (not a directory) ignoring ..\stubgen.pdb (not a directory) ignoring ..\synex.dll (not a directory) ignoring ..\synex.pdb (not a directory) ignoring ..\synwr.dll (not a directory) ignoring ..\synwr.pdb (not a directory) ignoring ..\table-list.dll (not a directory) ignoring ..\table-list.pdb (not a directory) ignoring ..\tar.exe (not a directory) ignoring ..\TempFiles.dll (not a directory) ignoring ..\TempFiles.pdb (not a directory) ignoring ..\TestPixmap.pdb (not a directory) ignoring ..\UDP.dll (not a directory) ignoring ..\UDP.pdb (not a directory) ignoring ..\uniq.pdb (not a directory) ignoring ..\videovbt.dll (not a directory) ignoring ..\videovbt.pdb (not a directory) ignoring ..\visobliq.exe (not a directory) ignoring ..\visobliq.pdb (not a directory) ignoring ..\vocgi.exe (not a directory) ignoring ..\vocgi.pdb (not a directory) ignoring ..\voquery.exe (not a directory) ignoring ..\voquery.pdb (not a directory) ignoring ..\vorun.exe (not a directory) ignoring ..\vorun.pdb (not a directory) ignoring ..\vostart (not a directory) ignoring ..\vostart.cmd (not a directory) ignoring ..\web.dll (not a directory) ignoring ..\web.pdb (not a directory) ignoring ..\webvbt.dll (not a directory) ignoring ..\webvbt.pdb (not a directory) ignoring ..\windowsResources.dll (not a directory) ignoring ..\windowsResources.pdb (not a directory) ignoring ..\zapNT386.cmd (not a directory) EVAL ("m3make.args") rm .M3SHIP rm .M3OVERRIDES rm .M3EXPORTS rm prog.exe rm prog.mx rm .M3WEB rm prog.map rm prog.lst rm _m3main.c rm _m3main.o rm _m3main.obj rm .M3WEB seconds #times operation 0.01 3 garbage collection 0.04 other --------------------------------------------------- 0.05 TOTAL rm m3make.args cd .. is_empty (NT386) => rmdir NT386 ================================================================================= #4: Here is the build operation on the current cm3 (this is different from v5.2.6 and wrong--it does not find the package to build!): calling build_package("C:\DOCUME~1\cm3\MYDOCU~1\CM3_ID~1\hello", "") EVAL ("cm3.cfg") mkdir NT386 --- building in NT386 --- cd NT386 Looking in .. ignoring ..\anim3D.dll (not a directory) ignoring ..\anim3D.pdb (not a directory) ignoring ..\binIO.dll (not a directory) ignoring ..\binIO.pdb (not a directory) ignoring ..\BitVector.dll (not a directory) ignoring ..\BitVector.pdb (not a directory) ignoring ..\Calculator.exe (not a directory) ignoring ..\Calculator.pdb (not a directory) ignoring ..\CheckForNetObjD.exe (not a directory) ignoring ..\CheckForNetObjD.pdb (not a directory) ignoring ..\cm3-d5.5.0.exe (not a directory) ignoring ..\cm3-d5.5.0.pdb (not a directory) ignoring ..\cm3-d5.5.1.exe (not a directory) ignoring ..\cm3-d5.5.1.pdb (not a directory) ignoring ..\cm3.cfg (not a directory) ignoring ..\cm3.exe (not a directory) ignoring ..\cm3.pdb (not a directory) ignoring ..\cm3ide.exe (not a directory) ignoring ..\cm3ide.pdb (not a directory) ignoring ..\cm3Proj.CMD (not a directory) ignoring ..\cm3SetupCmdEnv.CMD (not a directory) ignoring ..\cm3StartIDE.CMD (not a directory) ignoring ..\cm3v41.cfg (not a directory) ignoring ..\cmpdir.exe (not a directory) ignoring ..\cmpdir.pdb (not a directory) ignoring ..\cmpfp.pdb (not a directory) ignoring ..\cmvbt.dll (not a directory) ignoring ..\cmvbt.pdb (not a directory) ignoring ..\Cube.exe (not a directory) ignoring ..\Cube.pdb (not a directory) ignoring ..\CV_Banner.exe (not a directory) ignoring ..\CV_Banner.pdb (not a directory) ignoring ..\CV_Client.exe (not a directory) ignoring ..\CV_Client.pdb (not a directory) ignoring ..\CV_ListConfigDefns.exe (not a directory) ignoring ..\CV_ListConfigDefns.pdb (not a directory) ignoring ..\CV_MessageTool.exe (not a directory) ignoring ..\CV_MessageTool.pdb (not a directory) ignoring ..\CV_Server.exe (not a directory) ignoring ..\CV_Server.pdb (not a directory) ignoring ..\CV_Shutdown.exe (not a directory) ignoring ..\CV_Shutdown.pdb (not a directory) ignoring ..\cygwin1.dll (not a directory) ignoring ..\db.dll (not a directory) ignoring ..\db.pdb (not a directory) ignoring ..\debug.dll (not a directory) ignoring ..\debug.pdb (not a directory) ignoring ..\deepcopy.dll (not a directory) ignoring ..\deepcopy.pdb (not a directory) ignoring ..\DiGraph.dll (not a directory) ignoring ..\DiGraph.pdb (not a directory) ignoring ..\dirfp.exe (not a directory) ignoring ..\dirfp.pdb (not a directory) ignoring ..\Documentation_cm3Proj.htm (not a directory) ignoring ..\Documentation_cm3Proj.pdf (not a directory) ignoring ..\Documentation_CM3SetupCmdEnv.htm (not a directory) ignoring ..\Documentation_CM3SetupCmdEnv.pdf (not a directory) ignoring ..\Documentation_CM3StartIDE.htm (not a directory) ignoring ..\Documentation_CM3StartIDE.pdf (not a directory) ignoring ..\DummyNavServer.exe (not a directory) ignoring ..\DummyNavServer.pdb (not a directory) ignoring ..\embutils.dll (not a directory) ignoring ..\embutils.pdb (not a directory) ignoring ..\events.dll (not a directory) ignoring ..\events.pdb (not a directory) ignoring ..\fisheye.exe (not a directory) ignoring ..\fisheye.pdb (not a directory) ignoring ..\fix_nl.exe (not a directory) ignoring ..\fix_nl.pdb (not a directory) ignoring ..\foo2.pdb (not a directory) ignoring ..\formsedit.exe (not a directory) ignoring ..\formsedit.pdb (not a directory) ignoring ..\formsview.pdb (not a directory) ignoring ..\Geometry.dll (not a directory) ignoring ..\Geometry.pdb (not a directory) ignoring ..\gzip.exe (not a directory) ignoring ..\http.dll (not a directory) ignoring ..\http.pdb (not a directory) ignoring ..\juno-compiler.dll (not a directory) ignoring ..\juno-compiler.pdb (not a directory) ignoring ..\juno-machine.dll (not a directory) ignoring ..\juno-machine.pdb (not a directory) ignoring ..\Juno.exe (not a directory) ignoring ..\Juno.pdb (not a directory) ignoring ..\jvideo.dll (not a directory) ignoring ..\jvideo.pdb (not a directory) ignoring ..\libbuf.dll (not a directory) ignoring ..\libbuf.pdb (not a directory) ignoring ..\libCV.dll (not a directory) ignoring ..\libCV.pdb (not a directory) ignoring ..\libdump.pdb (not a directory) ignoring ..\libGUI.dll (not a directory) ignoring ..\libGUI.pdb (not a directory) ignoring ..\libSciRes3.dll (not a directory) ignoring ..\libSciRes3.pdb (not a directory) ignoring ..\libsio.dll (not a directory) ignoring ..\libsio.pdb (not a directory) ignoring ..\listfuncs.dll (not a directory) ignoring ..\listfuncs.pdb (not a directory) ignoring ..\m3.dll (not a directory) ignoring ..\m3.pdb (not a directory) ignoring ..\m3back.pdb (not a directory) ignoring ..\m3browser.exe (not a directory) ignoring ..\m3browser.pdb (not a directory) ignoring ..\m3bundle.exe (not a directory) ignoring ..\m3bundle.pdb (not a directory) ignoring ..\m3cgcat.pdb (not a directory) ignoring ..\m3cggen.pdb (not a directory) ignoring ..\m3codeview.dll (not a directory) ignoring ..\m3codeview.pdb (not a directory) ignoring ..\m3core.dll (not a directory) ignoring ..\m3core.pdb (not a directory) ignoring ..\m3formsvbt.dll (not a directory) ignoring ..\m3formsvbt.pdb (not a directory) ignoring ..\m3formsvbtpixmaps.dll (not a directory) ignoring ..\m3formsvbtpixmaps.pdb (not a directory) ignoring ..\m3markup.dll (not a directory) ignoring ..\m3markup.pdb (not a directory) ignoring ..\m3mg.dll (not a directory) ignoring ..\m3mg.pdb (not a directory) ignoring ..\m3mgkit.dll (not a directory) ignoring ..\m3mgkit.pdb (not a directory) ignoring ..\m3netobj.dll (not a directory) ignoring ..\m3netobj.pdb (not a directory) ignoring ..\m3parseparams.dll (not a directory) ignoring ..\m3parseparams.pdb (not a directory) ignoring ..\m3scan.dll (not a directory) ignoring ..\m3scan.pdb (not a directory) ignoring ..\m3slisp.dll (not a directory) ignoring ..\m3slisp.pdb (not a directory) ignoring ..\m3smalldb.dll (not a directory) ignoring ..\m3smalldb.pdb (not a directory) ignoring ..\m3tcl.dll (not a directory) ignoring ..\m3tcl.pdb (not a directory) ignoring ..\m3tcp.dll (not a directory) ignoring ..\m3tcp.pdb (not a directory) ignoring ..\m3tk-misc.dll (not a directory) ignoring ..\m3tk-misc.pdb (not a directory) ignoring ..\m3tk.dll (not a directory) ignoring ..\m3tk.pdb (not a directory) ignoring ..\m3tohtml.exe (not a directory) ignoring ..\m3tohtml.pdb (not a directory) ignoring ..\m3totex.exe (not a directory) ignoring ..\m3totex.pdb (not a directory) ignoring ..\m3ui.dll (not a directory) ignoring ..\m3ui.pdb (not a directory) ignoring ..\m3vbtkit.dll (not a directory) ignoring ..\m3vbtkit.pdb (not a directory) ignoring ..\m3zeus.dll (not a directory) ignoring ..\m3zeus.pdb (not a directory) ignoring ..\m3zume.exe (not a directory) ignoring ..\m3zume.pdb (not a directory) ignoring ..\MakeShortPath.cmd (not a directory) ignoring ..\mentor.exe (not a directory) ignoring ..\mentor.pdb (not a directory) ignoring ..\metasyn.dll (not a directory) ignoring ..\metasyn.pdb (not a directory) ignoring ..\mklib.exe (not a directory) ignoring ..\mklib.pdb (not a directory) ignoring ..\netobjd.exe (not a directory) ignoring ..\netobjd.pdb (not a directory) ignoring ..\NT386 (derived object directory) ignoring ..\obliq (not a directory) ignoring ..\obliq-anim.exe (not a directory) ignoring ..\obliq-anim.pdb (not a directory) ignoring ..\obliq-min.exe (not a directory) ignoring ..\obliq-min.pdb (not a directory) ignoring ..\obliq-std.exe (not a directory) ignoring ..\obliq-std.pdb (not a directory) ignoring ..\obliq-ui.exe (not a directory) ignoring ..\obliq-ui.pdb (not a directory) ignoring ..\obliq.dll (not a directory) ignoring ..\obliq.pdb (not a directory) ignoring ..\obliqlibanim.dll (not a directory) ignoring ..\obliqlibanim.pdb (not a directory) ignoring ..\obliqlibemb.dll (not a directory) ignoring ..\obliqlibemb.pdb (not a directory) ignoring ..\obliqlibm3.dll (not a directory) ignoring ..\obliqlibm3.pdb (not a directory) ignoring ..\obliqlibui.dll (not a directory) ignoring ..\obliqlibui.pdb (not a directory) ignoring ..\obliqparse.dll (not a directory) ignoring ..\obliqparse.pdb (not a directory) ignoring ..\obliqprint.dll (not a directory) ignoring ..\obliqprint.pdb (not a directory) ignoring ..\obliqrt.dll (not a directory) ignoring ..\obliqrt.pdb (not a directory) ignoring ..\obliqsrv (not a directory) ignoring ..\obliqsrv-std.exe (not a directory) ignoring ..\obliqsrv-std.pdb (not a directory) ignoring ..\obliqsrv-ui.exe (not a directory) ignoring ..\obliqsrv-ui.pdb (not a directory) ignoring ..\odbc.dll (not a directory) ignoring ..\odbc.pdb (not a directory) ignoring ..\opengl.dll (not a directory) ignoring ..\opengl.pdb (not a directory) ignoring ..\patternmatching.dll (not a directory) ignoring ..\patternmatching.pdb (not a directory) ignoring ..\PklFonts.pdb (not a directory) ignoring ..\rdwr.dll (not a directory) ignoring ..\rdwr.pdb (not a directory) ignoring ..\recordheap (not a directory) ignoring ..\RehearseCode.exe (not a directory) ignoring ..\RehearseCode.pdb (not a directory) ignoring ..\replayheap.exe (not a directory) ignoring ..\replayheap.pdb (not a directory) ignoring ..\serial2.dll (not a directory) ignoring ..\serial2.pdb (not a directory) ignoring ..\serialio.dll (not a directory) ignoring ..\serialio.pdb (not a directory) ignoring ..\set.dll (not a directory) ignoring ..\set.pdb (not a directory) ignoring ..\sgml.dll (not a directory) ignoring ..\sgml.pdb (not a directory) ignoring ..\sharedobj.dll (not a directory) ignoring ..\sharedobj.pdb (not a directory) ignoring ..\shobjcodegen.exe (not a directory) ignoring ..\shobjcodegen.pdb (not a directory) ignoring ..\showheap.exe (not a directory) ignoring ..\showheap.pdb (not a directory) ignoring ..\shownew.exe (not a directory) ignoring ..\shownew.pdb (not a directory) ignoring ..\showthread.exe (not a directory) ignoring ..\showthread.pdb (not a directory) ignoring ..\SortedTableExtras.dll (not a directory) ignoring ..\SortedTableExtras.pdb (not a directory) ignoring ..\stable.dll (not a directory) ignoring ..\stable.pdb (not a directory) ignoring ..\stablegen.exe (not a directory) ignoring ..\stablegen.pdb (not a directory) ignoring ..\stubgen.exe (not a directory) ignoring ..\stubgen.pdb (not a directory) ignoring ..\synex.dll (not a directory) ignoring ..\synex.pdb (not a directory) ignoring ..\synwr.dll (not a directory) ignoring ..\synwr.pdb (not a directory) ignoring ..\table-list.dll (not a directory) ignoring ..\table-list.pdb (not a directory) ignoring ..\tar.exe (not a directory) ignoring ..\TempFiles.dll (not a directory) ignoring ..\TempFiles.pdb (not a directory) ignoring ..\TestPixmap.pdb (not a directory) ignoring ..\UDP.dll (not a directory) ignoring ..\UDP.pdb (not a directory) ignoring ..\uniq.pdb (not a directory) ignoring ..\videovbt.dll (not a directory) ignoring ..\videovbt.pdb (not a directory) ignoring ..\visobliq.exe (not a directory) ignoring ..\visobliq.pdb (not a directory) ignoring ..\vocgi.exe (not a directory) ignoring ..\vocgi.pdb (not a directory) ignoring ..\voquery.exe (not a directory) ignoring ..\voquery.pdb (not a directory) ignoring ..\vorun.exe (not a directory) ignoring ..\vorun.pdb (not a directory) ignoring ..\vostart (not a directory) ignoring ..\vostart.cmd (not a directory) ignoring ..\web.dll (not a directory) ignoring ..\web.pdb (not a directory) ignoring ..\webvbt.dll (not a directory) ignoring ..\webvbt.pdb (not a directory) ignoring ..\windowsResources.dll (not a directory) ignoring ..\windowsResources.pdb (not a directory) ignoring ..\zapNT386.cmd (not a directory) cm3: found nothing to build. rm m3make.args seconds #times operation 0.02 2 garbage collection 0.02 other --------------------------------------------------- 0.04 TOTAL cd .. is_empty (NT386) => rmdir NT386 Regards, Randy -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Wed Jan 23 12:20:02 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 23 Jan 2008 12:20:02 +0100 Subject: [M3devel] platform/build_dir is a big tuple? In-Reply-To: References: <479605CF.1E75.00D7.1@scires.com> Message-ID: <20080123122002.6rcdyji1us4okkww@mail.elegosoft.com> Quoting Henning Thielemann : > > On Tue, 22 Jan 2008, Randy Coleburn wrote: > >> Jay: >> >> For my part on Windows, I am happy to stay with the underlying OS, the >> native windows threading, the integrated backend, and use the free >> Microsoft Visual Studio tools. I don't really want to have to >> install/use cygwin or any of the other variants. When I see target = >> NT386, this list is what I am expecting. For the cm3 newbie coming from >> a Microsoft Windows environment, I think this list would be the most >> appealing and pose the least barrier to getting starting. Yes, I still >> will work on the installer program once I'm satisfied that I have a good >> working cm3 on Windows. > > One year ago I was in the situation to port one of my Modula-3 programs > from Linux to Windows in order to hand it over to a Windows user. As I > never use Windows, I have only a plain Windows installation on my machine > with almost no tools other than cm3. I was glad to be able to run cm3 > immediately and to find all libraries that I needed in binary form without > Cygwin dependencies - otherwise not only I had to install that on my > machine but I also would have to persuade the other Windows guy to install > it as well. Summarized I strongly vote for NT386 being Windows with least > dependencies on other packages. There has never been a question about this. But there are other who prefer something more POSIXish like Cygwin, which is why other targets like NT386GNU (or NT386_CYGWIN or whatever) are 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 wagner at elegosoft.com Wed Jan 23 12:39:37 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 23 Jan 2008 12:39:37 +0100 Subject: [M3devel] new problem on NT386 In-Reply-To: <4796D0BA.1E75.00D7.1@scires.com> References: <4796B970.1E75.00D7.1@scires.com> <4796D0BA.1E75.00D7.1@scires.com> Message-ID: <20080123123937.onc4m6fa4gg8ogg0@mail.elegosoft.com> Quoting Randy Coleburn : > OK, scratch what I said in my prior message about the "cd" not > working. I ran some more tests and I'm not sure anymore. > > Jay, what has changed in the way quake, cm3, and cm3.cfg interact > since v5.2.6? > > What I am seeing is that when Reactor is built using the current > cm3, the output that should be going to the web browser is instead > going to the console log. This is strange. The same exact code > compiled under 5.2.6 works correctly (output goes to browser). > > Also, there are some strange differences in the output and the > results are different. Not only are the results different, they are > wrong under the new system, while they are correct under 5.2.6. > Indeed, the build operation on the new system does not even find the > correct package. > > Reactor is written in Modula-3, but it does use some quake helper > functions. Here are the quake sources that Reactor is using for the > clean and build procedures: > > proc clean_package (pkg) is > exec ("cd", pkg, "| cm3 -verbose -clean") > end > proc build_package (pkg, options) is > exec ("cd", pkg, "| cm3 -verbose", options) > end > As you can see, I've turned on the -verbose cm3 option to make the > differences clear. I don't understand these: | is the pipe symbol even for cmd.exe, isn't it? Shouldn't these commands just read `cd pkg && cm3 -verbose ...'? && should work for /bin/sh as well as for cme.exe, IIRC. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jayk123 at hotmail.com Wed Jan 23 13:37:29 2008 From: jayk123 at hotmail.com (Jay) Date: Wed, 23 Jan 2008 12:37:29 +0000 Subject: [M3devel] new problem on NT386 In-Reply-To: <20080123123937.onc4m6fa4gg8ogg0@mail.elegosoft.com> References: <4796B970.1E75.00D7.1@scires.com> <4796D0BA.1E75.00D7.1@scires.com> <20080123123937.onc4m6fa4gg8ogg0@mail.elegosoft.com> Message-ID: Oops good point Olaf. Yes && works with cmd. If the first command succeeds, the second is run. Succeeds as in exit code is 0. I assume "pkg" contained "enough content to make it work", but if indeed it is a directory, no go. I wasn't really reading the content oops sorry. But yet Randy said it worked with 5.2.6. Randy, you reminded me of a good point though. Upgrade.py plays a new game with config files, one which I like so far, but maybe isn't so great. I don't remember if I updated upgrade.cmd to this new model. In either case, to remove variables, to remove changes, look at your cm3.cfg. Read it a bit. Is it a stub that looks for another config file to include? If so, undo that on your machine. Find the other file, it is cvsroot\m3-sys\cminstall\src\config\nt386, and copy that over \cm3\bin\cm3.cfg, and try again. In either case I'm sure this is not a big deal.... Can you make the code available to me somehow? I do need to get some real work done during the week(s) but the weekend... - Jay > Date: Wed, 23 Jan 2008 12:39:37 +0100> From: wagner at elegosoft.com> To: m3devel at elegosoft.com> Subject: Re: [M3devel] new problem on NT386> > Quoting Randy Coleburn :> > > OK, scratch what I said in my prior message about the "cd" not > > working. I ran some more tests and I'm not sure anymore.> >> > Jay, what has changed in the way quake, cm3, and cm3.cfg interact > > since v5.2.6?> >> > What I am seeing is that when Reactor is built using the current > > cm3, the output that should be going to the web browser is instead > > going to the console log. This is strange. The same exact code > > compiled under 5.2.6 works correctly (output goes to browser).> >> > Also, there are some strange differences in the output and the > > results are different. Not only are the results different, they are > > wrong under the new system, while they are correct under 5.2.6. > > Indeed, the build operation on the new system does not even find the > > correct package.> >> > Reactor is written in Modula-3, but it does use some quake helper > > functions. Here are the quake sources that Reactor is using for the > > clean and build procedures:> >> > proc clean_package (pkg) is> > exec ("cd", pkg, "| cm3 -verbose -clean")> > end> > proc build_package (pkg, options) is> > exec ("cd", pkg, "| cm3 -verbose", options)> > end> > As you can see, I've turned on the -verbose cm3 option to make the > > differences clear.> > I don't understand these: | is the pipe symbol even for cmd.exe, isn't> it?> > Shouldn't these commands just read `cd pkg && cm3 -verbose ...'?> > && should work for /bin/sh as well as for cme.exe, IIRC.> > Olaf> -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194> _________________________________________________________________ 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 Jan 23 13:48:28 2008 From: jayk123 at hotmail.com (Jay) Date: Wed, 23 Jan 2008 12:48:28 +0000 Subject: [M3devel] platform/build_dir is a big tuple? In-Reply-To: <20080123122002.6rcdyji1us4okkww@mail.elegosoft.com> References: <479605CF.1E75.00D7.1@scires.com> <20080123122002.6rcdyji1us4okkww@mail.elegosoft.com> Message-ID: Good point Olaf, thanks for refocusing us. (and here I go again...) The behavior of NT386 is not in question. I churned the underlying code (just the default config file, which "hopefully" nobody has to change at all) and it can/does now share with others, but "nobody should notice anything" that is using NT386 (famous last words..nothing under my sleeve...) NT386GNU's behavior is the question. I made it more like NT386 that some/all folks desire while still using the gcc backend, which is goodness, from a certain point of view, but not everything. Perhaps nobody wants the in between behavior, granted. However if there are people really eager for LONGINT on NT386, then "NT386MINGNU" will be it for now. That's it's critical innovation, perhaps. I was taking too long on the integrated backend changes. I still have stuff sitting around there. And a slower build, with less efficient code without the -O flag but oh well. >> (or NT386_CYGWIN or whatever) I assume that name is out of the question. But if we are still talking about this (!) and still open to such changes, then I like NT386_CYGWIN, NT386_MINGWIN, NT386_MINGNU, I386_CYGWIN, I386_MINGWIN, I386_NT_CYG, I386_NT_?, and simlar with "x86" replacing I386, or maybe I686, maybe drop the "i". I used to use a system that didn't like leading numbers on file names, only latter, but I think that's now always allowed. If we must derive from (and keep) the existing NT386 and NT386GNU names, then NT386MINGNU I like. In any case, my plan remains, for the actual "target" to be NT386. These other names are only file names and have less impact on the system. As well, you know that function over in m3cc\m3makefile and m3gdb\m3makefile? How does that compare with the GNU_PLATFORM defined in the individual config files? Seems redundant, eh? So that reduces slightly this impact. As I said..cm3.exe itself has only a few differences between NT386 and other similar, and adequate bits via "backend mode" and perhaps "os type". cm3 cares about jmpbuf size but it doesn't care about threading library, window library, c library. Maybe hopefully some day it will care about exception handling model but for now, the same across all targets. Really we're talking about 10, maybe 30 lines of diff to push this stuff much further along..depending on how much Cygwin "just works". - Jay > From: wagner at elegosoft.com >> > it as well. Summarized I strongly vote for NT386 being Windows with least> > dependencies on other packages.> > There has never been a question about this. But there are other who> prefer something more POSIXish like Cygwin, which is why other targets> like NT386GNU (or NT386_CYGWIN or whatever) are needed.> > Olaf _________________________________________________________________ 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 Wed Jan 23 13:50:13 2008 From: jayk123 at hotmail.com (Jay) Date: Wed, 23 Jan 2008 12:50:13 +0000 Subject: [M3devel] new problem on NT386 In-Reply-To: References: <4796B970.1E75.00D7.1@scires.com> <4796D0BA.1E75.00D7.1@scires.com> <20080123123937.onc4m6fa4gg8ogg0@mail.elegosoft.com> Message-ID: forgot to answer that, yes. There's good online documentation for cmd viewable from any host. :) - Jay > > I don't understand these: | is the pipe symbol even for cmd.exe, isn't> it?> > Olaf _________________________________________________________________ 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 Jan 23 16:20:47 2008 From: jayk123 at hotmail.com (Jay) Date: Wed, 23 Jan 2008 15:20:47 +0000 Subject: [M3devel] license.. Message-ID: Where must the Critical Mass notice be displayed? See for example cminstall/src/config/NT386*. Did they remove all the individual Digital notices? I'll check later.. I'm not against licensing and all, but I dislike big banners *everywhere*, in every file. One little file per directory I guess ok, still kind of obnoxious. It's not up to me obviously, it's up to the original author. We have it far from the worst, I realize. I have seen some humungous per-file banners. The banners are often the vast majority of the file... (all the more reason to smush files together :) ) - 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 rcoleburn at scires.com Wed Jan 23 18:31:16 2008 From: rcoleburn at scires.com (Randy Coleburn) Date: Wed, 23 Jan 2008 12:31:16 -0500 Subject: [M3devel] new problem on NT386 In-Reply-To: References: <4796B970.1E75.00D7.1@scires.com> <4796D0BA.1E75.00D7.1@scires.com> <20080123123937.onc4m6fa4gg8ogg0@mail.elegosoft.com> Message-ID: <47973393.1E75.00D7.1@scires.com> Jay: Reactor uses quake to invoke procedures that do the build, link, ship, edit, start browser, etc. The user can customize these quake procedures, if needed. The default procedures all cd to the package root. The package should contain a "src" folder and optionally, one or more target folders, e.g. "NT386". So, after cd to the package root, "cm3" is invoked to do the build/clean/ship type work with the package root as the "current dir". A writer is set up to capture the output of the quake calls and the output of this writer is fed back into the browser window so the user can see the progress of the compile/ship/clean/etc. As for "&&" vs. "|", I am not a quake guru, but the pipe symbol has worked in all versions of reactor on all platforms up to this point as a command separator in the built-in quake exec() function call. As for my cm3.cfg, it is the one that came from your MIN distribution that I used to get started, with one exception. There is a place early in the file where INSTALL_ROOT = "c:\\cm3" is commented out. If I run reactor with cm3.cfg this way, it gets a runtime exception "array subscript out of range" in module M3Path.m3 at line 410. So, I un-commented this line and reactor runs without the error, but alas it is having the other aforementioned problems. I have attached the cm3.cfg file that I use in the v5.2.6 tests as cm3.cfg.526 I have attached the cm3.cfg file that I use in the vd5.5.1 tests as cm3.cfg.d551 You should note that Reactor was written by Critical Mass for v4.1 and they had a deep understanding of the system. If the underlying system changes in a way that breaks some deep understanding reliance on the v4.1 architecture, reactor will most likely misbehave. At this point I don't think I am at liberty to give you the source code to look at. My agreement with the Critical Mass license holders is that I had to make certain changes before releasing the code. As for the cm3.cfg at m3-sys\cminstall\src\config\nt386, I took a look at it. It seems to include a NT386.common file. I have not tried this variant yet. If I need to try it, let me know. And, do I have to copy NT386 to cm3\bin as cm3.cfg and then also copy the NT386.common file to cm3\bin? There seems to be a lot of stuff going on under the covers that I don't understand about finding locations for things. I see code in reactor where it tries to locate certain things. It seems the cm3.exe is doing similar stuff. I always thought that the cm3.cfg that was in the INSTALL_ROOT bin folder is the one that rules. Let me know if this is not the case. Regards, Randy >>> Jay 1/23/2008 7:37 AM >>> Oops good point Olaf. Yes && works with cmd. If the first command succeeds, the second is run. Succeeds as in exit code is 0. I assume "pkg" contained "enough content to make it work", but if indeed it is a directory, no go. I wasn't really reading the content oops sorry. But yet Randy said it worked with 5.2.6. Randy, you reminded me of a good point though. Upgrade.py plays a new game with config files, one which I like so far, but maybe isn't so great. I don't remember if I updated upgrade.cmd to this new model. In either case, to remove variables, to remove changes, look at your cm3.cfg. Read it a bit. Is it a stub that looks for another config file to include? If so, undo that on your machine. Find the other file, it is cvsroot\m3-sys\cminstall\src\config\nt386, and copy that over \cm3\bin\cm3.cfg, and try again. In either case I'm sure this is not a big deal.... Can you make the code available to me somehow? I do need to get some real work done during the week(s) but the weekend... - Jay > Date: Wed, 23 Jan 2008 12:39:37 +0100 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] new problem on NT386 > > Quoting Randy Coleburn : > > > OK, scratch what I said in my prior message about the "cd" not > > working. I ran some more tests and I'm not sure anymore. > > > > Jay, what has changed in the way quake, cm3, and cm3.cfg interact > > since v5.2.6? > > > > What I am seeing is that when Reactor is built using the current > > cm3, the output that should be going to the web browser is instead > > going to the console log. This is strange. The same exact code > > compiled under 5.2.6 works correctly (output goes to browser). > > > > Also, there are some strange differences in the output and the > > results are different. Not only are the results different, they are > > wrong under the new system, while they are correct under 5.2.6. > > Indeed, the build operation on the new system does not even find the > > correct package. > > > > Reactor is written in Modula-3, but it does use some quake helper > > functions. Here are the quake sources that Reactor is using for the > > clean and build procedures: > > > > proc clean_package (pkg) is > > exec ("cd", pkg, "| cm3 -verbose -clean") > > end > > proc build_package (pkg, options) is > > exec ("cd", pkg, "| cm3 -verbose", options) > > end > > As you can see, I've turned on the -verbose cm3 option to make the > > differences clear. > > I don't understand these: | is the pipe symbol even for cmd.exe, isn't > it? > > Shouldn't these commands just read `cd pkg && cm3 -verbose ...'? > > && should work for /bin/sh as well as for cme.exe, IIRC. > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > Helping your favorite cause is as easy as instant messaging. You IM, we give. Learn more. ( 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: cm3.cfg.526 Type: application/octet-stream Size: 14465 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: cm3.cfg.d551 Type: application/octet-stream Size: 18873 bytes Desc: not available URL: From wagner at elegosoft.com Wed Jan 23 19:32:16 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 23 Jan 2008 19:32:16 +0100 Subject: [M3devel] new problem on NT386 In-Reply-To: <479734AB.1E75.00D7.1@scires.com> References: <4796B970.1E75.00D7.1@scires.com> <4796D0BA.1E75.00D7.1@scires.com> <20080123123937.onc4m6fa4gg8ogg0@mail.elegosoft.com> <479734AB.1E75.00D7.1@scires.com> Message-ID: <20080123193216.4hun5uus8hwksw88@mail.elegosoft.com> Quoting Randy Coleburn : > Olaf: > > The pipe symbol is used by reactor in the quake exec() calls. I did > not program this; it was done by CMass Inc. My experience has been that > the pipe worked as a command separator in the quake exec() call, even on > the Unix systems. I agree it looks strange, but then, I'm not a quake > expert. Is this documented anywhere? The online doc says exec(...) The arguments are catenated and passed to the operating system to be executed as a child process. The command may start `-' or `@'. These are stripped before the command is passed to the command interpreter. A prefix of `@' indicates that the default action of printing the command to the standard output stream before execution should be overridden. A prefix character of `-' overrides quake's default action of aborting if it detects an error return code after executing the command. I've never seen it, and it seems a really strange choice to me, since it would make it impossible to use pipes within a command. OK, I've found it, but didn't know it ever existed ;-) Here is the diff: % cvs diff -u -r 1.3 -r 1.4 m3-sys/m3quake/src/QMachine.m3 Index: m3-sys/m3quake/src/QMachine.m3 =================================================================== RCS file: /usr/cvs/cm3/m3-sys/m3quake/src/QMachine.m3,v retrieving revision 1.3 retrieving revision 1.4 diff -u -u -r1.3 -r1.4 --- m3-sys/m3quake/src/QMachine.m3 25 Jun 2003 14:36:32 -0000 1.3 +++ m3-sys/m3quake/src/QMachine.m3 16 Oct 2005 13:43:32 -0000 1.4 @@ -1354,7 +1354,6 @@ quake_in : Pipe.T; process_out : Pipe.T; wr : Wr.T := CurWr (t); - wd : TEXT; inbuf : ARRAY [0..255] OF CHAR; BEGIN info.command := ""; @@ -1396,8 +1395,6 @@ Err (t, "write failed" & OSErr (ec)); END; - wd := ExtractInitialDir (info.command); - args [0] := t.sh_option; args [1] := info.command; n_shell_args := 2; @@ -1410,7 +1407,7 @@ (* fire up the subprocess *) handle := Process.Create (t.shell, SUBARRAY (args, 0, n_shell_args), stdin := stdin, stdout := process_out, - stderr := process_out, wd := wd); + stderr := process_out); (* close our copy of the writing end of the output pipe *) process_out.close (); LOOP (* send anything coming through the pipe to the quake output file *) @@ -1439,38 +1436,6 @@ RETURN info; END ExecCommand; -PROCEDURE ExtractInitialDir (VAR cmd: TEXT): TEXT = - (* search for "cd |" or "cd ;" prefix in "cmd". - If it's found, return "" and remove the prefix from "cmd". - Otherwise, return "NIL". *) - VAR - len := Text.Length (cmd); - buf : ARRAY [0..99] OF CHAR; - start, stop: INTEGER; - dir: TEXT; - BEGIN - IF (len < 5) THEN RETURN NIL; END; - Text.SetChars (buf, cmd); - start := 0; - WHILE (start < len) AND (buf[start] = ' ') DO INC (start); END; - IF (start+4 >= len) THEN RETURN NIL; END; - IF (buf[start] # 'c') THEN RETURN NIL; END; - IF (buf[start+1] # 'd') THEN RETURN NIL; END; - IF (buf[start+2] # ' ') THEN RETURN NIL; END; - INC (start, 3); - WHILE (start < len) AND (buf[start] = ' ') DO INC (start); END; - stop := start; - WHILE (stop < len) AND (buf[stop] # ' ') - AND (buf[stop] # '|') AND (buf[stop] # ';') DO INC (stop); END; - IF (stop <= start) THEN RETURN NIL; END; - dir := Text.FromChars (SUBARRAY (buf, start, stop - start)); - WHILE (stop < len) AND (buf[stop] = ' ') DO INC (stop); END; - IF (stop >= len) THEN RETURN NIL; END; - IF (buf[stop] # '|') AND (buf[stop] # ';') THEN RETURN NIL; END; - cmd := Text.Sub (cmd, stop+1); - RETURN dir; - END ExtractInitialDir; - PROCEDURE KillProcess (handle: Process.T) = BEGIN IF (handle # NIL) THEN Obviously it has been remove by rillig (Robert Illig?): revision 1.4 date: 2005-10-16 13:43:32 +0000; author: rillig; state: Exp; lines: +1 -36; Removed the superfluous and error prone ExtractInitialDir procedure, which had tried to parse the shell command, and if it starts with "cd ", changed to that directory itself. So it only looked for cd dir | and then changed the directory accordingly, but it really was an undocumented hack and is not needed. I'd suggest to just use 'cd dir &&' instead. If that doesn't work, please let me know. A grep through the sources for 'cd .*\|' should reveal all occurences. If you need more enhanced execution functions, I can also contribute a module with much better abstractions for running commands. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Jan 23 20:55:21 2008 From: rcoleburn at scires.com (Randy Coleburn) Date: Wed, 23 Jan 2008 14:55:21 -0500 Subject: [M3devel] new problem on NT386 In-Reply-To: <20080123193216.4hun5uus8hwksw88@mail.elegosoft.com> References: <4796B970.1E75.00D7.1@scires.com> <4796D0BA.1E75.00D7.1@scires.com> <20080123123937.onc4m6fa4gg8ogg0@mail.elegosoft.com> <479734AB.1E75.00D7.1@scires.com> <20080123193216.4hun5uus8hwksw88@mail.elegosoft.com> Message-ID: <47975558.1E75.00D7.1@scires.com> Olaf: THANKS! It is obvious that these changes to QMachine are responsible for the problems. It would have taken me forever to find this. Thanks so much! I changed the quake procedures to use "&&" instead of "|" and the build/ship routines seem to work again. Indeed, I even went back and put the comment back in Jay's cm3.cfg and it still works without crashing in M3Path. This is very good! Now, I am not real good at parsing thru these text diff files, but am I seeing there was also a change to QMachine that involves how the output is being redirected? What I am observing in reactor, is that the build/ship/clean/etc output is not being shown in the browser window. Since these functions are being called via a quake procedure, if the QMachine has been altered somehow not to allow this output to be redirected, then reactor is going to have a real problem. The output of these quake routines is showing up in the console log window instead of being redirected back to the browser as it was in 4.1 and 5.2.6. Regards, Randy >>> Olaf Wagner 1/23/2008 1:32 PM >>> Quoting Randy Coleburn : > Olaf: > > The pipe symbol is used by reactor in the quake exec() calls. I did > not program this; it was done by CMass Inc. My experience has been that > the pipe worked as a command separator in the quake exec() call, even on > the Unix systems. I agree it looks strange, but then, I'm not a quake > expert. Is this documented anywhere? The online doc says exec(...) The arguments are catenated and passed to the operating system to be executed as a child process. The command may start `-' or `@'. These are stripped before the command is passed to the command interpreter. A prefix of `@' indicates that the default action of printing the command to the standard output stream before execution should be overridden. A prefix character of `-' overrides quake's default action of aborting if it detects an error return code after executing the command. I've never seen it, and it seems a really strange choice to me, since it would make it impossible to use pipes within a command. OK, I've found it, but didn't know it ever existed ;-) Here is the diff: % cvs diff -u -r 1.3 -r 1.4 m3-sys/m3quake/src/QMachine.m3 Index: m3-sys/m3quake/src/QMachine.m3 =================================================================== RCS file: /usr/cvs/cm3/m3-sys/m3quake/src/QMachine.m3,v retrieving revision 1.3 retrieving revision 1.4 diff -u -u -r1.3 -r1.4 --- m3-sys/m3quake/src/QMachine.m3 25 Jun 2003 14:36:32 -0000 1.3 +++ m3-sys/m3quake/src/QMachine.m3 16 Oct 2005 13:43:32 -0000 1.4 @@ -1354,7 +1354,6 @@ quake_in : Pipe.T; process_out : Pipe.T; wr : Wr.T := CurWr (t); - wd : TEXT; inbuf : ARRAY [0..255] OF CHAR; BEGIN info.command := ""; @@ -1396,8 +1395,6 @@ Err (t, "write failed" & OSErr (ec)); END; - wd := ExtractInitialDir (info.command); - args [0] := t.sh_option; args [1] := info.command; n_shell_args := 2; @@ -1410,7 +1407,7 @@ (* fire up the subprocess *) handle := Process.Create (t.shell, SUBARRAY (args, 0, n_shell_args), stdin := stdin, stdout := process_out, - stderr := process_out, wd := wd); + stderr := process_out); (* close our copy of the writing end of the output pipe *) process_out.close (); LOOP (* send anything coming through the pipe to the quake output file *) @@ -1439,38 +1436,6 @@ RETURN info; END ExecCommand; -PROCEDURE ExtractInitialDir (VAR cmd: TEXT): TEXT = - (* search for "cd |" or "cd ;" prefix in "cmd". - If it's found, return "" and remove the prefix from "cmd". - Otherwise, return "NIL". *) - VAR - len := Text.Length (cmd); - buf : ARRAY [0..99] OF CHAR; - start, stop: INTEGER; - dir: TEXT; - BEGIN - IF (len < 5) THEN RETURN NIL; END; - Text.SetChars (buf, cmd); - start := 0; - WHILE (start < len) AND (buf[start] = ' ') DO INC (start); END; - IF (start+4 >= len) THEN RETURN NIL; END; - IF (buf[start] # 'c') THEN RETURN NIL; END; - IF (buf[start+1] # 'd') THEN RETURN NIL; END; - IF (buf[start+2] # ' ') THEN RETURN NIL; END; - INC (start, 3); - WHILE (start < len) AND (buf[start] = ' ') DO INC (start); END; - stop := start; - WHILE (stop < len) AND (buf[stop] # ' ') - AND (buf[stop] # '|') AND (buf[stop] # ';') DO INC (stop); END; - IF (stop <= start) THEN RETURN NIL; END; - dir := Text.FromChars (SUBARRAY (buf, start, stop - start)); - WHILE (stop < len) AND (buf[stop] = ' ') DO INC (stop); END; - IF (stop >= len) THEN RETURN NIL; END; - IF (buf[stop] # '|') AND (buf[stop] # ';') THEN RETURN NIL; END; - cmd := Text.Sub (cmd, stop+1); - RETURN dir; - END ExtractInitialDir; - PROCEDURE KillProcess (handle: Process.T) = BEGIN IF (handle # NIL) THEN Obviously it has been remove by rillig (Robert Illig?): revision 1.4 date: 2005-10-16 13:43:32 +0000; author: rillig; state: Exp; lines: +1 -36; Removed the superfluous and error prone ExtractInitialDir procedure, which had tried to parse the shell command, and if it starts with "cd ", changed to that directory itself. So it only looked for cd dir | and then changed the directory accordingly, but it really was an undocumented hack and is not needed. I'd suggest to just use 'cd dir &&' instead. If that doesn't work, please let me know. A grep through the sources for 'cd .*\|' should reveal all occurences. If you need more enhanced execution functions, I can also contribute a module with much better abstractions for running commands. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com ( http://www.elegosoft.com/ ) | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Wed Jan 23 21:38:35 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 23 Jan 2008 15:38:35 -0500 Subject: [M3devel] platform/build_dir is a big tuple? In-Reply-To: References: <479605CF.1E75.00D7.1@scires.com> Message-ID: <9402FB12-D4AF-458A-93B8-3A6973D88CFE@cs.purdue.edu> On Jan 23, 2008, at 2:49 AM, Jay wrote: > > If anyone wanted user vtlaram or fiber, this could be > extended. > > It probably always should have been fibers instead of setjmp/ > longjmp where fibers are available... > > Oh, sorry, Modula-3 has never to my knowledge used user/vtalarm > threads. ThreadPosix uses user/vtalarm threads. Swicthing is done using setjmp/longjmp or setcontext/getcontext depending on platform. ON modern POSIX platforms it should always use the latter. > > > If anyone does want to take over their own scheduling and have an > N:M model, fibers are perhaps the way to go, unless you need Win9x. > Fibers take care of creating a stack and swapping register context, > whereas setjmp/longjmp only swap register context and I suspect > Modula-3 uses them in a non-conformant but generally-compatible > way. I haven't looked into this yet. For exceptions, ok. For thread > switching, probably not. > But I'd have to look at how it's implemented.. > > user mode threads, fibers..are problematic. For example Win32 > critical sections can be taken recursively, on the same thread. > Fibers can move around between threads and therefore cannot take > them recursively. > > All in all, as said below, I'm inclined to omit support for user > mode threads on Windows. > I ASSUME the Cygwin pthreads are a thin wrapper over Windows, > except...except there is the condition variables...not sure they > can be layered over thinly... As I said, this is one bit I am > uncertan of. Maybe just always use native Win32 threads. > It would be a perhaps interesting curiosity to see if cygwin > binaries tend to only depend on cygwin .dlls and not win32 .dlls, > as a "proof" of the "completeness" of the layer/wrapping. (though > as to the quality, see below.) Of course, cygwin code can still use > win32..your m3makefile might actually check target==nt386 to know > "the truth". But I doubt anyone would use this flexibility. > > - Jay > > From: jayk123 at hotmail.com > To: lemming at henning-thielemann.de; rcoleburn at scires.com > CC: m3devel at elegosoft.com > Subject: RE: [M3devel] platform/build_dir is a big tuple? > Date: Wed, 23 Jan 2008 07:37:28 +0000 > > Let me cut to the chase, again: > > Everyone will probably be satisfied. > For a very small "everyone". :) > > The underlying implementation shall be "heavily" parameterized. > There shall be three visible pre packaged configurations. > Power users, and clever and crazy people can experiment beyond > those three. > The EXACT three configurations is SLIGHTLY up in the air, but is > likely to be: > > NT386 > same as today, integrated backend, Win32 GUI, msvc*.dll, native > win32 kernel threads, native backslashy paths (and perhaps > increased compat with forward slashes, some of that is already in, > m3core, but not yet cm3), Visual C++ compiler and linker. > > NT386MINGNU > same as today's (recent) NT386GNU, but with Trestle-on-Win32 also > working > external backend, gcc compiler and linker, but otherwise same as > NT386 > One small wrinkle here is there is no m3gdb, but you can use the > m3gdb from the next one, or Cygwin's gdb. > > NT386GNU > As GNU as possible. pthreads (uncertain), X Windows (CygwinX), > Cygwin C library, stupid looking paths that start /cygdrive, wierdo > symlinks that don't interoperate well with the rest of the system > (attempting to run cc.exe crashes ntvdm.exe, for example), "link" > makes file system links (or at least strange files) instead of > linking programs, a slow and perhaps fragile copy-immediately > implementation of fork, problems running one type of program from > another because you don't know which command line parameters and > which environment variables represent paths or lists of paths and > therefore how to translate them, etc. > > The underlying parameters, which are largely independent and which > you can change individually, but which you will actually just > ignore usually, shall be: > > modula-3 backend > integrated 0 > cm3cg 1 > This might be replaced by the existing 0-3 variable. > > C compiler > Visual C++ cl 0 > gcc 1 > In future this could be redefined as decimal digit or a > character to accomodate other choices. > > linker > Visual C++ link 0 > gcc 1 > In future this could be redefined as decimal digit or a > character to accomodate other choices. > > Threading library > Native Win32 kernel threads 0 > Cygwin pthreads which are probably layered on native Win32 > kernel threads 1 > This is the one area where people have suggested using native > Win32 functionality instead of Cygwin > vtalaram user threads probably not available > fiber user threads probably not available > This would have been better than vtalaram, but not Win9x > compatible > If anyone wanted user vtlaram or fiber, this could be > extended. It probably always should have been fibers instead of > setjmp/longjmp where fibers are available... > > Window library > Native Win32 gui 0 (hopefully with bugs to be worked out) > X Windows via CygwinX 1 (hopefully the binaries are X server > agnostic, and even work against a remote Unix machine?) > > C library > native msvcr* through Visual C++ or MinGWin 0 > Cygwin and its path oddities 1 > > The current notion of "OSTYPE" becomes much less useful here, as it > previously embodied multiple factors. > It wasn't all that useful anyway, imho, but as a way to reduce the > matrix of targets down to two, the same two in multiple places. > Now, in a few places, you check a more specific variable. > Theoretically, I don't have to change cm3 here, just the config > file and some m3makefiles. Because, tricky tricky, the main thing > cm3 cares about is the backend "mode", and that does match up above > with the 0/1. There are actually 4 modes and I should maybe hoist > that up to be the variable, very maybe. A few m3makefiles will have > to change, in small ways. > > Therefore, NT386 is all 0s, NT386GNU shall be all 1s, except > maybe threading, and NT386MINGNU shall be a mix -- backend, C > compiler, linker 1, the rest 0. Besides that, what I haven't in my > head yet, is that individual m3makefiles should be able to ask for > one compiler or the other. The base system won't do that, but user > systems could, if they have some code that depends on one compiler > or the other and they are going to link it together. For this > purpose, for exposing these features to users, possibly values > other than "0" and "1" are needed. > > If the configuration is one of these three combinations, build_dir > is translated as shown. > Otherwise, it is "NT386-" plus the unreadable string of 0s and 1s. > > This is essentially already commited. NT386 works this way. > NT386MINGNU works this, but is for now called NT386GNU, and doesn't > have any Trestle yet. The new/old Cygwin NT386GNU isn't active yet, > but easily should be. > > There are three config files, NT386, NT386MINGNU, NT386GNU, they > are all just a few lines and then include NT386.common. > > Oh, one more thing I haven't worked out is how the user asks for > one target or another. > It is probably via the environment variable CM3_TARGET, though in > reality, "TARGET" for all of these shall be NT386. > > Any questions? > Don't ask me when Cygwin NT386GNU will be active or when the names > will flip. I will try it soon. > > This is essentiallyalready in the tree, with a little bit of > "temporary, for compat" sprinkled in to avoid renaming NT386GNU/ > MINGNU just yet, and the Cygwinish stuff not active, no X Windows > on NT386 yet..groundwork is laid, I think I've stopped thinking > through the indecisiveness, I just keep hearing the two extreme > sides, the Windows users who want Windows (do you even care about > the gcc backend? It's slow. It generates inefficient code. It > supports Longint) and a few Unix users who might reluctantly use > Windows a little more if their backend slowed down and their > libraries changed... > > Personally my main goal here is to not feel guilty about not > finishing the LONGINT support yet in the integrated backend. > I'd still like to finish that, but it was taking embarassingly long. > > I'd also like an uber-cross build environment, where I can build > anything from anything. Getting cm3cg working was part of that. I'm > not sure I have the patience to build gcc and ld/binutils that many > times though. > > - Jay > > > > > Date: Wed, 23 Jan 2008 08:06:20 +0100 > > From: lemming at henning-thielemann.de > > Subject: Re: [M3devel] platform/build_dir is a big tuple? > > To: rcoleburn at scires.com > > CC: m3devel at elegosoft.com; jayk123 at hotmail.com > > > > > > On Tue, 22 Jan 2008, Randy Coleburn wrote: > > > > > Jay: > > > > > > For my part on Windows, I am happy to stay with the underlying > OS, the > > > native windows threading, the integrated backend, and use the free > > > Microsoft Visual Studio tools. I don't really want to have to > > > install/use cygwin or any of the other variants. When I see > target = > > > NT386, this list is what I am expecting. For the cm3 newbie > coming from > > > a Microsoft Windows environment, I think this list would be the > most > > > appealing and pose the least barrier to getting starting. Yes, > I still > > > will work on the installer program once I'm satisfied that I > have a good > > > working cm3 on Windows. > > > > One year ago I was in the situation to port one of my Modula-3 > programs > > from Linux to Windows in order to hand it over to a Windows user. > As I > > never use Windows, I have only a plain Windows installation on my > machine > > with almost no tools other than cm3. I was glad to be able to run > cm3 > > immediately and to find all libraries that I needed in binary > form without > > Cygwin dependencies - otherwise not only I had to install that on my > > machine but I also would have to persuade the other Windows guy > to install > > it as well. Summarized I strongly vote for NT386 being Windows > with least > > dependencies on other packages. > > > 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 wagner at elegosoft.com Wed Jan 23 22:10:01 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 23 Jan 2008 22:10:01 +0100 Subject: [M3devel] new problem on NT386 In-Reply-To: <47975558.1E75.00D7.1@scires.com> References: <4796B970.1E75.00D7.1@scires.com> <4796D0BA.1E75.00D7.1@scires.com> <20080123123937.onc4m6fa4gg8ogg0@mail.elegosoft.com> <479734AB.1E75.00D7.1@scires.com> <20080123193216.4hun5uus8hwksw88@mail.elegosoft.com> <47975558.1E75.00D7.1@scires.com> Message-ID: <20080123221001.8pbvhkjdc8408w80@mail.elegosoft.com> Quoting Randy Coleburn : > Olaf: > > THANKS! It is obvious that these changes to QMachine are responsible > for the problems. It would have taken me forever to find this. Thanks > so much! > > I changed the quake procedures to use "&&" instead of "|" and the > build/ship routines seem to work again. Indeed, I even went back and > put the comment back in Jay's cm3.cfg and it still works without > crashing in M3Path. This is very good! > > Now, I am not real good at parsing thru these text diff files, but am I > seeing there was also a change to QMachine that involves how the output > is being redirected? > > What I am observing in reactor, is that the build/ship/clean/etc output > is not being shown in the browser window. Since these functions are > being called via a quake procedure, if the QMachine has been altered > somehow not to allow this output to be redirected, then reactor is going > to have a real problem. The output of these quake routines is showing > up in the console log window instead of being redirected back to the > browser as it was in 4.1 and 5.2.6. Randy, I've added compatibilit procedures that should show the old (queer) behaviour: cm3_exec and try_cm3_exec. The semantics were changed in this commit: revision 1.5 date: 2005-10-17 21:00:36 +0000; author: rillig; state: Exp; lines: +4 -20; Don't pass the stdout and stderr from child processes through quake. This makes the quake code simpler and also allows the user to redirect the stdout and the stderr to different files. Before, the stdout and stderr had been merged by quake and then printed on stdout. I think the main goal of the quake changes was to make CM3 and PM3 compatible; but this now seems to break the old Reactor code. So try if cm3_exec instead of just exec will cure your problem. You'll have to rebuild the m3quake package of course. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Jan 23 22:37:53 2008 From: rcoleburn at scires.com (Randy Coleburn) Date: Wed, 23 Jan 2008 16:37:53 -0500 Subject: [M3devel] new problem on NT386 In-Reply-To: <20080123221001.8pbvhkjdc8408w80@mail.elegosoft.com> References: <4796B970.1E75.00D7.1@scires.com> <4796D0BA.1E75.00D7.1@scires.com> <20080123123937.onc4m6fa4gg8ogg0@mail.elegosoft.com> <479734AB.1E75.00D7.1@scires.com> <20080123193216.4hun5uus8hwksw88@mail.elegosoft.com> <47975558.1E75.00D7.1@scires.com> <20080123221001.8pbvhkjdc8408w80@mail.elegosoft.com> Message-ID: <47976D5F.1E75.00D7.1@scires.com> Olaf: I grabbed the new QMachine via cvs and rebuilt & shipped the m3quake package, then rebuilt reactor (now cm3_ide) to take advantage of it. I replaced the exec calls with cm3_exec(). At first glance, things were working better in that the output is now going back to the browser. Great! But, when I tried to compile a simple "HelloWorld" program, I ran into some errors. See attached PDF file. Does any of this make sense to you? Note that this same HelloWorld program was compiling before the QMachine change, its just that the output went to the wrong window. Regards, Randy >>> Olaf Wagner 1/23/2008 4:10 PM >>> Quoting Randy Coleburn : > Olaf: > > THANKS! It is obvious that these changes to QMachine are responsible > for the problems. It would have taken me forever to find this. Thanks > so much! > > I changed the quake procedures to use "&&" instead of "|" and the > build/ship routines seem to work again. Indeed, I even went back and > put the comment back in Jay's cm3.cfg and it still works without > crashing in M3Path. This is very good! > > Now, I am not real good at parsing thru these text diff files, but am I > seeing there was also a change to QMachine that involves how the output > is being redirected? > > What I am observing in reactor, is that the build/ship/clean/etc output > is not being shown in the browser window. Since these functions are > being called via a quake procedure, if the QMachine has been altered > somehow not to allow this output to be redirected, then reactor is going > to have a real problem. The output of these quake routines is showing > up in the console log window instead of being redirected back to the > browser as it was in 4.1 and 5.2.6. Randy, I've added compatibilit procedures that should show the old (queer) behaviour: cm3_exec and try_cm3_exec. The semantics were changed in this commit: revision 1.5 date: 2005-10-17 21:00:36 +0000; author: rillig; state: Exp; lines: +4 -20; Don't pass the stdout and stderr from child processes through quake. This makes the quake code simpler and also allows the user to redirect the stdout and the stderr to different files. Before, the stdout and stderr had been merged by quake and then printed on stdout. I think the main goal of the quake changes was to make CM3 and PM3 compatible; but this now seems to break the old Reactor code. So try if cm3_exec instead of just exec will cure your problem. You'll have to rebuild the m3quake package of course. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com ( http://www.elegosoft.com/ ) | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: buildHello.pdf Type: application/pdf Size: 30627 bytes Desc: not available URL: From wagner at elegosoft.com Wed Jan 23 23:23:10 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 23 Jan 2008 23:23:10 +0100 Subject: [M3devel] new problem on NT386 In-Reply-To: <47976D5F.1E75.00D7.1@scires.com> References: <4796B970.1E75.00D7.1@scires.com> <4796D0BA.1E75.00D7.1@scires.com> <20080123123937.onc4m6fa4gg8ogg0@mail.elegosoft.com> <479734AB.1E75.00D7.1@scires.com> <20080123193216.4hun5uus8hwksw88@mail.elegosoft.com> <47975558.1E75.00D7.1@scires.com> <20080123221001.8pbvhkjdc8408w80@mail.elegosoft.com> <47976D5F.1E75.00D7.1@scires.com> Message-ID: <20080123232310.5znrlsr5ywwgc4o0@mail.elegosoft.com> Quoting Randy Coleburn : > Olaf: > > I grabbed the new QMachine via cvs and rebuilt & shipped the m3quake > package, then rebuilt reactor (now cm3_ide) to take advantage of it. I > replaced the exec calls with cm3_exec(). > > At first glance, things were working better in that the output is now > going back to the browser. Great! > > But, when I tried to compile a simple "HelloWorld" program, I ran into > some errors. See attached PDF file. Does any of this make sense to > you? > > Note that this same HelloWorld program was compiling before the > QMachine change, its just that the output went to the wrong window. It seems I've made a mistake by forgetting to initialize the std file handles. Please try again, Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Jan 24 00:05:12 2008 From: jayk123 at hotmail.com (Jay) Date: Wed, 23 Jan 2008 23:05:12 +0000 Subject: [M3devel] new problem on NT386 In-Reply-To: <20080123232310.5znrlsr5ywwgc4o0@mail.elegosoft.com> References: <4796B970.1E75.00D7.1@scires.com> <4796D0BA.1E75.00D7.1@scires.com> <20080123123937.onc4m6fa4gg8ogg0@mail.elegosoft.com> <479734AB.1E75.00D7.1@scires.com> <20080123193216.4hun5uus8hwksw88@mail.elegosoft.com> <47975558.1E75.00D7.1@scires.com> <20080123221001.8pbvhkjdc8408w80@mail.elegosoft.com> <47976D5F.1E75.00D7.1@scires.com> <20080123232310.5znrlsr5ywwgc4o0@mail.elegosoft.com> Message-ID: Catching up, just to clearly confirm: | and && have the same meaning in cmd as in sh. | is the pipe, the stdout of the left is the stdin of the right stderr probably is separate, and you should in general imho throw in "2>&1" to avoid hangs that can occur if stderr is used. && is kind of like && in C, boolean and, shortcircuiting. I was unaware of this stuff in Quake. cmd is actually documented online, can read those docs from any host, not just windows, the online docs appear similar to what you can find on a live system. Randy, I ask again, can what you have be made available to anyone to assist with any problems? It seems you have no outstanding problems, so currently moot. Btw, Microsoft nmake handles cd specially as well. Normally each nmake command is a separate process, but a few are "emulated", cd and set. And cd can cross drives, but cd /d does not, which is the opposite of cmd, where cd /d is needed to cross drives, and cd does not.. Later. - Jay > Date: Wed, 23 Jan 2008 23:23:10 +0100> From: wagner at elegosoft.com> To: rcoleburn at scires.com> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] new problem on NT386> > Quoting Randy Coleburn :> > > Olaf:> >> > I grabbed the new QMachine via cvs and rebuilt & shipped the m3quake> > package, then rebuilt reactor (now cm3_ide) to take advantage of it. I> > replaced the exec calls with cm3_exec().> >> > At first glance, things were working better in that the output is now> > going back to the browser. Great!> >> > But, when I tried to compile a simple "HelloWorld" program, I ran into> > some errors. See attached PDF file. Does any of this make sense to> > you?> >> > Note that this same HelloWorld program was compiling before the> > QMachine change, its just that the output went to the wrong window.> > It seems I've made a mistake by forgetting to initialize the std> file handles.> > Please try again,> > Olaf> -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 Thu Jan 24 00:08:20 2008 From: jayk123 at hotmail.com (Jay) Date: Wed, 23 Jan 2008 23:08:20 +0000 Subject: [M3devel] platform/build_dir is a big tuple? In-Reply-To: <9402FB12-D4AF-458A-93B8-3A6973D88CFE@cs.purdue.edu> References: <479605CF.1E75.00D7.1@scires.com> <9402FB12-D4AF-458A-93B8-3A6973D88CFE@cs.purdue.edu> Message-ID: below > From: hosking at cs.purdue.edu> Subject: Re: [M3devel] platform/build_dir is a big tuple?> > On Jan 23, 2008, at 2:49 AM, Jay wrote:> > > Oh, sorry, Modula-3 has never to my knowledge used user/vtalarm > > threads.> > ThreadPosix uses user/vtalarm threads. Swicthing is done using > setjmp/longjmp or setcontext/getcontext depending on platform. ON > modern POSIX platforms it should always use the latter. Oops, I meant on Windows! The use of setjmp/longjmp is not ANSI C conformant, right? I kind of suspect how it'd work without having looked it but I don't have quite in my head. Will look later and know better, just curious, no matter. - 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 Thu Jan 24 00:23:20 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 24 Jan 2008 00:23:20 +0100 Subject: [M3devel] Archive Upload to CM3 WWW Message-ID: <20080124002320.c3lzxz55mso8gs00@mail.elegosoft.com> All those m3-users with ssh access can now upload installation archives they have built to birch.elegosoft.com:/var/www/modula3.elegosoft.com/cm3/uploaded-archives The archives must conform to the standard naming scheme: cm3-{min,std,all,core,base,doc}-{POSIX,WIN32,WIN,WIN64}-*-*.\ {tar.gz,tar.bz,tar.bz2,tgz,tbz,zip} for example cm3-min-WIN32-NT386GNU-d5.5.1.tar.bz2 cm3-min-POSIX-LINUXLIBC6-d5.5.0.tgz You may also add a corresponding description in a file with the same name and added .html or .txt suffix. Please don't copy anything else to this directory; I trust that the service will not be misused. A new index is generated every 5 minutes. You'll find the index under Installation / Uploaded Archives on the CM3 WWW pages. The URL is http://modula3.elegosoft.com/cm3/snaps/snapshot-index.html We can extend the naming scheme if necessary; it's probably a bit limited currently. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Jan 24 01:51:33 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 23 Jan 2008 19:51:33 -0500 Subject: [M3devel] platform/build_dir is a big tuple? In-Reply-To: References: <479605CF.1E75.00D7.1@scires.com> <9402FB12-D4AF-458A-93B8-3A6973D88CFE@cs.purdue.edu> Message-ID: <66444C15-4C87-4444-AECF-A97D79CF461D@cs.purdue.edu> Yes, setjmp/longjmp hacking (changing fields to cause thread switches) breaks on some implementations (Linux) that encrypt the fields to prevent exploits. setcontext/getcontext are the modern POSIX calls that should be used for user-threading on POSIX. On Jan 23, 2008, at 6:08 PM, Jay wrote: > below > > > From: hosking at cs.purdue.edu > > Subject: Re: [M3devel] platform/build_dir is a big tuple? > > > > On Jan 23, 2008, at 2:49 AM, Jay wrote: > > > > > Oh, sorry, Modula-3 has never to my knowledge used user/vtalarm > > > threads. > > > > ThreadPosix uses user/vtalarm threads. Swicthing is done using > > setjmp/longjmp or setcontext/getcontext depending on platform. ON > > modern POSIX platforms it should always use the latter. > > Oops, I meant on Windows! > > The use of setjmp/longjmp is not ANSI C conformant, right? I kind > of suspect how it'd work without having looked it but I don't have > quite in my head. Will look later and know better, just curious, no > matter. > > > - Jay > > Shed those extra pounds with MSN and The Biggest Loser! Learn more. From neels at elego.de Thu Jan 24 14:47:17 2008 From: neels at elego.de (Neels Janosch Hofmeyr) Date: Thu, 24 Jan 2008 14:47:17 +0100 Subject: [M3devel] minimal binary d5.5.0 fails on Ubuntu 7.10 Message-ID: <479896E5.3090106@elego.de> Hello m3-support and m3devel, I tried to bootstrap cm3 on Ubuntu 7.10 using the newer d5.5.0 binaries. Upon running cd scripts ./do-cm3-core.sh buildship I got a series of errors, ending in a segmentation fault. I am now going back to the 5.4.0 minimal binary. For interest, find the error output below. Regards, Neels neels at oubantu:~/cm3-build/scripts $ ./do-cm3-core.sh buildship CM3C = /home/neels/cm3-build/scripts/pkgmap.sh -c "cm3 -build -DROOT='/home/neels/cm3-build' && cm3 -ship -DROOT='/home/neels/cm3-build' " m3gc-simple m3core libm3 patternmatching m3middle m3linker m3front m3quake m3cc cm3 m3scanner m3tools m3cgcat m3cggen m3bundle bitvector digraph parseparams realgeometry set slisp sortedtableextras table-list tempfiles === package /home/neels/cm3-build/m3-libs/m3gc-simple === +++ cm3 -build -DROOT='/home/neels/cm3-build' && cm3 -ship -DROOT='/home/neels/cm3-build' +++ --- building in LINUXLIBC6 --- new source -> compiling sysdeps.c -> archiving libm3gcdefs.a --- shipping from LINUXLIBC6 --- . => /usr/local/cm3/pkg/m3gc-simple/LINUXLIBC6 .M3EXPORTS libm3gcdefs.so.5 libm3gcdefs.a libm3gcdefs.m3x .M3WEB ../src/runtime => /usr/local/cm3/pkg/m3gc-simple/src/runtime RTVM.c ../src/runtime/LINUXLIBC6 => /usr/local/cm3/pkg/m3gc-simple/src/runtime/LINUXLIBC6 sysdeps.c . => /usr/local/cm3/lib libm3gcdefs.a ==> /home/neels/cm3-build/m3-libs/m3gc-simple done === package /home/neels/cm3-build/m3-libs/m3core === +++ cm3 -build -DROOT='/home/neels/cm3-build' && cm3 -ship -DROOT='/home/neels/cm3-build' +++ --- building in LINUXLIBC6 --- ignoring ../src/m3overrides new source -> compiling RTHooks.i3 RTHooks.i3: In function 'RTHooks_I3': RTHooks.i3:141: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling RT0.i3 RT0.i3: In function 'RT0_I3': RT0.i3:230: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling RuntimeError.i3 RuntimeError.i3: In function 'RuntimeError_I3': RuntimeError.i3:63: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling Word.i3 Word.i3: In function 'Word_I3': Word.i3:67: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling RTException.i3 RTException.i3: In function 'RTException_I3': RTException.i3:34: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling RTHooks.m3 RTHooks.m3: In function 'RTHooks_M3': RTHooks.m3:130: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling RT0.m3 RT0.m3:10: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling Compiler.i3 Compiler.i3: In function 'Compiler_I3': Compiler.i3:42: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling RuntimeError.m3 RuntimeError.m3: In function 'RuntimeError_M3': RuntimeError.m3:61: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling Compiler.m3 Compiler.m3: In function 'Compiler_M3': Compiler.m3:11: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling RTAllocator.i3 RTAllocator.i3: In function 'RTAllocator_I3': RTAllocator.i3:79: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling RTType.i3 RTType.i3: In function 'RTType_I3': RTType.i3:65: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling Uucontext.i3 Uucontext.i3: In function 'Uucontext_I3': Uucontext.i3:195: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling Utypes.i3 Utypes.i3: In function 'Utypes_I3': Utypes.i3:108: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling BasicCtypes.i3 BasicCtypes.i3: In function 'BasicCtypes_I3': BasicCtypes.i3:33: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling Ctypes.i3 Ctypes.i3: In function 'Ctypes_I3': Ctypes.i3:67: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling Usignal.i3 Usignal.i3: In function 'Usignal_I3': Usignal.i3:199: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling Csetjmp.i3 Csetjmp.i3: In function 'Csetjmp_I3': Csetjmp.i3:29: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling RTMachine.i3 RTMachine.i3: In function 'RTMachine_I3': RTMachine.i3:87: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling Upthread.i3 Upthread.i3: In function 'Upthread_I3': Upthread.i3:343: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling Utime.i3 Utime.i3: In function 'Utime_I3': Utime.i3:182: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling RTHeapDep.i3 RTHeapDep.i3: In function 'RTHeapDep_I3': RTHeapDep.i3:74: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling RTHeapRep.i3 RTHeapRep.i3: In function 'RTHeapRep_I3': RTHeapRep.i3:310: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling Thread.i3 Thread.i3: In function 'Thread_I3': Thread.i3:120: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling FloatMode.i3 FloatMode.i3: In function 'FloatMode_I3': FloatMode.i3:123: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling ThreadF.i3 ThreadF.i3: In function 'ThreadF_I3': ThreadF.i3:110: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling RTOS.i3 RTOS.i3: In function 'RTOS_I3': RTOS.i3:44: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling RTMisc.i3 RTMisc.i3: In function 'RTMisc_I3': RTMisc.i3:29: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling RTHeap.i3 RTHeap.i3: In function 'RTHeap_I3': RTHeap.i3:44: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling Cstdlib.i3 Cstdlib.i3: In function 'Cstdlib_I3': Cstdlib.i3:34: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling Cstddef.i3 Cstddef.i3: In function 'Cstddef_I3': Cstddef.i3:14: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling RTAllocCnts.i3 RTAllocCnts.i3: In function 'RTAllocCnts_I3': RTAllocCnts.i3:22: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling RTAllocator.m3 RTAllocator.m3: In function 'RTAllocator_M3': RTAllocator.m3:387: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling RTAllocStats.i3 RTAllocStats.i3: In function 'RTAllocStats_I3': RTAllocStats.i3:39: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling Convert.i3 Convert.i3: In function 'Convert_I3': Convert.i3:111: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling TextClass.i3 TextClass.i3: In function 'TextClass_I3': TextClass.i3:46: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling Text.i3 Text.i3: In function 'Text_I3': Text.i3:81: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling RTProcedureSRC.i3 RTProcedureSRC.i3: In function 'RTProcedureSRC_I3': RTProcedureSRC.i3:28: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling Fingerprint.i3 Fingerprint.i3: In function 'Fingerprint_I3': Fingerprint.i3:63: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling RTProcedure.i3 RTProcedure.i3: In function 'RTProcedure_I3': RTProcedure.i3:32: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling RTStack.i3 RTStack.i3: In function 'RTStack_I3': RTStack.i3:53: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling RTAllocStats.m3 "../src/runtime/common/RTAllocStats.m3", line 46: undefined runtime symbol !! (RTHooks.AllocateTracedRef) *** *** runtime error: *** Segmentation violation - possible attempt to dereference NIL *** pc = 0x811e7ff = StartCall + 0x19 in ../src/values/Procedure.m3 *** Aborted (core dumped) *** execution of failed *** -- Neels Janosch Hofmeyr Software Developer neels at elego.de Public Key: http://binarchy.net/neels/neels.hofmeyr.public.key.asc elego Software Solutions GmbH http://www.elegosoft.com Gustav-Meyer-Allee 25, Geb?ude 12 HRB 77719 13355 Berlin, Germany Amtsgericht Charlottenburg Tel.: +49 30 23 45 86 96 Sitz der Gesellschaft: Berlin Fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Olaf Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From mika at async.caltech.edu Thu Jan 24 15:41:50 2008 From: mika at async.caltech.edu (Mika Nystrom) Date: Thu, 24 Jan 2008 06:41:50 -0800 Subject: [M3devel] minimal binary d5.5.0 fails on Ubuntu 7.10 In-Reply-To: Your message of "Thu, 24 Jan 2008 14:47:17 +0100." <479896E5.3090106@elego.de> Message-ID: <200801241441.m0OEfo13084214@camembert.async.caltech.edu> I think this is the broken cm3.cfg . Search for -g in cm3.cfg and replace it with -gstabs+ This thing bites a lot! I think it got me twice to the extent that I had to ask this mailing list. Several other times that it had me scratching my head and then thinking "oh it's that cm3.cfg thing again..." cm3.cfg in general is pretty weird. I know the compiler looks in at least two places for it. (Undocumented behavior.) Mika Neels Janosch Hofmeyr writes: >This is an OpenPGP/MIME signed message (RFC 2440 and 3156) >--------------enigBBB9AF364E0AAD943688858C >Content-Type: text/plain; charset=UTF-8; format=flowed >Content-Transfer-Encoding: quoted-printable > >Hello m3-support and m3devel, > >I tried to bootstrap cm3 on Ubuntu 7.10 using the newer d5.5.0 binaries. = > >Upon running > cd scripts > ./do-cm3-core.sh buildship > >I got a series of errors, ending in a segmentation fault. I am now going = > >back to the 5.4.0 minimal binary. For interest, find the error output bel= >ow. > >Regards, >Neels > > >neels at oubantu:~/cm3-build/scripts >$ ./do-cm3-core.sh buildship >CM3C =3D >/home/neels/cm3-build/scripts/pkgmap.sh -c "cm3 -build =20 >-DROOT=3D'/home/neels/cm3-build' && cm3 -ship=20 >-DROOT=3D'/home/neels/cm3-build' " m3gc-simple m3core libm3=20 >patternmatching m3middle m3linker m3front m3quake m3cc cm3 m3scanner=20 >m3tools m3cgcat m3cggen m3bundle bitvector digraph parseparams=20 >realgeometry set slisp sortedtableextras table-list tempfiles >=3D=3D=3D package /home/neels/cm3-build/m3-libs/m3gc-simple =3D=3D=3D > +++ cm3 -build -DROOT=3D'/home/neels/cm3-build' && cm3 -ship=20 >-DROOT=3D'/home/neels/cm3-build' +++ >--- building in LINUXLIBC6 --- > >new source -> compiling sysdeps.c > -> archiving libm3gcdefs.a >--- shipping from LINUXLIBC6 --- > >=2E =3D> /usr/local/cm3/pkg/m3gc-simple/LINUXLIBC6 > .M3EXPORTS libm3gcdefs.so.5 libm3gcdefs.a libm3gcdefs.m3x > .M3WEB =20 >=2E./src/runtime =3D> /usr/local/cm3/pkg/m3gc-simple/src/runtime > RTVM.c =20 >=2E./src/runtime/LINUXLIBC6 =3D>=20 >/usr/local/cm3/pkg/m3gc-simple/src/runtime/LINUXLIBC6 > sysdeps.c =20 >=2E =3D> /usr/local/cm3/lib > libm3gcdefs.a =20 > =3D=3D> /home/neels/cm3-build/m3-libs/m3gc-simple done > >=3D=3D=3D package /home/neels/cm3-build/m3-libs/m3core =3D=3D=3D > +++ cm3 -build -DROOT=3D'/home/neels/cm3-build' && cm3 -ship=20 >-DROOT=3D'/home/neels/cm3-build' +++ >--- building in LINUXLIBC6 --- > >ignoring ../src/m3overrides > >new source -> compiling RTHooks.i3 >RTHooks.i3: In function 'RTHooks_I3': >RTHooks.i3:141: internal compiler error: Segmentation fault >Please submit a full bug report, >with preprocessed source if appropriate. >See for instructions. >new source -> compiling RT0.i3 >RT0.i3: In function 'RT0_I3': >RT0.i3:230: internal compiler error: Segmentation fault >Please submit a full bug report, >with preprocessed source if appropriate. >See for instructions. >new source -> compiling RuntimeError.i3 >RuntimeError.i3: In function 'RuntimeError_I3': >RuntimeError.i3:63: internal compiler error: Segmentation fault >Please submit a full bug report, >with preprocessed source if appropriate. >See for instructions. >new source -> compiling Word.i3 >Word.i3: In function 'Word_I3': >Word.i3:67: internal compiler error: Segmentation fault >Please submit a full bug report, >with preprocessed source if appropriate. >See for instructions. >new source -> compiling RTException.i3 >RTException.i3: In function 'RTException_I3': >RTException.i3:34: internal compiler error: Segmentation fault >Please submit a full bug report, >with preprocessed source if appropriate. >See for instructions. >new source -> compiling RTHooks.m3 >RTHooks.m3: In function 'RTHooks_M3': >RTHooks.m3:130: internal compiler error: Segmentation fault >Please submit a full bug report, >with preprocessed source if appropriate. >See for instructions. >new source -> compiling RT0.m3 >RT0.m3:10: internal compiler error: Segmentation fault >Please submit a full bug report, >with preprocessed source if appropriate. >See for instructions. >new source -> compiling Compiler.i3 >Compiler.i3: In function 'Compiler_I3': >Compiler.i3:42: internal compiler error: Segmentation fault >Please submit a full bug report, >with preprocessed source if appropriate. >See for instructions. >new source -> compiling RuntimeError.m3 >RuntimeError.m3: In function 'RuntimeError_M3': >RuntimeError.m3:61: internal compiler error: Segmentation fault >Please submit a full bug report, >with preprocessed source if appropriate. >See for instructions. >new source -> compiling Compiler.m3 >Compiler.m3: In function 'Compiler_M3': >Compiler.m3:11: internal compiler error: Segmentation fault >Please submit a full bug report, >with preprocessed source if appropriate. >See for instructions. >new source -> compiling RTAllocator.i3 >RTAllocator.i3: In function 'RTAllocator_I3': >RTAllocator.i3:79: internal compiler error: Segmentation fault >Please submit a full bug report, >with preprocessed source if appropriate. >See for instructions. >new source -> compiling RTType.i3 >RTType.i3: In function 'RTType_I3': >RTType.i3:65: internal compiler error: Segmentation fault >Please submit a full bug report, >with preprocessed source if appropriate. >See for instructions. >new source -> compiling Uucontext.i3 >Uucontext.i3: In function 'Uucontext_I3': >Uucontext.i3:195: internal compiler error: Segmentation fault >Please submit a full bug report, >with preprocessed source if appropriate. >See for instructions. >new source -> compiling Utypes.i3 >Utypes.i3: In function 'Utypes_I3': >Utypes.i3:108: internal compiler error: Segmentation fault >Please submit a full bug report, >with preprocessed source if appropriate. >See for instructions. >new source -> compiling BasicCtypes.i3 >BasicCtypes.i3: In function 'BasicCtypes_I3': >BasicCtypes.i3:33: internal compiler error: Segmentation fault >Please submit a full bug report, >with preprocessed source if appropriate. >See for instructions. >new source -> compiling Ctypes.i3 Ctypes.i3: In function 'Ctypes_I3': >Ctypes.i3:67: internal compiler error: Segmentation fault >Please submit a full bug report, >with preprocessed source if appropriate. >See for instructions. >new source -> compiling Usignal.i3 >Usignal.i3: In function 'Usignal_I3': >Usignal.i3:199: internal compiler error: Segmentation fault >Please submit a full bug report, >with preprocessed source if appropriate. >See for instructions. >new source -> compiling Csetjmp.i3 >Csetjmp.i3: In function 'Csetjmp_I3': >Csetjmp.i3:29: internal compiler error: Segmentation fault >Please submit a full bug report, >with preprocessed source if appropriate. >See for instructions. >new source -> compiling RTMachine.i3 >RTMachine.i3: In function 'RTMachine_I3': >RTMachine.i3:87: internal compiler error: Segmentation fault >Please submit a full bug report, >with preprocessed source if appropriate. >See for instructions. >new source -> compiling Upthread.i3 >Upthread.i3: In function 'Upthread_I3': >Upthread.i3:343: internal compiler error: Segmentation fault >Please submit a full bug report, >with preprocessed source if appropriate. >See for instructions. >new source -> compiling Utime.i3 >Utime.i3: In function 'Utime_I3': >Utime.i3:182: internal compiler error: Segmentation fault >Please submit a full bug report, >with preprocessed source if appropriate. >See for instructions. >new source -> compiling RTHeapDep.i3 >RTHeapDep.i3: In function 'RTHeapDep_I3': >RTHeapDep.i3:74: internal compiler error: Segmentation fault >Please submit a full bug report, >with preprocessed source if appropriate. >See for instructions. >new source -> compiling RTHeapRep.i3 >RTHeapRep.i3: In function 'RTHeapRep_I3': >RTHeapRep.i3:310: internal compiler error: Segmentation fault >Please submit a full bug report, >with preprocessed source if appropriate. >See for instructions. >new source -> compiling Thread.i3 >Thread.i3: In function 'Thread_I3': >Thread.i3:120: internal compiler error: Segmentation fault >Please submit a full bug report, >with preprocessed source if appropriate. >See for instructions. >new source -> compiling FloatMode.i3 >FloatMode.i3: In function 'FloatMode_I3': >FloatMode.i3:123: internal compiler error: Segmentation fault >Please submit a full bug report, >with preprocessed source if appropriate. >See for instructions. >new source -> compiling ThreadF.i3 >ThreadF.i3: In function 'ThreadF_I3': >ThreadF.i3:110: internal compiler error: Segmentation fault >Please submit a full bug report, >with preprocessed source if appropriate. >See for instructions. >new source -> compiling RTOS.i3 >RTOS.i3: In function 'RTOS_I3': >RTOS.i3:44: internal compiler error: Segmentation fault >Please submit a full bug report, >with preprocessed source if appropriate. >See for instructions. >new source -> compiling RTMisc.i3 >RTMisc.i3: In function 'RTMisc_I3': >RTMisc.i3:29: internal compiler error: Segmentation fault >Please submit a full bug report, >with preprocessed source if appropriate. >See for instructions. >new source -> compiling RTHeap.i3 >RTHeap.i3: In function 'RTHeap_I3': >RTHeap.i3:44: internal compiler error: Segmentation fault >Please submit a full bug report, >with preprocessed source if appropriate. >See for instructions. >new source -> compiling Cstdlib.i3 >Cstdlib.i3: In function 'Cstdlib_I3': >Cstdlib.i3:34: internal compiler error: Segmentation fault >Please submit a full bug report, >with preprocessed source if appropriate. >See for instructions. >new source -> compiling Cstddef.i3 >Cstddef.i3: In function 'Cstddef_I3': >Cstddef.i3:14: internal compiler error: Segmentation fault >Please submit a full bug report, >with preprocessed source if appropriate. >See for instructions. >new source -> compiling RTAllocCnts.i3 >RTAllocCnts.i3: In function 'RTAllocCnts_I3': >RTAllocCnts.i3:22: internal compiler error: Segmentation fault >Please submit a full bug report, >with preprocessed source if appropriate. >See for instructions. >new source -> compiling RTAllocator.m3 >RTAllocator.m3: In function 'RTAllocator_M3': >RTAllocator.m3:387: internal compiler error: Segmentation fault >Please submit a full bug report, >with preprocessed source if appropriate. >See for instructions. >new source -> compiling RTAllocStats.i3 >RTAllocStats.i3: In function 'RTAllocStats_I3': >RTAllocStats.i3:39: internal compiler error: Segmentation fault >Please submit a full bug report, >with preprocessed source if appropriate. >See for instructions. >new source -> compiling Convert.i3 >Convert.i3: In function 'Convert_I3': >Convert.i3:111: internal compiler error: Segmentation fault >Please submit a full bug report, >with preprocessed source if appropriate. >See for instructions. >new source -> compiling TextClass.i3 >TextClass.i3: In function 'TextClass_I3': >TextClass.i3:46: internal compiler error: Segmentation fault >Please submit a full bug report, >with preprocessed source if appropriate. >See for instructions. >new source -> compiling Text.i3 >Text.i3: In function 'Text_I3': >Text.i3:81: internal compiler error: Segmentation fault >Please submit a full bug report, >with preprocessed source if appropriate. >See for instructions. >new source -> compiling RTProcedureSRC.i3 >RTProcedureSRC.i3: In function 'RTProcedureSRC_I3': >RTProcedureSRC.i3:28: internal compiler error: Segmentation fault >Please submit a full bug report, >with preprocessed source if appropriate. >See for instructions. >new source -> compiling Fingerprint.i3 >Fingerprint.i3: In function 'Fingerprint_I3': >Fingerprint.i3:63: internal compiler error: Segmentation fault >Please submit a full bug report, >with preprocessed source if appropriate. >See for instructions. >new source -> compiling RTProcedure.i3 >RTProcedure.i3: In function 'RTProcedure_I3': >RTProcedure.i3:32: internal compiler error: Segmentation fault >Please submit a full bug report, >with preprocessed source if appropriate. >See for instructions. >new source -> compiling RTStack.i3 >RTStack.i3: In function 'RTStack_I3': >RTStack.i3:53: internal compiler error: Segmentation fault >Please submit a full bug report, >with preprocessed source if appropriate. >See for instructions. >new source -> compiling RTAllocStats.m3 >"../src/runtime/common/RTAllocStats.m3", line 46: undefined runtime=20 >symbol !! (RTHooks.AllocateTracedRef) > > >*** >*** runtime error: >*** Segmentation violation - possible attempt to dereference NIL >*** pc =3D 0x811e7ff =3D StartCall + 0x19 in ../src/values/Procedure.m= >3 >*** > >Aborted (core dumped) > *** execution of failed *** > > >--=20 >Neels Janosch Hofmeyr >Software Developer > >neels at elego.de >Public Key: http://binarchy.net/neels/neels.hofmeyr.public.key.asc > >elego Software Solutions GmbH http://www.elegosoft.com >Gustav-Meyer-Allee 25, Geb=C3=A4ude 12 HRB 77719 >13355 Berlin, Germany Amtsgericht Charlottenburg >Tel.: +49 30 23 45 86 96 Sitz der Gesellschaft: Berlin >Fax: +49 30 23 45 86 95 Gesch=C3=A4ftsf=C3=BChrer: Olaf W= >agner > > > >--------------enigBBB9AF364E0AAD943688858C >Content-Type: application/pgp-signature; name="signature.asc" >Content-Description: OpenPGP digital signature >Content-Disposition: attachment; filename="signature.asc" > >-----BEGIN PGP SIGNATURE----- >Version: GnuPG v1.4.6 (GNU/Linux) > >iD8DBQFHmJbkRpHEG7B8Y+ARAtjGAJ47SAvF3xSFUuQT0gd5ZF2OLbOX9wCg12+B >bD8Jx13qOgK+5OasBdztrYg= >=IPcA >-----END PGP SIGNATURE----- > >--------------enigBBB9AF364E0AAD943688858C-- From hendrik at topoi.pooq.com Thu Jan 24 15:44:36 2008 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Thu, 24 Jan 2008 09:44:36 -0500 Subject: [M3devel] license.. In-Reply-To: References: Message-ID: <20080124144436.GC18598@topoi.pooq.com> On Wed, Jan 23, 2008 at 03:20:47PM +0000, Jay wrote: > > I'm not against licensing and all, but I dislike big banners *everywhere*, in every file. > One little file per directory I guess ok, still kind of obnoxious. > It's not up to me obviously, it's up to the original author. > We have it far from the worst, I realize. I have seen some humungous per-file banners. > The banners are often the vast majority of the file... > (all the more reason to smush files together :) ) One of the things I hate about Eiffel is that every class has to be in its own file. Java is almost as bad. It doesn't formally have this restriction, but except for a few very local classes, you pretty well have to follow it anyway. I really like the way you can put multiple classes into one file in Modula 3. Now if I could only have modules within modules too, or at least multiple modules per file, I'd be happy. The way you want break a program up into files -- or don't -- depends on pragmatics, such as the tools you are comfortable with in the operating environment, and not on the way you want to express your program in your programming language. I'm in favour of a greater disconnect between syntactic struture and division into files. Huge copyright banners are an excellent example of how pragmatics affect programming. -- hendrik From wagner at elegosoft.com Thu Jan 24 16:34:03 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 24 Jan 2008 16:34:03 +0100 Subject: [M3devel] minimal binary d5.5.0 fails on Ubuntu 7.10 In-Reply-To: <200801241441.m0OEfo13084214@camembert.async.caltech.edu> References: <200801241441.m0OEfo13084214@camembert.async.caltech.edu> Message-ID: <20080124163403.d91ldw5m8s84gw88@mail.elegosoft.com> Quoting Mika Nystrom : > > I think this is the broken cm3.cfg . > > Search for -g in cm3.cfg and replace it with -gstabs+ > > This thing bites a lot! I think it got me twice to the extent that > I had to ask this mailing list. Several other times that it had > me scratching my head and then thinking "oh it's that cm3.cfg thing > again..." The problem here is that dwarf debugging format which was in wide use seems to be discontinued and now produces segmentation faults if used with gcc or at least cm3cg :-/ Perhaps it's just nor correctly supported in the CM3 gcc backend. There's another possibility for `wrong' update: it does not suffice to run do-cm3-core.sh, you probably need to perform a full upgrade with scripts/upgrade.sh. > cm3.cfg in general is pretty weird. I know the compiler looks > in at least two places for it. (Undocumented behavior.) The compiler looks o based on an environment variable ((C)M3CONFIG?) o in the current directory o in the directory where the cm3 binary resides IIRC. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From lemming at henning-thielemann.de Thu Jan 24 16:39:57 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Thu, 24 Jan 2008 16:39:57 +0100 (MET) Subject: [M3devel] license.. In-Reply-To: <20080124144436.GC18598@topoi.pooq.com> References: <20080124144436.GC18598@topoi.pooq.com> Message-ID: On Thu, 24 Jan 2008 hendrik at topoi.pooq.com wrote: > On Wed, Jan 23, 2008 at 03:20:47PM +0000, Jay wrote: > > > > I'm not against licensing and all, but I dislike big banners *everywhere*, in every file. > > One little file per directory I guess ok, still kind of obnoxious. > > It's not up to me obviously, it's up to the original author. > > We have it far from the worst, I realize. I have seen some humungous per-file banners. > > The banners are often the vast majority of the file... > > (all the more reason to smush files together :) ) > > One of the things I hate about Eiffel is that every class has to be in > its own file. > > Java is almost as bad. It doesn't formally have this restriction, but > except for a few very local classes, you pretty well have to follow it > anyway. > > I really like the way you can put multiple classes into one file in > Modula 3. But you should not do so, because qualification gives more natural names if the module name reflects the name of its main type. In anticipation of generic modules it is also a good idea to call the main type T. I found it good style, also in other programming languages, to setup one module per (important) data type. Sooner or later there are enough functions in the module to justify this separate unit. From mika at async.caltech.edu Thu Jan 24 16:58:21 2008 From: mika at async.caltech.edu (Mika Nystrom) Date: Thu, 24 Jan 2008 07:58:21 -0800 Subject: [M3devel] license.. In-Reply-To: Your message of "Thu, 24 Jan 2008 16:39:57 +0100." Message-ID: <200801241558.m0OFwLIG086411@camembert.async.caltech.edu> Henning Thielemann writes: > >On Thu, 24 Jan 2008 hendrik at topoi.pooq.com wrote: > >> On Wed, Jan 23, 2008 at 03:20:47PM +0000, Jay wrote: >> > >> > I'm not against licensing and all, but I dislike big banners *everywhere*, in every file. >> > One little file per directory I guess ok, still kind of obnoxious. >> > It's not up to me obviously, it's up to the original author. >> > We have it far from the worst, I realize. I have seen some humungous per-file banners. >> > The banners are often the vast majority of the file... >> > (all the more reason to smush files together :) ) >> >> One of the things I hate about Eiffel is that every class has to be in >> its own file. >> >> Java is almost as bad. It doesn't formally have this restriction, but >> except for a few very local classes, you pretty well have to follow it >> anyway. >> >> I really like the way you can put multiple classes into one file in >> Modula 3. > >But you should not do so, because qualification gives more natural names >if the module name reflects the name of its main type. In anticipation of >generic modules it is also a good idea to call the main type T. I found it >good style, also in other programming languages, to setup one module per >(important) data type. Sooner or later there are enough functions in the >module to justify this separate unit. It would be Really Nice to be able to instantiate more than one generic in a single file, I think.... (As it is, using lots of generics in M3 involves writing lots of Quake code.) Mika P.S. I do not believe the language specification makes any reference whatever to the concent of source "files". There is no reason you couldn't have a single file containing: INTERFACE A; TYPE T = RECORD x : SomeType END; END A. INTERFACE B; IMPORT A; TYPE T = A.T; END B. (Two modules in one file.) The stylistic matter of whether to declare more than one type in an interface is a separate issue, I think. From jayk123 at hotmail.com Thu Jan 24 17:06:46 2008 From: jayk123 at hotmail.com (Jay) Date: Thu, 24 Jan 2008 16:06:46 +0000 Subject: [M3devel] license.. In-Reply-To: References: <20080124144436.GC18598@topoi.pooq.com> Message-ID: oh boy.. I'm slightly on the fence here but tend toward the fewer files answer.The open question to me is, is programming more type based or module based? If your modules all have one primary type, then I claim it is really type based masquerading as module based. Lately in C I have: typedef struct Foo_t { .. } Foo_t; typedef struct Bar_t { .. } Bar_t; Bar_DoSomething(Bar_t* ...) { } Foo_DoSomething(Foo_t* ...) { } My code is all about types and not so much about "modules" or "facilities" or "subsystems". The types may be groupable into much, but it seems a secondary thing. I'm thinking of inventing a new programming language called Typo-3. :) - Jay > Date: Thu, 24 Jan 2008 16:39:57 +0100> From: lemming at henning-thielemann.de> To: hendrik at topoi.pooq.com> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] license..> > > On Thu, 24 Jan 2008 hendrik at topoi.pooq.com wrote:> > > On Wed, Jan 23, 2008 at 03:20:47PM +0000, Jay wrote:> > >> > > I'm not against licensing and all, but I dislike big banners *everywhere*, in every file.> > > One little file per directory I guess ok, still kind of obnoxious.> > > It's not up to me obviously, it's up to the original author.> > > We have it far from the worst, I realize. I have seen some humungous per-file banners.> > > The banners are often the vast majority of the file...> > > (all the more reason to smush files together :) )> >> > One of the things I hate about Eiffel is that every class has to be in> > its own file.> >> > Java is almost as bad. It doesn't formally have this restriction, but> > except for a few very local classes, you pretty well have to follow it> > anyway.> >> > I really like the way you can put multiple classes into one file in> > Modula 3.> > But you should not do so, because qualification gives more natural names> if the module name reflects the name of its main type. In anticipation of> generic modules it is also a good idea to call the main type T. I found it> good style, also in other programming languages, to setup one module per> (important) data type. Sooner or later there are enough functions in the> module to justify this separate unit.> _________________________________________________________________ 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 Jan 24 19:30:08 2008 From: jayk123 at hotmail.com (Jay) Date: Thu, 24 Jan 2008 18:30:08 +0000 Subject: [M3devel] minimal binary d5.5.0 fails on Ubuntu 7.10 In-Reply-To: <200801241441.m0OEfo13084214@camembert.async.caltech.edu> References: Your message of "Thu, 24 Jan 2008 14:47:17 +0100." <479896E5.3090106@elego.de> <200801241441.m0OEfo13084214@camembert.async.caltech.edu> Message-ID: I thought Dwarf, or Dwarf2 was the preferred format. Weird all around. On "NT386GNU", as I recall, -ggdb crashes, -g is equiv to -stabs+, which is a little more info than -gstabs. I have to check again to see if there are types. I assume we can't submit bug reports due to having a custom front end unless you can repro with C/C++/Ada/Java. Right I saw the probing for cm3.cfg in the code and was surprised, I only knew the place it was actually present. - Jay > To: neels at elego.de> Date: Thu, 24 Jan 2008 06:41:50 -0800> From: mika at async.caltech.edu> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] minimal binary d5.5.0 fails on Ubuntu 7.10> > > I think this is the broken cm3.cfg .> > Search for -g in cm3.cfg and replace it with -gstabs+> > This thing bites a lot! I think it got me twice to the extent that> I had to ask this mailing list. Several other times that it had> me scratching my head and then thinking "oh it's that cm3.cfg thing> again..."> > cm3.cfg in general is pretty weird. I know the compiler looks> in at least two places for it. (Undocumented behavior.)> > Mika> > Neels Janosch Hofmeyr writes:> >This is an OpenPGP/MIME signed message (RFC 2440 and 3156)> >--------------enigBBB9AF364E0AAD943688858C> >Content-Type: text/plain; charset=UTF-8; format=flowed> >Content-Transfer-Encoding: quoted-printable> >> >Hello m3-support and m3devel,> >> >I tried to bootstrap cm3 on Ubuntu 7.10 using the newer d5.5.0 binaries. => >> >Upon running> > cd scripts> > ./do-cm3-core.sh buildship> >> >I got a series of errors, ending in a segmentation fault. I am now going => >> >back to the 5.4.0 minimal binary. For interest, find the error output bel=> >ow.> >> >Regards,> >Neels> >> >> >neels at oubantu:~/cm3-build/scripts> >$ ./do-cm3-core.sh buildship> >CM3C =3D> >/home/neels/cm3-build/scripts/pkgmap.sh -c "cm3 -build =20> >-DROOT=3D'/home/neels/cm3-build' && cm3 -ship=20> >-DROOT=3D'/home/neels/cm3-build' " m3gc-simple m3core libm3=20> >patternmatching m3middle m3linker m3front m3quake m3cc cm3 m3scanner=20> >m3tools m3cgcat m3cggen m3bundle bitvector digraph parseparams=20> >realgeometry set slisp sortedtableextras table-list tempfiles> >=3D=3D=3D package /home/neels/cm3-build/m3-libs/m3gc-simple =3D=3D=3D> > +++ cm3 -build -DROOT=3D'/home/neels/cm3-build' && cm3 -ship=20> >-DROOT=3D'/home/neels/cm3-build' +++> >--- building in LINUXLIBC6 ---> >> >new source -> compiling sysdeps.c> > -> archiving libm3gcdefs.a> >--- shipping from LINUXLIBC6 ---> >> >=2E =3D> /usr/local/cm3/pkg/m3gc-simple/LINUXLIBC6> > .M3EXPORTS libm3gcdefs.so.5 libm3gcdefs.a libm3gcdefs.m3x> > .M3WEB =20> >=2E./src/runtime =3D> /usr/local/cm3/pkg/m3gc-simple/src/runtime> > RTVM.c =20> >=2E./src/runtime/LINUXLIBC6 =3D>=20> >/usr/local/cm3/pkg/m3gc-simple/src/runtime/LINUXLIBC6> > sysdeps.c =20> >=2E =3D> /usr/local/cm3/lib> > libm3gcdefs.a =20> > =3D=3D> /home/neels/cm3-build/m3-libs/m3gc-simple done> >> >=3D=3D=3D package /home/neels/cm3-build/m3-libs/m3core =3D=3D=3D> > +++ cm3 -build -DROOT=3D'/home/neels/cm3-build' && cm3 -ship=20> >-DROOT=3D'/home/neels/cm3-build' +++> >--- building in LINUXLIBC6 ---> >> >ignoring ../src/m3overrides> >> >new source -> compiling RTHooks.i3> >RTHooks.i3: In function 'RTHooks_I3':> >RTHooks.i3:141: internal compiler error: Segmentation fault> >Please submit a full bug report,> >with preprocessed source if appropriate.> >See for instructions.> >new source -> compiling RT0.i3> >RT0.i3: In function 'RT0_I3':> >RT0.i3:230: internal compiler error: Segmentation fault> >Please submit a full bug report,> >with preprocessed source if appropriate.> >See for instructions.> >new source -> compiling RuntimeError.i3> >RuntimeError.i3: In function 'RuntimeError_I3':> >RuntimeError.i3:63: internal compiler error: Segmentation fault> >Please submit a full bug report,> >with preprocessed source if appropriate.> >See for instructions.> >new source -> compiling Word.i3> >Word.i3: In function 'Word_I3':> >Word.i3:67: internal compiler error: Segmentation fault> >Please submit a full bug report,> >with preprocessed source if appropriate.> >See for instructions.> >new source -> compiling RTException.i3> >RTException.i3: In function 'RTException_I3':> >RTException.i3:34: internal compiler error: Segmentation fault> >Please submit a full bug report,> >with preprocessed source if appropriate.> >See for instructions.> >new source -> compiling RTHooks.m3> >RTHooks.m3: In function 'RTHooks_M3':> >RTHooks.m3:130: internal compiler error: Segmentation fault> >Please submit a full bug report,> >with preprocessed source if appropriate.> >See for instructions.> >new source -> compiling RT0.m3> >RT0.m3:10: internal compiler error: Segmentation fault> >Please submit a full bug report,> >with preprocessed source if appropriate.> >See for instructions.> >new source -> compiling Compiler.i3> >Compiler.i3: In function 'Compiler_I3':> >Compiler.i3:42: internal compiler error: Segmentation fault> >Please submit a full bug report,> >with preprocessed source if appropriate.> >See for instructions.> >new source -> compiling RuntimeError.m3> >RuntimeError.m3: In function 'RuntimeError_M3':> >RuntimeError.m3:61: internal compiler error: Segmentation fault> >Please submit a full bug report,> >with preprocessed source if appropriate.> >See for instructions.> >new source -> compiling Compiler.m3> >Compiler.m3: In function 'Compiler_M3':> >Compiler.m3:11: internal compiler error: Segmentation fault> >Please submit a full bug report,> >with preprocessed source if appropriate.> >See for instructions.> >new source -> compiling RTAllocator.i3> >RTAllocator.i3: In function 'RTAllocator_I3':> >RTAllocator.i3:79: internal compiler error: Segmentation fault> >Please submit a full bug report,> >with preprocessed source if appropriate.> >See for instructions.> >new source -> compiling RTType.i3> >RTType.i3: In function 'RTType_I3':> >RTType.i3:65: internal compiler error: Segmentation fault> >Please submit a full bug report,> >with preprocessed source if appropriate.> >See for instructions.> >new source -> compiling Uucontext.i3> >Uucontext.i3: In function 'Uucontext_I3':> >Uucontext.i3:195: internal compiler error: Segmentation fault> >Please submit a full bug report,> >with preprocessed source if appropriate.> >See for instructions.> >new source -> compiling Utypes.i3> >Utypes.i3: In function 'Utypes_I3':> >Utypes.i3:108: internal compiler error: Segmentation fault> >Please submit a full bug report,> >with preprocessed source if appropriate.> >See for instructions.> >new source -> compiling BasicCtypes.i3> >BasicCtypes.i3: In function 'BasicCtypes_I3':> >BasicCtypes.i3:33: internal compiler error: Segmentation fault> >Please submit a full bug report,> >with preprocessed source if appropriate.> >See for instructions.> >new source -> compiling Ctypes.i3> Ctypes.i3: In function 'Ctypes_I3':> >Ctypes.i3:67: internal compiler error: Segmentation fault> >Please submit a full bug report,> >with preprocessed source if appropriate.> >See for instructions.> >new source -> compiling Usignal.i3> >Usignal.i3: In function 'Usignal_I3':> >Usignal.i3:199: internal compiler error: Segmentation fault> >Please submit a full bug report,> >with preprocessed source if appropriate.> >See for instructions.> >new source -> compiling Csetjmp.i3> >Csetjmp.i3: In function 'Csetjmp_I3':> >Csetjmp.i3:29: internal compiler error: Segmentation fault> >Please submit a full bug report,> >with preprocessed source if appropriate.> >See for instructions.> >new source -> compiling RTMachine.i3> >RTMachine.i3: In function 'RTMachine_I3':> >RTMachine.i3:87: internal compiler error: Segmentation fault> >Please submit a full bug report,> >with preprocessed source if appropriate.> >See for instructions.> >new source -> compiling Upthread.i3> >Upthread.i3: In function 'Upthread_I3':> >Upthread.i3:343: internal compiler error: Segmentation fault> >Please submit a full bug report,> >with preprocessed source if appropriate.> >See for instructions.> >new source -> compiling Utime.i3> >Utime.i3: In function 'Utime_I3':> >Utime.i3:182: internal compiler error: Segmentation fault> >Please submit a full bug report,> >with preprocessed source if appropriate.> >See for instructions.> >new source -> compiling RTHeapDep.i3> >RTHeapDep.i3: In function 'RTHeapDep_I3':> >RTHeapDep.i3:74: internal compiler error: Segmentation fault> >Please submit a full bug report,> >with preprocessed source if appropriate.> >See for instructions.> >new source -> compiling RTHeapRep.i3> >RTHeapRep.i3: In function 'RTHeapRep_I3':> >RTHeapRep.i3:310: internal compiler error: Segmentation fault> >Please submit a full bug report,> >with preprocessed source if appropriate.> >See for instructions.> >new source -> compiling Thread.i3> >Thread.i3: In function 'Thread_I3':> >Thread.i3:120: internal compiler error: Segmentation fault> >Please submit a full bug report,> >with preprocessed source if appropriate.> >See for instructions.> >new source -> compiling FloatMode.i3> >FloatMode.i3: In function 'FloatMode_I3':> >FloatMode.i3:123: internal compiler error: Segmentation fault> >Please submit a full bug report,> >with preprocessed source if appropriate.> >See for instructions.> >new source -> compiling ThreadF.i3> >ThreadF.i3: In function 'ThreadF_I3':> >ThreadF.i3:110: internal compiler error: Segmentation fault> >Please submit a full bug report,> >with preprocessed source if appropriate.> >See for instructions.> >new source -> compiling RTOS.i3> >RTOS.i3: In function 'RTOS_I3':> >RTOS.i3:44: internal compiler error: Segmentation fault> >Please submit a full bug report,> >with preprocessed source if appropriate.> >See for instructions.> >new source -> compiling RTMisc.i3> >RTMisc.i3: In function 'RTMisc_I3':> >RTMisc.i3:29: internal compiler error: Segmentation fault> >Please submit a full bug report,> >with preprocessed source if appropriate.> >See for instructions.> >new source -> compiling RTHeap.i3> >RTHeap.i3: In function 'RTHeap_I3':> >RTHeap.i3:44: internal compiler error: Segmentation fault> >Please submit a full bug report,> >with preprocessed source if appropriate.> >See for instructions.> >new source -> compiling Cstdlib.i3> >Cstdlib.i3: In function 'Cstdlib_I3':> >Cstdlib.i3:34: internal compiler error: Segmentation fault> >Please submit a full bug report,> >with preprocessed source if appropriate.> >See for instructions.> >new source -> compiling Cstddef.i3> >Cstddef.i3: In function 'Cstddef_I3':> >Cstddef.i3:14: internal compiler error: Segmentation fault> >Please submit a full bug report,> >with preprocessed source if appropriate.> >See for instructions.> >new source -> compiling RTAllocCnts.i3> >RTAllocCnts.i3: In function 'RTAllocCnts_I3':> >RTAllocCnts.i3:22: internal compiler error: Segmentation fault> >Please submit a full bug report,> >with preprocessed source if appropriate.> >See for instructions.> >new source -> compiling RTAllocator.m3> >RTAllocator.m3: In function 'RTAllocator_M3':> >RTAllocator.m3:387: internal compiler error: Segmentation fault> >Please submit a full bug report,> >with preprocessed source if appropriate.> >See for instructions.> >new source -> compiling RTAllocStats.i3> >RTAllocStats.i3: In function 'RTAllocStats_I3':> >RTAllocStats.i3:39: internal compiler error: Segmentation fault> >Please submit a full bug report,> >with preprocessed source if appropriate.> >See for instructions.> >new source -> compiling Convert.i3> >Convert.i3: In function 'Convert_I3':> >Convert.i3:111: internal compiler error: Segmentation fault> >Please submit a full bug report,> >with preprocessed source if appropriate.> >See for instructions.> >new source -> compiling TextClass.i3> >TextClass.i3: In function 'TextClass_I3':> >TextClass.i3:46: internal compiler error: Segmentation fault> >Please submit a full bug report,> >with preprocessed source if appropriate.> >See for instructions.> >new source -> compiling Text.i3> >Text.i3: In function 'Text_I3':> >Text.i3:81: internal compiler error: Segmentation fault> >Please submit a full bug report,> >with preprocessed source if appropriate.> >See for instructions.> >new source -> compiling RTProcedureSRC.i3> >RTProcedureSRC.i3: In function 'RTProcedureSRC_I3':> >RTProcedureSRC.i3:28: internal compiler error: Segmentation fault> >Please submit a full bug report,> >with preprocessed source if appropriate.> >See for instructions.> >new source -> compiling Fingerprint.i3> >Fingerprint.i3: In function 'Fingerprint_I3':> >Fingerprint.i3:63: internal compiler error: Segmentation fault> >Please submit a full bug report,> >with preprocessed source if appropriate.> >See for instructions.> >new source -> compiling RTProcedure.i3> >RTProcedure.i3: In function 'RTProcedure_I3':> >RTProcedure.i3:32: internal compiler error: Segmentation fault> >Please submit a full bug report,> >with preprocessed source if appropriate.> >See for instructions.> >new source -> compiling RTStack.i3> >RTStack.i3: In function 'RTStack_I3':> >RTStack.i3:53: internal compiler error: Segmentation fault> >Please submit a full bug report,> >with preprocessed source if appropriate.> >See for instructions.> >new source -> compiling RTAllocStats.m3> >"../src/runtime/common/RTAllocStats.m3", line 46: undefined runtime=20> >symbol !! (RTHooks.AllocateTracedRef)> >> >> >***> >*** runtime error:> >*** Segmentation violation - possible attempt to dereference NIL> >*** pc =3D 0x811e7ff =3D StartCall + 0x19 in ../src/values/Procedure.m=> >3> >***> >> >Aborted (core dumped)> > *** execution of failed ***> >> >> >--=20> >Neels Janosch Hofmeyr> >Software Developer> >> >neels at elego.de> >Public Key: http://binarchy.net/neels/neels.hofmeyr.public.key.asc> >> >elego Software Solutions GmbH http://www.elegosoft.com> >Gustav-Meyer-Allee 25, Geb=C3=A4ude 12 HRB 77719> >13355 Berlin, Germany Amtsgericht Charlottenburg> >Tel.: +49 30 23 45 86 96 Sitz der Gesellschaft: Berlin> >Fax: +49 30 23 45 86 95 Gesch=C3=A4ftsf=C3=BChrer: Olaf W=> >agner> >> >> >> >--------------enigBBB9AF364E0AAD943688858C> >Content-Type: application/pgp-signature; name="signature.asc"> >Content-Description: OpenPGP digital signature> >Content-Disposition: attachment; filename="signature.asc"> >> >-----BEGIN PGP SIGNATURE-----> >Version: GnuPG v1.4.6 (GNU/Linux)> >> >iD8DBQFHmJbkRpHEG7B8Y+ARAtjGAJ47SAvF3xSFUuQT0gd5ZF2OLbOX9wCg12+B> >bD8Jx13qOgK+5OasBdztrYg=> >=IPcA> >-----END PGP SIGNATURE-----> >> >--------------enigBBB9AF364E0AAD943688858C-- _________________________________________________________________ Shed those extra pounds with MSN and The Biggest Loser! http://biggestloser.msn.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From neels at elego.de Thu Jan 24 22:09:47 2008 From: neels at elego.de (Neels Janosch Hofmeyr) Date: Thu, 24 Jan 2008 22:09:47 +0100 Subject: [M3devel] segmentation fault upon ./install-cm3-compiler.sh upgrade Message-ID: <4798FE9B.1090204@elego.de> Hi lists, I am trying to install cm3 5.4.0 on Ubuntu 7.10. I know that it worked on 7.4, and am doing the exact same steps. I have now tried it with cm3-min-...-5.4.0, just as I did last year. But now, I get this output: neels at oubantu:~/cm3-build/scripts $ ./install-cm3-compiler.sh upgrade cp /usr/local/cm3/bin/cm3 /usr/local/cm3/bin/cm3-5.4.0 cp /usr/local/cm3/bin/cm3cg /usr/local/cm3/bin/cm3cg-5.4.0 Segmentation fault (core dumped) cp /home/neels/cm3-build/m3-sys/cm3/LINUXLIBC6/cm3 /usr/local/cm3/bin/cm3- cp /home/neels/cm3-build/m3-sys/m3cc/LINUXLIBC6/cm3cg /usr/local/cm3/bin/cm3cg- cp /usr/local/cm3/bin/cm3- /usr/local/cm3/bin/cm3 cp /usr/local/cm3/bin/cm3cg- /usr/local/cm3/bin/cm3cg I have done this a second time, making sure everything is cleaned out and monitored things. From adding a `set -x' in the install-cm3-compiler.sh, it becomes obvious that `/usr/local/cm3/bin/cm3 -version' exits with a Segmentation Fault. After doing ./cminstall (the minimal binary install), cm3 -version said $ /usr/local/cm3/bin/cm3 -version Critical Mass Modula-3 version 5.4.0 last updated: 2006-10-11 configuration: /usr/local/cm3/bin/cm3.cfg After doing ./do-cm3-core.sh buildship, it still said the same. So, somewhere in install-cm3-compiler.sh, a disfunctional cm3 binary gets installed in /usr/local/cm3/bin/, after which cm3 yields only segmentation faults. After install-cm3-compiler.sh, cm3 -version says $ /usr/local/cm3/bin/cm3 -version *** *** runtime error: *** Segmentation violation - possible attempt to dereference NIL *** pc = 0x9e841069 *** Aborted (core dumped) Trying to backtrace in gdb apparently doesn't work -- I don't know how to compile debugging symbols into it. Giving up. I think now is the time to remove the statement "[cm3 is] easy-to-use [and] easy-to-install" from modula3.elegosoft.com. No piece of software I have ever encountered is as difficult to use and as impossible to install as critical mass modula3. I *am* following all the instructions! argh, Neels -- Neels Janosch Hofmeyr Software Developer neels at elego.de Public Key: http://binarchy.net/neels/neels.hofmeyr.public.key.asc elego Software Solutions GmbH http://www.elegosoft.com Gustav-Meyer-Allee 25, Geb?ude 12 HRB 77719 13355 Berlin, Germany Amtsgericht Charlottenburg Tel.: +49 30 23 45 86 96 Sitz der Gesellschaft: Berlin Fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Olaf Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From neels at elego.de Thu Jan 24 22:23:13 2008 From: neels at elego.de (Neels Janosch Hofmeyr) Date: Thu, 24 Jan 2008 22:23:13 +0100 Subject: [M3devel] minimal binary d5.5.0 fails on Ubuntu 7.10 In-Reply-To: <200801241441.m0OEfo13084214@camembert.async.caltech.edu> References: <200801241441.m0OEfo13084214@camembert.async.caltech.edu> Message-ID: <479901C1.5060208@elego.de> Well, back to trying cm3-min-POSIX-LINUXLIBC6-d5.5.0.tgz, I tried Mikas suggestion ("Search for -g in cm3.cfg and replace it with -gstabs+"), after which I get the following output: $ ./do-cm3-core.sh buildship CM3C = /home/neels/cm3-build/scripts/pkgmap.sh -c "cm3 -build -DROOT='/home/neels/cm3-build' && cm3 -ship -DROOT='/home/neels/cm3-build' " m3gc-simple m3core libm3 patternmatching m3middle m3linker m3front m3quake m3cc cm3 m3scanner m3tools m3cgcat m3cggen m3bundle bitvector digraph parseparams realgeometry set slisp sortedtableextras table-list tempfiles === package /home/neels/cm3-build/m3-libs/m3gc-simple === +++ cm3 -build -DROOT='/home/neels/cm3-build' && cm3 -ship -DROOT='/home/neels/cm3-build' +++ --- building in LINUXLIBC6 --- new source -> compiling sysdeps.c -> archiving libm3gcdefs.a --- shipping from LINUXLIBC6 --- . => /usr/local/cm3/pkg/m3gc-simple/LINUXLIBC6 .M3EXPORTS libm3gcdefs.so.5 libm3gcdefs.a libm3gcdefs.m3x .M3WEB ../src/runtime => /usr/local/cm3/pkg/m3gc-simple/src/runtime RTVM.c ../src/runtime/LINUXLIBC6 => /usr/local/cm3/pkg/m3gc-simple/src/runtime/LINUXLIBC6 sysdeps.c . => /usr/local/cm3/lib libm3gcdefs.a ==> /home/neels/cm3-build/m3-libs/m3gc-simple done === package /home/neels/cm3-build/m3-libs/m3core === +++ cm3 -build -DROOT='/home/neels/cm3-build' && cm3 -ship -DROOT='/home/neels/cm3-build' +++ --- building in LINUXLIBC6 --- ignoring ../src/m3overrides new source -> compiling RTHooks.i3 new source -> compiling RT0.i3 new source -> compiling RuntimeError.i3 new source -> compiling Word.i3 new source -> compiling RTException.i3 new source -> compiling RTHooks.m3 new source -> compiling RT0.m3 new source -> compiling Compiler.i3 new source -> compiling RuntimeError.m3 new source -> compiling Compiler.m3 new source -> compiling RTAllocator.i3 new source -> compiling RTType.i3 new source -> compiling Uucontext.i3 new source -> compiling Utypes.i3 new source -> compiling BasicCtypes.i3 new source -> compiling Ctypes.i3 new source -> compiling Usignal.i3 new source -> compiling Csetjmp.i3 new source -> compiling RTMachine.i3 new source -> compiling Upthread.i3 new source -> compiling Utime.i3 new source -> compiling RTHeapDep.i3 new source -> compiling RTHeapRep.i3 new source -> compiling Thread.i3 new source -> compiling FloatMode.i3 new source -> compiling ThreadF.i3 new source -> compiling RTOS.i3 new source -> compiling RTMisc.i3 new source -> compiling RTHeap.i3 new source -> compiling Cstdlib.i3 new source -> compiling Cstddef.i3 new source -> compiling RTAllocCnts.i3 new source -> compiling RTAllocator.m3 new source -> compiling RTAllocStats.i3 new source -> compiling Convert.i3 new source -> compiling TextClass.i3 new source -> compiling Text.i3 new source -> compiling RTProcedureSRC.i3 new source -> compiling Fingerprint.i3 new source -> compiling RTProcedure.i3 new source -> compiling RTStack.i3 new source -> compiling RTAllocStats.m3 "../src/runtime/common/RTAllocStats.m3", line 46: undefined runtime symbol !! (RTHooks.AllocateTracedRef) *** *** runtime error: *** Segmentation violation - possible attempt to dereference NIL *** pc = 0x811e7ff = StartCall + 0x19 in ../src/values/Procedure.m3 *** Aborted (core dumped) *** execution of failed *** It looks a little better, but still doesn't work. Any more ideas? Mika Nystrom wrote: > I think this is the broken cm3.cfg . > > Search for -g in cm3.cfg and replace it with -gstabs+ > > This thing bites a lot! I think it got me twice to the extent that > I had to ask this mailing list. Several other times that it had > me scratching my head and then thinking "oh it's that cm3.cfg thing > again..." > > cm3.cfg in general is pretty weird. I know the compiler looks > in at least two places for it. (Undocumented behavior.) > > Mika > > Neels Janosch Hofmeyr writes: > >> This is an OpenPGP/MIME signed message (RFC 2440 and 3156) >> --------------enigBBB9AF364E0AAD943688858C >> Content-Type: text/plain; charset=UTF-8; format=flowed >> Content-Transfer-Encoding: quoted-printable >> >> Hello m3-support and m3devel, >> >> I tried to bootstrap cm3 on Ubuntu 7.10 using the newer d5.5.0 binaries. = >> >> Upon running >> cd scripts >> ./do-cm3-core.sh buildship >> >> I got a series of errors, ending in a segmentation fault. I am now going = >> >> back to the 5.4.0 minimal binary. For interest, find the error output bel= >> ow. >> >> Regards, >> Neels >> >> >> neels at oubantu:~/cm3-build/scripts >> $ ./do-cm3-core.sh buildship >> CM3C =3D >> /home/neels/cm3-build/scripts/pkgmap.sh -c "cm3 -build =20 >> -DROOT=3D'/home/neels/cm3-build' && cm3 -ship=20 >> -DROOT=3D'/home/neels/cm3-build' " m3gc-simple m3core libm3=20 >> patternmatching m3middle m3linker m3front m3quake m3cc cm3 m3scanner=20 >> m3tools m3cgcat m3cggen m3bundle bitvector digraph parseparams=20 >> realgeometry set slisp sortedtableextras table-list tempfiles >> =3D=3D=3D package /home/neels/cm3-build/m3-libs/m3gc-simple =3D=3D=3D >> +++ cm3 -build -DROOT=3D'/home/neels/cm3-build' && cm3 -ship=20 >> -DROOT=3D'/home/neels/cm3-build' +++ >> --- building in LINUXLIBC6 --- >> >> new source -> compiling sysdeps.c >> -> archiving libm3gcdefs.a >> --- shipping from LINUXLIBC6 --- >> >> =2E =3D> /usr/local/cm3/pkg/m3gc-simple/LINUXLIBC6 >> .M3EXPORTS libm3gcdefs.so.5 libm3gcdefs.a libm3gcdefs.m3x >> .M3WEB =20 >> =2E./src/runtime =3D> /usr/local/cm3/pkg/m3gc-simple/src/runtime >> RTVM.c =20 >> =2E./src/runtime/LINUXLIBC6 =3D>=20 >> /usr/local/cm3/pkg/m3gc-simple/src/runtime/LINUXLIBC6 >> sysdeps.c =20 >> =2E =3D> /usr/local/cm3/lib >> libm3gcdefs.a =20 >> =3D=3D> /home/neels/cm3-build/m3-libs/m3gc-simple done >> >> =3D=3D=3D package /home/neels/cm3-build/m3-libs/m3core =3D=3D=3D >> +++ cm3 -build -DROOT=3D'/home/neels/cm3-build' && cm3 -ship=20 >> -DROOT=3D'/home/neels/cm3-build' +++ >> --- building in LINUXLIBC6 --- >> >> ignoring ../src/m3overrides >> >> new source -> compiling RTHooks.i3 >> RTHooks.i3: In function 'RTHooks_I3': >> RTHooks.i3:141: internal compiler error: Segmentation fault >> Please submit a full bug report, >> with preprocessed source if appropriate. >> See for instructions. >> new source -> compiling RT0.i3 >> RT0.i3: In function 'RT0_I3': >> RT0.i3:230: internal compiler error: Segmentation fault >> Please submit a full bug report, >> with preprocessed source if appropriate. >> See for instructions. >> new source -> compiling RuntimeError.i3 >> RuntimeError.i3: In function 'RuntimeError_I3': >> RuntimeError.i3:63: internal compiler error: Segmentation fault >> Please submit a full bug report, >> with preprocessed source if appropriate. >> See for instructions. >> new source -> compiling Word.i3 >> Word.i3: In function 'Word_I3': >> Word.i3:67: internal compiler error: Segmentation fault >> Please submit a full bug report, >> with preprocessed source if appropriate. >> See for instructions. >> new source -> compiling RTException.i3 >> RTException.i3: In function 'RTException_I3': >> RTException.i3:34: internal compiler error: Segmentation fault >> Please submit a full bug report, >> with preprocessed source if appropriate. >> See for instructions. >> new source -> compiling RTHooks.m3 >> RTHooks.m3: In function 'RTHooks_M3': >> RTHooks.m3:130: internal compiler error: Segmentation fault >> Please submit a full bug report, >> with preprocessed source if appropriate. >> See for instructions. >> new source -> compiling RT0.m3 >> RT0.m3:10: internal compiler error: Segmentation fault >> Please submit a full bug report, >> with preprocessed source if appropriate. >> See for instructions. >> new source -> compiling Compiler.i3 >> Compiler.i3: In function 'Compiler_I3': >> Compiler.i3:42: internal compiler error: Segmentation fault >> Please submit a full bug report, >> with preprocessed source if appropriate. >> See for instructions. >> new source -> compiling RuntimeError.m3 >> RuntimeError.m3: In function 'RuntimeError_M3': >> RuntimeError.m3:61: internal compiler error: Segmentation fault >> Please submit a full bug report, >> with preprocessed source if appropriate. >> See for instructions. >> new source -> compiling Compiler.m3 >> Compiler.m3: In function 'Compiler_M3': >> Compiler.m3:11: internal compiler error: Segmentation fault >> Please submit a full bug report, >> with preprocessed source if appropriate. >> See for instructions. >> new source -> compiling RTAllocator.i3 >> RTAllocator.i3: In function 'RTAllocator_I3': >> RTAllocator.i3:79: internal compiler error: Segmentation fault >> Please submit a full bug report, >> with preprocessed source if appropriate. >> See for instructions. >> new source -> compiling RTType.i3 >> RTType.i3: In function 'RTType_I3': >> RTType.i3:65: internal compiler error: Segmentation fault >> Please submit a full bug report, >> with preprocessed source if appropriate. >> See for instructions. >> new source -> compiling Uucontext.i3 >> Uucontext.i3: In function 'Uucontext_I3': >> Uucontext.i3:195: internal compiler error: Segmentation fault >> Please submit a full bug report, >> with preprocessed source if appropriate. >> See for instructions. >> new source -> compiling Utypes.i3 >> Utypes.i3: In function 'Utypes_I3': >> Utypes.i3:108: internal compiler error: Segmentation fault >> Please submit a full bug report, >> with preprocessed source if appropriate. >> See for instructions. >> new source -> compiling BasicCtypes.i3 >> BasicCtypes.i3: In function 'BasicCtypes_I3': >> BasicCtypes.i3:33: internal compiler error: Segmentation fault >> Please submit a full bug report, >> with preprocessed source if appropriate. >> See for instructions. >> new source -> compiling Ctypes.i3 >> > Ctypes.i3: In function 'Ctypes_I3': > >> Ctypes.i3:67: internal compiler error: Segmentation fault >> Please submit a full bug report, >> with preprocessed source if appropriate. >> See for instructions. >> new source -> compiling Usignal.i3 >> Usignal.i3: In function 'Usignal_I3': >> Usignal.i3:199: internal compiler error: Segmentation fault >> Please submit a full bug report, >> with preprocessed source if appropriate. >> See for instructions. >> new source -> compiling Csetjmp.i3 >> Csetjmp.i3: In function 'Csetjmp_I3': >> Csetjmp.i3:29: internal compiler error: Segmentation fault >> Please submit a full bug report, >> with preprocessed source if appropriate. >> See for instructions. >> new source -> compiling RTMachine.i3 >> RTMachine.i3: In function 'RTMachine_I3': >> RTMachine.i3:87: internal compiler error: Segmentation fault >> Please submit a full bug report, >> with preprocessed source if appropriate. >> See for instructions. >> new source -> compiling Upthread.i3 >> Upthread.i3: In function 'Upthread_I3': >> Upthread.i3:343: internal compiler error: Segmentation fault >> Please submit a full bug report, >> with preprocessed source if appropriate. >> See for instructions. >> new source -> compiling Utime.i3 >> Utime.i3: In function 'Utime_I3': >> Utime.i3:182: internal compiler error: Segmentation fault >> Please submit a full bug report, >> with preprocessed source if appropriate. >> See for instructions. >> new source -> compiling RTHeapDep.i3 >> RTHeapDep.i3: In function 'RTHeapDep_I3': >> RTHeapDep.i3:74: internal compiler error: Segmentation fault >> Please submit a full bug report, >> with preprocessed source if appropriate. >> See for instructions. >> new source -> compiling RTHeapRep.i3 >> RTHeapRep.i3: In function 'RTHeapRep_I3': >> RTHeapRep.i3:310: internal compiler error: Segmentation fault >> Please submit a full bug report, >> with preprocessed source if appropriate. >> See for instructions. >> new source -> compiling Thread.i3 >> Thread.i3: In function 'Thread_I3': >> Thread.i3:120: internal compiler error: Segmentation fault >> Please submit a full bug report, >> with preprocessed source if appropriate. >> See for instructions. >> new source -> compiling FloatMode.i3 >> FloatMode.i3: In function 'FloatMode_I3': >> FloatMode.i3:123: internal compiler error: Segmentation fault >> Please submit a full bug report, >> with preprocessed source if appropriate. >> See for instructions. >> new source -> compiling ThreadF.i3 >> ThreadF.i3: In function 'ThreadF_I3': >> ThreadF.i3:110: internal compiler error: Segmentation fault >> Please submit a full bug report, >> with preprocessed source if appropriate. >> See for instructions. >> new source -> compiling RTOS.i3 >> RTOS.i3: In function 'RTOS_I3': >> RTOS.i3:44: internal compiler error: Segmentation fault >> Please submit a full bug report, >> with preprocessed source if appropriate. >> See for instructions. >> new source -> compiling RTMisc.i3 >> RTMisc.i3: In function 'RTMisc_I3': >> RTMisc.i3:29: internal compiler error: Segmentation fault >> Please submit a full bug report, >> with preprocessed source if appropriate. >> See for instructions. >> new source -> compiling RTHeap.i3 >> RTHeap.i3: In function 'RTHeap_I3': >> RTHeap.i3:44: internal compiler error: Segmentation fault >> Please submit a full bug report, >> with preprocessed source if appropriate. >> See for instructions. >> new source -> compiling Cstdlib.i3 >> Cstdlib.i3: In function 'Cstdlib_I3': >> Cstdlib.i3:34: internal compiler error: Segmentation fault >> Please submit a full bug report, >> with preprocessed source if appropriate. >> See for instructions. >> new source -> compiling Cstddef.i3 >> Cstddef.i3: In function 'Cstddef_I3': >> Cstddef.i3:14: internal compiler error: Segmentation fault >> Please submit a full bug report, >> with preprocessed source if appropriate. >> See for instructions. >> new source -> compiling RTAllocCnts.i3 >> RTAllocCnts.i3: In function 'RTAllocCnts_I3': >> RTAllocCnts.i3:22: internal compiler error: Segmentation fault >> Please submit a full bug report, >> with preprocessed source if appropriate. >> See for instructions. >> new source -> compiling RTAllocator.m3 >> RTAllocator.m3: In function 'RTAllocator_M3': >> RTAllocator.m3:387: internal compiler error: Segmentation fault >> Please submit a full bug report, >> with preprocessed source if appropriate. >> See for instructions. >> new source -> compiling RTAllocStats.i3 >> RTAllocStats.i3: In function 'RTAllocStats_I3': >> RTAllocStats.i3:39: internal compiler error: Segmentation fault >> Please submit a full bug report, >> with preprocessed source if appropriate. >> See for instructions. >> new source -> compiling Convert.i3 >> Convert.i3: In function 'Convert_I3': >> Convert.i3:111: internal compiler error: Segmentation fault >> Please submit a full bug report, >> with preprocessed source if appropriate. >> See for instructions. >> new source -> compiling TextClass.i3 >> TextClass.i3: In function 'TextClass_I3': >> TextClass.i3:46: internal compiler error: Segmentation fault >> Please submit a full bug report, >> with preprocessed source if appropriate. >> See for instructions. >> new source -> compiling Text.i3 >> Text.i3: In function 'Text_I3': >> Text.i3:81: internal compiler error: Segmentation fault >> Please submit a full bug report, >> with preprocessed source if appropriate. >> See for instructions. >> new source -> compiling RTProcedureSRC.i3 >> RTProcedureSRC.i3: In function 'RTProcedureSRC_I3': >> RTProcedureSRC.i3:28: internal compiler error: Segmentation fault >> Please submit a full bug report, >> with preprocessed source if appropriate. >> See for instructions. >> new source -> compiling Fingerprint.i3 >> Fingerprint.i3: In function 'Fingerprint_I3': >> Fingerprint.i3:63: internal compiler error: Segmentation fault >> Please submit a full bug report, >> with preprocessed source if appropriate. >> See for instructions. >> new source -> compiling RTProcedure.i3 >> RTProcedure.i3: In function 'RTProcedure_I3': >> RTProcedure.i3:32: internal compiler error: Segmentation fault >> Please submit a full bug report, >> with preprocessed source if appropriate. >> See for instructions. >> new source -> compiling RTStack.i3 >> RTStack.i3: In function 'RTStack_I3': >> RTStack.i3:53: internal compiler error: Segmentation fault >> Please submit a full bug report, >> with preprocessed source if appropriate. >> See for instructions. >> new source -> compiling RTAllocStats.m3 >> "../src/runtime/common/RTAllocStats.m3", line 46: undefined runtime=20 >> symbol !! (RTHooks.AllocateTracedRef) >> >> >> *** >> *** runtime error: >> *** Segmentation violation - possible attempt to dereference NIL >> *** pc =3D 0x811e7ff =3D StartCall + 0x19 in ../src/values/Procedure.m= >> 3 >> *** >> >> Aborted (core dumped) >> *** execution of failed *** >> >> >> --=20 >> Neels Janosch Hofmeyr >> Software Developer >> >> neels at elego.de >> Public Key: http://binarchy.net/neels/neels.hofmeyr.public.key.asc >> >> elego Software Solutions GmbH http://www.elegosoft.com >> Gustav-Meyer-Allee 25, Geb=C3=A4ude 12 HRB 77719 >> 13355 Berlin, Germany Amtsgericht Charlottenburg >> Tel.: +49 30 23 45 86 96 Sitz der Gesellschaft: Berlin >> Fax: +49 30 23 45 86 95 Gesch=C3=A4ftsf=C3=BChrer: Olaf W= >> agner >> >> >> >> --------------enigBBB9AF364E0AAD943688858C >> Content-Type: application/pgp-signature; name="signature.asc" >> Content-Description: OpenPGP digital signature >> Content-Disposition: attachment; filename="signature.asc" >> >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG v1.4.6 (GNU/Linux) >> >> iD8DBQFHmJbkRpHEG7B8Y+ARAtjGAJ47SAvF3xSFUuQT0gd5ZF2OLbOX9wCg12+B >> bD8Jx13qOgK+5OasBdztrYg= >> =IPcA >> -----END PGP SIGNATURE----- >> >> --------------enigBBB9AF364E0AAD943688858C-- >> -- Neels Janosch Hofmeyr Software Developer neels at elego.de Public Key: http://binarchy.net/neels/neels.hofmeyr.public.key.asc elego Software Solutions GmbH http://www.elegosoft.com Gustav-Meyer-Allee 25, Geb?ude 12 HRB 77719 13355 Berlin, Germany Amtsgericht Charlottenburg Tel.: +49 30 23 45 86 96 Sitz der Gesellschaft: Berlin Fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Olaf Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From neels at elego.de Thu Jan 24 22:40:24 2008 From: neels at elego.de (Neels Janosch Hofmeyr) Date: Thu, 24 Jan 2008 22:40:24 +0100 Subject: [M3devel] segmentation fault upon ./install-cm3-compiler.sh upgrade In-Reply-To: <4798FE9B.1090204@elego.de> References: <4798FE9B.1090204@elego.de> Message-ID: <479905C8.7080003@elego.de> btw, I am using the "stable release" source tarballs with the 5.4.0 minimal binary as available on the download page. http://modula3.elegosoft.com/cm3/cm3-min-POSIX-LINUXLIBC6-5.4.0.tgz http://modula3.elegosoft.com/cm3/cm3-src-sys-5.4.0.tgz http://modula3.elegosoft.com/cm3/cm3-src-gnu-5.4.0.tgz http://modula3.elegosoft.com/cm3/cm3-src-std-5.4.0.tgz Neels Janosch Hofmeyr wrote: > Hi lists, > > I am trying to install cm3 5.4.0 on Ubuntu 7.10. I know that it worked > on 7.4, and am doing the exact same steps. I have now tried it with > cm3-min-...-5.4.0, just as I did last year. > > But now, I get this output: > > neels at oubantu:~/cm3-build/scripts > $ ./install-cm3-compiler.sh upgrade > cp /usr/local/cm3/bin/cm3 /usr/local/cm3/bin/cm3-5.4.0 > cp /usr/local/cm3/bin/cm3cg /usr/local/cm3/bin/cm3cg-5.4.0 > Segmentation fault (core dumped) > cp /home/neels/cm3-build/m3-sys/cm3/LINUXLIBC6/cm3 > /usr/local/cm3/bin/cm3- > cp /home/neels/cm3-build/m3-sys/m3cc/LINUXLIBC6/cm3cg > /usr/local/cm3/bin/cm3cg- > cp /usr/local/cm3/bin/cm3- /usr/local/cm3/bin/cm3 > cp /usr/local/cm3/bin/cm3cg- /usr/local/cm3/bin/cm3cg > > I have done this a second time, making sure everything is cleaned out > and monitored things. From adding a `set -x' in the > install-cm3-compiler.sh, it becomes obvious that > `/usr/local/cm3/bin/cm3 -version' exits with a Segmentation Fault. > > After doing ./cminstall (the minimal binary install), cm3 -version said > $ /usr/local/cm3/bin/cm3 -version > Critical Mass Modula-3 version 5.4.0 > last updated: 2006-10-11 > configuration: /usr/local/cm3/bin/cm3.cfg > > After doing ./do-cm3-core.sh buildship, it still said the same. > So, somewhere in install-cm3-compiler.sh, a disfunctional cm3 binary > gets installed in /usr/local/cm3/bin/, after which cm3 yields only > segmentation faults. > > After install-cm3-compiler.sh, cm3 -version says > $ /usr/local/cm3/bin/cm3 -version > > > *** > *** runtime error: > *** Segmentation violation - possible attempt to dereference NIL > *** pc = 0x9e841069 > *** > > Aborted (core dumped) > > Trying to backtrace in gdb apparently doesn't work -- I don't know how > to compile debugging symbols into it. Giving up. > > I think now is the time to remove the statement "[cm3 is] easy-to-use > [and] easy-to-install" from modula3.elegosoft.com. No piece of > software I have ever encountered is as difficult to use and as > impossible to install as critical mass modula3. I *am* following all > the instructions! > > argh, > Neels > -- Neels Janosch Hofmeyr Software Developer neels at elego.de Public Key: http://binarchy.net/neels/neels.hofmeyr.public.key.asc elego Software Solutions GmbH http://www.elegosoft.com Gustav-Meyer-Allee 25, Geb?ude 12 HRB 77719 13355 Berlin, Germany Amtsgericht Charlottenburg Tel.: +49 30 23 45 86 96 Sitz der Gesellschaft: Berlin Fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Olaf Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From jayk123 at hotmail.com Thu Jan 24 22:48:17 2008 From: jayk123 at hotmail.com (Jay) Date: Thu, 24 Jan 2008 21:48:17 +0000 Subject: [M3devel] segmentation fault upon ./install-cm3-compiler.sh upgrade In-Reply-To: <479905C8.7080003@elego.de> References: <4798FE9B.1090204@elego.de> <479905C8.7080003@elego.de> Message-ID: Personally I would try checking out the current tree. And I thought there was a 5.5.x build to start from. I'd try it. And if the existing binaries don't have symbols, and you can't build the system, find a system you can build or cross build from and get symbols in there and then debug it here. Symbols can be very valuable and I have mixed thoughts on stripped binaries. Maybe I'll get around to running this x86 Linux stuff in a virtual or physical machine sometime soon. Hopefully this gets solved before I resort to it. - Jay > Date: Thu, 24 Jan 2008 22:40:24 +0100> From: neels at elego.de> To: m3devel at elego.de; m3-support at elego.de> Subject: Re: [M3devel] segmentation fault upon ./install-cm3-compiler.sh upgrade> > btw, I am using the "stable release" source tarballs with the 5.4.0 > minimal binary as available on the download page.> http://modula3.elegosoft.com/cm3/cm3-min-POSIX-LINUXLIBC6-5.4.0.tgz> http://modula3.elegosoft.com/cm3/cm3-src-sys-5.4.0.tgz> http://modula3.elegosoft.com/cm3/cm3-src-gnu-5.4.0.tgz> http://modula3.elegosoft.com/cm3/cm3-src-std-5.4.0.tgz> > Neels Janosch Hofmeyr wrote:> > Hi lists,> >> > I am trying to install cm3 5.4.0 on Ubuntu 7.10. I know that it worked > > on 7.4, and am doing the exact same steps. I have now tried it with > > cm3-min-...-5.4.0, just as I did last year.> >> > But now, I get this output:> >> > neels at oubantu:~/cm3-build/scripts> > $ ./install-cm3-compiler.sh upgrade> > cp /usr/local/cm3/bin/cm3 /usr/local/cm3/bin/cm3-5.4.0> > cp /usr/local/cm3/bin/cm3cg /usr/local/cm3/bin/cm3cg-5.4.0> > Segmentation fault (core dumped)> > cp /home/neels/cm3-build/m3-sys/cm3/LINUXLIBC6/cm3 > > /usr/local/cm3/bin/cm3-> > cp /home/neels/cm3-build/m3-sys/m3cc/LINUXLIBC6/cm3cg > > /usr/local/cm3/bin/cm3cg-> > cp /usr/local/cm3/bin/cm3- /usr/local/cm3/bin/cm3> > cp /usr/local/cm3/bin/cm3cg- /usr/local/cm3/bin/cm3cg> >> > I have done this a second time, making sure everything is cleaned out > > and monitored things. From adding a `set -x' in the > > install-cm3-compiler.sh, it becomes obvious that > > `/usr/local/cm3/bin/cm3 -version' exits with a Segmentation Fault.> >> > After doing ./cminstall (the minimal binary install), cm3 -version said> > $ /usr/local/cm3/bin/cm3 -version> > Critical Mass Modula-3 version 5.4.0> > last updated: 2006-10-11> > configuration: /usr/local/cm3/bin/cm3.cfg> >> > After doing ./do-cm3-core.sh buildship, it still said the same.> > So, somewhere in install-cm3-compiler.sh, a disfunctional cm3 binary > > gets installed in /usr/local/cm3/bin/, after which cm3 yields only > > segmentation faults.> >> > After install-cm3-compiler.sh, cm3 -version says> > $ /usr/local/cm3/bin/cm3 -version> >> >> > ***> > *** runtime error:> > *** Segmentation violation - possible attempt to dereference NIL> > *** pc = 0x9e841069> > ***> >> > Aborted (core dumped)> >> > Trying to backtrace in gdb apparently doesn't work -- I don't know how > > to compile debugging symbols into it. Giving up.> >> > I think now is the time to remove the statement "[cm3 is] easy-to-use > > [and] easy-to-install" from modula3.elegosoft.com. No piece of > > software I have ever encountered is as difficult to use and as > > impossible to install as critical mass modula3. I *am* following all > > the instructions!> >> > argh,> > Neels> >> > -- > Neels Janosch Hofmeyr> Software Developer> > neels at elego.de> Public Key: http://binarchy.net/neels/neels.hofmeyr.public.key.asc> > elego Software Solutions GmbH http://www.elegosoft.com> Gustav-Meyer-Allee 25, Geb?ude 12 HRB 77719> 13355 Berlin, Germany Amtsgericht Charlottenburg> Tel.: +49 30 23 45 86 96 Sitz der Gesellschaft: Berlin> Fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Olaf Wagner> > _________________________________________________________________ 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 neels at elego.de Thu Jan 24 22:59:16 2008 From: neels at elego.de (Neels Janosch Hofmeyr) Date: Thu, 24 Jan 2008 22:59:16 +0100 Subject: [M3devel] segmentation fault upon ./install-cm3-compiler.sh upgrade In-Reply-To: References: <4798FE9B.1090204@elego.de> <479905C8.7080003@elego.de> Message-ID: <47990A34.7070909@elego.de> Jay wrote: > Personally I would try checking out the current tree. that's worth another try... > And I thought there was a 5.5.x build to start from. I'd try it. I have, see my previous mail: "minimal binary d5.5.0 fails on Ubuntu 7.10" > Connect and share in new ways with Windows Live. Get it now! > no thanks. -- Neels Janosch Hofmeyr Software Developer neels at elego.de Public Key: http://binarchy.net/neels/neels.hofmeyr.public.key.asc elego Software Solutions GmbH http://www.elegosoft.com Gustav-Meyer-Allee 25, Geb?ude 12 HRB 77719 13355 Berlin, Germany Amtsgericht Charlottenburg Tel.: +49 30 23 45 86 96 Sitz der Gesellschaft: Berlin Fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Olaf Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From wagner at elegosoft.com Thu Jan 24 23:03:22 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 24 Jan 2008 23:03:22 +0100 Subject: [M3devel] segmentation fault upon ./install-cm3-compiler.sh upgrade In-Reply-To: <479905C8.7080003@elego.de> References: <4798FE9B.1090204@elego.de> <479905C8.7080003@elego.de> Message-ID: <20080124230322.vl12nlls4kosoocs@mail.elegosoft.com> Quoting Neels Janosch Hofmeyr : > btw, I am using the "stable release" source tarballs with the 5.4.0 > minimal binary as available on the download page. > http://modula3.elegosoft.com/cm3/cm3-min-POSIX-LINUXLIBC6-5.4.0.tgz > http://modula3.elegosoft.com/cm3/cm3-src-sys-5.4.0.tgz > http://modula3.elegosoft.com/cm3/cm3-src-gnu-5.4.0.tgz > http://modula3.elegosoft.com/cm3/cm3-src-std-5.4.0.tgz Hi Neels, 5.4.0 is rather old now. I assume Ubuntu has made some incompatible changes to its kernel or C library interfaces that the old cm3 binary cannot cope with. What about trying one the more recent installation archives, like d.5.5.1? Once you have a working cm3 and cm3cg, compiling the rest should be no problem. Stable releases cannot necessarily be expected to run on newer operating systems when the ABI changes, as they don't adapt themselves ;-) Try this, for example: http://modula3.elegosoft.com/cm3/snaps/cm3-min-POSIX-LINUXLIBC6-d5.5.1-2008-01-24-03-35-01.tgz It should also be possible to get a backtrace of the cm3 crash within gdb. There should be debugging symbols in the distributed binaries. What does bt show? If debugging symbols are missing, we've got to fix that. Olaf > Neels Janosch Hofmeyr wrote: >> Hi lists, >> >> I am trying to install cm3 5.4.0 on Ubuntu 7.10. I know that it >> worked on 7.4, and am doing the exact same steps. I have now tried >> it with cm3-min-...-5.4.0, just as I did last year. >> >> But now, I get this output: >> >> neels at oubantu:~/cm3-build/scripts >> $ ./install-cm3-compiler.sh upgrade >> cp /usr/local/cm3/bin/cm3 /usr/local/cm3/bin/cm3-5.4.0 >> cp /usr/local/cm3/bin/cm3cg /usr/local/cm3/bin/cm3cg-5.4.0 >> Segmentation fault (core dumped) >> cp /home/neels/cm3-build/m3-sys/cm3/LINUXLIBC6/cm3 /usr/local/cm3/bin/cm3- >> cp /home/neels/cm3-build/m3-sys/m3cc/LINUXLIBC6/cm3cg >> /usr/local/cm3/bin/cm3cg- >> cp /usr/local/cm3/bin/cm3- /usr/local/cm3/bin/cm3 >> cp /usr/local/cm3/bin/cm3cg- /usr/local/cm3/bin/cm3cg >> >> I have done this a second time, making sure everything is cleaned >> out and monitored things. From adding a `set -x' in the >> install-cm3-compiler.sh, it becomes obvious that >> `/usr/local/cm3/bin/cm3 -version' exits with a Segmentation Fault. >> >> After doing ./cminstall (the minimal binary install), cm3 -version said >> $ /usr/local/cm3/bin/cm3 -version >> Critical Mass Modula-3 version 5.4.0 >> last updated: 2006-10-11 >> configuration: /usr/local/cm3/bin/cm3.cfg >> >> After doing ./do-cm3-core.sh buildship, it still said the same. >> So, somewhere in install-cm3-compiler.sh, a disfunctional cm3 >> binary gets installed in /usr/local/cm3/bin/, after which cm3 >> yields only segmentation faults. >> >> After install-cm3-compiler.sh, cm3 -version says >> $ /usr/local/cm3/bin/cm3 -version >> >> >> *** >> *** runtime error: >> *** Segmentation violation - possible attempt to dereference NIL >> *** pc = 0x9e841069 >> *** >> >> Aborted (core dumped) >> >> Trying to backtrace in gdb apparently doesn't work -- I don't know >> how to compile debugging symbols into it. Giving up. >> >> I think now is the time to remove the statement "[cm3 is] >> easy-to-use [and] easy-to-install" from modula3.elegosoft.com. No >> piece of software I have ever encountered is as difficult to use >> and as impossible to install as critical mass modula3. I *am* >> following all the instructions! >> >> argh, >> Neels >> > > -- > Neels Janosch Hofmeyr > Software Developer > > neels at elego.de > Public Key: http://binarchy.net/neels/neels.hofmeyr.public.key.asc > > elego Software Solutions GmbH http://www.elegosoft.com > Gustav-Meyer-Allee 25, Geb?ude 12 HRB 77719 > 13355 Berlin, Germany Amtsgericht Charlottenburg > Tel.: +49 30 23 45 86 96 Sitz der Gesellschaft: Berlin > Fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Olaf Wagner -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From neels at elego.de Thu Jan 24 23:11:08 2008 From: neels at elego.de (Neels Janosch Hofmeyr) Date: Thu, 24 Jan 2008 23:11:08 +0100 Subject: [M3devel] segmentation fault upon ./install-cm3-compiler.sh upgrade In-Reply-To: <20080124230322.vl12nlls4kosoocs@mail.elegosoft.com> References: <4798FE9B.1090204@elego.de> <479905C8.7080003@elego.de> <20080124230322.vl12nlls4kosoocs@mail.elegosoft.com> Message-ID: <47990CFC.8080609@elego.de> Olaf Wagner wrote: > Quoting Neels Janosch Hofmeyr : > >> btw, I am using the "stable release" source tarballs with the 5.4.0 > > Hi Neels, > > 5.4.0 is rather old now. I assume Ubuntu has made some incompatible > changes to its kernel or C library interfaces that the old cm3 binary > cannot cope with. What about trying one the more recent installation > archives, like d.5.5.1? Once you have a working cm3 and cm3cg, compiling > the rest should be no problem. Stable releases cannot necessarily be > expected to run on newer operating systems when the ABI changes, as they > don't adapt themselves ;-) > > Try this, for example: > > http://modula3.elegosoft.com/cm3/snaps/cm3-min-POSIX-LINUXLIBC6-d5.5.1-2008-01-24-03-35-01.tgz > I'll try it next. btw, I am writing an instructions text for installing on ubuntu 7.10 along the way... > > It should also be possible to get a backtrace of the cm3 crash > within gdb. There should be debugging symbols in the distributed > binaries. What does bt show? I tried bt, it shows nothing: $ gdb /usr/local/cm3/bin/cm3 GNU gdb 6.6-debian Copyright (C) 2006 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i486-linux-gnu"... Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1". (gdb) run -version Starting program: /usr/local/cm3/bin/cm3 -version Program received signal SIGSEGV, Segmentation fault. 0x9e841069 in ?? () (gdb) bt #0 0x9e841069 in ?? () Cannot access memory at address 0xf05fc929 (gdb) > > If debugging symbols are missing, we've got to fix that. Well, that doesn't mean debugging symbols are missing, sometimes this kind of thing happens anyway (right?). > > Olaf > >> Neels Janosch Hofmeyr wrote: >>> Hi lists, >>> >>> I am trying to install cm3 5.4.0 on Ubuntu 7.10. I know that it >>> worked on 7.4, and am doing the exact same steps. I have now tried >>> it with cm3-min-...-5.4.0, just as I did last year. >>> >>> But now, I get this output: >>> >>> neels at oubantu:~/cm3-build/scripts >>> $ ./install-cm3-compiler.sh upgrade >>> cp /usr/local/cm3/bin/cm3 /usr/local/cm3/bin/cm3-5.4.0 >>> cp /usr/local/cm3/bin/cm3cg /usr/local/cm3/bin/cm3cg-5.4.0 >>> Segmentation fault (core dumped) >>> cp /home/neels/cm3-build/m3-sys/cm3/LINUXLIBC6/cm3 >>> /usr/local/cm3/bin/cm3- >>> cp /home/neels/cm3-build/m3-sys/m3cc/LINUXLIBC6/cm3cg >>> /usr/local/cm3/bin/cm3cg- >>> cp /usr/local/cm3/bin/cm3- /usr/local/cm3/bin/cm3 >>> cp /usr/local/cm3/bin/cm3cg- /usr/local/cm3/bin/cm3cg >>> >>> I have done this a second time, making sure everything is cleaned >>> out and monitored things. From adding a `set -x' in the >>> install-cm3-compiler.sh, it becomes obvious that >>> `/usr/local/cm3/bin/cm3 -version' exits with a Segmentation Fault. >>> >>> After doing ./cminstall (the minimal binary install), cm3 -version said >>> $ /usr/local/cm3/bin/cm3 -version >>> Critical Mass Modula-3 version 5.4.0 >>> last updated: 2006-10-11 >>> configuration: /usr/local/cm3/bin/cm3.cfg >>> >>> After doing ./do-cm3-core.sh buildship, it still said the same. >>> So, somewhere in install-cm3-compiler.sh, a disfunctional cm3 >>> binary gets installed in /usr/local/cm3/bin/, after which cm3 >>> yields only segmentation faults. >>> >>> After install-cm3-compiler.sh, cm3 -version says >>> $ /usr/local/cm3/bin/cm3 -version >>> >>> >>> *** >>> *** runtime error: >>> *** Segmentation violation - possible attempt to dereference NIL >>> *** pc = 0x9e841069 >>> *** >>> >>> Aborted (core dumped) >>> >>> Trying to backtrace in gdb apparently doesn't work -- I don't know >>> how to compile debugging symbols into it. Giving up. >>> >>> I think now is the time to remove the statement "[cm3 is] >>> easy-to-use [and] easy-to-install" from modula3.elegosoft.com. No >>> piece of software I have ever encountered is as difficult to use >>> and as impossible to install as critical mass modula3. I *am* >>> following all the instructions! >>> >>> argh, >>> Neels >>> >> >> -- >> Neels Janosch Hofmeyr >> Software Developer >> >> neels at elego.de >> Public Key: http://binarchy.net/neels/neels.hofmeyr.public.key.asc >> >> elego Software Solutions GmbH http://www.elegosoft.com >> Gustav-Meyer-Allee 25, Geb?ude 12 HRB 77719 >> 13355 Berlin, Germany Amtsgericht Charlottenburg >> Tel.: +49 30 23 45 86 96 Sitz der Gesellschaft: Berlin >> Fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Olaf Wagner > > > -- Neels Janosch Hofmeyr Software Developer neels at elego.de Public Key: http://binarchy.net/neels/neels.hofmeyr.public.key.asc elego Software Solutions GmbH http://www.elegosoft.com Gustav-Meyer-Allee 25, Geb?ude 12 HRB 77719 13355 Berlin, Germany Amtsgericht Charlottenburg Tel.: +49 30 23 45 86 96 Sitz der Gesellschaft: Berlin Fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Olaf Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From neels at elego.de Thu Jan 24 23:21:39 2008 From: neels at elego.de (Neels Janosch Hofmeyr) Date: Thu, 24 Jan 2008 23:21:39 +0100 Subject: [M3devel] snapshots checksums are missing Message-ID: <47990F73.3010707@elego.de> btw, on http://modula3.elegosoft.com/cm3/checksums.php3 , I can't find checksums for the daily snapshots. At least not for cm3-min-POSIX-LINUXLIBC6-d5.5.1-2008-01-24-03-35-01.tgz or any other d5.5.1 tarball -- Neels Janosch Hofmeyr Software Developer neels at elego.de Public Key: http://binarchy.net/neels/neels.hofmeyr.public.key.asc elego Software Solutions GmbH http://www.elegosoft.com Gustav-Meyer-Allee 25, Geb?ude 12 HRB 77719 13355 Berlin, Germany Amtsgericht Charlottenburg Tel.: +49 30 23 45 86 96 Sitz der Gesellschaft: Berlin Fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Olaf Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From jayk123 at hotmail.com Thu Jan 24 23:32:08 2008 From: jayk123 at hotmail.com (Jay) Date: Thu, 24 Jan 2008 22:32:08 +0000 Subject: [M3devel] segmentation fault upon ./install-cm3-compiler.sh upgrade In-Reply-To: <47990CFC.8080609@elego.de> References: <4798FE9B.1090204@elego.de> <479905C8.7080003@elego.de> <20080124230322.vl12nlls4kosoocs@mail.elegosoft.com> <47990CFC.8080609@elego.de> Message-ID: > Stable releases cannot necessarily be > expected to run on newer operating systems when the ABI changes, as they > don't adapt themselves ;-) Wow. No stable ABI? What's up with that? I understand that building with current headers/libs might not work on older systems, but building with older headers/libs should almost always work on newer systems, AT LEAST at the ABI level, if not at the exact behavioral level, that's much harder, if there is to be any change or any bug fixes. People get away with the craziest things, like double frees (ok, not in safe Modula-3), only to have newer better heaps be more strict and catch them... > Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1". Is that normal? > Program received signal SIGSEGV, Segmentation fault. > 0x9e841069 in ?? () > (gdb) bt > #0 0x9e841069 in ?? () > Cannot access memory at address 0xf05fc929 > (gdb) If the above is normal..can you break on main? And..I don't know what the name is...a bisection search..for how far it gets before it crashes? You know, either systematically, or at least randomly, step over and step into function calls, if you go to far and it crashes, step into next time instead of step over. > > If debugging symbols are missing, we've got to fix that. Sorry, I was speculating, based mainly on "strip" appear in scripts/*.sh, didn't look if it is used. > Well, that doesn't mean debugging symbols are missing, sometimes this > kind of thing happens anyway (right?). Right. - Jay > Date: Thu, 24 Jan 2008 23:11:08 +0100> From: neels at elego.de> To: wagner at elegosoft.com> CC: m3devel at elego.de; m3-support at elego.de> Subject: Re: [M3devel] segmentation fault upon ./install-cm3-compiler.sh upgrade> > > > Olaf Wagner wrote:> > Quoting Neels Janosch Hofmeyr :> >> >> btw, I am using the "stable release" source tarballs with the 5.4.0> >> > Hi Neels,> >> > 5.4.0 is rather old now. I assume Ubuntu has made some incompatible> > changes to its kernel or C library interfaces that the old cm3 binary> > cannot cope with. What about trying one the more recent installation> > archives, like d.5.5.1? Once you have a working cm3 and cm3cg, compiling> > the rest should be no problem. Stable releases cannot necessarily be> > expected to run on newer operating systems when the ABI changes, as they> > don't adapt themselves ;-)> >> > Try this, for example:> >> > http://modula3.elegosoft.com/cm3/snaps/cm3-min-POSIX-LINUXLIBC6-d5.5.1-2008-01-24-03-35-01.tgz > >> I'll try it next.> btw, I am writing an instructions text for installing on ubuntu 7.10 > along the way...> >> > It should also be possible to get a backtrace of the cm3 crash> > within gdb. There should be debugging symbols in the distributed> > binaries. What does bt show?> I tried bt, it shows nothing:> > $ gdb /usr/local/cm3/bin/cm3> GNU gdb 6.6-debian> Copyright (C) 2006 Free Software Foundation, Inc.> GDB is free software, covered by the GNU General Public License, and you are> welcome to change it and/or distribute copies of it under certain > conditions.> Type "show copying" to see the conditions.> There is absolutely no warranty for GDB. Type "show warranty" for details.> This GDB was configured as "i486-linux-gnu"...> Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1".> (gdb) run -version> Starting program: /usr/local/cm3/bin/cm3 -version> > Program received signal SIGSEGV, Segmentation fault.> 0x9e841069 in ?? ()> (gdb) bt> #0 0x9e841069 in ?? ()> Cannot access memory at address 0xf05fc929> (gdb)> > >> > If debugging symbols are missing, we've got to fix that.> Well, that doesn't mean debugging symbols are missing, sometimes this > kind of thing happens anyway (right?).> >> > Olaf> >> >> Neels Janosch Hofmeyr wrote:> >>> Hi lists,> >>>> >>> I am trying to install cm3 5.4.0 on Ubuntu 7.10. I know that it > >>> worked on 7.4, and am doing the exact same steps. I have now tried > >>> it with cm3-min-...-5.4.0, just as I did last year.> >>>> >>> But now, I get this output:> >>>> >>> neels at oubantu:~/cm3-build/scripts> >>> $ ./install-cm3-compiler.sh upgrade> >>> cp /usr/local/cm3/bin/cm3 /usr/local/cm3/bin/cm3-5.4.0> >>> cp /usr/local/cm3/bin/cm3cg /usr/local/cm3/bin/cm3cg-5.4.0> >>> Segmentation fault (core dumped)> >>> cp /home/neels/cm3-build/m3-sys/cm3/LINUXLIBC6/cm3 > >>> /usr/local/cm3/bin/cm3-> >>> cp /home/neels/cm3-build/m3-sys/m3cc/LINUXLIBC6/cm3cg > >>> /usr/local/cm3/bin/cm3cg-> >>> cp /usr/local/cm3/bin/cm3- /usr/local/cm3/bin/cm3> >>> cp /usr/local/cm3/bin/cm3cg- /usr/local/cm3/bin/cm3cg> >>>> >>> I have done this a second time, making sure everything is cleaned > >>> out and monitored things. From adding a `set -x' in the > >>> install-cm3-compiler.sh, it becomes obvious that > >>> `/usr/local/cm3/bin/cm3 -version' exits with a Segmentation Fault.> >>>> >>> After doing ./cminstall (the minimal binary install), cm3 -version said> >>> $ /usr/local/cm3/bin/cm3 -version> >>> Critical Mass Modula-3 version 5.4.0> >>> last updated: 2006-10-11> >>> configuration: /usr/local/cm3/bin/cm3.cfg> >>>> >>> After doing ./do-cm3-core.sh buildship, it still said the same.> >>> So, somewhere in install-cm3-compiler.sh, a disfunctional cm3 > >>> binary gets installed in /usr/local/cm3/bin/, after which cm3 > >>> yields only segmentation faults.> >>>> >>> After install-cm3-compiler.sh, cm3 -version says> >>> $ /usr/local/cm3/bin/cm3 -version> >>>> >>>> >>> ***> >>> *** runtime error:> >>> *** Segmentation violation - possible attempt to dereference NIL> >>> *** pc = 0x9e841069> >>> ***> >>>> >>> Aborted (core dumped)> >>>> >>> Trying to backtrace in gdb apparently doesn't work -- I don't know > >>> how to compile debugging symbols into it. Giving up.> >>>> >>> I think now is the time to remove the statement "[cm3 is] > >>> easy-to-use [and] easy-to-install" from modula3.elegosoft.com. No > >>> piece of software I have ever encountered is as difficult to use > >>> and as impossible to install as critical mass modula3. I *am* > >>> following all the instructions!> >>>> >>> argh,> >>> Neels> >>>> >>> >> -- > >> Neels Janosch Hofmeyr> >> Software Developer> >>> >> neels at elego.de> >> Public Key: http://binarchy.net/neels/neels.hofmeyr.public.key.asc> >>> >> elego Software Solutions GmbH http://www.elegosoft.com> >> Gustav-Meyer-Allee 25, Geb?ude 12 HRB 77719> >> 13355 Berlin, Germany Amtsgericht Charlottenburg> >> Tel.: +49 30 23 45 86 96 Sitz der Gesellschaft: Berlin> >> Fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Olaf Wagner> >> >> >> > -- > Neels Janosch Hofmeyr> Software Developer> > neels at elego.de> Public Key: http://binarchy.net/neels/neels.hofmeyr.public.key.asc> > elego Software Solutions GmbH http://www.elegosoft.com> Gustav-Meyer-Allee 25, Geb?ude 12 HRB 77719> 13355 Berlin, Germany Amtsgericht Charlottenburg> Tel.: +49 30 23 45 86 96 Sitz der Gesellschaft: Berlin> Fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Olaf Wagner> > _________________________________________________________________ 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 Jan 24 23:35:19 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 24 Jan 2008 23:35:19 +0100 Subject: [M3devel] segmentation fault upon ./install-cm3-compiler.sh upgrade In-Reply-To: <47990CFC.8080609@elego.de> References: <4798FE9B.1090204@elego.de> <479905C8.7080003@elego.de> <20080124230322.vl12nlls4kosoocs@mail.elegosoft.com> <47990CFC.8080609@elego.de> Message-ID: <20080124233519.s3o34cbsmc8kocs8@mail.elegosoft.com> Quoting Neels Janosch Hofmeyr : > Olaf Wagner wrote: >> Quoting Neels Janosch Hofmeyr : >> >>> btw, I am using the "stable release" source tarballs with the 5.4.0 >> >> Hi Neels, >> >> 5.4.0 is rather old now. I assume Ubuntu has made some incompatible >> changes to its kernel or C library interfaces that the old cm3 binary >> cannot cope with. What about trying one the more recent installation >> archives, like d.5.5.1? Once you have a working cm3 and cm3cg, compiling >> the rest should be no problem. Stable releases cannot necessarily be >> expected to run on newer operating systems when the ABI changes, as they >> don't adapt themselves ;-) >> >> Try this, for example: >> >> http://modula3.elegosoft.com/cm3/snaps/cm3-min-POSIX-LINUXLIBC6-d5.5.1-2008-01-24-03-35-01.tgz > I'll try it next. > btw, I am writing an instructions text for installing on ubuntu 7.10 > along the way... >> >> It should also be possible to get a backtrace of the cm3 crash >> within gdb. There should be debugging symbols in the distributed >> binaries. What does bt show? > I tried bt, it shows nothing: > > $ gdb /usr/local/cm3/bin/cm3 > GNU gdb 6.6-debian > Copyright (C) 2006 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and you are > welcome to change it and/or distribute copies of it under certain conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for details. > This GDB was configured as "i486-linux-gnu"... > Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1". > (gdb) run -version > Starting program: /usr/local/cm3/bin/cm3 -version > > Program received signal SIGSEGV, Segmentation fault. > 0x9e841069 in ?? () > (gdb) bt > #0 0x9e841069 in ?? () > Cannot access memory at address 0xf05fc929 > (gdb) Seems to be a random address. My guess would be that Ubuntu now encrypts its jmp_buf data, too, and you are using M3 UTHREADS. Try some runtime arguments to get some more data: @M3debugthreads, @M3nopreemption, @M3novm, @M3nogc Perhaps we get some clues. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Jan 24 23:38:24 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 24 Jan 2008 23:38:24 +0100 Subject: [M3devel] snapshots checksums are missing In-Reply-To: <47990F73.3010707@elego.de> References: <47990F73.3010707@elego.de> Message-ID: <20080124233824.aqrb8ki1kcsww48o@mail.elegosoft.com> Quoting Neels Janosch Hofmeyr : > btw, on > > http://modula3.elegosoft.com/cm3/checksums.php3 > > , I can't find checksums for the daily snapshots. At least not for > > cm3-min-POSIX-LINUXLIBC6-d5.5.1-2008-01-24-03-35-01.tgz > > or any other d5.5.1 tarball There are none so far :-). Are you afraid or is the archive broken? Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From neels at elego.de Thu Jan 24 23:42:11 2008 From: neels at elego.de (Neels Janosch Hofmeyr) Date: Thu, 24 Jan 2008 23:42:11 +0100 Subject: [M3devel] still errors with cm3-min-POSIX-LINUXLIBC6-d5.5.1-2008-01-24-03-35-01 Message-ID: <47991443.2050809@elego.de> Using the cm3-min-POSIX-LINUXLIBC6-d5.5.1-2008-01-24-03-35-01.tgz in conjunction with the 5.4.0 source tarballs, I get, : $ cm3 -version Critical Mass Modula-3 version d5.5.1-2008-01-24-03-35-01 last updated: 2007-12-30 compiled: 2008-01-24 03:54:37 configuration: /usr/local/cm3/bin/cm3.cfg neels at oubantu:~/cm3-build/scripts $ vim ~/cm3-build/m3-libs/m3gc-simple/src/runtime/LINUXLIBC6/sysdeps.c {to remove the asm/ipc.h, as described on the known problems page} neels at oubantu:~/cm3-build/scripts $ ./do-cm3-core.sh buildship CM3C = /home/neels/cm3-build/scripts/pkgmap.sh -c "cm3 -build -DROOT='/home/neels/cm3-build' && cm3 -ship -DROOT='/home/neels/cm3-build' " m3gc-simple m3core libm3 patternmatching m3middle m3linker m3front m3quake m3cc cm3 m3scanner m3tools m3cgcat m3cggen m3bundle bitvector digraph parseparams realgeometry set slisp sortedtableextras table-list tempfiles === package /home/neels/cm3-build/m3-libs/m3gc-simple === +++ cm3 -build -DROOT='/home/neels/cm3-build' && cm3 -ship -DROOT='/home/neels/cm3-build' +++ --- building in LINUXLIBC6 --- new source -> compiling RTVM.c new source -> compiling sysdeps.c -> archiving libm3gcdefs.a --- shipping from LINUXLIBC6 --- . => /usr/local/cm3/pkg/m3gc-simple/LINUXLIBC6 .M3EXPORTS libm3gcdefs.so.5 libm3gcdefs.a libm3gcdefs.m3x .M3WEB ../src/runtime => /usr/local/cm3/pkg/m3gc-simple/src/runtime RTVM.c ../src/runtime/LINUXLIBC6 => /usr/local/cm3/pkg/m3gc-simple/src/runtime/LINUXLIBC6 sysdeps.c . => /usr/local/cm3/lib libm3gcdefs.a ==> /home/neels/cm3-build/m3-libs/m3gc-simple done === package /home/neels/cm3-build/m3-libs/m3core === +++ cm3 -build -DROOT='/home/neels/cm3-build' && cm3 -ship -DROOT='/home/neels/cm3-build' +++ --- building in LINUXLIBC6 --- ignoring ../src/m3overrides new source -> compiling RTHooks.i3 new source -> compiling RT0.i3 new source -> compiling RuntimeError.i3 new source -> compiling Word.i3 new source -> compiling RTException.i3 new source -> compiling RTHooks.m3 new source -> compiling RT0.m3 new source -> compiling Compiler.i3 new source -> compiling RuntimeError.m3 new source -> compiling Compiler.m3 new source -> compiling RTAllocator.i3 new source -> compiling RTType.i3 new source -> compiling Uucontext.i3 new source -> compiling Utypes.i3 new source -> compiling BasicCtypes.i3 new source -> compiling Ctypes.i3 new source -> compiling Usignal.i3 new source -> compiling Csetjmp.i3 new source -> compiling RTMachine.i3 new source -> compiling Upthread.i3 new source -> compiling Utime.i3 new source -> compiling RTHeapDep.i3 new source -> compiling RTHeapRep.i3 new source -> compiling Thread.i3 new source -> compiling FloatMode.i3 new source -> compiling ThreadF.i3 new source -> compiling RTOS.i3 new source -> compiling RTMisc.i3 new source -> compiling RTHeap.i3 new source -> compiling Cstdlib.i3 new source -> compiling Cstddef.i3 new source -> compiling RTAllocCnts.i3 new source -> compiling RTAllocator.m3 new source -> compiling RTAllocStats.i3 new source -> compiling Convert.i3 new source -> compiling TextClass.i3 new source -> compiling Text.i3 new source -> compiling RTProcedureSRC.i3 new source -> compiling Fingerprint.i3 new source -> compiling RTProcedure.i3 new source -> compiling RTStack.i3 new source -> compiling RTAllocStats.m3 "../src/runtime/common/RTAllocStats.m3", line 46: undefined runtime symbol !! (RTHooks.AllocateTracedRef) *** *** runtime error: *** Segmentation violation - possible attempt to dereference NIL *** pc = 0x816f27f = StartCall + 0x19 in ../src/values/Procedure.m3 *** Aborted (core dumped) *** execution of failed *** trying to backtrace yields this: neels at oubantu:~/cm3-build/m3-libs/m3core $ gdb /usr/local/cm3/bin/cm3 GNU gdb 6.6-debian Copyright (C) 2006 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i486-linux-gnu"... (no debugging symbols found) Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1". (gdb) run -build -DROOT='/home/neels/cm3-build' Starting program: /usr/local/cm3/bin/cm3 -build -DROOT='/home/neels/cm3-build' (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) [Thread debugging using libthread_db enabled] [New Thread -1210534224 (LWP 6710)] (no debugging symbols found) [New Thread -1210807408 (LWP 6713)] Program received signal SIG64, Real-time event 64. [Switching to Thread -1210807408 (LWP 6713)] 0xffffe410 in __kernel_vsyscall () (gdb) bt #0 0xffffe410 in __kernel_vsyscall () #1 0xb7ee0676 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/i686/cmov/libpthread.so.0 #2 0x082ac2d0 in ?? () #3 0x08b5c1a0 in ?? () #4 0x08b5c3a8 in ?? () #5 0xb7d48198 in ?? () #6 0x082abeb2 in ?? () #7 0xb7d4a0b0 in ?? () #8 0x082ab578 in ?? () #9 0xb7ede541 in pthread_mutex_lock () from /lib/tls/i686/cmov/libpthread.so.0 #10 0x082ac932 in ?? () #11 0xb7d4a174 in ?? () #12 0xb7d4a0b0 in ?? () #13 0xb7d4a0c0 in ?? () #14 0x00000000 in ?? () (gdb) c Continuing. Program received signal SIG64, Real-time event 64. 0xffffe410 in __kernel_vsyscall () (gdb) c Continuing. --- building in LINUXLIBC6 --- ignoring ../src/m3overrides Program received signal SIG64, Real-time event 64. 0xffffe410 in __kernel_vsyscall () (gdb) c Continuing. Program received signal SIG64, Real-time event 64. 0xffffe410 in __kernel_vsyscall () (gdb) c Continuing. Program received signal SIG64, Real-time event 64. 0xffffe410 in __kernel_vsyscall () (gdb) c Continuing. Program received signal SIG64, Real-time event 64. 0xffffe410 in __kernel_vsyscall () (gdb) c Continuing. Program received signal SIG64, Real-time event 64. 0xffffe410 in __kernel_vsyscall () (gdb) c Continuing. Program received signal SIG64, Real-time event 64. 0xffffe410 in __kernel_vsyscall () (gdb) c Continuing. new source -> compiling RTAllocStats.m3 Program received signal SIG64, Real-time event 64. 0xffffe410 in __kernel_vsyscall () (gdb) c Continuing. Program received signal SIG64, Real-time event 64. 0xffffe410 in __kernel_vsyscall () (gdb) c Continuing. Program received signal SIG64, Real-time event 64. 0xffffe410 in __kernel_vsyscall () (gdb) c Continuing. Program received signal SIG64, Real-time event 64. 0xffffe410 in __kernel_vsyscall () (gdb) c Continuing. "../src/runtime/common/RTAllocStats.m3", line 46: undefined runtime symbol !! (RTHooks.AllocateTracedRef) Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1210534224 (LWP 6710)] 0x0816f27f in ?? () (gdb) c Continuing. *** *** runtime error: *** Segmentation violation - possible attempt to dereference NIL *** pc = 0x816f27f = StartCall + 0x19 in ../src/values/Procedure.m3 *** Program received signal SIGABRT, Aborted. 0xffffe410 in __kernel_vsyscall () (gdb) bt #0 0xffffe410 in __kernel_vsyscall () #1 0xb7db6875 in raise () from /lib/tls/i686/cmov/libc.so.6 #2 0xb7db8201 in abort () from /lib/tls/i686/cmov/libc.so.6 #3 0x082a8daf in ?? () #4 0x080159a4 in ?? () #5 0x082d31a4 in ?? () #6 0xbfe7f578 in ?? () #7 0x0829e3c4 in ?? () #8 0x0000004d in ?? () #9 0x082d31a4 in ?? () #10 0xbfe7f588 in ?? () #11 0x08298aa1 in ?? () #12 0x01b514e0 in ?? () #13 0x082d31a4 in ?? () #14 0xbfe7f598 in ?? () #15 0x0829bd25 in ?? () #16 0x00000000 in ?? () (gdb) c Continuing. Program terminated with signal SIGABRT, Aborted. The program no longer exists. (gdb) This happens both with "-gstabs+" and "-g" in cm3.cfg (Mikas hint reversed). Next, I'll try to checkout the sources from CVS... if that makes any sense. -- Neels Janosch Hofmeyr Software Developer neels at elego.de Public Key: http://binarchy.net/neels/neels.hofmeyr.public.key.asc elego Software Solutions GmbH http://www.elegosoft.com Gustav-Meyer-Allee 25, Geb?ude 12 HRB 77719 13355 Berlin, Germany Amtsgericht Charlottenburg Tel.: +49 30 23 45 86 96 Sitz der Gesellschaft: Berlin Fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Olaf Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From neels at elego.de Thu Jan 24 23:44:58 2008 From: neels at elego.de (Neels Janosch Hofmeyr) Date: Thu, 24 Jan 2008 23:44:58 +0100 Subject: [M3devel] segmentation fault upon ./install-cm3-compiler.sh upgrade In-Reply-To: <20080124233519.s3o34cbsmc8kocs8@mail.elegosoft.com> References: <4798FE9B.1090204@elego.de> <479905C8.7080003@elego.de> <20080124230322.vl12nlls4kosoocs@mail.elegosoft.com> <47990CFC.8080609@elego.de> <20080124233519.s3o34cbsmc8kocs8@mail.elegosoft.com> Message-ID: <479914EA.3060902@elego.de> Olaf Wagner wrote: > > Try some runtime arguments to get some more data: > @M3debugthreads, @M3nopreemption, @M3novm, @M3nogc Sorry, I don't understand... -- Neels Janosch Hofmeyr Software Developer neels at elego.de Public Key: http://binarchy.net/neels/neels.hofmeyr.public.key.asc elego Software Solutions GmbH http://www.elegosoft.com Gustav-Meyer-Allee 25, Geb?ude 12 HRB 77719 13355 Berlin, Germany Amtsgericht Charlottenburg Tel.: +49 30 23 45 86 96 Sitz der Gesellschaft: Berlin Fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Olaf Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From neels at elego.de Thu Jan 24 23:46:03 2008 From: neels at elego.de (Neels Janosch Hofmeyr) Date: Thu, 24 Jan 2008 23:46:03 +0100 Subject: [M3devel] snapshots checksums are missing In-Reply-To: <20080124233824.aqrb8ki1kcsww48o@mail.elegosoft.com> References: <47990F73.3010707@elego.de> <20080124233824.aqrb8ki1kcsww48o@mail.elegosoft.com> Message-ID: <4799152B.2090906@elego.de> Olaf Wagner wrote: > Quoting Neels Janosch Hofmeyr : > >> btw, on >> >> http://modula3.elegosoft.com/cm3/checksums.php3 >> >> , I can't find checksums for the daily snapshots. At least not for >> >> cm3-min-POSIX-LINUXLIBC6-d5.5.1-2008-01-24-03-35-01.tgz >> >> or any other d5.5.1 tarball > > There are none so far :-). Are you afraid or is the archive broken? No, I'm just including the checksums in the instructions text for completeness. Just wanted to double check... nevermind though. -- Neels Janosch Hofmeyr Software Developer neels at elego.de Public Key: http://binarchy.net/neels/neels.hofmeyr.public.key.asc elego Software Solutions GmbH http://www.elegosoft.com Gustav-Meyer-Allee 25, Geb?ude 12 HRB 77719 13355 Berlin, Germany Amtsgericht Charlottenburg Tel.: +49 30 23 45 86 96 Sitz der Gesellschaft: Berlin Fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Olaf Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From hosking at cs.purdue.edu Thu Jan 24 23:46:31 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 24 Jan 2008 17:46:31 -0500 Subject: [M3devel] segmentation fault upon ./install-cm3-compiler.sh upgrade In-Reply-To: <479914EA.3060902@elego.de> References: <4798FE9B.1090204@elego.de> <479905C8.7080003@elego.de> <20080124230322.vl12nlls4kosoocs@mail.elegosoft.com> <47990CFC.8080609@elego.de> <20080124233519.s3o34cbsmc8kocs8@mail.elegosoft.com> <479914EA.3060902@elego.de> Message-ID: <80025F80-FDA6-4E9D-AC2A-73C6498A6EA0@cs.purdue.edu> I'm pretty sure these problems are a result of needing to use a new bootstrap compiler. On Jan 24, 2008, at 5:44 PM, Neels Janosch Hofmeyr wrote: > > > Olaf Wagner wrote: >> >> Try some runtime arguments to get some more data: >> @M3debugthreads, @M3nopreemption, @M3novm, @M3nogc > Sorry, I don't understand... > > -- > Neels Janosch Hofmeyr > Software Developer > > neels at elego.de > Public Key: http://binarchy.net/neels/neels.hofmeyr.public.key.asc > > elego Software Solutions GmbH http://www.elegosoft.com > Gustav-Meyer-Allee 25, Geb?ude 12 HRB 77719 > 13355 Berlin, Germany Amtsgericht Charlottenburg > Tel.: +49 30 23 45 86 96 Sitz der Gesellschaft: Berlin > Fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Olaf Wagner > > From hosking at cs.purdue.edu Thu Jan 24 23:47:24 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 24 Jan 2008 17:47:24 -0500 Subject: [M3devel] still errors with cm3-min-POSIX-LINUXLIBC6-d5.5.1-2008-01-24-03-35-01 In-Reply-To: <47991443.2050809@elego.de> References: <47991443.2050809@elego.de> Message-ID: <0ABA0093-F7F5-440F-98B7-7AFD4317FAC6@cs.purdue.edu> On Jan 24, 2008, at 5:42 PM, Neels Janosch Hofmeyr wrote: > Using the > cm3-min-POSIX-LINUXLIBC6-d5.5.1-2008-01-24-03-35-01.tgz > in conjunction with the 5.4.0 source tarballs, I get, : > > $ cm3 -version > Critical Mass Modula-3 version d5.5.1-2008-01-24-03-35-01 > last updated: 2007-12-30 > compiled: 2008-01-24 03:54:37 > configuration: /usr/local/cm3/bin/cm3.cfg > > neels at oubantu:~/cm3-build/scripts > $ vim ~/cm3-build/m3-libs/m3gc-simple/src/runtime/LINUXLIBC6/sysdeps.c > {to remove the asm/ipc.h, as described on the known problems page} > > neels at oubantu:~/cm3-build/scripts > $ ./do-cm3-core.sh buildship > CM3C = > /home/neels/cm3-build/scripts/pkgmap.sh -c "cm3 -build -DROOT='/ > home/neels/cm3-build' && cm3 -ship -DROOT='/home/neels/cm3-build' > " m3gc-simple m3core libm3 patternmatching m3middle m3linker > m3front m3quake m3cc cm3 m3scanner m3tools m3cgcat m3cggen m3bundle > bitvector digraph parseparams realgeometry set slisp > sortedtableextras table-list tempfiles > === package /home/neels/cm3-build/m3-libs/m3gc-simple === > +++ cm3 -build -DROOT='/home/neels/cm3-build' && cm3 -ship - > DROOT='/home/neels/cm3-build' +++ > --- building in LINUXLIBC6 --- > > new source -> compiling RTVM.c > new source -> compiling sysdeps.c > -> archiving libm3gcdefs.a > --- shipping from LINUXLIBC6 --- > > . => /usr/local/cm3/pkg/m3gc-simple/LINUXLIBC6 > .M3EXPORTS libm3gcdefs.so.5 libm3gcdefs.a libm3gcdefs.m3x > .M3WEB ../src/runtime => /usr/local/cm3/pkg/m3gc-simple/ > src/runtime > RTVM.c ../src/runtime/LINUXLIBC6 => /usr/local/cm3/pkg/ > m3gc-simple/src/runtime/LINUXLIBC6 > sysdeps.c . => /usr/local/cm3/lib > libm3gcdefs.a ==> /home/neels/cm3-build/m3-libs/m3gc-simple done > > === package /home/neels/cm3-build/m3-libs/m3core === > +++ cm3 -build -DROOT='/home/neels/cm3-build' && cm3 -ship - > DROOT='/home/neels/cm3-build' +++ > --- building in LINUXLIBC6 --- > > ignoring ../src/m3overrides > > new source -> compiling RTHooks.i3 > new source -> compiling RT0.i3 > new source -> compiling RuntimeError.i3 > new source -> compiling Word.i3 > new source -> compiling RTException.i3 > new source -> compiling RTHooks.m3 > new source -> compiling RT0.m3 > new source -> compiling Compiler.i3 > new source -> compiling RuntimeError.m3 > new source -> compiling Compiler.m3 > new source -> compiling RTAllocator.i3 > new source -> compiling RTType.i3 > new source -> compiling Uucontext.i3 > new source -> compiling Utypes.i3 > new source -> compiling BasicCtypes.i3 > new source -> compiling Ctypes.i3 > new source -> compiling Usignal.i3 > new source -> compiling Csetjmp.i3 > new source -> compiling RTMachine.i3 > new source -> compiling Upthread.i3 > new source -> compiling Utime.i3 > new source -> compiling RTHeapDep.i3 > new source -> compiling RTHeapRep.i3 > new source -> compiling Thread.i3 > new source -> compiling FloatMode.i3 > new source -> compiling ThreadF.i3 > new source -> compiling RTOS.i3 > new source -> compiling RTMisc.i3 > new source -> compiling RTHeap.i3 > new source -> compiling Cstdlib.i3 > new source -> compiling Cstddef.i3 > new source -> compiling RTAllocCnts.i3 > new source -> compiling RTAllocator.m3 > new source -> compiling RTAllocStats.i3 > new source -> compiling Convert.i3 > new source -> compiling TextClass.i3 > new source -> compiling Text.i3 > new source -> compiling RTProcedureSRC.i3 > new source -> compiling Fingerprint.i3 > new source -> compiling RTProcedure.i3 > new source -> compiling RTStack.i3 > new source -> compiling RTAllocStats.m3 > "../src/runtime/common/RTAllocStats.m3", line 46: undefined runtime > symbol !! This is a new library function: you need newer sources. > (RTHooks.AllocateTracedRef) > > > *** > *** runtime error: > *** Segmentation violation - possible attempt to dereference NIL > *** pc = 0x816f27f = StartCall + 0x19 in ../src/values/Procedure.m3 > *** > > Aborted (core dumped) > *** execution of failed *** > > > trying to backtrace yields this: > > neels at oubantu:~/cm3-build/m3-libs/m3core > $ gdb /usr/local/cm3/bin/cm3 > GNU gdb 6.6-debian > Copyright (C) 2006 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, > and you are > welcome to change it and/or distribute copies of it under certain > conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for > details. > This GDB was configured as "i486-linux-gnu"... > (no debugging symbols found) > Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so. > 1". > (gdb) run -build -DROOT='/home/neels/cm3-build' > Starting program: /usr/local/cm3/bin/cm3 -build -DROOT='/home/ > neels/cm3-build' > (no debugging symbols found) > (no debugging symbols found) > (no debugging symbols found) > (no debugging symbols found) > [Thread debugging using libthread_db enabled] > [New Thread -1210534224 (LWP 6710)] > (no debugging symbols found) > [New Thread -1210807408 (LWP 6713)] > > Program received signal SIG64, Real-time event 64. > [Switching to Thread -1210807408 (LWP 6713)] > 0xffffe410 in __kernel_vsyscall () > (gdb) bt > #0 0xffffe410 in __kernel_vsyscall () > #1 0xb7ee0676 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/ > i686/cmov/libpthread.so.0 > #2 0x082ac2d0 in ?? () > #3 0x08b5c1a0 in ?? () > #4 0x08b5c3a8 in ?? () > #5 0xb7d48198 in ?? () > #6 0x082abeb2 in ?? () > #7 0xb7d4a0b0 in ?? () > #8 0x082ab578 in ?? () > #9 0xb7ede541 in pthread_mutex_lock () from /lib/tls/i686/cmov/ > libpthread.so.0 > #10 0x082ac932 in ?? () > #11 0xb7d4a174 in ?? () > #12 0xb7d4a0b0 in ?? () > #13 0xb7d4a0c0 in ?? () > #14 0x00000000 in ?? () > (gdb) c > Continuing. > > Program received signal SIG64, Real-time event 64. > 0xffffe410 in __kernel_vsyscall () > (gdb) c > Continuing. > --- building in LINUXLIBC6 --- > > ignoring ../src/m3overrides > > > Program received signal SIG64, Real-time event 64. > 0xffffe410 in __kernel_vsyscall () > (gdb) c > Continuing. > > Program received signal SIG64, Real-time event 64. > 0xffffe410 in __kernel_vsyscall () > (gdb) c > Continuing. > > Program received signal SIG64, Real-time event 64. > 0xffffe410 in __kernel_vsyscall () > (gdb) c > Continuing. > > Program received signal SIG64, Real-time event 64. > 0xffffe410 in __kernel_vsyscall () > (gdb) c > Continuing. > > Program received signal SIG64, Real-time event 64. > 0xffffe410 in __kernel_vsyscall () > (gdb) c > Continuing. > > Program received signal SIG64, Real-time event 64. > 0xffffe410 in __kernel_vsyscall () > (gdb) c > Continuing. > new source -> compiling RTAllocStats.m3 > > Program received signal SIG64, Real-time event 64. > 0xffffe410 in __kernel_vsyscall () > (gdb) c > Continuing. > > Program received signal SIG64, Real-time event 64. > 0xffffe410 in __kernel_vsyscall () > (gdb) c > Continuing. > > Program received signal SIG64, Real-time event 64. > 0xffffe410 in __kernel_vsyscall () > (gdb) c > Continuing. > > Program received signal SIG64, Real-time event 64. > 0xffffe410 in __kernel_vsyscall () > (gdb) c > Continuing. > "../src/runtime/common/RTAllocStats.m3", line 46: undefined runtime > symbol !! (RTHooks.AllocateTracedRef) > > Program received signal SIGSEGV, Segmentation fault. > [Switching to Thread -1210534224 (LWP 6710)] > 0x0816f27f in ?? () > (gdb) c > Continuing. > > > *** > *** runtime error: > *** Segmentation violation - possible attempt to dereference NIL > *** pc = 0x816f27f = StartCall + 0x19 in ../src/values/Procedure.m3 > *** > > > Program received signal SIGABRT, Aborted. > 0xffffe410 in __kernel_vsyscall () > (gdb) bt > #0 0xffffe410 in __kernel_vsyscall () > #1 0xb7db6875 in raise () from /lib/tls/i686/cmov/libc.so.6 > #2 0xb7db8201 in abort () from /lib/tls/i686/cmov/libc.so.6 > #3 0x082a8daf in ?? () > #4 0x080159a4 in ?? () > #5 0x082d31a4 in ?? () > #6 0xbfe7f578 in ?? () > #7 0x0829e3c4 in ?? () > #8 0x0000004d in ?? () > #9 0x082d31a4 in ?? () > #10 0xbfe7f588 in ?? () > #11 0x08298aa1 in ?? () > #12 0x01b514e0 in ?? () > #13 0x082d31a4 in ?? () > #14 0xbfe7f598 in ?? () > #15 0x0829bd25 in ?? () > #16 0x00000000 in ?? () > (gdb) c > Continuing. > > Program terminated with signal SIGABRT, Aborted. > The program no longer exists. > (gdb) > > > This happens both with "-gstabs+" and "-g" in cm3.cfg (Mikas hint > reversed). > > Next, I'll try to checkout the sources from CVS... if that makes > any sense. > > -- > Neels Janosch Hofmeyr > Software Developer > > neels at elego.de > Public Key: http://binarchy.net/neels/neels.hofmeyr.public.key.asc > > elego Software Solutions GmbH http://www.elegosoft.com > Gustav-Meyer-Allee 25, Geb?ude 12 HRB 77719 > 13355 Berlin, Germany Amtsgericht Charlottenburg > Tel.: +49 30 23 45 86 96 Sitz der Gesellschaft: Berlin > Fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Olaf Wagner > > From neels at elego.de Thu Jan 24 23:54:24 2008 From: neels at elego.de (Neels Janosch Hofmeyr) Date: Thu, 24 Jan 2008 23:54:24 +0100 Subject: [M3devel] segmentation fault upon ./install-cm3-compiler.sh upgrade In-Reply-To: <80025F80-FDA6-4E9D-AC2A-73C6498A6EA0@cs.purdue.edu> References: <4798FE9B.1090204@elego.de> <479905C8.7080003@elego.de> <20080124230322.vl12nlls4kosoocs@mail.elegosoft.com> <47990CFC.8080609@elego.de> <20080124233519.s3o34cbsmc8kocs8@mail.elegosoft.com> <479914EA.3060902@elego.de> <80025F80-FDA6-4E9D-AC2A-73C6498A6EA0@cs.purdue.edu> Message-ID: <47991720.1030307@elego.de> Tony Hosking wrote: > I'm pretty sure these problems are a result of needing to use a new > bootstrap compiler. How can I build one from source? (does this question make sense?) -- Neels Janosch Hofmeyr Software Developer neels at elego.de Public Key: http://binarchy.net/neels/neels.hofmeyr.public.key.asc elego Software Solutions GmbH http://www.elegosoft.com Gustav-Meyer-Allee 25, Geb?ude 12 HRB 77719 13355 Berlin, Germany Amtsgericht Charlottenburg Tel.: +49 30 23 45 86 96 Sitz der Gesellschaft: Berlin Fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Olaf Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From neels at elego.de Thu Jan 24 23:57:12 2008 From: neels at elego.de (Neels Janosch Hofmeyr) Date: Thu, 24 Jan 2008 23:57:12 +0100 Subject: [M3devel] still errors with cm3-min-POSIX-LINUXLIBC6-d5.5.1-2008-01-24-03-35-01 In-Reply-To: <0ABA0093-F7F5-440F-98B7-7AFD4317FAC6@cs.purdue.edu> References: <47991443.2050809@elego.de> <0ABA0093-F7F5-440F-98B7-7AFD4317FAC6@cs.purdue.edu> Message-ID: <479917C8.1080106@elego.de> Tony Hosking wrote: >> "../src/runtime/common/RTAllocStats.m3", line 46: undefined runtime >> symbol !! > > This is a new library function: you need newer sources. > This seems to do the trick (checked out from CVS)... waiting for the compile to complete. -- Neels Janosch Hofmeyr Software Developer neels at elego.de Public Key: http://binarchy.net/neels/neels.hofmeyr.public.key.asc elego Software Solutions GmbH http://www.elegosoft.com Gustav-Meyer-Allee 25, Geb?ude 12 HRB 77719 13355 Berlin, Germany Amtsgericht Charlottenburg Tel.: +49 30 23 45 86 96 Sitz der Gesellschaft: Berlin Fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Olaf Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From jayk123 at hotmail.com Fri Jan 25 00:02:48 2008 From: jayk123 at hotmail.com (Jay) Date: Thu, 24 Jan 2008 23:02:48 +0000 Subject: [M3devel] segmentation fault upon ./install-cm3-compiler.sh upgrade In-Reply-To: <47991720.1030307@elego.de> References: <4798FE9B.1090204@elego.de> <479905C8.7080003@elego.de> <20080124230322.vl12nlls4kosoocs@mail.elegosoft.com> <47990CFC.8080609@elego.de> <20080124233519.s3o34cbsmc8kocs8@mail.elegosoft.com> <479914EA.3060902@elego.de> <80025F80-FDA6-4E9D-AC2A-73C6498A6EA0@cs.purdue.edu> <47991720.1030307@elego.de> Message-ID: You do it by building the compiler but not building the runtime, upgrade the compiler, rebuild the runtime, rebuild the compiler again clean, update the compiler again. upgrade.sh does this. The thing about @M3novm, @M3debugwhatever, etc. these are command line switches. The Modula-3 runtime (libm3core.so) looks for them and alters its behavior in various ways. For example @M3vm was needed to debug slightly older runtimes without incurrent kind of bogus faults. Anything starting with "@M3" is considered reserved for libm3core.so. - Jay > Date: Thu, 24 Jan 2008 23:54:24 +0100> From: neels at elego.de> To: hosking at cs.purdue.edu> CC: m3devel at elego.de; m3-support at elego.de> Subject: Re: [M3devel] segmentation fault upon ./install-cm3-compiler.sh upgrade> > > Tony Hosking wrote:> > I'm pretty sure these problems are a result of needing to use a new > > bootstrap compiler.> How can I build one from source? (does this question make sense?)> > -- > Neels Janosch Hofmeyr> Software Developer> > neels at elego.de> Public Key: http://binarchy.net/neels/neels.hofmeyr.public.key.asc> > elego Software Solutions GmbH http://www.elegosoft.com> Gustav-Meyer-Allee 25, Geb?ude 12 HRB 77719> 13355 Berlin, Germany Amtsgericht Charlottenburg> Tel.: +49 30 23 45 86 96 Sitz der Gesellschaft: Berlin> Fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Olaf Wagner> > _________________________________________________________________ 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 Fri Jan 25 00:19:27 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 25 Jan 2008 00:19:27 +0100 Subject: [M3devel] snapshots checksums are missing In-Reply-To: <47990F73.3010707@elego.de> References: <47990F73.3010707@elego.de> Message-ID: <20080125001927.92eud7h544gs0csg@mail.elegosoft.com> Quoting Neels Janosch Hofmeyr : > btw, on > > http://modula3.elegosoft.com/cm3/checksums.php3 > > , I can't find checksums for the daily snapshots. At least not for > > cm3-min-POSIX-LINUXLIBC6-d5.5.1-2008-01-24-03-35-01.tgz > > or any other d5.5.1 tarball Fixed :) Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Fri Jan 25 00:53:48 2008 From: rcoleburn at scires.com (Randy Coleburn) Date: Thu, 24 Jan 2008 18:53:48 -0500 Subject: [M3devel] INSTALL_ROOT and PKG_USE in cm3.cfg Message-ID: <4798DEB8.1E75.00D7.1@scires.com> Jay: The cm3.cfg that comes with your minimal binary installation on Windows (NT386) has the following lines: *---------------------------------------- % INSTALL_ROOT = BEGIN_CONFIG % "Where should CM3 be installed?" % 7 %-- user specified install root % END_CONFIG % INSTALL_ROOT = "c:\\cm3" if not defined("INSTALL_ROOT") if not equal ($INSTALLROOT, "") INSTALL_ROOT = $INSTALLROOT else INSTALL_ROOT = (path() & "\\..") end end BIN_INSTALL = INSTALL_ROOT & "\\bin ( file://\bin )" % executables LIB_INSTALL = INSTALL_ROOT & "\\lib ( file://\lib )" % libraries PKG_INSTALL = INSTALL_ROOT & "\\pkg ( file://\pkg )" % packages DOC_INSTALL = INSTALL_ROOT & "\\doc ( file://\doc )" % documents EMACS_INSTALL = INSTALL_ROOT & "\\elisp ( file://\elisp )" % emacs lisp code MAN_INSTALL = INSTALL_ROOT & "\\man ( file://\man )" % man pages HTML_INSTALL = INSTALL_ROOT & "\\www ( file://\www )" % public hypertext % % On some systems (e.g. AFS) you must install public files in a different % place from where you use them. If that is the case for your system, % specify the "use" location here, otherwise leave them alone. % %USE_ROOT = INSTALL_ROOT BIN_USE = BIN_INSTALL % executables LIB_USE = LIB_INSTALL % libraries PKG_USE = PKG_INSTALL % packages *---------------------------------------- Notice that the lines for INSTALL_ROOT and USE_ROOT are commented out. The Reactor program is coded to grab several variables out of cm3.cfg. For example, build_dir := M3Config.Get ("BUILD_DIR"); system_root := M3Config.Get ("PKG_USE"); doc_root := M3Config.Get ("DOC_INSTALL"); initial_browser := M3Config.Get ("INITIAL_CM3_IDE_BROWSER"); initial_editor := M3Config.Get ("INITIAL_CM3_IDE_EDITOR"); What is happening on my installation is that PKG_USE winds up being "\..\PKG". This is not a valid path and it is causing all sorts of trouble for Reactor. The reason it is getting set this way is that the ELSE branch of the, if not defined("INSTALL_ROOT"), is getting executed resulting in INSTALL_ROOT=\.. I'm not sure why this is coded this way. How do you suggest this should be repaired? Note, I have not checked all of the cm3.cfg variants for the other target platforms, but in order for reactor to work properly, it must be able to find a valid "PKG_USE" in the cm3.cfg. Regards, Randy -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Fri Jan 25 01:24:08 2008 From: jayk123 at hotmail.com (Jay) Date: Fri, 25 Jan 2008 00:24:08 +0000 Subject: [M3devel] INSTALL_ROOT and PKG_USE in cm3.cfg In-Reply-To: <4798DEB8.1E75.00D7.1@scires.com> References: <4798DEB8.1E75.00D7.1@scires.com> Message-ID: Blech. My way is more automatic and "portable" in the sense that you can move installations around and they keep working. As well, with my way, you just extract an archive and go, no setup/cminstall, no editing of the cm3.cfg file, just set %PATH% and run vcvars, and vcvars I think I can remove the need for. path() is a builtin Quake function that returns the directory of the currently being run Quake code. But yet Reactor. To unblock yourself, remove my code, add back the commented out, fix the path to match your particular install, don't submit the file. Perhaps move the current checked in file over to the config-no-install directory and then put config's file back in the old style, that requires running cminstall. My workflow will keep working, since it probes for config-no-install first. - Jay Date: Thu, 24 Jan 2008 18:53:48 -0500From: rcoleburn at scires.comTo: jay123 at hotmail.comCC: m3devel at elegosoft.comSubject: [M3devel] INSTALL_ROOT and PKG_USE in cm3.cfg Jay: The cm3.cfg that comes with your minimal binary installation on Windows (NT386) has the following lines: ----------------------------------------- % INSTALL_ROOT = BEGIN_CONFIG% "Where should CM3 be installed?"% 7 %-- user specified install root% END_CONFIG % INSTALL_ROOT = "c:\\cm3" if not defined("INSTALL_ROOT") if not equal ($INSTALLROOT, "") INSTALL_ROOT = $INSTALLROOT else INSTALL_ROOT = (path() & "\\..") endend BIN_INSTALL = INSTALL_ROOT & "\\bin" % executablesLIB_INSTALL = INSTALL_ROOT & "\\lib" % librariesPKG_INSTALL = INSTALL_ROOT & "\\pkg" % packagesDOC_INSTALL = INSTALL_ROOT & "\\doc" % documentsEMACS_INSTALL = INSTALL_ROOT & "\\elisp" % emacs lisp codeMAN_INSTALL = INSTALL_ROOT & "\\man" % man pagesHTML_INSTALL = INSTALL_ROOT & "\\www" % public hypertext %% On some systems (e.g. AFS) you must install public files in a different% place from where you use them. If that is the case for your system,% specify the "use" location here, otherwise leave them alone.%%USE_ROOT = INSTALL_ROOTBIN_USE = BIN_INSTALL % executablesLIB_USE = LIB_INSTALL % librariesPKG_USE = PKG_INSTALL % packages ----------------------------------------- Notice that the lines for INSTALL_ROOT and USE_ROOT are commented out. The Reactor program is coded to grab several variables out of cm3.cfg. For example, build_dir := M3Config.Get ("BUILD_DIR"); system_root := M3Config.Get ("PKG_USE"); doc_root := M3Config.Get ("DOC_INSTALL"); initial_browser := M3Config.Get ("INITIAL_CM3_IDE_BROWSER"); initial_editor := M3Config.Get ("INITIAL_CM3_IDE_EDITOR"); What is happening on my installation is that PKG_USE winds up being "\..\PKG". This is not a valid path and it is causing all sorts of trouble for Reactor. The reason it is getting set this way is that the ELSE branch of the, if not defined("INSTALL_ROOT"), is getting executed resulting in INSTALL_ROOT=\.. I'm not sure why this is coded this way. How do you suggest this should be repaired? Note, I have not checked all of the cm3.cfg variants for the other target platforms, but in order for reactor to work properly, it must be able to find a valid "PKG_USE" in the cm3.cfg. Regards, Randy _________________________________________________________________ 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 neels at elego.de Fri Jan 25 01:45:22 2008 From: neels at elego.de (Neels Janosch Hofmeyr) Date: Fri, 25 Jan 2008 01:45:22 +0100 Subject: [M3devel] CM3 5.5.1 works on Ubuntu 7.10! Message-ID: <47993122.2030201@elego.de> Thanks Olaf, Tony, Mika and Jay, I have cm3 working on Ubuntu 7.10! Complete instructions are given in the attached file. After all, it _does_ look quite simple. But only once you know how. Please let me know if you have any improvements waiting. I'll check this file into the CVS somewhere. We need to add these instructions to modula3.elegosoft.com, so that others do not take the same "shortcuts" I did. If noone else feels like doing it, I will. But right now, it's way past bedtime. All the best, Neels -- Neels Janosch Hofmeyr Software Developer neels at elego.de Public Key: http://binarchy.net/neels/neels.hofmeyr.public.key.asc elego Software Solutions GmbH http://www.elegosoft.com Gustav-Meyer-Allee 25, Geb?ude 12 HRB 77719 13355 Berlin, Germany Amtsgericht Charlottenburg Tel.: +49 30 23 45 86 96 Sitz der Gesellschaft: Berlin Fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Olaf Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: install-cm3-on-ubuntu-7-10.txt Type: application/vnd.ms-powerpoint Size: 9673 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From neels at elego.de Fri Jan 25 01:55:36 2008 From: neels at elego.de (Neels Janosch Hofmeyr) Date: Fri, 25 Jan 2008 01:55:36 +0100 Subject: [M3devel] CM3 5.5.1 works on Ubuntu 7.10! In-Reply-To: <47993122.2030201@elego.de> References: <47993122.2030201@elego.de> Message-ID: <47993388.9030909@elego.de> Well, I've got a change myself. Some libfoo.a need to be libfoo.so for 5.5.1. Wow, does your mail client also think the attachment is a PowerPoint Document? Well, in fact it's a plain ASCII text file. Neels Janosch Hofmeyr wrote: > Thanks Olaf, Tony, Mika and Jay, I have cm3 working on Ubuntu 7.10! > Complete instructions are given in the attached file. After all, it > _does_ look quite simple. But only once you know how. Please let me > know if you have any improvements waiting. I'll check this file into > the CVS somewhere. > > We need to add these instructions to modula3.elegosoft.com, so that > others do not take the same "shortcuts" I did. If noone else feels > like doing it, I will. But right now, it's way past bedtime. > > All the best, > Neels > -- Neels Janosch Hofmeyr Software Developer neels at elego.de Public Key: http://binarchy.net/neels/neels.hofmeyr.public.key.asc elego Software Solutions GmbH http://www.elegosoft.com Gustav-Meyer-Allee 25, Geb?ude 12 HRB 77719 13355 Berlin, Germany Amtsgericht Charlottenburg Tel.: +49 30 23 45 86 96 Sitz der Gesellschaft: Berlin Fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Olaf Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: install-cm3-on-ubuntu-7-10.txt Type: application/vnd.ms-powerpoint Size: 9628 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From rcoleburn at scires.com Fri Jan 25 02:06:09 2008 From: rcoleburn at scires.com (Randy Coleburn) Date: Thu, 24 Jan 2008 20:06:09 -0500 Subject: [M3devel] INSTALL_ROOT and PKG_USE in cm3.cfg In-Reply-To: References: <4798DEB8.1E75.00D7.1@scires.com> Message-ID: <4798EFAE.1E75.00D7.1@scires.com> Jay: That's the reason I asked before making a change. I don't want to break or mess up what you are doing. I can get around the problem easily for me. I just remove the comment from the %INSTALL_ROOT="c:\\cm3" and "everything" is ok. I'm hoping we can come up with a way that works for everyone. Once the CM3_IDE (formerly known as Reactor) package is in the repository and part of the standard distribution, it would be best if folks don't have to go around editing cm3.cfg to make it work properly. Now, you are saying your way is more automatic and portable. I like these words. Is there a way we can set something in cm3.cfg that I can key off of for CM3_IDE/Reactor? I don't mind changing the code to accommodate. The big thing for CM3_IDE/Reactor, is that it needs to know where to look for the cm3 installation because it has to find all of the subdirs, like doc, examples, etc. BTW, I still don't see why all this "works" since I am getting "\.." as my INSTALL_ROOT. Regards, Randy >>> Jay 1/24/2008 7:24 PM >>> Blech. My way is more automatic and "portable" in the sense that you can move installations around and they keep working. As well, with my way, you just extract an archive and go, no setup/cminstall, no editing of the cm3.cfg file, just set %PATH% and run vcvars, and vcvars I think I can remove the need for. path() is a builtin Quake function that returns the directory of the currently being run Quake code. But yet Reactor. To unblock yourself, remove my code, add back the commented out, fix the path to match your particular install, don't submit the file. Perhaps move the current checked in file over to the config-no-install directory and then put config's file back in the old style, that requires running cminstall. My workflow will keep working, since it probes for config-no-install first. - Jay Date: Thu, 24 Jan 2008 18:53:48 -0500 From: rcoleburn at scires.com To: jay123 at hotmail.com CC: m3devel at elegosoft.com Subject: [M3devel] INSTALL_ROOT and PKG_USE in cm3.cfg Jay: The cm3.cfg that comes with your minimal binary installation on Windows (NT386) has the following lines: ----------------------------------------- % INSTALL_ROOT = BEGIN_CONFIG % "Where should CM3 be installed?" % 7 %-- user specified install root % END_CONFIG % INSTALL_ROOT = "c:\\cm3" if not defined("INSTALL_ROOT") if not equal ($INSTALLROOT, "") INSTALL_ROOT = $INSTALLROOT else INSTALL_ROOT = (path() & "\\..") end end BIN_INSTALL = INSTALL_ROOT & "\\bin" % executables LIB_INSTALL = INSTALL_ROOT & "\\lib" % libraries PKG_INSTALL = INSTALL_ROOT & "\\pkg" % packages DOC_INSTALL = INSTALL_ROOT & "\\doc" % documents EMACS_INSTALL = INSTALL_ROOT & "\\elisp" % emacs lisp code MAN_INSTALL = INSTALL_ROOT & "\\man" % man pages HTML_INSTALL = INSTALL_ROOT & "\\www" % public hypertext % % On some systems (e.g. AFS) you must install public files in a different % place from where you use them. If that is the case for your system, % specify the "use" location here, otherwise leave them alone. % %USE_ROOT = INSTALL_ROOT BIN_USE = BIN_INSTALL % executables LIB_USE = LIB_INSTALL % libraries PKG_USE = PKG_INSTALL % packages ----------------------------------------- Notice that the lines for INSTALL_ROOT and USE_ROOT are commented out. The Reactor program is coded to grab several variables out of cm3.cfg. For example, build_dir := M3Config.Get ("BUILD_DIR"); system_root := M3Config.Get ("PKG_USE"); doc_root := M3Config.Get ("DOC_INSTALL"); initial_browser := M3Config.Get ("INITIAL_CM3_IDE_BROWSER"); initial_editor := M3Config.Get ("INITIAL_CM3_IDE_EDITOR"); What is happening on my installation is that PKG_USE winds up being "\..\PKG". This is not a valid path and it is causing all sorts of trouble for Reactor. The reason it is getting set this way is that the ELSE branch of the, if not defined("INSTALL_ROOT"), is getting executed resulting in INSTALL_ROOT=\.. I'm not sure why this is coded this way. How do you suggest this should be repaired? Note, I have not checked all of the cm3.cfg variants for the other target platforms, but in order for reactor to work properly, it must be able to find a valid "PKG_USE" in the cm3.cfg. Regards, Randy 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 jayk123 at hotmail.com Fri Jan 25 02:33:40 2008 From: jayk123 at hotmail.com (Jay) Date: Fri, 25 Jan 2008 01:33:40 +0000 Subject: [M3devel] INSTALL_ROOT and PKG_USE in cm3.cfg In-Reply-To: <4798EFAE.1E75.00D7.1@scires.com> References: <4798DEB8.1E75.00D7.1@scires.com> <4798EFAE.1E75.00D7.1@scires.com> Message-ID: I'm not sure what versions of cm3 have path(). I did think I saw it missing the other day. That could be your problem.m3cgcat also doesn't like my config file, it wants to open it to find TARGET, not sure it uses it at all, but it wants it. When I run mcgcat, I first put back a TARGET line in my cm3.cfg. And then remove it. This is very related. I would suspect that whoever reads the files MIGHT find it acceptable to RUN them. Running them doesn't mean compiling or linking or anything, those are functions that the "host" would chose to call or not. But toplevel can have arbitrary code so maybe this is not great. Reactor is a persistant web server though, right? It should be ok "running" the file, esp. since it doesn't start often. The "normal" alternative that other folks use is to run cminstall, which I find all but useless. In terms of my workflow, you can go ahead and copy NT386 to the config-no-install directory. I'll survive. Randy you should try debugging stuff. Quake is readily debuggabe through printing. if defined("path") write("path is defined") write("path is " & path()) else write("path is not defined") end error("") I put in error so I stop after my printing and don't go and build stuff when my intent was just to run a snippet of Quake. - Jay Date: Thu, 24 Jan 2008 20:06:09 -0500From: rcoleburn at scires.comTo: jay123 at hotmail.com; jayk123 at hotmail.comCC: m3devel at elegosoft.comSubject: RE: [M3devel] INSTALL_ROOT and PKG_USE in cm3.cfg Jay: That's the reason I asked before making a change. I don't want to break or mess up what you are doing. I can get around the problem easily for me. I just remove the comment from the %INSTALL_ROOT="c:\\cm3" and "everything" is ok. I'm hoping we can come up with a way that works for everyone. Once the CM3_IDE (formerly known as Reactor) package is in the repository and part of the standard distribution, it would be best if folks don't have to go around editing cm3.cfg to make it work properly. Now, you are saying your way is more automatic and portable. I like these words. Is there a way we can set something in cm3.cfg that I can key off of for CM3_IDE/Reactor? I don't mind changing the code to accommodate. The big thing for CM3_IDE/Reactor, is that it needs to know where to look for the cm3 installation because it has to find all of the subdirs, like doc, examples, etc. BTW, I still don't see why all this "works" since I am getting "\.." as my INSTALL_ROOT. Regards, Randy>>> Jay 1/24/2008 7:24 PM >>>Blech. My way is more automatic and "portable" in the sense that you can move installations around and they keep working. As well, with my way, you just extract an archive and go, no setup/cminstall, no editing of the cm3.cfg file, just set %PATH% and run vcvars, and vcvars I think I can remove the need for. path() is a builtin Quake function that returns the directory of the currently being run Quake code. But yet Reactor.To unblock yourself, remove my code, add back the commented out, fix the path to match your particular install, don't submit the file. Perhaps move the current checked in file over to the config-no-install directory and then put config's file back in the old style, that requires running cminstall. My workflow will keep working, since it probes for config-no-install first. - Jay Date: Thu, 24 Jan 2008 18:53:48 -0500From: rcoleburn at scires.comTo: jay123 at hotmail.comCC: m3devel at elegosoft.comSubject: [M3devel] INSTALL_ROOT and PKG_USE in cm3.cfg Jay: The cm3.cfg that comes with your minimal binary installation on Windows (NT386) has the following lines: ----------------------------------------- % INSTALL_ROOT = BEGIN_CONFIG% "Where should CM3 be installed?"% 7 %-- user specified install root% END_CONFIG % INSTALL_ROOT = "c:\\cm3" if not defined("INSTALL_ROOT") if not equal ($INSTALLROOT, "") INSTALL_ROOT = $INSTALLROOT else INSTALL_ROOT = (path() & "\\..") endend BIN_INSTALL = INSTALL_ROOT & "\\bin" % executablesLIB_INSTALL = INSTALL_ROOT & "\\lib" % librariesPKG_INSTALL = INSTALL_ROOT & "\\pkg" % packagesDOC_INSTALL = INSTALL_ROOT & "\\doc" % documentsEMACS_INSTALL = INSTALL_ROOT & "\\elisp" % emacs lisp codeMAN_INSTALL = INSTALL_ROOT & "\\man" % man pagesHTML_INSTALL = INSTALL_ROOT & "\\www" % public hypertext %% On some systems (e.g. AFS) you must install public files in a different% place from where you use them. If that is the case for your system,% specify the "use" location here, otherwise leave them alone.%%USE_ROOT = INSTALL_ROOTBIN_USE = BIN_INSTALL % executablesLIB_USE = LIB_INSTALL % librariesPKG_USE = PKG_INSTALL % packages ----------------------------------------- Notice that the lines for INSTALL_ROOT and USE_ROOT are commented out. The Reactor program is coded to grab several variables out of cm3.cfg. For example, build_dir := M3Config.Get ("BUILD_DIR"); system_root := M3Config.Get ("PKG_USE"); doc_root := M3Config.Get ("DOC_INSTALL"); initial_browser := M3Config.Get ("INITIAL_CM3_IDE_BROWSER"); initial_editor := M3Config.Get ("INITIAL_CM3_IDE_EDITOR"); What is happening on my installation is that PKG_USE winds up being "\..\PKG". This is not a valid path and it is causing all sorts of trouble for Reactor. The reason it is getting set this way is that the ELSE branch of the, if not defined("INSTALL_ROOT"), is getting executed resulting in INSTALL_ROOT=\.. I'm not sure why this is coded this way. How do you suggest this should be repaired? Note, I have not checked all of the cm3.cfg variants for the other target platforms, but in order for reactor to work properly, it must be able to find a valid "PKG_USE" in the cm3.cfg. Regards, Randy 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 rodney.bates at wichita.edu Fri Jan 25 02:33:15 2008 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Thu, 24 Jan 2008 19:33:15 -0600 Subject: [M3devel] SIG64 from gdb (was still errors with cm3-min-POSIX-LINUXLIBC6-d5.5.1-2008-01-24-03-35-01) In-Reply-To: <47991443.2050809@elego.de> References: <47991443.2050809@elego.de> Message-ID: <47993C5B.8020505@wichita.edu> See embedded comments at end: Neels Janosch Hofmeyr wrote: > Using the > cm3-min-POSIX-LINUXLIBC6-d5.5.1-2008-01-24-03-35-01.tgz > in conjunction with the 5.4.0 source tarballs, I get, : > ... snip ... > $ cm3 -version > Critical Mass Modula-3 version d5.5.1-2008-01-24-03-35-01 > last updated: 2007-12-30 > compiled: 2008-01-24 03:54:37 > configuration: /usr/local/cm3/bin/cm3.cfg > (gdb) c > Continuing. > > Program received signal SIG64, Real-time event 64. > 0xffffe410 in __kernel_vsyscall () > (gdb) c > Continuing. > --- building in LINUXLIBC6 --- > > ignoring ../src/m3overrides > > > Program received signal SIG64, Real-time event 64. > 0xffffe410 in __kernel_vsyscall () > (gdb) c > Continuing. This is secondary to the original problem, but the SIG64 stops are false stops in gdb. In the phtreads implementation, SIG64 is used internally as a normal event, and you don't want gdb to stop there. (Unless, maybe, you're debugging the use of SIG64 :-) ) To prevent this happening in gdb, type: handle SIG64 nostop noprint pass I checked in an update to m3gdb around Oct. 8, that makes m3gdb adopt this behavior by default, when debugging a program that uses pthreads. From the checkin log text: 6) When PThreads are used, automatically set m3gdb to silently pass SIG64 to the program. Otherwise, this also would cause false stops. -- ------------------------------------------------------------- Rodney 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 Fri Jan 25 03:07:29 2008 From: rcoleburn at scires.com (Randy Coleburn) Date: Thu, 24 Jan 2008 21:07:29 -0500 Subject: [M3devel] INSTALL_ROOT and PKG_USE in cm3.cfg In-Reply-To: References: <4798DEB8.1E75.00D7.1@scires.com> <4798EFAE.1E75.00D7.1@scires.com> Message-ID: <4798FE0E.1E75.00D7.1@scires.com> Jay: Not sure exactly what you mean by: >I'm not sure what versions of cm3 have path(). I did think I saw it missing the other day. I assume you are not referring to the path env variable. Is this some built-in quake function or a function you have written in quake? The version of cm3.cfg that I am using is the one that *you* put in the minimal binary installation for windows. Reactor does indeed "run" the cm3.cfg in that it uses quake to load and interpret this file. What is the significance of doing the copy you suggest below? >In terms of my workflow, you can go ahead and copy NT386 to the config-no-install directory. I'll survive. I'm not trying to be obtuse here. It's just that you have been working on the windows distribution and all these scripts etc for a while now. I don't want to mess up anything you are doing and I know I don't have a deep understanding of all this, so I am reluctant to change anything like cm3.cfg for my needs. My goal is to make the CM3-IDE (old Reactor) available to everyone. As I said before, it does "run" the cm3.cfg and it needs to use this somehow to come up with a valid "PKG_USE" which should point to the "pkg" folder inside the cm3 installation root. Regards, Randy >>> Jay 1/24/2008 8:33 PM >>> I'm not sure what versions of cm3 have path(). I did think I saw it missing the other day. That could be your problem. m3cgcat also doesn't like my config file, it wants to open it to find TARGET, not sure it uses it at all, but it wants it. When I run mcgcat, I first put back a TARGET line in my cm3.cfg. And then remove it. This is very related. I would suspect that whoever reads the files MIGHT find it acceptable to RUN them. Running them doesn't mean compiling or linking or anything, those are functions that the "host" would chose to call or not. But toplevel can have arbitrary code so maybe this is not great. Reactor is a persistant web server though, right? It should be ok "running" the file, esp. since it doesn't start often. The "normal" alternative that other folks use is to run cminstall, which I find all but useless. In terms of my workflow, you can go ahead and copy NT386 to the config-no-install directory. I'll survive. Randy you should try debugging stuff. Quake is readily debuggabe through printing. if defined("path") write("path is defined") write("path is " & path()) else write("path is not defined") end error("") I put in error so I stop after my printing and don't go and build stuff when my intent was just to run a snippet of Quake. - Jay Date: Thu, 24 Jan 2008 20:06:09 -0500 From: rcoleburn at scires.com To: jay123 at hotmail.com; jayk123 at hotmail.com CC: m3devel at elegosoft.com Subject: RE: [M3devel] INSTALL_ROOT and PKG_USE in cm3.cfg Jay: That's the reason I asked before making a change. I don't want to break or mess up what you are doing. I can get around the problem easily for me. I just remove the comment from the %INSTALL_ROOT="c:\\cm3" and "everything" is ok. I'm hoping we can come up with a way that works for everyone. Once the CM3_IDE (formerly known as Reactor) package is in the repository and part of the standard distribution, it would be best if folks don't have to go around editing cm3.cfg to make it work properly. Now, you are saying your way is more automatic and portable. I like these words. Is there a way we can set something in cm3.cfg that I can key off of for CM3_IDE/Reactor? I don't mind changing the code to accommodate. The big thing for CM3_IDE/Reactor, is that it needs to know where to look for the cm3 installation because it has to find all of the subdirs, like doc, examples, etc. BTW, I still don't see why all this "works" since I am getting "\.." as my INSTALL_ROOT. Regards, Randy >>> Jay 1/24/2008 7:24 PM >>> Blech. My way is more automatic and "portable" in the sense that you can move installations around and they keep working. As well, with my way, you just extract an archive and go, no setup/cminstall, no editing of the cm3.cfg file, just set %PATH% and run vcvars, and vcvars I think I can remove the need for. path() is a builtin Quake function that returns the directory of the currently being run Quake code. But yet Reactor. To unblock yourself, remove my code, add back the commented out, fix the path to match your particular install, don't submit the file. Perhaps move the current checked in file over to the config-no-install directory and then put config's file back in the old style, that requires running cminstall. My workflow will keep working, since it probes for config-no-install first. - Jay Date: Thu, 24 Jan 2008 18:53:48 -0500 From: rcoleburn at scires.com To: jay123 at hotmail.com CC: m3devel at elegosoft.com Subject: [M3devel] INSTALL_ROOT and PKG_USE in cm3.cfg Jay: The cm3.cfg that comes with your minimal binary installation on Windows (NT386) has the following lines: ----------------------------------------- % INSTALL_ROOT = BEGIN_CONFIG % "Where should CM3 be installed?" % 7 %-- user specified install root % END_CONFIG % INSTALL_ROOT = "c:\\cm3" if not defined("INSTALL_ROOT") if not equal ($INSTALLROOT, "") INSTALL_ROOT = $INSTALLROOT else INSTALL_ROOT = (path() & "\\..") end end BIN_INSTALL = INSTALL_ROOT & "\\bin" % executables LIB_INSTALL = INSTALL_ROOT & "\\lib" % libraries PKG_INSTALL = INSTALL_ROOT & "\\pkg" % packages DOC_INSTALL = INSTALL_ROOT & "\\doc" % documents EMACS_INSTALL = INSTALL_ROOT & "\\elisp" % emacs lisp code MAN_INSTALL = INSTALL_ROOT & "\\man" % man pages HTML_INSTALL = INSTALL_ROOT & "\\www" % public hypertext % % On some systems (e.g. AFS) you must install public files in a different % place from where you use them. If that is the case for your system, % specify the "use" location here, otherwise leave them alone. % %USE_ROOT = INSTALL_ROOT BIN_USE = BIN_INSTALL % executables LIB_USE = LIB_INSTALL % libraries PKG_USE = PKG_INSTALL % packages ----------------------------------------- Notice that the lines for INSTALL_ROOT and USE_ROOT are commented out. The Reactor program is coded to grab several variables out of cm3.cfg. For example, build_dir := M3Config.Get ("BUILD_DIR"); system_root := M3Config.Get ("PKG_USE"); doc_root := M3Config.Get ("DOC_INSTALL"); initial_browser := M3Config.Get ("INITIAL_CM3_IDE_BROWSER"); initial_editor := M3Config.Get ("INITIAL_CM3_IDE_EDITOR"); What is happening on my installation is that PKG_USE winds up being "\..\PKG". This is not a valid path and it is causing all sorts of trouble for Reactor. The reason it is getting set this way is that the ELSE branch of the, if not defined("INSTALL_ROOT"), is getting executed resulting in INSTALL_ROOT=\.. I'm not sure why this is coded this way. How do you suggest this should be repaired? Note, I have not checked all of the cm3.cfg variants for the other target platforms, but in order for reactor to work properly, it must be able to find a valid "PKG_USE" in the cm3.cfg. Regards, Randy 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 ) 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 jayk123 at hotmail.com Fri Jan 25 03:23:51 2008 From: jayk123 at hotmail.com (Jay) Date: Fri, 25 Jan 2008 02:23:51 +0000 Subject: [M3devel] INSTALL_ROOT and PKG_USE in cm3.cfg In-Reply-To: <4798FE0E.1E75.00D7.1@scires.com> References: <4798DEB8.1E75.00D7.1@scires.com> <4798EFAE.1E75.00D7.1@scires.com> <4798FE0E.1E75.00D7.1@scires.com> Message-ID: Randy, don't worry, whatever you do, I'll be able to recover from. Just try editing your \cm3\bin\cm3.cfg file to say INSTALLROOT="c:\cm3" or whatever. Remove the path() function as a variable. See what happens. Maybe it's the problem, maybe not. It is something that I changed, and is worth trying the old way. Use write() and error() to print the other variables. Can you make the stuff you are working on available? To just some people? - Jay Date: Thu, 24 Jan 2008 21:07:29 -0500From: rcoleburn at scires.comTo: jay123 at hotmail.com; jayk123 at hotmail.comCC: m3devel at elegosoft.comSubject: Re: [M3devel] INSTALL_ROOT and PKG_USE in cm3.cfg Jay: Not sure exactly what you mean by:>I'm not sure what versions of cm3 have path(). I did think I saw it missing the other day. I assume you are not referring to the path env variable. Is this some built-in quake function or a function you have written in quake? The version of cm3.cfg that I am using is the one that *you* put in the minimal binary installation for windows. Reactor does indeed "run" the cm3.cfg in that it uses quake to load and interpret this file. What is the significance of doing the copy you suggest below? >In terms of my workflow, you can go ahead and copy NT386 to the config-no-install directory. I'll survive. I'm not trying to be obtuse here. It's just that you have been working on the windows distribution and all these scripts etc for a while now. I don't want to mess up anything you are doing and I know I don't have a deep understanding of all this, so I am reluctant to change anything like cm3.cfg for my needs. My goal is to make the CM3-IDE (old Reactor) available to everyone. As I said before, it does "run" the cm3.cfg and it needs to use this somehow to come up with a valid "PKG_USE" which should point to the "pkg" folder inside the cm3 installation root. Regards, Randy >>> Jay 1/24/2008 8:33 PM >>>I'm not sure what versions of cm3 have path(). I did think I saw it missing the other day.That could be your problem.m3cgcat also doesn't like my config file, it wants to open it to find TARGET, not sure it uses it at all, but it wants it. When I run mcgcat, I first put back a TARGET line in my cm3.cfg. And then remove it.This is very related.I would suspect that whoever reads the files MIGHT find it acceptable to RUN them.Running them doesn't mean compiling or linking or anything, those are functions that the "host" would chose to call or not. But toplevel can have arbitrary code so maybe this is not great. Reactor is a persistant web server though, right? It should be ok "running" the file, esp. since it doesn't start often. The "normal" alternative that other folks use is to run cminstall, which I find all but useless. In terms of my workflow, you can go ahead and copy NT386 to the config-no-install directory. I'll survive. Randy you should try debugging stuff. Quake is readily debuggabe through printing. if defined("path") write("path is defined") write("path is " & path())else write("path is not defined")enderror("") I put in error so I stop after my printing and don't go and build stuff when my intent was just to run a snippet of Quake. - Jay Date: Thu, 24 Jan 2008 20:06:09 -0500From: rcoleburn at scires.comTo: jay123 at hotmail.com; jayk123 at hotmail.comCC: m3devel at elegosoft.comSubject: RE: [M3devel] INSTALL_ROOT and PKG_USE in cm3.cfg Jay: That's the reason I asked before making a change. I don't want to break or mess up what you are doing. I can get around the problem easily for me. I just remove the comment from the %INSTALL_ROOT="c:\\cm3" and "everything" is ok. I'm hoping we can come up with a way that works for everyone. Once the CM3_IDE (formerly known as Reactor) package is in the repository and part of the standard distribution, it would be best if folks don't have to go around editing cm3.cfg to make it work properly. Now, you are saying your way is more automatic and portable. I like these words. Is there a way we can set something in cm3.cfg that I can key off of for CM3_IDE/Reactor? I don't mind changing the code to accommodate. The big thing for CM3_IDE/Reactor, is that it needs to know where to look for the cm3 installation because it has to find all of the subdirs, like doc, examples, etc. BTW, I still don't see why all this "works" since I am getting "\.." as my INSTALL_ROOT. Regards, Randy>>> Jay 1/24/2008 7:24 PM >>>Blech. My way is more automatic and "portable" in the sense that you can move installations around and they keep working. As well, with my way, you just extract an archive and go, no setup/cminstall, no editing of the cm3.cfg file, just set %PATH% and run vcvars, and vcvars I think I can remove the need for. path() is a builtin Quake function that returns the directory of the currently being run Quake code. But yet Reactor.To unblock yourself, remove my code, add back the commented out, fix the path to match your particular install, don't submit the file. Perhaps move the current checked in file over to the config-no-install directory and then put config's file back in the old style, that requires running cminstall. My workflow will keep working, since it probes for config-no-install first. - Jay Date: Thu, 24 Jan 2008 18:53:48 -0500From: rcoleburn at scires.comTo: jay123 at hotmail.comCC: m3devel at elegosoft.comSubject: [M3devel] INSTALL_ROOT and PKG_USE in cm3.cfg Jay: The cm3.cfg that comes with your minimal binary installation on Windows (NT386) has the following lines: ----------------------------------------- % INSTALL_ROOT = BEGIN_CONFIG% "Where should CM3 be installed?"% 7 %-- user specified install root% END_CONFIG % INSTALL_ROOT = "c:\\cm3" if not defined("INSTALL_ROOT") if not equal ($INSTALLROOT, "") INSTALL_ROOT = $INSTALLROOT else INSTALL_ROOT = (path() & "\\..") endend BIN_INSTALL = INSTALL_ROOT & "\\bin" % executablesLIB_INSTALL = INSTALL_ROOT & "\\lib" % librariesPKG_INSTALL = INSTALL_ROOT & "\\pkg" % packagesDOC_INSTALL = INSTALL_ROOT & "\\doc" % documentsEMACS_INSTALL = INSTALL_ROOT & "\\elisp" % emacs lisp codeMAN_INSTALL = INSTALL_ROOT & "\\man" % man pagesHTML_INSTALL = INSTALL_ROOT & "\\www" % public hypertext %% On some systems (e.g. AFS) you must install public files in a different% place from where you use them. If that is the case for your system,% specify the "use" location here, otherwise leave them alone.%%USE_ROOT = INSTALL_ROOTBIN_USE = BIN_INSTALL % executablesLIB_USE = LIB_INSTALL % librariesPKG_USE = PKG_INSTALL % packages ----------------------------------------- Notice that the lines for INSTALL_ROOT and USE_ROOT are commented out. The Reactor program is coded to grab several variables out of cm3.cfg. For example, build_dir := M3Config.Get ("BUILD_DIR"); system_root := M3Config.Get ("PKG_USE"); doc_root := M3Config.Get ("DOC_INSTALL"); initial_browser := M3Config.Get ("INITIAL_CM3_IDE_BROWSER"); initial_editor := M3Config.Get ("INITIAL_CM3_IDE_EDITOR"); What is happening on my installation is that PKG_USE winds up being "\..\PKG". This is not a valid path and it is causing all sorts of trouble for Reactor. The reason it is getting set this way is that the ELSE branch of the, if not defined("INSTALL_ROOT"), is getting executed resulting in INSTALL_ROOT=\.. I'm not sure why this is coded this way. How do you suggest this should be repaired? Note, I have not checked all of the cm3.cfg variants for the other target platforms, but in order for reactor to work properly, it must be able to find a valid "PKG_USE" in the cm3.cfg. Regards, Randy 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. 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 rcoleburn at scires.com Fri Jan 25 03:48:28 2008 From: rcoleburn at scires.com (Randy Coleburn) Date: Thu, 24 Jan 2008 21:48:28 -0500 Subject: [M3devel] INSTALL_ROOT and PKG_USE in cm3.cfg In-Reply-To: References: <4798DEB8.1E75.00D7.1@scires.com> <4798EFAE.1E75.00D7.1@scires.com> <4798FE0E.1E75.00D7.1@scires.com> Message-ID: <479907A8.1E75.00D7.1@scires.com> Jay: I've already edited my version of cm3.cfg to make it work for me. I don't know what the path() function does. The path() function is only used in the following code: if not defined("INSTALL_ROOT") if not equal ($INSTALLROOT, "") INSTALL_ROOT = $INSTALLROOT else INSTALL_ROOT = (path() & "\\..") end end Since this code is not executed when I define INSTALL_ROOT as "c:\\cm3", there is no need to remove it for my use. I've already confirmed that the other variables I need get set correctly inside CM3-IDE/Reactor once the INSTALL_ROOT is set properly. Note that a bunch of variables inside cm3.cfg depend on INSTALL_ROOT. I'm still want to find a solution for the general user population. Regards, Randy >>> Jay 1/24/2008 9:23 PM >>> Randy, don't worry, whatever you do, I'll be able to recover from. Just try editing your \cm3\bin\cm3.cfg file to say INSTALLROOT="c:\cm3" or whatever. Remove the path() function as a variable. See what happens. Maybe it's the problem, maybe not. It is something that I changed, and is worth trying the old way. Use write() and error() to print the other variables. Can you make the stuff you are working on available? To just some people? - Jay Date: Thu, 24 Jan 2008 21:07:29 -0500 From: rcoleburn at scires.com To: jay123 at hotmail.com; jayk123 at hotmail.com CC: m3devel at elegosoft.com Subject: Re: [M3devel] INSTALL_ROOT and PKG_USE in cm3.cfg Jay: Not sure exactly what you mean by: >I'm not sure what versions of cm3 have path(). I did think I saw it missing the other day. I assume you are not referring to the path env variable. Is this some built-in quake function or a function you have written in quake? The version of cm3.cfg that I am using is the one that *you* put in the minimal binary installation for windows. Reactor does indeed "run" the cm3.cfg in that it uses quake to load and interpret this file. What is the significance of doing the copy you suggest below? >In terms of my workflow, you can go ahead and copy NT386 to the config-no-install directory. I'll survive. I'm not trying to be obtuse here. It's just that you have been working on the windows distribution and all these scripts etc for a while now. I don't want to mess up anything you are doing and I know I don't have a deep understanding of all this, so I am reluctant to change anything like cm3.cfg for my needs. My goal is to make the CM3-IDE (old Reactor) available to everyone. As I said before, it does "run" the cm3.cfg and it needs to use this somehow to come up with a valid "PKG_USE" which should point to the "pkg" folder inside the cm3 installation root. Regards, Randy >>> Jay 1/24/2008 8:33 PM >>> I'm not sure what versions of cm3 have path(). I did think I saw it missing the other day. That could be your problem. m3cgcat also doesn't like my config file, it wants to open it to find TARGET, not sure it uses it at all, but it wants it. When I run mcgcat, I first put back a TARGET line in my cm3.cfg. And then remove it. This is very related. I would suspect that whoever reads the files MIGHT find it acceptable to RUN them. Running them doesn't mean compiling or linking or anything, those are functions that the "host" would chose to call or not. But toplevel can have arbitrary code so maybe this is not great. Reactor is a persistant web server though, right? It should be ok "running" the file, esp. since it doesn't start often. The "normal" alternative that other folks use is to run cminstall, which I find all but useless. In terms of my workflow, you can go ahead and copy NT386 to the config-no-install directory. I'll survive. Randy you should try debugging stuff. Quake is readily debuggabe through printing. if defined("path") write("path is defined") write("path is " & path()) else write("path is not defined") end error("") I put in error so I stop after my printing and don't go and build stuff when my intent was just to run a snippet of Quake. - Jay Date: Thu, 24 Jan 2008 20:06:09 -0500 From: rcoleburn at scires.com To: jay123 at hotmail.com; jayk123 at hotmail.com CC: m3devel at elegosoft.com Subject: RE: [M3devel] INSTALL_ROOT and PKG_USE in cm3.cfg Jay: That's the reason I asked before making a change. I don't want to break or mess up what you are doing. I can get around the problem easily for me. I just remove the comment from the %INSTALL_ROOT="c:\\cm3" and "everything" is ok. I'm hoping we can come up with a way that works for everyone. Once the CM3_IDE (formerly known as Reactor) package is in the repository and part of the standard distribution, it would be best if folks don't have to go around editing cm3.cfg to make it work properly. Now, you are saying your way is more automatic and portable. I like these words. Is there a way we can set something in cm3.cfg that I can key off of for CM3_IDE/Reactor? I don't mind changing the code to accommodate. The big thing for CM3_IDE/Reactor, is that it needs to know where to look for the cm3 installation because it has to find all of the subdirs, like doc, examples, etc. BTW, I still don't see why all this "works" since I am getting "\.." as my INSTALL_ROOT. Regards, Randy >>> Jay 1/24/2008 7:24 PM >>> Blech. My way is more automatic and "portable" in the sense that you can move installations around and they keep working. As well, with my way, you just extract an archive and go, no setup/cminstall, no editing of the cm3.cfg file, just set %PATH% and run vcvars, and vcvars I think I can remove the need for. path() is a builtin Quake function that returns the directory of the currently being run Quake code. But yet Reactor. To unblock yourself, remove my code, add back the commented out, fix the path to match your particular install, don't submit the file. Perhaps move the current checked in file over to the config-no-install directory and then put config's file back in the old style, that requires running cminstall. My workflow will keep working, since it probes for config-no-install first. - Jay Date: Thu, 24 Jan 2008 18:53:48 -0500 From: rcoleburn at scires.com To: jay123 at hotmail.com CC: m3devel at elegosoft.com Subject: [M3devel] INSTALL_ROOT and PKG_USE in cm3.cfg Jay: The cm3.cfg that comes with your minimal binary installation on Windows (NT386) has the following lines: ----------------------------------------- % INSTALL_ROOT = BEGIN_CONFIG % "Where should CM3 be installed?" % 7 %-- user specified install root % END_CONFIG % INSTALL_ROOT = "c:\\cm3" if not defined("INSTALL_ROOT") if not equal ($INSTALLROOT, "") INSTALL_ROOT = $INSTALLROOT else INSTALL_ROOT = (path() & "\\..") end end BIN_INSTALL = INSTALL_ROOT & "\\bin" % executables LIB_INSTALL = INSTALL_ROOT & "\\lib" % libraries PKG_INSTALL = INSTALL_ROOT & "\\pkg" % packages DOC_INSTALL = INSTALL_ROOT & "\\doc" % documents EMACS_INSTALL = INSTALL_ROOT & "\\elisp" % emacs lisp code MAN_INSTALL = INSTALL_ROOT & "\\man" % man pages HTML_INSTALL = INSTALL_ROOT & "\\www" % public hypertext % % On some systems (e.g. AFS) you must install public files in a different % place from where you use them. If that is the case for your system, % specify the "use" location here, otherwise leave them alone. % %USE_ROOT = INSTALL_ROOT BIN_USE = BIN_INSTALL % executables LIB_USE = LIB_INSTALL % libraries PKG_USE = PKG_INSTALL % packages ----------------------------------------- Notice that the lines for INSTALL_ROOT and USE_ROOT are commented out. The Reactor program is coded to grab several variables out of cm3.cfg. For example, build_dir := M3Config.Get ("BUILD_DIR"); system_root := M3Config.Get ("PKG_USE"); doc_root := M3Config.Get ("DOC_INSTALL"); initial_browser := M3Config.Get ("INITIAL_CM3_IDE_BROWSER"); initial_editor := M3Config.Get ("INITIAL_CM3_IDE_EDITOR"); What is happening on my installation is that PKG_USE winds up being "\..\PKG". This is not a valid path and it is causing all sorts of trouble for Reactor. The reason it is getting set this way is that the ELSE branch of the, if not defined("INSTALL_ROOT"), is getting executed resulting in INSTALL_ROOT=\.. I'm not sure why this is coded this way. How do you suggest this should be repaired? Note, I have not checked all of the cm3.cfg variants for the other target platforms, but in order for reactor to work properly, it must be able to find a valid "PKG_USE" in the cm3.cfg. Regards, Randy 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 ) 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 ) 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 ) -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcoleburn at scires.com Fri Jan 25 06:07:28 2008 From: rcoleburn at scires.com (Randy Coleburn) Date: Fri, 25 Jan 2008 00:07:28 -0500 Subject: [M3devel] INSTALL_ROOT and PKG_USE in cm3.cfg In-Reply-To: References: <4798DEB8.1E75.00D7.1@scires.com> <4798EFAE.1E75.00D7.1@scires.com> <4798FE0E.1E75.00D7.1@scires.com> <479907A8.1E75.00D7.1@scires.com> Message-ID: <4799283C.1E75.00D7.1@scires.com> Jay: Based on your description of path(), I don't think it is working correctly. My INSTALL_ROOT is turning up as "\.." instead of "C:\cm3\bin\.." If this path() function worked as advertised, I think your solution might work. Reactor/CM3-IDE is running from C:\cm3\bin, so when it uses quake to evaluate cm3.cfg, shouldn't it come up with "C:\cm3\bin\.." for the path? Maybe it does, and if so, then the ".." in the path may be confusing internally when it tries to make paths like "C:\cm3\bin\..\pkg". I don't know. Just a thought. Regards, Randy >>> Jay 1/24/2008 11:44 PM >>> 1) the general user population could revert back to cminstall; nobody else complained except me (a common occurence), and Olaf did improve it; I'd have to deign to putting together such a distribution yuck. Perhaps when a nice GUI installer comes along it won't feel so bad. 2) Again, can you make the stuff you are working on available? To just some people? path() returns the directory of the currently executing Quake code. And in this case, the file is in the directory that contains cm3.exe, so it is cm3.exe's directory, which we know is INSTALLROOT\bin, so go up one with .. and we have INSTALLROOT. It's a little unsightly to have ".." in all the resulting paths, but I think it is worth it. It could be fixed in a number of ways. 1) add a function PathDotDot or PathUp to cm3 2) more generally add a function PathCanonicalize to cm3. Or heck, move more and more of this stuff into cm3. I asked about this recently -- what are the requirements for compatibility with older tools. It is that unanswered, and presuming "the worst", besides my persistant distaste for Modula-3, that keeps me writing Quake code.. - Jay Date: Thu, 24 Jan 2008 21:48:28 -0500 From: rcoleburn at scires.com To: jay123 at hotmail.com; jayk123 at hotmail.com CC: m3devel at elegosoft.com Subject: Re: [M3devel] INSTALL_ROOT and PKG_USE in cm3.cfg Jay: I've already edited my version of cm3.cfg to make it work for me. I don't know what the path() function does. The path() function is only used in the following code: if not defined("INSTALL_ROOT") if not equal ($INSTALLROOT, "") INSTALL_ROOT = $INSTALLROOT else INSTALL_ROOT = (path() & "\\..") end end Since this code is not executed when I define INSTALL_ROOT as "c:\\cm3", there is no need to remove it for my use. I've already confirmed that the other variables I need get set correctly inside CM3-IDE/Reactor once the INSTALL_ROOT is set properly. Note that a bunch of variables inside cm3.cfg depend on INSTALL_ROOT. I'm still want to find a solution for the general user population. Regards, Randy >>> Jay 1/24/2008 9:23 PM >>> Randy, don't worry, whatever you do, I'll be able to recover from. Just try editing your \cm3\bin\cm3.cfg file to say INSTALLROOT="c:\cm3" or whatever. Remove the path() function as a variable. See what happens. Maybe it's the problem, maybe not. It is something that I changed, and is worth trying the old way. Use write() and error() to print the other variables. Can you make the stuff you are working on available? To just some people? - Jay Date: Thu, 24 Jan 2008 21:07:29 -0500 From: rcoleburn at scires.com To: jay123 at hotmail.com; jayk123 at hotmail.com CC: m3devel at elegosoft.com Subject: Re: [M3devel] INSTALL_ROOT and PKG_USE in cm3.cfg Jay: Not sure exactly what you mean by: >I'm not sure what versions of cm3 have path(). I did think I saw it missing the other day. I assume you are not referring to the path env variable. Is this some built-in quake function or a function you have written in quake? The version of cm3.cfg that I am using is the one that *you* put in the minimal binary installation for windows. Reactor does indeed "run" the cm3.cfg in that it uses quake to load and interpret this file. What is the significance of doing the copy you suggest below? >In terms of my workflow, you can go ahead and copy NT386 to the config-no-install directory. I'll survive. I'm not trying to be obtuse here. It's just that you have been working on the windows distribution and all these scripts etc for a while now. I don't want to mess up anything you are doing and I know I don't have a deep understanding of all this, so I am reluctant to change anything like cm3.cfg for my needs. My goal is to make the CM3-IDE (old Reactor) available to everyone. As I said before, it does "run" the cm3.cfg and it needs to use this somehow to come up with a valid "PKG_USE" which should point to the "pkg" folder inside the cm3 installation root. Regards, Randy >>> Jay 1/24/2008 8:33 PM >>> I'm not sure what versions of cm3 have path(). I did think I saw it missing the other day. That could be your problem. m3cgcat also doesn't like my config file, it wants to open it to find TARGET, not sure it uses it at all, but it wants it. When I run mcgcat, I first put back a TARGET line in my cm3.cfg. And then remove it. This is very related. I would suspect that whoever reads the files MIGHT find it acceptable to RUN them. Running them doesn't mean compiling or linking or anything, those are functions that the "host" would chose to call or not. But toplevel can have arbitrary code so maybe this is not great. Reactor is a persistant web server though, right? It should be ok "running" the file, esp. since it doesn't start often. The "normal" alternative that other folks use is to run cminstall, which I find all but useless. In terms of my workflow, you can go ahead and copy NT386 to the config-no-install directory. I'll survive. Randy you should try debugging stuff. Quake is readily debuggabe through printing. if defined("path") write("path is defined") write("path is " & path()) else write("path is not defined") end error("") I put in error so I stop after my printing and don't go and build stuff when my intent was just to run a snippet of Quake. - Jay Date: Thu, 24 Jan 2008 20:06:09 -0500 From: rcoleburn at scires.com To: jay123 at hotmail.com; jayk123 at hotmail.com CC: m3devel at elegosoft.com Subject: RE: [M3devel] INSTALL_ROOT and PKG_USE in cm3.cfg Jay: That's the reason I asked before making a change. I don't want to break or mess up what you are doing. I can get around the problem easily for me. I just remove the comment from the %INSTALL_ROOT="c:\\cm3" and "everything" is ok. I'm hoping we can come up with a way that works for everyone. Once the CM3_IDE (formerly known as Reactor) package is in the repository and part of the standard distribution, it would be best if folks don't have to go around editing cm3.cfg to make it work properly. Now, you are saying your way is more automatic and portable. I like these words. Is there a way we can set something in cm3.cfg that I can key off of for CM3_IDE/Reactor? I don't mind changing the code to accommodate. The big thing for CM3_IDE/Reactor, is that it needs to know where to look for the cm3 installation because it has to find all of the subdirs, like doc, examples, etc. BTW, I still don't see why all this "works" since I am getting "\.." as my INSTALL_ROOT. Regards, Randy >>> Jay 1/24/2008 7:24 PM >>> Blech. My way is more automatic and "portable" in the sense that you can move installations around and they keep working. As well, with my way, you just extract an archive and go, no setup/cminstall, no editing of the cm3.cfg file, just set %PATH% and run vcvars, and vcvars I think I can remove the need for. path() is a builtin Quake function that returns the directory of the currently being run Quake code. But yet Reactor. To unblock yourself, remove my code, add back the commented out, fix the path to match your particular install, don't submit the file. Perhaps move the current checked in file over to the config-no-install directory and then put config's file back in the old style, that requires running cminstall. My workflow will keep working, since it probes for config-no-install first. - Jay Date: Thu, 24 Jan 2008 18:53:48 -0500 From: rcoleburn at scires.com To: jay123 at hotmail.com CC: m3devel at elegosoft.com Subject: [M3devel] INSTALL_ROOT and PKG_USE in cm3.cfg Jay: The cm3.cfg that comes with your minimal binary installation on Windows (NT386) has the following lines: ----------------------------------------- % INSTALL_ROOT = BEGIN_CONFIG % "Where should CM3 be installed?" % 7 %-- user specified install root % END_CONFIG % INSTALL_ROOT = "c:\\cm3" if not defined("INSTALL_ROOT") if not equal ($INSTALLROOT, "") INSTALL_ROOT = $INSTALLROOT else INSTALL_ROOT = (path() & "\\..") end end BIN_INSTALL = INSTALL_ROOT & "\\bin" % executables LIB_INSTALL = INSTALL_ROOT & "\\lib" % libraries PKG_INSTALL = INSTALL_ROOT & "\\pkg" % packages DOC_INSTALL = INSTALL_ROOT & "\\doc" % documents EMACS_INSTALL = INSTALL_ROOT & "\\elisp" % emacs lisp code MAN_INSTALL = INSTALL_ROOT & "\\man" % man pages HTML_INSTALL = INSTALL_ROOT & "\\www" % public hypertext % % On some systems (e.g. AFS) you must install public files in a different % place from where you use them. If that is the case for your system, % specify the "use" location here, otherwise leave them alone. % %USE_ROOT = INSTALL_ROOT BIN_USE = BIN_INSTALL % executables LIB_USE = LIB_INSTALL % libraries PKG_USE = PKG_INSTALL % packages ----------------------------------------- Notice that the lines for INSTALL_ROOT and USE_ROOT are commented out. The Reactor program is coded to grab several variables out of cm3.cfg. For example, build_dir := M3Config.Get ("BUILD_DIR"); system_root := M3Config.Get ("PKG_USE"); doc_root := M3Config.Get ("DOC_INSTALL"); initial_browser := M3Config.Get ("INITIAL_CM3_IDE_BROWSER"); initial_editor := M3Config.Get ("INITIAL_CM3_IDE_EDITOR"); What is happening on my installation is that PKG_USE winds up being "\..\PKG". This is not a valid path and it is causing all sorts of trouble for Reactor. The reason it is getting set this way is that the ELSE branch of the, if not defined("INSTALL_ROOT"), is getting executed resulting in INSTALL_ROOT=\.. I'm not sure why this is coded this way. How do you suggest this should be repaired? Note, I have not checked all of the cm3.cfg variants for the other target platforms, but in order for reactor to work properly, it must be able to find a valid "PKG_USE" in the cm3.cfg. Regards, Randy 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 ) 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 ) 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 ) 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 ) -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Fri Jan 25 06:19:31 2008 From: jayk123 at hotmail.com (Jay) Date: Fri, 25 Jan 2008 05:19:31 +0000 Subject: [M3devel] INSTALL_ROOT and PKG_USE in cm3.cfg In-Reply-To: <4799283C.1E75.00D7.1@scires.com> References: <4798DEB8.1E75.00D7.1@scires.com> <4798EFAE.1E75.00D7.1@scires.com> <4798FE0E.1E75.00D7.1@scires.com> <479907A8.1E75.00D7.1@scires.com> <4799283C.1E75.00D7.1@scires.com> Message-ID: >> shouldn't it come up with "C:\cm3\bin\.." for the path? Correct. >> be confusing internally when it tries to make paths like "C:\cm3\bin\..\pkg". I don't know. Just a thought No. It works fine. I've been building this way a while now, no problems. YOU built this way I believe, just not using Reactor. It looks a little ugly if you see it, I admit, but it's worth it. I usually bootstrap from circa 5.1.6 and surely from 5.5.0 or .1 itself. I had been bootstrapping from something in between but haven't lately. So I can't vouch for all that many builds. I'm also using this code on PPC_LINUX and PPC_DARWIN (should be called PPC_MACOSX but oh well) successfully (look in m3-sys\cminstall\src\config-no-install). I have seen path() return empty with some older builds, but not with current builds. Where I have seen it, I added in if defined() to cope and something more that I forget, maybe just the "normal" thing, like to bootstrap from an older build, and it gets overwritten during the bootstrap, once there is a current cm3.exe. I should check, I should check the history, and consistently workaround for all the files with this construct (ie. config-no-install and NT386). The documentation says it returns the path or directory of cm3.exe. But I did find that to be false, but the function is still useful. It seems to return the path of the current Quake code. I haven't looked at the implementation (yet). Something is different in the Reactor path. >>> 2) Again again, can you make the stuff you are working on available? To just some people? ? - Jay Date: Fri, 25 Jan 2008 00:07:28 -0500From: rcoleburn at scires.comTo: jay123 at hotmail.com; jayk123 at hotmail.comCC: m3devel at elegosoft.comSubject: RE: [M3devel] INSTALL_ROOT and PKG_USE in cm3.cfg Jay: Based on your description of path(), I don't think it is working correctly. My INSTALL_ROOT is turning up as "\.." instead of "C:\cm3\bin\.." If this path() function worked as advertised, I think your solution might work. Reactor/CM3-IDE is running from C:\cm3\bin, so when it uses quake to evaluate cm3.cfg, shouldn't it come up with "C:\cm3\bin\.." for the path? Maybe it does, and if so, then the ".." in the path may be confusing internally when it tries to make paths like "C:\cm3\bin\..\pkg". I don't know. Just a thought. Regards, Randy>>> Jay 1/24/2008 11:44 PM >>>1) the general user population could revert back to cminstall; nobody else complained except me (a common occurence), and Olaf did improve it; I'd have to deign to putting together such a distribution yuck. Perhaps when a nice GUI installer comes along it won't feel so bad.2) Again, can you make the stuff you are working on available? To just some people? path() returns the directory of the currently executing Quake code.And in this case, the file is in the directory that contains cm3.exe, so it is cm3.exe's directory, which we know is INSTALLROOT\bin, so go up one with .. and we have INSTALLROOT. It's a little unsightly to have ".." in all the resulting paths, but I think it is worth it. It could be fixed in a number of ways. 1) add a function PathDotDot or PathUp to cm3 2) more generally add a function PathCanonicalize to cm3. Or heck, move more and more of this stuff into cm3. I asked about this recently -- what are the requirements for compatibility with older tools. It is that unanswered, and presuming "the worst", besides my persistant distaste for Modula-3, that keeps me writing Quake code.. - Jay Date: Thu, 24 Jan 2008 21:48:28 -0500From: rcoleburn at scires.comTo: jay123 at hotmail.com; jayk123 at hotmail.comCC: m3devel at elegosoft.comSubject: Re: [M3devel] INSTALL_ROOT and PKG_USE in cm3.cfg Jay: I've already edited my version of cm3.cfg to make it work for me. I don't know what the path() function does. The path() function is only used in the following code: if not defined("INSTALL_ROOT") if not equal ($INSTALLROOT, "") INSTALL_ROOT = $INSTALLROOT else INSTALL_ROOT = (path() & "\\..") endend Since this code is not executed when I define INSTALL_ROOT as "c:\\cm3", there is no need to remove it for my use. I've already confirmed that the other variables I need get set correctly inside CM3-IDE/Reactor once the INSTALL_ROOT is set properly. Note that a bunch of variables inside cm3.cfg depend on INSTALL_ROOT. I'm still want to find a solution for the general user population. Regards, Randy>>> Jay 1/24/2008 9:23 PM >>>Randy, don't worry, whatever you do, I'll be able to recover from. Just try editing your \cm3\bin\cm3.cfg file to say INSTALLROOT="c:\cm3" or whatever.Remove the path() function as a variable.See what happens. Maybe it's the problem, maybe not. It is something that I changed, and is worth trying the old way. Use write() and error() to print the other variables. Can you make the stuff you are working on available? To just some people? - Jay Date: Thu, 24 Jan 2008 21:07:29 -0500From: rcoleburn at scires.comTo: jay123 at hotmail.com; jayk123 at hotmail.comCC: m3devel at elegosoft.comSubject: Re: [M3devel] INSTALL_ROOT and PKG_USE in cm3.cfg Jay: Not sure exactly what you mean by:>I'm not sure what versions of cm3 have path(). I did think I saw it missing the other day. I assume you are not referring to the path env variable. Is this some built-in quake function or a function you have written in quake? The version of cm3.cfg that I am using is the one that *you* put in the minimal binary installation for windows. Reactor does indeed "run" the cm3.cfg in that it uses quake to load and interpret this file. What is the significance of doing the copy you suggest below? >In terms of my workflow, you can go ahead and copy NT386 to the config-no-install directory. I'll survive. I'm not trying to be obtuse here. It's just that you have been working on the windows distribution and all these scripts etc for a while now. I don't want to mess up anything you are doing and I know I don't have a deep understanding of all this, so I am reluctant to change anything like cm3.cfg for my needs. My goal is to make the CM3-IDE (old Reactor) available to everyone. As I said before, it does "run" the cm3.cfg and it needs to use this somehow to come up with a valid "PKG_USE" which should point to the "pkg" folder inside the cm3 installation root. Regards, Randy >>> Jay 1/24/2008 8:33 PM >>>I'm not sure what versions of cm3 have path(). I did think I saw it missing the other day.That could be your problem.m3cgcat also doesn't like my config file, it wants to open it to find TARGET, not sure it uses it at all, but it wants it. When I run mcgcat, I first put back a TARGET line in my cm3.cfg. And then remove it.This is very related.I would suspect that whoever reads the files MIGHT find it acceptable to RUN them.Running them doesn't mean compiling or linking or anything, those are functions that the "host" would chose to call or not. But toplevel can have arbitrary code so maybe this is not great. Reactor is a persistant web server though, right? It should be ok "running" the file, esp. since it doesn't start often. The "normal" alternative that other folks use is to run cminstall, which I find all but useless. In terms of my workflow, you can go ahead and copy NT386 to the config-no-install directory. I'll survive. Randy you should try debugging stuff. Quake is readily debuggabe through printing. if defined("path") write("path is defined") write("path is " & path())else write("path is not defined")enderror("") I put in error so I stop after my printing and don't go and build stuff when my intent was just to run a snippet of Quake. - Jay Date: Thu, 24 Jan 2008 20:06:09 -0500From: rcoleburn at scires.comTo: jay123 at hotmail.com; jayk123 at hotmail.comCC: m3devel at elegosoft.comSubject: RE: [M3devel] INSTALL_ROOT and PKG_USE in cm3.cfg Jay: That's the reason I asked before making a change. I don't want to break or mess up what you are doing. I can get around the problem easily for me. I just remove the comment from the %INSTALL_ROOT="c:\\cm3" and "everything" is ok. I'm hoping we can come up with a way that works for everyone. Once the CM3_IDE (formerly known as Reactor) package is in the repository and part of the standard distribution, it would be best if folks don't have to go around editing cm3.cfg to make it work properly. Now, you are saying your way is more automatic and portable. I like these words. Is there a way we can set something in cm3.cfg that I can key off of for CM3_IDE/Reactor? I don't mind changing the code to accommodate. The big thing for CM3_IDE/Reactor, is that it needs to know where to look for the cm3 installation because it has to find all of the subdirs, like doc, examples, etc. BTW, I still don't see why all this "works" since I am getting "\.." as my INSTALL_ROOT. Regards, Randy>>> Jay 1/24/2008 7:24 PM >>>Blech. My way is more automatic and "portable" in the sense that you can move installations around and they keep working. As well, with my way, you just extract an archive and go, no setup/cminstall, no editing of the cm3.cfg file, just set %PATH% and run vcvars, and vcvars I think I can remove the need for. path() is a builtin Quake function that returns the directory of the currently being run Quake code. But yet Reactor.To unblock yourself, remove my code, add back the commented out, fix the path to match your particular install, don't submit the file. Perhaps move the current checked in file over to the config-no-install directory and then put config's file back in the old style, that requires running cminstall. My workflow will keep working, since it probes for config-no-install first. - Jay Date: Thu, 24 Jan 2008 18:53:48 -0500From: rcoleburn at scires.comTo: jay123 at hotmail.comCC: m3devel at elegosoft.comSubject: [M3devel] INSTALL_ROOT and PKG_USE in cm3.cfg Jay: The cm3.cfg that comes with your minimal binary installation on Windows (NT386) has the following lines: ----------------------------------------- % INSTALL_ROOT = BEGIN_CONFIG% "Where should CM3 be installed?"% 7 %-- user specified install root% END_CONFIG % INSTALL_ROOT = "c:\\cm3" if not defined("INSTALL_ROOT") if not equal ($INSTALLROOT, "") INSTALL_ROOT = $INSTALLROOT else INSTALL_ROOT = (path() & "\\..") endend BIN_INSTALL = INSTALL_ROOT & "\\bin" % executablesLIB_INSTALL = INSTALL_ROOT & "\\lib" % librariesPKG_INSTALL = INSTALL_ROOT & "\\pkg" % packagesDOC_INSTALL = INSTALL_ROOT & "\\doc" % documentsEMACS_INSTALL = INSTALL_ROOT & "\\elisp" % emacs lisp codeMAN_INSTALL = INSTALL_ROOT & "\\man" % man pagesHTML_INSTALL = INSTALL_ROOT & "\\www" % public hypertext %% On some systems (e.g. AFS) you must install public files in a different% place from where you use them. If that is the case for your system,% specify the "use" location here, otherwise leave them alone.%%USE_ROOT = INSTALL_ROOTBIN_USE = BIN_INSTALL % executablesLIB_USE = LIB_INSTALL % librariesPKG_USE = PKG_INSTALL % packages ----------------------------------------- Notice that the lines for INSTALL_ROOT and USE_ROOT are commented out. The Reactor program is coded to grab several variables out of cm3.cfg. For example, build_dir := M3Config.Get ("BUILD_DIR"); system_root := M3Config.Get ("PKG_USE"); doc_root := M3Config.Get ("DOC_INSTALL"); initial_browser := M3Config.Get ("INITIAL_CM3_IDE_BROWSER"); initial_editor := M3Config.Get ("INITIAL_CM3_IDE_EDITOR"); What is happening on my installation is that PKG_USE winds up being "\..\PKG". This is not a valid path and it is causing all sorts of trouble for Reactor. The reason it is getting set this way is that the ELSE branch of the, if not defined("INSTALL_ROOT"), is getting executed resulting in INSTALL_ROOT=\.. I'm not sure why this is coded this way. How do you suggest this should be repaired? Note, I have not checked all of the cm3.cfg variants for the other target platforms, but in order for reactor to work properly, it must be able to find a valid "PKG_USE" in the cm3.cfg. Regards, Randy 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. Play now! 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". 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 wagner at elegosoft.com Fri Jan 25 08:06:33 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 25 Jan 2008 08:06:33 +0100 Subject: [M3devel] CM3 5.5.1 works on Ubuntu 7.10! In-Reply-To: <47993122.2030201@elego.de> References: <47993122.2030201@elego.de> Message-ID: <20080125080633.72gtexb6m8cocwsk@mail.elegosoft.com> Quoting Neels Janosch Hofmeyr : > Thanks Olaf, Tony, Mika and Jay, I have cm3 working on Ubuntu 7.10! > Complete instructions are given in the attached file. After all, it > _does_ look quite simple. But only once you know how. Please let me > know if you have any improvements waiting. I'll check this file into > the CVS somewhere. > > We need to add these instructions to modula3.elegosoft.com, so that > others do not take the same "shortcuts" I did. If noone else feels like > doing it, I will. But right now, it's way past bedtime. Would you care to load up your archive to birch.elegosoft.com:/var/www/modula3.elegosoft.com/cm3/uploaded-archives ? And check-in your instructions to cm3/www and link them in? That would be great. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From stsp at elego.de Fri Jan 25 10:35:35 2008 From: stsp at elego.de (Stefan Sperling) Date: Fri, 25 Jan 2008 10:35:35 +0100 Subject: [M3devel] CM3 5.5.1 works on Ubuntu 7.10! In-Reply-To: <47993388.9030909@elego.de> References: <47993122.2030201@elego.de> <47993388.9030909@elego.de> Message-ID: <20080125093535.GA27717@jack.stsp.name> On Fri, Jan 25, 2008 at 01:55:36AM +0100, Neels Janosch Hofmeyr wrote: > Wow, does your mail client also think the attachment is a PowerPoint > Document? Well, in fact it's a plain ASCII text file. Yes, the mime-type is wrong. Mutt tells me: [-- Attachment #2: install-cm3-on-ubuntu-7-10.txt --] [-- Type: application/vnd.ms-powerpoint, Encoding: base64, Size: 12K --] [-- application/vnd.ms-powerpoint is unsupported (use 'v' to view this part) --] -- Stefan Sperling Software Developer elego Software Solutions GmbH HRB 77719 Gustav-Meyer-Allee 25, Gebaeude 12 Tel: +49 30 23 45 86 96 13355 Berlin Fax: +49 30 23 45 86 95 http://www.elego.de Geschaeftsfuehrer: Olaf Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From wagner at elegosoft.com Fri Jan 25 11:09:59 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 25 Jan 2008 11:09:59 +0100 Subject: [M3devel] INSTALL_ROOT and PKG_USE in cm3.cfg In-Reply-To: References: <4798DEB8.1E75.00D7.1@scires.com> <4798EFAE.1E75.00D7.1@scires.com> <4798FE0E.1E75.00D7.1@scires.com> <479907A8.1E75.00D7.1@scires.com> <4799283C.1E75.00D7.1@scires.com> Message-ID: <20080125110959.5oc8u98w0w8csc80@mail.elegosoft.com> Quoting Jay : > using this code on PPC_LINUX and PPC_DARWIN (should be called > PPC_MACOSX but oh well) Actually I did the port on a plain DARWIN system from opendarwin.org when this was still alive. So there should be no dependency on MacOS X extensions. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Fri Jan 25 11:23:10 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 25 Jan 2008 11:23:10 +0100 Subject: [M3devel] INSTALL_ROOT and PKG_USE in cm3.cfg In-Reply-To: References: <4798DEB8.1E75.00D7.1@scires.com> <4798EFAE.1E75.00D7.1@scires.com> <4798FE0E.1E75.00D7.1@scires.com> <479907A8.1E75.00D7.1@scires.com> <4799283C.1E75.00D7.1@scires.com> Message-ID: <20080125112310.9qfns8rzx5gckgck@mail.elegosoft.com> Quoting Jay : > I have seen path() return empty with some older builds, but not with > current builds. > Where I have seen it, I added in if defined() to cope and something > more that I forget, maybe just the "normal" thing, like to bootstrap > from an older build, and it gets overwritten during the bootstrap, > once there is a current cm3.exe. I should check, I should check the > history, and consistently workaround for all the files with this > construct (ie. config-no-install and NT386). > > The documentation says it returns the path or directory of cm3.exe. > But I did find that to be false, but the function is still useful. > It seems to return the path of the current Quake code. I haven't > looked at the implementation (yet). Where did you read that? http://modula3.elegosoft.com/cm3/doc/help/cm3/quake.html says path() Returns the directory of the currently executing file as a string Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Jan 25 11:29:28 2008 From: jayk123 at hotmail.com (Jay) Date: Fri, 25 Jan 2008 10:29:28 +0000 Subject: [M3devel] INSTALL_ROOT and PKG_USE in cm3.cfg In-Reply-To: <20080125110959.5oc8u98w0w8csc80@mail.elegosoft.com> References: <4798DEB8.1E75.00D7.1@scires.com> <4798EFAE.1E75.00D7.1@scires.com> <4798FE0E.1E75.00D7.1@scires.com> <479907A8.1E75.00D7.1@scires.com> <4799283C.1E75.00D7.1@scires.com> <20080125110959.5oc8u98w0w8csc80@mail.elegosoft.com> Message-ID: ok, but independent of what it's actual dependencies are...how many people run Darwin? How many people run Mac OS X? How many people have heard of Darwin (not Charles)? How many people have heard of Mac OS X? Even among the unusual people who might read anything related to Modula-3 and own a Macintosh running Mac OS X? I know it's not a popularity contest but.. NT386 should be called Windows. The name "NT" will probably gradually fade into obscurity and the name "Windows" will live on much longe. Posix and Unix will probably be forgotten and people will only have heard of "Linux". The PPC_DARWIN port has an optional dependency on X Windows..is that available for plain Darwin or only with Mac OS X? Anyway..it's just a gut feeling I have as to what names people would look for and find less surprising. I was surprised by "Darwin", therefore would be.. :) MacX is maybe a better compromise to be shorter. or Macintosh for verbosity and without so many initials.. (NT386 may be short and typable but every letter is a syllable and I think economy of syllables is also important....(not clear if prounounced "eight" or "eighty") Or maybe just Mac, assuming nobody thinks there will ever be a port to pre MacX, which could be called OldMac or MacClassic or Mac9 anyway if necessary.. :) LINUX, LINUXELF, LINUXLIBC6? Please. Couldn't Linux have been recycled for LINUXLIBC6?Does anyone have Linux 1.2 around? That's the version I've run the most, long ago. :) Anyway I don't care THAT much and I will resist suggesting any more names for any preexisting targets or criticizing them. They almost all stink, esp. the active ones. :) Are the older FreeBSD ABIs so inferior that it is worth having newer ones? They didn't have pthreads back then and they do now? - Jay > Date: Fri, 25 Jan 2008 11:09:59 +0100> From: wagner at elegosoft.com> To: m3devel at elegosoft.com> Subject: Re: [M3devel] INSTALL_ROOT and PKG_USE in cm3.cfg> > Quoting Jay :> > > using this code on PPC_LINUX and PPC_DARWIN (should be called > > PPC_MACOSX but oh well)> > Actually I did the port on a plain DARWIN system from opendarwin.org> when this was still alive. So there should be no dependency on MacOS X> extensions.> > Olaf> -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 Fri Jan 25 11:38:17 2008 From: mika at async.caltech.edu (Mika Nystrom) Date: Fri, 25 Jan 2008 02:38:17 -0800 Subject: [M3devel] INSTALL_ROOT and PKG_USE in cm3.cfg In-Reply-To: Your message of "Fri, 25 Jan 2008 10:29:28 GMT." Message-ID: <200801251038.m0PAcHVv014819@camembert.async.caltech.edu> I'm not sure about this MACOSX business. This is what I see when I log in to my Mac: (94)rover:~>ssh -Y lapdog Last login: Tue Jan 22 00:33:21 2008 from rover Welcome to Darwin! [lapdog:~] mika% uname -a Darwin lapdog 8.11.0 Darwin Kernel Version 8.11.0: Wed Oct 10 18:26:00 PDT 2007; root:xnu-792.24.17~1/RELEASE_PPC Power Macintosh powerpc [lapdog:~] mika% Jay writes: >--_587094ee-5029-41f3-88b0-f4a35ad4e834_ >Content-Type: text/plain; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > >ok, but independent of what it's actual dependencies are...how many people = >run Darwin? How many people run Mac OS X? How many people have heard of Dar= >win (not Charles)? How many people have heard of Mac OS X? Even among the u= >nusual people who might read anything related to Modula-3 and own a Macinto= >sh running Mac OS X? I know it's not a popularity contest but.. NT386 shoul= >d be called Windows. The name "NT" will probably gradually fade into obscur= >ity and the name "Windows" will live on much longe. Posix and Unix will pro= >bably be forgotten and people will only have heard of "Linux". >=20 >The PPC_DARWIN port has an optional dependency on X Windows..is that availa= >ble for plain Darwin or only with Mac OS X? >=20 >Anyway..it's just a gut feeling I have as to what names people would look f= >or and find less surprising. >I was surprised by "Darwin", therefore would be.. :) >MacX is maybe a better compromise to be shorter. >or Macintosh for verbosity and without so many initials.. (NT386 may be sho= >rt and typable but every letter is a syllable and I think economy of syllab= >les is also important....(not clear if prounounced "eight" or "eighty") >Or maybe just Mac, assuming nobody thinks there will ever be a port to pre = >MacX, which could be called OldMac or MacClassic or Mac9 anyway if necessar= >y.. :) >=20 >LINUX, LINUXELF, LINUXLIBC6? Please. >Couldn't Linux have been recycled for LINUXLIBC6?Does anyone have Linux 1.2= > around? >That's the version I've run the most, long ago. :) >=20 >Anyway I don't care THAT much and I will resist suggesting any more names f= >or any preexisting targets or criticizing them. >They almost all stink, esp. the active ones. :) >Are the older FreeBSD ABIs so inferior that it is worth having newer ones? = >They didn't have pthreads back then and they do now? >=20 > - Jay > > > >> Date: Fri, 25 Jan 2008 11:09:59 +0100> From: wagner at elegosoft.com> To: m3= >devel at elegosoft.com> Subject: Re: [M3devel] INSTALL_ROOT and PKG_USE in cm3= >.cfg> > Quoting Jay :> > > using this code on PPC_LINU= >X and PPC_DARWIN (should be called > > PPC_MACOSX but oh well)> > Actually = >I did the port on a plain DARWIN system from opendarwin.org> when this was = >still alive. So there should be no dependency on MacOS X> extensions.> > Ol= >af> -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 2= >5 / 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 Cha= >rlottenburg HRB 77719 | USt-IdNr: DE163214194>=20 >_________________________________________________________________ >Helping your favorite cause is as easy as instant messaging.=A0You IM, we g= >ive. >http://im.live.com/Messenger/IM/Home/?source=3Dtext_hotmail_join= > >--_587094ee-5029-41f3-88b0-f4a35ad4e834_ >Content-Type: text/html; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > > > > >ok, but independent of what it's actual dependenc= >ies are...how many people run Darwin? How many people run Mac OS X? How man= >y people have heard of Darwin (not Charles)? How many people have heard of = >Mac OS X? Even among the unusual people who might read anything related to = >Modula-3 and own a Macintosh running Mac OS X? I know it's not a popul= >arity contest but.. NT386 should be called Windows. The name "NT" will prob= >ably gradually fade into obscurity and the name "Windows" will live on much= > longe. Posix and Unix will probably be forgotten and people will only have= > heard of "Linux".
> 
>The PPC_DARWIN port has an optional dependency on X Windows..is that availa= >ble for plain Darwin or only with Mac OS X?
> 
>Anyway..it's just a gut feeling I have as to what names people would look f= >or and find less surprising.
>I was surprised by "Darwin", therefore would be.. :)
>MacX is maybe a better compromise to be shorter.
>or Macintosh for verbosity and without so many initials.. (NT386 may be sho= >rt and typable but every letter is a syllable and I think economy of syllab= >les is also important....(not clear if prounounced "eight" or "eighty")
>Or maybe just Mac, assuming nobody thinks there will ever be a port to pre = >MacX, which could be called OldMac or MacClassic or Mac9 anyway if necessar= >y.. :)
> 
>LINUX, LINUXELF, LINUXLIBC6? Please.
>Couldn't Linux have been recycled for LINUXLIBC6?
Does anyone have Linux= > 1.2 around?
>That's the version I've run the most, long ago. :)
> 
>Anyway I don't care THAT much and I will resist suggesting any more names f= >or any preexisting targets or criticizing them.
>They almost all stink, esp. the active ones. :)
>Are the older FreeBSD ABIs so inferior that it is worth having newer ones? = >They didn't have pthreads back then and they do now?
> 
> - Jay


> >
>
>> Date: Fri, 25 Jan 2008 11:09:59 +0100
> From: wagner at elegosoft.c= >om
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] INSTALL= >_ROOT and PKG_USE in cm3.cfg
>
> Quoting Jay <jayk123 at hotma= >il.com>:
>
> > using this code on PPC_LINUX and PPC_DARW= >IN (should be called
> > PPC_MACOSX but oh well)
>
>= > Actually I did the port on a plain DARWIN system from opendarwin.org
&g= >t; when this was still alive. So there should be no dependency on MacOS XR>> extensions.
>
> 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 2= >345 869 fax: +49 30 23 45 86 95
> http://www.elegosoft.com | Gesch=E4= >ftsf=FChrer: Olaf Wagner | Sitz: Berlin
> Handelregister: Amtsgericht= > Charlottenburg HRB 77719 | USt-IdNr: DE163214194
>


/>Helping your favorite cause is as easy as instant messaging.=A0You IM, w= >e give. ail_join' target=3D'_new'>Learn more. >= > >--_587094ee-5029-41f3-88b0-f4a35ad4e834_-- From jayk123 at hotmail.com Fri Jan 25 11:39:19 2008 From: jayk123 at hotmail.com (Jay) Date: Fri, 25 Jan 2008 10:39:19 +0000 Subject: [M3devel] INSTALL_ROOT and PKG_USE in cm3.cfg In-Reply-To: <20080125112310.9qfns8rzx5gckgck@mail.elegosoft.com> References: <4798DEB8.1E75.00D7.1@scires.com> <4798EFAE.1E75.00D7.1@scires.com> <4798FE0E.1E75.00D7.1@scires.com> <479907A8.1E75.00D7.1@scires.com> <4799283C.1E75.00D7.1@scires.com> <20080125112310.9qfns8rzx5gckgck@mail.elegosoft.com> Message-ID: Oops I must have just misinterpreted that. executing, executable, .exe.. - Jay > Date: Fri, 25 Jan 2008 11:23:10 +0100> From: wagner at elegosoft.com> To: m3devel at elegosoft.com> Subject: Re: [M3devel] INSTALL_ROOT and PKG_USE in cm3.cfg> > Quoting Jay :> > I have seen path() return empty with some older builds, but not with > > current builds.> > Where I have seen it, I added in if defined() to cope and something > > more that I forget, maybe just the "normal" thing, like to bootstrap > > from an older build, and it gets overwritten during the bootstrap, > > once there is a current cm3.exe. I should check, I should check the > > history, and consistently workaround for all the files with this > > construct (ie. config-no-install and NT386).> >> > The documentation says it returns the path or directory of cm3.exe.> > But I did find that to be false, but the function is still useful. > > It seems to return the path of the current Quake code. I haven't > > looked at the implementation (yet).> > Where did you read that?> > http://modula3.elegosoft.com/cm3/doc/help/cm3/quake.html says> > path() Returns the directory of the currently executing file as a string> > Olaf> -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 Fri Jan 25 12:26:09 2008 From: jayk123 at hotmail.com (Jay) Date: Fri, 25 Jan 2008 11:26:09 +0000 Subject: [M3devel] INSTALL_ROOT and PKG_USE in cm3.cfg In-Reply-To: <200801251038.m0PAcHVv014819@camembert.async.caltech.edu> References: Your message of "Fri, 25 Jan 2008 10:29:28 GMT." <200801251038.m0PAcHVv014819@camembert.async.caltech.edu> Message-ID: true.. It looks like binary releases of Darwin are no longer made and apparently there are no instructions for building it from source...though that is the source presumably from which part of MacOSX is built.. > To: jayk123 at hotmail.com> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] INSTALL_ROOT and PKG_USE in cm3.cfg > Date: Fri, 25 Jan 2008 02:38:17 -0800> From: mika at async.caltech.edu> > I'm not sure about this MACOSX business.> > This is what I see when I log in to my Mac:> > (94)rover:~>ssh -Y lapdog> Last login: Tue Jan 22 00:33:21 2008 from rover> Welcome to Darwin!> [lapdog:~] mika% uname -a> Darwin lapdog 8.11.0 Darwin Kernel Version 8.11.0: Wed Oct 10 18:26:00 PDT 2007; root:xnu-792.24.17~1/RELEASE_PPC Power Macintosh powerpc> [lapdog:~] mika% > > > > Jay writes:> >--_587094ee-5029-41f3-88b0-f4a35ad4e834_> >Content-Type: text/plain; charset="iso-8859-1"> >Content-Transfer-Encoding: quoted-printable> >> >ok, but independent of what it's actual dependencies are...how many people => >run Darwin? How many people run Mac OS X? How many people have heard of Dar=> >win (not Charles)? How many people have heard of Mac OS X? Even among the u=> >nusual people who might read anything related to Modula-3 and own a Macinto=> >sh running Mac OS X? I know it's not a popularity contest but.. NT386 shoul=> >d be called Windows. The name "NT" will probably gradually fade into obscur=> >ity and the name "Windows" will live on much longe. Posix and Unix will pro=> >bably be forgotten and people will only have heard of "Linux".> >=20> >The PPC_DARWIN port has an optional dependency on X Windows..is that availa=> >ble for plain Darwin or only with Mac OS X?> >=20> >Anyway..it's just a gut feeling I have as to what names people would look f=> >or and find less surprising.> >I was surprised by "Darwin", therefore would be.. :)> >MacX is maybe a better compromise to be shorter.> >or Macintosh for verbosity and without so many initials.. (NT386 may be sho=> >rt and typable but every letter is a syllable and I think economy of syllab=> >les is also important....(not clear if prounounced "eight" or "eighty")> >Or maybe just Mac, assuming nobody thinks there will ever be a port to pre => >MacX, which could be called OldMac or MacClassic or Mac9 anyway if necessar=> >y.. :)> >=20> >LINUX, LINUXELF, LINUXLIBC6? Please.> >Couldn't Linux have been recycled for LINUXLIBC6?Does anyone have Linux 1.2=> > around?> >That's the version I've run the most, long ago. :)> >=20> >Anyway I don't care THAT much and I will resist suggesting any more names f=> >or any preexisting targets or criticizing them.> >They almost all stink, esp. the active ones. :)> >Are the older FreeBSD ABIs so inferior that it is worth having newer ones? => >They didn't have pthreads back then and they do now?> >=20> > - Jay> >> >> >> >> Date: Fri, 25 Jan 2008 11:09:59 +0100> From: wagner at elegosoft.com> To: m3=> >devel at elegosoft.com> Subject: Re: [M3devel] INSTALL_ROOT and PKG_USE in cm3=> >.cfg> > Quoting Jay :> > > using this code on PPC_LINU=> >X and PPC_DARWIN (should be called > > PPC_MACOSX but oh well)> > Actually => >I did the port on a plain DARWIN system from opendarwin.org> when this was => >still alive. So there should be no dependency on MacOS X> extensions.> > Ol=> >af> -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 2=> >5 / 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 Cha=> >rlottenburg HRB 77719 | USt-IdNr: DE163214194>=20> >_________________________________________________________________> >Helping your favorite cause is as easy as instant messaging.=A0You IM, we g=> >ive.> >http://im.live.com/Messenger/IM/Home/?source=3Dtext_hotmail_join=> >> >--_587094ee-5029-41f3-88b0-f4a35ad4e834_> >Content-Type: text/html; charset="iso-8859-1"> >Content-Transfer-Encoding: quoted-printable> >> >> >> >> >> >ok, but independent of what it's actual dependenc=> >ies are...how many people run Darwin? How many people run Mac OS X? How man=> >y people have heard of Darwin (not Charles)? How many people have heard of => >Mac OS X? Even among the unusual people who might read anything related to => >Modula-3 and own a Macintosh running Mac OS X? I know it's not a popul=> >arity contest but.. NT386 should be called Windows. The name "NT" will prob=> >ably gradually fade into obscurity and the name "Windows" will live on much=> > longe. Posix and Unix will probably be forgotten and people will only have=> > heard of "Linux".
> > 
> >The PPC_DARWIN port has an optional dependency on X Windows..is that availa=> >ble for plain Darwin or only with Mac OS X?
> > 
> >Anyway..it's just a gut feeling I have as to what names people would look f=> >or and find less surprising.
> >I was surprised by "Darwin", therefore would be.. :)
> >MacX is maybe a better compromise to be shorter.
> >or Macintosh for verbosity and without so many initials.. (NT386 may be sho=> >rt and typable but every letter is a syllable and I think economy of syllab=> >les is also important....(not clear if prounounced "eight" or "eighty")
> >Or maybe just Mac, assuming nobody thinks there will ever be a port to pre => >MacX, which could be called OldMac or MacClassic or Mac9 anyway if necessar=> >y.. :)
> > 
> >LINUX, LINUXELF, LINUXLIBC6? Please.
> >Couldn't Linux have been recycled for LINUXLIBC6?
Does anyone have Linux=> > 1.2 around?
> >That's the version I've run the most, long ago. :)
> > 
> >Anyway I don't care THAT much and I will resist suggesting any more names f=> >or any preexisting targets or criticizing them.
> >They almost all stink, esp. the active ones. :)
> >Are the older FreeBSD ABIs so inferior that it is worth having newer ones? => >They didn't have pthreads back then and they do now?
> > 
> > - Jay


> >> >
> >
> >> Date: Fri, 25 Jan 2008 11:09:59 +0100
> From: wagner at elegosoft.c=> >om
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] INSTALL=> >_ROOT and PKG_USE in cm3.cfg
>
> Quoting Jay <jayk123 at hotma=> >il.com>:
>
> > using this code on PPC_LINUX and PPC_DARW=> >IN (should be called
> > PPC_MACOSX but oh well)
>
>=> > Actually I did the port on a plain DARWIN system from opendarwin.org
&g=> >t; when this was still alive. So there should be no dependency on MacOS X >R>> extensions.
>
> 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 2=> >345 869 fax: +49 30 23 45 86 95
> http://www.elegosoft.com | Gesch=E4=> >ftsf=FChrer: Olaf Wagner | Sitz: Berlin
> Handelregister: Amtsgericht=> > Charlottenburg HRB 77719 | USt-IdNr: DE163214194
>


> />Helping your favorite cause is as easy as instant messaging.=A0You IM, w=> >e give. >ail_join' target=3D'_new'>Learn more.> >=> >> >--_587094ee-5029-41f3-88b0-f4a35ad4e834_-- _________________________________________________________________ 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 Fri Jan 25 13:36:49 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 25 Jan 2008 13:36:49 +0100 Subject: [M3devel] INSTALL_ROOT and PKG_USE in cm3.cfg In-Reply-To: References: <4798DEB8.1E75.00D7.1@scires.com> <4798EFAE.1E75.00D7.1@scires.com> <4798FE0E.1E75.00D7.1@scires.com> <479907A8.1E75.00D7.1@scires.com> <4799283C.1E75.00D7.1@scires.com> <20080125110959.5oc8u98w0w8csc80@mail.elegosoft.com> Message-ID: <20080125133649.vq9xj54iqok00so0@mail.elegosoft.com> I just wanted to point out why it's call PPC_DARWIN. Now that the OpenDarwin project has closed down, it may indeed seem strange. But many of the names can only be understood based on their history. I'm with you that they are neither systematic nor intuitive. I think I could even be persuaded to support a general renaming, if the scheme and concepts are well considered before. Quoting Jay : > The PPC_DARWIN port has an optional dependency on X Windows..is that > available for plain Darwin or only with Mac OS X? Yes. Actually the X in X Windows and MacOS X refer to completely different things. MacOS X does not support X Windows out of the box, it uses Aqua as GUI. > I was surprised by "Darwin", therefore would be.. :) That's why I tried to explain it ;-) > LINUX, LINUXELF, LINUXLIBC6? Please. > Couldn't Linux have been recycled for LINUXLIBC6?Does anyone have > Linux 1.2 around? It could be done now, but it couldn't when it was created. > Are the older FreeBSD ABIs so inferior that it is worth having newer > ones? They didn't have pthreads back then and they do now? There are ABI changes with every major release of FreeBSD (and also Linux, Solaris, and other operating systems if I am not much mistaken). Of course, everyone strives for compatibility of the often used and most important interfaces, but there is a grey zone where data structures common to the kernel and userland are touched, and they need to be updated (in order to not hinder improvement) more often than you'd think. If such an update annoys or disturbs users often enough, new interface abstractions tend to appear that should avoid the problem for future releases (for example, changes of the jmp_buf structure break threading code --> new interfaces for thread context access are defined). The M3 runtime is somewhat special and differs from the C runtime in that it makes use of quite a number of not always well-defined system interfaces. We also try to eliminate these dependencies (VM calls, jmp_buf structure, whole threading, ...) Actually I think I was the first one to port any pthread package to FreeBSD (when working for a company building POS solutions, but we could never release the code) back in the 1.5 and 2.x days. I used a pthreads implementation by Frank Mueller. Official pthread support came much later. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From hosking at cs.purdue.edu Fri Jan 25 15:28:46 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 25 Jan 2008 09:28:46 -0500 Subject: [M3devel] segmentation fault upon ./install-cm3-compiler.sh upgrade In-Reply-To: <47991720.1030307@elego.de> References: <4798FE9B.1090204@elego.de> <479905C8.7080003@elego.de> <20080124230322.vl12nlls4kosoocs@mail.elegosoft.com> <47990CFC.8080609@elego.de> <20080124233519.s3o34cbsmc8kocs8@mail.elegosoft.com> <479914EA.3060902@elego.de> <80025F80-FDA6-4E9D-AC2A-73C6498A6EA0@cs.purdue.edu> <47991720.1030307@elego.de> Message-ID: Build and ship packages in the following order: m3middle m3linker m3front m3quake cm3 This builds a bootstrap compiler using the *old* libraries. Use the binary this creates to build your system. On Jan 24, 2008, at 5:54 PM, Neels Janosch Hofmeyr wrote: > > Tony Hosking wrote: >> I'm pretty sure these problems are a result of needing to use a >> new bootstrap compiler. > How can I build one from source? (does this question make sense?) > > -- > Neels Janosch Hofmeyr > Software Developer > > neels at elego.de > Public Key: http://binarchy.net/neels/neels.hofmeyr.public.key.asc > > elego Software Solutions GmbH http://www.elegosoft.com > Gustav-Meyer-Allee 25, Geb?ude 12 HRB 77719 > 13355 Berlin, Germany Amtsgericht Charlottenburg > Tel.: +49 30 23 45 86 96 Sitz der Gesellschaft: Berlin > Fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Olaf Wagner > > From hosking at cs.purdue.edu Fri Jan 25 15:39:22 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 25 Jan 2008 09:39:22 -0500 Subject: [M3devel] INSTALL_ROOT and PKG_USE in cm3.cfg In-Reply-To: References: <4798DEB8.1E75.00D7.1@scires.com> <4798EFAE.1E75.00D7.1@scires.com> <4798FE0E.1E75.00D7.1@scires.com> <479907A8.1E75.00D7.1@scires.com> <4799283C.1E75.00D7.1@scires.com> <20080125110959.5oc8u98w0w8csc80@mail.elegosoft.com> Message-ID: <2157F648-47CC-4C3F-BD9E-07D14841C238@cs.purdue.edu> On Jan 25, 2008, at 5:29 AM, Jay wrote: > ok, but independent of what it's actual dependencies are...how many > people run Darwin? How many people run Mac OS X? How many people > have heard of Darwin (not Charles)? How many people have heard of > Mac OS X? Even among the unusual people who might read anything > related to Modula-3 and own a Macintosh running Mac OS X? I know > it's not a popularity contest but.. NT386 should be called Windows. > The name "NT" will probably gradually fade into obscurity and the > name "Windows" will live on much longe. Posix and Unix will > probably be forgotten and people will only have heard of "Linux". > > The PPC_DARWIN port has an optional dependency on X Windows..is > that available for plain Darwin or only with Mac OS X? Darwin makes sense given that it works on both MacOSX and open source Darwin. > Anyway..it's just a gut feeling I have as to what names people > would look for and find less surprising. > I was surprised by "Darwin", therefore would be.. :) Folks installing from source the way M3 requires generally are familiar with this terminology. If we had binary installers then naturally OSX would make sense. > MacX is maybe a better compromise to be shorter. > or Macintosh for verbosity and without so many initials.. (NT386 > may be short and typable but every letter is a syllable and I think > economy of syllables is also important....(not clear if prounounced > "eight" or "eighty") > Or maybe just Mac, assuming nobody thinks there will ever be a port > to pre MacX, which could be called OldMac or MacClassic or Mac9 > anyway if necessary.. :) > > LINUX, LINUXELF, LINUXLIBC6? Please. > Couldn't Linux have been recycled for LINUXLIBC6? > Does anyone have Linux 1.2 around? > That's the version I've run the most, long ago. :) You must understand that the naming schemes grew organically over the past 20 years or so (before Linux was even widely known!), and when Windows was definitely not NT and never would have supported M3. > Anyway I don't care THAT much and I will resist suggesting any more > names for any preexisting targets or criticizing them. > They almost all stink, esp. the active ones. :) > Are the older FreeBSD ABIs so inferior that it is worth having > newer ones? They didn't have pthreads back then and they do now? Keeping the old distros around with their old names is a convenient historical record that I have frequently used to implement functionality on new systems. For example, much of the current Solaris exception handling (which uses native stack unwinding rather than setjmp/longjmp) was derived from DS3100 and ALPHA_OSF! Remember, the average M3 installer from source will need to be somewhat familiar with the target names. We should also strive to allow easier installs from RPMS on Linux, Fink on OSX, and binary installers on Windows that will cater to the masses! > > > - Jay > > > > > Date: Fri, 25 Jan 2008 11:09:59 +0100 > > From: wagner at elegosoft.com > > To: m3devel at elegosoft.com > > Subject: Re: [M3devel] INSTALL_ROOT and PKG_USE in cm3.cfg > > > > Quoting Jay : > > > > > using this code on PPC_LINUX and PPC_DARWIN (should be called > > > PPC_MACOSX but oh well) > > > > Actually I did the port on a plain DARWIN system from opendarwin.org > > when this was still alive. So there should be no dependency on > MacOS X > > extensions. > > > > Olaf > > -- > > Olaf Wagner -- elego Software Solutions GmbH > > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 Fri Jan 25 15:40:00 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 25 Jan 2008 09:40:00 -0500 Subject: [M3devel] INSTALL_ROOT and PKG_USE in cm3.cfg In-Reply-To: <200801251038.m0PAcHVv014819@camembert.async.caltech.edu> References: <200801251038.m0PAcHVv014819@camembert.async.caltech.edu> Message-ID: <1A4B11E5-3935-4662-AD1F-CDFB0CB940CB@cs.purdue.edu> Precisely! On Jan 25, 2008, at 5:38 AM, Mika Nystrom wrote: > I'm not sure about this MACOSX business. > > This is what I see when I log in to my Mac: > > (94)rover:~>ssh -Y lapdog > Last login: Tue Jan 22 00:33:21 2008 from rover > Welcome to Darwin! > [lapdog:~] mika% uname -a > Darwin lapdog 8.11.0 Darwin Kernel Version 8.11.0: Wed Oct 10 > 18:26:00 PDT 2007; root:xnu-792.24.17~1/RELEASE_PPC Power Macintosh > powerpc > [lapdog:~] mika% > > > > Jay writes: >> --_587094ee-5029-41f3-88b0-f4a35ad4e834_ >> Content-Type: text/plain; charset="iso-8859-1" >> Content-Transfer-Encoding: quoted-printable >> >> ok, but independent of what it's actual dependencies are...how >> many people = >> run Darwin? How many people run Mac OS X? How many people have >> heard of Dar= >> win (not Charles)? How many people have heard of Mac OS X? Even >> among the u= >> nusual people who might read anything related to Modula-3 and own >> a Macinto= >> sh running Mac OS X? I know it's not a popularity contest but.. >> NT386 shoul= >> d be called Windows. The name "NT" will probably gradually fade >> into obscur= >> ity and the name "Windows" will live on much longe. Posix and Unix >> will pro= >> bably be forgotten and people will only have heard of "Linux". >> =20 >> The PPC_DARWIN port has an optional dependency on X Windows..is >> that availa= >> ble for plain Darwin or only with Mac OS X? >> =20 >> Anyway..it's just a gut feeling I have as to what names people >> would look f= >> or and find less surprising. >> I was surprised by "Darwin", therefore would be.. :) >> MacX is maybe a better compromise to be shorter. >> or Macintosh for verbosity and without so many initials.. (NT386 >> may be sho= >> rt and typable but every letter is a syllable and I think economy >> of syllab= >> les is also important....(not clear if prounounced "eight" or >> "eighty") >> Or maybe just Mac, assuming nobody thinks there will ever be a >> port to pre = >> MacX, which could be called OldMac or MacClassic or Mac9 anyway if >> necessar= >> y.. :) >> =20 >> LINUX, LINUXELF, LINUXLIBC6? Please. >> Couldn't Linux have been recycled for LINUXLIBC6?Does anyone have >> Linux 1.2= >> around? >> That's the version I've run the most, long ago. :) >> =20 >> Anyway I don't care THAT much and I will resist suggesting any >> more names f= >> or any preexisting targets or criticizing them. >> They almost all stink, esp. the active ones. :) >> Are the older FreeBSD ABIs so inferior that it is worth having >> newer ones? = >> They didn't have pthreads back then and they do now? >> =20 >> - Jay >> >> >> >>> Date: Fri, 25 Jan 2008 11:09:59 +0100> From: >>> wagner at elegosoft.com> To: m3= >> devel at elegosoft.com> Subject: Re: [M3devel] INSTALL_ROOT and >> PKG_USE in cm3= >> .cfg> > Quoting Jay :> > > using this code on >> PPC_LINU= >> X and PPC_DARWIN (should be called > > PPC_MACOSX but oh well)> > >> Actually = >> I did the port on a plain DARWIN system from opendarwin.org> when >> this was = >> still alive. So there should be no dependency on MacOS X> >> extensions.> > Ol= >> af> -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav- >> Meyer-Allee 2= >> 5 / 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 Cha= >> rlottenburg HRB 77719 | USt-IdNr: DE163214194>=20 >> _________________________________________________________________ >> Helping your favorite cause is as easy as instant messaging.=A0You >> IM, we g= >> ive. >> http://im.live.com/Messenger/IM/Home/?source=3Dtext_hotmail_join= >> >> --_587094ee-5029-41f3-88b0-f4a35ad4e834_ >> Content-Type: text/html; charset="iso-8859-1" >> Content-Transfer-Encoding: quoted-printable >> >> >> >> >> >> ok, but independent of what it's actual >> dependenc= >> ies are...how many people run Darwin? How many people run Mac OS >> X? How man= >> y people have heard of Darwin (not Charles)? How many people have >> heard of = >> Mac OS X? Even among the unusual people who might read anything >> related to = >> Modula-3 and own a Macintosh running Mac OS X? I know it's >> not a popul= >> arity contest but.. NT386 should be called Windows. The name "NT" >> will prob= >> ably gradually fade into obscurity and the name "Windows" will >> live on much= >> longe. Posix and Unix will probably be forgotten and people will >> only have= >> heard of "Linux".
>>  
>> The PPC_DARWIN port has an optional dependency on X Windows..is >> that availa= >> ble for plain Darwin or only with Mac OS X?
>>  
>> Anyway..it's just a gut feeling I have as to what names people >> would look f= >> or and find less surprising.
>> I was surprised by "Darwin", therefore would be.. :)
>> MacX is maybe a better compromise to be shorter.
>> or Macintosh for verbosity and without so many initials.. (NT386 >> may be sho= >> rt and typable but every letter is a syllable and I think economy >> of syllab= >> les is also important....(not clear if prounounced "eight" or >> "eighty")
>> Or maybe just Mac, assuming nobody thinks there will ever be a >> port to pre = >> MacX, which could be called OldMac or MacClassic or Mac9 anyway if >> necessar= >> y.. :)
>>  
>> LINUX, LINUXELF, LINUXLIBC6? Please.
>> Couldn't Linux have been recycled for LINUXLIBC6?
Does anyone >> have Linux= >> 1.2 around?
>> That's the version I've run the most, long ago. :)
>>  
>> Anyway I don't care THAT much and I will resist suggesting any >> more names f= >> or any preexisting targets or criticizing them.
>> They almost all stink, esp. the active ones. :)
>> Are the older FreeBSD ABIs so inferior that it is worth having >> newer ones? = >> They didn't have pthreads back then and they do now?
>>  
>>  - Jay


>> >>
>>
>> > Date: Fri, 25 Jan 2008 11:09:59 +0100
> From: >> wagner at elegosoft.c= >> om
> To: m3devel at elegosoft.com
> Subject: Re: >> [M3devel] INSTALL= >> _ROOT and PKG_USE in cm3.cfg
>
> Quoting Jay >> <jayk123 at hotma= >> il.com>:
>
> > using this code on PPC_LINUX and >> PPC_DARW= >> IN (should be called
> > PPC_MACOSX but oh well)
> >>
>= >> Actually I did the port on a plain DARWIN system from >> opendarwin.org
&g= >> t; when this was still alive. So there should be no dependency on >> MacOS X> R>> extensions.
>
> 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 2= >> 345 869 fax: +49 30 23 45 86 95
> http://www.elegosoft.com | >> Gesch=E4= >> ftsf=FChrer: Olaf Wagner | Sitz: Berlin
> Handelregister: >> Amtsgericht= >> Charlottenburg HRB 77719 | USt-IdNr: DE163214194
> >>


> />Helping your favorite cause is as easy as instant >> messaging.=A0You IM, w= >> e give. > source=3Dtext_hotm= >> ail_join' target=3D'_new'>Learn more. >> = >> >> --_587094ee-5029-41f3-88b0-f4a35ad4e834_-- From hosking at cs.purdue.edu Fri Jan 25 15:49:53 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 25 Jan 2008 09:49:53 -0500 Subject: [M3devel] INSTALL_ROOT and PKG_USE in cm3.cfg In-Reply-To: <1A4B11E5-3935-4662-AD1F-CDFB0CB940CB@cs.purdue.edu> References: <200801251038.m0PAcHVv014819@camembert.async.caltech.edu> <1A4B11E5-3935-4662-AD1F-CDFB0CB940CB@cs.purdue.edu> Message-ID: Latest Darwin source is still at http://www.opensource.apple.com/ darwinsource/ On Jan 25, 2008, at 9:40 AM, Tony Hosking wrote: > Precisely! > > On Jan 25, 2008, at 5:38 AM, Mika Nystrom wrote: > >> I'm not sure about this MACOSX business. >> >> This is what I see when I log in to my Mac: >> >> (94)rover:~>ssh -Y lapdog >> Last login: Tue Jan 22 00:33:21 2008 from rover >> Welcome to Darwin! >> [lapdog:~] mika% uname -a >> Darwin lapdog 8.11.0 Darwin Kernel Version 8.11.0: Wed Oct 10 >> 18:26:00 PDT 2007; root:xnu-792.24.17~1/RELEASE_PPC Power >> Macintosh powerpc >> [lapdog:~] mika% >> >> >> >> Jay writes: >>> --_587094ee-5029-41f3-88b0-f4a35ad4e834_ >>> Content-Type: text/plain; charset="iso-8859-1" >>> Content-Transfer-Encoding: quoted-printable >>> >>> ok, but independent of what it's actual dependencies are...how >>> many people = >>> run Darwin? How many people run Mac OS X? How many people have >>> heard of Dar= >>> win (not Charles)? How many people have heard of Mac OS X? Even >>> among the u= >>> nusual people who might read anything related to Modula-3 and own >>> a Macinto= >>> sh running Mac OS X? I know it's not a popularity contest but.. >>> NT386 shoul= >>> d be called Windows. The name "NT" will probably gradually fade >>> into obscur= >>> ity and the name "Windows" will live on much longe. Posix and >>> Unix will pro= >>> bably be forgotten and people will only have heard of "Linux". >>> =20 >>> The PPC_DARWIN port has an optional dependency on X Windows..is >>> that availa= >>> ble for plain Darwin or only with Mac OS X? >>> =20 >>> Anyway..it's just a gut feeling I have as to what names people >>> would look f= >>> or and find less surprising. >>> I was surprised by "Darwin", therefore would be.. :) >>> MacX is maybe a better compromise to be shorter. >>> or Macintosh for verbosity and without so many initials.. (NT386 >>> may be sho= >>> rt and typable but every letter is a syllable and I think economy >>> of syllab= >>> les is also important....(not clear if prounounced "eight" or >>> "eighty") >>> Or maybe just Mac, assuming nobody thinks there will ever be a >>> port to pre = >>> MacX, which could be called OldMac or MacClassic or Mac9 anyway >>> if necessar= >>> y.. :) >>> =20 >>> LINUX, LINUXELF, LINUXLIBC6? Please. >>> Couldn't Linux have been recycled for LINUXLIBC6?Does anyone have >>> Linux 1.2= >>> around? >>> That's the version I've run the most, long ago. :) >>> =20 >>> Anyway I don't care THAT much and I will resist suggesting any >>> more names f= >>> or any preexisting targets or criticizing them. >>> They almost all stink, esp. the active ones. :) >>> Are the older FreeBSD ABIs so inferior that it is worth having >>> newer ones? = >>> They didn't have pthreads back then and they do now? >>> =20 >>> - Jay >>> >>> >>> >>>> Date: Fri, 25 Jan 2008 11:09:59 +0100> From: >>>> wagner at elegosoft.com> To: m3= >>> devel at elegosoft.com> Subject: Re: [M3devel] INSTALL_ROOT and >>> PKG_USE in cm3= >>> .cfg> > Quoting Jay :> > > using this code >>> on PPC_LINU= >>> X and PPC_DARWIN (should be called > > PPC_MACOSX but oh well)> > >>> Actually = >>> I did the port on a plain DARWIN system from opendarwin.org> when >>> this was = >>> still alive. So there should be no dependency on MacOS X> >>> extensions.> > Ol= >>> af> -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav- >>> Meyer-Allee 2= >>> 5 / 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 Cha= >>> rlottenburg HRB 77719 | USt-IdNr: DE163214194>=20 >>> _________________________________________________________________ >>> Helping your favorite cause is as easy as instant >>> messaging.=A0You IM, we g= >>> ive. >>> http://im.live.com/Messenger/IM/Home/?source=3Dtext_hotmail_join= >>> >>> --_587094ee-5029-41f3-88b0-f4a35ad4e834_ >>> Content-Type: text/html; charset="iso-8859-1" >>> Content-Transfer-Encoding: quoted-printable >>> >>> >>> >>> >>> >>> ok, but independent of what it's actual >>> dependenc= >>> ies are...how many people run Darwin? How many people run Mac OS >>> X? How man= >>> y people have heard of Darwin (not Charles)? How many people have >>> heard of = >>> Mac OS X? Even among the unusual people who might read anything >>> related to = >>> Modula-3 and own a Macintosh running Mac OS X? I know it's >>> not a popul= >>> arity contest but.. NT386 should be called Windows. The name "NT" >>> will prob= >>> ably gradually fade into obscurity and the name "Windows" will >>> live on much= >>> longe. Posix and Unix will probably be forgotten and people will >>> only have= >>> heard of "Linux".
>>>  
>>> The PPC_DARWIN port has an optional dependency on X Windows..is >>> that availa= >>> ble for plain Darwin or only with Mac OS X?
>>>  
>>> Anyway..it's just a gut feeling I have as to what names people >>> would look f= >>> or and find less surprising.
>>> I was surprised by "Darwin", therefore would be.. :)
>>> MacX is maybe a better compromise to be shorter.
>>> or Macintosh for verbosity and without so many initials.. (NT386 >>> may be sho= >>> rt and typable but every letter is a syllable and I think economy >>> of syllab= >>> les is also important....(not clear if prounounced "eight" or >>> "eighty")
>>> Or maybe just Mac, assuming nobody thinks there will ever be a >>> port to pre = >>> MacX, which could be called OldMac or MacClassic or Mac9 anyway >>> if necessar= >>> y.. :)
>>>  
>>> LINUX, LINUXELF, LINUXLIBC6? Please.
>>> Couldn't Linux have been recycled for LINUXLIBC6?
Does anyone >>> have Linux= >>> 1.2 around?
>>> That's the version I've run the most, long ago. :)
>>>  
>>> Anyway I don't care THAT much and I will resist suggesting any >>> more names f= >>> or any preexisting targets or criticizing them.
>>> They almost all stink, esp. the active ones. :)
>>> Are the older FreeBSD ABIs so inferior that it is worth having >>> newer ones? = >>> They didn't have pthreads back then and they do now?
>>>  
>>>  - Jay


>>> >>>
>>>
>>> > Date: Fri, 25 Jan 2008 11:09:59 +0100
> From: >>> wagner at elegosoft.c= >>> om
> To: m3devel at elegosoft.com
> Subject: Re: >>> [M3devel] INSTALL= >>> _ROOT and PKG_USE in cm3.cfg
>
> Quoting Jay >>> <jayk123 at hotma= >>> il.com>:
>
> > using this code on PPC_LINUX >>> and PPC_DARW= >>> IN (should be called
> > PPC_MACOSX but oh well) >>>
>
>= >>> Actually I did the port on a plain DARWIN system from >>> opendarwin.org
&g= >>> t; when this was still alive. So there should be no dependency on >>> MacOS X>> R>> extensions.
>
> 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 2= >>> 345 869 fax: +49 30 23 45 86 95
> http://www.elegosoft.com >>> | Gesch=E4= >>> ftsf=FChrer: Olaf Wagner | Sitz: Berlin
> Handelregister: >>> Amtsgericht= >>> Charlottenburg HRB 77719 | USt-IdNr: DE163214194
> >>>


>> />Helping your favorite cause is as easy as instant >>> messaging.=A0You IM, w= >>> e give. >> source=3Dtext_hotm= >>> ail_join' target=3D'_new'>Learn more. >>> = >>> >>> --_587094ee-5029-41f3-88b0-f4a35ad4e834_-- From jayk123 at hotmail.com Fri Jan 25 16:07:20 2008 From: jayk123 at hotmail.com (Jay) Date: Fri, 25 Jan 2008 15:07:20 +0000 Subject: [M3devel] INSTALL_ROOT and PKG_USE in cm3.cfg In-Reply-To: <20080125133649.vq9xj54iqok00so0@mail.elegosoft.com> References: <4798DEB8.1E75.00D7.1@scires.com> <4798EFAE.1E75.00D7.1@scires.com> <4798FE0E.1E75.00D7.1@scires.com> <479907A8.1E75.00D7.1@scires.com> <4799283C.1E75.00D7.1@scires.com> <20080125110959.5oc8u98w0w8csc80@mail.elegosoft.com> <20080125133649.vq9xj54iqok00so0@mail.elegosoft.com> Message-ID: > I'm with you that they are neither systematic nor intuitive.> I think I could even be persuaded to support a general renaming,> if the scheme and concepts are well considered before. Uh oh... [big ramble...] Darwin: I was surprised, but I understood. I know a lot of the history and I get it. I used the LINUXELF port briefly, or maybe the LINUX (a.out) one. I guess hypothetically you can still boot LINUX 1.2 on either modern hardware or VMs?????? Anyone reporting 10 year uptimes?? Unix ABI: I'm surprised the compat is so bad. Microsoft does an excellent job of ABI compat, but behavioral compat is another matter. > Yes. Actually the X in X Windows and MacOS X refer to completely different> things. MacOS X does not support X Windows out of the box, it uses> Aqua as GUI. I understand. I believe Aqua is mostly just a marketing term even. Apple's got a bazillion different libraries to do the same thing. Want to draw on the screen -- QuickDraw (deprecated) or CoreGraphics, OpenGL.. Want to have a text editor -- TextEdit, MSLTE, and something else, and third party like "WASTE". Want to get a mouse click -- there's two event managers. Want to open a file -- there's like four or more sets of APIs -- FSSpec, FSRef, stdio, unixio, maybe something in Cocoa. Even in the kernel they have multiple frameworks I believe. It appears to be a big random mishmash. They had two APIs for LoadLibrary/GetProcAddress, and then later add dlopen. A lot of this is historical too. They have history back to the early 1980s and they have migration story after migration story after migration story, gradually breaking all existing source code and binaries, but never eveything quite at once. At this point, nothing produced before around the year 2000 can run on an Intel Mac or a PowerPC Mac running 10.5. 10.4 on PowerPC could run stuff going way way back -- 68K even. People used to have access to video memory at fixed addresses, "low memory globals" all kinds of crazy stuff. (Really, I understand -- MacOS X is 10 or Unix. I don't know how/if they are ever going to get to 11. They were up to about version 10 via gradual incrementing through the years. System 7 was a breathrough kind of in the late 80's early 90's, System 7.1ish when the PPC came out in 1994, gradually up to around 7.5, then rapidly through 8 and 9 when Jobs returned before they release Mac OS X. I know a lot here..it's annoying... We had "fat Mac" circa 1984/1985 with 512meg and two floppy drives, a 68020 Mac II, etc. If you see the movie The Firm, when lawyer/actionhero Tom Cruise uses his computer, it plays the Mac floppy disk noise.) And by breathrough, I mean it actually sucked. They had no or nearly no protected memory user/kernel split until this century. Shared library sorts of things were loaded completely into memory at boot time generally. Microsoft beat them by 5+ years, Unix beat by far more. But now it's a fairly level playing field -- everyone has about the same architecture. Except all the low end (free) Unixes seemed to take forever to admit they needed threads, and I doubt any of them scale well. I think they resisted just to avoid being like NT, waiting and waiting and finally giving in, thus some of the ABI issues, no threads, "Linux threads", and finally NPTL -- native pthreads library -- kernel threads. And just when everyone arrived at the same place, along comes web apps distributed across a cluster, too many cores per chip for anyone to schedule... [editing has ripped things away from what they related oh well...] You can have all the smarts you want about your workload and manually schedule (fibers, vtalarm threads), but you'll never likely be able to control what CPU you are on and thus you will generally lose, unless there is only one CPU. I kind of assume we (the larger we m3devel, but indeed, perhaps every pair of developers :) ) would never be able to agree on names. I think the easiest to agree to plan is to leave it alone. But, um, I agree! If we, um, could agree on a scheme and set of names, I'd go for it. I am a little more optimistic than this...but I hesitate, briefly, to suggest... The GNU folks have a system, of triples or more recently quadruples. Something like processor-'hardware'-kernel, I forget and can't look now. 'hardware' seems to be 'unknown' or 'pc' a bunch, so I don't know what it is. uname seems to be the ingredients of most of this. i686-pc-cygwin i686-pc-nt i686-pc-linux ppc-mac-darwin? ppc-mac-classic 68k-mac-classic I figure to vet the design it helps to come up with many examples, even of platforms that don't matter. Maybe even to deal with the msdos mess, could be 16bit, 286, 386.. I agree with you that a double seems to almost always suffice. If you look at the existing names (from memory), I think you can derive something like: {X86,AMD64,PPC,PPC64,ALPHA,MIPS,ARM,SH,SPARC,68K,VAX,IA64,HPPA}_{LINUX,SOLARIS,NT,OSF1,OS2,NEXT,MSDOS,VMS,Mac,OldMac,AIX,HPUX,FreeBSD,NetBSD,OpenBSD} and cover almost the whole problem. This doesn't address the elephants that seems to have finally left the room -- compiler, linker, window library, thread library, C library, modula-3 backend. Probably most platforms should be a 2-tuple but there should guidance on how to build n-tuples. ?? x86-nt-msc-mslink-msgui-kthr-msvcr -- native just call it x86-nt ? x86-nt-gcc-gld-msgui-kthr-msvcr -- mingwin x86-nt-gcc-gld-xwin-kthr-cyg -- nt386gnu x86-nt-gcc-gld-xwin-pthr-cyg -- nt386gnu with pthreads x86-linux-gcc-gld-vga-nothr-newlibx86-linux-icc-glc-nowin-nptl-glibc -- icc Intel compiler x86-linux-gcc-gcc-qtopia-uthread-glibc These names are too long. The n-tuples open up many issues, such as variables that really almost never vary given what preceds them. Linux doesn't always use gcc, but almost. Or whether or not a configuration is link compatible with another. Varying the compiler tends not to break link compatibility, that isn't automatic, it isn't free i general, but the compiler authors usually make it so. You all can see if n-tuples matter for the vast majority of platforms, but they, perhaps matter for x86-nt. But there is a big huge out of this that is in place, as I have said many times.. platform is nt386, everything else is something else, a "configuration" perhaps. Perhaps there should be a few more quake variables specced that cm3 can/should know about. Perhaps all of the target dependencies should be moved into the configuration file?????? I think there's so little, it makes little difference either way. Perhaps the notion of target drops away entire in cm3 and it's all just configuration and has less meaning? I mean..you know, what is the meaning? it's jmpbuf size, it gcc configuration, it's build_dir, those strike me as the majority of what "target" means. alignment, integer-size (always 32...except alpha), whether to use the integrated backend, and if so, a few other variables. I haven't allowed for versions -- FreeBSD4, FreeBSD5, FreeBSD6. I also think, I hate to say, you might want to account for "fat binaries". On a Mac, you can build up for four architectures into one binary. x86,AMD64,PPC,PPC64. However that really strikes at my crazy cross idea and putting in .sh files that call out to the right binary. I heard NextStep/OpenStep ran on four architectures way back when -- 68k, x86, SPARC, HPPA, not to mention the variant the x86 variant that ran in NT (with gcc). Even Win32 lets you build hybrid 16bit/32bit or 16bit/64bit binaries, since there is an "MS-DOS" stub. This is why, of course, you end up with ad-hoc names. Because the extra variables are usually missing, and they vary differently depending on context, so just make up something. Perhaps you use the doubles I gave, and then you are allowed to append a dash and an arbitrary extra string. Oh, sorry, you already said that. You called it "variant". I guess that's it. {x86,AMD64,...}_{NT,SOLARIS,LINUX}{_optional variant} Here are some possible names from this system: X86_NT (WIN? MSWIN?) X86_NT_MINGNU X86_NT_GNU X86_SOLARIS X86_SOLARIS_GNU SPARC_SOLARIS SPARC_SOLARIS_GNU PPC_MAC X86_MAC AMD64_MAC PPC64_MAC IA64_VMS VAX_VMS ALPHA_VMS MIPS_ULTRIX MIPS_IRIX IA64_NT AMD64_NT MIPS_NT PPC_NT PPC_XBOX ? X86_XBOX ? PPC_AIX (Is POWER interesting?) PPC601_AIX ? PPC603_AIX ? G3_MAC ? G4_MAC ? G5_MAC ? PPCG3_MAC ? PPCG4_MAC ? (doesn't run on G3) PPCG4_MAC ? (64 bit, lame names...) X86_MSDOS ? X86_DJGPP ? X86_NT_MWERKS ? X86_NT_DIGITALMARS ? X86_NT_SYMANTEC ? X86_NT_BORLAND ? C_NT ? outputs C code... hm. not right, C gets converted to something else. ALPHA_OSF1 ALPHA_TRU64 ? ALPHA32_NT ? X86_NT_WATCOM ? X86_WINCE ? ARM_WINCE ? ARM_CE ? ARM_MSCE ? ARM_SYMBIAN ? ARM_PALM ? ARM_PALMOS ? X86_BEOS ? 68000_OLDMAC ? 68020_OLDMAC ? Obviously the vast vast vast vast majority of these don't matter, but as I said it helps to see how a bunch of platforms work out to vet the design. I've held back from...6502_APPLEII, 65816_APPLEIIGS.. 6502_C64 :) 65816_SNES ? (Super Nintendo game console) 6502_NES ? (Nintendo...) MIPS_PLAYSTATION ? ?_SONYPS2 ? PPC_SONYPS3 (Linux runs on this, and maybe previous) SH_DREAMCAST ? (NetBSD runs on this... as does CE) X86_XBOX ? MSBOX ? PPC_XBOX360 (or is it PPC64? Oh, and for these things, you probably need to say MS or LINUX) PPC_MSXBOX360 PPC_?XBOX and maybe some virtual machine targets: JVM_ANY ?JAVA_ANY ? MSDOTNET_ANY ?MSIL_ANY ? LLVM_NT ? Is x86 generically named and people can tweak it. Or call it 686 or I686 and if anyone really has an old processor, they can still tweak and rename and keep the name. Sorry if this is all very annoying. I'm ok with doing nothing here. Ultimately as I said, there isn't even that much code involved, as I recall. It seems to me if you move about 50 lines of cm3 out of cm3 into quake, the matter becomes even less "important", because the config file would be the only thing that cared and would only need to make sense to itself. - Jay > Date: Fri, 25 Jan 2008 13:36:49 +0100> From: wagner at elegosoft.com> To: jayk123 at hotmail.com> CC: m3devel at elegosoft.com> Subject: RE: [M3devel] INSTALL_ROOT and PKG_USE in cm3.cfg> > I just wanted to point out why it's call PPC_DARWIN. Now that the> OpenDarwin project has closed down, it may indeed seem strange.> But many of the names can only be understood based on their history.> I'm with you that they are neither systematic nor intuitive.> I think I could even be persuaded to support a general renaming,> if the scheme and concepts are well considered before.> > Quoting Jay :> > > The PPC_DARWIN port has an optional dependency on X Windows..is that > > available for plain Darwin or only with Mac OS X?> > Yes. Actually the X in X Windows and MacOS X refer to completely different> things. MacOS X does not support X Windows out of the box, it uses> Aqua as GUI.> > > I was surprised by "Darwin", therefore would be.. :)> That's why I tried to explain it ;-)> > > LINUX, LINUXELF, LINUXLIBC6? Please.> > Couldn't Linux have been recycled for LINUXLIBC6?Does anyone have > > Linux 1.2 around?> > It could be done now, but it couldn't when it was created.> > > Are the older FreeBSD ABIs so inferior that it is worth having newer > > ones? They didn't have pthreads back then and they do now?> > There are ABI changes with every major release of FreeBSD (and also> Linux, Solaris, and other operating systems if I am not much mistaken).> Of course, everyone strives for compatibility of the often used and> most important interfaces, but there is a grey zone where data> structures common to the kernel and userland are touched, and they> need to be updated (in order to not hinder improvement) more often> than you'd think. If such an update annoys or disturbs users often> enough, new interface abstractions tend to appear that should> avoid the problem for future releases (for example, changes of the> jmp_buf structure break threading code --> new interfaces for thread> context access are defined). The M3 runtime is somewhat special and> differs from the C runtime in that it makes use of quite a number of not> always well-defined system interfaces. We also try to eliminate these> dependencies (VM calls, jmp_buf structure, whole threading, ...)> > Actually I think I was the first one to port any pthread package to> FreeBSD (when working for a company building POS solutions, but we could> never release the code) back in the 1.5 and 2.x days. I used a pthreads> implementation by Frank Mueller.> Official pthread support came much later.> > Olaf> -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194> _________________________________________________________________ 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 Jan 25 16:13:20 2008 From: jayk123 at hotmail.com (Jay) Date: Fri, 25 Jan 2008 15:13:20 +0000 Subject: [M3devel] INSTALL_ROOT and PKG_USE in cm3.cfg In-Reply-To: References: <200801251038.m0PAcHVv014819@camembert.async.caltech.edu> <1A4B11E5-3935-4662-AD1F-CDFB0CB940CB@cs.purdue.edu> Message-ID: Is it usable?buildable? I don't think so but I am curious. Maybe research later, but there are way more pressing matters... I'm fine either way. I think I've said more than my piece, many times over. :) Very cathartic, and less damaging than doing anything to the code. :) Yes yes, I know the names but I don't know what others would know. And I know renaming makes tracking history hard, depending on source control, but pretty much no matter what. This is a huge reason not to rename. History can be super valuable. That's why I took forever to get over the hump and push all the NT386 content into NT386.Common instead of doing it a bit earlier, and I'm still not sure it was a good idea. The code is highly shared though. Perhaps it should be smushed all into NT386 in the source tree and three variants extracted in the build. NT386 seems to have the fewest people that give a damn so... - Jay > From: hosking at cs.purdue.edu> Date: Fri, 25 Jan 2008 09:49:53 -0500> To: hosking at cs.purdue.edu> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] INSTALL_ROOT and PKG_USE in cm3.cfg> > Latest Darwin source is still at http://www.opensource.apple.com/ > darwinsource/> > On Jan 25, 2008, at 9:40 AM, Tony Hosking wrote:> > > Precisely!> >> > On Jan 25, 2008, at 5:38 AM, Mika Nystrom wrote:> >> >> I'm not sure about this MACOSX business.> >>> >> This is what I see when I log in to my Mac:> >>> >> (94)rover:~>ssh -Y lapdog> >> Last login: Tue Jan 22 00:33:21 2008 from rover> >> Welcome to Darwin!> >> [lapdog:~] mika% uname -a> >> Darwin lapdog 8.11.0 Darwin Kernel Version 8.11.0: Wed Oct 10 > >> 18:26:00 PDT 2007; root:xnu-792.24.17~1/RELEASE_PPC Power > >> Macintosh powerpc> >> [lapdog:~] mika%> >>> >>> >>> >> Jay writes:> >>> --_587094ee-5029-41f3-88b0-f4a35ad4e834_> >>> Content-Type: text/plain; charset="iso-8859-1"> >>> Content-Transfer-Encoding: quoted-printable> >>>> >>> ok, but independent of what it's actual dependencies are...how > >>> many people => >>> run Darwin? How many people run Mac OS X? How many people have > >>> heard of Dar=> >>> win (not Charles)? How many people have heard of Mac OS X? Even > >>> among the u=> >>> nusual people who might read anything related to Modula-3 and own > >>> a Macinto=> >>> sh running Mac OS X? I know it's not a popularity contest but.. > >>> NT386 shoul=> >>> d be called Windows. The name "NT" will probably gradually fade > >>> into obscur=> >>> ity and the name "Windows" will live on much longe. Posix and > >>> Unix will pro=> >>> bably be forgotten and people will only have heard of "Linux".> >>> =20> >>> The PPC_DARWIN port has an optional dependency on X Windows..is > >>> that availa=> >>> ble for plain Darwin or only with Mac OS X?> >>> =20> >>> Anyway..it's just a gut feeling I have as to what names people > >>> would look f=> >>> or and find less surprising.> >>> I was surprised by "Darwin", therefore would be.. :)> >>> MacX is maybe a better compromise to be shorter.> >>> or Macintosh for verbosity and without so many initials.. (NT386 > >>> may be sho=> >>> rt and typable but every letter is a syllable and I think economy > >>> of syllab=> >>> les is also important....(not clear if prounounced "eight" or > >>> "eighty")> >>> Or maybe just Mac, assuming nobody thinks there will ever be a > >>> port to pre => >>> MacX, which could be called OldMac or MacClassic or Mac9 anyway > >>> if necessar=> >>> y.. :)> >>> =20> >>> LINUX, LINUXELF, LINUXLIBC6? Please.> >>> Couldn't Linux have been recycled for LINUXLIBC6?Does anyone have > >>> Linux 1.2=> >>> around?> >>> That's the version I've run the most, long ago. :)> >>> =20> >>> Anyway I don't care THAT much and I will resist suggesting any > >>> more names f=> >>> or any preexisting targets or criticizing them.> >>> They almost all stink, esp. the active ones. :)> >>> Are the older FreeBSD ABIs so inferior that it is worth having > >>> newer ones? => >>> They didn't have pthreads back then and they do now?> >>> =20> >>> - Jay> >>>> >>>> >>>> >>>> Date: Fri, 25 Jan 2008 11:09:59 +0100> From: > >>>> wagner at elegosoft.com> To: m3=> >>> devel at elegosoft.com> Subject: Re: [M3devel] INSTALL_ROOT and > >>> PKG_USE in cm3=> >>> .cfg> > Quoting Jay :> > > using this code > >>> on PPC_LINU=> >>> X and PPC_DARWIN (should be called > > PPC_MACOSX but oh well)> > > >>> Actually => >>> I did the port on a plain DARWIN system from opendarwin.org> when > >>> this was => >>> still alive. So there should be no dependency on MacOS X> > >>> extensions.> > Ol=> >>> af> -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav- > >>> Meyer-Allee 2=> >>> 5 / 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 Cha=> >>> rlottenburg HRB 77719 | USt-IdNr: DE163214194>=20> >>> _________________________________________________________________> >>> Helping your favorite cause is as easy as instant > >>> messaging.=A0You IM, we g=> >>> ive.> >>> http://im.live.com/Messenger/IM/Home/?source=3Dtext_hotmail_join=> >>>> >>> --_587094ee-5029-41f3-88b0-f4a35ad4e834_> >>> Content-Type: text/html; charset="iso-8859-1"> >>> Content-Transfer-Encoding: quoted-printable> >>>> >>> > >>> > >>> > >>> > >>> ok, but independent of what it's actual > >>> dependenc=> >>> ies are...how many people run Darwin? How many people run Mac OS > >>> X? How man=> >>> y people have heard of Darwin (not Charles)? How many people have > >>> heard of => >>> Mac OS X? Even among the unusual people who might read anything > >>> related to => >>> Modula-3 and own a Macintosh running Mac OS X? I know it's > >>> not a popul=> >>> arity contest but.. NT386 should be called Windows. The name "NT" > >>> will prob=> >>> ably gradually fade into obscurity and the name "Windows" will > >>> live on much=> >>> longe. Posix and Unix will probably be forgotten and people will > >>> only have=> >>> heard of "Linux".
> >>>  
> >>> The PPC_DARWIN port has an optional dependency on X Windows..is > >>> that availa=> >>> ble for plain Darwin or only with Mac OS X?
> >>>  
> >>> Anyway..it's just a gut feeling I have as to what names people > >>> would look f=> >>> or and find less surprising.
> >>> I was surprised by "Darwin", therefore would be.. :)
> >>> MacX is maybe a better compromise to be shorter.
> >>> or Macintosh for verbosity and without so many initials.. (NT386 > >>> may be sho=> >>> rt and typable but every letter is a syllable and I think economy > >>> of syllab=> >>> les is also important....(not clear if prounounced "eight" or > >>> "eighty")
> >>> Or maybe just Mac, assuming nobody thinks there will ever be a > >>> port to pre => >>> MacX, which could be called OldMac or MacClassic or Mac9 anyway > >>> if necessar=> >>> y.. :)
> >>>  
> >>> LINUX, LINUXELF, LINUXLIBC6? Please.
> >>> Couldn't Linux have been recycled for LINUXLIBC6?
Does anyone > >>> have Linux=> >>> 1.2 around?
> >>> That's the version I've run the most, long ago. :)
> >>>  
> >>> Anyway I don't care THAT much and I will resist suggesting any > >>> more names f=> >>> or any preexisting targets or criticizing them.
> >>> They almost all stink, esp. the active ones. :)
> >>> Are the older FreeBSD ABIs so inferior that it is worth having > >>> newer ones? => >>> They didn't have pthreads back then and they do now?
> >>>  
> >>>  - Jay


> >>>> >>>
> >>>
> >>> > Date: Fri, 25 Jan 2008 11:09:59 +0100
> From: > >>> wagner at elegosoft.c=> >>> om
> To: m3devel at elegosoft.com
> Subject: Re: > >>> [M3devel] INSTALL=> >>> _ROOT and PKG_USE in cm3.cfg
>
> Quoting Jay > >>> <jayk123 at hotma=> >>> il.com>:
>
> > using this code on PPC_LINUX > >>> and PPC_DARW=> >>> IN (should be called
> > PPC_MACOSX but oh well) > >>>
>
>=> >>> Actually I did the port on a plain DARWIN system from > >>> opendarwin.org
&g=> >>> t; when this was still alive. So there should be no dependency on > >>> MacOS X >>> R>> extensions.
>
> 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 2=> >>> 345 869 fax: +49 30 23 45 86 95
> http://www.elegosoft.com > >>> | Gesch=E4=> >>> ftsf=FChrer: Olaf Wagner | Sitz: Berlin
> Handelregister: > >>> Amtsgericht=> >>> Charlottenburg HRB 77719 | USt-IdNr: DE163214194
> > >>>


>>> />Helping your favorite cause is as easy as instant > >>> messaging.=A0You IM, w=> >>> e give. >>> source=3Dtext_hotm=> >>> ail_join' target=3D'_new'>Learn more.> >>> => >>>> >>> --_587094ee-5029-41f3-88b0-f4a35ad4e834_--> _________________________________________________________________ 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 Jan 25 16:14:06 2008 From: jayk123 at hotmail.com (Jay) Date: Fri, 25 Jan 2008 15:14:06 +0000 Subject: [M3devel] INSTALL_ROOT and PKG_USE in cm3.cfg In-Reply-To: References: <4798DEB8.1E75.00D7.1@scires.com> <4798EFAE.1E75.00D7.1@scires.com> <4798FE0E.1E75.00D7.1@scires.com> <479907A8.1E75.00D7.1@scires.com> <4799283C.1E75.00D7.1@scires.com> <20080125110959.5oc8u98w0w8csc80@mail.elegosoft.com> <20080125133649.vq9xj54iqok00so0@mail.elegosoft.com> Message-ID: truncated again! > From: jayk123 at hotmail.com> To: wagner at elegosoft.com> Date: Fri, 25 Jan 2008 15:07:20 +0000> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] INSTALL_ROOT and PKG_USE in cm3.cfg> > > I'm with you that they are neither systematic nor intuitive.> I think I could even be persuaded to support a general renaming,> if the scheme and concepts are well considered before.> Uh oh...> [big ramble...]> > Darwin: I was surprised, but I understood.> > I know a lot of the history and I get it.> I used the LINUXELF port briefly, or maybe the LINUX (a.out) one.> I guess hypothetically you can still boot LINUX 1.2 on either modern hardware or VMs??????> Anyone reporting 10 year uptimes??> > Unix ABI: I'm surprised the compat is so bad. Microsoft does an excellent job of ABI compat, but behavioral compat is another matter.> > > Yes. Actually the X in X Windows and MacOS X refer to completely different> things. MacOS X does not support X Windows out of the box, it uses> Aqua as GUI.> I understand. I believe Aqua is mostly just a marketing term even.> Apple's got a bazillion different libraries to do the same thing.> Want to draw on the screen -- QuickDraw (deprecated) or CoreGraphics, OpenGL..> Want to have a text editor -- TextEdit, MSLTE, and something else, and third party like "WASTE".> Want to get a mouse click -- there's two event managers.> Want to open a file -- there's like four or more sets of APIs -- FSSpec, FSRef, stdio, unixio, maybe something in Cocoa.> Even in the kernel they have multiple frameworks I believe.> It appears to be a big random mishmash.> They had two APIs for LoadLibrary/GetProcAddress, and then later add dlopen _________________________________________________________________ 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 Jan 25 16:21:26 2008 From: jayk123 at hotmail.com (Jay) Date: Fri, 25 Jan 2008 15:21:26 +0000 Subject: [M3devel] FW: INSTALL_ROOT and PKG_USE in cm3.cfg In-Reply-To: <20080125133649.vq9xj54iqok00so0@mail.elegosoft.com> References: <4798DEB8.1E75.00D7.1@scires.com> <4798EFAE.1E75.00D7.1@scires.com> <4798FE0E.1E75.00D7.1@scires.com> <479907A8.1E75.00D7.1@scires.com> <4799283C.1E75.00D7.1@scires.com> <20080125110959.5oc8u98w0w8csc80@mail.elegosoft.com> <20080125133649.vq9xj54iqok00so0@mail.elegosoft.com> Message-ID: This was truncated, and there is a little of value perhaps...except probably just leave all the targets alone and focus on the much less disruptive decision for how to name all the many future targets. :) and the more productive work of bringing them up (I'm thinking, after NT386GNUish stuff, of looking into PPC_{NETBSD,OPENBSD} or NBSD,OBSD. I've got the hardware and the CDs at least.. and then if I'm feeling crazy, X86_DJGPP aka X86_MSDOS or such, and then X86_SOLARIS maybe..I've got X86 and PPC32 you see, grasping at where to go...oh, and AMD64_NT, AMD64_SOLARIS does that exist? Might have to get a new machine for that, but as long as its available in laptop form factor I'm game. (AMD64_F|N|OBSD too, I wonder if AMD64_DJGPP will materialize :) oh but this takes wasting money but AMD64_DARWIN; OLPC is en route but I don't think that merits work, it's just X86_LINUX, I mean LINUXLIBC6.. :) ). No idea how far I'll get here but they are thoughts at least. And fix the Pixmap bug... I basically below just agree with what Olaf already said -- processor-os-variant. Variant is "random", but doing better is probably impossible, and variant is bound to be needed somewhere sometime. And it can be empty so no harm. - Jay From: jayk123 at hotmail.comTo: wagner at elegosoft.comCC: m3devel at elegosoft.comSubject: RE: [M3devel] INSTALL_ROOT and PKG_USE in cm3.cfgDate: Fri, 25 Jan 2008 15:07:20 +0000 > I'm with you that they are neither systematic nor intuitive.> I think I could even be persuaded to support a general renaming,> if the scheme and concepts are well considered before.Uh oh...[big ramble...] Darwin: I was surprised, but I understood. I know a lot of the history and I get it.I used the LINUXELF port briefly, or maybe the LINUX (a.out) one.I guess hypothetically you can still boot LINUX 1.2 on either modern hardware or VMs??????Anyone reporting 10 year uptimes?? Unix ABI: I'm surprised the compat is so bad. Microsoft does an excellent job of ABI compat, but behavioral compat is another matter. > Yes. Actually the X in X Windows and MacOS X refer to completely different> things. MacOS X does not support X Windows out of the box, it uses> Aqua as GUI.I understand. I believe Aqua is mostly just a marketing term even.Apple's got a bazillion different libraries to do the same thing.Want to draw on the screen -- QuickDraw (deprecated) or CoreGraphics, OpenGL..Want to have a text editor -- TextEdit, MSLTE, and something else, and third party like "WASTE".Want to get a mouse click -- there's two event managers.Want to open a file -- there's like four or more sets of APIs -- FSSpec, FSRef, stdio, unixio, maybe something in Cocoa.Even in the kernel they have multiple frameworks I believe.It appears to be a big random mishmash.They had two APIs for LoadLibrary/GetProcAddress, and then later add dlopen.A lot of this is historical too.They have history back to the early 1980s and they have migration story after migration story after migration story, gradually breaking all existing source code and binaries, but never eveything quite at once. At this point, nothing produced before around the year 2000 can run on an Intel Mac or a PowerPC Mac running 10.5. 10.4 on PowerPC could run stuff going way way back -- 68K even. People used to have access to video memory at fixed addresses, "low memory globals" all kinds of crazy stuff. (Really, I understand -- MacOS X is 10 or Unix. I don't know how/if they are ever going to get to 11. They were up to about version 10 via gradual incrementing through the years. System 7 was a breathrough kind of in the late 80's early 90's, System 7.1ish when the PPC came out in 1994, gradually up to around 7.5, then rapidly through 8 and 9 when Jobs returned before they release Mac OS X. I know a lot here..it's annoying... We had "fat Mac" circa 1984/1985 with 512meg and two floppy drives, a 68020 Mac II, etc.If you see the movie The Firm, when lawyer/actionhero Tom Cruise uses his computer, it plays the Mac floppy disk noise.)And by breathrough, I mean it actually sucked. They had no or nearly no protected memory user/kernel split until this century. Shared library sorts of things were loaded completely into memory at boot time generally. Microsoft beat them by 5+ years, Unix beat by far more. But now it's a fairly level playing field -- everyone has about the same architecture. Except all the low end (free) Unixes seemed to take forever to admit they needed threads, and I doubt any of them scale well. I think they resisted just to avoid being like NT, waiting and waiting and finally giving in, thus some of the ABI issues, no threads, "Linux threads", and finally NPTL -- native pthreads library -- kernel threads. And just when everyone arrived at the same place, along comes web apps distributed across a cluster, too many cores per chip for anyone to schedule... [editing has ripped things away from what they related oh well...] You can have all the smarts you want about your workload and manually schedule (fibers, vtalarm threads), but you'll never likely be able to control what CPU you are on and thus you will generally lose, unless there is only one CPU. I kind of assume we (the larger we m3devel, but indeed, perhaps every pair of developers :) ) would never be able to agree on names. I think the easiest to agree to plan is to leave it alone.But, um, I agree! If we, um, could agree on a scheme and set of names, I'd go for it.I am a little more optimistic than this...but I hesitate, briefly, to suggest... The GNU folks have a system, of triples or more recently quadruples.Something like processor-'hardware'-kernel, I forget and can't look now.'hardware' seems to be 'unknown' or 'pc' a bunch, so I don't know what it is.uname seems to be the ingredients of most of this.i686-pc-cygwini686-pc-nti686-pc-linuxppc-mac-darwin?ppc-mac-classic68k-mac-classic I figure to vet the design it helps to come up with many examples, even of platforms that don't matter.Maybe even to deal with the msdos mess, could be 16bit, 286, 386.. I agree with you that a double seems to almost always suffice. If you look at the existing names (from memory), I think you can derive something like:{X86,AMD64,PPC,PPC64,ALPHA,MIPS,ARM,SH,SPARC,68K,VAX,IA64,HPPA}_{LINUX,SOLARIS,NT,OSF1,OS2,NEXT,MSDOS,VMS,Mac,OldMac,AIX,HPUX,FreeBSD,NetBSD,OpenBSD} and cover almost the whole problem. This doesn't address the elephants that seems to have finally left the room -- compiler, linker, window library, thread library, C library, modula-3 backend. Probably most platforms should be a 2-tuple but there should guidance on how to build n-tuples.?? x86-nt-msc-mslink-msgui-kthr-msvcr -- native just call it x86-nt ?x86-nt-gcc-gld-msgui-kthr-msvcr -- mingwinx86-nt-gcc-gld-xwin-kthr-cyg -- nt386gnux86-nt-gcc-gld-xwin-pthr-cyg -- nt386gnu with pthreadsx86-linux-gcc-gld-vga-nothr-newlibx86-linux-icc-glc-nowin-nptl-glibc -- icc Intel compilerx86-linux-gcc-gcc-qtopia-uthread-glibc These names are too long. The n-tuples open up many issues, such as variables that really almost never vary given what preceds them.Linux doesn't always use gcc, but almost.Or whether or not a configuration is link compatible with another.Varying the compiler tends not to break link compatibility, that isn't automatic, it isn't free i general, but the compiler authors usually make it so. You all can see if n-tuples matter for the vast majority of platforms, but they, perhaps matter for x86-nt.But there is a big huge out of this that is in place, as I have said many times.. platform is nt386, everything else is something else, a "configuration" perhaps. Perhaps there should be a few more quake variables specced that cm3 can/should know about. Perhaps all of the target dependencies should be moved into the configuration file?????? I think there's so little, it makes little difference either way. Perhaps the notion of target drops away entire in cm3 and it's all just configuration and has less meaning?I mean..you know, what is the meaning? it's jmpbuf size, it gcc configuration, it's build_dir, those strike me as the majority of what "target" means. alignment, integer-size (always 32...except alpha), whether to use the integrated backend, and if so, a few other variables. I haven't allowed for versions -- FreeBSD4, FreeBSD5, FreeBSD6. I also think, I hate to say, you might want to account for "fat binaries".On a Mac, you can build up for four architectures into one binary.x86,AMD64,PPC,PPC64.However that really strikes at my crazy cross idea and putting in .sh files that call out to the right binary.I heard NextStep/OpenStep ran on four architectures way back when -- 68k, x86, SPARC, HPPA, not to mention the variant the x86 variant that ran in NT (with gcc). Even Win32 lets you build hybrid 16bit/32bit or 16bit/64bit binaries, since there is an "MS-DOS" stub. This is why, of course, you end up with ad-hoc names. Because the extra variables are usually missing, and they vary differently depending on context, so just make up something. Perhaps you use the doubles I gave, and then you are allowed to append a dash and an arbitrary extra string.Oh, sorry, you already said that. You called it "variant". I guess that's it. {x86,AMD64,...}_{NT,SOLARIS,LINUX}{_optional variant} Here are some possible names from this system: X86_NT (WIN? MSWIN?)X86_NT_MINGNUX86_NT_GNUX86_SOLARISX86_SOLARIS_GNUSPARC_SOLARISSPARC_SOLARIS_GNUPPC_MACX86_MACAMD64_MACPPC64_MACIA64_VMSVAX_VMSALPHA_VMSMIPS_ULTRIXMIPS_IRIXIA64_NTAMD64_NTMIPS_NTPPC_NTPPC_XBOX ?X86_XBOX ?PPC_AIX (Is POWER interesting?)PPC601_AIX ?PPC603_AIX ?G3_MAC ?G4_MAC ?G5_MAC ?PPCG3_MAC ?PPCG4_MAC ? (doesn't run on G3)PPCG4_MAC ? (64 bit, lame names...)X86_MSDOS ?X86_DJGPP ? X86_NT_MWERKS ?X86_NT_DIGITALMARS ?X86_NT_SYMANTEC ?X86_NT_BORLAND ?C_NT ? outputs C code... hm. not right, C gets converted to something else.ALPHA_OSF1 ALPHA_TRU64 ?ALPHA32_NT ?X86_NT_WATCOM ?X86_WINCE ?ARM_WINCE ?ARM_CE ?ARM_MSCE ?ARM_SYMBIAN ?ARM_PALM ?ARM_PALMOS ?X86_BEOS ?68000_OLDMAC ?68020_OLDMAC ? Obviously the vast vast vast vast majority of these don't matter, but as I said it helps to see how a bunch of platforms work out to vet the design. I've held back from...6502_APPLEII, 65816_APPLEIIGS.. 6502_C64 :)65816_SNES ? (Super Nintendo game console) 6502_NES ? (Nintendo...)MIPS_PLAYSTATION ??_SONYPS2 ?PPC_SONYPS3 (Linux runs on this, and maybe previous) SH_DREAMCAST ? (NetBSD runs on this... as does CE)X86_XBOX ? MSBOX ?PPC_XBOX360 (or is it PPC64? Oh, and for these things, you probably need to say MS or LINUX)PPC_MSXBOX360PPC_?XBOX and maybe some virtual machine targets:JVM_ANY ?JAVA_ANY ?MSDOTNET_ANY ?MSIL_ANY ?LLVM_NT ? Is x86 generically named and people can tweak it. Or call it 686 or I686 and if anyone really has an old processor, they can still tweak and rename and keep the name. Sorry if this is all very annoying. I'm ok with doing nothing here. Ultimately as I said, there isn't even that much code involved, as I recall.It seems to me if you move about 50 lines of cm3 out of cm3 into quake, the matter becomes even less "important", because the config file would be the only thing that cared and would only need to make sense to itself. - Jay > Date: Fri, 25 Jan 2008 13:36:49 +0100> From: wagner at elegosoft.com> To: jayk123 at hotmail.com> CC: m3devel at elegosoft.com> Subject: RE: [M3devel] INSTALL_ROOT and PKG_USE in cm3.cfg> > I just wanted to point out why it's call PPC_DARWIN. Now that the> OpenDarwin project has closed down, it may indeed seem strange.> But many of the names can only be understood based on their history.> I'm with you that they are neither systematic nor intuitive.> I think I could even be persuaded to support a general renaming,> if the scheme and concepts are well considered before.> > Quoting Jay :> > > The PPC_DARWIN port has an optional dependency on X Windows..is that > > available for plain Darwin or only with Mac OS X?> > Yes. Actually the X in X Windows and MacOS X refer to completely different> things. MacOS X does not support X Windows out of the box, it uses> Aqua as GUI.> > > I was surprised by "Darwin", therefore would be.. :)> That's why I tried to explain it ;-)> > > LINUX, LINUXELF, LINUXLIBC6? Please.> > Couldn't Linux have been recycled for LINUXLIBC6?Does anyone have > > Linux 1.2 around?> > It could be done now, but it couldn't when it was created.> > > Are the older FreeBSD ABIs so inferior that it is worth having newer > > ones? They didn't have pthreads back then and they do now?> > There are ABI changes with every major release of FreeBSD (and also> Linux, Solaris, and other operating systems if I am not much mistaken).> Of course, everyone strives for compatibility of the often used and> most important interfaces, but there is a grey zone where data> structures common to the kernel and userland are touched, and they> need to be updated (in order to not hinder improvement) more often> than you'd think. If such an update annoys or disturbs users often> enough, new interface abstractions tend to appear that should> avoid the problem for future releases (for example, changes of the> jmp_buf structure break threading code --> new interfaces for thread> context access are defined). The M3 runtime is somewhat special and> differs from the C runtime in that it makes use of quite a number of not> always well-defined system interfaces. We also try to eliminate these> dependencies (VM calls, jmp_buf structure, whole threading, ...)> > Actually I think I was the first one to port any pthread package to> FreeBSD (when working for a company building POS solutions, but we could> never release the code) back in the 1.5 and 2.x days. I used a pthreads> implementation by Frank Mueller.> Official pthread support came much later.> > Olaf> -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194> Helping your favorite cause is as easy as instant messaging. You IM, we give. Learn more. _________________________________________________________________ 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 Jan 25 16:41:31 2008 From: jayk123 at hotmail.com (Jay) Date: Fri, 25 Jan 2008 15:41:31 +0000 Subject: [M3devel] m3devel vs. m3support? In-Reply-To: <20080125133649.vq9xj54iqok00so0@mail.elegosoft.com> References: <4798DEB8.1E75.00D7.1@scires.com> <4798EFAE.1E75.00D7.1@scires.com> <4798FE0E.1E75.00D7.1@scires.com> <479907A8.1E75.00D7.1@scires.com> <4799283C.1E75.00D7.1@scires.com> <20080125110959.5oc8u98w0w8csc80@mail.elegosoft.com> <20080125133649.vq9xj54iqok00so0@mail.elegosoft.com> Message-ID: I noticed at the end of the Ubuntu instructions: "see m3-support for help" Which got me thinking: Is m3devel for developers who USE m3, or the developers OF m3. I'm not sure. In particular, is it lower level, discussing how to bring up new targets, how to change the compiler or higher level help with learning the language? Is m3support for support of developers who use m3 (as indicated above), or for infrastructure support for developer OF m3, like fixing networking connectivity to birch or unusual stuff like that? I thought it was the second. AND/OR m3devel is both, if you were to split in half, you'd only have 2 people on each list and you wouldn't need a list? :) (somewhat the small community is a bonus for me, fewer people to piss off if I make a mistake, somewhat it is depressingly small...) - 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 wagner at elegosoft.com Fri Jan 25 18:02:37 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 25 Jan 2008 18:02:37 +0100 Subject: [M3devel] m3devel vs. m3support? In-Reply-To: References: <4798DEB8.1E75.00D7.1@scires.com> <4798EFAE.1E75.00D7.1@scires.com> <4798FE0E.1E75.00D7.1@scires.com> <479907A8.1E75.00D7.1@scires.com> <4799283C.1E75.00D7.1@scires.com> <20080125110959.5oc8u98w0w8csc80@mail.elegosoft.com> <20080125133649.vq9xj54iqok00so0@mail.elegosoft.com> Message-ID: <20080125180237.xderhsyo00wgksgo@mail.elegosoft.com> Quoting Jay : > I noticed at the end of the Ubuntu instructions: > "see m3-support for help" > > Which got me thinking: > > Is m3devel for developers who USE m3, or the developers OF m3. > I'm not sure. In particular, is it lower level, discussing how to > bring up new targets, how to change the compiler > or higher level help with learning the language? > > Is m3support for support of developers who use m3 (as indicated > above), or for infrastructure support for developer OF m3, like > fixing networking connectivity to birch or unusual stuff like that? > I thought it was the second. > > AND/OR m3devel is both, if you were to split in half, you'd only > have 2 people on each list and you wouldn't need a list? :) > > (somewhat the small community is a bonus for me, fewer people to > piss off if I make a mistake, somewhat it is depressingly small...) m3devel was created for developers of M3 and developers using M3. It's a rather technical group. You need to subscribe to it to be able to post. m3-support is (currently) an Elego-internal list of M3-capable users willing to help anybody running into problems with the system. It is basically just a sendmail alias as far as I know, so everybody can freely send mail to it. There is no archive of the mails (or I don't know of it). m3-support is used on all the M3 WWW pages. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Sat Jan 26 07:11:28 2008 From: mika at async.caltech.edu (Mika Nystrom) Date: Fri, 25 Jan 2008 22:11:28 -0800 Subject: [M3devel] INSTALL_ROOT and PKG_USE in cm3.cfg In-Reply-To: Your message of "Fri, 25 Jan 2008 13:36:49 +0100." <20080125133649.vq9xj54iqok00so0@mail.elegosoft.com> Message-ID: <200801260611.m0Q6BS8r045276@camembert.async.caltech.edu> >> LINUX, LINUXELF, LINUXLIBC6? Please. >> Couldn't Linux have been recycled for LINUXLIBC6?Does anyone have >> Linux 1.2 around? > >It could be done now, but it couldn't when it was created. Please don't recycle the names. That's just dumb. More people than you'd think use old hardware and software for reasons that may be out of their control. Mika From jayk123 at hotmail.com Sat Jan 26 10:13:35 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 26 Jan 2008 09:13:35 +0000 Subject: [M3devel] INSTALL_ROOT and PKG_USE in cm3.cfg In-Reply-To: <200801260611.m0Q6BS8r045276@camembert.async.caltech.edu> References: Your message of "Fri, 25 Jan 2008 13:36:49 +0100." <20080125133649.vq9xj54iqok00so0@mail.elegosoft.com> <200801260611.m0Q6BS8r045276@camembert.async.caltech.edu> Message-ID: I'm on the fence. People always miss that changing new software doesn't necessarily impact old software/hardware. Do the LINUX/LINUXELF targets still work? Will they ever again? If they did, couldn't they be renamed as well? X86_LINUX (LINUXLIBC6) X86_LINUX1 or X86_LINUX1_ELF X86_LINUX1_AOUT 1 as in kernel 1.x Or possibly even merged with one and only X86_LINUX and just vary in the configuration file. (Does the codegen even vary across these architectures, or just the the linking options and maybe file format output by as?) Name evolution is tough. There's often some ideal short name Foo and then only in the future you realize you have to differentiate NewAndImprovedFoo or FooX or Foo2 from Foo aka FooClassic aka Foo1 aka OldFoo. FooSr, FooJr, FooIII. Historical records I think are the bigger sale. But sometimes you are just left with cruft upon cruft upon cruft for some hypothetical compat. In this case, it's not a big deal. - Jay > To: wagner at elegosoft.com> Date: Fri, 25 Jan 2008 22:11:28 -0800> From: mika at async.caltech.edu> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] INSTALL_ROOT and PKG_USE in cm3.cfg> > >> LINUX, LINUXELF, LINUXLIBC6? Please.> >> Couldn't Linux have been recycled for LINUXLIBC6?Does anyone have > >> Linux 1.2 around?> >> >It could be done now, but it couldn't when it was created.> > Please don't recycle the names. That's just dumb. More people> than you'd think use old hardware and software for reasons that may> be out of their control.> > Mika _________________________________________________________________ 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 Sun Jan 27 15:03:27 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Sun, 27 Jan 2008 15:03:27 +0100 Subject: [M3devel] Open CM3 regression tests In-Reply-To: <9C00EA97-9B43-43BE-9CDF-EEAC9C1321D5@cs.purdue.edu> References: <20080120211832.GA26993@elegosoft.com> <9C00EA97-9B43-43BE-9CDF-EEAC9C1321D5@cs.purdue.edu> Message-ID: <20080127150327.mh686v2hx4w080w4@mail.elegosoft.com> Quoting Tony Hosking : > The set operations are all coded as external C functions -- should be > easy enough to fix those. Or are there type issues too? Sorry for the long delay. I'm afraid I don't really understand how set operations are implemented after a quick look. I thought it was all done in the Word modules, but these seem to be only self-referring M3 definitions. I'm sure you can point me to the correct location for the >= operation faster than I'll need to find it; I'll have a look at it then. Thanks in advance, Olaf >> --- p155 --- operations on small sets >> --- p1/p155/stderr.pgm 2008-01-20 00:48:16.000000000 +0100 >> +++ ../src/p1/p155/stderr.pgm 2008-01-13 00:55:56.000000000 +0100 >> @@ -2,7 +2,6 @@ >> check set q = {} >> check set r = {a, b} >> check set x = {a, b, e} >> -************************ ERROR: check (NOT (p >= x)) failed >> >>> This concerns the >= operation on sets. The language definition >>> says: >>> >>> infix <=, >= (x,y: Ordinal) : BOOLEAN >>> (x,y: Float) : BOOLEAN >>> (x,y: ADDRESS) : BOOLEAN >>> (x,y: Set) : BOOLEAN >>> >>> In the first three cases, <= returns TRUE if x is at most as large as >>> y. In the last case, <= returns TRUE if every element of x is an >>> element of y. In all cases, it is a static error if the type of x is >>> not assignable to the type of y, or vice versa. The expression x >= y >>> is equivalent to y <= x. >>> >>> So the implementation seems to be plainly wrong. I think the test >>> for the previous operation <= only succeeds accidentally. -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Jan 27 15:26:35 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Sun, 27 Jan 2008 15:26:35 +0100 Subject: [M3devel] Open CM3 regression tests In-Reply-To: References: <20080120211832.GA26993@elegosoft.com> Message-ID: <20080127152635.91rtdsvgsoo4080g@mail.elegosoft.com> Quoting Henning Thielemann : > On Sun, 20 Jan 2008, Olaf Wagner wrote: > >> > no errors for p1 to p115 >> >> --- p116b --- default IEEE floating point tests from Xerox PARC >> --- p1/p116b/stderr.pgm 2008-01-20 00:47:20.000000000 +0100 >> +++ ../src/p1/p116b/stderr.pgm 2008-01-13 00:55:55.000000000 +0100 > > My compiler complains about LONGINT type in src/Test.i3 . I assume that > this is the 64 bit support. Seems that I have to upgrade my compiler. > > In general floating point is a strange issue. You cannot rely on that your > machine supports IEEE format, although most machines do. The precision of > the same float type can be different on different machines. However, the > Float modules shall reflect that. Computation with NaN and Infinity is > broken, it should be avoided and in most cases continueing the computation > with NaN or Infinity only hides the precise error location. It would be > better to abort with an error for a division by zero, overflow and so on. > I think one can enable this with FloatModes. I don't really understand the consequences of what you say above: are the tests wrong and should be adapted, or is the implementation broken for IEEE-default (where most of the FloatMode procedures simply raise exceptions; if so, can we fix that for these platforms), or do we simply rely on broken hardware (x86 floating point processors)? It seems that FloatMode is only implemented for very few targets: DS3100 DS3100_OSF IRIX5 SOLsun SPARC SUN386 VAX. All the others use the default. Will we simply have to implement the missing functionality for all platforms? If so, can e.g. SUN386 be easily adapted to other x86 platforms (FreeBSD4, LINUXLIBC6, I386_DARWIN, NetBSD2_i386)? That would be a start. As I said, I'm no expert in this domain, and would rather rely on others knowledge there. If you don't have a compiler that is up-to-date, you can always use workspaces on birch.elegosoft.com for tests. The regression tests on this machine use CM3 installations at m3 at birch:~/cm3$ ls /home/m3/work/cm3-inst/birch.elegosoft.com/ current last-ok prev-ok rel-5.4.0. If you don't have login access but need it, just let me know. Of course this applies to everybody wanting to work on the tests or other improvements (as long as there aren't hundreds of requests at least :-). Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Sun Jan 27 15:52:04 2008 From: mika at async.caltech.edu (Mika Nystrom) Date: Sun, 27 Jan 2008 06:52:04 -0800 Subject: [M3devel] Open CM3 regression tests In-Reply-To: Your message of "Sun, 27 Jan 2008 15:26:35 +0100." <20080127152635.91rtdsvgsoo4080g@mail.elegosoft.com> Message-ID: <200801271452.m0REq4Oi093531@camembert.async.caltech.edu> Olaf Wagner writes: ... >I don't really understand the consequences of what you say above: >are the tests wrong and should be adapted, or is the implementation >broken for IEEE-default (where most of the FloatMode procedures simply >raise exceptions; if so, can we fix that for these platforms), or do >we simply rely on broken hardware (x86 floating point processors)? > >It seems that FloatMode is only implemented for very few targets: >DS3100 DS3100_OSF IRIX5 SOLsun SPARC SUN386 VAX. All the others use >the default. Will we simply have to implement the missing functionality >for all platforms? If so, can e.g. SUN386 be easily adapted to other >x86 platforms (FreeBSD4, LINUXLIBC6, I386_DARWIN, NetBSD2_i386)? >That would be a start. Hmm this reminds me of something I read a long time ago. My recollection is that what we have is effectively the second implementation of floating point in Modula-3. At some point during the design, I think someone talked to Bill Kahan, and he (or someone like him) persuaded them that the only right way to do floating-point is to provide an interface for turning on and off floating point exceptions. I believe that at least on DS3100, the floating point exceptions (if enabled) are actually turned into bona fide, catch-able, Modula-3 exceptions. It's a little odd because I suppose you can have code like this... TRY x := a/b EXCEPT SomeFloatingException ... END even though no exceptions are declared to be RAISEd anywhere... I think very few programming languages actually support IEEE754 the way Kahan originally envisioned it. Modula-3 on DS3100 is one of the few that actually approach the original intent (most of the others have "fortran" somewhere in their names, and usually only accomplish the goal with compiler flags). It would be very neat if this work could be extended to the modern targets. x86 FP also isn't really that broken---the 8087 was actually to some extent the reference implementation of IEEE754. It works fine if you write back the results between operations. The problem is that it uses higher (EXTENDED) precision internally, so if you keep intermediate values in FP registers you get smaller rounding errors than expected. It's mainly a problem if you are doing step-by-step comparison debugging with an x86 and a non-x86 and you can't somehow tell your compiler to flush intermediate results to memory. Mika From hosking at cs.purdue.edu Sun Jan 27 16:36:04 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 27 Jan 2008 10:36:04 -0500 Subject: [M3devel] Open CM3 regression tests In-Reply-To: <20080127150327.mh686v2hx4w080w4@mail.elegosoft.com> References: <20080120211832.GA26993@elegosoft.com> <9C00EA97-9B43-43BE-9CDF-EEAC9C1321D5@cs.purdue.edu> <20080127150327.mh686v2hx4w080w4@mail.elegosoft.com> Message-ID: <1DA9FA59-6DFF-430C-90C5-F1D30003607A@cs.purdue.edu> The set operations are coded in cm3/m3-libs/m3core/src/Csupport/ Common/hand.c. I notice Jay has made a number of changes here since September -- I wonder if they have broken something. On Jan 27, 2008, at 9:03 AM, Olaf Wagner wrote: > Quoting Tony Hosking : >> The set operations are all coded as external C functions -- should be >> easy enough to fix those. Or are there type issues too? > > Sorry for the long delay. I'm afraid I don't really understand how > set operations are implemented after a quick look. I thought it was > all done in the Word modules, but these seem to be only self-referring > M3 definitions. I'm sure you can point me to the correct location for > the >= operation faster than I'll need to find it; I'll have a look at > it then. > > Thanks in advance, > > Olaf > >>> --- p155 --- operations on small sets >>> --- p1/p155/stderr.pgm 2008-01-20 00:48:16.000000000 +0100 >>> +++ ../src/p1/p155/stderr.pgm 2008-01-13 00:55:56.000000000 +0100 >>> @@ -2,7 +2,6 @@ >>> check set q = {} >>> check set r = {a, b} >>> check set x = {a, b, e} >>> -************************ ERROR: check (NOT (p >= x)) failed >>> >>>> This concerns the >= operation on sets. The language definition >>>> says: >>>> >>>> infix <=, >= (x,y: Ordinal) : BOOLEAN >>>> (x,y: Float) : BOOLEAN >>>> (x,y: ADDRESS) : BOOLEAN >>>> (x,y: Set) : BOOLEAN >>>> >>>> In the first three cases, <= returns TRUE if x is at most as >>>> large as >>>> y. In the last case, <= returns TRUE if every element of x is an >>>> element of y. In all cases, it is a static error if the type of >>>> x is >>>> not assignable to the type of y, or vice versa. The expression x >>>> >= y >>>> is equivalent to y <= x. >>>> >>>> So the implementation seems to be plainly wrong. I think the test >>>> for the previous operation <= only succeeds accidentally. > > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, > Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 > 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: > Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > DE163214194 > From roland.illig at gmx.de Sun Jan 27 17:23:02 2008 From: roland.illig at gmx.de (Roland Illig) Date: Sun, 27 Jan 2008 17:23:02 +0100 Subject: [M3devel] reactor: catalyst vs cm3-ide In-Reply-To: <479223AC.1E75.00D7.1@scires.com> References: <479223AC.1E75.00D7.1@scires.com> Message-ID: <479CAFE6.8050601@gmx.de> Randy Coleburn wrote: > Ok, I've gotten some feedback on the new name for reactor. > > I've attached a PDF that has two pages: one depicts use of Catalyst, > the other CM3-IDE. > > Please let me know which you prefer. If these are going to become logos of any kind, I don't like them both. - They use lots of different font shapes and sizes. This makes the image rather complicated. A logo should use at most one font shape. - There are lots of components in the logo. To view them all, it takes a long time. A logo should be as simple that one can recognize it at a glance. - What does the battery have to do with Modula-3? - How does it relate to the light bulb? - What does the "With Power" on the light bulb mean? Is it important for the logo? - Is there any prior art for these kinds of logos? Roland From dmuysers at hotmail.com Sun Jan 27 18:02:05 2008 From: dmuysers at hotmail.com (Dirk Muysers) Date: Sun, 27 Jan 2008 18:02:05 +0100 Subject: [M3devel] reactor: catalyst vs cm3-ide In-Reply-To: <479223AC.1E75.00D7.1@scires.com> <479CAFE6.8050601@gmx.de> References: <479223AC.1E75.00D7.1@scires.com> <479CAFE6.8050601@gmx.de> Message-ID: What others have done along the same lines: Have a look at the Cocotron (http://www.cocotron.org/Info) -------------------------------------------------- From: "Roland Illig" Sent: Sunday, January 27, 2008 5:23 PM To: "Randy Coleburn" Cc: Subject: Re: [M3devel] reactor: catalyst vs cm3-ide > Randy Coleburn wrote: >> Ok, I've gotten some feedback on the new name for reactor. >> I've attached a PDF that has two pages: one depicts use of Catalyst, >> the other CM3-IDE. >> Please let me know which you prefer. > > If these are going to become logos of any kind, I don't like them both. > > - They use lots of different font shapes and sizes. This makes the image > rather complicated. A logo should use at most one font shape. > > - There are lots of components in the logo. To view them all, it takes a > long time. A logo should be as simple that one can recognize it at a > glance. > > - What does the battery have to do with Modula-3? > > - How does it relate to the light bulb? > > - What does the "With Power" on the light bulb mean? Is it important for > the logo? > > - Is there any prior art for these kinds of logos? > > Roland > From wagner at elegosoft.com Sun Jan 27 18:55:30 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Sun, 27 Jan 2008 18:55:30 +0100 Subject: [M3devel] Open CM3 regression tests In-Reply-To: <1DA9FA59-6DFF-430C-90C5-F1D30003607A@cs.purdue.edu> References: <20080120211832.GA26993@elegosoft.com> <9C00EA97-9B43-43BE-9CDF-EEAC9C1321D5@cs.purdue.edu> <20080127150327.mh686v2hx4w080w4@mail.elegosoft.com> <1DA9FA59-6DFF-430C-90C5-F1D30003607A@cs.purdue.edu> Message-ID: <20080127185530.e255i76vcwckss4o@mail.elegosoft.com> Quoting Tony Hosking : > The set operations are coded in > cm3/m3-libs/m3core/src/Csupport/Common/hand.c. > > I notice Jay has made a number of changes here since September -- I > wonder if they have broken something. I tried different revisions of this file with no difference in the test results. I then took the latest version and added some printfs, and they got never displayed. So I checked what gets linked, but the symbols in question don't occur in the test program: % nm hand.o U __divdi3 U __moddi3 000001e0 R _highbits 00000140 R _lowbits 00000000 T m3_div 000000ac T m3_divL 000001d4 T m3_mod 0000026c T m3_modL U printf 00000494 T set_difference 00000554 T set_eq 0000061c T set_ge 000006ac T set_gt 00000434 T set_intersection 0000077c T set_le 0000080c T set_lt 000003a8 T set_member 000005b8 T set_ne 000008d8 T set_range 000009d8 T set_singleton 000004f4 T set_sym_difference 000003d4 T set_union % nm /usr/local/cm3/pkg/m3core/FreeBSD4/libm3core.so.5 | grep set_ 000243d0 T set_difference 00024490 T set_eq 00024558 T set_ge 000245fc T set_gt 00024370 T set_intersection 000246e0 T set_le 00024784 T set_lt 000242e4 T set_member 000244f4 T set_ne 00024864 T set_range 00024998 T set_singleton 00024430 T set_sym_difference 00024310 T set_union % ldd FreeBSD4/p1/p155/FreeBSD4/pgm FreeBSD4/p1/p155/FreeBSD4/pgm: libtest.so.5 => /d/home/wagner/work/cm3/m3-sys/m3tests/FreeBSD4/libtest.so.5 (0x28085000) libm3.so.5 => /usr/local/cm3/pkg/libm3/FreeBSD4/libm3.so.5 (0x28088000) libm3core.so.5 => /usr/local/cm3/pkg/m3core/FreeBSD4/libm3core.so.5 (0x281aa000) libm.so.4 => /lib/libm.so.4 (0x28a2d000) libpthread.so.2 => /lib/libpthread.so.2 (0x28a46000) libc.so.6 => /lib/libc.so.6 (0x28a6a000) % nm /usr/local/cm3/pkg/m3core/FreeBSD4/libm3core.so.5 | grep set_ 000243d0 T set_difference 00024490 T set_eq 00024558 T set_ge 000245fc T set_gt 00024370 T set_intersection 000246e0 T set_le 00024784 T set_lt 000242e4 T set_member 000244f4 T set_ne 00024864 T set_range 00024998 T set_singleton 00024430 T set_sym_difference 00024310 T set_union luthien [~/work/cm3/m3-sys/m3tests] wagner % ldd FreeBSD4/p1/p155/FreeBSD4/pgm FreeBSD4/p1/p155/FreeBSD4/pgm: libtest.so.5 => /d/home/wagner/work/cm3/m3-sys/m3tests/FreeBSD4/libtest.so.5 (0x28085000) libm3.so.5 => /usr/local/cm3/pkg/libm3/FreeBSD4/libm3.so.5 (0x28088000) libm3core.so.5 => /usr/local/cm3/pkg/m3core/FreeBSD4/libm3core.so.5 (0x281aa000) libm.so.4 => /lib/libm.so.4 (0x28a2d000) libpthread.so.2 => /lib/libpthread.so.2 (0x28a46000) libc.so.6 => /lib/libc.so.6 (0x28a6a000) luthien [~/work/cm3/m3-sys/m3tests] wagner % nm -C -u FreeBSD4/p1/p155/FreeBSD4/pgm U Main_I3 U RTHooks_I3 U RTHooks__CheckLoadTracedRef U RTHooks__Concat U RTHooks__PopEFrame U RTHooks__PushEFrame U RTHooks__TextLitGetChar U RTHooks__TextLitGetChars U RTHooks__TextLitGetWideChar U RTHooks__TextLitGetWideChars U RTHooks__TextLitInfo U RTLinker__AddUnit U RTLinker__InitRuntime U RTProcess__Exit U Stdio_I3 U Test_I3 U Test__checkM U Test__done U Wr_I3 U Wr__Flush U Wr__PutText w _Jv_RegisterClasses w __deregister_frame_info w __register_frame_info U _init_tls U _setjmp U atexit U exit Now I'm rather confused 8-/ Any ideas? Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From rcoleburn at scires.com Sun Jan 27 18:59:32 2008 From: rcoleburn at scires.com (Randy Coleburn) Date: Sun, 27 Jan 2008 12:59:32 -0500 Subject: [M3devel] reactor: catalyst vs cm3-ide In-Reply-To: <479CAFE6.8050601@gmx.de> References: <479223AC.1E75.00D7.1@scires.com> <479CAFE6.8050601@gmx.de> Message-ID: <479C8034.1E75.00D7.1@scires.com> Hi Roland: Thanks for your feedback and to the other folks that responded. At this point, I've elected to go with the CM3-IDE name instead of Catalyst. Despite the fact that several folks like "Catalyst" (it is a more catchy name and easier to pronounce), it did not intuitively convey the purpose of the program and it conflicts with another trademarked name in the industry. As for the graphics, I'm not a trained graphic artist or logo designer. I just tried to put something together that would satisfy the license requirements so we could make this software package available to the community. One of the conditions was that we remove use of the prior trademarked name and logo/graphic. Back a few years ago, Olly Stephens came up with the idea of using the battery theme to show the "power" of Modula-3. In trying to come up with something for CM3-IDE, I went back to Olly's battery theme and embellished it a bit. Here is the message that I was trying to convey: The CM3-IDE light bulb is powered by the Modula-3 battery to perform great things for the developer, including creating, building, running, maintaining, and browsing source code packages. Once we get the CM3-IDE package into the repository, the CM3 community is welcome to improve it and change any of the graphics. I will be putting all of my original artwork in the repository to provide a starting point for anyone who wants to modify the graphics. The original art work was done in Microsoft PowerPoint 2003 and exported to TIF format, then cropped, resized, and converted to GIF as needed for use in the application. I used IrfanView to do the conversions and manipulations from TIF to GIF. An announcement will go out on the m3devel news list as soon as the package has been put in the repository. I am working to finalize the arrangements this week so hopefully you will see it real soon. Regards, Randy >>> Roland Illig 1/27/2008 11:23 AM >>> Randy Coleburn wrote: > Ok, I've gotten some feedback on the new name for reactor. > > I've attached a PDF that has two pages: one depicts use of Catalyst, > the other CM3-IDE. > > Please let me know which you prefer. If these are going to become logos of any kind, I don't like them both. - They use lots of different font shapes and sizes. This makes the image rather complicated. A logo should use at most one font shape. - There are lots of components in the logo. To view them all, it takes a long time. A logo should be as simple that one can recognize it at a glance. - What does the battery have to do with Modula-3? - How does it relate to the light bulb? - What does the "With Power" on the light bulb mean? Is it important for the logo? - Is there any prior art for these kinds of logos? Roland -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Sun Jan 27 21:31:00 2008 From: jayk123 at hotmail.com (Jay) Date: Sun, 27 Jan 2008 20:31:00 +0000 Subject: [M3devel] Open CM3 regression tests In-Reply-To: <20080127185530.e255i76vcwckss4o@mail.elegosoft.com> References: <20080120211832.GA26993@elegosoft.com> <9C00EA97-9B43-43BE-9CDF-EEAC9C1321D5@cs.purdue.edu> <20080127150327.mh686v2hx4w080w4@mail.elegosoft.com> <1DA9FA59-6DFF-430C-90C5-F1D30003607A@cs.purdue.edu> <20080127185530.e255i76vcwckss4o@mail.elegosoft.com> Message-ID: The functions are only used if the set doesn't fit in an integer. I'll try to look at this today. - Jay > Date: Sun, 27 Jan 2008 18:55:30 +0100> From: wagner at elegosoft.com> To: hosking at cs.purdue.edu> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] Open CM3 regression tests> > Quoting Tony Hosking :> > > The set operations are coded in > > cm3/m3-libs/m3core/src/Csupport/Common/hand.c.> >> > I notice Jay has made a number of changes here since September -- I> > wonder if they have broken something.> > I tried different revisions of this file with no difference in the> test results. I then took the latest version and added some printfs,> and they got never displayed. So I checked what gets linked, but the> symbols in question don't occur in the test program:> > % nm hand.o> U __divdi3> U __moddi3> 000001e0 R _highbits> 00000140 R _lowbits> 00000000 T m3_div> 000000ac T m3_divL> 000001d4 T m3_mod> 0000026c T m3_modL> U printf> 00000494 T set_difference> 00000554 T set_eq> 0000061c T set_ge> 000006ac T set_gt> 00000434 T set_intersection> 0000077c T set_le> 0000080c T set_lt> 000003a8 T set_member> 000005b8 T set_ne> 000008d8 T set_range> 000009d8 T set_singleton> 000004f4 T set_sym_difference> 000003d4 T set_union> > % nm /usr/local/cm3/pkg/m3core/FreeBSD4/libm3core.so.5 | grep set_> 000243d0 T set_difference> 00024490 T set_eq> 00024558 T set_ge> 000245fc T set_gt> 00024370 T set_intersection> 000246e0 T set_le> 00024784 T set_lt> 000242e4 T set_member> 000244f4 T set_ne> 00024864 T set_range> 00024998 T set_singleton> 00024430 T set_sym_difference> 00024310 T set_union> > % ldd FreeBSD4/p1/p155/FreeBSD4/pgm> FreeBSD4/p1/p155/FreeBSD4/pgm:> libtest.so.5 => > /d/home/wagner/work/cm3/m3-sys/m3tests/FreeBSD4/libtest.so.5 > (0x28085000)> libm3.so.5 => /usr/local/cm3/pkg/libm3/FreeBSD4/libm3.so.5 > (0x28088000)> libm3core.so.5 => > /usr/local/cm3/pkg/m3core/FreeBSD4/libm3core.so.5 (0x281aa000)> libm.so.4 => /lib/libm.so.4 (0x28a2d000)> libpthread.so.2 => /lib/libpthread.so.2 (0x28a46000)> libc.so.6 => /lib/libc.so.6 (0x28a6a000)> > % nm /usr/local/cm3/pkg/m3core/FreeBSD4/libm3core.so.5 | grep set_> 000243d0 T set_difference> 00024490 T set_eq> 00024558 T set_ge> 000245fc T set_gt> 00024370 T set_intersection> 000246e0 T set_le> 00024784 T set_lt> 000242e4 T set_member> 000244f4 T set_ne> 00024864 T set_range> 00024998 T set_singleton> 00024430 T set_sym_difference> 00024310 T set_union> luthien [~/work/cm3/m3-sys/m3tests] wagner> % ldd FreeBSD4/p1/p155/FreeBSD4/pgm> FreeBSD4/p1/p155/FreeBSD4/pgm:> libtest.so.5 => > /d/home/wagner/work/cm3/m3-sys/m3tests/FreeBSD4/libtest.so.5 > (0x28085000)> libm3.so.5 => /usr/local/cm3/pkg/libm3/FreeBSD4/libm3.so.5 > (0x28088000)> libm3core.so.5 => > /usr/local/cm3/pkg/m3core/FreeBSD4/libm3core.so.5 (0x281aa000)> libm.so.4 => /lib/libm.so.4 (0x28a2d000)> libpthread.so.2 => /lib/libpthread.so.2 (0x28a46000)> libc.so.6 => /lib/libc.so.6 (0x28a6a000)> luthien [~/work/cm3/m3-sys/m3tests] wagner> % nm -C -u FreeBSD4/p1/p155/FreeBSD4/pgm> U Main_I3> U RTHooks_I3> U RTHooks__CheckLoadTracedRef> U RTHooks__Concat> U RTHooks__PopEFrame> U RTHooks__PushEFrame> U RTHooks__TextLitGetChar> U RTHooks__TextLitGetChars> U RTHooks__TextLitGetWideChar> U RTHooks__TextLitGetWideChars> U RTHooks__TextLitInfo> U RTLinker__AddUnit> U RTLinker__InitRuntime> U RTProcess__Exit> U Stdio_I3> U Test_I3> U Test__checkM> U Test__done> U Wr_I3> U Wr__Flush> U Wr__PutText> w _Jv_RegisterClasses> w __deregister_frame_info> w __register_frame_info> U _init_tls> U _setjmp> U atexit> U exit> > Now I'm rather confused 8-/> > Any ideas?> > Olaf> -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194> _________________________________________________________________ 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 Sun Jan 27 21:33:34 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 27 Jan 2008 15:33:34 -0500 Subject: [M3devel] Open CM3 regression tests In-Reply-To: <20080127185530.e255i76vcwckss4o@mail.elegosoft.com> References: <20080120211832.GA26993@elegosoft.com> <9C00EA97-9B43-43BE-9CDF-EEAC9C1321D5@cs.purdue.edu> <20080127150327.mh686v2hx4w080w4@mail.elegosoft.com> <1DA9FA59-6DFF-430C-90C5-F1D30003607A@cs.purdue.edu> <20080127185530.e255i76vcwckss4o@mail.elegosoft.com> Message-ID: <417F5D6F-D9A1-41C0-8B2F-58056170C5F4@cs.purdue.edu> Are your sets larger than a single word? The M3 frontend compiles small sets (elements <= BITSIZE(Word.T)) differently from large (elements > BITSIZE(Word.T)). The out-of-line set operations are only for large sets. On Jan 27, 2008, at 12:55 PM, Olaf Wagner wrote: > Quoting Tony Hosking : > >> The set operations are coded in cm3/m3-libs/m3core/src/Csupport/ >> Common/hand.c. >> >> I notice Jay has made a number of changes here since September -- I >> wonder if they have broken something. > > I tried different revisions of this file with no difference in the > test results. I then took the latest version and added some printfs, > and they got never displayed. So I checked what gets linked, but the > symbols in question don't occur in the test program: > > % nm hand.o > U __divdi3 > U __moddi3 > 000001e0 R _highbits > 00000140 R _lowbits > 00000000 T m3_div > 000000ac T m3_divL > 000001d4 T m3_mod > 0000026c T m3_modL > U printf > 00000494 T set_difference > 00000554 T set_eq > 0000061c T set_ge > 000006ac T set_gt > 00000434 T set_intersection > 0000077c T set_le > 0000080c T set_lt > 000003a8 T set_member > 000005b8 T set_ne > 000008d8 T set_range > 000009d8 T set_singleton > 000004f4 T set_sym_difference > 000003d4 T set_union > > % nm /usr/local/cm3/pkg/m3core/FreeBSD4/libm3core.so.5 | grep set_ > 000243d0 T set_difference > 00024490 T set_eq > 00024558 T set_ge > 000245fc T set_gt > 00024370 T set_intersection > 000246e0 T set_le > 00024784 T set_lt > 000242e4 T set_member > 000244f4 T set_ne > 00024864 T set_range > 00024998 T set_singleton > 00024430 T set_sym_difference > 00024310 T set_union > > % ldd FreeBSD4/p1/p155/FreeBSD4/pgm > FreeBSD4/p1/p155/FreeBSD4/pgm: > libtest.so.5 => /d/home/wagner/work/cm3/m3-sys/m3tests/ > FreeBSD4/libtest.so.5 (0x28085000) > libm3.so.5 => /usr/local/cm3/pkg/libm3/FreeBSD4/libm3.so.5 > (0x28088000) > libm3core.so.5 => /usr/local/cm3/pkg/m3core/FreeBSD4/ > libm3core.so.5 (0x281aa000) > libm.so.4 => /lib/libm.so.4 (0x28a2d000) > libpthread.so.2 => /lib/libpthread.so.2 (0x28a46000) > libc.so.6 => /lib/libc.so.6 (0x28a6a000) > > % nm /usr/local/cm3/pkg/m3core/FreeBSD4/libm3core.so.5 | grep set_ > 000243d0 T set_difference > 00024490 T set_eq > 00024558 T set_ge > 000245fc T set_gt > 00024370 T set_intersection > 000246e0 T set_le > 00024784 T set_lt > 000242e4 T set_member > 000244f4 T set_ne > 00024864 T set_range > 00024998 T set_singleton > 00024430 T set_sym_difference > 00024310 T set_union > luthien [~/work/cm3/m3-sys/m3tests] wagner > % ldd FreeBSD4/p1/p155/FreeBSD4/pgm > FreeBSD4/p1/p155/FreeBSD4/pgm: > libtest.so.5 => /d/home/wagner/work/cm3/m3-sys/m3tests/ > FreeBSD4/libtest.so.5 (0x28085000) > libm3.so.5 => /usr/local/cm3/pkg/libm3/FreeBSD4/libm3.so.5 > (0x28088000) > libm3core.so.5 => /usr/local/cm3/pkg/m3core/FreeBSD4/ > libm3core.so.5 (0x281aa000) > libm.so.4 => /lib/libm.so.4 (0x28a2d000) > libpthread.so.2 => /lib/libpthread.so.2 (0x28a46000) > libc.so.6 => /lib/libc.so.6 (0x28a6a000) > luthien [~/work/cm3/m3-sys/m3tests] wagner > % nm -C -u FreeBSD4/p1/p155/FreeBSD4/pgm > U Main_I3 > U RTHooks_I3 > U RTHooks__CheckLoadTracedRef > U RTHooks__Concat > U RTHooks__PopEFrame > U RTHooks__PushEFrame > U RTHooks__TextLitGetChar > U RTHooks__TextLitGetChars > U RTHooks__TextLitGetWideChar > U RTHooks__TextLitGetWideChars > U RTHooks__TextLitInfo > U RTLinker__AddUnit > U RTLinker__InitRuntime > U RTProcess__Exit > U Stdio_I3 > U Test_I3 > U Test__checkM > U Test__done > U Wr_I3 > U Wr__Flush > U Wr__PutText > w _Jv_RegisterClasses > w __deregister_frame_info > w __register_frame_info > U _init_tls > U _setjmp > U atexit > U exit > > Now I'm rather confused 8-/ > > Any ideas? > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, > Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 > 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: > Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > DE163214194 > From jayk123 at hotmail.com Sun Jan 27 21:44:52 2008 From: jayk123 at hotmail.com (Jay) Date: Sun, 27 Jan 2008 20:44:52 +0000 Subject: [M3devel] Open CM3 regression tests In-Reply-To: <417F5D6F-D9A1-41C0-8B2F-58056170C5F4@cs.purdue.edu> References: <20080120211832.GA26993@elegosoft.com> <9C00EA97-9B43-43BE-9CDF-EEAC9C1321D5@cs.purdue.edu> <20080127150327.mh686v2hx4w080w4@mail.elegosoft.com> <1DA9FA59-6DFF-430C-90C5-F1D30003607A@cs.purdue.edu> <20080127185530.e255i76vcwckss4o@mail.elegosoft.com> <417F5D6F-D9A1-41C0-8B2F-58056170C5F4@cs.purdue.edu> Message-ID: Yes. C:\dev2\cm3.2\m3-sys\m3tests\src\p1\p155\Main.m3 (* Copyright (C) 1994, Digital Equipment Corporation. *)(* All rights reserved. *)(* See the file COPYRIGHT for a full description. *) (* Last modified on Tue Oct 27 14:49:19 PST 1992 by kalsow *)(* modified on Wed Oct 10 13:15:01 1990 by saxe *) (* Set operators on a small set type. *) MODULE Main;IMPORT Test, Wr;FROM Stdio IMPORT stderr; TYPE Elt = {a, b, c, d, e}; Set = SET OF Elt; VAR x: Set; CONST p = Set{Elt.a, Elt.c, Elt.e}; q = Set{}; r = Set{Elt.a .. Elt.b, Elt.a .. Elt.a (* , Elt.d .. Elt.b *)}; PROCEDURE m( s: TEXT ) = BEGIN TRY Wr.PutText (stderr, s & "\n"); Wr.Flush (stderr); EXCEPT ELSE END; END m; BEGIN m ("check set p = {a, c, e}"); Test.checkM (Elt.a IN p, "Elt.a IN p"); Test.checkM (NOT (Elt.b IN p), "NOT (Elt.b IN p)"); Test.checkM (Elt.c IN p, "Elt.c IN p"); Test.checkM (NOT (Elt.d IN p), "NOT (Elt.d IN p)"); Test.checkM (Elt.e IN p, "(Elt.e IN p"); m ("check set q = {}"); Test.checkM (NOT (Elt.a IN q), "NOT (Elt.a IN q)"); Test.checkM (NOT (Elt.b IN q), "NOT (Elt.b IN q)"); Test.checkM (NOT (Elt.c IN q), "NOT (Elt.c IN q)"); Test.checkM (NOT (Elt.d IN q), "NOT (Elt.d IN q)"); Test.checkM (NOT (Elt.e IN q), "NOT (Elt.e IN q)"); m ("check set r = {a, b}"); Test.checkM (Elt.a IN r, "Elt.a IN r"); Test.checkM (Elt.b IN r, "Elt.b IN r"); Test.checkM (NOT (Elt.c IN r), "NOT (Elt.c IN r)"); Test.checkM (NOT (Elt.d IN r), "NOT (Elt.d IN r)"); Test.checkM (NOT (Elt.e IN r), "NOT (Elt.e IN r)"); Test.checkM (r = Set{Elt.b, Elt.a}, "r = Set{Elt.b, Elt.a}"); (** Test.checkM (-p = Set{Elt.d, Elt.b}); **) (** Test.checkM (+p = p); **) Test.checkM (p - p = q, "check (p - p = q)"); Test.checkM ((p - r) * (r - p) = q, "check ((p - r) * (r - p) = q)"); Test.checkM (p - r = Set{Elt.c, Elt.e}, "check (p - r = Set{Elt.c, Elt.e})"); Test.checkM (p + p = p, "check (p + p = p)"); Test.checkM (p + r = Set{Elt.a, Elt.b, Elt.c, Elt.e}, "check (p + r = Set{Elt.a, Elt.b, Elt.c, Elt.e})"); (** Test.checkM (-(-(r)) = r); **) Test.checkM (p * r = Set{Elt.a}, "check (p * r = Set{Elt.a})"); Test.checkM (p * q = Set{}, "check (p * q = Set{})"); Test.checkM (p # q, "check (p # q)"); Test.checkM (q < p, "check (q < p)"); Test.checkM (NOT (p < r), "check (NOT (p < r))"); Test.checkM (NOT (p > r), "check (NOT (p > r))"); Test.checkM (NOT (p = r), "check (NOT (p = r))"); Test.checkM ((p / r) = (Set{Elt.b, Elt.c, Elt.e}), "check ((p / r) = (Set{Elt.b, Elt.c, Elt.e}))"); Test.checkM (r / q = q / r, "check (r / q = q / r)"); Test.checkM (r / p / r / p / q / r = r, "check (r / p / r / p / q / r = r)"); Test.checkM (p / r - r / p = q, "check (p / r - r / p = q)"); x := p; x := x + Set{Elt.b}; (*INCL(x, Elt.b);*) (* x = { a, b, c, e } *) Test.checkM (x > p, "check (x > p)"); Test.checkM (x >= p, "check (x >= p)"); Test.checkM (p <= x, "check (p <= x)"); Test.checkM (p # x, "check (p # x)"); x := x - Set{Elt.c}; (*EXCL(x, Elt.c);*) (* x = { a, b, e } *) m ("check set x = {a, b, e}"); Test.checkM (Elt.a IN x, "Elt.a IN x"); Test.checkM (Elt.b IN x, "Elt.b IN x"); Test.checkM (NOT (Elt.c IN x), "NOT (Elt.c IN x)"); Test.checkM (NOT (Elt.d IN x), "NOT (Elt.d IN x)"); Test.checkM (Elt.e IN x, "Elt.e IN x"); Test.checkM (NOT (p <= x), "check (NOT (p <= x))"); Test.checkM (NOT (p >= x), "check (NOT (p >= x))"); Test.checkM (x = r + Set{Elt.e}, "check (x = r + Set{Elt.e})"); Test.done ();END Main. -Jay > From: hosking at cs.purdue.edu> Date: Sun, 27 Jan 2008 15:33:34 -0500> To: wagner at elegosoft.com> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] Open CM3 regression tests> > Are your sets larger than a single word? The M3 frontend compiles > small sets (elements <= BITSIZE(Word.T)) differently from large > (elements > BITSIZE(Word.T)). The out-of-line set operations are > only for large sets.> > > On Jan 27, 2008, at 12:55 PM, Olaf Wagner wrote:> > > Quoting Tony Hosking :> >> >> The set operations are coded in cm3/m3-libs/m3core/src/Csupport/ > >> Common/hand.c.> >>> >> I notice Jay has made a number of changes here since September -- I> >> wonder if they have broken something.> >> > I tried different revisions of this file with no difference in the> > test results. I then took the latest version and added some printfs,> > and they got never displayed. So I checked what gets linked, but the> > symbols in question don't occur in the test program:> >> > % nm hand.o> > U __divdi3> > U __moddi3> > 000001e0 R _highbits> > 00000140 R _lowbits> > 00000000 T m3_div> > 000000ac T m3_divL> > 000001d4 T m3_mod> > 0000026c T m3_modL> > U printf> > 00000494 T set_difference> > 00000554 T set_eq> > 0000061c T set_ge> > 000006ac T set_gt> > 00000434 T set_intersection> > 0000077c T set_le> > 0000080c T set_lt> > 000003a8 T set_member> > 000005b8 T set_ne> > 000008d8 T set_range> > 000009d8 T set_singleton> > 000004f4 T set_sym_difference> > 000003d4 T set_union> >> > % nm /usr/local/cm3/pkg/m3core/FreeBSD4/libm3core.so.5 | grep set_> > 000243d0 T set_difference> > 00024490 T set_eq> > 00024558 T set_ge> > 000245fc T set_gt> > 00024370 T set_intersection> > 000246e0 T set_le> > 00024784 T set_lt> > 000242e4 T set_member> > 000244f4 T set_ne> > 00024864 T set_range> > 00024998 T set_singleton> > 00024430 T set_sym_difference> > 00024310 T set_union> >> > % ldd FreeBSD4/p1/p155/FreeBSD4/pgm> > FreeBSD4/p1/p155/FreeBSD4/pgm:> > libtest.so.5 => /d/home/wagner/work/cm3/m3-sys/m3tests/ > > FreeBSD4/libtest.so.5 (0x28085000)> > libm3.so.5 => /usr/local/cm3/pkg/libm3/FreeBSD4/libm3.so.5 > > (0x28088000)> > libm3core.so.5 => /usr/local/cm3/pkg/m3core/FreeBSD4/ > > libm3core.so.5 (0x281aa000)> > libm.so.4 => /lib/libm.so.4 (0x28a2d000)> > libpthread.so.2 => /lib/libpthread.so.2 (0x28a46000)> > libc.so.6 => /lib/libc.so.6 (0x28a6a000)> >> > % nm /usr/local/cm3/pkg/m3core/FreeBSD4/libm3core.so.5 | grep set_> > 000243d0 T set_difference> > 00024490 T set_eq> > 00024558 T set_ge> > 000245fc T set_gt> > 00024370 T set_intersection> > 000246e0 T set_le> > 00024784 T set_lt> > 000242e4 T set_member> > 000244f4 T set_ne> > 00024864 T set_range> > 00024998 T set_singleton> > 00024430 T set_sym_difference> > 00024310 T set_union> > luthien [~/work/cm3/m3-sys/m3tests] wagner> > % ldd FreeBSD4/p1/p155/FreeBSD4/pgm> > FreeBSD4/p1/p155/FreeBSD4/pgm:> > libtest.so.5 => /d/home/wagner/work/cm3/m3-sys/m3tests/ > > FreeBSD4/libtest.so.5 (0x28085000)> > libm3.so.5 => /usr/local/cm3/pkg/libm3/FreeBSD4/libm3.so.5 > > (0x28088000)> > libm3core.so.5 => /usr/local/cm3/pkg/m3core/FreeBSD4/ > > libm3core.so.5 (0x281aa000)> > libm.so.4 => /lib/libm.so.4 (0x28a2d000)> > libpthread.so.2 => /lib/libpthread.so.2 (0x28a46000)> > libc.so.6 => /lib/libc.so.6 (0x28a6a000)> > luthien [~/work/cm3/m3-sys/m3tests] wagner> > % nm -C -u FreeBSD4/p1/p155/FreeBSD4/pgm> > U Main_I3> > U RTHooks_I3> > U RTHooks__CheckLoadTracedRef> > U RTHooks__Concat> > U RTHooks__PopEFrame> > U RTHooks__PushEFrame> > U RTHooks__TextLitGetChar> > U RTHooks__TextLitGetChars> > U RTHooks__TextLitGetWideChar> > U RTHooks__TextLitGetWideChars> > U RTHooks__TextLitInfo> > U RTLinker__AddUnit> > U RTLinker__InitRuntime> > U RTProcess__Exit> > U Stdio_I3> > U Test_I3> > U Test__checkM> > U Test__done> > U Wr_I3> > U Wr__Flush> > U Wr__PutText> > w _Jv_RegisterClasses> > w __deregister_frame_info> > w __register_frame_info> > U _init_tls> > U _setjmp> > U atexit> > U exit> >> > Now I'm rather confused 8-/> >> > Any ideas?> >> > Olaf> > -- > > Olaf Wagner -- elego Software Solutions GmbH> > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, > > Germany> > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 > > 45 86 95> > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: > > Berlin> > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > > DE163214194> >> _________________________________________________________________ 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 Sun Jan 27 21:54:55 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Sun, 27 Jan 2008 21:54:55 +0100 Subject: [M3devel] Open CM3 regression tests In-Reply-To: <417F5D6F-D9A1-41C0-8B2F-58056170C5F4@cs.purdue.edu> References: <20080120211832.GA26993@elegosoft.com> <9C00EA97-9B43-43BE-9CDF-EEAC9C1321D5@cs.purdue.edu> <20080127150327.mh686v2hx4w080w4@mail.elegosoft.com> <1DA9FA59-6DFF-430C-90C5-F1D30003607A@cs.purdue.edu> <20080127185530.e255i76vcwckss4o@mail.elegosoft.com> <417F5D6F-D9A1-41C0-8B2F-58056170C5F4@cs.purdue.edu> Message-ID: <20080127215455.4q09uyuj8ko40k4w@mail.elegosoft.com> Quoting Tony Hosking : > Are your sets larger than a single word? The M3 frontend compiles > small sets (elements <= BITSIZE(Word.T)) differently from large > (elements > BITSIZE(Word.T)). The out-of-line set operations are only > for large sets. These are small sets. There are other tests for large sets, which seem to succeed. So obviously the problem is in the cm3cg backend, as in m3middle set_compare will only write Cmd (u, OpName [op]); Int (u, s); TName (u, t); which then gets read by the actual code generator. I guess one of you guys will be much faster tracking this down through the gcc tree construction and manipulation code. It's been several years that I have had a look at that. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From hosking at cs.purdue.edu Sun Jan 27 22:31:22 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 27 Jan 2008 16:31:22 -0500 Subject: [M3devel] Open CM3 regression tests In-Reply-To: <20080127215455.4q09uyuj8ko40k4w@mail.elegosoft.com> References: <20080120211832.GA26993@elegosoft.com> <9C00EA97-9B43-43BE-9CDF-EEAC9C1321D5@cs.purdue.edu> <20080127150327.mh686v2hx4w080w4@mail.elegosoft.com> <1DA9FA59-6DFF-430C-90C5-F1D30003607A@cs.purdue.edu> <20080127185530.e255i76vcwckss4o@mail.elegosoft.com> <417F5D6F-D9A1-41C0-8B2F-58056170C5F4@cs.purdue.edu> <20080127215455.4q09uyuj8ko40k4w@mail.elegosoft.com> Message-ID: <45340E89-F1AD-40CC-BF84-77607A35D4A8@cs.purdue.edu> It is the *front* end that compiles small sets into word operations. The backend doesn't even see small sets. So, this suggests that the small sets are failing due to some interaction between the front end and back end. On Jan 27, 2008, at 3:54 PM, Olaf Wagner wrote: > Quoting Tony Hosking : > >> Are your sets larger than a single word? The M3 frontend compiles >> small sets (elements <= BITSIZE(Word.T)) differently from large >> (elements > BITSIZE(Word.T)). The out-of-line set operations are >> only >> for large sets. > > These are small sets. There are other tests for large sets, which seem > to succeed. > > So obviously the problem is in the cm3cg backend, as in m3middle > set_compare will only write > > Cmd (u, OpName [op]); > Int (u, s); > TName (u, t); > > which then gets read by the actual code generator. > I guess one of you guys will be much faster tracking this down > through the gcc tree construction and manipulation code. It's been > several years that I have had a look at that. > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, > Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 > 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: > Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > DE163214194 > From wagner at elegosoft.com Sun Jan 27 23:11:57 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Sun, 27 Jan 2008 23:11:57 +0100 Subject: [M3devel] Open CM3 regression tests In-Reply-To: <45340E89-F1AD-40CC-BF84-77607A35D4A8@cs.purdue.edu> References: <20080120211832.GA26993@elegosoft.com> <9C00EA97-9B43-43BE-9CDF-EEAC9C1321D5@cs.purdue.edu> <20080127150327.mh686v2hx4w080w4@mail.elegosoft.com> <1DA9FA59-6DFF-430C-90C5-F1D30003607A@cs.purdue.edu> <20080127185530.e255i76vcwckss4o@mail.elegosoft.com> <417F5D6F-D9A1-41C0-8B2F-58056170C5F4@cs.purdue.edu> <20080127215455.4q09uyuj8ko40k4w@mail.elegosoft.com> <45340E89-F1AD-40CC-BF84-77607A35D4A8@cs.purdue.edu> Message-ID: <20080127231157.7y1adg5bksw08o0k@mail.elegosoft.com> Quoting Tony Hosking : > It is the *front* end that compiles small sets into word operations. > The backend doesn't even see small sets. So, this suggests that the > small sets are failing due to some interaction between the front end > and back end. Sorry if I seem to be a bit slow (I've caught a bronchitis again and perhaps cannot think as clearly as I should)... So you think the error is in m3-sys/m3front/src/exprs/SetExpr.m3 in PROCEDURE Compare (a, b: Expr.T; VAR sign: INTEGER): BOOLEAN = and PROCEDURE Visit (VAR s: VisitState): BOOLEAN = or rather in m3middle while writing the intermediate representation? Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Jan 28 00:18:05 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 27 Jan 2008 18:18:05 -0500 Subject: [M3devel] Open CM3 regression tests In-Reply-To: <20080127231157.7y1adg5bksw08o0k@mail.elegosoft.com> References: <20080120211832.GA26993@elegosoft.com> <9C00EA97-9B43-43BE-9CDF-EEAC9C1321D5@cs.purdue.edu> <20080127150327.mh686v2hx4w080w4@mail.elegosoft.com> <1DA9FA59-6DFF-430C-90C5-F1D30003607A@cs.purdue.edu> <20080127185530.e255i76vcwckss4o@mail.elegosoft.com> <417F5D6F-D9A1-41C0-8B2F-58056170C5F4@cs.purdue.edu> <20080127215455.4q09uyuj8ko40k4w@mail.elegosoft.com> <45340E89-F1AD-40CC-BF84-77607A35D4A8@cs.purdue.edu> <20080127231157.7y1adg5bksw08o0k@mail.elegosoft.com> Message-ID: I would be surprised if the front-end is wrong, but it might be. It might also be some strange interaction with the backend. I can put this on my stack of things to look at, but it will be a little while as I catch up with other things -- I've only just begun to regain usable sight in one of my eyes after scratching a cornea last week. On Jan 27, 2008, at 5:11 PM, Olaf Wagner wrote: > Quoting Tony Hosking : > >> It is the *front* end that compiles small sets into word operations. >> The backend doesn't even see small sets. So, this suggests that the >> small sets are failing due to some interaction between the front end >> and back end. > > Sorry if I seem to be a bit slow (I've caught a bronchitis again > and perhaps cannot think as clearly as I should)... So you think > the error is in m3-sys/m3front/src/exprs/SetExpr.m3 in > > PROCEDURE Compare (a, b: Expr.T; VAR sign: INTEGER): BOOLEAN = > and > PROCEDURE Visit (VAR s: VisitState): BOOLEAN = > > or rather in m3middle while writing the intermediate representation? > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, > Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Jan 28 10:48:31 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 28 Jan 2008 09:48:31 +0000 Subject: [M3devel] heap vs. stack? (sort of) Message-ID: Is it possible to have this pattern in Modula-3: PROCEDURE Parse (nm: TEXT; host: BOOLEAN): T = VAR len := Text.Length (nm); buf: ARRAY [0..255] OF CHAR; BEGIN IF (len <= NUMBER (buf)) THEN RETURN DoParse (nm, SUBARRAY (buf, 0, len), host); ELSE RETURN DoParse (nm, NEW (REF ARRAY OF CHAR, len)^, host); END; END Parse; PROCEDURE DoParse (nm_txt: TEXT; VAR nm: ARRAY OF CHAR; host: BOOLEAN): T = without the extra function? There are places in M3Path.m3 that duplicate code otherwise, one branch acting on a local stack allocated array, the other acting on a heap allocated array when the stack array is too small, but otherwise identical code. So far I have not figured out how. Local variables cannot be open array. SUBARRAY returns an ARRAY and not a REF ARRAY... It seems that parameters can be open arrays but local variables cannot, and that seems wrong.. parameters and locals so often share characteristics... - 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 Jan 28 12:29:31 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 28 Jan 2008 11:29:31 +0000 Subject: [M3devel] nt386gnu threads? Message-ID: Can anyone confirm my read that PM3's NT386GNU used user/vtalarm threads? PM3 appears to have no PThread support ant its NT386GNU appears to have OS_TYPE=POSIX. Heck, even its NT386 has OS_TYPE=POSIX, but its NT386 is probably dead/broken. 1) I'm too lazy to tediously rewrite Cygwin's pthread.h et. al. into Modula-3. 2) The thread library you pick is not an independent decision. The Modula-3 File I/O libraries interact with the threading library at least a little bit. The path of less resistance seems to be user/vtalarm threads for now, until such time as Cygwin Upthread.i3 is written. (That is, neither pthreads nor win32 satisfied my laziness; I'm going to try user/vtalarm threads, see how it goes; I'm sure they aren't very good, but...) - Jay _________________________________________________________________ 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 Mon Jan 28 12:39:10 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Mon, 28 Jan 2008 12:39:10 +0100 (MET) Subject: [M3devel] heap vs. stack? (sort of) In-Reply-To: References: Message-ID: On Mon, 28 Jan 2008, Jay wrote: > Is it possible to have this pattern in Modula-3: > > PROCEDURE Parse (nm: TEXT; host: BOOLEAN): T = VAR len := Text.Length (nm); buf: ARRAY [0..255] OF CHAR; BEGIN IF (len <= NUMBER (buf)) THEN RETURN DoParse (nm, SUBARRAY (buf, 0, len), host); ELSE RETURN DoParse (nm, NEW (REF ARRAY OF CHAR, len)^, host); END; END Parse; > > PROCEDURE DoParse (nm_txt: TEXT; VAR nm: ARRAY OF CHAR; host: BOOLEAN): T = I think it is a good idea to encapsulate the common code in DoParse. If DoParse needs local variables, it can be turned into a local PROCEDURE of Parse. On the other hand I doubt that it is sensible to reserve 256 bytes on the stack also if they are not used, or only a part of them are used. What's bad about always using NEW? I think Modula-3's memory management has optimizations for small amounts of memory. From mika at async.caltech.edu Mon Jan 28 13:04:50 2008 From: mika at async.caltech.edu (Mika Nystrom) Date: Mon, 28 Jan 2008 04:04:50 -0800 Subject: [M3devel] nt386gnu threads? In-Reply-To: Your message of "Mon, 28 Jan 2008 11:29:31 GMT." Message-ID: <200801281204.m0SC4oNp025190@camembert.async.caltech.edu> I am almost certain it uses Win32 threads. Attached: ThreadWin32.m3 from PM3-Klagenfurt Mika Jay writes: >--_ddef1601-2afe-4ff4-9567-11d7fc5d354a_ >Content-Type: text/plain; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > >Can anyone confirm my read that PM3's NT386GNU used user/vtalarm threads? .... (* Copyright (C) 1994, Digital Equipment Corporation *) (* All rights reserved. *) (* See the file COPYRIGHT for a full description. *) (* *) (* portions Copyright 1996, Critical Mass, Inc. *) (* *) (* Last modified on Fri Apr 26 10:21:56 PDT 1996 by heydon *) (* modified on Thu Jun 15 09:06:37 PDT 1995 by kalsow *) (* modified on Tue Oct 4 10:34:00 PDT 1994 by isard *) (* modified on Tue May 4 10:20:03 PDT 1993 by mjordan *) (* modified on Wed Apr 21 16:31:21 PDT 1993 by mcjones *) (* modified on Fri Mar 26 15:04:39 PST 1993 by birrell *) UNSAFE MODULE ThreadWin32 EXPORTS Scheduler, Thread, ThreadF, RTThreadInit, RTHooks; IMPORT RTHeapRep, RTLinker, RTMisc, WinBase, WinDef, WinNT, ThreadContext; IMPORT Word; (*** IMPORT RTIO; ***) (*----------------------------------------- Exceptions, types and globals ---*) VAR cm: WinBase.LPCRITICAL_SECTION; (* Global lock for internals of Mutex and Condition *) default_stack: WinDef.DWORD := 16384; nextId: Id := 1; REVEAL Mutex = BRANDED "MUTEX Win32-1.0" OBJECT cs: WinBase.LPCRITICAL_SECTION := NIL; held: BOOLEAN := FALSE; (* LL = self.cs *) (* Because critical sections are thread re-entrant *) END; Condition = BRANDED "Thread.Condition Win32-1.0" OBJECT waiters: T := NIL; (* LL = cm *) (* List of threads waiting on this CV. *) END; T = BRANDED "Thread.T Win32-1.0" OBJECT next, prev: T := NIL; (* LL = threadMu; global doubly-linked, circular list of all threads *) nextIdle: T := NIL; (* LL = threadMu; global list of idle threads *) handle: WinNT.HANDLE := NIL; (* LL = threadMu; thread handle in Windows *) stackbase: ADDRESS := NIL; (* LL = threadMu; base of thread stack for use by GC *) closure: Closure := NIL; (* LL = threadMu *) result: REFANY := NIL; (* LL = threadMu; if not self.completed, used only by self; if self.completed, read-only. *) cond: Condition; (* LL = threadMu; wait here to join, or for rebirth *) waitingOn: Condition := NIL; (* LL = cm; CV that we're blocked on *) nextWaiter: T := NIL; (* LL = cm; queue of threads waiting on the same CV *) waitSema: WinNT.HANDLE := NIL; (* binary semaphore for blocking during "Wait" *) alertable: BOOLEAN := FALSE; (* LL = cm; distinguishes between "Wait" and "AlertWait" *) alerted: BOOLEAN := FALSE; (* LL = cm; the alert flag, of course *) completed: BOOLEAN := FALSE; (* LL = threadMu; indicates that "result" is set *) joined: BOOLEAN := FALSE; (* LL = threadMu; "Join" or "AlertJoin" has already returned *) id: Id; (* LL = threadMu; unique ID of this thread *) slot: INTEGER; (* LL = threadMu; index into global array of active, slotted threads *) END; (*------------------------------------------- Caches of critical sections ---*) CONST CSectCacheSize = 20; (* Everything should work OK if these are 0 *) VAR cSectCache: ARRAY [0..CSectCacheSize-1] OF WinBase.LPCRITICAL_SECTION; cSectCacheContents := 0; PROCEDURE AllocCSect(m: Mutex) = (* LL = 0 *) (* If we can take a critical section from the cache, do so; otherwise create it. In any case, register the containing Mutex with the GC so that we can clean-up on de-allocation. *) VAR mcs: WinBase.LPCRITICAL_SECTION := NIL; lost_race := FALSE; BEGIN WinBase.EnterCriticalSection(cm); IF cSectCacheContents > 0 THEN DEC(cSectCacheContents); m.cs := cSectCache[cSectCacheContents]; ELSE WinBase.LeaveCriticalSection(cm); mcs := NEW(WinBase.LPCRITICAL_SECTION); WinBase.EnterCriticalSection(cm); IF (m.cs = NIL) THEN m.cs := mcs; WinBase.InitializeCriticalSection(m.cs); ELSE (* somebody else beat us thru the preceding NEW *) lost_race := TRUE; END; END; WinBase.LeaveCriticalSection(cm); IF lost_race THEN DISPOSE (mcs); ELSE RTHeapRep.RegisterFinalCleanup(m, FreeCSect); END; END AllocCSect; PROCEDURE FreeCSect(r: REFANY (*Mutex*) ) = (* LL < cm *) (* Must not dereference any traced REF when called from GC *) VAR m: Mutex := r; BEGIN WinBase.EnterCriticalSection(cm); IF m.cs # NIL THEN IF cSectCacheContents < CSectCacheSize THEN cSectCache[cSectCacheContents] := m.cs; INC(cSectCacheContents); ELSE WinBase.DeleteCriticalSection(m.cs); DISPOSE(m.cs); END; m.cs := NIL; END; WinBase.LeaveCriticalSection(cm) END FreeCSect; (*----------------------------------------------------------------- Mutex ---*) (* Note: RTHooks.{Unlock,Lock}Mutex are the routines called directly by the compiler. Acquire and Release are the routines exported through the Thread interface *) PROCEDURE Acquire (m: Mutex) = BEGIN LockMutex (m); END Acquire; PROCEDURE Release (m: Mutex) = BEGIN UnlockMutex (m); END Release; PROCEDURE (*RTHooks.*)LockMutex (m: Mutex) = BEGIN IF (m.cs = NIL) THEN AllocCSect(m); END; WinBase.EnterCriticalSection(m.cs); IF m.held THEN Die("attempt to lock mutex already locked by self") END; m.held := TRUE; END LockMutex; PROCEDURE (*RTHooks.*)UnlockMutex(m: Mutex) = BEGIN IF NOT m.held THEN Die("attempt to release an unlocked mutex") END; m.held := FALSE; WinBase.LeaveCriticalSection(m.cs); END UnlockMutex; (*---------------------------------------- Condition variables and Alerts ---*) PROCEDURE InnerWait(m: Mutex; c: Condition; self: T) = (* LL = cm+m on entry; LL = m on exit *) BEGIN <* ASSERT( (self.waitingOn=NIL) AND (self.nextWaiter=NIL) ) *> self.waitingOn := c; self.nextWaiter := c.waiters; c.waiters := self; WinBase.LeaveCriticalSection(cm); UnlockMutex(m); IF WinBase.WaitForSingleObject(self.waitSema, WinBase.INFINITE) # 0 THEN Choke(); END; LockMutex(m); END InnerWait; PROCEDURE InnerTestAlert(self: T) RAISES {Alerted} = (* LL = cm on entry; LL = cm on normal exit, 0 on exception exit *) (* If self.alerted, clear "alerted", leave cm and raise "Alerted". *) BEGIN IF self.alerted THEN self.alerted := FALSE; WinBase.LeaveCriticalSection(cm); RAISE Alerted END; END InnerTestAlert; PROCEDURE AlertWait (m: Mutex; c: Condition) RAISES {Alerted} = (* LL = m *) VAR self := Self(); BEGIN IF self = NIL THEN Die("AlertWait called from non-Modula-3 thread") END; WinBase.EnterCriticalSection(cm); InnerTestAlert(self); self.alertable := TRUE; InnerWait(m, c, self); WinBase.EnterCriticalSection(cm); InnerTestAlert(self); WinBase.LeaveCriticalSection(cm); END AlertWait; PROCEDURE Wait (m: Mutex; c: Condition) = (* LL = m *) VAR self := Self(); BEGIN IF self = NIL THEN Die("Wait called from non-Modula-3 thread") END; WinBase.EnterCriticalSection(cm); InnerWait(m, c, self); END Wait; PROCEDURE DequeueHead(c: Condition) = (* LL = cm *) VAR t: T; prevCount: WinDef.LONG; BEGIN t := c.waiters; c.waiters := t.nextWaiter; t.nextWaiter := NIL; t.waitingOn := NIL; t.alertable := FALSE; IF WinBase.ReleaseSemaphore(t.waitSema, 1, ADR(prevCount)) = 0 THEN Choke(); END; END DequeueHead; PROCEDURE Signal (c: Condition) = BEGIN WinBase.EnterCriticalSection(cm); IF c.waiters # NIL THEN DequeueHead(c) END; WinBase.LeaveCriticalSection(cm); END Signal; PROCEDURE Broadcast (c: Condition) = BEGIN WinBase.EnterCriticalSection(cm); WHILE c.waiters # NIL DO DequeueHead(c) END; WinBase.LeaveCriticalSection(cm); END Broadcast; PROCEDURE Alert(t: T) = VAR prevCount: WinDef.LONG; prev, next: T; BEGIN IF t = NIL THEN Die("Alert called from non-Modula-3 thread") END; WinBase.EnterCriticalSection(cm); t.alerted := TRUE; IF t.alertable THEN (* Dequeue from any CV and unblock from the semaphore *) IF t.waitingOn # NIL THEN next := t.waitingOn.waiters; prev := NIL; WHILE next # t DO <* ASSERT(next#NIL) *> prev := next; next := next.nextWaiter; END; IF prev = NIL THEN t.waitingOn.waiters := t.nextWaiter ELSE prev.nextWaiter := t.nextWaiter; END; t.nextWaiter := NIL; t.waitingOn := NIL; END; t.alertable := FALSE; IF WinBase.ReleaseSemaphore(t.waitSema, 1, ADR(prevCount)) = 0 THEN Choke(); END; END; WinBase.LeaveCriticalSection(cm); END Alert; PROCEDURE TestAlert(): BOOLEAN = VAR self := Self(); result: BOOLEAN; BEGIN IF self = NIL THEN (* Not created by Fork; not alertable *) RETURN FALSE ELSE WinBase.EnterCriticalSection(cm); result := self.alerted; IF result THEN self.alerted := FALSE END; WinBase.LeaveCriticalSection(cm); RETURN result END; END TestAlert; (*------------------------------------------------------------------ Self ---*) VAR threadIndex: WinDef.DWORD; (* read-only; TLS (Thread Local Storage) index *) VAR (* LL = threadMu *) n_slotted := 0; next_slot := 1; slots : REF ARRAY OF T; (* NOTE: we don't use slots[0]. *) PROCEDURE Self (): T = (* If not the initial thread and not created by Fork, returns NIL *) VAR t: T; x := LOOPHOLE(WinBase.TlsGetValue(threadIndex), INTEGER); BEGIN IF (x < 1) THEN RETURN NIL; END; t := slots[x]; IF (t.slot # x) THEN Die ("thread with bad slot!"); END; RETURN t; END Self; PROCEDURE SetSelf (t: T) = (* LL = 0 *) BEGIN IF (slots [t.slot] # t) THEN Die ("unslotted thread!"); END; IF WinBase.TlsSetValue(threadIndex, LOOPHOLE(t.slot, WinDef.LPVOID)) = 0 THEN Choke(); END; END SetSelf; PROCEDURE AssignSlot (t: T): INTEGER = (* LL = threadMu *) BEGIN (* make sure we have room to register this guy *) IF (slots = NIL) THEN slots := NEW (REF ARRAY OF T, 20); END; IF (n_slotted >= LAST (slots^)) THEN ExpandSlots (); END; (* look for an empty slot *) WHILE (slots [next_slot] # NIL) DO INC (next_slot); IF (next_slot >= NUMBER (slots^)) THEN next_slot := 1; END; END; INC (n_slotted); t.slot := next_slot; slots [next_slot] := t; RETURN t.slot; END AssignSlot; PROCEDURE FreeSlot (t: T) = (* LL = threadMu *) BEGIN DEC (n_slotted); WITH z = slots [t.slot] DO IF (z # t) THEN Die ("unslotted thread!"); END; z := NIL; END; t.slot := 0; END FreeSlot; PROCEDURE ExpandSlots () = VAR n := NUMBER (slots^); new := NEW (REF ARRAY OF T, n+n); BEGIN SUBARRAY (new^, 0, n) := slots^; slots := new; END ExpandSlots; (*------------------------------------------------------------ Fork, Join ---*) CONST MaxIdle = 20; VAR (* LL=threadMu *) threadMu: Mutex; allThreads: T := NIL; (* global list of registered threads *) idleThreads: T := NIL; (* global list of idle threads *) nIdle := 0; PROCEDURE CreateT(): T = (* LL < threadMu, because allocated a traced reference may cause the allocator to start a collection which will call SuspendOthers which will try to acquire threadMu. *) BEGIN RETURN NEW(T, waitSema := WinBase.CreateSemaphore(NIL, 0, 1, NIL), cond := NEW(Condition)); END CreateT; (* ThreadBase calls ThreadMain after finding (approximately) where its stack begins. This dance ensures that all of ThreadMain's traced references are within the stack scanned by the collector. *) PROCEDURE ThreadBase(param: WinDef.DWORD): WinDef.DWORD = VAR self: T; x := LOOPHOLE(param, INTEGER); BEGIN LockMutex(threadMu); self := slots[x]; self.stackbase := ADR(self); UnlockMutex(threadMu); ThreadMain(self); RETURN 0; END ThreadBase; PROCEDURE ThreadMain(self: T) = TYPE ObjRef = UNTRACED REF MethodList; MethodList = UNTRACED REF RECORD typecode: INTEGER; method0: ADDRESS END; VAR next_self: T; cl: Closure; res: REFANY; BEGIN LOOP (* The incarnation loop. *) SetSelf (self); LockMutex(threadMu); cl := self.closure; self.id := nextId; INC (nextId); UnlockMutex(threadMu); IF (cl = NIL) THEN Die ("NIL closure passed to Thread.Fork!"); ELSIF (LOOPHOLE (cl, ObjRef)^^.method0 = NIL) THEN Die ("NIL apply method passed to Thread.Fork!"); END; res := cl.apply(); next_self := NIL; IF nIdle < MaxIdle THEN (* apparently the cache isn't full, although we don't hold threadMu so we can't be certain... *) next_self := NEW(T); END; LockMutex(threadMu); self.result := res; self.completed := TRUE; IF next_self # NIL THEN (* transplant the guts of "self" into next_self *) next_self.handle := self.handle; next_self.stackbase := self.stackbase; next_self.waitSema := self.waitSema; next_self.cond := self.cond; (* put "next_self" on the list of all threads *) next_self.next := allThreads; next_self.prev := allThreads.prev; allThreads.prev.next := next_self; allThreads.prev := next_self; (* put "next_self" on the list of idle threads *) next_self.nextIdle := idleThreads; idleThreads := next_self; INC(nIdle); (* finish making "self" an orphan *) IF allThreads = self THEN allThreads := self.next; END; self.next.prev := self.prev; self.prev.next := self.next; self.next := NIL; self.prev := NIL; self.handle := NIL; self.stackbase := NIL; END; UnlockMutex(threadMu); Broadcast(self.cond); (* let everybody know that "self" is done *) IF next_self = NIL THEN EXIT; END; self := next_self; IF WinBase.WaitForSingleObject(self.waitSema, WinBase.INFINITE) # 0 THEN Choke(); END; END; (* remove ourself from the list of all threads *) LockMutex(threadMu); IF allThreads = self THEN allThreads := self.next; END; self.next.prev := self.prev; self.prev.next := self.next; self.next := NIL; self.prev := NIL; IF WinBase.CloseHandle(self.waitSema) = 0 THEN Choke() END; IF WinBase.CloseHandle(self.handle) = 0 THEN Choke() END; self.handle := NIL; self.waitSema := NIL; FreeSlot (self); UnlockMutex(threadMu); END ThreadMain; PROCEDURE Fork(closure: Closure): T = VAR t: T := NIL; id, stack_size: WinDef.DWORD; prevCount: WinDef.LONG; new_born: BOOLEAN; BEGIN (* determine the initial size of the stack for this thread *) stack_size := default_stack; TYPECASE closure OF SizedClosure (scl) => IF scl.stackSize # 0 THEN stack_size := scl.stackSize * BYTESIZE(INTEGER); END; ELSE (*skip*) END; (* try the cache for a thread *) LockMutex(threadMu); IF nIdle > 0 THEN new_born := FALSE; <* ASSERT(idleThreads # NIL) *> DEC(nIdle); t := idleThreads; idleThreads := t.nextIdle; t.nextIdle := NIL; t.slot := AssignSlot (t); ELSE (* empty cache => we need a fresh thread *) new_born := TRUE; UnlockMutex(threadMu); t := CreateT(); LockMutex(threadMu); t.slot := AssignSlot (t); t.handle := WinBase.CreateThread(NIL, stack_size, LOOPHOLE(ThreadBase, WinBase.LPTHREAD_START_ROUTINE), LOOPHOLE(t.slot,WinDef.LPVOID), WinBase.CREATE_SUSPENDED, ADR(id)); t.next := allThreads; t.prev := allThreads.prev; allThreads.prev.next := t; allThreads.prev := t; END; IF (t.handle = NIL) THEN Choke() END; t.closure := closure; UnlockMutex(threadMu); IF new_born THEN IF WinBase.ResumeThread(t.handle) = -1 THEN Choke() END; ELSE IF WinBase.ReleaseSemaphore(t.waitSema, 1, ADR(prevCount)) = 0 THEN Choke(); END; END; RETURN t END Fork; PROCEDURE Join(t: T): REFANY = VAR res: REFANY; BEGIN LockMutex(threadMu); IF t.joined THEN Die("attempt to join with thread twice"); END; WHILE NOT t.completed DO Wait(threadMu, t.cond) END; res := t.result; t.result := NIL; t.joined := TRUE; UnlockMutex(threadMu); RETURN res; END Join; PROCEDURE AlertJoin(t: T): REFANY RAISES {Alerted} = VAR res: REFANY; BEGIN LockMutex(threadMu); TRY IF t.joined THEN Die("attempt to join with thread twice"); END; WHILE NOT t.completed DO AlertWait(threadMu, t.cond) END; res := t.result; t.result := NIL; t.joined := TRUE; FINALLY UnlockMutex(threadMu); END; RETURN res; END AlertJoin; (*------------------------------------------------ timer-based preemption ---*) PROCEDURE SetSwitchingInterval (<*UNUSED*> usec: CARDINAL) = BEGIN END SetSwitchingInterval; (*---------------------------------------------------- Scheduling support ---*) PROCEDURE Pause(n: LONGREAL) = VAR amount, thisTime: LONGREAL; CONST Limit = FLOAT(LAST(CARDINAL), LONGREAL) / 1000.0D0 - 1.0D0; BEGIN amount := n; WHILE amount > 0.0D0 DO thisTime := MIN (Limit, amount); amount := amount - thisTime; WinBase.Sleep(ROUND(thisTime*1000.0D0)); END; END Pause; PROCEDURE AlertPause(n: LONGREAL) RAISES {Alerted} = VAR amount, thisTime: LONGREAL; CONST Limit = FLOAT(LAST(CARDINAL), LONGREAL) / 1000.0D0 - 1.0D0; VAR self: T; BEGIN self := Self(); amount := n; WHILE amount > 0.0D0 DO thisTime := MIN (Limit, amount); amount := amount - thisTime; WinBase.EnterCriticalSection(cm); InnerTestAlert(self); self.alertable := TRUE; <* ASSERT(self.waitingOn = NIL) *> WinBase.LeaveCriticalSection(cm); EVAL WinBase.WaitForSingleObject(self.waitSema, ROUND(thisTime*1.0D3)); WinBase.EnterCriticalSection(cm); self.alertable := FALSE; IF self.alerted THEN (* Sadly, the alert might have happened after we timed out on the semaphore and before we entered "cm". In that case, we need to decrement the semaphore's count *) EVAL WinBase.WaitForSingleObject(self.waitSema, 0); InnerTestAlert(self); END; WinBase.LeaveCriticalSection(cm); END; END AlertPause; PROCEDURE Yield() = BEGIN WinBase.Sleep(0); END Yield; (*--------------------------------------------------- Stack size controls ---*) PROCEDURE GetDefaultStackSize(): CARDINAL= BEGIN RETURN default_stack DIV BYTESIZE (INTEGER); END GetDefaultStackSize; PROCEDURE MinDefaultStackSize(new_min: CARDINAL)= BEGIN default_stack := MAX (default_stack, new_min * BYTESIZE (INTEGER)); END MinDefaultStackSize; PROCEDURE IncDefaultStackSize(inc: CARDINAL)= BEGIN INC (default_stack, inc * BYTESIZE (INTEGER)); END IncDefaultStackSize; (*-------------------------------------------- Exception handling support ---*) VAR handlersIndex: INTEGER; PROCEDURE GetCurrentHandlers(): ADDRESS= BEGIN RETURN WinBase.TlsGetValue(handlersIndex); END GetCurrentHandlers; PROCEDURE SetCurrentHandlers(h: ADDRESS)= BEGIN EVAL WinBase.TlsSetValue(handlersIndex, h); END SetCurrentHandlers; PROCEDURE PushEFrame (frame: ADDRESS) = TYPE Frame = UNTRACED REF RECORD next: ADDRESS END; VAR f := LOOPHOLE (frame, Frame); BEGIN f.next := WinBase.TlsGetValue(handlersIndex); EVAL WinBase.TlsSetValue(handlersIndex, f); END PushEFrame; PROCEDURE PopEFrame (frame: ADDRESS) = BEGIN EVAL WinBase.TlsSetValue(handlersIndex, frame); END PopEFrame; (*--------------------------------------------- Garbage collector support ---*) VAR suspend_mu : Mutex; suspend_cnt : CARDINAL := 0; (* LL = suspend_mu *) PROCEDURE SuspendOthers () = (* LL=0. Always bracketed with ResumeOthers, which will unlock threadMu *) VAR t: T; self := Self (); cnt: CARDINAL; BEGIN LOCK suspend_mu DO cnt := suspend_cnt; INC (suspend_cnt); END; IF (cnt = 0) THEN LockMutex(threadMu); WinBase.EnterCriticalSection(cm); (* We must hold 'cm' to guarantee that no suspended thread holds it. Otherwise, when the collector tries to acquire a mutex or signal a condition, it will deadlock with the suspended thread that holds 'cm'. *) t := self.next; WHILE (t # self) DO IF WinBase.SuspendThread(t.handle) = -1 THEN Choke() END; t := t.next; END; WinBase.LeaveCriticalSection(cm); END; END SuspendOthers; PROCEDURE ResumeOthers () = (* LL=threadMu. Always preceded by SuspendOthers, which locks threadMu *) VAR t: T; self := Self (); cnt: CARDINAL; BEGIN LOCK suspend_mu DO DEC (suspend_cnt); cnt := suspend_cnt; END; IF (cnt = 0) THEN t := self.next; WHILE (t # self) DO IF WinBase.ResumeThread(t.handle) = -1 THEN Choke() END; t := t.next; END; UnlockMutex(threadMu); END; END ResumeOthers; PROCEDURE ProcessStacks (p: PROCEDURE (start, stop: ADDRESS)) = (* LL=threadMu. Only called within {SuspendOthers, ResumeOthers} *) CONST UserRegs = Word.Or(ThreadContext.CONTEXT_CONTROL, ThreadContext.CONTEXT_INTEGER); VAR t := allThreads; context: ThreadContext.CONTEXT; fixed_SP: ADDRESS; BEGIN REPEAT IF (t.stackbase # NIL) THEN context.ContextFlags := UserRegs; IF WinBase.GetThreadContext(t.handle, ADR(context))=0 THEN Choke() END; fixed_SP := LOOPHOLE (context.Esp, ADDRESS); IF (t.stackbase - fixed_SP) > 10000 THEN fixed_SP := VerifySP (fixed_SP, t.stackbase); END; p(fixed_SP, t.stackbase); (* Process the stack *) p(ADR(context.Edi), ADR(context.Eip)); (* Process the registers *) END; t := t.next; UNTIL (t = allThreads); END ProcessStacks; PROCEDURE VerifySP (start, stop: ADDRESS): ADDRESS = (* Apparently, Win95 will lie about a thread's stack pointer! *) (* Verify that the claimed stack pages are really readable... *) CONST PageSize = 4096; CONST N = BYTESIZE (info); VAR info: WinNT.MEMORY_BASIC_INFORMATION; BEGIN (****** RTIO.PutText ("GC: suspicious stack: ["); RTIO.PutAddr (start); RTIO.PutText (".."); RTIO.PutAddr (stop); RTIO.PutText ("]\n"); RTIO.Flush (); ******) info.BaseAddress := LOOPHOLE (stop-1, ADDRESS); LOOP IF (info.BaseAddress <= start) THEN info.BaseAddress := start; EXIT; END; IF WinBase.VirtualQuery (info.BaseAddress, ADR (info), N) # N THEN Choke(); END; (******* RTIO.PutText (" --> "); RTIO.PutAddr (info.BaseAddress); RTIO.PutText (" "); RTIO.PutAddr (info.AllocationBase); RTIO.PutText (" "); RTIO.PutHex (info.AllocationProtect); RTIO.PutText (" "); RTIO.PutHex (info.RegionSize); RTIO.PutText (" "); RTIO.PutHex (info.State); RTIO.PutText (" "); RTIO.PutHex (info.Protect); RTIO.PutText (" "); RTIO.PutHex (info.Type); RTIO.PutText ("\n"); *******) (* is this chunk readable? *) IF (info.Protect # WinNT.PAGE_READWRITE) AND (info.Protect # WinNT.PAGE_READONLY) THEN (* nope, return the base of the last good chunk *) INC (info.BaseAddress, info.RegionSize); EXIT; END; (* yep, try the next chunk *) DEC (info.BaseAddress, PageSize); END; (******** RTIO.PutText (" ==> ["); RTIO.PutAddr (info.BaseAddress); RTIO.PutText (".."); RTIO.PutAddr (stop); RTIO.PutText ("]"); RTIO.PutText ("\n"); RTIO.Flush (); *******) RETURN info.BaseAddress; END VerifySP; (*------------------------------------------------------------ misc. junk ---*) PROCEDURE MyId(): Id RAISES {}= VAR self := Self (); BEGIN RETURN self.id; END MyId; (*---------------------------------------------------------------- errors ---*) PROCEDURE Die(msg: TEXT) = BEGIN RTMisc.FatalError ("ThreadWin32.m3", 721, "Thread client error: ", msg); END Die; PROCEDURE Choke() = BEGIN RTMisc.FatalErrorI ( "ThreadWin32.m3, line 726: Windows OS failure, GetLastError = ", WinBase.GetLastError ()); END Choke; (*-------------------------------------------------------- Initialization ---*) PROCEDURE Init() = VAR self: T; threadhandle, processhandle: WinNT.HANDLE; BEGIN handlersIndex := WinBase.TlsAlloc(); IF handlersIndex < 0 THEN Choke() END; threadIndex := WinBase.TlsAlloc(); IF threadIndex < 0 THEN Choke() END; cm := NEW(WinBase.LPCRITICAL_SECTION); WinBase.InitializeCriticalSection(cm); suspend_mu := NEW(Mutex); suspend_cnt := 0; threadMu := NEW(Mutex); self := CreateT(); LockMutex(threadMu); threadhandle := WinBase.GetCurrentThread(); processhandle := WinBase.GetCurrentProcess(); IF WinBase.DuplicateHandle(processhandle, threadhandle, processhandle, LOOPHOLE(ADR(self.handle), WinNT.PHANDLE), 0, 0, WinNT.DUPLICATE_SAME_ACCESS) = 0 THEN Choke(); END; self.slot := AssignSlot (self); self.id := nextId; INC (nextId); self.next := self; self.prev := self; allThreads := self; self.stackbase := RTLinker.info.bottom_of_stack; IF self.stackbase = NIL THEN Choke(); END; UnlockMutex(threadMu); SetSelf (self); END Init; BEGIN END ThreadWin32. From jayk123 at hotmail.com Mon Jan 28 13:25:20 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 28 Jan 2008 12:25:20 +0000 Subject: [M3devel] nt386gnu threads? Message-ID: ok, I partially take that back. It looks like pthreads are the path of least resistance.. but still probably not great perf since cygwin pthread mutexes are kernel objects.. (Win32 critical sections only involve the kernel if there is contention, Win32 mutexes are kernel objects.) - Jay From: jayk123 at hotmail.comTo: m3devel at elegosoft.comSubject: nt386gnu threads?Date: Mon, 28 Jan 2008 11:29:31 +0000 Can anyone confirm my read that PM3's NT386GNU used user/vtalarm threads?PM3 appears to have no PThread support ant its NT386GNU appears to have OS_TYPE=POSIX.Heck, even its NT386 has OS_TYPE=POSIX, but its NT386 is probably dead/broken. 1) I'm too lazy to tediously rewrite Cygwin's pthread.h et. al. into Modula-3.2) The thread library you pick is not an independent decision. The Modula-3 File I/O libraries interact with the threading library at least a little bit. The path of less resistance seems to be user/vtalarm threads for now, untilsuch time as Cygwin Upthread.i3 is written.(That is, neither pthreads nor win32 satisfied my laziness; I'm going to try user/vtalarm threads, see how it goes; I'm sure they aren't very good, but...) - Jay 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 neels at elego.de Mon Jan 28 13:25:40 2008 From: neels at elego.de (Neels Janosch Hofmeyr) Date: Mon, 28 Jan 2008 13:25:40 +0100 Subject: [M3devel] new unknown qualification errors Message-ID: <479DC9C4.30505@elego.de> Hi devel, I am trying to compile the suplib with the new 5.5.1 snapshot cm3. It worked fine with 5.4.0, but now I get errors I cannot figure out how to correct: ===> suplib --- building in LINUXLIBC6 --- new source -> compiling StatBufOffT64.m3 "../src/StatBufOffT64.m3", line 40: unknown qualification '.' (asLong) "../src/StatBufOffT64.m3", line 45: unknown qualification '.' (assignOffT) 2 errors encountered new source -> compiling Ugzip.m3 "../src/Ugzip.m3", line 63: unknown qualification '.' (DisableSwitching) "../src/Ugzip.m3", line 67: unknown qualification '.' (EnableSwitching) "../src/Ugzip.m3", line 74: unknown qualification '.' (DisableSwitching) "../src/Ugzip.m3", line 78: unknown qualification '.' (EnableSwitching) 4 errors encountered new source -> compiling CVTree.m3 "../src/CVTree.m3", line 315: unknown qualification '.' (DisableSwitching) "../src/CVTree.m3", line 319: unknown qualification '.' (EnableSwitching) "../src/CVTree.m3", line 325: unknown qualification '.' (DisableSwitching) "../src/CVTree.m3", line 329: unknown qualification '.' (EnableSwitching) "../src/CVTree.m3", line 335: unknown qualification '.' (DisableSwitching) "../src/CVTree.m3", line 339: unknown qualification '.' (EnableSwitching) 6 errors encountered compilation failed => not building library "libsuplib.a" Fatal Error: package build failed I need help with all of these. However, I tried investigating the first one: Utypes.asLong() By coincidence, I saw that in FSPosix.m3, a line saying status.size := Utypes.asLong(statBuf.st_size); was changed to status.size := ORD(statBuf.st_size); Reading the log for the linux/Utypes.i3 gets me confused. It says how to make a off_t from a long, but doesn't say anything about the reverse direction. Is ORD(x) always the way to go? Here is the log extract: revision 1.4 date: 2007-11-29 03:53:15 +0100; author: hosking; state: Exp; lines: +0 -3; commitid: 3xU0vDzVxflBSpHs; Remove residual implementations of Utypes.asLong and Utypes.assignOffT. ---------------------------- revision 1.3 date: 2004-01-30 18:45:34 +0100; author: wagner; state: Exp; lines: +1 -0; add a procedure to assign values to off_t variables, as they may now be structured types, depending on the platform: PROCEDURE expandAssign(VAR dest: off_t; src: long) Well, where would API changes like these be documented, if I ever need to look them up on my own? Thanks, -- Neels Janosch Hofmeyr Software Developer neels at elego.de Public Key: http://binarchy.net/neels/neels.hofmeyr.public.key.asc elego Software Solutions GmbH http://www.elegosoft.com Gustav-Meyer-Allee 25, Geb?ude 12 HRB 77719 13355 Berlin, Germany Amtsgericht Charlottenburg Tel.: +49 30 23 45 86 96 Sitz der Gesellschaft: Berlin Fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Olaf Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From jayk123 at hotmail.com Mon Jan 28 13:37:12 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 28 Jan 2008 12:37:12 +0000 Subject: [M3devel] heap vs. stack? (sort of) In-Reply-To: References: Message-ID: I totally want common code, there's just no point in moving it into a separate function. For now I used a separate function, and I made it nested. I also tried WITH that got its value from "PickBuffer", also a useless function but at least small, but functions can't return open arrays. The problem with heap allocation is that it is slow. This code is optimizing it away in the first place for "small" strings, that's not my doing. Of course you have to pick some heuristic "small" and hope not to blow too much wasted stack. 256 bytes of stack is not small sometimes. It appears that nested functions have to occur up in the variable section but that is very dificult to glean from the documentation or the error messages. Blech. - Jay > Date: Mon, 28 Jan 2008 12:39:10 +0100> From: lemming at henning-thielemann.de> Subject: Re: [M3devel] heap vs. stack? (sort of)> To: jayk123 at hotmail.com> CC: m3devel at elegosoft.com> > > On Mon, 28 Jan 2008, Jay wrote:> > > Is it possible to have this pattern in Modula-3:> >> > PROCEDURE Parse (nm: TEXT; host: BOOLEAN): T = VAR len := Text.Length (nm); buf: ARRAY [0..255] OF CHAR; BEGIN IF (len <= NUMBER (buf)) THEN RETURN DoParse (nm, SUBARRAY (buf, 0, len), host); ELSE RETURN DoParse (nm, NEW (REF ARRAY OF CHAR, len)^, host); END; END Parse;> >> > PROCEDURE DoParse (nm_txt: TEXT; VAR nm: ARRAY OF CHAR; host: BOOLEAN): T => > I think it is a good idea to encapsulate the common code in DoParse. If> DoParse needs local variables, it can be turned into a local PROCEDURE of> Parse. On the other hand I doubt that it is sensible to reserve 256 bytes> on the stack also if they are not used, or only a part of them are used.> What's bad about always using NEW? I think Modula-3's memory management> has optimizations for small amounts of memory. _________________________________________________________________ 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 Jan 28 13:38:38 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 28 Jan 2008 12:38:38 +0000 Subject: [M3devel] nt386gnu threads? In-Reply-To: <200801281204.m0SC4oNp025190@camembert.async.caltech.edu> References: Your message of "Mon, 28 Jan 2008 11:29:31 GMT." <200801281204.m0SC4oNp025190@camembert.async.caltech.edu> Message-ID: Um, so the file exists..does it get compiled? Did you look at the m3makefiles? I skimmed the m3makefiles. I have not tried building PM3 myself. - Jay > To: jayk123 at hotmail.com> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] nt386gnu threads? > Date: Mon, 28 Jan 2008 04:04:50 -0800> From: mika at async.caltech.edu> > I am almost certain it uses Win32 threads. Attached: ThreadWin32.m3> from PM3-Klagenfurt> > Mika> > Jay writes:> >--_ddef1601-2afe-4ff4-9567-11d7fc5d354a_> >Content-Type: text/plain; charset="iso-8859-1"> >Content-Transfer-Encoding: quoted-printable> >> >Can anyone confirm my read that PM3's NT386GNU used user/vtalarm threads?> ....> > > (* Copyright (C) 1994, Digital Equipment Corporation *)> (* All rights reserved. *)> (* See the file COPYRIGHT for a full description. *)> (* *)> (* portions Copyright 1996, Critical Mass, Inc. *)> (* *)> (* Last modified on Fri Apr 26 10:21:56 PDT 1996 by heydon *)> (* modified on Thu Jun 15 09:06:37 PDT 1995 by kalsow *)> (* modified on Tue Oct 4 10:34:00 PDT 1994 by isard *)> (* modified on Tue May 4 10:20:03 PDT 1993 by mjordan *)> (* modified on Wed Apr 21 16:31:21 PDT 1993 by mcjones *)> (* modified on Fri Mar 26 15:04:39 PST 1993 by birrell *)> > UNSAFE MODULE ThreadWin32> EXPORTS Scheduler, Thread, ThreadF, RTThreadInit, RTHooks;> > IMPORT RTHeapRep, RTLinker, RTMisc, WinBase, WinDef, WinNT, ThreadContext;> IMPORT Word;> (*** IMPORT RTIO; ***)> > (*----------------------------------------- Exceptions, types and globals ---*)> > VAR> cm: WinBase.LPCRITICAL_SECTION;> (* Global lock for internals of Mutex and Condition *)> > default_stack: WinDef.DWORD := 16384;> > nextId: Id := 1;> > REVEAL> Mutex = BRANDED "MUTEX Win32-1.0" OBJECT> cs: WinBase.LPCRITICAL_SECTION := NIL;> held: BOOLEAN := FALSE;> (* LL = self.cs *)> (* Because critical sections are thread re-entrant *)> END;> > Condition = BRANDED "Thread.Condition Win32-1.0" OBJECT> waiters: T := NIL;> (* LL = cm *)> (* List of threads waiting on this CV. *)> END;> > T = BRANDED "Thread.T Win32-1.0" OBJECT> next, prev: T := NIL;> (* LL = threadMu; global doubly-linked, circular list of all threads *)> nextIdle: T := NIL;> (* LL = threadMu; global list of idle threads *)> handle: WinNT.HANDLE := NIL;> (* LL = threadMu; thread handle in Windows *)> stackbase: ADDRESS := NIL;> (* LL = threadMu; base of thread stack for use by GC *)> closure: Closure := NIL;> (* LL = threadMu *)> result: REFANY := NIL;> (* LL = threadMu; if not self.completed, used only by self;> if self.completed, read-only. *)> cond: Condition;> (* LL = threadMu; wait here to join, or for rebirth *)> waitingOn: Condition := NIL;> (* LL = cm; CV that we're blocked on *)> nextWaiter: T := NIL;> (* LL = cm; queue of threads waiting on the same CV *)> waitSema: WinNT.HANDLE := NIL;> (* binary semaphore for blocking during "Wait" *)> alertable: BOOLEAN := FALSE;> (* LL = cm; distinguishes between "Wait" and "AlertWait" *)> alerted: BOOLEAN := FALSE;> (* LL = cm; the alert flag, of course *)> completed: BOOLEAN := FALSE;> (* LL = threadMu; indicates that "result" is set *)> joined: BOOLEAN := FALSE;> (* LL = threadMu; "Join" or "AlertJoin" has already returned *)> id: Id;> (* LL = threadMu; unique ID of this thread *)> slot: INTEGER;> (* LL = threadMu; index into global array of active, slotted threads *)> END;> > (*------------------------------------------- Caches of critical sections ---*)> > CONST> CSectCacheSize = 20;> (* Everything should work OK if these are 0 *)> > VAR> cSectCache: ARRAY [0..CSectCacheSize-1] OF WinBase.LPCRITICAL_SECTION;> cSectCacheContents := 0;> > PROCEDURE AllocCSect(m: Mutex) => (* LL = 0 *)> (* If we can take a critical section from the cache, > do so; otherwise create it. In any case, register the containing> Mutex with the GC so that we can clean-up on de-allocation. *)> VAR mcs: WinBase.LPCRITICAL_SECTION := NIL; lost_race := FALSE;> BEGIN> WinBase.EnterCriticalSection(cm);> IF cSectCacheContents > 0 THEN> DEC(cSectCacheContents);> m.cs := cSectCache[cSectCacheContents];> ELSE> WinBase.LeaveCriticalSection(cm);> mcs := NEW(WinBase.LPCRITICAL_SECTION);> WinBase.EnterCriticalSection(cm);> IF (m.cs = NIL) THEN> m.cs := mcs;> WinBase.InitializeCriticalSection(m.cs);> ELSE> (* somebody else beat us thru the preceding NEW *)> lost_race := TRUE;> END;> END;> WinBase.LeaveCriticalSection(cm);> > IF lost_race> THEN DISPOSE (mcs);> ELSE RTHeapRep.RegisterFinalCleanup(m, FreeCSect);> END;> END AllocCSect;> > PROCEDURE FreeCSect(r: REFANY (*Mutex*) ) => (* LL < cm *)> (* Must not dereference any traced REF when called from GC *)> VAR m: Mutex := r;> BEGIN> WinBase.EnterCriticalSection(cm);> IF m.cs # NIL THEN> IF cSectCacheContents < CSectCacheSize THEN> cSectCache[cSectCacheContents] := m.cs;> INC(cSectCacheContents);> ELSE> WinBase.DeleteCriticalSection(m.cs);> DISPOSE(m.cs);> END;> m.cs := NIL;> END;> WinBase.LeaveCriticalSection(cm)> END FreeCSect;> > (*----------------------------------------------------------------- Mutex ---*)> (* Note: RTHooks.{Unlock,Lock}Mutex are the routines called directly by> the compiler. Acquire and Release are the routines exported through> the Thread interface *)> > PROCEDURE Acquire (m: Mutex) => BEGIN> LockMutex (m);> END Acquire;> > PROCEDURE Release (m: Mutex) => BEGIN> UnlockMutex (m);> END Release;> > PROCEDURE (*RTHooks.*)LockMutex (m: Mutex) => BEGIN> IF (m.cs = NIL) THEN AllocCSect(m); END;> WinBase.EnterCriticalSection(m.cs);> IF m.held THEN Die("attempt to lock mutex already locked by self") END;> m.held := TRUE;> END LockMutex;> > PROCEDURE (*RTHooks.*)UnlockMutex(m: Mutex) => BEGIN> IF NOT m.held THEN Die("attempt to release an unlocked mutex") END;> m.held := FALSE;> WinBase.LeaveCriticalSection(m.cs);> END UnlockMutex;> > (*---------------------------------------- Condition variables and Alerts ---*)> > PROCEDURE InnerWait(m: Mutex; c: Condition; self: T) => (* LL = cm+m on entry; LL = m on exit *)> BEGIN> <* ASSERT( (self.waitingOn=NIL) AND (self.nextWaiter=NIL) ) *>> self.waitingOn := c;> self.nextWaiter := c.waiters;> c.waiters := self;> WinBase.LeaveCriticalSection(cm);> UnlockMutex(m);> IF WinBase.WaitForSingleObject(self.waitSema, WinBase.INFINITE) # 0 THEN> Choke();> END;> LockMutex(m);> END InnerWait;> > PROCEDURE InnerTestAlert(self: T) RAISES {Alerted} => (* LL = cm on entry; LL = cm on normal exit, 0 on exception exit *)> (* If self.alerted, clear "alerted", leave cm and raise> "Alerted". *)> BEGIN> IF self.alerted THEN> self.alerted := FALSE;> WinBase.LeaveCriticalSection(cm);> RAISE Alerted> END;> END InnerTestAlert;> > PROCEDURE AlertWait (m: Mutex; c: Condition) RAISES {Alerted} => (* LL = m *)> VAR self := Self();> BEGIN> IF self = NIL THEN Die("AlertWait called from non-Modula-3 thread") END;> WinBase.EnterCriticalSection(cm);> InnerTestAlert(self);> self.alertable := TRUE;> InnerWait(m, c, self);> WinBase.EnterCriticalSection(cm);> InnerTestAlert(self);> WinBase.LeaveCriticalSection(cm);> END AlertWait;> > PROCEDURE Wait (m: Mutex; c: Condition) => (* LL = m *)> VAR self := Self();> BEGIN> IF self = NIL THEN Die("Wait called from non-Modula-3 thread") END;> WinBase.EnterCriticalSection(cm);> InnerWait(m, c, self);> END Wait;> > PROCEDURE DequeueHead(c: Condition) => (* LL = cm *)> VAR t: T; prevCount: WinDef.LONG;> BEGIN> t := c.waiters; c.waiters := t.nextWaiter;> t.nextWaiter := NIL;> t.waitingOn := NIL;> t.alertable := FALSE;> IF WinBase.ReleaseSemaphore(t.waitSema, 1, ADR(prevCount)) = 0 THEN> Choke();> END;> END DequeueHead;> > PROCEDURE Signal (c: Condition) => BEGIN> WinBase.EnterCriticalSection(cm);> IF c.waiters # NIL THEN DequeueHead(c) END;> WinBase.LeaveCriticalSection(cm);> END Signal;> > PROCEDURE Broadcast (c: Condition) => BEGIN> WinBase.EnterCriticalSection(cm);> WHILE c.waiters # NIL DO DequeueHead(c) END;> WinBase.LeaveCriticalSection(cm);> END Broadcast;> > PROCEDURE Alert(t: T) => VAR prevCount: WinDef.LONG; prev, next: T;> BEGIN> IF t = NIL THEN Die("Alert called from non-Modula-3 thread") END;> WinBase.EnterCriticalSection(cm);> t.alerted := TRUE;> IF t.alertable THEN> (* Dequeue from any CV and unblock from the semaphore *)> IF t.waitingOn # NIL THEN> next := t.waitingOn.waiters; prev := NIL;> WHILE next # t DO> <* ASSERT(next#NIL) *>> prev := next; next := next.nextWaiter;> END;> IF prev = NIL THEN> t.waitingOn.waiters := t.nextWaiter> ELSE> prev.nextWaiter := t.nextWaiter;> END;> t.nextWaiter := NIL;> t.waitingOn := NIL;> END;> t.alertable := FALSE;> IF WinBase.ReleaseSemaphore(t.waitSema, 1, ADR(prevCount)) = 0 THEN> Choke();> END;> END;> WinBase.LeaveCriticalSection(cm);> END Alert;> > PROCEDURE TestAlert(): BOOLEAN => VAR self := Self(); result: BOOLEAN;> BEGIN> IF self = NIL THEN> (* Not created by Fork; not alertable *)> RETURN FALSE> ELSE> WinBase.EnterCriticalSection(cm);> result := self.alerted; IF result THEN self.alerted := FALSE END;> WinBase.LeaveCriticalSection(cm);> RETURN result> END;> END TestAlert;> > (*------------------------------------------------------------------ Self ---*)> > VAR> threadIndex: WinDef.DWORD;> (* read-only; TLS (Thread Local Storage) index *)> > VAR (* LL = threadMu *)> n_slotted := 0;> next_slot := 1;> slots : REF ARRAY OF T; (* NOTE: we don't use slots[0]. *)> > PROCEDURE Self (): T => (* If not the initial thread and not created by Fork, returns NIL *)> VAR t: T; x := LOOPHOLE(WinBase.TlsGetValue(threadIndex), INTEGER);> BEGIN> IF (x < 1) THEN RETURN NIL; END;> t := slots[x];> IF (t.slot # x) THEN Die ("thread with bad slot!"); END;> RETURN t;> END Self;> > PROCEDURE SetSelf (t: T) => (* LL = 0 *)> BEGIN> IF (slots [t.slot] # t) THEN Die ("unslotted thread!"); END;> IF WinBase.TlsSetValue(threadIndex, LOOPHOLE(t.slot, WinDef.LPVOID)) = 0> THEN Choke();> END;> END SetSelf;> > PROCEDURE AssignSlot (t: T): INTEGER => (* LL = threadMu *)> BEGIN> (* make sure we have room to register this guy *)> IF (slots = NIL) THEN slots := NEW (REF ARRAY OF T, 20); END;> IF (n_slotted >= LAST (slots^)) THEN ExpandSlots (); END;> > (* look for an empty slot *)> WHILE (slots [next_slot] # NIL) DO> INC (next_slot);> IF (next_slot >= NUMBER (slots^)) THEN next_slot := 1; END;> END;> > INC (n_slotted);> t.slot := next_slot;> slots [next_slot] := t;> RETURN t.slot;> END AssignSlot;> > PROCEDURE FreeSlot (t: T) => (* LL = threadMu *)> BEGIN> DEC (n_slotted);> WITH z = slots [t.slot] DO> IF (z # t) THEN Die ("unslotted thread!"); END;> z := NIL;> END;> t.slot := 0;> END FreeSlot;> > PROCEDURE ExpandSlots () => VAR n := NUMBER (slots^); new := NEW (REF ARRAY OF T, n+n);> BEGIN> SUBARRAY (new^, 0, n) := slots^;> slots := new;> END ExpandSlots;> > (*------------------------------------------------------------ Fork, Join ---*)> > CONST> MaxIdle = 20;> > VAR (* LL=threadMu *)> threadMu: Mutex;> allThreads: T := NIL; (* global list of registered threads *)> idleThreads: T := NIL; (* global list of idle threads *)> nIdle := 0;> > PROCEDURE CreateT(): T => (* LL < threadMu, because allocated a traced reference may cause> the allocator to start a collection which will call SuspendOthers> which will try to acquire threadMu. *)> BEGIN> RETURN NEW(T, waitSema := WinBase.CreateSemaphore(NIL, 0, 1, NIL),> cond := NEW(Condition));> END CreateT;> > (* ThreadBase calls ThreadMain after finding (approximately) where> its stack begins. This dance ensures that all of ThreadMain's> traced references are within the stack scanned by the collector. *)> > PROCEDURE ThreadBase(param: WinDef.DWORD): WinDef.DWORD => VAR self: T; x := LOOPHOLE(param, INTEGER);> BEGIN> LockMutex(threadMu);> self := slots[x];> self.stackbase := ADR(self);> UnlockMutex(threadMu);> ThreadMain(self);> RETURN 0;> END ThreadBase;> > PROCEDURE ThreadMain(self: T) => TYPE> ObjRef = UNTRACED REF MethodList;> MethodList = UNTRACED REF RECORD typecode: INTEGER; method0: ADDRESS END;> VAR next_self: T; cl: Closure; res: REFANY;> BEGIN> LOOP (* The incarnation loop. *)> SetSelf (self);> > LockMutex(threadMu);> cl := self.closure;> self.id := nextId; INC (nextId);> UnlockMutex(threadMu);> > IF (cl = NIL) THEN> Die ("NIL closure passed to Thread.Fork!");> ELSIF (LOOPHOLE (cl, ObjRef)^^.method0 = NIL) THEN> Die ("NIL apply method passed to Thread.Fork!");> END;> > res := cl.apply();> > next_self := NIL;> IF nIdle < MaxIdle THEN> (* apparently the cache isn't full, although we don't hold threadMu> so we can't be certain... *)> next_self := NEW(T);> END;> > LockMutex(threadMu);> self.result := res;> self.completed := TRUE;> > IF next_self # NIL THEN> (* transplant the guts of "self" into next_self *)> next_self.handle := self.handle;> next_self.stackbase := self.stackbase;> next_self.waitSema := self.waitSema;> next_self.cond := self.cond;> > (* put "next_self" on the list of all threads *)> next_self.next := allThreads;> next_self.prev := allThreads.prev;> allThreads.prev.next := next_self;> allThreads.prev := next_self;> > (* put "next_self" on the list of idle threads *)> next_self.nextIdle := idleThreads;> idleThreads := next_self;> INC(nIdle);> > (* finish making "self" an orphan *)> IF allThreads = self THEN allThreads := self.next; END;> self.next.prev := self.prev;> self.prev.next := self.next;> self.next := NIL;> self.prev := NIL;> self.handle := NIL;> self.stackbase := NIL;> END;> UnlockMutex(threadMu);> > Broadcast(self.cond); (* let everybody know that "self" is done *)> > IF next_self = NIL THEN EXIT; END;> self := next_self;> IF WinBase.WaitForSingleObject(self.waitSema, WinBase.INFINITE) # 0 THEN> Choke();> END;> END;> > (* remove ourself from the list of all threads *)> LockMutex(threadMu);> IF allThreads = self THEN allThreads := self.next; END;> self.next.prev := self.prev;> self.prev.next := self.next;> self.next := NIL;> self.prev := NIL;> IF WinBase.CloseHandle(self.waitSema) = 0 THEN Choke() END;> IF WinBase.CloseHandle(self.handle) = 0 THEN Choke() END;> self.handle := NIL;> self.waitSema := NIL;> FreeSlot (self);> UnlockMutex(threadMu);> END ThreadMain;> > PROCEDURE Fork(closure: Closure): T => VAR> t: T := NIL;> id, stack_size: WinDef.DWORD;> prevCount: WinDef.LONG;> new_born: BOOLEAN;> BEGIN> (* determine the initial size of the stack for this thread *)> stack_size := default_stack;> TYPECASE closure OF SizedClosure (scl) =>> IF scl.stackSize # 0 THEN > stack_size := scl.stackSize * BYTESIZE(INTEGER);> END;> ELSE (*skip*)> END;> > (* try the cache for a thread *)> LockMutex(threadMu);> IF nIdle > 0 THEN> new_born := FALSE;> <* ASSERT(idleThreads # NIL) *>> DEC(nIdle);> t := idleThreads;> idleThreads := t.nextIdle;> t.nextIdle := NIL;> t.slot := AssignSlot (t);> ELSE (* empty cache => we need a fresh thread *)> new_born := TRUE;> UnlockMutex(threadMu);> t := CreateT();> LockMutex(threadMu);> t.slot := AssignSlot (t);> t.handle := WinBase.CreateThread(NIL, stack_size,> LOOPHOLE(ThreadBase, WinBase.LPTHREAD_START_ROUTINE),> LOOPHOLE(t.slot,WinDef.LPVOID), WinBase.CREATE_SUSPENDED, ADR(id));> t.next := allThreads;> t.prev := allThreads.prev;> allThreads.prev.next := t;> allThreads.prev := t;> END;> IF (t.handle = NIL) THEN Choke() END;> t.closure := closure;> UnlockMutex(threadMu);> > IF new_born THEN> IF WinBase.ResumeThread(t.handle) = -1 THEN Choke() END;> ELSE> IF WinBase.ReleaseSemaphore(t.waitSema, 1, ADR(prevCount)) = 0 THEN> Choke();> END;> END;> > RETURN t> END Fork;> > PROCEDURE Join(t: T): REFANY => VAR res: REFANY;> BEGIN> LockMutex(threadMu);> IF t.joined THEN Die("attempt to join with thread twice"); END;> WHILE NOT t.completed DO Wait(threadMu, t.cond) END;> res := t.result;> t.result := NIL;> t.joined := TRUE;> UnlockMutex(threadMu);> RETURN res;> END Join;> > PROCEDURE AlertJoin(t: T): REFANY RAISES {Alerted} => VAR res: REFANY;> BEGIN> LockMutex(threadMu);> TRY> IF t.joined THEN Die("attempt to join with thread twice"); END;> WHILE NOT t.completed DO AlertWait(threadMu, t.cond) END;> res := t.result;> t.result := NIL;> t.joined := TRUE;> FINALLY> UnlockMutex(threadMu);> END;> RETURN res;> END AlertJoin;> > (*------------------------------------------------ timer-based preemption ---*)> > PROCEDURE SetSwitchingInterval (<*UNUSED*> usec: CARDINAL) => BEGIN> END SetSwitchingInterval;> > (*---------------------------------------------------- Scheduling support ---*)> > PROCEDURE Pause(n: LONGREAL) => VAR amount, thisTime: LONGREAL;> CONST Limit = FLOAT(LAST(CARDINAL), LONGREAL) / 1000.0D0 - 1.0D0;> BEGIN> amount := n;> WHILE amount > 0.0D0 DO> thisTime := MIN (Limit, amount);> amount := amount - thisTime;> WinBase.Sleep(ROUND(thisTime*1000.0D0));> END;> END Pause;> > PROCEDURE AlertPause(n: LONGREAL) RAISES {Alerted} => VAR amount, thisTime: LONGREAL;> CONST Limit = FLOAT(LAST(CARDINAL), LONGREAL) / 1000.0D0 - 1.0D0;> VAR self: T;> BEGIN> self := Self();> amount := n;> WHILE amount > 0.0D0 DO> thisTime := MIN (Limit, amount);> amount := amount - thisTime;> WinBase.EnterCriticalSection(cm);> InnerTestAlert(self);> self.alertable := TRUE;> <* ASSERT(self.waitingOn = NIL) *>> WinBase.LeaveCriticalSection(cm);> EVAL WinBase.WaitForSingleObject(self.waitSema, ROUND(thisTime*1.0D3));> WinBase.EnterCriticalSection(cm);> self.alertable := FALSE;> IF self.alerted THEN> (* Sadly, the alert might have happened after we timed out on the> semaphore and before we entered "cm". In that case, we need to> decrement the semaphore's count *)> EVAL WinBase.WaitForSingleObject(self.waitSema, 0);> InnerTestAlert(self);> END;> WinBase.LeaveCriticalSection(cm);> END;> END AlertPause;> > PROCEDURE Yield() => BEGIN> WinBase.Sleep(0);> END Yield;> > (*--------------------------------------------------- Stack size controls ---*)> > PROCEDURE GetDefaultStackSize(): CARDINAL=> BEGIN> RETURN default_stack DIV BYTESIZE (INTEGER);> END GetDefaultStackSize;> > PROCEDURE MinDefaultStackSize(new_min: CARDINAL)=> BEGIN> default_stack := MAX (default_stack, new_min * BYTESIZE (INTEGER));> END MinDefaultStackSize;> > PROCEDURE IncDefaultStackSize(inc: CARDINAL)=> BEGIN> INC (default_stack, inc * BYTESIZE (INTEGER));> END IncDefaultStackSize;> > (*-------------------------------------------- Exception handling support ---*)> > VAR handlersIndex: INTEGER;> > PROCEDURE GetCurrentHandlers(): ADDRESS=> BEGIN> RETURN WinBase.TlsGetValue(handlersIndex);> END GetCurrentHandlers;> > PROCEDURE SetCurrentHandlers(h: ADDRESS)=> BEGIN> EVAL WinBase.TlsSetValue(handlersIndex, h);> END SetCurrentHandlers;> > PROCEDURE PushEFrame (frame: ADDRESS) => TYPE Frame = UNTRACED REF RECORD next: ADDRESS END;> VAR f := LOOPHOLE (frame, Frame);> BEGIN> f.next := WinBase.TlsGetValue(handlersIndex);> EVAL WinBase.TlsSetValue(handlersIndex, f);> END PushEFrame;> > PROCEDURE PopEFrame (frame: ADDRESS) => BEGIN> EVAL WinBase.TlsSetValue(handlersIndex, frame);> END PopEFrame;> > (*--------------------------------------------- Garbage collector support ---*)> > VAR> suspend_mu : Mutex;> suspend_cnt : CARDINAL := 0; (* LL = suspend_mu *)> > PROCEDURE SuspendOthers () => (* LL=0. Always bracketed with ResumeOthers, which will unlock threadMu *)> VAR t: T; self := Self (); cnt: CARDINAL;> BEGIN> LOCK suspend_mu DO> cnt := suspend_cnt;> INC (suspend_cnt);> END;> > IF (cnt = 0) THEN> LockMutex(threadMu);> > WinBase.EnterCriticalSection(cm);> (* We must hold 'cm' to guarantee that no suspended thread holds it.> Otherwise, when the collector tries to acquire a mutex or signal> a condition, it will deadlock with the suspended thread that> holds 'cm'. *)> > t := self.next;> WHILE (t # self) DO> IF WinBase.SuspendThread(t.handle) = -1 THEN Choke() END;> t := t.next;> END;> WinBase.LeaveCriticalSection(cm);> END;> END SuspendOthers;> > PROCEDURE ResumeOthers () => (* LL=threadMu. Always preceded by SuspendOthers, which locks threadMu *)> VAR t: T; self := Self (); cnt: CARDINAL;> BEGIN> LOCK suspend_mu DO> DEC (suspend_cnt);> cnt := suspend_cnt;> END;> > IF (cnt = 0) THEN> t := self.next;> WHILE (t # self) DO> IF WinBase.ResumeThread(t.handle) = -1 THEN Choke() END;> t := t.next;> END;> UnlockMutex(threadMu);> END;> END ResumeOthers;> > PROCEDURE ProcessStacks (p: PROCEDURE (start, stop: ADDRESS)) => (* LL=threadMu. Only called within {SuspendOthers, ResumeOthers} *)> CONST UserRegs = Word.Or(ThreadContext.CONTEXT_CONTROL,> ThreadContext.CONTEXT_INTEGER);> VAR t := allThreads; context: ThreadContext.CONTEXT; fixed_SP: ADDRESS;> BEGIN> REPEAT> IF (t.stackbase # NIL) THEN> context.ContextFlags := UserRegs;> IF WinBase.GetThreadContext(t.handle, ADR(context))=0 THEN Choke() END;> fixed_SP := LOOPHOLE (context.Esp, ADDRESS);> IF (t.stackbase - fixed_SP) > 10000 THEN> fixed_SP := VerifySP (fixed_SP, t.stackbase);> END;> p(fixed_SP, t.stackbase); (* Process the stack *)> p(ADR(context.Edi), ADR(context.Eip)); (* Process the registers *)> END;> t := t.next;> UNTIL (t = allThreads);> END ProcessStacks;> > PROCEDURE VerifySP (start, stop: ADDRESS): ADDRESS => (* Apparently, Win95 will lie about a thread's stack pointer! *)> (* Verify that the claimed stack pages are really readable... *)> CONST PageSize = 4096;> CONST N = BYTESIZE (info);> VAR info: WinNT.MEMORY_BASIC_INFORMATION;> BEGIN> > (******> RTIO.PutText ("GC: suspicious stack: [");> RTIO.PutAddr (start);> RTIO.PutText ("..");> RTIO.PutAddr (stop);> RTIO.PutText ("]\n");> RTIO.Flush ();> ******)> > info.BaseAddress := LOOPHOLE (stop-1, ADDRESS);> LOOP> IF (info.BaseAddress <= start) THEN> info.BaseAddress := start;> EXIT;> END;> > IF WinBase.VirtualQuery (info.BaseAddress, ADR (info), N) # N THEN> Choke();> END;> > (*******> RTIO.PutText (" --> "); RTIO.PutAddr (info.BaseAddress);> RTIO.PutText (" "); RTIO.PutAddr (info.AllocationBase);> RTIO.PutText (" "); RTIO.PutHex (info.AllocationProtect);> RTIO.PutText (" "); RTIO.PutHex (info.RegionSize);> RTIO.PutText (" "); RTIO.PutHex (info.State);> RTIO.PutText (" "); RTIO.PutHex (info.Protect);> RTIO.PutText (" "); RTIO.PutHex (info.Type);> RTIO.PutText ("\n");> *******)> > (* is this chunk readable? *)> IF (info.Protect # WinNT.PAGE_READWRITE)> AND (info.Protect # WinNT.PAGE_READONLY) THEN> (* nope, return the base of the last good chunk *)> INC (info.BaseAddress, info.RegionSize);> EXIT;> END;> > (* yep, try the next chunk *)> DEC (info.BaseAddress, PageSize);> END;> > (********> RTIO.PutText (" ==> [");> RTIO.PutAddr (info.BaseAddress);> RTIO.PutText ("..");> RTIO.PutAddr (stop);> RTIO.PutText ("]");> RTIO.PutText ("\n");> RTIO.Flush ();> *******)> > RETURN info.BaseAddress;> END VerifySP;> > (*------------------------------------------------------------ misc. junk ---*)> > PROCEDURE MyId(): Id RAISES {}=> VAR self := Self ();> BEGIN> RETURN self.id;> END MyId;> > (*---------------------------------------------------------------- errors ---*)> > PROCEDURE Die(msg: TEXT) => BEGIN> RTMisc.FatalError ("ThreadWin32.m3", 721, "Thread client error: ", msg);> END Die;> > PROCEDURE Choke() => BEGIN> RTMisc.FatalErrorI (> "ThreadWin32.m3, line 726: Windows OS failure, GetLastError = ",> WinBase.GetLastError ());> END Choke;> > (*-------------------------------------------------------- Initialization ---*)> > > PROCEDURE Init() => VAR> self: T;> threadhandle, processhandle: WinNT.HANDLE;> BEGIN> handlersIndex := WinBase.TlsAlloc();> IF handlersIndex < 0 THEN Choke() END;> > threadIndex := WinBase.TlsAlloc();> IF threadIndex < 0 THEN Choke() END;> > cm := NEW(WinBase.LPCRITICAL_SECTION);> WinBase.InitializeCriticalSection(cm);> > suspend_mu := NEW(Mutex);> suspend_cnt := 0;> > threadMu := NEW(Mutex);> self := CreateT();> > LockMutex(threadMu);> threadhandle := WinBase.GetCurrentThread();> processhandle := WinBase.GetCurrentProcess();> IF WinBase.DuplicateHandle(processhandle, threadhandle, processhandle,> LOOPHOLE(ADR(self.handle), WinNT.PHANDLE), 0,> 0, WinNT.DUPLICATE_SAME_ACCESS) = 0 THEN> Choke();> END;> self.slot := AssignSlot (self);> self.id := nextId; INC (nextId);> self.next := self;> self.prev := self;> allThreads := self;> self.stackbase := RTLinker.info.bottom_of_stack;> IF self.stackbase = NIL THEN Choke(); END;> UnlockMutex(threadMu);> SetSelf (self);> END Init;> > BEGIN> END ThreadWin32. _________________________________________________________________ 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 Jan 28 13:50:54 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 28 Jan 2008 12:50:54 +0000 Subject: [M3devel] new unknown qualification errors In-Reply-To: <479DC9C4.30505@elego.de> References: <479DC9C4.30505@elego.de> Message-ID: (Btw, I find these error messages poor. It should say asLong is not defined in module X, or type T in module X, and give full paths to the two relevant files..meanwhile, my cm3 is outputing user-unfriendly forward slashes on Windows so I could perhaps blow past uninteresting problems oops :) ) - Jay > Date: Mon, 28 Jan 2008 13:25:40 +0100> From: neels at elego.de> To: m3devel at elego.de> Subject: [M3devel] new unknown qualification errors> > Hi devel,> > I am trying to compile the suplib with the new 5.5.1 snapshot cm3. It > worked fine with 5.4.0, but now I get errors I cannot figure out how to > correct:> > ===> suplib> --- building in LINUXLIBC6 ---> > new source -> compiling StatBufOffT64.m3> "../src/StatBufOffT64.m3", line 40: unknown qualification '.' (asLong)> "../src/StatBufOffT64.m3", line 45: unknown qualification '.' (assignOffT)> 2 errors encountered> new source -> compiling Ugzip.m3> "../src/Ugzip.m3", line 63: unknown qualification '.' (DisableSwitching)> "../src/Ugzip.m3", line 67: unknown qualification '.' (EnableSwitching)> "../src/Ugzip.m3", line 74: unknown qualification '.' (DisableSwitching)> "../src/Ugzip.m3", line 78: unknown qualification '.' (EnableSwitching)> 4 errors encountered> new source -> compiling CVTree.m3> "../src/CVTree.m3", line 315: unknown qualification '.' (DisableSwitching)> "../src/CVTree.m3", line 319: unknown qualification '.' (EnableSwitching)> "../src/CVTree.m3", line 325: unknown qualification '.' (DisableSwitching)> "../src/CVTree.m3", line 329: unknown qualification '.' (EnableSwitching)> "../src/CVTree.m3", line 335: unknown qualification '.' (DisableSwitching)> "../src/CVTree.m3", line 339: unknown qualification '.' (EnableSwitching)> 6 errors encountered> compilation failed => not building library "libsuplib.a"> Fatal Error: package build failed> > > I need help with all of these. However, I tried investigating the first > one: Utypes.asLong()> > By coincidence, I saw that in FSPosix.m3, a line saying> status.size := Utypes.asLong(statBuf.st_size);> was changed to> status.size := ORD(statBuf.st_size);> > Reading the log for the linux/Utypes.i3 gets me confused. It says how to > make a off_t from a long, but doesn't say anything about the reverse > direction. Is ORD(x) always the way to go? Here is the log extract:> > revision 1.4> date: 2007-11-29 03:53:15 +0100; author: hosking; state: Exp; lines: > +0 -3; commitid: 3xU0vDzVxflBSpHs;> Remove residual implementations of Utypes.asLong and Utypes.assignOffT.> ----------------------------> revision 1.3> date: 2004-01-30 18:45:34 +0100; author: wagner; state: Exp; lines: > +1 -0;> add a procedure to assign values to off_t variables, as they may now be> structured types, depending on the platform:> > PROCEDURE expandAssign(VAR dest: off_t; src: long)> > > Well, where would API changes like these be documented, if I ever need > to look them up on my own?> Thanks,> > -- > Neels Janosch Hofmeyr> Software Developer> > neels at elego.de> Public Key: http://binarchy.net/neels/neels.hofmeyr.public.key.asc> > elego Software Solutions GmbH http://www.elegosoft.com> Gustav-Meyer-Allee 25, Geb?ude 12 HRB 77719> 13355 Berlin, Germany Amtsgericht Charlottenburg> Tel.: +49 30 23 45 86 96 Sitz der Gesellschaft: Berlin> Fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Olaf Wagner> > _________________________________________________________________ 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 dabenavidesd at yahoo.es Mon Jan 28 13:51:43 2008 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Mon, 28 Jan 2008 13:51:43 +0100 (CET) Subject: [M3devel] new unknown qualification errors In-Reply-To: <479DC9C4.30505@elego.de> Message-ID: <762336.53722.qm@web27110.mail.ukl.yahoo.com> Hi Neels: If I rememeber this happen since some time ago. Just look this post of mine, you need to change the IMPORT and the lines that compiler complains: https://mail.elegosoft.com/pipermail/m3devel/2008-January/000806.html: importing Scheduler instead of SchedulerPosix Then replace the call for the functions of SchedulerPosix for Scheduler I think that would solve that problem. Thanks, Daniel Benavides Neels Janosch Hofmeyr escribi?: Hi devel, I am trying to compile the suplib with the new 5.5.1 snapshot cm3. It worked fine with 5.4.0, but now I get errors I cannot figure out how to correct: ===> suplib --- building in LINUXLIBC6 --- new source -> compiling StatBufOffT64.m3 "../src/StatBufOffT64.m3", line 40: unknown qualification '.' (asLong) "../src/StatBufOffT64.m3", line 45: unknown qualification '.' (assignOffT) 2 errors encountered new source -> compiling Ugzip.m3 "../src/Ugzip.m3", line 63: unknown qualification '.' (DisableSwitching) "../src/Ugzip.m3", line 67: unknown qualification '.' (EnableSwitching) "../src/Ugzip.m3", line 74: unknown qualification '.' (DisableSwitching) "../src/Ugzip.m3", line 78: unknown qualification '.' (EnableSwitching) 4 errors encountered new source -> compiling CVTree.m3 "../src/CVTree.m3", line 315: unknown qualification '.' (DisableSwitching) "../src/CVTree.m3", line 319: unknown qualification '.' (EnableSwitching) "../src/CVTree.m3", line 325: unknown qualification '.' (DisableSwitching) "../src/CVTree.m3", line 329: unknown qualification '.' (EnableSwitching) "../src/CVTree.m3", line 335: unknown qualification '.' (DisableSwitching) "../src/CVTree.m3", line 339: unknown qualification '.' (EnableSwitching) 6 errors encountered compilation failed => not building library "libsuplib.a" Fatal Error: package build failed I need help with all of these. However, I tried investigating the first one: Utypes.asLong() By coincidence, I saw that in FSPosix.m3, a line saying status.size := Utypes.asLong(statBuf.st_size); was changed to status.size := ORD(statBuf.st_size); Reading the log for the linux/Utypes.i3 gets me confused. It says how to make a off_t from a long, but doesn't say anything about the reverse direction. Is ORD(x) always the way to go? Here is the log extract: revision 1.4 date: 2007-11-29 03:53:15 +0100; author: hosking; state: Exp; lines: +0 -3; commitid: 3xU0vDzVxflBSpHs; Remove residual implementations of Utypes.asLong and Utypes.assignOffT. ---------------------------- revision 1.3 date: 2004-01-30 18:45:34 +0100; author: wagner; state: Exp; lines: +1 -0; add a procedure to assign values to off_t variables, as they may now be structured types, depending on the platform: PROCEDURE expandAssign(VAR dest: off_t; src: long) Well, where would API changes like these be documented, if I ever need to look them up on my own? Thanks, -- Neels Janosch Hofmeyr Software Developer neels at elego.de Public Key: http://binarchy.net/neels/neels.hofmeyr.public.key.asc elego Software Solutions GmbH http://www.elegosoft.com Gustav-Meyer-Allee 25, Geb?ude 12 HRB 77719 13355 Berlin, Germany Amtsgericht Charlottenburg Tel.: +49 30 23 45 86 96 Sitz der Gesellschaft: Berlin Fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Olaf Wagner --------------------------------- ?Con Mascota por primera vez? - S? un mejor Amigo Entra en Yahoo! Respuestas. -------------- next part -------------- An HTML attachment was scrubbed... URL: From neels at elego.de Mon Jan 28 14:30:29 2008 From: neels at elego.de (Neels Janosch Hofmeyr) Date: Mon, 28 Jan 2008 14:30:29 +0100 Subject: [M3devel] new unknown qualification errors In-Reply-To: <762336.53722.qm@web27110.mail.ukl.yahoo.com> References: <762336.53722.qm@web27110.mail.ukl.yahoo.com> Message-ID: <479DD8F5.1090001@elego.de> Thanks Daniel, that seems to work. However, if SchedulerPosix does not support these calls (DisableSwitching and EnableSwitching), do we not end up with concurreny problems? (This assuming that the Scheduler internally calls SchedulerPosix on POSIX platforms, which I am just wildly guessing...) Thanks again, Neels Daniel Alejandro Benavides D. wrote: > Hi Neels: > If I rememeber this happen since some time ago. Just look this post of > mine, you need to change the IMPORT and the lines that compiler complains: > https://mail.elegosoft.com/pipermail/m3devel/2008-January/000806.html: > importing Scheduler instead of SchedulerPosix > Then replace the call for the functions of SchedulerPosix for Scheduler > I think that would solve that problem. > > Thanks, > > Daniel Benavides > > > > > > */Neels Janosch Hofmeyr /* escribi?: > > Hi devel, > > I am trying to compile the suplib with the new 5.5.1 snapshot cm3. It > worked fine with 5.4.0, but now I get errors I cannot figure out > how to > correct: > > ===> suplib > --- building in LINUXLIBC6 --- > > new source -> compiling StatBufOffT64.m3 > "../src/StatBufOffT64.m3", line 40: unknown qualification '.' (asLong) > "../src/StatBufOffT64.m3", line 45: unknown qualification '.' > (assignOffT) > 2 errors encountered > new source -> compiling Ugzip.m3 > "../src/Ugzip.m3", line 63: unknown qualification '.' > (DisableSwitching) > "../src/Ugzip.m3", line 67: unknown qualification '.' > (EnableSwitching) > "../src/Ugzip.m3", line 74: unknown qualification '.' > (DisableSwitching) > "../src/Ugzip.m3", line 78: unknown qualification '.' > (EnableSwitching) > 4 errors encountered > new source -> compiling CVTree.m3 > "../src/CVTree.m3", line 315: unknown qualification '.' > (DisableSwitching) > "../src/CVTree.m3", line 319: unknown qualification '.' > (EnableSwitching) > "../src/CVTree.m3", line 325: unknown qualification '.' > (DisableSwitching) > "../src/CVTree.m3", line 329: unknown qualification '.' > (EnableSwitching) > "../src/CVTree.m3", line 335: unknown qualification '.' > (DisableSwitching) > "../src/CVTree.m3", line 339: unknown qualification '.' > (EnableSwitching) > 6 errors encountered > compilation failed => not building library "libsuplib.a" > Fatal Error: package build failed > > > I need help with all of these. However, I tried investigating the > first > one: Utypes.asLong() > > By coincidence, I saw that in FSPosix.m3, a line saying > status.size := Utypes.asLong(statBuf.st_size); > was changed to > status.size := ORD(statBuf.st_size); > > Reading the log for the linux/Utypes.i3 gets me confused. It says > how to > make a off_t from a long, but doesn't say anything about the reverse > direction. Is ORD(x) always the way to go? Here is the log extract: > > revision 1.4 > date: 2007-11-29 03:53:15 +0100; author: hosking; state: Exp; lines: > +0 -3; commitid: 3xU0vDzVxflBSpHs; > Remove residual implementations of Utypes.asLong and > Utypes.assignOffT. > ---------------------------- > revision 1.3 > date: 2004-01-30 18:45:34 +0100; author: wagner; state: Exp; lines: > +1 -0; > add a procedure to assign values to off_t variables, as they may > now be > structured types, depending on the platform: > > PROCEDURE expandAssign(VAR dest: off_t; src: long) > > > Well, where would API changes like these be documented, if I ever > need > to look them up on my own? > Thanks, > > -- > Neels Janosch Hofmeyr > Software Developer > > neels at elego.de > Public Key: http://binarchy.net/neels/neels.hofmeyr.public.key.asc > > elego Software Solutions GmbH http://www.elegosoft.com > Gustav-Meyer-Allee 25, Geb?ude 12 HRB 77719 > 13355 Berlin, Germany Amtsgericht Charlottenburg > Tel.: +49 30 23 45 86 96 Sitz der Gesellschaft: Berlin > Fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Olaf Wagner > > > > > ?Con Mascota por primera vez? - S? un mejor Amigo > Entra en Yahoo! Respuestas > . -- Neels Janosch Hofmeyr Software Developer neels at elego.de Public Key: http://binarchy.net/neels/neels.hofmeyr.public.key.asc elego Software Solutions GmbH http://www.elegosoft.com Gustav-Meyer-Allee 25, Geb?ude 12 HRB 77719 13355 Berlin, Germany Amtsgericht Charlottenburg Tel.: +49 30 23 45 86 96 Sitz der Gesellschaft: Berlin Fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Olaf Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From lemming at henning-thielemann.de Mon Jan 28 14:38:37 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Mon, 28 Jan 2008 14:38:37 +0100 (MET) Subject: [M3devel] heap vs. stack? (sort of) In-Reply-To: References: Message-ID: On Mon, 28 Jan 2008, Jay wrote: > I totally want common code, there's just no point in moving it into a separate function. Are you concerned about efficiency or about readability? In the first case maybe <* INLINE *> helps? > I also tried WITH that got its value from "PickBuffer", also a useless > function but at least small, but functions can't return open arrays. Functions can return pointers to open arrays - isn't this enough? From neels at elego.de Mon Jan 28 14:40:12 2008 From: neels at elego.de (Neels Janosch Hofmeyr) Date: Mon, 28 Jan 2008 14:40:12 +0100 Subject: [M3devel] Utypes.asLong / Utypes.assignOffT Message-ID: <479DDB3C.4020300@elego.de> Hi, after some problems have been resolved, I still cannot figure out these errors: ===> suplib --- building in LINUXLIBC6 --- new source -> compiling StatBufOffT64.m3 "../src/StatBufOffT64.m3", line 40: unknown qualification '.' (asLong) "../src/StatBufOffT64.m3", line 45: unknown qualification '.' (assignOffT) They are trying to access the procedures Utypes.asLong Utypes.assignOffT Apparently, Utypes.asLong(..) can simply be replaced by ORD(..). Is this correct?? Concerning assignOffT, the commit log speaks of a function called PROCEDURE expandAssign(VAR dest: off_t; src: long) , but this function does not exist anywhere in the cm3 source tree (grep -r expandAssign yielded no results). How do I fix this line in suplib/src/StatBufOffT64.m3 (ll.43-46)? PROCEDURE SetStatSize(VAR st: struct_stat; size: CARDINAL) = BEGIN Utypes.assignOffT(st.st_size, size); END SetStatSize; "../src/StatBufOffT64.m3", line 45: unknown qualification '.' (assignOffT) Thanks -- Neels Janosch Hofmeyr Software Developer neels at elego.de Public Key: http://binarchy.net/neels/neels.hofmeyr.public.key.asc elego Software Solutions GmbH http://www.elegosoft.com Gustav-Meyer-Allee 25, Geb?ude 12 HRB 77719 13355 Berlin, Germany Amtsgericht Charlottenburg Tel.: +49 30 23 45 86 96 Sitz der Gesellschaft: Berlin Fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Olaf Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From jayk123 at hotmail.com Mon Jan 28 15:00:46 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 28 Jan 2008 14:00:46 +0000 Subject: [M3devel] heap vs. stack? (sort of) In-Reply-To: References: Message-ID: Both. In thinking about how to write the code, there is no point in splitting the code into two functions. They are each small and the one is only called once. The language should in general not force me to write functions merely to work over the type system. <*inline*> is not implemented by the integrated backend. I assume every function call I write will not be inlined. > Functions can return pointers to open arrays - isn't this enough? Yes that might help. I had tried like PROCEDURE PickBuffer(VAR buf: ARRAY OF CHAR; len: INTEGER): ARRAY OF CHAR = BEGIN IF len <= NUMBER(buf) RETURN buf; END; RETURN NEW ARRAY OF CHAR (len); END PickBuffer; PROCEDURE Parse(...) VAR stack: ARRAY [0..255] OF CHAR; BEGIN ... WITH buf = PickBuffer(stack, len) DO use buf END; END Parse but I couldn't come up with a PickBuffer that the compiler liked. PickBuffer is still a bit iffy. More generally in C++ I would implement that as a template class where one of the parameters is how much to preallocate. In C I would implement it as a struct and some functions and the initialization function would take the preallocated buffer and size. Surely Modula-3 can do either/both of those patterns well and it doesn't have to be reimplemented over and over. The Modula-3 code I see around the system is way more low level and repetitive than seems appropriate, more so than C code that I write. Another example is that it definitely appears that if I try to compile code with a path like \a\b\c\d\e\f\g\h\a\b\c\d\e\f\g...\foo.m3 that has more than around 32 path separators, I'll just get some random failures since the code just "gives up". M3Path has an array of 32 to store the positions of path separators. That whole chunk of code, to remove \.\ I'll probably rewrite to be both more efficient and have no such capacity limits. For \.\ it is trivial. For \..\ it takes a bit of cleverness -- rather than rely on any indefinite amount of storage, what you can do is first reverse the string, then whenever you se .., bump up a counter, whenever you see not .., bump it down, only copy from source to dest when the counter is zero. Roughly. Of course...maybe better here...count the slashes, if there are more than ~30, do the heap alloc, as in the previous pattern. Though it'd be nice, since it is possible, to handle arbitrarily long paths without the heap alloc. In a compacting garbage collection system, heap alloc can be roughly the cost of incrementing an integer. I do not assume Modula-3 has that, though maybe, and I do not assume it has particularly fast heap allocation. I have seen heap allocation just be very slow in general and I avoid it whenever possible/easy/correct. There are competing desires here of course. 1 Be fast. 2 Don't have fixed sized limits. (and esp. don't crash when you go past them! as I complained about recently..) 3 Don't use "too much" stack, however much that is. The easiest way to do #2 and #3 is always heap alloc exactly how much you need, but that kills #1. - Jay > Date: Mon, 28 Jan 2008 14:38:37 +0100> From: lemming at henning-thielemann.de> Subject: RE: [M3devel] heap vs. stack? (sort of)> To: jayk123 at hotmail.com> CC: m3devel at elegosoft.com> > > On Mon, 28 Jan 2008, Jay wrote:> > > I totally want common code, there's just no point in moving it into a separate function.> > Are you concerned about efficiency or about readability? In the first case> maybe <* INLINE *> helps?> > > I also tried WITH that got its value from "PickBuffer", also a useless> > function but at least small, but functions can't return open arrays.> > Functions can return pointers to open arrays - isn't this enough? _________________________________________________________________ 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 hendrik at topoi.pooq.com Mon Jan 28 15:46:29 2008 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Mon, 28 Jan 2008 09:46:29 -0500 Subject: [M3devel] heap vs. stack? (sort of) In-Reply-To: References: Message-ID: <20080128144629.GB1732@topoi.pooq.com> On Mon, Jan 28, 2008 at 02:00:46PM +0000, Jay wrote: > Both. > In thinking about how to write the code, there is no point in splitting the code into two functions. > They are each small and the one is only called once. > The language should in general not force me to write functions merely to work over the type system. > <*inline*> is not implemented by the integrated backend. I assume every function call I write will not be inlined. > > > Functions can return pointers to open arrays - isn't this enough? > > Yes that might help. > I had tried like > > PROCEDURE PickBuffer(VAR buf: ARRAY OF CHAR; len: INTEGER): ARRAY OF CHAR = > BEGIN > IF len <= NUMBER(buf) RETURN buf; > END; > RETURN NEW ARRAY OF CHAR (len); > END PickBuffer; > > PROCEDURE Parse(...) > VAR > stack: ARRAY [0..255] OF CHAR; > BEGIN > ... > WITH buf = PickBuffer(stack, len) DO use buf > END; > END Parse > > but I couldn't come up with a PickBuffer that the compiler liked. > > PickBuffer is still a bit iffy. > > More generally in C++ I would implement that as a template class where one of the parameters is how much to preallocate. In C I would implement it as a struct and some functions and the initialization function would take the preallocated buffer and size. > > Surely Modula-3 can do either/both of those patterns well and it doesn't have to be reimplemented over and over. > > The Modula-3 code I see around the system is way more low level and repetitive than seems appropriate, more so than C code that I write. > > Another example is that it definitely appears that if I try to compile code with a path like > \a\b\c\d\e\f\g\h\a\b\c\d\e\f\g...\foo.m3 > > that has more than around 32 path separators, I'll just get some random failures since the code just "gives up". > M3Path has an array of 32 to store the positions of path separators. > That whole chunk of code, to remove \.\ I'll probably rewrite to be both more efficient and have no such capacity limits. > For \.\ it is trivial. > For \..\ it takes a bit of cleverness -- rather than rely on any indefinite amount of storage, what you can do is first reverse the string, then whenever you se .., bump up a counter, whenever you see not .., bump it down, only copy from source to dest when the counter is zero. Roughly. If you are talking about paths for naming files, you might want to consider that (on Unix systems at least) '..' does not back out of a symbolic link, but may go somewhere else entirely. Whether you want this behaviour is, of course, up to you. -- hendrik From jayk123 at hotmail.com Mon Jan 28 16:40:59 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 28 Jan 2008 15:40:59 +0000 Subject: [M3devel] heap vs. stack? (sort of) In-Reply-To: <20080128144629.GB1732@topoi.pooq.com> References: <20080128144629.GB1732@topoi.pooq.com> Message-ID: > consider that (on Unix systems at least) '..' does not back out of a > symbolic link, but may go somewhere else entirely. Whether you want > this behaviour is, of course, up to you. cm3 does this. Not up to me or you probably. See m3-sys/cm3/src/M3Path.m3 PROCEDURE FixPath (VAR p: ARRAY OF CHAR; host: BOOLEAN): TEXT = (* remove redundant "/arc/../" and "/./" segments *) VAR os := os_map [host]; len, x, s0, s1, s2: INTEGER; info: SepInfo; - Jay > Date: Mon, 28 Jan 2008 09:46:29 -0500> From: hendrik at topoi.pooq.com> To: m3devel at elegosoft.com> Subject: Re: [M3devel] heap vs. stack? (sort of)> > On Mon, Jan 28, 2008 at 02:00:46PM +0000, Jay wrote:> > Both.> > In thinking about how to write the code, there is no point in splitting the code into two functions.> > They are each small and the one is only called once.> > The language should in general not force me to write functions merely to work over the type system.> > <*inline*> is not implemented by the integrated backend. I assume every function call I write will not be inlined.> > > > > Functions can return pointers to open arrays - isn't this enough?> > > > Yes that might help.> > I had tried like> > > > PROCEDURE PickBuffer(VAR buf: ARRAY OF CHAR; len: INTEGER): ARRAY OF CHAR => > BEGIN> > IF len <= NUMBER(buf) RETURN buf;> > END;> > RETURN NEW ARRAY OF CHAR (len);> > END PickBuffer;> > > > PROCEDURE Parse(...)> > VAR> > stack: ARRAY [0..255] OF CHAR;> > BEGIN> > ...> > WITH buf = PickBuffer(stack, len) DO use buf> > END;> > END Parse> > > > but I couldn't come up with a PickBuffer that the compiler liked.> > > > PickBuffer is still a bit iffy.> > > > More generally in C++ I would implement that as a template class where one of the parameters is how much to preallocate. In C I would implement it as a struct and some functions and the initialization function would take the preallocated buffer and size.> > > > Surely Modula-3 can do either/both of those patterns well and it doesn't have to be reimplemented over and over.> > > > The Modula-3 code I see around the system is way more low level and repetitive than seems appropriate, more so than C code that I write.> > > > Another example is that it definitely appears that if I try to compile code with a path like> > \a\b\c\d\e\f\g\h\a\b\c\d\e\f\g...\foo.m3> > > > that has more than around 32 path separators, I'll just get some random failures since the code just "gives up".> > M3Path has an array of 32 to store the positions of path separators.> > That whole chunk of code, to remove \.\ I'll probably rewrite to be both more efficient and have no such capacity limits.> > For \.\ it is trivial.> > For \..\ it takes a bit of cleverness -- rather than rely on any indefinite amount of storage, what you can do is first reverse the string, then whenever you se .., bump up a counter, whenever you see not .., bump it down, only copy from source to dest when the counter is zero. Roughly.> > If you are talking about paths for naming files, you might want to > consider that (on Unix systems at least) '..' does not back out of a > symbolic link, but may go somewhere else entirely. Whether you want > this behaviour is, of course, up to you.> > -- hendrik _________________________________________________________________ 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 Jan 28 17:02:25 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 28 Jan 2008 11:02:25 -0500 Subject: [M3devel] nt386gnu threads? In-Reply-To: References: Message-ID: <591840BD-4494-4A2C-AC0F-CD017338E5ED@cs.purdue.edu> On Jan 28, 2008, at 6:29 AM, Jay wrote: > Can anyone confirm my read that PM3's NT386GNU used user/vtalarm > threads? Indeed. Pthread support has only been available in CM3 since I started on it in in 2006. Thus, unless it was using Win32 threads it had to have been SIGVTALRM based (ie, implemented as in ThreadPosix.m3). > PM3 appears to have no PThread support ant its NT386GNU appears to > have OS_TYPE=POSIX. > Heck, even its NT386 has OS_TYPE=POSIX, but its NT386 is probably > dead/broken. > > 1) I'm too lazy to tediously rewrite Cygwin's pthread.h et. al. > into Modula-3. I am unfamiliar with Cygwin pthread support. Are they layered on win32 threads? It is not terribly hard to write Upthread.i3 and friends. > 2) The thread library you pick is not an independent decision. > The Modula-3 File I/O libraries interact with the threading > library at least a little bit. The POSIX file IO libraries are known to function with both ThreadPThread and ThreadPosix (SIGVTALRM). Thus, you should be able to use them cleanly if the Cygwin-based Modula-3 implementation takes on a purely/mainly POSIX personality (as many of us have argued it should!). > The path of less resistance seems to be user/vtalarm threads for > now, until > such time as Cygwin Upthread.i3 is written. Yes, indeed. > (That is, neither pthreads nor win32 satisfied my laziness; I'm > going to try user/vtalarm threads, see how it goes; I'm sure they > aren't very good, but...) Certainly, you won't get any multicore benefit with SIGVTALRM-based threads. From hosking at cs.purdue.edu Mon Jan 28 17:16:13 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 28 Jan 2008 11:16:13 -0500 Subject: [M3devel] new unknown qualification errors In-Reply-To: <479DD8F5.1090001@elego.de> References: <762336.53722.qm@web27110.mail.ukl.yahoo.com> <479DD8F5.1090001@elego.de> Message-ID: <758D5468-25A7-4853-BD61-F012890358A6@cs.purdue.edu> On Jan 28, 2008, at 8:30 AM, Neels Janosch Hofmeyr wrote: > Thanks Daniel, that seems to work. > > However, if SchedulerPosix does not support these calls > (DisableSwitching and EnableSwitching), do we not end up with > concurreny problems? (This assuming that the Scheduler internally > calls SchedulerPosix on POSIX platforms, which I am just wildly > guessing...) The calls to Schedule.DisableSwitching/EnableSwitching turn into different things for different threading subsystems. The reason is because SIGVTALRM-based thread scheduling (ThreadPosix) can cause thread switches in library code that is not thread-safe. Thus, certain system calls need to be wrapped in DisableSwitching/ EnableSwitching calls which prevent user-level threads switches. With system thread scheduling (ThreadPThread) the library calls are known to be thread-safe (since we link with a pthreads-aware C library) so DisableSwitching/EnableSwitching can be implemented as a no-op. The purpose of this is to allow suplib (and CVSup) to be compiled for all POSIX targets (both pthreads and user-threads). So, short answer to your question is: no, we don't end up with concurrency problems. > > Thanks again, > Neels > > Daniel Alejandro Benavides D. wrote: >> Hi Neels: >> If I rememeber this happen since some time ago. Just look this >> post of mine, you need to change the IMPORT and the lines that >> compiler complains: >> https://mail.elegosoft.com/pipermail/m3devel/2008-January/ >> 000806.html: >> importing Scheduler instead of SchedulerPosix Then replace the >> call for the functions of SchedulerPosix for Scheduler >> I think that would solve that problem. >> >> Thanks, >> >> Daniel Benavides >> >> >> >> >> */Neels Janosch Hofmeyr /* escribi?: >> >> Hi devel, >> >> I am trying to compile the suplib with the new 5.5.1 snapshot >> cm3. It >> worked fine with 5.4.0, but now I get errors I cannot figure out >> how to >> correct: >> >> ===> suplib >> --- building in LINUXLIBC6 --- >> >> new source -> compiling StatBufOffT64.m3 >> "../src/StatBufOffT64.m3", line 40: unknown qualification >> '.' (asLong) >> "../src/StatBufOffT64.m3", line 45: unknown qualification '.' >> (assignOffT) >> 2 errors encountered >> new source -> compiling Ugzip.m3 >> "../src/Ugzip.m3", line 63: unknown qualification '.' >> (DisableSwitching) >> "../src/Ugzip.m3", line 67: unknown qualification '.' >> (EnableSwitching) >> "../src/Ugzip.m3", line 74: unknown qualification '.' >> (DisableSwitching) >> "../src/Ugzip.m3", line 78: unknown qualification '.' >> (EnableSwitching) >> 4 errors encountered >> new source -> compiling CVTree.m3 >> "../src/CVTree.m3", line 315: unknown qualification '.' >> (DisableSwitching) >> "../src/CVTree.m3", line 319: unknown qualification '.' >> (EnableSwitching) >> "../src/CVTree.m3", line 325: unknown qualification '.' >> (DisableSwitching) >> "../src/CVTree.m3", line 329: unknown qualification '.' >> (EnableSwitching) >> "../src/CVTree.m3", line 335: unknown qualification '.' >> (DisableSwitching) >> "../src/CVTree.m3", line 339: unknown qualification '.' >> (EnableSwitching) >> 6 errors encountered >> compilation failed => not building library "libsuplib.a" >> Fatal Error: package build failed >> >> >> I need help with all of these. However, I tried investigating the >> first >> one: Utypes.asLong() >> >> By coincidence, I saw that in FSPosix.m3, a line saying >> status.size := Utypes.asLong(statBuf.st_size); >> was changed to >> status.size := ORD(statBuf.st_size); >> >> Reading the log for the linux/Utypes.i3 gets me confused. It says >> how to >> make a off_t from a long, but doesn't say anything about the >> reverse >> direction. Is ORD(x) always the way to go? Here is the log >> extract: >> >> revision 1.4 >> date: 2007-11-29 03:53:15 +0100; author: hosking; state: Exp; >> lines: >> +0 -3; commitid: 3xU0vDzVxflBSpHs; >> Remove residual implementations of Utypes.asLong and >> Utypes.assignOffT. >> ---------------------------- >> revision 1.3 >> date: 2004-01-30 18:45:34 +0100; author: wagner; state: Exp; >> lines: >> +1 -0; >> add a procedure to assign values to off_t variables, as they may >> now be >> structured types, depending on the platform: >> >> PROCEDURE expandAssign(VAR dest: off_t; src: long) >> >> >> Well, where would API changes like these be documented, if I ever >> need >> to look them up on my own? >> Thanks, >> >> -- Neels Janosch Hofmeyr >> Software Developer >> >> neels at elego.de >> Public Key: http://binarchy.net/neels/ >> neels.hofmeyr.public.key.asc >> >> elego Software Solutions GmbH http://www.elegosoft.com >> Gustav-Meyer-Allee 25, Geb?ude 12 HRB 77719 >> 13355 Berlin, Germany Amtsgericht Charlottenburg >> Tel.: +49 30 23 45 86 96 Sitz der Gesellschaft: Berlin >> Fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Olaf Wagner >> >> >> >> >> ?Con Mascota por primera vez? - S? un mejor Amigo >> Entra en Yahoo! Respuestas > *http://es.answers.yahoo.com/dir/ >> index;_ylc=X3oDMTE4ZWhyZjU0BF9TAzIxMTQ3MTQzMjIEc2VjA0Jhbm5lcgRzbGsDQW >> NxdWlzaXRpb24-?link=over&sid=XXXXXXXX>. > > -- > Neels Janosch Hofmeyr > Software Developer > > neels at elego.de > Public Key: http://binarchy.net/neels/neels.hofmeyr.public.key.asc > > elego Software Solutions GmbH http://www.elegosoft.com > Gustav-Meyer-Allee 25, Geb?ude 12 HRB 77719 > 13355 Berlin, Germany Amtsgericht Charlottenburg > Tel.: +49 30 23 45 86 96 Sitz der Gesellschaft: Berlin > Fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Olaf Wagner > > From jayk123 at hotmail.com Mon Jan 28 17:19:48 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 28 Jan 2008 16:19:48 +0000 Subject: [M3devel] nt386gnu threads? In-Reply-To: <591840BD-4494-4A2C-AC0F-CD017338E5ED@cs.purdue.edu> References: <591840BD-4494-4A2C-AC0F-CD017338E5ED@cs.purdue.edu> Message-ID: I understand how to write pthread.i3 but it is tedious and I am lazy. This idea that the headers have to be rewritten in Modula-3 bugs me. I realize it purchases my "crazy cross" but it's not the only way -- the native headers distributed to other machines could work....but then I realize it buys writing more Modula-3 and less C, and I'm not sure that's valuable. :) For now I've copied/pasted bits and pieces around to get m3core.dll to build. It builds. I believe Cygwin Pthreads are layered on Win32 threads. I'm sure they add cost oh well. Yes NT386GNU will use Cygwin and it'll be slow. NT386MINGNU will use cm3cg and only build slowly. It is painfully noticable how much more slowly NT386GNU m3cc builds than NT386MINGNU m3cc, presumably due to the underlying slower bash/sed/make etc. All just twiddle the slashes around... I did twiddle M3Path to print like c:/cm3 and accept either input. I probably will stil make it accept either input, since from a certain point of view, that is more correct. Oh, I had treating \ and / the same on all platforms -- surely \ never occurs anyway on Unix... :) The Cygwin stuff was either out of date for vtalarm, or I was building the wrong files and thought it was broken. So I went back to pthreads. Besides, vtalarm threads put you in the shady business of creating stacks and such.. - Jay > CC: m3devel at elegosoft.com> From: hosking at cs.purdue.edu> Subject: Re: [M3devel] nt386gnu threads?> Date: Mon, 28 Jan 2008 11:02:25 -0500> To: jayk123 at hotmail.com> > > On Jan 28, 2008, at 6:29 AM, Jay wrote:> > > Can anyone confirm my read that PM3's NT386GNU used user/vtalarm > > threads?> > Indeed. Pthread support has only been available in CM3 since I > started on it in in 2006. Thus, unless it was using Win32 threads it > had to have been SIGVTALRM based (ie, implemented as in ThreadPosix.m3).> > > PM3 appears to have no PThread support ant its NT386GNU appears to > > have OS_TYPE=POSIX.> > Heck, even its NT386 has OS_TYPE=POSIX, but its NT386 is probably > > dead/broken.> >> > 1) I'm too lazy to tediously rewrite Cygwin's pthread.h et. al. > > into Modula-3.> > I am unfamiliar with Cygwin pthread support. Are they layered on > win32 threads? It is not terribly hard to write Upthread.i3 and > friends.> > > 2) The thread library you pick is not an independent decision.> > The Modula-3 File I/O libraries interact with the threading > > library at least a little bit.> > The POSIX file IO libraries are known to function with both > ThreadPThread and ThreadPosix (SIGVTALRM). Thus, you should be able > to use them cleanly if the Cygwin-based Modula-3 implementation takes > on a purely/mainly POSIX personality (as many of us have argued it > should!).> > > The path of less resistance seems to be user/vtalarm threads for > > now, until> > such time as Cygwin Upthread.i3 is written.> > Yes, indeed.> > > (That is, neither pthreads nor win32 satisfied my laziness; I'm > > going to try user/vtalarm threads, see how it goes; I'm sure they > > aren't very good, but...)> > Certainly, you won't get any multicore benefit with SIGVTALRM-based > threads.> _________________________________________________________________ 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 Jan 28 17:26:45 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 28 Jan 2008 16:26:45 +0000 Subject: [M3devel] Open CM3 regression tests In-Reply-To: <20080127185530.e255i76vcwckss4o@mail.elegosoft.com> References: <20080120211832.GA26993@elegosoft.com> <9C00EA97-9B43-43BE-9CDF-EEAC9C1321D5@cs.purdue.edu> <20080127150327.mh686v2hx4w080w4@mail.elegosoft.com> <1DA9FA59-6DFF-430C-90C5-F1D30003607A@cs.purdue.edu> <20080127185530.e255i76vcwckss4o@mail.elegosoft.com> Message-ID: The tests don't even build on Windows and it was going to take more than 5 minutes fix that. They are slightly full of sh. :) (I never tire of this joke. :) ) My current plan is: get NT386GNU working -- I can already build cm3 and it fails an assertion about pthread_mutex_something failing. Hey, maybe I should fix some of the declarations.. :) or go back to my Mac briefly to investigate and/or give Tony a day :) - Jay From: jayk123 at hotmail.comTo: wagner at elegosoft.com; hosking at cs.purdue.eduCC: m3devel at elegosoft.comSubject: RE: [M3devel] Open CM3 regression testsDate: Sun, 27 Jan 2008 20:31:00 +0000 The functions are only used if the set doesn't fit in an integer.I'll try to look at this today. - Jay > Date: Sun, 27 Jan 2008 18:55:30 +0100> From: wagner at elegosoft.com> To: hosking at cs.purdue.edu> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] Open CM3 regression tests> > Quoting Tony Hosking :> > > The set operations are coded in > > cm3/m3-libs/m3core/src/Csupport/Common/hand.c.> >> > I notice Jay has made a number of changes here since September -- I> > wonder if they have broken something.> > I tried different revisions of this file with no difference in the> test results. I then took the latest version and added some printfs,> and they got never displayed. So I checked what gets linked, but the> symbols in question don't occur in the test program:> > % nm hand.o> U __divdi3> U __moddi3> 000001e0 R _highbits> 00000140 R _lowbits> 00000000 T m3_div> 000000ac T m3_divL> 000001d4 T m3_mod> 0000026c T m3_modL> U printf> 00000494 T set_difference> 00000554 T set_eq> 0000061c T set_ge> 000006ac T set_gt> 00000434 T set_intersection> 0000077c T set_le> 0000080c T set_lt> 000003a8 T set_member> 000005b8 T set_ne> 000008d8 T set_range> 000009d8 T set_singleton> 000004f4 T set_sym_difference> 000003d4 T set_union> > % nm /usr/local/cm3/pkg/m3core/FreeBSD4/libm3core.so.5 | grep set_> 000243d0 T set_difference> 00024490 T set_eq> 00024558 T set_ge> 000245fc T set_gt> 00024370 T set_intersection> 000246e0 T set_le> 00024784 T set_lt> 000242e4 T set_member> 000244f4 T set_ne> 00024864 T set_range> 00024998 T set_singleton> 00024430 T set_sym_difference> 00024310 T set_union> > % ldd FreeBSD4/p1/p155/FreeBSD4/pgm> FreeBSD4/p1/p155/FreeBSD4/pgm:> libtest.so.5 => > /d/home/wagner/work/cm3/m3-sys/m3tests/FreeBSD4/libtest.so.5 > (0x28085000)> libm3.so.5 => /usr/local/cm3/pkg/libm3/FreeBSD4/libm3.so.5 > (0x28088000)> libm3core.so.5 => > /usr/local/cm3/pkg/m3core/FreeBSD4/libm3core.so.5 (0x281aa000)> libm.so.4 => /lib/libm.so.4 (0x28a2d000)> libpthread.so.2 => /lib/libpthread.so.2 (0x28a46000)> libc.so.6 => /lib/libc.so.6 (0x28a6a000)> > % nm /usr/local/cm3/pkg/m3core/FreeBSD4/libm3core.so.5 | grep set_> 000243d0 T set_difference> 00024490 T set_eq> 00024558 T set_ge> 000245fc T set_gt> 00024370 T set_intersection> 000246e0 T set_le> 00024784 T set_lt> 000242e4 T set_member> 000244f4 T set_ne> 00024864 T set_range> 00024998 T set_singleton> 00024430 T set_sym_difference> 00024310 T set_union> luthien [~/work/cm3/m3-sys/m3tests] wagner> % ldd FreeBSD4/p1/p155/FreeBSD4/pgm> FreeBSD4/p1/p155/FreeBSD4/pgm:> libtest.so.5 => > /d/home/wagner/work/cm3/m3-sys/m3tests/FreeBSD4/libtest.so.5 > (0x28085000)> libm3.so.5 => /usr/local/cm3/pkg/libm3/FreeBSD4/libm3.so.5 > (0x28088000)> libm3core.so.5 => > /usr/local/cm3/pkg/m3core/FreeBSD4/libm3core.so.5 (0x281aa000)> libm.so.4 => /lib/libm.so.4 (0x28a2d000)> libpthread.so.2 => /lib/libpthread.so.2 (0x28a46000)> libc.so.6 => /lib/libc.so.6 (0x28a6a000)> luthien [~/work/cm3/m3-sys/m3tests] wagner> % nm -C -u FreeBSD4/p1/p155/FreeBSD4/pgm> U Main_I3> U RTHooks_I3> U RTHooks__CheckLoadTracedRef> U RTHooks__Concat> U RTHooks__PopEFrame> U RTHooks__PushEFrame> U RTHooks__TextLitGetChar> U RTHooks__TextLitGetChars> U RTHooks__TextLitGetWideChar> U RTHooks__TextLitGetWideChars> U RTHooks__TextLitInfo> U RTLinker__AddUnit> U RTLinker__InitRuntime> U RTProcess__Exit> U Stdio_I3> U Test_I3> U Test__checkM> U Test__done> U Wr_I3> U Wr__Flush> U Wr__PutText> w _Jv_RegisterClasses> w __deregister_frame_info> w __register_frame_info> U _init_tls> U _setjmp> U atexit> U exit> > Now I'm rather confused 8-/> > Any ideas?> > Olaf> -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194> 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 neels at elego.de Mon Jan 28 17:35:41 2008 From: neels at elego.de (Neels Janosch Hofmeyr) Date: Mon, 28 Jan 2008 17:35:41 +0100 Subject: [M3devel] Utypes.asLong / Utypes.assignOffT In-Reply-To: <479DDB3C.4020300@elego.de> References: <479DDB3C.4020300@elego.de> Message-ID: <479E045D.2000903@elego.de> Apparently, the answer to this is trivial. I found the missing functions in a CVS diff: -PROCEDURE asLong (val: off_t): long = - BEGIN - RETURN val; - END asLong; - -PROCEDURE assignOffT (VAR dest: off_t; src: long) = - BEGIN - dest := src; - END assignOffT; So, just replacing all occurences of these functions with direct assignments compiles without problems. y := Utypes.asLong(x) ==becomes==> y := ORD(x); x := Utypes.assignOffT(y) ==becomes==> x := y; Obviously, CVSup needs to be updated so that it compiles with the most recent CM3! The suplib still uses the obsoleted procedures asLong and assignOffT. Shall I write a mail to Mr. Polstra? Neels Neels Janosch Hofmeyr wrote: > Hi, > > after some problems have been resolved, I still cannot figure out > these errors: > > ===> suplib > --- building in LINUXLIBC6 --- > > new source -> compiling StatBufOffT64.m3 > "../src/StatBufOffT64.m3", line 40: unknown qualification '.' (asLong) > "../src/StatBufOffT64.m3", line 45: unknown qualification '.' > (assignOffT) > > They are trying to access the procedures > Utypes.asLong > Utypes.assignOffT > > Apparently, Utypes.asLong(..) can simply be replaced by ORD(..). Is > this correct?? > > Concerning assignOffT, the commit log speaks of a function called > PROCEDURE expandAssign(VAR dest: off_t; src: long) > , but this function does not exist anywhere in the cm3 source tree > (grep -r expandAssign yielded no results). > > > How do I fix this line in suplib/src/StatBufOffT64.m3 (ll.43-46)? > > PROCEDURE SetStatSize(VAR st: struct_stat; size: CARDINAL) = > BEGIN > Utypes.assignOffT(st.st_size, size); > END SetStatSize; > > "../src/StatBufOffT64.m3", line 45: unknown qualification '.' > (assignOffT) > > > Thanks > -- Neels Janosch Hofmeyr Software Developer neels at elego.de Public Key: http://binarchy.net/neels/neels.hofmeyr.public.key.asc elego Software Solutions GmbH http://www.elegosoft.com Gustav-Meyer-Allee 25, Geb?ude 12 HRB 77719 13355 Berlin, Germany Amtsgericht Charlottenburg Tel.: +49 30 23 45 86 96 Sitz der Gesellschaft: Berlin Fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Olaf Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From hosking at cs.purdue.edu Mon Jan 28 17:38:34 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 28 Jan 2008 11:38:34 -0500 Subject: [M3devel] heap vs. stack? (sort of) In-Reply-To: References: Message-ID: <3FB18C3C-0AE9-482F-AAAB-1196A81F73FB@cs.purdue.edu> <*INLINE*> currently does nothing with CM3. However, the gcc-based backend will inline procedures when optimizations are turned on. On Jan 28, 2008, at 8:38 AM, Henning Thielemann wrote: > > On Mon, 28 Jan 2008, Jay wrote: > >> I totally want common code, there's just no point in moving it >> into a separate function. > > Are you concerned about efficiency or about readability? In the > first case > maybe <* INLINE *> helps? > >> I also tried WITH that got its value from "PickBuffer", also a >> useless >> function but at least small, but functions can't return open arrays. > > Functions can return pointers to open arrays - isn't this enough? From hosking at cs.purdue.edu Mon Jan 28 17:43:35 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 28 Jan 2008 11:43:35 -0500 Subject: [M3devel] heap vs. stack? (sort of) In-Reply-To: References: Message-ID: <5DF1BB14-913D-460B-9F42-BA96B0B3682B@cs.purdue.edu> Modula-3 heap allocation is just bumping a pointer. The M3 GC is a copying (ie, compacting) collector. Fast path allocation doesn't even need synchronization since every thread allocates from its own private heap buffer. On Jan 28, 2008, at 9:00 AM, Jay wrote: > Both. > In thinking about how to write the code, there is no point in > splitting the code into two functions. > They are each small and the one is only called once. > The language should in general not force me to write functions > merely to work over the type system. > <*inline*> is not implemented by the integrated backend. I assume > every function call I write will not be inlined. > > > Functions can return pointers to open arrays - isn't this enough? > > Yes that might help. > I had tried like > > PROCEDURE PickBuffer(VAR buf: ARRAY OF CHAR; len: INTEGER): ARRAY > OF CHAR = > BEGIN > IF len <= NUMBER(buf) > RETURN buf; > END; > RETURN NEW ARRAY OF CHAR (len); > END PickBuffer; > > PROCEDURE Parse(...) > VAR > stack: ARRAY [0..255] OF CHAR; > BEGIN > ... > WITH buf = PickBuffer(stack, len) DO > use buf > END; > END Parse > > but I couldn't come up with a PickBuffer that the compiler liked. > > PickBuffer is still a bit iffy. > > More generally in C++ I would implement that as a template class > where one of the parameters is how much to preallocate. In C I > would implement it as a struct and some functions and the > initialization function would take the preallocated buffer and size. > > Surely Modula-3 can do either/both of those patterns well and it > doesn't have to be reimplemented over and over. > > The Modula-3 code I see around the system is way more low level and > repetitive than seems appropriate, more so than C code that I write. > > Another example is that it definitely appears that if I try to > compile code with a path like > \a\b\c\d\e\f\g\h\a\b\c\d\e\f\g...\foo.m3 > > that has more than around 32 path separators, I'll just get some > random failures since the code just "gives up". > M3Path has an array of 32 to store the positions of path separators. > That whole chunk of code, to remove \.\ I'll probably rewrite to be > both more efficient and have no such capacity limits. > For \.\ it is trivial. > For \..\ it takes a bit of cleverness -- rather than rely on any > indefinite amount of storage, what you can do is first reverse the > string, then whenever you se .., bump up a counter, whenever you > see not .., bump it down, only copy from source to dest when the > counter is zero. Roughly. > > Of course...maybe better here...count the slashes, if there are > more than ~30, do the heap alloc, as in the previous pattern. > Though it'd be nice, since it is possible, to handle arbitrarily > long paths without the heap alloc. > > In a compacting garbage collection system, heap alloc can be > roughly the cost of incrementing an integer. > I do not assume Modula-3 has that, though maybe, and I do not > assume it has particularly fast heap allocation. > I have seen heap allocation just be very slow in general and I > avoid it whenever possible/easy/correct. > > There are competing desires here of course. > 1 Be fast. > 2 Don't have fixed sized limits. (and esp. don't crash when you > go past them! as I complained about recently..) > 3 Don't use "too much" stack, however much that is. > > The easiest way to do #2 and #3 is always heap alloc exactly how > much you need, but that kills #1. > > - Jay > > > > > Date: Mon, 28 Jan 2008 14:38:37 +0100 > > From: lemming at henning-thielemann.de > > Subject: RE: [M3devel] heap vs. stack? (sort of) > > To: jayk123 at hotmail.com > > CC: m3devel at elegosoft.com > > > > > > On Mon, 28 Jan 2008, Jay wrote: > > > > > I totally want common code, there's just no point in moving it > into a separate function. > > > > Are you concerned about efficiency or about readability? In the > first case > > maybe <* INLINE *> helps? > > > > > I also tried WITH that got its value from "PickBuffer", also a > useless > > > function but at least small, but functions can't return open > arrays. > > > > Functions can return pointers to open arrays - isn't this enough? > > > Connect and share in new ways with Windows Live. Get it now! From hosking at cs.purdue.edu Mon Jan 28 17:55:24 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 28 Jan 2008 11:55:24 -0500 Subject: [M3devel] heap vs. stack? (sort of) In-Reply-To: References: Message-ID: <99035865-C3FD-45CB-8508-5D9C6B010D44@cs.purdue.edu> I actually find this idiom for avoiding heap allocation (assuming it really is expensive in the first place) particularly elegant. In any case, what's wrong with defining a generic procedure: PROCEDURE Apply (p: PROCEDURE(nm: ARRAY OF CHAR); nm: TEXT): T = VAR len := Text.Length(nm); buf: ARRAY [0..255] OF CHAR; BEGIN IF len <= NUMBER(buf) THEN RETURN p(SUBARRAY(buf, 0, len)); ELSE RETURN p(NEW(REF ARRAY OF CHAR, len)^); END; END Apply; and then use Apply to apply a nested procedure to the appropriate text at each place you need it? On Jan 28, 2008, at 4:48 AM, Jay wrote: > Is it possible to have this pattern in Modula-3: > > PROCEDURE Parse (nm: TEXT; host: BOOLEAN): T = > VAR len := Text.Length (nm); buf: ARRAY [0..255] OF CHAR; > BEGIN > IF (len <= NUMBER (buf)) > THEN RETURN DoParse (nm, SUBARRAY (buf, 0, len), host); > ELSE RETURN DoParse (nm, NEW (REF ARRAY OF CHAR, len)^, host); > END; > END Parse; > > PROCEDURE DoParse (nm_txt: TEXT; VAR nm: ARRAY OF CHAR; host: > BOOLEAN): T = > > without the extra function? > > There are places in M3Path.m3 that duplicate code otherwise, one > branch acting on a local stack allocated array, the other acting on > a heap allocated array when the stack array is too small, but > otherwise identical code. > > So far I have not figured out how. Local variables cannot be open > array. SUBARRAY returns an ARRAY and not a REF ARRAY... It seems > that parameters can be open arrays but local variables cannot, and > that seems wrong.. parameters and locals so often share > characteristics... > > - 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 Jan 28 17:55:39 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 28 Jan 2008 11:55:39 -0500 Subject: [M3devel] heap vs. stack? (sort of) In-Reply-To: <5DF1BB14-913D-460B-9F42-BA96B0B3682B@cs.purdue.edu> References: <5DF1BB14-913D-460B-9F42-BA96B0B3682B@cs.purdue.edu> Message-ID: I should say CM3 here. On Jan 28, 2008, at 11:43 AM, Tony Hosking wrote: > Modula-3 heap allocation is just bumping a pointer. The M3 GC is a > copying (ie, compacting) collector. Fast path allocation doesn't > even need synchronization since every thread allocates from its own > private heap buffer. > > On Jan 28, 2008, at 9:00 AM, Jay wrote: > >> Both. >> In thinking about how to write the code, there is no point in >> splitting the code into two functions. >> They are each small and the one is only called once. >> The language should in general not force me to write functions >> merely to work over the type system. >> <*inline*> is not implemented by the integrated backend. I assume >> every function call I write will not be inlined. >> >> > Functions can return pointers to open arrays - isn't this enough? >> >> Yes that might help. >> I had tried like >> >> PROCEDURE PickBuffer(VAR buf: ARRAY OF CHAR; len: INTEGER): ARRAY >> OF CHAR = >> BEGIN >> IF len <= NUMBER(buf) >> RETURN buf; >> END; >> RETURN NEW ARRAY OF CHAR (len); >> END PickBuffer; >> >> PROCEDURE Parse(...) >> VAR >> stack: ARRAY [0..255] OF CHAR; >> BEGIN >> ... >> WITH buf = PickBuffer(stack, len) DO >> use buf >> END; >> END Parse >> >> but I couldn't come up with a PickBuffer that the compiler liked. >> >> PickBuffer is still a bit iffy. >> >> More generally in C++ I would implement that as a template class >> where one of the parameters is how much to preallocate. In C I >> would implement it as a struct and some functions and the >> initialization function would take the preallocated buffer and size. >> >> Surely Modula-3 can do either/both of those patterns well and it >> doesn't have to be reimplemented over and over. >> >> The Modula-3 code I see around the system is way more low level >> and repetitive than seems appropriate, more so than C code that I >> write. >> >> Another example is that it definitely appears that if I try to >> compile code with a path like >> \a\b\c\d\e\f\g\h\a\b\c\d\e\f\g...\foo.m3 >> >> that has more than around 32 path separators, I'll just get some >> random failures since the code just "gives up". >> M3Path has an array of 32 to store the positions of path separators. >> That whole chunk of code, to remove \.\ I'll probably rewrite to >> be both more efficient and have no such capacity limits. >> For \.\ it is trivial. >> For \..\ it takes a bit of cleverness -- rather than rely on any >> indefinite amount of storage, what you can do is first reverse the >> string, then whenever you se .., bump up a counter, whenever you >> see not .., bump it down, only copy from source to dest when the >> counter is zero. Roughly. >> >> Of course...maybe better here...count the slashes, if there are >> more than ~30, do the heap alloc, as in the previous pattern. >> Though it'd be nice, since it is possible, to handle arbitrarily >> long paths without the heap alloc. >> >> In a compacting garbage collection system, heap alloc can be >> roughly the cost of incrementing an integer. >> I do not assume Modula-3 has that, though maybe, and I do not >> assume it has particularly fast heap allocation. >> I have seen heap allocation just be very slow in general and I >> avoid it whenever possible/easy/correct. >> >> There are competing desires here of course. >> 1 Be fast. >> 2 Don't have fixed sized limits. (and esp. don't crash when you >> go past them! as I complained about recently..) >> 3 Don't use "too much" stack, however much that is. >> >> The easiest way to do #2 and #3 is always heap alloc exactly how >> much you need, but that kills #1. >> >> - Jay >> >> >> >> > Date: Mon, 28 Jan 2008 14:38:37 +0100 >> > From: lemming at henning-thielemann.de >> > Subject: RE: [M3devel] heap vs. stack? (sort of) >> > To: jayk123 at hotmail.com >> > CC: m3devel at elegosoft.com >> > >> > >> > On Mon, 28 Jan 2008, Jay wrote: >> > >> > > I totally want common code, there's just no point in moving it >> into a separate function. >> > >> > Are you concerned about efficiency or about readability? In the >> first case >> > maybe <* INLINE *> helps? >> > >> > > I also tried WITH that got its value from "PickBuffer", also a >> useless >> > > function but at least small, but functions can't return open >> arrays. >> > >> > Functions can return pointers to open arrays - isn't this enough? >> >> >> Connect and share in new ways with Windows Live. Get it now! From hosking at cs.purdue.edu Mon Jan 28 18:03:10 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 28 Jan 2008 12:03:10 -0500 Subject: [M3devel] nt386gnu threads? In-Reply-To: References: <591840BD-4494-4A2C-AC0F-CD017338E5ED@cs.purdue.edu> Message-ID: <2AEEE262-57C1-4D62-AB21-CA977F6C273E@cs.purdue.edu> On Jan 28, 2008, at 11:19 AM, Jay wrote: > I understand how to write pthread.i3 but it is tedious and I am > lazy. This idea that the headers have to be rewritten in Modula-3 > bugs me. I realize it purchases my "crazy cross" but it's not the > only way -- the native headers distributed to other machines could > work....but then I realize it buys writing more Modula-3 and less > C, and I'm not sure that's valuable. :) > > For now I've copied/pasted bits and pieces around to get m3core.dll > to build. It builds. > I believe Cygwin Pthreads are layered on Win32 threads. > I'm sure they add cost oh well. > Yes NT386GNU will use Cygwin and it'll be slow. > NT386MINGNU will use cm3cg and only build slowly. > > It is painfully noticable how much more slowly NT386GNU m3cc builds > than NT386MINGNU m3cc, presumably due to the underlying slower bash/ > sed/make etc. > > All just twiddle the slashes around... I did twiddle M3Path to > print like c:/cm3 and accept either input. I probably will stil > make it accept either input, since from a certain point of view, > that is more correct. Oh, I had treating \ and / the same on all > platforms -- surely \ never occurs anyway on Unix... :) Not sure: can \ be used as an escape in file names? > The Cygwin stuff was either out of date for vtalarm, or I was > building the wrong files and thought it was broken. So I went back > to pthreads. Besides, vtalarm threads put you in the shady business > of creating stacks and such.. I think NT386GNU always used Win32 threads. > > > - Jay > > > > CC: m3devel at elegosoft.com > > From: hosking at cs.purdue.edu > > Subject: Re: [M3devel] nt386gnu threads? > > Date: Mon, 28 Jan 2008 11:02:25 -0500 > > To: jayk123 at hotmail.com > > > > > > On Jan 28, 2008, at 6:29 AM, Jay wrote: > > > > > Can anyone confirm my read that PM3's NT386GNU used user/vtalarm > > > threads? > > > > Indeed. Pthread support has only been available in CM3 since I > > started on it in in 2006. Thus, unless it was using Win32 threads it > > had to have been SIGVTALRM based (ie, implemented as in > ThreadPosix.m3). > > > > > PM3 appears to have no PThread support ant its NT386GNU appears to > > > have OS_TYPE=POSIX. > > > Heck, even its NT386 has OS_TYPE=POSIX, but its NT386 is probably > > > dead/broken. > > > > > > 1) I'm too lazy to tediously rewrite Cygwin's pthread.h et. al. > > > into Modula-3. > > > > I am unfamiliar with Cygwin pthread support. Are they layered on > > win32 threads? It is not terribly hard to write Upthread.i3 and > > friends. > > > > > 2) The thread library you pick is not an independent decision. > > > The Modula-3 File I/O libraries interact with the threading > > > library at least a little bit. > > > > The POSIX file IO libraries are known to function with both > > ThreadPThread and ThreadPosix (SIGVTALRM). Thus, you should be able > > to use them cleanly if the Cygwin-based Modula-3 implementation > takes > > on a purely/mainly POSIX personality (as many of us have argued it > > should!). > > > > > The path of less resistance seems to be user/vtalarm threads for > > > now, until > > > such time as Cygwin Upthread.i3 is written. > > > > Yes, indeed. > > > > > (That is, neither pthreads nor win32 satisfied my laziness; I'm > > > going to try user/vtalarm threads, see how it goes; I'm sure they > > > aren't very good, but...) > > > > Certainly, you won't get any multicore benefit with SIGVTALRM-based > > threads. > > > > > Helping your favorite cause is as easy as instant messaging. You > IM, we give. Learn more. From hosking at cs.purdue.edu Mon Jan 28 18:04:46 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 28 Jan 2008 12:04:46 -0500 Subject: [M3devel] Utypes.asLong / Utypes.assignOffT In-Reply-To: <479E045D.2000903@elego.de> References: <479DDB3C.4020300@elego.de> <479E045D.2000903@elego.de> Message-ID: <4C6699EA-187B-455D-A7D0-63A69FABF1B7@cs.purdue.edu> You will need to use VAL as I noted to handle the fact that off_t is LONGINT on some targets and INTEGER on others. On Jan 28, 2008, at 11:35 AM, Neels Janosch Hofmeyr wrote: > Apparently, the answer to this is trivial. I found the missing > functions in a CVS diff: > > -PROCEDURE asLong (val: off_t): long = > - BEGIN > - RETURN val; > - END asLong; > - > -PROCEDURE assignOffT (VAR dest: off_t; src: long) = > - BEGIN > - dest := src; > - END assignOffT; > > So, just replacing all occurences of these functions with direct > assignments compiles without problems. > y := Utypes.asLong(x) ==becomes==> y := ORD(x); > x := Utypes.assignOffT(y) ==becomes==> x := y; > > Obviously, CVSup needs to be updated so that it compiles with the > most recent CM3! The suplib still uses the obsoleted procedures > asLong and assignOffT. Shall I write a mail to Mr. Polstra? > > Neels > > Neels Janosch Hofmeyr wrote: >> Hi, >> >> after some problems have been resolved, I still cannot figure out >> these errors: >> >> ===> suplib >> --- building in LINUXLIBC6 --- >> >> new source -> compiling StatBufOffT64.m3 >> "../src/StatBufOffT64.m3", line 40: unknown qualification >> '.' (asLong) >> "../src/StatBufOffT64.m3", line 45: unknown qualification >> '.' (assignOffT) >> >> They are trying to access the procedures >> Utypes.asLong >> Utypes.assignOffT >> >> Apparently, Utypes.asLong(..) can simply be replaced by ORD(..). >> Is this correct?? >> >> Concerning assignOffT, the commit log speaks of a function called >> PROCEDURE expandAssign(VAR dest: off_t; src: long) >> , but this function does not exist anywhere in the cm3 source tree >> (grep -r expandAssign yielded no results). >> >> >> How do I fix this line in suplib/src/StatBufOffT64.m3 (ll.43-46)? >> >> PROCEDURE SetStatSize(VAR st: struct_stat; size: CARDINAL) = >> BEGIN >> Utypes.assignOffT(st.st_size, size); >> END SetStatSize; >> >> "../src/StatBufOffT64.m3", line 45: unknown qualification >> '.' (assignOffT) >> >> >> Thanks >> > > -- > Neels Janosch Hofmeyr > Software Developer > > neels at elego.de > Public Key: http://binarchy.net/neels/neels.hofmeyr.public.key.asc > > elego Software Solutions GmbH http://www.elegosoft.com > Gustav-Meyer-Allee 25, Geb?ude 12 HRB 77719 > 13355 Berlin, Germany Amtsgericht Charlottenburg > Tel.: +49 30 23 45 86 96 Sitz der Gesellschaft: Berlin > Fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Olaf Wagner > > From neels at elego.de Mon Jan 28 18:11:30 2008 From: neels at elego.de (Neels Janosch Hofmeyr) Date: Mon, 28 Jan 2008 18:11:30 +0100 Subject: [M3devel] Utypes.asLong / Utypes.assignOffT In-Reply-To: <4C6699EA-187B-455D-A7D0-63A69FABF1B7@cs.purdue.edu> References: <479DDB3C.4020300@elego.de> <479E045D.2000903@elego.de> <4C6699EA-187B-455D-A7D0-63A69FABF1B7@cs.purdue.edu> Message-ID: <479E0CC2.1020206@elego.de> So, if I understand correctly, this should read y := Utypes.asLong(x) ==becomes==> y := ORD(x); x := Utypes.assignOffT(y) ==becomes==> x := VAL(y); right? Tony Hosking wrote: > You will need to use VAL as I noted to handle the fact that off_t is > LONGINT on some targets and INTEGER on others. > > On Jan 28, 2008, at 11:35 AM, Neels Janosch Hofmeyr wrote: > >> Apparently, the answer to this is trivial. I found the missing >> functions in a CVS diff: >> >> -PROCEDURE asLong (val: off_t): long = >> - BEGIN >> - RETURN val; >> - END asLong; >> - >> -PROCEDURE assignOffT (VAR dest: off_t; src: long) = >> - BEGIN >> - dest := src; >> - END assignOffT; >> >> So, just replacing all occurences of these functions with direct >> assignments compiles without problems. >> y := Utypes.asLong(x) ==becomes==> y := ORD(x); >> x := Utypes.assignOffT(y) ==becomes==> x := y; >> >> Obviously, CVSup needs to be updated so that it compiles with the >> most recent CM3! The suplib still uses the obsoleted procedures >> asLong and assignOffT. Shall I write a mail to Mr. Polstra? >> >> Neels >> >> Neels Janosch Hofmeyr wrote: >>> Hi, >>> >>> after some problems have been resolved, I still cannot figure out >>> these errors: >>> >>> ===> suplib >>> --- building in LINUXLIBC6 --- >>> >>> new source -> compiling StatBufOffT64.m3 >>> "../src/StatBufOffT64.m3", line 40: unknown qualification '.' (asLong) >>> "../src/StatBufOffT64.m3", line 45: unknown qualification '.' >>> (assignOffT) >>> >>> They are trying to access the procedures >>> Utypes.asLong >>> Utypes.assignOffT >>> >>> Apparently, Utypes.asLong(..) can simply be replaced by ORD(..). Is >>> this correct?? >>> >>> Concerning assignOffT, the commit log speaks of a function called >>> PROCEDURE expandAssign(VAR dest: off_t; src: long) >>> , but this function does not exist anywhere in the cm3 source tree >>> (grep -r expandAssign yielded no results). >>> >>> >>> How do I fix this line in suplib/src/StatBufOffT64.m3 (ll.43-46)? >>> >>> PROCEDURE SetStatSize(VAR st: struct_stat; size: CARDINAL) = >>> BEGIN >>> Utypes.assignOffT(st.st_size, size); >>> END SetStatSize; >>> >>> "../src/StatBufOffT64.m3", line 45: unknown qualification '.' >>> (assignOffT) >>> >>> >>> Thanks >>> >> >> -- >> Neels Janosch Hofmeyr >> Software Developer >> >> neels at elego.de >> Public Key: http://binarchy.net/neels/neels.hofmeyr.public.key.asc >> >> elego Software Solutions GmbH http://www.elegosoft.com >> Gustav-Meyer-Allee 25, Geb?ude 12 HRB 77719 >> 13355 Berlin, Germany Amtsgericht Charlottenburg >> Tel.: +49 30 23 45 86 96 Sitz der Gesellschaft: Berlin >> Fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Olaf Wagner >> >> > -- Neels Janosch Hofmeyr Software Developer neels at elego.de Public Key: http://binarchy.net/neels/neels.hofmeyr.public.key.asc elego Software Solutions GmbH http://www.elegosoft.com Gustav-Meyer-Allee 25, Geb?ude 12 HRB 77719 13355 Berlin, Germany Amtsgericht Charlottenburg Tel.: +49 30 23 45 86 96 Sitz der Gesellschaft: Berlin Fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Olaf Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From neels at elego.de Mon Jan 28 18:22:21 2008 From: neels at elego.de (Neels Janosch Hofmeyr) Date: Mon, 28 Jan 2008 18:22:21 +0100 Subject: [M3devel] Utypes.asLong / Utypes.assignOffT In-Reply-To: <479E0CC2.1020206@elego.de> References: <479DDB3C.4020300@elego.de> <479E045D.2000903@elego.de> <4C6699EA-187B-455D-A7D0-63A69FABF1B7@cs.purdue.edu> <479E0CC2.1020206@elego.de> Message-ID: <479E0F4D.3050809@elego.de> Duh, that was definitely wrong. If anything, it should read y := Utypes.asLong(x) ==becomes==> y := ORD(x); x := Utypes.assignOffT(y) ==becomes==> x := VAL(y, Utypes.off_t); So, is this correct, now? Neels Janosch Hofmeyr wrote: > So, if I understand correctly, this should read > > y := Utypes.asLong(x) ==becomes==> y := ORD(x); > x := Utypes.assignOffT(y) ==becomes==> x := VAL(y); > > right? > > Tony Hosking wrote: >> You will need to use VAL as I noted to handle the fact that off_t is >> LONGINT on some targets and INTEGER on others. >> >> On Jan 28, 2008, at 11:35 AM, Neels Janosch Hofmeyr wrote: >> >>> Apparently, the answer to this is trivial. I found the missing >>> functions in a CVS diff: >>> >>> -PROCEDURE asLong (val: off_t): long = >>> - BEGIN >>> - RETURN val; >>> - END asLong; >>> - >>> -PROCEDURE assignOffT (VAR dest: off_t; src: long) = >>> - BEGIN >>> - dest := src; >>> - END assignOffT; >>> >>> So, just replacing all occurences of these functions with direct >>> assignments compiles without problems. >>> y := Utypes.asLong(x) ==becomes==> y := ORD(x); >>> x := Utypes.assignOffT(y) ==becomes==> x := y; >>> >>> Obviously, CVSup needs to be updated so that it compiles with the >>> most recent CM3! The suplib still uses the obsoleted procedures >>> asLong and assignOffT. Shall I write a mail to Mr. Polstra? >>> >>> Neels >>> >>> Neels Janosch Hofmeyr wrote: >>>> Hi, >>>> >>>> after some problems have been resolved, I still cannot figure out >>>> these errors: >>>> >>>> ===> suplib >>>> --- building in LINUXLIBC6 --- >>>> >>>> new source -> compiling StatBufOffT64.m3 >>>> "../src/StatBufOffT64.m3", line 40: unknown qualification '.' (asLong) >>>> "../src/StatBufOffT64.m3", line 45: unknown qualification '.' >>>> (assignOffT) >>>> >>>> They are trying to access the procedures >>>> Utypes.asLong >>>> Utypes.assignOffT >>>> >>>> Apparently, Utypes.asLong(..) can simply be replaced by ORD(..). Is >>>> this correct?? >>>> >>>> Concerning assignOffT, the commit log speaks of a function called >>>> PROCEDURE expandAssign(VAR dest: off_t; src: long) >>>> , but this function does not exist anywhere in the cm3 source tree >>>> (grep -r expandAssign yielded no results). >>>> >>>> >>>> How do I fix this line in suplib/src/StatBufOffT64.m3 (ll.43-46)? >>>> >>>> PROCEDURE SetStatSize(VAR st: struct_stat; size: CARDINAL) = >>>> BEGIN >>>> Utypes.assignOffT(st.st_size, size); >>>> END SetStatSize; >>>> >>>> "../src/StatBufOffT64.m3", line 45: unknown qualification '.' >>>> (assignOffT) >>>> >>>> >>>> Thanks >>>> >>> >>> -- >>> Neels Janosch Hofmeyr >>> Software Developer >>> >>> neels at elego.de >>> Public Key: http://binarchy.net/neels/neels.hofmeyr.public.key.asc >>> >>> elego Software Solutions GmbH http://www.elegosoft.com >>> Gustav-Meyer-Allee 25, Geb?ude 12 HRB 77719 >>> 13355 Berlin, Germany Amtsgericht Charlottenburg >>> Tel.: +49 30 23 45 86 96 Sitz der Gesellschaft: Berlin >>> Fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Olaf Wagner >>> >>> >> > -- Neels Janosch Hofmeyr Software Developer neels at elego.de Public Key: http://binarchy.net/neels/neels.hofmeyr.public.key.asc elego Software Solutions GmbH http://www.elegosoft.com Gustav-Meyer-Allee 25, Geb?ude 12 HRB 77719 13355 Berlin, Germany Amtsgericht Charlottenburg Tel.: +49 30 23 45 86 96 Sitz der Gesellschaft: Berlin Fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Olaf Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From jayk123 at hotmail.com Mon Jan 28 18:27:19 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 28 Jan 2008 17:27:19 +0000 Subject: [M3devel] nt386gnu threads? In-Reply-To: <2AEEE262-57C1-4D62-AB21-CA977F6C273E@cs.purdue.edu> References: <591840BD-4494-4A2C-AC0F-CD017338E5ED@cs.purdue.edu> <2AEEE262-57C1-4D62-AB21-CA977F6C273E@cs.purdue.edu> Message-ID: > > platforms -- surely \ never occurs anyway on Unix... :)> > Not sure: can \ be used as an escape in file names? Escaping? At the libc/kernel level? Are you serious? I assume they are taken literally and either accepted or rejected. I can try some stuff later. But, even if they are accepted literally, nobody uses them. FURTHERMORE, there is way too much low level parsing of paths. It's a big huge mess. They should probably be parsed into a higher level for internal manipulation and then regurgiated into an external form for the lower level APIs and for human display. Of course, abstraction abstraction abstraction show me the real thing already. :) > I think NT386GNU always used Win32 threads. I think not, but nobody has really said anything with certainty. I am not placing bets either way. I have the PM3 source from Elegosoft locally, simple cvs checkout. I haven't built it. It doesn't show much sign of using native Win32 threads, but I realize building the source and looking at the binaries is much more conclusive than reading the source. As well, what is PM3-Klagenfurt compard to what I am looking at? Should I go and get its source? And, what matters anyway? I think this Cygwin port is going to be mostly garbage anyway, and using pthreads does enhance the garbage somewhat what with pthread_once and pthread_cond, that NT doesn't have until Vista (sigh). Oh..I am remembering why it matters. Direct Win32 threads would be nice but you'd have to weed out other stuff, the dependency from the File APIs to the threading library. Once thie "port" is working and available, maybe someone else who actually uses it can improve it? (Bueller?) I'd like to get back to adding longint support to the integrated backend and possibly bringing up other targets.. I mean, heck, I'm no big user/fan of Unix, but running Unix natively has got to be better than this mismash.. And the pixmap bug, and the set regression test.. :) - 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 rcoleburn at scires.com Mon Jan 28 19:15:42 2008 From: rcoleburn at scires.com (Randy Coleburn) Date: Mon, 28 Jan 2008 13:15:42 -0500 Subject: [M3devel] cm3.cfg variables for IDE In-Reply-To: References: <591840BD-4494-4A2C-AC0F-CD017338E5ED@cs.purdue.edu> <2AEEE262-57C1-4D62-AB21-CA977F6C273E@cs.purdue.edu> Message-ID: <479DD57E.1E75.00D7.1@scires.com> Jay: I thought I should let you know what I understand to be the variables that the IDE is looking to find in cm3.cfg. That way, as you work through any changes to the various cm3.cfg, you can make sure these requirements are met. INSTALL_ROOT (e.g., c:\cm3) BUILD_DIR (e.g., NT386) PKG_USE (e.g., c:\cm3\pkg) DOC_INSTALL (e.g., c:\cm3\doc) INITIAL_CM3_IDE_BROWSER (e.g., c:\progra~1\intern~1\iexplore.exe) INITIAL_CM3_IDE_EDITOR (e.g., c:\progra~1\window~1\accessories\wordpad.exe) Now, of these 6 listed above, the first three: INSTALL_ROOT, BUILD_DIR and PKG_USE, are the most critical for the IDE. DOC_INSTALL can be omitted, in which case the IDE will substitute INSTALL_ROOT\doc If INITIAL_CM3_IDE_BROWSER and/or INITIAL_CM3_IDE_EDITOR are not defined, the IDE will prompt the user via its console log window for the complete paths to these two programs; thus their definition can be omitted from the cm3.cfg. The IDE will store the user's input for subsequent reuse in its own private cfg file. This file is stored in the user's home folder or as specified in the optional CM3_IDE_HOME environment variable. The CM3_IDE_HOME environment variable should point to the path of the user's primary private package repository. CM3_IDE_HOME should NOT be defined in cm3.cfg. If anyone wants to keep the cminstall program up-to-date, they should replace INITIAL_REACTOR_BROWSER and INITIAL_REACTOR_EDITOR with INITIAL_CM3_IDE_BROWSER and/or INITIAL_CM3_IDE_EDITOR . Regards, Randy -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon Jan 28 19:27:04 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 28 Jan 2008 13:27:04 -0500 Subject: [M3devel] nt386gnu threads? In-Reply-To: References: <591840BD-4494-4A2C-AC0F-CD017338E5ED@cs.purdue.edu> <2AEEE262-57C1-4D62-AB21-CA977F6C273E@cs.purdue.edu> Message-ID: <8A226653-07FE-4222-9D54-ADB55D6358CB@cs.purdue.edu> On Jan 28, 2008, at 12:27 PM, Jay wrote: > And the pixmap bug, and the set regression test.. :) :-) And the backend (for me to add stdcall tags), and a known bug in pthreads on FreeBSD, ... It's great that there is so much activity in CM3 these days though. > > > - Jay > > > Connect and share in new ways with Windows Live. Get it now! From jayk123 at hotmail.com Mon Jan 28 19:33:18 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 28 Jan 2008 18:33:18 +0000 Subject: [M3devel] nt386gnu threads? In-Reply-To: <8A226653-07FE-4222-9D54-ADB55D6358CB@cs.purdue.edu> References: <591840BD-4494-4A2C-AC0F-CD017338E5ED@cs.purdue.edu> <2AEEE262-57C1-4D62-AB21-CA977F6C273E@cs.purdue.edu> <8A226653-07FE-4222-9D54-ADB55D6358CB@cs.purdue.edu> Message-ID: I believe I'll have an ok workaround for the stdcall stuff. I think I even know how to fix it "properly". First I want the non-gui NT386GNU to work. It builds *now*, but doesn't work. - Jay > CC: m3devel at elegosoft.com> From: hosking at cs.purdue.edu> Subject: Re: [M3devel] nt386gnu threads?> Date: Mon, 28 Jan 2008 13:27:04 -0500> To: jayk123 at hotmail.com> > > On Jan 28, 2008, at 12:27 PM, Jay wrote:> > > And the pixmap bug, and the set regression test.. :)> > :-) And the backend (for me to add stdcall tags), and a known bug in > pthreads on FreeBSD, ...> > It's great that there is so much activity in CM3 these days though.> > >> >> > - 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 Jan 28 19:40:04 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 28 Jan 2008 18:40:04 +0000 Subject: [M3devel] cm3.cfg variables for IDE In-Reply-To: <479DD57E.1E75.00D7.1@scires.com> References: <591840BD-4494-4A2C-AC0F-CD017338E5ED@cs.purdue.edu> <2AEEE262-57C1-4D62-AB21-CA977F6C273E@cs.purdue.edu> <479DD57E.1E75.00D7.1@scires.com> Message-ID: There are other ways to do this...rather than run iexplore, you can use ShellExecute and run a url or something, or find the clsid of mshtml.dll maybe. For wordpad, again ShellExecute wil tend to find it. Notice how if you say start.run and type wordpad, it finds it? Or "start wordpad" from the command line? "start" ~ ShellExecute, instead of CreateProcess. "Shell" meaning the GUI shell -- Windows Explorer. Wordpad and notepad stink as text editors. And notepad doesn't like Unix newlines. I assume that's why wordepad. Someting should be done, like, in the grand gui installer, where it lists some freeware/shareware editors and offers to download and install and set them as the editor for you. Stuf like TextEdit, TextPad, UltraEdit...I think all of those exist, though somewhat I'm guesing based on the obvious formula. :) As well if it locate msdev or devenv that would be super. As I was saying the other day, I believe msdev and devenv are easily findable via normal installs, except not on my machines. :) I need to go through the environment you sent. The way this stuff works in Modula-3 today is..unnecessarily old fashioned...I'm all for simplicity, but having a bajillion environment variables does not seem to be the thing. Or a bajillion line user editor text files. Or short file names anywhere! Just do a backup/restore and see if those names survive. They might. They might not. Oh well, true, nobody ever backs anything up. Still, xcopy your software from one machine to another and see if the paths still work -- definitely it's hard to do that for free, but you can keep the cost down. - Jay Date: Mon, 28 Jan 2008 13:15:42 -0500From: rcoleburn at scires.comTo: jayk123 at hotmail.comCC: m3devel at elegosoft.comSubject: cm3.cfg variables for IDE Jay: I thought I should let you know what I understand to be the variables that the IDE is looking to find in cm3.cfg. That way, as you work through any changes to the various cm3.cfg, you can make sure these requirements are met. INSTALL_ROOT (e.g., c:\cm3)BUILD_DIR (e.g., NT386)PKG_USE (e.g., c:\cm3\pkg) DOC_INSTALL (e.g., c:\cm3\doc)INITIAL_CM3_IDE_BROWSER (e.g., c:\progra~1\intern~1\iexplore.exe)INITIAL_CM3_IDE_EDITOR (e.g., c:\progra~1\window~1\accessories\wordpad.exe) Now, of these 6 listed above, the first three: INSTALL_ROOT, BUILD_DIR and PKG_USE, are the most critical for the IDE. DOC_INSTALL can be omitted, in which case the IDE will substitute INSTALL_ROOT\doc If INITIAL_CM3_IDE_BROWSER and/or INITIAL_CM3_IDE_EDITOR are not defined, the IDE will prompt the user via its console log window for the complete paths to these two programs; thus their definition can be omitted from the cm3.cfg. The IDE will store the user's input for subsequent reuse in its own private cfg file. This file is stored in the user's home folder or as specified in the optional CM3_IDE_HOME environment variable. The CM3_IDE_HOME environment variable should point to the path of the user's primary private package repository. CM3_IDE_HOME should NOT be defined in cm3.cfg. If anyone wants to keep the cminstall program up-to-date, they should replace INITIAL_REACTOR_BROWSER and INITIAL_REACTOR_EDITOR with INITIAL_CM3_IDE_BROWSER and/or INITIAL_CM3_IDE_EDITOR . Regards, Randy _________________________________________________________________ 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 Jan 28 19:54:47 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 28 Jan 2008 18:54:47 +0000 Subject: [M3devel] NT386/NT386GNU/NT386MINGNU? In-Reply-To: <479DD57E.1E75.00D7.1@scires.com> References: <591840BD-4494-4A2C-AC0F-CD017338E5ED@cs.purdue.edu> <2AEEE262-57C1-4D62-AB21-CA977F6C273E@cs.purdue.edu> <479DD57E.1E75.00D7.1@scires.com> Message-ID: NT386/NT386GNU/NT386MINGNU My "vision" of these is pretty much in now.My weirdo target vs. configuration split. They are all TARGET = NT386. That's the "odd" part.TARGET = NT386GNU doesn't really mean anything.BUILD_DIR varies.OS_TYPE varies.Some other things vary. Does it suck or is it ok or is it great? Should they just be targets instead? This question is really aimed at the people who work on it, who have added new targets in the past, and who have perhaps thought about the SOLsun vs. SOLgnu split. How do you specify which you want? There are a few ways. Just use one usual cm3.cfg file next to cm3.exe (granted, you have to have around like four files, since they share code, NT386 and NT386GNU includes NT386.Common, NT386MINGNU includes NT386). or set the M3CONFIG variable; I've been doing that, right into the source tree. Or possibly CM3_TARGET + CM3_OSTYPE + CM3_GCC_BACKEND The Python code sniffs those. I've been trying that too. Or uname. Again the Python code sniffs. In the compiler, TARGET = NT386 + OS_TYPE == POSIX means Cygwin means a larger jmpbuf. Sleazy or reasonable? I think reasonable. There are still missing parts but it is taking shape. NT386GNU now builds, but you can't run the results at all, they crash.Been there before. :)(But it's obvious where to start here -- fix Upthread.i3.) m3makefiles have to cope, at least in m3core.They always did. You know, there are directories named POSIX, NT386, cygwin, pthread.That is, neither include(OS_TYPE) nor include(TARGET) were ever always correct. Sometimes there was special logic.Now there is just slightly more logic.Reasonable? One bit I feel guilty about is probably too much dependency on OS_TYPE.Some of that should probably be on C_LIBRARY and OS_TYPE should fall away ifC_LIBRARY / THREAD_LIBRARY / WINDOW_LIBRARY are used.I changed them from 0 and 1 to more readable like MS, GNU, X, CYG.There's also C_COMPILER = MS or GNULINKER = MS or GNU The primary users of these variables are NT386.Common. NT386GNU, NT386, NT386MINGNU are little stubs that set some variables and include it. Naming conventions isn't working correctly right now, must have been some oversight by me. Still much to do. Folks who favor one coniguration or the other should benchmark the build times.I should report them.The integrated backend is FAST.Cygwin is SLOW. For goodness sakes, look at how it implements fork(). It does an immediate selective copy, erring toward copying stuff. Yeah, it's nice and impressive that it even works, I realize.MinGWin is in betwen. AND you /should/ be able to target the Cygwin runtime using the integrated backend, and either compiler/lnker. That is, if you really want those forward slashes, and a fast build, that should be totally doable.I was thinking of making NT386FASTGNU, but it's not clear if it is builds fast or runs fast -- builds fast. Well, a native build of that would be in between. cm3 would still pay for Cygwin, but the backend would still be faster for most of its work. :) later, - 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 Jan 28 20:00:35 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 28 Jan 2008 19:00:35 +0000 Subject: [M3devel] NT386/NT386GNU/NT386MINGNU? In-Reply-To: References: <591840BD-4494-4A2C-AC0F-CD017338E5ED@cs.purdue.edu> <2AEEE262-57C1-4D62-AB21-CA977F6C273E@cs.purdue.edu> <479DD57E.1E75.00D7.1@scires.com> Message-ID: ps: NT386MINGNU really does not capture it -- it should like NT386_GNUTOOLS or NT386_GCCBACKEND As I've said, there's a bunch of independent variables, and precanned combinations are nice to have, but hard to chose just which ones and hard to name them... - Jay From: jayk123 at hotmail.comTo: m3devel at elegosoft.comDate: Mon, 28 Jan 2008 18:54:47 +0000Subject: [M3devel] NT386/NT386GNU/NT386MINGNU? NT386/NT386GNU/NT386MINGNU My "vision" of these is pretty much in now.My weirdo target vs. configuration split.They are all TARGET = NT386. That's the "odd" part.TARGET = NT386GNU doesn't really mean anything.BUILD_DIR varies.OS_TYPE varies.Some other things vary.Does it suck or is it ok or is it great?Should they just be targets instead?This question is really aimed at the people who work on it, who have added new targets in the past, and who have perhaps thought about the SOLsun vs. SOLgnu split.How do you specify which you want?There are a few ways. Just use one usual cm3.cfg file next to cm3.exe (granted, you have to have around like four files, since they share code, NT386 and NT386GNU includes NT386.Common, NT386MINGNU includes NT386). or set the M3CONFIG variable; I've been doing that, right into the source tree. Or possibly CM3_TARGET + CM3_OSTYPE + CM3_GCC_BACKEND The Python code sniffs those. I've been trying that too. Or uname. Again the Python code sniffs.In the compiler, TARGET = NT386 + OS_TYPE == POSIX means Cygwin means a larger jmpbuf. Sleazy or reasonable? I think reasonable.There are still missing parts but it is taking shape.NT386GNU now builds, but you can't run the results at all, they crash.Been there before. :)(But it's obvious where to start here -- fix Upthread.i3.)m3makefiles have to cope, at least in m3core.They always did. You know, there are directories named POSIX, NT386, cygwin, pthread.That is, neither include(OS_TYPE) nor include(TARGET) were ever always correct.Sometimes there was special logic.Now there is just slightly more logic.Reasonable?One bit I feel guilty about is probably too much dependency on OS_TYPE.Some of that should probably be on C_LIBRARY and OS_TYPE should fall away ifC_LIBRARY / THREAD_LIBRARY / WINDOW_LIBRARY are used.I changed them from 0 and 1 to more readable like MS, GNU, X, CYG.There's also C_COMPILER = MS or GNULINKER = MS or GNU The primary users of these variables are NT386.Common.NT386GNU, NT386, NT386MINGNU are little stubs that set some variables and include it.Naming conventions isn't working correctly right now, must have been some oversight by me.Still much to do.Folks who favor one coniguration or the other should benchmark the build times.I should report them.The integrated backend is FAST.Cygwin is SLOW. For goodness sakes, look at how it implements fork(). It does an immediate selective copy, erring toward copying stuff. Yeah, it's nice and impressive that it even works, I realize.MinGWin is in betwen. AND you /should/ be able to target the Cygwin runtime using the integrated backend, and either compiler/lnker.That is, if you really want those forward slashes, and a fast build, that should be totally doable.I was thinking of making NT386FASTGNU, but it's not clear if it is builds fast or runs fast -- builds fast.Well, a native build of that would be in between. cm3 would still pay for Cygwin, but the backend would still be faster for most of its work. :) later, - 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 Mon Jan 28 20:32:19 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 28 Jan 2008 14:32:19 -0500 Subject: [M3devel] cm3.cfg variables for IDE In-Reply-To: References: <591840BD-4494-4A2C-AC0F-CD017338E5ED@cs.purdue.edu> <2AEEE262-57C1-4D62-AB21-CA977F6C273E@cs.purdue.edu> <479DD57E.1E75.00D7.1@scires.com> Message-ID: It is not so much old-fashioned as consistent across platforms (Unix, Windows, etc.). Ideally, the same install procedure and environment variables make sense on all platforms. Don't fork the install for different platforms if at all possible. On Jan 28, 2008, at 1:40 PM, Jay wrote: > There are other ways to do this...rather than run iexplore, you can > use ShellExecute and run a url or something, or find the clsid of > mshtml.dll maybe. For wordpad, again ShellExecute wil tend to find > it. Notice how if you say start.run and type wordpad, it finds it? > Or "start wordpad" from the command line? "start" ~ ShellExecute, > instead of CreateProcess. "Shell" meaning the GUI shell -- Windows > Explorer. > > Wordpad and notepad stink as text editors. And notepad doesn't like > Unix newlines. I assume that's why wordepad. > Someting should be done, like, in the grand gui installer, where it > lists some freeware/shareware editors and offers to download and > install and set them as the editor for you. Stuf like TextEdit, > TextPad, UltraEdit...I think all of those exist, though somewhat > I'm guesing based on the obvious formula. :) > As well if it locate msdev or devenv that would be super. > > As I was saying the other day, I believe msdev and devenv are > easily findable via normal installs, except not on my machines. :) > I need to go through the environment you sent. > > The way this stuff works in Modula-3 today is..unnecessarily old > fashioned...I'm all for simplicity, but having a bajillion > environment variables does not seem to be the thing. Or a bajillion > line user editor text files. Or short file names anywhere! Just do > a backup/restore and see if those names survive. They might. They > might not. Oh well, true, nobody ever backs anything up. Still, > xcopy your software from one machine to another and see if the > paths still work -- definitely it's hard to do that for free, but > you can keep the cost down. > > - Jay > > > Date: Mon, 28 Jan 2008 13:15:42 -0500From: rcoleburn at scires.comTo: > jayk123 at hotmail.comCC: m3devel at elegosoft.comSubject: cm3.cfg > variables for IDE > > Jay: > > I thought I should let you know what I understand to be the > variables that the IDE is looking to find in cm3.cfg. That way, as > you work through any changes to the various cm3.cfg, you can make > sure these requirements are met From jayk123 at hotmail.com Mon Jan 28 22:33:57 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 28 Jan 2008 21:33:57 +0000 Subject: [M3devel] cm3.cfg variables for IDE In-Reply-To: References: <591840BD-4494-4A2C-AC0F-CD017338E5ED@cs.purdue.edu> <2AEEE262-57C1-4D62-AB21-CA977F6C273E@cs.purdue.edu> <479DD57E.1E75.00D7.1@scires.com> Message-ID: Make it easier on Windows... ? Right? Windows is the oddball anyway, right? Ok, that's not a great excuse. Do people tend to have firefox or firefox-bin on $PATH on Unix, if they have it on their machines? Or they have "shortcuts" on their "start menus"? I know this totally Windows termonilogy but I have used KDE and GNOME and they seem pretty isomorphic in this area. Ok, I guess they are the K menu the Foot menu. I don't know what they call "shortcuts". Is anyone, um, interested in adopting spaces in their file paths on Unix and work out the kinks? I for one put my compiler, linker, headers, libs without spaces, AND the environment variable based approach I put in makes spaces work anyway. Less luck with IE though. The code is likely forked in terms of where it runs stuff. CreateProcess vs. exec. Not that Windows doesn't have stuff that looks more like exec, or esp. system(), but still some chance that it is forked. So going down the Windows CreateProcess path, it could optionally use ShellExecute, and that will more leaf-only paths like "wordpad.exe" and "iexplore.exe" "just work". Here is another idea. There are environment variables for %programfiles% and %programfiles(x86)%. How about letting environment variables be used here? Well, heck, they are already are allowed, in Quake, with a leading dollar sign. BROWSER = $ProgramFiles & "\internet explorer\iexplore.exe" or somesuch. Not sure you could reference x86 IE from a 64bit process, what with hose parens in the variable name.. darnit. I've got to an AMD64 machine for home soon... If these are "paths to files" and not "command lines", then spaces are unambiguous. As well, CreateProcess is a little funky, but one of its parameters is a file path, not a command line and using that might help here, might. - Jay > CC: rcoleburn at scires.com; m3devel at elegosoft.com> From: hosking at cs.purdue.edu> Subject: Re: [M3devel] cm3.cfg variables for IDE> Date: Mon, 28 Jan 2008 14:32:19 -0500> To: jayk123 at hotmail.com> > It is not so much old-fashioned as consistent across platforms (Unix, > Windows, etc.). Ideally, the same install procedure and environment > variables make sense on all platforms. Don't fork the install for > different platforms if at all possible.> > On Jan 28, 2008, at 1:40 PM, Jay wrote:> > > There are other ways to do this...rather than run iexplore, you can > > use ShellExecute and run a url or something, or find the clsid of > > mshtml.dll maybe. For wordpad, again ShellExecute wil tend to find > > it. Notice how if you say start.run and type wordpad, it finds it? > > Or "start wordpad" from the command line? "start" ~ ShellExecute, > > instead of CreateProcess. "Shell" meaning the GUI shell -- Windows > > Explorer.> >> > Wordpad and notepad stink as text editors. And notepad doesn't like > > Unix newlines. I assume that's why wordepad.> > Someting should be done, like, in the grand gui installer, where it > > lists some freeware/shareware editors and offers to download and > > install and set them as the editor for you. Stuf like TextEdit, > > TextPad, UltraEdit...I think all of those exist, though somewhat > > I'm guesing based on the obvious formula. :)> > As well if it locate msdev or devenv that would be super.> >> > As I was saying the other day, I believe msdev and devenv are > > easily findable via normal installs, except not on my machines. :) > > I need to go through the environment you sent.> >> > The way this stuff works in Modula-3 today is..unnecessarily old > > fashioned...I'm all for simplicity, but having a bajillion > > environment variables does not seem to be the thing. Or a bajillion > > line user editor text files. Or short file names anywhere! Just do > > a backup/restore and see if those names survive. They might. They > > might not. Oh well, true, nobody ever backs anything up. Still, > > xcopy your software from one machine to another and see if the > > paths still work -- definitely it's hard to do that for free, but > > you can keep the cost down.> >> > - Jay> >> >> > Date: Mon, 28 Jan 2008 13:15:42 -0500From: rcoleburn at scires.comTo: > > jayk123 at hotmail.comCC: m3devel at elegosoft.comSubject: cm3.cfg > > variables for IDE> >> > Jay:> >> > I thought I should let you know what I understand to be the > > variables that the IDE is looking to find in cm3.cfg. That way, as > > you work through any changes to the various cm3.cfg, you can make > > sure these requirements are met> _________________________________________________________________ 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 Jan 28 22:35:51 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 28 Jan 2008 21:35:51 +0000 Subject: [M3devel] cm3.cfg variables for IDE In-Reply-To: References: <591840BD-4494-4A2C-AC0F-CD017338E5ED@cs.purdue.edu> <2AEEE262-57C1-4D62-AB21-CA977F6C273E@cs.purdue.edu> <479DD57E.1E75.00D7.1@scires.com> Message-ID: or heck, just spec these as command lines, or command line prefixes, instead of file names and say "start iexplore" and "start wordpad". If you want to wait for them to exit, try "start /wait". If it doesn't quite work the first time, try "cmd start wordpad" or "cmd start /wait wordpad", that probably is needed. No more path to configure. No more install.... - Jay From: jayk123 at hotmail.comTo: hosking at cs.purdue.eduCC: rcoleburn at scires.com; m3devel at elegosoft.comSubject: RE: [M3devel] cm3.cfg variables for IDEDate: Mon, 28 Jan 2008 21:33:57 +0000 Make it easier on Windows... ? Right?Windows is the oddball anyway, right? Ok, that's not a great excuse. Do people tend to have firefox or firefox-bin on $PATH on Unix, if they have it on their machines?Or they have "shortcuts" on their "start menus"? I know this totally Windows termonilogy but I have used KDE and GNOME and they seem pretty isomorphic in this area. Ok, I guess they are the K menu the Foot menu. I don't know what they call "shortcuts". Is anyone, um, interested in adopting spaces in their file paths on Unix and work out the kinks?I for one put my compiler, linker, headers, libs without spaces, AND the environment variable based approach I put in makes spaces work anyway.Less luck with IE though. The code is likely forked in terms of where it runs stuff. CreateProcess vs. exec. Not that Windows doesn't have stuff that looks more like exec, or esp. system(), but still some chance that it is forked. So going down the Windows CreateProcess path, it could optionally use ShellExecute, and that will more leaf-only paths like "wordpad.exe" and "iexplore.exe" "just work". Here is another idea. There are environment variables for %programfiles% and %programfiles(x86)%.How about letting environment variables be used here?Well, heck, they are already are allowed, in Quake, with a leading dollar sign.BROWSER = $ProgramFiles & "\internet explorer\iexplore.exe" or somesuch.Not sure you could reference x86 IE from a 64bit process, what with hose parens in the variable name.. darnit.I've got to an AMD64 machine for home soon... If these are "paths to files" and not "command lines", then spaces are unambiguous.As well, CreateProcess is a little funky, but one of its parameters is a file path, not a command line and using that might help here, might. - Jay > CC: rcoleburn at scires.com; m3devel at elegosoft.com> From: hosking at cs.purdue.edu> Subject: Re: [M3devel] cm3.cfg variables for IDE> Date: Mon, 28 Jan 2008 14:32:19 -0500> To: jayk123 at hotmail.com> > It is not so much old-fashioned as consistent across platforms (Unix, > Windows, etc.). Ideally, the same install procedure and environment > variables make sense on all platforms. Don't fork the install for > different platforms if at all possible.> > On Jan 28, 2008, at 1:40 PM, Jay wrote:> > > There are other ways to do this...rather than run iexplore, you can > > use ShellExecute and run a url or something, or find the clsid of > > mshtml.dll maybe. For wordpad, again ShellExecute wil tend to find > > it. Notice how if you say start.run and type wordpad, it finds it? > > Or "start wordpad" from the command line? "start" ~ ShellExecute, > > instead of CreateProcess. "Shell" meaning the GUI shell -- Windows > > Explorer.> >> > Wordpad and notepad stink as text editors. And notepad doesn't like > > Unix newlines. I assume that's why wordepad.> > Someting should be done, like, in the grand gui installer, where it > > lists some freeware/shareware editors and offers to download and > > install and set them as the editor for you. Stuf like TextEdit, > > TextPad, UltraEdit...I think all of those exist, though somewhat > > I'm guesing based on the obvious formula. :)> > As well if it locate msdev or devenv that would be super.> >> > As I was saying the other day, I believe msdev and devenv are > > easily findable via normal installs, except not on my machines. :) > > I need to go through the environment you sent.> >> > The way this stuff works in Modula-3 today is..unnecessarily old > > fashioned...I'm all for simplicity, but having a bajillion > > environment variables does not seem to be the thing. Or a bajillion > > line user editor text files. Or short file names anywhere! Just do > > a backup/restore and see if those names survive. They might. They > > might not. Oh well, true, nobody ever backs anything up. Still, > > xcopy your software from one machine to another and see if the > > paths still work -- definitely it's hard to do that for free, but > > you can keep the cost down.> >> > - Jay> >> >> > Date: Mon, 28 Jan 2008 13:15:42 -0500From: rcoleburn at scires.comTo: > > jayk123 at hotmail.comCC: m3devel at elegosoft.comSubject: cm3.cfg > > variables for IDE> >> > Jay:> >> > I thought I should let you know what I understand to be the > > variables that the IDE is looking to find in cm3.cfg. That way, as > > you work through any changes to the various cm3.cfg, you can make > > sure these requirements are met> 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 wagner at elegosoft.com Mon Jan 28 23:31:30 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 28 Jan 2008 23:31:30 +0100 Subject: [M3devel] cm3.cfg variables for IDE In-Reply-To: References: <591840BD-4494-4A2C-AC0F-CD017338E5ED@cs.purdue.edu> <2AEEE262-57C1-4D62-AB21-CA977F6C273E@cs.purdue.edu> <479DD57E.1E75.00D7.1@scires.com> Message-ID: <20080128233130.qzbxmy3wg444o84k@mail.elegosoft.com> Quoting Jay : > Do people tend to have firefox or firefox-bin on $PATH on Unix, if > they have it on their machines? People I know use all sorts of browsers on Unix: firefox, mozilla, opera, conquerer, ... > Or they have "shortcuts" on their "start menus"? > I know this totally Windows termonilogy but I have used KDE and > GNOME and they seem pretty isomorphic in this area. > Ok, I guess they are the K menu the Foot menu. I don't know what > they call "shortcuts". I still use fvwm and avoid all more enhanced desktops if possible ;-) > Is anyone, um, interested in adopting spaces in their file paths on > Unix and work out the kinks? This has been tried before, but it will break all simple usage of command line utilities (and there are hundreds of these). I personally don't see the point of using spaces in file names, but opinions may differ on this topic. As for the rest: I'd like to see a list of those settings an installer should find out for itself (as they are platform dependent and there is no real choice for the user) and those that are truly user-selectable due to personal preferences etc. These may also depend on the platform. Such a document may might be a start for an installer redesign (if we don't go for the system-dependent installation packages at last). It will be a tedious work to do that 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 rcoleburn at scires.com Mon Jan 28 23:34:19 2008 From: rcoleburn at scires.com (Randy Coleburn) Date: Mon, 28 Jan 2008 17:34:19 -0500 Subject: [M3devel] cm3.cfg variables for IDE In-Reply-To: References: <591840BD-4494-4A2C-AC0F-CD017338E5ED@cs.purdue.edu> <2AEEE262-57C1-4D62-AB21-CA977F6C273E@cs.purdue.edu> <479DD57E.1E75.00D7.1@scires.com> Message-ID: <479E121A.1E75.00D7.1@scires.com> Jay: I understand about use of the "shell" in Windows to find stuff. I use the "start" command all the time. I'm not ASKING for how best to fix/change/improve the current situation. I'm just STATING what is required for now. Anyone is welcome to improve upon things later. I'm just trying to get this "out the door" so it is available to everyone. At one point in time, circa cm3 v4.1, all of this did in fact work; and, it worked across multiple platforms. If we can get the IDE into the repository, we can migrate it along with the rest of cm3 as the system evolves. No, I don't use WordPad or Notepad as my primary editor for m3 code. I use CRiSP, but that is beside the point. The original CMass Reactor designers tried to come up with some reasonable defaults for the various platforms that would work in virtually all cases. CMInstall used notepad as the default editor for Windows because all Windows systems were known to have notepad installed by default. On Unix, it used a different default, probably vi or something. During the CMInstall dialog, my recollection is that it probed your system for "known" editors and browsers and let you pick from a list of what it found, or you could override its default choices by specifying whatever you wanted. At run-time, the IDE has a configuration screen where you can change these selections again. So, the idea was to make sure Reactor worked out-of-the-box, and let the user customize it to make the experience better, e.g., choose your favorite editor, source code control system, etc. Bottom line, for now we need to make sure INSTALL_ROOT, BUILD_DIR and PKG_USE are defined in cm3.cfg for all platforms. Otherwise, the user is going to run into trouble and we will have to deal with a bunch of support requests. Going forward, we can adapt the IDE code to do whatever works best for everyone. Regards, Randy >>> Jay 1/28/2008 1:40 PM >>> There are other ways to do this...rather than run iexplore, you can use ShellExecute and run a url or something, or find the clsid of mshtml.dll maybe. For wordpad, again ShellExecute wil tend to find it. Notice how if you say start.run and type wordpad, it finds it? Or "start wordpad" from the command line? "start" ~ ShellExecute, instead of CreateProcess. "Shell" meaning the GUI shell -- Windows Explorer. Wordpad and notepad stink as text editors. And notepad doesn't like Unix newlines. I assume that's why wordepad. Someting should be done, like, in the grand gui installer, where it lists some freeware/shareware editors and offers to download and install and set them as the editor for you. Stuf like TextEdit, TextPad, UltraEdit...I think all of those exist, though somewhat I'm guesing based on the obvious formula. :) As well if it locate msdev or devenv that would be super. As I was saying the other day, I believe msdev and devenv are easily findable via normal installs, except not on my machines. :) I need to go through the environment you sent. The way this stuff works in Modula-3 today is..unnecessarily old fashioned... I'm all for simplicity, but having a bajillion environment variables does not seem to be the thing. Or a bajillion line user editor text files. Or short file names anywhere! Just do a backup/restore and see if those names survive. They might. They might not. Oh well, true, nobody ever backs anything up. Still, xcopy your software from one machine to another and see if the paths still work -- definitely it's hard to do that for free, but you can keep the cost down. - Jay Date: Mon, 28 Jan 2008 13:15:42 -0500 From: rcoleburn at scires.com To: jayk123 at hotmail.com CC: m3devel at elegosoft.com Subject: cm3.cfg variables for IDE Jay: I thought I should let you know what I understand to be the variables that the IDE is looking to find in cm3.cfg. That way, as you work through any changes to the various cm3.cfg, you can make sure these requirements are met. INSTALL_ROOT (e.g., c:\cm3) BUILD_DIR (e.g., NT386) PKG_USE (e.g., c:\cm3\pkg) DOC_INSTALL (e.g., c:\cm3\doc) INITIAL_CM3_IDE_BROWSER (e.g., c:\progra~1\intern~1\iexplore.exe) INITIAL_CM3_IDE_EDITOR (e.g., c:\progra~1\window~1\accessories\wordpad.exe) Now, of these 6 listed above, the first three: INSTALL_ROOT, BUILD_DIR and PKG_USE, are the most critical for the IDE. DOC_INSTALL can be omitted, in which case the IDE will substitute INSTALL_ROOT\doc If INITIAL_CM3_IDE_BROWSER and/or INITIAL_CM3_IDE_EDITOR are not defined, the IDE will prompt the user via its console log window for the complete paths to these two programs; thus their definition can be omitted from the cm3.cfg. The IDE will store the user's input for subsequent reuse in its own private cfg file. This file is stored in the user's home folder or as specified in the optional CM3_IDE_HOME environment variable. The CM3_IDE_HOME environment variable should point to the path of the user's primary private package repository. CM3_IDE_HOME should NOT be defined in cm3.cfg. If anyone wants to keep the cminstall program up-to-date, they should replace INITIAL_REACTOR_BROWSER and INITIAL_REACTOR_EDITOR with INITIAL_CM3_IDE_BROWSER and/or INITIAL_CM3_IDE_EDITOR . Regards, Randy 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 wagner at elegosoft.com Mon Jan 28 23:48:43 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 28 Jan 2008 23:48:43 +0100 Subject: [M3devel] Open CM3 regression tests In-Reply-To: References: <20080120211832.GA26993@elegosoft.com> <9C00EA97-9B43-43BE-9CDF-EEAC9C1321D5@cs.purdue.edu> <20080127150327.mh686v2hx4w080w4@mail.elegosoft.com> <1DA9FA59-6DFF-430C-90C5-F1D30003607A@cs.purdue.edu> <20080127185530.e255i76vcwckss4o@mail.elegosoft.com> Message-ID: <20080128234843.c4sc4uzy4gs8wk8c@mail.elegosoft.com> Quoting Jay : > The tests don't even build on Windows and it was going to take more > than 5 minutes fix that. > They are slightly full of sh. :) (I never tire of this joke. :) ) > My current plan is: > get NT386GNU working -- I can already build cm3 and it fails an > assertion about pthread_mutex_something failing. Hey, maybe I should > fix some of the declarations.. :) > or go back to my Mac briefly to investigate > and/or give Tony a day :) Hi Jay, don't try to do too much all at once -- take your time, there's no heed to hurry. This is an open source project :-) If I were you, I'd finish the Windows ports you are working on first, and then help Randy with his bitmap and m3ide problems. It's all up to you of course. What exactly in m3tests is slightly full of sh? I just fixed one missing abstraction, but except for some definitions at the top of the m3makefile, the rest should be quake. As for the regression test framework in scripts/regression, we can run that in NT386GNU / Cygwin if needed. It may be slow, but that should be OK. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Jan 29 00:49:32 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 28 Jan 2008 18:49:32 -0500 Subject: [M3devel] cm3.cfg variables for IDE In-Reply-To: References: <591840BD-4494-4A2C-AC0F-CD017338E5ED@cs.purdue.edu> <2AEEE262-57C1-4D62-AB21-CA977F6C273E@cs.purdue.edu> <479DD57E.1E75.00D7.1@scires.com> Message-ID: <770ED7C9-B8D5-42EC-A7A1-C54EAFDEB1AB@cs.purdue.edu> On Jan 28, 2008, at 4:33 PM, Jay wrote: > Make it easier on Windows... ? Right? > Windows is the oddball anyway, right? Ok, that's not a great excuse. > > Do people tend to have firefox or firefox-bin on $PATH on Unix, if > they have it on their machines? > Or they have "shortcuts" on their "start menus"? Nope. Not on Mac OS X. > I know this totally Windows termonilogy but I have used KDE and > GNOME and they seem pretty isomorphic in this area. > Ok, I guess they are the K menu the Foot menu. I don't know what > they call "shortcuts". > > Is anyone, um, interested in adopting spaces in their file paths on > Unix and work out the kinks? > I for one put my compiler, linker, headers, libs without spaces, > AND the environment variable based approach I put in makes spaces > work anyway. > Less luck with IE though. > > The code is likely forked in terms of where it runs stuff. > CreateProcess vs. exec. Not that Windows doesn't have stuff that > looks more like exec, or esp. system(), but still some chance that > it is forked. So going down the Windows CreateProcess path, it > could optionally use ShellExecute, and that will more leaf-only > paths like "wordpad.exe" and "iexplore.exe" "just work". > > Here is another idea. There are environment variables for % > programfiles% and %programfiles(x86)%. > How about letting environment variables be used here? > Well, heck, they are already are allowed, in Quake, with a leading > dollar sign. > BROWSER = $ProgramFiles & "\internet explorer\iexplore.exe" or > somesuch. > Not sure you could reference x86 IE from a 64bit process, what with > hose parens in the variable name.. darnit. > I've got to an AMD64 machine for home soon... > > If these are "paths to files" and not "command lines", then spaces > are unambiguous. > As well, CreateProcess is a little funky, but one of its parameters > is a file path, not a command line and using that might help here, > might. > > - Jay > > > > > CC: rcoleburn at scires.com; m3devel at elegosoft.com > > From: hosking at cs.purdue.edu > > Subject: Re: [M3devel] cm3.cfg variables for IDE > > Date: Mon, 28 Jan 2008 14:32:19 -0500 > > To: jayk123 at hotmail.com > > > > It is not so much old-fashioned as consistent across platforms > (Unix, > > Windows, etc.). Ideally, the same install procedure and environment > > variables make sense on all platforms. Don't fork the install for > > different platforms if at all possible. > > > > On Jan 28, 2008, at 1:40 PM, Jay wrote: > > > > > There are other ways to do this...rather than run iexplore, you > can > > > use ShellExecute and run a url or something, or find the clsid of > > > mshtml.dll maybe. For wordpad, again ShellExecute wil tend to find > > > it. Notice how if you say start.run and type wordpad, it finds it? > > > Or "start wordpad" from the command line? "start" ~ ShellExecute, > > > instead of CreateProcess. "Shell" meaning the GUI shell -- Windows > > > Explorer. > > > > > > Wordpad and notepad stink as text editors. And notepad doesn't > like > > > Unix newlines. I assume that's why wordepad. > > > Someting should be done, like, in the grand gui installer, > where it > > > lists some freeware/shareware editors and offers to download and > > > install and set them as the editor for you. Stuf like TextEdit, > > > TextPad, UltraEdit...I think all of those exist, though somewhat > > > I'm guesing based on the obvious formula. :) > > > As well if it locate msdev or devenv that would be super. > > > > > > As I was saying the other day, I believe msdev and devenv are > > > easily findable via normal installs, except not on my machines. :) > > > I need to go through the environment you sent. > > > > > > The way this stuff works in Modula-3 today is..unnecessarily old > > > fashioned...I'm all for simplicity, but having a bajillion > > > environment variables does not seem to be the thing. Or a > bajillion > > > line user editor text files. Or short file names anywhere! Just do > > > a backup/restore and see if those names survive. They might. They > > > might not. Oh well, true, nobody ever backs anything up. Still, > > > xcopy your software from one machine to another and see if the > > > paths still work -- definitely it's hard to do that for free, but > > > you can keep the cost down. > > > > > > - Jay > > > > > > > > > Date: Mon, 28 Jan 2008 13:15:42 -0500From: rcoleburn at scires.comTo: > > > jayk123 at hotmail.comCC: m3devel at elegosoft.comSubject: cm3.cfg > > > variables for IDE > > > > > > Jay: > > > > > > I thought I should let you know what I understand to be the > > > variables that the IDE is looking to find in cm3.cfg. That way, as > > > you work through any changes to the various cm3.cfg, you can make > > > sure these requirements are met > > > > > 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 Tue Jan 29 00:50:55 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 28 Jan 2008 18:50:55 -0500 Subject: [M3devel] cm3.cfg variables for IDE In-Reply-To: <479E121A.1E75.00D7.1@scires.com> References: <591840BD-4494-4A2C-AC0F-CD017338E5ED@cs.purdue.edu> <2AEEE262-57C1-4D62-AB21-CA977F6C273E@cs.purdue.edu> <479DD57E.1E75.00D7.1@scires.com> <479E121A.1E75.00D7.1@scires.com> Message-ID: <73F72170-FD22-476F-A307-1E9DE9331CA4@cs.purdue.edu> Hear, hear. Jay, please listen to this -- it is important! On Jan 28, 2008, at 5:34 PM, Randy Coleburn wrote: > Jay: > > I understand about use of the "shell" in Windows to find stuff. I > use the "start" command all the time. > > I'm not ASKING for how best to fix/change/improve the current > situation. I'm just STATING what is required for now. Anyone is > welcome to improve upon things later. I'm just trying to get this > "out the door" so it is available to everyone. > > At one point in time, circa cm3 v4.1, all of this did in fact work; > and, it worked across multiple platforms. If we can get the IDE > into the repository, we can migrate it along with the rest of cm3 > as the system evolves. > > No, I don't use WordPad or Notepad as my primary editor for m3 > code. I use CRiSP, but that is beside the point. The original > CMass Reactor designers tried to come up with some reasonable > defaults for the various platforms that would work in virtually all > cases. CMInstall used notepad as the default editor for Windows > because all Windows systems were known to have notepad installed by > default. On Unix, it used a different default, probably vi or > something. During the CMInstall dialog, my recollection is that it > probed your system for "known" editors and browsers and let you > pick from a list of what it found, or you could override its > default choices by specifying whatever you wanted. At run-time, > the IDE has a configuration screen where you can change these > selections again. > > So, the idea was to make sure Reactor worked out-of-the-box, and > let the user customize it to make the experience better, e.g., > choose your favorite editor, source code control system, etc. > > Bottom line, for now we need to make sure INSTALL_ROOT, BUILD_DIR > and PKG_USE are defined in cm3.cfg for all platforms. Otherwise, > the user is going to run into trouble and we will have to deal with > a bunch of support requests. > > Going forward, we can adapt the IDE code to do whatever works best > for everyone. > > Regards, > Randy > > >>> Jay 1/28/2008 1:40 PM >>> > There are other ways to do this...rather than run iexplore, you can > use ShellExecute and run a url or something, or find the clsid of > mshtml.dll maybe. For wordpad, again ShellExecute wil tend to find > it. Notice how if you say start.run and type wordpad, it finds it? > Or "start wordpad" from the command line? "start" ~ ShellExecute, > instead of CreateProcess. "Shell" meaning the GUI shell -- Windows > Explorer. > > Wordpad and notepad stink as text editors. And notepad doesn't like > Unix newlines. I assume that's why wordepad. > Someting should be done, like, in the grand gui installer, where it > lists some freeware/shareware editors and offers to download and > install and set them as the editor for you. Stuf like TextEdit, > TextPad, UltraEdit...I think all of those exist, though somewhat > I'm guesing based on the obvious formula. :) > As well if it locate msdev or devenv that would be super. > > As I was saying the other day, I believe msdev and devenv are > easily findable via normal installs, except not on my machines. :) > I need to go through the environment you sent. > > The way this stuff works in Modula-3 today is..unnecessarily old > fashioned... > I'm all for simplicity, but having a bajillion environment > variables does not seem to be the thing. Or a bajillion line user > editor text files. Or short file names anywhere! Just do a backup/ > restore and see if those names survive. They might. They might not. > Oh well, true, nobody ever backs anything up. Still, xcopy your > software from one machine to another and see if the paths still > work -- definitely it's hard to do that for free, but you can keep > the cost down. > > - Jay > > Date: Mon, 28 Jan 2008 13:15:42 -0500 > From: rcoleburn at scires.com > To: jayk123 at hotmail.com > CC: m3devel at elegosoft.com > Subject: cm3.cfg variables for IDE > > Jay: > > I thought I should let you know what I understand to be the > variables that the IDE is looking to find in cm3.cfg. That way, as > you work through any changes to the various cm3.cfg, you can make > sure these requirements are met. > > INSTALL_ROOT (e.g., c:\cm3) > BUILD_DIR (e.g., NT386) > PKG_USE (e.g., c:\cm3\pkg) > > DOC_INSTALL (e.g., c:\cm3\doc) > INITIAL_CM3_IDE_BROWSER (e.g., c:\progra~1\intern~1\iexplore.exe) > INITIAL_CM3_IDE_EDITOR (e.g., c:\progra~1\window~1\accessories > \wordpad.exe) > > Now, of these 6 listed above, the first three: INSTALL_ROOT, > BUILD_DIR and PKG_USE, are the most critical for the IDE. > > DOC_INSTALL can be omitted, in which case the IDE will substitute > INSTALL_ROOT\doc > > If INITIAL_CM3_IDE_BROWSER and/or INITIAL_CM3_IDE_EDITOR are not > defined, the IDE will prompt the user via its console log window > for the complete paths to these two programs; thus their definition > can be omitted from the cm3.cfg. The IDE will store the user's > input for subsequent reuse in its own private cfg file. This file > is stored in the user's home folder or as specified in the optional > CM3_IDE_HOME environment variable. The CM3_IDE_HOME environment > variable should point to the path of the user's primary private > package repository. CM3_IDE_HOME should NOT be defined in cm3.cfg. > > If anyone wants to keep the cminstall program up-to-date, they should > replace INITIAL_REACTOR_BROWSER and INITIAL_REACTOR_EDITOR > with INITIAL_CM3_IDE_BROWSER and/or INITIAL_CM3_IDE_EDITOR . > > Regards, > Randy > > Connect and share in new ways with Windows Live. Get it now! From hosking at cs.purdue.edu Tue Jan 29 01:02:45 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 28 Jan 2008 19:02:45 -0500 Subject: [M3devel] Utypes.asLong / Utypes.assignOffT In-Reply-To: <479E0F4D.3050809@elego.de> References: <479DDB3C.4020300@elego.de> <479E045D.2000903@elego.de> <4C6699EA-187B-455D-A7D0-63A69FABF1B7@cs.purdue.edu> <479E0CC2.1020206@elego.de> <479E0F4D.3050809@elego.de> Message-ID: Yes! On Jan 28, 2008, at 12:22 PM, Neels Janosch Hofmeyr wrote: > Duh, that was definitely wrong. If anything, it should read > > y := Utypes.asLong(x) ==becomes==> y := ORD(x); > x := Utypes.assignOffT(y) ==becomes==> x := VAL(y, Utypes.off_t); > > So, is this correct, now? > > Neels Janosch Hofmeyr wrote: >> So, if I understand correctly, this should read >> >> y := Utypes.asLong(x) ==becomes==> y := ORD(x); >> x := Utypes.assignOffT(y) ==becomes==> x := VAL(y); >> >> right? >> >> Tony Hosking wrote: >>> You will need to use VAL as I noted to handle the fact that off_t >>> is LONGINT on some targets and INTEGER on others. >>> >>> On Jan 28, 2008, at 11:35 AM, Neels Janosch Hofmeyr wrote: >>> >>>> Apparently, the answer to this is trivial. I found the missing >>>> functions in a CVS diff: >>>> >>>> -PROCEDURE asLong (val: off_t): long = >>>> - BEGIN >>>> - RETURN val; >>>> - END asLong; >>>> - >>>> -PROCEDURE assignOffT (VAR dest: off_t; src: long) = >>>> - BEGIN >>>> - dest := src; >>>> - END assignOffT; >>>> >>>> So, just replacing all occurences of these functions with direct >>>> assignments compiles without problems. >>>> y := Utypes.asLong(x) ==becomes==> y := ORD(x); >>>> x := Utypes.assignOffT(y) ==becomes==> x := y; >>>> >>>> Obviously, CVSup needs to be updated so that it compiles with >>>> the most recent CM3! The suplib still uses the obsoleted >>>> procedures asLong and assignOffT. Shall I write a mail to Mr. >>>> Polstra? >>>> >>>> Neels >>>> >>>> Neels Janosch Hofmeyr wrote: >>>>> Hi, >>>>> >>>>> after some problems have been resolved, I still cannot figure >>>>> out these errors: >>>>> >>>>> ===> suplib >>>>> --- building in LINUXLIBC6 --- >>>>> >>>>> new source -> compiling StatBufOffT64.m3 >>>>> "../src/StatBufOffT64.m3", line 40: unknown qualification >>>>> '.' (asLong) >>>>> "../src/StatBufOffT64.m3", line 45: unknown qualification >>>>> '.' (assignOffT) >>>>> >>>>> They are trying to access the procedures >>>>> Utypes.asLong >>>>> Utypes.assignOffT >>>>> >>>>> Apparently, Utypes.asLong(..) can simply be replaced by ORD >>>>> (..). Is this correct?? >>>>> >>>>> Concerning assignOffT, the commit log speaks of a function called >>>>> PROCEDURE expandAssign(VAR dest: off_t; src: long) >>>>> , but this function does not exist anywhere in the cm3 source >>>>> tree (grep -r expandAssign yielded no results). >>>>> >>>>> >>>>> How do I fix this line in suplib/src/StatBufOffT64.m3 (ll.43-46)? >>>>> >>>>> PROCEDURE SetStatSize(VAR st: struct_stat; size: CARDINAL) = >>>>> BEGIN >>>>> Utypes.assignOffT(st.st_size, size); >>>>> END SetStatSize; >>>>> >>>>> "../src/StatBufOffT64.m3", line 45: unknown qualification >>>>> '.' (assignOffT) >>>>> >>>>> >>>>> Thanks >>>>> >>>> >>>> -- >>>> Neels Janosch Hofmeyr >>>> Software Developer >>>> >>>> neels at elego.de >>>> Public Key: http://binarchy.net/neels/neels.hofmeyr.public.key.asc >>>> >>>> elego Software Solutions GmbH http://www.elegosoft.com >>>> Gustav-Meyer-Allee 25, Geb?ude 12 HRB 77719 >>>> 13355 Berlin, Germany Amtsgericht Charlottenburg >>>> Tel.: +49 30 23 45 86 96 Sitz der Gesellschaft: >>>> Berlin >>>> Fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Olaf >>>> Wagner >>>> >>>> >>> >> > > -- > Neels Janosch Hofmeyr > Software Developer > > neels at elego.de > Public Key: http://binarchy.net/neels/neels.hofmeyr.public.key.asc > > elego Software Solutions GmbH http://www.elegosoft.com > Gustav-Meyer-Allee 25, Geb?ude 12 HRB 77719 > 13355 Berlin, Germany Amtsgericht Charlottenburg > Tel.: +49 30 23 45 86 96 Sitz der Gesellschaft: Berlin > Fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Olaf Wagner > > From jayk123 at hotmail.com Tue Jan 29 01:38:26 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 29 Jan 2008 00:38:26 +0000 Subject: [M3devel] Open CM3 regression tests In-Reply-To: <20080128234843.c4sc4uzy4gs8wk8c@mail.elegosoft.com> References: <20080120211832.GA26993@elegosoft.com> <9C00EA97-9B43-43BE-9CDF-EEAC9C1321D5@cs.purdue.edu> <20080127150327.mh686v2hx4w080w4@mail.elegosoft.com> <1DA9FA59-6DFF-430C-90C5-F1D30003607A@cs.purdue.edu> <20080127185530.e255i76vcwckss4o@mail.elegosoft.com> <20080128234843.c4sc4uzy4gs8wk8c@mail.elegosoft.com> Message-ID: I was stuck on the use of "ln". I know, it should be easy, just copy stuff..or use Cygwin ln, but it kept not working and I moved on for now. I know it's an easy thing but I was being lazy and there are alternatives if it languishes long, I can try on Mac, or PPC_LINUX (which has other problems perhaps that need working out, maybe just that dynamic linking is broken, I put it in hold for now). > As for the regression test framework in scripts/regression, we can> run that in NT386GNU / Cygwin if needed. It may be slow, but that Agreed! Or, for tests failing on all systems, I can use non-Windows. > don't try to do too much all at once -- take your time, there's> no heed to hurry. I've heard this many times already. :) I am taking my time. You have not seen my hurry. And you hopefully never will. :) - Jay > Date: Mon, 28 Jan 2008 23:48:43 +0100> From: wagner at elegosoft.com> To: jayk123 at hotmail.com> CC: m3devel at elegosoft.com> Subject: RE: [M3devel] Open CM3 regression tests> > Quoting Jay :> > > The tests don't even build on Windows and it was going to take more > > than 5 minutes fix that.> > They are slightly full of sh. :) (I never tire of this joke. :) )> > My current plan is:> > get NT386GNU working -- I can already build cm3 and it fails an > > assertion about pthread_mutex_something failing. Hey, maybe I should > > fix some of the declarations.. :)> > or go back to my Mac briefly to investigate> > and/or give Tony a day :)> > Hi Jay,> > don't try to do too much all at once -- take your time, there's> no heed to hurry. This is an open source project :-)> > If I were you, I'd finish the Windows ports you are working on first,> and then help Randy with his bitmap and m3ide problems. It's all> up to you of course.> > What exactly in m3tests is slightly full of sh? I just fixed one> missing abstraction, but except for some definitions at the> top of the m3makefile, the rest should be quake.> > As for the regression test framework in scripts/regression, we can> run that in NT386GNU / Cygwin if needed. It may be slow, but that> should be OK.> > Olaf> -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 Jan 29 01:40:27 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 29 Jan 2008 00:40:27 +0000 Subject: [M3devel] cm3.cfg variables for IDE In-Reply-To: <770ED7C9-B8D5-42EC-A7A1-C54EAFDEB1AB@cs.purdue.edu> References: <591840BD-4494-4A2C-AC0F-CD017338E5ED@cs.purdue.edu> <2AEEE262-57C1-4D62-AB21-CA977F6C273E@cs.purdue.edu> <479DD57E.1E75.00D7.1@scires.com> <770ED7C9-B8D5-42EC-A7A1-C54EAFDEB1AB@cs.purdue.edu> Message-ID: Right, I've got a Mac...bite my tongue bite my tongue... :) (someday maybe we'll get this stuff working on MacClassic and 68K. :) ) - Jay > CC: rcoleburn at scires.com; m3devel at elegosoft.com> From: hosking at cs.purdue.edu> Subject: Re: [M3devel] cm3.cfg variables for IDE> Date: Mon, 28 Jan 2008 18:49:32 -0500> To: jayk123 at hotmail.com> > > On Jan 28, 2008, at 4:33 PM, Jay wrote:> > > Make it easier on Windows... ? Right?> > Windows is the oddball anyway, right? Ok, that's not a great excuse.> >> > Do people tend to have firefox or firefox-bin on $PATH on Unix, if > > they have it on their machines?> > Or they have "shortcuts" on their "start menus"?> > Nope. Not on Mac OS X. _________________________________________________________________ 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 Jan 29 01:46:50 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 29 Jan 2008 00:46:50 +0000 Subject: [M3devel] cm3.cfg variables for IDE In-Reply-To: <20080128233130.qzbxmy3wg444o84k@mail.elegosoft.com> References: <591840BD-4494-4A2C-AC0F-CD017338E5ED@cs.purdue.edu> <2AEEE262-57C1-4D62-AB21-CA977F6C273E@cs.purdue.edu> <479DD57E.1E75.00D7.1@scires.com> <20080128233130.qzbxmy3wg444o84k@mail.elegosoft.com> Message-ID: > Date: Mon, 28 Jan 2008 23:31:30 +0100> From: wagner at elegosoft.com> > Quoting Jay :> > Do people tend to have firefox or firefox-bin on $PATH on Unix, if > > they have it on their machines?> > People I know use all sorts of browsers on Unix: firefox, mozilla,> opera, conquerer, ... That wasn't my complete point, but partly. Do people have their browser in $PATH? Such that a full path isn't needed? I guess the answer is sometimes yes sometimes no. > > I still use fvwm and avoid all more enhanced desktops if possible ;-)> > > Is anyone, um, interested in adopting spaces in their file paths on > > Unix and work out the kinks?> > This has been tried before, but it will break all simple usage> of command line utilities (and there are hundreds of these).> I personally don't see the point of using spaces in file names,> but opinions may differ on this topic. I agree it is pretty pointless, but yet unfortunately on Windows there is "Program Files" and such and it's not going away. The biggest problem with quoting is you never know how many layers are going to quote/unquote. Really it's a major type system problem...one flat string vs. an array of strings. If only we typed in our command lines in a little gui with a box per parameter. :) cm3/cm3cg is very clever in one way here. cm3cg always gets its input and output from the current working directory. Boom, so many annoying problems gone. :) I don't think "hundreds" of utilities are relevant here, just a few. cc, ld, libtool, cl, link, cm3, cm3cg (not), and a little bit over in m3cc/m3gdb make sed sh. Ok, nevermind...just that I see those short paths..what a hack, they aren't even guaranteeably available, the option can be turned off....once this stuff is in I'll try to take a look at and fix it, only for the small number of visible cases, not the hundreds of cases. - 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 Jan 29 01:48:20 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 29 Jan 2008 00:48:20 +0000 Subject: [M3devel] Open CM3 regression tests In-Reply-To: <20080128234843.c4sc4uzy4gs8wk8c@mail.elegosoft.com> References: <20080120211832.GA26993@elegosoft.com> <9C00EA97-9B43-43BE-9CDF-EEAC9C1321D5@cs.purdue.edu> <20080127150327.mh686v2hx4w080w4@mail.elegosoft.com> <1DA9FA59-6DFF-430C-90C5-F1D30003607A@cs.purdue.edu> <20080127185530.e255i76vcwckss4o@mail.elegosoft.com> <20080128234843.c4sc4uzy4gs8wk8c@mail.elegosoft.com> Message-ID: > As for the regression test framework in scripts/regression, we can> run that in NT386GNU / Cygwin if needed. It may be slow, but that> Agreed! Or, for tests failing on all systems, I can use non-Windows. I was actually thinking of m3tests here, but yes, that too. - 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 Tue Jan 29 02:25:41 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 29 Jan 2008 02:25:41 +0100 Subject: [M3devel] Open CM3 regression tests In-Reply-To: References: <20080120211832.GA26993@elegosoft.com> <9C00EA97-9B43-43BE-9CDF-EEAC9C1321D5@cs.purdue.edu> <20080127150327.mh686v2hx4w080w4@mail.elegosoft.com> <1DA9FA59-6DFF-430C-90C5-F1D30003607A@cs.purdue.edu> <20080127185530.e255i76vcwckss4o@mail.elegosoft.com> <20080128234843.c4sc4uzy4gs8wk8c@mail.elegosoft.com> Message-ID: <20080129022541.0m78eettvocc00wo@mail.elegosoft.com> Quoting Jay : > I was stuck on the use of "ln". > I know, it should be easy, just copy stuff..or use Cygwin ln, but it > kept not working and I moved on for now. I can try to fix that. Let me know of anything else that does not work on Windows. > I know it's an easy thing but I was being lazy and there are > alternatives if it languishes long, I can try on Mac, or PPC_LINUX > (which has other problems perhaps that need working out, maybe just > that dynamic linking is broken, I put it in hold for now). You need to set DYLD_LIBRARY_PATH to m3test/PPC_DARWIN for Darwin, as there's a local library which gets used in all tests. Dynamic linking seems to work differently on Darwin from most other Unix systems I know. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Jan 29 11:45:12 2008 From: mika at async.caltech.edu (Mika Nystrom) Date: Tue, 29 Jan 2008 02:45:12 -0800 Subject: [M3devel] nt386gnu threads? In-Reply-To: Your message of "Mon, 28 Jan 2008 16:19:48 GMT." Message-ID: <200801291045.m0TAjCDM062661@camembert.async.caltech.edu> 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 From hosking at cs.purdue.edu Tue Jan 29 14:08:38 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 29 Jan 2008 08:08:38 -0500 Subject: [M3devel] nt386gnu threads? In-Reply-To: <200801291045.m0TAjCDM062661@camembert.async.caltech.edu> References: <200801291045.m0TAjCDM062661@camembert.async.caltech.edu> Message-ID: 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 From jayk123 at hotmail.com Tue Jan 29 20:43:43 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 29 Jan 2008 19:43:43 +0000 Subject: [M3devel] nt386gnu threads? In-Reply-To: References: <200801291045.m0TAjCDM062661@camembert.async.caltech.edu> Message-ID: I wasn't aware of this, but I don't think it is the problem, not having looked at it yet. Building in m3cc is very independent of cm3 one it gets going. So maybe this is just slow upon slow, sleep upon Cygwin.I should run some numbers with all my whining. Has anyone else built either NT386GNU or NT386MINGNU? MINGNU should be fairly easy to build now and work, for non-gui. GNU fairly easy to build but doesn't work. Possibly I broke it over the weekend, didn't test as much as previously. - 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> _________________________________________________________________ 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 Thu Jan 31 01:34:25 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 31 Jan 2008 01:34:25 +0100 Subject: [M3devel] quake extensions for tests / RFC Message-ID: <20080131013425.f1wph3ypkwc8wkw8@mail.elegosoft.com> Hi, I've added a utilities library package from the DCVS project and a whole bunch of quake builtin functions based on it. As I've often found that just the functions I'd need to express something in quake without using platform dependent means (exec cmd) are not available, I've now decided to add some. Most of them are string and file system related. There are standard text and text array functions, and functions that deal with files, directories, and their content. A third group are three new exec calls: one to execute a command list with the usual redirection options known from shell; one to pipe the contents of a quake variable to an external program, and one to capture the contents of an external program in a quake variable (shell's process or command substitution). I think they will be rather useful. I've also added some standard functions that were always missing in quake: a generic len() function (length of text, array, table), embedded quake code evaluation from a string (quake), and string encode and decode (from libm3). There are 80 short quake tests added in m3quake/test/src/m3makefile which can be run by a simple `cm3 -build'. Before I proceed, I'd like to hear comments about the interfaces and functionality, and especially the function names (always the part that takes most of the time in programming ;-). Several things could probably be better named or improved by adding or altering some parameters. Let me know what you think about it before these functions get used in CM3 packages. I'll write up an HTML documentation and add it to the existing quake language description (which is already a bit old and needs an update) on the WWW pages during the next days. Find attached the function overview and tests. Olaf PS: Some things are still missing and may be added during the next weeks, like directory stacks, system information access and pathname functions. -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 -------------- system information ------------------ hostname() --> text command execution ----------------- q_exec( cmd ) --> int # execute with redirections (>, >>,...) q_exec_put( cmd, text ) --> int # execute cmd with stdin from text q_exec_get( cmd ) --> [int, text] # execute cmd and return output text utilities -------------- split( text, seps ) --> text[] sub( text, off, len ) --> text skipl( text ) --> text skipr( text ) --> text compress( text ) --> text squeeze( text ) --> text pos( text, text ) --> int contains( text, text ) --> boolean bool( text ) --> boolean subst_chars( text, a, b ) --> text del_chars( text, a, b ) --> text subst( text, a, b, n ) --> text subst_env( text ) --> text add_prefix( text[], text ) --> text[] add_suffix( text[], text ) --> text[] file system utilities --------------------- pn -> pathname: text dir -> pn ( not yet; really needed? pn_native( pn ) --> text pn_posix( pn ) --> text pn_win( pn ) --> text pn_root( pn ) --> text pn_sep() --> text ) fs_exists( pn ) --> boolean fs_readable( pn ) --> boolean fs_writable( pn ) --> boolean fs_executable( pn ) --> boolean fs_isdir( pn ) --> boolean fs_isfile( pn ) --> boolean fs_lsdirs( pn, baseonly ) --> text[] fs_lsfiles( pn, baseonly ) --> text[] ( fs_canonical_pn( pn ) --> text ) fs_touch( pn ) # update access time of file fs_rm( pn ) # remove file fs_rmdir( pn ) # remove dir fs_rmrec( pn ) # remove dir and everything below fs_mkdir( pn ) # create directories (mkdir -p) fs_cp( pn, pn ) # copy file fs_contents( pn ) --> text # return file contents as text fs_putfile( pn, text ) # (over)write text into file directory stack --------------- ( not yet pushd( dir ) popd() setwd( dir ) getwd() --> text ) -------------- next part -------------- proc test( code, expected ) is write( "quake(", code, ")", CR, "expected: ", expected, CR, "result: ") quake( code ) write( CR ) end proc quote( s ) is return encode( s ) end proc header( id ) is write( CR, "------ " & id & " ------------------------------------------------------------------", CR ) end proc section( name ) is write( CR, CR, "---------------------------------------" & "---------------------------------------", CR ) write( name ) write( CR, "---------------------------------------" & "---------------------------------------", CR, CR ) end oks = [] kos = [] proc summary() is section( "summary" ) nok = len( oks ) nko = len( kos ) write( nok, " tests succeeded:", CR, oks, CR, CR ) write( nko, " tests failed:", CR, kos, CR ) end proc check( id, code, expected ) is header( id ) write( "quake(", quote(code), ")", CR, "expected: ", sub(quote(expected), 0, 68), CR) quake( code ) write( "result: " & sub(quote(res), 0, 68), CR ) if equal( res & "", expected & "") write( "==> OK", CR ) oks += id %return "T" else write( "==> FAILED", CR ) kos += id %return "" end end proc checkExec( id, code ) is header( id ) write( "quake(", code, ") --> " ) quake( code ) if equal( res, 0 ) write( "OK", CR ) oks += id else write( "FAILED", CR ) kos += id end end write( "quake extension tests", CR, CR ) proc findexe( cmd ) is write( "findexe(" & cmd & ")", CR ) local paths = [] if equal( OS_TYPE, "WIN32" ) paths = split( $PATH, ";" ) else paths = split( $PATH, ":" ) end local p = "" foreach p in paths local pn = p & SL & cmd if fs_isfile( pn ) and fs_executable( pn ) return pn end if equal( OS_TYPE, "WIN32" ) local ext = "" foreach ext in [ "exe", "cmd", "bat" ] local pne = pn & "." & ext if fs_isfile( pne ) and fs_executable( pne ) return pne end end end end return "false" end %----------------------------------------------------------------------------- section( "string function tests" ) %tx = "x = 3 write(\"x = \" & x, CR)" %test( tx, "x = 3" ) t = "a = \" \t ha ha\" res = skipl( a )" check( "t001", t, "ha ha" ) t = "a = \" ha\" res = skipl( a )" check( "t002", t, "ha" ) t = "a = \" ha \" res = skipr( a ) & \"x\"" check( "t003", t, " hax" ) t = "a = \" ha \" res = compress( a ) & \"x\"" check( "t004", t, "hax" ) t = "a = \"apple plum orange\" b = split(a, \" \") res = b[0] & b[2]" check( "t005", t, "appleorange" ) t = "a = \"applepie\" res = sub(a, 5, 3)" check( "t006", t, "pie" ) t = "a = \"applepie\" res = sub(a, 7, 3)" check( "t007", t, "e" ) t = "a = \"a\n\n\nb\n\n\n\nc\n\" res = squeeze(a)" check( "t008", t, "a\n\nb\n\nc\n" ) t = "a = \"applepie\" res = tcontains(a, \"pie\")" check( "t009", t, "TRUE" ) t = "a = \"applepie\" res = tcontains(a, \"pies\")" check( "t010", t, "" ) t = "a = \"applepie\" res = pos(a, \"pie\")" check( "t011", t, 5 ) t = "a = \"applepie\" res = pos(a, \"pies\")" check( "t012", t, "-1" ) t = "a = \"applepie\" n = pos(a, \"pie\") res = sub(a, n, 1)" check( "t013", t, "p" ) t = "res = bool(\"true\")" check( "t014", t, "TRUE") t = "res = bool(\"tRuE\")" check( "t015", t, "TRUE") t = "res = bool(\"TRUE\")" check( "t016", t, "TRUE") t = "res = bool(\"y\")" check( "t017", t, "TRUE") t = "res = bool(\"yes\")" check( "t018", t, "TRUE") t = "res = bool(\"Y\")" check( "t019", t, "TRUE") t = "res = bool(\"YES \")" check( "t020", t, "TRUE") t = "res = bool(\"no\")" check( "t021", t, "") t = "res = bool(\"false\")" check( "t022", t, "") t = "res = bool(\"foo\")" check( "t023", t, "") t = "res = bool(\"0\")" check( "t024", t, "") t = "res = bool(\"1\")" check( "t025", t, "TRUE") t = "a = \"aabaacabbbaccbca\" res = subst_chars(a, \"b\", \"d\")" check( "t026", t, "aadaacadddaccdca") t = "a = \"aabaacabbbaccbca\" res = subst_chars(a, \"bc\", \"dd\")" check( "t027", t, "aadaadadddadddda") t = "a = \"aabaacabbbaccbca\" res = del_chars(a, \"b\")" check( "t028", t, "aaaacaaccca") t = "a = \"aabaacabbbaccbca\" res = del_chars(a, \"bc\")" check( "t029", t, "aaaaaaa") t = "a = \"aabaacabbbaaccbca\" res = subst(a, \"aa\", \" 42 \", 1)" check( "t030", t, " 42 baacabbbaaccbca") t = "a = \"aabaacabbbaaccbca\" res = subst(a, \"aa\", \" 42 \", 2)" check( "t031", t, " 42 b 42 cabbbaaccbca") t = "a = \"aabaacabbbaaccbca\" res = subst(a, \"aa\", \" 42 \", 99)" check( "t032", t, " 42 b 42 cabbb 42 ccbca") t = "a = [ \"a\", \"b\", \"c\" ] res = add_prefix(a, \"pre-\")" check( "t033", t, [ "pre-a", "pre-b", "pre-c" ] ) t = "a = [ \"a\", \"b\", \"c\" ] res = add_suffix(a, \"-suf\")" check( "t034", t, [ "a-suf", "b-suf", "c-suf" ] ) t = "a = \"0123456789\"res = len( a )" check( "t035", t, "10") t = "a = [ \"a\", \"b\", \"c\" ] res = len( a )" check( "t036", t, "3") t = "a = { \"a\" : \"b\", \"c\" : \"d\" } res = len( a )" check( "t037", t, "2") %----------------------------------------------------------------------------- section( "large string tests" ) SP = " " write( "16", SP ) b = "0123456789abcdef" write( "32", SP ) b = b & b write( "64", SP ) b = b & b write( "128", SP ) b = b & b write( "256", SP ) b = b & b write( "512", SP ) b = b & b write( "1k", SP ) b = b & b write( "2k", SP ) b = b & b write( "4k", SP ) b = b & b write( "8k", SP ) b = b & b write( "16k", SP ) b = b & b write( "32k", SP ) b = b & b write( "64k", SP ) b = b & b write( "128k", SP ) b = b & b write( "256k", SP ) b = b & b write( "512k", SP ) b = b & b write( "1m", SP ) b = b & b write( "OK", CR ) t = "a = subst_chars(b, \"bc\", \"xy\") res = subst_chars(b, \"xy\", \"bc\")" check( "t100", t, b) t = "res = sub(del_chars(b, \"0123456789cdef\"), 0, 10)" check( "t101", t, "ababababab") t = "res = len( b )" check( "t102", t, "1048576") %----------------------------------------------------------------------------- section( "file system tests" ) f = "res = fs_exists(\".\")" check( "f001", f, "TRUE" ) f = "res = fs_exists(\"..\")" check( "f002", f, "TRUE" ) f = "res = fs_exists(\"..\" & SL & \"src\")" check( "f003", f, "TRUE" ) f = "res = fs_isdir(\".\")" check( "f004", f, "TRUE" ) f = "res = fs_isdir(\"..\")" check( "f005", f, "TRUE" ) f = "res = fs_isdir(\"..\" & SL & \"src\")" check( "f006", f, "TRUE" ) f = "res = fs_isfile(\".\")" check( "f007", f, "" ) f = "res = fs_isfile(\"..\")" check( "f008", f, "" ) f = "res = fs_isfile(\"..\" & SL & \"src\")" check( "f009", f, "" ) f = "res = fs_isfile(\"..\" & SL & \"src\" & SL & \"m3makefile\")" check( "f010", f, "TRUE" ) f = "res = fs_isdir(\"..\" & SL & \"src\" & SL & \"m3makefile\")" check( "f011", f, "" ) more = findexe( "more" ) f = "res = fs_executable( more )" check( "f012", f, "TRUE" ) f = "res = fs_writable( more )" check( "f013", f, "" ) f = "res = fs_writable(\"..\" & SL & \"src\" & SL & \"m3makefile\")" check( "f014", f, "TRUE" ) %write( pn, CR ) cm3 = findexe( "cm3" ) %write( pn , CR ) orange = "orange" data = "line1\nline2\line3\n" f = "fs_putfile( orange, data ) res = fs_contents( orange )" check( "f015", f, data ) dirs = "a" & SL & "b" dirs_0 = dirs & SL & "c" dirs_1 = dirs & SL & "cc" dirs_2 = dirs & SL & "ccc" dirs_3 = "a" & SL & "bb" fn_a = dirs_0 & SL & "a" fn_b = dirs_0 & SL & "b" fn_c = dirs_0 & SL & "c" write( CR, "--------------------------------------", CR ) write( "dirs = ", dirs, CR ) write( "dirs_0 = ", dirs_0, CR ) write( "dirs_1 = ", dirs_1, CR ) write( "dirs_2 = ", dirs_2, CR ) write( "dirs_3 = ", dirs_3, CR ) write( "fn_a = ", fn_a, CR ) write( "fn_b = ", fn_b, CR ) write( "fn_c = ", fn_c, CR ) f = "fs_mkdir( dirs_0 ) res = fs_isdir( dirs_0 )" check( "f016", f, "TRUE" ) f = "fs_mkdir( dirs_1 ) res = fs_isdir( dirs_1 )" check( "f017", f, "TRUE" ) f = "fs_mkdir( dirs_2 ) res = fs_isdir( dirs_2 )" check( "f018", f, "TRUE" ) f = "fs_mkdir( dirs_3 ) res = fs_isdir( dirs_3 )" check( "f019", f, "TRUE" ) f = "res = fs_lsdirs( dirs, \"\" )" check( "f020", f, [dirs_0, dirs_1, dirs_2] ) f = "res = fs_lsdirs( dirs, \"T\" )" check( "f021", f, "c cc ccc" ) f = "fs_touch( fn_a ) res = fs_isfile( fn_a )" check( "f022", f, "TRUE" ) f = "fs_touch( fn_b ) res = fs_isfile( fn_b )" check( "f023", f, "TRUE" ) f = "fs_touch( fn_c ) res = fs_isfile( fn_c )" check( "f024", f, "TRUE" ) f = "res = fs_lsfiles( dirs_0, \"\" )" check( "f025", f, [fn_a, fn_b, fn_c] ) f = "res = fs_lsfiles( dirs_0, \"T\" )" check( "f026", f, "a b c" ) f = "res = fs_lsfiles( dirs, \"T\" )" check( "f027", f, "" ) f = "fs_rmfile(fn_b) res = fs_lsfiles( dirs_0, \"T\" )" check( "f028", f, "a c" ) f = "fs_rmfile(fn_b) res = fs_lsfiles( dirs_0, \"T\" )" check( "f029", f, "a c" ) f = "fs_rmdir(dirs_3) res = fs_lsdirs( \"a\", \"T\" )" check( "f030", f, "b" ) f = "fs_rmdir(dirs_3) res = fs_lsdirs( \"a\", \"T\" )" check( "f031", f, "b" ) f = "fs_rmrec(dirs) res = fs_lsdirs( \"a\", \"T\" )" check( "f032", f, "" ) f = "fs_touch(dirs) res = fs_lsfiles( \"a\", \"T\" )" check( "f033", f, "b" ) apple = "apple" f = "fs_cp( orange, apple ) res = fs_contents( apple )" check( "f034", f, data ) apple2 = "a" & SL & apple f = "fs_cp( orange, apple2 ) res = fs_contents( apple2 )" check( "f035", f, data ) f = "res = fs_lsfiles( \"a\", \"T\" )" check( "f036", f, "b apple" ) f = "fs_rmfile(apple2) res = fs_lsfiles( \"a\", \"T\" )" check( "f037", f, "b" ) %f = "fs_cp( orange, \"a\" ) res = fs_contents( apple2 )" %check( "f038", f, data ) f = "fs_rmrec(\"a\") res = fs_lsdirs( \".\", \"T\" )" check( "f099", f, "" ) %----------------------------------------------------------------------------- section( "exec tests" ) header( "e001" ) res = q_exec_get( "ls -l" ) write( "rc = ", res[0], CR, "out = ", res[1], CR ) checkExec( "e002", "res = q_exec( \"cm3 -version > cm3.version\" )" ) checkExec( "e003", "res = q_exec( \"rm cm3.version\" )" ) header( "e004" ) a = "a\nb\n\c" res = q_exec_put( "cat -", a ) write( CR, "tests done", CR ) summary() -------------- next part -------------- --- building in FreeBSD4 --- quake extension tests ------------------------------------------------------------------------------ string function tests ------------------------------------------------------------------------------ ------ t001 ------------------------------------------------------------------ quake("a = \" \t ha ha\" res = skipl( a )") expected: "ha ha" result: "ha ha" ==> OK ------ t002 ------------------------------------------------------------------ quake("a = \" ha\" res = skipl( a )") expected: "ha" result: "ha" ==> OK ------ t003 ------------------------------------------------------------------ quake("a = \" ha \" res = skipr( a ) & \"x\"") expected: " hax" result: " hax" ==> OK ------ t004 ------------------------------------------------------------------ quake("a = \" ha \" res = compress( a ) & \"x\"") expected: "hax" result: "hax" ==> OK ------ t005 ------------------------------------------------------------------ quake("a = \"apple plum orange\" b = split(a, \" \") res = b[0] & b[2]") expected: "appleorange" result: "appleorange" ==> OK ------ t006 ------------------------------------------------------------------ quake("a = \"applepie\" res = sub(a, 5, 3)") expected: "pie" result: "pie" ==> OK ------ t007 ------------------------------------------------------------------ quake("a = \"applepie\" res = sub(a, 7, 3)") expected: "e" result: "e" ==> OK ------ t008 ------------------------------------------------------------------ quake("a = \"a\n\n\nb\n\n\n\nc\n\" res = squeeze(a)") expected: "a\n\nb\n\nc\n" result: "a\n\nb\n\nc\n" ==> OK ------ t009 ------------------------------------------------------------------ quake("a = \"applepie\" res = tcontains(a, \"pie\")") expected: "TRUE" result: "TRUE" ==> OK ------ t010 ------------------------------------------------------------------ quake("a = \"applepie\" res = tcontains(a, \"pies\")") expected: "" result: "" ==> OK ------ t011 ------------------------------------------------------------------ quake("a = \"applepie\" res = pos(a, \"pie\")") expected: "5" result: "5" ==> OK ------ t012 ------------------------------------------------------------------ quake("a = \"applepie\" res = pos(a, \"pies\")") expected: "-1" result: "-1" ==> OK ------ t013 ------------------------------------------------------------------ quake("a = \"applepie\" n = pos(a, \"pie\") res = sub(a, n, 1)") expected: "p" result: "p" ==> OK ------ t014 ------------------------------------------------------------------ quake("res = bool(\"true\")") expected: "TRUE" result: "TRUE" ==> OK ------ t015 ------------------------------------------------------------------ quake("res = bool(\"tRuE\")") expected: "TRUE" result: "TRUE" ==> OK ------ t016 ------------------------------------------------------------------ quake("res = bool(\"TRUE\")") expected: "TRUE" result: "TRUE" ==> OK ------ t017 ------------------------------------------------------------------ quake("res = bool(\"y\")") expected: "TRUE" result: "TRUE" ==> OK ------ t018 ------------------------------------------------------------------ quake("res = bool(\"yes\")") expected: "TRUE" result: "TRUE" ==> OK ------ t019 ------------------------------------------------------------------ quake("res = bool(\"Y\")") expected: "TRUE" result: "TRUE" ==> OK ------ t020 ------------------------------------------------------------------ quake("res = bool(\"YES \")") expected: "TRUE" result: "TRUE" ==> OK ------ t021 ------------------------------------------------------------------ quake("res = bool(\"no\")") expected: "" result: "" ==> OK ------ t022 ------------------------------------------------------------------ quake("res = bool(\"false\")") expected: "" result: "" ==> OK ------ t023 ------------------------------------------------------------------ quake("res = bool(\"foo\")") expected: "" result: "" ==> OK ------ t024 ------------------------------------------------------------------ quake("res = bool(\"0\")") expected: "" result: "" ==> OK ------ t025 ------------------------------------------------------------------ quake("res = bool(\"1\")") expected: "TRUE" result: "TRUE" ==> OK ------ t026 ------------------------------------------------------------------ quake("a = \"aabaacabbbaccbca\" res = subst_chars(a, \"b\", \"d\")") expected: "aadaacadddaccdca" result: "aadaacadddaccdca" ==> OK ------ t027 ------------------------------------------------------------------ quake("a = \"aabaacabbbaccbca\" res = subst_chars(a, \"bc\", \"dd\")") expected: "aadaadadddadddda" result: "aadaadadddadddda" ==> OK ------ t028 ------------------------------------------------------------------ quake("a = \"aabaacabbbaccbca\" res = del_chars(a, \"b\")") expected: "aaaacaaccca" result: "aaaacaaccca" ==> OK ------ t029 ------------------------------------------------------------------ quake("a = \"aabaacabbbaccbca\" res = del_chars(a, \"bc\")") expected: "aaaaaaa" result: "aaaaaaa" ==> OK ------ t030 ------------------------------------------------------------------ quake("a = \"aabaacabbbaaccbca\" res = subst(a, \"aa\", \" 42 \", 1)") expected: " 42 baacabbbaaccbca" result: " 42 baacabbbaaccbca" ==> OK ------ t031 ------------------------------------------------------------------ quake("a = \"aabaacabbbaaccbca\" res = subst(a, \"aa\", \" 42 \", 2)") expected: " 42 b 42 cabbbaaccbca" result: " 42 b 42 cabbbaaccbca" ==> OK ------ t032 ------------------------------------------------------------------ quake("a = \"aabaacabbbaaccbca\" res = subst(a, \"aa\", \" 42 \", 99)") expected: " 42 b 42 cabbb 42 ccbca" result: " 42 b 42 cabbb 42 ccbca" ==> OK ------ t033 ------------------------------------------------------------------ quake("a = [ \"a\", \"b\", \"c\" ] res = add_prefix(a, \"pre-\")") expected: "pre-a pre-b pre-c" result: "pre-a pre-b pre-c" ==> OK ------ t034 ------------------------------------------------------------------ quake("a = [ \"a\", \"b\", \"c\" ] res = add_suffix(a, \"-suf\")") expected: "a-suf b-suf c-suf" result: "a-suf b-suf c-suf" ==> OK ------ t035 ------------------------------------------------------------------ quake("a = \"0123456789\"res = len( a )") expected: "10" result: "10" ==> OK ------ t036 ------------------------------------------------------------------ quake("a = [ \"a\", \"b\", \"c\" ] res = len( a )") expected: "3" result: "3" ==> OK ------ t037 ------------------------------------------------------------------ quake("a = { \"a\" : \"b\", \"c\" : \"d\" } res = len( a )") expected: "2" result: "2" ==> OK ------------------------------------------------------------------------------ large string tests ------------------------------------------------------------------------------ 16 32 64 128 256 512 1k 2k 4k 8k 16k 32k 64k 128k 256k 512k 1m OK ------ t100 ------------------------------------------------------------------ quake("a = subst_chars(b, \"bc\", \"xy\") res = subst_chars(b, \"xy\", \"bc\")") expected: "0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef012 result: "0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef012 ==> OK ------ t101 ------------------------------------------------------------------ quake("res = sub(del_chars(b, \"0123456789cdef\"), 0, 10)") expected: "ababababab" result: "ababababab" ==> OK ------ t102 ------------------------------------------------------------------ quake("res = len( b )") expected: "1048576" result: "1048576" ==> OK ------------------------------------------------------------------------------ file system tests ------------------------------------------------------------------------------ ------ f001 ------------------------------------------------------------------ quake("res = fs_exists(\".\")") expected: "TRUE" result: "TRUE" ==> OK ------ f002 ------------------------------------------------------------------ quake("res = fs_exists(\"..\")") expected: "TRUE" result: "TRUE" ==> OK ------ f003 ------------------------------------------------------------------ quake("res = fs_exists(\"..\" & SL & \"src\")") expected: "TRUE" result: "TRUE" ==> OK ------ f004 ------------------------------------------------------------------ quake("res = fs_isdir(\".\")") expected: "TRUE" result: "TRUE" ==> OK ------ f005 ------------------------------------------------------------------ quake("res = fs_isdir(\"..\")") expected: "TRUE" result: "TRUE" ==> OK ------ f006 ------------------------------------------------------------------ quake("res = fs_isdir(\"..\" & SL & \"src\")") expected: "TRUE" result: "TRUE" ==> OK ------ f007 ------------------------------------------------------------------ quake("res = fs_isfile(\".\")") expected: "" result: "" ==> OK ------ f008 ------------------------------------------------------------------ quake("res = fs_isfile(\"..\")") expected: "" result: "" ==> OK ------ f009 ------------------------------------------------------------------ quake("res = fs_isfile(\"..\" & SL & \"src\")") expected: "" result: "" ==> OK ------ f010 ------------------------------------------------------------------ quake("res = fs_isfile(\"..\" & SL & \"src\" & SL & \"m3makefile\")") expected: "TRUE" result: "TRUE" ==> OK ------ f011 ------------------------------------------------------------------ quake("res = fs_isdir(\"..\" & SL & \"src\" & SL & \"m3makefile\")") expected: "" result: "" ==> OK findexe(more) ------ f012 ------------------------------------------------------------------ quake("res = fs_executable( more )") expected: "TRUE" result: "TRUE" ==> OK ------ f013 ------------------------------------------------------------------ quake("res = fs_writable( more )") expected: "" result: "" ==> OK ------ f014 ------------------------------------------------------------------ quake("res = fs_writable(\"..\" & SL & \"src\" & SL & \"m3makefile\")") expected: "TRUE" result: "TRUE" ==> OK findexe(cm3) ------ f015 ------------------------------------------------------------------ quake("fs_putfile( orange, data ) res = fs_contents( orange )") expected: "line1\nline2line3\n" result: "line1\nline2line3\n" ==> OK -------------------------------------- dirs = a/b dirs_0 = a/b/c dirs_1 = a/b/cc dirs_2 = a/b/ccc dirs_3 = a/bb fn_a = a/b/c/a fn_b = a/b/c/b fn_c = a/b/c/c ------ f016 ------------------------------------------------------------------ quake("fs_mkdir( dirs_0 ) res = fs_isdir( dirs_0 )") expected: "TRUE" result: "TRUE" ==> OK ------ f017 ------------------------------------------------------------------ quake("fs_mkdir( dirs_1 ) res = fs_isdir( dirs_1 )") expected: "TRUE" result: "TRUE" ==> OK ------ f018 ------------------------------------------------------------------ quake("fs_mkdir( dirs_2 ) res = fs_isdir( dirs_2 )") expected: "TRUE" result: "TRUE" ==> OK ------ f019 ------------------------------------------------------------------ quake("fs_mkdir( dirs_3 ) res = fs_isdir( dirs_3 )") expected: "TRUE" result: "TRUE" ==> OK ------ f020 ------------------------------------------------------------------ quake("res = fs_lsdirs( dirs, \"\" )") expected: "a/b/c a/b/cc a/b/ccc" result: "a/b/c a/b/cc a/b/ccc" ==> OK ------ f021 ------------------------------------------------------------------ quake("res = fs_lsdirs( dirs, \"T\" )") expected: "c cc ccc" result: "c cc ccc" ==> OK ------ f022 ------------------------------------------------------------------ quake("fs_touch( fn_a ) res = fs_isfile( fn_a )") expected: "TRUE" result: "TRUE" ==> OK ------ f023 ------------------------------------------------------------------ quake("fs_touch( fn_b ) res = fs_isfile( fn_b )") expected: "TRUE" result: "TRUE" ==> OK ------ f024 ------------------------------------------------------------------ quake("fs_touch( fn_c ) res = fs_isfile( fn_c )") expected: "TRUE" result: "TRUE" ==> OK ------ f025 ------------------------------------------------------------------ quake("res = fs_lsfiles( dirs_0, \"\" )") expected: "a/b/c/a a/b/c/b a/b/c/c" result: "a/b/c/a a/b/c/b a/b/c/c" ==> OK ------ f026 ------------------------------------------------------------------ quake("res = fs_lsfiles( dirs_0, \"T\" )") expected: "a b c" result: "a b c" ==> OK ------ f027 ------------------------------------------------------------------ quake("res = fs_lsfiles( dirs, \"T\" )") expected: "" result: "" ==> OK ------ f028 ------------------------------------------------------------------ quake("fs_rmfile(fn_b) res = fs_lsfiles( dirs_0, \"T\" )") expected: "a c" result: "a c" ==> OK ------ f029 ------------------------------------------------------------------ quake("fs_rmfile(fn_b) res = fs_lsfiles( dirs_0, \"T\" )") expected: "a c" result: "a c" ==> OK ------ f030 ------------------------------------------------------------------ quake("fs_rmdir(dirs_3) res = fs_lsdirs( \"a\", \"T\" )") expected: "b" result: "b" ==> OK ------ f031 ------------------------------------------------------------------ quake("fs_rmdir(dirs_3) res = fs_lsdirs( \"a\", \"T\" )") expected: "b" result: "b" ==> OK ------ f032 ------------------------------------------------------------------ quake("fs_rmrec(dirs) res = fs_lsdirs( \"a\", \"T\" )") expected: "" result: "" ==> OK ------ f033 ------------------------------------------------------------------ quake("fs_touch(dirs) res = fs_lsfiles( \"a\", \"T\" )") expected: "b" result: "b" ==> OK ------ f034 ------------------------------------------------------------------ quake("fs_cp( orange, apple ) res = fs_contents( apple )") expected: "line1\nline2line3\n" result: "line1\nline2line3\n" ==> OK ------ f035 ------------------------------------------------------------------ quake("fs_cp( orange, apple2 ) res = fs_contents( apple2 )") expected: "line1\nline2line3\n" result: "line1\nline2line3\n" ==> OK ------ f036 ------------------------------------------------------------------ quake("res = fs_lsfiles( \"a\", \"T\" )") expected: "b apple" result: "b apple" ==> OK ------ f037 ------------------------------------------------------------------ quake("fs_rmfile(apple2) res = fs_lsfiles( \"a\", \"T\" )") expected: "b" result: "b" ==> OK ------ f099 ------------------------------------------------------------------ quake("fs_rmrec(\"a\") res = fs_lsdirs( \".\", \"T\" )") expected: "" result: "" ==> OK ------------------------------------------------------------------------------ exec tests ------------------------------------------------------------------------------ ------ e001 ------------------------------------------------------------------ rc = 0 out = total 8 -rw-rw-r-- 1 wagner wheel 17 31 Jan 00:59 apple -rw-rw-r-- 1 wagner wheel 17 29 Jan 18:43 ls-1 -rw-rw-r-- 1 wagner wheel 97 31 Jan 00:59 m3make.args -rw-rw-r-- 1 wagner wheel 17 31 Jan 00:59 orange ------ e002 ------------------------------------------------------------------ quake(res = q_exec( "cm3 -version > cm3.version" )) --> OK ------ e003 ------------------------------------------------------------------ quake(res = q_exec( "rm cm3.version" )) --> OK ------ e004 ------------------------------------------------------------------ a b c tests done ------------------------------------------------------------------------------ summary ------------------------------------------------------------------------------ 80 tests succeeded: t001 t002 t003 t004 t005 t006 t007 t008 t009 t010 t011 t012 t013 t014 t015 t016 t017 t018 t019 t020 t021 t022 t023 t024 t025 t026 t027 t028 t029 t030 t031 t032 t033 t034 t035 t036 t037 t100 t101 t102 f001 f002 f003 f004 f005 f006 f007 f008 f009 f010 f011 f012 f013 f014 f015 f016 f017 f018 f019 f020 f021 f022 f023 f024 f025 f026 f027 f028 f029 f030 f031 f032 f033 f034 f035 f036 f037 f099 e002 e003 0 tests failed: From wagner at elegosoft.com Thu Jan 31 12:43:04 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 31 Jan 2008 12:43:04 +0100 Subject: [M3devel] Looking for CM3 Tinderbox regression test participants, was: Re: M3 concerns In-Reply-To: <20080105143235.ujed2tl3ksogws8k@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> Message-ID: <20080131124304.w0aq9ygt2ckw4okc@mail.elegosoft.com> 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 Thu Jan 31 17:22:23 2008 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Thu, 31 Jan 2008 10:22:23 -0600 Subject: [M3devel] [Fwd: Sanity check request regarding CT arithmetic] Message-ID: <47A1F5BF.3070201@wichita.edu> 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 From hosking at cs.purdue.edu Thu Jan 31 18:29:21 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 31 Jan 2008 12:29:21 -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: <22926B17-1317-4B74-9024-AADFF81ED88A@cs.purdue.edu> I can contribute: see below... 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 I can do OS X 10.4. > o I386_DARWIN I can do OS X 10.4. > o SOLgnu on any Solaris version I can do Solaris 10 T2000. > o SOLsun " I can do Solaris 10 T2000. > o LINUXLIBC6 on RedHat, Fedora, Ubuntu, Suse Linux (have I forgotten > some variants?) I can do these too if noone else wants to take up the cause. > 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 could fire up the one in the corner of my office that is lying dormant if there is need... :-) > > 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 Thu Jan 31 18:44:05 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 31 Jan 2008 12:44:05 -0500 Subject: [M3devel] [Fwd: Sanity check request regarding CT arithmetic] In-Reply-To: <47A1F5BF.3070201@wichita.edu> References: <47A1F5BF.3070201@wichita.edu> Message-ID: <338F5FD0-A818-4792-A583-A17B72EF956D@cs.purdue.edu> 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 > > From wagner at elegosoft.com Thu Jan 31 20:03:17 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 31 Jan 2008 20:03:17 +0100 Subject: [M3devel] Looking for CM3 Tinderbox regression test participants, was: Re: M3 concerns In-Reply-To: <22926B17-1317-4B74-9024-AADFF81ED88A@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> <22926B17-1317-4B74-9024-AADFF81ED88A@cs.purdue.edu> Message-ID: <20080131200317.uwy41vdfkw40o04g@mail.elegosoft.com> Great! Just go ahead and try one target of your choice; I dare say you should have no problem with the setup. (Solaris would be great, as this is a completely different architecture, and our last Sun died some time ago.) If it works OK, we should soon see the results in the tinderbox. We can then add others one by one. As you're the first to respond, you've got the free choice what and how much you will take over; running the tests regularly will cost some resources in form of disk space and cpu, of course. I'd like to set up a reliable network, that's why I want to progress cautiously and observe the effects and impacts. If I can be of any hlep, just let me know; as you've got ssh access already, everything *should* just work... ;-) Thanks in advance, Olaf Quoting Tony Hosking : > I can contribute: see below... > >> o PPC_DARWIN on MacOS X 10.4 or 10.5 > > I can do OS X 10.4. > >> o I386_DARWIN > > I can do OS X 10.4. > >> o SOLgnu on any Solaris version > > I can do Solaris 10 T2000. > >> o SOLsun " > > I can do Solaris 10 T2000. > >> o LINUXLIBC6 on RedHat, Fedora, Ubuntu, Suse Linux (have I forgotten >> some variants?) > > I can do these too if noone else wants to take up the cause. > >> o ALPHA_OSF -- is anybody still using Alphas? > > I could fire up the one in the corner of my office that is lying > dormant if there is need... :-) -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Jan 31 20:23:39 2008 From: jayk123 at hotmail.com (Jay) Date: Thu, 31 Jan 2008 19:23:39 +0000 Subject: [M3devel] Looking for CM3 Tinderbox regression test participants, was: Re: M3 concerns In-Reply-To: <20080131200317.uwy41vdfkw40o04g@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> <22926B17-1317-4B74-9024-AADFF81ED88A@cs.purdue.edu> <20080131200317.uwy41vdfkw40o04g@mail.elegosoft.com> Message-ID: I intendto try first PPC_DARWIN, PPC_LINUX, NT386* but no promises, esp. on regularity, my machines are mostly laptops that sleep a lot, and then maybe other x86 and PPC after that (including maybe try to bring up new ones..another thread..) - Jay > Date: Thu, 31 Jan 2008 20:03:17 +0100> From: wagner at elegosoft.com> To: hosking at cs.purdue.edu> CC: m3devel at elegosoft.com; m3-support at elego.de; tobermueller at elego.de; admins at elego.de> Subject: Re: [M3devel] Looking for CM3 Tinderbox regression test participants, was: Re: M3 concerns> > Great!> > Just go ahead and try one target of your choice; I dare say you should> have no problem with the setup. (Solaris would be great, as this is> a completely different architecture, and our last Sun died some time ago.)> > If it works OK, we should soon see the results in the tinderbox.> We can then add others one by one. As you're the first to respond,> you've got the free choice what and how much you will take over;> running the tests regularly will cost some resources in form of disk> space and cpu, of course. I'd like to set up a reliable network,> that's why I want to progress cautiously and observe the effects and> impacts.> > If I can be of any hlep, just let me know; as you've got ssh access> already, everything *should* just work... ;-)> > Thanks in advance,> > Olaf> > Quoting Tony Hosking :> > > I can contribute: see below...> >> > >> o PPC_DARWIN on MacOS X 10.4 or 10.5> >> > I can do OS X 10.4.> >> >> o I386_DARWIN> >> > I can do OS X 10.4.> >> >> o SOLgnu on any Solaris version> >> > I can do Solaris 10 T2000.> >> >> o SOLsun "> >> > I can do Solaris 10 T2000.> >> >> o LINUXLIBC6 on RedHat, Fedora, Ubuntu, Suse Linux (have I forgotten> >> some variants?)> >> > I can do these too if noone else wants to take up the cause.> >> >> o ALPHA_OSF -- is anybody still using Alphas?> >> > I could fire up the one in the corner of my office that is lying> > dormant if there is need... :-)> -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 Thu Jan 31 20:31:28 2008 From: jayk123 at hotmail.com (Jay) Date: Thu, 31 Jan 2008 19:31:28 +0000 Subject: [M3devel] what platforms/architectures interest people? In-Reply-To: <20080131200317.uwy41vdfkw40o04g@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> <22926B17-1317-4B74-9024-AADFF81ED88A@cs.purdue.edu> <20080131200317.uwy41vdfkw40o04g@mail.elegosoft.com> Message-ID: This is getting way ahead of things, but I was wondering what platforms/architectures interest folks? *_NETBSD (maybe NBSD for short?) *_OPENBSD (OBSD?) *_FREEBSD (FBSD?) MIPS_* SH_* ARM_* (there is some ARM stuff) ALPHA_* IA64_* AMD64_* *_WINCE (mainly ARM, but many possible -- x86, MIPS, PPC, SH) X86_DJGPP ?? SPARC_LINUX ?? SPARC_*BSD ?? Personally I only have PPC, x86, and AMD64 hardware, all laptops, and the rest aren't available in laptops afaik (ok, WINCE devices are small). I'd be willing to try PPC_*BSD, X86_*BSD|SOLARIS, AMD64_LINUX|NT|SOLARIS. Itanium 1 hardware is under $500 on eBay, Itanium 2 under $1000. Far from a laptop but slightly tempting in terms of aggressive porting. At least they run Windows. :) Or is everything pretty dead by now but x86 and AMD64? (other than cell phones, hand helds, game consoles). I was also think expanding the use of the integrated backend would be interesting. - Jay _________________________________________________________________ Shed those extra pounds with MSN and The Biggest Loser! http://biggestloser.msn.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcoleburn at scires.com Thu Jan 31 23:53:30 2008 From: rcoleburn at scires.com (Randy Coleburn) Date: Thu, 31 Jan 2008 17:53:30 -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: <47A20B17.1E75.00D7.1@scires.com> Olaf: I'll take a look at the requirements and see if I can set something up for testing NT386 on Windows XP and perhaps on Windows 2000. Regards, Randy >>> Olaf Wagner 1/31/2008 6:43 AM >>> 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 ( 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 rcoleburn at scires.com Thu Jan 31 23:56:05 2008 From: rcoleburn at scires.com (Randy Coleburn) Date: Thu, 31 Jan 2008 17:56:05 -0500 Subject: [M3devel] what platforms/architectures interest people? 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> <22926B17-1317-4B74-9024-AADFF81ED88A@cs.purdue.edu> <20080131200317.uwy41vdfkw40o04g@mail.elegosoft.com> Message-ID: <47A20BB2.1E75.00D7.1@scires.com> Jay: The platforms I use most for Modula-3 are Windows (NT/2000/XP) and HP-UX. I also may have occasion to use SPARC and Solaris. Of course, the list will change over time. Regards, Randy >>> Jay 1/31/2008 2:31 PM >>> This is getting way ahead of things, but I was wondering what platforms/architectures interest folks? *_NETBSD (maybe NBSD for short?) *_OPENBSD (OBSD?) *_FREEBSD (FBSD?) MIPS_* SH_* ARM_* (there is some ARM stuff) ALPHA_* IA64_* AMD64_* *_WINCE (mainly ARM, but many possible -- x86, MIPS, PPC, SH) X86_DJGPP ?? SPARC_LINUX ?? SPARC_*BSD ?? Personally I only have PPC, x86, and AMD64 hardware, all laptops, and the rest aren't available in laptops afaik (ok, WINCE devices are small). I'd be willing to try PPC_*BSD, X86_*BSD|SOLARIS, AMD64_LINUX|NT|SOLARIS. Itanium 1 hardware is under $500 on eBay, Itanium 2 under $1000. Far from a laptop but slightly tempting in terms of aggressive porting. At least they run Windows. :) Or is everything pretty dead by now but x86 and AMD64? (other than cell phones, hand helds, game consoles). I was also think expanding the use of the integrated backend would be interesting. - Jay 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 Thu Jan 3 11:58:38 2008 From: jayk123 at hotmail.com (Jay) Date: Thu, 03 Jan 2008 10:58:38 -0000 Subject: [M3devel] M3 concerns In-Reply-To: <200801030010.m030AgKN099099@camembert.async.caltech.edu> References: Your message of "Wed, 02 Jan 2008 14:32:02 EST." <477BA060.1E75.00D7.1@scires.com> <200801030010.m030AgKN099099@camembert.async.caltech.edu> Message-ID: This is in reference to me. I have been making pretty small safe tested changes. But yeah I am impatient and impulsive and do commit small bits, usually well tested. I do have more than one copy of the source and at least once recently checked in from the wrong copy. And scripts/python is new and presumably as yet unused so I don't see the harm in churn there. I've been able to build the system many times under Windows for quite a while, since around whenever scripts/win/* was commited. Over a year ago I think. I think self-buildability is a fairly good test already. Please let me know what the errors are. As for your code itself not working, well I can't promise as much and maybe you can't send it, but if you can provide source with problems I might be able to look into it. There was a problem bootstrapping from 5.2.6, since merely things weren't built in the right order, with the int64 work, but I fixed that a while ago. I haven't really touched the gui stuff. And the various gui apps do look very clunky, a bit hard to figure out how to use, and maybe flaky and unreliable. I guess I should try them on other systems. One thing I changed which should be discussed more is the entry code for .dlls. That's what the C/C++ interop question was about. I think where it is "wrong", you will get a link warning, but I didn't check that. It is "only" on the config file, though not sure that's a mitigating factor or not -- how much do people maintain local config files vs. take the checked in one and apply any diffs. The checked in Windows one is now designed to not need any diffs, so then saying people can change it is a bit hypocritical. So I guess I should remove that one line. I use mainly Windows but have Mac PowerPC and /maybe/ can commit to using others, like Linux PowerPC and other x86 systems (Solaris x86 anyone? :), Linux, FreeBSD, NetBSD)..gotta be a laptop though :) and VMware/VirtualPC are ok. (Nothing seems to compare in producitivity to merely older versions of Visual C++ (5.0, 6.0) and aggressive use of find in files, esp. because of the ease of keyboard use. I've been using "TextWrangler" on the Mac and it is ok but not as good, less keyboard accessible, annoying how each find-in-files opens a new window (even though VC can be annoying for lack of new windows there, usually not)..."kate" on Linux was ok, used it a bit, will try a bit more..) - Jay > To: rcoleburn at scires.com > Date: Wed, 2 Jan 2008 16:10:42 -0800 > From: mika at async.caltech.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] M3 concerns > > > I can happily volunteer FreeBSD 4.x and 5.x (i386) systems, Windows > 2000, and, I believe, Digital Unix 4.0 systems to run nightly > (daily?) builds. Unfortunately I am of course a bit short on Time, > which is probably what's lacking the most, anyhow... > > Mika > > "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. > > > >--=__Part103621A2.1__= > >Content-Type: text/plain; charset=US-ASCII > >Content-Transfer-Encoding: quoted-printable > > > >Tony: > >=20 > >I'm thinking that with a little work we could set up an automated set of = > >builds and regression tests that would make available a "scoreboard" via a = > >web interface where everyone could see the results. That way, as problems = > >are uncovered, folks could begin working on them. > >=20 > >For an example of how all this works, take a look at the scoreboard set up = > >for the ACE+TAO+CIAO projects. An overview is at http://www.dre.vanderbilt= > >.edu/Scoreboard/ . They provide instructions for setting up your own = > >daily build and scoreboard at https://svn.dre.vanderbilt.edu/viewvc/autobui= > >ld/trunk/README?revision=3DHEAD . You can see the scoreboard in operation = > >at http://remedy.nl/ . > >=20 > >Regards, > >Randy > > > >>>> Tony Hosking 1/2/2008 1:36 PM >>> > > > >On Jan 2, 2008, at 11:31 AM, Randy Coleburn wrote: > > > >> I've seen quite a number of m3commit and m3devel messages lately. =20 > >> Many of these give the appearance of "thinking out loud" with =20 > >> various commits followed by apparent reversals. In many cases the =20 > >> m3commit log messages are terse and don't give the rationale behind =20 > >> the change. > > > >Yes, I agree. Also, I tend to avoid committing multiple small =20 > >patches and rather defer until I have had a chance to test everything =20 > >and let it stabilize, before checking in as one single commit. So, =20 > >less frequent, coherent commits, are preferable to many smaller, =20 > >incoherent commits. > > > >> For those of us in the M3 community who rely upon the stability of =20 > >> the libraries and core M3 principles, these types of messages cause =20 > >> concern. While I appreciate everyone's efforts to move forward, I =20 > >> don't want to abandon the great care that went into formulating =20 > >> this language. > > > >Indeed. > > > >> Question: As various people make contributions and changes, is =20 > >> there any group of folks who is verifying that the changes don't =20 > >> break existing code or core principles? Another idea would be to =20 > >> have a series of test batteries that have to be passed before =20 > >> changes can be accepted. I know of a number of projects where many =20 > >> people contribute, but the contributions have to be vetted by =20 > >> passing some tests. > > > >I try to verify that all my code doesn't break existing code (though =20 > >I admit GC/thread subsystems can be devilish to completely verify). =20 > >We do need to have some sort of procedures in place for deciding what =20 > >commits make sense and should go into the CVS head. Tentative work =20 > >should always be done to a CVS branch until it can be vetted. > > > >> Without these types of controls, I fear that good forward progress =20 > >> will inevitably be hampered or compromised by changes made by =20 > >> someone who hasn't completely thought out and tested the =20 > >> ramifications of those changes. > > > >Agree! > > > >> For example, I've tried to get cm3 working for me on Windows XP =20 > >> several times. I still can't seem to get the "current" system to =20 > >> build correctly on XP. In the past, I have on occasion gotten the =20 > >> "system" to build, but then some of my programs don't work =20 > >> correctly when rebuilt using the new cm3. Thus, some changes =20 > >> somewhere have "broken" my code, yet all of my code uses the "safe" =20 > >> subset of the language. If I go back to my old reliable cm3 =20 > >> version 4.1 (the last one put out before Critical Mass, Inc. threw =20 > >> in the towel), my code compiles and works, even on Windows XP, even =20 > >> using Trestle, FormsVBT, NetObj, cross-platform pickles (e.g., =20 > >> pickles shared between Windows & Unix boxes), etc.! Much of my =20 > >> code was originally developed under Windows NT, so I think it is a =20 > >> tribute to the original language developers that my code and their =20 > >> compiler work through various OS version upgrades (NT, 2000, XP) =20 > >> and changes to the underlying C/C++ compilers used to build the =20 > >> core components. > > > >I thought we were getting closer to stability in this regard, though =20 > >I am not a heavy Windows user and have never built CM3 on Windows. > > > >> I would appreciate constructive feedback on this topic. > > > >It would be great to have a set of regression tests run on a regular =20 > >basis to ensure that checkins don't break things. What good =20 > >candidates do we have? cm3 itself I suppose. Any others? I can =20 > >probably devise a couple of thread and GC stress tests pretty =20 > >easily. Anyone willing to set up a testing regime? I have machines =20 > >that could be used to test on several supported platforms on a =20 > >nightly basis even. > > > >> > >> Regards, > >> Randy Coleburn > >> > >> > >> Randy C. Coleburn, CISSP > >> Senior Systems Engineer, Communications, Networks, & Electronics =20 > >> Division (CNE) > >> Corporate & Atlanta Information Systems Security Manager (ISSM) > >> Scientific Research Corporation > >> 2300 Windy Ridge Parkway, Suite 400 South, Atlanta, Georgia 30339 > >> voice: (770) 989-9464, email: RColeburn at SciRes.com, fax: (770) =20 > >> 989-9497 > >> > >> Quality Policy: "SRC CNE Division is committed to delivering =20 > >> continually improving research & engineering excellence that meets =20 > >> or exceeds customer requirements." > > > > > > > >--=__Part103621A2.1__= > >Content-Type: text/html; charset=US-ASCII > >Content-Transfer-Encoding: quoted-printable > >Content-Description: HTML > > > > > > >"> > > > > > >
Tony:
> >
 
> >
I'm thinking that with a little work we could set up an automated set = > >of builds and regression tests that would make available a "scoreboard" = > >via a web interface where everyone could see the results.  That way, = > >as problems are uncovered, folks could begin working on them.
> >
 
> >
For an example of how all this works, take a look at the scoreboard = > >set up for the ACE+TAO+CIAO projects.  An overview is at >tp://www.dre.vanderbilt.edu/Scoreboard/">http://www.dre.vanderbilt.edu/Scor= > >eboard/ .  They provide instructions for setting up your own = > >daily build and scoreboard at >wvc/autobuild/trunk/README?revision=3DHEAD">https://svn.dre.vanderbilt.edu/= > >viewvc/autobuild/trunk/README?revision=3DHEAD .  You can see = > >the scoreboard in operation at http://remedy.= > >nl/ .
> >
 
> >
Regards,
> >
Randy
> >

>>> Tony Hosking <hosking at cs.purdue.edu> 1/2/2008 = > >1:36 PM >>>

On Jan 2, 2008, at 11:31 AM, Randy Coleburn = > >wrote:

> I've seen quite a number of m3commit and m3devel = > >messages lately.  
> Many of these give the appearance of = > >"thinking out loud" with 
> various commits followed by = > >apparent reversals.  In many cases the 
> m3commit log = > >messages are terse and don't give the rationale behind 
> the = > >change.

Yes, I agree.  Also, I tend to avoid committing = > >multiple small 
patches and rather defer until I have had a = > >chance to test everything 
and let it stabilize, before checking = > >in as one single commit.   So, 
less frequent, coherent = > >commits, are preferable to many smaller, 
incoherent commits.
<= > >BR>>  For those of us in the M3 community who rely upon the = > >stability of 
> the libraries and core M3 principles, these = > >types of messages cause 
> concern.  While I appreciate = > >everyone's efforts to move forward, I 
> don't want to abandon = > >the great care that went into formulating 
> this language.
= > >
Indeed.

>  Question:  As various people make = > >contributions and changes, is 
> there any group of folks who = > >is verifying that the changes don't 
> break existing code or = > >core principles?  Another idea would be to 
> have a = > >series of test batteries that have to be passed before 
> = > >changes can be accepted.  I know of a number of projects where = > >many 
> people contribute, but the contributions have to be = > >vetted by 
> passing some tests.

I try to verify that = > >all my code doesn't break existing code (though 
I admit = > >GC/thread subsystems can be devilish to completely verify).   = > >
We do need to have some sort of procedures in place for deciding = > >what 
commits make sense and should go into the CVS head.  = > >Tentative work 
should always be done to a CVS branch until it = > >can be vetted.

>  Without these types of controls, I fear = > >that good forward progress 
> will inevitably be hampered or = > >compromised by changes made by 
> someone who hasn't completely= > > thought out and tested the 
> ramifications of those = > >changes.

Agree!

>  For example, I've tried to get = > >cm3 working for me on Windows XP 
> several times.  I = > >still can't seem to get the "current" system to 
> build = > >correctly on XP.  In the past, I have on occasion gotten the  = > >
> "system" to build, but then some of my programs don't work  = > >
> correctly when rebuilt using the new cm3.  Thus, some = > >changes 
> somewhere have "broken" my code, yet all of my code = > >uses the "safe" 
> subset of the language.  If I go back = > >to my old reliable cm3 
> version 4.1 (the last one put out = > >before Critical Mass, Inc. threw 
> in the towel), my code = > >compiles and works, even on Windows XP, even 
> using Trestle, = > >FormsVBT, NetObj, cross-platform pickles (e.g., 
> pickles = > >shared between Windows & Unix boxes), etc.!  Much of my  = > >
> code was originally developed under Windows NT, so I think it is = > >a 
> tribute to the original language developers that my code = > >and their 
> compiler work through various OS version upgrades = > >(NT, 2000, XP) 
> and changes to the underlying C/C++ = > >compilers used to build the 
> core components.

I = > >thought we were getting closer to stability in this regard, though  = > >
I am not a heavy Windows user and have never built CM3 on Windows.
<= > >BR>>  I would appreciate constructive feedback on this topic.
>R>It would be great to have a set of regression tests run on a regular = > >;
basis to ensure that checkins don't break things.  What = > >good 
candidates do we have?  cm3 itself I suppose.  = > >Any others?  I can 
probably devise a couple of thread and = > >GC stress tests pretty 
easily.  Anyone willing to set up a = > >testing regime? I have machines 
that could be used to test on = > >several supported platforms on a 
nightly basis even.

><= > >BR>> Regards,
> Randy Coleburn
>
>
> Randy C. = > >Coleburn, CISSP
> Senior Systems Engineer, Communications, Networks, = > >& Electronics 
> Division (CNE)
> Corporate & = > >Atlanta Information Systems Security Manager (ISSM)
> Scientific = > >Research Corporation
> 2300 Windy Ridge Parkway, Suite 400 South, = > >Atlanta, Georgia 30339
> voice: (770) 989-9464, email: RColeburn at SciR= > >es.com, fax: (770) 
> 989-9497
>
> Quality = > >Policy:  "SRC CNE Division is committed to delivering 
> = > >continually improving research & engineering excellence that meets = > >;
> or exceeds customer requirements."


>L> > > > >--=__Part103621A2.1__=-- _________________________________________________________________ Don't get caught with egg on your face. Play Chicktionary! http://club.live.com/chicktionary.aspx?icid=chick_wlhmtextlink1_dec -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Sat Jan 12 03:47:50 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 12 Jan 2008 02:47:50 -0000 Subject: [M3devel] I need CVS help again In-Reply-To: <20080112012216.k4d438pquc0sw8os@mail.elegosoft.com> References: <478807B4.2080100@wichita.edu> <20080112012216.k4d438pquc0sw8os@mail.elegosoft.com> Message-ID: [tangent as usual :)] I find the CVS usage model "ok", but I would like a choice of another one. I would like to know there is a conflict before it changes any of my files, or AT LEAST the ones with conflicts. And then I want to easily browse the conflicting changes, possibly applying them manually locally, so that CVS can do the merge automatically. In Perforce the way this works is it goes ahead and changes all the files with no merging at all to be done and then you have several choices for the merges and conflicts. You can accept the automatic ones, reviewing them or not before accepting them. For conflicts you can accept theirs or yours or bring up an editor with something like what CVS does, but you can also put it off a bit -- but can't commit (submit) before resolving. A missing or unclear thing though is if you can have it accept automatic merges within a file where possible, and then yours/theirs on the conflicts. Duh I just had a really obvious epiphany finally. I need to try out TortoiseCVS and its nearest competing Mac and Linux analogs. That'll probably make me much more satisified. :) (Reminder to any other folks to try the GUIs if they aren't experts with the command line.) TortoiseSVN has been nice to use for example. - Jay > Date: Sat, 12 Jan 2008 01:22:16 +0100> From: wagner at elegosoft.com> To: m3devel at elegosoft.com> Subject: Re: [M3devel] I need CVS help again> > Quoting "Rodney M. Bates" :> > > I have gotten myself into this jam before, as a result of trying to> > develop/test on more than one local machine with more than one M3> > installation. I have more questions on how to figure out what happened> > and how to fix it.> >> > I did a cvs update when, I guess, I had local uncommitted edits.> > I got messages saying that changes were being merged and there were> > conflicts. For example, I now have local files named:> >> > .#m3-eval.c.1.12> > m3-eval.c> >> > and in CVS/Entries, the line:> >> > /m3-eval.c/1.14/Result of merge...> >> > Have I correctly surmised that this all means> >> > 1) prior to the update, CVS/Entries would have said:> >> > /m3-eval/c/1.12...> >> > meaning 1.12 was the last version cvs knew I had,> >> > 2) But my local m3-eval.c had local changes relative to 1.12,> >> > 3) And .#m3-eval.c.1.12 is a copy of that locally changed> > m3-eval.c, as it was prior to the cvs update,> > Yes, this should be your original file.> > > 4) The latest version cvs has in its repository is 1.14, and> > Yes.> > > 5) My current local m3-eval.c was generated by merging version> > 1.14 from the repository with what is now in .#m3-eval.c.1.12?> > Yes.> You should simply find the comflicts in m3-eval.c by looking for> lines with <<<< and ===== and >>>>.> Often they are easy to edit manually.> > > Is there a simple way to get cvs to diff between its stored> > version 1.12 and my .#m3-eval.1.12?> > You can checkout any version into your workspace and compare locally:> > cvs up -p -r 1.12 m3-eval.c > m3-eval.c.1.12> cvs up -p -r 1.14 m3-eval.c > m3-eval.c.1.14> > diff -u .m3-eval.c.1.12 \#m3-eval.1.12> ...> > HTH,> > Olaf> -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194> _________________________________________________________________ Watch ?Cause Effect,? a show about real people making a real difference. http://im.live.com/Messenger/IM/MTV/?source=text_watchcause -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sun Jan 13 04:10:57 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 13 Jan 2008 03:10:57 -0000 Subject: [M3devel] could someone add __stdcall name mangling to m3cc please? In-Reply-To: References: Your message of "Wed, 09 Jan 2008 17:25:31 PST." <200801100131.m0A1VQYS034516@camembert.async.caltech.edu> <6D467648-44A7-48DC-AB8D-27B3AC19EBB0@cs.purdue.edu> <80BC3E7C-2DA6-4765-9053-A52950700404@cs.purdue.edu> Message-ID: <0FD0008E-575E-4362-8B78-A125EF9FFD07@cs.purdue.edu> Yup. On Jan 12, 2008, at 7:51 PM, Jay wrote: > > current_param_count > > Must this code use globals? > > - Jay > > > From: jayk123 at hotmail.com > To: hosking at cs.purdue.edu > CC: m3devel at elegosoft.com > Subject: RE: [M3devel] could someone add __stdcall name mangling to > m3cc please? > Date: Sun, 13 Jan 2008 00:49:10 +0000 > > I commited something LIKE this, that lets m3core.dll link. > (The below had several errors. Failing to loop, failing to > terminate the list correctly, only getting function pointers or > functions instead of both, for some reason the Windows *.i3 files > use a mix.) > > libm3.dll has a boring pathname format problem, ld doesn't like c: > \foo\../bar.lib and I got sidetracked.. > > It MIGHT not work for SOME functions, a link error -- if taking > __int64 or small structs by value, in a __stdcall function. > I'll see if that comes up as I progress through the system slowly. > > - Jay > > > > CC: m3devel at elegosoft.com > > From: hosking at cs.purdue.edu > > Subject: Re: [M3devel] could someone add __stdcall name mangling > to m3cc please? > > Date: Sat, 12 Jan 2008 19:06:35 -0500 > > To: jayk123 at hotmail.com > > > > It will need to be a little cleaner than that -- I'd rather gather > > the parameters as declared and enter them into the function type. It > > means not ignoring the parameter decls: see m3cg_declare_param check > > for current_param_count==0. To do this it needs to be a little bit > > smarter about managing current_function_decl -- probably a stack. > > > > On Jan 12, 2008, at 2:57 PM, Jay wrote: > > > > > Something like this????? > > > > > > > =================================================================== > > > RCS file: /usr/cvs/cm3/m3-sys/m3cc/gcc/gcc/m3cg/parse.c,v > > > retrieving revision 1.41 > > > diff -r1.41 parse.c > > > 3066a3070 > > > > tree atypes = NULL_TREE); > > > 3091c3095,3102 > > > < TREE_TYPE (p) = build_function_type (return_type, NULL_TREE); > > > --- > > > > /* for NT386 __stdcall, we just need to declare the right number > > > > of parameters > > > > */ > > > > if (--n_params== 0) { > > > > atypes = tree_cons (NULL_TREE, t_word, atypes); > > > > } > > > > > > > > TREE_TYPE (p) = build_function_type (return_type, atypes); > > > > > > haven't even compiled it yet.. > > > > > > - Jay > > > > > > > > > > > > > > > > > > > > > > From: jayk123 at hotmail.com > > > > To: hosking at cs.purdue.edu > > > > Date: Sat, 12 Jan 2008 18:13:27 +0000 > > > > CC: m3devel at elegosoft.com > > > > Subject: Re: [M3devel] could someone add __stdcall name mangling > > > to m3cc please? > > > > > > > > Tony, Sorry, I didn't mean to check those in. Those were wild > > > guesses that I hadn't tested yet.I put it back. Thanks for > catching > > > that. > > > > > > > > - Jay > > > > > > > > > > > > > > > > > CC: m3devel at elegosoft.com> From: hosking at cs.purdue.edu> > > > Subject: Re: [M3devel] could someone add __stdcall name > mangling to > > > m3cc please?> Date: Sat, 12 Jan 2008 10:41:26 -0500> To: > > > jayk123 at hotmail.com> > I'm not sure what you were trying to do > with > > > parse.c by adding a > parameter (nargs*4) to the stdcall > attribute, > > > but that probably > doesn't do anything interesting. The problem > > > appears to be because > on external function decls the parameter > > > decls are currently being > ignored by cm3cg. If I fix parse.c to > > > add the params for those then > it should work properly with the > > > stdcall attribute.> > On Jan 12, 2008, at 8:27 AM, Jay wrote:> > > > > > Thanks, but not quite. The number of parameters times four > needs to > > > > > be appended to the name, in decimal.> > But I'm just getting > > > 0.> > That is, gcc is handling the underlying detail, but you > > > aren't > > giving it enough infomrmation.> > I'll see if I can > bang > > > out those temporary wrappers automatically.. > > (a Quake > > > programming challenge, that I've already invented the hard > > > part > > > of I think -- Quake can't do math..)> >> > - Jay> >> >> > > CC: > > > m3devel at elegosoft.com> > > From: hosking at cs.purdue.edu> > > > > > Subject: Re: [M3devel] could someone add __stdcall name mangling > > > > > to m3cc please?> > > Date: Fri, 11 Jan 2008 13:16:44 -0500> > > > > > To: jayk123 at hotmail.com> > >> > > I just added support for this. > > > Let me know if it seems to work (or> > > not! :-) ).> > >> > >> > > > > > > On Jan 10, 2008, at 7:40 AM, Jay wrote:> > >> > > > Could someone > > > out there (Tony?) familiar with the gcc backend> > > > have it not > > > ignore call_conv and if call_conv is 1, append> > > > an at symbol > > > and the number of bytes of parameters to the function> > > > > name?> > > > > > > (Even for zero, e.g. Sleep at 0, GetFileAttributes at 4).> > > > > > > This would be I guess at least for "imported" functions.> > > >> > > > > > > Not clear about calling function pointers, probably needs> > > > > > > modification.> > > > call_conv 0 is "__cdecl" is push right to > > > left, caller cleans up> > > > call_conv 1 is "__stdcall" is push > > > right to left, callee cleans up> > > > There are various > synonyms.> > > > > > > With no command line switches, __cdecl is the compiler > > > default.> > > > __stdcall is deemed more efficient, and is very > > > widely used.> > > >> > > > Not clear about functions > implemented in > > > Modula-3.> > > > Probably won't occur? Maybe for callbacks? > > > WindowProcs, thread> > > > entry point?> > > >> > > > This could/ > > > should be for NT386GNU only.> > > > The hypothetical other NT > > > targets only have one calling convention> > > > each.> > > >> > > > > > > > I COULD do something sleazy here and generate little adapter> > > > > > > > functions, over in m3-win/import-libs esp.> > > >> > > > I'm still > > > checking out pm3 to see what it does here.> > > > (as in cvs > > > checkout, not "looking at")> > > >> > > > This'll clear up:> > > > >> > > > > > > RTOS.m3:27: undefined reference to `_FatalExit'> > > > > > > RTOS.mo: In function `RTOS__GetMemory':> > > > RTOS.m3:75: > > > undefined reference to `_VirtualAlloc'> > > > RTOS.m3:85: > undefined > > > reference to `_VirtualAlloc'> > > > RTOS.mo: In function > > > `RTOS__InitMemory':> > > > RTOS.m3:96: undefined reference to > > > `_VirtualAlloc'> > > > RTOS.m3:100: undefined reference to > > > `_GetSystemInfo'> > > > RTOS.mo: In function `RTOS__Write':> > > > > > > RTOS.m3:118: undefined reference to `_AllocConsole'> > > > > > > RTOS.m3:119: undefined reference to `_GetStdHandle'> > > > > > > RTOS.m3:122: undefined reference to `_WriteFile'> > > > > > > RTPerfTool.mo: In function `RTPerfTool__Start':> > > > > > > RTPerfTool.m3:19: undefined reference to `_ReadFile'> > > > > > > RTPerfTool.m3:22: undefined reference to `_CloseHandle'> > > > > > > RTPerfTool.mo: In function `RTPerfTool__Close':> > > > > > > RTPerfTool.m3:28: undefined reference to `_CloseHandle'> > > > > > > RTPerfTool.mo: In function `RTPerfTool__Send':> > > > > > > RTPerfTool.m3:34: undefined reference to `_WriteFile'> > > > > > > RTPerfTool.mo: In function `RTPerfTool__PrepHandle':> > > > > > > RTPerfTool.m3:58: undefined reference to `_GetCurrentProcess'> > > > > > > RTPerfTool.m3:59: undefined reference to `_DuplicateHandle'> > > > > > > etc.> > > >> > > > I did think I was past these. I thought I > > > built m3core and libm3> > > > including linking (having even > > > modified cm3.cfg)> > > > COULD be I'm using the wrong .libs, but:> > > > > > >> > > > C:\cygwin\lib\w32api>nm libkernel32.a | findstr > > > CreateFile> > > > 00000000 I __imp__CreateFileW at 28> > > > 00000000 > > > T _CreateFileW at 28> > > > 00000000 I > __imp__CreateFileMappingW at 24> > > > > > > 00000000 T _CreateFileMappingW at 24> > > > 00000000 I > > > __imp__CreateFileMappingA at 24> > > > 00000000 T > > > _CreateFileMappingA at 24> > > > 00000000 I __imp__CreateFileA at 28> > > > > > > > 00000000 T _CreateFileA at 28> > > >> > > > C:\cygwin\lib\w32api>cd > > > \MinGW\lib> > > >> > > > C:\MinGW\lib>nm libkernel32.a | findstr > > > CreateFile> > > > 00000000 I __imp__CreateFileW at 28> > > > 00000000 > > > T _CreateFileW at 28> > > > 00000000 I > __imp__CreateFileMappingW at 24> > > > > > > 00000000 T _CreateFileMappingW at 24> > > > 00000000 I > > > __imp__CreateFileMappingA at 24> > > > 00000000 T > > > _CreateFileMappingA at 24> > > > 00000000 I __imp__CreateFileA at 28> > > > > > > > 00000000 T _CreateFileA at 28> > > >> > > > I think at least THREE > > > calling conventions should be supported --> > > > __cdecl, > > > __stdcall, __fastcall --> > > > but oh well. We can live without > > > __fastcall.> > > > Watcom has another calling convention, > > > "watcall", and they let you> > > > describe calling conventions > > > with #pragmas, neat.> > > >> > > > Thanks,> > > > - Jay> > > >> > > > > > > > Share life as it happens with the new Windows Live. Start > sharing! > > > > > >> >> >> > Make distant family not so distant with Windows > > > Vista? + Windows > > Live?. Start now!> > > > > > _________________________________________________________________ > > > > Watch ?Cause Effect,? a show about real people making a real > > > difference > > > > > > > > > Get the power of Windows + Web with the new Windows Live. Get > it now! > > > > > Watch ?Cause Effect,? a show about real people making a real > difference. Learn more > Watch ?Cause Effect,? a show about real people making a real > difference. Learn more From jayk123 at hotmail.com Wed Jan 16 04:29:40 2008 From: jayk123 at hotmail.com (Jay) Date: Wed, 16 Jan 2008 03:29:40 -0000 Subject: [M3devel] "crazy cross" In-Reply-To: <1DDFAB54-77B6-4593-B309-2C767D4F1FAC@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> <1DDFAB54-77B6-4593-B309-2C767D4F1FAC@cs.purdue.edu> Message-ID: Yeah, but many small bits of string are hard to put together into a useful ball. :) Platitude (I think is the word): Finding the right balance can be difficult, and it is neither one extreme nor the other. I don't like having to search so many different directories and files, I like more stuff readily at hand. And layering so many things together..do-cm3-std calls do-pkg calls syinfo calls cm3 can also be confusing, at least at first, but once known, I guess not, whereas smushed together code can remain confusing to maintain longer term. I'm the odd one out here though. I'd rather the current liberal BSD-ish licenses. I think multithreading would be good. I'm leary of what functionality is in cm3 vs. above. I think more should be in it. I actually like a model where you cd around and run some command it builds from the current directory and on down. But possibly escaping that part of the tree to rebuild dependencies, if they are out of date. Currently we have two choices: cd around to specific packages and run cmd cd to the specific scripts directory and do-pkg a specific list Kind of not not ideal somehow. Maybe all I really want is do-pkg to leave the cm3 command line options -- the local defines -- in its callers environment somehow for cm3 to pickup. So run do-pkg env and then cd around and run cm3. Anyway, much more bugs me than is important and these things are by far not the most important. I'd be happier merely to have quake provide move_file. :) And for it to batch up compilation of C perhaps. But then I get creedy and want to batch up cm3cg runs..back to where I was.. :) So -- dynamic linking is where people draw the line, but not one process running another? That seems dubious. Debugging-wise, there is this issue of "entry points". Where can I easily stop and resume? You are referring to cm3 outputs .ic (I think it is) files and then cm3cg can be run over them, easily, independently, without starting the pipeline all the way back before Modula-3 parsing. The entry points remain in the shipping product/configuration, even though they are "never" taken advantage of there..even if cm3 doesn't run cm3cg, the cost of mapping in a larger executable in a demand-paged environment is neglible, except as it pulls in dependencies on additional .dlls/.sos, though I expect (I will check), cm3cg's dependencies are light and a subset or equal to cm3's, so that's zero. I don't have an answer here, debugging entry points vs. optimized runtime. Debuggability and performance are very often open opposing forces (see the static_link thread :) ) Sometimes you can have the debug path as an option and the perf path by default, but of course, every fork, every if, (every conditional branch, conditional move (x86), predicated instruction (IA64) -- though I guess sometimes the conditions are the same) is another multiplication out of test cases and inevitably reduced coverage. - Jay > CC: m3devel at elegosoft.com> From: hosking at cs.purdue.edu> Subject: Re: [M3devel] "crazy cross"> Date: Tue, 15 Jan 2008 18:51:44 -0500> To: jayk123 at hotmail.com> > > On Jan 15, 2008, at 6:24 PM, Jay wrote:> > >> > I forgot some vaguely related things.> >> > Do people worry about optimizing away creating new processes?> > Perhaps.> > > Could m3cg be built as an .so/.dll? Probably.> > Tricky given gcc's nature.> > But, m3middle could be glued to gcc to build gcc's trees > directly...though I strongly prefer the current arrangement.> > > And ok license-wise?> > Um, no. FSF have been generally opposed to the way the Modula-3 > backend is a thin front-end veneer over gcc, since we get to use > their compiler without infecting M3 with the GPL/LGPL. Of course, it > would probably be preferable to have CM3 under the GPL/LGPL> > > Could m3cg be run once per package instead of once per source?> > Possibly, though right now m3cg does not use the gcc front-end > driver. To be honest, I prefer the separation of concerns between > m3middle and the gcc-based backend. It is much easier for debugging > and development.> > > gcc and cl both can be:> > cl -c foo.c bar.c> > gcc -c foo.c bar.c> > Currently in NT386GNU I depend on -o,> > gcc -c foo.c -o foo.obj> > Would need to handle that, not a big deal.> >> > Also, in the scheme below, either cm3.sh/cm3.cmd would have a > > switch to merely print the "real" cm3's path, or, just as well, > > sysinfo.sh et. al. would know how to find it, save that process.> >> > Furthermore -- multithreaded build?> >> > I believe, maybe absent bootstrapping, that cm3 could read "all" > > the m3makefiles, work out the dependency graph trivially, and build > > things in parallel. Bootstrappinging works too. It builds only what > > you say, in the right order. The Python scripts can implement this > > easily enough.> > I would strongly prefer to see functionality remain decomposed as it > currently is. Tangled balls of string are tough to understand, > maintain, and develop.> > >> > - Jay> >> > ----------------------------------------> >> CC: m3devel at elegosoft.com> >> From: hosking at cs.purdue.edu> >> Subject: Re: [M3devel] "crazy cross"> >> Date: Tue, 15 Jan 2008 08:47:13 -0500> >> To: jayk123 at hotmail.com> >>> >>> >> On Jan 15, 2008, at 2:00 AM, Jay wrote:> >>> >>> It looks like at least cm3 is "always" target-independent.> >>> Whatever target is defined to in cm3.cfg, if it is one of the built> >>> in known ones, cm3 will generate code for. Except maybe NT386,> >>> though it need not be -- cm3 could have both the .obj and "gcc> >>> tree" writing backends both linked into it and dynamically chose> >>> between them.> >>> >> Yes, the cm3 front-end will generate .mo/.io files for any target on> >> any other host. The gcc-based backend runs as a separate process> >> (there are license issues with linking the gcc-based backend directly> >> with the front-end).> >>> >>> Maybe it already does.> >>> cm3 operates at a fairly high level when using gcc, and the target> >>> specific stuff is just some data about the name of setjmp, the> >>> sizeof jmp_buf, etc..> >>>> >>> The "only" "problem" is then m3cg/as/ld/link.> >>> m3cg could be moved to $CM3_INSTALL/pkg/x/HOST/TARGET.> >>> >> True!> >>> >>> cm3, along with everything else, could be $CM3_INSTALL/pkg/x/HOST> >>> leaving $CM3_INSTALL/bin/cm3 that is sh and $CM3_INSTALL/bin/cm3.py> >>> or cm3.cmd that calls out to cm3.> >>> >> Possibly.> >>> >>> "Fixing" as/ld, well, I don't suppose they tend to be target> >>> neutral do they? You'd have to import them like gcc and build them> >>> n times. Gaining a much slower build, much larger tree.> >>> >> Indeed.> >>> >>> I suppose anyone could do this themselves, and change cm3.cfg> >>> appropriately. Doing things "officially" this way for one "big"> >>> distribution, probably folks would not go for.> >>> >> This is how bootstraps to other targets typically go: cm3 *.m3-> >>> *.mo. Copy .mo files to target. Build cm3cg for target. cm3cg> >> *.mo->*.ms as *.ms->*.o ld *.o->libs/execs.> >>> >>> >>>> >>>> >>> - Jay> >>>> >>>> >>>> >>> From: jayk123 at hotmail.com> >>> To: m3devel at elegosoft.com> >>> Subject: "crazy cross"> >>> Date: Sat, 5 Jan 2008 01:22:13 +0000> >>>> >>> You've all heard of "Canadian cross"?> >>>> >>> It is cross-building a cross-compiler.> >>> I'm sitting in Windows. I'm going to build a compiler that is going> >>> to run on Linux that is going to target Solaris.> >>> For one example.> >>>> >>> You've all seen that Apple has switches like so:> >>>> >>> gcc -arch i386 ppc ppc64 x86_64 hello.c> >>> and poof out comes a binary that runs natively on four architectures> >>>> >>> I don't like the "inconvenience" of non cross systems and having to> >>> have all the machines/OSes just to build the binaries.> >>> I realize that you hit the wall if you actually want to test the> >>> results. So cross building only gets so much.> >>> Of course I also don't want to multiply out build times for tools...> >>>> >>> Ok, well what is the possibility of:> >>>> >>> cm3 -target NT386> >>> cm3 -target NT386 -target PPC_DARWIN> >>>> >>> ? In my crazy imagination, you have:> >>>> >>> \cm3\bin\cm3.cmd> >>> %~dp0..\libexec\%processor_architecture%\%TARGET%\cm3.exe %*> >>>> >>> \cm3\bin\cm3> >>> #!/bin/sh> >>> dirname(dirname($0))/libexec/`uname whatever`/$TARGET/cm3 $@> >>>> >>> Thus it becomes POSSIBLE to have an n x m matrix, host x target,> >>> and be able to build> >>> "anything" from one environment.> >>>> >>> Actually the targets could all be merged into one .exe or> >>> be .dll/.sos.> >>> Except the code isn't setup for that.> >>>> >>> Interesting?> >>>> >>> I guess the hard part is the C code and linking?> >>> The Modula-3 stuff is already setup to do most of this?> >>> (partly by virtue of all that header rewriting that I labeled> >>> sleazy)> >>>> >>> - Jay> >>>> >>>> >>>> >>> Share life as it happens with the new Windows Live. Start sharing!> >>>> >>> Share life as it happens with the new Windows Live. Start sharing!> >>> >> > _________________________________________________________________> > Watch ?Cause Effect,? a show about real people making a real > > difference.> > http://im.live.com/Messenger/IM/MTV/?source=text_watchcause> _________________________________________________________________ Watch ?Cause Effect,? a show about real people making a real difference. http://im.live.com/Messenger/IM/MTV/?source=text_watchcause -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Wed Jan 23 03:45:43 2008 From: jayk123 at hotmail.com (Jay) Date: Wed, 23 Jan 2008 02:45:43 -0000 Subject: [M3devel] platform/build_dir is a big tuple? In-Reply-To: <2AB0D273-C3B8-4D46-BCC1-4D032692DCB0@cs.purdue.edu> References: <20080122142922.k73w5es5j4gckso4@mail.elegosoft.com> <2AB0D273-C3B8-4D46-BCC1-4D032692DCB0@cs.purdue.edu> Message-ID: Two of the types are dead and the calling convention doesn't matter. If the function has any parameters, a LOOPHOLE is needed, if it has no pararemeters, as the types are declared, the calling convention has no affect. So fixing the warnings are trivial and will be done momentarily. - Jay From: jayk123 at hotmail.comTo: hosking at cs.purdue.edu; wagner at elegosoft.comCC: m3devel at elegosoft.comSubject: RE: [M3devel] platform/build_dir is a big tuple?Date: Wed, 23 Jan 2008 02:25:39 +0000 > Precisely why I don't like many of the recent changes. I don't want > to build Windows interfaces and gorp for a non-Windows platform. It is *just* types. (I didn't read the code entirely, but it appears so).Other than the three or so types marked WINAPI, which I could see about moving/removing,*types* work fine across architectures.You could produce and consume these types in pure Modula-3 on any platform.That kernel32.dll happens to traffic in them is just coincidence.Except maybe those function pointer types with WINAPI.What's wrong with that?As long as I can fix the warnings I think these should say.Not that there aren't lots of warnings in the build already, but I don't like having any. - Jay > From: hosking at cs.purdue.edu> Date: Tue, 22 Jan 2008 12:54:04 -0500> To: wagner at elegosoft.com> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] platform/build_dir is a big tuple?> > > On Jan 22, 2008, at 8:29 AM, Olaf Wagner wrote:> > > All this may be useful during development, but it is not really> > useful for a software distribution to our users, I think.> >> > Nobody will understand it :-( We need to keep things more simple.> >> > We don't need to support everything out of the box. Instead, we should> > offer some sensible default combinations of everyhing you describe.> >> > First of all: we don't distribute cross compilers (at least until > > now).> > This is a special topic reserved for adding new platforms.> > Precisely why I don't like many of the recent changes. I don't want > to build Windows interfaces and gorp for a non-Windows platform. > Jay, can you *please* back these changes out?> > >> > Runtime and compilers used do not necessarily need to be distinguished> > by target or build dir, in many cases different cm3.cfg may suffice.> >> > Until now, threading models are also no choice that needs to be> > visible at this level. There's one default model for every target,> > and the user can change it by recompiling.> >> > And if we should really agree that changing the target naming scheme> > is a good idea, we should> >> > o use a systematic one with not more than 4 elements (better still,> > 3 (e.g. --))> > o don't use cryptic abbreviations that will confuse most people> >> > Just my 2 cents,> >> > Olaf> >> > Quoting Jay :> >> I'm still torn over that any NT386 target could have a choice of > >> three threading models (win32, pthread, vtalarm), two windowing > >> libraries (ms, x), two (three) compilers (ms, mingwin, cygwin), > >> two (three) linkers (ms, mingwn, cygwin), various runtimes (msvc > >> various versions, cygwin, mingwin (discouraged)) etc.> >>> >> Appending a short string of unreadable bits to BUILD_DIR is very > >> temptingin order to easily generate and test the combinatorial > >> possibilities.> >>> >> backend: 0 integrated, 1 gcc already a setting (with four values)> >>> >> ccompiler/linker: 0 ms, 1 gcc (these could be split, and could > >> allocate more bits...) maybe 00 ms, 01 cygwin, 10 ming maybe > >> define enum up front that allows for watcom, metrowerks, > >> digitalmars, llvm etc.> >> maybe use a decimal digit for all these, and 0 is reserved, maybe.> >>> >> threading: 0 win32, 1 pthreads drop vtalarm, or use two bits?> >>> >> windowing: 0 ms, 1 x> >>> >> cruntime: 0 ms, 1 cyg There is also a ming runtime, discouraged > >> There also really N ms runtimes, ming offers several: > >> msvcrt.dll, msvcr70.dll, msvcr71.dll, msvcr80.dll, > >> msvcr90.dll... but jmpbuf presumbly doesn't change again could > >> allocate multiple bits..> >>> >> cruntime I guess determines oSTYPE Win32 or Posix, thoughit loses > >> its meaning mostly, and X vs. not-X is usually decide the same...> >>> >> The three most common combinations: 00000 -- NT386 11111 -- > >> NT386GNU 11000 -- NT386MINGNU> >>> >> but several others would work 11101 -- cygwin with native > >> windowing 11011 -- cygwin with native threads 11001 -- cygwin > >> with native threads and native windowing> >> BUILD_DIR would be NT386-$(config)as a special case perhaps, the > >> three commoncases could be translated to the above strings.> >>> >> But the underlying implementation would be a few bools/enums,and > >> iterating through them would be easy, while special casingand > >> skipping deemed invalid combinations, like ms runtime and > >> pthreads,and possibly ms runtime and x windows.> >> Really, it might surprise folks, but really, basically every > >> single combination works.> >> Compilers are very independent of headers and libs and headers > >> and libs are very independent of compilers, aside from a few > >> language extensions like __stdcall. You can generally mix > >> runtimes in the same process, just as you can mix them on the > >> same machine, you just need to be careful about what you pass to > >> what. If you call fopen, be sure pass the result back to the > >> matching fclose, malloc/free, etc. Startup code, to the extent > >> that it matters, might be a problem, but really, just avoid C++ > >> globals with constructors/destructors anyway, they are always a > >> problem. Modula-3 has its own startup code, and if you were to > >> write "main" in C and link in Modula-3 static .libs, that > >> probably doesn't work...might actually be better to play into > >> whatever the platform's C++ constructor story is, as problematic > >> as they (probably always?) are -- i.e. unpredictable/hard-to- > >> control ordering.> >>> >> (bad editing...and maybe use hex for compression..)> >>> >> Bringing back cminstall is almost interesting, to promptthe user, > >> or probe their system, though Quake/cm3 can probe at runtime.if > >> os == windows_nt system_cc | findstr version | findstr gcc > >> else system_cc | findstr visual c++else system_cc | grep > >> version | grep gcc else system_cc | grep visual c++end> >>> >> inefficient.> >>> >> anyway, I'll merge current NT386GNU into NT386 and make it > >> chosehow to compile/link which are the main variables today.> >> and then decide about cygwin, but probably do like the above, > >> sinceit'll totally share code with NT386 except the naming > >> conventionsand the removal of the -mno-cygwin switch..> >>> >> I know this seems overly complicated, but it should be > >> exposableeasily enough to users by hiding the choices, presenting > >> three basic ones,and still allow all the obvious and perhaps > >> useful knobs, and iterating throughthe combinations, without > >> creating a combinatorial explosion of source filesor Modula-3 or > >> Quake code.> >> ...Jay> >>> >>> >> From: jayk123 at hotmail.comTo: m3devel at elegosoft.comDate: Tue, 22 > >> Jan 2008 10:48:56 +0000Subject: Re: [M3devel] platform/build_dir > >> is a big tuple?> >>> >>> >> Final answer? I played around with this but just can't accept > >> platforms/build_dirs like: ntx86msmsmscm3msn > >> ntx86gccgcccm3cgmsn ntx86gccgcccm3cgxn ntx86-gggggmn ntx86- > >> ggixn ntx86_mmmimmOk, I have one more name here, and then a bit > >> of a change, or a stronger statement of something I had already > >> said.NT386MINGNUOk, I think we (me!) are confusing host and > >> target, MOSTLY.And cm3 might not have them quite divided > >> appropriately.What is a "host"? What is a "target"?MinGWin and > >> Visual C++ output similar results, targetingthe same runtime > >> (usually), threading library, windowing library.There is a chance > >> for exception handling to diverge however.Well, speaking of > >> Visual C++ the C/C++ compiler and MinGWinthe gcc environment, > >> yes, very different, not interoperable.MinGWin uses what gcc > >> calls "sjlj" -- setjmp/longjmp exceptions.Very inefficient. But > >> heck, gcc doesn't support __try/__except/__finally,only C++ > >> exceptions, and interop of C++ is often not great,what with name > >> mangling and all.NT386GNU's OUTPUT uses a different runtime, > >> unless you trim dependencies, possibly a different threading > >> library, possibly a different windowing library. All this > >> probably configurable. Again exception handling is a sore point > >> in that it is the primary C runtime dependency of Modula-3. If > >> you use Cygwin but say -mno-cygwin, that means you are targeting > >> NT386. (and don't use pthreads or X Windows; behavior of > >> exceptions/setjmp/longjmp TBD -- really, need to not use the - > >> mno-cygwin headers in that case; I'll check).Perhaps m3core.dll > >> should export m3_setjmp/m3_longjmp..Either one can do a cross > >> build to the other.Two cm3.exes, two sets of outputs, that either > >> can produce.NT386 can use gcc or the integrated backend. And the > >> gcc it uses can be MinGWin or Cygwin. (theoretically and probably > >> soon reality) NT386GNU can use either as well! (also currently > >> theory, but a real possibility) It isn't GNU tools, it is GNU > >> runtime.One small area with cm3 might fall down just slightly is > >> that of cross builds where host and target have different > >> naming conventions. -lfoo vs. foo.lib, foo.o vs. foo.obj are an > >> aspect of the host and I vaguely recall that cm3 ties naming > >> convention to ostype. The appending of .exe is a target > >> characteristics, but the others are not really. Naming > >> convention is really a host thing and not a target thing.The > >> config files are a mix of host and target information, mostly > >> actually host, except for the one line that says TARGET. Most of > >> the target variation is in cm3, which always can do any, and > >> cm3cg (which might be nice to be similar, but that's another > >> matter and not likely to ever change, except when AMD64 is the > >> last architecture standing. :) )If Windows had "rpath", then SL > >> would be split between HOST_SL and TARGET_SL.As it stands, SL is > >> HOST_SL.Consider as well the various versions of Visual C++.They > >> output mostly the same, very interoperable.Consider optimization > >> switches. Host or target?Consider version of gcc or Visual C++? > >> Host or target?Well, inevitably, the host has an affect on the > >> target. If not the for the host, the target would not even > >> exist. Bugs in the host produce bugs in the target. etc.(And > >> realize that Cygwin runs on top of an OS built witha Microsoft > >> compiler, so really there is interop, but sometimes through a > >> layer.) So there's a risk of saying there is six+ combinations. > >> (host cygwin, host mingwin, host native) x (target nt386, target > >> nt386gnu) But generally the host is assumed not a factor. I > >> guess "LIBC" could be seperated into several options...You could > >> actually have code that needs one runtime or another, and they > >> couldlink together, depending on what they do.. This is something > >> I don't know if cm3 handles, or anything I have seen. I should be > >> able to build a static .lib, that includes some C code, that > >> imbues its clients with build time dependencies. Well, I guess > >> #pragma comment(linker) is this.So the next tasks are roughly: > >> Merge my NT386 and NT386GNU files. Switching on a variable such > >> as backend mode. Introduce a "new" (old) NT386GNU file, > >> perhaps more like what was already there. Change NT386GNU back > >> to Posix. Build NT386GNU. oh, one more point...while these are > >> two targets from cm3's point of view, they are PROBABLY the same > >> target to cm3cgand so only one is needed. I have to check if > >> configure differentiates between i686-pc-cygwin and i686-pc- > >> mingwin...but I guess it should...It might actually be profitable > >> to have two bloated cm3cg.exe's.And they should ship to \cm3\pkg > >> \m3cc\target\host or host\target and cm3 should know which to > >> run.Blech..four of them when one would suffice?The detail being > >> mainly what the paths to .libs look like, unfortunate.Possibly > >> cm3 can bridge this gap using that "broken" feature that symlinks > >> libs into the target directory,using NTFS hard links, if > >> installroot and root are on the same volume... (or symlinks on > >> Vista).Or maybe convert the paths as appropriate, hacky, but > >> saves an extra cm3cg.exe which is good to avoid. (all the more > >> reason to lump all targets into one file, so that the host x > >> target matrix collapses to just one axis, host; andthen you can > >> write stuff in Perl/Python/Java/C# to collapse that to just one, > >> except for the underlying runtime/interpreter...) Oh, cm3cg isn't > >> the issue. It is always sitting in the correct directory and > >> reads one file and writes one file, no slashes.The issue is gcc > >> as the linker. Again, this is a host issue..and cm3 or the config > >> file definitely should do the translation. - Jay> >>> >>> >> From: jayk123 at hotmail.comTo: m3devel at elegosoft.comDate: Mon, 21 > >> Jan 2008 23:01:44 +0000Subject: [M3devel] platform/build_dir is a > >> big tuple?> >>> >> 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> >> >> >> > -- > > Olaf Wagner -- elego Software Solutions GmbH> > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, > > Germany> > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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". 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 Sun Jan 20 04:42:02 2008 From: mika at async.caltech.edu (Mika Nystrom) Date: Sun, 20 Jan 2008 03:42:02 -0000 Subject: [M3devel] pixmap problem In-Reply-To: Your message of "Sat, 19 Jan 2008 17:54:00 +0100." <235688.77597.qm@web27110.mail.ukl.yahoo.com> Message-ID: <200801200341.m0K3feKM023564@camembert.async.caltech.edu> It works great on NT386GNU, PM3/Klagenfurt, as well, without the build_standalone. Mika "Daniel Alejandro Benavides D." writes: >--0-1095273535-1200761640=:77597 >Content-Type: text/plain; charset=iso-8859-1 >Content-Transfer-Encoding: 8bit > >Hi: >The TestPixmap does show a nice battery on LINUXLIBC6, Ubuntu Gutsy 2.6.22-14-386, 32 bits machine. > >Thanks > > >Jay wrote: .hmmessage P { margin:0px; padding:0px } body.hmmessage { FONT-SIZE: 10pt; FONT-FAMILY:Tahoma } I can repro > the two different behaviors on XP. > I was going to try on PPC_DARWIN but I guess Tony's info suffices. > > I tried rolling hand.c back to before I changed (months/year ago), since it is involved in bit twiddling, no change, phew. > > Debugging here is a big humungous pain. > NT386 has good stacks and line numbers, but no locals or type info, I'd really sometime like to get Codeview info into those .objs...I think it > is documented well enough, but still not necessarily easy, or maybe have a C generating backend partly for this reason (and to bring up more ta >rgets, using native tools), and function calls in disassembly I think don't resolve; NT386GNU can't yet build this, though it will soon, but I'm > not familiar with gdb and there appears to be no type info. I'm building m3gdb right now, I don't know if it will work, I hope it has type info >, and I'm not familiar with the relevant code. In gdb I struggle just to view bytes in memory, add numbers to addresses and see those, etc. I th >ink for MY problem, I'm going to link in C code to dump the structs. There is tracing code and I enabled it, but even it crashes in Text_Length. > At least MY problem crashes, hopefully near the problem, whereas your problem goes all the way through to completion with > no stopping to hint where the problem is. Darn it. :) on the mock rudeness and :( on the lack of a crash. > > You write the bundle out and it matches, so that doesn't rule out bundles as being the problem? (darn) > And bundles look pretty simple, a bundle is just a generated source file with a constant in it. > Maybe newline problems? That wouldn't make sense. I just downloaded some program that might let me separately view the ppm, maybe it'll reveal >something. > > The bad behavior has like regularly spaced solid color veritical bars a few pixels side across the whole picture, and regularly spaced vertical > stripes from the correct picture alternating with that. Perhaps someone with ppm/bitmap/graphics experience has seen this behavior and it resul >ts from some common pixmap mismanagement we could look for? > > I have to say this is very surprising. > > I always wondered, and now I pretty much assume -- Modula-3 never imports/exports data in its dynamic linking, right? It alway imports/exports >functions, right? > On Windows, functions have an optional optimization, but data must be handled differently at compile time if it is going to be dynamically impo >rted. > For functions, if you don't apply the optimization at compile time, the linker will just generate a single instruction thunk instead. > > That is, given a symbol Foo, there is a symbol __imp__Foo that is a pointer to the actual foo in another .dll/.so. > The loader only patches pointers, one per import if you build your .dll correctly, it doesn't patch instructions or code strewn throughout a .d >ll, just one contiguous array of pointers. MAYBE they don't have to be contiguous for each .dl you import from. > > That is, if call msvcrt!fopen, msvcrt!fclose, kernel32!Sleep, my .dll/.exe typically has an array: > > pointer to msvcrt!fopen > pointer to msvcrt!fclose > null > pointer to kernel32!Sleep > > But perhaps kernel32.dll's pointers and msvcrt.dll's pointers need not be adjacent. > > So, going back, my point/question is that, if the compiler knows the function is imported, it can call through __imp__Foo instead of calling Fo >o. > But if it calls Foo and you import Foo, the linker will create the function Foo that just jmps through __imp__Foo. > That doesn't work for data though. There's no ability to intervenve like that. > So for imported data, the compiler must generated a read and dereference of the pointer __imp__Foo for accesses to Foo, if Foo is to be importe >d. > Data imports may be faster when appropriate, but for this reason, I'd say they aren't worth it. > And for this reason, I HOPE Modula-3 never imports/exports data. > > Oh, you could, for data, always reference the pointer __imp_Foo, and if non materializes, create one. > However that would suck perf in order to make an uncommon case work. > I hope Modula-3 doesn't do that either. :) > Though I guess since this global data in question...maybe it is rare??? > > Later, > - Jay > > > >--------------------------------- > > > From: hosking at cs.purdue.edu >> Date: Sat, 19 Jan 2008 03:09:47 -0500 >> To: rcoleburn at scires.com >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] pixmap problem >> >> Looks fine to me on I386_DARWIN. >> >> On Jan 19, 2008, at 12:31 AM, Randy Coleburn wrote: >> >> > >> > > > >--------------------------------- >Need to know the score, the latest news, or you need your Hotmail?-get your "fix" Check it out. > > >--------------------------------- > >Web Revelaci?n Yahoo! 2007: > Premio Favorita del P?blico - ?Vota tu preferida! >--0-1095273535-1200761640=:77597 >Content-Type: text/html; charset=iso-8859-1 >Content-Transfer-Encoding: 8bit > >Hi:
The TestPixmap does show a nice battery on LINUXLIBC6, Ubuntu Gutsy 2.6.22-14-386, 32 bits machine.

Thanks


Jay &l >t;jayk123 at hotmail.com> wrote:
I can repro the two > different behaviors on XP.
I was going to try on PPC_DARWIN but I guess Tony's info suffices.
 
I tried rolling hand.c back to > before I changed (months/year ago), since it is involved in bit twiddling, no change, phew.
 
Debugging here is a big humungous&nb >sp;pain.
NT386 has good stacks and line numbers, but no locals or type info, I'd really sometime like to get Codeview info into those .objs. >..I think it is documented well enough, but still not necessarily easy, or maybe have a C generating backend partly for this > reason (and to bring up more targets, using native tools), and function calls in disassembly I think don't resolve; NT386GNU can't yet bui >ld this, though it will soon, but I'm not familiar with gdb and there appears to be no type info. I'm building m3gdb right now, I don't know if >it will work, I hope it has type info, and I'm not familiar with the relevant code. In gdb I struggle just to view bytes in memory, add numbers >to addresses and see those, etc. I think for MY problem, I'm going to link in C code to dump the structs. There is tracing code and I enabled it >, but even it crashes in Text_Length. At least MY problem crashes, hopefully near the problem, whereas your problem goes all the way through to >completion with no stopping to hint where the problem is. Darn it. :) on the mock rudeness and :( on the lack of a crash.
 
You wri >te the bundle out and it matches, so that doesn't rule out bundles as being the problem? (darn)
And bundles look pretty > simple, a bundle is just a generated source file with a constant in it.
Maybe newline problems? That wouldn't make sense. I just downl >oaded some program that might let me separately view the ppm, maybe it'll reveal something.
 
The bad behavior has like regularly s >paced solid color veritical bars a few pixels side across the whole picture, and regularly spaced vertical stripes from the correct picture alte >rnating with that. Perhaps someone with ppm/bitmap/graphics experience has seen this behavior and it results from some common pixmap mismanageme >nt we could look for?
 
I have to say this is very surprising.
 
I always wondered, and now I pretty much assume -- Mo >dula-3 never imports/exports data in its dynamic linking, right? It alway imports/exports functions, right?
On Windows, functions have an op >tional optimization, but data must be handled differently at compile time if it is going to be dynamically imported.
For > functions, if you don't apply the optimization at compile time, the linker will just generate a single instruction thunk instead.
 
> That is, given a symbol Foo, there is a symbol __imp__Foo that is a pointer to the actual foo in another .dll/.so.
Th >e loader only patches pointers, one per import if you build your .dll correctly, it doesn't patch instructions or code strewn throughout a >.dll, just one contiguous array of pointers. MAYBE they don't have to be contiguous for each .dl you import from.
 
That is, if cal >l msvcrt!fopen, msvcrt!fclose, kernel32!Sleep, my .dll/.exe typically has an array:
 
pointer to msvcrt!fopen
pointer to msvcrt >!fclose
null
pointer to kernel32!Sleep
 
But perhaps kernel32.dll's pointers and msvcrt.dll's pointers need not be adjacent >.
 
So, going back, my point/question is that, if the compiler knows the function is imported, it can call > through __imp__Foo instead of calling Foo.
But if it calls Foo and you import Foo, the linker will create the function Foo that just jmps t >hrough __imp__Foo.
That doesn't work for data though. There's no ability to intervenve like that.
So for imported data, the compiler mus >t generated a read and dereference of the pointer __imp__Foo for accesses to Foo, if Foo is to be imported.
Data import >s may be faster when appropriate, but for this reason, I'd say they aren't worth it.
And for this reason, I HOPE Modula-3 never imports/expo >rts data.
 
Oh, you could, for data, always reference the pointer __imp_Foo, and if non materializes, create one.
However that >would suck perf in order to make an uncommon case work.
I hope Modula-3 doesn't do that either. :)
Though I guess since this global data > in question...maybe it is rare???
 
Later,
 - Jay



> From: > hosking at cs.purdue.edu
> Date: Sat, 19 Jan 2008 03:09:47 -0500
> To: rcoleburn at scires.com
> CC: m3devel at elegosoft.com
> >Subject: Re: [M3devel] pixmap problem
>
> Looks fine to me on I386_DARWIN.
>
> On Jan 19, 2008, at 12:31 AM, Randy Col >eburn wrote:
>
> > <TestPixmap.zip>
>


Need to know the score, the latest news, or you need your Hotm >ail?-get your "fix" Check it out.

> > >


Web Revelaci?n Yahoo! 2007:
Premio Favorita del P?blico - ?Vota tu preferida! >--0-1095273535-1200761640=:77597-- From rcoleburn at scires.com Thu Jan 24 03:51:41 2008 From: rcoleburn at scires.com (Randy Coleburn) Date: Thu, 24 Jan 2008 02:51:41 -0000 Subject: [M3devel] new problem on NT386 In-Reply-To: <20080123232310.5znrlsr5ywwgc4o0@mail.elegosoft.com> References: <4796B970.1E75.00D7.1@scires.com> <4796D0BA.1E75.00D7.1@scires.com> <20080123123937.onc4m6fa4gg8ogg0@mail.elegosoft.com> <479734AB.1E75.00D7.1@scires.com> <20080123193216.4hun5uus8hwksw88@mail.elegosoft.com> <47975558.1E75.00D7.1@scires.com> <20080123221001.8pbvhkjdc8408w80@mail.elegosoft.com> <47976D5F.1E75.00D7.1@scires.com> <20080123232310.5znrlsr5ywwgc4o0@mail.elegosoft.com> Message-ID: <4797B66F.1E75.00D7.1@scires.com> Olaf: Thanks. This is looking very promising now. Regards, Randy >>> Olaf Wagner 1/23/2008 5:23 PM >>> Quoting Randy Coleburn : > Olaf: > > I grabbed the new QMachine via cvs and rebuilt & shipped the m3quake > package, then rebuilt reactor (now cm3_ide) to take advantage of it. I > replaced the exec calls with cm3_exec(). > > At first glance, things were working better in that the output is now > going back to the browser. Great! > > But, when I tried to compile a simple "HelloWorld" program, I ran into > some errors. See attached PDF file. Does any of this make sense to > you? > > Note that this same HelloWorld program was compiling before the > QMachine change, its just that the output went to the wrong window. It seems I've made a mistake by forgetting to initialize the std file handles. Please try again, Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com ( http://www.elegosoft.com/ ) | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Fri Jan 25 05:44:41 2008 From: jayk123 at hotmail.com (Jay) Date: Fri, 25 Jan 2008 04:44:41 -0000 Subject: [M3devel] INSTALL_ROOT and PKG_USE in cm3.cfg In-Reply-To: <479907A8.1E75.00D7.1@scires.com> References: <4798DEB8.1E75.00D7.1@scires.com> <4798EFAE.1E75.00D7.1@scires.com> <4798FE0E.1E75.00D7.1@scires.com> <479907A8.1E75.00D7.1@scires.com> Message-ID: 1) the general user population could revert back to cminstall; nobody else complained except me (a common occurence), and Olaf did improve it; I'd have to deign to putting together such a distribution yuck. Perhaps when a nice GUI installer comes along it won't feel so bad. 2) Again, can you make the stuff you are working on available? To just some people? path() returns the directory of the currently executing Quake code. And in this case, the file is in the directory that contains cm3.exe, so it is cm3.exe's directory, which we know is INSTALLROOT\bin, so go up one with .. and we have INSTALLROOT. It's a little unsightly to have ".." in all the resulting paths, but I think it is worth it. It could be fixed in a number of ways. 1) add a function PathDotDot or PathUp to cm3 2) more generally add a function PathCanonicalize to cm3. Or heck, move more and more of this stuff into cm3. I asked about this recently -- what are the requirements for compatibility with older tools. It is that unanswered, and presuming "the worst", besides my persistant distaste for Modula-3, that keeps me writing Quake code.. - Jay Date: Thu, 24 Jan 2008 21:48:28 -0500From: rcoleburn at scires.comTo: jay123 at hotmail.com; jayk123 at hotmail.comCC: m3devel at elegosoft.comSubject: Re: [M3devel] INSTALL_ROOT and PKG_USE in cm3.cfg Jay: I've already edited my version of cm3.cfg to make it work for me. I don't know what the path() function does. The path() function is only used in the following code: if not defined("INSTALL_ROOT") if not equal ($INSTALLROOT, "") INSTALL_ROOT = $INSTALLROOT else INSTALL_ROOT = (path() & "\\..") endend Since this code is not executed when I define INSTALL_ROOT as "c:\\cm3", there is no need to remove it for my use. I've already confirmed that the other variables I need get set correctly inside CM3-IDE/Reactor once the INSTALL_ROOT is set properly. Note that a bunch of variables inside cm3.cfg depend on INSTALL_ROOT. I'm still want to find a solution for the general user population. Regards, Randy>>> Jay 1/24/2008 9:23 PM >>>Randy, don't worry, whatever you do, I'll be able to recover from. Just try editing your \cm3\bin\cm3.cfg file to say INSTALLROOT="c:\cm3" or whatever.Remove the path() function as a variable.See what happens. Maybe it's the problem, maybe not. It is something that I changed, and is worth trying the old way. Use write() and error() to print the other variables. Can you make the stuff you are working on available? To just some people? - Jay Date: Thu, 24 Jan 2008 21:07:29 -0500From: rcoleburn at scires.comTo: jay123 at hotmail.com; jayk123 at hotmail.comCC: m3devel at elegosoft.comSubject: Re: [M3devel] INSTALL_ROOT and PKG_USE in cm3.cfg Jay: Not sure exactly what you mean by:>I'm not sure what versions of cm3 have path(). I did think I saw it missing the other day. I assume you are not referring to the path env variable. Is this some built-in quake function or a function you have written in quake? The version of cm3.cfg that I am using is the one that *you* put in the minimal binary installation for windows. Reactor does indeed "run" the cm3.cfg in that it uses quake to load and interpret this file. What is the significance of doing the copy you suggest below? >In terms of my workflow, you can go ahead and copy NT386 to the config-no-install directory. I'll survive. I'm not trying to be obtuse here. It's just that you have been working on the windows distribution and all these scripts etc for a while now. I don't want to mess up anything you are doing and I know I don't have a deep understanding of all this, so I am reluctant to change anything like cm3.cfg for my needs. My goal is to make the CM3-IDE (old Reactor) available to everyone. As I said before, it does "run" the cm3.cfg and it needs to use this somehow to come up with a valid "PKG_USE" which should point to the "pkg" folder inside the cm3 installation root. Regards, Randy >>> Jay 1/24/2008 8:33 PM >>>I'm not sure what versions of cm3 have path(). I did think I saw it missing the other day.That could be your problem.m3cgcat also doesn't like my config file, it wants to open it to find TARGET, not sure it uses it at all, but it wants it. When I run mcgcat, I first put back a TARGET line in my cm3.cfg. And then remove it.This is very related.I would suspect that whoever reads the files MIGHT find it acceptable to RUN them.Running them doesn't mean compiling or linking or anything, those are functions that the "host" would chose to call or not. But toplevel can have arbitrary code so maybe this is not great. Reactor is a persistant web server though, right? It should be ok "running" the file, esp. since it doesn't start often. The "normal" alternative that other folks use is to run cminstall, which I find all but useless. In terms of my workflow, you can go ahead and copy NT386 to the config-no-install directory. I'll survive. Randy you should try debugging stuff. Quake is readily debuggabe through printing. if defined("path") write("path is defined") write("path is " & path())else write("path is not defined")enderror("") I put in error so I stop after my printing and don't go and build stuff when my intent was just to run a snippet of Quake. - Jay Date: Thu, 24 Jan 2008 20:06:09 -0500From: rcoleburn at scires.comTo: jay123 at hotmail.com; jayk123 at hotmail.comCC: m3devel at elegosoft.comSubject: RE: [M3devel] INSTALL_ROOT and PKG_USE in cm3.cfg Jay: That's the reason I asked before making a change. I don't want to break or mess up what you are doing. I can get around the problem easily for me. I just remove the comment from the %INSTALL_ROOT="c:\\cm3" and "everything" is ok. I'm hoping we can come up with a way that works for everyone. Once the CM3_IDE (formerly known as Reactor) package is in the repository and part of the standard distribution, it would be best if folks don't have to go around editing cm3.cfg to make it work properly. Now, you are saying your way is more automatic and portable. I like these words. Is there a way we can set something in cm3.cfg that I can key off of for CM3_IDE/Reactor? I don't mind changing the code to accommodate. The big thing for CM3_IDE/Reactor, is that it needs to know where to look for the cm3 installation because it has to find all of the subdirs, like doc, examples, etc. BTW, I still don't see why all this "works" since I am getting "\.." as my INSTALL_ROOT. Regards, Randy>>> Jay 1/24/2008 7:24 PM >>>Blech. My way is more automatic and "portable" in the sense that you can move installations around and they keep working. As well, with my way, you just extract an archive and go, no setup/cminstall, no editing of the cm3.cfg file, just set %PATH% and run vcvars, and vcvars I think I can remove the need for. path() is a builtin Quake function that returns the directory of the currently being run Quake code. But yet Reactor.To unblock yourself, remove my code, add back the commented out, fix the path to match your particular install, don't submit the file. Perhaps move the current checked in file over to the config-no-install directory and then put config's file back in the old style, that requires running cminstall. My workflow will keep working, since it probes for config-no-install first. - Jay Date: Thu, 24 Jan 2008 18:53:48 -0500From: rcoleburn at scires.comTo: jay123 at hotmail.comCC: m3devel at elegosoft.comSubject: [M3devel] INSTALL_ROOT and PKG_USE in cm3.cfg Jay: The cm3.cfg that comes with your minimal binary installation on Windows (NT386) has the following lines: ----------------------------------------- % INSTALL_ROOT = BEGIN_CONFIG% "Where should CM3 be installed?"% 7 %-- user specified install root% END_CONFIG % INSTALL_ROOT = "c:\\cm3" if not defined("INSTALL_ROOT") if not equal ($INSTALLROOT, "") INSTALL_ROOT = $INSTALLROOT else INSTALL_ROOT = (path() & "\\..") endend BIN_INSTALL = INSTALL_ROOT & "\\bin" % executablesLIB_INSTALL = INSTALL_ROOT & "\\lib" % librariesPKG_INSTALL = INSTALL_ROOT & "\\pkg" % packagesDOC_INSTALL = INSTALL_ROOT & "\\doc" % documentsEMACS_INSTALL = INSTALL_ROOT & "\\elisp" % emacs lisp codeMAN_INSTALL = INSTALL_ROOT & "\\man" % man pagesHTML_INSTALL = INSTALL_ROOT & "\\www" % public hypertext %% On some systems (e.g. AFS) you must install public files in a different% place from where you use them. If that is the case for your system,% specify the "use" location here, otherwise leave them alone.%%USE_ROOT = INSTALL_ROOTBIN_USE = BIN_INSTALL % executablesLIB_USE = LIB_INSTALL % librariesPKG_USE = PKG_INSTALL % packages ----------------------------------------- Notice that the lines for INSTALL_ROOT and USE_ROOT are commented out. The Reactor program is coded to grab several variables out of cm3.cfg. For example, build_dir := M3Config.Get ("BUILD_DIR"); system_root := M3Config.Get ("PKG_USE"); doc_root := M3Config.Get ("DOC_INSTALL"); initial_browser := M3Config.Get ("INITIAL_CM3_IDE_BROWSER"); initial_editor := M3Config.Get ("INITIAL_CM3_IDE_EDITOR"); What is happening on my installation is that PKG_USE winds up being "\..\PKG". This is not a valid path and it is causing all sorts of trouble for Reactor. The reason it is getting set this way is that the ELSE branch of the, if not defined("INSTALL_ROOT"), is getting executed resulting in INSTALL_ROOT=\.. I'm not sure why this is coded this way. How do you suggest this should be repaired? Note, I have not checked all of the cm3.cfg variants for the other target platforms, but in order for reactor to work properly, it must be able to find a valid "PKG_USE" in the cm3.cfg. Regards, Randy 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. Play now! 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 rodney.bates at wichita.edu Wed Jan 30 04:15:54 2008 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Wed, 30 Jan 2008 03:15:54 -0000 Subject: [M3devel] Sanity check request regarding CT arithmetic Message-ID: <479FEFA0.5040309@wichita.edu> 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 From jayk123 at hotmail.com Tue Jan 1 22:33:18 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 1 Jan 2008 21:33:18 +0000 Subject: [M3devel] efficient "safe" Modula-3? Message-ID: How can I write this in idiomatic Modula-3: date : Date.T Fmt.FN( (* heap alloc *) "%04s-%02s-%02s %02s:%02s:%02s", ARRAY OF TEXT{ (* heap alloc? easily avoided, but just over the limit *) Fmt.Int(date.year), (* heap alloc *) Fmt.Int(ORD(date.month) + 1), (* heap alloc *) Fmt.Int(date.day), (* heap alloc *) Fmt.Int(date.hour), (* heap alloc *) Fmt.Int(date.minute), (* heap alloc *) Fmt.Int(date.second) (* heap alloc *) }))); to be more like in performance to: Date_t date; /* Win32 SYSTEMTIME essentially */ char Buffer[sizeof("2008-01-01 20:29:58")]; sprintf( Buffer, "%04u-%02u-%02u %02u:%02u:%02u", date.year, ORD(date.month) + 1, date.day, date.hour, date.minute, date.second); or, ok: Date_t date; /* Win32 SYSTEMTIME essentially */ char* Buffer = (char*) malloc(sizeof("2008-01-01 20:29:58")); /* deliberate heap alloc for long lived string */ if (Buffer== NULL) ... sprintf( Buffer, "%04u-%02u-%02u %02u:%02u:%02u", date.year, ORD(date.month) + 1, date.day, date.hour, date.minute, date.second); Unnecessary heap allocations bug me. I seem to see a fair amount of tedious Modula-3 code around to avoid heap allocs,folks manually managing growing arrays instead of using something generic and efficient. Can "safe" code be efficient and convenient to write? (and yes, I know about snprintf, sprintf_s, etc.) - Jay _________________________________________________________________ The best games are on Xbox 360. Click here for a special offer on an Xbox 360 Console. http://www.xbox.com/en-US/hardware/wheretobuy/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Tue Jan 1 21:17:51 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 1 Jan 2008 20:17:51 +0000 Subject: [M3devel] time/date/version functions in Quake? Message-ID: Hi. This is per Olaf. Quake code in m3-sys\cm3\src\version.quake wants/needs the time/date like so: C:\dev2\cm3.2\m3-sys\m3quake>\cm3\bin\cm3.exe -version Critical Mass Modula-3 version d5.5.1 last updated: 2007-12-30 compiled: 2008-01-01 19:59:32 <=== configuration: \cm3\bin\cm3.cfg In UTC (universal coordinated time, also known as "greenwich mean time (GMT)")Currently this is via an application specific global variable in m3quake called "CM3_VERSION_NOW"."Currently", as in, I just did it, it is committed. (I'm impatient and impulsive and love coding, take me or leave me...) C:\dev2\cm3.2\m3-sys\m3quake>findstr /s NOW * src\QMachine.m3: "CM3_VERSION_NOW", It's only used on Windows, because I haven't yet tested elsewhere. Olaf wants to consider something more general, as I understand.Some little extra feature in Quake, new built in function(s)/variable(s) (probably function(s)).Maybe something like Unix date (er, probably less general than that)or strftime, or something. I'm skeptical that resolution to the second is useful here, seems overly precise. Please discuss/decide/spec. :)(I don't care much. I'd be content just to change the variable to a function and decide on a name that isn't ALL CAPS, though those were my own doing in the first place, as well as learning the best idiom for those few lines of code, such as hopefully to avoid the six+ extra heap allocs for the TEXTs before concating them, like something involving a small fixed sized buffer on the stack maybe? :) ) (Not clear how much "safety" a "competent programmer" needs and if it is all worth it...obviously has its place, but...) Oh, and to be a bit obnoxious -- maybe the higher level version.quake should be pushed into Modula-3 code????I mean..something like..some stamp that is applied to all binaries? You know, like on Windows, there are these nice version resources.Putting them in every file automatically would be nice, unless overridden by the use -- typical override wouldbe provision of all Win32 resources, and hopefully that'd include a version resource. I /know/ I am confusing issues -- universal injection of such data, vs. implementation in Quake vs. Modula-3.Any conventions/mechanisms for other platforms?The Mac has/had version resources, but these days that'd probably involve creating 10 more files and directories per executable.I can research it though easily enough.. On Windows it would be an extra dependency, on a resource compiler, but they are ubuiquitous.They come with all commercial toolsets and many free ones. - Jay _________________________________________________________________ Don't get caught with egg on your face. Play Chicktionary! http://club.live.com/chicktionary.aspx?icid=chick_wlhmtextlink1_dec -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Wed Jan 2 11:18:33 2008 From: jayk123 at hotmail.com (Jay) Date: Wed, 2 Jan 2008 10:18:33 +0000 Subject: [M3devel] FW: time/date/version functions in Quake? Message-ID: The one I got from m3devel had most newlines removed such as to be hard to read, AND got /slightly/ truncated (just the signature). Let's try this. I will change the global to datetime() shortly. I was thinking of GetDateTimeStamp() but others probably don't like my verbosity and it is not consistent with the terse lowercasing "Romans". - Jay From: jayk123 at hotmail.comTo: m3devel at elegosoft.comCC: wagner at elegosoft.comSubject: time/date/version functions in Quake?Date: Tue, 1 Jan 2008 20:17:51 +0000 Hi. This is per Olaf. Quake code in m3-sys\cm3\src\version.quake wants/needs the time/date like so: C:\dev2\cm3.2\m3-sys\m3quake>\cm3\bin\cm3.exe -version Critical Mass Modula-3 version d5.5.1 last updated: 2007-12-30 compiled: 2008-01-01 19:59:32 <=== configuration: \cm3\bin\cm3.cfg In UTC (universal coordinated time, also known as "greenwich mean time (GMT)")Currently this is via an application specific global variable in m3quake called "CM3_VERSION_NOW"."Currently", as in, I just did it, it is committed. (I'm impatient and impulsive and love coding, take me or leave me...) C:\dev2\cm3.2\m3-sys\m3quake>findstr /s NOW * src\QMachine.m3: "CM3_VERSION_NOW", It's only used on Windows, because I haven't yet tested elsewhere.Olaf wants to consider something more general, as I understand.Some little extra feature in Quake, new built in function(s)/variable(s) (probably function(s)).Maybe something like Unix date (er, probably less general than that)or strftime, or something.I'm skeptical that resolution to the second is useful here, seems overly precise.Please discuss/decide/spec. :)(I don't care much. I'd be content just to change the variable to a function and decide on a name that isn't ALL CAPS,though those were my own doing in the first place, as well as learning the best idiom for those few lines of code,such as hopefully to avoid the six+ extra heap allocs for the TEXTs before concating them, like something involvinga small fixed sized buffer on the stack maybe? :) ) (Not clear how much "safety" a "competent programmer"needs and if it is all worth it...obviously has its place, but...)Oh, and to be a bit obnoxious -- maybe the higher level version.quake should be pushed into Modula-3 code????I mean..something like..some stamp that is applied to all binaries?You know, like on Windows, there are these nice version resources.Putting them in every file automatically would be nice, unless overridden by the use -- typical override wouldbe provision of all Win32 resources, and hopefully that'd include a version resource. I /know/ I am confusing issues -- universal injection of such data, vs. implementation in Quake vs. Modula-3.Any conventions/mechanisms for other platforms?The Mac has/had version resources, but these days that'd probably involve creating 10 more files and directories per executable.I can research it though easily enough..On Windows it would be an extra dependency, on a resource compiler, but they are ubuiquitous.They come with all commercial toolsets and many free ones. - Jay _________________________________________________________________ The best games are on Xbox 360. Click here for a special offer on an Xbox 360 Console. http://www.xbox.com/en-US/hardware/wheretobuy/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Wed Jan 2 11:22:28 2008 From: jayk123 at hotmail.com (Jay) Date: Wed, 2 Jan 2008 10:22:28 +0000 Subject: [M3devel] FW: "where to root archives?" In-Reply-To: <20071230162432.C498A10D4596@birch.elegosoft.com> References: <20071230162432.C498A10D4596@birch.elegosoft.com> Message-ID: More messed up formating in the first copy I got from m3devel. I'm going to have to send things to myself first, or experiment to see how to avoid newline deletion. I often add spaces to the start/end of lines to avoid this problem. It's sad that mere email doesn't really work... :( I realize wordwrap vs. linejoin vs. leaveonly are hard to decide about... - Jay From: jayk123 at hotmail.comTo: m3devel at elegosoft.comSubject: "where to root archives?"Date: Mon, 31 Dec 2007 11:04:53 +0000 "where to root archives?"Maybe this is along the lines of "how to format my code?"Religous and unanswerable and strong proponents of every answer?but:A) *.zip|*.tar.gz|*.tar.bz2 shall be named cm3.* or B) cm3-.* ok, no question here, B is it.And shall contain the structure: 1) more than one file/directory at the root bin/cm3(.exe) pkg/libm3/...or 2) root contains only one directory, and it has a version in its name (and target probably) cm3-/bin/cm3(.exe) cm3-/pkg/libm3/.. or 3) root contains only one directory, with no version in its name cm3/bin/cm3(.exe) cm3/pkg/libm3/.. #1 is what the current cminstall-using distributions use I believe.Since it is wrapped by an installer, doesn't really matter.Note though that the enclosing archive is also formed this way I think, but with fewer than 10 files.It seems clearly the worst, unless you know about the tar -C or unzip -d switches, though tar -C doesn'tcreate the output directory, unzip -d does.#2 is VERY popular and tempting for me#3 is what the Win32 builds use currently (scripts/win/make-dist.cmd) It has the advantage of being more directly useable. cd \ unzip cm3-.zip and it goes into \cm3, a reasonable default, but could be preexisting (unzip does prompt I think) If it went to cm3-version, you'd probably want to either rename it, or create a link to it, Window having varying support for different types of links on different versions, not sure if use is widespread. fsutil hardlink create creates file hard links on XP+ mklink creates hardlinks and symlinks on Vista+ probably only file hardlinks and file or directory symlinks At some point, directory links were avoided because a) not required by Posix? b) allows creating cycles I see cycles now on my default installs and have crashed stuff as a result. :( junction from www.sysinternals.com creates directory linkes on...Win2000+? (This is all NTFS only of course, or over SMB to other file systems; actually stupid fsutil demands a local file system, even though underlying CreateHardLink works over SMB..) #2 seems safer, and user can immediatley rename to #3 after extraction.Oh, and in the Explorer GUI, the default is to extract in a directory with the same name as the basename of the archive.That makes #1 slightly better and the others slightly worse. Inevitably it seems the command line is doomed to always check before extracting anyway.. unzip -l foo.zip | more tar tfz foo.tar.gz | more Besides that, it still impresses and bugs me how much smaller .tar.bz2 is vs. anything else...but the Explorer support or .zip filesis also somewhat compelling...except that you have to use the command line with CM3 anyway.... - Jay The best games are on Xbox 360. Click here for a special offer on an Xbox 360 Console. Get it now! _________________________________________________________________ i?m is proud to present Cause Effect, a series about real people making a difference. http://im.live.com/Messenger/IM/MTV/?source=text_Cause_Effect -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Wed Jan 2 12:21:48 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 2 Jan 2008 12:21:48 +0100 Subject: [M3devel] cvs question: how to know what I have changed on my machine? In-Reply-To: References: <20071230163328.GB5689@elegosoft.com> Message-ID: <20080102112147.GA12332@elegosoft.com> On Mon, Dec 31, 2007 at 09:48:26AM +0000, Jay wrote: > > I swear I looked for this on the web, several times. :) > What is the right/fast way to see what I have changed in cvs? > Is it really to go to the top of the tree and say cvs diff? > Some source control system I have used, makes "checked in" files > read only, requires you to "check out", and keeps track of what > you checked out. > This model seems quite nice. cvs works recursively from the current directory by default. To check what has changed you use cvs -nq up which simulates an update and lets you know the status of changes. To get more details, you use cvs -q diff -u [files] | less This is of course what I do most of the times. There may be other ways. > There is a fallback if the network is needed and not available. > It is a little annoying, the inevitable failed save, but it is well > worth it. CVS use an optimistic approach wrt. locking, and it works well in practice. Locks or watches can be set if one really wants to, but this needs the cooperation of all users. See `cvs edit' and `cvs watchers' for details. > I've been doing cvs diff but it seem terribly inefficient. > Same question for Subversion, though I haven't looked. > It at least seems to rapidly know what I have changed, on my puny > tree, > and I know it also saves away all the originals, so diff is a client > only operation. In Subversion, diff is a client operation wrt. the base vesion you checked out, because that is held as backup copy in your workspace. This leads to workspaces which occupy twice the amount of space, but is sometimes worth the effort. > Oh another question -- how to view history? In CVS, the history for one file is called log. Use `cvs log file' to view it. To get a complete history of changes, use the cvs2cl utility, which accumulates changes recursively into ChangeLog files. It's what you can see at http://modula3.elegosoft.com/cm3/ChangeLog for the cm3 repository. > Like, what i keep doing is navigating to individual files on the web. > It's fairly tedious. > It'd be nice if checkins at right about the same time, with the same > comment, > where packaged up in the ui, like Perforce (well, for it, it is just > one change).... > I usually look at the diffs after commit, besides before. I'd suggest to do commits at package level (to always have a consistent version checked-in) and look at the diffs before commit. There are some more suggestions in http://modula3.elegosoft.com/cm3/cm3-cm-rules.html Olaf > Thanks, > - Jay > _________________________________________________________________ > > Share life as it happens with the new Windows Live. Share now! -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From lemming at henning-thielemann.de Wed Jan 2 12:20:14 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Wed, 02 Jan 2008 12:20:14 +0100 (CET) Subject: [M3devel] cvs question: how to know what I have changed on my machine? In-Reply-To: References: <20071230163328.GB5689@elegosoft.com> Message-ID: On Mon, 31 Dec 2007, Jay wrote: > I swear I looked for this on the web, several times. :) > What is the right/fast way to see what I have changed in cvs? > Is it really to go to the top of the tree and say cvs diff? Yes, if you want to see the lines which changed. Otherwise 'status' gives more of an overview. I rarely use that, but most oftenly type just 'update' because that marks all modified files with 'M' and added files with 'A'. From wagner at elegosoft.com Wed Jan 2 12:24:51 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 2 Jan 2008 12:24:51 +0100 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: References: <20071230162432.C498A10D4596@birch.elegosoft.com> Message-ID: <20080102112451.GB12332@elegosoft.com> On Mon, Dec 31, 2007 at 10:44:37AM +0000, Jay wrote: > > Olaf, > 1) I PERSONALLY really don't like hidden files. > Most things that people hide aren't worth hiding and might be worth > seeing. > Rename the . file you create? > Besides that, get this.. > I have a low end Western Digital NAS. > It runs Linux but it's very much a "sealed box" "appliance". > The source to the thing is available of course. > It has files that start with dot. > They show as hidden -- and they cannot be unhidden. > This caused me problems trying to copy the source over itself, since > on Windows "hidden" is somewhat "protected", kind of like "read only". > So that just makes me further dislike this notion. > 2) You created the .datenow file outside the output directory on > purpose? > So it doesn't get cleaned as often? No, I just used existing quake code there; I've got no objection to change name and location. The code got copied from DCVS and in turn from CVSup. I just recycled 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 Wed Jan 2 12:28:03 2008 From: jayk123 at hotmail.com (Jay) Date: Wed, 2 Jan 2008 11:28:03 +0000 Subject: [M3devel] cvs question: how to know what I have changed on my machine? In-Reply-To: <20080102112147.GA12332@elegosoft.com> References: <20071230163328.GB5689@elegosoft.com> <20080102112147.GA12332@elegosoft.com> Message-ID: I look before and after, fyi, not just after, and do strive for coherence, within the limits of CVS (I think it's still only one file at a time, rapidly, one right after the other). Thanks for the other tips. cvs diff seems so inefficient. SVN's double diskspace is definitely worthwhile vs. CVS, but the way it should REALLY work is have the files be initially read only on the client, make me "check them out", which would save a copy and save some state locally as to what is checked out. No cooperation with others should be needed here. Perforce does this all correctly.. it seems pretty obvious and simple how to impelement this well. Ok, actually Perforce doesn't save the local copy. But it does know what you checked out, so it only goes to the server for the small number of files. So nobody gets it quite right, that I know, that I have used, yet, really, it seems so obvious and simple and inefficient and convenient...... sorry about the annoying ad, it's not my doing > Date: Wed, 2 Jan 2008 12:21:48 +0100> To: jayk123 at hotmail.com> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] cvs question: how to know what I have changed on my machine?> From: wagner at elegosoft.com> > On Mon, Dec 31, 2007 at 09:48:26AM +0000, Jay wrote:> > > > I swear I looked for this on the web, several times. :)> > What is the right/fast way to see what I have changed in cvs?> > Is it really to go to the top of the tree and say cvs diff?> > Some source control system I have used, makes "checked in" files> > read only, requires you to "check out", and keeps track of what> > you checked out.> > This model seems quite nice.> > cvs works recursively from the current directory by default.> To check what has changed you use> > cvs -nq up> > which simulates an update and lets you know the status of changes.> > To get more details, you use> > cvs -q diff -u [files] | less> > This is of course what I do most of the times. There may be other> ways.> > > There is a fallback if the network is needed and not available.> > It is a little annoying, the inevitable failed save, but it is well> > worth it.> > CVS use an optimistic approach wrt. locking, and it works well in> practice. Locks or watches can be set if one really wants to, but> this needs the cooperation of all users. See `cvs edit' and> `cvs watchers' for details.> > > I've been doing cvs diff but it seem terribly inefficient.> > Same question for Subversion, though I haven't looked.> > It at least seems to rapidly know what I have changed, on my puny> > tree,> > and I know it also saves away all the originals, so diff is a client> > only operation.> > In Subversion, diff is a client operation wrt. the base vesion you> checked out, because that is held as backup copy in your workspace.> This leads to workspaces which occupy twice the amount of space,> but is sometimes worth the effort.> > > Oh another question -- how to view history?> > In CVS, the history for one file is called log. Use `cvs log file' to> view it. To get a complete history of changes, use the cvs2cl> utility, which accumulates changes recursively into ChangeLog files.> It's what you can see at http://modula3.elegosoft.com/cm3/ChangeLog> for the cm3 repository.> > > Like, what i keep doing is navigating to individual files on the web.> > It's fairly tedious.> > It'd be nice if checkins at right about the same time, with the same> > comment,> > where packaged up in the ui, like Perforce (well, for it, it is just> > one change)....> > I usually look at the diffs after commit, besides before.> > I'd suggest to do commits at package level (to always have a> consistent version checked-in) and look at the diffs before commit.> There are some more suggestions in > > http://modula3.elegosoft.com/cm3/cm3-cm-rules.html> > Olaf> > 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 _________________________________________________________________ Share life as it happens with the new Windows Live. http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_122007 -------------- next part -------------- An HTML attachment was scrubbed... URL: From lemming at henning-thielemann.de Wed Jan 2 12:28:18 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Wed, 02 Jan 2008 12:28:18 +0100 (CET) Subject: [M3devel] efficient "safe" Modula-3? In-Reply-To: References: Message-ID: On Tue, 1 Jan 2008, Jay wrote: > How can I write this in idiomatic Modula-3: > date : Date.T Fmt.FN( (* heap alloc *) "%04s-%02s-%02s %02s:%02s:%02s", ARRAY OF TEXT{ (* heap alloc? easily avoided, but just over the limit *) Fmt.Int(date.year), (* heap alloc *) Fmt.Int(ORD(date.month) + 1), (* heap alloc *) Fmt.Int(date.day), (* heap alloc *) Fmt.Int(date.hour), (* heap alloc *) Fmt.Int(date.minute), (* heap alloc *) Fmt.Int(date.second) (* heap alloc *) }))); I think that this solution is the most elegant one can do. It's still not entirely safe, because the number of arguments may not match the number of placeholders in the format string. GCC checks this for printf and friends, but I'm afraid this is restricted to the standard format strings. Even more safe, but maybe less readable and less efficient is Fmt.Int(date.year) & "-" & Fmt.Int(date.month+1) & "-" ... People have even invented dependently typed languages in order to get functions like printf typed in a statically safe manner: http://en.wikipedia.org/wiki/Cayenne_(programming_language) From mika at async.caltech.edu Wed Jan 2 13:47:24 2008 From: mika at async.caltech.edu (Mika Nystrom) Date: Wed, 02 Jan 2008 04:47:24 -0800 Subject: [M3devel] efficient "safe" Modula-3? In-Reply-To: Your message of "Wed, 02 Jan 2008 12:28:18 +0100." Message-ID: <200801021247.m02ClO9D076834@camembert.async.caltech.edu> Well it's hard (i.e., impossible) to do a safe sprintf in Modula-3 that doesn't require heap allocations. Fast idiomatic Modula-3 would involve using procedures to append to an ARRAY OF CHAR, and then passing it a SUBARRAY as you go down the string. If the format string is constant, as it is in most cases, why don't you write a printf compiler? :) Something that can write to a Wr.T, maybe. By the way, from the point of view of performance, the worst piece of the Modula-3 system that I have found is Scan.LongReal. It's horrid! (At least with PM3, but I think CM3 still has problems.) The libraries I have that need to read lots of numbers from disk files use the C routines strtod and strtol for that reason. The performance loss here, in my experience, dwarfs any memory allocator/garbage collector performance issues from the code you attached... Mika Henning Thielemann writes: > >On Tue, 1 Jan 2008, Jay wrote: > >> How can I write this in idiomatic Modula-3: > >> date : Date.T Fmt.FN( (* heap alloc *) "%04s-%02s-%02s %02s:%02s:%02s", ARRAY OF TEXT{ (* heap alloc? easily avoided, but just over t >he limit *) Fmt.Int(date.year), (* heap alloc *) Fmt.Int(ORD(date.month) + 1), (* heap alloc *) Fmt.Int(date.day), (* heap alloc *) Fmt.In >t(date.hour), (* heap alloc *) Fmt.Int(date.minute), (* heap alloc *) Fmt.Int(date.second) (* heap alloc *) }))); > > I think that this solution is the most elegant one can do. It's still not >entirely safe, because the number of arguments may not match the number of >placeholders in the format string. GCC checks this for printf and friends, >but I'm afraid this is restricted to the standard format strings. > Even more safe, but maybe less readable and less efficient is > Fmt.Int(date.year) & "-" & Fmt.Int(date.month+1) & "-" ... > > People have even invented dependently typed languages in order to get >functions like printf typed in a statically safe manner: > http://en.wikipedia.org/wiki/Cayenne_(programming_language) From rcoleburn at scires.com Wed Jan 2 17:31:54 2008 From: rcoleburn at scires.com (Randy Coleburn) Date: Wed, 02 Jan 2008 11:31:54 -0500 Subject: [M3devel] M3 concerns Message-ID: <477B7629.1E75.00D7.1@scires.com> I've seen quite a number of m3commit and m3devel messages lately. Many of these give the appearance of "thinking out loud" with various commits followed by apparent reversals. In many cases the m3commit log messages are terse and don't give the rationale behind the change. For those of us in the M3 community who rely upon the stability of the libraries and core M3 principles, these types of messages cause concern. While I appreciate everyone's efforts to move forward, I don't want to abandon the great care that went into formulating this language. Question: As various people make contributions and changes, is there any group of folks who is verifying that the changes don't break existing code or core principles? Another idea would be to have a series of test batteries that have to be passed before changes can be accepted. I know of a number of projects where many people contribute, but the contributions have to be vetted by passing some tests. Without these types of controls, I fear that good forward progress will inevitably be hampered or compromised by changes made by someone who hasn't completely thought out and tested the ramifications of those changes. For example, I've tried to get cm3 working for me on Windows XP several times. I still can't seem to get the "current" system to build correctly on XP. In the past, I have on occasion gotten the "system" to build, but then some of my programs don't work correctly when rebuilt using the new cm3. Thus, some changes somewhere have "broken" my code, yet all of my code uses the "safe" subset of the language. If I go back to my old reliable cm3 version 4.1 (the last one put out before Critical Mass, Inc. threw in the towel), my code compiles and works, even on Windows XP, even using Trestle, FormsVBT, NetObj, cross-platform pickles (e.g., pickles shared between Windows & Unix boxes), etc.! Much of my code was originally developed under Windows NT, so I think it is a tribute to the original language developers that my code and their compiler work through various OS version upgrades (NT, 2000, XP) and changes to the underlying C/C++ compilers used to build the core components. I would appreciate constructive feedback on this topic. Regards, Randy Coleburn Randy C. Coleburn, CISSP Senior Systems Engineer, Communications, Networks, & Electronics Division (CNE) Corporate & Atlanta Information Systems Security Manager (ISSM) Scientific Research Corporation 2300 Windy Ridge Parkway, Suite 400 South, Atlanta, Georgia 30339 voice: (770) 989-9464, email: RColeburn at SciRes.com, fax: (770) 989-9497 Quality Policy: "SRC CNE Division is committed to delivering continually improving research & engineering excellence that meets or exceeds customer requirements." -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Wed Jan 2 19:36:10 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 2 Jan 2008 13:36:10 -0500 Subject: [M3devel] M3 concerns In-Reply-To: <477B7629.1E75.00D7.1@scires.com> References: <477B7629.1E75.00D7.1@scires.com> Message-ID: On Jan 2, 2008, at 11:31 AM, Randy Coleburn wrote: > I've seen quite a number of m3commit and m3devel messages lately. > Many of these give the appearance of "thinking out loud" with > various commits followed by apparent reversals. In many cases the > m3commit log messages are terse and don't give the rationale behind > the change. Yes, I agree. Also, I tend to avoid committing multiple small patches and rather defer until I have had a chance to test everything and let it stabilize, before checking in as one single commit. So, less frequent, coherent commits, are preferable to many smaller, incoherent commits. > For those of us in the M3 community who rely upon the stability of > the libraries and core M3 principles, these types of messages cause > concern. While I appreciate everyone's efforts to move forward, I > don't want to abandon the great care that went into formulating > this language. Indeed. > Question: As various people make contributions and changes, is > there any group of folks who is verifying that the changes don't > break existing code or core principles? Another idea would be to > have a series of test batteries that have to be passed before > changes can be accepted. I know of a number of projects where many > people contribute, but the contributions have to be vetted by > passing some tests. I try to verify that all my code doesn't break existing code (though I admit GC/thread subsystems can be devilish to completely verify). We do need to have some sort of procedures in place for deciding what commits make sense and should go into the CVS head. Tentative work should always be done to a CVS branch until it can be vetted. > Without these types of controls, I fear that good forward progress > will inevitably be hampered or compromised by changes made by > someone who hasn't completely thought out and tested the > ramifications of those changes. Agree! > For example, I've tried to get cm3 working for me on Windows XP > several times. I still can't seem to get the "current" system to > build correctly on XP. In the past, I have on occasion gotten the > "system" to build, but then some of my programs don't work > correctly when rebuilt using the new cm3. Thus, some changes > somewhere have "broken" my code, yet all of my code uses the "safe" > subset of the language. If I go back to my old reliable cm3 > version 4.1 (the last one put out before Critical Mass, Inc. threw > in the towel), my code compiles and works, even on Windows XP, even > using Trestle, FormsVBT, NetObj, cross-platform pickles (e.g., > pickles shared between Windows & Unix boxes), etc.! Much of my > code was originally developed under Windows NT, so I think it is a > tribute to the original language developers that my code and their > compiler work through various OS version upgrades (NT, 2000, XP) > and changes to the underlying C/C++ compilers used to build the > core components. I thought we were getting closer to stability in this regard, though I am not a heavy Windows user and have never built CM3 on Windows. > I would appreciate constructive feedback on this topic. It would be great to have a set of regression tests run on a regular basis to ensure that checkins don't break things. What good candidates do we have? cm3 itself I suppose. Any others? I can probably devise a couple of thread and GC stress tests pretty easily. Anyone willing to set up a testing regime? I have machines that could be used to test on several supported platforms on a nightly basis even. > > Regards, > Randy Coleburn > > > Randy C. Coleburn, CISSP > Senior Systems Engineer, Communications, Networks, & Electronics > Division (CNE) > Corporate & Atlanta Information Systems Security Manager (ISSM) > Scientific Research Corporation > 2300 Windy Ridge Parkway, Suite 400 South, Atlanta, Georgia 30339 > voice: (770) 989-9464, email: RColeburn at SciRes.com, fax: (770) > 989-9497 > > Quality Policy: "SRC CNE Division is committed to delivering > continually improving research & engineering excellence that meets > or exceeds customer requirements." From rcoleburn at scires.com Wed Jan 2 20:32:02 2008 From: rcoleburn at scires.com (Randy Coleburn) Date: Wed, 02 Jan 2008 14:32:02 -0500 Subject: [M3devel] M3 concerns In-Reply-To: References: <477B7629.1E75.00D7.1@scires.com> Message-ID: <477BA060.1E75.00D7.1@scires.com> Tony: I'm thinking that with a little work we could set up an automated set of builds and regression tests that would make available a "scoreboard" via a web interface where everyone could see the results. That way, as problems are uncovered, folks could begin working on them. For an example of how all this works, take a look at the scoreboard set up for the ACE+TAO+CIAO projects. An overview is at http://www.dre.vanderbilt.edu/Scoreboard/ . They provide instructions for setting up your own daily build and scoreboard at https://svn.dre.vanderbilt.edu/viewvc/autobuild/trunk/README?revision=HEAD . You can see the scoreboard in operation at http://remedy.nl/ . Regards, Randy >>> Tony Hosking 1/2/2008 1:36 PM >>> On Jan 2, 2008, at 11:31 AM, Randy Coleburn wrote: > I've seen quite a number of m3commit and m3devel messages lately. > Many of these give the appearance of "thinking out loud" with > various commits followed by apparent reversals. In many cases the > m3commit log messages are terse and don't give the rationale behind > the change. Yes, I agree. Also, I tend to avoid committing multiple small patches and rather defer until I have had a chance to test everything and let it stabilize, before checking in as one single commit. So, less frequent, coherent commits, are preferable to many smaller, incoherent commits. > For those of us in the M3 community who rely upon the stability of > the libraries and core M3 principles, these types of messages cause > concern. While I appreciate everyone's efforts to move forward, I > don't want to abandon the great care that went into formulating > this language. Indeed. > Question: As various people make contributions and changes, is > there any group of folks who is verifying that the changes don't > break existing code or core principles? Another idea would be to > have a series of test batteries that have to be passed before > changes can be accepted. I know of a number of projects where many > people contribute, but the contributions have to be vetted by > passing some tests. I try to verify that all my code doesn't break existing code (though I admit GC/thread subsystems can be devilish to completely verify). We do need to have some sort of procedures in place for deciding what commits make sense and should go into the CVS head. Tentative work should always be done to a CVS branch until it can be vetted. > Without these types of controls, I fear that good forward progress > will inevitably be hampered or compromised by changes made by > someone who hasn't completely thought out and tested the > ramifications of those changes. Agree! > For example, I've tried to get cm3 working for me on Windows XP > several times. I still can't seem to get the "current" system to > build correctly on XP. In the past, I have on occasion gotten the > "system" to build, but then some of my programs don't work > correctly when rebuilt using the new cm3. Thus, some changes > somewhere have "broken" my code, yet all of my code uses the "safe" > subset of the language. If I go back to my old reliable cm3 > version 4.1 (the last one put out before Critical Mass, Inc. threw > in the towel), my code compiles and works, even on Windows XP, even > using Trestle, FormsVBT, NetObj, cross-platform pickles (e.g., > pickles shared between Windows & Unix boxes), etc.! Much of my > code was originally developed under Windows NT, so I think it is a > tribute to the original language developers that my code and their > compiler work through various OS version upgrades (NT, 2000, XP) > and changes to the underlying C/C++ compilers used to build the > core components. I thought we were getting closer to stability in this regard, though I am not a heavy Windows user and have never built CM3 on Windows. > I would appreciate constructive feedback on this topic. It would be great to have a set of regression tests run on a regular basis to ensure that checkins don't break things. What good candidates do we have? cm3 itself I suppose. Any others? I can probably devise a couple of thread and GC stress tests pretty easily. Anyone willing to set up a testing regime? I have machines that could be used to test on several supported platforms on a nightly basis even. > > Regards, > Randy Coleburn > > > Randy C. Coleburn, CISSP > Senior Systems Engineer, Communications, Networks, & Electronics > Division (CNE) > Corporate & Atlanta Information Systems Security Manager (ISSM) > Scientific Research Corporation > 2300 Windy Ridge Parkway, Suite 400 South, Atlanta, Georgia 30339 > voice: (770) 989-9464, email: RColeburn at SciRes.com, fax: (770) > 989-9497 > > Quality Policy: "SRC CNE Division is committed to delivering > continually improving research & engineering excellence that meets > or exceeds customer requirements." -------------- next part -------------- An HTML attachment was scrubbed... URL: From kschleiser at elego.de Wed Jan 2 21:51:00 2008 From: kschleiser at elego.de (Kaspar Schleiser) Date: Wed, 02 Jan 2008 21:51:00 +0100 Subject: [M3devel] M3 concerns In-Reply-To: <477BA060.1E75.00D7.1@scires.com> References: <477B7629.1E75.00D7.1@scires.com> <477BA060.1E75.00D7.1@scires.com> Message-ID: <477BF934.80805@elego.de> Hey all, Randy Coleburn wrote: > I'm thinking that with a little work we could set up an automated set of builds and regression tests that would make available a "scoreboard" via a web interface where everyone could see the results. That way, as problems are uncovered, folks could begin working on them. Just to let you know, we at elego have set up a tinderbox based automated build system which should be ready for production soon. Regards, Kaspar Schleiser From lemming at henning-thielemann.de Wed Jan 2 22:51:23 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Wed, 02 Jan 2008 22:51:23 +0100 (CET) Subject: [M3devel] M3 concerns In-Reply-To: References: <477B7629.1E75.00D7.1@scires.com> Message-ID: On Wed, 2 Jan 2008, Tony Hosking wrote: > > I would appreciate constructive feedback on this topic. > > It would be great to have a set of regression tests run on a regular > basis to ensure that checkins don't break things. What good > candidates do we have? cm3 itself I suppose. Any others? Do you mean m3-sys/m3tests ? From mika at async.caltech.edu Thu Jan 3 01:10:42 2008 From: mika at async.caltech.edu (Mika Nystrom) Date: Wed, 02 Jan 2008 16:10:42 -0800 Subject: [M3devel] M3 concerns In-Reply-To: Your message of "Wed, 02 Jan 2008 14:32:02 EST." <477BA060.1E75.00D7.1@scires.com> Message-ID: <200801030010.m030AgKN099099@camembert.async.caltech.edu> I can happily volunteer FreeBSD 4.x and 5.x (i386) systems, Windows 2000, and, I believe, Digital Unix 4.0 systems to run nightly (daily?) builds. Unfortunately I am of course a bit short on Time, which is probably what's lacking the most, anyhow... Mika "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. > >--=__Part103621A2.1__= >Content-Type: text/plain; charset=US-ASCII >Content-Transfer-Encoding: quoted-printable > >Tony: >=20 >I'm thinking that with a little work we could set up an automated set of = >builds and regression tests that would make available a "scoreboard" via a = >web interface where everyone could see the results. That way, as problems = >are uncovered, folks could begin working on them. >=20 >For an example of how all this works, take a look at the scoreboard set up = >for the ACE+TAO+CIAO projects. An overview is at http://www.dre.vanderbilt= >.edu/Scoreboard/ . They provide instructions for setting up your own = >daily build and scoreboard at https://svn.dre.vanderbilt.edu/viewvc/autobui= >ld/trunk/README?revision=3DHEAD . You can see the scoreboard in operation = >at http://remedy.nl/ . >=20 >Regards, >Randy > >>>> Tony Hosking 1/2/2008 1:36 PM >>> > >On Jan 2, 2008, at 11:31 AM, Randy Coleburn wrote: > >> I've seen quite a number of m3commit and m3devel messages lately. =20 >> Many of these give the appearance of "thinking out loud" with =20 >> various commits followed by apparent reversals. In many cases the =20 >> m3commit log messages are terse and don't give the rationale behind =20 >> the change. > >Yes, I agree. Also, I tend to avoid committing multiple small =20 >patches and rather defer until I have had a chance to test everything =20 >and let it stabilize, before checking in as one single commit. So, =20 >less frequent, coherent commits, are preferable to many smaller, =20 >incoherent commits. > >> For those of us in the M3 community who rely upon the stability of =20 >> the libraries and core M3 principles, these types of messages cause =20 >> concern. While I appreciate everyone's efforts to move forward, I =20 >> don't want to abandon the great care that went into formulating =20 >> this language. > >Indeed. > >> Question: As various people make contributions and changes, is =20 >> there any group of folks who is verifying that the changes don't =20 >> break existing code or core principles? Another idea would be to =20 >> have a series of test batteries that have to be passed before =20 >> changes can be accepted. I know of a number of projects where many =20 >> people contribute, but the contributions have to be vetted by =20 >> passing some tests. > >I try to verify that all my code doesn't break existing code (though =20 >I admit GC/thread subsystems can be devilish to completely verify). =20 >We do need to have some sort of procedures in place for deciding what =20 >commits make sense and should go into the CVS head. Tentative work =20 >should always be done to a CVS branch until it can be vetted. > >> Without these types of controls, I fear that good forward progress =20 >> will inevitably be hampered or compromised by changes made by =20 >> someone who hasn't completely thought out and tested the =20 >> ramifications of those changes. > >Agree! > >> For example, I've tried to get cm3 working for me on Windows XP =20 >> several times. I still can't seem to get the "current" system to =20 >> build correctly on XP. In the past, I have on occasion gotten the =20 >> "system" to build, but then some of my programs don't work =20 >> correctly when rebuilt using the new cm3. Thus, some changes =20 >> somewhere have "broken" my code, yet all of my code uses the "safe" =20 >> subset of the language. If I go back to my old reliable cm3 =20 >> version 4.1 (the last one put out before Critical Mass, Inc. threw =20 >> in the towel), my code compiles and works, even on Windows XP, even =20 >> using Trestle, FormsVBT, NetObj, cross-platform pickles (e.g., =20 >> pickles shared between Windows & Unix boxes), etc.! Much of my =20 >> code was originally developed under Windows NT, so I think it is a =20 >> tribute to the original language developers that my code and their =20 >> compiler work through various OS version upgrades (NT, 2000, XP) =20 >> and changes to the underlying C/C++ compilers used to build the =20 >> core components. > >I thought we were getting closer to stability in this regard, though =20 >I am not a heavy Windows user and have never built CM3 on Windows. > >> I would appreciate constructive feedback on this topic. > >It would be great to have a set of regression tests run on a regular =20 >basis to ensure that checkins don't break things. What good =20 >candidates do we have? cm3 itself I suppose. Any others? I can =20 >probably devise a couple of thread and GC stress tests pretty =20 >easily. Anyone willing to set up a testing regime? I have machines =20 >that could be used to test on several supported platforms on a =20 >nightly basis even. > >> >> Regards, >> Randy Coleburn >> >> >> Randy C. Coleburn, CISSP >> Senior Systems Engineer, Communications, Networks, & Electronics =20 >> Division (CNE) >> Corporate & Atlanta Information Systems Security Manager (ISSM) >> Scientific Research Corporation >> 2300 Windy Ridge Parkway, Suite 400 South, Atlanta, Georgia 30339 >> voice: (770) 989-9464, email: RColeburn at SciRes.com, fax: (770) =20 >> 989-9497 >> >> Quality Policy: "SRC CNE Division is committed to delivering =20 >> continually improving research & engineering excellence that meets =20 >> or exceeds customer requirements." > > > >--=__Part103621A2.1__= >Content-Type: text/html; charset=US-ASCII >Content-Transfer-Encoding: quoted-printable >Content-Description: HTML > > >"> > > >
Tony:
>
 
>
I'm thinking that with a little work we could set up an automated set = >of builds and regression tests that would make available a "scoreboard" = >via a web interface where everyone could see the results.  That way, = >as problems are uncovered, folks could begin working on them.
>
 
>
For an example of how all this works, take a look at the scoreboard = >set up for the ACE+TAO+CIAO projects.  An overview is at tp://www.dre.vanderbilt.edu/Scoreboard/">http://www.dre.vanderbilt.edu/Scor= >eboard/ .  They provide instructions for setting up your own = >daily build and scoreboard at wvc/autobuild/trunk/README?revision=3DHEAD">https://svn.dre.vanderbilt.edu/= >viewvc/autobuild/trunk/README?revision=3DHEAD .  You can see = >the scoreboard in operation at http://remedy.= >nl/ .
>
 
>
Regards,
>
Randy
>

>>> Tony Hosking <hosking at cs.purdue.edu> 1/2/2008 = >1:36 PM >>>

On Jan 2, 2008, at 11:31 AM, Randy Coleburn = >wrote:

> I've seen quite a number of m3commit and m3devel = >messages lately.  
> Many of these give the appearance of = >"thinking out loud" with 
> various commits followed by = >apparent reversals.  In many cases the 
> m3commit log = >messages are terse and don't give the rationale behind 
> the = >change.

Yes, I agree.  Also, I tend to avoid committing = >multiple small 
patches and rather defer until I have had a = >chance to test everything 
and let it stabilize, before checking = >in as one single commit.   So, 
less frequent, coherent = >commits, are preferable to many smaller, 
incoherent commits.
<= >BR>>  For those of us in the M3 community who rely upon the = >stability of 
> the libraries and core M3 principles, these = >types of messages cause 
> concern.  While I appreciate = >everyone's efforts to move forward, I 
> don't want to abandon = >the great care that went into formulating 
> this language.
= >
Indeed.

>  Question:  As various people make = >contributions and changes, is 
> there any group of folks who = >is verifying that the changes don't 
> break existing code or = >core principles?  Another idea would be to 
> have a = >series of test batteries that have to be passed before 
> = >changes can be accepted.  I know of a number of projects where = >many 
> people contribute, but the contributions have to be = >vetted by 
> passing some tests.

I try to verify that = >all my code doesn't break existing code (though 
I admit = >GC/thread subsystems can be devilish to completely verify).   = >
We do need to have some sort of procedures in place for deciding = >what 
commits make sense and should go into the CVS head.  = >Tentative work 
should always be done to a CVS branch until it = >can be vetted.

>  Without these types of controls, I fear = >that good forward progress 
> will inevitably be hampered or = >compromised by changes made by 
> someone who hasn't completely= > thought out and tested the 
> ramifications of those = >changes.

Agree!

>  For example, I've tried to get = >cm3 working for me on Windows XP 
> several times.  I = >still can't seem to get the "current" system to 
> build = >correctly on XP.  In the past, I have on occasion gotten the  = >
> "system" to build, but then some of my programs don't work  = >
> correctly when rebuilt using the new cm3.  Thus, some = >changes 
> somewhere have "broken" my code, yet all of my code = >uses the "safe" 
> subset of the language.  If I go back = >to my old reliable cm3 
> version 4.1 (the last one put out = >before Critical Mass, Inc. threw 
> in the towel), my code = >compiles and works, even on Windows XP, even 
> using Trestle, = >FormsVBT, NetObj, cross-platform pickles (e.g., 
> pickles = >shared between Windows & Unix boxes), etc.!  Much of my  = >
> code was originally developed under Windows NT, so I think it is = >a 
> tribute to the original language developers that my code = >and their 
> compiler work through various OS version upgrades = >(NT, 2000, XP) 
> and changes to the underlying C/C++ = >compilers used to build the 
> core components.

I = >thought we were getting closer to stability in this regard, though  = >
I am not a heavy Windows user and have never built CM3 on Windows.
<= >BR>>  I would appreciate constructive feedback on this topic.
R>It would be great to have a set of regression tests run on a regular = >;
basis to ensure that checkins don't break things.  What = >good 
candidates do we have?  cm3 itself I suppose.  = >Any others?  I can 
probably devise a couple of thread and = >GC stress tests pretty 
easily.  Anyone willing to set up a = >testing regime? I have machines 
that could be used to test on = >several supported platforms on a 
nightly basis even.

><= >BR>> Regards,
> Randy Coleburn
>
>
> Randy C. = >Coleburn, CISSP
> Senior Systems Engineer, Communications, Networks, = >& Electronics 
> Division (CNE)
> Corporate & = >Atlanta Information Systems Security Manager (ISSM)
> Scientific = >Research Corporation
> 2300 Windy Ridge Parkway, Suite 400 South, = >Atlanta, Georgia 30339
> voice: (770) 989-9464, email: RColeburn at SciR= >es.com, fax: (770) 
> 989-9497
>
> Quality = >Policy:  "SRC CNE Division is committed to delivering 
> = >continually improving research & engineering excellence that meets = >;
> or exceeds customer requirements."


L> > >--=__Part103621A2.1__=-- From dabenavidesd at yahoo.es Thu Jan 3 04:52:51 2008 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Thu, 3 Jan 2008 04:52:51 +0100 (CET) Subject: [M3devel] cm3 winvbt concerns Message-ID: <846332.60063.qm@web27115.mail.ukl.yahoo.com> Hi all: Talking about Windows state, the gui packet (winvbt used in mentor, juno, etc, ..) needs to be checked, at least as I see the problem that Jay and maybe Randy are seeing was reported in a 2003 post on comp.lang.modula3: http://groups.google.com/group/comp.lang.modula3/browse_thread/thread/cffb2c2cfda5d9b7/a1822c17c9381925#a1822c17c9381925 Looking more closely, I think there is some code that need to be completed as is documented on the file WinContext.m3 at the procedure: PushStroke (below is a url to show you the comment on that function of dec src that is equal implemented on cm3): http://www.cs.tut.fi/lintula/manual/modula3/m3sources/html/ui/src/winvbt/WinContext.m3.html#PushStroke It says: (* * The main omission is that I don't deal with pixmaps! * * Refer back to XGC.ResolveStrokeGC to see just how much functionality * is missing! *) The comment refers to this function that is implemented in xvbt implementation: http://modula3.elegosoft.com/cm3/doc/help/gen_html/ui/src/xvbt/XGC.m3.html#ResolveStrokeGC I got into this function (PushPixmap of WinContext ) because the assert fails at WinContext.PushPixmap in the line: *** <*ASSERT*> failed. *** file "..\src\winvbt\WinContext.m3", line 165 : brush := WinGDI.CreatePatternBrush (pst.pmtable[pm].hbmp); brush gets NIL. I suspect that is because of the (pst.pmtable[pm].hbmp) argument is not correct. If you have a m3browser winnt machine (pcname named) with latest cm3, this is the url of the procedure implementation: http://pcname:3829/SWinContext.i3.PushPixmap#PushPixmap Or in the cvs online this is the source file of that function: http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/~checkout~/cm3/m3-ui/ui/src/winvbt/WinContext.m3?rev=1.1.1.2;content-type=text%2Fplain Also, the function doesn't exist on the old implementation of winvbt (of dec src): http://www.cs.tut.fi/lintula/manual/modula3/m3sources/html/ui/src/winvbt/WinContext.m3.html One can look more further, but let me know what do you think. Daniel Benavides --------------------------------- ?Chef por primera vez? - S? un mejor Cocinillas. Entra en Yahoo! Respuestas. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Thu Jan 3 23:09:22 2008 From: jayk123 at hotmail.com (Jay) Date: Thu, 3 Jan 2008 22:09:22 +0000 Subject: [M3devel] PPC_LINUX breaks Message-ID: I can't build PPC_LINUX. I can build the compiler with 5.2.6 but then stuck at building m3core with current compiler. There are several problems. Some I can fix, some stump me. This platform still uses non-PTHREADs. I figure that is worth fixing, but maybe afterward? [jay at localhost m3core]$ /tmp/make-dist/compiler_with_self/bin/cm3 -override -DROOT='/dev2/cm3' new source -> compiling Uucontext.i3 "../src/unix/linux-ppc/Uucontext.i3", line 102: syntax error: missing ']' 1 error encountered [jay at localhost m3core]$ cvs diff src/unix/linux-ppc/Uucontext.i3 Index: src/unix/linux-ppc/Uucontext.i3 =================================================================== RCS file: /usr/cvs/cm3/m3-libs/m3core/src/unix/linux-ppc/Uucontext.i3,v retrieving revision 1.1 diff -r1.1 Uucontext.i3 102c102 < vrregs: ARRAY[0..32,0..4] OF unsigned_int; --- > vrregs: ARRAY[0..32 * 4] OF unsigned_int; new source -> compiling Uucontext.i3 "../src/unix/linux-ppc/Uucontext.i3", line 92: undefined (double) "../src/unix/linux-ppc/Uucontext.i3", line 93: undefined (double) "../src/unix/linux-ppc/Uucontext.i3", line 94: undefined (unsigned_int) "../src/unix/linux-ppc/Uucontext.i3", line 102: undefined (unsigned_int) "../src/unix/linux-ppc/Uucontext.i3", line 103: undefined (unsigned_int) "../src/unix/linux-ppc/Uucontext.i3", line 104: undefined (unsigned_int) "../src/unix/linux-ppc/Uucontext.i3", line 105: undefined (unsigned_int) "../src/unix/linux-ppc/Uucontext.i3", line 149: undefined (char) "../src/unix/linux-ppc/Uucontext.i3", line 10: warning: not used (unsigned_short) "../src/unix/linux-ppc/Uucontext.i3", line 11: warning: not used (unsigned_short_int) 8 errors and 2 warnings encountered [jay at localhost m3core]$ cvs diff src/unix/linux-ppc/Uucontext.i3 Index: src/unix/linux-ppc/Uucontext.i3 =================================================================== RCS file: /usr/cvs/cm3/m3-libs/m3core/src/unix/linux-ppc/Uucontext.i3,v retrieving revision 1.1 diff -r1.1 Uucontext.i3 10,11c10,11 < IMPORT int, unsigned_long, unsigned_long_int, unsigned_short, void_star, < unsigned_short_int; --- > IMPORT int, unsigned_long, unsigned_long_int, void_star, > double, unsigned_int, char; new source -> compiling RTSignal.m3 "../src/runtime/PPC_LINUX/RTSignal.m3", line 82: undefined (Usignal.struct_sigcontext) 1 error encountered [jay at localhost m3core]$ cvs diff src/runtime/PPC_LINUX/RTSignal.m3 Index: src/runtime/PPC_LINUX/RTSignal.m3 =================================================================== RCS file: /usr/cvs/cm3/m3-libs/m3core/src/runtime/PPC_LINUX/RTSignal.m3,v retrieving revision 1.1 diff -r1.1 RTSignal.m3 10c10 < IMPORT RTError, RTProcess, Csignal, Usignal, Uprocess; --- > IMPORT RTError, RTProcess, Csignal, Usignal, Uprocess, Uucontext; 82c82 < scp : Usignal.struct_sigcontext; --- > scp : Uucontext.struct_sigcontext; new source -> compiling RTSignal.m3 "../src/runtime/PPC_LINUX/RTSignal.m3", line 85: unknown qualification '.' (eip) 1 error encountered This I looked into a while. The problem is obvious, the fix is not. For now I replaced whatever.eip with 0. Sometimes PowerPC calls eip srr0, but sometimes not. The first thing I found reading about PowerPC is that there's no instruction counter register, because it is rarely needed directly in code. But anyway, it's still need for traps/exceptions. I'll look at an old winnt.h. And then I am stuck on: new source -> compiling RTThread.m3 "../src/runtime/PPC_LINUX/RTThread.m3", line 88: unknown qualification '.' (sa_handler) "../src/runtime/PPC_LINUX/RTThread.m3", line 89: unknown qualification '.' (empty_sigset_t) "../src/runtime/PPC_LINUX/RTThread.m3", line 91: incompatible types (act) "../src/runtime/PPC_LINUX/RTThread.m3", line 91: VAR actual must be a designator (oact) "../src/runtime/PPC_LINUX/RTThread.m3", line 96: incompatible types (set) "../src/runtime/PPC_LINUX/RTThread.m3", line 96: VAR actual must be a designator (oset) "../src/runtime/PPC_LINUX/RTThread.m3", line 101: incompatible types (set) "../src/runtime/PPC_LINUX/RTThread.m3", line 101: VAR actual must be a designator (oset) "../src/runtime/PPC_LINUX/RTThread.m3", line 108: unknown qualification '.' (sigmask) 9 errors encountered The code: PROCEDURE setup_sigvtalrm (handler: Usignal.SignalHandler) = VAR x: Usignal.struct_sigaction; BEGIN x.sa_handler := LOOPHOLE (handler, Usignal.SignalActionHandler); (* line 88*) x.sa_mask := Usignal.empty_sigset_t; (*89*) x.sa_flags := Usignal.SA_RESTART; (*90*) EVAL Usignal.sigaction (Usignal.SIGVTALRM, ADR (x), NIL); (*91*) END setup_sigvtalrm; Other platforms get away without this stuff by using just "signal" which takes fewer parameters. I ASSUME PPC_LINUX as some interest in more parameters in order to implement vtalarm based threads, instead of pthreads. Usignal does define these types..unless I am looking at the wrong one. Or heck, even the obvious wrong one. Except..overrides..the local package..stuff doesn't need an override to refer to itself, right? Non-standalone binaries also don't work. I think I reported that two weeks ago. I figured that'd come afterward.. There is also: new source -> compiling Long.m3 GenWord.mg: In function `Long__Divide': GenWord.mg:13: Internal compiler error in emit_library_call_value_1, at calls.c:3684 Please submit a full bug report, with preprocessed source if appropriate. See for instructions. though I thought I had gotten past that by building m3cc. Not likely a Modula-3 problem and I could always get around it by making LONGINT only 32 bits (I think "long" is dumb in a name...). [jay at localhost m3core]$ uname -a Linux localhost.localdomain 2.6.15-rc5.ydl.1 #1 Wed Jan 4 16:25:38 EST 2006 ppc ppc ppc GNU/Linux [jay at localhost m3core]$ gcc -v Reading specs from /usr/lib/gcc/ppc64-yellowdog-linux/3.4.4/specs Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --disable-checking --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-java-awt=gtk --host=ppc64-yellowdog-linux --build=ppc64-yellowdog-linux --target=ppc64-yellowdog-linux --with-cpu=default32 Thread model: posix gcc version 3.4.4 20050721 (Yellow Dog 3.4.4-2.ydl.2) This is like Yellow Dog 4.x or so. I don't know why all the ppc64 references. This is an iBook G3 -- 32bit. I guess maybe it can build both -- oh, not that this gcc is in use. Nor do I expect it matters. - Jay _________________________________________________________________ The best games are on Xbox 360. Click here for a special offer on an Xbox 360 Console. http://www.xbox.com/en-US/hardware/wheretobuy/ From jayk123 at hotmail.com Thu Jan 3 23:51:46 2008 From: jayk123 at hotmail.com (Jay) Date: Thu, 3 Jan 2008 22:51:46 +0000 Subject: [M3devel] PPC_LINUX breaks Message-ID: I'll try upgrade.sh instead of my make-dist.py. I got the same gcc error on PPC_DRAWIN too, but that was definitely without building m3cc. Also from an older build. - Jay ---------------------------------------- > From: jayk123 at hotmail.com > To: m3devel at elegosoft.com > Subject: PPC_LINUX breaks > Date: Thu, 3 Jan 2008 22:09:22 +0000 > > > I can't build PPC_LINUX. > > > I can build the compiler with 5.2.6 but then stuck at building m3core with current compiler. > There are several problems. > Some I can fix, some stump me. > This platform still uses non-PTHREADs. > I figure that is worth fixing, but maybe afterward? > > > [jay at localhost m3core]$ /tmp/make-dist/compiler_with_self/bin/cm3 -override -DROOT='/dev2/cm3' > > > new source -> compiling Uucontext.i3 > "../src/unix/linux-ppc/Uucontext.i3", line 102: syntax error: missing ']' > 1 error encountered > > > [jay at localhost m3core]$ cvs diff src/unix/linux-ppc/Uucontext.i3 > Index: src/unix/linux-ppc/Uucontext.i3 > =================================================================== > RCS file: /usr/cvs/cm3/m3-libs/m3core/src/unix/linux-ppc/Uucontext.i3,v > retrieving revision 1.1 > diff -r1.1 Uucontext.i3 > 102c102 > < vrregs: ARRAY[0..32,0..4] OF unsigned_int; > --- >> vrregs: ARRAY[0..32 * 4] OF unsigned_int; > > > new source -> compiling Uucontext.i3 > "../src/unix/linux-ppc/Uucontext.i3", line 92: undefined (double) > "../src/unix/linux-ppc/Uucontext.i3", line 93: undefined (double) > "../src/unix/linux-ppc/Uucontext.i3", line 94: undefined (unsigned_int) > "../src/unix/linux-ppc/Uucontext.i3", line 102: undefined (unsigned_int) > "../src/unix/linux-ppc/Uucontext.i3", line 103: undefined (unsigned_int) > "../src/unix/linux-ppc/Uucontext.i3", line 104: undefined (unsigned_int) > "../src/unix/linux-ppc/Uucontext.i3", line 105: undefined (unsigned_int) > "../src/unix/linux-ppc/Uucontext.i3", line 149: undefined (char) > "../src/unix/linux-ppc/Uucontext.i3", line 10: warning: not used (unsigned_short) > "../src/unix/linux-ppc/Uucontext.i3", line 11: warning: not used (unsigned_short_int) > 8 errors and 2 warnings encountered > > > [jay at localhost m3core]$ cvs diff src/unix/linux-ppc/Uucontext.i3 > Index: src/unix/linux-ppc/Uucontext.i3 > =================================================================== > RCS file: /usr/cvs/cm3/m3-libs/m3core/src/unix/linux-ppc/Uucontext.i3,v > retrieving revision 1.1 > diff -r1.1 Uucontext.i3 > 10,11c10,11 > < IMPORT int, unsigned_long, unsigned_long_int, unsigned_short, void_star, > < unsigned_short_int; > --- >> IMPORT int, unsigned_long, unsigned_long_int, void_star, >> double, unsigned_int, char; > > > > new source -> compiling RTSignal.m3 > "../src/runtime/PPC_LINUX/RTSignal.m3", line 82: undefined (Usignal.struct_sigcontext) > 1 error encountered > > [jay at localhost m3core]$ cvs diff src/runtime/PPC_LINUX/RTSignal.m3 > Index: src/runtime/PPC_LINUX/RTSignal.m3 > =================================================================== > RCS file: /usr/cvs/cm3/m3-libs/m3core/src/runtime/PPC_LINUX/RTSignal.m3,v > retrieving revision 1.1 > diff -r1.1 RTSignal.m3 > 10c10 > < IMPORT RTError, RTProcess, Csignal, Usignal, Uprocess; > --- >> IMPORT RTError, RTProcess, Csignal, Usignal, Uprocess, Uucontext; > 82c82 > < scp : Usignal.struct_sigcontext; > --- >> scp : Uucontext.struct_sigcontext; > > > new source -> compiling RTSignal.m3 > "../src/runtime/PPC_LINUX/RTSignal.m3", line 85: unknown qualification '.' (eip) > 1 error encountered > > This I looked into a while. The problem is obvious, the fix is not. > For now I replaced whatever.eip with 0. > Sometimes PowerPC calls eip srr0, but sometimes not. > The first thing I found reading about PowerPC is that there's no instruction > counter register, because it is rarely needed directly in code. > But anyway, it's still need for traps/exceptions. > I'll look at an old winnt.h. > > > And then I am stuck on: > > > new source -> compiling RTThread.m3 > "../src/runtime/PPC_LINUX/RTThread.m3", line 88: unknown qualification '.' (sa_handler) > "../src/runtime/PPC_LINUX/RTThread.m3", line 89: unknown qualification '.' (empty_sigset_t) > "../src/runtime/PPC_LINUX/RTThread.m3", line 91: incompatible types (act) > "../src/runtime/PPC_LINUX/RTThread.m3", line 91: VAR actual must be a designator (oact) > "../src/runtime/PPC_LINUX/RTThread.m3", line 96: incompatible types (set) > "../src/runtime/PPC_LINUX/RTThread.m3", line 96: VAR actual must be a designator (oset) > "../src/runtime/PPC_LINUX/RTThread.m3", line 101: incompatible types (set) > "../src/runtime/PPC_LINUX/RTThread.m3", line 101: VAR actual must be a designator (oset) > "../src/runtime/PPC_LINUX/RTThread.m3", line 108: unknown qualification '.' (sigmask) > 9 errors encountered > > > The code: > > > PROCEDURE setup_sigvtalrm (handler: Usignal.SignalHandler) = > VAR x: Usignal.struct_sigaction; > BEGIN > x.sa_handler := LOOPHOLE (handler, Usignal.SignalActionHandler); (* line 88*) > x.sa_mask := Usignal.empty_sigset_t; (*89*) > x.sa_flags := Usignal.SA_RESTART; (*90*) > EVAL Usignal.sigaction (Usignal.SIGVTALRM, ADR (x), NIL); (*91*) > END setup_sigvtalrm; > > > Other platforms get away without this stuff by using just "signal" which > takes fewer parameters. I ASSUME PPC_LINUX as some interest in more parameters > in order to implement vtalarm based threads, instead of pthreads. > > > Usignal does define these types..unless I am looking at the wrong one. > Or heck, even the obvious wrong one. > > > Except..overrides..the local package..stuff doesn't need an override to refer to itself, right? > > > Non-standalone binaries also don't work. I think I reported that two weeks ago. > I figured that'd come afterward.. > > > There is also: > new source -> compiling Long.m3 > GenWord.mg: In function `Long__Divide': > GenWord.mg:13: Internal compiler error in emit_library_call_value_1, at calls.c:3684 > Please submit a full bug report, > with preprocessed source if appropriate. > See for instructions. > > > though I thought I had gotten past that by building m3cc. > Not likely a Modula-3 problem and I could always get around it > by making LONGINT only 32 bits (I think "long" is dumb in a name...). > > > [jay at localhost m3core]$ uname -a > Linux localhost.localdomain 2.6.15-rc5.ydl.1 #1 Wed Jan 4 16:25:38 EST 2006 ppc ppc ppc GNU/Linux > > > [jay at localhost m3core]$ gcc -v > Reading specs from /usr/lib/gcc/ppc64-yellowdog-linux/3.4.4/specs > Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --disable-checking --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-java-awt=gtk --host=ppc64-yellowdog-linux --build=ppc64-yellowdog-linux --target=ppc64-yellowdog-linux --with-cpu=default32 > Thread model: posix > gcc version 3.4.4 20050721 (Yellow Dog 3.4.4-2.ydl.2) > > > This is like Yellow Dog 4.x or so. > I don't know why all the ppc64 references. This is an iBook G3 -- 32bit. > I guess maybe it can build both -- oh, not that this gcc is in use. > Nor do I expect it matters. > > > - Jay > _________________________________________________________________ > The best games are on Xbox 360. Click here for a special offer on an Xbox 360 Console. > http://www.xbox.com/en-US/hardware/wheretobuy/ _________________________________________________________________ The best games are on Xbox 360. Click here for a special offer on an Xbox 360 Console. http://www.xbox.com/en-US/hardware/wheretobuy/ From jayk123 at hotmail.com Fri Jan 4 02:55:25 2008 From: jayk123 at hotmail.com (Jay) Date: Fri, 4 Jan 2008 01:55:25 +0000 Subject: [M3devel] test Message-ID: I think this is down again. - Jay _________________________________________________________________ Don't get caught with egg on your face. Play Chicktionary! http://club.live.com/chicktionary.aspx?icid=chick_wlhmtextlink1_dec -------------- next part -------------- An HTML attachment was scrubbed... URL: From stsp at elego.de Fri Jan 4 15:15:23 2008 From: stsp at elego.de (Stefan Sperling) Date: Fri, 4 Jan 2008 15:15:23 +0100 Subject: [M3devel] PPC_LINUX breaks In-Reply-To: References: Message-ID: <20080104141523.GC1459@ted.stsp.lan> On Thu, Jan 03, 2008 at 10:09:22PM +0000, Jay wrote: > > I can't build PPC_LINUX. It's been broken at least since the 5.4 release was made. Back then I failed to build it, and we decided to drop it from the 5.4 release. It needs fixing. -- Stefan Sperling Software Developer elego Software Solutions GmbH HRB 77719 Gustav-Meyer-Allee 25, Gebaeude 12 Tel: +49 30 23 45 86 96 13355 Berlin Fax: +49 30 23 45 86 95 http://www.elego.de Geschaeftsfuehrer: Olaf Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From hosking at cs.purdue.edu Fri Jan 4 15:43:31 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 4 Jan 2008 09:43:31 -0500 Subject: [M3devel] PPC_LINUX breaks In-Reply-To: <20080104141523.GC1459@ted.stsp.lan> References: <20080104141523.GC1459@ted.stsp.lan> Message-ID: <65C183A8-6102-49E9-9C38-8D59C966E42D@cs.purdue.edu> Has anyone built PPC_LINUX? I've never tried. On Jan 4, 2008, at 9:15 AM, Stefan Sperling wrote: > On Thu, Jan 03, 2008 at 10:09:22PM +0000, Jay wrote: >> >> I can't build PPC_LINUX. > > It's been broken at least since the 5.4 release was made. > > Back then I failed to build it, and we decided to drop > it from the 5.4 release. It needs fixing. > > -- > Stefan Sperling Software Developer > elego Software Solutions GmbH HRB 77719 > Gustav-Meyer-Allee 25, Gebaeude 12 Tel: +49 30 23 45 86 96 > 13355 Berlin Fax: +49 30 23 45 86 95 > http://www.elego.de Geschaeftsfuehrer: Olaf Wagner From dabenavidesd at yahoo.es Fri Jan 4 19:34:29 2008 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Fri, 4 Jan 2008 19:34:29 +0100 (CET) Subject: [M3devel] Ubuntu Gutsy problems Message-ID: <122805.74554.qm@web27110.mail.ukl.yahoo.com> Hi all: I'm trying to compile the first step bootstrap compiler on ubuntu gutsy 2.6.22-14-386, and I get into segmentation fault: adminfbd at fbd-desktop:/home/daniel/code/cm3/scripts$ sudo ./do-pkg.sh buildship m3core CM3C = /home/daniel/code/cm3/scripts/pkgmap.sh -c "/usr/local/cm3/bin/cm3 -build -DROOT='/home/daniel/code/cm3' && /usr/local/cm3/bin/cm3 -ship -DROOT='/home/daniel/code/cm3' " m3core === package /home/daniel/code/cm3/m3-libs/m3core === +++ /usr/local/cm3/bin/cm3 -build -DROOT='/home/daniel/code/cm3' && /usr/local/cm3/bin/cm3 -ship -DROOT='/home/daniel/code/cm3' +++ --- building in LINUXLIBC6 --- ignoring ../src/m3overrides new source -> compiling RTHooks.i3 RTHooks.i3: In function 'RTHooks_I3': RTHooks.i3:146: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling RT0.i3 RT0.i3: In function 'RT0_I3': RT0.i3:230: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling RuntimeError.i3 RuntimeError.i3: In function 'RuntimeError_I3': I used the new binaries of the d5.5.0 branch. Thanks --------------------------------- Web Revelaci?n Yahoo! 2007: Premio Favorita del P?blico - ?Vota tu preferida! -------------- next part -------------- An HTML attachment was scrubbed... URL: From dabenavidesd at yahoo.es Fri Jan 4 19:42:40 2008 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Fri, 4 Jan 2008 19:42:40 +0100 (CET) Subject: [M3devel] Ubuntu Gutsy problems In-Reply-To: <122805.74554.qm@web27110.mail.ukl.yahoo.com> Message-ID: <735847.33274.qm@web27102.mail.ukl.yahoo.com> Hi: Here is a stacktrace of cm3cg, compiled with a gcc 4.1 compiler (of this machine). daniel at fbd-desktop:~$ gdb cm3cg GNU gdb 6.6-debian Copyright (C) 2006 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i486-linux-gnu"... Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1". (gdb) run RTHooks.ic -o RTHooks.is -g Starting program: /usr/local/cm3/bin/cm3cg RTHooks.ic -o RTHooks.is -g Program received signal SIGSEGV, Segmentation fault. 0x080d8e6d in gen_field_die () (gdb) where #0 0x080d8e6d in gen_field_die () #1 0x080dc988 in gen_decl_die () #2 0x080d9d61 in gen_type_die () #3 0x080dcb45 in gen_decl_die () #4 0x080dcd34 in dwarf2out_decl () #5 0x080dcd55 in dwarf2out_type_decl () #6 0x08050178 in debug_struct () #7 0x080505ea in m3cg_declare_formal () #8 0x080515b6 in m3_parse_file () #9 0x082682aa in toplev_main () #10 0x080568ca in main () "Daniel Alejandro Benavides D." escribi?: Hi all: I'm trying to compile the first step bootstrap compiler on ubuntu gutsy 2.6.22-14-386, and I get into segmentation fault: adminfbd at fbd-desktop:/home/daniel/code/cm3/scripts$ sudo ./do-pkg.sh buildship m3core CM3C = /home/daniel/code/cm3/scripts/pkgmap.sh -c "/usr/local/cm3/bin/cm3 -build -DROOT='/home/daniel/code/cm3' && /usr/local/cm3/bin/cm3 -ship -DROOT='/home/daniel/code/cm3' " m3core === package /home/daniel/code/cm3/m3-libs/m3core === +++ /usr/local/cm3/bin/cm3 -build -DROOT='/home/daniel/code/cm3' && /usr/local/cm3/bin/cm3 -ship -DROOT='/home/daniel/code/cm3' +++ --- building in LINUXLIBC6 --- ignoring ../src/m3overrides new source -> compiling RTHooks.i3 RTHooks.i3: In function 'RTHooks_I3': RTHooks.i3:146: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling RT0.i3 RT0.i3: In function 'RT0_I3': RT0.i3:230: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling RuntimeError.i3 RuntimeError.i3: In function 'RuntimeError_I3': I used the new binaries of the d5.5.0 branch. Thanks --------------------------------- Web Revelaci?n Yahoo! 2007: Premio Favorita del P?blico - ?Vota tu preferida! --------------------------------- Web Revelaci?n Yahoo! 2007: Premio Favorita del P?blico - ?Vota tu preferida! -------------- next part -------------- An HTML attachment was scrubbed... URL: From dabenavidesd at yahoo.es Fri Jan 4 19:58:49 2008 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Fri, 4 Jan 2008 19:58:49 +0100 (CET) Subject: [M3devel] Ubuntu Gutsy problems In-Reply-To: <735847.33274.qm@web27102.mail.ukl.yahoo.com> Message-ID: <546440.55084.qm@web27111.mail.ukl.yahoo.com> Hi: It gets compiled well when using -gstabs command line option of cm3cg, as Tony marked on this post, so for now we can change the cm3.cfg debug variable of m3_backend: https://mail.elegosoft.com/pipermail/m3devel/2007-June/000238.html proc m3_backend (source, object, optimize, debug) is local args = [ "-quiet", source, "-o", object ] if optimize args += "-O" end if debug args += "-gstabs" end (gdb) run RTHooks.ic -o RTHooks.is -gstabs Starting program: /usr/local/cm3/bin/cm3cg RTHooks.ic -o RTHooks.is -gstabs RTHooks_I3 Execution times (seconds) TOTAL : 0.02 0.00 0.02 596 kB Program exited normally. (gdb) Thanks "Daniel Alejandro Benavides D." escribi?: Hi: Here is a stacktrace of cm3cg, compiled with a gcc 4.1 compiler (of this machine). daniel at fbd-desktop:~$ gdb cm3cg GNU gdb 6.6-debian Copyright (C) 2006 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i486-linux-gnu"... Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1". (gdb) run RTHooks.ic -o RTHooks.is -g Starting program: /usr/local/cm3/bin/cm3cg RTHooks.ic -o RTHooks.is -g Program received signal SIGSEGV, Segmentation fault. 0x080d8e6d in gen_field_die () (gdb) where #0 0x080d8e6d in gen_field_die () #1 0x080dc988 in gen_decl_die () #2 0x080d9d61 in gen_type_die () #3 0x080dcb45 in gen_decl_die () #4 0x080dcd34 in dwarf2out_decl () #5 0x080dcd55 in dwarf2out_type_decl () #6 0x08050178 in debug_struct () #7 0x080505ea in m3cg_declare_formal () #8 0x080515b6 in m3_parse_file () #9 0x082682aa in toplev_main () #10 0x080568ca in main () "Daniel Alejandro Benavides D." escribi?: Hi all: I'm trying to compile the first step bootstrap compiler on ubuntu gutsy 2.6.22-14-386, and I get into segmentation fault: adminfbd at fbd-desktop:/home/daniel/code/cm3/scripts$ sudo ./do-pkg.sh buildship m3core CM3C = /home/daniel/code/cm3/scripts/pkgmap.sh -c "/usr/local/cm3/bin/cm3 -build -DROOT='/home/daniel/code/cm3' && /usr/local/cm3/bin/cm3 -ship -DROOT='/home/daniel/code/cm3' " m3core === package /home/daniel/code/cm3/m3-libs/m3core === +++ /usr/local/cm3/bin/cm3 -build -DROOT='/home/daniel/code/cm3' && /usr/local/cm3/bin/cm3 -ship -DROOT='/home/daniel/code/cm3' +++ --- building in LINUXLIBC6 --- ignoring ../src/m3overrides new source -> compiling RTHooks.i3 RTHooks.i3: In function 'RTHooks_I3': RTHooks.i3:146: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling RT0.i3 RT0.i3: In function 'RT0_I3': RT0.i3:230: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling RuntimeError.i3 RuntimeError.i3: In function 'RuntimeError_I3': I used the new binaries of the d5.5.0 branch. Thanks --------------------------------- Web Revelaci?n Yahoo! 2007: Premio Favorita del P?blico - ?Vota tu preferida! --------------------------------- Web Revelaci?n Yahoo! 2007: Premio Favorita del P?blico - ?Vota tu preferida! --------------------------------- Web Revelaci?n Yahoo! 2007: Premio Favorita del P?blico - ?Vota tu preferida! -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Fri Jan 4 20:17:23 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 4 Jan 2008 14:17:23 -0500 Subject: [M3devel] Ubuntu Gutsy problems In-Reply-To: <735847.33274.qm@web27102.mail.ukl.yahoo.com> References: <735847.33274.qm@web27102.mail.ukl.yahoo.com> Message-ID: <70ABAF58-FC5A-4FBB-8CCC-BEC58BAC73E4@cs.purdue.edu> Did you update your m3cg backend? Also, make sure your config file has "-gstabs" defined in the debug portion of the arguments to the m3_backend. It seems you are suffering from a lag between the 4.1 backend and config file and the newer one. On Jan 4, 2008, at 1:42 PM, Daniel Alejandro Benavides D. wrote: > Hi: > Here is a stacktrace of cm3cg, compiled with a gcc 4.1 compiler (of > this machine). > > daniel at fbd-desktop:~$ gdb cm3cg > GNU gdb 6.6-debian > Copyright (C) 2006 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, > and you are > welcome to change it and/or distribute copies of it under certain > conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for > details. > This GDB was configured as "i486-linux-gnu"... > Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so. > 1". > (gdb) run RTHooks.ic -o RTHooks.is -g > Starting program: /usr/local/cm3/bin/cm3cg RTHooks.ic -o RTHooks.is -g > > Program received signal SIGSEGV, Segmentation fault. > 0x080d8e6d in gen_field_die () > (gdb) where > #0 0x080d8e6d in gen_field_die () > #1 0x080dc988 in gen_decl_die () > #2 0x080d9d61 in gen_type_die () > #3 0x080dcb45 in gen_decl_die () > #4 0x080dcd34 in dwarf2out_decl () > #5 0x080dcd55 in dwarf2out_type_decl () > #6 0x08050178 in debug_struct () > #7 0x080505ea in m3cg_declare_formal () > #8 0x080515b6 in m3_parse_file () > #9 0x082682aa in toplev_main () > #10 0x080568ca in main () > > > "Daniel Alejandro Benavides D." escribi?: > Hi all: > I'm trying to compile the first step bootstrap compiler on ubuntu > gutsy 2.6.22-14-386, and I get into segmentation fault: > > adminfbd at fbd-desktop:/home/daniel/code/cm3/scripts$ sudo ./do- > pkg.sh buildship m3core > CM3C = > /home/daniel/code/cm3/scripts > /pkgmap.sh -c "/usr/local/cm3/bin/cm3 -build -DROOT='/home/daniel/ > code/cm3' && /usr/local/cm3/bin/cm3 -ship -DROOT='/home/daniel/ > code/cm3' " m3core > === package /home/daniel/code/cm3/m3-libs/m3core === > +++ /usr/local/cm3/bin/cm3 -build -DROOT='/home/daniel/code/cm3' > && /usr/local/cm3/bin/cm3 -ship -DROOT='/home/daniel/code/cm3' +++ > --- building in LINUXLIBC6 --- > > ignoring ../src/m3overrides > > new source -> compiling RTHooks.i3 > RTHooks.i3: In function 'RTHooks_I3': > RTHooks.i3:146: internal compiler error: Segmentation fault > Please submit a full bug report, > with preprocessed source if appropriate. > See for instructions. > new source -> compiling RT0.i3 > RT0.i3: In function 'RT0_I3': > RT0.i3:230: internal compiler error: Segmentation fault > Please submit a full bug report, > with preprocessed source if appropriate. > See for instructions. > new source -> compiling RuntimeError.i3 > RuntimeError.i3: In function 'RuntimeError_I3': > > I used the new binaries of the d5.5.0 branch. > > Thanks > > Web Revelaci?n Yahoo! 2007: > Premio Favorita del P?blico - ?Vota tu preferida! > > > Web Revelaci?n Yahoo! 2007: > Premio Favorita del P?blico - ?Vota tu preferida! From jayk123 at hotmail.com Fri Jan 4 20:58:45 2008 From: jayk123 at hotmail.com (Jay) Date: Fri, 4 Jan 2008 19:58:45 +0000 Subject: [M3devel] PPC_LINUX breaks In-Reply-To: <65C183A8-6102-49E9-9C38-8D59C966E42D@cs.purdue.edu> References: <20080104141523.GC1459@ted.stsp.lan> <65C183A8-6102-49E9-9C38-8D59C966E42D@cs.purdue.edu> Message-ID: I figured out a bunch here. a) the diffs I showed. b) "nip" is "next instruction pointer"; that's what you want in the SegV function. And the last parameter should be void_star instead of int. You can use like pt_regs.nip for the old definition or uc_regs.gprregs[PT_NIP] for the new definition. I have diffs here. c) Usignal.i3 had the stuff vtalarm stuff removed, which PPC_LINUX still uses, "POSIX threads" vs. "PThreads" (oh the names..), though perhaps broken by setjmp/longjmp "scrambling". Is it possible to break up an interface into linux-common/foo.i3 linux-ppc/foo.i3 I think not. Shall we just go ahead and translate LINUX_PPC pthread.h into Modula-3? (Btw, doesn't anyone find all this header rewriting sleazy? Or they have to maintain compat anyway so no problem?) The error messages are poor. Let's say I.T does not exist. VAR x : I.T; (* no error *) x.foo = bar; (* "unknown qualification" *) FROM I IMPORT T; (* "T not exported" -- better, but should say T does not exist I was fumbling around with needing a module to say "EXPORTS" or to capitalize the Interface directive in m3makefile, neither of which seemed right *) - Jay > From: hosking at cs.purdue.edu > Date: Fri, 4 Jan 2008 09:43:31 -0500 > To: stsp at elego.de > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] PPC_LINUX breaks > > Has anyone built PPC_LINUX? I've never tried. > > On Jan 4, 2008, at 9:15 AM, Stefan Sperling wrote: > > > On Thu, Jan 03, 2008 at 10:09:22PM +0000, Jay wrote: > >> > >> I can't build PPC_LINUX. > > > > It's been broken at least since the 5.4 release was made. > > > > Back then I failed to build it, and we decided to drop > > it from the 5.4 release. It needs fixing. > > > > -- > > Stefan Sperling Software Developer > > elego Software Solutions GmbH HRB 77719 > > Gustav-Meyer-Allee 25, Gebaeude 12 Tel: +49 30 23 45 86 96 > > 13355 Berlin Fax: +49 30 23 45 86 95 > > http://www.elego.de Geschaeftsfuehrer: Olaf Wagner > _________________________________________________________________ Share life as it happens with the new Windows Live. http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Fri Jan 4 21:45:06 2008 From: jayk123 at hotmail.com (Jay) Date: Fri, 4 Jan 2008 20:45:06 +0000 Subject: [M3devel] PPC_LINUX breaks In-Reply-To: References: <20080104141523.GC1459@ted.stsp.lan> <65C183A8-6102-49E9-9C38-8D59C966E42D@cs.purdue.edu> Message-ID: I'm confused here on what got deleted. I keep seeing it present. I swear I saw the diff though.. :( Browing CVS is such a pain. - Jay From: jayk123 at hotmail.com To: hosking at cs.purdue.edu; stsp at elego.de Date: Fri, 4 Jan 2008 19:58:45 +0000 CC: m3devel at elegosoft.com Subject: Re: [M3devel] PPC_LINUX breaks I figured out a bunch here. a) the diffs I showed. b) "nip" is "next instruction pointer"; that's what you want in the SegV function. And the last parameter should be void_star instead of int. You can use like pt_regs.nip for the old definition or uc_regs.gprregs[PT_NIP] for the new definition. I have diffs here. c) Usignal.i3 had the stuff vtalarm stuff removed, which PPC_LINUX still uses, "POSIX threads" vs. "PThreads" (oh the names..), though perhaps broken by setjmp/longjmp "scrambling". Is it possible to break up an interface into linux-common/foo.i3 linux-ppc/foo.i3 I think not. Shall we just go ahead and translate LINUX_PPC pthread.h into Modula-3? (Btw, doesn't anyone find all this header rewriting sleazy? Or they have to maintain compat anyway so no problem?) The error messages are poor. Let's say I.T does not exist. VAR x : I.T; (* no error *) x.foo = bar; (* "unknown qualification" *) FROM I IMPORT T; (* "T not exported" -- better, but should say T does not exist I was fumbling around with needing a module to say "EXPORTS" or to capitalize the Interface directive in m3makefile, neither of which seemed right *) - Jay > From: hosking at cs.purdue.edu > Date: Fri, 4 Jan 2008 09:43:31 -0500 > To: stsp at elego.de > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] PPC_LINUX breaks > > Has anyone built PPC_LINUX? I've never tried. > > On Jan 4, 2008, at 9:15 AM, Stefan Sperling wrote: > > > On Thu, Jan 03, 2008 at 10:09:22PM +0000, Jay wrote: > >> > >> I can't build PPC_LINUX. > > > > It's been broken at least since the 5.4 release was made. > > > > Back then I failed to build it, and we decided to drop > > it from the 5.4 release. It needs fixing. > > > > -- > > Stefan Sperling Software Developer > > elego Software Solutions GmbH HRB 77719 > > Gustav-Meyer-Allee 25, Gebaeude 12 Tel: +49 30 23 45 86 96 > > 13355 Berlin Fax: +49 30 23 45 86 95 > > http://www.elego.de Geschaeftsfuehrer: Olaf Wagner > Share life as it happens with the new Windows Live. Start sharing! _________________________________________________________________ Share life as it happens with the new Windows Live. http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Fri Jan 4 22:10:59 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 04 Jan 2008 22:10:59 +0100 Subject: [M3devel] M3 concerns In-Reply-To: <477B7629.1E75.00D7.1@scires.com> References: <477B7629.1E75.00D7.1@scires.com> Message-ID: <20080104221059.uwf80xrms0gw8880@mail.elegosoft.com> Quoting Randy Coleburn : > I've seen quite a number of m3commit and m3devel messages lately. > Many of these give the appearance of "thinking out loud" with > various commits followed by apparent reversals. In many cases the > m3commit log messages are terse and don't give the rationale behind > the change. > > For those of us in the M3 community who rely upon the stability of > the libraries and core M3 principles, these types of messages cause > concern. While I appreciate everyone's efforts to move forward, I > don't want to abandon the great care that went into formulating this > language. I agree that some of the recent commit messages seem to give the impression of quick changes. More care should be taken here. I'm not really concerned about the stability of the whole system, as those changes did mostly concern build infrastructure and minor fixes and adaptions. > Question: As various people make contributions and changes, is > there any group of folks who is verifying that the changes don't > break existing code or core principles? Another idea would be to > have a series of test batteries that have to be passed before > changes can be accepted. I know of a number of projects where many > people contribute, but the contributions have to be vetted by > passing some tests. Automated regression tests have been on my agenda for CM3 for a long time. I coulnd't contribute much myself during the last year, as I've been very busy. I've done a little bit in the last two weeks, and others have also worked in this area, so that I hope we will be able to present some working regression test setup within some days. At least we'll have some initial setup that can be extended and improved. More to this topic in another mail. > Without these types of controls, I fear that good forward progress > will inevitably be hampered or compromised by changes made by > someone who hasn't completely thought out and tested the > ramifications of those changes. Yes, this is the usual problem with all systems without periodic automatic regression testing. > For example, I've tried to get cm3 working for me on Windows XP > several times. I still can't seem to get the "current" system to > build correctly on XP. In the past, I have on occasion gotten the > "system" to build, but then some of my programs don't work correctly > when rebuilt using the new cm3. Thus, some changes somewhere have > "broken" my code, yet all of my code uses the "safe" subset of the > language. If I go back to my old reliable cm3 version 4.1 (the last > one put out before Critical Mass, Inc. threw in the towel), my code > compiles and works, even on Windows XP, even using Trestle, > FormsVBT, NetObj, cross-platform pickles (e.g., pickles shared > between Windows & Unix boxes), etc.! Much of my code was originally > developed under Windows NT, so I think it is a tribute to the > original language developers that my code and their compiler work > through various OS version upgrades (NT, 2000, XP) and changes to > the underlying C/C++ compilers used to build the core components. Ah well, Windows is a somewhat special topic. I even haven't a system here for tests, and most of the other contributors don't use it either. I was of the opinion that Jay Krell had fixes or workarounds for most current problems (except for the missing LONGINT support), but I haven't tried his distribution archives yet. It would indeed be very helpful if we could setup regression tests on Windows, too. As for the stability and interoperability, this is a very complex requirement that needs much care and testing. It is difficult to achieve in an open source project, at least in one with so few contributors. I'm sure Critical Mass did an excellent job on this, but it's been a commercial company with other organization and resources. We'll have to become better in this respect step by step. It would also be possible to define a group of reviewers for every change, but I doubt that there would be enough competent volunteers, and I'm afraid that it would rather repress development of CM3. And we really need to have development, as the underlying systems and techniques change and we need to adapt to that. So I'd vote for free commits for everybody, as long as there are not too many contributors, and setup of continually improved regression testing. And we don't need to worry, as all changes can be reverted; we won't lose development history with CVS. > I would appreciate constructive feedback on this topic. I hope this has been constructive enough, Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From hosking at cs.purdue.edu Fri Jan 4 22:17:19 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 4 Jan 2008 16:17:19 -0500 Subject: [M3devel] M3 concerns In-Reply-To: <20080104221059.uwf80xrms0gw8880@mail.elegosoft.com> References: <477B7629.1E75.00D7.1@scires.com> <20080104221059.uwf80xrms0gw8880@mail.elegosoft.com> Message-ID: <063F2D47-D837-4E11-9001-D152527E8694@cs.purdue.edu> My comments embedded: On Jan 4, 2008, at 4:10 PM, Olaf Wagner wrote: > Quoting Randy Coleburn : > >> For example, I've tried to get cm3 working for me on Windows XP >> several times. I still can't seem to get the "current" system to >> build correctly on XP. In the past, I have on occasion gotten >> the "system" to build, but then some of my programs don't work >> correctly when rebuilt using the new cm3. Thus, some changes >> somewhere have "broken" my code, yet all of my code uses the >> "safe" subset of the language. If I go back to my old reliable >> cm3 version 4.1 (the last one put out before Critical Mass, Inc. >> threw in the towel), my code compiles and works, even on Windows >> XP, even using Trestle, FormsVBT, NetObj, cross-platform pickles >> (e.g., pickles shared between Windows & Unix boxes), etc.! Much >> of my code was originally developed under Windows NT, so I think >> it is a tribute to the original language developers that my code >> and their compiler work through various OS version upgrades (NT, >> 2000, XP) and changes to the underlying C/C++ compilers used to >> build the core components. > > Ah well, Windows is a somewhat special topic. I even haven't a system > here for tests, and most of the other contributors don't use it > either. > I was of the opinion that Jay Krell had fixes or workarounds for most > current problems (except for the missing LONGINT support), but I > haven't > tried his distribution archives yet. It would indeed be very helpful > if we could setup regression tests on Windows, too. LONGINT = INTEGER on Windows, which is fine as far as it goes (everything builds appropriately), but not particularly useful. > As for the stability and interoperability, this is a very complex > requirement that needs much care and testing. It is difficult to > achieve > in an open source project, at least in one with so few contributors. > I'm sure Critical Mass did an excellent job on this, but it's been > a commercial company with other organization and resources. We'll > have to become better in this respect step by step. > > It would also be possible to define a group of reviewers for every > change, but I doubt that there would be enough competent volunteers, > and I'm afraid that it would rather repress development of CM3. > And we really need to have development, as the underlying systems and > techniques change and we need to adapt to that. So I'd vote for > free commits for everybody, as long as there are not too many > contributors, and setup of continually improved regression testing. > And we don't need to worry, as all changes can be reverted; we won't > lose development history with CVS. One option is to have moderated commits for non-core developers. After someone has earned the trust of the core developers they can be elected as a member of the core team. This approach is used with the Jikes RVM (www.jikesrvm.org). From jayk123 at hotmail.com Fri Jan 4 22:26:08 2008 From: jayk123 at hotmail.com (Jay) Date: Fri, 4 Jan 2008 21:26:08 +0000 Subject: [M3devel] PPC_LINUX breaks In-Reply-To: References: <20080104141523.GC1459@ted.stsp.lan> <65C183A8-6102-49E9-9C38-8D59C966E42D@cs.purdue.edu> Message-ID: [redundant] ok, I commited fixes for what I have seen so far. There was no delete, though probably changes -- sigset changes from int to 1024 bits for example, or somesuch. I'm sure you all see the commits. Given that PPC_LINUX still uses usermode threads, could have "that" problem, we'll see.. Gotta go for a while now. - Jay From: jayk123 at hotmail.com To: hosking at cs.purdue.edu; stsp at elego.de CC: m3devel at elegosoft.com Subject: RE: [M3devel] PPC_LINUX breaks Date: Fri, 4 Jan 2008 20:45:06 +0000 I'm confused here on what got deleted. I keep seeing it present. I swear I saw the diff though.. :( Browing CVS is such a pain. - Jay From: jayk123 at hotmail.com To: hosking at cs.purdue.edu; stsp at elego.de Date: Fri, 4 Jan 2008 19:58:45 +0000 CC: m3devel at elegosoft.com Subject: Re: [M3devel] PPC_LINUX breaks I figured out a bunch here. a) the diffs I showed. b) "nip" is "next instruction pointer"; that's what you want in the SegV function. And the last parameter should be void_star instead of int. You can use like pt_regs.nip for the old definition or uc_regs.gprregs[PT_NIP] for the new definition. I have diffs here. c) Usignal.i3 had the stuff vtalarm stuff removed, which PPC_LINUX still uses, "POSIX threads" vs. "PThreads" (oh the names..), though perhaps broken by setjmp/longjmp "scrambling". Is it possible to break up an interface into linux-common/foo.i3 linux-ppc/foo.i3 I think not. Shall we just go ahead and translate LINUX_PPC pthread.h into Modula-3? (Btw, doesn't anyone find all this header rewriting sleazy? Or they have to maintain compat anyway so no problem?) The error messages are poor. Let's say I.T does not exist. VAR x : I.T; (* no error *) x.foo = bar; (* "unknown qualification" *) FROM I IMPORT T; (* "T not exported" -- better, but should say T does not exist I was fumbling around with needing a module to say "EXPORTS" or to capitalize the Interface directive in m3makefile, neither of which seemed right *) - Jay > From: hosking at cs.purdue.edu > Date: Fri, 4 Jan 2008 09:43:31 -0500 > To: stsp at elego.de > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] PPC_LINUX breaks > > Has anyone built PPC_LINUX? I've never tried. > > On Jan 4, 2008, at 9:15 AM, Stefan Sperling wrote: > > > On Thu, Jan 03, 2008 at 10:09:22PM +0000, Jay wrote: > >> > >> I can't build PPC_LINUX. > > > > It's been broken at least since the 5.4 release was made. > > > > Back then I failed to build it, and we decided to drop > > it from the 5.4 release. It needs fixing. > > > > -- > > Stefan Sperling Software Developer > > elego Software Solutions GmbH HRB 77719 > > Gustav-Meyer-Allee 25, Gebaeude 12 Tel: +49 30 23 45 86 96 > > 13355 Berlin Fax: +49 30 23 45 86 95 > > http://www.elego.de Geschaeftsfuehrer: Olaf Wagner > Share life as it happens with the new Windows Live. Start sharing! Share life as it happens with the new Windows Live. Start sharing! _________________________________________________________________ Put your friends on the big screen with Windows Vista? + Windows Live?. http://www.microsoft.com/windows/shop/specialoffers.mspx?ocid=TXT_TAGLM_CPC_MediaCtr_bigscreen_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Fri Jan 4 22:32:52 2008 From: jayk123 at hotmail.com (Jay) Date: Fri, 4 Jan 2008 21:32:52 +0000 Subject: [M3devel] Darwin upgrade/fingerprint error In-Reply-To: References: <20080104141523.GC1459@ted.stsp.lan> <65C183A8-6102-49E9-9C38-8D59C966E42D@cs.purdue.edu> Message-ID: Starting with an older release on PPC_DARWIN and running upgrade.sh, I keep getting: === package /dev2/cm3/m3-sys/m3middle === +++ cm3 -build -DROOT='/dev2/cm3' -DCM3_VERSION_TEXT='d5.5.1' -DCM3_VERSION_NUMBER='050501' -DCM3_LAST_CHANGED='2007-12-30' && cm3 -ship -DROOT='/dev2/cm3' -DCM3_VERSION_TEXT='d5.5.1' -DCM3_VERSION_NUMBER='050501' -DCM3_LAST_CHANGED='2007-12-30' +++ --- building in PPC_DARWIN --- ignoring ../src/m3overrides stale imports -> compiling CoffTime.m3 stale imports -> compiling M3Process.i3 stale imports -> compiling M3Process.m3 stale imports -> compiling TFloat.m3 Fatal Error: bad version stamps: TFloat.m3 version stamp mismatch: TargetMap.Float_types <31f4d45a27120488> => TFloat.m3 <663449bb704e9c85> => TargetMap.i3 *** execution of failed *** I assume this will be fixed by: ijayk:/dev2/cm3/scripts jay$ cvs diff upgrade.sh Index: upgrade.sh =================================================================== RCS file: /usr/cvs/cm3/scripts/upgrade.sh,v retrieving revision 1.4 diff -r1.4 upgrade.sh 52a53,55 > echo "$ROOT/scripts/do-pkg.sh" "$@" "realclean ${P}" > "$ROOT/scripts/do-pkg.sh" "$@" "realclean" ${P} || exit 1 > 58a62,64 > echo "$ROOT/scripts/do-cm3-core.sh" "$@" "realclean" > "$ROOT/scripts/do-cm3-core.sh" "$@" "realclean" || exit 1 > Will that really harm/slow anyone's workflow? In fact, notice how the older upgrade, while broken for other reasons, did this dance with upgrading and restoring the pkg store. win\upgrade.cmd still does. Something to consider.. (And I realize that backup/restore of install/pkg is different than realclean of root/*, so maybe that diff is not the fix.) Though it is a problem to manage the versions, in doing the backup/restore. Perhaps this all falls under the heading of -- not worth automating, people know what they are doing, else they can pickup a current binary distribution?? I'll get something working locally no doubt, I don't need any further help. :) (Though past help has helped shed light here, the local/global/ship thing is still just a tad vague to me and I'm just slightly unconvinced it has to be this way, but probably it does, what with necessary circularities between compiler and runtime, building with an older compiler and all that...) - Jay _________________________________________________________________ Share life as it happens with the new Windows Live. http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Fri Jan 4 22:51:48 2008 From: jayk123 at hotmail.com (Jay) Date: Fri, 4 Jan 2008 21:51:48 +0000 Subject: [M3devel] Darwin upgrade/fingerprint error In-Reply-To: References: <20080104141523.GC1459@ted.stsp.lan> <65C183A8-6102-49E9-9C38-8D59C966E42D@cs.purdue.edu> Message-ID: (probably OMIT_GCC=1 on the second clean and build; I assume it has no dependency into the tree and it'd just be building the same thing a second time, slowly) From: jayk123 at hotmail.com To: m3devel at elegosoft.com Date: Fri, 4 Jan 2008 21:32:52 +0000 Subject: [M3devel] Darwin upgrade/fingerprint error Starting with an older release on PPC_DARWIN and running upgrade.sh, I keep getting: === package /dev2/cm3/m3-sys/m3middle === +++ cm3 -build -DROOT='/dev2/cm3' -DCM3_VERSION_TEXT='d5.5.1' -DCM3_VERSION_NUMBER='050501' -DCM3_LAST_CHANGED='2007-12-30' && cm3 -ship -DROOT='/dev2/cm3' -DCM3_VERSION_TEXT='d5.5.1' -DCM3_VERSION_NUMBER='050501' -DCM3_LAST_CHANGED='2007-12-30' +++ --- building in PPC_DARWIN --- ignoring ../src/m3overrides stale imports -> compiling CoffTime.m3 stale imports -> compiling M3Process.i3 stale imports -> compiling M3Process.m3 stale imports -> compiling TFloat.m3 Fatal Error: bad version stamps: TFloat.m3 version stamp mismatch: TargetMap.Float_types <31f4d45a27120488> => TFloat.m3 <663449bb704e9c85> => TargetMap.i3 *** execution of failed *** I assume this will be fixed by: ijayk:/dev2/cm3/scripts jay$ cvs diff upgrade.sh Index: upgrade.sh =================================================================== RCS file: /usr/cvs/cm3/scripts/upgrade.sh,v retrieving revision 1.4 diff -r1.4 upgrade.sh 52a53,55 > echo "$ROOT/scripts/do-pkg.sh" "$@" "realclean ${P}" > "$ROOT/scripts/do-pkg.sh" "$@" "realclean" ${P} || exit 1 > 58a62,64 > echo "$ROOT/scripts/do-cm3-core.sh" "$@" "realclean" > "$ROOT/scripts/do-cm3-core.sh" "$@" "realclean" || exit 1 > Will that really harm/slow anyone's workflow? In fact, notice how the older upgrade, while broken for other reasons, did this dance with upgrading and restoring the pkg store. win\upgrade.cmd still does. Something to consider.. (And I realize that backup/restore of install/pkg is different than realclean of root/*, so maybe that diff is not the fix.) Though it is a problem to manage the versions, in doing the backup/restore. Perhaps this all falls under the heading of -- not worth automating, people know what they are doing, else they can pickup a current binary distribution?? I'll get something working locally no doubt, I don't need any further help. :) (Though past help has helped shed light here, the local/global/ship thing is still just a tad vague to me and I'm just slightly unconvinced it has to be this way, but probably it does, what with necessary circularities between compiler and runtime, building with an older compiler and all that...) - Jay Share life as it happens with the new Windows Live. Start sharing! _________________________________________________________________ Get the power of Windows + Web with the new Windows Live. http://www.windowslive.com?ocid=TXT_TAGHM_Wave2_powerofwindows_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Sat Jan 5 01:13:35 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 05 Jan 2008 01:13:35 +0100 Subject: [M3devel] M3 concerns In-Reply-To: <063F2D47-D837-4E11-9001-D152527E8694@cs.purdue.edu> References: <477B7629.1E75.00D7.1@scires.com> <20080104221059.uwf80xrms0gw8880@mail.elegosoft.com> <063F2D47-D837-4E11-9001-D152527E8694@cs.purdue.edu> Message-ID: <20080105011335.n767h3zbz4gcgk4k@mail.elegosoft.com> Quoting Tony Hosking : > My comments embedded: > > On Jan 4, 2008, at 4:10 PM, Olaf Wagner wrote: >> Ah well, Windows is a somewhat special topic. I even haven't a system >> here for tests, and most of the other contributors don't use it either. >> I was of the opinion that Jay Krell had fixes or workarounds for most >> current problems (except for the missing LONGINT support), but I haven't >> tried his distribution archives yet. It would indeed be very helpful >> if we could setup regression tests on Windows, too. > > LONGINT = INTEGER on Windows, which is fine as far as it goes > (everything builds appropriately), but not particularly useful. I know that it should run this way, but pickles for example wouldn't be exchangeable then, would they? Has anybody tested pickle support for LONGINT yet? >> It would also be possible to define a group of reviewers for every >> change, but I doubt that there would be enough competent volunteers, >> and I'm afraid that it would rather repress development of CM3. >> And we really need to have development, as the underlying systems and >> techniques change and we need to adapt to that. So I'd vote for >> free commits for everybody, as long as there are not too many >> contributors, and setup of continually improved regression testing. >> And we don't need to worry, as all changes can be reverted; we won't >> lose development history with CVS. > > One option is to have moderated commits for non-core developers. After > someone has earned the trust of the core developers they can be elected > as a member of the core team. This approach is used with the Jikes RVM > (www.jikesrvm.org). I wouldn't object to such a policy, though I don't really think that it is currently necessary. But if more active committers do prefer it, we can set up the necessary commit checks. I assume that Randy Coleburn and you are in favour of restricted commits? What about the others? Who would volunteer to review commits from other people? Would this be a responsibility inherited by the unrestricted access? Should we allow commits to branches and only restrict access to the main line? Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jayk123 at hotmail.com Sat Jan 5 02:04:47 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 5 Jan 2008 01:04:47 +0000 Subject: [M3devel] M3 concerns In-Reply-To: <20080105011335.n767h3zbz4gcgk4k@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> Message-ID: I oppose most red tape. However branching can be good, as long as there are frequent merges (between once a week and once a month..well, those timelines are based on other contexts, in this context, I don't know) and automated testing/buildmonkeys/tinderboxes. That is, if I'm in a ghetto branch, I loose both the pressure not to break things, because few/nobody else is in the branch, and the feedback loop of hearing that I've broken someone, so automation would be nice to replace that. I am not experienced with CVS though. I don't know how to setup or merge branches. Even browsing history I find painful, in one branch. Perforce I am quite familiar with. Subversion I learned enough about to know it doesn't suffice, so I'm leary of CVS, which is supposedly in all ways worse. In particular, Subversion doesn't track which changes have been merged from one branch to another. Whereas in Perforce that is a key feature of the system. Amazing that Subversion doesn't do it, but it is near the top of their wishlist. This is a small project. I haven't yet heard of anyone getting one of my possibly "in between" changes and being broken, and even when I checkin frequently, that doesn't mean any one state was broken or wrong. I haven't tested anything with Pickes. One set of tests I found failed all over the place, the m3tests stuff, floating point problems, I think a bunch of never implemented stuff on Windows around calling _fpcontrol or such (platform dependent). The system does build itself, the compiler and "std" packages. I consider that a pretty good start. I realize you can always do more, more and less obvious. There's probably no threading in the compiler, and maybe not even any garbage collection, nor any pickles. I'll look what Olaf commited over the weekend.. Bah humbug and happy new year, :) - Jay > Date: Sat, 5 Jan 2008 01:13:35 +0100> From: wagner at elegosoft.com> To: hosking at cs.purdue.edu; m3devel at elegosoft.com> CC: m3-support at elegosoft.com> Subject: Re: [M3devel] M3 concerns> > Quoting Tony Hosking :> > > My comments embedded:> >> > On Jan 4, 2008, at 4:10 PM, Olaf Wagner wrote:> > >> Ah well, Windows is a somewhat special topic. I even haven't a system> >> here for tests, and most of the other contributors don't use it either.> >> I was of the opinion that Jay Krell had fixes or workarounds for most> >> current problems (except for the missing LONGINT support), but I haven't> >> tried his distribution archives yet. It would indeed be very helpful> >> if we could setup regression tests on Windows, too.> >> > LONGINT = INTEGER on Windows, which is fine as far as it goes> > (everything builds appropriately), but not particularly useful.> > I know that it should run this way, but pickles for example wouldn't> be exchangeable then, would they? Has anybody tested pickle support> for LONGINT yet?> > >> It would also be possible to define a group of reviewers for every> >> change, but I doubt that there would be enough competent volunteers,> >> and I'm afraid that it would rather repress development of CM3.> >> And we really need to have development, as the underlying systems and> >> techniques change and we need to adapt to that. So I'd vote for> >> free commits for everybody, as long as there are not too many> >> contributors, and setup of continually improved regression testing.> >> And we don't need to worry, as all changes can be reverted; we won't> >> lose development history with CVS.> >> > One option is to have moderated commits for non-core developers. After> > someone has earned the trust of the core developers they can be elected> > as a member of the core team. This approach is used with the Jikes RVM> > (www.jikesrvm.org).> > I wouldn't object to such a policy, though I don't really think that> it is currently necessary. But if more active committers do prefer> it, we can set up the necessary commit checks. I assume that Randy Coleburn> and you are in favour of restricted commits? What about the others?> > Who would volunteer to review commits from other people? Would this> be a responsibility inherited by the unrestricted access?> > Should we allow commits to branches and only restrict access to the> main line?> > Olaf> -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194> _________________________________________________________________ Share life as it happens with the new Windows Live. 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 Jan 5 02:22:13 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 5 Jan 2008 01:22:13 +0000 Subject: [M3devel] "crazy cross" In-Reply-To: <20080105011335.n767h3zbz4gcgk4k@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> Message-ID: You've all heard of "Canadian cross"? It is cross-building a cross-compiler.I'm sitting in Windows. I'm going to build a compiler that is going to run on Linux that is going to target Solaris.For one example. You've all seen that Apple has switches like so: gcc -arch i386 ppc ppc64 x86_64 hello.cand poof out comes a binary that runs natively on four architectures I don't like the "inconvenience" of non cross systems and having to have all the machines/OSes just to build the binaries.I realize that you hit the wall if you actually want to test the results. So cross building only gets so much.Of course I also don't want to multiply out build times for tools... Ok, well what is the possibility of: cm3 -target NT386cm3 -target NT386 -target PPC_DARWIN ? In my crazy imagination, you have: \cm3\bin\cm3.cmd %~dp0..\libexec\%processor_architecture%\%TARGET%\cm3.exe %* \cm3\bin\cm3 #!/bin/sh dirname(dirname($0))/libexec/`uname whatever`/$TARGET/cm3 $@ Thus it becomes POSSIBLE to have an n x m matrix, host x target, and be able to build"anything" from one environment. Actually the targets could all be merged into one .exe or be .dll/.sos.Except the code isn't setup for that. Interesting? I guess the hard part is the C code and linking?The Modula-3 stuff is already setup to do most of this? (partly by virtue of all that header rewriting that I labeled sleazy) - Jay _________________________________________________________________ Share life as it happens with the new Windows Live. http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Sat Jan 5 02:28:46 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 5 Jan 2008 01:28:46 +0000 Subject: [M3devel] NT386GNU? In-Reply-To: <20080105011335.n767h3zbz4gcgk4k@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> Message-ID: I assume NT386GNU remains very interesting to folks. Right? Anyone know what's the deal with it? Little work? Lots of work? It'd net LONGINT at least. I realize you'd need sh/awk/sed/gmake/etc., and ld. You'd start by installing mingwin or cygwin. And they (or one) would likely be required for all users, at least for ld and some libs.I assume cygwin/mingwin have long since merged to mainline. I'll try to look into it..... - Jay _________________________________________________________________ Get the power of Windows + Web with the new Windows Live. http://www.windowslive.com?ocid=TXT_TAGHM_Wave2_powerofwindows_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: From hendrik at topoi.pooq.com Sat Jan 5 02:33:07 2008 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Fri, 4 Jan 2008 20:33:07 -0500 Subject: [M3devel] 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> Message-ID: <20080105013307.GB5064@topoi.pooq.com> On Sat, Jan 05, 2008 at 01:04:47AM +0000, Jay wrote: > I oppose most red tape. > > However branching can be good, as long as there are frequent merges > (between once a week and once a month..well, those timelines are based > on other contexts, in this context, I don't know) and automated > testing/buildmonkeys/tinderboxes. That is, if I'm in a ghetto branch, > I loose both the pressure not to break things, because few/nobody else > is in the branch, and the feedback loop of hearing that I've broken > someone, so automation would be nice to replace that. Distributed revision systems have completely implicit, low red-tape branching just by being distributed. > I am not experienced with CVS though. I don't know how to setup or > merge branches. Even browsing history I find painful, in one branch. > Perforce I am quite familiar with. > Subversion I learned enough about to know it doesn't suffice, so I'm > leary of CVS, which is supposedly in all ways worse. gravityboy (http://gravityboy.livejournal.com/39755.html) has a few things to say about people who compare svn with cvs: essentially, he says cvs is so obsolete no one should even be comparing things with it any more. Saying something is better than CVS is like saying that a new model of automatic washing machines work better than rocks by the side of the river. > In particular, Subversion doesn't track which changes have been merged > from one branch to another. Whereas in Perforce that is a key feature > of the system. Amazing that Subversion doesn't do it, but it is near > the top of their wishlist. > > This is a small project. > I haven't yet heard of anyone getting one of my possibly "in between" changes and being broken, and even when I checkin frequently, that doesn't mean any one state was broken or wrong. > > I haven't tested anything with Pickes. One set of tests I found failed all over the place, the m3tests stuff, floating point problems, I think a bunch of never implemented stuff on Windows around calling _fpcontrol or such (platform dependent). > > The system does build itself, the compiler and "std" packages. I consider that a pretty good start. > I realize you can always do more, more and less obvious. There's probably no threading in the compiler, and maybe not even any garbage collection, nor any pickles. > > I'll look what Olaf commited over the weekend.. > > Bah humbug and happy new year, :) > - Jay > > > > > Date: Sat, 5 Jan 2008 01:13:35 +0100> From: wagner at elegosoft.com> To: hosking at cs.purdue.edu; m3devel at elegosoft.com> CC: m3-support at elegosoft.com> Subject: Re: [M3devel] M3 concerns> > Quoting Tony Hosking :> > > My comments embedded:> >> > On Jan 4, 2008, at 4:10 PM, Olaf Wagner wrote:> > >> Ah well, Windows is a somewhat special topic. I even haven't a system> >> here for tests, and most of the other contributors don't use it either.> >> I was of the opinion that Jay Krell had fixes or workarounds for most> >> current problems (except for the missing LONGINT support), but I haven't> >> tried his distribution archives yet. It would indeed be very helpful> >> if we could setup regression tests on Windows, too.> >> > LONGINT = INTEGER on Windows, which is fine as far as it goes> > (everything builds appropriately), but not particularly useful.> > I know that it should run this way, but pickles for example wouldn't> be exchangeable then, would they? Has anybody tested pickle support> for LONGINT yet?> > >> It would also be possible to define a group of reviewers for every> >> change, but I doubt that there would be enough competent volunteers,> >> and I'm afraid that it would rather repress development of CM3.> >> And we really need to have development, as the underlying systems and> >> techniques change and we need to adapt to that. So I'd vote for> >> free commits for everybody, as long as there are not too many> >> contributors, and setup of continually improved regression testing.> >> And we don't need to worry, as all changes can be reverted; we won't> >> lose development history with CVS.> >> > One option is to have moderated commits for non-core developers. After> > someone has earned the trust of the core developers they can be elected> > as a member of the core team. This approach is used with the Jikes RVM> > (www.jikesrvm.org).> > I wouldn't object to such a policy, though I don't really think that> it is currently necessary. But if more active committers do prefer> it, we can set up the necessary commit checks. I assume that Randy Coleburn> and you are in favour of restricted commits? What about the others?> > Who would volunteer to review commits from other people? Would this> be a responsibility inherited by the unrestricted access?> > Should we allow commits to branches and only restrict access to the> main line?> > Olaf> -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194> > _________________________________________________________________ > Share life as it happens with the new Windows Live. > http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_012008 From hendrik at topoi.pooq.com Sat Jan 5 02:17:19 2008 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Fri, 4 Jan 2008 20:17:19 -0500 Subject: [M3devel] M3 concerns In-Reply-To: <20080105011335.n767h3zbz4gcgk4k@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> Message-ID: <20080105011719.GA5064@topoi.pooq.com> On Sat, Jan 05, 2008 at 01:13:35AM +0100, Olaf Wagner wrote: > Quoting Tony Hosking : > > >My comments embedded: > > > >On Jan 4, 2008, at 4:10 PM, Olaf Wagner wrote: > > >>Ah well, Windows is a somewhat special topic. I even haven't a system > >>here for tests, and most of the other contributors don't use it either. > >>I was of the opinion that Jay Krell had fixes or workarounds for most > >>current problems (except for the missing LONGINT support), but I haven't > >>tried his distribution archives yet. It would indeed be very helpful > >>if we could setup regression tests on Windows, too. > > > >LONGINT = INTEGER on Windows, which is fine as far as it goes > >(everything builds appropriately), but not particularly useful. > > I know that it should run this way, but pickles for example wouldn't > be exchangeable then, would they? Has anybody tested pickle support > for LONGINT yet? > > >>It would also be possible to define a group of reviewers for every > >>change, but I doubt that there would be enough competent volunteers, > >>and I'm afraid that it would rather repress development of CM3. > >>And we really need to have development, as the underlying systems and > >>techniques change and we need to adapt to that. So I'd vote for > >>free commits for everybody, as long as there are not too many > >>contributors, and setup of continually improved regression testing. > >>And we don't need to worry, as all changes can be reverted; we won't > >>lose development history with CVS. > > > >One option is to have moderated commits for non-core developers. After > >someone has earned the trust of the core developers they can be elected > >as a member of the core team. This approach is used with the Jikes RVM > >(www.jikesrvm.org). > > I wouldn't object to such a policy, though I don't really think that > it is currently necessary. But if more active committers do prefer > it, we can set up the necessary commit checks. I assume that Randy Coleburn > and you are in favour of restricted commits? What about the others? > > Who would volunteer to review commits from other people? Would this > be a responsibility inherited by the unrestricted access? > > Should we allow commits to branches and only restrict access to the > main line? The philosophy among the monotone developers (who use monotone as their revision control system) is to separate committing from certification. Anyone can commit a revision, which cen then be looked at, discussed, revised a few times, and if found worthy, certified. It gives them an informal kind of flexibility for small changes. Because monotone is a distributed revision conttrol system, they frequently have multiple heads in a branch (I prefer to call them leaves, or buds ready for the growth of new twigs). It's usualy to check out the most recent certified revision when you start a new bit of development. But being stuck with multiple heads, and having their system understand multiple heads, gives them a kind of flexibility that reflects the chaotic structure of real-sorld development. Official branches can also exist. If so, it's usually done by certifying revisions with different branch certificates. Botice that one same revision of one same file can be on several branches with no problems at all. I fact, it's perfectly possible to discover that development that has gone on for a few weeks really belongs on a different branch and so certify it after the fact. Now I'm not telling you to convert your whole development system to monotone, though I might advise it if you were looking for a new revision-control system. Such a changeover could involve substantial disruption. But looking at how it's done there might suggest possibilities after you map it hack to what you are using. The separation of commit from certify seems to be quite useful. -- hendrik From rcoleburn at scires.com Sat Jan 5 03:12:24 2008 From: rcoleburn at scires.com (Randy Coleburn) Date: Fri, 04 Jan 2008 21:12:24 -0500 Subject: [M3devel] 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> Message-ID: <477EA137.1E75.00D7.1@scires.com> Given the current situation, I'm not sure that moderated commits are practical. I think the best route is to get enough tests in place so that all developers can run a regression test suite BEFORE committing changes. Having an automated scoreboard would also help point out where things are broken and need fixing so that folks can volunteer to help. I'll try to find time again this weekend to do a build of cm3 on Windows XP again. If one goes to the website, there seems to be several choices for getting started, so I need some advice on the best way to move forward. 1. Get current sources from head branch and try to build from scratch (after first installing free Microsoft Visual C/C++ tools). 2. Get an older variant (5.2.6, 4.1, etc.) and try to use it to build the new current sources from CVS. 3. Get Jay's d5.5.0 min Win32 and use it to build the current sources from CVS. 4. ?? I know that there are some scripts that have been built to help in building things. One thing that would be helpful I think is to have a text file that lists the correct build sequence order for all packages in the repository. I know that some packages may not build on every platform, but if we keep this text file up-to-date, it would help folks as they work on scripts, etc. Also, I seem to recall that in the past that for some of the core packages, you had to build these twice in the process of getting everything up and running. Again, these facts need to be made very obvious so folks don't go down a wrong path. Once I get started on a path (1..4 above), I also need to know which of the current scripts to use in building on Windows XP to get the best results. I love the language and have been a zealous proponent of it for a long time, but we've got to make it easier for folks to get started with Modula-3. I will carefully document the steps I take in getting the system built on Windows so we can make this available to everyone. As for Jay's comment that he hasn't heard of anyone getting a "broken" version, please understand that I am not directing my comments at any one person, but rather to the system of "checks and balances" that need to be put in place for everyone. The last time I was able to get the sources and build on Windows was v5.26. That version didn't work correctly with some of my programs and I reported the problems to Olaf et al. The last time I checked out the sources and tried to build 5.40, I wound up with compiler errors. I recall some of these were related to LONGINT and some were related to the garbage collector. So yes, there was a situation where I checked out sources that represented a "broken" version in that it would not build. Thus, there are at least two types of "broken": (1) the system sources can't be built correctly, (2) the newly built system causes previously working code to misbehave when recompiled with the new system. Broken #1 should never be allowed to occur for the core system. From what Olaf said, the rule seems to be to keep broken #1 stuff in a branch and only merge it back into the main line when the broken state is resolved. Broken #2 should be avoided using regression test suites. The package status page at http://modula3.elegosoft.com/cm3/package-status.html is headed up by the title CM3 v5.1. Is this page up-to-date? It would be helpful to know where we stand wrt each package on each supported platform relative to the current source tree. Again, I think an automated scoreboard could make this possible. Sorry to ramble on so much in this post. My main interest is in getting the current sources built and running on Windows XP. As soon as I am successful, I will run tests using my code base. I have a number of programs that were built using cm3 v4.1 that are still in use. These use a lot of features, including pickles, netobj, trestle, etc. So, my tests should help uncover Broken #2 problems on Windows. Finally, once I get a working cm3 system on Windows, I'll provide the new cm3-IDE (aka Reactor) package. Regards, Randy >>> Jay 1/4/2008 8:04 PM >>> I oppose most red tape. However branching can be good, as long as there are frequent merges (between once a week and once a month..well, those timelines are based on other contexts, in this context, I don't know) and automated testing/buildmonkeys/tinderboxes. That is, if I'm in a ghetto branch, I loose both the pressure not to break things, because few/nobody else is in the branch, and the feedback loop of hearing that I've broken someone, so automation would be nice to replace that. I am not experienced with CVS though. I don't know how to setup or merge branches. Even browsing history I find painful, in one branch. Perforce I am quite familiar with. Subversion I learned enough about to know it doesn't suffice, so I'm leary of CVS, which is supposedly in all ways worse. In particular, Subversion doesn't track which changes have been merged from one branch to another. Whereas in Perforce that is a key feature of the system. Amazing that Subversion doesn't do it, but it is near the top of their wishlist. This is a small project. I haven't yet heard of anyone getting one of my possibly "in between" changes and being broken, and even when I checkin frequently, that doesn't mean any one state was broken or wrong. I haven't tested anything with Pickes. One set of tests I found failed all over the place, the m3tests stuff, floating point problems, I think a bunch of never implemented stuff on Windows around calling _fpcontrol or such (platform dependent). The system does build itself, the compiler and "std" packages. I consider that a pretty good start. I realize you can always do more, more and less obvious. There's probably no threading in the compiler, and maybe not even any garbage collection, nor any pickles. I'll look what Olaf commited over the weekend.. Bah humbug and happy new year, :) - Jay > Date: Sat, 5 Jan 2008 01:13:35 +0100 > From: wagner at elegosoft.com > To: hosking at cs.purdue.edu; m3devel at elegosoft.com > CC: m3-support at elegosoft.com > Subject: Re: [M3devel] M3 concerns > > Quoting Tony Hosking : > > > My comments embedded: > > > > On Jan 4, 2008, at 4:10 PM, Olaf Wagner wrote: > > >> Ah well, Windows is a somewhat special topic. I even haven't a system > >> here for tests, and most of the other contributors don't use it either. > >> I was of the opinion that Jay Krell had fixes or workarounds for most > >> current problems (except for the missing LONGINT support), but I haven't > >> tried his distribution archives yet. It would indeed be very helpful > >> if we could setup regression tests on Windows, too. > > > > LONGINT = INTEGER on Windows, which is fine as far as it goes > > (everything builds appropriately), but not particularly useful. > > I know that it should run this way, but pickles for example wouldn't > be exchangeable then, would they? Has anybody tested pickle support > for LONGINT yet? > > >> It would also be possible to define a group of reviewers for every > >> change, but I doubt that there would be enough competent volunteers, > >> and I'm afraid that it would rather repress development of CM3. > >> And we really need to have development, as the underlying systems and > >> techniques change and we need to adapt to that. So I'd vote for > >> free commits for everybody, as long as there are not too many > >> contributors, and setup of continually improved regression testing. > >> And we don't need to worry, as all changes can be reverted; we won't > >> lose development history with CVS. > > > > One option is to have moderated commits for non-core developers. After > > someone has earned the trust of the core developers they can be elected > > as a member of the core team. This approach is used with the Jikes RVM > > (www.jikesrvm.org). > > I wouldn't object to such a policy, though I don't really think that > it is currently necessary. But if more active committers do prefer > it, we can set up the necessary commit checks. I assume that Randy Coleburn > and you are in favour of restricted commits? What about the others? > > Who would volunteer to review commits from other people? Would this > be a responsibility inherited by the unrestricted access? > > Should we allow commits to branches and only restrict access to the > main line? > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > Share life as it happens with the new Windows Live. Start sharing! ( 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 Jan 5 05:24:17 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 5 Jan 2008 04:24:17 +0000 Subject: [M3devel] M3 concerns In-Reply-To: <477EA137.1E75.00D7.1@scires.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> <477EA137.1E75.00D7.1@scires.com> Message-ID: Anything that was broken in 5.2.6 is "probably" still broken."Probably" as in that *I* haven't fixed much.Not that *I* am a big deal or anything.Other folks might have fixed stuff. There's been some talk about GUI stuff and not much progress.I'm not much into GUI programming, though I can't standnot having a good GUI (hypocrite I am!) The build stuff, yes and no. There isn't QUITE a canonical build order it turns out.It's circular. I'll explain. I agree work is needed here though.I put forward a very lame candiate for improvement here inscripts\python\pylib.py where at least all the "filters" are in one place.Now any of scripts\python\do*.py can ask for whatever, no need toknow what works on what platform, and the filtering is centralized.The ordering is not. Hey, that's easy.But still, my representation is wrong. It should be a more generic textformat and less actual Python code. Except that there isn't one ordering. I will explain in a sec. For your options 1-4, well, hey, I've endeavored to keep multiple options working.Don't be confused. Just pick one. :) Specifically, you can start with 5.2.6 and run scripts\win\upgrade.It WAS broken recently, related to LONGINT, but it is fixed now.(There isn't yet scripts\python\upgrade, but I promise there will be. :) ) Or you can take my 5.5.0 distribution, and run "anything". I would also recommend you take the exact checked in config file.m3-sys\cminstall\src\config\NT386.It shouldn't require any edits. Feel free to read it, and consider editing it,but it shouldn't require any. I'm assuming current source.There should be no need to "sync backward" or such.I have even endeavored to make one cm3.cfg file work with latest and older source.That is still a developing story on PPC_DARWIN and PPC_LINUX.(And "autoconf-ish" instead of "version checking" checks might be good) You should be able to use just about any Visual C++ toolset.I put in fixes to accomodate various versions.Of course, 8.0 is about the best. 9.0 is a recent release.The releases are all high quality in my experience. Ok, let me explain the ordering thing.There is a necessary circular dependency between the compiler and runtime.You cannot build the runtime unless you have a compiler.You cannot build a compiler unless you have a runtime.An older compiler cannot compile the current runtime, because of LONGINT. Or could be other reasons in the future.However if you already have a runtime (somehow), an older compiler cancompile a current compiler, and then you can use the new compiler tobuild the current runtime, and then rebuild (or at least relink),the compiler against the current runtime. (I'm not sure "compile" and "link"apply per se in Modula-3, I'm not sure it builds in quite the traditionalway.) scripts\win\make-dist and scripts\win\upgrade both take care of this.They can both start with a 5.2.6 compiler/runtime, or a current compiler/runtime.They do waste time if starting with current.Yes, they do build the compiler twice. At some point the first computers must have been built from sticks and rocks and dirt,but once they were working, the second computer could be built with more advanced materials. In particular, the first Modula-3 compiler was probably written in C.The first C compiler was probably written in assembly. Or maybe written in C and hand compiled into assembly.The first assembler was probably hand translated into "machine code". Bootstrapping is a funny thing.Circular dependencies seem wrong, but they are necessary. Bootstrappability from earlier than 5.2 I cannot at this time vouch for.I was thinking of trying with 3.6 which I have and 4.1 if I can find my CD.But it might not be easy and it might be fairly pointless.Bootstrapping does tend to lead to building up and up and up and an inabilityto jump from the initial step to the latest. You do, I expect, restthe starting level from time to time. 3.6 does still build quite easily out of the box on current systems.I built it last week. :)(Only NT386.) Oh, also, the order "only" matters when you don't have a package store already and/or you are changing types. If you are only changing code, and you already have a packge store you can build in any order. When you are changing types, or don't have a package store, I believe you have to build from the bottom of the dependency graph and on up. If you ignore the compiler, the dependency graph that I have in my head is just m3core, then libm3, then everything else. The compiler, well, you get clear errors as to what is missing if you build it out of order. I'll get some ordering into scripts\python, excluding the circularity. I may be mispresenting the circularity. It's probably really m3core, libm3, then the compiler but in the bootstrapping case, you must already have m3core and libm3, from a different build. The circularity exists, but maybe in sort of different terms. You don't need the compiler's .i3 files published to build libm3/m3core, you just need a cm3.exe. - Jay Date: Fri, 4 Jan 2008 21:12:24 -0500From: rcoleburn at scires.comTo: hosking at cs.purdue.edu; m3devel at elegosoft.com; wagner at elegosoft.com; jayk123 at hotmail.comCC: m3-support at elegosoft.comSubject: Re: [M3devel] M3 concerns Given the current situation, I'm not sure that moderated commits are practical. I think the best route is to get enough tests in place so that all developers can run a regression test suite BEFORE committing changes. Having an automated scoreboard would also help point out where things are broken and need fixing so that folks can volunteer to help. I'll try to find time again this weekend to do a build of cm3 on Windows XP again. If one goes to the website, there seems to be several choices for getting started, so I need some advice on the best way to move forward. 1. Get current sources from head branch and try to build from scratch (after first installing free Microsoft Visual C/C++ tools). 2. Get an older variant (5.2.6, 4.1, etc.) and try to use it to build the new current sources from CVS. 3. Get Jay's d5.5.0 min Win32 and use it to build the current sources from CVS. 4. ?? I know that there are some scripts that have been built to help in building things. One thing that would be helpful I think is to have a text file that lists the correct build sequence order for all packages in the repository. I know that some packages may not build on every platform, but if we keep this text file up-to-date, it would help folks as they work on scripts, etc. Also, I seem to recall that in the past that for some of the core packages, you had to build these twice in the process of getting everything up and running. Again, these facts need to be made very obvious so folks don't go down a wrong path. Once I get started on a path (1..4 above), I also need to know which of the current scripts to use in building on Windows XP to get the best results. I love the language and have been a zealous proponent of it for a long time, but we've got to make it easier for folks to get started with Modula-3. I will carefully document the steps I take in getting the system built on Windows so we can make this available to everyone. As for Jay's comment that he hasn't heard of anyone getting a "broken" version, please understand that I am not directing my comments at any one person, but rather to the system of "checks and balances" that need to be put in place for everyone. The last time I was able to get the sources and build on Windows was v5.26. That version didn't work correctly with some of my programs and I reported the problems to Olaf et al. The last time I checked out the sources and tried to build 5.40, I wound up with compiler errors. I recall some of these were related to LONGINT and some were related to the garbage collector. So yes, there was a situation where I checked out sources that represented a "broken" version in that it would not build. Thus, there are at least two types of "broken": (1) the system sources can't be built correctly, (2) the newly built system causes previously working code to misbehave when recompiled with the new system. Broken #1 should never be allowed to occur for the core system. From what Olaf said, the rule seems to be to keep broken #1 stuff in a branch and only merge it back into the main line when the broken state is resolved. Broken #2 should be avoided using regression test suites. The package status page at http://modula3.elegosoft.com/cm3/package-status.html is headed up by the title CM3 v5.1. Is this page up-to-date? It would be helpful to know where we stand wrt each package on each supported platform relative to the current source tree. Again, I think an automated scoreboard could make this possible. Sorry to ramble on so much in this post. My main interest is in getting the current sources built and running on Windows XP. As soon as I am successful, I will run tests using my code base. I have a number of programs that were built using cm3 v4.1 that are still in use. These use a lot of features, including pickles, netobj, trestle, etc. So, my tests should help uncover Broken #2 problems on Windows. Finally, once I get a working cm3 system on Windows, I'll provide the new cm3-IDE (aka Reactor) package. Regards, Randy>>> Jay 1/4/2008 8:04 PM >>>I oppose most red tape. However branching can be good, as long as there are frequent merges (between once a week and once a month..well, those timelines are based on other contexts, in this context, I don't know) and automated testing/buildmonkeys/tinderboxes. That is, if I'm in a ghetto branch, I loose both the pressure not to break things, because few/nobody else is in the branch, and the feedback loop of hearing that I've broken someone, so automation would be nice to replace that. I am not experienced with CVS though. I don't know how to setup or merge branches. Even browsing history I find painful, in one branch.Perforce I am quite familiar with.Subversion I learned enough about to know it doesn't suffice, so I'm leary of CVS, which is supposedly in all ways worse.In particular, Subversion doesn't track which changes have been merged from one branch to another. Whereas in Perforce that is a key feature of the system. Amazing that Subversion doesn't do it, but it is near the top of their wishlist. This is a small project.I haven't yet heard of anyone getting one of my possibly "in between" changes and being broken, and even when I checkin frequently, that doesn't mean any one state was broken or wrong. I haven't tested anything with Pickes. One set of tests I found failed all over the place, the m3tests stuff, floating point problems, I think a bunch of never implemented stuff on Windows around calling _fpcontrol or such (platform dependent). The system does build itself, the compiler and "std" packages. I consider that a pretty good start.I realize you can always do more, more and less obvious. There's probably no threading in the compiler, and maybe not even any garbage collection, nor any pickles. I'll look what Olaf commited over the weekend.. Bah humbug and happy new year, :) - Jay > Date: Sat, 5 Jan 2008 01:13:35 +0100> From: wagner at elegosoft.com> To: hosking at cs.purdue.edu; m3devel at elegosoft.com> CC: m3-support at elegosoft.com> Subject: Re: [M3devel] M3 concerns> > Quoting Tony Hosking :> > > My comments embedded:> >> > On Jan 4, 2008, at 4:10 PM, Olaf Wagner wrote:> > >> Ah well, Windows is a somewhat special topic. I even haven't a system> >> here for tests, and most of the other contributors don't use it either.> >> I was of the opinion that Jay Krell had fixes or workarounds for most> >> current problems (except for the missing LONGINT support), but I haven't> >> tried his distribution archives yet. It would indeed be very helpful> >> if we could setup regression tests on Windows, too.> >> > LONGINT = INTEGER on Windows, which is fine as far as it goes> > (everything builds appropriately), but not particularly useful.> > I know that it should run this way, but pickles for example wouldn't> be exchangeable then, would they? Has anybody tested pickle support> for LONGINT yet?> > >> It would also be possible to define a group of reviewers for every> >> change, but I doubt that there would be enough competent volunteers,> >> and I'm afraid that it would rather repress development of CM3.> >> And we really need to have development, as the underlying systems and> >> techniques change and we need to adapt to that. So I'd vote for> >> free commits for everybody, as long as there are not too many> >> contributors, and setup of continually improved regression testing.> >> And we don't need to worry, as all changes can be reverted; we won't> >> lose development history with CVS.> >> > One option is to have moderated commits for non-core developers. After> > someone has earned the trust of the core developers they can be elected> > as a member of the core team. This approach is used with the Jikes RVM> > (www.jikesrvm.org).> > I wouldn't object to such a policy, though I don't really think that> it is currently necessary. But if more active committers do prefer> it, we can set up the necessary commit checks. I assume that Randy Coleburn> and you are in favour of restricted commits? What about the others?> > Who would volunteer to review commits from other people? Would this> be a responsibility inherited by the unrestricted access?> > Should we allow commits to branches and only restrict access to the> main line?> > Olaf> -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194> Share life as it happens with the new Windows Live. Start sharing! _________________________________________________________________ Share life as it happens with the new Windows Live. http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Sat Jan 5 05:31:03 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 5 Jan 2008 04:31:03 +0000 Subject: [M3devel] 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> <477EA137.1E75.00D7.1@scires.com> Message-ID: Randy if you want to try remote assistance or call me on the phone over the weekend, that's fine. OR, I would agree, that might be cheating. Do it yourself and pound out the good documentation, if you want. Either way. If you cheat, you can always let the next guy tough it out and update the docs. :) There is a checked in document. installation-windows.html or such, though...I'm not the best writer... 1. Get current sources from head branch and try to build from scratch (after first installing free Microsoft Visual C/C++ tools). Not possible -- er, not sufficient. You must start with an existing CM3 distribution as well..the system is written in Modula-3 after all, and CM3 doesn't currently ship the "boot" archives like Digital did, where you just need a C compiler and linker. Heck, it's "binaries" either way. CM3 ships .exes, Digital shipped .obj files. 5.5.0 or 5.2.6 will work. Anything else, I haven't tried (I'm using 5.2.4 on another platform). If you have a particular need/desire/motivation to start with 3.6 or 4.1 or whatever, let me know and I can try. Otherwise, not clear it is interesting. I don't think bootstrapping from *any* version is necessarily interesting, you have to advance sometimes, I think. - Jay From: jayk123 at hotmail.comTo: rcoleburn at scires.com; hosking at cs.purdue.edu; m3devel at elegosoft.com; wagner at elegosoft.comDate: Sat, 5 Jan 2008 04:24:17 +0000CC: m3-support at elegosoft.comSubject: Re: [M3devel] M3 concerns Anything that was broken in 5.2.6 is "probably" still broken."Probably" as in that *I* haven't fixed much.Not that *I* am a big deal or anything.Other folks might have fixed stuff.There's been some talk about GUI stuff and not much progress.I'm not much into GUI programming, though I can't standnot having a good GUI (hypocrite I am!)The build stuff, yes and no.There isn't QUITE a canonical build order it turns out.It's circular. I'll explain.I agree work is needed here though.I put forward a very lame candiate for improvement here inscripts\python\pylib.py where at least all the "filters" are in one place.Now any of scripts\python\do*.py can ask for whatever, no need toknow what works on what platform, and the filtering is centralized.The ordering is not. Hey, that's easy.But still, my representation is wrong. It should be a more generic textformat and less actual Python code.Except that there isn't one ordering. I will explain in a sec.For your options 1-4, well, hey, I've endeavored to keep multiple options working.Don't be confused. Just pick one. :)Specifically, you can start with 5.2.6 and run scripts\win\upgrade.It WAS broken recently, related to LONGINT, but it is fixed now.(There isn't yet scripts\python\upgrade, but I promise there will be. :) )Or you can take my 5.5.0 distribution, and run "anything".I would also recommend you take the exact checked in config file.m3-sys\cminstall\src\config\NT386.It shouldn't require any edits. Feel free to read it, and consider editing it,but it shouldn't require any.I'm assuming current source.There should be no need to "sync backward" or such.I have even endeavored to make one cm3.cfg file work with latest and older source.That is still a developing story on PPC_DARWIN and PPC_LINUX.(And "autoconf-ish" instead of "version checking" checks might be good)You should be able to use just about any Visual C++ toolset.I put in fixes to accomodate various versions.Of course, 8.0 is about the best. 9.0 is a recent release.The releases are all high quality in my experience.Ok, let me explain the ordering thing.There is a necessary circular dependency between the compiler and runtime.You cannot build the runtime unless you have a compiler.You cannot build a compiler unless you have a runtime.An older compiler cannot compile the current runtime, because of LONGINT. Or could be other reasons in the future.However if you already have a runtime (somehow), an older compiler cancompile a current compiler, and then you can use the new compiler tobuild the current runtime, and then rebuild (or at least relink),the compiler against the current runtime. (I'm not sure "compile" and "link"apply per se in Modula-3, I'm not sure it builds in quite the traditionalway.)scripts\win\make-dist and scripts\win\upgrade both take care of this.They can both start with a 5.2.6 compiler/runtime, or a current compiler/runtime.They do waste time if starting with current.Yes, they do build the compiler twice.At some point the first computers must have been built from sticks and rocks and dirt,but once they were working, the second computer could be built with more advanced materials.In particular, the first Modula-3 compiler was probably written in C.The first C compiler was probably written in assembly. Or maybe written in C and hand compiled into assembly.The first assembler was probably hand translated into "machine code".Bootstrapping is a funny thing.Circular dependencies seem wrong, but they are necessary.Bootstrappability from earlier than 5.2 I cannot at this time vouch for.I was thinking of trying with 3.6 which I have and 4.1 if I can find my CD.But it might not be easy and it might be fairly pointless.Bootstrapping does tend to lead to building up and up and up and an inabilityto jump from the initial step to the latest. You do, I expect, restthe starting level from time to time.3.6 does still build quite easily out of the box on current systems.I built it last week. :)(Only NT386.) Oh, also, the order "only" matters when you don't have a package store already and/or you are changing types.If you are only changing code, and you already have a packge store you can build in any order.When you are changing types, or don't have a package store, I believe you have to build from the bottom of the dependency graph and on up. If you ignore the compiler, the dependency graph that I have in my head is just m3core, then libm3, then everything else. The compiler, well, you get clear errors as to what is missing if you build it out of order. I'll get some ordering into scripts\python, excluding the circularity. I may be mispresenting the circularity. It's probably really m3core, libm3, then the compiler but in the bootstrapping case, you must already have m3core and libm3, from a different build. The circularity exists, but maybe in sort of different terms. You don't need the compiler's .i3 files published to build libm3/m3core, you just need a cm3.exe. - Jay Date: Fri, 4 Jan 2008 21:12:24 -0500From: rcoleburn at scires.comTo: hosking at cs.purdue.edu; m3devel at elegosoft.com; wagner at elegosoft.com; jayk123 at hotmail.comCC: m3-support at elegosoft.comSubject: Re: [M3devel] M3 concerns Given the current situation, I'm not sure that moderated commits are practical. I think the best route is to get enough tests in place so that all developers can run a regression test suite BEFORE committing changes. Having an automated scoreboard would also help point out where things are broken and need fixing so that folks can volunteer to help. I'll try to find time again this weekend to do a build of cm3 on Windows XP again. If one goes to the website, there seems to be several choices for getting started, so I need some advice on the best way to move forward. 1. Get current sources from head branch and try to build from scratch (after first installing free Microsoft Visual C/C++ tools). 2. Get an older variant (5.2.6, 4.1, etc.) and try to use it to build the new current sources from CVS. 3. Get Jay's d5.5.0 min Win32 and use it to build the current sources from CVS. 4. ?? I know that there are some scripts that have been built to help in building things. One thing that would be helpful I think is to have a text file that lists the correct build sequence order for all packages in the repository. I know that some packages may not build on every platform, but if we keep this text file up-to-date, it would help folks as they work on scripts, etc. Also, I seem to recall that in the past that for some of the core packages, you had to build these twice in the process of getting everything up and running. Again, these facts need to be made very obvious so folks don't go down a wrong path. Once I get started on a path (1..4 above), I also need to know which of the current scripts to use in building on Windows XP to get the best results. I love the language and have been a zealous proponent of it for a long time, but we've got to make it easier for folks to get started with Modula-3. I will carefully document the steps I take in getting the system built on Windows so we can make this available to everyone. As for Jay's comment that he hasn't heard of anyone getting a "broken" version, please understand that I am not directing my comments at any one person, but rather to the system of "checks and balances" that need to be put in place for everyone. The last time I was able to get the sources and build on Windows was v5.26. That version didn't work correctly with some of my programs and I reported the problems to Olaf et al. The last time I checked out the sources and tried to build 5.40, I wound up with compiler errors. I recall some of these were related to LONGINT and some were related to the garbage collector. So yes, there was a situation where I checked out sources that represented a "broken" version in that it would not build. Thus, there are at least two types of "broken": (1) the system sources can't be built correctly, (2) the newly built system causes previously working code to misbehave when recompiled with the new system. Broken #1 should never be allowed to occur for the core system. From what Olaf said, the rule seems to be to keep broken #1 stuff in a branch and only merge it back into the main line when the broken state is resolved. Broken #2 should be avoided using regression test suites. The package status page at http://modula3.elegosoft.com/cm3/package-status.html is headed up by the title CM3 v5.1. Is this page up-to-date? It would be helpful to know where we stand wrt each package on each supported platform relative to the current source tree. Again, I think an automated scoreboard could make this possible. Sorry to ramble on so much in this post. My main interest is in getting the current sources built and running on Windows XP. As soon as I am successful, I will run tests using my code base. I have a number of programs that were built using cm3 v4.1 that are still in use. These use a lot of features, including pickles, netobj, trestle, etc. So, my tests should help uncover Broken #2 problems on Windows. Finally, once I get a working cm3 system on Windows, I'll provide the new cm3-IDE (aka Reactor) package. Regards, Randy>>> Jay 1/4/2008 8:04 PM >>>I oppose most red tape. However branching can be good, as long as there are frequent merges (between once a week and once a month..well, those timelines are based on other contexts, in this context, I don't know) and automated testing/buildmonkeys/tinderboxes. That is, if I'm in a ghetto branch, I loose both the pressure not to break things, because few/nobody else is in the branch, and the feedback loop of hearing that I've broken someone, so automation would be nice to replace that. I am not experienced with CVS though. I don't know how to setup or merge branches. Even browsing history I find painful, in one branch.Perforce I am quite familiar with.Subversion I learned enough about to know it doesn't suffice, so I'm leary of CVS, which is supposedly in all ways worse.In particular, Subversion doesn't track which changes have been merged from one branch to another. Whereas in Perforce that is a key feature of the system. Amazing that Subversion doesn't do it, but it is near the top of their wishlist. This is a small project.I haven't yet heard of anyone getting one of my possibly "in between" changes and being broken, and even when I checkin frequently, that doesn't mean any one state was broken or wrong. I haven't tested anything with Pickes. One set of tests I found failed all over the place, the m3tests stuff, floating point problems, I think a bunch of never implemented stuff on Windows around calling _fpcontrol or such (platform dependent). The system does build itself, the compiler and "std" packages. I consider that a pretty good start.I realize you can always do more, more and less obvious. There's probably no threading in the compiler, and maybe not even any garbage collection, nor any pickles. I'll look what Olaf commited over the weekend.. Bah humbug and happy new year, :) - Jay > Date: Sat, 5 Jan 2008 01:13:35 +0100> From: wagner at elegosoft.com> To: hosking at cs.purdue.edu; m3devel at elegosoft.com> CC: m3-support at elegosoft.com> Subject: Re: [M3devel] M3 concerns> > Quoting Tony Hosking :> > > My comments embedded:> >> > On Jan 4, 2008, at 4:10 PM, Olaf Wagner wrote:> > >> Ah well, Windows is a somewhat special topic. I even haven't a system> >> here for tests, and most of the other contributors don't use it either.> >> I was of the opinion that Jay Krell had fixes or workarounds for most> >> current problems (except for the missing LONGINT support), but I haven't> >> tried his distribution archives yet. It would indeed be very helpful> >> if we could setup regression tests on Windows, too.> >> > LONGINT = INTEGER on Windows, which is fine as far as it goes> > (everything builds appropriately), but not particularly useful.> > I know that it should run this way, but pickles for example wouldn't> be exchangeable then, would they? Has anybody tested pickle support> for LONGINT yet?> > >> It would also be possible to define a group of reviewers for every> >> change, but I doubt that there would be enough competent volunteers,> >> and I'm afraid that it would rather repress development of CM3.> >> And we really need to have development, as the underlying systems and> >> techniques change and we need to adapt to that. So I'd vote for> >> free commits for everybody, as long as there are not too many> >> contributors, and setup of continually improved regression testing.> >> And we don't need to worry, as all changes can be reverted; we won't> >> lose development history with CVS.> >> > One option is to have moderated commits for non-core developers. After> > someone has earned the trust of the core developers they can be elected> > as a member of the core team. This approach is used with the Jikes RVM> > (www.jikesrvm.org).> > I wouldn't object to such a policy, though I don't really think that> it is currently necessary. But if more active committers do prefer> it, we can set up the necessary commit checks. I assume that Randy Coleburn> and you are in favour of restricted commits? What about the others?> > Who would volunteer to review commits from other people? Would this> be a responsibility inherited by the unrestricted access?> > Should we allow commits to branches and only restrict access to the> main line?> > Olaf> -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194> Share life as it happens with the new Windows Live. Start sharing! Share life as it happens with the new Windows Live. Start sharing! _________________________________________________________________ Put your friends on the big screen with Windows Vista? + Windows Live?. http://www.microsoft.com/windows/shop/specialoffers.mspx?ocid=TXT_TAGLM_CPC_MediaCtr_bigscreen_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Sat Jan 5 05:41:01 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 5 Jan 2008 04:41:01 +0000 Subject: [M3devel] 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> <477EA137.1E75.00D7.1@scires.com> Message-ID: darnit -- one more thing...yeah, I know my email sucks, but you get what you pay for :) Randy asked how to build "everything". "everything" == "standard" == "std". scripts\do-cm3-std.sh scripts\win\do-cm3-std.cmd and def-std-pkgs.sh or such scripts\python\do-cm3-std.py coming soon Yeah, the scripts directory..confused me at first too. So I rewrote it... :) More data driven would be good. If someone can propose the text file format, including specifying the "filters", I can implement the cmd and Python...oh should really move on to using Modula-3 though, stick the knowledge into cm3 itself. cm3 -build libm3 m3core cm3.... Two types of broken, right -- build breaks and run breaks, static breaks and dynamic breaks. - Jay From: jayk123 at hotmail.comTo: rcoleburn at scires.com; hosking at cs.purdue.edu; m3devel at elegosoft.com; wagner at elegosoft.comDate: Sat, 5 Jan 2008 04:31:03 +0000CC: m3-support at elegosoft.comSubject: Re: [M3devel] M3 concerns Randy if you want to try remote assistance or call me on the phone over the weekend, that's fine.OR, I would agree, that might be cheating. Do it yourself and pound out the good documentation, if you want. Either way. If you cheat, you can always let the next guy tough it out and update the docs. :)There is a checked in document. installation-windows.html or such, though...I'm not the best writer... 1. Get current sources from head branch and try to build from scratch (after first installing free Microsoft Visual C/C++ tools). Not possible -- er, not sufficient. You must start with an existing CM3 distribution as well..the system is written in Modula-3 after all, and CM3 doesn't currently ship the "boot" archives like Digital did, where you just need a C compiler and linker. Heck, it's "binaries" either way. CM3 ships .exes, Digital shipped .obj files. 5.5.0 or 5.2.6 will work. Anything else, I haven't tried (I'm using 5.2.4 on another platform). If you have a particular need/desire/motivation to start with 3.6 or 4.1 or whatever, let me know and I can try. Otherwise, not clear it is interesting. I don't think bootstrapping from *any* version is necessarily interesting, you have to advance sometimes, I think. - Jay From: jayk123 at hotmail.comTo: rcoleburn at scires.com; hosking at cs.purdue.edu; m3devel at elegosoft.com; wagner at elegosoft.comDate: Sat, 5 Jan 2008 04:24:17 +0000CC: m3-support at elegosoft.comSubject: Re: [M3devel] M3 concerns Anything that was broken in 5.2.6 is "probably" still broken."Probably" as in that *I* haven't fixed much.Not that *I* am a big deal or anything.Other folks might have fixed stuff.There's been some talk about GUI stuff and not much progress.I'm not much into GUI programming, though I can't standnot having a good GUI (hypocrite I am!)The build stuff, yes and no.There isn't QUITE a canonical build order it turns out.It's circular. I'll explain.I agree work is needed here though.I put forward a very lame candiate for improvement here inscripts\python\pylib.py where at least all the "filters" are in one place.Now any of scripts\python\do*.py can ask for whatever, no need toknow what works on what platform, and the filtering is centralized.The ordering is not. Hey, that's easy.But still, my representation is wrong. It should be a more generic textformat and less actual Python code.Except that there isn't one ordering. I will explain in a sec.For your options 1-4, well, hey, I've endeavored to keep multiple options working.Don't be confused. Just pick one. :)Specifically, you can start with 5.2.6 and run scripts\win\upgrade.It WAS broken recently, related to LONGINT, but it is fixed now.(There isn't yet scripts\python\upgrade, but I promise there will be. :) )Or you can take my 5.5.0 distribution, and run "anything".I would also recommend you take the exact checked in config file.m3-sys\cminstall\src\config\NT386.It shouldn't require any edits. Feel free to read it, and consider editing it,but it shouldn't require any.I'm assuming current source.There should be no need to "sync backward" or such.I have even endeavored to make one cm3.cfg file work with latest and older source.That is still a developing story on PPC_DARWIN and PPC_LINUX.(And "autoconf-ish" instead of "version checking" checks might be good)You should be able to use just about any Visual C++ toolset.I put in fixes to accomodate various versions.Of course, 8.0 is about the best. 9.0 is a recent release.The releases are all high quality in my experience.Ok, let me explain the ordering thing.There is a necessary circular dependency between the compiler and runtime.You cannot build the runtime unless you have a compiler.You cannot build a compiler unless you have a runtime.An older compiler cannot compile the current runtime, because of LONGINT. Or could be other reasons in the future.However if you already have a runtime (somehow), an older compiler cancompile a current compiler, and then you can use the new compiler tobuild the current runtime, and then rebuild (or at least relink),the compiler against the current runtime. (I'm not sure "compile" and "link"apply per se in Modula-3, I'm not sure it builds in quite the traditionalway.)scripts\win\make-dist and scripts\win\upgrade both take care of this.They can both start with a 5.2.6 compiler/runtime, or a current compiler/runtime.They do waste time if starting with current.Yes, they do build the compiler twice.At some point the first computers must have been built from sticks and rocks and dirt,but once they were working, the second computer could be built with more advanced materials.In particular, the first Modula-3 compiler was probably written in C.The first C compiler was probably written in assembly. Or maybe written in C and hand compiled into assembly.The first assembler was probably hand translated into "machine code".Bootstrapping is a funny thing.Circular dependencies seem wrong, but they are necessary.Bootstrappability from earlier than 5.2 I cannot at this time vouch for.I was thinking of trying with 3.6 which I have and 4.1 if I can find my CD.But it might not be easy and it might be fairly pointless.Bootstrapping does tend to lead to building up and up and up and an inabilityto jump from the initial step to the latest. You do, I expect, restthe starting level from time to time.3.6 does still build quite easily out of the box on current systems.I built it last week. :)(Only NT386.) Oh, also, the order "only" matters when you don't have a package store already and/or you are changing types.If you are only changing code, and you already have a packge store you can build in any order.When you are changing types, or don't have a package store, I believe you have to build from the bottom of the dependency graph and on up. If you ignore the compiler, the dependency graph that I have in my head is just m3core, then libm3, then everything else. The compiler, well, you get clear errors as to what is missing if you build it out of order. I'll get some ordering into scripts\python, excluding the circularity. I may be mispresenting the circularity. It's probably really m3core, libm3, then the compiler but in the bootstrapping case, you must already have m3core and libm3, from a different build. The circularity exists, but maybe in sort of different terms. You don't need the compiler's .i3 files published to build libm3/m3core, you just need a cm3.exe. - Jay Date: Fri, 4 Jan 2008 21:12:24 -0500From: rcoleburn at scires.comTo: hosking at cs.purdue.edu; m3devel at elegosoft.com; wagner at elegosoft.com; jayk123 at hotmail.comCC: m3-support at elegosoft.comSubject: Re: [M3devel] M3 concerns Given the current situation, I'm not sure that moderated commits are practical. I think the best route is to get enough tests in place so that all developers can run a regression test suite BEFORE committing changes. Having an automated scoreboard would also help point out where things are broken and need fixing so that folks can volunteer to help. I'll try to find time again this weekend to do a build of cm3 on Windows XP again. If one goes to the website, there seems to be several choices for getting started, so I need some advice on the best way to move forward. 1. Get current sources from head branch and try to build from scratch (after first installing free Microsoft Visual C/C++ tools). 2. Get an older variant (5.2.6, 4.1, etc.) and try to use it to build the new current sources from CVS. 3. Get Jay's d5.5.0 min Win32 and use it to build the current sources from CVS. 4. ?? I know that there are some scripts that have been built to help in building things. One thing that would be helpful I think is to have a text file that lists the correct build sequence order for all packages in the repository. I know that some packages may not build on every platform, but if we keep this text file up-to-date, it would help folks as they work on scripts, etc. Also, I seem to recall that in the past that for some of the core packages, you had to build these twice in the process of getting everything up and running. Again, these facts need to be made very obvious so folks don't go down a wrong path. Once I get started on a path (1..4 above), I also need to know which of the current scripts to use in building on Windows XP to get the best results. I love the language and have been a zealous proponent of it for a long time, but we've got to make it easier for folks to get started with Modula-3. I will carefully document the steps I take in getting the system built on Windows so we can make this available to everyone. As for Jay's comment that he hasn't heard of anyone getting a "broken" version, please understand that I am not directing my comments at any one person, but rather to the system of "checks and balances" that need to be put in place for everyone. The last time I was able to get the sources and build on Windows was v5.26. That version didn't work correctly with some of my programs and I reported the problems to Olaf et al. The last time I checked out the sources and tried to build 5.40, I wound up with compiler errors. I recall some of these were related to LONGINT and some were related to the garbage collector. So yes, there was a situation where I checked out sources that represented a "broken" version in that it would not build. Thus, there are at least two types of "broken": (1) the system sources can't be built correctly, (2) the newly built system causes previously working code to misbehave when recompiled with the new system. Broken #1 should never be allowed to occur for the core system. From what Olaf said, the rule seems to be to keep broken #1 stuff in a branch and only merge it back into the main line when the broken state is resolved. Broken #2 should be avoided using regression test suites. The package status page at http://modula3.elegosoft.com/cm3/package-status.html is headed up by the title CM3 v5.1. Is this page up-to-date? It would be helpful to know where we stand wrt each package on each supported platform relative to the current source tree. Again, I think an automated scoreboard could make this possible. Sorry to ramble on so much in this post. My main interest is in getting the current sources built and running on Windows XP. As soon as I am successful, I will run tests using my code base. I have a number of programs that were built using cm3 v4.1 that are still in use. These use a lot of features, including pickles, netobj, trestle, etc. So, my tests should help uncover Broken #2 problems on Windows. Finally, once I get a working cm3 system on Windows, I'll provide the new cm3-IDE (aka Reactor) package. Regards, Randy>>> Jay 1/4/2008 8:04 PM >>>I oppose most red tape. However branching can be good, as long as there are frequent merges (between once a week and once a month..well, those timelines are based on other contexts, in this context, I don't know) and automated testing/buildmonkeys/tinderboxes. That is, if I'm in a ghetto branch, I loose both the pressure not to break things, because few/nobody else is in the branch, and the feedback loop of hearing that I've broken someone, so automation would be nice to replace that. I am not experienced with CVS though. I don't know how to setup or merge branches. Even browsing history I find painful, in one branch.Perforce I am quite familiar with.Subversion I learned enough about to know it doesn't suffice, so I'm leary of CVS, which is supposedly in all ways worse.In particular, Subversion doesn't track which changes have been merged from one branch to another. Whereas in Perforce that is a key feature of the system. Amazing that Subversion doesn't do it, but it is near the top of their wishlist. This is a small project.I haven't yet heard of anyone getting one of my possibly "in between" changes and being broken, and even when I checkin frequently, that doesn't mean any one state was broken or wrong. I haven't tested anything with Pickes. One set of tests I found failed all over the place, the m3tests stuff, floating point problems, I think a bunch of never implemented stuff on Windows around calling _fpcontrol or such (platform dependent). The system does build itself, the compiler and "std" packages. I consider that a pretty good start.I realize you can always do more, more and less obvious. There's probably no threading in the compiler, and maybe not even any garbage collection, nor any pickles. I'll look what Olaf commited over the weekend.. Bah humbug and happy new year, :) - Jay > Date: Sat, 5 Jan 2008 01:13:35 +0100> From: wagner at elegosoft.com> To: hosking at cs.purdue.edu; m3devel at elegosoft.com> CC: m3-support at elegosoft.com> Subject: Re: [M3devel] M3 concerns> > Quoting Tony Hosking :> > > My comments embedded:> >> > On Jan 4, 2008, at 4:10 PM, Olaf Wagner wrote:> > >> Ah well, Windows is a somewhat special topic. I even haven't a system> >> here for tests, and most of the other contributors don't use it either.> >> I was of the opinion that Jay Krell had fixes or workarounds for most> >> current problems (except for the missing LONGINT support), but I haven't> >> tried his distribution archives yet. It would indeed be very helpful> >> if we could setup regression tests on Windows, too.> >> > LONGINT = INTEGER on Windows, which is fine as far as it goes> > (everything builds appropriately), but not particularly useful.> > I know that it should run this way, but pickles for example wouldn't> be exchangeable then, would they? Has anybody tested pickle support> for LONGINT yet?> > >> It would also be possible to define a group of reviewers for every> >> change, but I doubt that there would be enough competent volunteers,> >> and I'm afraid that it would rather repress development of CM3.> >> And we really need to have development, as the underlying systems and> >> techniques change and we need to adapt to that. So I'd vote for> >> free commits for everybody, as long as there are not too many> >> contributors, and setup of continually improved regression testing.> >> And we don't need to worry, as all changes can be reverted; we won't> >> lose development history with CVS.> >> > One option is to have moderated commits for non-core developers. After> > someone has earned the trust of the core developers they can be elected> > as a member of the core team. This approach is used with the Jikes RVM> > (www.jikesrvm.org).> > I wouldn't object to such a policy, though I don't really think that> it is currently necessary. But if more active committers do prefer> it, we can set up the necessary commit checks. I assume that Randy Coleburn> and you are in favour of restricted commits? What about the others?> > Who would volunteer to review commits from other people? Would this> be a responsibility inherited by the unrestricted access?> > Should we allow commits to branches and only restrict access to the> main line?> > Olaf> -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194> Share life as it happens with the new Windows Live. Start sharing! Share life as it happens with the new Windows Live. Start sharing! Put your friends on the big screen with Windows Vista? + Windows Live?. Start now! _________________________________________________________________ Put your friends on the big screen with Windows Vista? + Windows Live?. http://www.microsoft.com/windows/shop/specialoffers.mspx?ocid=TXT_TAGLM_CPC_MediaCtr_bigscreen_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: From lemming at henning-thielemann.de Sat Jan 5 09:44:40 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Sat, 05 Jan 2008 09:44:40 +0100 (CET) Subject: [M3devel] M3 concerns In-Reply-To: <20080105013307.GB5064@topoi.pooq.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> <20080105013307.GB5064@topoi.pooq.com> Message-ID: On Fri, 4 Jan 2008 hendrik at topoi.pooq.com wrote: > gravityboy (http://gravityboy.livejournal.com/39755.html) has a few > things to say about people who compare svn with cvs: essentially, he > says cvs is so obsolete no one should even be comparing things with it > any more. Saying something is better than CVS is like saying that > a new model of automatic washing machines work better than rocks by the > side of the river. When I was moving from CVS to Darcs, a popular distributed versioning software in the Haskell world, one of my colleagues gave a talk about RCS. I wondered why he still uses and promotes RCS, when even CVS was too restricted for me. However after the talk many of my colleagues seconded his attitude, because CVS was already too complicated for them. To be honest, I still use CVS for small projects, when other machines are invoked, where I can't install Darcs. CVS has the charme, that you have the versioning data in a readable form. You could even repair small damages manually, if it is necessary. From wagner at elegosoft.com Sat Jan 5 13:49:52 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 05 Jan 2008 13:49:52 +0100 Subject: [M3devel] NT386GNU? 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> Message-ID: <20080105134952.6kvyefcy8c0gswkg@mail.elegosoft.com> Quoting Jay : > I assume NT386GNU remains very interesting to folks. Right? > Anyone know what's the deal with it? > Little work? Lots of work? > It'd net LONGINT at least. > I realize you'd need sh/awk/sed/gmake/etc., and ld. > You'd start by installing mingwin or cygwin. > And they (or one) would likely be required for all users, at least > for ld and some libs.I assume cygwin/mingwin have long since > merged to mainline. > I'll try to look into it..... CM3 never had a working NT386GNU target, though PM3 had. It would be great, as this is a POSIX system running on Windows (based on Cygwin32). Some years ago, when I still had a working NT system, I could never get cm3cg backends based on anything above gcc 2.95 to work on Cygwin. They always produced segmentation violations. But I haven't tried for many years now, so things may have changed. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Jan 5 14:32:35 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 05 Jan 2008 14:32:35 +0100 Subject: [M3devel] M3 concerns In-Reply-To: <20080105011719.GA5064@topoi.pooq.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> Message-ID: <20080105143235.ujed2tl3ksogws8k@mail.elegosoft.com> Discussions seem to loose their focus quiet easy on this list :-/ I'd strongly prefer if we could keep the discussion of alternative version control systems out of this. It won't help us, and you can trust this opinion as I really know many version control systems (SCCS, RCS, CVS, Subversion, ClearCase, PVCS Dimensions, Perforce, AccuRev, OpenCM, Vesta,...). I can assure you that CVS is quite adequate for the simple purposes and requirements we have. Changing will make things different, but not better, and cost a lot of efforts we should rather invest into other topics. I'd like to get back to the original topic. How do we need to improve the CM3 development process to ensure and increase the overall quality of the CM3 code base? Could everybody interested in this discussion please just comment on the following items to state his opinion: 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). Technical details should be discussed in a different thread. o Do we need / want to restrict the commit access for the CM3 code repositories? If so, only for certain areas, or for everything? This would be a distinction based on packages. Should we allow or prefer committing new code to branches and merge the resulting change sets based on reviews? (I could also contribute automatic support for creating change sets on branches, as this is part of the DCVS functionality elego developed some time ago). This would be a distinction based on code lines. Yesterday I had the impression that some members of this list would prefer some access restriction, but I'm not really sure. o I'm not sure if and how we should include the Windows target problems here. They were part of the original mail, but seem to belong to another category to me, at least have different causes. Suggestions what exactly to discuss are welcome. o To reach a conclusion on these topics, I suggest that we simply count the majority of opinions of list members that care to participate in this discussion. I'll try to summarize again after everybody has had time for consideration and has spoken up (or remained silent). I'd suggest to continue the discussion for the following week. Please try to keep comments short :-) Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Jan 5 18:06:01 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 05 Jan 2008 18:06:01 +0100 Subject: [M3devel] M3 concerns / Windows problems In-Reply-To: <477EA137.1E75.00D7.1@scires.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> <477EA137.1E75.00D7.1@scires.com> Message-ID: <20080105180601.unyynodmqswo44cs@mail.elegosoft.com> Quoting Randy Coleburn : > I'll try to find time again this weekend to do a build of cm3 on > Windows XP again. That would be great. > 3. Get Jay's d5.5.0 min Win32 and use it to build the current sources > from CVS. I'd choose this one. > I know that there are some scripts that have been built to help in > building things. One thing that would be helpful I think is to have a > text file that lists the correct build sequence order for all > packages in the repository. I know that some packages may not build on > every platform, but if we keep this text file up-to-date, it would help > folks as they work on scripts, etc. The file that lists all packages in order is scripts/def-std-pkgs.sh, though some may be missing from it. It's in Bourne shell format though. A compiler bootstrap may need another more complex order, where some packages are compiled twice at least though. The upgrade process should be automated in scripts/upgrade.sh (for most scenarios). This is due to subtle dependencies between the compiler and the runtime libraries. > Also, I seem to recall that in the past that for some of the core > packages, you had to build these twice in the process of getting > everything up and running. Again, these facts need to be made very > obvious so folks don't go down a wrong path. As explained above... > Once I get started on a path (1..4 above), I also need to know which of > the current scripts to use in building on Windows XP to get the best > results. You should be able to use all, though for the shell scripts you need a POSIX environment (like Cygwin), for the Python scripts you obviously need a Python installation (and they are quiet new, I don't know about their status); easiest will probably be Jay's CMD scripts for Windows. So I think upgrade,cmd would be a good start, followed probably by do-cm3-std.cmd. > I love the language and have been a zealous proponent of it for a long > time, but we've got to make it easier for folks to get started with > Modula-3. I will carefully document the steps I take in getting the > system built on Windows so we can make this available to everyone. I second this. > The last time I was able to get the sources and build on Windows was > v5.26. That version didn't work correctly with some of my programs and > I reported the problems to Olaf et al. The last time I checked out the > sources and tried to build 5.40, I wound up with compiler errors. I > recall some of these were related to LONGINT and some were related to > the garbage collector. So yes, there was a situation where I checked > out sources that represented a "broken" version in that it would not > build. I think that the head of the tree is quiet often broken wrt. a simple compilation of all packages, and sometimes even broken wrt. to the standard compiler upgrade procedure. This is really difficult to foresee for many commits, if they concern the runtime and/or compiler extensions. It's the main reason why I think we need automated regression tests on as many platforms as possible. > The package status page at > http://modula3.elegosoft.com/cm3/package-status.html is headed up by > the title CM3 v5.1. Is this page up-to-date? It would be helpful to > know where we stand wrt each package on each supported platform relative > to the current source tree. Again, I think an automated scoreboard > could make this possible. No, the package status hasn't been updated for a long time. There are lots of things that would need updating. Volunteers are welcome. Once we've got automated tests, this page could be generated, too. > Sorry to ramble on so much in this post. My main interest is in > getting the current sources built and running on Windows XP. As soon as > I am successful, I will run tests using my code base. I have a number > of programs that were built using cm3 v4.1 that are still in use. These > use a lot of features, including pickles, netobj, trestle, etc. So, my > tests should help uncover Broken #2 problems on Windows. IIRC, the main problems we at Elego had with Windows years ago were mostly GUI-related; the base stuff was working well. Unfortunately, there was noone with Windows GUI programming experience at that time :-( > Finally, once I get a working cm3 system on Windows, I'll provide the > new cm3-IDE (aka Reactor) package. This will be great and long-awaited indeed. I hope you succeed, Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From hendrik at topoi.pooq.com Sat Jan 5 19:54:30 2008 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Sat, 5 Jan 2008 13:54:30 -0500 Subject: [M3devel] 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> <20080105013307.GB5064@topoi.pooq.com> Message-ID: <20080105185430.GA6402@topoi.pooq.com> On Sat, Jan 05, 2008 at 09:44:40AM +0100, Henning Thielemann wrote: > > On Fri, 4 Jan 2008 hendrik at topoi.pooq.com wrote: > > > gravityboy (http://gravityboy.livejournal.com/39755.html) has a few > > things to say about people who compare svn with cvs: essentially, he > > says cvs is so obsolete no one should even be comparing things with it > > any more. Saying something is better than CVS is like saying that > > a new model of automatic washing machines work better than rocks by the > > side of the river. > > When I was moving from CVS to Darcs, a popular distributed versioning > software in the Haskell world, one of my colleagues gave a talk about RCS. > I wondered why he still uses and promotes RCS, when even CVS was too > restricted for me. However after the talk many of my colleagues seconded > his attitude, because CVS was already too complicated for them. > To be honest, I still use CVS for small projects, when other machines are > invoked, where I can't install Darcs. CVS has the charme, that you have > the versioning data in a readable form. You could even repair small > damages manually, if it is necessary. What I like about monotone is its absolute paranoia about losing data. When it is syncing different "copies" of the repository, apparently much of the time is spent making sure that the ancient history hasn't been corrupted, and that the data being transferred from one to the other hasn't been corrupted either. And having multiple repositories really does make it hard to lose data. The original CVS, I'm told, was a set of scripts operating on top of RCS. I don't know what it is now. -- hendrik From dabenavidesd at yahoo.es Sat Jan 5 20:06:41 2008 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Sat, 5 Jan 2008 20:06:41 +0100 (CET) Subject: [M3devel] cvsup fix latest cm3 (Scheduler.DisableSwitching, EnableSwitching) Message-ID: <835827.15730.qm@web27109.mail.ukl.yahoo.com> H all: I get some error compiling cvsup (sublib) because of the change on the Scheduler interface of Pthread, It's not hard to fix (importing Scheduler instead of SchedulerPosix). This for your knowledge, with this fixes it compiles and runs well. "../src/Ugzip.m3", line 63: unknown qualification '.' (DisableSwitching) "../src/Ugzip.m3", line 67: unknown qualification '.' (EnableSwitching) "../src/Ugzip.m3", line 74: unknown qualification '.' (DisableSwitching) "../src/Ugzip.m3", line 78: unknown qualification '.' (EnableSwitching) 4 errors encountered new source -> compiling Umd5.i3 new source -> compiling StatusFile.m3 new source -> compiling CVTree.i3 new source -> compiling CVTree.m3 "../src/CVTree.m3", line 315: unknown qualification '.' (DisableSwitching) "../src/CVTree.m3", line 319: unknown qualification '.' (EnableSwitching) "../src/CVTree.m3", line 325: unknown qualification '.' (DisableSwitching) "../src/CVTree.m3", line 329: unknown qualification '.' (EnableSwitching) "../src/CVTree.m3", line 335: unknown qualification '.' (DisableSwitching) "../src/CVTree.m3", line 339: unknown qualification '.' (EnableSwitching) 6 errors encountered --------------------------------- Web Revelaci?n Yahoo! 2007: Premio Favorita del P?blico - ?Vota tu preferida! -------------- next part -------------- An HTML attachment was scrubbed... URL: From hendrik at topoi.pooq.com Sat Jan 5 20:12:43 2008 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Sat, 5 Jan 2008 14:12:43 -0500 Subject: [M3devel] M3 concerns In-Reply-To: <20080105143235.ujed2tl3ksogws8k@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> Message-ID: <20080105191243.GB6402@topoi.pooq.com> On Sat, Jan 05, 2008 at 02:32:35PM +0100, Olaf Wagner wrote: > Discussions seem to loose their focus quiet easy on this list :-/ > > I'd strongly prefer if we could keep the discussion of alternative > version control systems out of this. It won't help us, and you can > trust this opinion as I really know many version control systems > (SCCS, RCS, CVS, Subversion, ClearCase, PVCS Dimensions, Perforce, > AccuRev, OpenCM, Vesta,...). I can assure you that CVS is quite > adequate for the simple purposes and requirements we have. Changing > will make things different, but not better, and cost a lot of efforts > we should rather invest into other topics. I quite agree. But if you have this experience, it would be useful to see a rundown of the advantages and disadvantages of each. I've seen a table of features against version control systems, but it doesn't give any feel for what it's like to use them. Such an essay would be useful for those involved in other projects. It probably won't help Modula 3 itself. Or might you know of such an essay elsewhere? -- hendrik > > I'd like to get back to the original topic. How do we need to improve > the CM3 development process to ensure and increase the overall quality > of the CM3 code base? Could everybody interested in this discussion > please just comment on the following items to state his opinion: > > 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). > > Technical details should be discussed in a different thread. > > o Do we need / want to restrict the commit access for the CM3 > code repositories? At the very least, you should keep spammers out. > > If so, only for certain areas, or for everything? This would > be a distinction based on packages. > > Should we allow or prefer committing new code to branches and > merge the resulting change sets based on reviews? (I could also > contribute automatic support for creating change sets on branches, > as this is part of the DCVS functionality elego developed some time > ago). This would be a distinction based on code lines. What's the 'D' of 'DVCS'? > Yesterday I had the impression that some members of this list > would prefer some access restriction, but I'm not really sure. The real questions are whether corrupt code is checked in often enough to cause trouble to other developers, whether check-in conflicts happen enough to be troublesome, and whether the red tape of lots of branches would be more trouble than it is worth. I don't know the answer to this. For preparing regular stable releases, it is probably worthwhile to freeze development on a release branch, but to keep fixing bugs on both the development and the release branches. As for reviews of changes, that should happen whether there's an access restriction or not. It may be the most important role of those who are knowledgeable with the code base. And they should probably happen before debugging. -- hendrik From wagner at elegosoft.com Sat Jan 5 21:00:05 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 05 Jan 2008 21:00:05 +0100 Subject: [M3devel] more m3tests failures Message-ID: <20080105210005.7iacdx5nkks84osk@mail.elegosoft.com> I've looked into some more failures of m3tests, which I'd like to present to the whole list: (All tests run on FreeBSD 6.3) p035 is a scoping problem which was Ok with /usr/local/cm3/bin/cm3cg-5.4.0 but /usr/local/cm3/bin/cm3cg-d5.5.1 fails, so it must be caused by recent gcc changes. The check that fails is PROCEDURE foo (p: P; same: BOOLEAN) = BEGIN checkB (bar = p, same); checkB (bar # p, NOT same); END foo; PROCEDURE bar (<*UNUSED*> t: Text.T) = BEGIN END bar; BEGIN msg ("group M"); foo (bar, TRUE); msg ("group N"); foo (dummy, FALSE); END; p040 fails due to differences in floating point precision; the numbers on FreeBSD seem to have a higher precision. +++ ../src/p0/p040/stdout.pgm 2003-03-08 11:14:03.000000000 +0100 @@ -964,85 +964,85 @@ ToLongFloat => 0.1 / 3 -0.001234567890123456 +0.0012345678901235 - FromLongFloat [Flo] => 0.001234567890123 - ToLongFloat => 0.001234567890123 / 17 - FromLongFloat [AltFlo] => 0.001234567890123 - ToLongFloat => 0.001234567890123 / 17 - FromLongFloat [Sci] => 1.234567890123456D-3 - ToLongFloat => 0.001234567890123456 / 20 - FromLongFloat [AltSci] => 1.234567890123456D-3 - ToLongFloat => 0.001234567890123456 / 20 - FromLongFloat [Mix] => 0.001234567890123 - ToLongFloat => 0.001234567890123 / 17 + FromLongFloat [Flo] => 0.001234567890124 + ToLongFloat => 0.001234567890124 / 17 + FromLongFloat [AltFlo] => 0.001234567890124 + ToLongFloat => 0.001234567890124 / 17 + FromLongFloat [Sci] => 1.234567890123500D-3 + ToLongFloat => 0.0012345678901235 / 20 + FromLongFloat [AltSci] => 1.2345678901235D-3 + ToLongFloat => 0.0012345678901235 / 18 + FromLongFloat [Mix] => 0.001234567890124 + ToLongFloat => 0.001234567890124 / 17 I'm not sure here what to do, as well as for p070, which tests fingerprints for procedures, and is not implemented in CM3. Do we need that? From RTProcedure.m3: PROCEDURE ToFingerprint (<*UNUSED*> p: Proc): Fingerprint.T = BEGIN <*ASSERT FALSE, "RTProcedure.ToFingerprint is not supported" *> RETURN Fingerprint.Zero; <*NOWARN*> END ToFingerprint; PROCEDURE FromFingerprint (<*UNUSED*> READONLY fp: Fingerprint.T): Proc = BEGIN <*ASSERT FALSE, "RTProcedure.FromFingerprint is not supported" *> RETURN NIL; <*NOWARN*> END FromFingerprint; Or should we deactivate that test? p096 fails with @@ -1,3 +1,2 @@ "../src/Main.m3", line 27: default is not a procedure constant (m) 1 error encountered -Fatal Error: package build failed --- p0/p096/stderr.build 2008-01-05 18:27:24.000000000 +0100 +++ ../src/p0/p096/stderr.build 2003-03-08 11:14:05.000000000 +0100 because of this code: MODULE Main; CONST K = T.m; L = Q; TYPE TProc = PROCEDURE(s: T); CONST A = ARRAY OF TProc{Q}; TYPE T = OBJECT METHODS m() := L; END; ST1 = T OBJECT OVERRIDES m := K END; (*** ILLEGAL *** ST2 = T OBJECT OVERRIDES m := TProc END; ***) ST3 = T OBJECT OVERRIDES m := A[0]; END; PROCEDURE Q(s: T) = BEGIN EVAL s END Q; VAR t: T; st1: ST1; st3: ST3; BEGIN EVAL t; EVAL st1; EVAL st3; END Main. I think I can somehow understand the compiler here. Did this ever work? p116 first fails because FlotMode procedures are not implemented by default: +++ ../src/p1/p116/stderr.pgm 2003-03-08 11:13:53.000000000 +0100 @@ -1,11 +1,3 @@ - - -*** -*** runtime error: -*** <*ASSERT*> failed: FloatMode.SetRounding not implemented -*** file "../src/float/IEEE-default/FloatMode.m3", line 14 -*** - ---------------------------- REAL --- 1.0/0.0 # 1.0/(-0.0) test OK 1.0/0.0 = 1.0/(- (-0.0)) test OK I think this should be tested conditionally depending on platform. But then more checks fail: @@ -25,14 +17,14 @@ Class (MaxFinite*ten) test OK Finite (MaxFinite*ten) test OK IsNaN (MaxFinite*ten) test OK -** Class (zero/zero) test not OK: FALSE should be TRUE + Class (zero/zero) test OK Finite (zero/zero) test OK IsNaN (zero/zero) test OK Sign (zero) test OK Sign (minusZero) test OK - Unordered (zero, NaN) test OK +** Unordered (zero, NaN) test not OK: FALSE should be TRUE Unordered (zero, zero) test OK - Unordered (NaN, NaN) test OK +** Unordered (NaN, NaN) test not OK: FALSE should be TRUE Differs (zero, NaN) test OK which refers to the test lines BCheck("Class (zero/zero)", RealFloat.Class(x) = IEEEClass.QuietNaN, TRUE); BCheck("Unordered (zero, NaN)", RealFloat.Unordered(zero, NaN), TRUE); BCheck("Unordered (NaN, NaN)", RealFloat.Unordered(NaN, NaN), TRUE); Especially the last one suprises me, but I'm no specialist in arithmetics. Is this to be expected? Should we tolerate or can we fix it? So far for now, I need to prepare dinner now, Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From dabenavidesd at yahoo.es Sun Jan 6 02:26:48 2008 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Sun, 6 Jan 2008 02:26:48 +0100 (CET) Subject: [M3devel] Problem with an exmaple of Modula-3 tutorial Message-ID: <316462.45428.qm@web27102.mail.ukl.yahoo.com> Hi all: I was showing an example to a friend of the Modula-3 tutorial, but we ran into an error with the first one: http://modula3.elegosoft.com/cm3/doc/tutorial/m3/m3_2.html#SEC2 MODULE Main ; IMPORT IO; (* So we can print things *) VAR name: TEXT; (* a string variable called "name" *) BEGIN IO.Put("Enter your name: "); IO.GetLine(name); IO.Put("Your name is: " & name & "\n"); END Main. "../src/Main.m3", line 9: incompatible types (rd) Well fortunately we have this great documentation of the interfaces, so a correct (not formally proved) code is: MODULE Main; IMPORT IO; (* So we can print things *) VAR name: TEXT; (* a string variable called "name" *) BEGIN IO.Put("Enter your name: "); name:=IO.GetLine(); IO.Put("Your name is: " & name & "\n"); END Main. I have a cvs account, I cancheck it also for prepare my knowledge and merge some modifications of m3-lectern packages to be able to compile them. Thanks for the great work you have done to keep this wonderful enviroment going on in so many platforms. Happy new years modula-3 developers !! Daniel Benavides --------------------------------- Web Revelaci?n Yahoo! 2007: Premio Favorita del P?blico - ?Vota tu preferida! -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.caltech.edu Sun Jan 6 02:59:23 2008 From: mika at async.caltech.edu (Mika Nystrom) Date: Sat, 05 Jan 2008 17:59:23 -0800 Subject: [M3devel] M3 concerns In-Reply-To: Your message of "Fri, 04 Jan 2008 21:12:24 EST." <477EA137.1E75.00D7.1@scires.com> Message-ID: <200801060159.m061xNjc047849@camembert.async.caltech.edu> "Randy Coleburn" writes: > > >> Date: Sat, 5 Jan 2008 01:13:35 +0100 >> From: wagner at elegosoft.com >> To: hosking at cs.purdue.edu; m3devel at elegosoft.com >> CC: m3-support at elegosoft.com >> Subject: Re: [M3devel] M3 concerns >> >> Quoting Tony Hosking : >> >> > My comments embedded: >> > >> > On Jan 4, 2008, at 4:10 PM, Olaf Wagner wrote: >> >> >> Ah well, Windows is a somewhat special topic. I even haven't a >system >> >> here for tests, and most of the other contributors don't use it >either. >> >> I was of the opinion that Jay Krell had fixes or workarounds for >most >> >> current problems (except for the missing LONGINT support), but I >haven't >> >> tried his distribution archives yet. It would indeed be very >helpful >> >> if we could setup regression tests on Windows, too. >> > >> > LONGINT = INTEGER on Windows, which is fine as far as it goes >> > (everything builds appropriately), but not particularly useful. >> >> I know that it should run this way, but pickles for example wouldn't >> be exchangeable then, would they? Has anybody tested pickle support >> for LONGINT yet? Well, I think this depends on exactly what you (not sure who said this originally) mean by "LONGINT = INTEGER". What you say is true if indeed LONGINT and INTEGER are the same type. If, however, they are different types (as they should be), which just happen to be of the same size (on Windows/i386), there should be no problem. The Pickle library (at least ver. 2) transparently performs endianness reordering and word-size adjustments. (Pickles *should* be exchangeable between 32- and 64-bit architectures, for example, and between big-endian sparcs and little-endian i386s and alphas---this latter property I use to exchange pickles between PPC_DARWIN and FreeBSD4.) Of course, have all the proper hooks been called to enable this? I don't know, I just know it's definitely possible to set things up so that Pickles are exchangeable even under these conditions. Mika From hosking at cs.purdue.edu Sun Jan 6 04:41:33 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 5 Jan 2008 22:41:33 -0500 Subject: [M3devel] M3 concerns In-Reply-To: <200801060159.m061xNjc047849@camembert.async.caltech.edu> References: <200801060159.m061xNjc047849@camembert.async.caltech.edu> Message-ID: <8C8CF668-F1C6-475B-B67A-EA3DCDC7509C@cs.purdue.edu> On Jan 5, 2008, at 8:59 PM, Mika Nystrom wrote: > "Randy Coleburn" writes: >> >> >>>> >>>> LONGINT = INTEGER on Windows, which is fine as far as it goes >>>> (everything builds appropriately), but not particularly useful. >>> >>> I know that it should run this way, but pickles for example wouldn't >>> be exchangeable then, would they? Has anybody tested pickle support >>> for LONGINT yet? > Sorry, yes, I was incorrect in saying LONGINT=INTEGER on WIN32. In fact, they are distinct types that just happen to have the same representation, so the backend can handle them. > Well, I think this depends on exactly what you (not sure who said > this originally) mean by "LONGINT = INTEGER". What you say is true > if indeed LONGINT and INTEGER are the same type. If, however, they > are different types (as they should be), which just happen to be > of the same size (on Windows/i386), there should be no problem. > The Pickle library (at least ver. 2) transparently performs endianness > reordering and word-size adjustments. (Pickles *should* be > exchangeable between 32- and 64-bit architectures, for example, and > between big-endian sparcs and little-endian i386s and alphas---this > latter property I use to exchange pickles between PPC_DARWIN and > FreeBSD4.) Of course, have all the proper hooks been called to > enable this? I don't know, I just know it's definitely possible > to set things up so that Pickles are exchangeable even under these > conditions. > > Mika From wagner at elegosoft.com Sun Jan 6 13:01:46 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Sun, 06 Jan 2008 13:01:46 +0100 Subject: [M3devel] Problem with an exmaple of Modula-3 tutorial In-Reply-To: <316462.45428.qm@web27102.mail.ukl.yahoo.com> References: <316462.45428.qm@web27102.mail.ukl.yahoo.com> Message-ID: <20080106130146.46qwab3808wkogwc@mail.elegosoft.com> Quoting "Daniel Alejandro Benavides D." : > Hi all: > I was showing an example to a friend of the Modula-3 tutorial, but > we ran into an error with the first one: > > http://modula3.elegosoft.com/cm3/doc/tutorial/m3/m3_2.html#SEC2 > > > MODULE Main ; > > IMPORT IO; (* So we can print things *) > > VAR name: TEXT; (* a string variable called "name" *) > > BEGIN > IO.Put("Enter your name: "); > IO.GetLine(name); > IO.Put("Your name is: " & name & "\n"); > END Main. > > "../src/Main.m3", line 9: incompatible types (rd) > > Well fortunately we have this great documentation of the interfaces, > so a correct (not formally proved) code is: > > MODULE Main; > > IMPORT IO; (* So we can print things *) > > VAR name: TEXT; (* a string variable called "name" *) > > BEGIN > IO.Put("Enter your name: "); > name:=IO.GetLine(); > IO.Put("Your name is: " & name & "\n"); > END Main. > > I have a cvs account, I cancheck it also for prepare my knowledge > and merge some modifications of m3-lectern packages to be able to > compile them. Please check in any corrections you'd care to do and let m3-support know about when to ship updates to the web server. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Jan 6 20:39:03 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Sun, 06 Jan 2008 20:39:03 +0100 Subject: [M3devel] M3 concerns / automated regression tests In-Reply-To: <477B7629.1E75.00D7.1@scires.com> References: <477B7629.1E75.00D7.1@scires.com> Message-ID: <20080106203903.tav3gl9c00ow8ggc@mail.elegosoft.com> Quoting Randy Coleburn : > Question: As various people make contributions and changes, is > there any group of folks who is verifying that the changes don't > break existing code or core principles? Another idea would be to > have a series of test batteries that have to be passed before > changes can be accepted. I know of a number of projects where many > people contribute, but the contributions have to be vetted by > passing some tests. > > Without these types of controls, I fear that good forward progress > will inevitably be hampered or compromised by changes made by > someone who hasn't completely thought out and tested the > ramifications of those changes. As announced in other mails, I'd like to get into some details of the regression test standardization I suggest. As you may have noticed, several scripts have been committed to cm3/scripts/regression/. There are some scripts for the integration of tests into the elego tinderbox framework, which are still work in progress. Kaspar Schleiser is working on this; it may take some days before everything works as expected. The main functions for test standardization are contained in the file defs.sh. This is a shell script which can be sourced and used in different contexts. It contains functions for CVS checkout, binary installation, and the actual tests. In my opinion, the most important thing that should be ensured is that the current sources can be compiled with the latest official release of the system. This can get tricky in case of incompatible changes in the compiler runtime, frontend, or configuration (cm3.cfg). So the main part of test_build_core_rel() is an upgrade performed by scripts/upgrade.sh based on the last release. In order to use this, it must of course be installed. This can be done with install_bin_dist(). The test framework uses three installations of CM3, located in INSTBASE, which defaults to ${HOME}/work/cm3-inst. There are rel-${LASTREL}, e.g. rel-5.4.0 current last-ok rel-x.x.x should contain at least a minimal installation of the last official release. It may have to be installed manually, as the installer was interactive until recently. (This has been changed in d5.5.1.) current always contains the CM3 installation which is used for actual shipping during test builds and is usually based on the current sources. last-ok is always updated with the last successfully built version. The workspaces which are used for checkout and compilation contain date stamps in their name, eg. ~/work/cm3-ws-2008-01-04-20-05-06/. They can be set with the variables DS and WS: DS=${DS:-`date -u +'%Y-%m-%d-%H-%M-%S' | tr -d '\\n'`} WS=${WS:-${HOME}/work/cm3-ws-${DS}} Apart from building with the latest release, there are currently the following tests automated: o building the core system with the last-ok version. This will work until anybody checks in an incompatible change for the runtime, frontend, or configuration. It may be used as an indicator that a full upgrade procedure is necessary from this point in time. As this is expected to fail eventually, it should not be considered fatal. This is performed by test_build_core_lastok(). o building the complete set of standard packages with the last-ok / current version. This excludes the compiler itself, and will give an indication if the second step of the bootstrap after initial installation works (installing all standard packages with the minimal system). This is done by test_build_std_lastok(). o building of a minimal binary installation archive. This will ensure that we can actually build a new release for the tested platform. It is done by test_make_bin_dist(). The produced archives can be distributed as current snapshots. o testall() and main() simply combine all tests into one run which might be done nightly. This is currently not compatible with the intended tinderbox integration though. Needed extensions: o The actual compiler regression tests (m3tests) need to be included. I've imported them 2003 from the PM3 distribution, but they are not in a good shape. I've started to work on them, but will need help of others; you will have noticed my messages. o There are many more package-related regression tests, which need to be added, too. I don't know about the status of most though, so this will be a tedious task, too. We could distinguish between tests for core packages work/cm3/m3-libs/binIO/test work/cm3/m3-libs/bitvector/test work/cm3/m3-libs/libm3/tests work/cm3/m3-libs/libm3/tests/rw/autotest work/cm3/m3-libs/m3core/tests work/cm3/m3-libs/patternmatching/tests work/cm3/m3-libs/slisp/tests work/cm3/m3-libs/sortedtableextras/tests and others work/cm3/caltech-parser/drawcontext/test work/cm3/caltech-parser/m3tmplhack/test work/cm3/caltech-parser/parserlib/parserlib/test work/cm3/caltech-parser/parserlib/parserlib/test_stdin work/cm3/m3-comm/events/tests work/cm3/m3-comm/events/tests/test work/cm3/m3-comm/netobj/tests work/cm3/m3-comm/rdwr/test work/cm3/m3-comm/serial/test work/cm3/m3-comm/sharedobj/tests work/cm3/m3-comm/sharedobj/tests/netobjtest work/cm3/m3-comm/sharedobjgen/test work/cm3/m3-comm/udp/test work/cm3/m3-db/db/test work/cm3/m3-db/odbc/test work/cm3/m3-db/pgodbc/test work/cm3/m3-db/postgres95/test work/cm3/m3-db/stable/test work/cm3/m3-libs/dps/test work/cm3/m3-libs/synthesizer/test work/cm3/m3-libs/tcl/test work/cm3/m3-libs/deepcopy/test work/cm3/m3-libs/plplot/test work/cm3/m3-libs/arithmetic/test work/cm3/m3-libs/fftw/test work/cm3/m3-libs/lapack/test work/cm3/m3-libs/unittest work/cm3/m3-libs/unittest-numeric work/cm3/m3-libs/wellfett/test work/cm3/m3-sys/m3modinittest work/cm3/m3-ui/juno-2/juno-app/juno-src/test work/cm3/m3-ui/juno-2/juno-app/juno-src/testRedundant work/cm3/m3-ui/juno-2/juno-compiler/tests work/cm3/m3-ui/ui/test work/cm3/m3-ui/motif/tests work/cm3/m3-ui/ui-tests work/cm3/m3-ui/vbtkit/src/vtext/testing I'll try these after m3tests are working. Of course, contributions of others are welcome for all these. As a start, it may be a good idea if those interested in running regular tests could try the core test framework. What needs to be done is o ( . ./scripts/regression/defs.sh; install_bin_dist ) once, potentially manuallly, or with overwriting the cminstall program to use something current: ( export CMINSTALL=...; . ./scripts/regression/defs.sh; install_bin_dist ) This expects the latest binary installation archive in your home directory. o Now tests should be able to run on a regular basis like this: ( . ./scripts/regression/defs.sh; main ) This will create a new workspace, checkout the current sources, and perform all the tests described above. I've tried this now on a FreeBSD 6.2 and Debian Linux system. It may well be that more adaptions and extensions to the scripts are necessary, but we have to try. If the above works for others, too, we can turn to the tinderbox integration to gather all the results in a database and display them. You may have a look at the results at http://tinderbox.elegosoft.com/ http://tinderbox.elegosoft.com/cm3/status.html Keep in mind that this work is not finished yet. Please let me know of any problems, improvements, or just comments. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From hosking at cs.purdue.edu Sun Jan 6 22:29:58 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 6 Jan 2008 16:29:58 -0500 Subject: [M3devel] more m3tests failures In-Reply-To: <20080105210005.7iacdx5nkks84osk@mail.elegosoft.com> References: <20080105210005.7iacdx5nkks84osk@mail.elegosoft.com> Message-ID: <5BED31CE-54AB-44CB-905A-E19ED6B0435A@cs.purdue.edu> On Jan 5, 2008, at 3:00 PM, Olaf Wagner wrote: > I've looked into some more failures of m3tests, which I'd like to > present to the whole list: (All tests run on FreeBSD 6.3) > > p035 is a scoping problem which was Ok with > > /usr/local/cm3/bin/cm3cg-5.4.0 > > but > > /usr/local/cm3/bin/cm3cg-d5.5.1 > > fails, so it must be caused by recent gcc changes. The check that > fails is > > PROCEDURE foo (p: P; same: BOOLEAN) = > BEGIN > checkB (bar = p, same); checkB (bar # p, NOT same); > END foo; > PROCEDURE bar (<*UNUSED*> t: Text.T) = > BEGIN > END bar; > BEGIN > msg ("group M"); foo (bar, TRUE); > msg ("group N"); foo (dummy, FALSE); > END; Hmm. Something is broken with load_static_link. I will look into it. > > p040 fails due to differences in floating point precision; the numbers > on FreeBSD seem to have a higher precision. > > +++ ../src/p0/p040/stdout.pgm 2003-03-08 11:14:03.000000000 +0100 > @@ -964,85 +964,85 @@ > ToLongFloat => 0.1 / 3 > > > -0.001234567890123456 > +0.0012345678901235 > > - FromLongFloat [Flo] => 0.001234567890123 > - ToLongFloat => 0.001234567890123 / 17 > - FromLongFloat [AltFlo] => 0.001234567890123 > - ToLongFloat => 0.001234567890123 / 17 > - FromLongFloat [Sci] => 1.234567890123456D-3 > - ToLongFloat => 0.001234567890123456 / 20 > - FromLongFloat [AltSci] => 1.234567890123456D-3 > - ToLongFloat => 0.001234567890123456 / 20 > - FromLongFloat [Mix] => 0.001234567890123 > - ToLongFloat => 0.001234567890123 / 17 > + FromLongFloat [Flo] => 0.001234567890124 > + ToLongFloat => 0.001234567890124 / 17 > + FromLongFloat [AltFlo] => 0.001234567890124 > + ToLongFloat => 0.001234567890124 / 17 > + FromLongFloat [Sci] => 1.234567890123500D-3 > + ToLongFloat => 0.0012345678901235 / 20 > + FromLongFloat [AltSci] => 1.2345678901235D-3 > + ToLongFloat => 0.0012345678901235 / 18 > + FromLongFloat [Mix] => 0.001234567890124 > + ToLongFloat => 0.001234567890124 / 17 > > I'm not sure here what to do, as well as for p070, which tests > fingerprints for procedures, and is not implemented in CM3. Do we > need that? From RTProcedure.m3: > > PROCEDURE ToFingerprint (<*UNUSED*> p: Proc): Fingerprint.T = > BEGIN > <*ASSERT FALSE, "RTProcedure.ToFingerprint is not supported" *> > RETURN Fingerprint.Zero; <*NOWARN*> > END ToFingerprint; > > PROCEDURE FromFingerprint (<*UNUSED*> READONLY fp: Fingerprint.T): > Proc = > BEGIN > <*ASSERT FALSE, "RTProcedure.FromFingerprint is not supported" *> > RETURN NIL; <*NOWARN*> > END FromFingerprint; > > Or should we deactivate that test? I suspect we should deactivate both of these for now. > > p096 fails with > > @@ -1,3 +1,2 @@ > "../src/Main.m3", line 27: default is not a procedure constant (m) > 1 error encountered > -Fatal Error: package build failed > --- p0/p096/stderr.build 2008-01-05 18:27:24.000000000 +0100 > +++ ../src/p0/p096/stderr.build 2003-03-08 11:14:05.000000000 +0100 > > because of this code: > > MODULE Main; > > CONST K = T.m; L = Q; > TYPE TProc = PROCEDURE(s: T); > CONST A = ARRAY OF TProc{Q}; > > TYPE T = OBJECT METHODS m() := L; END; > ST1 = T OBJECT OVERRIDES m := K END; > (*** ILLEGAL *** ST2 = T OBJECT OVERRIDES m := TProc END; ***) > ST3 = T OBJECT OVERRIDES m := A[0]; END; > > PROCEDURE Q(s: T) = BEGIN EVAL s END Q; > > VAR t: T; st1: ST1; st3: ST3; > BEGIN > EVAL t; EVAL st1; EVAL st3; > END Main. > > I think I can somehow understand the compiler here. Did this ever > work? Is "CONST K = T.m" not a procedure constant? In which case m := K should work! > > p116 first fails because FlotMode procedures are not implemented by > default: > > +++ ../src/p1/p116/stderr.pgm 2003-03-08 11:13:53.000000000 +0100 > @@ -1,11 +1,3 @@ > - > - > -*** > -*** runtime error: > -*** <*ASSERT*> failed: FloatMode.SetRounding not implemented > -*** file "../src/float/IEEE-default/FloatMode.m3", line 14 > -*** > - > ---------------------------- REAL --- > 1.0/0.0 # 1.0/(-0.0) test OK > 1.0/0.0 = 1.0/(- (-0.0)) test OK > > I think this should be tested conditionally depending on platform. Indeed. > But then more checks fail: > > @@ -25,14 +17,14 @@ > Class (MaxFinite*ten) test OK > Finite (MaxFinite*ten) test OK > IsNaN (MaxFinite*ten) test OK > -** Class (zero/zero) test not OK: FALSE should be TRUE > + Class (zero/zero) test OK > Finite (zero/zero) test OK > IsNaN (zero/zero) test OK > Sign (zero) test OK > Sign (minusZero) test OK > - Unordered (zero, NaN) test OK > +** Unordered (zero, NaN) test not OK: FALSE should be TRUE > Unordered (zero, zero) test OK > - Unordered (NaN, NaN) test OK > +** Unordered (NaN, NaN) test not OK: FALSE should be TRUE > Differs (zero, NaN) test OK > > which refers to the test lines > > BCheck("Class (zero/zero)", RealFloat.Class(x) = > IEEEClass.QuietNaN, TRUE); > BCheck("Unordered (zero, NaN)", RealFloat.Unordered(zero, NaN), > TRUE); > BCheck("Unordered (NaN, NaN)", RealFloat.Unordered(NaN, NaN), > TRUE); > > Especially the last one suprises me, but I'm no specialist in > arithmetics. > Is this to be expected? Should we tolerate or can we fix it? Not sure... > > So far for now, I need to prepare dinner now, > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, > Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 > 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: > Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > DE163214194 > From hosking at cs.purdue.edu Mon Jan 7 15:56:12 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 7 Jan 2008 09:56:12 -0500 Subject: [M3devel] more m3tests failures In-Reply-To: <20080105210005.7iacdx5nkks84osk@mail.elegosoft.com> References: <20080105210005.7iacdx5nkks84osk@mail.elegosoft.com> Message-ID: <145F79EF-1CFF-4393-9C81-7F15CD283674@cs.purdue.edu> On Jan 5, 2008, at 3:00 PM, Olaf Wagner wrote: > I've looked into some more failures of m3tests, which I'd like to > present to the whole list: (All tests run on FreeBSD 6.3) > > p035 is a scoping problem which was Ok with > > /usr/local/cm3/bin/cm3cg-5.4.0 > > but > > /usr/local/cm3/bin/cm3cg-d5.5.1 > > fails, so it must be caused by recent gcc changes. The check that > fails is > > PROCEDURE foo (p: P; same: BOOLEAN) = > BEGIN > checkB (bar = p, same); checkB (bar # p, NOT same); > END foo; > PROCEDURE bar (<*UNUSED*> t: Text.T) = > BEGIN > END bar; > BEGIN > msg ("group M"); foo (bar, TRUE); > msg ("group N"); foo (dummy, FALSE); > END; I think the issue is to do with the fact that we use gcc's automatic nested function support instead of m3cg's load_static_link and pop_static_link. I believe the fix is to make load_static_link load nil instead of an actual static chain value. > > p040 fails due to differences in floating point precision; the numbers > on FreeBSD seem to have a higher precision. > > +++ ../src/p0/p040/stdout.pgm 2003-03-08 11:14:03.000000000 +0100 > @@ -964,85 +964,85 @@ > ToLongFloat => 0.1 / 3 > > > -0.001234567890123456 > +0.0012345678901235 > > - FromLongFloat [Flo] => 0.001234567890123 > - ToLongFloat => 0.001234567890123 / 17 > - FromLongFloat [AltFlo] => 0.001234567890123 > - ToLongFloat => 0.001234567890123 / 17 > - FromLongFloat [Sci] => 1.234567890123456D-3 > - ToLongFloat => 0.001234567890123456 / 20 > - FromLongFloat [AltSci] => 1.234567890123456D-3 > - ToLongFloat => 0.001234567890123456 / 20 > - FromLongFloat [Mix] => 0.001234567890123 > - ToLongFloat => 0.001234567890123 / 17 > + FromLongFloat [Flo] => 0.001234567890124 > + ToLongFloat => 0.001234567890124 / 17 > + FromLongFloat [AltFlo] => 0.001234567890124 > + ToLongFloat => 0.001234567890124 / 17 > + FromLongFloat [Sci] => 1.234567890123500D-3 > + ToLongFloat => 0.0012345678901235 / 20 > + FromLongFloat [AltSci] => 1.2345678901235D-3 > + ToLongFloat => 0.0012345678901235 / 18 > + FromLongFloat [Mix] => 0.001234567890124 > + ToLongFloat => 0.001234567890124 / 17 > > I'm not sure here what to do, as well as for p070, which tests > fingerprints for procedures, and is not implemented in CM3. Do we > need that? From RTProcedure.m3: > > PROCEDURE ToFingerprint (<*UNUSED*> p: Proc): Fingerprint.T = > BEGIN > <*ASSERT FALSE, "RTProcedure.ToFingerprint is not supported" *> > RETURN Fingerprint.Zero; <*NOWARN*> > END ToFingerprint; > > PROCEDURE FromFingerprint (<*UNUSED*> READONLY fp: Fingerprint.T): > Proc = > BEGIN > <*ASSERT FALSE, "RTProcedure.FromFingerprint is not supported" *> > RETURN NIL; <*NOWARN*> > END FromFingerprint; > > Or should we deactivate that test? I suspect we should deactivate both of these for now. > > p096 fails with > > @@ -1,3 +1,2 @@ > "../src/Main.m3", line 27: default is not a procedure constant (m) > 1 error encountered > -Fatal Error: package build failed > --- p0/p096/stderr.build 2008-01-05 18:27:24.000000000 +0100 > +++ ../src/p0/p096/stderr.build 2003-03-08 11:14:05.000000000 +0100 > > because of this code: > > MODULE Main; > > CONST K = T.m; L = Q; > TYPE TProc = PROCEDURE(s: T); > CONST A = ARRAY OF TProc{Q}; > > TYPE T = OBJECT METHODS m() := L; END; > ST1 = T OBJECT OVERRIDES m := K END; > (*** ILLEGAL *** ST2 = T OBJECT OVERRIDES m := TProc END; ***) > ST3 = T OBJECT OVERRIDES m := A[0]; END; > > PROCEDURE Q(s: T) = BEGIN EVAL s END Q; > > VAR t: T; st1: ST1; st3: ST3; > BEGIN > EVAL t; EVAL st1; EVAL st3; > END Main. > > I think I can somehow understand the compiler here. Did this ever > work? Is "CONST K = T.m" not a procedure constant? In which case m := K should work! > > p116 first fails because FlotMode procedures are not implemented by > default: > > +++ ../src/p1/p116/stderr.pgm 2003-03-08 11:13:53.000000000 +0100 > @@ -1,11 +1,3 @@ > - > - > -*** > -*** runtime error: > -*** <*ASSERT*> failed: FloatMode.SetRounding not implemented > -*** file "../src/float/IEEE-default/FloatMode.m3", line 14 > -*** > - > ---------------------------- REAL --- > 1.0/0.0 # 1.0/(-0.0) test OK > 1.0/0.0 = 1.0/(- (-0.0)) test OK > > I think this should be tested conditionally depending on platform. Indeed. > But then more checks fail: > > @@ -25,14 +17,14 @@ > Class (MaxFinite*ten) test OK > Finite (MaxFinite*ten) test OK > IsNaN (MaxFinite*ten) test OK > -** Class (zero/zero) test not OK: FALSE should be TRUE > + Class (zero/zero) test OK > Finite (zero/zero) test OK > IsNaN (zero/zero) test OK > Sign (zero) test OK > Sign (minusZero) test OK > - Unordered (zero, NaN) test OK > +** Unordered (zero, NaN) test not OK: FALSE should be TRUE > Unordered (zero, zero) test OK > - Unordered (NaN, NaN) test OK > +** Unordered (NaN, NaN) test not OK: FALSE should be TRUE > Differs (zero, NaN) test OK > > which refers to the test lines > > BCheck("Class (zero/zero)", RealFloat.Class(x) = > IEEEClass.QuietNaN, TRUE); > BCheck("Unordered (zero, NaN)", RealFloat.Unordered(zero, NaN), > TRUE); > BCheck("Unordered (NaN, NaN)", RealFloat.Unordered(NaN, NaN), > TRUE); > > Especially the last one suprises me, but I'm no specialist in > arithmetics. > Is this to be expected? Should we tolerate or can we fix it? > > So far for now, I need to prepare dinner now, > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, > Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 > 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: > Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > DE163214194 > From darko at darko.org Mon Jan 7 19:12:35 2008 From: darko at darko.org (Darko) Date: Mon, 7 Jan 2008 10:12:35 -0800 Subject: [M3devel] CM3 on Leopard Message-ID: <6CD6F1AC-449E-421D-A26A-C50BA1DFC301@darko.org> Hi Tony, Are you using CM3 on Leopard, aka Mac OS X 10.5? It's stopped working since I upgraded, I get: cc -o parser -fPIC _m3main.o [ ... various libs, modules ... ] - lm3gcdefs -lm -multiply_defined suppress -bind_at_load -shared-libgcc /usr/bin/ld: /usr/lib/gcc/i686-apple-darwin8/4.0.1/../../../libm.dylib unknown flags (type) of section 6 (__TEXT,__dof_plockstat) in load command 0 /usr/bin/ld: can't locate file for: -lgcc_s.10.4 collect2: ld returned 1 exit status when trying to compile. Uname says: Darwin Lucifer.local 9.1.0 Darwin Kernel Version 9.1.0: Wed Oct 31 17:46:22 PDT 2007; root:xnu-1228.0.2~1/RELEASE_I386 i386 It would seem that i just needs to be nudged up to the right version, but I couldn't find anything in the cfg file. Any suggestions? Thanks, Darko. From hosking at cs.purdue.edu Mon Jan 7 20:08:08 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 7 Jan 2008 14:08:08 -0500 Subject: [M3devel] CM3 on Leopard In-Reply-To: <6CD6F1AC-449E-421D-A26A-C50BA1DFC301@darko.org> References: <6CD6F1AC-449E-421D-A26A-C50BA1DFC301@darko.org> Message-ID: On Jan 7, 2008, at 1:12 PM, Darko wrote: > Hi Tony, > > Are you using CM3 on Leopard, aka Mac OS X 10.5? No, I've deliberately *not* upgraded to Leopard until I am able to test CM3 on it. Generally, I avoid bleeding edge OS upgrades for precisely this reason. I don't know when I will have time to play with CM3 on Leopard. Right now, I am tracking down another issue related to the regression framework Olaf is putting together. > It's stopped working since I upgraded, I get: > > cc -o parser -fPIC _m3main.o [ ... various libs, modules ... ] - > lm3gcdefs -lm -multiply_defined suppress -bind_at_load -shared-libgcc At least this suggest your cm3 binary was able to run on Leopard, which is a good start. > > /usr/bin/ld: /usr/lib/gcc/i686-apple-darwin8/4.0.1/../../../ > libm.dylib unknown flags (type) of section 6 > (__TEXT,__dof_plockstat) in load command 0 > /usr/bin/ld: can't locate file for: -lgcc_s.10.4 > collect2: ld returned 1 exit status > > when trying to compile. Uname says: > > Darwin Lucifer.local 9.1.0 Darwin Kernel Version 9.1.0: Wed Oct 31 > 17:46:22 PDT 2007; root:xnu-1228.0.2~1/RELEASE_I386 i386 > > It would seem that i just needs to be nudged up to the right > version, but I couldn't find anything in the cfg file. Any > suggestions? I suspect that you need to rebuild the m3cg backend, but I have no idea how well it will play with Leopard. Also, I have heard there were changes to ucontexts and other thread state which may mean M3 exceptions break, but I have not verified yet. > > Thanks, > Darko. > From hosking at cs.purdue.edu Mon Jan 7 20:27:19 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 7 Jan 2008 14:27:19 -0500 Subject: [M3devel] more m3tests failures In-Reply-To: <20080105210005.7iacdx5nkks84osk@mail.elegosoft.com> References: <20080105210005.7iacdx5nkks84osk@mail.elegosoft.com> Message-ID: I just checked in the fix for p035, with changes to the gcc-based backend (tree-nested.c and parse.c). On Jan 5, 2008, at 3:00 PM, Olaf Wagner wrote: > I've looked into some more failures of m3tests, which I'd like to > present to the whole list: (All tests run on FreeBSD 6.3) > > p035 is a scoping problem which was Ok with > > /usr/local/cm3/bin/cm3cg-5.4.0 > > but > > /usr/local/cm3/bin/cm3cg-d5.5.1 > > fails, so it must be caused by recent gcc changes. The check that > fails is > > PROCEDURE foo (p: P; same: BOOLEAN) = > BEGIN > checkB (bar = p, same); checkB (bar # p, NOT same); > END foo; > PROCEDURE bar (<*UNUSED*> t: Text.T) = > BEGIN > END bar; > BEGIN > msg ("group M"); foo (bar, TRUE); > msg ("group N"); foo (dummy, FALSE); > END; From hosking at cs.purdue.edu Mon Jan 7 21:16:47 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 7 Jan 2008 15:16:47 -0500 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <20080107073815.DBCDD10D45C8@birch.elegosoft.com> References: <20080107073815.DBCDD10D45C8@birch.elegosoft.com> Message-ID: <4F88D761-5F3F-4891-B3BD-7490FC7E7A2A@cs.purdue.edu> Jay, I am very nervous about the pervasive nature of some of your recent commits. NT386GNU is usually configured with OS_TYPE="POSIX". Thus, the m3makefile for cm3, which contains the following: if equal (OS_TYPE, "POSIX") interface ("M3Backend") implementation ("M3BackPosix") implementation ("UtilsPosix") else import ("m3objfile") import ("m3back") interface ("M3Backend") implementation ("M3BackWin32") implementation ("UtilsWin32") end will build a POSIX backend for you on NT386GNU which should do the right thing in invoking the gcc-based backend. Your changes, which hardwire things in cm3 for NT386GNU are thus unnecessary. I suggest you back these changes out and reconsider things. Certainly, NT386GNU should be considered as an independent POSIX target from the NT386 WIN32 target. Thus, one need not make changes to M3BackWin32 for NT386GNU, since it is treated as a POSIX target. As far as threading goes, if user-level threading for NT386 does not work then I can imagine it would be OK to use native WIN32 threads. The switch for that is in m3core/src/thread/m3makefile, which would check for TARGET="NT386GNU" and choose sibdirectory WIN32 instead of using OS_TYPE to pick subdirectory POSIX. On Jan 7, 2008, at 8:38 AM, Jay Krell wrote: > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 08/01/07 08:38:15 > > Modified files: > cm3/m3-libs/m3core/src/unix/cygwin/: Umman.i3 Uresource.i3 > Utypes.m3 > cm3/m3-sys/cm3/src/: Builder.i3 Builder.m3 M3BackPosix.m3 > M3BackWin32.m3 M3Backend.i3 > cm3/m3-sys/cminstall/src/config/: NT386GNU > cm3/m3-sys/m3front/src/misc/: M3Front.m3 > > Log message: > some fixes for NT386GNU (cygwin) > > let win32 cm3 use the gcc backend if target == NT386GNU > might need a better interface here? > switching on target name is probably the wrong thing > need something called "use gcc backend" or somesuch > > loosen the check for file name vs. module name to account for > paths with both types of slashes > might need a better interface/implementation here? > should try to get the paths to line up instead? > > remove -fPIC since it warns that it is redundant (though the > warning is probably wrong > in other details -- not all code is position independent, merely > relocatable..) > > use configured ar, /usr/bin/ar doesn't work, just plain ar does > > update Umman.i3 MAP_ANONYMOUS to new shorter name MAP_ANON > > update Uresource.i3 from struct_rusage_start to VAR struct_rusage > > fix warning about unused import long in Utypes.m3 > > change SYSTEM_CC from cc to gcc because cc is something on my system, > that I have not investigated, and doesn't work; gcc is perfectly > ok here, though > cc lines up nicely with the other two character names -- ar and as > > now need to deal with threads to get m3core to build From darko at darko.org Mon Jan 7 21:23:14 2008 From: darko at darko.org (Darko) Date: Mon, 7 Jan 2008 12:23:14 -0800 Subject: [M3devel] CM3 on Leopard In-Reply-To: References: <6CD6F1AC-449E-421D-A26A-C50BA1DFC301@darko.org> Message-ID: <934FB1C7-75A5-4720-B14E-EFAF6CD52C46@darko.org> It seems that I just forgot to install the latest tools. I fixed it by installing XCode from the Leopard DVD. Exceptions seem to work ok, but I did a very basic test. Maybe I can run the regression test suite on 10.5 when it's finished. I'll report any problems meanwhile. Thanks, Darko. On 07/01/2008, at 11:08 AM, Tony Hosking wrote: > > On Jan 7, 2008, at 1:12 PM, Darko wrote: > >> Hi Tony, >> >> Are you using CM3 on Leopard, aka Mac OS X 10.5? > > No, I've deliberately *not* upgraded to Leopard until I am able to > test CM3 on it. Generally, I avoid bleeding edge OS upgrades for > precisely this reason. I don't know when I will have time to play > with CM3 on Leopard. Right now, I am tracking down another issue > related to the regression framework Olaf is putting together. > >> It's stopped working since I upgraded, I get: >> >> cc -o parser -fPIC _m3main.o [ ... various libs, modules ... ] - >> lm3gcdefs -lm -multiply_defined suppress -bind_at_load -shared-libgcc > > At least this suggest your cm3 binary was able to run on Leopard, > which is a good start. > >> >> /usr/bin/ld: /usr/lib/gcc/i686-apple-darwin8/4.0.1/../../../ >> libm.dylib unknown flags (type) of section 6 >> (__TEXT,__dof_plockstat) in load command 0 >> /usr/bin/ld: can't locate file for: -lgcc_s.10.4 >> collect2: ld returned 1 exit status >> >> when trying to compile. Uname says: >> >> Darwin Lucifer.local 9.1.0 Darwin Kernel Version 9.1.0: Wed Oct 31 >> 17:46:22 PDT 2007; root:xnu-1228.0.2~1/RELEASE_I386 i386 >> >> It would seem that i just needs to be nudged up to the right >> version, but I couldn't find anything in the cfg file. Any >> suggestions? > > I suspect that you need to rebuild the m3cg backend, but I have no > idea how well it will play with Leopard. > > Also, I have heard there were changes to ucontexts and other thread > state which may mean M3 exceptions break, but I have not verified yet. > >> >> Thanks, >> Darko. >> > From hosking at cs.purdue.edu Mon Jan 7 21:27:30 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 7 Jan 2008 15:27:30 -0500 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <4F88D761-5F3F-4891-B3BD-7490FC7E7A2A@cs.purdue.edu> References: <20080107073815.DBCDD10D45C8@birch.elegosoft.com> <4F88D761-5F3F-4891-B3BD-7490FC7E7A2A@cs.purdue.edu> Message-ID: Also, following up on your changes for the backend. I suggest you take a look at the way things are handled in the M3BackLinux.m3 code for PM3. You should be able to switch between the integrated backend and the gcc-based backend similarly, based on the value of the M3_BACKEND_MODE flag. Thus, controlling the backend is a simple matter of changing the cm3.cfg. On Jan 7, 2008, at 3:16 PM, Tony Hosking wrote: > Jay, I am very nervous about the pervasive nature of some of your > recent commits. NT386GNU is usually configured with > OS_TYPE="POSIX". Thus, the m3makefile for cm3, which contains the > following: > > if equal (OS_TYPE, "POSIX") > interface ("M3Backend") > implementation ("M3BackPosix") > implementation ("UtilsPosix") > else > import ("m3objfile") > import ("m3back") > interface ("M3Backend") > implementation ("M3BackWin32") > implementation ("UtilsWin32") > end > > will build a POSIX backend for you on NT386GNU which should do the > right thing in invoking the gcc-based backend. Your changes, which > hardwire things in cm3 for NT386GNU are thus unnecessary. I > suggest you back these changes out and reconsider things. > Certainly, NT386GNU should be considered as an independent POSIX > target from the NT386 WIN32 target. Thus, one need not make > changes to M3BackWin32 for NT386GNU, since it is treated as a POSIX > target. > > As far as threading goes, if user-level threading for NT386 does > not work then I can imagine it would be OK to use native WIN32 > threads. The switch for that is in m3core/src/thread/m3makefile, > which would check for TARGET="NT386GNU" and choose sibdirectory > WIN32 instead of using OS_TYPE to pick subdirectory POSIX. > > On Jan 7, 2008, at 8:38 AM, Jay Krell wrote: > >> CVSROOT: /usr/cvs >> Changes by: jkrell at birch. 08/01/07 08:38:15 >> >> Modified files: >> cm3/m3-libs/m3core/src/unix/cygwin/: Umman.i3 Uresource.i3 >> Utypes.m3 >> cm3/m3-sys/cm3/src/: Builder.i3 Builder.m3 M3BackPosix.m3 >> M3BackWin32.m3 M3Backend.i3 >> cm3/m3-sys/cminstall/src/config/: NT386GNU >> cm3/m3-sys/m3front/src/misc/: M3Front.m3 >> >> Log message: >> some fixes for NT386GNU (cygwin) >> >> let win32 cm3 use the gcc backend if target == NT386GNU >> might need a better interface here? >> switching on target name is probably the wrong thing >> need something called "use gcc backend" or somesuch >> >> loosen the check for file name vs. module name to account for >> paths with both types of slashes >> might need a better interface/implementation here? >> should try to get the paths to line up instead? >> >> remove -fPIC since it warns that it is redundant (though the >> warning is probably wrong >> in other details -- not all code is position independent, merely >> relocatable..) >> >> use configured ar, /usr/bin/ar doesn't work, just plain ar does >> >> update Umman.i3 MAP_ANONYMOUS to new shorter name MAP_ANON >> >> update Uresource.i3 from struct_rusage_start to VAR struct_rusage >> >> fix warning about unused import long in Utypes.m3 >> >> change SYSTEM_CC from cc to gcc because cc is something on my >> system, >> that I have not investigated, and doesn't work; gcc is perfectly >> ok here, though >> cc lines up nicely with the other two character names -- ar and as >> >> now need to deal with threads to get m3core to build > From hosking at cs.purdue.edu Mon Jan 7 21:28:59 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 7 Jan 2008 15:28:59 -0500 Subject: [M3devel] CM3 on Leopard In-Reply-To: <934FB1C7-75A5-4720-B14E-EFAF6CD52C46@darko.org> References: <6CD6F1AC-449E-421D-A26A-C50BA1DFC301@darko.org> <934FB1C7-75A5-4720-B14E-EFAF6CD52C46@darko.org> Message-ID: <2774155B-86E0-4F68-B1D6-AB1FCC9A8AB2@cs.purdue.edu> Very cool! I was thinking it was going to be more painful. Have you bootstrapped a new compiler? On Jan 7, 2008, at 3:23 PM, Darko wrote: > It seems that I just forgot to install the latest tools. I fixed it > by installing XCode from the Leopard DVD. > > Exceptions seem to work ok, but I did a very basic test. Maybe I > can run the regression test suite on 10.5 when it's finished. I'll > report any problems meanwhile. > > Thanks, > Darko. > > > > On 07/01/2008, at 11:08 AM, Tony Hosking wrote: > >> >> On Jan 7, 2008, at 1:12 PM, Darko wrote: >> >>> Hi Tony, >>> >>> Are you using CM3 on Leopard, aka Mac OS X 10.5? >> >> No, I've deliberately *not* upgraded to Leopard until I am able to >> test CM3 on it. Generally, I avoid bleeding edge OS upgrades for >> precisely this reason. I don't know when I will have time to play >> with CM3 on Leopard. Right now, I am tracking down another issue >> related to the regression framework Olaf is putting together. >> >>> It's stopped working since I upgraded, I get: >>> >>> cc -o parser -fPIC _m3main.o [ ... various libs, modules ... ] - >>> lm3gcdefs -lm -multiply_defined suppress -bind_at_load -shared- >>> libgcc >> >> At least this suggest your cm3 binary was able to run on Leopard, >> which is a good start. >> >>> >>> /usr/bin/ld: /usr/lib/gcc/i686-apple-darwin8/4.0.1/../../../ >>> libm.dylib unknown flags (type) of section 6 >>> (__TEXT,__dof_plockstat) in load command 0 >>> /usr/bin/ld: can't locate file for: -lgcc_s.10.4 >>> collect2: ld returned 1 exit status >>> >>> when trying to compile. Uname says: >>> >>> Darwin Lucifer.local 9.1.0 Darwin Kernel Version 9.1.0: Wed Oct >>> 31 17:46:22 PDT 2007; root:xnu-1228.0.2~1/RELEASE_I386 i386 >>> >>> It would seem that i just needs to be nudged up to the right >>> version, but I couldn't find anything in the cfg file. Any >>> suggestions? >> >> I suspect that you need to rebuild the m3cg backend, but I have no >> idea how well it will play with Leopard. >> >> Also, I have heard there were changes to ucontexts and other >> thread state which may mean M3 exceptions break, but I have not >> verified yet. >> >>> >>> Thanks, >>> Darko. >>> >> From darko at darko.org Mon Jan 7 21:41:48 2008 From: darko at darko.org (Darko) Date: Mon, 7 Jan 2008 12:41:48 -0800 Subject: [M3devel] CM3 on Leopard In-Reply-To: <2774155B-86E0-4F68-B1D6-AB1FCC9A8AB2@cs.purdue.edu> References: <6CD6F1AC-449E-421D-A26A-C50BA1DFC301@darko.org> <934FB1C7-75A5-4720-B14E-EFAF6CD52C46@darko.org> <2774155B-86E0-4F68-B1D6-AB1FCC9A8AB2@cs.purdue.edu> Message-ID: No, that's actually my idea of pain - the scripts never seem to work for me. But I'll give it a try because I need to have a go at the (byte) alignment problem evident with the current Intel Darwin compiler at some point. I've actually never really had a problem with Mac OS revisions beyond a cfg file tweak or a rollback of gcc versions. On 07/01/2008, at 12:28 PM, Tony Hosking wrote: > Very cool! I was thinking it was going to be more painful. Have > you bootstrapped a new compiler? > > > On Jan 7, 2008, at 3:23 PM, Darko wrote: > >> It seems that I just forgot to install the latest tools. I fixed it >> by installing XCode from the Leopard DVD. >> >> Exceptions seem to work ok, but I did a very basic test. Maybe I >> can run the regression test suite on 10.5 when it's finished. I'll >> report any problems meanwhile. >> >> Thanks, >> Darko. >> >> >> >> On 07/01/2008, at 11:08 AM, Tony Hosking wrote: >> >>> >>> On Jan 7, 2008, at 1:12 PM, Darko wrote: >>> >>>> Hi Tony, >>>> >>>> Are you using CM3 on Leopard, aka Mac OS X 10.5? >>> >>> No, I've deliberately *not* upgraded to Leopard until I am able to >>> test CM3 on it. Generally, I avoid bleeding edge OS upgrades for >>> precisely this reason. I don't know when I will have time to play >>> with CM3 on Leopard. Right now, I am tracking down another issue >>> related to the regression framework Olaf is putting together. >>> >>>> It's stopped working since I upgraded, I get: >>>> >>>> cc -o parser -fPIC _m3main.o [ ... various libs, modules ... ] - >>>> lm3gcdefs -lm -multiply_defined suppress -bind_at_load -shared- >>>> libgcc >>> >>> At least this suggest your cm3 binary was able to run on Leopard, >>> which is a good start. >>> >>>> >>>> /usr/bin/ld: /usr/lib/gcc/i686-apple-darwin8/4.0.1/../../../ >>>> libm.dylib unknown flags (type) of section 6 >>>> (__TEXT,__dof_plockstat) in load command 0 >>>> /usr/bin/ld: can't locate file for: -lgcc_s.10.4 >>>> collect2: ld returned 1 exit status >>>> >>>> when trying to compile. Uname says: >>>> >>>> Darwin Lucifer.local 9.1.0 Darwin Kernel Version 9.1.0: Wed Oct >>>> 31 17:46:22 PDT 2007; root:xnu-1228.0.2~1/RELEASE_I386 i386 >>>> >>>> It would seem that i just needs to be nudged up to the right >>>> version, but I couldn't find anything in the cfg file. Any >>>> suggestions? >>> >>> I suspect that you need to rebuild the m3cg backend, but I have no >>> idea how well it will play with Leopard. >>> >>> Also, I have heard there were changes to ucontexts and other >>> thread state which may mean M3 exceptions break, but I have not >>> verified yet. >>> >>>> >>>> Thanks, >>>> Darko. >>>> >>> > From jayk123 at hotmail.com Mon Jan 7 22:10:28 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 7 Jan 2008 21:10:28 +0000 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: References: <20080107073815.DBCDD10D45C8@birch.elegosoft.com> <4F88D761-5F3F-4891-B3BD-7490FC7E7A2A@cs.purdue.edu> Message-ID: > Thus, controlling the backend is a simple matter of changing the cm3.cfg Exactly. What I have right now is I build an NT386/Win32 cm3, and then I change the config file, and that one cm3 switches between gcc or not. It is a hybrid. I can already compile all of m3core with this cm3/m3cg, except for threading. I also copy the NT386 directories in pkg to NT386GNU, and possibly foo.lib to libfoo.a -- I have to try again to see if that was the key or not. This gives me an easier sort of "cross", on one machine/OS. I actually swap out the entire cm3.cfg, cm3/m3-sys/cminstall/config/NT386 vs. cm3/m3-sys/cminstall/config/NT386GNU, not just one line. I'll try the "mode" and look at pm3. Thanks. > threading Yeah I thought Win32 would work. I'll try/look again. Later. I think it was set for Posix/setjmp/longjmp and I think I tried pthreads, might not have tried Win32. - Jay > From: hosking at cs.purdue.edu > Date: Mon, 7 Jan 2008 15:27:30 -0500 > To: hosking at cs.purdue.edu > CC: m3devel at elegosoft.com; m3commit at elegosoft.com > Subject: Re: [M3commit] CVS Update: cm3 > > Also, following up on your changes for the backend. I suggest you > take a look at the way things are handled in the M3BackLinux.m3 code > for PM3. You should be able to switch between the integrated backend > and the gcc-based backend similarly, based on the value of the > M3_BACKEND_MODE flag. Thus, controlling the backend is a simple > matter of changing the cm3.cfg. > > > > On Jan 7, 2008, at 3:16 PM, Tony Hosking wrote: > > > Jay, I am very nervous about the pervasive nature of some of your > > recent commits. NT386GNU is usually configured with > > OS_TYPE="POSIX". Thus, the m3makefile for cm3, which contains the > > following: > > > > if equal (OS_TYPE, "POSIX") > > interface ("M3Backend") > > implementation ("M3BackPosix") > > implementation ("UtilsPosix") > > else > > import ("m3objfile") > > import ("m3back") > > interface ("M3Backend") > > implementation ("M3BackWin32") > > implementation ("UtilsWin32") > > end > > > > will build a POSIX backend for you on NT386GNU which should do the > > right thing in invoking the gcc-based backend. Your changes, which > > hardwire things in cm3 for NT386GNU are thus unnecessary. I > > suggest you back these changes out and reconsider things. > > Certainly, NT386GNU should be considered as an independent POSIX > > target from the NT386 WIN32 target. Thus, one need not make > > changes to M3BackWin32 for NT386GNU, since it is treated as a POSIX > > target. > > > > As far as threading goes, if user-level threading for NT386 does > > not work then I can imagine it would be OK to use native WIN32 > > threads. The switch for that is in m3core/src/thread/m3makefile, > > which would check for TARGET="NT386GNU" and choose sibdirectory > > WIN32 instead of using OS_TYPE to pick subdirectory POSIX. > > > > On Jan 7, 2008, at 8:38 AM, Jay Krell wrote: > > > >> CVSROOT: /usr/cvs > >> Changes by: jkrell at birch. 08/01/07 08:38:15 > >> > >> Modified files: > >> cm3/m3-libs/m3core/src/unix/cygwin/: Umman.i3 Uresource.i3 > >> Utypes.m3 > >> cm3/m3-sys/cm3/src/: Builder.i3 Builder.m3 M3BackPosix.m3 > >> M3BackWin32.m3 M3Backend.i3 > >> cm3/m3-sys/cminstall/src/config/: NT386GNU > >> cm3/m3-sys/m3front/src/misc/: M3Front.m3 > >> > >> Log message: > >> some fixes for NT386GNU (cygwin) > >> > >> let win32 cm3 use the gcc backend if target == NT386GNU > >> might need a better interface here? > >> switching on target name is probably the wrong thing > >> need something called "use gcc backend" or somesuch > >> > >> loosen the check for file name vs. module name to account for > >> paths with both types of slashes > >> might need a better interface/implementation here? > >> should try to get the paths to line up instead? > >> > >> remove -fPIC since it warns that it is redundant (though the > >> warning is probably wrong > >> in other details -- not all code is position independent, merely > >> relocatable..) > >> > >> use configured ar, /usr/bin/ar doesn't work, just plain ar does > >> > >> update Umman.i3 MAP_ANONYMOUS to new shorter name MAP_ANON > >> > >> update Uresource.i3 from struct_rusage_start to VAR struct_rusage > >> > >> fix warning about unused import long in Utypes.m3 > >> > >> change SYSTEM_CC from cc to gcc because cc is something on my > >> system, > >> that I have not investigated, and doesn't work; gcc is perfectly > >> ok here, though > >> cc lines up nicely with the other two character names -- ar and as > >> > >> now need to deal with threads to get m3core to build > > > _________________________________________________________________ Watch ?Cause Effect,? a show about real people making a real difference. http://im.live.com/Messenger/IM/MTV/?source=text_watchcause -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon Jan 7 22:21:37 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 7 Jan 2008 16:21:37 -0500 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: References: <20080107073815.DBCDD10D45C8@birch.elegosoft.com> <4F88D761-5F3F-4891-B3BD-7490FC7E7A2A@cs.purdue.edu> Message-ID: I'm about to check in a version that achieves what you want based on M3_BACKEND_MODE in cm3.cfg without the nasty hack of hardwiring cm3. On Jan 7, 2008, at 4:10 PM, Jay wrote: > > >> Thus, controlling the backend is a simple matter of changing the >> cm3.cfg > > > > Exactly. > > > What I have right now is I build an NT386/Win32 cm3, and then I > change the config file, and that one cm3 switches between gcc or not. > It is a hybrid. > I can already compile all of m3core with this cm3/m3cg, except for > threading. > I also copy the NT386 directories in pkg to NT386GNU, and possibly > foo.lib to libfoo.a -- I have to try again to see if that was the > key or not. > This gives me an easier sort of "cross", on one machine/OS. > > I actually swap out the entire cm3.cfg, cm3/m3-sys/cminstall/config/ > NT386 vs. cm3/m3-sys/cminstall/config/NT386GNU, not just one line. > > I'll try the "mode" and look at pm3. Thanks. > > >> threading > > Yeah I thought Win32 would work. I'll try/look again. Later. > I think it was set for Posix/setjmp/longjmp and I think I tried > pthreads, might not have tried Win32. > > - Jay > >> From: hosking at cs.purdue.edu >> Date: Mon, 7 Jan 2008 15:27:30 -0500 >> To: hosking at cs.purdue.edu >> CC: m3devel at elegosoft.com; m3commit at elegosoft.com >> Subject: Re: [M3commit] CVS Update: cm3 >> >> Also, following up on your changes for the backend. I suggest you >> take a look at the way things are handled in the M3BackLinux.m3 code >> for PM3. You should be able to switch between the integrated backend >> and the gcc-based backend similarly, based on the value of the >> M3_BACKEND_MODE flag. Thus, controlling the backend is a simple >> matter of changing the cm3.cfg. >> >> >> >> On Jan 7, 2008, at 3:16 PM, Tony Hosking wrote: >> >>> Jay, I am very nervous about the pervasive nature of some of your >>> recent commits. NT386GNU is usually configured with >>> OS_TYPE="POSIX". Thus, the m3makefile for cm3, which contains the >>> following: >>> >>> if equal (OS_TYPE, "POSIX") >>> interface ("M3Backend") >>> implementation ("M3BackPosix") >>> implementation ("UtilsPosix") >>> else >>> import ("m3objfile") >>> import ("m3back") >>> interface ("M3Backend") >>> implementation ("M3BackWin32") >>> implementation ("UtilsWin32") >>> end >>> >>> will build a POSIX backend for you on NT386GNU which should do the >>> right thing in invoking the gcc-based backend. Your changes, which >>> hardwire things in cm3 for NT386GNU are thus unnecessary. I >>> suggest you back these changes out and reconsider things. >>> Certainly, NT386GNU should be considered as an independent POSIX >>> target from the NT386 WIN32 target. Thus, one need not make >>> changes to M3BackWin32 for NT386GNU, since it is treated as a POSIX >>> target. >>> >>> As far as threading goes, if user-level threading for NT386 does >>> not work then I can imagine it would be OK to use native WIN32 >>> threads. The switch for that is in m3core/src/thread/m3makefile, >>> which would check for TARGET="NT386GNU" and choose sibdirectory >>> WIN32 instead of using OS_TYPE to pick subdirectory POSIX. >>> >>> On Jan 7, 2008, at 8:38 AM, Jay Krell wrote: >>> >>>> CVSROOT: /usr/cvs >>>> Changes by: jkrell at birch. 08/01/07 08:38:15 >>>> >>>> Modified files: >>>> cm3/m3-libs/m3core/src/unix/cygwin/: Umman.i3 Uresource.i3 >>>> Utypes.m3 >>>> cm3/m3-sys/cm3/src/: Builder.i3 Builder.m3 M3BackPosix.m3 >>>> M3BackWin32.m3 M3Backend.i3 >>>> cm3/m3-sys/cminstall/src/config/: NT386GNU >>>> cm3/m3-sys/m3front/src/misc/: M3Front.m3 >>>> >>>> Log message: >>>> some fixes for NT386GNU (cygwin) >>>> >>>> let win32 cm3 use the gcc backend if target == NT386GNU >>>> might need a better interface here? >>>> switching on target name is probably the wrong thing >>>> need something called "use gcc backend" or somesuch >>>> >>>> loosen the check for file name vs. module name to account for >>>> paths with both types of slashes >>>> might need a better interface/implementation here? >>>> should try to get the paths to line up instead? >>>> >>>> remove -fPIC since it warns that it is redundant (though the >>>> warning is probably wrong >>>> in other details -- not all code is position independent, merely >>>> relocatable..) >>>> >>>> use configured ar, /usr/bin/ar doesn't work, just plain ar does >>>> >>>> update Umman.i3 MAP_ANONYMOUS to new shorter name MAP_ANON >>>> >>>> update Uresource.i3 from struct_rusage_start to VAR struct_rusage >>>> >>>> fix warning about unused import long in Utypes.m3 >>>> >>>> change SYSTEM_CC from cc to gcc because cc is something on my >>>> system, >>>> that I have not investigated, and doesn't work; gcc is perfectly >>>> ok here, though >>>> cc lines up nicely with the other two character names -- ar and as >>>> >>>> now need to deal with threads to get m3core to build >>> >> > > _________________________________________________________________ > Watch ?Cause Effect,? a show about real people making a real > difference From kschleiser at elego.de Mon Jan 7 22:32:53 2008 From: kschleiser at elego.de (Kaspar Schleiser) Date: Mon, 07 Jan 2008 22:32:53 +0100 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <20080107192048.3FFBB10D461D@birch.elegosoft.com> References: <20080107192048.3FFBB10D461D@birch.elegosoft.com> Message-ID: <47829A85.4070609@elego.de> Hey, Antony Hosking wrote: > Log message: > Fix bug in procedure value comparison as revealed by p035 of m3tests. Is it possible that this breaks compilation on LINUXLIBC6? I'm getting the following compiler error using the 5.4.0 release compiler, which worked OK this morning: new source -> compiling RTCollector.m3 RTCollector.m3:1878: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. Cheers, Kaspar From hosking at cs.purdue.edu Mon Jan 7 23:28:09 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 7 Jan 2008 17:28:09 -0500 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: References: <20080107073815.DBCDD10D45C8@birch.elegosoft.com> <4F88D761-5F3F-4891-B3BD-7490FC7E7A2A@cs.purdue.edu> Message-ID: I went ahead and cleaned things up to be based on M3_BACKEND_MODE instead of the overly-hardwired approach you were using. On Jan 7, 2008, at 4:10 PM, Jay wrote: > > > Thus, controlling the backend is a simple matter of changing the > cm3.cfg > > Exactly. > > What I have right now is I build an NT386/Win32 cm3, and then I > change the config file, and that one cm3 switches between gcc or not. > It is a hybrid. > I can already compile all of m3core with this cm3/m3cg, except for > threading. > I also copy the NT386 directories in pkg to NT386GNU, and possibly > foo.lib to libfoo.a -- I have to try again to see if that was the > key or not. > This gives me an easier sort of "cross", on one machine/OS. > > I actually swap out the entire cm3.cfg, cm3/m3-sys/cminstall/config/ > NT386 vs. cm3/m3-sys/cminstall/config/NT386GNU, not just one line. > > I'll try the "mode" and look at pm3. Thanks. > > > threading > > Yeah I thought Win32 would work. I'll try/look again. Later. > I think it was set for Posix/setjmp/longjmp and I think I tried > pthreads, might not have tried Win32. > > - Jay > > > From: hosking at cs.purdue.edu > > Date: Mon, 7 Jan 2008 15:27:30 -0500 > > To: hosking at cs.purdue.edu > > CC: m3devel at elegosoft.com; m3commit at elegosoft.com > > Subject: Re: [M3commit] CVS Update: cm3 > > > > Also, following up on your changes for the backend. I suggest you > > take a look at the way things are handled in the M3BackLinux.m3 code > > for PM3. You should be able to switch between the integrated backend > > and the gcc-based backend similarly, based on the value of the > > M3_BACKEND_MODE flag. Thus, controlling the backend is a simple > > matter of changing the cm3.cfg. > > > > > > > > On Jan 7, 2008, at 3:16 PM, Tony Hosking wrote: > > > > > Jay, I am very nervous about the pervasive nature of some of your > > > recent commits. NT386GNU is usually configured with > > > OS_TYPE="POSIX". Thus, the m3makefile for cm3, which contains the > > > following: > > > > > > if equal (OS_TYPE, "POSIX") > > > interface ("M3Backend") > > > implementation ("M3BackPosix") > > > implementation ("UtilsPosix") > > > else > > > import ("m3objfile") > > > import ("m3back") > > > interface ("M3Backend") > > > implementation ("M3BackWin32") > > > implementation ("UtilsWin32") > > > end > > > > > > will build a POSIX backend for you on NT386GNU which should do the > > > right thing in invoking the gcc-based backend. Your changes, which > > > hardwire things in cm3 for NT386GNU are thus unnecessary. I > > > suggest you back these changes out and reconsider things. > > > Certainly, NT386GNU should be considered as an independent POSIX > > > target from the NT386 WIN32 target. Thus, one need not make > > > changes to M3BackWin32 for NT386GNU, since it is treated as a > POSIX > > > target. > > > > > > As far as threading goes, if user-level threading for NT386 does > > > not work then I can imagine it would be OK to use native WIN32 > > > threads. The switch for that is in m3core/src/thread/m3makefile, > > > which would check for TARGET="NT386GNU" and choose sibdirectory > > > WIN32 instead of using OS_TYPE to pick subdirectory POSIX. > > > > > > On Jan 7, 2008, at 8:38 AM, Jay Krell wrote: > > > > > >> CVSROOT: /usr/cvs > > >> Changes by: jkrell at birch. 08/01/07 08:38:15 > > >> > > >> Modified files: > > >> cm3/m3-libs/m3core/src/unix/cygwin/: Umman.i3 Uresource.i3 > > >> Utypes.m3 > > >> cm3/m3-sys/cm3/src/: Builder.i3 Builder.m3 M3BackPosix.m3 > > >> M3BackWin32.m3 M3Backend.i3 > > >> cm3/m3-sys/cminstall/src/config/: NT386GNU > > >> cm3/m3-sys/m3front/src/misc/: M3Front.m3 > > >> > > >> Log message: > > >> some fixes for NT386GNU (cygwin) > > >> > > >> let win32 cm3 use the gcc backend if target == NT386GNU > > >> might need a better interface here? > > >> switching on target name is probably the wrong thing > > >> need something called "use gcc backend" or somesuch > > >> > > >> loosen the check for file name vs. module name to account for > > >> paths with both types of slashes > > >> might need a better interface/implementation here? > > >> should try to get the paths to line up instead? > > >> > > >> remove -fPIC since it warns that it is redundant (though the > > >> warning is probably wrong > > >> in other details -- not all code is position independent, merely > > >> relocatable..) > > >> > > >> use configured ar, /usr/bin/ar doesn't work, just plain ar does > > >> > > >> update Umman.i3 MAP_ANONYMOUS to new shorter name MAP_ANON > > >> > > >> update Uresource.i3 from struct_rusage_start to VAR struct_rusage > > >> > > >> fix warning about unused import long in Utypes.m3 > > >> > > >> change SYSTEM_CC from cc to gcc because cc is something on my > > >> system, > > >> that I have not investigated, and doesn't work; gcc is perfectly > > >> ok here, though > > >> cc lines up nicely with the other two character names -- ar > and as > > >> > > >> now need to deal with threads to get m3core to build > > > > > > > Watch ?Cause Effect,? a show about real people making a real > difference. Learn more From hosking at cs.purdue.edu Mon Jan 7 23:29:04 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 7 Jan 2008 17:29:04 -0500 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: References: <20080107073815.DBCDD10D45C8@birch.elegosoft.com> <4F88D761-5F3F-4891-B3BD-7490FC7E7A2A@cs.purdue.edu> Message-ID: On Jan 7, 2008, at 4:10 PM, Jay wrote: > > >> Thus, controlling the backend is a simple matter of changing the >> cm3.cfg > > > > Exactly. > > > What I have right now is I build an NT386/Win32 cm3, and then I > change the config file, and that one cm3 switches between gcc or not. > It is a hybrid. The hybrid behavior can be controlled from cm3.cfg instead. See my latest checkin. > I can already compile all of m3core with this cm3/m3cg, except for > threading. > I also copy the NT386 directories in pkg to NT386GNU, and possibly > foo.lib to libfoo.a -- I have to try again to see if that was the > key or not. > This gives me an easier sort of "cross", on one machine/OS. > > I actually swap out the entire cm3.cfg, cm3/m3-sys/cminstall/config/ > NT386 vs. cm3/m3-sys/cminstall/config/NT386GNU, not just one line. > > I'll try the "mode" and look at pm3. Thanks. > > >> threading > > Yeah I thought Win32 would work. I'll try/look again. Later. > I think it was set for Posix/setjmp/longjmp and I think I tried > pthreads, might not have tried Win32. > > - Jay > >> From: hosking at cs.purdue.edu >> Date: Mon, 7 Jan 2008 15:27:30 -0500 >> To: hosking at cs.purdue.edu >> CC: m3devel at elegosoft.com; m3commit at elegosoft.com >> Subject: Re: [M3commit] CVS Update: cm3 >> >> Also, following up on your changes for the backend. I suggest you >> take a look at the way things are handled in the M3BackLinux.m3 code >> for PM3. You should be able to switch between the integrated backend >> and the gcc-based backend similarly, based on the value of the >> M3_BACKEND_MODE flag. Thus, controlling the backend is a simple >> matter of changing the cm3.cfg. >> >> >> >> On Jan 7, 2008, at 3:16 PM, Tony Hosking wrote: >> >>> Jay, I am very nervous about the pervasive nature of some of your >>> recent commits. NT386GNU is usually configured with >>> OS_TYPE="POSIX". Thus, the m3makefile for cm3, which contains the >>> following: >>> >>> if equal (OS_TYPE, "POSIX") >>> interface ("M3Backend") >>> implementation ("M3BackPosix") >>> implementation ("UtilsPosix") >>> else >>> import ("m3objfile") >>> import ("m3back") >>> interface ("M3Backend") >>> implementation ("M3BackWin32") >>> implementation ("UtilsWin32") >>> end >>> >>> will build a POSIX backend for you on NT386GNU which should do the >>> right thing in invoking the gcc-based backend. Your changes, which >>> hardwire things in cm3 for NT386GNU are thus unnecessary. I >>> suggest you back these changes out and reconsider things. >>> Certainly, NT386GNU should be considered as an independent POSIX >>> target from the NT386 WIN32 target. Thus, one need not make >>> changes to M3BackWin32 for NT386GNU, since it is treated as a POSIX >>> target. >>> >>> As far as threading goes, if user-level threading for NT386 does >>> not work then I can imagine it would be OK to use native WIN32 >>> threads. The switch for that is in m3core/src/thread/m3makefile, >>> which would check for TARGET="NT386GNU" and choose sibdirectory >>> WIN32 instead of using OS_TYPE to pick subdirectory POSIX. >>> >>> On Jan 7, 2008, at 8:38 AM, Jay Krell wrote: >>> >>>> CVSROOT: /usr/cvs >>>> Changes by: jkrell at birch. 08/01/07 08:38:15 >>>> >>>> Modified files: >>>> cm3/m3-libs/m3core/src/unix/cygwin/: Umman.i3 Uresource.i3 >>>> Utypes.m3 >>>> cm3/m3-sys/cm3/src/: Builder.i3 Builder.m3 M3BackPosix.m3 >>>> M3BackWin32.m3 M3Backend.i3 >>>> cm3/m3-sys/cminstall/src/config/: NT386GNU >>>> cm3/m3-sys/m3front/src/misc/: M3Front.m3 >>>> >>>> Log message: >>>> some fixes for NT386GNU (cygwin) >>>> >>>> let win32 cm3 use the gcc backend if target == NT386GNU >>>> might need a better interface here? >>>> switching on target name is probably the wrong thing >>>> need something called "use gcc backend" or somesuch >>>> >>>> loosen the check for file name vs. module name to account for >>>> paths with both types of slashes >>>> might need a better interface/implementation here? >>>> should try to get the paths to line up instead? >>>> >>>> remove -fPIC since it warns that it is redundant (though the >>>> warning is probably wrong >>>> in other details -- not all code is position independent, merely >>>> relocatable..) >>>> >>>> use configured ar, /usr/bin/ar doesn't work, just plain ar does >>>> >>>> update Umman.i3 MAP_ANONYMOUS to new shorter name MAP_ANON >>>> >>>> update Uresource.i3 from struct_rusage_start to VAR struct_rusage >>>> >>>> fix warning about unused import long in Utypes.m3 >>>> >>>> change SYSTEM_CC from cc to gcc because cc is something on my >>>> system, >>>> that I have not investigated, and doesn't work; gcc is perfectly >>>> ok here, though >>>> cc lines up nicely with the other two character names -- ar and as >>>> >>>> now need to deal with threads to get m3core to build >>> >> > > _________________________________________________________________ > Watch ?Cause Effect,? a show about real people making a real > difference From jayk123 at hotmail.com Tue Jan 8 00:40:49 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 7 Jan 2008 23:40:49 +0000 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: References: <20080107073815.DBCDD10D45C8@birch.elegosoft.com> <4F88D761-5F3F-4891-B3BD-7490FC7E7A2A@cs.purdue.edu> Message-ID: Right, thanks. Looks/sounds about right. Will try it "later". Except: http://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/cm3/src/M3BackWin32.m3.diff?r1=1.2;r2=1.3 Looks suspicious, just by visual inspection, haven't built it -- missing an import and comma vs. period. Style tangent: Have people heard the advise that boolean parameters are bad, because at the callsite esp. they don't give much meaning? What is TRUE? What is FALSE? Enums or named parameters are clearer. Furthermore, heck, the switch on small integers 0,1,2,3... (Not that my switching on targetname was good either.) And, more importantly, given a commit, how do I view it? Easily?Currently I hunt around to each file and view it, but I have to manually navigate to each file in cvs web. I want all the diffs associated with one checkin to be viewable together, no matter which all files were checked at the same time. - Jay > CC: m3devel at elegosoft.com; m3commit at elegosoft.com> From: hosking at cs.purdue.edu> Subject: Re: [M3commit] CVS Update: cm3> Date: Mon, 7 Jan 2008 17:29:04 -0500> To: jayk123 at hotmail.com> > > On Jan 7, 2008, at 4:10 PM, Jay wrote:> > >> >> >> Thus, controlling the backend is a simple matter of changing the > >> cm3.cfg> >> >> >> > Exactly.> >> >> > What I have right now is I build an NT386/Win32 cm3, and then I > > change the config file, and that one cm3 switches between gcc or not.> > It is a hybrid.> > The hybrid behavior can be controlled from cm3.cfg instead. See my > latest checkin.> > > I can already compile all of m3core with this cm3/m3cg, except for > > threading.> > I also copy the NT386 directories in pkg to NT386GNU, and possibly > > foo.lib to libfoo.a -- I have to try again to see if that was the > > key or not.> > This gives me an easier sort of "cross", on one machine/OS.> >> > I actually swap out the entire cm3.cfg, cm3/m3-sys/cminstall/config/ > > NT386 vs. cm3/m3-sys/cminstall/config/NT386GNU, not just one line.> >> > I'll try the "mode" and look at pm3. Thanks.> >> >> >> threading> >> > Yeah I thought Win32 would work. I'll try/look again. Later.> > I think it was set for Posix/setjmp/longjmp and I think I tried > > pthreads, might not have tried Win32.> >> > - Jay> >> >> From: hosking at cs.purdue.edu> >> Date: Mon, 7 Jan 2008 15:27:30 -0500> >> To: hosking at cs.purdue.edu> >> CC: m3devel at elegosoft.com; m3commit at elegosoft.com> >> Subject: Re: [M3commit] CVS Update: cm3> >>> >> Also, following up on your changes for the backend. I suggest you> >> take a look at the way things are handled in the M3BackLinux.m3 code> >> for PM3. You should be able to switch between the integrated backend> >> and the gcc-based backend similarly, based on the value of the> >> M3_BACKEND_MODE flag. Thus, controlling the backend is a simple> >> matter of changing the cm3.cfg.> >>> >>> >>> >> On Jan 7, 2008, at 3:16 PM, Tony Hosking wrote:> >>> >>> Jay, I am very nervous about the pervasive nature of some of your> >>> recent commits. NT386GNU is usually configured with> >>> OS_TYPE="POSIX". Thus, the m3makefile for cm3, which contains the> >>> following:> >>>> >>> if equal (OS_TYPE, "POSIX")> >>> interface ("M3Backend")> >>> implementation ("M3BackPosix")> >>> implementation ("UtilsPosix")> >>> else> >>> import ("m3objfile")> >>> import ("m3back")> >>> interface ("M3Backend")> >>> implementation ("M3BackWin32")> >>> implementation ("UtilsWin32")> >>> end> >>>> >>> will build a POSIX backend for you on NT386GNU which should do the> >>> right thing in invoking the gcc-based backend. Your changes, which> >>> hardwire things in cm3 for NT386GNU are thus unnecessary. I> >>> suggest you back these changes out and reconsider things.> >>> Certainly, NT386GNU should be considered as an independent POSIX> >>> target from the NT386 WIN32 target. Thus, one need not make> >>> changes to M3BackWin32 for NT386GNU, since it is treated as a POSIX> >>> target.> >>>> >>> As far as threading goes, if user-level threading for NT386 does> >>> not work then I can imagine it would be OK to use native WIN32> >>> threads. The switch for that is in m3core/src/thread/m3makefile,> >>> which would check for TARGET="NT386GNU" and choose sibdirectory> >>> WIN32 instead of using OS_TYPE to pick subdirectory POSIX.> >>>> >>> On Jan 7, 2008, at 8:38 AM, Jay Krell wrote:> >>>> >>>> CVSROOT: /usr/cvs> >>>> Changes by: jkrell at birch. 08/01/07 08:38:15> >>>>> >>>> Modified files:> >>>> cm3/m3-libs/m3core/src/unix/cygwin/: Umman.i3 Uresource.i3> >>>> Utypes.m3> >>>> cm3/m3-sys/cm3/src/: Builder.i3 Builder.m3 M3BackPosix.m3> >>>> M3BackWin32.m3 M3Backend.i3> >>>> cm3/m3-sys/cminstall/src/config/: NT386GNU> >>>> cm3/m3-sys/m3front/src/misc/: M3Front.m3> >>>>> >>>> Log message:> >>>> some fixes for NT386GNU (cygwin)> >>>> > >>>> let win32 cm3 use the gcc backend if target == NT386GNU> >>>> might need a better interface here?> >>>> switching on target name is probably the wrong thing> >>>> need something called "use gcc backend" or somesuch> >>>> > >>>> loosen the check for file name vs. module name to account for> >>>> paths with both types of slashes> >>>> might need a better interface/implementation here?> >>>> should try to get the paths to line up instead?> >>>> > >>>> remove -fPIC since it warns that it is redundant (though the> >>>> warning is probably wrong> >>>> in other details -- not all code is position independent, merely> >>>> relocatable..)> >>>> > >>>> use configured ar, /usr/bin/ar doesn't work, just plain ar does> >>>> > >>>> update Umman.i3 MAP_ANONYMOUS to new shorter name MAP_ANON> >>>> > >>>> update Uresource.i3 from struct_rusage_start to VAR struct_rusage> >>>> > >>>> fix warning about unused import long in Utypes.m3> >>>> > >>>> change SYSTEM_CC from cc to gcc because cc is something on my> >>>> system,> >>>> that I have not investigated, and doesn't work; gcc is perfectly> >>>> ok here, though> >>>> cc lines up nicely with the other two character names -- ar and as> >>>> > >>>> now need to deal with threads to get m3core to build> >>>> >>> >> > _________________________________________________________________> > Watch ?Cause Effect,? a show about real people making a real > > difference> _________________________________________________________________ Share life as it happens with the new Windows Live. http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Tue Jan 8 01:16:58 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 08 Jan 2008 01:16:58 +0100 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: References: <20080107073815.DBCDD10D45C8@birch.elegosoft.com> <4F88D761-5F3F-4891-B3BD-7490FC7E7A2A@cs.purdue.edu> Message-ID: <20080108011658.dp4d4zumw4wwkg88@mail.elegosoft.com> Quoting Jay : > Style tangent: Have people heard the advise that boolean parameters > are bad, because at the callsite esp. they don't give much meaning? > What is TRUE? What is FALSE? Enums or named parameters are clearer. I tend to agree, but this might get religious ;-) > And, more importantly, given a commit, how do I view it? > Easily?Currently I hunt around to each file and view it, but I have > to manually navigate to each file in cvs web. > I want all the diffs associated with one checkin to be viewable > together, no matter which all files were checked at the same time. You need two tags or dates to view changeset-like differences with CVS. For example cvs diff -u -r release_CM3_5_4_0 -r HEAD m3-libs will list all the changes in libraries between release 5.4.0 and the current HEAD. cvs diff -u -D yesterday -D now m3-sys Of course you can use other date formats, too, for example "1972-09-24 20:05" or "24 Sep 1972 20:05" or "1 hour ago". Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Jan 8 03:32:14 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 7 Jan 2008 21:32:14 -0500 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <47829A85.4070609@elego.de> References: <20080107192048.3FFBB10D461D@birch.elegosoft.com> <47829A85.4070609@elego.de> Message-ID: On Jan 7, 2008, at 4:32 PM, Kaspar Schleiser wrote: > Hey, > > Antony Hosking wrote: >> Log message: >> Fix bug in procedure value comparison as revealed by p035 of >> m3tests. > Is it possible that this breaks compilation on LINUXLIBC6? > I'm getting the following compiler error using the 5.4.0 release > compiler, which worked OK this morning: > > new source -> compiling RTCollector.m3 > RTCollector.m3:1878: internal compiler error: Segmentation fault > Please submit a full bug report, > with preprocessed source if appropriate. > See for instructions. Yeah, I have the same problem on I386_DARWIN. I will track down the problem tomorrow. Sorry for all the brokenness today -- it pays to compile and test before committing. It did fix the problem with p035 though. :-) > > Cheers, > Kaspar From hosking at cs.purdue.edu Tue Jan 8 04:02:34 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 7 Jan 2008 22:02:34 -0500 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <20080108011658.dp4d4zumw4wwkg88@mail.elegosoft.com> References: <20080107073815.DBCDD10D45C8@birch.elegosoft.com> <4F88D761-5F3F-4891-B3BD-7490FC7E7A2A@cs.purdue.edu> <20080108011658.dp4d4zumw4wwkg88@mail.elegosoft.com> Message-ID: On Jan 7, 2008, at 7:16 PM, Olaf Wagner wrote: > Quoting Jay : > >> Style tangent: Have people heard the advise that boolean >> parameters are bad, because at the callsite esp. they don't give >> much meaning? What is TRUE? What is FALSE? Enums or named >> parameters are clearer. > > I tend to agree, but this might get religious ;-) Indeed. I considered [0..3] but decided against it. :-) But seriously, an alternative would have been a new type in the interface I suppose. Given that it is a private module to the package I didn't feel overly compelled to be more obvious. From hosking at cs.purdue.edu Tue Jan 8 07:23:58 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 8 Jan 2008 01:23:58 -0500 Subject: [M3devel] more m3tests failures In-Reply-To: <20080108013027.jjutp2wnc48gwsk4@mail.elegosoft.com> References: <20080105210005.7iacdx5nkks84osk@mail.elegosoft.com> <20080108013027.jjutp2wnc48gwsk4@mail.elegosoft.com> Message-ID: <4E362486-79CE-4283-AA39-D18066C9E44F@cs.purdue.edu> Seems to be fixed now. Includes fix for p035. On Jan 7, 2008, at 7:30 PM, Olaf Wagner wrote: > Quoting Tony Hosking : > >> I just checked in the fix for p035, with changes to the gcc-based >> backend (tree-nested.c and parse.c). > > As Kaspar has already noticed, this seems to break compilation > of m3core: > > +++ cm3 -build -override -DROOT='/d/home/wagner/work/cm3' - > DCM3_VERSION_TEXT='d5.5.1' -DCM3_VERSION_NUMBER='050501' - > DCM3_LAST_CHANGED='2007-12-30' +++ > --- building in FreeBSD4 --- > > new source -> compiling RTCollector.m3 > RTCollector.m3:1878: internal compiler error: Segmentation fault: 11 > Please submit a full bug report, > with preprocessed source if appropriate. > See for instructions. > compilation failed => not building library "libm3core.a" > Fatal Error: package build failed > *** execution of failed *** > > Olaf >> >> On Jan 5, 2008, at 3:00 PM, Olaf Wagner wrote: >> >>> I've looked into some more failures of m3tests, which I'd like to >>> present to the whole list: (All tests run on FreeBSD 6.3) >>> >>> p035 is a scoping problem which was Ok with >>> >>> /usr/local/cm3/bin/cm3cg-5.4.0 >>> >>> but >>> >>> /usr/local/cm3/bin/cm3cg-d5.5.1 >>> >>> fails, so it must be caused by recent gcc changes. The check that >>> fails is >>> >>> PROCEDURE foo (p: P; same: BOOLEAN) = >>> BEGIN >>> checkB (bar = p, same); checkB (bar # p, NOT same); >>> END foo; >>> PROCEDURE bar (<*UNUSED*> t: Text.T) = >>> BEGIN >>> END bar; >>> BEGIN >>> msg ("group M"); foo (bar, TRUE); >>> msg ("group N"); foo (dummy, FALSE); >>> END; > > > > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, > Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Jan 8 09:13:22 2008 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Tue, 08 Jan 2008 09:13:22 +0100 Subject: [M3devel] Didn't happen for long time now... pthread related error while ./scripts/do-cm3-std.sh build Message-ID: <1199780002.11961.28.camel@faramir.m3w.org> I have Fedora6 on this box, and I've building cm3 for long time on it. Last night ago I've updated my local repo to CVS head, and tried this script.. It breaks on every package linking pthread, looks like. Then I cd to package folder, type "cm3", and it links ok. Example is at end of message. cm3.cfg changes? Here is what I think is relevant in my current. % grep -i pthread /usr/local/cm3/bin/cm3.cfg -A1 -B1 "LIBC" : [ "-lm" ], "PTHREAD" : ["-L/usr/lib", "-lpthread"], %-- not on most Linux platforms -- SYSTEM_LIBORDER = [ "OPENGL", "DECPEX", "MOTIF", "X11", "TCP", "ODBC", "POSTGRES95", "FLEX-BISON", "LEX-YACC", "LIBC", "PTHREAD" ] TIA, dd > === package m3-tools/m3totex === > +++ cm3 -DPTHREAD -build -override -DROOT='/home/dragisha/src/cm3-cvshead-0629/cm3' -DCM3_VERSION_TEXT='d5.5.1' -DCM3_VERSION_NUMBER='050501' -DCM3_LAST_CHANGED='2007-12-30' +++ > --- building in LINUXLIBC6 --- > > /home/dragisha/src/cm3-cvshead-0629/cm3/m3-tools/m3bundle/LINUXLIBC6/m3bundle -name B -F/var/tmp/qk > new source -> compiling B.i3 > new source -> compiling B.m3 > new source -> compiling m3totex.m3 > -> linking m3totex > /home/dragisha/src/cm3-cvshead-0629/cm3/m3-libs/m3core/LINUXLIBC6/libm3core.so: undefined reference to `sem_init' > /home/dragisha/src/cm3-cvshead-0629/cm3/m3-libs/m3core/LINUXLIBC6/libm3core.so: undefined reference to `pthread_key_create' > /home/dragisha/src/cm3-cvshead-0629/cm3/m3-libs/m3core/LINUXLIBC6/libm3core.so: undefined reference to `pthread_attr_setstacksize' > /home/dragisha/src/cm3-cvshead-0629/cm3/m3-libs/m3core/LINUXLIBC6/libm3core.so: undefined reference to `pthread_kill' > /home/dragisha/src/cm3-cvshead-0629/cm3/m3-libs/m3core/LINUXLIBC6/libm3core.so: undefined reference to `pthread_getspecific' > /home/dragisha/src/cm3-cvshead-0629/cm3/m3-libs/m3core/LINUXLIBC6/libm3core.so: undefined reference to `pthread_create' > /home/dragisha/src/cm3-cvshead-0629/cm3/m3-libs/m3core/LINUXLIBC6/libm3core.so: undefined reference to `pthread_attr_getstacksize' > /home/dragisha/src/cm3-cvshead-0629/cm3/m3-libs/m3core/LINUXLIBC6/libm3core.so: undefined reference to `sem_post' > /home/dragisha/src/cm3-cvshead-0629/cm3/m3-libs/m3core/LINUXLIBC6/libm3core.so: undefined reference to `pthread_detach' > /home/dragisha/src/cm3-cvshead-0629/cm3/m3-libs/m3core/LINUXLIBC6/libm3core.so: undefined reference to `sem_getvalue' > /home/dragisha/src/cm3-cvshead-0629/cm3/m3-libs/m3core/LINUXLIBC6/libm3core.so: undefined reference to `pthread_setspecific' > /home/dragisha/src/cm3-cvshead-0629/cm3/m3-libs/m3core/LINUXLIBC6/libm3core.so: undefined reference to `sem_wait' > collect2: ld returned 1 exit status > Fatal Error: package build failed > *** execution of failed *** > faramir:dragisha/pts/7: src/cm3-cvshead-0629/cm3% cd m3-tools/m3totex > faramir:dragisha/pts/7: cm3/m3-tools/m3totex% cm3 > --- building in LINUXLIBC6 --- > > ignoring ../src/m3overrides > > -> linking m3totex > faramir:dragisha/pts/7: cm3/m3-tools/m3totex% which cm3 > /usr/local/cm3/bin/cm3 > faramir:dragisha/pts/7: cm3/m3-tools/m3totex% echo $CM3 > cm3 -DPTHREAD > -- Dragi?a Duri? From lemming at henning-thielemann.de Tue Jan 8 12:29:30 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Tue, 08 Jan 2008 12:29:30 +0100 (CET) Subject: [M3devel] BOOLEAN (Was: CVS Update: cm3) In-Reply-To: <20080108011658.dp4d4zumw4wwkg88@mail.elegosoft.com> References: <20080107073815.DBCDD10D45C8@birch.elegosoft.com> <4F88D761-5F3F-4891-B3BD-7490FC7E7A2A@cs.purdue.edu> <20080108011658.dp4d4zumw4wwkg88@mail.elegosoft.com> Message-ID: On Tue, 8 Jan 2008, Olaf Wagner wrote: > Quoting Jay : > > > Style tangent: Have people heard the advise that boolean parameters > > are bad, because at the callsite esp. they don't give much meaning? > > What is TRUE? What is FALSE? Enums or named parameters are clearer. > > I tend to agree, but this might get religious ;-) In Modula-3 you can explicitly write f (switch := TRUE); Problem is of course, that you only can but you need not. Another advise I like to give about BOOLEANs is, that one should use positive flag names, e.g. not skipIntro := FALSE; but showIntro := TRUE; not disableGUI := TRUE; but enableGUI := FALSE; From jayk123 at hotmail.com Tue Jan 8 14:18:10 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 8 Jan 2008 13:18:10 +0000 Subject: [M3devel] BOOLEAN (Was: CVS Update: cm3) In-Reply-To: References: <20080107073815.DBCDD10D45C8@birch.elegosoft.com> <4F88D761-5F3F-4891-B3BD-7490FC7E7A2A@cs.purdue.edu> <20080108011658.dp4d4zumw4wwkg88@mail.elegosoft.com> Message-ID: Henning, agreed. I said named parameters help, understood that they are up to the caller to use though. Agreed about avoiding negative options, better to have an option that is positive, and leave the users as true and false, or..er..oops, that's what we are also saying not to use. I'm definitely a proponent of this second one. I actually haven't heard/used it for locals, but more for, uh, parameters. (I see I'm being hypocritical again -- don't use booleans...but if you do, use positive ones..), makes sense for locals too. On the other hand, I also like to default things to false/zero, globals, and locals, for easier/more efficient initialization, lately in C I write: void F() { type1 local1 = { 0 } type2 local2 = { 0 } .. } for all my small locals. A good compiler will optimize away at least some of them (as long as they aren't "out parameters") and I've been too burned by uninitialized locals too much, and the code is usually fairly efficient otherwise (again, the initialization can often be removed by the compiler), to desire optimizing them.. So sometimes name things to favor false being the default or more common value. For globals esp. that saves space in the resulting executable. For locals, well, if you initialize all your locals to zero, the compiler can optimize that, into a small loop for zeroing...if it was REALLY smart, it'd move the locals that are zero-initialized to be adjacent, but that could trade off with other factors so I don't assume it happens. - Jay > Date: Tue, 8 Jan 2008 12:29:30 +0100> From: lemming at henning-thielemann.de> Subject: BOOLEAN (Was: CVS Update: cm3)> To: wagner at elegosoft.com> CC: jayk123 at hotmail.com; m3devel at elegosoft.com> > > On Tue, 8 Jan 2008, Olaf Wagner wrote:> > > Quoting Jay :> >> > > Style tangent: Have people heard the advise that boolean parameters> > > are bad, because at the callsite esp. they don't give much meaning?> > > What is TRUE? What is FALSE? Enums or named parameters are clearer.> >> > I tend to agree, but this might get religious ;-)> > In Modula-3 you can explicitly write> f (switch := TRUE);> Problem is of course, that you only can but you need not.> > > Another advise I like to give about BOOLEANs is, that one should use> positive flag names, e.g. not> skipIntro := FALSE;> but> showIntro := TRUE;> > not> disableGUI := TRUE;> but> enableGUI := FALSE;> _________________________________________________________________ Make distant family not so distant with Windows Vista? + Windows Live?. http://www.microsoft.com/windows/digitallife/keepintouch.mspx?ocid=TXT_TAGLM_CPC_VideoChat_distantfamily_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Tue Jan 8 14:24:00 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 8 Jan 2008 13:24:00 +0000 Subject: [M3devel] Didn't happen for long time now... pthread related error while ./scripts/do-cm3-std.sh In-Reply-To: <1199780002.11961.28.camel@faramir.m3w.org> References: <1199780002.11961.28.camel@faramir.m3w.org> Message-ID: Not my area of expertise, but, try this: > "LIBC" : [ "-lm", "-L/usr/lib", "-lpthread" ], > "PTHREAD" : [ ], and look here: http://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/cminstall/src/config/LINUXLIBC6?rev=1.20;content-type=text%2Fplain or here: http://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/cminstall/src/config-no-install/LINUXLIBC6?rev=1.10;content-type=text%2Fplain ..ok, which suggests really, try this: "LIBC" : [ "-Xlinker", "-Bdynamic", "-L/usr/lib", "-lm", "-L/usr/lib", "-lpthread" ], and remove the PTHREAD line. (My suggest was from memory of -lpthread being on the LIBC line.) - Jay > From: dragisha at m3w.org> To: m3devel at elegosoft.com> Date: Tue, 8 Jan 2008 09:13:22 +0100> Subject: [M3devel] Didn't happen for long time now... pthread related error while ./scripts/do-cm3-std.sh build> > I have Fedora6 on this box, and I've building cm3 for long time on it.> Last night ago I've updated my local repo to CVS head, and tried this> script.. It breaks on every package linking pthread, looks like. Then I> cd to package folder, type "cm3", and it links ok. Example is at end of> message.> > cm3.cfg changes? Here is what I think is relevant in my current.> > > % grep -i pthread /usr/local/cm3/bin/cm3.cfg -A1 -B1> "LIBC" : [ "-lm" ],> "PTHREAD" : ["-L/usr/lib", "-lpthread"],> %-- not on most Linux platforms> --> SYSTEM_LIBORDER = [ "OPENGL", "DECPEX", "MOTIF", "X11", "TCP", "ODBC",> "POSTGRES95", "FLEX-BISON", "LEX-YACC", "LIBC",> "PTHREAD" ]> > TIA,> dd> > > > === package m3-tools/m3totex ===> > +++ cm3 -DPTHREAD -build -override -DROOT='/home/dragisha/src/cm3-cvshead-0629/cm3' -DCM3_VERSION_TEXT='d5.5.1' -DCM3_VERSION_NUMBER='050501' -DCM3_LAST_CHANGED='2007-12-30' +++> > --- building in LINUXLIBC6 ---> > > > /home/dragisha/src/cm3-cvshead-0629/cm3/m3-tools/m3bundle/LINUXLIBC6/m3bundle -name B -F/var/tmp/qk> > new source -> compiling B.i3> > new source -> compiling B.m3> > new source -> compiling m3totex.m3> > -> linking m3totex> > /home/dragisha/src/cm3-cvshead-0629/cm3/m3-libs/m3core/LINUXLIBC6/libm3core.so: undefined reference to `sem_init'> > /home/dragisha/src/cm3-cvshead-0629/cm3/m3-libs/m3core/LINUXLIBC6/libm3core.so: undefined reference to `pthread_key_create'> > /home/dragisha/src/cm3-cvshead-0629/cm3/m3-libs/m3core/LINUXLIBC6/libm3core.so: undefined reference to `pthread_attr_setstacksize'> > /home/dragisha/src/cm3-cvshead-0629/cm3/m3-libs/m3core/LINUXLIBC6/libm3core.so: undefined reference to `pthread_kill'> > /home/dragisha/src/cm3-cvshead-0629/cm3/m3-libs/m3core/LINUXLIBC6/libm3core.so: undefined reference to `pthread_getspecific'> > /home/dragisha/src/cm3-cvshead-0629/cm3/m3-libs/m3core/LINUXLIBC6/libm3core.so: undefined reference to `pthread_create'> > /home/dragisha/src/cm3-cvshead-0629/cm3/m3-libs/m3core/LINUXLIBC6/libm3core.so: undefined reference to `pthread_attr_getstacksize'> > /home/dragisha/src/cm3-cvshead-0629/cm3/m3-libs/m3core/LINUXLIBC6/libm3core.so: undefined reference to `sem_post'> > /home/dragisha/src/cm3-cvshead-0629/cm3/m3-libs/m3core/LINUXLIBC6/libm3core.so: undefined reference to `pthread_detach'> > /home/dragisha/src/cm3-cvshead-0629/cm3/m3-libs/m3core/LINUXLIBC6/libm3core.so: undefined reference to `sem_getvalue'> > /home/dragisha/src/cm3-cvshead-0629/cm3/m3-libs/m3core/LINUXLIBC6/libm3core.so: undefined reference to `pthread_setspecific'> > /home/dragisha/src/cm3-cvshead-0629/cm3/m3-libs/m3core/LINUXLIBC6/libm3core.so: undefined reference to `sem_wait'> > collect2: ld returned 1 exit status> > Fatal Error: package build failed> > *** execution of failed ***> > faramir:dragisha/pts/7: src/cm3-cvshead-0629/cm3% cd m3-tools/m3totex> > faramir:dragisha/pts/7: cm3/m3-tools/m3totex% cm3> > --- building in LINUXLIBC6 ---> > > > ignoring ../src/m3overrides> > > > -> linking m3totex> > faramir:dragisha/pts/7: cm3/m3-tools/m3totex% which cm3> > /usr/local/cm3/bin/cm3> > faramir:dragisha/pts/7: cm3/m3-tools/m3totex% echo $CM3> > cm3 -DPTHREAD> > > -- > Dragi?a Duri? > _________________________________________________________________ Watch "Cause Effect," a show about real people making a real difference. http://im.live.com/Messenger/IM/MTV/?source=text_watchcause -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Tue Jan 8 23:57:30 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 08 Jan 2008 23:57:30 +0100 Subject: [M3devel] pthread errors on FreeBSD In-Reply-To: References: <20080105195158.l0sirwku74k84o0s@mail.elegosoft.com> Message-ID: <20080108235730.kkfq44pjkc8s0s0o@mail.elegosoft.com> Quoting Tony Hosking : > On Jan 5, 2008, at 1:51 PM, Olaf Wagner wrote: > >> Hi Tony, >> >> I've today run the tests in m3-sys/m3tests (which were never completely >> adapted to CM3 since my initial import in 2003, I'm afraid), but there >> are two significant differences between UTHREADS and PTHREADS on >> FreeBSD. >> >> The first is the failure of p005: >> >> --- p005 --- a simple thread program >> --- p0/p005/stdout.pgm 2008-01-05 18:24:25.000000000 +0100 >> +++ ../src/p0/p005/stdout.pgm 2003-03-08 11:14:00.000000000 +0100 >> @@ -1,4 +1,4 @@ >> i = 12 >> -Changing i to 15 >> +Changing i to 19 >> Changing i to 22 >> i = 22 >> >> This concerns the order in which new threads are started. > > Whatever order they are started there is no guarantee they will reach > acquire the lock in any particular order. > >> I'm not >> sure if this is really specified, or just random; if so, the test >> should be changed. Programs which make assumptions about the order >> will of course fail then. > > The test needs changing to force a particular order. > >> The second failure shows up in p007, where `a whole bunch of threads' >> is started: >> +++ ../src/p0/p007/stderr.pgm 2003-03-08 11:14:01.000000000 +0100 >> @@ -218,11 +218,1798 @@ >> 218: 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 >> 219: 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 >> 220: 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 >> - 221: >> - >> -*** >> -*** runtime error: >> -*** Thread client error: Release failed with error: 1 >> -*** file "ThreadPThread.m3", line 174 >> -*** >> - >> + 221: 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 >> + 222: 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 >> + 223: 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 >> + 224: 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 >> + 225: 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 >> + 226: 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 >> + 227: 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 >> + 228: 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 >> + 229: 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 >> + 230: 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 >> + 231: 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 >> + 232: 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 >> + 233: 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 >> + 234: 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 >> + 235: 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 >> + 236: 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 >> >> Here a thread crashes when trying to unlock a mutex with EPERM, >> which I do not really understand. man errno says: > > I am unable to reproduce this on my I386_DARWIN machine. EPERM is the > error given if the thread trying to release the mutex does not actually > hold it. However, the ThreadPThread is already checking to make sure > the lock is held by the releasing thread, in this case claiming that > the thread *does* hold the lock. So, I suspect the EPERM error is a > result of some other problem, though I don't know what based on the > output you are showing. I wonder if you have encountered some system > limit. This seems to be caused by using the ThreadF interface to suspend other threads. If a mutex is used, the test passes: PROCEDURE Txt (t: TEXT) = BEGIN (* ThreadF.SuspendOthers (); *) LOCK iolock DO RTIO.PutText (t); END; (* ThreadF.ResumeOthers (); *) END Txt; Apart from the fact that a mutex is the correct thing to use, have you any idea why ThreadF procedures fail? It makes me a bit nervous, as they are used by the garbage collector, aren't they? Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Jan 9 00:16:36 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 8 Jan 2008 18:16:36 -0500 Subject: [M3devel] pthread errors on FreeBSD In-Reply-To: <20080108235730.kkfq44pjkc8s0s0o@mail.elegosoft.com> References: <20080105195158.l0sirwku74k84o0s@mail.elegosoft.com> <20080108235730.kkfq44pjkc8s0s0o@mail.elegosoft.com> Message-ID: Let me look into this one... On Jan 8, 2008, at 5:57 PM, Olaf Wagner wrote: > Quoting Tony Hosking : >> On Jan 5, 2008, at 1:51 PM, Olaf Wagner wrote: >> >>> The second failure shows up in p007, where `a whole bunch of >>> threads' >>> is started: >>> +++ ../src/p0/p007/stderr.pgm 2003-03-08 11:14:01.000000000 +0100 >>> @@ -218,11 +218,1798 @@ >>> 218: 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 >>> 219: 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 >>> 220: 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 >>> - 221: >>> - >>> -*** >>> -*** runtime error: >>> -*** Thread client error: Release failed with error: 1 >>> -*** file "ThreadPThread.m3", line 174 >>> -*** >>> - >>> + 221: 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 >>> + 222: 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 >>> + 223: 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 >>> + 224: 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 >>> + 225: 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 >>> + 226: 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 >>> + 227: 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 >>> + 228: 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 >>> + 229: 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 >>> + 230: 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 >>> + 231: 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 >>> + 232: 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 >>> + 233: 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 >>> + 234: 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 >>> + 235: 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 >>> + 236: 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 >>> >>> Here a thread crashes when trying to unlock a mutex with EPERM, >>> which I do not really understand. man errno says: >> >> I am unable to reproduce this on my I386_DARWIN machine. EPERM is >> the >> error given if the thread trying to release the mutex does not >> actually >> hold it. However, the ThreadPThread is already checking to make sure >> the lock is held by the releasing thread, in this case claiming that >> the thread *does* hold the lock. So, I suspect the EPERM error is a >> result of some other problem, though I don't know what based on the >> output you are showing. I wonder if you have encountered some system >> limit. > > This seems to be caused by using the ThreadF interface to suspend > other threads. If a mutex is used, the test passes: > > PROCEDURE Txt (t: TEXT) = > BEGIN > (* ThreadF.SuspendOthers (); *) > LOCK iolock DO > RTIO.PutText (t); > END; > (* ThreadF.ResumeOthers (); *) > END Txt; > > Apart from the fact that a mutex is the correct thing to use, > have you any idea why ThreadF procedures fail? It makes me a bit > nervous, as they are used by the garbage collector, aren't they? > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, > Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Wed Jan 9 04:48:25 2008 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Wed, 9 Jan 2008 04:48:25 +0100 (CET) Subject: [M3devel] Didn't happen for long time now... pthread related error while ./scripts/do-cm3-std.sh build In-Reply-To: <1199780002.11961.28.camel@faramir.m3w.org> Message-ID: <791321.83057.qm@web27112.mail.ukl.yahoo.com> Hi: Try putting "LIBC" : [ "-lm", "-lpthread" ], in cm3.cfg file I think in this Ubuntu it happened the same, so try and let we know what happens. Daniel Benavides Dragi??a Duri?? wrote: I have Fedora6 on this box, and I've building cm3 for long time on it. Last night ago I've updated my local repo to CVS head, and tried this script.. It breaks on every package linking pthread, looks like. Then I cd to package folder, type "cm3", and it links ok. Example is at end of message. cm3.cfg changes? Here is what I think is relevant in my current. % grep -i pthread /usr/local/cm3/bin/cm3.cfg -A1 -B1 "LIBC" : [ "-lm" ], "PTHREAD" : ["-L/usr/lib", "-lpthread"], %-- not on most Linux platforms -- SYSTEM_LIBORDER = [ "OPENGL", "DECPEX", "MOTIF", "X11", "TCP", "ODBC", "POSTGRES95", "FLEX-BISON", "LEX-YACC", "LIBC", "PTHREAD" ] TIA, dd > === package m3-tools/m3totex === > +++ cm3 -DPTHREAD -build -override -DROOT='/home/dragisha/src/cm3-cvshead-0629/cm3' -DCM3_VERSION_TEXT='d5.5.1' -DCM3_VERSION_NUMBER='050501' -DCM3_LAST_CHANGED='2007-12-30' +++ > --- building in LINUXLIBC6 --- > > /home/dragisha/src/cm3-cvshead-0629/cm3/m3-tools/m3bundle/LINUXLIBC6/m3bundle -name B -F/var/tmp/qk > new source -> compiling B.i3 > new source -> compiling B.m3 > new source -> compiling m3totex.m3 > -> linking m3totex > /home/dragisha/src/cm3-cvshead-0629/cm3/m3-libs/m3core/LINUXLIBC6/libm3core.so: undefined reference to `sem_init' > /home/dragisha/src/cm3-cvshead-0629/cm3/m3-libs/m3core/LINUXLIBC6/libm3core.so: undefined reference to `pthread_key_create' > /home/dragisha/src/cm3-cvshead-0629/cm3/m3-libs/m3core/LINUXLIBC6/libm3core.so: undefined reference to `pthread_attr_setstacksize' > /home/dragisha/src/cm3-cvshead-0629/cm3/m3-libs/m3core/LINUXLIBC6/libm3core.so: undefined reference to `pthread_kill' > /home/dragisha/src/cm3-cvshead-0629/cm3/m3-libs/m3core/LINUXLIBC6/libm3core.so: undefined reference to `pthread_getspecific' > /home/dragisha/src/cm3-cvshead-0629/cm3/m3-libs/m3core/LINUXLIBC6/libm3core.so: undefined reference to `pthread_create' > /home/dragisha/src/cm3-cvshead-0629/cm3/m3-libs/m3core/LINUXLIBC6/libm3core.so: undefined reference to `pthread_attr_getstacksize' > /home/dragisha/src/cm3-cvshead-0629/cm3/m3-libs/m3core/LINUXLIBC6/libm3core.so: undefined reference to `sem_post' > /home/dragisha/src/cm3-cvshead-0629/cm3/m3-libs/m3core/LINUXLIBC6/libm3core.so: undefined reference to `pthread_detach' > /home/dragisha/src/cm3-cvshead-0629/cm3/m3-libs/m3core/LINUXLIBC6/libm3core.so: undefined reference to `sem_getvalue' > /home/dragisha/src/cm3-cvshead-0629/cm3/m3-libs/m3core/LINUXLIBC6/libm3core.so: undefined reference to `pthread_setspecific' > /home/dragisha/src/cm3-cvshead-0629/cm3/m3-libs/m3core/LINUXLIBC6/libm3core.so: undefined reference to `sem_wait' > collect2: ld returned 1 exit status > Fatal Error: package build failed > *** execution of failed *** > faramir:dragisha/pts/7: src/cm3-cvshead-0629/cm3% cd m3-tools/m3totex > faramir:dragisha/pts/7: cm3/m3-tools/m3totex% cm3 > --- building in LINUXLIBC6 --- > > ignoring ../src/m3overrides > > -> linking m3totex > faramir:dragisha/pts/7: cm3/m3-tools/m3totex% which cm3 > /usr/local/cm3/bin/cm3 > faramir:dragisha/pts/7: cm3/m3-tools/m3totex% echo $CM3 > cm3 -DPTHREAD > -- Dragi??a Duri?? --------------------------------- Web Revelaci?n Yahoo! 2007: Premio Favorita del P?blico - ?Vota tu preferida! -------------- next part -------------- An HTML attachment was scrubbed... URL: From dabenavidesd at yahoo.es Wed Jan 9 05:10:17 2008 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Wed, 9 Jan 2008 05:10:17 +0100 (CET) Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: Message-ID: <909140.85424.qm@web27110.mail.ukl.yahoo.com> Hi: You can check what are the differences between a given set of files against a cvs repository with cvs and the diff option: In the below example of the directory of cm3/doc/turorial/m3 (Modula-3 tutorial), the current (in that bash session was revision 1.2), so the comparision is between my version (let's say the wanted to be commited) and the rev. 1.2: daniel at fbd-desktop:~/code/m3-devel$ cvs -d :ext:dbenavid at birch.elegosoft.com:/usr/cvs diff cm3/doc/tutorial/m3 Enter passphrase for key '/home/daniel/.ssh/id_dsa': cvs diff: Diffing cm3/doc/tutorial/m3 Index: cm3/doc/tutorial/m3/m3_2.html =================================================================== RCS file: /usr/cvs/cm3/doc/tutorial/m3/m3_2.html,v retrieving revision 1.2 diff -r1.2 m3_2.html 30c30 < IO.GetLine(name); --- > name:=IO.GetLine(); daniel at fbd-desktop:~/code/m3-devel$ The contents of the my current directory (me-devel) are: daniel at fbd-desktop:~/code/m3-devel$ ls -alh cm3/* cm3/CVS: total 20K drwxr-xr-x 2 daniel daniel 4,0K 2008-01-06 10:28 . drwxr-xr-x 4 daniel daniel 4,0K 2008-01-06 09:40 .. -rw-r--r-- 1 daniel daniel 10 2008-01-06 10:28 Entries -rw-r--r-- 1 daniel daniel 0 2008-01-06 09:40 Entries.Static -rw-r--r-- 1 daniel daniel 4 2008-01-06 09:40 Repository -rw-r--r-- 1 daniel daniel 43 2008-01-06 09:40 Root cm3/doc: total 16K drwxr-xr-x 4 daniel daniel 4,0K 2008-01-06 09:40 . drwxr-xr-x 4 daniel daniel 4,0K 2008-01-06 09:40 .. drwxr-xr-x 2 daniel daniel 4,0K 2008-01-06 10:28 CVS drwxr-xr-x 4 daniel daniel 4,0K 2008-01-06 09:40 tutorial daniel at fbd-desktop:~/code/m3-devel$ This is helpful if you want to compare them in a recursively way. Daniel Benavides Jay wrote: .hmmessage P { margin:0px; padding:0px } body.hmmessage { FONT-SIZE: 10pt; FONT-FAMILY:Tahoma } Right, thanks. Looks/sounds about right. Will try it "later". Except: http://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/cm3/src/M3BackWin32.m3.diff?r1=1.2;r2=1.3 Looks suspicious, just by visual inspection, haven't built it -- missing an import and comma vs. period. Style tangent: Have people heard the advise that boolean parameters are bad, because at the callsite esp. they don't give much meaning? What is TRUE? What is FALSE? Enums or named parameters are clearer. Furthermore, heck, the switch on small integers 0,1,2,3... (Not that my switching on targetname was good either.) And, more importantly, given a commit, how do I view it? Easily? Currently I hunt around to each file and view it, but I have to manually navigate to each file in cvs web. I want all the diffs associated with one checkin to be viewable together, no matter which all files were checked at the same time. - Jay --------------------------------- > CC: m3devel at elegosoft.com; m3commit at elegosoft.com > From: hosking at cs.purdue.edu > Subject: Re: [M3commit] CVS Update: cm3 > Date: Mon, 7 Jan 2008 17:29:04 -0500 > To: jayk123 at hotmail.com > > > On Jan 7, 2008, at 4:10 PM, Jay wrote: > > > > > > >> Thus, controlling the backend is a simple matter of changing the > >> cm3.cfg > > > > > > > > Exactly. > > > > > > What I have right now is I build an NT386/Win32 cm3, and then I > > change the config file, and that one cm3 switches between gcc or not. > > It is a hybrid. > > The hybrid behavior can be controlled from cm3.cfg instead. See my > latest checkin. > > > I can already compile all of m3core with this cm3/m3cg, except for > > threading. > > I also copy the NT386 directories in pkg to NT386GNU, and possibly > > foo.lib to libfoo.a -- I have to try again to see if that was the > > key or not. > > This gives me an easier sort of "cross", on one machine/OS. > > > > I actually swap out the entire cm3.cfg, cm3/m3-sys/cminstall/config/ > > NT386 vs. cm3/m3-sys/cminstall/config/NT386GNU, not just one line. > > > > I'll try the "mode" and look at pm3. Thanks. > > > > > >> threading > > > > Yeah I thought Win32 would work. I'll try/look again. Later. > > I think it was set for Posix/setjmp/longjmp and I think I tried > > pthreads, might not have tried Win32. > > > > - Jay > > > >> From: hosking at cs.purdue.edu > >> Date: Mon, 7 Jan 2008 15:27:30 -0500 > >> To: hosking at cs.purdue.edu > >> CC: m3devel at elegosoft.com; m3commit at elegosoft.com > >> Subject: Re: [M3commit] CVS Update: cm3 > >> > >> Also, following up on your changes for the backend. I suggest you > >> take a look at the way things are handled in the M3BackLinux.m3 code > >> for PM3. You should be able to switch between the integrated backend > >> and the gcc-based backend similarly, based on the value of the > >> M3_BACKEND_MODE flag. Thus, controlling the backend is a simple > >> matter of changing the cm3.cfg. > >> > >> > >> > >> On Jan 7, 2008, at 3:16 PM, Tony Hosking wrote: > >> > >>> Jay, I am very nervous about the pervasive nature of some of your > >>> recent commits. NT386GNU is usually configured with > >>> OS_TYPE="POSIX". Thus, the m3makefile for cm3, which contains the > >>> following: > >>> > >>> if equal (OS_TYPE, "POSIX") > >>> interface ("M3Backend") > >>> implementation ("M3BackPosix") > >>> implementation ("UtilsPosix") > >>> else > >>> import ("m3objfile") > >>> import ("m3back") > >>> interface ("M3Backend") > >>> implementation ("M3BackWin32") > >>> implementation ("UtilsWin32") > >>> end > >>> > >>> will build a POSIX backend for you on NT386GNU which should do the > >>> right thing in invoking the gcc-based backend. Your changes, which > >>> hardwire things in cm3 for NT386GNU are thus unnecessary. I > >>> suggest you back these changes out and reconsider things. > >>> Certainly, NT386GNU should be considered as an independent POSIX > >>> target from the NT386 WIN32 target. Thus, one need not make > >>> changes to M3BackWin32 for NT386GNU, since it is treated as a POSIX > >>> target. > >>> > >>> As far as threading goes, if user-level threading for NT386 does > >>> not work then I can imagine it would be OK to use native WIN32 > >>> threads. The switch for that is in m3core/src/thread/m3makefile, > >>> which would check for TARGET="NT386GNU" and choose sibdirectory > >>> WIN32 instead of using OS_TYPE to pick subdirectory POSIX. > >>> > >>> On Jan 7, 2008, at 8:38 AM, Jay Krell wrote: > >>> > >>>> CVSROOT: /usr/cvs > >>>> Changes by: jkrell at birch. 08/01/07 08:38:15 > >>>> > >>>> Modified files: > >>>> cm3/m3-libs/m3core/src/unix/cygwin/: Umman.i3 Uresource.i3 > >>>> Utypes.m3 > >>>> cm3/m3-sys/cm3/src/: Builder.i3 Builder.m3 M3BackPosix.m3 > >>>> M3BackWin32.m3 M3Backend.i3 > >>>> cm3/m3-sys/cminstall/src/config/: NT386GNU > >>>> cm3/m3-sys/m3front/src/misc/: M3Front.m3 > >>>> > >>>> Log message: > >>>> some fixes for NT386GNU (cygwin) > >>>> > >>>> let win32 cm3 use the gcc backend if target == NT386GNU > >>>> might need a better interface here? > >>>> switching on target name is probably the wrong thing > >>>> need something called "use gcc backend" or somesuch > >>>> > >>>> loosen the check for file name vs. module name to account for > >>>> paths with both types of slashes > >>>> might need a better interface/implementation here? > >>>> should try to get the paths to line up instead? > >>>> > >>>> remove -fPIC since it warns that it is redundant (though the > >>>> warning is probably wrong > >>>> in other details -- not all code is position independent, merely > >>>> relocatable..) > >>>> > >>>> use configured ar, /usr/bin/ar doesn't work, just plain ar does > >>>> > >>>> update Umman.i3 MAP_ANONYMOUS to new shorter name MAP_ANON > >>>> > >>>> update Uresource.i3 from struct_rusage_start to VAR struct_rusage > >>>> > >>>> fix warning about unused import long in Utypes.m3 > >>>> > >>>> change SYSTEM_CC from cc to gcc because cc is something on my > >>>> system, > >>>> that I have not investigated, and doesn't work; gcc is perfectly > >>>> ok here, though > >>>> cc lines up nicely with the other two character names -- ar and as > >>>> > >>>> now need to deal with threads to get m3core to build > >>> > >> > > > > _________________________________________________________________ > > Watch ?Cause Effect,? a show about real people making a real > > difference > --------------------------------- Share life as it happens with the new Windows Live. Start sharing! --------------------------------- Web Revelaci?n Yahoo! 2007: Premio Favorita del P?blico - ?Vota tu preferida! -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Wed Jan 9 11:29:48 2008 From: jayk123 at hotmail.com (Jay) Date: Wed, 9 Jan 2008 10:29:48 +0000 Subject: [M3devel] bunch of win32 archives available Message-ID: I can now readily create these, just via scripts\python\make-dist.Interesting? Note that that they are all now "rooted" in a directory correspondingto their "basename" (cm3-min-WIN32-NT386-d5.5.1, not just cm3, not one level below that)I'm still undecided on this. Rooting them at just "cm3" is much more convenient.Even if I setup a link/junction, cm3 to ...d.5.5.1, annoying then to upgradeit in place to 5.5.2 and still have the old directory name. Also note that "core" and "base" sound the same, and are almost the same. C:\DOCUME~1\Jay\LOCALS~1\Temp\cm3\make-dist\tmp4zutb8>dir /a-d Directory of C:\DOCUME~1\Jay\LOCALS~1\Temp\cm3\make-dist\tmp4zutb8 01/09/2008 12:08 AM 1,666,826 cm3-base-WIN32-NT386-d5.5.1-symbols.tar.bz201/09/2008 12:07 AM 1,939,273 cm3-base-WIN32-NT386-d5.5.1-symbols.zip01/09/2008 12:08 AM 7,388,174 cm3-base-WIN32-NT386-d5.5.1.exe01/09/2008 12:08 AM 5,941,364 cm3-base-WIN32-NT386-d5.5.1.tar.bz201/09/2008 12:08 AM 7,209,998 cm3-base-WIN32-NT386-d5.5.1.zip01/09/2008 12:07 AM 1,590,776 cm3-core-WIN32-NT386-d5.5.1-symbols.tar.bz201/09/2008 12:06 AM 1,943,429 cm3-core-WIN32-NT386-d5.5.1-symbols.zip01/09/2008 12:07 AM 7,388,037 cm3-core-WIN32-NT386-d5.5.1.exe01/09/2008 12:07 AM 5,942,837 cm3-core-WIN32-NT386-d5.5.1.tar.bz201/09/2008 12:07 AM 7,209,861 cm3-core-WIN32-NT386-d5.5.1.zip01/09/2008 12:02 AM 734,369 cm3-min-WIN32-NT386-d5.5.1-symbols.tar.bz201/09/2008 12:02 AM 891,409 cm3-min-WIN32-NT386-d5.5.1-symbols.zip01/09/2008 12:02 AM 3,346,742 cm3-min-WIN32-NT386-d5.5.1.exe01/09/2008 12:02 AM 2,642,419 cm3-min-WIN32-NT386-d5.5.1.tar.bz201/09/2008 12:02 AM 3,168,566 cm3-min-WIN32-NT386-d5.5.1.zip01/09/2008 12:04 AM 5,493,247 cm3-std-WIN32-NT386-d5.5.1-symbols.tar.bz201/09/2008 12:03 AM 6,617,011 cm3-std-WIN32-NT386-d5.5.1-symbols.zip01/09/2008 12:04 AM 19,373,554 cm3-std-WIN32-NT386-d5.5.1.exe01/09/2008 12:06 AM 15,826,615 cm3-std-WIN32-NT386-d5.5.1.tar.bz201/09/2008 12:04 AM 19,195,378 cm3-std-WIN32-NT386-d5.5.1.zip I guess just stick with .zip. Arguably symbols are for "power users/developers" that will have tar/bzip2, arguably not. - Jay _________________________________________________________________ Get the power of Windows + Web with the new Windows Live. http://www.windowslive.com?ocid=TXT_TAGHM_Wave2_powerofwindows_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Wed Jan 9 17:05:57 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 9 Jan 2008 11:05:57 -0500 Subject: [M3devel] Didn't happen for long time now... pthread related error while ./scripts/do-cm3-std.sh In-Reply-To: References: <1199780002.11961.28.camel@faramir.m3w.org> Message-ID: On Jan 8, 2008, at 8:24 AM, Jay wrote: > Not my area of expertise, but, try this: > > > "LIBC" : [ "-lm", "-L/usr/lib", "-lpthread" ], > > "PTHREAD" : [ ], PTHREAD is no longer used, so can safely be discarded. LIBC should indeed contain "-lpthread" where pthreads are not part of libc. > > > and look here: > > http://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/cminstall/ > src/config/LINUXLIBC6?rev=1.20;content-type=text%2Fplain > > or here: > > http://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/cminstall/ > src/config-no-install/LINUXLIBC6?rev=1.10;content-type=text%2Fplain > > ..ok, which suggests really, try this: > > "LIBC" : [ "-Xlinker", "-Bdynamic", "-L/usr/lib", "-lm", "- > L/usr/lib", "-lpthread" ], > > and remove the PTHREAD line. (My suggest was from memory of - > lpthread being on the LIBC line.) > > - Jay > > > > > From: dragisha at m3w.org > > To: m3devel at elegosoft.com > > Date: Tue, 8 Jan 2008 09:13:22 +0100 > > Subject: [M3devel] Didn't happen for long time now... pthread > related error while ./scripts/do-cm3-std.sh build > > > > I have Fedora6 on this box, and I've building cm3 for long time > on it. > > Last night ago I've updated my local repo to CVS head, and tried > this > > script.. It breaks on every package linking pthread, looks like. > Then I > > cd to package folder, type "cm3", and it links ok. Example is at > end of > > message. > > > > cm3.cfg changes? Here is what I think is relevant in my current. > > > > > > % grep -i pthread /usr/local/cm3/bin/cm3.cfg -A1 -B1 > > "LIBC" : [ "-lm" ], > > "PTHREAD" : ["-L/usr/lib", "-lpthread"], > > %-- not on most Linux platforms > > -- > > SYSTEM_LIBORDER = [ "OPENGL", "DECPEX", "MOTIF", "X11", "TCP", > "ODBC", > > "POSTGRES95", "FLEX-BISON", "LEX-YACC", "LI! BC", > > "PTHREAD" ] > > > > TIA, > > dd > > > > > > > === package m3-tools/m3totex === > > > +++ cm3 -DPTHREAD -build -override -DROOT='/home/dragisha/src/ > cm3-cvshead-0629/cm3' -DCM3_VERSION_TEXT='d5.5.1' - > DCM3_VERSION_NUMBER='050501' -DCM3_LAST_CHANGED='2007-12-30' +++ > > > --- building in LINUXLIBC6 --- > > > > > > /home/dragisha/src/cm3-cvshead-0629/cm3/m3-tools/m3bundle/ > LINUXLIBC6/m3bundle -name B -F/var/tmp/qk > > > new source -> compiling B.i3 > > > new source -> compiling B.m3 > > > new source -> compiling m3totex.m3 > > > -> linking m3totex > > > /home/dragisha/src/cm3-cvshead-0629/cm3/m3-libs/m3core/ > LINUXLIBC6/libm3core.so: undefined reference to `sem_init' > > > /home/dragisha/src/cm3-cvshead-0629/cm3/m3-libs/m3core/ > LINUXLIBC6/libm3core.so: undefined reference to `pthread_key_create' > > > /home/dragisha/src/cm3-cvshead-0629/cm3/m3-libs/m3c! ore/ > LINUXLIBC6/libm3core.so: undefined reference to `pthread_attr_sets > tacksize' > > > /home/dragisha/src/cm3-cvshead-0629/cm3/m3-libs/m3core/ > LINUXLIBC6/libm3core.so: undefined reference to `pthread_kill' > > > /home/dragisha/src/cm3-cvshead-0629/cm3/m3-libs/m3core/ > LINUXLIBC6/libm3core.so: undefined reference to `pthread_getspecific' > > > /home/dragisha/src/cm3-cvshead-0629/cm3/m3-libs/m3core/ > LINUXLIBC6/libm3core.so: undefined reference to `pthread_create' > > > /home/dragisha/src/cm3-cvshead-0629/cm3/m3-libs/m3core/ > LINUXLIBC6/libm3core.so: undefined reference to > `pthread_attr_getstacksize' > > > /home/dragisha/src/cm3-cvshead-0629/cm3/m3-libs/m3core/ > LINUXLIBC6/libm3core.so: undefined reference to `sem_post' > > > /home/dragisha/src/cm3-cvshead-0629/cm3/m3-libs/m3core/ > LINUXLIBC6/libm3core.so: undefined reference to `pthread_detach' > > > /home/dragisha/src/cm3-cvshead-0629/cm3/m3-libs/m3core/ > LINUXLIBC6/libm3core.so: undefined reference to `sem_getvalue' > > > /home/dragisha/src/cm3-cvshea! d-0629/cm3/m3-libs/m3core/ > LINUXLIBC6/libm3core.so: undefined reference to `pthread_setspecific' > > > /home/dragisha/src/cm3-cvshead-0629/cm3/m3-libs/m3core/ > LINUXLIBC6/libm3core.so: undefined reference to `sem_wait' > > > collect2: ld returned 1 exit status > > > Fatal Error: package build failed > > > *** execution of failed *** > > > faramir:dragisha/pts/7: src/cm3-cvshead-0629/cm3% cd m3-tools/ > m3totex > > > faramir:dragisha/pts/7: cm3/m3-tools/m3totex% cm3 > > > --- building in LINUXLIBC6 --- > > > > > > ignoring ../src/m3overrides > > > > > > -> linking m3totex > > > faramir:dragisha/pts/7: cm3/m3-tools/m3totex% which cm3 > > > /usr/local/cm3/bin/cm3 > > > faramir:dragisha/pts/7: cm3/m3-tools/m3totex% echo $CM3 > > > cm3 -DPTHREAD > > > > > -- > > Dragi?a Duri? > > > > > Watch "Cause Effect," a show abo! ut real people making a real > difference. Learn more From hosking at cs.purdue.edu Wed Jan 9 18:03:47 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 9 Jan 2008 12:03:47 -0500 Subject: [M3devel] pthread errors on FreeBSD In-Reply-To: <20080108235730.kkfq44pjkc8s0s0o@mail.elegosoft.com> References: <20080105195158.l0sirwku74k84o0s@mail.elegosoft.com> <20080108235730.kkfq44pjkc8s0s0o@mail.elegosoft.com> Message-ID: <0EF146EC-FC60-4467-BEA0-D2B18C608E3C@cs.purdue.edu> On Jan 8, 2008, at 5:57 PM, Olaf Wagner wrote: > Quoting Tony Hosking : >> On Jan 5, 2008, at 1:51 PM, Olaf Wagner wrote: >> >>> >>> The second failure shows up in p007, where `a whole bunch of >>> threads' >>> is started: >>> +++ ../src/p0/p007/stderr.pgm 2003-03-08 11:14:01.000000000 +0100 >>> @@ -218,11 +218,1798 @@ >>> 218: 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 >>> 219: 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 >>> 220: 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 >>> - 221: >>> - >>> -*** >>> -*** runtime error: >>> -*** Thread client error: Release failed with error: 1 >>> -*** file "ThreadPThread.m3", line 174 >>> -*** >>> - >>> + 221: 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 >>> + 222: 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 >>> + 223: 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 >>> + 224: 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 >>> + 225: 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 >>> + 226: 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 >>> + 227: 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 >>> + 228: 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 >>> + 229: 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 >>> + 230: 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 >>> + 231: 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 >>> + 232: 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 >>> + 233: 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 >>> + 234: 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 >>> + 235: 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 >>> + 236: 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 >>> >>> Here a thread crashes when trying to unlock a mutex with EPERM, >>> which I do not really understand. man errno says: >> >> I am unable to reproduce this on my I386_DARWIN machine. EPERM is >> the >> error given if the thread trying to release the mutex does not >> actually >> hold it. However, the ThreadPThread is already checking to make sure >> the lock is held by the releasing thread, in this case claiming that >> the thread *does* hold the lock. So, I suspect the EPERM error is a >> result of some other problem, though I don't know what based on the >> output you are showing. I wonder if you have encountered some system >> limit. > > This seems to be caused by using the ThreadF interface to suspend > other threads. If a mutex is used, the test passes: > > PROCEDURE Txt (t: TEXT) = > BEGIN > (* ThreadF.SuspendOthers (); *) > LOCK iolock DO > RTIO.PutText (t); > END; > (* ThreadF.ResumeOthers (); *) > END Txt; > > Apart from the fact that a mutex is the correct thing to use, > have you any idea why ThreadF procedures fail? It makes me a bit > nervous, as they are used by the garbage collector, aren't they? ThreadF.SuspendOthers/ResumeOthers are particularly dangerous operations that should not be used generally by user-level code, especially where multiple threads may simultaneously invoke SuspendOthers/ResumeOthers, as in this example. I suspect also that any call to SuspendOthers should only be made when RTOS.LockHeap has been called, based on the dependency between LockHeap and SuspendOthers in the ThreadPThread implementation. I could fix this by adding the necessary calls to SuspendOthers (since LockHeap is re- entrant), but would like you to confirm that the following change "works" (even though a lock really is the correct way to go): PROCEDURE Txt (t: TEXT) = BEGIN RTOS.LockHeap(); ThreadF.SuspendOthers (); RTIO.PutText (t); ThreadF.ResumeOthers (); RTOS.UnlockHeap(); END Txt; > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, > Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Jan 10 00:08:57 2008 From: jayk123 at hotmail.com (Jay) Date: Wed, 9 Jan 2008 23:08:57 +0000 Subject: [M3devel] nt386gnu is posix or win32? In-Reply-To: References: <20080107073815.DBCDD10D45C8@birch.elegosoft.com> <4F88D761-5F3F-4891-B3BD-7490FC7E7A2A@cs.purdue.edu> Message-ID: I'm going to be rude and just throw this out there at a time when I probably can't discuss it or yet have enough data/diffs to matter. However, in building NT386GNU -- I can build libm3 and m3core -- the question arises as to if this target is "win32" or "posix'. Currently in the tree it is setup to be "posix", with a fair amount of work already done in that direction -- in particular, the Unix interfaces. However, I think this target is potentially an odd beast. Potentially it is two targets. I guess this mimics cygwin vs. mingwin. Exactly. The "host" is gcc. In order to build this system, one needs "gmake", sh, gcc probably (I'm assuming Visual C++'s compiler/linker cannot build m3cg, but very maybe..). In order to build anything with this system, one needs "as", and most likely ld. (I quote "as" because it is an English word and confusing to read otherwise.) Changing it to output assembly for masm or even Visual C++'s inline __asm is probably actually viable, but not a tiny short term task. (Or maybe writing an as clone that outputs .objs? Maybe using nasm/yasm??? Not sure the point, maybe "as" is perfectly ok.) And then the question arises as to what it takes to run the output. As I've said in other topics, the C runtime dependency of Modula-3 is light -- startup code mainly, but, yeah, also important setjmp/longjmp, and multiplication/division helpers sometimes. This could perhaps all be statically linked. Certainly for Visual C++ it can be. (NOTE: The Cygwin jmp_buf is much larger than Visual C++'s. A THOUGHT is to grow them to the same, for object code compatibility, but probably not useful, and very wasteful, Cygwin's is much larger, the data in the existing code I verified is correct, like 0x40 vs. 0xD0 I think it was, I just did printf("%x", sizeof(jmp_buf)).) To get m3core to build, I switched NT386GNU to use Win32 threads. For THAT to build, I switched OSTYPE to Win32. Overkill perhaps, in order to get the Win32 *.i3 files. Overkill perhaps, but it does build. I fully suspect that old style Posix threads can work easily, and that pthreads can work easily, increasing the dependency on cygwin1.dll. While this is the "other" direction, given the dependency on as, and gcc to build m3cg, probably the horse is out of the barn. This is arguably a simpler answer, less hybrid. I think the analogy to cygwin/mingwin holds, possibly perfectly. Maybe this is two targets. NT386CYGWIN ? NT386MINGWIN ? (Which begs the point -- target naming.... NT386 vs. PPC_LINUX...OS+ARCH vs. ARCH + _ + OS, etc... but ARCH and OS aren't it, there is toolchain and C runtime in the mix..) Obviously SOMETHING is better than NOTHING and I have no useful binary distribution yet to show, so these questions are all very premature. I'm also unsure as to the "seriousness" of using the GNU tools. a) There don't seem to be many users of Modula-3 on Win32. b) Will such users accept/trust a non Microsoft toolchain? (Just what to do folks do with cygwin/mingwin? Build/ship real software?) >From my point of view, the attractive thing about m3cg is I get the int64 stuff arguably out of the way easier. :) Licensing wise..probably a dependency on cygwin1.dll is not desirable. When I'm further along, er, actually, with my existing libm3.dll/m3core.dll, I can see what the dependencies are. If it's just setjmp/lonjmp/memset, maybe try static linking (what is the licensing of that?) or link to msvcr*.dll. Maybe see if I can configure to use mingwin to compile/link except for m3cc. That sounds excellent. You would configure a CYGWIN_ROOT (gcc, ld, make, sh, libs) and a MINGWIN_ROOT (gcc, ld, libs). CYGWIN_ROOT would be required for building m3cc, and either could be used for building anything else. ?? That seems good, though I just thought of it, need more time to think and investigate. Later.. - Jay _________________________________________________________________ Share life as it happens with the new Windows Live. http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Thu Jan 10 01:16:03 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 10 Jan 2008 01:16:03 +0100 Subject: [M3devel] pthread errors on FreeBSD In-Reply-To: <0EF146EC-FC60-4467-BEA0-D2B18C608E3C@cs.purdue.edu> References: <20080105195158.l0sirwku74k84o0s@mail.elegosoft.com> <20080108235730.kkfq44pjkc8s0s0o@mail.elegosoft.com> <0EF146EC-FC60-4467-BEA0-D2B18C608E3C@cs.purdue.edu> Message-ID: <20080110011603.zwkknbh9z44gk40k@mail.elegosoft.com> Quoting Tony Hosking : > On Jan 8, 2008, at 5:57 PM, Olaf Wagner wrote: >> This seems to be caused by using the ThreadF interface to suspend >> other threads. If a mutex is used, the test passes: >> >> PROCEDURE Txt (t: TEXT) = >> BEGIN >> (* ThreadF.SuspendOthers (); *) >> LOCK iolock DO >> RTIO.PutText (t); >> END; >> (* ThreadF.ResumeOthers (); *) >> END Txt; >> >> Apart from the fact that a mutex is the correct thing to use, >> have you any idea why ThreadF procedures fail? It makes me a bit >> nervous, as they are used by the garbage collector, aren't they? > > ThreadF.SuspendOthers/ResumeOthers are particularly dangerous > operations that should not be used generally by user-level code, > especially where multiple threads may simultaneously invoke > SuspendOthers/ResumeOthers, as in this example. I suspect also that > any call to SuspendOthers should only be made when RTOS.LockHeap has > been called, based on the dependency between LockHeap and SuspendOthers > in the ThreadPThread implementation. I could fix this by adding the > necessary calls to SuspendOthers (since LockHeap is re-entrant), but > would like you to confirm that the following change "works" (even > though a lock really is the correct way to go): > > PROCEDURE Txt (t: TEXT) = > BEGIN > RTOS.LockHeap(); > ThreadF.SuspendOthers (); > RTIO.PutText (t); > ThreadF.ResumeOthers (); > RTOS.UnlockHeap(); > END Txt; Though it sounds very convincing, it cannot be completely right: I've run the test three times with mutual exclusion as suggested, and it crashed at three different counts, but never completed :-/ Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Jan 10 02:02:38 2008 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Wed, 9 Jan 2008 20:02:38 -0500 Subject: [M3devel] nt386gnu is posix or win32? In-Reply-To: References: <20080107073815.DBCDD10D45C8@birch.elegosoft.com> <4F88D761-5F3F-4891-B3BD-7490FC7E7A2A@cs.purdue.edu> Message-ID: <20080110010238.GA3891@topoi.pooq.com> On Wed, Jan 09, 2008 at 11:08:57PM +0000, Jay wrote: > I'm going to be rude and just throw this out there at a time when I probably can't discuss it or yet have enough data/diffs to matter. > > However, in building NT386GNU -- I can build libm3 and m3core -- the question arises as to if this target is "win32" or "posix'. > Currently in the tree it is setup to be "posix", with a fair amount of work already done in that direction -- in particular, the Unix interfaces. > > However, I think this target is potentially an odd beast. Potentially it is two targets. > I guess this mimics cygwin vs. mingwin. Exactly. > > The "host" is gcc. In order to build this system, one needs "gmake", sh, gcc probably (I'm assuming Visual C++'s compiler/linker cannot build m3cg, but very maybe..). > > In order to build anything with this system, one needs "as", and most likely ld. > (I quote "as" because it is an English word and confusing to read otherwise.) > Changing it to output assembly for masm or even Visual C++'s inline __asm is probably actually viable, but not a tiny short term task. > (Or maybe writing an as clone that outputs .objs? Maybe using nasm/yasm??? Not sure the point, maybe "as" is perfectly ok.) > > And then the question arises as to what it takes to run the output. > As I've said in other topics, the C runtime dependency of Modula-3 is light -- startup code mainly, but, yeah, also important setjmp/longjmp, and multiplication/division helpers sometimes. This could perhaps all be statically linked. Certainly for Visual C++ it can be. > (NOTE: The Cygwin jmp_buf is much larger than Visual C++'s. A THOUGHT is to grow them to the same, for object code compatibility, but probably not useful, and very wasteful, Cygwin's is much larger, the data in the existing code I verified is correct, like 0x40 vs. 0xD0 I think it was, I just did printf("%x", sizeof(jmp_buf)).) > > To get m3core to build, I switched NT386GNU to use Win32 threads. > For THAT to build, I switched OSTYPE to Win32. Overkill perhaps, in order to get the Win32 *.i3 files. > Overkill perhaps, but it does build. > > I fully suspect that old style Posix threads can work easily, and that pthreads can work easily, increasing the dependency on cygwin1.dll. > While this is the "other" direction, given the dependency on as, and gcc to build m3cg, probably the horse is out of the barn. > This is arguably a simpler answer, less hybrid. > > I think the analogy to cygwin/mingwin holds, possibly perfectly. > > Maybe this is two targets. > NT386CYGWIN ? > NT386MINGWIN ? > > (Which begs the point -- target naming.... NT386 vs. PPC_LINUX...OS+ARCH vs. ARCH + _ + OS, etc... but ARCH and OS aren't it, there is toolchain and C runtime in the mix..) > > Obviously SOMETHING is better than NOTHING and I have no useful binary distribution yet to show, so these questions are all very premature. > > I'm also unsure as to the "seriousness" of using the GNU tools. > a) There don't seem to be many users of Modula-3 on Win32. > b) Will such users accept/trust a non Microsoft toolchain? > (Just what to do folks do with cygwin/mingwin? Build/ship real software?) One of my reasons for using m3 long ago was that I could write programs that would run on both Linux and Windows *without* using the Microsoft tools, which I did not possess. -- hendrik From darko at darko.org Thu Jan 10 02:24:42 2008 From: darko at darko.org (Darko) Date: Wed, 9 Jan 2008 17:24:42 -0800 Subject: [M3devel] nt386gnu is posix or win32? In-Reply-To: References: <20080107073815.DBCDD10D45C8@birch.elegosoft.com> <4F88D761-5F3F-4891-B3BD-7490FC7E7A2A@cs.purdue.edu> Message-ID: <6B5887DD-C4CA-4A5F-9814-C59F9B5DCD87@darko.org> On 09/01/2008, at 3:08 PM, Jay wrote: > a) There don't seem to be many users of Modula-3 on Win32. > b) Will such users accept/trust a non Microsoft toolchain? I think there are as many users as any other CM3 platform. It's an important platform, so it should be supported for that reason I think. Being able to use the GCC back end is very useful. I'm not sure what your exact criteria for 'seriousness' is though. I'd like to see MinGW supported because of better performance and the permissive licence. Implementation issues aside, I don't see the point of loading up all the Cygwin junk onto Windows to make it look like Posix. Darko. From darko at darko.org Thu Jan 10 02:25:31 2008 From: darko at darko.org (Darko) Date: Wed, 9 Jan 2008 17:25:31 -0800 Subject: [M3devel] nt386gnu is posix or win32? In-Reply-To: <20080110010238.GA3891@topoi.pooq.com> References: <20080107073815.DBCDD10D45C8@birch.elegosoft.com> <4F88D761-5F3F-4891-B3BD-7490FC7E7A2A@cs.purdue.edu> <20080110010238.GA3891@topoi.pooq.com> Message-ID: On 09/01/2008, at 5:02 PM, hendrik at topoi.pooq.com wrote: > > One of my reasons for using m3 long ago was that I could write > programs > that would run on both Linux and Windows *without* using the Microsoft > tools, which I did not possess. > > -- hendrik There are free versions of the tools these days, if that makes any difference. Darko. From mika at async.caltech.edu Thu Jan 10 02:31:25 2008 From: mika at async.caltech.edu (Mika Nystrom) Date: Wed, 09 Jan 2008 17:31:25 -0800 Subject: [M3devel] nt386gnu is posix or win32? In-Reply-To: Your message of "Wed, 09 Jan 2008 17:25:31 PST." Message-ID: <200801100131.m0A1VQYS034516@camembert.async.caltech.edu> In this vein, I can tell you I am a frequent user of Modula-3 on Windows. I use PM3/Klagenfurt on a Win 2003 Server system, and occasionally on XP and Win2k. I use it this way because while I develop on Unix, I have users who insist on using Windows for their servers. What matters to me is that I can get an environment that (a) runs decently fast on Windows (b) looks as much as possible like Unix (also from the user point of view) (c) requires minimal code changes The combination of Cygwin and M3 takes care of this, more or less... It's also an easy download/install. Mika Darko writes: > >On 09/01/2008, at 5:02 PM, hendrik at topoi.pooq.com wrote: >> >> One of my reasons for using m3 long ago was that I could write >> programs >> that would run on both Linux and Windows *without* using the Microsoft >> tools, which I did not possess. >> >> -- hendrik > > >There are free versions of the tools these days, if that makes any >difference. > >Darko. From jayk123 at hotmail.com Thu Jan 10 08:11:11 2008 From: jayk123 at hotmail.com (Jay) Date: Thu, 10 Jan 2008 07:11:11 +0000 Subject: [M3devel] bad code on PPC_LINUX? Message-ID: Something is screwy I think. My gdb skills are um not good. On PPC_LINUX. /dev2/cm3/m3-sys/cm3/src/Utils.m3 PROCEDURE WriteFile (file: TEXT; proc: Emitter; append := FALSE) = VAR wr: Wr.T; BEGIN IF (append) THEN wr := AppendWriter (file, fatal := TRUE); ELSE wr := OpenWriter (file, fatal := TRUE); END; TRY (* line 78 *) TRY proc (wr); EXCEPT | Wr.Failure (ec) => Msg.FatalError (ec, "write failed on ", file); | Thread.Alerted => Msg.FatalError (NIL, "interrupted while writing ", file); END; FINALLY CloseWriter (wr, file); END; END WriteFile; I get a SEGV on line 78. I'm willing to believe, sadly, that some of these huge offsets are the price of TRY and saving the register context on anything other than x86 (for registers that aren't even used by the function?), however it crashes just after the call and notice there the huge 32k offset. And really? A 720 byte frame for any function with a TRY on PowerPC? Really? I guess I should look at what PPC_DARWIN does. If someone can give me a quick run down on PowerPC ABI, thanks. I'll search the web. Or maybe check my Mac docs. register 0 is 0 or general purpose? Stack is register ? I know that return address is in the link register. bl is branch and link -- call -- jump and save pc in link register. The code is: (gdb) disassemble Dump of assembler code for function Utils__WriteFile: 0x10024fbc : stwu r1,-720(r1) 0x10024fc0 : mflr r0 0x10024fc4 : mfcr r12 0x10024fc8 : stfd f14,576(r1) 0x10024fcc : stfd f15,584(r1) 0x10024fd0 : stfd f16,592(r1) 0x10024fd4 : stfd f17,600(r1) 0x10024fd8 : stfd f18,608(r1) 0x10024fdc : stfd f19,616(r1) 0x10024fe0 : stfd f20,624(r1) 0x10024fe4 : stfd f21,632(r1) 0x10024fe8 : stfd f22,640(r1) 0x10024fec : stfd f23,648(r1) 0x10024ff0 : stfd f24,656(r1) 0x10024ff4 : stfd f25,664(r1) 0x10024ff8 : stfd f26,672(r1) 0x10024ffc : stfd f27,680(r1) 0x10025000 : stfd f28,688(r1) 0x10025004 : stfd f29,696(r1) 0x10025008 : stfd f30,704(r1) 0x1002500c : stfd f31,712(r1) 0x10025010 : stw r14,504(r1) 0x10025014 : stw r15,508(r1) 0x10025018 : stw r16,512(r1) 0x1002501c : stw r17,516(r1) 0x10025020 : stw r18,520(r1) 0x10025024 : stw r19,524(r1) 0x10025028 : stw r20,528(r1) 0x1002502c : stw r21,532(r1) ---Type to continue, or q to quit--- 0x10025030 : stw r22,536(r1) 0x10025034 : stw r23,540(r1) 0x10025038 : stw r24,544(r1) 0x1002503c : stw r25,548(r1) 0x10025040 : stw r26,552(r1) 0x10025044 : stw r27,556(r1) 0x10025048 : stw r28,560(r1) 0x1002504c : stw r29,564(r1) 0x10025050 : stw r30,568(r1) 0x10025054 : stw r31,572(r1) 0x10025058 : stw r0,724(r1) 0x1002505c : stw r12,500(r1) 0x10025060 : mr r31,r1 0x10025064 : bl 0x10025068 0x10025068 : mflr r30 0x1002506c : lwz r0,-176(r30) 0x10025070 : add r30,r0,r30 0x10025074 : stw r3,8(r31) 0x10025078 : stw r4,12(r31) 0x1002507c : mr r0,r5 0x10025080 : stb r0,16(r31) 0x10025084 : li r0,0 0x10025088 : stw r0,20(r31) 0x1002508c : lbz r0,16(r31) 0x10025090 : clrlwi r0,r0,24 0x10025094 : cmpwi r0,0 0x10025098 : beq- 0x100250b8 0x1002509c : lwz r3,8(r31) 0x100250a0 : li r4,1 0x100250a4 : bl 0x100248a4 ---Type to continue, or q to quit--- 0x100250a8 : stw r3,476(r31) 0x100250ac : lwz r9,476(r31) 0x100250b0 : stw r9,20(r31) 0x100250b4 : b 0x100250d0 0x100250b8 : lwz r3,8(r31) 0x100250bc : li r4,1 0x100250c0 : bl 0x10024658 0x100250c4 : stw r3,476(r31) 0x100250c8 : lwz r9,476(r31) 0x100250cc : stw r9,20(r31) ** here I believe ** 0x100250d0 : lwz r0,-32760(r30) 0x100250d4 : stw r0,32(r31) 0x100250d8 : addi r0,r31,8 0x100250dc : stw r0,36(r31) 0x100250e0 : li r0,3 0x100250e4 : stw r0,28(r31) 0x100250e8 : lwz r9,-32764(r30) 0x100250ec : lwz r0,0(r9) 0x100250f0 : stw r0,24(r31) 0x100250f4 : lwz r9,-32764(r30) 0x100250f8 : addi r0,r31,24 0x100250fc : stw r0,0(r9) 0x10025100 : lwz r9,-32768(r30) 0x10025104 : addi r0,r9,76 0x10025108 : stw r0,64(r31) 0x1002510c : li r0,0 0x10025110 : stw r0,60(r31) 0x10025114 : lwz r9,-32764(r30) 0x10025118 : lwz r0,0(r9) 0x1002511c : stw r0,56(r31) ---Type to continue, or q to quit--- 0x10025120 : lwz r9,-32764(r30) 0x10025124 : addi r0,r31,56 0x10025128 : stw r0,0(r9) 0x1002512c : addi r9,r31,56 0x10025130 : addi r0,r9,48 0x10025134 : mr r3,r0 0x10025138 : bl 0x101bbf28 0x1002513c : mr r0,r3 0x10025140 : cmpwi r0,0 0x10025144 : bne- 0x100251ac 0x10025148 : lwz r9,12(r31) 0x1002514c : stw r9,476(r31) 0x10025150 : lwz r9,476(r31) 0x10025154 : cmpwi r9,0 0x10025158 : beq- 0x10025188 0x1002515c : lwz r9,476(r31) 0x10025160 : lwz r0,0(r9) 0x10025164 : li r9,-1 0x10025168 : cmpw r0,r9 0x1002516c : bne- 0x10025188 0x10025170 : lwz r9,476(r31) 0x10025174 : lwz r9,8(r9) 0x10025178 : stw r9,480(r31) 0x1002517c : lwz r9,476(r31) 0x10025180 : lwz r9,4(r9) 0x10025184 : stw r9,476(r31) 0x10025188 : lwz r11,480(r31) 0x1002518c : lwz r3,20(r31) 0x10025190 : lwz r0,476(r31) 0x10025194 : mtlr r0 ---Type to continue, or q to quit--- 0x10025198 : blrl 0x1002519c : lwz r9,-32764(r30) 0x100251a0 : lwz r0,56(r31) 0x100251a4 : stw r0,0(r9) 0x100251a8 : b 0x10025210 0x100251ac : lwz r9,68(r31) 0x100251b0 : lwz r9,0(r9) 0x100251b4 : lis r0,-15535 0x100251b8 : ori r0,r0,42454 0x100251bc : cmpw r9,r0 0x100251c0 : bne- 0x100251f0 0x100251c4 : lwz r0,72(r31) 0x100251c8 : stw r0,472(r31) 0x100251cc : lwz r9,-32768(r30) 0x100251d0 : addi r0,r9,180 0x100251d4 : lwz r3,472(r31) 0x100251d8 : mr r4,r0 0x100251dc : lwz r5,8(r31) 0x100251e0 : li r6,0 0x100251e4 : li r7,0 0x100251e8 : bl 0x10023b4c 0x100251ec : b 0x10025210 0x100251f0 : lwz r9,-32768(r30) 0x100251f4 : addi r0,r9,212 0x100251f8 : li r3,0 0x100251fc : mr r4,r0 0x10025200 : lwz r5,8(r31) 0x10025204 : li r6,0 0x10025208 : li r7,0 0x1002520c : bl 0x10023b4c ---Type to continue, or q to quit--- 0x10025210 : lwz r9,-32764(r30) 0x10025214 : lwz r0,24(r31) 0x10025218 : stw r0,0(r9) 0x1002521c : addi r11,r31,8 0x10025220 : bl 0x10024f74 0x10025224 : lwz r11,0(r1) 0x10025228 : lwz r0,4(r11) 0x1002522c : lwz r12,-220(r11) 0x10025230 : mtlr r0 0x10025234 : lwz r14,-216(r11) 0x10025238 : lwz r15,-212(r11) 0x1002523c : lwz r16,-208(r11) 0x10025240 : lwz r17,-204(r11) 0x10025244 : lwz r18,-200(r11) 0x10025248 : lwz r19,-196(r11) 0x1002524c : lwz r20,-192(r11) 0x10025250 : lwz r21,-188(r11) 0x10025254 : lwz r22,-184(r11) 0x10025258 : lwz r23,-180(r11) 0x1002525c : lwz r24,-176(r11) 0x10025260 : lwz r25,-172(r11) 0x10025264 : lwz r26,-168(r11) 0x10025268 : lwz r27,-164(r11) 0x1002526c : lwz r28,-160(r11) 0x10025270 : lwz r29,-156(r11) 0x10025274 : lwz r30,-152(r11) 0x10025278 : lwz r31,-148(r11) 0x1002527c : lfd f14,-144(r11) 0x10025280 : lfd f15,-136(r11) 0x10025284 : lfd f16,-128(r11) ---Type to continue, or q to quit--- 0x10025288 : lfd f17,-120(r11) 0x1002528c : lfd f18,-112(r11) 0x10025290 : lfd f19,-104(r11) 0x10025294 : lfd f20,-96(r11) 0x10025298 : lfd f21,-88(r11) 0x1002529c : lfd f22,-80(r11) 0x100252a0 : lfd f23,-72(r11) 0x100252a4 : lfd f24,-64(r11) 0x100252a8 : lfd f25,-56(r11) 0x100252ac : lfd f26,-48(r11) 0x100252b0 : lfd f27,-40(r11) 0x100252b4 : lfd f28,-32(r11) 0x100252b8 : lfd f29,-24(r11) 0x100252bc : lfd f30,-16(r11) 0x100252c0 : lfd f31,-8(r11) 0x100252c4 : mtcrf 56,r12 0x100252c8 : mr r1,r11 0x100252cc : blr 0x100252d0 : .long 0x24ebb0 End of assembler dump. (gdb) bt #0 Utils__WriteFile (M3_Bd56fi_file=0x10277ba0, M3_DmuccK_proc=0x7fb22210, M3_AicXUJ_append=0 '\0') at Utils.m3:78 #1 0x10020a10 in Makefile__Build (M3_Bd56fi_src_dir=0x102720ec) at Makefile.m3:101 #2 0x100292d4 in Main__DoIt () at Main.m3:71 #3 0x10029834 in Main_M3 (M3_AcxOUs_mode=1) at Main.m3:193 #4 0x10188f9c in RTLinker__RunMainBody (M3_DUuepq_m=0x10279b28) at RTLinker.m3:387 #5 0x101880bc in RTLinker__AddUnitI (M3_DUuepq_m=0x10279b28) at RTLinker.m3:100 #6 0x10188198 in RTLinker__AddUnit (M3_DUuepw_b=0x100297f8) at RTLinker.m3:110 #7 0x100002ec in main (argc=1, argv=0x7fb22834, envp=0x7fb2283c) at _m3main.mc:4 I haven't yet figured out how to get gdb to show me the details of the SEGV, like what address was referenced. I swear I think this was working better recently. Oh, I did change something. I will try to change it back. I added -fPIC. Dynamic linking was not working and I thought that might fix it. I'll definitely try without it now. Also, relevant aside -- what, if any, distributions/versions of Linux are people using on PowerPC? Specifically on PowerPC (to limit the religious explosion) I'm currently using Yellow Dog, I think 4.1, but only for Modula-3 purposes, not for anything else. ps: I'd like a SMALL forum of SMART programmers, to discuss GENERAL programming topics. This is it perhaps? - Jay _________________________________________________________________ Watch ?Cause Effect,? a show about real people making a real difference. http://im.live.com/Messenger/IM/MTV/?source=text_watchcause From jayk123 at hotmail.com Thu Jan 10 10:28:31 2008 From: jayk123 at hotmail.com (Jay) Date: Thu, 10 Jan 2008 09:28:31 +0000 Subject: [M3devel] FW: bad code on PPC_LINUX? Message-ID: My emails keep getting truncated for some reason.. :( > From: jayk123 at hotmail.com > To: m3devel at elegosoft.com > Subject: bad code on PPC_LINUX? > Date: Thu, 10 Jan 2008 07:11:11 +0000 > > > Something is screwy I think. > My gdb skills are um not good. > > On PPC_LINUX. > > /dev2/cm3/m3-sys/cm3/src/Utils.m3 > > PROCEDURE WriteFile (file: TEXT; proc: Emitter; append := FALSE) = > VAR wr: Wr.T; > BEGIN > IF (append) > THEN wr := AppendWriter (file, fatal := TRUE); > ELSE wr := OpenWriter (file, fatal := TRUE); > END; > TRY (* line 78 *) > TRY > proc (wr); > EXCEPT > | Wr.Failure (ec) => > Msg.FatalError (ec, "write failed on ", file); > | Thread.Alerted => > Msg.FatalError (NIL, "interrupted while writing ", file); > END; > FINALLY > CloseWriter (wr, file); > END; > END WriteFile; > > I get a SEGV on line 78. > > I'm willing to believe, sadly, that some of these huge offsets > are the price of TRY and saving the register context on anything > other than x86 (for registers that aren't even used by the function?), > however it crashes just after the call and notice there the huge 32k offset. > > And really? A 720 byte frame for any function with a TRY on PowerPC? > Really? > I guess I should look at what PPC_DARWIN does. > > If someone can give me a quick run down on PowerPC ABI, thanks. > I'll search the web. Or maybe check my Mac docs. > register 0 is 0 or general purpose? > Stack is register ? > I know that return address is in the link register. > bl is branch and link -- call -- jump and save pc in link register. > > The code is: > (gdb) disassemble > Dump of assembler code for function Utils__WriteFile: > 0x10024fbc : stwu r1,-720(r1) > 0x10024fc0 : mflr r0 > 0x10024fc4 : mfcr r12 > 0x10024fc8 : stfd f14,576(r1) > 0x10024fcc : stfd f15,584(r1) > 0x10024fd0 : stfd f16,592(r1) > 0x10024fd4 : stfd f17,600(r1) > 0x10024fd8 : stfd f18,608(r1) > 0x10024fdc : stfd f19,616(r1) > 0x10024fe0 : stfd f20,624(r1) > 0x10024fe4 : stfd f21,632(r1) > 0x10024fe8 : stfd f22,640(r1) > 0x10024fec : stfd f23,648(r1) > 0x10024ff0 : stfd f24,656(r1) > 0x10024ff4 : stfd f25,664(r1) > 0x10024ff8 : stfd f26,672(r1) > 0x10024ffc : stfd f27,680(r1) > 0x10025000 : stfd f28,688(r1) > 0x10025004 : stfd f29,696(r1) > 0x10025008 : stfd f30,704(r1) > 0x1002500c : stfd f31,712(r1) > 0x10025010 : stw r14,504(r1) > 0x10025014 : stw r15,508(r1) > 0x10025018 : stw r16,512(r1) > 0x1002501c : stw r17,516(r1) > 0x10025020 : stw r18,520(r1) > 0x10025024 : stw r19,524(r1) > 0x10025028 : stw r20,528(r1) > 0x1002502c : stw r21,532(r1) > ---Type to continue, or q to quit--- > 0x10025030 : stw r22,536(r1) > 0x10025034 : stw r23,540(r1) > 0x10025038 : stw r24,544(r1) > 0x1002503c : stw r25,548(r1) > 0x10025040 : stw r26,552(r1) > 0x10025044 : stw r27,556(r1) > 0x10025048 : stw r28,560(r1) > 0x1002504c : stw r29,564(r1) > 0x10025050 : stw r30,568(r1) > 0x10025054 : stw r31,572(r1) > 0x10025058 : stw r0,724(r1) > 0x1002505c : stw r12,500(r1) > 0x10025060 : mr r31,r1 > 0x10025064 : bl 0x10025068 > 0x10025068 : mflr r30 > 0x1002506c : lwz r0,-176(r30) > 0x10025070 : add r30,r0,r30 > 0x10025074 : stw r3,8(r31) > 0x10025078 : stw r4,12(r31) > 0x1002507c : mr r0,r5 > 0x10025080 : stb r0,16(r31) > 0x10025084 : li r0,0 > 0x10025088 : stw r0,20(r31) > 0x1002508c : lbz r0,16(r31) > 0x10025090 : clrlwi r0,r0,24 > 0x10025094 : cmpwi r0,0 > 0x10025098 : beq- 0x100250b8 > 0x1002509c : lwz r3,8(r31) > 0x100250a0 : li r4,1 > 0x100250a4 : bl 0x100248a4 > ---Type to continue, or q to quit--- > 0x100250a8 : stw r3,476(r31) > 0x100250ac : lwz r9,476(r31) > 0x100250b0 : stw r9,20(r31) > 0x100250b4 : b 0x100250d0 > 0x100250b8 : lwz r3,8(r31) > 0x100250bc : li r4,1 > 0x100250c0 : bl 0x10024658 > 0x100250c4 : stw r3,476(r31) > 0x100250c8 : lwz r9,476(r31) > 0x100250cc : stw r9,20(r31) > > ** here I believe ** > > 0x100250d0 : lwz r0,-32760(r30) > 0x100250d4 : stw r0,32(r31) > 0x100250d8 : addi r0,r31,8 > 0x100250dc : stw r0,36(r31) > 0x100250e0 : li r0,3 > 0x100250e4 : stw r0,28(r31) > 0x100250e8 : lwz r9,-32764(r30) > 0x100250ec : lwz r0,0(r9) > 0x100250f0 : stw r0,24(r31) > 0x100250f4 : lwz r9,-32764(r30) > 0x100250f8 : addi r0,r31,24 > 0x100250fc : stw r0,0(r9) > 0x10025100 : lwz r9,-32768(r30) > 0x10025104 : addi r0,r9,76 > 0x10025108 : stw r0,64(r31) > 0x1002510c : li r0,0 > 0x10025110 : stw r0,60(r31) > 0x10025114 : lwz r9,-32764(r30) > 0x10025118 : lwz r0,0(r9) > 0x1002511c : stw r0,56(r31) > ---Type to continue, or q to quit--- > 0x10025120 : lwz r9,-32764(r30) > 0x10025124 : addi r0,r31,56 > 0x10025128 : stw r0,0(r9) > 0x1002512c : addi r9,r31,56 > 0x10025130 : addi r0,r9,48 > 0x10025134 : mr r3,r0 > 0x10025138 : bl 0x101bbf28 > 0x1002513c : mr r0,r3 > 0x10025140 : cmpwi r0,0 > 0x10025144 : bne- 0x100251ac > 0x10025148 : lwz r9,12(r31) > 0x1002514c : stw r9,476(r31) > 0x10025150 : lwz r9,476(r31) > 0x10025154 : cmpwi r9,0 > 0x10025158 : beq- 0x10025188 > 0x1002515c : lwz r9,476(r31) > 0x10025160 : lwz r0,0(r9) > 0x10025164 : li r9,-1 > 0x10025168 : cmpw r0,r9 > 0x1002516c : bne- 0x10025188 > 0x10025170 : lwz r9,476(r31) > 0x10025174 : lwz r9,8(r9) > 0x10025178 : stw r9,480(r31) > 0x1002517c : lwz r9,476(r31) > 0x10025180 : lwz r9,4(r9) > 0x10025184 : stw r9,476(r31) > 0x10025188 : lwz r11,480(r31) > 0x1002518c : lwz r3,20(r31) > 0x10025190 : lwz r0,476(r31) > 0x10025194 : mtlr r0 > ---Type to continue, or q to quit--- > 0x10025198 : blrl > 0x1002519c : lwz r9,-32764(r30) > 0x100251a0 : lwz r0,56(r31) > 0x100251a4 : stw r0,0(r9) > 0x100251a8 : b 0x10025210 > 0x100251ac : lwz r9,68(r31) > 0x100251b0 : lwz r9,0(r9) > 0x100251b4 : lis r0,-15535 > 0x100251b8 : ori r0,r0,42454 > 0x100251bc : cmpw r9,r0 > 0x100251c0 : bne- 0x100251f0 > 0x100251c4 : lwz r0,72(r31) > 0x100251c8 : stw r0,472(r31) > 0x100251cc : lwz r9,-32768(r30) > 0x100251d0 : addi r0,r9,180 > 0x100251d4 : lwz r3,472(r31) > 0x100251d8 : mr r4,r0 > 0x100251dc : lwz r5,8(r31) > 0x100251e0 : li r6,0 > 0x100251e4 : li r7,0 > 0x100251e8 : bl 0x10023b4c > 0x100251ec : b 0x10025210 > 0x100251f0 : lwz r9,-32768(r30) > 0x100251f4 : addi r0,r9,212 > 0x100251f8 : li r3,0 > 0x100251fc : mr r4,r0 > 0x10025200 : lwz r5,8(r31) > 0x10025204 : li r6,0 > 0x10025208 : li r7,0 > 0x1002520c : bl 0x10023b4c > ---Type to continue, or q to quit--- > 0x10025210 : lwz r9,-32764(r30) > 0x10025214 : lwz r0,24(r31) > 0x10025218 : stw r0,0(r9) > 0x1002521c : addi r11,r31,8 > 0x10025220 : bl 0x10024f74 > 0x10025224 : lwz r11,0(r1) > 0x10025228 : lwz r0,4(r11) > 0x1002522c : lwz r12,-220(r11) > 0x10025230 : mtlr r0 > 0x10025234 : lwz r14,-216(r11) > 0x10025238 : lwz r15,-212(r11) > 0x1002523c : lwz r16,-208(r11) > 0x10025240 : lwz r17,-204(r11) > 0x10025244 : lwz r18,-200(r11) > 0x10025248 : lwz r19,-196(r11) > 0x1002524c : lwz r20,-192(r11) > 0x10025250 : lwz r21,-188(r11) > 0x10025254 : lwz r22,-184(r11) > 0x10025258 : lwz r23,-180(r11) > 0x1002525c : lwz r24,-176(r11) > 0x10025260 : lwz r25,-172(r11) > 0x10025264 : lwz r26,-168(r11) > 0x10025268 : lwz r27,-164(r11) > 0x1002526c : lwz r28,-160(r11) > 0x10025270 : lwz r29,-156(r11) > 0x10025274 : lwz r30,-152(r11) > 0x10025278 : lwz r31,-148(r11) > 0x1002527c : lfd f14,-144(r11) > 0x10025280 : lfd f15,-136(r11) > 0x10025284 : lfd f16,-128(r11) > ---Type to continue, or q to quit--- > 0x10025288 : lfd f17,-120(r11) > 0x1002528c : lfd f18,-112(r11) > 0x10025290 : lfd f19,-104(r11) > 0x10025294 : lfd f20,-96(r11) > 0x10025298 : lfd f21,-88(r11) > 0x1002529c : lfd f22,-80(r11) > 0x100252a0 : lfd f23,-72(r11) > 0x100252a4 : lfd f24,-64(r11) > 0x100252a8 : lfd f25,-56(r11) > 0x100252ac : lfd f26,-48(r11) > 0x100252b0 : lfd f27,-40(r11) > 0x100252b4 : lfd f28,-32(r11) > 0x100252b8 : lfd f29,-24(r11) > 0x100252bc : lfd f30,-16(r11) > 0x100252c0 : lfd f31,-8(r11) > 0x100252c4 : mtcrf 56,r12 > 0x100252c8 : mr r1,r11 > 0x100252cc : blr > 0x100252d0 : .long 0x24ebb0 > End of assembler dump. > > > (gdb) bt > #0 Utils__WriteFile (M3_Bd56fi_file=0x10277ba0, M3_DmuccK_proc=0x7fb22210, > M3_AicXUJ_append=0 '\0') at Utils.m3:78 > #1 0x10020a10 in Makefile__Build (M3_Bd56fi_src_dir=0x102720ec) > at Makefile.m3:101 > #2 0x100292d4 in Main__DoIt () at Main.m3:71 > #3 0x10029834 in Main_M3 (M3_AcxOUs_mode=1) at Main.m3:193 > #4 0x10188f9c in RTLinker__RunMainBody (M3_DUuepq_m=0x10279b28) > at RTLinker.m3:387 > #5 0x101880bc in RTLinker__AddUnitI (M3_DUuepq_m=0x10279b28) at RTLinker.m3:100 > #6 0x10188198 in RTLinker__AddUnit (M3_DUuepw_b=0x100297f8) at RTLinker.m3:110 > #7 0x100002ec in main (argc=1, argv=0x7fb22834, envp=0x7fb2283c) at _m3main.mc:4 > > I haven't yet figured out how to get gdb to show me the details of the SEGV, like what address was referenced. > > I swear I think this was working better recently. > > Oh, I did change something. I will try to change it back. > I added -fPIC. > Dynamic linking was not working and I thought that might fix it. > I'll definitely try without it now. > > Also, relevant aside -- what, if any, distributions/versions of Linux are people using on PowerPC? > Specifically on PowerPC (to limit the religious explosion) > I'm currently using Yellow Dog, I think 4.1, but only for Modula-3 purposes, not for anything else. > > ps: I'd like a SMALL forum of SMART programmers, to discuss GENERAL programming topics. > This is it perhaps? > > - Jay > _________________________________________________________________ > Watch ?Cause Effect,? a show about real people making a real difference. > http://im.live.com/Messenger/IM/MTV/?source=text_watchcause _________________________________________________________________ Make distant family not so distant with Windows Vista? + Windows Live?. http://www.microsoft.com/windows/digitallife/keepintouch.mspx?ocid=TXT_TAGLM_CPC_VideoChat_distantfamily_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Thu Jan 10 12:16:36 2008 From: jayk123 at hotmail.com (Jay) Date: Thu, 10 Jan 2008 11:16:36 +0000 Subject: [M3devel] nt386gnu is posix or win32? In-Reply-To: <200801100131.m0A1VQYS034516@camembert.async.caltech.edu> References: Your message of "Wed, 09 Jan 2008 17:25:31 PST." <200801100131.m0A1VQYS034516@camembert.async.caltech.edu> Message-ID: clarification/additional info Whatever MinGWin I have installed, is via the GPL Qt download. I did not realize MinGWin had the "MSYS" component -- sh, make, etc., enough for autoconf. Enough for gcc? http://www.mingw.org/mingwfaq.shtml#faq-usingwithmsys "How do I use MinGW with Cygwin?For those who would like to use the Cygwin environment for development, yet generatenon-Cygwin-dependant executables, a much easier option to "-mno-cygwin" does exist.Simply install Cygwin and the MinGW distribution in seperate directories (i.e. "C:\CYGWIN"and "C:\MINGW"), and make sure that the "/bin" subdirectory beneath your MinGW installationcomes before Cygwin's "/bin" subdirectory in your PATH environment variable(i.e. "PATH=%PATH%;C:\MINGW\BIN;C:\CYGWIN\BIN"). This will allow you accessto all the UNIX tools you want, while ensuring that the instance of GCC used is the MinGW version." Sounds good.So a possibly good easy answer is just one target -- "NT386GNU" configured probably always as I have it currently -- Win32 threads maybe a cm3 command line define, like -DPTHREAD to use pthreads, will require a tiny bit of work heck, maybe -DUSERTHREAD (and for other systems?) jmpbuf asis -- 0xd0 and will work linked either way. Whether or not mingw works alone, is to be determined.It probably does if not building m3cc, and it may very well even for building m3cc. Among those goals: (a) runs decently fast on Windows (b) looks as much as possible like Unix (also from the user point of view) (c) requires minimal code changes These are related and to some extent help each other, and to some extentare independent. In particular, the theory is, you get #c without requiring #b.Regarding #a, well, it's a question of one or two layers.Modula-3 already provides in many places, but certainly not all, a portability layer.And then another cygwin/posix portability layer? Maybe.These aren't necessarily thick layers and if your code is i/o bound anyway, doesn't matter. (While I'm sure it wasn't intended, "runs fast" can be interpreted as "fast to get it to run",as in ease of development/porting. :) ) Anyway, it seems like both camps (all camps?) can be satisfied. By "serious" I mean, "ship real software using it".Oh and the reference to "toolchains" was dodgy.Already Modula-3 on Windows involves an unusual codegenerator, though still a "normal" linker. - Jay..waiting for m3cc to build again as part of upgrade.sh...(my excuse for wasting time in email..) > To: darko at darko.org> Date: Wed, 9 Jan 2008 17:31:25 -0800> From: mika at async.caltech.edu> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] nt386gnu is posix or win32?> > > In this vein, I can tell you I am a frequent user of Modula-3 on Windows.> I use PM3/Klagenfurt on a Win 2003 Server system, and occasionally on XP and> Win2k.> > I use it this way because while I develop on Unix, I have users who insist on> using Windows for their servers. What matters to me is that I can get an> environment that> > (a) runs decently fast on Windows> (b) looks as much as possible like Unix (also from the user point of view)> (c) requires minimal code changes> > The combination of Cygwin and M3 takes care of this, more or less... It's> also an easy download/install.> > Mika> > > Darko writes:> >> >On 09/01/2008, at 5:02 PM, hendrik at topoi.pooq.com wrote:> >>> >> One of my reasons for using m3 long ago was that I could write > >> programs> >> that would run on both Linux and Windows *without* using the Microsoft> >> tools, which I did not possess.> >>> >> -- hendrik> >> >> >There are free versions of the tools these days, if that makes any > >difference.> >> >Darko. _________________________________________________________________ Put your friends on the big screen with Windows Vista? + Windows Live?. http://www.microsoft.com/windows/shop/specialoffers.mspx?ocid=TXT_TAGLM_CPC_MediaCtr_bigscreen_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Thu Jan 10 12:20:20 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 10 Jan 2008 12:20:20 +0100 Subject: [M3devel] (Offtopic) Some comments on SCM tools, was: Re: M3 concerns In-Reply-To: <20080105191243.GB6402@topoi.pooq.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> <20080105191243.GB6402@topoi.pooq.com> Message-ID: <20080110122020.zm4wc29e8044c0kw@mail.elegosoft.com> Quoting hendrik at topoi.pooq.com: > But if you have this experience, it would be useful to see a rundown > of the advantages and disadvantages of each. I've seen a table of > features against version control systems, but it doesn't give any feel > for what it's like to use them. > > Such an essay would be useful for those involved in other projects. It > probably won't help Modula 3 itself. That would easily become an open-ended task :-) It is not easy to compare different complex tools like SCM systems, which interact in various degrees with process control, workflow management, problem management, project management, general policies... We've tried to provide feature-oriented comparison lists some years ago, but even this needs too much efforts and is too fast out-of-date. There are some aspects that may currently be helpful as criterions though. I'd like to mention some of them o Traditionally, version control tools were centralized server systems. There is one central repository (which can in advanced setups be replicated to several sites for many systems. Replicas may even be partly writable. In case of replication there is one `logical' central repository which is physically distributed.). Systems in this group are CVS, ClearCase, PVCS, AccuRev, Perforce, Subversion, and many others. In recent years, peer-to-peer systems have become popular, because they correspond better to certain aspects of open software projects and are inherently distributed. There is no distinction between workspace and repository, and each workspace holds a partial or complete change history. Such systems are BitKeeper, git, Darcs, and others. As far as I know, these systems are not very popular in the commercial world (yet?). o An orthogonal criterion is the range of functionality that is addressed with the solution. Simple systems like CVS and Perforce do just version control and offer some hooks for further integration. On the other side are process-oriented systems like PVCS Dimensions or a complete ClearCase/ClearQuest setup for RUP. These systems are rather based on change management und workflow than on developer needs. Basic abstractions are baselines, changesets, tasks, projects, activities, functional roles. Of course, some tools are somewhere in between these extremes, like AccuRev, which supports kinds of long-running transactions for everything, called `streams'. (This one's very nice IMO.) o Then there are the costs of the use of the systems. There are always costs, even for open source solutions. You have to consider - server costs (hardware, energy, OS, database, licences, networks) - administration and maintenance (servers and user setup) - user license costs (from 0 to several thousand dollars per year) - use overhead (depending on tool usability and process) - instruction and training Again there are systems that are rather lightweight in this respect (like CVS and Perforce) and some tending to be more heavyweight (like ClearCase and PVCS). o The `end user experience' corresponds very much to the basic concepts needed in everyday use. File based ci/co is very simple, development lines are more or less a must have, change sets and baselines (like in DCVS, AccuRev or RUP) are very nice; diffs and merges seem to be too complex for many users (but are of course needed); conflict avoidance vs. conflict resolution (locking or optimistic approach) is often a religiously discussed topic. The other important issue here is the IDE integration (at least for developers). These are only some randomly picked topics that would need to be addressed in a useful tool comparison. There are very few situations in which you can evaluate and choose the best tool for your purpose; most of the time, you have to adapt and improve existing setups, as everything else would be too expensive and disrupting. Our company has supported several migration projects recently though, so it's not impossible to change ;-) As for CM3, I'm still of the opinion that there is no need to change the existing CVS infrastructure. > Or might you know of such an essay elsewhere? Well, the more interesting field studies and evaluations are not free; there are quite a lot of interesting articles though. I haven't any links here right now; CM crossroads or a Google search on `configuration management' should be a good starting point. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Jan 10 12:24:20 2008 From: jayk123 at hotmail.com (Jay) Date: Thu, 10 Jan 2008 11:24:20 +0000 Subject: [M3devel] win32 path separators -- support forward and backward in libm3? In-Reply-To: <200801100131.m0A1VQYS034516@camembert.async.caltech.edu> References: Your message of "Wed, 09 Jan 2008 17:25:31 PST." <200801100131.m0A1VQYS034516@camembert.async.caltech.edu> Message-ID: To a very large extent, Win32 accepts both / and \ equally as path delimiters. CreateFile, DeleteFile, CreateDirectory, MoveFile, CopyFile, FindFirstFile, GetFileAttributes, the C runtime wrappers fopen, unlink/remove, stat, etc., those all work either way, or with a mix. "Shell" functions like shlwapi.dll, commdlg32.dll, tend not to. In building NT386GNU, I run into places where cm3 is picking apart paths. For whatever reason, it is being given paths with a mix of forward and backward slashes. I find these paths ugly, but they work ok. I've been able to easily progress by changing m3-libs/libm3/src/os/WIN32/PathnameWin32.m3 to treat forward and backslashes the same. I have not yet rebuilt the normal NT386 target with this change. An ok change? Or go and fix NT386GNU a) to be consistent, b) use backward slashes, c) translate at some place. ? C:\dev2\cm3.2\m3-libs\libm3>cvs diffIndex: src/os/WIN32/PathnameWin32.m3===================================================================RCS file: /usr/cvs/cm3/m3-libs/libm3/src/os/WIN32/PathnameWin32.m3,vretrieving revision 1.3diff -r1.3 PathnameWin32.m313c13< DirSepChar = '\\'; DirSepText = "\\";---> DirSepText = "\\";17c17< CONST Legal = SET OF CHAR {'\001' .. '\177'} - SET OF CHAR {DirSepChar, ':'};---> CONST Legal = SET OF CHAR {'\001' .. '\177'} - SET OF CHAR {'\\', '/', ':', '?', '*'};21a22,26> PROCEDURE IsDirSepChar(ch: CHAR): BOOLEAN => BEGIN> RETURN (ch = '\\' OR ch = '/');> END IsDirSepChar;>53,54c58,59< IF Text.GetChar(t, 0) = DirSepChar AND< Text.GetChar(t, nRoot - 1) # DirSepChar THEN---> IF IsDirSepChar(Text.GetChar(t, 0)) AND> NOT IsDirSepChar(Text.GetChar(t, nRoot - 1)) THEN125c130< IF c # DirSepChar AND c # DriveSepChar THEN---> IF NOT IsDirSepChar(c) AND c # DriveSepChar THEN173,174c178,179< IF c = DirSepChar THEN< IF n = 1 OR Text.GetChar(t, 1) # DirSepChar THEN RETURN 1 END;---> IF IsDirSepChar(c) THEN> IF n = 1 OR NOT IsDirSepChar(Text.GetChar(t, 1)) THEN RETURN 1 END;178c183< IF cc = DirSepChar THEN---> IF IsDirSepChar(cc) THEN196c201< IF n > 2 AND Text.GetChar(t, 2) = DirSepChar THEN RETURN 3 END;---> IF n > 2 AND IsDirSepChar(Text.GetChar(t, 2)) THEN RETURN 3 END;218c223< IF c = DirSepChar THEN---> IF IsDirSepChar(c) THEN253c258< IF ch = DirSepChar OR ch = DriveSepChar THEN---> IF IsDirSepChar(ch) OR ch = DriveSepChar THEN - Jay _________________________________________________________________ Put your friends on the big screen with Windows Vista? + Windows Live?. http://www.microsoft.com/windows/shop/specialoffers.mspx?ocid=TXT_TAGLM_CPC_MediaCtr_bigscreen_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.caltech.edu Thu Jan 10 12:34:47 2008 From: mika at async.caltech.edu (Mika Nystrom) Date: Thu, 10 Jan 2008 03:34:47 -0800 Subject: [M3devel] win32 path separators -- support forward and backward in libm3? In-Reply-To: Your message of "Thu, 10 Jan 2008 11:24:20 GMT." Message-ID: <200801101134.m0ABYl2I053123@camembert.async.caltech.edu> With Cygwin, I think it's pretty much inevitable that you're going to get a mixture of / and \.... (and sometimes it's a real pain, yes). For your "edification", I include the file "README.CYGWIN" that I keep at the root of my software repository... I'm sure this doesn't all apply to CM3, but it's what I deal with to get things running with the Klagenfurt compiler... 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. From jayk123 at hotmail.com Thu Jan 10 13:40:22 2008 From: jayk123 at hotmail.com (Jay) Date: Thu, 10 Jan 2008 12:40:22 +0000 Subject: [M3devel] could someone add __stdcall name mangling to m3cc please? In-Reply-To: <200801100131.m0A1VQYS034516@camembert.async.caltech.edu> References: Your message of "Wed, 09 Jan 2008 17:25:31 PST." <200801100131.m0A1VQYS034516@camembert.async.caltech.edu> Message-ID: Could someone out there (Tony?) familiar with the gcc backendhave it not ignore call_conv and if call_conv is 1, appendan at symbol and the number of bytes of parameters to the function name? (Even for zero, e.g. Sleep at 0, GetFileAttributes at 4).This would be I guess at least for "imported" functions. Not clear about calling function pointers, probably needs modification.call_conv 0 is "__cdecl" is push right to left, caller cleans upcall_conv 1 is "__stdcall" is push right to left, callee cleans up There are various synonyms. With no command line switches, __cdecl is the compiler default. __stdcall is deemed more efficient, and is very widely used. Not clear about functions implemented in Modula-3.Probably won't occur? Maybe for callbacks? WindowProcs, thread entry point? This could/should be for NT386GNU only.The hypothetical other NT targets only have one calling convention each. I COULD do something sleazy here and generate little adapter functions, over in m3-win/import-libs esp. I'm still checking out pm3 to see what it does here.(as in cvs checkout, not "looking at") This'll clear up: RTOS.m3:27: undefined reference to `_FatalExit'RTOS.mo: In function `RTOS__GetMemory':RTOS.m3:75: undefined reference to `_VirtualAlloc'RTOS.m3:85: undefined reference to `_VirtualAlloc'RTOS.mo: In function `RTOS__InitMemory':RTOS.m3:96: undefined reference to `_VirtualAlloc'RTOS.m3:100: undefined reference to `_GetSystemInfo'RTOS.mo: In function `RTOS__Write':RTOS.m3:118: undefined reference to `_AllocConsole'RTOS.m3:119: undefined reference to `_GetStdHandle'RTOS.m3:122: undefined reference to `_WriteFile'RTPerfTool.mo: In function `RTPerfTool__Start':RTPerfTool.m3:19: undefined reference to `_ReadFile'RTPerfTool.m3:22: undefined reference to `_CloseHandle'RTPerfTool.mo: In function `RTPerfTool__Close':RTPerfTool.m3:28: undefined reference to `_CloseHandle'RTPerfTool.mo: In function `RTPerfTool__Send':RTPerfTool.m3:34: undefined reference to `_WriteFile'RTPerfTool.mo: In function `RTPerfTool__PrepHandle':RTPerfTool.m3:58: undefined reference to `_GetCurrentProcess'RTPerfTool.m3:59: undefined reference to `_DuplicateHandle'etc. I did think I was past these. I thought I built m3core and libm3 including linking (having even modified cm3.cfg)COULD be I'm using the wrong .libs, but: C:\cygwin\lib\w32api>nm libkernel32.a | findstr CreateFile00000000 I __imp__CreateFileW at 2800000000 T _CreateFileW at 2800000000 I __imp__CreateFileMappingW at 2400000000 T _CreateFileMappingW at 2400000000 I __imp__CreateFileMappingA at 2400000000 T _CreateFileMappingA at 2400000000 I __imp__CreateFileA at 2800000000 T _CreateFileA at 28 C:\cygwin\lib\w32api>cd \MinGW\lib C:\MinGW\lib>nm libkernel32.a | findstr CreateFile00000000 I __imp__CreateFileW at 2800000000 T _CreateFileW at 2800000000 I __imp__CreateFileMappingW at 2400000000 T _CreateFileMappingW at 2400000000 I __imp__CreateFileMappingA at 2400000000 T _CreateFileMappingA at 2400000000 I __imp__CreateFileA at 2800000000 T _CreateFileA at 28 I think at least THREE calling conventions should be supported -- __cdecl, __stdcall, __fastcall --but oh well. We can live without __fastcall.Watcom has another calling convention, "watcall", and they let you describe calling conventions with #pragmas, neat. Thanks, - Jay _________________________________________________________________ Share life as it happens with the new Windows Live. http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Thu Jan 10 13:42:58 2008 From: jayk123 at hotmail.com (Jay) Date: Thu, 10 Jan 2008 12:42:58 +0000 Subject: [M3devel] could someone add __stdcall name mangling to m3cc please? In-Reply-To: References: Your message of "Wed, 09 Jan 2008 17:25:31 PST." <200801100131.m0A1VQYS034516@camembert.async.caltech.edu> Message-ID: PM3 appears to ignore call_conv. Perhaps its NT386GNU uses usermode threads via cygwin1.dll and has no gui support, such as to not import any __stdcall functions??? http://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/m3/pm3/language/modula3/m3compiler/m3cc/gcc/gcc/m3cg/m3.c?rev=1.1;content-type=text%2Fx-cvsweb-markup;cvsroot=PM3 - Jay From: jayk123 at hotmail.comTo: m3devel at elegosoft.comDate: Thu, 10 Jan 2008 12:40:22 +0000Subject: [M3devel] could someone add __stdcall name mangling to m3cc please? Could someone out there (Tony?) familiar with the gcc backendhave it not ignore call_conv and if call_conv is 1, appendan at symbol and the number of bytes of parameters to the function name? (Even for zero, e.g. Sleep at 0, GetFileAttributes at 4).This would be I guess at least for "imported" functions.Not clear about calling function pointers, probably needs modification.call_conv 0 is "__cdecl" is push right to left, caller cleans upcall_conv 1 is "__stdcall" is push right to left, callee cleans up There are various synonyms. With no command line switches, __cdecl is the compiler default. __stdcall is deemed more efficient, and is very widely used.Not clear about functions implemented in Modula-3.Probably won't occur? Maybe for callbacks? WindowProcs, thread entry point?This could/should be for NT386GNU only.The hypothetical other NT targets only have one calling convention each.I COULD do something sleazy here and generate little adapter functions, over in m3-win/import-libs esp.I'm still checking out pm3 to see what it does here.(as in cvs checkout, not "looking at")This'll clear up:RTOS.m3:27: undefined reference to `_FatalExit'RTOS.mo: In function `RTOS__GetMemory':RTOS.m3:75: undefined reference to `_VirtualAlloc'RTOS.m3:85: undefined reference to `_VirtualAlloc'RTOS.mo: In function `RTOS__InitMemory':RTOS.m3:96: undefined reference to `_VirtualAlloc'RTOS.m3:100: undefined reference to `_GetSystemInfo'RTOS.mo: In function `RTOS__Write':RTOS.m3:118: undefined reference to `_AllocConsole'RTOS.m3:119: undefined reference to `_GetStdHandle'RTOS.m3:122: undefined reference to `_WriteFile'RTPerfTool.mo: In function `RTPerfTool__Start':RTPerfTool.m3:19: undefined reference to `_ReadFile'RTPerfTool.m3:22: undefined reference to `_CloseHandle'RTPerfTool.mo: In function `RTPerfTool__Close':RTPerfTool.m3:28: undefined reference to `_CloseHandle'RTPerfTool.mo: In function `RTPerfTool__Send':RTPerfTool.m3:34: undefined reference to `_WriteFile'RTPerfTool.mo: In function `RTPerfTool__PrepHandle':RTPerfTool.m3:58: undefined reference to `_GetCurrentProcess'RTPerfTool.m3:59: undefined reference to `_DuplicateHandle'etc.I did think I was past these. I thought I built m3core and libm3 including linking (having even modified cm3.cfg)COULD be I'm using the wrong .libs, but:C:\cygwin\lib\w32api>nm libkernel32.a | findstr CreateFile00000000 I __imp__CreateFileW at 2800000000 T _CreateFileW at 2800000000 I __imp__CreateFileMappingW at 2400000000 T _CreateFileMappingW at 2400000000 I __imp__CreateFileMappingA at 2400000000 T _CreateFileMappingA at 2400000000 I __imp__CreateFileA at 2800000000 T _CreateFileA at 28C:\cygwin\lib\w32api>cd \MinGW\libC:\MinGW\lib>nm libkernel32.a | findstr CreateFile00000000 I __imp__CreateFileW at 2800000000 T _CreateFileW at 2800000000 I __imp__CreateFileMappingW at 2400000000 T _CreateFileMappingW at 2400000000 I __imp__CreateFileMappingA at 2400000000 T _CreateFileMappingA at 2400000000 I __imp__CreateFileA at 2800000000 T _CreateFileA at 28 I think at least THREE calling conventions should be supported -- __cdecl, __stdcall, __fastcall --but oh well. We can live without __fastcall.Watcom has another calling convention, "watcall", and they let you describe calling conventions with #pragmas, neat.Thanks, - Jay Share life as it happens with the new Windows Live. Start sharing! _________________________________________________________________ Get the power of Windows + Web with the new Windows Live. http://www.windowslive.com?ocid=TXT_TAGHM_Wave2_powerofwindows_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Thu Jan 10 13:58:50 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 10 Jan 2008 13:58:50 +0100 Subject: [M3devel] win32 path separators -- support forward and backward in libm3? In-Reply-To: References: Your message of "Wed, 09 Jan 2008 17:25:31 PST." <200801100131.m0A1VQYS034516@camembert.async.caltech.edu> Message-ID: <20080110135850.g34emuxds0ogwwk4@mail.elegosoft.com> Quoting Jay : > To a very large extent, Win32 accepts both / and \ equally as path > delimiters. > CreateFile, DeleteFile, CreateDirectory, MoveFile, CopyFile, > FindFirstFile, GetFileAttributes, the C runtime wrappers fopen, > unlink/remove, stat, etc., those all work either way, or with a mix. > "Shell" functions like shlwapi.dll, commdlg32.dll, tend not to. > > In building NT386GNU, I run into places where cm3 is picking apart paths. > For whatever reason, it is being given paths with a mix of forward > and backward slashes. > I find these paths ugly, but they work ok. > > I've been able to easily progress by changing > m3-libs/libm3/src/os/WIN32/PathnameWin32.m3 to treat forward and > backslashes the same. > I have not yet rebuilt the normal NT386 target with this change. > > An ok change? > > Or go and fix NT386GNU a) to be consistent, b) use backward slashes, > c) translate at some place. > > ? In my opininion NT386GNU should be a POSIX target and thus use forward slashes as standard as POSIX defines. Offhand I wouldn't object to accept backward slashes as path delimiters, too. But you must heed that \ is used as an escape character almost everywhere (and so should it be in pathname denotations then: a\\b\\c) or you loose much compatibility. I still wonder if the decision to use \ on DOS/Windows was only made to be as incompatible as possible with Unix... Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Jan 10 14:11:33 2008 From: jayk123 at hotmail.com (Jay) Date: Thu, 10 Jan 2008 13:11:33 +0000 Subject: [M3devel] FW: bad code on PPC_LINUX? In-Reply-To: References: Message-ID: Removing -fPIC seems to fix this, though the code still stinks and the frame is still huge (700+ bytes). Even with -O, even without -gstabs (adding/removing -gstabs shouldn't matter but I tried anyway) - Jay ________________________________ > From: jayk123 at hotmail.com > To: m3devel at elegosoft.com > Date: Thu, 10 Jan 2008 09:28:31 +0000 > Subject: [M3devel] FW: bad code on PPC_LINUX? > > My emails keep getting truncated for some reason.. :( > > > ________________________________ >> From: jayk123 at hotmail.com >> To: m3devel at elegosoft.com >> Subject: bad code on PPC_LINUX? >> Date: Thu, 10 Jan 2008 07:11:11 +0000 >> >> >> Something is screwy I think. >> My gdb skills are um not good. >> >> On PPC_LINUX. >> >> /dev2/cm3/m3-sys/cm3/src/Utils.m3 >> >> PROCEDURE WriteFile (file: TEXT; proc: Emitter; append := FALSE) = >> VAR wr: Wr.T; >> BEGIN >> IF (append) >> THEN wr := AppendWriter (file, fatal := TRUE); >> ELSE wr := OpenWriter (file, fatal := TRUE); >> END; >> TRY (* line 78 *) >> TRY >> proc (wr); >> EXCEPT >> | Wr.Failure (ec) => >> Msg.FatalError (ec, "write failed on ", file); >> | Thread.Alerted => >> Msg.FatalError (NIL, "interrupted while writing ", file); >> END; >> FINALLY >> CloseWriter (wr, file); >> END; >> END WriteFile; >> >> I get a SEGV on line 78. >> >> I'm willing to believe, sadly, that some of these huge offsets >> are the price of TRY and saving the register context on anything >> other than x86 (for registers that aren't even used by the function?), >> however it crashes just after the call and notice there the huge 32k offset. >> >> And really? A 720 byte frame for any function with a TRY on PowerPC? >> Really? >> I guess I should look at what PPC_DARWIN does. >> >> If someone can give me a quick run down on PowerPC ABI, thanks. >> I'll search the web. Or maybe check my Mac docs. >> register 0 is 0 or general purpose? >> Stack is register ? >> I know that return address is in the link register. >> bl is branch and link -- call -- jump and save pc in link register. >> >> The code is: >> (gdb) disassemble >> Dump of assembler code for function Utils__WriteFile: >> 0x10024fbc : stwu r1,-720(r1) >> 0x10024fc0 : mflr r0 >> 0x10024fc4 : mfcr r12 >> 0x10024fc8 : stfd f14,576(r1) >> 0x10024fcc : stfd f15,584(r1) >> 0x10024fd0 : stfd f16,592(r1) >> 0x10024fd4 : stfd f17,600(r1) >> 0x10024fd8 : stfd f18,608(r1) >> 0x10024fdc : stfd f19,616(r1) >> 0x10024fe0 : stfd f20,624(r1) >> 0x10024fe4 : stfd f21,632(r1) >> 0x10024fe8 : stfd f22,640(r1) >> 0x10024fec : stfd f23,648(r1) >> 0x10024ff0 : stfd f24,656(r1) >> 0x10024ff4 : stfd f25,664(r1) >> 0x10024ff8 : stfd f26,672(r1) >> 0x10024ffc : stfd f27,680(r1) >> 0x10025000 : stfd f28,688(r1) >> 0x10025004 : stfd f29,696(r1) >> 0x10025008 : stfd f30,704(r1) >> 0x1002500c : stfd f31,712(r1) >> 0x10025010 : stw r14,504(r1) >> 0x10025014 : stw r15,508(r1) >> 0x10025018 : stw r16,512(r1) >> 0x1002501c : stw r17,516(r1) >> 0x10025020 : stw r18,520(r1) >> 0x10025024 : stw r19,524(r1) >> 0x10025028 : stw r20,528(r1) >> 0x1002502c : stw r21,532(r1) >> ---Type to continue, or q to quit--- >> 0x10025030 : stw r22,536(r1) >> 0x10025034 : stw r23,540(r1) >> 0x10025038 : stw r24,544(r1) >> 0x1002503c : stw r25,548(r1) >> 0x10025040 : stw r26,552(r1) >> 0x10025044 : stw r27,556(r1) >> 0x10025048 : stw r28,560(r1) >> 0x1002504c : stw r29,564(r1) >> 0x10025050 : stw r30,568(r1) >> 0x10025054 : stw r31,572(r1) >> 0x10025058 : stw r0,724(r1) >> 0x1002505c : stw r12,500(r1) >> 0x10025060 : mr r31,r1 >> 0x10025064 : bl 0x10025068 >> 0x10025068 : mflr r30 >> 0x1002506c : lwz r0,-176(r30) >> 0x10025070 : add r30,r0,r30 >> 0x10025074 : stw r3,8(r31) >> 0x10025078 : stw r4,12(r31) >> 0x1002507c : mr r0,r5 >> 0x10025080 : stb r0,16(r31) >> 0x10025084 : li r0,0 >> 0x10025088 : stw r0,20(r31) >> 0x1002508c : lbz r0,16(r31) >> 0x10025090 : clrlwi r0,r0,24 >> 0x10025094 : cmpwi r0,0 >> 0x10025098 : beq- 0x100250b8 >> 0x1002509c : lwz r3,8(r31) >> 0x100250a0 : li r4,1 >> 0x100250a4 : bl 0x100248a4 >> ---Type to continue, or q to quit--- >> 0x100250a8 : stw r3,476(r31) >> 0x100250ac : lwz r9,476(r31) >> 0x100250b0 : stw r9,20(r31) >> 0x100250b4 : b 0x100250d0 >> 0x100250b8 : lwz r3,8(r31) >> 0x100250bc : li r4,1 >> 0x100250c0 : bl 0x10024658 >> 0x100250c4 : stw r3,476(r31) >> 0x100250c8 : lwz r9,476(r31) >> 0x100250cc : stw r9,20(r31) >> >> ** here I believe ** >> >> 0x100250d0 : lwz r0,-32760(r30) >> 0x100250d4 : stw r0,32(r31) >> 0x100250d8 : addi r0,r31,8 >> 0x100250dc : stw r0,36(r31) >> 0x100250e0 : li r0,3 >> 0x100250e4 : stw r0,28(r31) >> 0x100250e8 : lwz r9,-32764(r30) >> 0x100250ec : lwz r0,0(r9) >> 0x100250f0 : stw r0,24(r31) >> 0x100250f4 : lwz r9,-32764(r30) >> 0x100250f8 : addi r0,r31,24 >> 0x100250fc : stw r0,0(r9) >> 0x10025100 : lwz r9,-32768(r30) >> 0x10025104 : addi r0,r9,76 >> 0x10025108 : stw r0,64(r31) >> 0x1002510c : li r0,0 >> 0x10025110 : stw r0,60(r31) >> 0x10025114 : lwz r9,-32764(r30) >> 0x10025118 : lwz r0,0(r9) >> 0x1002511c : stw r0,56(r31) >> ---Type to continue, or q to quit--- >> 0x10025120 : lwz r9,-32764(r30) >> 0x10025124 : addi r0,r31,56 >> 0x10025128 : stw r0,0(r9) >> 0x1002512c : addi r9,r31,56 >> 0x10025130 : addi r0,r9,48 >> 0x10025134 : mr r3,r0 >> 0x10025138 : bl 0x101bbf28 >> 0x1002513c : mr r0,r3 >> 0x10025140 : cmpwi r0,0 >> 0x10025144 : bne- 0x100251ac >> 0x10025148 : lwz r9,12(r31) >> 0x1002514c : stw r9,476(r31) >> 0x10025150 : lwz r9,476(r31) >> 0x10025154 : cmpwi r9,0 >> 0x10025158 : beq- 0x10025188 >> 0x1002515c : lwz r9,476(r31) >> 0x10025160 : lwz r0,0(r9) >> 0x10025164 : li r9,-1 >> 0x10025168 : cmpw r0,r9 >> 0x1002516c : bne- 0x10025188 >> 0x10025170 : lwz r9,476(r31) >> 0x10025174 : lwz r9,8(r9) >> 0x10025178 : stw r9,480(r31) >> 0x1002517c : lwz r9,476(r31) >> 0x10025180 : lwz r9,4(r9) >> 0x10025184 : stw r9,476(r31) >> 0x10025188 : lwz r11,480(r31) >> 0x1002518c : lwz r3,20(r31) >> 0x10025190 : lwz r0,476(r31) >> 0x10025194 : mtlr r0 >> ---Type to continue, or q to quit--- >> 0x10025198 : blrl >> 0x1002519c : lwz r9,-32764(r30) >> 0x100251a0 : lwz r0,56(r31) >> 0x100251a4 : stw r0,0(r9) >> 0x100251a8 : b 0x10025210 >> 0x100251ac : lwz r9,68(r31) >> 0x100251b0 : lwz r9,0(r9) >> 0x100251b4 : lis r0,-15535 >> 0x100251b8 : ori r0,r0,42454 >> 0x100251bc : cmpw r9,r0 >> 0x100251c0 : bne- 0x100251f0 >> 0x100251c4 : lwz r0,72(r31) >> 0x100251c8 : stw r0,472(r31) >> 0x100251cc : lwz r9,-32768(r30) >> 0x100251d0 : addi r0,r9,180 >> 0x100251d4 : lwz r3,472(r31) >> 0x100251d8 : mr r4,r0 >> 0x100251dc : lwz r5,8(r31) >> 0x100251e0 : li r6,0 >> 0x100251e4 : li r7,0 >> 0x100251e8 : bl 0x10023b4c >> 0x100251ec : b 0x10025210 >> 0x100251f0 : lwz r9,-32768(r30) >> 0x100251f4 : addi r0,r9,212 >> 0x100251f8 : li r3,0 >> 0x100251fc : mr r4,r0 >> 0x10025200 : lwz r5,8(r31) >> 0x10025204 : li r6,0 >> 0x10025208 : li r7,0 >> 0x1002520c : bl 0x10023b4c >> ---Type to continue, or q to quit--- >> 0x10025210 : lwz r9,-32764(r30) >> 0x10025214 : lwz r0,24(r31) >> 0x10025218 : stw r0,0(r9) >> 0x1002521c : addi r11,r31,8 >> 0x10025220 : bl 0x10024f74 >> 0x10025224 : lwz r11,0(r1) >> 0x10025228 : lwz r0,4(r11) >> 0x1002522c : lwz r12,-220(r11) >> 0x10025230 : mtlr r0 >> 0x10025234 : lwz r14,-216(r11) >> 0x10025238 : lwz r15,-212(r11) >> 0x1002523c : lwz r16,-208(r11) >> 0x10025240 : lwz r17,-204(r11) >> 0x10025244 : lwz r18,-200(r11) >> 0x10025248 : lwz r19,-196(r11) >> 0x1002524c : lwz r20,-192(r11) >> 0x10025250 : lwz r21,-188(r11) >> 0x10025254 : lwz r22,-184(r11) >> 0x10025258 : lwz r23,-180(r11) >> 0x1002525c : lwz r24,-176(r11) >> 0x10025260 : lwz r25,-172(r11) >> 0x10025264 : lwz r26,-168(r11) >> 0x10025268 : lwz r27,-164(r11) >> 0x1002526c : lwz r28,-160(r11) >> 0x10025270 : lwz r29,-156(r11) >> 0x10025274 : lwz r30,-152(r11) >> 0x10025278 : lwz r31,-148(r11) >> 0x1002527c : lfd f14,-144(r11) >> 0x10025280 : lfd f15,-136(r11) >> 0x10025284 : lfd f16,-128(r11) >> ---Type to continue, or q to quit--- >> 0x10025288 : lfd f17,-120(r11) >> 0x1002528c : lfd f18,-112(r11) >> 0x10025290 : lfd f19,-104(r11) >> 0x10025294 : lfd f20,-96(r11) >> 0x10025298 : lfd f21,-88(r11) >> 0x1002529c : lfd f22,-80(r11) >> 0x100252a0 : lfd f23,-72(r11) >> 0x100252a4 : lfd f24,-64(r11) >> 0x100252a8 : lfd f25,-56(r11) >> 0x100252ac : lfd f26,-48(r11) >> 0x100252b0 : lfd f27,-40(r11) >> 0x100252b4 : lfd f28,-32(r11) >> 0x100252b8 : lfd f29,-24(r11) >> 0x100252bc : lfd f30,-16(r11) >> 0x100252c0 : lfd f31,-8(r11) >> 0x100252c4 : mtcrf 56,r12 >> 0x100252c8 : mr r1,r11 >> 0x100252cc : blr >> 0x100252d0 : .long 0x24ebb0 >> End of assembler dump. >> >> >> (gdb) bt >> #0 Utils__WriteFile (M3_Bd56fi_file=0x10277ba0, M3_DmuccK_proc=0x7fb22210, >> M3_AicXUJ_append=0 '\0') at Utils.m3:78 >> #1 0x10020a10 in Makefile__Build (M3_Bd56fi_src_dir=0x102720ec) >> at Makefile.m3:101 >> #2 0x100292d4 in Main__DoIt () at Main.m3:71 >> #3 0x10029834 in Main_M3 (M3_AcxOUs_mode=1) at Main.m3:193 >> #4 0x10188f9c in RTLinker__RunMainBody (M3_DUuepq_m=0x10279b28) >> at RTLinker.m3:387 >> #5 0x101880bc in RTLinker__AddUnitI (M3_DUuepq_m=0x10279b28) at RTLinker.m3:100 >> #6 0x10188198 in RTLinker__AddUnit (M3_DUuepw_b=0x100297f8) at RTLinker.m3:110 >> #7 0x100002ec in main (argc=1, argv=0x7fb22834, envp=0x7fb2283c) at _m3main.mc:4 >> >> I haven't yet figured out how to get gdb to show me the details of the SEGV, like what address was referenced. >> >> I swear I think this was working better recently. >> >> Oh, I did change something. I will try to change it back. >> I added -fPIC. >> Dynamic linking was not working and I thought that might fix it. >> I'll definitely try without it now. >> >> Also, relevant aside -- what, if any, distributions/versions of Linux are people using on PowerPC? >> Specifically on PowerPC (to limit the religious explosion) >> I'm currently using Yellow Dog, I think 4.1, but only for Modula-3 purposes, not for anything else. >> >> ps: I'd like a SMALL forum of SMART programmers, to discuss GENERAL programming topics. >> This is it perhaps? >> >> - Jay >> _________________________________________________________________ >> Watch ?Cause Effect,? a show about real people making a real difference. >> http://im.live.com/Messenger/IM/MTV/?source=text_watchcause > > ________________________________ > Make distant family not so distant with Windows Vista? + Windows Live?. Start now! _________________________________________________________________ Put your friends on the big screen with Windows Vista? + Windows Live?. http://www.microsoft.com/windows/shop/specialoffers.mspx?ocid=TXT_TAGLM_CPC_MediaCtr_bigscreen_012008 From hendrik at topoi.pooq.com Thu Jan 10 15:28:12 2008 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Thu, 10 Jan 2008 09:28:12 -0500 Subject: [M3devel] (Offtopic) Some comments on SCM tools, was: Re: M3 concerns In-Reply-To: <20080110122020.zm4wc29e8044c0kw@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> <20080105191243.GB6402@topoi.pooq.com> <20080110122020.zm4wc29e8044c0kw@mail.elegosoft.com> Message-ID: <20080110142812.GA2503@topoi.pooq.com> On Thu, Jan 10, 2008 at 12:20:20PM +0100, Olaf Wagner wrote: > Quoting hendrik at topoi.pooq.com: > >But if you have this experience, it would be useful to see a rundown > >of the advantages and disadvantages of each. I've seen a table of > >features against version control systems, but it doesn't give any feel > >for what it's like to use them. > > > >Such an essay would be useful for those involved in other projects. It > >probably won't help Modula 3 itself. > > That would easily become an open-ended task :-) I was once asked to compare several programming languages with the intent of advising researchers in an institute which ones to use. A year into the project, I was sorry I ever started it. I learned a lot about CPU-time clocks running backward. I learned a lot about how different languages ended up with differences in floating-point behaviour, even though they were all running on the same hardware with one same set of floating-point instructions. > It is not easy to > compare different complex tools like SCM systems, which interact > in various degrees with process control, workflow management, problem > management, project management, general policies... Which is why a list of features really isn't enough. What's needed is poeple with hands-on experience with several. Which is hard to get. > > We've tried to provide feature-oriented comparison lists some years > ago, but even this needs too much efforts and is too fast out-of-date. > > There are some aspects that may currently be helpful as criterions > though. I'd like to mention some of them > > o Traditionally, version control tools were centralized server systems. > There is one central repository (which can in advanced setups be > replicated to several sites for many systems. Replicas may even be > partly writable. In case of replication there is one `logical' central > repository which is physically distributed.). Systems in this group > are CVS, ClearCase, PVCS, AccuRev, Perforce, Subversion, and many > others. > In recent years, peer-to-peer systems have become popular, because > they correspond better to certain aspects of open software projects > and are inherently distributed. There is no distinction between > workspace and repository, and each workspace holds a partial or > complete change history. > Such systems are BitKeeper, git, Darcs, and others. As far as I know, > these systems are not very popular in the commercial world (yet?). > > o An orthogonal criterion is the range of functionality that is addressed > with the solution. Simple systems like CVS and Perforce do just version > control and offer some hooks for further integration. > On the other side are process-oriented systems like PVCS Dimensions or a > complete ClearCase/ClearQuest setup for RUP. These systems are > rather based on change management und workflow than on developer > needs. Basic abstractions are baselines, changesets, tasks, projects, > activities, functional roles. > Of course, some tools are somewhere in between these extremes, like > AccuRev, which supports kinds of long-running transactions for > everything, called `streams'. (This one's very nice IMO.) > > o Then there are the costs of the use of the systems. There are always > costs, even for open source solutions. You have to consider > > - server costs (hardware, energy, OS, database, licences, networks) > - administration and maintenance (servers and user setup) > - user license costs (from 0 to several thousand dollars per year) > - use overhead (depending on tool usability and process) > - instruction and training > > Again there are systems that are rather lightweight in this respect > (like CVS and Perforce) and some tending to be more heavyweight > (like ClearCase and PVCS). > > o The `end user experience' corresponds very much to the basic > concepts needed in everyday use. File based ci/co is very > simple, development lines are more or less a must have, > change sets and baselines (like in DCVS, AccuRev or RUP) are very > nice; diffs and merges seem to be too complex for many users > (but are of course needed); conflict avoidance vs. conflict > resolution (locking or optimistic approach) is often a religiously > discussed topic. > The other important issue here is the IDE integration (at least > for developers). > > These are only some randomly picked topics that would need to be > addressed in a useful tool comparison. > > There are very few situations in which you can evaluate and choose > the best tool for your purpose; most of the time, you have to adapt > and improve existing setups, as everything else would be too > expensive and disrupting. Our company has supported several migration > projects recently though, so it's not impossible to change ;-) > > As for CM3, I'm still of the opinion that there is no need to > change the existing CVS infrastructure. > > >Or might you know of such an essay elsewhere? > > Well, the more interesting field studies and evaluations are not > free; there are quite a lot of interesting articles though. > I haven't any links here right now; CM crossroads or a Google > search on `configuration management' should be a good starting point. Thank you for this very brief review. I'm really not wanting you to take a year off from more urgent 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 hendrik at topoi.pooq.com Thu Jan 10 15:37:50 2008 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Thu, 10 Jan 2008 09:37:50 -0500 Subject: [M3devel] win32 path separators -- support forward and backward in libm3? In-Reply-To: <20080110135850.g34emuxds0ogwwk4@mail.elegosoft.com> References: <200801100131.m0A1VQYS034516@camembert.async.caltech.edu> <20080110135850.g34emuxds0ogwwk4@mail.elegosoft.com> Message-ID: <20080110143750.GB2503@topoi.pooq.com> On Thu, Jan 10, 2008 at 01:58:50PM +0100, Olaf Wagner wrote: > Quoting Jay : > > >To a very large extent, Win32 accepts both / and \ equally as path > >delimiters. > >CreateFile, DeleteFile, CreateDirectory, MoveFile, CopyFile, > >FindFirstFile, GetFileAttributes, the C runtime wrappers fopen, > >unlink/remove, stat, etc., those all work either way, or with a mix. > >"Shell" functions like shlwapi.dll, commdlg32.dll, tend not to. > > > >In building NT386GNU, I run into places where cm3 is picking apart paths. > >For whatever reason, it is being given paths with a mix of forward > >and backward slashes. > >I find these paths ugly, but they work ok. > > > >I've been able to easily progress by changing > >m3-libs/libm3/src/os/WIN32/PathnameWin32.m3 to treat forward and > >backslashes the same. > >I have not yet rebuilt the normal NT386 target with this change. > > > >An ok change? > > > >Or go and fix NT386GNU a) to be consistent, b) use backward slashes, > > c) translate at some place. > > > >? > > In my opininion NT386GNU should be a POSIX target and thus use forward > slashes as standard as POSIX defines. Offhand I wouldn't object to accept > backward slashes as path delimiters, too. But you must heed that \ > is used as an escape character almost everywhere (and so should it be > in pathname denotations then: a\\b\\c) or you loose much compatibility. > > I still wonder if the decision to use \ on DOS/Windows was only made to > be as incompatible as possible with Unix... In the early days, DOS did not have directories, so there was no need of a slash or anything as a pathname separator. Instead, it got used as a character to attach options to command names. I think is also got used to attach options to filenames sometimes. When someone got the bright idea that directories were a neat idea, it was too late. Incidentally, in those days, Unix wasn't yet the big deal it is now. There were lots of other OS's to be compatible with -- or not. -- hendrik From darko at darko.org Thu Jan 10 17:35:05 2008 From: darko at darko.org (Darko) Date: Thu, 10 Jan 2008 08:35:05 -0800 Subject: [M3devel] nt386gnu is posix or win32? In-Reply-To: References: Your message of "Wed, 09 Jan 2008 17:25:31 PST." <200801100131.m0A1VQYS034516@camembert.async.caltech.edu> Message-ID: <6A267174-E215-48A6-BD0D-CB9AF4C13FE5@darko.org> On 10/01/2008, at 3:16 AM, Jay wrote: > By "serious" I mean, "ship real software using it". Then the question is: what is' real' software. I've shipped commercial software (a smallish application) using the existing native back end, which doesn't produce very good code, but the performance was adequate. For many other applications this won't be the case. You should look at this issue the other way around: If it allows people to build 'serious' software, they will use it. If you have an interest in Windows and M3, this would be one of the most useful things you could do, IMHO. Darko. From hosking at cs.purdue.edu Thu Jan 10 18:41:55 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 10 Jan 2008 12:41:55 -0500 Subject: [M3devel] bad code on PPC_LINUX? In-Reply-To: References: Message-ID: <9E64639D-CF64-4E6E-A157-FB67D1AC0C9B@cs.purdue.edu> Is this an alignment problem? Or a mismatch between the compiler and runtime? I have no idea if the alignment specs and definitions for the jmp_buf used in exceptions are matched between the compiler and run-time properly. See Target.m3 in the compiler and RTMachine.i3 in the runtime. On Jan 10, 2008, at 2:11 AM, Jay wrote: > > Something is screwy I think. > My gdb skills are um not good. > > On PPC_LINUX. > > /dev2/cm3/m3-sys/cm3/src/Utils.m3 > > PROCEDURE WriteFile (file: TEXT; proc: Emitter; append := FALSE) = > VAR wr: Wr.T; > BEGIN > IF (append) > THEN wr := AppendWriter (file, fatal := TRUE); > ELSE wr := OpenWriter (file, fatal := TRUE); > END; > TRY (* line 78 *) > TRY > proc (wr); > EXCEPT > | Wr.Failure (ec) => > Msg.FatalError (ec, "write failed on ", file); > | Thread.Alerted => > Msg.FatalError (NIL, "interrupted while writing ", file); > END; > FINALLY > CloseWriter (wr, file); > END; > END WriteFile; > > I get a SEGV on line 78. > > I'm willing to believe, sadly, that some of these huge offsets > are the price of TRY and saving the register context on anything > other than x86 (for registers that aren't even used by the function?), > however it crashes just after the call and notice there the huge > 32k offset From hosking at cs.purdue.edu Thu Jan 10 18:52:35 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 10 Jan 2008 12:52:35 -0500 Subject: [M3devel] could someone add __stdcall name mangling to m3cc please? In-Reply-To: References: Your message of "Wed, 09 Jan 2008 17:25:31 PST." <200801100131.m0A1VQYS034516@camembert.async.caltech.edu> Message-ID: <6D677FCA-D704-4E84-BD58-893C71D97B59@cs.purdue.edu> On Jan 10, 2008, at 7:42 AM, Jay wrote: > PM3 appears to ignore call_conv. > Perhaps its NT386GNU uses usermode threads via cygwin1.dll and has > no gui support, such as to not import any __stdcall functions??? Probably, yes. CM3 were the ones who added gui support. Anyway, I think it is simply a matter of adding the appropriate attribute to the function decls in the gcc backend. I believe that it supports cdecl and stdcall. Are these all we need to specify? > http://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/m3/pm3/language/ > modula3/m3compiler/m3cc/gcc/gcc/m3cg/m3.c?rev=1.1;content-type=text% > 2Fx-cvsweb-markup;cvsroot=PM3 > > - Jay > > From: jayk123 at hotmail.com > To: m3devel at elegosoft.com > Date: Thu, 10 Jan 2008 12:40:22 +0000 > Subject: [M3devel] could someone add __stdcall name mangling to > m3cc please? > > Could someone out there (Tony?) familiar with the gcc backend > have it not ignore call_conv and if call_conv is 1, append > an at symbol and the number of bytes of parameters to the function > name? > (Even for zero, e.g. Sleep at 0, GetFileAttributes at 4). > This would be I guess at least for "imported" functions. > > Not clear about calling function pointers, probably needs > modification. > call_conv 0 is "__cdecl" is push right to left, caller cleans up > call_conv 1 is "__stdcall" is push right to left, callee cleans up > There are various synonyms. > With no command line switches, __cdecl is the compiler default. > __stdcall is deemed more efficient, and is very widely used. > > Not clear about functions implemented in Modula-3. > Probably won't occur? Maybe for callbacks? WindowProcs, thread > entry point? > > This could/should be for NT386GNU only. > The hypothetical other NT targets only have one calling convention > each. > > I COULD do something sleazy here and generate little adapter > functions, over in m3-win/import-libs esp. > > I'm still checking out pm3 to see what it does here. > (as in cvs checkout, not "looking at") > > This'll clear up: > > RTOS.m3:27: undefined reference to `_FatalExit' > RTOS.mo: In function `RTOS__GetMemory': > RTOS.m3:75: undefined reference to `_VirtualAlloc' > RTOS.m3:85: undefined reference to `_VirtualAlloc' > RTOS.mo: In function `RTOS__InitMemory': > RTOS.m3:96: undefined reference to `_VirtualAlloc' > RTOS.m3:100: undefined reference to `_GetSystemInfo' > RTOS.mo: In function `RTOS__Write': > RTOS.m3:118: undefined reference to `_AllocConsole' > RTOS.m3:119: undefined reference to `_GetStdHandle' > RTOS.m3:122: undefined reference to `_WriteFile' > RTPerfTool.mo: In function `RTPerfTool__Start': > RTPerfTool.m3:19: undefined reference to `_ReadFile' > RTPerfTool.m3:22: undefined reference to `_CloseHandle' > RTPerfTool.mo: In function `RTPerfTool__Close': > RTPerfTool.m3:28: undefined reference to `_CloseHandle' > RTPerfTool.mo: In function `RTPerfTool__Send': > RTPerfTool.m3:34: undefined reference to `_WriteFile' > RTPerfTool.mo: In function `RTPerfTool__PrepHandle': > RTPerfTool.m3:58: undefined reference to `_GetCurrentProcess' > RTPerfTool.m3:59: undefined reference to `_DuplicateHandle' > etc. > > I did think I was past these. I thought I built m3core and libm3 > including linking (having even modified cm3.cfg) > COULD be I'm using the wrong .libs, but: > > C:\cygwin\lib\w32api>nm libkernel32.a | findstr CreateFile > 00000000 I __imp__CreateFileW at 28 > 00000000 T _CreateFileW at 28 > 00000000 I __imp__CreateFileMappingW at 24 > 00000000 T _CreateFileMappingW at 24 > 00000000 I __imp__CreateFileMappingA at 24 > 00000000 T _CreateFileMappingA at 24 > 00000000 I __imp__CreateFileA at 28 > 00000000 T _CreateFileA at 28 > > C:\cygwin\lib\w32api>cd \MinGW\lib > > C:\MinGW\lib>nm libkernel32.a | findstr CreateFile > 00000000 I __imp__CreateFileW at 28 > 00000000 T _CreateFileW at 28 > 00000000 I __imp__CreateFileMappingW at 24 > 00000000 T _CreateFileMappingW at 24 > 00000000 I __imp__CreateFileMappingA at 24 > 00000000 T _CreateFileMappingA at 24 > 00000000 I __imp__CreateFileA at 28 > 00000000 T _CreateFileA at 28 > > I think at least THREE calling conventions should be supported -- > __cdecl, __stdcall, __fastcall -- > but oh well. We can live without __fastcall. > Watcom has another calling convention, "watcall", and they let you > describe calling conventions with #pragmas, neat. > > Thanks, > - Jay > > Share life as it happens with the new Windows Live. Start sharing! > Get the power of Windows + Web with the new Windows Live. Get it now! From hosking at cs.purdue.edu Thu Jan 10 18:57:47 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 10 Jan 2008 12:57:47 -0500 Subject: [M3devel] could someone add __stdcall name mangling to m3cc please? In-Reply-To: References: Your message of "Wed, 09 Jan 2008 17:25:31 PST." <200801100131.m0A1VQYS034516@camembert.async.caltech.edu> Message-ID: <70EC0898-EE63-4C19-8C28-EC72E2B73B31@cs.purdue.edu> Do we have a version of the gcc-based backend that *ever* supported the calling conventions? On Jan 10, 2008, at 7:40 AM, Jay wrote: > Could someone out there (Tony?) familiar with the gcc backend > have it not ignore call_conv and if call_conv is 1, append > an at symbol and the number of bytes of parameters to the function > name? > (Even for zero, e.g. Sleep at 0, GetFileAttributes at 4). > This would be I guess at least for "imported" functions. > > Not clear about calling function pointers, probably needs > modification. > call_conv 0 is "__cdecl" is push right to left, caller cleans up > call_conv 1 is "__stdcall" is push right to left, callee cleans up > There are various synonyms. > With no command line switches, __cdecl is the compiler default. > __stdcall is deemed more efficient, and is very widely used. > > Not clear about functions implemented in Modula-3. > Probably won't occur? Maybe for callbacks? WindowProcs, thread > entry point? > > This could/should be for NT386GNU only. > The hypothetical other NT targets only have one calling convention > each. > > I COULD do something sleazy here and generate little adapter > functions, over in m3-win/import-libs esp. > > I'm still checking out pm3 to see what it does here. > (as in cvs checkout, not "looking at") > > This'll clear up: > > RTOS.m3:27: undefined reference to `_FatalExit' > RTOS.mo: In function `RTOS__GetMemory': > RTOS.m3:75: undefined reference to `_VirtualAlloc' > RTOS.m3:85: undefined reference to `_VirtualAlloc' > RTOS.mo: In function `RTOS__InitMemory': > RTOS.m3:96: undefined reference to `_VirtualAlloc' > RTOS.m3:100: undefined reference to `_GetSystemInfo' > RTOS.mo: In function `RTOS__Write': > RTOS.m3:118: undefined reference to `_AllocConsole' > RTOS.m3:119: undefined reference to `_GetStdHandle' > RTOS.m3:122: undefined reference to `_WriteFile' > RTPerfTool.mo: In function `RTPerfTool__Start': > RTPerfTool.m3:19: undefined reference to `_ReadFile' > RTPerfTool.m3:22: undefined reference to `_CloseHandle' > RTPerfTool.mo: In function `RTPerfTool__Close': > RTPerfTool.m3:28: undefined reference to `_CloseHandle' > RTPerfTool.mo: In function `RTPerfTool__Send': > RTPerfTool.m3:34: undefined reference to `_WriteFile' > RTPerfTool.mo: In function `RTPerfTool__PrepHandle': > RTPerfTool.m3:58: undefined reference to `_GetCurrentProcess' > RTPerfTool.m3:59: undefined reference to `_DuplicateHandle' > etc. > > I did think I was past these. I thought I built m3core and libm3 > including linking (having even modified cm3.cfg) > COULD be I'm using the wrong .libs, but: > > C:\cygwin\lib\w32api>nm libkernel32.a | findstr CreateFile > 00000000 I __imp__CreateFileW at 28 > 00000000 T _CreateFileW at 28 > 00000000 I __imp__CreateFileMappingW at 24 > 00000000 T _CreateFileMappingW at 24 > 00000000 I __imp__CreateFileMappingA at 24 > 00000000 T _CreateFileMappingA at 24 > 00000000 I __imp__CreateFileA at 28 > 00000000 T _CreateFileA at 28 > > C:\cygwin\lib\w32api>cd \MinGW\lib > > C:\MinGW\lib>nm libkernel32.a | findstr CreateFile > 00000000 I __imp__CreateFileW at 28 > 00000000 T _CreateFileW at 28 > 00000000 I __imp__CreateFileMappingW at 24 > 00000000 T _CreateFileMappingW at 24 > 00000000 I __imp__CreateFileMappingA at 24 > 00000000 T _CreateFileMappingA at 24 > 00000000 I __imp__CreateFileA at 28 > 00000000 T _CreateFileA at 28 > > I think at least THREE calling conventions should be supported -- > __cdecl, __stdcall, __fastcall -- > but oh well. We can live without __fastcall. > Watcom has another calling convention, "watcall", and they let you > describe calling conventions with #pragmas, neat. > > Thanks, > - Jay > > Share life as it happens with the new Windows Live. Start sharing! From hosking at cs.purdue.edu Thu Jan 10 19:16:40 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 10 Jan 2008 13:16:40 -0500 Subject: [M3devel] FW: bad code on PPC_LINUX? In-Reply-To: References: Message-ID: <9D5186FA-9A91-4696-B6C6-CABC12DAE188@cs.purdue.edu> On Jan 10, 2008, at 4:28 AM, Jay wrote: > My emails keep getting truncated for some reason.. :( > > > > From: jayk123 at hotmail.com > > To: m3devel at elegosoft.com > > Subject: bad code on PPC_LINUX? > > Date: Thu, 10 Jan 2008 07:11:11 +0000 > > > > > > Something is screwy I think. > > My gdb skills are um not good. > > > > On PPC_LINUX. > > > > /dev2/cm3/m3-sys/cm3/src/Utils.m3 > > > > PROCEDURE WriteFile (file: TEXT; proc: Emitter; append := FALSE) = > > VAR wr: Wr.T; > > BEGIN > > IF (append) > > THEN wr := AppendWriter (file, fatal := TRUE); > > ELSE wr := OpenWriter (file, fatal := TRUE); > > END; > > TRY (* line 78 *) > > TRY > > proc (wr); > > EXCEPT > > | Wr.Failure (ec) => > > Msg.FatalError (ec, "write failed on ", file); > > | Thread.Alerted => > > Msg.FatalError (NIL, "interrupted while writing ", file); > > END; > > FINALLY > > CloseWriter (wr, file); > > END; > > END WriteFile; > > > > I get a SEGV on line 78. > > > > I'm willing to believe, sadly, that some of these huge offsets > > are the price of TRY and saving the register context on anything > > other than x86 (for registers that aren't even used by the > function?), > > however it crashes just after the call and notice there the huge > 32k offset. > > > > And really? A 720 byte frame for any function with a TRY on PowerPC? > > Really? Sounds odd, but maybe some struct in the frame is huge. What is the size of the jmp_buf? > > > I guess I should look at what PPC_DARWIN does. Sure. > > > > > If someone can give me a quick run down on PowerPC ABI, thanks. > > I'll search the web. Or maybe check my Mac docs. Mac docs do a reasonable job. It is similar for PPC Linux. http://developer.apple.com/documentation/DeveloperTools/ CompilersDebuggers-date.html > > > register 0 is 0 or general purpose? > > Stack is register ? > > I know that return address is in the link register. > > bl is branch and link -- call -- jump and save pc in link register. > > > > The code is: > > (gdb) disassemble > > Dump of assembler code for function Utils__WriteFile: > > 0x10024fbc : stwu r1,-720(r1) > > 0x10024fc0 : mflr r0 > > 0x10024fc4 : mfcr r12 > > 0x10024fc8 : stfd f14,576(r1) > > 0x10024fcc : stfd f15,584(r1) > > 0x10024fd0 : stfd f16,592(r1) > > 0x10024fd4 : stfd f17,600(r1) > > 0x10024fd8 : stfd f18,608(r1) > > 0x10024fdc : stfd f19,616(r1) > > 0x10024fe0 : stfd f20,624(r1) > > 0x10024fe4 : stfd f21,632(r1) > > 0x10024fe8 : stfd f22,640(r1) > > 0x10024fec : stfd f23,648(r1) > > 0x10024ff0 : stfd f24,656(r1) > > 0x10024ff4 : stfd f25,664(r1) > > 0x10024ff8 : stfd f26,672(r1) > > 0x10024ffc : stfd f27,680(r1) > > 0x10025000 : stfd f28,688(r1) > > 0x10025004 : stfd f29,696(r1) > > 0x10025008 : stfd f30,704(r1) > > 0x1002500c : stfd f31,712(r1) > > 0x10025010 : stw r14,504(r1) > > 0x10025014 : stw r15,508(r1) > > 0x10025018 : stw r16,512(r1) > > 0x1002501c : stw r17,516(r1) > > 0x10025020 : stw r18,520(r1) > > 0x10025024 : stw r19,524(r1) > > 0x10025028 : stw r20,528(r1) > > 0x1002502c : stw r21,532(r1) > > ---Type to continue, or q to quit--- > > 0x10025030 : stw r22,536(r1) > > 0x10025034 : stw r23,540(r1) > > 0x10025038 : stw r24,544(r1) > > 0x1002503c : stw r25,548(r1) > > 0x10025040 : stw r26,552(r1) > > 0x10025044 : stw r27,556(r1) > > 0x10025048 : stw r28,560(r1) > > 0x1002504c : stw r29,564(r1) > > 0x10025050 : stw r30,568(r1) > > 0x10025054 : stw r31,572(r1) > > 0x10025058 : stw r0,724(r1) > > 0x1002505c : stw r12,500(r1) > > 0x10025060 : mr r31,r1 > > 0x10025064 : bl 0x10025068 > > 0x10025068 : mflr r30 > > 0x1002506c : lwz r0,-176(r30) > > 0x10025070 : add r30,r0,r30 > > 0x10025074 : stw r3,8(r31) > > 0x10025078 : stw r4,12(r31) > > 0x1002507c : mr r0,r5 > > 0x10025080 : stb r0,16(r31) > > 0x10025084 : li r0,0 > > 0x10025088 : stw r0,20(r31) > > 0x1002508c : lbz r0,16(r31) > > 0x10025090 : clrlwi r0,r0,24 > > 0x10025094 : cmpwi r0,0 > > 0x10025098 : beq- 0x100250b8 > > 0x1002509c : lwz r3,8(r31) > > 0x100250a0 : li r4,1 > > 0x100250a4 : bl 0x100248a4 > > ---Type to continue, or q to quit--- > > 0x100250a8 : stw r3,476(r31) > > 0x100250ac : lwz r9,476(r31) > > 0x100250b0 : stw r9,20(r31) > > 0x100250b4 : b 0x100250d0 > > 0x100250b8 : lwz r3,8(r31) > > 0x100250bc : li r4,1 > > 0x100250c0 : bl 0x10024658 > > 0x100250c4 : stw r3,476(r31) > > 0x100250c8 : lwz r9,476(r31) > > 0x100250cc : stw r9,20(r31) > > > > ** here I believe ** > > > > 0x100250d0 : lwz r0,-32760(r30) > > 0x100250d4 : stw r0,32(r31) > > 0x100250d8 : addi r0,r31,8 > > 0x100250dc : stw r0,36(r31) > > 0x100250e0 : li r0,3 > > 0x100250e4 : stw r0,28(r31) > > 0x100250e8 : lwz r9,-32764(r30) > > 0x100250ec : lwz r0,0(r9) > > 0x100250f0 : stw r0,24(r31) > > 0x100250f4 : lwz r9,-32764(r30) > > 0x100250f8 : addi r0,r31,24 > > 0x100250fc : stw r0,0(r9) > > 0x10025100 : lwz r9,-32768(r30) > > 0x10025104 : addi r0,r9,76 > > 0x10025108 : stw r0,64(r31) > > 0x1002510c : li r0,0 > > 0x10025110 : stw r0,60(r31) > > 0x10025114 : lwz r9,-32764(r30) > > 0x10025118 : lwz r0,0(r9) > > 0x1002511c : stw r0,56(r31) > > ---Type to continue, or q to quit--- > > 0x10025120 : lwz r9,-32764(r30) > > 0x10025124 : addi r0,r31,56 > > 0x10025128 : stw r0,0(r9) > > 0x1002512c : addi r9,r31,56 > > 0x10025130 : addi r0,r9,48 > > 0x10025134 : mr r3,r0 > > 0x10025138 : bl 0x101bbf28 > > 0x1002513c : mr r0,r3 > > 0x10025140 : cmpwi r0,0 > > 0x10025144 : bne- 0x100251ac > > 0x10025148 : lwz r9,12(r31) > > 0x1002514c : stw r9,476(r31) > > 0x10025150 : lwz r9,476(r31) > > 0x10025154 : cmpwi r9,0 > > 0x10025158 : beq- 0x10025188 > > 0x1002515c : lwz r9,476(r31) > > 0x10025160 : lwz r0,0(r9) > > 0x10025164 : li r9,-1 > > 0x10025168 : cmpw r0,r9 > > 0x1002516c : bne- 0x10025188 > > 0x10025170 : lwz r9,476(r31) > > 0x10025174 : lwz r9,8(r9) > > 0x10025178 : stw r9,480(r31) > > 0x1002517c : lwz r9,476(r31) > > 0x10025180 : lwz r9,4(r9) > > 0x10025184 : stw r9,476(r31) > > 0x10025188 : lwz r11,480(r31) > > 0x1002518c : lwz r3,20(r31) > > 0x10025190 : lwz r0,476(r31) > > 0x10025194 : mtlr r0 > > ---Type to continue, or q to quit--- > > 0x10025198 : blrl > > 0x1002519c : lwz r9,-32764(r30) > > 0x100251a0 : lwz r0,56(r31) > > 0x100251a4 : stw r0,0(r9) > > 0x100251a8 : b 0x10025210 > > 0x100251ac : lwz r9,68(r31) > > 0x100251b0 : lwz r9,0(r9) > > 0x100251b4 : lis r0,-15535 > > 0x100251b8 : ori r0,r0,42454 > > 0x100251bc : cmpw r9,r0 > > 0x100251c0 : bne- 0x100251f0 > > 0x100251c4 : lwz r0,72(r31) > > 0x100251c8 : stw r0,472(r31) > > 0x100251cc : lwz r9,-32768(r30) > > 0x100251d0 : addi r0,r9,180 > > 0x100251d4 : lwz r3,472(r31) > > 0x100251d8 : mr r4,r0 > > 0x100251dc : lwz r5,8(r31) > > 0x100251e0 : li r6,0 > > 0x100251e4 : li r7,0 > > 0x100251e8 : bl 0x10023b4c > > 0x100251ec : b 0x10025210 > > 0x100251f0 : lwz r9,-32768(r30) > > 0x100251f4 : addi r0,r9,212 > > 0x100251f8 : li r3,0 > > 0x100251fc : mr r4,r0 > > 0x10025200 : lwz r5,8(r31) > > 0x10025204 : li r6,0 > > 0x10025208 : li r7,0 > > 0x1002520c : bl 0x10023b4c > > ---Type to continue, or q to quit--- > > 0x10025210 : lwz r9,-32764(r30) > > 0x10025214 : lwz r0,24(r31) > > 0x10025218 : stw r0,0(r9) > > 0x1002521c : addi r11,r31,8 > > 0x10025220 : bl 0x10024f74 > > 0x10025224 : lwz r11,0(r1) > > 0x10025228 : lwz r0,4(r11) > > 0x1002522c : lwz r12,-220(r11) > > 0x10025230 : mtlr r0 > > 0x10025234 : lwz r14,-216(r11) > > 0x10025238 : lwz r15,-212(r11) > > 0x1002523c : lwz r16,-208(r11) > > 0x10025240 : lwz r17,-204(r11) > > 0x10025244 : lwz r18,-200(r11) > > 0x10025248 : lwz r19,-196(r11) > > 0x1002524c : lwz r20,-192(r11) > > 0x10025250 : lwz r21,-188(r11) > > 0x10025254 : lwz r22,-184(r11) > > 0x10025258 : lwz r23,-180(r11) > > 0x1002525c : lwz r24,-176(r11) > > 0x10025260 : lwz r25,-172(r11) > > 0x10025264 : lwz r26,-168(r11) > > 0x10025268 : lwz r27,-164(r11) > > 0x1002526c : lwz r28,-160(r11) > > 0x10025270 : lwz r29,-156(r11) > > 0x10025274 : lwz r30,-152(r11) > > 0x10025278 : lwz r31,-148(r11) > > 0x1002527c : lfd f14,-144(r11) > > 0x10025280 : lfd f15,-136(r11) > > 0x10025284 : lfd f16,-128(r11) > > ---Type to continue, or q to quit--- > > 0x10025288 : lfd f17,-120(r11) > > 0x1002528c : lfd f18,-112(r11) > > 0x10025290 : lfd f19,-104(r11) > > 0x10025294 : lfd f20,-96(r11) > > 0x10025298 : lfd f21,-88(r11) > > 0x1002529c : lfd f22,-80(r11) > > 0x100252a0 : lfd f23,-72(r11) > > 0x100252a4 : lfd f24,-64(r11) > > 0x100252a8 : lfd f25,-56(r11) > > 0x100252ac : lfd f26,-48(r11) > > 0x100252b0 : lfd f27,-40(r11) > > 0x100252b4 : lfd f28,-32(r11) > > 0x100252b8 : lfd f29,-24(r11) > > 0x100252bc : lfd f30,-16(r11) > > 0x100252c0 : lfd f31,-8(r11) > > 0x100252c4 : mtcrf 56,r12 > > 0x100252c8 : mr r1,r11 > > 0x100252cc : blr > > 0x100252d0 : .long 0x24ebb0 > > End of assembler dump. > > > > > > (gdb) bt > > #0 Utils__WriteFile (M3_Bd56fi_file=0x10277ba0, > M3_DmuccK_proc=0x7fb22210, > > M3_AicXUJ_append=0 '\0') at Utils.m3:78 > > #1 0x10020a10 in Makefile__Build (M3_Bd56fi_src_dir=0x102720ec) > > at Makefile.m3:101 > > #2 0x100292d4 in Main__DoIt () at Main.m3:71 > > #3 0x10029834 in Main_M3 (M3_AcxOUs_mode=1) at Main.m3:193 > > #4 0x10188f9c in RTLinker__RunMainBody (M3_DUuepq_m=0x10279b28) > > at RTLinker.m3:387 > > #5 0x101880bc in RTLinker__AddUnitI (M3_DUuepq_m=0x10279b28) at > RTLinker.m3:100 > > #6 0x10188198 in RTLinker__AddUnit (M3_DUuepw_b=0x100297f8) at > RTLinker.m3:110 > > #7 0x100002ec in main (argc=1, argv=0x7fb22834, envp=0x7fb2283c) > at _m3main.mc:4 > > > > I haven't yet figured out how to get gdb to show me the details > of the SEGV, like what address was referenced. > > > > I swear I think this was working better recently. > > > > Oh, I did change something. I will try to change it back. > > I added -fPIC. > > Dynamic linking was not working and I thought that might fix it. > > I'll definitely try without it now. > > > > Also, relevant aside -- what, if any, distributions/versions of > Linux are people using on PowerPC? > > Specifically on PowerPC (to limit the religious explosion) > > I'm currently using Yellow Dog, I think 4.1, but only for > Modula-3 purposes, not for anything else. > > > > ps: I'd like a SMALL forum of SMART programmers, to discuss > GENERAL programming topics. > > This is it perhaps? > > > > - Jay > > _________________________________________________________________ > > Watch ?Cause Effect,? a show about real people making a real > difference. > > http://im.live.com/Messenger/IM/MTV/?source=text_watchcause > > Make distant family not so distant with Windows Vista? + Windows > Live?. Start now! From hosking at cs.purdue.edu Thu Jan 10 19:30:55 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 10 Jan 2008 13:30:55 -0500 Subject: [M3devel] nt386gnu is posix or win32? In-Reply-To: References: <20080107073815.DBCDD10D45C8@birch.elegosoft.com> <4F88D761-5F3F-4891-B3BD-7490FC7E7A2A@cs.purdue.edu> Message-ID: On Jan 9, 2008, at 6:08 PM, Jay wrote: > I'm going to be rude and just throw this out there at a time when I > probably can't discuss it or yet have enough data/diffs to matter. > > However, in building NT386GNU -- I can build libm3 and m3core -- > the question arises as to if this target is "win32" or "posix'. > Currently in the tree it is setup to be "posix", with a fair amount > of work already done in that direction -- in particular, the Unix > interfaces. > > However, I think this target is potentially an odd beast. > Potentially it is two targets. > I guess this mimics cygwin vs. mingwin. Exactly. > > The "host" is gcc. In order to build this system, one needs > "gmake", sh, gcc probably (I'm assuming Visual C++'s compiler/ > linker cannot build m3cg, but very maybe..). > > In order to build anything with this system, one needs "as", and > most likely ld. > (I quote "as" because it is an English word and confusing to read > otherwise.) > Changing it to output assembly for masm or even Visual C++'s inline > __asm is probably actually viable, but not a tiny short term task. > (Or maybe writing an as clone that outputs .objs? Maybe using nasm/ > yasm??? Not sure the point, maybe "as" is perfectly ok.) > > And then the question arises as to what it takes to run the output. > As I've said in other topics, the C runtime dependency of Modula-3 > is light -- startup code mainly, but, yeah, also important setjmp/ > longjmp, and multiplication/division helpers sometimes. This could > perhaps all be statically linked. Certainly for Visual C++ it can be. > (NOTE: The Cygwin jmp_buf is much larger than Visual C++'s. A > THOUGHT is to grow them to the same, for object code compatibility, > but probably not useful, and very wasteful, Cygwin's is much > larger, the data in the existing code I verified is correct, like > 0x40 vs. 0xD0 I think it was, I just did printf("%x", sizeof > (jmp_buf)).) > > To get m3core to build, I switched NT386GNU to use Win32 threads. > For THAT to build, I switched OSTYPE to Win32. Overkill perhaps, in > order to get the Win32 *.i3 files. > Overkill perhaps, but it does build. > > I fully suspect that old style Posix threads can work easily, and > that pthreads can work easily, increasing the dependency on > cygwin1.dll. User-level (ThreadPosix) threads might work (using setjmp/longjmp for thread switching -- I guess that is what PM3 used to do). Or did it use ThreadWin32? I doubt ThreadPThread will work since I don't think there is a pthreads binding for Win32 threads on NT, or is there? > While this is the "other" direction, given the dependency on as, > and gcc to build m3cg, probably the horse is out of the barn. > This is arguably a simpler answer, less hybrid. My strong preference is to tread NT386GNU (i.e., Cygwin based) as a POSIX target, which might happen to use ThreadWin32. That way, the usual POSIX/Cygwin flavor of things is preserved. > > > I think the analogy to cygwin/mingwin holds, possibly perfectly. > > Maybe this is two targets. > NT386CYGWIN ? > NT386MINGWIN ? > > (Which begs the point -- target naming.... NT386 vs. PPC_LINUX...OS > +ARCH vs. ARCH + _ + OS, etc... but ARCH and OS aren't it, there is > toolchain and C runtime in the mix..) > > Obviously SOMETHING is better than NOTHING and I have no useful > binary distribution yet to show, so these questions are all very > premature. > > I'm also unsure as to the "seriousness" of using the GNU tools. > a) There don't seem to be many users of Modula-3 on Win32. > b) Will such users accept/trust a non Microsoft toolchain? > (Just what to do folks do with cygwin/mingwin? Build/ship real > software?) > > From my point of view, the attractive thing about m3cg is I get the > int64 stuff arguably out of the way easier. :) > > Licensing wise..probably a dependency on cygwin1.dll is not desirable. > > When I'm further along, er, actually, with my existing libm3.dll/ > m3core.dll, I can see what the dependencies are. > If it's just setjmp/lonjmp/memset, maybe try static linking (what > is the licensing of that?) or link to msvcr*.dll. > > Maybe see if I can configure to use mingwin to compile/link except > for m3cc. That sounds excellent. > You would configure a CYGWIN_ROOT (gcc, ld, make, sh, libs) and a > MINGWIN_ROOT (gcc, ld, libs). CYGWIN_ROOT would be required for > building m3cc, and either could be used for building anything > else. ?? That seems good, though I just thought of it, need more > time to think and investigate. > > Later.. > - Jay > > > Share life as it happens with the new Windows Live. Start sharing! From hosking at cs.purdue.edu Thu Jan 10 19:32:04 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 10 Jan 2008 13:32:04 -0500 Subject: [M3devel] nt386gnu is posix or win32? In-Reply-To: <20080110010238.GA3891@topoi.pooq.com> References: <20080107073815.DBCDD10D45C8@birch.elegosoft.com> <4F88D761-5F3F-4891-B3BD-7490FC7E7A2A@cs.purdue.edu> <20080110010238.GA3891@topoi.pooq.com> Message-ID: This echoes my desire that NT386GNU/Cygwin rely mostly on the POSIX personality of Cygwin, though threading might use win32.dll. On Jan 9, 2008, at 8:02 PM, hendrik at topoi.pooq.com wrote: > On Wed, Jan 09, 2008 at 11:08:57PM +0000, Jay wrote: >> I'm going to be rude and just throw this out there at a time when >> I probably can't discuss it or yet have enough data/diffs to matter. >> >> However, in building NT386GNU -- I can build libm3 and m3core -- >> the question arises as to if this target is "win32" or "posix'. >> Currently in the tree it is setup to be "posix", with a fair >> amount of work already done in that direction -- in particular, >> the Unix interfaces. >> >> However, I think this target is potentially an odd beast. >> Potentially it is two targets. >> I guess this mimics cygwin vs. mingwin. Exactly. >> >> The "host" is gcc. In order to build this system, one needs >> "gmake", sh, gcc probably (I'm assuming Visual C++'s compiler/ >> linker cannot build m3cg, but very maybe..). >> >> In order to build anything with this system, one needs "as", and >> most likely ld. >> (I quote "as" because it is an English word and confusing to >> read otherwise.) >> Changing it to output assembly for masm or even Visual C++'s >> inline __asm is probably actually viable, but not a tiny short >> term task. >> (Or maybe writing an as clone that outputs .objs? Maybe using nasm/ >> yasm??? Not sure the point, maybe "as" is perfectly ok.) >> >> And then the question arises as to what it takes to run the output. >> As I've said in other topics, the C runtime dependency of Modula-3 >> is light -- startup code mainly, but, yeah, also important setjmp/ >> longjmp, and multiplication/division helpers sometimes. This could >> perhaps all be statically linked. Certainly for Visual C++ it can be. >> (NOTE: The Cygwin jmp_buf is much larger than Visual C++'s. A >> THOUGHT is to grow them to the same, for object code >> compatibility, but probably not useful, and very wasteful, >> Cygwin's is much larger, the data in the existing code I verified >> is correct, like 0x40 vs. 0xD0 I think it was, I just did printf("% >> x", sizeof(jmp_buf)).) >> >> To get m3core to build, I switched NT386GNU to use Win32 threads. >> For THAT to build, I switched OSTYPE to Win32. Overkill perhaps, >> in order to get the Win32 *.i3 files. >> Overkill perhaps, but it does build. >> >> I fully suspect that old style Posix threads can work easily, and >> that pthreads can work easily, increasing the dependency on >> cygwin1.dll. >> While this is the "other" direction, given the dependency on as, >> and gcc to build m3cg, probably the horse is out of the barn. >> This is arguably a simpler answer, less hybrid. >> >> I think the analogy to cygwin/mingwin holds, possibly perfectly. >> >> Maybe this is two targets. >> NT386CYGWIN ? >> NT386MINGWIN ? >> >> (Which begs the point -- target naming.... NT386 vs. PPC_LINUX...OS >> +ARCH vs. ARCH + _ + OS, etc... but ARCH and OS aren't it, there >> is toolchain and C runtime in the mix..) >> >> Obviously SOMETHING is better than NOTHING and I have no useful >> binary distribution yet to show, so these questions are all very >> premature. >> >> I'm also unsure as to the "seriousness" of using the GNU tools. >> a) There don't seem to be many users of Modula-3 on Win32. >> b) Will such users accept/trust a non Microsoft toolchain? >> (Just what to do folks do with cygwin/mingwin? Build/ship real >> software?) > > One of my reasons for using m3 long ago was that I could write > programs > that would run on both Linux and Windows *without* using the Microsoft > tools, which I did not possess. > > -- hendrik From jayk123 at hotmail.com Thu Jan 10 20:48:15 2008 From: jayk123 at hotmail.com (Jay) Date: Thu, 10 Jan 2008 19:48:15 +0000 Subject: [M3devel] could someone add __stdcall name mangling to m3cc please? In-Reply-To: <70EC0898-EE63-4C19-8C28-EC72E2B73B31@cs.purdue.edu> References: Your message of "Wed, 09 Jan 2008 17:25:31 PST." <200801100131.m0A1VQYS034516@camembert.async.caltech.edu> <70EC0898-EE63-4C19-8C28-EC72E2B73B31@cs.purdue.edu> Message-ID: > CC: m3devel at elegosoft.com > From: hosking at cs.purdue.edu > > Do we have a version of the gcc-based backend that *ever* supported > the calling conventions? I don't know, but I theorize no. - Jay _________________________________________________________________ Share life as it happens with the new Windows Live. http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Thu Jan 10 20:55:15 2008 From: jayk123 at hotmail.com (Jay) Date: Thu, 10 Jan 2008 19:55:15 +0000 Subject: [M3devel] could someone add __stdcall name mangling to m3cc please? In-Reply-To: <6D677FCA-D704-4E84-BD58-893C71D97B59@cs.purdue.edu> References: Your message of "Wed, 09 Jan 2008 17:25:31 PST." <200801100131.m0A1VQYS034516@camembert.async.caltech.edu> <6D677FCA-D704-4E84-BD58-893C71D97B59@cs.purdue.edu> Message-ID: > CC: m3devel at elegosoft.com > From: hosking at cs.purdue.edu > > On Jan 10, 2008, at 7:42 AM, Jay wrote: > > > PM3 appears to ignore call_conv. > > Perhaps its NT386GNU uses usermode threads via cygwin1.dll and has > > no gui support, such as to not import any __stdcall functions??? > > Probably, yes. CM3 were the ones who added gui support. Anyway, I > think it is simply a matter of adding the appropriate attribute to > the function decls in the gcc backend. I believe that it supports > cdecl and stdcall. Are these all we need to specify? Digital added GUI support, but that doesn't necessary matter. PM3 might have dropped or broken it -- well, at least the NT386GNU target, not NT386. Good point, attributes, not name. __cdecl and __stdcall will suffice, yes. There is __fastcall but the M3 front end doesn't support it. The M3 front end only supports __cdecl and __stdcall, and various synonyms thereof, but it just resolves to 0 and 1, I think 0 is __cdecl. Look for "NTCall" in the source, or "stdcall" on the front end. It's pretty clear. If I knew how to easily "build things properly" "but get a preprocessed file", that is, add -E to the proper place, I would have preprocessed parse.c to get an idea how to...well...add the stuff to the name, which isn't the right fix anyway. As two where the char* or char[] is is buried in macros.. (e.g. CodeWarrior implements this well, right click a file and say "preprocess" or "disassemble") - Jay _________________________________________________________________ Put your friends on the big screen with Windows Vista? + Windows Live?. http://www.microsoft.com/windows/shop/specialoffers.mspx?ocid=TXT_TAGLM_CPC_MediaCtr_bigscreen_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney.bates at wichita.edu Thu Jan 10 22:39:57 2008 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Thu, 10 Jan 2008 15:39:57 -0600 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <20080108011658.dp4d4zumw4wwkg88@mail.elegosoft.com> References: <20080107073815.DBCDD10D45C8@birch.elegosoft.com> <4F88D761-5F3F-4891-B3BD-7490FC7E7A2A@cs.purdue.edu> <20080108011658.dp4d4zumw4wwkg88@mail.elegosoft.com> Message-ID: <478690AD.5000104@wichita.edu> My practice is to let the actual expression do the explaining to the reader, if it can do that, otherwise, give the formal name in a keyword binding. For example, if the actual is a (boolean-typed) variable named "IsEmpty", that alone probably suggests what the meaning of the parameter is. OTOH, if the actual is "TRUE", then I would code "IsEmpty := TRUE". > Quoting Jay : > >> Style tangent: Have people heard the advise that boolean parameters >> are bad, because at the callsite esp. they don't give much meaning? >> What is TRUE? What is FALSE? Enums or named parameters are clearer. > > -- ------------------------------------------------------------- Rodney 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 Thu Jan 10 22:31:16 2008 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Thu, 10 Jan 2008 15:31:16 -0600 Subject: [M3devel] M3 concerns In-Reply-To: <20080105011335.n767h3zbz4gcgk4k@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> Message-ID: <47868EA4.6090407@wichita.edu> I have been inside pickles a few times, so I might be the logical person to do this. All the infrastructure is there to convert integer sizes, but I expect detection of the fingerprint for LONGINT and determining its size will need a bit of work. Olaf Wagner wrote: > I know that it should run this way, but pickles for example wouldn't > be exchangeable then, would they? Has anybody tested pickle support > for LONGINT yet? > -- ------------------------------------------------------------- Rodney 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 Thu Jan 10 22:58:36 2008 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Thu, 10 Jan 2008 15:58:36 -0600 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <20080107192048.3FFBB10D461D@birch.elegosoft.com> References: <20080107192048.3FFBB10D461D@birch.elegosoft.com> Message-ID: <4786950C.6020502@wichita.edu> Antony, I can' tell from your posts whether this is what you did or not, but: m3gdb really needs for there to be a static link allocated space and stored, for _every_ nested procedure, even if there is nothing in the compiled code that uses it. m3gdb accesses/passes static links in several situations, e.g., a user-typed call on a nested procedure constant, user-typed assignment of a nested procedure value to a procedure variable, user-typed call on a procedure variable (whose value might be nested or top-level), and just access to a variable that is nonlocal to the current frame. All of this has been implemented for some time, although it is distressingly fragile. I have a number of times gone back in and fixed some case I thought I had working earlier. I recently started seeing "invalid static link" messages again from m3gdb, after a hiatus. The variable access function is particularly important to me, as I often use nested procedures, especially a recursive nested procedure inside a parent that holds variables that are local to the whole recursive (dynamic) nest but not fully global. Especially when the recursion is umpteen levels deep, it is a real pain to have to figure out how many levels to go "up" in the dynamic chain just to get to the immediate static parent to print one of its variables. And if you want to type a expression that mixes a local and a nonlocal variable, the feature is almost essential. So, I propose static links be there always, with the possible exception of at very high optimization levels. Antony Hosking wrote: > CVSROOT: /usr/cvs > Changes by: hosking at birch. 08/01/07 20:20:48 > > Modified files: > cm3/m3-sys/m3cc/gcc/gcc/: tree-nested.c > cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c > > Log message: > Fix bug in procedure value comparison as revealed by p035 of m3tests. > The problem was that convert_all_function_calls was marking nested function > decls as *not* needing a static chain (DECL_NO_STATIC_CHAIN) when their bodies > and other nested procedures within them did not refer to any of their > variables. In Modula-3 we still need the static chain (ie, procedure > environment) for procedure values so that they can be compared (tested > for equality) properly. See the M3 language specification for details of > procedure types, which define a procedure as a triple, including its > environment. The fix makes use of DECL_NONLOCAL on function decls to mark > them as needing the static chain to be preserved whenever a STATIC_CHAIN_EXPR > is created for the decl. > > -- ------------------------------------------------------------- Rodney 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 Jan 11 02:39:33 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 10 Jan 2008 20:39:33 -0500 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <4786950C.6020502@wichita.edu> References: <20080107192048.3FFBB10D461D@birch.elegosoft.com> <4786950C.6020502@wichita.edu> Message-ID: <79F0BFF3-15DB-48BF-A7D4-B5C6CEA3FF7A@cs.purdue.edu> This is easy enough to fix. I'll get to it tomorrow. On Jan 10, 2008, at 4:58 PM, Rodney M. Bates wrote: > Antony, I can' tell from your posts whether this is what you did or > not, but: > > m3gdb really needs for there to be a static link allocated space > and stored, for > _every_ nested procedure, even if there is nothing in the compiled > code that uses > it. m3gdb accesses/passes static links in several situations, > e.g., a user-typed > call on a nested procedure constant, user-typed assignment of a > nested procedure > value to a procedure variable, user-typed call on a procedure > variable (whose > value might be nested or top-level), and just access to a variable > that is nonlocal > to the current frame. > > All of this has been implemented for some time, although it is > distressingly > fragile. I have a number of times gone back in and fixed some case > I thought > I had working earlier. I recently started seeing "invalid static > link" messages > again from m3gdb, after a hiatus. > > The variable access function is particularly important to me, as I > often use nested > procedures, especially a recursive nested procedure inside a parent > that holds variables > that are local to the whole recursive (dynamic) nest but not fully > global. Especially when > the recursion is umpteen levels deep, it is a real pain to have to > figure out how > many levels to go "up" in the dynamic chain just to get to the > immediate static parent > to print one of its variables. And if you want to type a expression > that mixes a local > and a nonlocal variable, the feature is almost essential. > > So, I propose static links be there always, with the possible > exception of at very > high optimization levels. > > > > Antony Hosking wrote: >> CVSROOT: /usr/cvs >> Changes by: hosking at birch. 08/01/07 20:20:48 >> Modified files: >> cm3/m3-sys/m3cc/gcc/gcc/: tree-nested.c cm3/m3-sys/m3cc/gcc/gcc/ >> m3cg/: parse.c Log message: >> Fix bug in procedure value comparison as revealed by p035 of >> m3tests. >> The problem was that convert_all_function_calls was marking >> nested function >> decls as *not* needing a static chain (DECL_NO_STATIC_CHAIN) when >> their bodies >> and other nested procedures within them did not refer to any of >> their >> variables. In Modula-3 we still need the static chain (ie, >> procedure >> environment) for procedure values so that they can be compared >> (tested >> for equality) properly. See the M3 language specification for >> details of >> procedure types, which define a procedure as a triple, including its >> environment. The fix makes use of DECL_NONLOCAL on function >> decls to mark >> them as needing the static chain to be preserved whenever a >> STATIC_CHAIN_EXPR >> is created for the decl. > > -- > ------------------------------------------------------------- > Rodney 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 Jan 11 08:36:20 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 11 Jan 2008 08:36:20 +0100 Subject: [M3devel] CVS repo changed, was: Re: scripts/pkgs In-Reply-To: References: Message-ID: <20080111083620.zxhq9ylw08ogw0oc@mail.elegosoft.com> Quoting Jay : > Please do "something" about this directory I created. > Like very much delete/obliterate it. If the history can be renamed > to another directory, say, pkginfo maybe, ok. > The files are all deleted but might be worth bringing back at some > point, maybe. > > On a case insensitive file system, this directory conflicts with the > PKGS file. > This was totally my fault and stupid. I was thinking "PKGS" was > named "PKGSDB", but that's just the variable name, and I should have > checked. I've moved cm3/scripts/pkgs to cm3/scripts/pkgs-obsolete on birch. This will break existing workspaces which contain it; you'll have to remove and update it, or edit CVS/Entries. If you use -P for checkout and update, empty directories will be removed on-the-fly. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Fri Jan 11 09:18:23 2008 From: mika at async.caltech.edu (Mika Nystrom) Date: Fri, 11 Jan 2008 00:18:23 -0800 Subject: [M3devel] nt386gnu is posix or win32? In-Reply-To: Your message of "Thu, 10 Jan 2008 08:35:05 PST." <6A267174-E215-48A6-BD0D-CB9AF4C13FE5@darko.org> Message-ID: <200801110818.m0B8IN44005691@camembert.async.caltech.edu> That program I talked about that I build under PM3/Klagenfurt, NT386GNU, is a multi-threaded real-time financial application that, at times, trades over a million dollars an hour's worth of stocks. It doesn't run on Windows for any technical reason. If it were completely up to me, it wouldn't. But I am still glad that Modula-3 works on Windows. Mika Darko writes: > >On 10/01/2008, at 3:16 AM, Jay wrote: >> By "serious" I mean, "ship real software using it". > >Then the question is: what is' real' software. I've shipped commercial >software (a smallish application) using the existing native back end, >which doesn't produce very good code, but the performance was >adequate. For many other applications this won't be the case. > >You should look at this issue the other way around: If it allows >people to build 'serious' software, they will use it. If you have an >interest in Windows and M3, this would be one of the most useful >things you could do, IMHO. > >Darko. From mika at async.caltech.edu Fri Jan 11 09:23:42 2008 From: mika at async.caltech.edu (Mika Nystrom) Date: Fri, 11 Jan 2008 00:23:42 -0800 Subject: [M3devel] could someone add __stdcall name mangling to m3cc please? In-Reply-To: Your message of "Thu, 10 Jan 2008 12:52:35 EST." <6D677FCA-D704-4E84-BD58-893C71D97B59@cs.purdue.edu> Message-ID: <200801110823.m0B8NgIn005977@camembert.async.caltech.edu> Hmm my Klagenfurt distribution of PM3 has a bunch of Trestle things in it. mentor even works sometimes. But I am not sure exactly when it came out or what kinds of tricks they were doing in the backend. One can track it down by following the link in an email I sent yesterday or the day before, but it's a binary distribution. Mika Tony Hosking writes: > >On Jan 10, 2008, at 7:42 AM, Jay wrote: > >> PM3 appears to ignore call_conv. >> Perhaps its NT386GNU uses usermode threads via cygwin1.dll and has >> no gui support, such as to not import any __stdcall functions??? > >Probably, yes. CM3 were the ones who added gui support. Anyway, I >think it is simply a matter of adding the appropriate attribute to >the function decls in the gcc backend. I believe that it supports >cdecl and stdcall. Are these all we need to specify? > >> http://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/m3/pm3/language/ >> modula3/m3compiler/m3cc/gcc/gcc/m3cg/m3.c?rev=1.1;content-type=text% >> 2Fx-cvsweb-markup;cvsroot=PM3 >> >> - Jay >> >> From: jayk123 at hotmail.com >> To: m3devel at elegosoft.com >> Date: Thu, 10 Jan 2008 12:40:22 +0000 >> Subject: [M3devel] could someone add __stdcall name mangling to >> m3cc please? >> >> Could someone out there (Tony?) familiar with the gcc backend >> have it not ignore call_conv and if call_conv is 1, append >> an at symbol and the number of bytes of parameters to the function >> name? >> (Even for zero, e.g. Sleep at 0, GetFileAttributes at 4). >> This would be I guess at least for "imported" functions. >> >> Not clear about calling function pointers, probably needs >> modification. >> call_conv 0 is "__cdecl" is push right to left, caller cleans up >> call_conv 1 is "__stdcall" is push right to left, callee cleans up >> There are various synonyms. >> With no command line switches, __cdecl is the compiler default. >> __stdcall is deemed more efficient, and is very widely used. >> >> Not clear about functions implemented in Modula-3. >> Probably won't occur? Maybe for callbacks? WindowProcs, thread >> entry point? >> >> This could/should be for NT386GNU only. >> The hypothetical other NT targets only have one calling convention >> each. >> >> I COULD do something sleazy here and generate little adapter >> functions, over in m3-win/import-libs esp. >> >> I'm still checking out pm3 to see what it does here. >> (as in cvs checkout, not "looking at") >> >> This'll clear up: >> >> RTOS.m3:27: undefined reference to `_FatalExit' >> RTOS.mo: In function `RTOS__GetMemory': >> RTOS.m3:75: undefined reference to `_VirtualAlloc' >> RTOS.m3:85: undefined reference to `_VirtualAlloc' >> RTOS.mo: In function `RTOS__InitMemory': >> RTOS.m3:96: undefined reference to `_VirtualAlloc' >> RTOS.m3:100: undefined reference to `_GetSystemInfo' >> RTOS.mo: In function `RTOS__Write': >> RTOS.m3:118: undefined reference to `_AllocConsole' >> RTOS.m3:119: undefined reference to `_GetStdHandle' >> RTOS.m3:122: undefined reference to `_WriteFile' >> RTPerfTool.mo: In function `RTPerfTool__Start': >> RTPerfTool.m3:19: undefined reference to `_ReadFile' >> RTPerfTool.m3:22: undefined reference to `_CloseHandle' >> RTPerfTool.mo: In function `RTPerfTool__Close': >> RTPerfTool.m3:28: undefined reference to `_CloseHandle' >> RTPerfTool.mo: In function `RTPerfTool__Send': >> RTPerfTool.m3:34: undefined reference to `_WriteFile' >> RTPerfTool.mo: In function `RTPerfTool__PrepHandle': >> RTPerfTool.m3:58: undefined reference to `_GetCurrentProcess' >> RTPerfTool.m3:59: undefined reference to `_DuplicateHandle' >> etc. >> >> I did think I was past these. I thought I built m3core and libm3 >> including linking (having even modified cm3.cfg) >> COULD be I'm using the wrong .libs, but: >> >> C:\cygwin\lib\w32api>nm libkernel32.a | findstr CreateFile >> 00000000 I __imp__CreateFileW at 28 >> 00000000 T _CreateFileW at 28 >> 00000000 I __imp__CreateFileMappingW at 24 >> 00000000 T _CreateFileMappingW at 24 >> 00000000 I __imp__CreateFileMappingA at 24 >> 00000000 T _CreateFileMappingA at 24 >> 00000000 I __imp__CreateFileA at 28 >> 00000000 T _CreateFileA at 28 >> >> C:\cygwin\lib\w32api>cd \MinGW\lib >> >> C:\MinGW\lib>nm libkernel32.a | findstr CreateFile >> 00000000 I __imp__CreateFileW at 28 >> 00000000 T _CreateFileW at 28 >> 00000000 I __imp__CreateFileMappingW at 24 >> 00000000 T _CreateFileMappingW at 24 >> 00000000 I __imp__CreateFileMappingA at 24 >> 00000000 T _CreateFileMappingA at 24 >> 00000000 I __imp__CreateFileA at 28 >> 00000000 T _CreateFileA at 28 >> >> I think at least THREE calling conventions should be supported -- >> __cdecl, __stdcall, __fastcall -- >> but oh well. We can live without __fastcall. >> Watcom has another calling convention, "watcall", and they let you >> describe calling conventions with #pragmas, neat. >> >> Thanks, >> - Jay >> >> Share life as it happens with the new Windows Live. Start sharing! >> Get the power of Windows + Web with the new Windows Live. Get it now! From mika at async.caltech.edu Fri Jan 11 09:25:22 2008 From: mika at async.caltech.edu (Mika Nystrom) Date: Fri, 11 Jan 2008 00:25:22 -0800 Subject: [M3devel] nt386gnu is posix or win32? In-Reply-To: Your message of "Thu, 10 Jan 2008 13:30:55 EST." Message-ID: <200801110825.m0B8PMSW006110@camembert.async.caltech.edu> ThreadWin32, I think. That's supposed to be one of the benefits of using Modula-3 under Windows :-) Tony Hosking writes: > >On Jan 9, 2008, at 6:08 PM, Jay wrote: ... >> that pthreads can work easily, increasing the dependency on >> cygwin1.dll. > >User-level (ThreadPosix) threads might work (using setjmp/longjmp for >thread switching -- I guess that is what PM3 used to do). Or did it >use ThreadWin32? I doubt ThreadPThread will work since I don't >think there is a pthreads binding for Win32 threads on NT, or is there? > >> While this is the "other" direction, given the dependency on as, >> and gcc to build m3cg, probably the horse is out of the barn. >> This is arguably a simpler answer, less hybrid. > >My strong preference is to tread NT386GNU (i.e., Cygwin based) as a >POSIX target, which might happen to use ThreadWin32. That way, the >usual POSIX/Cygwin flavor of things is preserved. > >> >> >> I think the analogy to cygwin/mingwin holds, possibly perfectly. >> >> Maybe this is two targets. >> NT386CYGWIN ? >> NT386MINGWIN ? >> >> (Which begs the point -- target naming.... NT386 vs. PPC_LINUX...OS >> +ARCH vs. ARCH + _ + OS, etc... but ARCH and OS aren't it, there is >> toolchain and C runtime in the mix..) >> >> Obviously SOMETHING is better than NOTHING and I have no useful >> binary distribution yet to show, so these questions are all very >> premature. >> >> I'm also unsure as to the "seriousness" of using the GNU tools. >> a) There don't seem to be many users of Modula-3 on Win32. >> b) Will such users accept/trust a non Microsoft toolchain? >> (Just what to do folks do with cygwin/mingwin? Build/ship real >> software?) >> >> From my point of view, the attractive thing about m3cg is I get the >> int64 stuff arguably out of the way easier. :) >> >> Licensing wise..probably a dependency on cygwin1.dll is not desirable. >> >> When I'm further along, er, actually, with my existing libm3.dll/ >> m3core.dll, I can see what the dependencies are. >> If it's just setjmp/lonjmp/memset, maybe try static linking (what >> is the licensing of that?) or link to msvcr*.dll. >> >> Maybe see if I can configure to use mingwin to compile/link except >> for m3cc. That sounds excellent. >> You would configure a CYGWIN_ROOT (gcc, ld, make, sh, libs) and a >> MINGWIN_ROOT (gcc, ld, libs). CYGWIN_ROOT would be required for >> building m3cc, and either could be used for building anything >> else. ?? That seems good, though I just thought of it, need more >> time to think and investigate. >> >> Later.. >> - Jay >> >> >> Share life as it happens with the new Windows Live. Start sharing! From mika at async.caltech.edu Fri Jan 11 09:32:56 2008 From: mika at async.caltech.edu (Mika Nystrom) Date: Fri, 11 Jan 2008 00:32:56 -0800 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: Your message of "Thu, 10 Jan 2008 15:58:36 CST." <4786950C.6020502@wichita.edu> Message-ID: <200801110832.m0B8Wuwg006472@camembert.async.caltech.edu> This reminds me, there used to be a bug in PM3... has it been fixed? This code was unreliable: PROCEDURE P() = VAR a : T; PROCEDURE Q(b : U) = BEGIN a := saveSomethingAbout(b) END Q; BEGIN CallVisitor(Q) END P; (Note that the M3 report says that while inner procedures may not be assigned to variables, they may be passed as procedure parameters. The workaround for the compiler bug is to use something called "object-oriented programming".) "Rodney M. Bates" writes: >Antony, I can' tell from your posts whether this is what you did or not, but: > >m3gdb really needs for there to be a static link allocated space and stored, for >_every_ nested procedure, even if there is nothing in the compiled code that uses >it. m3gdb accesses/passes static links in several situations, e.g., a user-typed >call on a nested procedure constant, user-typed assignment of a nested procedure >value to a procedure variable, user-typed call on a procedure variable (whose >value might be nested or top-level), and just access to a variable that is nonlocal >to the current frame. > >All of this has been implemented for some time, although it is distressingly >fragile. I have a number of times gone back in and fixed some case I thought >I had working earlier. I recently started seeing "invalid static link" messages >again from m3gdb, after a hiatus. > >The variable access function is particularly important to me, as I often use nested >procedures, especially a recursive nested procedure inside a parent that holds variables >that are local to the whole recursive (dynamic) nest but not fully global. Especially when >the recursion is umpteen levels deep, it is a real pain to have to figure out how >many levels to go "up" in the dynamic chain just to get to the immediate static parent >to print one of its variables. And if you want to type a expression that mixes a local >and a nonlocal variable, the feature is almost essential. > >So, I propose static links be there always, with the possible exception of at very >high optimization levels. > > > >Antony Hosking wrote: >> CVSROOT: /usr/cvs >> Changes by: hosking at birch. 08/01/07 20:20:48 >> >> Modified files: >> cm3/m3-sys/m3cc/gcc/gcc/: tree-nested.c >> cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c >> >> Log message: >> Fix bug in procedure value comparison as revealed by p035 of m3tests. >> The problem was that convert_all_function_calls was marking nested function >> decls as *not* needing a static chain (DECL_NO_STATIC_CHAIN) when their bodies >> and other nested procedures within them did not refer to any of their >> variables. In Modula-3 we still need the static chain (ie, procedure >> environment) for procedure values so that they can be compared (tested >> for equality) properly. See the M3 language specification for details of >> procedure types, which define a procedure as a triple, including its >> environment. The fix makes use of DECL_NONLOCAL on function decls to mark >> them as needing the static chain to be preserved whenever a STATIC_CHAIN_EXPR >> is created for the decl. >> >> > >-- >------------------------------------------------------------- >Rodney 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 Jan 11 12:36:14 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 11 Jan 2008 12:36:14 +0100 Subject: [M3devel] M3 project references, was: Re: nt386gnu is posix or win32? In-Reply-To: <200801110818.m0B8IN44005691@camembert.async.caltech.edu> References: <200801110818.m0B8IN44005691@camembert.async.caltech.edu> Message-ID: <20080111123614.txul50nyqs80oowg@mail.elegosoft.com> Quoting Mika Nystrom : > That program I talked about that I build under PM3/Klagenfurt, > NT386GNU, is a multi-threaded real-time financial application that, > at times, trades over a million dollars an hour's worth of stocks. > It doesn't run on Windows for any technical reason. If it were > completely up to me, it wouldn't. But I am still glad that Modula-3 > works on Windows. Cool. I didn't know that M3 was really used in such commercial projects. It would be great if we had a list of such projects on our web site as references. Would that be possible with your program/customer? Are there other commercial projects we could mention? Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Fri Jan 11 13:32:24 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 11 Jan 2008 13:32:24 +0100 Subject: [M3devel] Darwin upgrade/fingerprint error In-Reply-To: References: <20080104141523.GC1459@ted.stsp.lan> <65C183A8-6102-49E9-9C38-8D59C966E42D@cs.purdue.edu> Message-ID: <20080111133224.kpsd1ehwso4go048@mail.elegosoft.com> Quoting Jay : > (probably OMIT_GCC=1 on the second clean and build; I assume it has > no dependency into the tree and it'd just be building the same thing > a second time, slowly) Late answer, but I can hardly catch up with all the mail I get. Even CM3 is so active these days (which is a good thing :). You are right, m3cc does not depend on any other CM3 package and needs to be built just once. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From hosking at cs.purdue.edu Fri Jan 11 16:17:00 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 11 Jan 2008 10:17:00 -0500 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <200801110832.m0B8Wuwg006472@camembert.async.caltech.edu> References: <200801110832.m0B8Wuwg006472@camembert.async.caltech.edu> Message-ID: <85B79C0A-B69E-4E12-B938-6A374398568D@cs.purdue.edu> Certainly fixed in CM3. On Jan 11, 2008, at 3:32 AM, Mika Nystrom wrote: > This reminds me, there used to be a bug in PM3... has it been > fixed? This code > was unreliable: > > PROCEDURE P() = > > VAR a : T; > > PROCEDURE Q(b : U) = > BEGIN a := saveSomethingAbout(b) END Q; > > BEGIN CallVisitor(Q) END P; > > (Note that the M3 report says that while inner procedures may not > be assigned to variables, they may be passed as procedure parameters. > The workaround for the compiler bug is to use something called > "object-oriented programming".) > > "Rodney M. Bates" writes: >> Antony, I can' tell from your posts whether this is what you did >> or not, but: >> >> m3gdb really needs for there to be a static link allocated space >> and stored, for >> _every_ nested procedure, even if there is nothing in the compiled >> code that uses >> it. m3gdb accesses/passes static links in several situations, >> e.g., a user-typed >> call on a nested procedure constant, user-typed assignment of a >> nested procedure >> value to a procedure variable, user-typed call on a procedure >> variable (whose >> value might be nested or top-level), and just access to a variable >> that is nonlocal >> to the current frame. >> >> All of this has been implemented for some time, although it is >> distressingly >> fragile. I have a number of times gone back in and fixed some >> case I thought >> I had working earlier. I recently started seeing "invalid static >> link" messages >> again from m3gdb, after a hiatus. >> >> The variable access function is particularly important to me, as I >> often use nested >> procedures, especially a recursive nested procedure inside a >> parent that holds variables >> that are local to the whole recursive (dynamic) nest but not fully >> global. Especially when >> the recursion is umpteen levels deep, it is a real pain to have to >> figure out how >> many levels to go "up" in the dynamic chain just to get to the >> immediate static parent >> to print one of its variables. And if you want to type a >> expression that mixes a local >> and a nonlocal variable, the feature is almost essential. >> >> So, I propose static links be there always, with the possible >> exception of at very >> high optimization levels. >> >> >> >> Antony Hosking wrote: >>> CVSROOT: /usr/cvs >>> Changes by: hosking at birch. 08/01/07 20:20:48 >>> >>> Modified files: >>> cm3/m3-sys/m3cc/gcc/gcc/: tree-nested.c >>> cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c >>> >>> Log message: >>> Fix bug in procedure value comparison as revealed by p035 of >>> m3tests. >>> The problem was that convert_all_function_calls was marking >>> nested function >>> decls as *not* needing a static chain (DECL_NO_STATIC_CHAIN) >>> when their bodies >>> and other nested procedures within them did not refer to any of >>> their >>> variables. In Modula-3 we still need the static chain (ie, >>> procedure >>> environment) for procedure values so that they can be compared >>> (tested >>> for equality) properly. See the M3 language specification for >>> details of >>> procedure types, which define a procedure as a triple, including >>> its >>> environment. The fix makes use of DECL_NONLOCAL on function >>> decls to mark >>> them as needing the static chain to be preserved whenever a >>> STATIC_CHAIN_EXPR >>> is created for the decl. >>> >>> >> >> -- >> ------------------------------------------------------------- >> Rodney 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 Jan 11 18:10:36 2008 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Fri, 11 Jan 2008 11:10:36 -0600 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <200801110832.m0B8Wuwg006472@camembert.async.caltech.edu> References: <200801110832.m0B8Wuwg006472@camembert.async.caltech.edu> Message-ID: <4787A30C.3060709@wichita.edu> I use what I think is the pattern you refer to regularly. A callback "visit" procedure (which is nested) is passed as a parameter and it accesses nonlocal variables. I just reran a test driver main program that does massive tests of a particular module and uses this pattern extensively. No problems showed up, using PM3 integrated backend, PM3 with gcc backend, and a recent CM3. I still run a lot of stuff PM3-compiled, but my PM3 has somehow diverged significantly from the official distribution, and every time I start to resolve this, it quickly gets a lot deeper than I want to take time for. Mika Nystrom wrote: > This reminds me, there used to be a bug in PM3... has it been fixed? This code > was unreliable: > > PROCEDURE P() = > > VAR a : T; > > PROCEDURE Q(b : U) = > BEGIN a := saveSomethingAbout(b) END Q; > > BEGIN CallVisitor(Q) END P; > > (Note that the M3 report says that while inner procedures may not > be assigned to variables, they may be passed as procedure parameters. > The workaround for the compiler bug is to use something called > "object-oriented programming".) > -- ------------------------------------------------------------- Rodney 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 Jan 11 19:16:44 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 11 Jan 2008 13:16:44 -0500 Subject: [M3devel] could someone add __stdcall name mangling to m3cc please? In-Reply-To: References: Your message of "Wed, 09 Jan 2008 17:25:31 PST." <200801100131.m0A1VQYS034516@camembert.async.caltech.edu> Message-ID: <6D467648-44A7-48DC-AB8D-27B3AC19EBB0@cs.purdue.edu> I just added support for this. Let me know if it seems to work (or not! :-) ). On Jan 10, 2008, at 7:40 AM, Jay wrote: > Could someone out there (Tony?) familiar with the gcc backend > have it not ignore call_conv and if call_conv is 1, append > an at symbol and the number of bytes of parameters to the function > name? > (Even for zero, e.g. Sleep at 0, GetFileAttributes at 4). > This would be I guess at least for "imported" functions. > > Not clear about calling function pointers, probably needs > modification. > call_conv 0 is "__cdecl" is push right to left, caller cleans up > call_conv 1 is "__stdcall" is push right to left, callee cleans up > There are various synonyms. > With no command line switches, __cdecl is the compiler default. > __stdcall is deemed more efficient, and is very widely used. > > Not clear about functions implemented in Modula-3. > Probably won't occur? Maybe for callbacks? WindowProcs, thread > entry point? > > This could/should be for NT386GNU only. > The hypothetical other NT targets only have one calling convention > each. > > I COULD do something sleazy here and generate little adapter > functions, over in m3-win/import-libs esp. > > I'm still checking out pm3 to see what it does here. > (as in cvs checkout, not "looking at") > > This'll clear up: > > RTOS.m3:27: undefined reference to `_FatalExit' > RTOS.mo: In function `RTOS__GetMemory': > RTOS.m3:75: undefined reference to `_VirtualAlloc' > RTOS.m3:85: undefined reference to `_VirtualAlloc' > RTOS.mo: In function `RTOS__InitMemory': > RTOS.m3:96: undefined reference to `_VirtualAlloc' > RTOS.m3:100: undefined reference to `_GetSystemInfo' > RTOS.mo: In function `RTOS__Write': > RTOS.m3:118: undefined reference to `_AllocConsole' > RTOS.m3:119: undefined reference to `_GetStdHandle' > RTOS.m3:122: undefined reference to `_WriteFile' > RTPerfTool.mo: In function `RTPerfTool__Start': > RTPerfTool.m3:19: undefined reference to `_ReadFile' > RTPerfTool.m3:22: undefined reference to `_CloseHandle' > RTPerfTool.mo: In function `RTPerfTool__Close': > RTPerfTool.m3:28: undefined reference to `_CloseHandle' > RTPerfTool.mo: In function `RTPerfTool__Send': > RTPerfTool.m3:34: undefined reference to `_WriteFile' > RTPerfTool.mo: In function `RTPerfTool__PrepHandle': > RTPerfTool.m3:58: undefined reference to `_GetCurrentProcess' > RTPerfTool.m3:59: undefined reference to `_DuplicateHandle' > etc. > > I did think I was past these. I thought I built m3core and libm3 > including linking (having even modified cm3.cfg) > COULD be I'm using the wrong .libs, but: > > C:\cygwin\lib\w32api>nm libkernel32.a | findstr CreateFile > 00000000 I __imp__CreateFileW at 28 > 00000000 T _CreateFileW at 28 > 00000000 I __imp__CreateFileMappingW at 24 > 00000000 T _CreateFileMappingW at 24 > 00000000 I __imp__CreateFileMappingA at 24 > 00000000 T _CreateFileMappingA at 24 > 00000000 I __imp__CreateFileA at 28 > 00000000 T _CreateFileA at 28 > > C:\cygwin\lib\w32api>cd \MinGW\lib > > C:\MinGW\lib>nm libkernel32.a | findstr CreateFile > 00000000 I __imp__CreateFileW at 28 > 00000000 T _CreateFileW at 28 > 00000000 I __imp__CreateFileMappingW at 24 > 00000000 T _CreateFileMappingW at 24 > 00000000 I __imp__CreateFileMappingA at 24 > 00000000 T _CreateFileMappingA at 24 > 00000000 I __imp__CreateFileA at 28 > 00000000 T _CreateFileA at 28 > > I think at least THREE calling conventions should be supported -- > __cdecl, __stdcall, __fastcall -- > but oh well. We can live without __fastcall. > Watcom has another calling convention, "watcall", and they let you > describe calling conventions with #pragmas, neat. > > Thanks, > - Jay > > Share life as it happens with the new Windows Live. Start sharing! From hosking at cs.purdue.edu Fri Jan 11 19:24:49 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 11 Jan 2008 13:24:49 -0500 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <4786950C.6020502@wichita.edu> References: <20080107192048.3FFBB10D461D@birch.elegosoft.com> <4786950C.6020502@wichita.edu> Message-ID: Rodney, Can you confirm that the static chains are now there for your purposes with the latest m3cc? As far as I know, *any* nested procedure that might be called *will* now have a static chain generated for it. I don't think I need to make any other changes to support this. The reasoning is as follows: load_static_link is generated by the M3 front-end compiler whenever a nested function is called, and whenever a procedure value is created from a nested function -- ie, when passing a nested procedure as an actual -- since the value includes the static link as its environment. This is what fixed p035 of m3tests. -- Tony On Jan 10, 2008, at 4:58 PM, Rodney M. Bates wrote: > Antony, I can' tell from your posts whether this is what you did or > not, but: > > m3gdb really needs for there to be a static link allocated space > and stored, for > _every_ nested procedure, even if there is nothing in the compiled > code that uses > it. m3gdb accesses/passes static links in several situations, > e.g., a user-typed > call on a nested procedure constant, user-typed assignment of a > nested procedure > value to a procedure variable, user-typed call on a procedure > variable (whose > value might be nested or top-level), and just access to a variable > that is nonlocal > to the current frame. > > All of this has been implemented for some time, although it is > distressingly > fragile. I have a number of times gone back in and fixed some case > I thought > I had working earlier. I recently started seeing "invalid static > link" messages > again from m3gdb, after a hiatus. > > The variable access function is particularly important to me, as I > often use nested > procedures, especially a recursive nested procedure inside a parent > that holds variables > that are local to the whole recursive (dynamic) nest but not fully > global. Especially when > the recursion is umpteen levels deep, it is a real pain to have to > figure out how > many levels to go "up" in the dynamic chain just to get to the > immediate static parent > to print one of its variables. And if you want to type a expression > that mixes a local > and a nonlocal variable, the feature is almost essential. > > So, I propose static links be there always, with the possible > exception of at very > high optimization levels. > > > > Antony Hosking wrote: >> CVSROOT: /usr/cvs >> Changes by: hosking at birch. 08/01/07 20:20:48 >> Modified files: >> cm3/m3-sys/m3cc/gcc/gcc/: tree-nested.c cm3/m3-sys/m3cc/gcc/gcc/ >> m3cg/: parse.c Log message: >> Fix bug in procedure value comparison as revealed by p035 of >> m3tests. >> The problem was that convert_all_function_calls was marking >> nested function >> decls as *not* needing a static chain (DECL_NO_STATIC_CHAIN) when >> their bodies >> and other nested procedures within them did not refer to any of >> their >> variables. In Modula-3 we still need the static chain (ie, >> procedure >> environment) for procedure values so that they can be compared >> (tested >> for equality) properly. See the M3 language specification for >> details of >> procedure types, which define a procedure as a triple, including its >> environment. The fix makes use of DECL_NONLOCAL on function >> decls to mark >> them as needing the static chain to be preserved whenever a >> STATIC_CHAIN_EXPR >> is created for the decl. > > -- > ------------------------------------------------------------- > Rodney 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 Jan 12 01:20:04 2008 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Fri, 11 Jan 2008 18:20:04 -0600 Subject: [M3devel] I need CVS help again Message-ID: <478807B4.2080100@wichita.edu> I have gotten myself into this jam before, as a result of trying to develop/test on more than one local machine with more than one M3 installation. I have more questions on how to figure out what happened and how to fix it. I did a cvs update when, I guess, I had local uncommitted edits. I got messages saying that changes were being merged and there were conflicts. For example, I now have local files named: .#m3-eval.c.1.12 m3-eval.c and in CVS/Entries, the line: /m3-eval.c/1.14/Result of merge... Have I correctly surmised that this all means 1) prior to the update, CVS/Entries would have said: /m3-eval/c/1.12... meaning 1.12 was the last version cvs knew I had, 2) But my local m3-eval.c had local changes relative to 1.12, 3) And .#m3-eval.c.1.12 is a copy of that locally changed m3-eval.c, as it was prior to the cvs update, 4) The latest version cvs has in its repository is 1.14, and 5) My current local m3-eval.c was generated by merging version 1.14 from the repository with what is now in .#m3-eval.c.1.12? Is there a simple way to get cvs to diff between its stored version 1.12 and my .#m3-eval.1.12? -- ------------------------------------------------------------- Rodney 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 Sat Jan 12 01:22:16 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 12 Jan 2008 01:22:16 +0100 Subject: [M3devel] I need CVS help again In-Reply-To: <478807B4.2080100@wichita.edu> References: <478807B4.2080100@wichita.edu> Message-ID: <20080112012216.k4d438pquc0sw8os@mail.elegosoft.com> Quoting "Rodney M. Bates" : > I have gotten myself into this jam before, as a result of trying to > develop/test on more than one local machine with more than one M3 > installation. I have more questions on how to figure out what happened > and how to fix it. > > I did a cvs update when, I guess, I had local uncommitted edits. > I got messages saying that changes were being merged and there were > conflicts. For example, I now have local files named: > > .#m3-eval.c.1.12 > m3-eval.c > > and in CVS/Entries, the line: > > /m3-eval.c/1.14/Result of merge... > > Have I correctly surmised that this all means > > 1) prior to the update, CVS/Entries would have said: > > /m3-eval/c/1.12... > > meaning 1.12 was the last version cvs knew I had, > > 2) But my local m3-eval.c had local changes relative to 1.12, > > 3) And .#m3-eval.c.1.12 is a copy of that locally changed > m3-eval.c, as it was prior to the cvs update, Yes, this should be your original file. > 4) The latest version cvs has in its repository is 1.14, and Yes. > 5) My current local m3-eval.c was generated by merging version > 1.14 from the repository with what is now in .#m3-eval.c.1.12? Yes. You should simply find the comflicts in m3-eval.c by looking for lines with <<<< and ===== and >>>>. Often they are easy to edit manually. > Is there a simple way to get cvs to diff between its stored > version 1.12 and my .#m3-eval.1.12? You can checkout any version into your workspace and compare locally: cvs up -p -r 1.12 m3-eval.c > m3-eval.c.1.12 cvs up -p -r 1.14 m3-eval.c > m3-eval.c.1.14 diff -u .m3-eval.c.1.12 \#m3-eval.1.12 ... HTH, Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Jan 12 14:27:23 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 12 Jan 2008 13:27:23 +0000 Subject: [M3devel] could someone add __stdcall name mangling to m3cc please? In-Reply-To: <6D467648-44A7-48DC-AB8D-27B3AC19EBB0@cs.purdue.edu> References: Your message of "Wed, 09 Jan 2008 17:25:31 PST." <200801100131.m0A1VQYS034516@camembert.async.caltech.edu> <6D467648-44A7-48DC-AB8D-27B3AC19EBB0@cs.purdue.edu> Message-ID: Thanks, but not quite. The number of parameters times four needs to be appended to the name, in decimal. But I'm just getting 0. That is, gcc is handling the underlying detail, but you aren't giving it enough infomrmation. I'll see if I can bang out those temporary wrappers automatically.. (a Quake programming challenge, that I've already invented the hard part of I think -- Quake can't do math..) - Jay > CC: m3devel at elegosoft.com> From: hosking at cs.purdue.edu> Subject: Re: [M3devel] could someone add __stdcall name mangling to m3cc please?> Date: Fri, 11 Jan 2008 13:16:44 -0500> To: jayk123 at hotmail.com> > I just added support for this. Let me know if it seems to work (or > not! :-) ).> > > On Jan 10, 2008, at 7:40 AM, Jay wrote:> > > Could someone out there (Tony?) familiar with the gcc backend> > have it not ignore call_conv and if call_conv is 1, append> > an at symbol and the number of bytes of parameters to the function > > name?> > (Even for zero, e.g. Sleep at 0, GetFileAttributes at 4).> > This would be I guess at least for "imported" functions.> >> > Not clear about calling function pointers, probably needs > > modification.> > call_conv 0 is "__cdecl" is push right to left, caller cleans up> > call_conv 1 is "__stdcall" is push right to left, callee cleans up> > There are various synonyms.> > With no command line switches, __cdecl is the compiler default.> > __stdcall is deemed more efficient, and is very widely used.> >> > Not clear about functions implemented in Modula-3.> > Probably won't occur? Maybe for callbacks? WindowProcs, thread > > entry point?> >> > This could/should be for NT386GNU only.> > The hypothetical other NT targets only have one calling convention > > each.> >> > I COULD do something sleazy here and generate little adapter > > functions, over in m3-win/import-libs esp.> >> > I'm still checking out pm3 to see what it does here.> > (as in cvs checkout, not "looking at")> >> > This'll clear up:> >> > RTOS.m3:27: undefined reference to `_FatalExit'> > RTOS.mo: In function `RTOS__GetMemory':> > RTOS.m3:75: undefined reference to `_VirtualAlloc'> > RTOS.m3:85: undefined reference to `_VirtualAlloc'> > RTOS.mo: In function `RTOS__InitMemory':> > RTOS.m3:96: undefined reference to `_VirtualAlloc'> > RTOS.m3:100: undefined reference to `_GetSystemInfo'> > RTOS.mo: In function `RTOS__Write':> > RTOS.m3:118: undefined reference to `_AllocConsole'> > RTOS.m3:119: undefined reference to `_GetStdHandle'> > RTOS.m3:122: undefined reference to `_WriteFile'> > RTPerfTool.mo: In function `RTPerfTool__Start':> > RTPerfTool.m3:19: undefined reference to `_ReadFile'> > RTPerfTool.m3:22: undefined reference to `_CloseHandle'> > RTPerfTool.mo: In function `RTPerfTool__Close':> > RTPerfTool.m3:28: undefined reference to `_CloseHandle'> > RTPerfTool.mo: In function `RTPerfTool__Send':> > RTPerfTool.m3:34: undefined reference to `_WriteFile'> > RTPerfTool.mo: In function `RTPerfTool__PrepHandle':> > RTPerfTool.m3:58: undefined reference to `_GetCurrentProcess'> > RTPerfTool.m3:59: undefined reference to `_DuplicateHandle'> > etc.> >> > I did think I was past these. I thought I built m3core and libm3 > > including linking (having even modified cm3.cfg)> > COULD be I'm using the wrong .libs, but:> >> > C:\cygwin\lib\w32api>nm libkernel32.a | findstr CreateFile> > 00000000 I __imp__CreateFileW at 28> > 00000000 T _CreateFileW at 28> > 00000000 I __imp__CreateFileMappingW at 24> > 00000000 T _CreateFileMappingW at 24> > 00000000 I __imp__CreateFileMappingA at 24> > 00000000 T _CreateFileMappingA at 24> > 00000000 I __imp__CreateFileA at 28> > 00000000 T _CreateFileA at 28> >> > C:\cygwin\lib\w32api>cd \MinGW\lib> >> > C:\MinGW\lib>nm libkernel32.a | findstr CreateFile> > 00000000 I __imp__CreateFileW at 28> > 00000000 T _CreateFileW at 28> > 00000000 I __imp__CreateFileMappingW at 24> > 00000000 T _CreateFileMappingW at 24> > 00000000 I __imp__CreateFileMappingA at 24> > 00000000 T _CreateFileMappingA at 24> > 00000000 I __imp__CreateFileA at 28> > 00000000 T _CreateFileA at 28> >> > I think at least THREE calling conventions should be supported -- > > __cdecl, __stdcall, __fastcall --> > but oh well. We can live without __fastcall.> > Watcom has another calling convention, "watcall", and they let you > > describe calling conventions with #pragmas, neat.> >> > Thanks,> > - Jay> >> > Share life as it happens with the new Windows Live. Start sharing!> _________________________________________________________________ Make distant family not so distant with Windows Vista? + Windows Live?. http://www.microsoft.com/windows/digitallife/keepintouch.mspx?ocid=TXT_TAGLM_CPC_VideoChat_distantfamily_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sat Jan 12 16:41:26 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 12 Jan 2008 10:41:26 -0500 Subject: [M3devel] could someone add __stdcall name mangling to m3cc please? In-Reply-To: References: Your message of "Wed, 09 Jan 2008 17:25:31 PST." <200801100131.m0A1VQYS034516@camembert.async.caltech.edu> <6D467648-44A7-48DC-AB8D-27B3AC19EBB0@cs.purdue.edu> Message-ID: I'm not sure what you were trying to do with parse.c by adding a parameter (nargs*4) to the stdcall attribute, but that probably doesn't do anything interesting. The problem appears to be because on external function decls the parameter decls are currently being ignored by cm3cg. If I fix parse.c to add the params for those then it should work properly with the stdcall attribute. On Jan 12, 2008, at 8:27 AM, Jay wrote: > Thanks, but not quite. The number of parameters times four needs to > be appended to the name, in decimal. > But I'm just getting 0. > That is, gcc is handling the underlying detail, but you aren't > giving it enough infomrmation. > I'll see if I can bang out those temporary wrappers automatically.. > (a Quake programming challenge, that I've already invented the hard > part of I think -- Quake can't do math..) > > - Jay > > > > CC: m3devel at elegosoft.com > > From: hosking at cs.purdue.edu > > Subject: Re: [M3devel] could someone add __stdcall name mangling > to m3cc please? > > Date: Fri, 11 Jan 2008 13:16:44 -0500 > > To: jayk123 at hotmail.com > > > > I just added support for this. Let me know if it seems to work (or > > not! :-) ). > > > > > > On Jan 10, 2008, at 7:40 AM, Jay wrote: > > > > > Could someone out there (Tony?) familiar with the gcc backend > > > have it not ignore call_conv and if call_conv is 1, append > > > an at symbol and the number of bytes of parameters to the function > > > name? > > > (Even for zero, e.g. Sleep at 0, GetFileAttributes at 4). > > > This would be I guess at least for "imported" functions. > > > > > > Not clear about calling function pointers, probably needs > > > modification. > > > call_conv 0 is "__cdecl" is push right to left, caller cleans up > > > call_conv 1 is "__stdcall" is push right to left, callee cleans up > > > There are various synonyms. > > > With no command line switches, __cdecl is the compiler default. > > > __stdcall is deemed more efficient, and is very widely used. > > > > > > Not clear about functions implemented in Modula-3. > > > Probably won't occur? Maybe for callbacks? WindowProcs, thread > > > entry point? > > > > > > This could/should be for NT386GNU only. > > > The hypothetical other NT targets only have one calling convention > > > each. > > > > > > I COULD do something sleazy here and generate little adapter > > > functions, over in m3-win/import-libs esp. > > > > > > I'm still checking out pm3 to see what it does here. > > > (as in cvs checkout, not "looking at") > > > > > > This'll clear up: > > > > > > RTOS.m3:27: undefined reference to `_FatalExit' > > > RTOS.mo: In function `RTOS__GetMemory': > > > RTOS.m3:75: undefined reference to `_VirtualAlloc' > > > RTOS.m3:85: undefined reference to `_VirtualAlloc' > > > RTOS.mo: In function `RTOS__InitMemory': > > > RTOS.m3:96: undefined reference to `_VirtualAlloc' > > > RTOS.m3:100: undefined reference to `_GetSystemInfo' > > > RTOS.mo: In function `RTOS__Write': > > > RTOS.m3:118: undefined reference to `_AllocConsole' > > > RTOS.m3:119: undefined reference to `_GetStdHandle' > > > RTOS.m3:122: undefined reference to `_WriteFile' > > > RTPerfTool.mo: In function `RTPerfTool__Start': > > > RTPerfTool.m3:19: undefined reference to `_ReadFile' > > > RTPerfTool.m3:22: undefined reference to `_CloseHandle' > > > RTPerfTool.mo: In function `RTPerfTool__Close': > > > RTPerfTool.m3:28: undefined reference to `_CloseHandle' > > > RTPerfTool.mo: In function `RTPerfTool__Send': > > > RTPerfTool.m3:34: undefined reference to `_WriteFile' > > > RTPerfTool.mo: In function `RTPerfTool__PrepHandle': > > > RTPerfTool.m3:58: undefined reference to `_GetCurrentProcess' > > > RTPerfTool.m3:59: undefined reference to `_DuplicateHandle' > > > etc. > > > > > > I did think I was past these. I thought I built m3core and libm3 > > > including linking (having even modified cm3.cfg) > > > COULD be I'm using the wrong .libs, but: > > > > > > C:\cygwin\lib\w32api>nm libkernel32.a | findstr CreateFile > > > 00000000 I __imp__CreateFileW at 28 > > > 00000000 T _CreateFileW at 28 > > > 00000000 I __imp__CreateFileMappingW at 24 > > > 00000000 T _CreateFileMappingW at 24 > > > 00000000 I __imp__CreateFileMappingA at 24 > > > 00000000 T _CreateFileMappingA at 24 > > > 00000000 I __imp__CreateFileA at 28 > > > 00000000 T _CreateFileA at 28 > > > > > > C:\cygwin\lib\w32api>cd \MinGW\lib > > > > > > C:\MinGW\lib>nm libkernel32.a | findstr CreateFile > > > 00000000 I __imp__CreateFileW at 28 > > > 00000000 T _CreateFileW at 28 > > > 00000000 I __imp__CreateFileMappingW at 24 > > > 00000000 T _CreateFileMappingW at 24 > > > 00000000 I __imp__CreateFileMappingA at 24 > > > 00000000 T _CreateFileMappingA at 24 > > > 00000000 I __imp__CreateFileA at 28 > > > 00000000 T _CreateFileA at 28 > > > > > > I think at least THREE calling conventions should be supported -- > > > __cdecl, __stdcall, __fastcall -- > > > but oh well. We can live without __fastcall. > > > Watcom has another calling convention, "watcall", and they let you > > > describe calling conventions with #pragmas, neat. > > > > > > Thanks, > > > - Jay > > > > > > Share life as it happens with the new Windows Live. Start sharing! > > > > > Make distant family not so distant with Windows Vista? + Windows > Live?. Start now! From jayk123 at hotmail.com Sat Jan 12 19:13:27 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 12 Jan 2008 18:13:27 +0000 Subject: [M3devel] could someone add __stdcall name mangling to m3cc please? In-Reply-To: References: Your message of "Wed, 09 Jan 2008 17:25:31 PST." <200801100131.m0A1VQYS034516@camembert.async.caltech.edu> <6D467648-44A7-48DC-AB8D-27B3AC19EBB0@cs.purdue.edu> Message-ID: Tony, Sorry, I didn't mean to check those in. Those were wild guesses that I hadn't tested yet.I put it back. Thanks for catching that. - Jay > CC: m3devel at elegosoft.com> From: hosking at cs.purdue.edu> Subject: Re: [M3devel] could someone add __stdcall name mangling to m3cc please?> Date: Sat, 12 Jan 2008 10:41:26 -0500> To: jayk123 at hotmail.com> > I'm not sure what you were trying to do with parse.c by adding a > parameter (nargs*4) to the stdcall attribute, but that probably > doesn't do anything interesting. The problem appears to be because > on external function decls the parameter decls are currently being > ignored by cm3cg. If I fix parse.c to add the params for those then > it should work properly with the stdcall attribute.> > On Jan 12, 2008, at 8:27 AM, Jay wrote:> > > Thanks, but not quite. The number of parameters times four needs to > > be appended to the name, in decimal.> > But I'm just getting 0.> > That is, gcc is handling the underlying detail, but you aren't > > giving it enough infomrmation.> > I'll see if I can bang out those temporary wrappers automatically.. > > (a Quake programming challenge, that I've already invented the hard > > part of I think -- Quake can't do math..)> >> > - Jay> >> >> > > CC: m3devel at elegosoft.com> > > From: hosking at cs.purdue.edu> > > Subject: Re: [M3devel] could someone add __stdcall name mangling > > to m3cc please?> > > Date: Fri, 11 Jan 2008 13:16:44 -0500> > > To: jayk123 at hotmail.com> > >> > > I just added support for this. Let me know if it seems to work (or> > > not! :-) ).> > >> > >> > > On Jan 10, 2008, at 7:40 AM, Jay wrote:> > >> > > > Could someone out there (Tony?) familiar with the gcc backend> > > > have it not ignore call_conv and if call_conv is 1, append> > > > an at symbol and the number of bytes of parameters to the function> > > > name?> > > > (Even for zero, e.g. Sleep at 0, GetFileAttributes at 4).> > > > This would be I guess at least for "imported" functions.> > > >> > > > Not clear about calling function pointers, probably needs> > > > modification.> > > > call_conv 0 is "__cdecl" is push right to left, caller cleans up> > > > call_conv 1 is "__stdcall" is push right to left, callee cleans up> > > > There are various synonyms.> > > > With no command line switches, __cdecl is the compiler default.> > > > __stdcall is deemed more efficient, and is very widely used.> > > >> > > > Not clear about functions implemented in Modula-3.> > > > Probably won't occur? Maybe for callbacks? WindowProcs, thread> > > > entry point?> > > >> > > > This could/should be for NT386GNU only.> > > > The hypothetical other NT targets only have one calling convention> > > > each.> > > >> > > > I COULD do something sleazy here and generate little adapter> > > > functions, over in m3-win/import-libs esp.> > > >> > > > I'm still checking out pm3 to see what it does here.> > > > (as in cvs checkout, not "looking at")> > > >> > > > This'll clear up:> > > >> > > > RTOS.m3:27: undefined reference to `_FatalExit'> > > > RTOS.mo: In function `RTOS__GetMemory':> > > > RTOS.m3:75: undefined reference to `_VirtualAlloc'> > > > RTOS.m3:85: undefined reference to `_VirtualAlloc'> > > > RTOS.mo: In function `RTOS__InitMemory':> > > > RTOS.m3:96: undefined reference to `_VirtualAlloc'> > > > RTOS.m3:100: undefined reference to `_GetSystemInfo'> > > > RTOS.mo: In function `RTOS__Write':> > > > RTOS.m3:118: undefined reference to `_AllocConsole'> > > > RTOS.m3:119: undefined reference to `_GetStdHandle'> > > > RTOS.m3:122: undefined reference to `_WriteFile'> > > > RTPerfTool.mo: In function `RTPerfTool__Start':> > > > RTPerfTool.m3:19: undefined reference to `_ReadFile'> > > > RTPerfTool.m3:22: undefined reference to `_CloseHandle'> > > > RTPerfTool.mo: In function `RTPerfTool__Close':> > > > RTPerfTool.m3:28: undefined reference to `_CloseHandle'> > > > RTPerfTool.mo: In function `RTPerfTool__Send':> > > > RTPerfTool.m3:34: undefined reference to `_WriteFile'> > > > RTPerfTool.mo: In function `RTPerfTool__PrepHandle':> > > > RTPerfTool.m3:58: undefined reference to `_GetCurrentProcess'> > > > RTPerfTool.m3:59: undefined reference to `_DuplicateHandle'> > > > etc.> > > >> > > > I did think I was past these. I thought I built m3core and libm3> > > > including linking (having even modified cm3.cfg)> > > > COULD be I'm using the wrong .libs, but:> > > >> > > > C:\cygwin\lib\w32api>nm libkernel32.a | findstr CreateFile> > > > 00000000 I __imp__CreateFileW at 28> > > > 00000000 T _CreateFileW at 28> > > > 00000000 I __imp__CreateFileMappingW at 24> > > > 00000000 T _CreateFileMappingW at 24> > > > 00000000 I __imp__CreateFileMappingA at 24> > > > 00000000 T _CreateFileMappingA at 24> > > > 00000000 I __imp__CreateFileA at 28> > > > 00000000 T _CreateFileA at 28> > > >> > > > C:\cygwin\lib\w32api>cd \MinGW\lib> > > >> > > > C:\MinGW\lib>nm libkernel32.a | findstr CreateFile> > > > 00000000 I __imp__CreateFileW at 28> > > > 00000000 T _CreateFileW at 28> > > > 00000000 I __imp__CreateFileMappingW at 24> > > > 00000000 T _CreateFileMappingW at 24> > > > 00000000 I __imp__CreateFileMappingA at 24> > > > 00000000 T _CreateFileMappingA at 24> > > > 00000000 I __imp__CreateFileA at 28> > > > 00000000 T _CreateFileA at 28> > > >> > > > I think at least THREE calling conventions should be supported --> > > > __cdecl, __stdcall, __fastcall --> > > > but oh well. We can live without __fastcall.> > > > Watcom has another calling convention, "watcall", and they let you> > > > describe calling conventions with #pragmas, neat.> > > >> > > > Thanks,> > > > - Jay> > > >> > > > Share life as it happens with the new Windows Live. Start sharing!> > >> >> >> > Make distant family not so distant with Windows Vista? + Windows > > Live?. Start now!> _________________________________________________________________ Watch ?Cause Effect,? a show about real people making a real difference. http://im.live.com/Messenger/IM/MTV/?source=text_watchcause -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Sat Jan 12 20:57:49 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 12 Jan 2008 19:57:49 +0000 Subject: [M3devel] could someone add __stdcall name mangling to m3cc please? In-Reply-To: References: Your message of "Wed, 09 Jan 2008 17:25:31 PST." <200801100131.m0A1VQYS034516@camembert.async.caltech.edu> <6D467648-44A7-48DC-AB8D-27B3AC19EBB0@cs.purdue.edu> Message-ID: Something like this????? ===================================================================RCS file: /usr/cvs/cm3/m3-sys/m3cc/gcc/gcc/m3cg/parse.c,vretrieving revision 1.41diff -r1.41 parse.c3066a3070> tree atypes = NULL_TREE);3091c3095,3102< TREE_TYPE (p) = build_function_type (return_type, NULL_TREE);---> /* for NT386 __stdcall, we just need to declare the right number> of parameters> */> if (--n_params== 0) {> atypes = tree_cons (NULL_TREE, t_word, atypes);> }>> TREE_TYPE (p) = build_function_type (return_type, atypes); haven't even compiled it yet.. - Jay > From: jayk123 at hotmail.com> To: hosking at cs.purdue.edu> Date: Sat, 12 Jan 2008 18:13:27 +0000> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] could someone add __stdcall name mangling to m3cc please?> > Tony, Sorry, I didn't mean to check those in. Those were wild guesses that I hadn't tested yet.I put it back. Thanks for catching that.> > - Jay> > > > > CC: m3devel at elegosoft.com> From: hosking at cs.purdue.edu> Subject: Re: [M3devel] could someone add __stdcall name mangling to m3cc please?> Date: Sat, 12 Jan 2008 10:41:26 -0500> To: jayk123 at hotmail.com> > I'm not sure what you were trying to do with parse.c by adding a > parameter (nargs*4) to the stdcall attribute, but that probably > doesn't do anything interesting. The problem appears to be because > on external function decls the parameter decls are currently being > ignored by cm3cg. If I fix parse.c to add the params for those then > it should work properly with the stdcall attribute.> > On Jan 12, 2008, at 8:27 AM, Jay wrote:> > > Thanks, but not quite. The number of parameters times four needs to > > be appended to the name, in decimal.> > But I'm just getting 0.> > That is, gcc is handling the underlying detail, but you aren't > > giving it enough infomrmation.> > I'll see if I can bang out those temporary wrappers automatically.. > > (a Quake programming challenge, that I've already invented the hard > > part of I think -- Quake can't do math..)> >> > - Jay> >> >> > > CC: m3devel at elegosoft.com> > > From: hosking at cs.purdue.edu> > > Subject: Re: [M3devel] could someone add __stdcall name mangling > > to m3cc please?> > > Date: Fri, 11 Jan 2008 13:16:44 -0500> > > To: jayk123 at hotmail.com> > >> > > I just added support for this. Let me know if it seems to work (or> > > not! :-) ).> > >> > >> > > On Jan 10, 2008, at 7:40 AM, Jay wrote:> > >> > > > Could someone out there (Tony?) familiar with the gcc backend> > > > have it not ignore call_conv and if call_conv is 1, append> > > > an at symbol and the number of bytes of parameters to the function> > > > name?> > > > (Even for zero, e.g. Sleep at 0, GetFileAttributes at 4).> > > > This would be I guess at least for "imported" functions.> > > >> > > > Not clear about calling function pointers, probably needs> > > > modification.> > > > call_conv 0 is "__cdecl" is push right to left, caller cleans up> > > > call_conv 1 is "__stdcall" is push right to left, callee cleans up> > > > There are various synonyms.> > > > With no command line switches, __cdecl is the compiler default.> > > > __stdcall is deemed more efficient, and is very widely used.> > > >> > > > Not clear about functions implemented in Modula-3.> > > > Probably won't occur? Maybe for callbacks? WindowProcs, thread> > > > entry point?> > > >> > > > This could/should be for NT386GNU only.> > > > The hypothetical other NT targets only have one calling convention> > > > each.> > > >> > > > I COULD do something sleazy here and generate little adapter> > > > functions, over in m3-win/import-libs esp.> > > >> > > > I'm still checking out pm3 to see what it does here.> > > > (as in cvs checkout, not "looking at")> > > >> > > > This'll clear up:> > > >> > > > RTOS.m3:27: undefined reference to `_FatalExit'> > > > RTOS.mo: In function `RTOS__GetMemory':> > > > RTOS.m3:75: undefined reference to `_VirtualAlloc'> > > > RTOS.m3:85: undefined reference to `_VirtualAlloc'> > > > RTOS.mo: In function `RTOS__InitMemory':> > > > RTOS.m3:96: undefined reference to `_VirtualAlloc'> > > > RTOS.m3:100: undefined reference to `_GetSystemInfo'> > > > RTOS.mo: In function `RTOS__Write':> > > > RTOS.m3:118: undefined reference to `_AllocConsole'> > > > RTOS.m3:119: undefined reference to `_GetStdHandle'> > > > RTOS.m3:122: undefined reference to `_WriteFile'> > > > RTPerfTool.mo: In function `RTPerfTool__Start':> > > > RTPerfTool.m3:19: undefined reference to `_ReadFile'> > > > RTPerfTool.m3:22: undefined reference to `_CloseHandle'> > > > RTPerfTool.mo: In function `RTPerfTool__Close':> > > > RTPerfTool.m3:28: undefined reference to `_CloseHandle'> > > > RTPerfTool.mo: In function `RTPerfTool__Send':> > > > RTPerfTool.m3:34: undefined reference to `_WriteFile'> > > > RTPerfTool.mo: In function `RTPerfTool__PrepHandle':> > > > RTPerfTool.m3:58: undefined reference to `_GetCurrentProcess'> > > > RTPerfTool.m3:59: undefined reference to `_DuplicateHandle'> > > > etc.> > > >> > > > I did think I was past these. I thought I built m3core and libm3> > > > including linking (having even modified cm3.cfg)> > > > COULD be I'm using the wrong .libs, but:> > > >> > > > C:\cygwin\lib\w32api>nm libkernel32.a | findstr CreateFile> > > > 00000000 I __imp__CreateFileW at 28> > > > 00000000 T _CreateFileW at 28> > > > 00000000 I __imp__CreateFileMappingW at 24> > > > 00000000 T _CreateFileMappingW at 24> > > > 00000000 I __imp__CreateFileMappingA at 24> > > > 00000000 T _CreateFileMappingA at 24> > > > 00000000 I __imp__CreateFileA at 28> > > > 00000000 T _CreateFileA at 28> > > >> > > > C:\cygwin\lib\w32api>cd \MinGW\lib> > > >> > > > C:\MinGW\lib>nm libkernel32.a | findstr CreateFile> > > > 00000000 I __imp__CreateFileW at 28> > > > 00000000 T _CreateFileW at 28> > > > 00000000 I __imp__CreateFileMappingW at 24> > > > 00000000 T _CreateFileMappingW at 24> > > > 00000000 I __imp__CreateFileMappingA at 24> > > > 00000000 T _CreateFileMappingA at 24> > > > 00000000 I __imp__CreateFileA at 28> > > > 00000000 T _CreateFileA at 28> > > >> > > > I think at least THREE calling conventions should be supported --> > > > __cdecl, __stdcall, __fastcall --> > > > but oh well. We can live without __fastcall.> > > > Watcom has another calling convention, "watcall", and they let you> > > > describe calling conventions with #pragmas, neat.> > > >> > > > Thanks,> > > > - Jay> > > >> > > > Share life as it happens with the new Windows Live. Start sharing!> > >> >> >> > Make distant family not so distant with Windows Vista? + Windows > > Live?. Start now!> > _________________________________________________________________> Watch ?Cause Effect,? a show about real people making a real difference _________________________________________________________________ Get the power of Windows + Web with the new Windows Live. http://www.windowslive.com?ocid=TXT_TAGHM_Wave2_powerofwindows_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sun Jan 13 01:04:12 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 12 Jan 2008 19:04:12 -0500 Subject: [M3devel] could someone add __stdcall name mangling to m3cc please? In-Reply-To: References: Your message of "Wed, 09 Jan 2008 17:25:31 PST." <200801100131.m0A1VQYS034516@camembert.async.caltech.edu> <6D467648-44A7-48DC-AB8D-27B3AC19EBB0@cs.purdue.edu> Message-ID: I will be able to get m3cc to spit out the appropriate stdcall function names. Needs a little work, but nothing too drastic. On Jan 12, 2008, at 1:13 PM, Jay wrote: > Tony, Sorry, I didn't mean to check those in. Those were wild > guesses that I hadn't tested yet. > I put it back. Thanks for catching that. > > - Jay > > > > > CC: m3devel at elegosoft.com > > From: hosking at cs.purdue.edu > > Subject: Re: [M3devel] could someone add __stdcall name mangling > to m3cc please? > > Date: Sat, 12 Jan 2008 10:41:26 -0500 > > To: jayk123 at hotmail.com > > > > I'm not sure what you were trying to do with parse.c by adding a > > parameter (nargs*4) to the stdcall attribute, but that probably > > doesn't do anything interesting. The problem appears to be because > > on external function decls the parameter decls are currently being > > ignored by cm3cg. If I fix parse.c to add the params for those then > > it should work properly with the stdcall attribute. > > > > On Jan 12, 2008, at 8:27 AM, Jay wrote: > > > > > Thanks, but not quite. The number of parameters times four > needs to > > > be appended to the name, in decimal. > > > But I'm just getting 0. > > > That is, gcc is handling the underlying detail, but you aren't > > > giving it enough infomrmation. > > > I'll see if I can bang out those temporary wrappers > automatically.. > > > (a Quake programming challenge, that I've already invented the > hard > > > part of I think -- Quake can't do math..) > > > > > > - Jay > > > > > > > > > > CC: m3devel at elegosoft.com > > > > From: hosking at cs.purdue.edu > > > > Subject: Re: [M3devel] could someone add __stdcall name mangling > > > to m3cc please? > > > > Date: Fri, 11 Jan 2008 13:16:44 -0500 > > > > To: jayk123 at hotmail.com > > > > > > > > I just added support for this. Let me know if it seems to > work (or > > > > not! :-) ). > > > > > > > > > > > > On Jan 10, 2008, at 7:40 AM, Jay wrote: > > > > > > > > > Could someone out there (Tony?) familiar with the gcc backend > > > > > have it not ignore call_conv and if call_conv is 1, append > > > > > an at symbol and the number of bytes of parameters to the > function > > > > > name? > > > > > (Even for zero, e.g. Sleep at 0, GetFileAttributes at 4). > > > > > This would be I guess at least for "imported" functions. > > > > > > > > > > Not clear about calling function pointers, probably needs > > > > > modification. > > > > > call_conv 0 is "__cdecl" is push right to left, caller > cleans up > > > > > call_conv 1 is "__stdcall" is push right to left, callee > cleans up > > > > > There are various synonyms. > > > > > With no command line switches, __cdecl is the compiler > default. > > > > > __stdcall is deemed more efficient, and is very widely used. > > > > > > > > > > Not clear about functions implemented in Modula-3. > > > > > Probably won't occur? Maybe for callbacks? WindowProcs, thread > > > > > entry point? > > > > > > > > > > This could/should be for NT386GNU only. > > > > > The hypothetical other NT targets only have one calling > convention > > > > > each. > > > > > > > > > > I COULD do something sleazy here and generate little adapter > > > > > functions, over in m3-win/import-libs esp. > > > > > > > > > > I'm still checking out pm3 to see what it does here. > > > > > (as in cvs checkout, not "looking at") > > > > > > > > > > This'll clear up: > > > > > > > > > > RTOS.m3:27: undefined reference to `_FatalExit' > > > > > RTOS.mo: In function `RTOS__GetMemory': > > > > > RTOS.m3:75: undefined reference to `_VirtualAlloc' > > > > > RTOS.m3:85: undefined reference to `_VirtualAlloc' > > > > > RTOS.mo: In function `RTOS__InitMemory': > > > > > RTOS.m3:96: undefined reference to `_VirtualAlloc' > > > > > RTOS.m3:100: undefined reference to `_GetSystemInfo' > > > > > RTOS.mo: In function `RTOS__Write': > > > > > RTOS.m3:118: undefined reference to `_AllocConsole' > > > > > RTOS.m3:119: undefined reference to `_GetStdHandle' > > > > > RTOS.m3:122: undefined reference to `_WriteFile' > > > > > RTPerfTool.mo: In function `RTPerfTool__Start': > > > > > RTPerfTool.m3:19: undefined reference to `_ReadFile' > > > > > RTPerfTool.m3:22: undefined reference to `_CloseHandle' > > > > > RTPerfTool.mo: In function `RTPerfTool__Close': > > > > > RTPerfTool.m3:28: undefined reference to `_CloseHandle' > > > > > RTPerfTool.mo: In function `RTPerfTool__Send': > > > > > RTPerfTool.m3:34: undefined reference to `_WriteFile' > > > > > RTPerfTool.mo: In function `RTPerfTool__PrepHandle': > > > > > RTPerfTool.m3:58: undefined reference to `_GetCurrentProcess' > > > > > RTPerfTool.m3:59: undefined reference to `_DuplicateHandle' > > > > > etc. > > > > > > > > > > I did think I was past these. I thought I built m3core and > libm3 > > > > > including linking (having even modified cm3.cfg) > > > > > COULD be I'm using the wrong .libs, but: > > > > > > > > > > C:\cygwin\lib\w32api>nm libkernel32.a | findstr CreateFile > > > > > 00000000 I __imp__CreateFileW at 28 > > > > > 00000000 T _CreateFileW at 28 > > > > > 00000000 I __imp__CreateFileMappingW at 24 > > > > > 00000000 T _CreateFileMappingW at 24 > > > > > 00000000 I __imp__CreateFileMappingA at 24 > > > > > 00000000 T _CreateFileMappingA at 24 > > > > > 00000000 I __imp__CreateFileA at 28 > > > > > 00000000 T _CreateFileA at 28 > > > > > > > > > > C:\cygwin\lib\w32api>cd \MinGW\lib > > > > > > > > > > C:\MinGW\lib>nm libkernel32.a | findstr CreateFile > > > > > 00000000 I __imp__CreateFileW at 28 > > > > > 00000000 T _CreateFileW at 28 > > > > > 00000000 I __imp__CreateFileMappingW at 24 > > > > > 00000000 T _CreateFileMappingW at 24 > > > > > 00000000 I __imp__CreateFileMappingA at 24 > > > > > 00000000 T _CreateFileMappingA at 24 > > > > > 00000000 I __imp__CreateFileA at 28 > > > > > 00000000 T _CreateFileA at 28 > > > > > > > > > > I think at least THREE calling conventions should be > supported -- > > > > > __cdecl, __stdcall, __fastcall -- > > > > > but oh well. We can live without __fastcall. > > > > > Watcom has another calling convention, "watcall", and they > let you > > > > > describe calling conventions with #pragmas, neat. > > > > > > > > > > Thanks, > > > > > - Jay > > > > > > > > > > Share life as it happens with the new Windows Live. Start > sharing! > > > > > > > > > > > > > Make distant family not so distant with Windows Vista? + Windows > > > Live?. Start now! > > > > > Watch ?Cause Effect,? a show about real people making a real > difference. Learn more From hosking at cs.purdue.edu Sun Jan 13 01:06:35 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 12 Jan 2008 19:06:35 -0500 Subject: [M3devel] could someone add __stdcall name mangling to m3cc please? In-Reply-To: References: Your message of "Wed, 09 Jan 2008 17:25:31 PST." <200801100131.m0A1VQYS034516@camembert.async.caltech.edu> <6D467648-44A7-48DC-AB8D-27B3AC19EBB0@cs.purdue.edu> Message-ID: <80BC3E7C-2DA6-4765-9053-A52950700404@cs.purdue.edu> It will need to be a little cleaner than that -- I'd rather gather the parameters as declared and enter them into the function type. It means not ignoring the parameter decls: see m3cg_declare_param check for current_param_count==0. To do this it needs to be a little bit smarter about managing current_function_decl -- probably a stack. On Jan 12, 2008, at 2:57 PM, Jay wrote: > Something like this????? > > =================================================================== > RCS file: /usr/cvs/cm3/m3-sys/m3cc/gcc/gcc/m3cg/parse.c,v > retrieving revision 1.41 > diff -r1.41 parse.c > 3066a3070 > > tree atypes = NULL_TREE); > 3091c3095,3102 > < TREE_TYPE (p) = build_function_type (return_type, NULL_TREE); > --- > > /* for NT386 __stdcall, we just need to declare the right number > > of parameters > > */ > > if (--n_params== 0) { > > atypes = tree_cons (NULL_TREE, t_word, atypes); > > } > > > > TREE_TYPE (p) = build_function_type (return_type, atypes); > > haven't even compiled it yet.. > > - Jay > > > > > > > > From: jayk123 at hotmail.com > > To: hosking at cs.purdue.edu > > Date: Sat, 12 Jan 2008 18:13:27 +0000 > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] could someone add __stdcall name mangling > to m3cc please? > > > > Tony, Sorry, I didn't mean to check those in. Those were wild > guesses that I hadn't tested yet.I put it back. Thanks for catching > that. > > > > - Jay > > > > > > > > > CC: m3devel at elegosoft.com> From: hosking at cs.purdue.edu> > Subject: Re: [M3devel] could someone add __stdcall name mangling to > m3cc please?> Date: Sat, 12 Jan 2008 10:41:26 -0500> To: > jayk123 at hotmail.com> > I'm not sure what you were trying to do with > parse.c by adding a > parameter (nargs*4) to the stdcall attribute, > but that probably > doesn't do anything interesting. The problem > appears to be because > on external function decls the parameter > decls are currently being > ignored by cm3cg. If I fix parse.c to > add the params for those then > it should work properly with the > stdcall attribute.> > On Jan 12, 2008, at 8:27 AM, Jay wrote:> > > > Thanks, but not quite. The number of parameters times four needs to > > > be appended to the name, in decimal.> > But I'm just getting > 0.> > That is, gcc is handling the underlying detail, but you > aren't > > giving it enough infomrmation.> > I'll see if I can bang > out those temporary wrappers automatically.. > > (a Quake > programming challenge, that I've already invented the hard > > part > of I think -- Quake can't do math..)> >> > - Jay> >> >> > > CC: > m3devel at elegosoft.com> > > From: hosking at cs.purdue.edu> > > > Subject: Re: [M3devel] could someone add __stdcall name mangling > > > to m3cc please?> > > Date: Fri, 11 Jan 2008 13:16:44 -0500> > > > To: jayk123 at hotmail.com> > >> > > I just added support for this. > Let me know if it seems to work (or> > > not! :-) ).> > >> > >> > > > On Jan 10, 2008, at 7:40 AM, Jay wrote:> > >> > > > Could someone > out there (Tony?) familiar with the gcc backend> > > > have it not > ignore call_conv and if call_conv is 1, append> > > > an at symbol > and the number of bytes of parameters to the function> > > > name?> > > > > (Even for zero, e.g. Sleep at 0, GetFileAttributes at 4).> > > > > This would be I guess at least for "imported" functions.> > > >> > > > > Not clear about calling function pointers, probably needs> > > > > modification.> > > > call_conv 0 is "__cdecl" is push right to > left, caller cleans up> > > > call_conv 1 is "__stdcall" is push > right to left, callee cleans up> > > > There are various synonyms.> > > > > With no command line switches, __cdecl is the compiler > default.> > > > __stdcall is deemed more efficient, and is very > widely used.> > > >> > > > Not clear about functions implemented in > Modula-3.> > > > Probably won't occur? Maybe for callbacks? > WindowProcs, thread> > > > entry point?> > > >> > > > This could/ > should be for NT386GNU only.> > > > The hypothetical other NT > targets only have one calling convention> > > > each.> > > >> > > > > I COULD do something sleazy here and generate little adapter> > > > > functions, over in m3-win/import-libs esp.> > > >> > > > I'm still > checking out pm3 to see what it does here.> > > > (as in cvs > checkout, not "looking at")> > > >> > > > This'll clear up:> > > >> > > > > RTOS.m3:27: undefined reference to `_FatalExit'> > > > > RTOS.mo: In function `RTOS__GetMemory':> > > > RTOS.m3:75: > undefined reference to `_VirtualAlloc'> > > > RTOS.m3:85: undefined > reference to `_VirtualAlloc'> > > > RTOS.mo: In function > `RTOS__InitMemory':> > > > RTOS.m3:96: undefined reference to > `_VirtualAlloc'> > > > RTOS.m3:100: undefined reference to > `_GetSystemInfo'> > > > RTOS.mo: In function `RTOS__Write':> > > > > RTOS.m3:118: undefined reference to `_AllocConsole'> > > > > RTOS.m3:119: undefined reference to `_GetStdHandle'> > > > > RTOS.m3:122: undefined reference to `_WriteFile'> > > > > RTPerfTool.mo: In function `RTPerfTool__Start':> > > > > RTPerfTool.m3:19: undefined reference to `_ReadFile'> > > > > RTPerfTool.m3:22: undefined reference to `_CloseHandle'> > > > > RTPerfTool.mo: In function `RTPerfTool__Close':> > > > > RTPerfTool.m3:28: undefined reference to `_CloseHandle'> > > > > RTPerfTool.mo: In function `RTPerfTool__Send':> > > > > RTPerfTool.m3:34: undefined reference to `_WriteFile'> > > > > RTPerfTool.mo: In function `RTPerfTool__PrepHandle':> > > > > RTPerfTool.m3:58: undefined reference to `_GetCurrentProcess'> > > > > RTPerfTool.m3:59: undefined reference to `_DuplicateHandle'> > > > > etc.> > > >> > > > I did think I was past these. I thought I > built m3core and libm3> > > > including linking (having even > modified cm3.cfg)> > > > COULD be I'm using the wrong .libs, but:> > > > >> > > > C:\cygwin\lib\w32api>nm libkernel32.a | findstr > CreateFile> > > > 00000000 I __imp__CreateFileW at 28> > > > 00000000 > T _CreateFileW at 28> > > > 00000000 I __imp__CreateFileMappingW at 24> > > > > 00000000 T _CreateFileMappingW at 24> > > > 00000000 I > __imp__CreateFileMappingA at 24> > > > 00000000 T > _CreateFileMappingA at 24> > > > 00000000 I __imp__CreateFileA at 28> > > > > 00000000 T _CreateFileA at 28> > > >> > > > C:\cygwin\lib\w32api>cd > \MinGW\lib> > > >> > > > C:\MinGW\lib>nm libkernel32.a | findstr > CreateFile> > > > 00000000 I __imp__CreateFileW at 28> > > > 00000000 > T _CreateFileW at 28> > > > 00000000 I __imp__CreateFileMappingW at 24> > > > > 00000000 T _CreateFileMappingW at 24> > > > 00000000 I > __imp__CreateFileMappingA at 24> > > > 00000000 T > _CreateFileMappingA at 24> > > > 00000000 I __imp__CreateFileA at 28> > > > > 00000000 T _CreateFileA at 28> > > >> > > > I think at least THREE > calling conventions should be supported --> > > > __cdecl, > __stdcall, __fastcall --> > > > but oh well. We can live without > __fastcall.> > > > Watcom has another calling convention, > "watcall", and they let you> > > > describe calling conventions > with #pragmas, neat.> > > >> > > > Thanks,> > > > - Jay> > > >> > > > > Share life as it happens with the new Windows Live. Start sharing! > > > >> >> >> > Make distant family not so distant with Windows > Vista? + Windows > > Live?. Start now!> > > _________________________________________________________________ > > Watch ?Cause Effect,? a show about real people making a real > difference > > > Get the power of Windows + Web with the new Windows Live. Get it now! From jayk123 at hotmail.com Sun Jan 13 01:49:10 2008 From: jayk123 at hotmail.com (Jay) Date: Sun, 13 Jan 2008 00:49:10 +0000 Subject: [M3devel] could someone add __stdcall name mangling to m3cc please? In-Reply-To: <80BC3E7C-2DA6-4765-9053-A52950700404@cs.purdue.edu> References: Your message of "Wed, 09 Jan 2008 17:25:31 PST." <200801100131.m0A1VQYS034516@camembert.async.caltech.edu> <6D467648-44A7-48DC-AB8D-27B3AC19EBB0@cs.purdue.edu> <80BC3E7C-2DA6-4765-9053-A52950700404@cs.purdue.edu> Message-ID: I commited something LIKE this, that lets m3core.dll link. (The below had several errors. Failing to loop, failing to terminate the list correctly, only getting function pointers or functions instead of both, for some reason the Windows *.i3 files use a mix.) libm3.dll has a boring pathname format problem, ld doesn't like c:\foo\../bar.lib and I got sidetracked.. It MIGHT not work for SOME functions, a link error -- if taking __int64 or small structs by value, in a __stdcall function. I'll see if that comes up as I progress through the system slowly. - Jay > CC: m3devel at elegosoft.com> From: hosking at cs.purdue.edu> Subject: Re: [M3devel] could someone add __stdcall name mangling to m3cc please?> Date: Sat, 12 Jan 2008 19:06:35 -0500> To: jayk123 at hotmail.com> > It will need to be a little cleaner than that -- I'd rather gather > the parameters as declared and enter them into the function type. It > means not ignoring the parameter decls: see m3cg_declare_param check > for current_param_count==0. To do this it needs to be a little bit > smarter about managing current_function_decl -- probably a stack.> > On Jan 12, 2008, at 2:57 PM, Jay wrote:> > > Something like this?????> >> > ===================================================================> > RCS file: /usr/cvs/cm3/m3-sys/m3cc/gcc/gcc/m3cg/parse.c,v> > retrieving revision 1.41> > diff -r1.41 parse.c> > 3066a3070> > > tree atypes = NULL_TREE);> > 3091c3095,3102> > < TREE_TYPE (p) = build_function_type (return_type, NULL_TREE);> > ---> > > /* for NT386 __stdcall, we just need to declare the right number> > > of parameters> > > */> > > if (--n_params== 0) {> > > atypes = tree_cons (NULL_TREE, t_word, atypes);> > > }> > >> > > TREE_TYPE (p) = build_function_type (return_type, atypes);> >> > haven't even compiled it yet..> >> > - Jay> >> >> >> >> >> >> > > From: jayk123 at hotmail.com> > > To: hosking at cs.purdue.edu> > > Date: Sat, 12 Jan 2008 18:13:27 +0000> > > CC: m3devel at elegosoft.com> > > Subject: Re: [M3devel] could someone add __stdcall name mangling > > to m3cc please?> > >> > > Tony, Sorry, I didn't mean to check those in. Those were wild > > guesses that I hadn't tested yet.I put it back. Thanks for catching > > that.> > >> > > - Jay> > >> > >> > >> > > > CC: m3devel at elegosoft.com> From: hosking at cs.purdue.edu> > > Subject: Re: [M3devel] could someone add __stdcall name mangling to > > m3cc please?> Date: Sat, 12 Jan 2008 10:41:26 -0500> To: > > jayk123 at hotmail.com> > I'm not sure what you were trying to do with > > parse.c by adding a > parameter (nargs*4) to the stdcall attribute, > > but that probably > doesn't do anything interesting. The problem > > appears to be because > on external function decls the parameter > > decls are currently being > ignored by cm3cg. If I fix parse.c to > > add the params for those then > it should work properly with the > > stdcall attribute.> > On Jan 12, 2008, at 8:27 AM, Jay wrote:> > > > > Thanks, but not quite. The number of parameters times four needs to > > > > be appended to the name, in decimal.> > But I'm just getting > > 0.> > That is, gcc is handling the underlying detail, but you > > aren't > > giving it enough infomrmation.> > I'll see if I can bang > > out those temporary wrappers automatically.. > > (a Quake > > programming challenge, that I've already invented the hard > > part > > of I think -- Quake can't do math..)> >> > - Jay> >> >> > > CC: > > m3devel at elegosoft.com> > > From: hosking at cs.purdue.edu> > > > > Subject: Re: [M3devel] could someone add __stdcall name mangling > > > > to m3cc please?> > > Date: Fri, 11 Jan 2008 13:16:44 -0500> > > > > To: jayk123 at hotmail.com> > >> > > I just added support for this. > > Let me know if it seems to work (or> > > not! :-) ).> > >> > >> > > > > On Jan 10, 2008, at 7:40 AM, Jay wrote:> > >> > > > Could someone > > out there (Tony?) familiar with the gcc backend> > > > have it not > > ignore call_conv and if call_conv is 1, append> > > > an at symbol > > and the number of bytes of parameters to the function> > > > name?> > > > > > (Even for zero, e.g. Sleep at 0, GetFileAttributes at 4).> > > > > > This would be I guess at least for "imported" functions.> > > >> > > > > > Not clear about calling function pointers, probably needs> > > > > > modification.> > > > call_conv 0 is "__cdecl" is push right to > > left, caller cleans up> > > > call_conv 1 is "__stdcall" is push > > right to left, callee cleans up> > > > There are various synonyms.> > > > > > With no command line switches, __cdecl is the compiler > > default.> > > > __stdcall is deemed more efficient, and is very > > widely used.> > > >> > > > Not clear about functions implemented in > > Modula-3.> > > > Probably won't occur? Maybe for callbacks? > > WindowProcs, thread> > > > entry point?> > > >> > > > This could/ > > should be for NT386GNU only.> > > > The hypothetical other NT > > targets only have one calling convention> > > > each.> > > >> > > > > > I COULD do something sleazy here and generate little adapter> > > > > > functions, over in m3-win/import-libs esp.> > > >> > > > I'm still > > checking out pm3 to see what it does here.> > > > (as in cvs > > checkout, not "looking at")> > > >> > > > This'll clear up:> > > >> > > > > > RTOS.m3:27: undefined reference to `_FatalExit'> > > > > > RTOS.mo: In function `RTOS__GetMemory':> > > > RTOS.m3:75: > > undefined reference to `_VirtualAlloc'> > > > RTOS.m3:85: undefined > > reference to `_VirtualAlloc'> > > > RTOS.mo: In function > > `RTOS__InitMemory':> > > > RTOS.m3:96: undefined reference to > > `_VirtualAlloc'> > > > RTOS.m3:100: undefined reference to > > `_GetSystemInfo'> > > > RTOS.mo: In function `RTOS__Write':> > > > > > RTOS.m3:118: undefined reference to `_AllocConsole'> > > > > > RTOS.m3:119: undefined reference to `_GetStdHandle'> > > > > > RTOS.m3:122: undefined reference to `_WriteFile'> > > > > > RTPerfTool.mo: In function `RTPerfTool__Start':> > > > > > RTPerfTool.m3:19: undefined reference to `_ReadFile'> > > > > > RTPerfTool.m3:22: undefined reference to `_CloseHandle'> > > > > > RTPerfTool.mo: In function `RTPerfTool__Close':> > > > > > RTPerfTool.m3:28: undefined reference to `_CloseHandle'> > > > > > RTPerfTool.mo: In function `RTPerfTool__Send':> > > > > > RTPerfTool.m3:34: undefined reference to `_WriteFile'> > > > > > RTPerfTool.mo: In function `RTPerfTool__PrepHandle':> > > > > > RTPerfTool.m3:58: undefined reference to `_GetCurrentProcess'> > > > > > RTPerfTool.m3:59: undefined reference to `_DuplicateHandle'> > > > > > etc.> > > >> > > > I did think I was past these. I thought I > > built m3core and libm3> > > > including linking (having even > > modified cm3.cfg)> > > > COULD be I'm using the wrong .libs, but:> > > > > >> > > > C:\cygwin\lib\w32api>nm libkernel32.a | findstr > > CreateFile> > > > 00000000 I __imp__CreateFileW at 28> > > > 00000000 > > T _CreateFileW at 28> > > > 00000000 I __imp__CreateFileMappingW at 24> > > > > > 00000000 T _CreateFileMappingW at 24> > > > 00000000 I > > __imp__CreateFileMappingA at 24> > > > 00000000 T > > _CreateFileMappingA at 24> > > > 00000000 I __imp__CreateFileA at 28> > > > > > 00000000 T _CreateFileA at 28> > > >> > > > C:\cygwin\lib\w32api>cd > > \MinGW\lib> > > >> > > > C:\MinGW\lib>nm libkernel32.a | findstr > > CreateFile> > > > 00000000 I __imp__CreateFileW at 28> > > > 00000000 > > T _CreateFileW at 28> > > > 00000000 I __imp__CreateFileMappingW at 24> > > > > > 00000000 T _CreateFileMappingW at 24> > > > 00000000 I > > __imp__CreateFileMappingA at 24> > > > 00000000 T > > _CreateFileMappingA at 24> > > > 00000000 I __imp__CreateFileA at 28> > > > > > 00000000 T _CreateFileA at 28> > > >> > > > I think at least THREE > > calling conventions should be supported --> > > > __cdecl, > > __stdcall, __fastcall --> > > > but oh well. We can live without > > __fastcall.> > > > Watcom has another calling convention, > > "watcall", and they let you> > > > describe calling conventions > > with #pragmas, neat.> > > >> > > > Thanks,> > > > - Jay> > > >> > > > > > Share life as it happens with the new Windows Live. Start sharing! > > > > >> >> >> > Make distant family not so distant with Windows > > Vista? + Windows > > Live?. Start now!>> > > _________________________________________________________________> > > Watch ?Cause Effect,? a show about real people making a real > > difference> >> >> > Get the power of Windows + Web with the new Windows Live. Get it now!> _________________________________________________________________ Watch ?Cause Effect,? a show about real people making a real difference. http://im.live.com/Messenger/IM/MTV/?source=text_watchcause -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Jan 13 01:51:15 2008 From: jay.krell at cornell.edu (Jay) Date: Sun, 13 Jan 2008 00:51:15 +0000 Subject: [M3devel] could someone add __stdcall name mangling to m3cc please? In-Reply-To: <80BC3E7C-2DA6-4765-9053-A52950700404@cs.purdue.edu> References: Your message of "Wed, 09 Jan 2008 17:25:31 PST." <200801100131.m0A1VQYS034516@camembert.async.caltech.edu> <6D467648-44A7-48DC-AB8D-27B3AC19EBB0@cs.purdue.edu> <80BC3E7C-2DA6-4765-9053-A52950700404@cs.purdue.edu> Message-ID: > current_param_count Must this code use globals? - Jay From: jayk123 at hotmail.comTo: hosking at cs.purdue.eduCC: m3devel at elegosoft.comSubject: RE: [M3devel] could someone add __stdcall name mangling to m3cc please?Date: Sun, 13 Jan 2008 00:49:10 +0000 I commited something LIKE this, that lets m3core.dll link. (The below had several errors. Failing to loop, failing to terminate the list correctly, only getting function pointers or functions instead of both, for some reason the Windows *.i3 files use a mix.) libm3.dll has a boring pathname format problem, ld doesn't like c:\foo\../bar.lib and I got sidetracked.. It MIGHT not work for SOME functions, a link error -- if taking __int64 or small structs by value, in a __stdcall function.I'll see if that comes up as I progress through the system slowly. - Jay > CC: m3devel at elegosoft.com> From: hosking at cs.purdue.edu> Subject: Re: [M3devel] could someone add __stdcall name mangling to m3cc please?> Date: Sat, 12 Jan 2008 19:06:35 -0500> To: jayk123 at hotmail.com> > It will need to be a little cleaner than that -- I'd rather gather > the parameters as declared and enter them into the function type. It > means not ignoring the parameter decls: see m3cg_declare_param check > for current_param_count==0. To do this it needs to be a little bit > smarter about managing current_function_decl -- probably a stack.> > On Jan 12, 2008, at 2:57 PM, Jay wrote:> > > Something like this?????> >> > ===================================================================> > RCS file: /usr/cvs/cm3/m3-sys/m3cc/gcc/gcc/m3cg/parse.c,v> > retrieving revision 1.41> > diff -r1.41 parse.c> > 3066a3070> > > tree atypes = NULL_TREE);> > 3091c3095,3102> > < TREE_TYPE (p) = build_function_type (return_type, NULL_TREE);> > ---> > > /* for NT386 __stdcall, we just need to declare the right number> > > of parameters> > > */> > > if (--n_params== 0) {> > > atypes = tree_cons (NULL_TREE, t_word, atypes);> > > }> > >> > > TREE_TYPE (p) = build_function_type (return_type, atypes);> >> > haven't even compiled it yet..> >> > - Jay> >> >> >> >> >> >> > > From: jayk123 at hotmail.com> > > To: hosking at cs.purdue.edu> > > Date: Sat, 12 Jan 2008 18:13:27 +0000> > > CC: m3devel at elegosoft.com> > > Subject: Re: [M3devel] could someone add __stdcall name mangling > > to m3cc please?> > >> > > Tony, Sorry, I didn't mean to check those in. Those were wild > > guesses that I hadn't tested yet.I put it back. Thanks for catching > > that.> > >> > > - Jay> > >> > >> > >> > > > CC: m3devel at elegosoft.com> From: hosking at cs.purdue.edu> > > Subject: Re: [M3devel] could someone add __stdcall name mangling to > > m3cc please?> Date: Sat, 12 Jan 2008 10:41:26 -0500> To: > > jayk123 at hotmail.com> > I'm not sure what you were trying to do with > > parse.c by adding a > parameter (nargs*4) to the stdcall attribute, > > but that probably > doesn't do anything interesting. The problem > > appears to be because > on external function decls the parameter > > decls are currently being > ignored by cm3cg. If I fix parse.c to > > add the params for those then > it should work properly with the > > stdcall attribute.> > On Jan 12, 2008, at 8:27 AM, Jay wrote:> > > > > Thanks, but not quite. The number of parameters times four needs to > > > > be appended to the name, in decimal.> > But I'm just getting > > 0.> > That is, gcc is handling the underlying detail, but you > > aren't > > giving it enough infomrmation.> > I'll see if I can bang > > out those temporary wrappers automatically.. > > (a Quake > > programming challenge, that I've already invented the hard > > part > > of I think -- Quake can't do math..)> >> > - Jay> >> >> > > CC: > > m3devel at elegosoft.com> > > From: hosking at cs.purdue.edu> > > > > Subject: Re: [M3devel] could someone add __stdcall name mangling > > > > to m3cc please?> > > Date: Fri, 11 Jan 2008 13:16:44 -0500> > > > > To: jayk123 at hotmail.com> > >> > > I just added support for this. > > Let me know if it seems to work (or> > > not! :-) ).> > >> > >> > > > > On Jan 10, 2008, at 7:40 AM, Jay wrote:> > >> > > > Could someone > > out there (Tony?) familiar with the gcc backend> > > > have it not > > ignore call_conv and if call_conv is 1, append> > > > an at symbol > > and the number of bytes of parameters to the function> > > > name?> > > > > > (Even for zero, e.g. Sleep at 0, GetFileAttributes at 4).> > > > > > This would be I guess at least for "imported" functions.> > > >> > > > > > Not clear about calling function pointers, probably needs> > > > > > modification.> > > > call_conv 0 is "__cdecl" is push right to > > left, caller cleans up> > > > call_conv 1 is "__stdcall" is push > > right to left, callee cleans up> > > > There are various synonyms.> > > > > > With no command line switches, __cdecl is the compiler > > default.> > > > __stdcall is deemed more efficient, and is very > > widely used.> > > >> > > > Not clear about functions implemented in > > Modula-3.> > > > Probably won't occur? Maybe for callbacks? > > WindowProcs, thread> > > > entry point?> > > >> > > > This could/ > > should be for NT386GNU only.> > > > The hypothetical other NT > > targets only have one calling convention> > > > each.> > > >> > > > > > I COULD do something sleazy here and generate little adapter> > > > > > functions, over in m3-win/import-libs esp.> > > >> > > > I'm still > > checking out pm3 to see what it does here.> > > > (as in cvs > > checkout, not "looking at")> > > >> > > > This'll clear up:> > > >> > > > > > RTOS.m3:27: undefined reference to `_FatalExit'> > > > > > RTOS.mo: In function `RTOS__GetMemory':> > > > RTOS.m3:75: > > undefined reference to `_VirtualAlloc'> > > > RTOS.m3:85: undefined > > reference to `_VirtualAlloc'> > > > RTOS.mo: In function > > `RTOS__InitMemory':> > > > RTOS.m3:96: undefined reference to > > `_VirtualAlloc'> > > > RTOS.m3:100: undefined reference to > > `_GetSystemInfo'> > > > RTOS.mo: In function `RTOS__Write':> > > > > > RTOS.m3:118: undefined reference to `_AllocConsole'> > > > > > RTOS.m3:119: undefined reference to `_GetStdHandle'> > > > > > RTOS.m3:122: undefined reference to `_WriteFile'> > > > > > RTPerfTool.mo: In function `RTPerfTool__Start':> > > > > > RTPerfTool.m3:19: undefined reference to `_ReadFile'> > > > > > RTPerfTool.m3:22: undefined reference to `_CloseHandle'> > > > > > RTPerfTool.mo: In function `RTPerfTool__Close':> > > > > > RTPerfTool.m3:28: undefined reference to `_CloseHandle'> > > > > > RTPerfTool.mo: In function `RTPerfTool__Send':> > > > > > RTPerfTool.m3:34: undefined reference to `_WriteFile'> > > > > > RTPerfTool.mo: In function `RTPerfTool__PrepHandle':> > > > > > RTPerfTool.m3:58: undefined reference to `_GetCurrentProcess'> > > > > > RTPerfTool.m3:59: undefined reference to `_DuplicateHandle'> > > > > > etc.> > > >> > > > I did think I was past these. I thought I > > built m3core and libm3> > > > including linking (having even > > modified cm3.cfg)> > > > COULD be I'm using the wrong .libs, but:> > > > > >> > > > C:\cygwin\lib\w32api>nm libkernel32.a | findstr > > CreateFile> > > > 00000000 I __imp__CreateFileW at 28> > > > 00000000 > > T _CreateFileW at 28> > > > 00000000 I __imp__CreateFileMappingW at 24> > > > > > 00000000 T _CreateFileMappingW at 24> > > > 00000000 I > > __imp__CreateFileMappingA at 24> > > > 00000000 T > > _CreateFileMappingA at 24> > > > 00000000 I __imp__CreateFileA at 28> > > > > > 00000000 T _CreateFileA at 28> > > >> > > > C:\cygwin\lib\w32api>cd > > \MinGW\lib> > > >> > > > C:\MinGW\lib>nm libkernel32.a | findstr > > CreateFile> > > > 00000000 I __imp__CreateFileW at 28> > > > 00000000 > > T _CreateFileW at 28> > > > 00000000 I __imp__CreateFileMappingW at 24> > > > > > 00000000 T _CreateFileMappingW at 24> > > > 00000000 I > > __imp__CreateFileMappingA at 24> > > > 00000000 T > > _CreateFileMappingA at 24> > > > 00000000 I __imp__CreateFileA at 28> > > > > > 00000000 T _CreateFileA at 28> > > >> > > > I think at least THREE > > calling conventions should be supported --> > > > __cdecl, > > __stdcall, __fastcall --> > > > but oh well. We can live without > > __fastcall.> > > > Watcom has another calling convention, > > "watcall", and they let you> > > > describe calling conventions > > with #pragmas, neat.> > > >> > > > Thanks,> > > > - Jay> > > >> > > > > > Share life as it happens with the new Windows Live. Start sharing! > > > > >> >> >> > Make distant family not so distant with Windows > > Vista? + Windows > > Live?. Start now!>> > > _________________________________________________________________> > > Watch ?Cause Effect,? a show about real people making a real > > difference> >> >> > Get the power of Windows + Web with the new Windows Live. Get it now!> Watch ?Cause Effect,? a show about real people making a real difference. Learn more _________________________________________________________________ Watch ?Cause Effect,? a show about real people making a real difference. http://im.live.com/Messenger/IM/MTV/?source=text_watchcause -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Sun Jan 13 16:05:23 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Sun, 13 Jan 2008 16:05:23 +0100 Subject: [M3devel] M3 concerns In-Reply-To: <20080105143235.ujed2tl3ksogws8k@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> Message-ID: <20080113160523.7ih7rpkusogsook8@mail.elegosoft.com> Quoting myself: > Discussions seem to loose their focus quiet easy on this list :-/ It might seem that I've scared everybody away from further discussing, or indeed nobody else is interested in this topic. As I'd promised to write a resume, here are some comments / suggestions: > How do we need to improve > the CM3 development process to ensure and increase the overall quality > of the CM3 code base? Could everybody interested in this discussion > please just comment on the following items to state his opinion: > > 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). > > Technical details should be discussed in a different thread. There has been some progress on CM3 regression test automation. The tinderbox setup by Kaspar is working and quite usable, though some things still need to be improved or fixed. Have a look at http://tinderbox.elegosoft.com/tinderbox/cm3/status.html to view the current build results (from FreeBSD and Linux systems; two test runs every day for every platform). We're now at the stage that others could contribute their daily build results, so that the platform coverage gets better. Some details (mostly security related) still have to be resolved (with out administrators); I'll follow up on this in a separate mail. I've also invested a considerable amount of time to review all the failures and problems in the m3-sys/m3tests regression test package, which is now run as part of the daily tests. The short result is that there still _are_ several problems with the current compiler and/or runtime which may need attention. I'll post another summary for this; volunteers for closer inspection are welcome. > o Do we need / want to restrict the commit access for the CM3 > code repositories? > > If so, only for certain areas, or for everything? This would > be a distinction based on packages. > > Should we allow or prefer committing new code to branches and > merge the resulting change sets based on reviews? (I could also > contribute automatic support for creating change sets on branches, > as this is part of the DCVS functionality elego developed some time > ago). This would be a distinction based on code lines. > > Yesterday I had the impression that some members of this list > would prefer some access restriction, but I'm not really sure. As there have been no more comments / opninions I'd suggest that we leave things as they currently are, unless there are good objections to this. > o I'm not sure if and how we should include the Windows target > problems here. They were part of the original mail, but seem > to belong to another category to me, at least have different > causes. Suggestions what exactly to discuss are welcome. I don't know if Randy was successful in getting the current CM3 system to run on Windows; some problems and solutions have been posted to m3devel since last week. There also seems to be progress in resurrecting the NT386GNU target, but this is obviously work in progress. So far for this (intermediate?) summary of CM3 QA :-) Please let me know what you think about the recent additions and changes, Olaf PS: I won't be able to continue to spare as much time on CM3 as I've done during the last three weeks, so I'd like to encourage everybody who'd like to help, improve or take responsibility for (some of) the started tasks. -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Jan 14 00:36:40 2008 From: jayk123 at hotmail.com (Jay) Date: Sun, 13 Jan 2008 23:36:40 +0000 Subject: [M3devel] religion, philosophy, Posix vs. Win32 In-Reply-To: <280102.76351.qm@web27105.mail.ukl.yahoo.com> References: <280102.76351.qm@web27105.mail.ukl.yahoo.com> Message-ID: The conclusion here is: Just try to convince me otherwise. :) The gist of the question is: Just what characteristics of "Posix" and "Win32" should "NT386GNU" have? Just what characteristics of "Posix" do people notice and like? You can't say "the whole thing". :) Restated: What is Posix? I don't mean, where is the standard document web site. I mean what is it TO YOU? Is it open/read/write/close? Is it fork? Is it sbrk? On these previous ones, they are interesting to many programmers, but Modula-3 already layers over all this, so these are unlikely defining characteristics here. Is it sh? Probably somewhat. But if have you sat in Cygwin sh much vs. cmd? It is annoying. Command line history is flaky. Paths are munged to say /cygdrive. You lose the critical F8 command line completion against history feature. You lose a lot of editing capability, but do gain some alternate possibly "portable" similar. Is it Perl? No. Is it X Windows. I doubt it. Is it pthreads? Probably not. Or at least vtalarm? Maybe? Or setjmp/longjmp? Ok. Longjmp to the same buffer multiple times? Not likely. Longjmp to a place that has already returned? Not likely. All full paths starting with a forward slash? Maybe. Backward slash being a valid non-seperator path character? Maybe. Think about that last one. It is valid and occurs in Win32 code to treat forward slash and backward slash the same. Some code does, some code does not. What if you just did that unconditionally, like even in Posix? What is the role of backward slash in Posix paths? It either just doesn't occur, or is an escape character, or is a regular character. Something at a low level could replace the backward slashes with forward slashes. I would like to change the code in m3-sys/cm3/m3path.m3 to treat backward slashes and forward slashes the same. Backward slashes just won't occur on Posix, right? So far I have managed without this change, but not having it has bitten me a few times. I do have the analogous change to the Win32 path code in m3core. It is the redundant filenames libfoo.a instead of foo.lib and libfoo.so instead of foo.so? Perhaps. This seems dumb, redundant to me. Why have prefixes and suffixes? Don't suffixes suffice? That all said, I remain convinced that a useful intermediate or probably endpoint is a toolset that targets Windows using cm3cg, ld, as, but otherwise looks like NT386 as much as possible. MAYBE alter the library names to libfoo.*. sh and make are needed for building cm3cg. I did use Cygwin for that. MinGWin sounds promising here too but I haven't tried. - Jay _________________________________________________________________ Get the power of Windows + Web with the new Windows Live. http://www.windowslive.com?ocid=TXT_TAGHM_Wave2_powerofwindows_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Mon Jan 14 00:43:41 2008 From: jayk123 at hotmail.com (Jay) Date: Sun, 13 Jan 2008 23:43:41 +0000 Subject: [M3devel] dynamic linking, stanalone()? In-Reply-To: <280102.76351.qm@web27105.mail.ukl.yahoo.com> References: <280102.76351.qm@web27105.mail.ukl.yahoo.com> Message-ID: Dynamic linking vs. "standalone". How does that work? On Posix, with ld, etc.? I understand fully how it works on NT386 and will explain, as a jumping off point for explanation and analogies. Windows has "import .libs" and regular old "static .libs". In reality it has import .objs and regular .objs, and a .lib is a collection of .objs, and can contain a mix, but this is not well known. Usually a .lib only has all one type or all the other type. Actually older import .libs are just kind of wierd and drive the linker in odd roundabout ways that end up doing the right thing, I guess without the linker knowing much. Current Cygwin/Mingwin ld/dlltool import libs I think are still odd. And large. And besides, they seem buggy but tht's a tangent. Look at msvcrt.lib. It contains static startup code and imports. There is no seperate crt0.o file on Windows. USUALLY people only build one .lib type or another. However the Modula-3 system has a clever innovation. It always builds both. This retains flexibility in how the clients are built. cm3.exe links to m3core/libm3 statically, most other folks dynamically. It is ROUGHLY like so: lib /out:foo.lib.sa objects... sa for standalone link /out:foo.dll objects... as a by-product of the link, foo.lib an import .lib is produced When you go to link, you give the linker, well, let's say, full paths. To foo.lib or foo.lib.sa, or whatever mix. (or leaf only paths and the LIB environment variable is searched, kind of like $PATH) In "Posix" I know there is foo.a and foo.so. But an .so is a .dll. An .a is? Either? And the third one is? To some extent, no matter. I THINK it goes like this for Cygwin/MinGWin: ar foo.lib.sa objects ld -o foo.dll --out-imlib foo.lib but it's not quite working for me currently. I'm backtracking to get to an earlier version of my config file that was. I should probably break down and use dlltool. And I can read the docs, of course. I do so. And search the web. I have avoided using anything that isn't already a configuration variable. That is, I use gcc instead of ld for example. This is dumb of me I realize. ld gave me fits also on MacOSX but on Windows it should be more viable, fewer arcane details as to what to link in. e.g. I believe on "Posix", the entry point of a file is whatever .o is linked first. Chose carefully. On Windows it is seperately specified and the order of the link command doesn't affect it (though still has other subtle affects). And it is usually buried in a .lib, fewer files to chose between. - Jay _________________________________________________________________ Share life as it happens with the new Windows Live. http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Mon Jan 14 00:53:58 2008 From: jayk123 at hotmail.com (Jay) Date: Sun, 13 Jan 2008 23:53:58 +0000 Subject: [M3devel] dynamic linking, stanalone()? In-Reply-To: References: <280102.76351.qm@web27105.mail.ukl.yahoo.com> Message-ID: Nevermind, I'll figure it out. I am going to try dlltool. Currently it SEEMS like references are to _Foo but defintions are Foo. Of course, leading underscores always confuse. Sometimes they are added, sometimes they are removed, sometimes they must match. It stinks a little bit. At least on x86 Windows. Usually it is well hidden. COULD be a disagreement between Cygwin cm3cg and mingwin as/ld..though given that things were working..I don't know. I should try the mingwin sh/make/sed... - Jay From: jayk123 at hotmail.com To: m3devel at elegosoft.com Date: Sun, 13 Jan 2008 23:43:41 +0000 Subject: [M3devel] dynamic linking, stanalone()? Dynamic linking vs. "standalone". How does that work? On Posix, with ld, etc.? I understand fully how it works on NT386 and will explain, as a jumping off point for explanation and analogies. Windows has "import .libs" and regular old "static .libs". In reality it has import .objs and regular .objs, and a .lib is a collection of .objs, and can contain a mix, but this is not well known. Usually a .lib only has all one type or all the other type. Actually older import .libs are just kind of wierd and drive the linker in odd roundabout ways that end up doing the right thing, I guess without the linker knowing much. Current Cygwin/Mingwin ld/dlltool import libs I think are still odd. And large. And besides, they seem buggy but tht's a tangent. Look at msvcrt.lib. It contains static startup code and imports. There is no seperate crt0.o file on Windows. USUALLY people only build one .lib type or another. However the Modula-3 system has a clever innovation. It always builds both. This retains flexibility in how the clients are built. cm3.exe links to m3core/libm3 statically, most other folks dynamically. It is ROUGHLY like so: lib /out:foo.lib.sa objects... sa for standalone link /out:foo.dll objects... as a by-product of the link, foo.lib an import .lib is produced When you go to link, you give the linker, well, let's say, full paths. To foo.lib or foo.lib.sa, or whatever mix. (or leaf only paths and the LIB environment variable is searched, kind of like $PATH) In "Posix" I know there is foo.a and foo.so. But an .so is a .dll. An .a is? Either? And the third one is? To some extent, no matter. I THINK it goes like this for Cygwin/MinGWin: ar foo.lib.sa objects ld -o foo.dll --out-imlib foo.lib but it's not quite working for me currently. I'm backtracking to get to an earlier version of my config file that was. I should probably break down and use dlltool. And I can read the docs, of course. I do so. And search the web. I have avoided using anything that isn't already a configuration variable. That is, I use gcc instead of ld for example. This is dumb of me I realize. ld gave me fits also on MacOSX but on Windows it should be more viable, fewer arcane details as to what to link in. e.g. I believe on "Posix", the entry point of a file is whatever .o is linked first. Chose carefully. On Windows it is seperately specified and the order of the link command doesn't affect it (though still has other subtle affects). And it is usually buried in a .lib, fewer files to chose between. - Jay Share life as it happens with the new Windows Live. Start sharing! _________________________________________________________________ Put your friends on the big screen with Windows Vista? + Windows Live?. http://www.microsoft.com/windows/shop/specialoffers.mspx?ocid=TXT_TAGLM_CPC_MediaCtr_bigscreen_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon Jan 14 01:13:17 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 13 Jan 2008 19:13:17 -0500 Subject: [M3devel] religion, philosophy, Posix vs. Win32 In-Reply-To: References: <280102.76351.qm@web27105.mail.ukl.yahoo.com> Message-ID: I really don't know enough about Windows to answer these questions properly. My take on it is: since Cygwin is intended to give a Linux-like environment on Windows, then it should behave more like a Linux system than a Windows system. That is, CM3 will look like it is running on some (strange) flavor of Linux. That said, the threading sub-system might be implemented as ThreadWin32 instead of ThreadPosix just to get system-level thread scheduling (ie, good for multi-core), similarly to the way ThreadPThread is used on some POSIX targets. The rest of things with Cygwin should behave like any other POSIX target. Perhaps someone else out there with better Windows knowledge can respond more intelligently than I have. On Jan 13, 2008, at 6:36 PM, Jay wrote: > The conclusion here is: > Just try to convince me otherwise. :) > > The gist of the question is: > Just what characteristics of "Posix" and "Win32" should > "NT386GNU" have? > > Just what characteristics of "Posix" do people notice and like? > You can't say "the whole thing". :) > > Restated: > > What is Posix? I don't mean, where is the standard document web site. > I mean what is it TO YOU? > > Is it open/read/write/close? > Is it fork? > Is it sbrk? > On these previous ones, they are interesting to many programmers, > but Modula-3 already layers over all this, so these are unlikely > defining > characteristics here. > > Is it sh? Probably somewhat. But if have you sat in Cygwin sh much > vs. cmd? > It is annoying. Command line history is flaky. Paths are munged to > say /cygdrive. > You lose the critical F8 command line completion against history > feature. > You lose a lot of editing capability, but do gain some alternate > possibly "portable" > similar. > > Is it Perl? No. > Is it X Windows. I doubt it. > Is it pthreads? Probably not. > Or at least vtalarm? Maybe? > Or setjmp/longjmp? Ok. > Longjmp to the same buffer multiple times? Not likely. > Longjmp to a place that has already returned? Not likely. > All full paths starting with a forward slash? Maybe. > Backward slash being a valid non-seperator path character? Maybe. > > Think about that last one. > It is valid and occurs in Win32 code to treat forward slash and > backward slash the same. > Some code does, some code does not. > What if you just did that unconditionally, like even in Posix? > What is the role of backward slash in Posix paths? It either just > doesn't occur, > or is an escape character, or is a regular character. Something at > a low level > could replace the backward slashes with forward slashes. > > I would like to change the code in m3-sys/cm3/m3path.m3 to treat > backward slashes > and forward slashes the same. Backward slashes just won't occur on > Posix, right? > So far I have managed without this change, but not having it has > bitten me a few times. > I do have the analogous change to the Win32 path code in m3core. > > It is the redundant filenames libfoo.a instead of foo.lib and > libfoo.so instead of foo.so? > Perhaps. This seems dumb, redundant to me. Why have prefixes and > suffixes? > Don't suffixes suffice? > > That all said, I remain convinced that a useful intermediate or > probably endpoint > is a toolset that targets Windows using cm3cg, ld, as, but > otherwise looks like > NT386 as much as possible. MAYBE alter the library names to libfoo.*. > > sh and make are needed for building cm3cg. > I did use Cygwin for that. MinGWin sounds promising here too but I > haven't tried. > > - Jay > > > Get the power of Windows + Web with the new Windows Live. Get it now! From mika at async.caltech.edu Mon Jan 14 01:40:17 2008 From: mika at async.caltech.edu (Mika Nystrom) Date: Sun, 13 Jan 2008 16:40:17 -0800 Subject: [M3devel] religion, philosophy, Posix vs. Win32 In-Reply-To: Your message of "Sun, 13 Jan 2008 23:36:40 GMT." Message-ID: <200801140040.m0E0eHs7046272@camembert.async.caltech.edu> Jay, I don't know if this is completely responsive to your question, and take it with a grain of salt because I have never programmed on a "pure" Windows system (and God willing, I never shall). I expect the NT386GNU target, Cygwin, Windows-POSIX, whatever you call it, to look as much as Unix "as possible." (Obviously not, but as "reasonable".) The main things are (1) yes, /bin/sh, and (2) Unix (POSIX?) libc---Modula-3 does a good job of covering up the basic stuff so you don't need to worry about it for the most part, but sometimes, just sometimes, you need to get, say, some system information that doesn't have an existing M3 interface (say the amount of free diskspace or something like that). Then you should be able to call C code that is portable between Unix and Windows. One thing that is bizarre about the old NT386GNU PM3 that doesn't conform to the above description: it uses Windows Time.T. It's all the more bizarre because Cygwin uses Unix time_t. (Time.Now and time(3) are off by a couple of hundred years on NT386GNU, whereas they are the same on all Unixes.) I am sure there are other things. Oh yes, the open-file (default) locking semantics are different too. Those two are actually the only differences that I noticed in the programming environments. Mika Jay writes: >--_d0659847-2f20-454a-9665-5df3b5ce2832_ >Content-Type: text/plain; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > >The conclusion here is: > Just try to convince me otherwise. :) > >The gist of the question is: > Just what characteristics of "Posix" and "Win32" should "NT386GNU" have? > > Just what characteristics of "Posix" do people notice and like? >You can't say "the whole thing". :) > >Restated: > >What is Posix? I don't mean, where is the standard document web site. >I mean what is it TO YOU? > >Is it open/read/write/close? >Is it fork? >Is it sbrk? > On these previous ones, they are interesting to many programmers, > but Modula-3 already layers over all this, so these are unlikely defining >characteristics here. > >Is it sh? Probably somewhat. But if have you sat in Cygwin sh much vs. cmd? > It is annoying. Command line history is flaky. Paths are munged to say /cy= >gdrive. > You lose the critical F8 command line completion against history feature. > You lose a lot of editing capability, but do gain some alternate possibly= > "portable" > similar. > >Is it Perl? No. >Is it X Windows. I doubt it. >Is it pthreads? Probably not. > Or at least vtalarm? Maybe? > Or setjmp/longjmp? Ok. > Longjmp to the same buffer multiple times? Not likely. > Longjmp to a place that has already returned? Not likely. >All full paths starting with a forward slash? Maybe. > Backward slash being a valid non-seperator path character? Maybe. > >Think about that last one. >It is valid and occurs in Win32 code to treat forward slash and backward sl= >ash the same. >Some code does, some code does not. >What if you just did that unconditionally, like even in Posix? >What is the role of backward slash in Posix paths? It either just doesn't o= >ccur, >or is an escape character, or is a regular character. Something at a low le= >vel >could replace the backward slashes with forward slashes. > >I would like to change the code in m3-sys/cm3/m3path.m3 to treat backward s= >lashes >and forward slashes the same. Backward slashes just won't occur on Posix, r= >ight? >So far I have managed without this change, but not having it has bitten me = >a few times. >I do have the analogous change to the Win32 path code in m3core. > >It is the redundant filenames libfoo.a instead of foo.lib and libfoo.so ins= >tead of foo.so? >Perhaps. This seems dumb, redundant to me. Why have prefixes and suffixes? >Don't suffixes suffice? > >That all said, I remain convinced that a useful intermediate or probably en= >dpoint >is a toolset that targets Windows using cm3cg, ld, as, but otherwise looks = >like >NT386 as much as possible. MAYBE alter the library names to libfoo.*. > >sh and make are needed for building cm3cg. >I did use Cygwin for that. MinGWin sounds promising here too but I haven't = >tried. > > - Jay > > >_________________________________________________________________ >Get the power of Windows + Web with the new Windows Live. >http://www.windowslive.com?ocid=3DTXT_TAGHM_Wave2_powerofwindows_012008= > >--_d0659847-2f20-454a-9665-5df3b5ce2832_ >Content-Type: text/html; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > > > > >The conclusion here is:
 Just try to conv= >ince me otherwise. :)

The gist of the question is:
  Just wh= >at characteristics of "Posix" and "Win32" should "NT386GNU" have?

&n= >bsp;Just what characteristics of "Posix" do people notice and like?
You = >can't say "the whole thing". :)

Restated:

What is Posix? I do= >n't mean, where is the standard document web site.
I mean what is it TO = >YOU?

Is it open/read/write/close?
Is it fork?
Is it sbrk?
&= >nbsp; On these previous ones, they are interesting to many programmers,
= > but Modula-3 already layers over all this, so these are unlikely defi= >ning
characteristics here.

Is it sh? Probably somewhat. But if ha= >ve you sat in Cygwin sh much vs. cmd?
 It is annoying. Command line= > history is flaky. Paths are munged to say /cygdrive.
 You lose the= > critical F8 command line completion against history feature.
  You= > lose a lot of editing capability, but do gain some alternate possibly "por= >table"
  similar.

Is it Perl? No.
Is it X Windows. I doub= >t it.
Is it pthreads? Probably not.
  Or at least vtalarm? Maybe= >?
  Or setjmp/longjmp? Ok.
    Longjmp to the sam= >e buffer multiple times? Not likely.
    Longjmp to a pla= >ce that has already returned? Not likely.
All full paths starting with a= > forward slash? Maybe.
  Backward slash being a valid non-seperator= > path character? Maybe.

Think about that last one.
It is valid an= >d occurs in Win32 code to treat forward slash and backward slash the same.<= >br>Some code does, some code does not.
What if you just did that uncondi= >tionally, like even in Posix?
What is the role of backward slash in Posi= >x paths? It either just doesn't occur,
or is an escape character, or is = >a regular character. Something at a low level
could replace the backward= > slashes with forward slashes.

I would like to change the code in m3= >-sys/cm3/m3path.m3 to treat backward slashes
and forward slashes the sam= >e. Backward slashes just won't occur on Posix, right?
So far I have mana= >ged without this change, but not having it has bitten me a few times.
I = >do have the analogous change to the Win32 path code in m3core.

It is= > the redundant filenames libfoo.a instead of foo.lib and libfoo.so instead = >of foo.so?
Perhaps. This seems dumb, redundant to me. Why have prefixes = >and suffixes?
Don't suffixes suffice?

That all said, I remain con= >vinced that a useful intermediate or probably endpoint
is a toolset that= > targets Windows using cm3cg, ld, as, but otherwise looks like
NT386 as = >much as possible. MAYBE alter the library names to libfoo.*.

sh and = >make are needed for building cm3cg.
I did use Cygwin for that. MinGWin s= >ounds promising here too but I haven't tried.

 - Jay

/>
Get the power of Windows + Web with the new Windows Live. =3D'http://www.windowslive.com?ocid=3DTXT_TAGHM_Wave2_powerofwindows_012008= >' target=3D'_new'>Get it now! >= > >--_d0659847-2f20-454a-9665-5df3b5ce2832_-- From jayk123 at hotmail.com Mon Jan 14 02:20:25 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 14 Jan 2008 01:20:25 +0000 Subject: [M3devel] "shared" vs. "standalone" Message-ID: I was experimenting with gcc/ld flags and I realized: There are two bits for shared/dynamic/standalone, sort of. It looks like cm3 only exposes one. They are: I am "shared", I am a .dll, I am an .so, code can link to me and "share" me. There is, I am "standalone", I have limited dependencies, I link to static .libs where possible, even if I am "shared". The same might not be true of my clients. AKA, same as previous, perhaps I am "dynamic" -- I link dynamically to stuff at runtime. IF I am dynamic, then my clients are. But if I am not, they might not be, and, actually, given CM3's provision for .sa files (on Windows at least), I can have it both ways. I can build a "dynamic" file and my clients can chose to use that or not. It looks like CM3 equates these.That is, you cannot build "standalone" .dlls/.sos..dlls/.sos are implicitly not standalone by virtue of being shared. - Jay _________________________________________________________________ Get the power of Windows + Web with the new Windows Live. http://www.windowslive.com?ocid=TXT_TAGHM_Wave2_powerofwindows_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Mon Jan 14 02:30:58 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 14 Jan 2008 01:30:58 +0000 Subject: [M3devel] religion, philosophy, Posix vs. Win32 In-Reply-To: <200801140040.m0E0eHs7046272@camembert.async.caltech.edu> References: Your message of "Sun, 13 Jan 2008 23:36:40 GMT." <200801140040.m0E0eHs7046272@camembert.async.caltech.edu> Message-ID: ok..well...some provision I guess eventually should be made for those who agree with you and Tony. What will come first is something else. :) A system that is Win32 as much as possible, EXCEPT that it uses the gcc-based backend, and as, and ld, and maybe throws around some forward slashes here and there. I weakly propose: NT386GNU be deleted and NT386MINGWIN (NT386MING? I386_MINGWIN? X86_MINGWIN?) and NT386CYGWIN (NT386CYG? I386_CYGWIN? X86_CYGWIN?) takes its place. but not right now. However, it still might be one target, and you edit the config file. It depends on what people define as a "target" and what it means for two "different" things to be the same "target". The same target can link with same target. To a huge extent, NT386 can link with NT386GNU. Different targets get installed to different pkg directories. SOLgnu and SOLsun might provide a similar set of questions/answers, not that I know anything about it. :) Anyway, I'm in a practical mode now, so I'll stop rambling in email. :) There's also the matter of X Windows or not... - Jay > To: jayk123 at hotmail.com> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] religion, philosophy, Posix vs. Win32 > Date: Sun, 13 Jan 2008 16:40:17 -0800> From: mika at async.caltech.edu> > Jay,> > I don't know if this is completely responsive to your question, and> take it with a grain of salt because I have never programmed on a> "pure" Windows system (and God willing, I never shall).> > I expect the NT386GNU target, Cygwin, Windows-POSIX, whatever you> call it, to look as much as Unix "as possible." (Obviously not,> but as "reasonable".) The main things are (1) yes, /bin/sh, and> (2) Unix (POSIX?) libc---Modula-3 does a good job of covering up> the basic stuff so you don't need to worry about it for the most> part, but sometimes, just sometimes, you need to get, say, some> system information that doesn't have an existing M3 interface (say> the amount of free diskspace or something like that). Then you> should be able to call C code that is portable between Unix and> Windows.> > One thing that is bizarre about the old NT386GNU PM3 that doesn't> conform to the above description: it uses Windows Time.T. It's all> the more bizarre because Cygwin uses Unix time_t. (Time.Now and> time(3) are off by a couple of hundred years on NT386GNU, whereas> they are the same on all Unixes.) I am sure there are other things.> Oh yes, the open-file (default) locking semantics are different> too. Those two are actually the only differences that I noticed> in the programming environments.> > Mika> > Jay writes:> >--_d0659847-2f20-454a-9665-5df3b5ce2832_> >Content-Type: text/plain; charset="iso-8859-1"> >Content-Transfer-Encoding: quoted-printable> >> >The conclusion here is:> > Just try to convince me otherwise. :)> >> >The gist of the question is:> > Just what characteristics of "Posix" and "Win32" should "NT386GNU" have?> >> > Just what characteristics of "Posix" do people notice and like?> >You can't say "the whole thing". :)> >> >Restated:> >> >What is Posix? I don't mean, where is the standard document web site.> >I mean what is it TO YOU?> >> >Is it open/read/write/close?> >Is it fork?> >Is it sbrk?> > On these previous ones, they are interesting to many programmers,> > but Modula-3 already layers over all this, so these are unlikely defining> >characteristics here.> >> >Is it sh? Probably somewhat. But if have you sat in Cygwin sh much vs. cmd?> > It is annoying. Command line history is flaky. Paths are munged to say /cy=> >gdrive.> > You lose the critical F8 command line completion against history feature.> > You lose a lot of editing capability, but do gain some alternate possibly=> > "portable"> > similar.> >> >Is it Perl? No.> >Is it X Windows. I doubt it.> >Is it pthreads? Probably not.> > Or at least vtalarm? Maybe?> > Or setjmp/longjmp? Ok.> > Longjmp to the same buffer multiple times? Not likely.> > Longjmp to a place that has already returned? Not likely.> >All full paths starting with a forward slash? Maybe.> > Backward slash being a valid non-seperator path character? Maybe.> >> >Think about that last one.> >It is valid and occurs in Win32 code to treat forward slash and backward sl=> >ash the same.> >Some code does, some code does not.> >What if you just did that unconditionally, like even in Posix?> >What is the role of backward slash in Posix paths? It either just doesn't o=> >ccur,> >or is an escape character, or is a regular character. Something at a low le=> >vel> >could replace the backward slashes with forward slashes.> >> >I would like to change the code in m3-sys/cm3/m3path.m3 to treat backward s=> >lashes> >and forward slashes the same. Backward slashes just won't occur on Posix, r=> >ight?> >So far I have managed without this change, but not having it has bitten me => >a few times.> >I do have the analogous change to the Win32 path code in m3core.> >> >It is the redundant filenames libfoo.a instead of foo.lib and libfoo.so ins=> >tead of foo.so?> >Perhaps. This seems dumb, redundant to me. Why have prefixes and suffixes?> >Don't suffixes suffice?> >> >That all said, I remain convinced that a useful intermediate or probably en=> >dpoint> >is a toolset that targets Windows using cm3cg, ld, as, but otherwise looks => >like> >NT386 as much as possible. MAYBE alter the library names to libfoo.*.> >> >sh and make are needed for building cm3cg.> >I did use Cygwin for that. MinGWin sounds promising here too but I haven't => >tried.> >> > - Jay> >> >> >_________________________________________________________________> >Get the power of Windows + Web with the new Windows Live.> >http://www.windowslive.com?ocid=3DTXT_TAGHM_Wave2_powerofwindows_012008=> >> >--_d0659847-2f20-454a-9665-5df3b5ce2832_> >Content-Type: text/html; charset="iso-8859-1"> >Content-Transfer-Encoding: quoted-printable> >> >> >> >> >> >The conclusion here is:
 Just try to conv=> >ince me otherwise. :)

The gist of the question is:
  Just wh=> >at characteristics of "Posix" and "Win32" should "NT386GNU" have?

&n=> >bsp;Just what characteristics of "Posix" do people notice and like?
You => >can't say "the whole thing". :)

Restated:

What is Posix? I do=> >n't mean, where is the standard document web site.
I mean what is it TO => >YOU?

Is it open/read/write/close?
Is it fork?
Is it sbrk?
&=> >nbsp; On these previous ones, they are interesting to many programmers,
=> > but Modula-3 already layers over all this, so these are unlikely defi=> >ning
characteristics here.

Is it sh? Probably somewhat. But if ha=> >ve you sat in Cygwin sh much vs. cmd?
 It is annoying. Command line=> > history is flaky. Paths are munged to say /cygdrive.
 You lose the=> > critical F8 command line completion against history feature.
  You=> > lose a lot of editing capability, but do gain some alternate possibly "por=> >table"
  similar.

Is it Perl? No.
Is it X Windows. I doub=> >t it.
Is it pthreads? Probably not.
  Or at least vtalarm? Maybe=> >?
  Or setjmp/longjmp? Ok.
    Longjmp to the sam=> >e buffer multiple times? Not likely.
    Longjmp to a pla=> >ce that has already returned? Not likely.
All full paths starting with a=> > forward slash? Maybe.
  Backward slash being a valid non-seperator=> > path character? Maybe.

Think about that last one.
It is valid an=> >d occurs in Win32 code to treat forward slash and backward slash the same.<=> >br>Some code does, some code does not.
What if you just did that uncondi=> >tionally, like even in Posix?
What is the role of backward slash in Posi=> >x paths? It either just doesn't occur,
or is an escape character, or is => >a regular character. Something at a low level
could replace the backward=> > slashes with forward slashes.

I would like to change the code in m3=> >-sys/cm3/m3path.m3 to treat backward slashes
and forward slashes the sam=> >e. Backward slashes just won't occur on Posix, right?
So far I have mana=> >ged without this change, but not having it has bitten me a few times.
I => >do have the analogous change to the Win32 path code in m3core.

It is=> > the redundant filenames libfoo.a instead of foo.lib and libfoo.so instead => >of foo.so?
Perhaps. This seems dumb, redundant to me. Why have prefixes => >and suffixes?
Don't suffixes suffice?

That all said, I remain con=> >vinced that a useful intermediate or probably endpoint
is a toolset that=> > targets Windows using cm3cg, ld, as, but otherwise looks like
NT386 as => >much as possible. MAYBE alter the library names to libfoo.*.

sh and => >make are needed for building cm3cg.
I did use Cygwin for that. MinGWin s=> >ounds promising here too but I haven't tried.

 - Jay

> />
Get the power of Windows + Web with the new Windows Live. >=3D'http://www.windowslive.com?ocid=3DTXT_TAGHM_Wave2_powerofwindows_012008=> >' target=3D'_new'>Get it now!> >=> >> >--_d0659847-2f20-454a-9665-5df3b5ce2832_-- _________________________________________________________________ Put your friends on the big screen with Windows Vista? + Windows Live?. http://www.microsoft.com/windows/shop/specialoffers.mspx?ocid=TXT_TAGLM_CPC_MediaCtr_bigscreen_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.caltech.edu Mon Jan 14 02:55:21 2008 From: mika at async.caltech.edu (Mika Nystrom) Date: Sun, 13 Jan 2008 17:55:21 -0800 Subject: [M3devel] religion, philosophy, Posix vs. Win32 In-Reply-To: Your message of "Mon, 14 Jan 2008 01:30:58 GMT." Message-ID: <200801140155.m0E1tLxU048776@camembert.async.caltech.edu> Well Unix compatibility is what Cygwin "is for"... it's a little odd to have Cygwin pretend to be Windows---if you want Windows, you don't need Cygwin! The old PM3 doesn't use X for its Trestle. It uses native Windows things. Note there is no contradiction between using Windows UI for Trestle and what I said before. Under Cygwin, you want to be able to use X, just like on Unix. But if M3 doesn't use it, well no matter. Although if you want to extend wish lists, sure, it might be nice to be able to build Trestle under X on Cygwin, too. (I mean, why not? It ought to be "trivial", right?) Mika Jay writes: >--_5cf007a7-8622-47c5-8550-283b4142bb52_ >Content-Type: text/plain; charset="Windows-1252" >Content-Transfer-Encoding: quoted-printable > >ok..well...some provision I guess eventually should be made for those who a= >gree with you and Tony. >What will come first is something else. :) > A system that is Win32 as much as possible, EXCEPT that it uses the gcc-ba= >sed backend, and as, and ld, and maybe throws around some forward slashes h= >ere and there. >=20 >I weakly propose: > NT386GNU be deleted > and NT386MINGWIN (NT386MING? I386_MINGWIN? X86_MINGWIN?) > and NT386CYGWIN (NT386CYG? I386_CYGWIN? X86_CYGWIN?) > takes its place. >=20 >but not right now. >=20 >However, it still might be one target, and you edit the config file. >It depends on what people define as a "target" and what it means for two "d= >ifferent" things to be the same "target". >The same target can link with same target. To a huge extent, NT386 can link= > with NT386GNU. >Different targets get installed to different pkg directories. >=20 >SOLgnu and SOLsun might provide a similar set of questions/answers, not tha= >t I know anything about it. :) >=20 >Anyway, I'm in a practical mode now, so I'll stop rambling in email. :) >=20 >There's also the matter of X Windows or not... >=20 > - Jay > >> To: jayk123 at hotmail.com> CC: m3devel at elegosoft.com> Subject: Re: [M3devel= >] religion, philosophy, Posix vs. Win32 > Date: Sun, 13 Jan 2008 16:40:17 -= >0800> From: mika at async.caltech.edu> > Jay,> > I don't know if this is compl= >etely responsive to your question, and> take it with a grain of salt becaus= >e I have never programmed on a> "pure" Windows system (and God willing, I n= >ever shall).> > I expect the NT386GNU target, Cygwin, Windows-POSIX, whatev= >er you> call it, to look as much as Unix "as possible." (Obviously not,> bu= >t as "reasonable".) The main things are (1) yes, /bin/sh, and> (2) Unix (PO= >SIX?) libc---Modula-3 does a good job of covering up> the basic stuff so yo= >u don't need to worry about it for the most> part, but sometimes, just some= >times, you need to get, say, some> system information that doesn't have an = >existing M3 interface (say> the amount of free diskspace or something like = >that). Then you> should be able to call C code that is portable between Uni= >x and> Windows.> > One thing that is bizarre about the old NT386GNU PM3 tha= >t doesn't> conform to the above description: it uses Windows Time.T. It's a= >ll> the more bizarre because Cygwin uses Unix time_t. (Time.Now and> time(3= >) are off by a couple of hundred years on NT386GNU, whereas> they are the s= >ame on all Unixes.) I am sure there are other things.> Oh yes, the open-fil= >e (default) locking semantics are different> too. Those two are actually th= >e only differences that I noticed> in the programming environments.> > Mika= >> > Jay writes:> >--_d0659847-2f20-454a-9665-5df3b5ce2832_> >Content-Type: = >text/plain; charset=3D"iso-8859-1"> >Content-Transfer-Encoding: quoted-prin= >table> >> >The conclusion here is:> > Just try to convince me otherwise. :)= >> >> >The gist of the question is:> > Just what characteristics of "Posix" = >and "Win32" should "NT386GNU" have?> >> > Just what characteristics of "Pos= >ix" do people notice and like?> >You can't say "the whole thing". :)> >> >R= >estated:> >> >What is Posix? I don't mean, where is the standard document w= >eb site.> >I mean what is it TO YOU?> >> >Is it open/read/write/close?> >Is= > it fork?> >Is it sbrk?> > On these previous ones, they are interesting to = >many programmers,> > but Modula-3 already layers over all this, so these ar= >e unlikely defining> >characteristics here.> >> >Is it sh? Probably somewha= >t. But if have you sat in Cygwin sh much vs. cmd?> > It is annoying. Comman= >d line history is flaky. Paths are munged to say /cy=3D> >gdrive.> > You lo= >se the critical F8 command line completion against history feature.> > You = >lose a lot of editing capability, but do gain some alternate possibly=3D> >= > "portable"> > similar.> >> >Is it Perl? No.> >Is it X Windows. I doubt it.= >> >Is it pthreads? Probably not.> > Or at least vtalarm? Maybe?> > Or setjm= >p/longjmp? Ok.> > Longjmp to the same buffer multiple times? Not likely.> >= > Longjmp to a place that has already returned? Not likely.> >All full paths= > starting with a forward slash? Maybe.> > Backward slash being a valid non-= >seperator path character? Maybe.> >> >Think about that last one.> >It is va= >lid and occurs in Win32 code to treat forward slash and backward sl=3D> >as= >h the same.> >Some code does, some code does not.> >What if you just did th= >at unconditionally, like even in Posix?> >What is the role of backward slas= >h in Posix paths? It either just doesn't o=3D> >ccur,> >or is an escape cha= >racter, or is a regular character. Something at a low le=3D> >vel> >could r= >eplace the backward slashes with forward slashes.> >> >I would like to chan= >ge the code in m3-sys/cm3/m3path.m3 to treat backward s=3D> >lashes> >and f= >orward slashes the same. Backward slashes just won't occur on Posix, r=3D> = >>ight?> >So far I have managed without this change, but not having it has b= >itten me =3D> >a few times.> >I do have the analogous change to the Win32 p= >ath code in m3core.> >> >It is the redundant filenames libfoo.a instead of = >foo.lib and libfoo.so ins=3D> >tead of foo.so?> >Perhaps. This seems dumb, = >redundant to me. Why have prefixes and suffixes?> >Don't suffixes suffice?>= > >> >That all said, I remain convinced that a useful intermediate or probab= >ly en=3D> >dpoint> >is a toolset that targets Windows using cm3cg, ld, as, = >but otherwise looks =3D> >like> >NT386 as much as possible. MAYBE alter the= > library names to libfoo.*.> >> >sh and make are needed for building cm3cg.= >> >I did use Cygwin for that. MinGWin sounds promising here too but I haven= >'t =3D> >tried.> >> > - Jay> >> >> >_______________________________________= >__________________________> >Get the power of Windows + Web with the new Wi= >ndows Live.> >http://www.windowslive.com?ocid=3D3DTXT_TAGHM_Wave2_powerofwi= >ndows_012008=3D> >> >--_d0659847-2f20-454a-9665-5df3b5ce2832_> >Content-Typ= >e: text/html; charset=3D"iso-8859-1"> >Content-Transfer-Encoding: quoted-pr= >intable> >> >> >> >> >> >The conclusion here= > is:
 Just try to conv=3D> >ince me otherwise. :)

The gist o= >f the question is:
  Just wh=3D> >at characteristics of "Posix" and= > "Win32" should "NT386GNU" have?

&n=3D> >bsp;Just what characteristi= >cs of "Posix" do people notice and like?
You =3D> >can't say "the whole = >thing". :)

Restated:

What is Posix? I do=3D> >n't mean, where= > is the standard document web site.
I mean what is it TO =3D> >YOU?
<= >br>Is it open/read/write/close?
Is it fork?
Is it sbrk?
&=3D> >nbs= >p; On these previous ones, they are interesting to many programmers,
=3D= >> > but Modula-3 already layers over all this, so these are unlikely d= >efi=3D> >ning
characteristics here.

Is it sh? Probably somewhat. = >But if ha=3D> >ve you sat in Cygwin sh much vs. cmd?
 It is annoyin= >g. Command line=3D> > history is flaky. Paths are munged to say /cygdrive.<= >br> You lose the=3D> > critical F8 command line completion against his= >tory feature.
  You=3D> > lose a lot of editing capability, but do = >gain some alternate possibly "por=3D> >table"
  similar.

Is = >it Perl? No.
Is it X Windows. I doub=3D> >t it.
Is it pthreads? Proba= >bly not.
  Or at least vtalarm? Maybe=3D> >?
  Or setjmp/lo= >ngjmp? Ok.
    Longjmp to the sam=3D> >e buffer multiple = >times? Not likely.
    Longjmp to a pla=3D> >ce that has = >already returned? Not likely.
All full paths starting with a=3D> > forwa= >rd slash? Maybe.
  Backward slash being a valid non-seperator=3D> >= > path character? Maybe.

Think about that last one.
It is valid an= >=3D> >d occurs in Win32 code to treat forward slash and backward slash the = >same.<=3D> >br>Some code does, some code does not.
What if you just did = >that uncondi=3D> >tionally, like even in Posix?
What is the role of back= >ward slash in Posi=3D> >x paths? It either just doesn't occur,
or is an = >escape character, or is =3D> >a regular character. Something at a low level= >
could replace the backward=3D> > slashes with forward slashes.

I= > would like to change the code in m3=3D> >-sys/cm3/m3path.m3 to treat backw= >ard slashes
and forward slashes the sam=3D> >e. Backward slashes just wo= >n't occur on Posix, right?
So far I have mana=3D> >ged without this chan= >ge, but not having it has bitten me a few times.
I =3D> >do have the ana= >logous change to the Win32 path code in m3core.

It is=3D> > the redu= >ndant filenames libfoo.a instead of foo.lib and libfoo.so instead =3D> >of = >foo.so?
Perhaps. This seems dumb, redundant to me. Why have prefixes =3D= >> >and suffixes?
Don't suffixes suffice?

That all said, I remain = >con=3D> >vinced that a useful intermediate or probably endpoint
is a too= >lset that=3D> > targets Windows using cm3cg, ld, as, but otherwise looks li= >ke
NT386 as =3D> >much as possible. MAYBE alter the library names to lib= >foo.*.

sh and =3D> >make are needed for building cm3cg.
I did use= > Cygwin for that. MinGWin s=3D> >ounds promising here too but I haven't tri= >ed.

 - Jay

> />
Get the power of Windows + = >Web with the new Windows Live. >=3D3D'http://www.windowslive.co= >m?ocid=3D3DTXT_TAGHM_Wave2_powerofwindows_012008=3D> >' target=3D3D'_new'>G= >et it now!> >=3D> >> >--_d0659847-2f20-454a-9665-5df3b5ce= >2832_-- >_________________________________________________________________ >Put your friends on the big screen with Windows Vista=AE + Windows Live=99. >http://www.microsoft.com/windows/shop/specialoffers.mspx?ocid=3DTXT_TAGLM_C= >PC_MediaCtr_bigscreen_012008= > >--_5cf007a7-8622-47c5-8550-283b4142bb52_ >Content-Type: text/html; charset="Windows-1252" >Content-Transfer-Encoding: quoted-printable > > > > > >ok..well...some provision I guess eventually shou= >ld be made for those who agree with you and Tony.
>What will come first is something else. :)
> A system that is Win32 as much as possible, EXCEPT that it uses the g= >cc-based backend, and as, and ld, and maybe throws around some forward slas= >hes here and there.
> 
>I weakly propose:
>  NT386GNU be deleted
>  and NT386MINGWIN (NT386MING? I386_MINGWIN? X86_MINGWIN?)
>  and NT386CYGWIN (NT386CYG? I386_CYGWIN? X86_CYGWIN?)
> takes its place.
> 
>but not right now.
> 
>However, it still might be one target, and you edit the config file.
>It depends on what people define as a "target" and what it means for two "d= >ifferent" things to be the same "target".
>The same target can link with same target. To a huge extent, NT386 can link= > with NT386GNU.
>Different targets get installed to different pkg directories.
> 
>SOLgnu and SOLsun might provide a similar set of questions/answers, not tha= >t I know anything about it. :)
> 
>Anyway, I'm in a practical mode now, so I'll stop rambling in email. :)
> 
>There's also the matter of X Windows or not...
> 
> - Jay

>
>> To: jayk123 at hotmail.com
> CC: m3devel at elegosoft.com
> Subj= >ect: Re: [M3devel] religion, philosophy, Posix vs. Win32
> Date: Sun= >, 13 Jan 2008 16:40:17 -0800
> From: mika at async.caltech.edu
> <= >BR>> Jay,
>
> I don't know if this is completely responsive= > to your question, and
> take it with a grain of salt because I have = >never programmed on a
> "pure" Windows system (and God willing, I nev= >er shall).
>
> I expect the NT386GNU target, Cygwin, Windows-P= >OSIX, whatever you
> call it, to look as much as Unix "as possible." = >(Obviously not,
> but as "reasonable".) The main things are (1) yes, = >/bin/sh, and
> (2) Unix (POSIX?) libc---Modula-3 does a good job of c= >overing up
> the basic stuff so you don't need to worry about it for = >the most
> part, but sometimes, just sometimes, you need to get, say,= > some
> system information that doesn't have an existing M3 interface= > (say
> the amount of free diskspace or something like that). Then yo= >u
> should be able to call C code that is portable between Unix andR>> Windows.
>
> One thing that is bizarre about the old NT= >386GNU PM3 that doesn't
> conform to the above description: it uses W= >indows Time.T. It's all
> the more bizarre because Cygwin uses Unix t= >ime_t. (Time.Now and
> time(3) are off by a couple of hundred years o= >n NT386GNU, whereas
> they are the same on all Unixes.) I am sure the= >re are other things.
> Oh yes, the open-file (default) locking semant= >ics are different
> too. Those two are actually the only differences = >that I noticed
> in the programming environments.
>
> Mi= >ka
>
> Jay writes:
> >--_d0659847-2f20-454a-9665-5df3= >b5ce2832_
> >Content-Type: text/plain; charset=3D"iso-8859-1"
&= >gt; >Content-Transfer-Encoding: quoted-printable
> >
> &g= >t;The conclusion here is:
> > Just try to convince me otherwise. := >)
> >
> >The gist of the question is:
> > Just w= >hat characteristics of "Posix" and "Win32" should "NT386GNU" have?
> = >>
> > Just what characteristics of "Posix" do people notice and= > like?
> >You can't say "the whole thing". :)
> >
>= > >Restated:
> >
> >What is Posix? I don't mean, where = >is the standard document web site.
> >I mean what is it TO YOU?>> >
> >Is it open/read/write/close?
> >Is it fork?= >
> >Is it sbrk?
> > On these previous ones, they are inte= >resting to many programmers,
> > but Modula-3 already layers over = >all this, so these are unlikely defining
> >characteristics here.<= >BR>> >
> >Is it sh? Probably somewhat. But if have you sat i= >n Cygwin sh much vs. cmd?
> > It is annoying. Command line history= > is flaky. Paths are munged to say /cy=3D
> >gdrive.
> > = >You lose the critical F8 command line completion against history feature.R>> > You lose a lot of editing capability, but do gain some alternat= >e possibly=3D
> > "portable"
> > similar.
> >>> >Is it Perl? No.
> >Is it X Windows. I doubt it.
> = >>Is it pthreads? Probably not.
> > Or at least vtalarm? Maybe?<= >BR>> > Or setjmp/longjmp? Ok.
> > Longjmp to the same buffer= > multiple times? Not likely.
> > Longjmp to a place that has alrea= >dy returned? Not likely.
> >All full paths starting with a forward= > slash? Maybe.
> > Backward slash being a valid non-seperator path= > character? Maybe.
> >
> >Think about that last one.
&= >gt; >It is valid and occurs in Win32 code to treat forward slash and bac= >kward sl=3D
> >ash the same.
> >Some code does, some code= > does not.
> >What if you just did that unconditionally, like even= > in Posix?
> >What is the role of backward slash in Posix paths? I= >t either just doesn't o=3D
> >ccur,
> >or is an escape ch= >aracter, or is a regular character. Something at a low le=3D
> >ve= >l
> >could replace the backward slashes with forward slashes.
&= >gt; >
> >I would like to change the code in m3-sys/cm3/m3path.m= >3 to treat backward s=3D
> >lashes
> >and forward slashes= > the same. Backward slashes just won't occur on Posix, r=3D
> >igh= >t?
> >So far I have managed without this change, but not having it= > has bitten me =3D
> >a few times.
> >I do have the analo= >gous change to the Win32 path code in m3core.
> >
> >It i= >s the redundant filenames libfoo.a instead of foo.lib and libfoo.so ins=3D<= >BR>> >tead of foo.so?
> >Perhaps. This seems dumb, redundant= > to me. Why have prefixes and suffixes?
> >Don't suffixes suffice?= >
> >
> >That all said, I remain convinced that a useful i= >ntermediate or probably en=3D
> >dpoint
> >is a toolset t= >hat targets Windows using cm3cg, ld, as, but otherwise looks =3D
> &g= >t;like
> >NT386 as much as possible. MAYBE alter the library names= > to libfoo.*.
> >
> >sh and make are needed for building = >cm3cg.
> >I did use Cygwin for that. MinGWin sounds promising here= > too but I haven't =3D
> >tried.
> >
> > - JayR>> >
> >
> >______________________________________= >___________________________
> >Get the power of Windows + Web with= > the new Windows Live.
> >http://www.windowslive.com?ocid=3D3DTXT_= >TAGHM_Wave2_powerofwindows_012008=3D
> >
> >--_d0659847-2= >f20-454a-9665-5df3b5ce2832_
> >Content-Type: text/html; charset=3D= >"iso-8859-1"
> >Content-Transfer-Encoding: quoted-printable
>= >; >
> ><html>
> ><head>
> ><st= >yle>
> >.hmmessage P
> >{
> >margin:0px;
&= >gt; >padding:0px
> >}
> >body.hmmessage
> >{<= >BR>> >FONT-SIZE: 10pt;
> >FONT-FAMILY:Tahoma
> >}R>> ></style>
> ></head>
> ><body cl= >ass=3D3D'hmmessage'>The conclusion here is:<br>&nbsp;Just try = >to conv=3D
> >ince me otherwise. :)<br><br>The gist of= > the question is:<br>&nbsp; Just wh=3D
> >at characteris= >tics of "Posix" and "Win32" should "NT386GNU" have?<br><br>&= >;n=3D
> >bsp;Just what characteristics of "Posix" do people notice= > and like?<br>You =3D
> >can't say "the whole thing". :)<= >br><br>Restated:<br><br>What is Posix? I do=3D
>= > >n't mean, where is the standard document web site.<br>I mean wha= >t is it TO =3D
> >YOU?<br><br>Is it open/read/write/cl= >ose?<br>Is it fork?<br>Is it sbrk?<br>&=3D
> &g= >t;nbsp; On these previous ones, they are interesting to many programmers,&l= >t;br>=3D
> >&nbsp;but Modula-3 already layers over all this= >, so these are unlikely defi=3D
> >ning<br>characteristics h= >ere.<br><br>Is it sh? Probably somewhat. But if ha=3D
> &= >gt;ve you sat in Cygwin sh much vs. cmd?<br>&nbsp;It is annoying.= > Command line=3D
> > history is flaky. Paths are munged to say /cy= >gdrive.<br>&nbsp;You lose the=3D
> > critical F8 command= > line completion against history feature.<br>&nbsp; You=3D
>= >; > lose a lot of editing capability, but do gain some alternate possibl= >y "por=3D
> >table"<br>&nbsp; similar.<br><br&g= >t;Is it Perl? No.<br>Is it X Windows. I doub=3D
> >t it.<= >br>Is it pthreads? Probably not.<br>&nbsp; Or at least vtalarm= >? Maybe=3D
> >?<br>&nbsp; Or setjmp/longjmp? Ok.<br&g= >t;&nbsp;&nbsp;&nbsp; Longjmp to the sam=3D
> >e buffer= > multiple times? Not likely.<br>&nbsp;&nbsp;&nbsp; Longjm= >p to a pla=3D
> >ce that has already returned? Not likely.<br&g= >t;All full paths starting with a=3D
> > forward slash? Maybe.<b= >r>&nbsp; Backward slash being a valid non-seperator=3D
> > = >path character? Maybe.<br><br>Think about that last one.<br&= >gt;It is valid an=3D
> >d occurs in Win32 code to treat forward sl= >ash and backward slash the same.<=3D
> >br>Some code does, s= >ome code does not.<br>What if you just did that uncondi=3D
> &g= >t;tionally, like even in Posix?<br>What is the role of backward slash= > in Posi=3D
> >x paths? It either just doesn't occur,<br>or = >is an escape character, or is =3D
> >a regular character. Somethin= >g at a low level<br>could replace the backward=3D
> > slashe= >s with forward slashes.<br><br>I would like to change the code = >in m3=3D
> >-sys/cm3/m3path.m3 to treat backward slashes<br>= >and forward slashes the sam=3D
> >e. Backward slashes just won't o= >ccur on Posix, right?<br>So far I have mana=3D
> >ged withou= >t this change, but not having it has bitten me a few times.<br>I =3D<= >BR>> >do have the analogous change to the Win32 path code in m3core.&= >lt;br><br>It is=3D
> > the redundant filenames libfoo.a i= >nstead of foo.lib and libfoo.so instead =3D
> >of foo.so?<br>= >;Perhaps. This seems dumb, redundant to me. Why have prefixes =3D
> &= >gt;and suffixes?<br>Don't suffixes suffice?<br><br>That a= >ll said, I remain con=3D
> >vinced that a useful intermediate or p= >robably endpoint<br>is a toolset that=3D
> > targets Windows= > using cm3cg, ld, as, but otherwise looks like<br>NT386 as =3D
>= >; >much as possible. MAYBE alter the library names to libfoo.*.<br>= >;<br>sh and =3D
> >make are needed for building cm3cg.<br= >>I did use Cygwin for that. MinGWin s=3D
> >ounds promising her= >e too but I haven't tried.<br><br>&nbsp;- Jay<br><= >br><br=3D
> > /><hr />Get the power of Windows + We= >b with the new Windows Live. <a href=3D
> >=3D3D'http://www.win= >dowslive.com?ocid=3D3DTXT_TAGHM_Wave2_powerofwindows_012008=3D
> >= >' target=3D3D'_new'>Get it now!</a></body>
> ></= >html>=3D
> >
> >--_d0659847-2f20-454a-9665-5df3b5ce283= >2_--


Put your friends on the big screen with Windows Vis= >ta=AE + Windows Live=99. pecialoffers.mspx?ocid=3DTXT_TAGLM_CPC_MediaCtr_bigscreen_012008' target=3D= >'_new'>Start now! >= > >--_5cf007a7-8622-47c5-8550-283b4142bb52_-- From dabenavidesd at yahoo.es Mon Jan 14 03:32:37 2008 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Mon, 14 Jan 2008 03:32:37 +0100 (CET) Subject: [M3devel] religion, philosophy, Posix vs. Win32 In-Reply-To: <200801140040.m0E0eHs7046272@camembert.async.caltech.edu> Message-ID: <17920.29413.qm@web27103.mail.ukl.yahoo.com> Hi all, Yes, I also noticed the Time.T issue in pm3 1.1.15 because I was trying to get compiled m3browser and I finally arranged to do that, but the program just broke, and I didn't know about cygwin differences against a real UNIX platform. Also in that pm3 NT386GNU, the winvbt implementation was the one of dec-src not like current cm3 winvbt (that use WIDECHAR as I remember) I tried to have the same interfaces to be able to use from m3browser. Now fortunately you can compile m3browser with NT386 cm3 platform. I just liked very much the way one can make a bootstrap from pm3 from one platform to another and make a minimal compiler for NT386GNU: http://tkb.mpl.com/~tkb/software/misc/pm3-NT386GNU.patch I couldn't repeat the above link instructions in a Debian Sarge machine, with all the pm3 Debian packages installed (available in the Debian Woody http://archive.debian.org/pool/main/p/pm3/ ) I think the reason was I was unable to do all the bootstrap process http://archive.debian.org/pool/main/p/pm3-i386 I would like to have that kind of posix to cygwin capability of port at least a minimal compiler/runtime system. Also, talking about the topic of port NT386 to NT386GNU (more than a year ago) I got some answer from Bert Laverman, Daniel Benavides wrote: > What if we use the cygwin platform to run cm3, an use its runtime > of linker and c Compiler? "Normally this involves a speed penalty, because cygwin will emulate a UNIX environment, and has to translate this to Windows calls. The advantage is of course that you can ignore most differences between Windows and UNIX. If you don't want the speed penalty, and can take care of the platform differences, then you can use the -mno-cygwin flag. However, make sure you use only "real" Windows API calls." Bert Laverman Thanks Mika Nystrom escribi?: Jay, I don't know if this is completely responsive to your question, and take it with a grain of salt because I have never programmed on a "pure" Windows system (and God willing, I never shall). I expect the NT386GNU target, Cygwin, Windows-POSIX, whatever you call it, to look as much as Unix "as possible." (Obviously not, but as "reasonable".) The main things are (1) yes, /bin/sh, and (2) Unix (POSIX?) libc---Modula-3 does a good job of covering up the basic stuff so you don't need to worry about it for the most part, but sometimes, just sometimes, you need to get, say, some system information that doesn't have an existing M3 interface (say the amount of free diskspace or something like that). Then you should be able to call C code that is portable between Unix and Windows. One thing that is bizarre about the old NT386GNU PM3 that doesn't conform to the above description: it uses Windows Time.T. It's all the more bizarre because Cygwin uses Unix time_t. (Time.Now and time(3) are off by a couple of hundred years on NT386GNU, whereas they are the same on all Unixes.) I am sure there are other things. Oh yes, the open-file (default) locking semantics are different too. Those two are actually the only differences that I noticed in the programming environments. Mika Jay writes: >--_d0659847-2f20-454a-9665-5df3b5ce2832_ >Content-Type: text/plain; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > >The conclusion here is: > Just try to convince me otherwise. :) > >The gist of the question is: > Just what characteristics of "Posix" and "Win32" should "NT386GNU" have? > > Just what characteristics of "Posix" do people notice and like? >You can't say "the whole thing". :) > >Restated: > >What is Posix? I don't mean, where is the standard document web site. >I mean what is it TO YOU? > >Is it open/read/write/close? >Is it fork? >Is it sbrk? > On these previous ones, they are interesting to many programmers, > but Modula-3 already layers over all this, so these are unlikely defining >characteristics here. > >Is it sh? Probably somewhat. But if have you sat in Cygwin sh much vs. cmd? > It is annoying. Command line history is flaky. Paths are munged to say /cy= >gdrive. > You lose the critical F8 command line completion against history feature. > You lose a lot of editing capability, but do gain some alternate possibly= > "portable" > similar. > >Is it Perl? No. >Is it X Windows. I doubt it. >Is it pthreads? Probably not. > Or at least vtalarm? Maybe? > Or setjmp/longjmp? Ok. > Longjmp to the same buffer multiple times? Not likely. > Longjmp to a place that has already returned? Not likely. >All full paths starting with a forward slash? Maybe. > Backward slash being a valid non-seperator path character? Maybe. > >Think about that last one. >It is valid and occurs in Win32 code to treat forward slash and backward sl= >ash the same. >Some code does, some code does not. >What if you just did that unconditionally, like even in Posix? >What is the role of backward slash in Posix paths? It either just doesn't o= >ccur, >or is an escape character, or is a regular character. Something at a low le= >vel >could replace the backward slashes with forward slashes. > >I would like to change the code in m3-sys/cm3/m3path.m3 to treat backward s= >lashes >and forward slashes the same. Backward slashes just won't occur on Posix, r= >ight? >So far I have managed without this change, but not having it has bitten me = >a few times. >I do have the analogous change to the Win32 path code in m3core. > >It is the redundant filenames libfoo.a instead of foo.lib and libfoo.so ins= >tead of foo.so? >Perhaps. This seems dumb, redundant to me. Why have prefixes and suffixes? >Don't suffixes suffice? > >That all said, I remain convinced that a useful intermediate or probably en= >dpoint >is a toolset that targets Windows using cm3cg, ld, as, but otherwise looks = >like >NT386 as much as possible. MAYBE alter the library names to libfoo.*. > >sh and make are needed for building cm3cg. >I did use Cygwin for that. MinGWin sounds promising here too but I haven't = >tried. > > - Jay > > >_________________________________________________________________ >Get the power of Windows + Web with the new Windows Live. >http://www.windowslive.com?ocid=3DTXT_TAGHM_Wave2_powerofwindows_012008= > >--_d0659847-2f20-454a-9665-5df3b5ce2832_ >Content-Type: text/html; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > > > >.hmmessage P >{ >margin:0px; >padding:0px >} >body.hmmessage >{ >FONT-SIZE: 10pt; >FONT-FAMILY:Tahoma >} > > >The conclusion here is: Just try to conv= >ince me otherwise. :) The gist of the question is: Just wh= >at characteristics of "Posix" and "Win32" should "NT386GNU" have? &n= >bsp;Just what characteristics of "Posix" do people notice and like? You = >can't say "the whole thing". :) Restated: What is Posix? I do= >n't mean, where is the standard document web site. I mean what is it TO = >YOU? Is it open/read/write/close? Is it fork? Is it sbrk? &= >nbsp; On these previous ones, they are interesting to many programmers, = > but Modula-3 already layers over all this, so these are unlikely defi= >ning characteristics here. Is it sh? Probably somewhat. But if ha= >ve you sat in Cygwin sh much vs. cmd? It is annoying. Command line= > history is flaky. Paths are munged to say /cygdrive. You lose the= > critical F8 command line completion against history feature. You= > lose a lot of editing capability, but do gain some alternate possibly "por= >table" similar. Is it Perl? No. Is it X Windows. I doub= >t it. Is it pthreads? Probably not. Or at least vtalarm? Maybe= >? Or setjmp/longjmp? Ok. Longjmp to the sam= >e buffer multiple times? Not likely. Longjmp to a pla= >ce that has already returned? Not likely. All full paths starting with a= > forward slash? Maybe. Backward slash being a valid non-seperator= > path character? Maybe. Think about that last one. It is valid an= >d occurs in Win32 code to treat forward slash and backward slash the same.<= >br>Some code does, some code does not. What if you just did that uncondi= >tionally, like even in Posix? What is the role of backward slash in Posi= >x paths? It either just doesn't occur, or is an escape character, or is = >a regular character. Something at a low level could replace the backward= > slashes with forward slashes. I would like to change the code in m3= >-sys/cm3/m3path.m3 to treat backward slashes and forward slashes the sam= >e. Backward slashes just won't occur on Posix, right? So far I have mana= >ged without this change, but not having it has bitten me a few times. I = >do have the analogous change to the Win32 path code in m3core. It is= > the redundant filenames libfoo.a instead of foo.lib and libfoo.so instead = >of foo.so? Perhaps. This seems dumb, redundant to me. Why have prefixes = >and suffixes? Don't suffixes suffice? That all said, I remain con= >vinced that a useful intermediate or probably endpoint is a toolset that= > targets Windows using cm3cg, ld, as, but otherwise looks like NT386 as = >much as possible. MAYBE alter the library names to libfoo.*. sh and = >make are needed for building cm3cg. I did use Cygwin for that. MinGWin s= >ounds promising here too but I haven't tried. - Jay > /> --------------------------------- Get the power of Windows + Web with the new Windows Live. >=3D'http://www.windowslive.com?ocid=3DTXT_TAGHM_Wave2_powerofwindows_012008= >' target=3D'_new'>Get it now! >= > >--_d0659847-2f20-454a-9665-5df3b5ce2832_-- --------------------------------- Web Revelaci?n Yahoo! 2007: Premio Favorita del P?blico - ?Vota tu preferida! -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Mon Jan 14 05:39:19 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 14 Jan 2008 04:39:19 +0000 Subject: [M3devel] religion, philosophy, Posix vs. Win32 In-Reply-To: <17920.29413.qm@web27103.mail.ukl.yahoo.com> References: <200801140040.m0E0eHs7046272@camembert.async.caltech.edu> <17920.29413.qm@web27103.mail.ukl.yahoo.com> Message-ID: I agree cross-buildability is nice. That is something NT-non-GNU will never have to the extent that NT-GNU would have, other than cross building from Windows x86 <=> Windows AMD64, etc., or NT => CE, or NT <=> 9x, which is all a fairly large set of cross combinations that do work.. You can have portability at one or more layers..and all that. How many/much do you want? At the Modula-3 level and at the C level and at the command line human interface/"scripting" level (for scripting, just use Quake or Perl or Python, really). For now my priority is using the gcc backend and the associated as and ld and possibly dlltool. And buildability of the gcc backend which requires much more, but is easy enough, I cross that bridge days ago. For some reason the gcc produced mklib.exe crashes at startup, I believe here:C:\dev2\cm3.2\m3-libs\m3core\src\runtime\common\RTLinker.m3(81): IF (imp.import = NIL) THEN imp.import := imp.binder (0); END;or here: C:\dev2\cm3.2\m3-libs\m3core\src\runtime\common\RTLinker.m3(182): IF (imp.import = NIL) THEN imp.import := imp.binder (0); END; imp.binder is NULL. I'm sure there was a check for NULL followed by a jump to NULL and recall the callstack was to around here. You can actually debug it with gdb. :) That was kind of nice. I'm not sure about looking at globals -- info globals just said I had void pointers, but at least I could see the stack. Not that I must use mklib, but I was considering it, and it should work.... 32 bit time_t is a nightmare waiting to happen. Have folks upgraded to 64 bit time_t? Win32, depending on the layer, supports 32 bit time_t seconds since 1970, 64 bit time_t I assume with the same start, and 64 bit time since 1601 something like 100's of nanoseconds, low enough precision to have a plenty large range (i.e. it isn't measuring 4 billionths of seconds and therefore would have already run out. :) ) Having time start at 1970 can be a bit inconenient. It is fine for the timestamps on files, but, e.g. for birthdays? Admittedly 1601 isn't adequate either for historical purposes, and eventually, if you are dealing with history, the Gregorian calendar runs out back in time and things get even much more complicated. :) - Jay Date: Mon, 14 Jan 2008 03:32:37 +0100From: dabenavidesd at yahoo.esSubject: Re: [M3devel] religion, philosophy, Posix vs. Win32To: mika at async.caltech.edu; jayk123 at hotmail.comCC: m3devel at elegosoft.comHi all,Yes, I also noticed the Time.T issue in pm3 1.1.15 because I was trying to get compiled m3browser and I finally arranged to do that, but the program just broke, and I didn't know about cygwin differences against a real UNIX platform.Also in that pm3 NT386GNU, the winvbt implementation was the one of dec-src not like current cm3 winvbt (that use WIDECHAR as I remember)I tried to have the same interfaces to be able to use from m3browser.Now fortunately you can compile m3browser with NT386 cm3 platform.I just liked very much the way one can make a bootstrap from pm3 from one platform to another and make a minimal compiler for NT386GNU:http://tkb.mpl.com/~tkb/software/misc/pm3-NT386GNU.patchI couldn't repeat the above link instructions in a Debian Sarge machine, with all the pm3 Debian packages installed (available in the Debian Woody http://archive.debian.org/pool/main/p/pm3/ ) I think the reason was I was unable to do all the bootstrap process http://archive.debian.org/pool/main/p/pm3-i386I would like to have that kind of posix to cygwin capability of port at least a minimal compiler/runtime system.Also, talking about the topic of port NT386 to NT386GNU (more than a year ago) I got some answer from Bert Laverman, Daniel Benavides wrote: > What if we use the cygwin platform to run cm3, an use its runtime > of linker and c Compiler? "Normally this involves a speed penalty, because cygwin will emulate a UNIX environment, and has to translate this to Windows calls. The advantage is of course that you can ignore most differences between Windows and UNIX. If you don't want the speed penalty, and can take care of the platform differences, then you can use the -mno-cygwin flag. However, make sure you use only "real" Windows API calls." Bert LavermanThanksMika Nystrom escribi?: Jay,I don't know if this is completely responsive to your question, andtake it with a grain of salt because I have never programmed on a"pure" Windows system (and God willing, I never shall).I expect the NT386GNU target, Cygwin, Windows-POSIX, whatever youcall it, to look as much as Unix "as possible." (Obviously not,but as "reasonable".) The main things are (1) yes, /bin/sh, and(2) Unix (POSIX?) libc---Modula-3 does a good job of covering upthe basic stuff so you don't need to worry about it for the mostpart, but sometimes, just sometimes, you need to get, say, somesystem information that doesn't have an existing M3 interface (saythe amount of free diskspace or something like that). Then youshould be able to call C code that is portable between Unix andWindows.One thing that is bizarre about the old NT386GNU PM3 that doesn'tconform to the above description: it uses Windows Time.T. It's allthe more bizarre because Cygwin uses Unix time_t. (Time.Now andtime(3) are off by a couple of hundred years on NT386GNU, whereasthey are the same on all Unixes.) I am sure there are other things.Oh yes, the open-file (default) locking semantics are differenttoo. Those two are actually the only differences that I noticedin the programming environments.MikaJay writes:>--_d0659847-2f20-454a-9665-5df3b5ce2832_>Content-Type: text/plain; charset="iso-8859-1">Content-Transfer-Encoding: quoted-printable>>The conclusion here is:> Just try to convince me otherwise. :)>>The gist of the question is:> Just what characteristics of "Posix" and "Win32" should "NT386GNU" have?>> Just what characteristics of "Posix" do people notice and like?>You can't say "the whole thing". :)>>Restated:>>What is Posix? I don't mean, where is the standard document web site.>I mean what is it TO YOU?>>Is it open/read/write/close?>Is it fork?>Is it sbrk?> On these previous ones, they are interesting to many programmers,> but Modula-3 already layers over all this, so these are unlikely defining>characteristics here.>>Is it sh? Probably somewhat. But if have you sat in Cygwin sh much vs. cmd?> It is annoying. Command line history is flaky. Paths are munged to say /cy=>gdrive.> You lose the critical F8 command line completion against history feature.> You lose a lot of editing capability, but do gain some alternate possibly=> "portable"> similar.>>Is it Perl? No.>Is it X Windows. I doubt it.>Is it pthreads? Probably not.> Or at least vtalarm? Maybe?> Or setjmp/longjmp? Ok.> Longjmp to the same buffer multiple times? Not likely.> Longjmp to a place that has already returned? Not likely.>All full paths starting with a forward slash? Maybe.> Backward slash being a valid non-seperator path character? Maybe.>>Think about that last one.>It is valid and occurs in Win32 code to treat forward slash and backward sl=>ash the same.>Some code does, some code does not.>What if you just did that unconditionally, like even in Posix?>What is the role of backward slash in Posix paths? It either just doesn't o=>ccur,>or is an escape character, or is a regular character. Something at a low le=>vel>could replace the backward slashes with forward slashes.>>I would like to change the code in m3-sys/cm3/m3path.m3 to treat backward s=>lashes>and forward slashes the same. Backward slashes just won't occur on Posix, r=>ight?>So far I have managed without this change, but not having it has bitten me =>a few times.>I do have the analogous change to the Win32 path code in m3core.>>It is the redundant filenames libfoo.a instead of foo.lib and libfoo.so ins=>tead of foo.so?>Perhaps. This seems dumb, redundant to me. Why have prefixes and suffixes?>Don't suffixes suffice?>>That all said, I remain convinced that a useful intermediate or probably en=>dpoint>is a toolset that targets Windows using cm3cg, ld, as, but otherwise looks =>like>NT386 as much as possible. MAYBE alter the library names to libfoo.*.>>sh and make are needed for building cm3cg.>I did use Cygwin for that. MinGWin sounds promising here too but I haven't =>tried.>> - Jay>>>_________________________________________________________________>Get the power of Windows + Web with the new Windows Live.>http://www.windowslive.com?ocid=3DTXT_TAGHM_Wave2_powerofwindows_012008=>>--_d0659847-2f20-454a-9665-5df3b5ce2832_>Content-Type: text/html; charset="iso-8859-1">Content-Transfer-Encoding: quoted-printable>>>> >>The conclusion here is: Just try to conv=>ince me otherwise. :)The gist of the question is: Just wh=>at characteristics of "Posix" and "Win32" should "NT386GNU" have?&n=>bsp;Just what characteristics of "Posix" do people notice and like?You =>can't say "the whole thing". :)Restated:What is Posix? I do=>n't mean, where is the standard document web site.I mean what is it TO =>YOU?Is it open/read/write/close?Is it fork?Is it sbrk?&=>nbsp; On these previous ones, they are interesting to many programmers,=> but Modula-3 already layers over all this, so these are unlikely defi=>ningcharacteristics here.Is it sh? Probably somewhat. But if ha=>ve you sat in Cygwin sh much vs. cmd? It is annoying. Command line=> history is flaky. Paths are munged to say /cygdrive. You lose the=> critical F8 command line completion against history feature. You=> lose a lot of editing capability, but do gain some alternate possibly "por=>table" similar.Is it Perl? No.Is it X Windows. I doub=>t it.Is it pthreads? Probably not. Or at least vtalarm? Maybe=>? Or setjmp/longjmp? Ok. Longjmp to the sam=>e buffer multiple times? Not likely. Longjmp to a pla=>ce that has already returned? Not likely.All full paths starting with a=> forward slash? Maybe. Backward slash being a valid non-seperator=> path character? Maybe.Think about that last one.It is valid an=>d occurs in Win32 code to treat forward slash and backward slash the same.<=>br>Some code does, some code does not.What if you just did that uncondi=>tionally, like even in Posix?What is the role of backward slash in Posi=>x paths? It either just doesn't occur,or is an escape character, or is =>a regular character. Something at a low levelcould replace the backward=> slashes with forward slashes.I would like to change the code in m3=>-sys/cm3/m3path.m3 to treat backward slashesand forward slashes the sam=>e. Backward slashes just won't occur on Posix, right?So far I have mana=>ged without this change, but not having it has bitten me a few times.I =>do have the analogous change to the Win32 path code in m3core.It is=> the redundant filenames libfoo.a instead of foo.lib and libfoo.so instead =>of foo.so?Perhaps. This seems dumb, redundant to me. Why have prefixes =>and suffixes?Don't suffixes suffice?That all said, I remain con=>vinced that a useful intermediate or probably endpointis a toolset that=> targets Windows using cm3cg, ld, as, but otherwise looks likeNT386 as =>much as possible. MAYBE alter the library names to libfoo.*.sh and =>make are needed for building cm3cg.I did use Cygwin for that. MinGWin s=>ounds promising here too but I haven't tried. - Jay> /> Get the power of Windows + Web with the new Windows Live. >=3D'http://www.windowslive.com?ocid=3DTXT_TAGHM_Wave2_powerofwindows_012008=>' target=3D'_new'>Get it now!>=>>--_d0659847-2f20-454a-9665-5df3b5ce2832_-- Web Revelaci?n Yahoo! 2007:Premio Favorita del P?blico - ?Vota tu preferida! _________________________________________________________________ Watch ?Cause Effect,? a show about real people making a real difference. http://im.live.com/Messenger/IM/MTV/?source=text_watchcause -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon Jan 14 16:47:28 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 14 Jan 2008 10:47:28 -0500 Subject: [M3devel] Static chains Message-ID: Rodney, I just realised that the static chains variables are *not* always being set up for nested function internal use. i.e., callers will pass them, but nested functions that don't explicitly use them will not have a static chain. Is this something essential for you? Why would you need a static chain from within a nested function that doesn't use any outer scope variables? Since it doesn't use any outer scope variables they cannot affect its execution, so debugging the value of those variables seems unnecessary. This is the default behavior of gcc for static chains. -- Tony From hendrik at topoi.pooq.com Mon Jan 14 18:19:50 2008 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Mon, 14 Jan 2008 12:19:50 -0500 Subject: [M3devel] Static chains In-Reply-To: References: Message-ID: <20080114171950.GB20313@topoi.pooq.com> On Mon, Jan 14, 2008 at 10:47:28AM -0500, Tony Hosking wrote: > Rodney, > > I just realised that the static chains variables are *not* always > being set up for nested function internal use. i.e., callers will > pass them, but nested functions that don't explicitly use them will > not have a static chain. Is this something essential for you? Why > would you need a static chain from within a nested function that > doesn't use any outer scope variables? Since it doesn't use any > outer scope variables they cannot affect its execution, so debugging > the value of those variables seems unnecessary. This is the default > behavior of gcc for static chains. And having them could break languages where it's possible to export procedures to places where their nonlocal procedures are still in existence but the intermediate lexical levels which they don't use are not. (Algol 68 is a case in point) -- hendrik > > -- Tony > From hosking at cs.purdue.edu Mon Jan 14 19:36:31 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 14 Jan 2008 13:36:31 -0500 Subject: [M3devel] Static chains In-Reply-To: <20080114171950.GB20313@topoi.pooq.com> References: <20080114171950.GB20313@topoi.pooq.com> Message-ID: <4C674DDA-00B2-4AFF-B78F-597C7ACC0E73@cs.purdue.edu> I believe Modula-3's downward-only (ie, only to callee's) exposure rules for procedure values will avoid this issue. On Jan 14, 2008, at 12:19 PM, hendrik at topoi.pooq.com wrote: > On Mon, Jan 14, 2008 at 10:47:28AM -0500, Tony Hosking wrote: >> Rodney, >> >> I just realised that the static chains variables are *not* always >> being set up for nested function internal use. i.e., callers will >> pass them, but nested functions that don't explicitly use them will >> not have a static chain. Is this something essential for you? Why >> would you need a static chain from within a nested function that >> doesn't use any outer scope variables? Since it doesn't use any >> outer scope variables they cannot affect its execution, so debugging >> the value of those variables seems unnecessary. This is the default >> behavior of gcc for static chains. > > And having them could break languages where it's possible to export > procedures to places where their nonlocal procedures are still in > existence but the intermediate lexical levels which they don't use are > not. (Algol 68 is a case in point) > > -- hendrik > >> >> -- Tony >> From darko at darko.org Mon Jan 14 21:35:45 2008 From: darko at darko.org (Darko) Date: Mon, 14 Jan 2008 12:35:45 -0800 Subject: [M3devel] GC question Message-ID: <9BB575E4-75B0-432D-BDEF-49F8F8644D80@darko.org> Tony, I imagine you're intimately familiar with the garbage collector implementation. If I wanted to implement a 'reallocate' function that preserved references to an object although the object was reallocated, ie change all existing references from the old object to the new object, would this be straight forward using the code of the current GC implementation? Is there any existing function that might do something like this already? Thanks, Darko. From mika at async.caltech.edu Mon Jan 14 21:53:18 2008 From: mika at async.caltech.edu (Mika Nystrom) Date: Mon, 14 Jan 2008 12:53:18 -0800 Subject: [M3devel] GC question In-Reply-To: Your message of "Mon, 14 Jan 2008 12:35:45 PST." <9BB575E4-75B0-432D-BDEF-49F8F8644D80@darko.org> Message-ID: <200801142053.m0EKrIMi087093@camembert.async.caltech.edu> It would have to be able to return an error, no? If there's an ambiguous root pointing to the object... Darko writes: >Tony, > >I imagine you're intimately familiar with the garbage collector >implementation. If I wanted to implement a 'reallocate' function that >preserved references to an object although the object was reallocated, >ie change all existing references from the old object to the new >object, would this be straight forward using the code of the current >GC implementation? Is there any existing function that might do >something like this already? > >Thanks, >Darko. From ndantam at purdue.edu Mon Jan 14 22:05:34 2008 From: ndantam at purdue.edu (Neil T. Dantam) Date: Mon, 14 Jan 2008 16:05:34 -0500 Subject: [M3devel] GC question In-Reply-To: <9BB575E4-75B0-432D-BDEF-49F8F8644D80@darko.org> References: <9BB575E4-75B0-432D-BDEF-49F8F8644D80@darko.org> Message-ID: <478BCE9E.70504@purdue.edu> Darko wrote: > If I wanted to implement a 'reallocate' function that preserved > references to an object although the object was reallocated, ie > change all existing references from the old object to the new > object, would this be straight forward using the code of the > current GC implementation? Probably not. Because precise pointer locations are not known for the stacks, they are treated conservatively, and any objects potentially referenced from the stacks are pinned in place by the GC. It would be impossible to update references to your reallocated object if those references live in the stack because we do not have precise information for stack pointer locations. -- Neil T. Dantam From ndantam at purdue.edu Mon Jan 14 22:09:30 2008 From: ndantam at purdue.edu (Neil T. Dantam) Date: Mon, 14 Jan 2008 16:09:30 -0500 Subject: [M3devel] GC question In-Reply-To: <200801142053.m0EKrIMi087093@camembert.async.caltech.edu> References: <200801142053.m0EKrIMi087093@camembert.async.caltech.edu> Message-ID: <478BCF8A.7090409@purdue.edu> Mika Nystrom wrote: > It would have to be able to return an error, no? If there's > an ambiguous root pointing to the object... If you have a reference to the object that you are reallocating which you must pass to this procedure, then you have a reference on the stack creating an ambiguous root. Also, the GC doesn't just pin objects, it pins entire pages because there may be a derived pointer referring to some object in that page. So if your object to reallocate is on the same page as anything referenced from the stack, you couldn't automatically update pointers. Now if you only want to update pointers in heap, maybe there's a way to make that work. -- Neil T. Dantam From hosking at cs.purdue.edu Mon Jan 14 22:17:11 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 14 Jan 2008 16:17:11 -0500 Subject: [M3devel] GC question In-Reply-To: <200801142053.m0EKrIMi087093@camembert.async.caltech.edu> References: <200801142053.m0EKrIMi087093@camembert.async.caltech.edu> Message-ID: <425DF106-9200-4E49-86FE-DCF377FEC631@cs.purdue.edu> I'm not sure what your purpose here might be. You shouldn't assume anything about an object's precise location since the collector is free to move it around. What are you trying to do? If you are trying to *replace* one object with another and have all references to the old object refer to the new object, then, yes, you really need to get intimately involved with the GC, since it will need to go through the whole heap and redirect those references. It is doable, but messy, and probably requires that all threads in the system be stopped while you pull off the switch. To do it without stopping all the threads requires that you do something much smarter (see papers on replicating GC...). On Jan 14, 2008, at 3:53 PM, Mika Nystrom wrote: > It would have to be able to return an error, no? If there's > an ambiguous root pointing to the object... > > > Darko writes: >> Tony, >> >> I imagine you're intimately familiar with the garbage collector >> implementation. If I wanted to implement a 'reallocate' function that >> preserved references to an object although the object was >> reallocated, >> ie change all existing references from the old object to the new >> object, would this be straight forward using the code of the current >> GC implementation? Is there any existing function that might do >> something like this already? >> >> Thanks, >> Darko. From hosking at cs.purdue.edu Mon Jan 14 22:17:46 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 14 Jan 2008 16:17:46 -0500 Subject: [M3devel] GC question In-Reply-To: <200801142053.m0EKrIMi087093@camembert.async.caltech.edu> References: <200801142053.m0EKrIMi087093@camembert.async.caltech.edu> Message-ID: PS Yes, if there is an ambiguous root pointing at the object then you are stuck. On Jan 14, 2008, at 3:53 PM, Mika Nystrom wrote: > It would have to be able to return an error, no? If there's > an ambiguous root pointing to the object... > > > Darko writes: >> Tony, >> >> I imagine you're intimately familiar with the garbage collector >> implementation. If I wanted to implement a 'reallocate' function that >> preserved references to an object although the object was >> reallocated, >> ie change all existing references from the old object to the new >> object, would this be straight forward using the code of the current >> GC implementation? Is there any existing function that might do >> something like this already? >> >> Thanks, >> Darko. From darko at darko.org Mon Jan 14 22:28:18 2008 From: darko at darko.org (Darko) Date: Mon, 14 Jan 2008 13:28:18 -0800 Subject: [M3devel] GC question In-Reply-To: <425DF106-9200-4E49-86FE-DCF377FEC631@cs.purdue.edu> References: <200801142053.m0EKrIMi087093@camembert.async.caltech.edu> <425DF106-9200-4E49-86FE-DCF377FEC631@cs.purdue.edu> Message-ID: <1AD34A8D-A9A6-464A-B8A1-792B74355528@darko.org> Yep, I want to replace one object with another. One application is to expand open arrays without searching large data structures for references to replace. Maybe a simpler question is can you increase the size of an allocated object without getting messy? On 14/01/2008, at 1:17 PM, Tony Hosking wrote: > I'm not sure what your purpose here might be. You shouldn't assume > anything about an object's precise location since the collector is > free to move it around. What are you trying to do? If you are > trying to *replace* one object with another and have all references > to the old object refer to the new object, then, yes, you really > need to get intimately involved with the GC, since it will need to > go through the whole heap and redirect those references. It is > doable, but messy, and probably requires that all threads in the > system be stopped while you pull off the switch. To do it without > stopping all the threads requires that you do something much smarter > (see papers on replicating GC...). > > On Jan 14, 2008, at 3:53 PM, Mika Nystrom wrote: > >> It would have to be able to return an error, no? If there's >> an ambiguous root pointing to the object... >> >> >> Darko writes: >>> Tony, >>> >>> I imagine you're intimately familiar with the garbage collector >>> implementation. If I wanted to implement a 'reallocate' function >>> that >>> preserved references to an object although the object was >>> reallocated, >>> ie change all existing references from the old object to the new >>> object, would this be straight forward using the code of the current >>> GC implementation? Is there any existing function that might do >>> something like this already? >>> >>> Thanks, >>> Darko. > From rodney.bates at wichita.edu Tue Jan 15 00:24:35 2008 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Mon, 14 Jan 2008 17:24:35 -0600 Subject: [M3devel] Static chains In-Reply-To: References: Message-ID: <478BEF33.2050203@wichita.edu> Think of the debugger as an interpreter for a substantial subset of the language. When the program is stopped at some point, m3gdb can, in effect, inject code to evaluate an arbitrary expression, typed by the debugger user, or execute an arbitrary assignment or call statement. Although there are a number of gaps yet in the implementation, m3gdb is approaching fitting this description. The user-typed code can both create and use static link values that do not occur in the original code that the compiler saws. The simplest example is, when stopped in a nested procedure, the user types 'print NonLocalVariable'. This works fine right now, unless the compiler has not stored the SL in the current proc's activation record, which a compiler might well do if the nested proc, as coded, has no references to any nonlocal variables. (Or keeps the SL only in a register, etc.) You could say this is only a convenience, as the user could work around it by just typing 'up' the exact number of times to get to the static parent's frame (which is, of course, also a dynamic ancestor). But that can slow down debugging a great deal, and I often find it a very important convenience. Anyway, you could say that to a degree about much of what a debugger does. A more complex example might be 'print Nested1(Nested2,NonlocalVar)', where Nested1 and Nested2 are nested procedures. Here, the debugger has create and pass the appropriate SL value in order to call Nested1, which, unless Nested1 is one scope deeper than the current stop point, also entails m3gdb's fetching the SL that was given to some procedure on the current dynamic call chain. The same things are required of m3gdb to construct the closure for Nested2, which it must pass to Nested1. And if NonlocalVar is in an outer scope where Nested1 and/or Nested2 aren't visible, there would be no workaround possible at all. Tony, I haven't been able to try out your latest change anyway, as I seem to have once again regressed to not being able to get CM3 to link to a working version of libpthread on Mandriva. Also, I am about to travel for a week, so may be out of this discussion for a while. Tony Hosking wrote: > Rodney, > > I just realised that the static chains variables are *not* always being > set up for nested function internal use. i.e., callers will pass them, > but nested functions that don't explicitly use them will not have a > static chain. Is this something essential for you? Why would you need > a static chain from within a nested function that doesn't use any outer > scope variables? Since it doesn't use any outer scope variables they > cannot affect its execution, so debugging the value of those variables > seems unnecessary. This is the default behavior of gcc for static chains. > > -- Tony > > -- ------------------------------------------------------------- Rodney 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 Jan 15 00:09:08 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 14 Jan 2008 18:09:08 -0500 Subject: [M3devel] GC question In-Reply-To: <1AD34A8D-A9A6-464A-B8A1-792B74355528@darko.org> References: <200801142053.m0EKrIMi087093@camembert.async.caltech.edu> <425DF106-9200-4E49-86FE-DCF377FEC631@cs.purdue.edu> <1AD34A8D-A9A6-464A-B8A1-792B74355528@darko.org> Message-ID: <5D72E480-17E4-4394-B617-83A7A8AF2F66@cs.purdue.edu> On Jan 14, 2008, at 4:28 PM, Darko wrote: > Yep, I want to replace one object with another. One application is > to expand open arrays without searching large data structures for > references to replace. Maybe a simpler question is can you increase > the size of an allocated object without getting messy? Not easily. Old-time Smalltalk systems had an "Object become:" method that you could use to reallocate in this way, but a level of indirection was used to avoid having to scan the heap. How about using an explicit level of indirection of your own? The WeakRef interface may be useful to you here too, so that you can discard indirection state when there are no other references to the object. > > > On 14/01/2008, at 1:17 PM, Tony Hosking wrote: > >> I'm not sure what your purpose here might be. You shouldn't >> assume anything about an object's precise location since the >> collector is free to move it around. What are you trying to do? >> If you are trying to *replace* one object with another and have >> all references to the old object refer to the new object, then, >> yes, you really need to get intimately involved with the GC, since >> it will need to go through the whole heap and redirect those >> references. It is doable, but messy, and probably requires that >> all threads in the system be stopped while you pull off the >> switch. To do it without stopping all the threads requires that >> you do something much smarter (see papers on replicating GC...). >> >> On Jan 14, 2008, at 3:53 PM, Mika Nystrom wrote: >> >>> It would have to be able to return an error, no? If there's >>> an ambiguous root pointing to the object... >>> >>> >>> Darko writes: >>>> Tony, >>>> >>>> I imagine you're intimately familiar with the garbage collector >>>> implementation. If I wanted to implement a 'reallocate' function >>>> that >>>> preserved references to an object although the object was >>>> reallocated, >>>> ie change all existing references from the old object to the new >>>> object, would this be straight forward using the code of the >>>> current >>>> GC implementation? Is there any existing function that might do >>>> something like this already? >>>> >>>> Thanks, >>>> Darko. >> From hendrik at topoi.pooq.com Tue Jan 15 00:30:47 2008 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Mon, 14 Jan 2008 18:30:47 -0500 Subject: [M3devel] Static chains In-Reply-To: <4C674DDA-00B2-4AFF-B78F-597C7ACC0E73@cs.purdue.edu> References: <20080114171950.GB20313@topoi.pooq.com> <4C674DDA-00B2-4AFF-B78F-597C7ACC0E73@cs.purdue.edu> Message-ID: <20080114233047.GC20313@topoi.pooq.com> On Mon, Jan 14, 2008 at 01:36:31PM -0500, Tony Hosking wrote: > I believe Modula-3's downward-only (ie, only to callee's) exposure > rules for procedure values will avoid this issue. Yes, that's true. But you mentioned static links i the context o gcc: > >>the value of those variables seems unnecessary. This is the default > >>behavior of gcc for static chains. so perhaps there was still some relevance. -- hendrik From darko at darko.org Tue Jan 15 01:39:23 2008 From: darko at darko.org (Darko) Date: Mon, 14 Jan 2008 16:39:23 -0800 Subject: [M3devel] GC question In-Reply-To: <5D72E480-17E4-4394-B617-83A7A8AF2F66@cs.purdue.edu> References: <200801142053.m0EKrIMi087093@camembert.async.caltech.edu> <425DF106-9200-4E49-86FE-DCF377FEC631@cs.purdue.edu> <1AD34A8D-A9A6-464A-B8A1-792B74355528@darko.org> <5D72E480-17E4-4394-B617-83A7A8AF2F66@cs.purdue.edu> Message-ID: <44DE2F53-50D6-4A32-AD7E-F8716E425D7B@darko.org> Yes, I was considering that and other options, I was just hoping to move the complexity to the compiler, where I thought it might already be implemented. I have to try keep my code very clean and simple. On 14/01/2008, at 3:09 PM, Tony Hosking wrote: > > On Jan 14, 2008, at 4:28 PM, Darko wrote: > >> Yep, I want to replace one object with another. One application is >> to expand open arrays without searching large data structures for >> references to replace. Maybe a simpler question is can you increase >> the size of an allocated object without getting messy? > > Not easily. > > Old-time Smalltalk systems had an "Object become:" method that you > could use to reallocate in this way, but a level of indirection was > used to avoid having to scan the heap. How about using an explicit > level of indirection of your own? The WeakRef interface may be > useful to you here too, so that you can discard indirection state > when there are no other references to the object. > >> >> >> On 14/01/2008, at 1:17 PM, Tony Hosking wrote: >> >>> I'm not sure what your purpose here might be. You shouldn't >>> assume anything about an object's precise location since the >>> collector is free to move it around. What are you trying to do? >>> If you are trying to *replace* one object with another and have >>> all references to the old object refer to the new object, then, >>> yes, you really need to get intimately involved with the GC, since >>> it will need to go through the whole heap and redirect those >>> references. It is doable, but messy, and probably requires that >>> all threads in the system be stopped while you pull off the >>> switch. To do it without stopping all the threads requires that >>> you do something much smarter (see papers on replicating GC...). >>> >>> On Jan 14, 2008, at 3:53 PM, Mika Nystrom wrote: >>> >>>> It would have to be able to return an error, no? If there's >>>> an ambiguous root pointing to the object... >>>> >>>> >>>> Darko writes: >>>>> Tony, >>>>> >>>>> I imagine you're intimately familiar with the garbage collector >>>>> implementation. If I wanted to implement a 'reallocate' function >>>>> that >>>>> preserved references to an object although the object was >>>>> reallocated, >>>>> ie change all existing references from the old object to the new >>>>> object, would this be straight forward using the code of the >>>>> current >>>>> GC implementation? Is there any existing function that might do >>>>> something like this already? >>>>> >>>>> Thanks, >>>>> Darko. >>> > From rodney.bates at wichita.edu Tue Jan 15 02:56:05 2008 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Mon, 14 Jan 2008 19:56:05 -0600 Subject: [M3devel] Static chains In-Reply-To: <20080114171950.GB20313@topoi.pooq.com> References: <20080114171950.GB20313@topoi.pooq.com> Message-ID: <478C12B5.4050908@wichita.edu> Modula-3 prevents the dangling environment problem with a rule that, while a nested procedure can indeed be passed as a parameter, it can not be assigned to a variable. Only a top-level procedure value can be assigned to a variable. In general, this has to be checked at runtime, at the time of an assignment. The compilers all do this by making the RT representation of a procedure value explicitly denote whether it is nested or top-level. hendrik at topoi.pooq.com wrote: > On Mon, Jan 14, 2008 at 10:47:28AM -0500, Tony Hosking wrote: > >>Rodney, >> >>I just realised that the static chains variables are *not* always >>being set up for nested function internal use. i.e., callers will >>pass them, but nested functions that don't explicitly use them will >>not have a static chain. Is this something essential for you? Why >>would you need a static chain from within a nested function that >>doesn't use any outer scope variables? Since it doesn't use any >>outer scope variables they cannot affect its execution, so debugging >>the value of those variables seems unnecessary. This is the default >>behavior of gcc for static chains. > > > And having them could break languages where it's possible to export > procedures to places where their nonlocal procedures are still in > existence but the intermediate lexical levels which they don't use are > not. (Algol 68 is a case in point) > > -- hendrik > > >>-- Tony >> > > -- ------------------------------------------------------------- Rodney 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 Jan 15 03:13:39 2008 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Mon, 14 Jan 2008 20:13:39 -0600 Subject: [M3devel] Static chains In-Reply-To: <478BEF33.2050203@wichita.edu> References: <478BEF33.2050203@wichita.edu> Message-ID: <478C16D3.6040405@wichita.edu> See embedded corrections I (Rodney M. Bates) wrote: > Think of the debugger as an interpreter for a substantial subset of the > language. When the program is stopped at some point, m3gdb can, in effect, > inject code to evaluate an arbitrary expression, typed by the debugger > user, or execute an arbitrary assignment or call statement. Although > there are a number of gaps yet in the implementation, m3gdb is approaching > fitting this description. > > The user-typed code can both create and use static link values that do > not occur in the original code that the compiler saws. The simplest ^saw > example is, when stopped in a nested procedure, the user types > 'print NonLocalVariable'. This works fine right now, unless the compiler > has not stored the SL in the current proc's activation record, which a > compiler might well do if the nested proc, as coded, has no references > to any nonlocal variables. (Or keeps the SL only in a register, etc.) > > You could say this is only a convenience, as the user could work around > it by just typing 'up' the exact number of times to get to the static > parent's frame (which is, of course, also a dynamic ancestor). But that > can slow down debugging a great deal, and I often find it a very important > convenience. Anyway, you could say that to a degree about much of what a > debugger does. > > A more complex example might be 'print Nested1(Nested2,NonlocalVar)', > where Nested1 and Nested2 are nested procedures. Here, the debugger > has create and pass the appropriate SL value in order to call Nested1, > which, unless Nested1 is one scope deeper than the current stop point, > also entails m3gdb's fetching the SL that was given to some procedure > on the current dynamic call chain. The same things are required of ^static chain. Although it is true that the proc is also on the dynamic chain, that is not what I meant and is confusing at best. > m3gdb to construct the closure for Nested2, which it must pass to Nested1. > And if NonlocalVar is in an outer scope where Nested1 and/or Nested2 > aren't visible, there would be no workaround possible at all. > > Tony, I haven't been able to try out your latest change anyway, as > I seem to have once again regressed to not being able to get CM3 to > link to a working version of libpthread on Mandriva. Also, I am about > to travel for a week, so may be out of this discussion for a while. > > > Tony Hosking wrote: > >> Rodney, >> >> I just realised that the static chains variables are *not* always >> being set up for nested function internal use. i.e., callers will >> pass them, but nested functions that don't explicitly use them will >> not have a static chain. Is this something essential for you? Why >> would you need a static chain from within a nested function that >> doesn't use any outer scope variables? Since it doesn't use any >> outer scope variables they cannot affect its execution, so debugging >> the value of those variables seems unnecessary. This is the default >> behavior of gcc for static chains. >> >> -- Tony >> >> > -- ------------------------------------------------------------- Rodney 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 Jan 15 06:54:05 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 15 Jan 2008 05:54:05 +0000 Subject: [M3devel] Static chains In-Reply-To: <478BEF33.2050203@wichita.edu> References: <478BEF33.2050203@wichita.edu> Message-ID: I really don't think an optimizing compiler should be passing around unused static links just for the debugger to use. The debugger should look up the stack itself. Optimizing compilers remove locals, remove parameters, remove functions, create custom calling conventions, etc. An non-optimizing compiler, sure, I guess. Though it seems some level of optimization should be always on. It pains me to think that every little function call I write might be made, and not inlined. Microsoft compilers now do inlining across static lib boundaries. Or that constant arithmetic like:#define A 1 #define B 2 int c = (A + B) might be computed at runtime. Or that while(1) .. .. if ... break; might generate a runtime check if 1 is not zero (along with the code bloat). Microsoft has "__forceinline", and it is a warning or error if the compiler is unable to inline such a function. - Jay> Date: Mon, 14 Jan 2008 17:24:35 -0600> From: rodney.bates at wichita.edu> To: hosking at cs.purdue.edu> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] Static chains> > Think of the debugger as an interpreter for a substantial subset of the> language. When the program is stopped at some point, m3gdb can, in effect,> inject code to evaluate an arbitrary expression, typed by the debugger> user, or execute an arbitrary assignment or call statement. Although> there are a number of gaps yet in the implementation, m3gdb is approaching> fitting this description.> > The user-typed code can both create and use static link values that do> not occur in the original code that the compiler saws. The simplest> example is, when stopped in a nested procedure, the user types> 'print NonLocalVariable'. This works fine right now, unless the compiler> has not stored the SL in the current proc's activation record, which a> compiler might well do if the nested proc, as coded, has no references> to any nonlocal variables. (Or keeps the SL only in a register, etc.)> > You could say this is only a convenience, as the user could work around> it by just typing 'up' the exact number of times to get to the static> parent's frame (which is, of course, also a dynamic ancestor). But that> can slow down debugging a great deal, and I often find it a very important> convenience. Anyway, you could say that to a degree about much of what a> debugger does.> > A more complex example might be 'print Nested1(Nested2,NonlocalVar)',> where Nested1 and Nested2 are nested procedures. Here, the debugger> has create and pass the appropriate SL value in order to call Nested1,> which, unless Nested1 is one scope deeper than the current stop point,> also entails m3gdb's fetching the SL that was given to some procedure> on the current dynamic call chain. The same things are required of> m3gdb to construct the closure for Nested2, which it must pass to Nested1.> And if NonlocalVar is in an outer scope where Nested1 and/or Nested2> aren't visible, there would be no workaround possible at all.> > Tony, I haven't been able to try out your latest change anyway, as> I seem to have once again regressed to not being able to get CM3 to> link to a working version of libpthread on Mandriva. Also, I am about> to travel for a week, so may be out of this discussion for a while.> > > Tony Hosking wrote:> > Rodney,> > > > I just realised that the static chains variables are *not* always being > > set up for nested function internal use. i.e., callers will pass them, > > but nested functions that don't explicitly use them will not have a > > static chain. Is this something essential for you? Why would you need > > a static chain from within a nested function that doesn't use any outer > > scope variables? Since it doesn't use any outer scope variables they > > cannot affect its execution, so debugging the value of those variables > > seems unnecessary. This is the default behavior of gcc for static chains.> > > > -- Tony> > > > > > -- > -------------------------------------------------------------> Rodney M. Bates, retired assistant professor> Dept. of Computer Science, Wichita State University> Wichita, KS 67260-0083> 316-978-3922> rodney.bates at wichita.edu _________________________________________________________________ Put your friends on the big screen with Windows Vista? + Windows Live?. http://www.microsoft.com/windows/shop/specialoffers.mspx?ocid=TXT_TAGLM_CPC_MediaCtr_bigscreen_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Tue Jan 15 07:00:48 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 15 Jan 2008 06:00:48 +0000 Subject: [M3devel] Static chains In-Reply-To: <478BEF33.2050203@wichita.edu> References: <478BEF33.2050203@wichita.edu> Message-ID: ps: I "like" nested functions, and even the ability for them to capture their outer context, like in Scheme: (define make-adder (lambda x) (lambda y) (x + y)) (define add5 (make-adder 5)) (add 5 4) => 9 but I've lived without this long enough. Capturing just the right amount of context manually is also easy. Otherwise the compiler/runtime either has to a) heap allocate and garbage collect all stack frames b) do the analysis to decide what to heap allocate. I believe Java and C# do b. They don't necessarily have nested "functions", but nested classes with functions, same thing. Java might make you declare captured state as "final" (aka const aka readonly). That said, heap allocated stack frames are a powerful measure in preventing stack exhaustion, which is an otherwise seemingly difficult and ignored problem. The stack is not infinite yet most programmers rarely think about its size. - Jay From: jayk123 at hotmail.comTo: rodney.bates at wichita.edu; hosking at cs.purdue.eduCC: m3devel at elegosoft.comSubject: RE: [M3devel] Static chainsDate: Tue, 15 Jan 2008 05:54:05 +0000 I really don't think an optimizing compiler should be passing around unused static links just for the debugger to use. The debugger should look up the stack itself. Optimizing compilers remove locals, remove parameters, remove functions, create custom calling conventions, etc. An non-optimizing compiler, sure, I guess. Though it seems some level of optimization should be always on.It pains me to think that every little function call I write might be made, and not inlined.Microsoft compilers now do inlining across static lib boundaries.Or that constant arithmetic like:#define A 1#define B 2int c = (A + B) might be computed at runtime. Or that while(1) .. .. if ... break; might generate a runtime check if 1 is not zero (along with the code bloat). Microsoft has "__forceinline", and it is a warning or error if the compiler is unable to inline such a function. - Jay> Date: Mon, 14 Jan 2008 17:24:35 -0600> From: rodney.bates at wichita.edu> To: hosking at cs.purdue.edu> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] Static chains> > Think of the debugger as an interpreter for a substantial subset of the> language. When the program is stopped at some point, m3gdb can, in effect,> inject code to evaluate an arbitrary expression, typed by the debugger> user, or execute an arbitrary assignment or call statement. Although> there are a number of gaps yet in the implementation, m3gdb is approaching> fitting this description.> > The user-typed code can both create and use static link values that do> not occur in the original code that the compiler saws. The simplest> example is, when stopped in a nested procedure, the user types> 'print NonLocalVariable'. This works fine right now, unless the compiler> has not stored the SL in the current proc's activation record, which a> compiler might well do if the nested proc, as coded, has no references> to any nonlocal variables. (Or keeps the SL only in a register, etc.)> > You could say this is only a convenience, as the user could work around> it by just typing 'up' the exact number of times to get to the static> parent's frame (which is, of course, also a dynamic ancestor). But that> can slow down debugging a great deal, and I often find it a very important> convenience. Anyway, you could say that to a degree about much of what a> debugger does.> > A more complex example might be 'print Nested1(Nested2,NonlocalVar)',> where Nested1 and Nested2 are nested procedures. Here, the debugger> has create and pass the appropriate SL value in order to call Nested1,> which, unless Nested1 is one scope deeper than the current stop point,> also entails m3gdb's fetching the SL that was given to some procedure> on the current dynamic call chain. The same things are required of> m3gdb to construct the closure for Nested2, which it must pass to Nested1.> And if NonlocalVar is in an outer scope where Nested1 and/or Nested2> aren't visible, there would be no workaround possible at all.> > Tony, I haven't been able to try out your latest change anyway, as> I seem to have once again regressed to not being able to get CM3 to> link to a working version of libpthread on Mandriva. Also, I am about> to travel for a week, so may be out of this discussion for a while.> > > Tony Hosking wrote:> > Rodney,> > > > I just realised that the static chains variables are *not* always being > > set up for nested function internal use. i.e., callers will pass them, > > but nested functions that don't explicitly use them will not have a > > static chain. Is this something essential for you? Why would you need > > a static chain from within a nested function that doesn't use any outer > > scope variables? Since it doesn't use any outer scope variables they > > cannot affect its execution, so debugging the value of those variables > > seems unnecessary. This is the default behavior of gcc for static chains.> > > > -- Tony> > > > > > -- > -------------------------------------------------------------> Rodney M. Bates, retired assistant professor> Dept. of Computer Science, Wichita State University> Wichita, KS 67260-0083> 316-978-3922> rodney.bates at wichita.edu Put your friends on the big screen with Windows Vista? + Windows Live?. Start now! _________________________________________________________________ Share life as it happens with the new Windows Live. http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Tue Jan 15 08:00:13 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 15 Jan 2008 07:00:13 +0000 Subject: [M3devel] "crazy cross" In-Reply-To: <20080105011335.n767h3zbz4gcgk4k@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> Message-ID: It looks like at least cm3 is "always" target-independent. Whatever target is defined to in cm3.cfg, if it is one of the built in known ones, cm3 will generate code for. Except maybe NT386, though it need not be -- cm3 could have both the .obj and "gcc tree" writing backends both linked into it and dynamically chose between them. Maybe it already does. cm3 operates at a fairly high level when using gcc, and the target specific stuff is just some data about the name of setjmp, the sizeof jmp_buf, etc..The "only" "problem" is then m3cg/as/ld/link.m3cg could be moved to $CM3_INSTALL/pkg/x/HOST/TARGET. cm3, along with everything else, could be $CM3_INSTALL/pkg/x/HOST leaving $CM3_INSTALL/bin/cm3 that is sh and $CM3_INSTALL/bin/cm3.py or cm3.cmd that calls out to cm3. "Fixing" as/ld, well, I don't suppose they tend to be target neutral do they? You'd have to import them like gcc and build them n times. Gaining a much slower build, much larger tree. I suppose anyone could do this themselves, and change cm3.cfg appropriately. Doing things "officially" this way for one "big" distribution, probably folks would not go for. - Jay From: jayk123 at hotmail.comTo: m3devel at elegosoft.comSubject: "crazy cross"Date: Sat, 5 Jan 2008 01:22:13 +0000 You've all heard of "Canadian cross"?It is cross-building a cross-compiler.I'm sitting in Windows. I'm going to build a compiler that is going to run on Linux that is going to target Solaris.For one example.You've all seen that Apple has switches like so:gcc -arch i386 ppc ppc64 x86_64 hello.cand poof out comes a binary that runs natively on four architecturesI don't like the "inconvenience" of non cross systems and having to have all the machines/OSes just to build the binaries.I realize that you hit the wall if you actually want to test the results. So cross building only gets so much.Of course I also don't want to multiply out build times for tools...Ok, well what is the possibility of:cm3 -target NT386cm3 -target NT386 -target PPC_DARWIN? In my crazy imagination, you have: \cm3\bin\cm3.cmd %~dp0..\libexec\%processor_architecture%\%TARGET%\cm3.exe %* \cm3\bin\cm3 #!/bin/sh dirname(dirname($0))/libexec/`uname whatever`/$TARGET/cm3 $@Thus it becomes POSSIBLE to have an n x m matrix, host x target, and be able to build"anything" from one environment.Actually the targets could all be merged into one .exe or be .dll/.sos.Except the code isn't setup for that.Interesting?I guess the hard part is the C code and linking?The Modula-3 stuff is already setup to do most of this? (partly by virtue of all that header rewriting that I labeled sleazy) - Jay Share life as it happens with the new Windows Live. Start sharing! _________________________________________________________________ Share life as it happens with the new Windows Live. http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Tue Jan 15 14:34:25 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 15 Jan 2008 13:34:25 +0000 Subject: [M3devel] NT386GNU status Message-ID: I can build a lot of std, at least up to m3ui. However..nothing works. Everything crashes. In order to build std, I copied back the NT386 cm3 and mklib, though the config sets TARGET=NT386GNU and runs cm3cg. (i.e. I'm not just using the NT386 backend!) The crash is what I mentioned the other day: D:\>\cygwin\bin\gdb \dev2\cm3.2\m3-sys\cm3\NT386GNU\cm3.exeGNU gdb 6.5.50.20060706-cvs (cygwin-special)Copyright (C) 2006 Free Software Foundation, Inc.GDB is free software, covered by the GNU General Public License, and you arewelcome to change it and/or distribute copies of it under certain conditions.Type "show copying" to see the conditions.There is absolutely no warranty for GDB. Type "show warranty" for details.This GDB was configured as "i686-pc-cygwin"...(gdb) runStarting program: D:/dev2/cm3.2/m3-sys/cm3/NT386GNU/cm3.exeLoaded symbols for /cygdrive/d/WINDOWS/system32/ntdll.dllLoaded symbols for /cygdrive/d/WINDOWS/system32/kernel32.dllLoaded symbols for /cygdrive/d/WINDOWS/system32/advapi32.dllLoaded symbols for /cygdrive/d/WINDOWS/system32/rpcrt4.dllLoaded symbols for /cygdrive/d/WINDOWS/system32/gdi32.dllLoaded symbols for /cygdrive/d/WINDOWS/system32/user32.dllLoaded symbols for /cygdrive/d/WINDOWS/system32/msvcrt.dllLoaded symbols for /cygdrive/d/WINDOWS/system32/wsock32.dllLoaded symbols for /cygdrive/d/WINDOWS/system32/ws2_32.dllLoaded symbols for /cygdrive/d/WINDOWS/system32/ws2help.dll Program received signal SIGSEGV, Segmentation fault.0x00000000 in ?? ()(gdb) bt#0 0x00000000 in ?? ()#1 0x005de831 in RTLinker__FindModules (M3_DjPxE3_m=0x682340) at RTLinker.m3:182#2 0x005de5fb in RTLinker__AddUnitI (M3_DjPxE3_m=0x682340) at RTLinker.m3:111#3 0x005de6b0 in RTLinker__AddUnit (M3_DjPxE5_b=0x603fd0) at RTLinker.m3:122#4 0x005de34d in RTLinker__InitRuntime (M3_AcxOUs_p_argc=0, M3_AJWxb1_p_argv=0x3f2bf0, M3_AJWxb1_p_envp=0x3f24c0, M3_AJWxb1_p_instance=0x1) at RTLinker.m3:42#5 0x00401315 in main (argc=1, argv=0x3f24c0, envp=0x3f2bf0) at _m3main.mc:3(gdb) qThe program is running. Exit anyway? (y or n) y D:\> Oh, m3ui and related are broken due to: D:\dev2\cm3.2\m3-tools\m3bundle\NT386GNU\m3bundle -name formseditBundle -FD:\DOCUME~1\Jay\LOCALS~1\Temp\qknew source -> compiling FormsEditVBT.i3new source -> compiling formseditBundle.i3new source -> compiling FormsEditVBT.m3new source -> compiling FormsEdit.m3new source -> compiling formseditBundle.m3 -> linking formsedit.exeD:\dev2\cm3.2/m3-ui\ui\NT386GNU\m3ui.lib.sa(WinTrestle.mo): In function `WinTrestle__ButtonEvent':WinTrestle.m3:1843: undefined reference to `WindowFromPoint at 4'collect2: ld returned 1 exit status"D:\\dev2\\cm3.2\m3-sys\cminstall\src\config\NT386GNU", line 583: quake runtimeerror: link failed, see D:\dev2\cm3.2\m3-ui\formsedit\NT386GNU\formsedit.lst for more information \mingw\bin\nm \MinGW\lib\libuser32.a | findstr WindowFromPoint00000000 T _WindowFromPoint at 800000000 I __imp__WindowFromPoint at 8 Maybe Tony will fix my __stdcall work. :)Or maybe the problem is the declaration.Or maybe I can confirm it is passing a small struct by pointer instead of by referenceand just write a little translation thunk. But also see why NT386 works.Not a big deal. Trestle can wait. If anyone wants to try this stuff out, debug, I can either share diffs or commit them.They are actually pretty small.I just have to look into the definitions of the runtime linker/binder stuff and/orthe assembly, see if there's some disconnect somewhere. Other gdb above, this is all with mingwin + msys. They are enough to build cm3cg. mingwin should suffice for the rest. The ld that comes with the mingwin that free Qt gives you is too old, from around 2004. It doesn't support "response files", which are needed for building some packages due to command line length. The change was made circa 2005. Current "released" Mingwin works (I didn't use "technology preview") Probably I'll take a break for now. - Jay _________________________________________________________________ Share life as it happens with the new Windows Live. http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Tue Jan 15 14:41:49 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 15 Jan 2008 08:41:49 -0500 Subject: [M3devel] Static chains In-Reply-To: References: <478BEF33.2050203@wichita.edu> Message-ID: <8E6886FC-DAD4-452A-9771-F40640045A74@cs.purdue.edu> Yes, I am leery myself of much the same. Gcc is very careful about when a nested procedure is allocated a static link. On Jan 15, 2008, at 12:54 AM, Jay wrote: > I really don't think an optimizing compiler should be passing > around unused static links just for the debugger to use. The > debugger should look up the stack itself. > > Optimizing compilers remove locals, remove parameters, remove > functions, create custom calling conventions, etc. > > An non-optimizing compiler, sure, I guess. > > Though it seems some level of optimization should be always on. > It pains me to think that every little function call I write might > be made, and not inlined. > Microsoft compilers now do inlining across static lib boundaries. > Or that constant arithmetic like: > #define A 1 > #define B 2 > int c = (A + B) > > might be computed at runtime. > > Or that > while(1) > .. > .. if ... break; > > might generate a runtime check if 1 is not zero (along with the > code bloat). > > Microsoft has "__forceinline", and it is a warning or error if the > compiler is unable to inline such a function. > > - Jay > > > > Date: Mon, 14 Jan 2008 17:24:35 -0600 > > From: rodney.bates at wichita.edu > > To: hosking at cs.purdue.edu > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] Static chains > > > > Think of the debugger as an interpreter for a substantial subset > of the > > language. When the program is stopped at some point, m3gdb can, > in effect, > > inject code to evaluate an arbitrary expression, typed by the > debugger > > user, or execute an arbitrary assignment or call statement. Although > > there are a number of gaps yet in the implementation, m3gdb is > approaching > > fitting this description. > > > > The user-typed code can both create and use static link values > that do > > not occur in the original code that the compiler saws. The simplest > > example is, when stopped in a nested procedure, the user types > > 'print NonLocalVariable'. This works fine right now, unless the > compiler > > has not stored the SL in the current proc's activation record, > which a > > compiler might well do if the nested proc, as coded, has no > references > > to any nonlocal variables. (Or keeps the SL only in a register, > etc.) > > > > You could say this is only a convenience, as the user could work > around > > it by just typing 'up' the exact number of times to get to the > static > > parent's frame (which is, of course, also a dynamic ancestor). > But that > > can slow down debugging a great deal, and I often find it a very > important > > convenience. Anyway, you could say that to a degree about much of > what a > > debugger does. > > > > A more complex example might be 'print Nested1 > (Nested2,NonlocalVar)', > > where Nested1 and Nested2 are nested procedures. Here, the debugger > > has create and pass the appropriate SL value in order to call > Nested1, > > which, unless Nested1 is one scope deeper than the current stop > point, > > also entails m3gdb's fetching the SL that was given to some > procedure > > on the current dynamic call chain. The same things are required of > > m3gdb to construct the closure for Nested2, which it must pass to > Nested1. > > And if NonlocalVar is in an outer scope where Nested1 and/or Nested2 > > aren't visible, there would be no workaround possible at all. > > > > Tony, I haven't been able to try out your latest change anyway, as > > I seem to have once again regressed to not being able to get CM3 to > > link to a working version of libpthread on Mandriva. Also, I am > about > > to travel for a week, so may be out of this discussion for a while. > > > > > > Tony Hosking wrote: > > > Rodney, > > > > > > I just realised that the static chains variables are *not* > always being > > > set up for nested function internal use. i.e., callers will > pass them, > > > but nested functions that don't explicitly use them will not > have a > > > static chain. Is this something essential for you? Why would > you need > > > a static chain from within a nested function that doesn't use > any outer > > > scope variables? Since it doesn't use any outer scope variables > they > > > cannot affect its execution, so debugging the value of those > variables > > > seems unnecessary. This is the default behavior of gcc for > static chains. > > > > > > -- Tony > > > > > > > > > > -- > > ------------------------------------------------------------- > > Rodney M. Bates, retired assistant professor > > Dept. of Computer Science, Wichita State University > > Wichita, KS 67260-0083 > > 316-978-3922 > > rodney.bates at wichita.edu > > > Put your friends on the big screen with Windows Vista? + Windows > Live?. Start now! From hosking at cs.purdue.edu Tue Jan 15 14:47:13 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 15 Jan 2008 08:47:13 -0500 Subject: [M3devel] "crazy cross" 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> Message-ID: On Jan 15, 2008, at 2:00 AM, Jay wrote: > It looks like at least cm3 is "always" target-independent. > Whatever target is defined to in cm3.cfg, if it is one of the built > in known ones, cm3 will generate code for. Except maybe NT386, > though it need not be -- cm3 could have both the .obj and "gcc > tree" writing backends both linked into it and dynamically chose > between them. Yes, the cm3 front-end will generate .mo/.io files for any target on any other host. The gcc-based backend runs as a separate process (there are license issues with linking the gcc-based backend directly with the front-end). > Maybe it already does. > cm3 operates at a fairly high level when using gcc, and the target > specific stuff is just some data about the name of setjmp, the > sizeof jmp_buf, etc.. > > The "only" "problem" is then m3cg/as/ld/link. > m3cg could be moved to $CM3_INSTALL/pkg/x/HOST/TARGET. True! > cm3, along with everything else, could be $CM3_INSTALL/pkg/x/HOST > leaving $CM3_INSTALL/bin/cm3 that is sh and $CM3_INSTALL/bin/cm3.py > or cm3.cmd that calls out to cm3. Possibly. > "Fixing" as/ld, well, I don't suppose they tend to be target > neutral do they? You'd have to import them like gcc and build them > n times. Gaining a much slower build, much larger tree. Indeed. > I suppose anyone could do this themselves, and change cm3.cfg > appropriately. Doing things "officially" this way for one "big" > distribution, probably folks would not go for. This is how bootstraps to other targets typically go: cm3 *.m3- >*.mo. Copy .mo files to target. Build cm3cg for target. cm3cg *.mo->*.ms as *.ms->*.o ld *.o->libs/execs. > > > - Jay > > > > From: jayk123 at hotmail.com > To: m3devel at elegosoft.com > Subject: "crazy cross" > Date: Sat, 5 Jan 2008 01:22:13 +0000 > > You've all heard of "Canadian cross"? > > It is cross-building a cross-compiler. > I'm sitting in Windows. I'm going to build a compiler that is going > to run on Linux that is going to target Solaris. > For one example. > > You've all seen that Apple has switches like so: > > gcc -arch i386 ppc ppc64 x86_64 hello.c > and poof out comes a binary that runs natively on four architectures > > I don't like the "inconvenience" of non cross systems and having to > have all the machines/OSes just to build the binaries. > I realize that you hit the wall if you actually want to test the > results. So cross building only gets so much. > Of course I also don't want to multiply out build times for tools... > > Ok, well what is the possibility of: > > cm3 -target NT386 > cm3 -target NT386 -target PPC_DARWIN > > ? In my crazy imagination, you have: > > \cm3\bin\cm3.cmd > %~dp0..\libexec\%processor_architecture%\%TARGET%\cm3.exe %* > > \cm3\bin\cm3 > #!/bin/sh > dirname(dirname($0))/libexec/`uname whatever`/$TARGET/cm3 $@ > > Thus it becomes POSSIBLE to have an n x m matrix, host x target, > and be able to build > "anything" from one environment. > > Actually the targets could all be merged into one .exe or > be .dll/.sos. > Except the code isn't setup for that. > > Interesting? > > I guess the hard part is the C code and linking? > The Modula-3 stuff is already setup to do most of this? > (partly by virtue of all that header rewriting that I labeled > sleazy) > > - Jay > > > > Share life as it happens with the new Windows Live. Start sharing! > > Share life as it happens with the new Windows Live. Start sharing! From hosking at cs.purdue.edu Tue Jan 15 14:54:50 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 15 Jan 2008 08:54:50 -0500 Subject: [M3devel] NT386GNU status In-Reply-To: References: Message-ID: <6D01FCB8-D43D-4927-BA3C-23C566E818E6@cs.purdue.edu> On Jan 15, 2008, at 8:34 AM, Jay wrote: > I can build a lot of std, at least up to m3ui. > > However..nothing works. > > Everything crashes. > > In order to build std, I copied back the NT386 cm3 and mklib, > though the config sets TARGET=NT386GNU and runs cm3cg. > (i.e. I'm not just using the NT386 backend!) > > The crash is what I mentioned the other day: > > D:\>\cygwin\bin\gdb \dev2\cm3.2\m3-sys\cm3\NT386GNU\cm3.exe > GNU gdb 6.5.50.20060706-cvs (cygwin-special) > Copyright (C) 2006 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, > and you are > welcome to change it and/or distribute copies of it under certain > conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for > details. > This GDB was configured as "i686-pc-cygwin"... > (gdb) run > Starting program: D:/dev2/cm3.2/m3-sys/cm3/NT386GNU/cm3.exe > Loaded symbols for /cygdrive/d/WINDOWS/system32/ntdll.dll > Loaded symbols for /cygdrive/d/WINDOWS/system32/kernel32.dll > Loaded symbols for /cygdrive/d/WINDOWS/system32/advapi32.dll > Loaded symbols for /cygdrive/d/WINDOWS/system32/rpcrt4.dll > Loaded symbols for /cygdrive/d/WINDOWS/system32/gdi32.dll > Loaded symbols for /cygdrive/d/WINDOWS/system32/user32.dll > Loaded symbols for /cygdrive/d/WINDOWS/system32/msvcrt.dll > Loaded symbols for /cygdrive/d/WINDOWS/system32/wsock32.dll > Loaded symbols for /cygdrive/d/WINDOWS/system32/ws2_32.dll > Loaded symbols for /cygdrive/d/WINDOWS/system32/ws2help.dll > > Program received signal SIGSEGV, Segmentation fault. > 0x00000000 in ?? () > (gdb) bt > #0 0x00000000 in ?? () > #1 0x005de831 in RTLinker__FindModules (M3_DjPxE3_m=0x682340) > at RTLinker.m3:182 > #2 0x005de5fb in RTLinker__AddUnitI (M3_DjPxE3_m=0x682340) at > RTLinker.m3:111 > #3 0x005de6b0 in RTLinker__AddUnit (M3_DjPxE5_b=0x603fd0) at > RTLinker.m3:122 > #4 0x005de34d in RTLinker__InitRuntime (M3_AcxOUs_p_argc=0, > M3_AJWxb1_p_argv=0x3f2bf0, M3_AJWxb1_p_envp=0x3f24c0, > M3_AJWxb1_p_instance=0x1) at RTLinker.m3:42 > #5 0x00401315 in main (argc=1, argv=0x3f24c0, envp=0x3f2bf0) at > _m3main.mc:3 > (gdb) q > The program is running. Exit anyway? (y or n) y > D:\> Looks like a problem with the run-time linker. Something must be broken in the compiler-generated link info. Not sure why... > Oh, m3ui and related are broken due to: > > D:\dev2\cm3.2\m3-tools\m3bundle\NT386GNU\m3bundle -name > formseditBundle -FD:\DOC > UME~1\Jay\LOCALS~1\Temp\qk > new source -> compiling FormsEditVBT.i3 > new source -> compiling formseditBundle.i3 > new source -> compiling FormsEditVBT.m3 > new source -> compiling FormsEdit.m3 > new source -> compiling formseditBundle.m3 > -> linking formsedit.exe > D:\dev2\cm3.2/m3-ui\ui\NT386GNU\m3ui.lib.sa(WinTrestle.mo): In > function `WinTres > tle__ButtonEvent': > WinTrestle.m3:1843: undefined reference to `WindowFromPoint at 4' > collect2: ld returned 1 exit status > "D:\\dev2\\cm3.2\m3-sys\cminstall\src\config\NT386GNU", line 583: > quake runtime > error: link failed, see D:\dev2\cm3.2\m3-ui\formsedit\NT386GNU > \formsedit.lst for > more information > > \mingw\bin\nm \MinGW\lib\libuser32.a | findstr WindowFromPoint > 00000000 T _WindowFromPoint at 8 > 00000000 I __imp__WindowFromPoint at 8 > > Maybe Tony will fix my __stdcall work. :) Yes, I know what needs doing to m3cc(cm3cg). Just need to do it. > Or maybe the problem is the declaration. > Or maybe I can confirm it is passing a small struct by pointer > instead of by reference > and just write a little translation thunk. But also see why NT386 > works. > Not a big deal. Trestle can wait. > > If anyone wants to try this stuff out, debug, I can either share > diffs or commit them. > They are actually pretty small. > I just have to look into the definitions of the runtime linker/ > binder stuff and/or > the assembly, see if there's some disconnect somewhere. > > Other gdb above, this is all with mingwin + msys. > They are enough to build cm3cg. > mingwin should suffice for the rest. > > The ld that comes with the mingwin that free Qt gives you is too > old, from around 2004. > It doesn't support "response files", which are needed for building > some packages due to command line length. > The change was made circa 2005. Current "released" Mingwin works (I > didn't use "technology preview") > > Probably I'll take a break for now. > > - Jay > > Share life as it happens with the new Windows Live. Start sharing! From jayk123 at hotmail.com Wed Jan 16 00:24:50 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 15 Jan 2008 23:24:50 +0000 Subject: [M3devel] "crazy cross" 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> Message-ID: I forgot some vaguely related things. Do people worry about optimizing away creating new processes? Could m3cg be built as an .so/.dll? Probably. And ok license-wise? Could m3cg be run once per package instead of once per source? gcc and cl both can be: cl -c foo.c bar.c gcc -c foo.c bar.c Currently in NT386GNU I depend on -o, gcc -c foo.c -o foo.obj Would need to handle that, not a big deal. Also, in the scheme below, either cm3.sh/cm3.cmd would have a switch to merely print the "real" cm3's path, or, just as well, sysinfo.sh et. al. would know how to find it, save that process. Furthermore -- multithreaded build? I believe, maybe absent bootstrapping, that cm3 could read "all" the m3makefiles, work out the dependency graph trivially, and build things in parallel. Bootstrappinging works too. It builds only what you say, in the right order. The Python scripts can implement this easily enough. - Jay ---------------------------------------- > CC: m3devel at elegosoft.com > From: hosking at cs.purdue.edu > Subject: Re: [M3devel] "crazy cross" > Date: Tue, 15 Jan 2008 08:47:13 -0500 > To: jayk123 at hotmail.com > > > On Jan 15, 2008, at 2:00 AM, Jay wrote: > >> It looks like at least cm3 is "always" target-independent. >> Whatever target is defined to in cm3.cfg, if it is one of the built >> in known ones, cm3 will generate code for. Except maybe NT386, >> though it need not be -- cm3 could have both the .obj and "gcc >> tree" writing backends both linked into it and dynamically chose >> between them. > > Yes, the cm3 front-end will generate .mo/.io files for any target on > any other host. The gcc-based backend runs as a separate process > (there are license issues with linking the gcc-based backend directly > with the front-end). > >> Maybe it already does. >> cm3 operates at a fairly high level when using gcc, and the target >> specific stuff is just some data about the name of setjmp, the >> sizeof jmp_buf, etc.. >> >> The "only" "problem" is then m3cg/as/ld/link. >> m3cg could be moved to $CM3_INSTALL/pkg/x/HOST/TARGET. > > True! > >> cm3, along with everything else, could be $CM3_INSTALL/pkg/x/HOST >> leaving $CM3_INSTALL/bin/cm3 that is sh and $CM3_INSTALL/bin/cm3.py >> or cm3.cmd that calls out to cm3. > > Possibly. > >> "Fixing" as/ld, well, I don't suppose they tend to be target >> neutral do they? You'd have to import them like gcc and build them >> n times. Gaining a much slower build, much larger tree. > > Indeed. > >> I suppose anyone could do this themselves, and change cm3.cfg >> appropriately. Doing things "officially" this way for one "big" >> distribution, probably folks would not go for. > > This is how bootstraps to other targets typically go: cm3 *.m3- > >*.mo. Copy .mo files to target. Build cm3cg for target. cm3cg > *.mo->*.ms as *.ms->*.o ld *.o->libs/execs. > > >> >> >> - Jay >> >> >> >> From: jayk123 at hotmail.com >> To: m3devel at elegosoft.com >> Subject: "crazy cross" >> Date: Sat, 5 Jan 2008 01:22:13 +0000 >> >> You've all heard of "Canadian cross"? >> >> It is cross-building a cross-compiler. >> I'm sitting in Windows. I'm going to build a compiler that is going >> to run on Linux that is going to target Solaris. >> For one example. >> >> You've all seen that Apple has switches like so: >> >> gcc -arch i386 ppc ppc64 x86_64 hello.c >> and poof out comes a binary that runs natively on four architectures >> >> I don't like the "inconvenience" of non cross systems and having to >> have all the machines/OSes just to build the binaries. >> I realize that you hit the wall if you actually want to test the >> results. So cross building only gets so much. >> Of course I also don't want to multiply out build times for tools... >> >> Ok, well what is the possibility of: >> >> cm3 -target NT386 >> cm3 -target NT386 -target PPC_DARWIN >> >> ? In my crazy imagination, you have: >> >> \cm3\bin\cm3.cmd >> %~dp0..\libexec\%processor_architecture%\%TARGET%\cm3.exe %* >> >> \cm3\bin\cm3 >> #!/bin/sh >> dirname(dirname($0))/libexec/`uname whatever`/$TARGET/cm3 $@ >> >> Thus it becomes POSSIBLE to have an n x m matrix, host x target, >> and be able to build >> "anything" from one environment. >> >> Actually the targets could all be merged into one .exe or >> be .dll/.sos. >> Except the code isn't setup for that. >> >> Interesting? >> >> I guess the hard part is the C code and linking? >> The Modula-3 stuff is already setup to do most of this? >> (partly by virtue of all that header rewriting that I labeled >> sleazy) >> >> - Jay >> >> >> >> Share life as it happens with the new Windows Live. Start sharing! >> >> Share life as it happens with the new Windows Live. Start sharing! > _________________________________________________________________ Watch ?Cause Effect,? a show about real people making a real difference. http://im.live.com/Messenger/IM/MTV/?source=text_watchcause From hosking at cs.purdue.edu Wed Jan 16 00:51:44 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 15 Jan 2008 18:51:44 -0500 Subject: [M3devel] "crazy cross" 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> Message-ID: <1DDFAB54-77B6-4593-B309-2C767D4F1FAC@cs.purdue.edu> On Jan 15, 2008, at 6:24 PM, Jay wrote: > > I forgot some vaguely related things. > > Do people worry about optimizing away creating new processes? Perhaps. > Could m3cg be built as an .so/.dll? Probably. Tricky given gcc's nature. But, m3middle could be glued to gcc to build gcc's trees directly...though I strongly prefer the current arrangement. > And ok license-wise? Um, no. FSF have been generally opposed to the way the Modula-3 backend is a thin front-end veneer over gcc, since we get to use their compiler without infecting M3 with the GPL/LGPL. Of course, it would probably be preferable to have CM3 under the GPL/LGPL > Could m3cg be run once per package instead of once per source? Possibly, though right now m3cg does not use the gcc front-end driver. To be honest, I prefer the separation of concerns between m3middle and the gcc-based backend. It is much easier for debugging and development. > gcc and cl both can be: > cl -c foo.c bar.c > gcc -c foo.c bar.c > Currently in NT386GNU I depend on -o, > gcc -c foo.c -o foo.obj > Would need to handle that, not a big deal. > > Also, in the scheme below, either cm3.sh/cm3.cmd would have a > switch to merely print the "real" cm3's path, or, just as well, > sysinfo.sh et. al. would know how to find it, save that process. > > Furthermore -- multithreaded build? > > I believe, maybe absent bootstrapping, that cm3 could read "all" > the m3makefiles, work out the dependency graph trivially, and build > things in parallel. Bootstrappinging works too. It builds only what > you say, in the right order. The Python scripts can implement this > easily enough. I would strongly prefer to see functionality remain decomposed as it currently is. Tangled balls of string are tough to understand, maintain, and develop. > > - Jay > > ---------------------------------------- >> CC: m3devel at elegosoft.com >> From: hosking at cs.purdue.edu >> Subject: Re: [M3devel] "crazy cross" >> Date: Tue, 15 Jan 2008 08:47:13 -0500 >> To: jayk123 at hotmail.com >> >> >> On Jan 15, 2008, at 2:00 AM, Jay wrote: >> >>> It looks like at least cm3 is "always" target-independent. >>> Whatever target is defined to in cm3.cfg, if it is one of the built >>> in known ones, cm3 will generate code for. Except maybe NT386, >>> though it need not be -- cm3 could have both the .obj and "gcc >>> tree" writing backends both linked into it and dynamically chose >>> between them. >> >> Yes, the cm3 front-end will generate .mo/.io files for any target on >> any other host. The gcc-based backend runs as a separate process >> (there are license issues with linking the gcc-based backend directly >> with the front-end). >> >>> Maybe it already does. >>> cm3 operates at a fairly high level when using gcc, and the target >>> specific stuff is just some data about the name of setjmp, the >>> sizeof jmp_buf, etc.. >>> >>> The "only" "problem" is then m3cg/as/ld/link. >>> m3cg could be moved to $CM3_INSTALL/pkg/x/HOST/TARGET. >> >> True! >> >>> cm3, along with everything else, could be $CM3_INSTALL/pkg/x/HOST >>> leaving $CM3_INSTALL/bin/cm3 that is sh and $CM3_INSTALL/bin/cm3.py >>> or cm3.cmd that calls out to cm3. >> >> Possibly. >> >>> "Fixing" as/ld, well, I don't suppose they tend to be target >>> neutral do they? You'd have to import them like gcc and build them >>> n times. Gaining a much slower build, much larger tree. >> >> Indeed. >> >>> I suppose anyone could do this themselves, and change cm3.cfg >>> appropriately. Doing things "officially" this way for one "big" >>> distribution, probably folks would not go for. >> >> This is how bootstraps to other targets typically go: cm3 *.m3- >>> *.mo. Copy .mo files to target. Build cm3cg for target. cm3cg >> *.mo->*.ms as *.ms->*.o ld *.o->libs/execs. >> >> >>> >>> >>> - Jay >>> >>> >>> >>> From: jayk123 at hotmail.com >>> To: m3devel at elegosoft.com >>> Subject: "crazy cross" >>> Date: Sat, 5 Jan 2008 01:22:13 +0000 >>> >>> You've all heard of "Canadian cross"? >>> >>> It is cross-building a cross-compiler. >>> I'm sitting in Windows. I'm going to build a compiler that is going >>> to run on Linux that is going to target Solaris. >>> For one example. >>> >>> You've all seen that Apple has switches like so: >>> >>> gcc -arch i386 ppc ppc64 x86_64 hello.c >>> and poof out comes a binary that runs natively on four architectures >>> >>> I don't like the "inconvenience" of non cross systems and having to >>> have all the machines/OSes just to build the binaries. >>> I realize that you hit the wall if you actually want to test the >>> results. So cross building only gets so much. >>> Of course I also don't want to multiply out build times for tools... >>> >>> Ok, well what is the possibility of: >>> >>> cm3 -target NT386 >>> cm3 -target NT386 -target PPC_DARWIN >>> >>> ? In my crazy imagination, you have: >>> >>> \cm3\bin\cm3.cmd >>> %~dp0..\libexec\%processor_architecture%\%TARGET%\cm3.exe %* >>> >>> \cm3\bin\cm3 >>> #!/bin/sh >>> dirname(dirname($0))/libexec/`uname whatever`/$TARGET/cm3 $@ >>> >>> Thus it becomes POSSIBLE to have an n x m matrix, host x target, >>> and be able to build >>> "anything" from one environment. >>> >>> Actually the targets could all be merged into one .exe or >>> be .dll/.sos. >>> Except the code isn't setup for that. >>> >>> Interesting? >>> >>> I guess the hard part is the C code and linking? >>> The Modula-3 stuff is already setup to do most of this? >>> (partly by virtue of all that header rewriting that I labeled >>> sleazy) >>> >>> - Jay >>> >>> >>> >>> Share life as it happens with the new Windows Live. Start sharing! >>> >>> Share life as it happens with the new Windows Live. Start sharing! >> > > _________________________________________________________________ > Watch ?Cause Effect,? a show about real people making a real > difference. > http://im.live.com/Messenger/IM/MTV/?source=text_watchcause From jayk123 at hotmail.com Wed Jan 16 04:57:13 2008 From: jayk123 at hotmail.com (Jay) Date: Wed, 16 Jan 2008 03:57:13 +0000 Subject: [M3devel] NT386GNU status In-Reply-To: <6D01FCB8-D43D-4927-BA3C-23C566E818E6@cs.purdue.edu> References: <6D01FCB8-D43D-4927-BA3C-23C566E818E6@cs.purdue.edu> Message-ID: I believe you are perfectly capable of finding this, but fyi: http://msdn2.microsoft.com/en-us/library/ms633558.aspx HWND WindowFromPoint(POINT Point); http://msdn2.microsoft.com/en-us/library/ms536119(VS.85).aspx typedef struct tagPOINT { LONG x; LONG y; } POINT, *PPOINT; http://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/m3core/src/win32/WinUser.i3?rev=1.2;content-type=text%2Fplain <*EXTERNAL WindowFromPoint:WINAPI*>PROCEDURE WindowFromPoint (Point: POINT): HWND; http://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/m3core/src/win32/WinDef.i3 POINT = RECORD x: LONG; y: LONG; END; so 8 byte structs are passed by value.Other small sizes might be an issue as well. Oh.. //#pragma pack(1) made no difference #define X(n) typedef struct { char a[n]; } A ## n; void __stdcall F ## n( A##n a) { } X(1) X(2) X(3) X(4) X(5) X(6) X(7) X(8)X(9) X(10) X(11) X(12) X(13) X(14) X(15)X(16) X(17) X(18) X(19) X(20) X(30) X(90)X(900) X(901) X(902) Y:\>link /dump /symbols t.obj Dump of file t.obj COFF SYMBOL TABLE008 00000000 SECT3 notype () External | _F1 at 4009 00000010 SECT3 notype () External | _F2 at 400A 00000020 SECT3 notype () External | _F3 at 400B 00000030 SECT3 notype () External | _F4 at 400C 00000040 SECT3 notype () External | _F5 at 800D 00000050 SECT3 notype () External | _F6 at 800E 00000060 SECT3 notype () External | _F7 at 800F 00000070 SECT3 notype () External | _F8 at 8010 00000080 SECT3 notype () External | _F9 at 12011 00000090 SECT3 notype () External | _F10 at 12012 000000A0 SECT3 notype () External | _F11 at 12013 000000B0 SECT3 notype () External | _F12 at 12014 000000C0 SECT3 notype () External | _F13 at 16015 000000D0 SECT3 notype () External | _F14 at 16016 000000E0 SECT3 notype () External | _F15 at 16017 000000F0 SECT3 notype () External | _F16 at 16018 00000100 SECT3 notype () External | _F17 at 20019 00000110 SECT3 notype () External | _F18 at 2001A 00000120 SECT3 notype () External | _F19 at 2001B 00000130 SECT3 notype () External | _F20 at 2001C 00000140 SECT3 notype () External | _F30 at 3201D 00000150 SECT3 notype () External | _F90 at 9201E 00000160 SECT3 notype () External | _F900 at 90001F 00000170 SECT3 notype () External | _F901 at 904020 00000180 SECT3 notype () External | _F902 at 904 so, really, pass by value is pass by value, no matter the size.Round struct sizes up to a multiple of 4 (or word size, but this naming stuff and multiple calling conventions is only x86). I thought beyond some small number they'd be passed by pointer and the callee would copy to its local stack..which /might/ still be the case, but it's not how the function naming works at least. I'll check what the code should and does look like. - Jay > From: hosking at cs.purdue.edu> > > Oh, m3ui and related are broken due to:> >> > -> linking formsedit.exe> > WinTrestle.m3:1843: undefined reference to `WindowFromPoint at 4'> >> > \mingw\bin\nm \MinGW\lib\libuser32.a | findstr WindowFromPoint> > 00000000 T _WindowFromPoint at 8> > 00000000 I __imp__WindowFromPoint at 8> >> > Maybe Tony will fix my __stdcall work. :)> > Yes, I know what needs doing to m3cc(cm3cg). Just need to do it. _________________________________________________________________ Make distant family not so distant with Windows Vista? + Windows Live?. http://www.microsoft.com/windows/digitallife/keepintouch.mspx?ocid=TXT_TAGLM_CPC_VideoChat_distantfamily_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcoleburn at scires.com Wed Jan 16 04:52:59 2008 From: rcoleburn at scires.com (Randy Coleburn) Date: Tue, 15 Jan 2008 22:52:59 -0500 Subject: [M3devel] my status on win32 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> <477EA137.1E75.00D7.1@scires.com> Message-ID: <478D394B.1E75.00D7.1@scires.com> Jay et al: I've listed below the steps I've undertaken to try and build the current sources on Windows XP. I've also attached a text file showing the output I got when trying to build everything using Jay's upgrade.cmd script. Unfortunately, I'm getting a build error (see below). Please advise on how to resolve. STEPS I TOOK: ========= 1. Download Microsoft Visual Studio 2008 Express Edition All-in-One .ISO file and burn to DVD. http://www.microsoft.com/express/download/ 2. Install Microsoft Visual C++ 2008 Express Edition from DVD. 3. Use "Microsoft Update" service to check for updates / service packs. 4. Download cygwin setup program from http://cygwin.com/ 5. Ran cygwin setup.exe program to install cygwin for all users. Under "Devel" category, make certain to select "cvs" for installation. 6. Launch cygwin from desktop icon. 7. In cygwin command shell window, execute following two commands, making sure to give email as password when prompted for login: cvs -d :pserver:anonymous at modula3.elegosoft.com:/usr/cvs login cvs -d :pserver:anonymous at modula3.elegosoft.com:/usr/cvs checkout cm3 8. Moved resulting C:\cygwin\home\rcoleburn\cm3 to C:\CM3_CVS_SourceTree Note that you should replace "rcoleburn" above with your Windows login username. 9. Download cm3-min-WIN32-NT386-d5.5.0.zip and cm3-min-WIN32-NT386-d5.5.0-symbols.zip from http://modula3.elegosoft.com/cm3/download.html 10. Unzipped cm3-min-WIN32-NT386-d5.5.0.zip and stored resulting cm3 folder at C:\cm3 11. Unzipped cm3-min-WIN32-NT386-d5.5.0-symbols.zip and stored resulting symbols folder at C:\cm3\symbols 12. Launch Windows Command Prompt shell. The following steps represent commands executed within this shell. 13. path %path%;c:\cm3\bin 14. "C:\Program Files\Microsoft Visual Studio 9.0\VC\vcvarsall.bat" 15. cd C:\CM3_CVS_SourceTree\scripts\win 16. upgrade.cmd ERROR I'M GETTING: ============= === package C:\CM3_CVS_SourceTree\m3-sys\cm3 === +++ "cm3 -build -DROOT=C:\\CM3_CVS_SourceTree -DCM3_VERSION_TEXT=d5.5.1 -DCM3_V ERSION_NUMBER=050501 -DCM3_LAST_CHANGED=2007-12-30 && cm3 -ship -DROOT=C:\\CM3_C VS_SourceTree -DCM3_VERSION_TEXT=d5.5.1 -DCM3_VERSION_NUMBER=050501 -DCM3_LAST_C HANGED=2007-12-30" +++ --- building in NT386 --- ignoring ..\src\m3overrides "C:\CM3_CVS_SourceTree\m3-sys\cm3\src\version.quake", line 136: quake runtime er ror: unable to open "C:\CM3_CVS_SourceTree\m3-sys\cm3\src\../NT386.datenow" for reading --procedure-- -line- -file--- include -- version_impl 136 C:\CM3_CVS_SourceTree\m3-sys\cm3\src\version.quake include_dir 20 C:\CM3_CVS_SourceTree\m3-sys\cm3\src\m3makefile 8 C:\CM3_CVS_SourceTree\m3-sys\cm3\NT386\m3make.args Fatal Error: package build failed ERROR: "cm3 -build -DROOT=C:\\CM3_CVS_SourceTree -DCM3_VERSION_TEXT=d5.5.1 -DCM 3_VERSION_NUMBER=050501 -DCM3_LAST_CHANGED=2007-12-30 && cm3 -ship -DROOT=C:\\CM 3_CVS_SourceTree -DCM3_VERSION_TEXT=d5.5.1 -DCM3_VERSION_NUMBER=050501 -DCM3_LAS T_CHANGED=2007-12-30" ERROR: cd C:\CM3_CVS_SourceTree\m3-sys\cm3 ERROR: set INSTALLROOT=c:\cm3 Regards, Randy -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: cm3setup.txt URL: From jayk123 at hotmail.com Wed Jan 16 05:03:24 2008 From: jayk123 at hotmail.com (Jay) Date: Wed, 16 Jan 2008 04:03:24 +0000 Subject: [M3devel] my status on win32 In-Reply-To: <478D394B.1E75.00D7.1@scires.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> <477EA137.1E75.00D7.1@scires.com> <478D394B.1E75.00D7.1@scires.com> Message-ID: That's not too bad really. 1) I'd recommend putting cm3 at the start of the path instead of the end. 2) Just comment out the offending code to make progress. It's not critical. >> C:\CM3_CVS_SourceTree\m3-sys\cm3\src\../NT386.datenow The code is: C:\CM3_CVS_SourceTree\m3-sys\cm3\src\version.quake or such, included by cm3\src\m3makefile. Does the file exist? Does version.quake use "/" or "SL"? If it uses "/", try replacing with SL (and ampersand for string concat). Could be that a newer binary distributions works better with forward slashes. > 4. > 5. > 6. Launch cygwin from desktop icon. Cygwin is only needed for cvs, I think you realize. Could you send me offline the result of just running "set" after running vcvarsall? I'd like to adapt pylib.py to it maybe. (I can start from 5.1.6 and will try 4.1 at some point.) - Jay Date: Tue, 15 Jan 2008 22:52:59 -0500From: rcoleburn at scires.comTo: m3devel at elegosoft.com; jayk123 at hotmail.comSubject: my status on win32 Jay et al: I've listed below the steps I've undertaken to try and build the current sources on Windows XP. I've also attached a text file showing the output I got when trying to build everything using Jay's upgrade.cmd script. Unfortunately, I'm getting a build error (see below). Please advise on how to resolve. STEPS I TOOK: ========= 1. Download Microsoft Visual Studio 2008 Express Edition All-in-One .ISO file and burn to DVD. http://www.microsoft.com/express/download/ 2. Install Microsoft Visual C++ 2008 Express Edition from DVD. 3. Use "Microsoft Update" service to check for updates / service packs. 4. Download cygwin setup program from http://cygwin.com/ 5. Ran cygwin setup.exe program to install cygwin for all users. Under "Devel" category, make certain to select "cvs" for installation. 6. Launch cygwin from desktop icon. 7. In cygwin command shell window, execute following two commands, making sure to give email as password when prompted for login: cvs -d :pserver:anonymous at modula3.elegosoft.com:/usr/cvs login cvs -d :pserver:anonymous at modula3.elegosoft.com:/usr/cvs checkout cm3 8. Moved resulting C:\cygwin\home\rcoleburn\cm3 to C:\CM3_CVS_SourceTree Note that you should replace "rcoleburn" above with your Windows login username. 9. Download cm3-min-WIN32-NT386-d5.5.0.zip and cm3-min-WIN32-NT386-d5.5.0-symbols.zip from http://modula3.elegosoft.com/cm3/download.html 10. Unzipped cm3-min-WIN32-NT386-d5.5.0.zip and stored resulting cm3 folder at C:\cm3 11. Unzipped cm3-min-WIN32-NT386-d5.5.0-symbols.zip and stored resulting symbols folder at C:\cm3\symbols 12. Launch Windows Command Prompt shell. The following steps represent commands executed within this shell. 13. path %path%;c:\cm3\bin 14. "C:\Program Files\Microsoft Visual Studio 9.0\VC\vcvarsall.bat" 15. cd C:\CM3_CVS_SourceTree\scripts\win 16. upgrade.cmd ERROR I'M GETTING: ============= === package C:\CM3_CVS_SourceTree\m3-sys\cm3 ===+++ "cm3 -build -DROOT=C:\\CM3_CVS_SourceTree -DCM3_VERSION_TEXT=d5.5.1 -DCM3_VERSION_NUMBER=050501 -DCM3_LAST_CHANGED=2007-12-30 && cm3 -ship -DROOT=C:\\CM3_CVS_SourceTree -DCM3_VERSION_TEXT=d5.5.1 -DCM3_VERSION_NUMBER=050501 -DCM3_LAST_CHANGED=2007-12-30" +++--- building in NT386 --- ignoring ..\src\m3overrides "C:\CM3_CVS_SourceTree\m3-sys\cm3\src\version.quake", line 136: quake runtime error: unable to open "C:\CM3_CVS_SourceTree\m3-sys\cm3\src\../NT386.datenow" forreading --procedure-- -line- -file---include -- version_impl 136 C:\CM3_CVS_SourceTree\m3-sys\cm3\src\version.quakeinclude_dir 20 C:\CM3_CVS_SourceTree\m3-sys\cm3\src\m3makefile 8 C:\CM3_CVS_SourceTree\m3-sys\cm3\NT386\m3make.args Fatal Error: package build failedERROR: "cm3 -build -DROOT=C:\\CM3_CVS_SourceTree -DCM3_VERSION_TEXT=d5.5.1 -DCM3_VERSION_NUMBER=050501 -DCM3_LAST_CHANGED=2007-12-30 && cm3 -ship -DROOT=C:\\CM3_CVS_SourceTree -DCM3_VERSION_TEXT=d5.5.1 -DCM3_VERSION_NUMBER=050501 -DCM3_LAST_CHANGED=2007-12-30"ERROR: cd C:\CM3_CVS_SourceTree\m3-sys\cm3ERROR: set INSTALLROOT=c:\cm3 Regards, Randy _________________________________________________________________ Share life as it happens with the new Windows Live. http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcoleburn at scires.com Wed Jan 16 05:30:01 2008 From: rcoleburn at scires.com (Randy Coleburn) Date: Tue, 15 Jan 2008 23:30:01 -0500 Subject: [M3devel] my status on win32 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> <477EA137.1E75.00D7.1@scires.com> <478D394B.1E75.00D7.1@scires.com> Message-ID: <478D41F9.1E75.00D7.1@scires.com> Jay: The file version.quake does exist in m3-sys\cm3\src I'm not much of a quake programmer, so not sure exactly how to alter this file. I did a search for "SL" but did not find it. Regards, Randy >>> Jay 1/15/2008 11:03 PM >>> That's not too bad really. 1) I'd recommend putting cm3 at the start of the path instead of the end. 2) Just comment out the offending code to make progress. It's not critical. >> C:\CM3_CVS_SourceTree\m3-sys\cm3\src\../NT386.datenow The code is: C:\CM3_CVS_SourceTree\m3-sys\cm3\src\version.quake or such, included by cm3\src\m3makefile. Does the file exist? Does version.quake use "/" or "SL"? If it uses "/", try replacing with SL (and ampersand for string concat). Could be that a newer binary distributions works better with forward slashes. > 4. > 5. > 6. Launch cygwin from desktop icon. Cygwin is only needed for cvs, I think you realize. Could you send me offline the result of just running "set" after running vcvarsall? I'd like to adapt pylib.py to it maybe. (I can start from 5.1.6 and will try 4.1 at some point.) - Jay Date: Tue, 15 Jan 2008 22:52:59 -0500 From: rcoleburn at scires.com To: m3devel at elegosoft.com; jayk123 at hotmail.com Subject: my status on win32 Jay et al: I've listed below the steps I've undertaken to try and build the current sources on Windows XP. I've also attached a text file showing the output I got when trying to build everything using Jay's upgrade.cmd script. Unfortunately, I'm getting a build error (see below). Please advise on how to resolve. STEPS I TOOK: ========= 1. Download Microsoft Visual Studio 2008 Express Edition All-in-One .ISO file and burn to DVD. http://www.microsoft.com/express/download/ 2. Install Microsoft Visual C++ 2008 Express Edition from DVD. 3. Use "Microsoft Update" service to check for updates / service packs. 4. Download cygwin setup program from http://cygwin.com/ 5. Ran cygwin setup.exe program to install cygwin for all users. Under "Devel" category, make certain to select "cvs" for installation. 6. Launch cygwin from desktop icon. 7. In cygwin command shell window, execute following two commands, making sure to give email as password when prompted for login: cvs -d :pserver:anonymous at modula3.elegosoft.com:/usr/cvs login cvs -d :pserver:anonymous at modula3.elegosoft.com:/usr/cvs checkout cm3 8. Moved resulting C:\cygwin\home\rcoleburn\cm3 to C:\CM3_CVS_SourceTree Note that you should replace "rcoleburn" above with your Windows login username. 9. Download cm3-min-WIN32-NT386-d5.5.0.zip and cm3-min-WIN32-NT386-d5.5.0-symbols.zip from http://modula3.elegosoft.com/cm3/download.html 10. Unzipped cm3-min-WIN32-NT386-d5.5.0.zip and stored resulting cm3 folder at C:\cm3 11. Unzipped cm3-min-WIN32-NT386-d5.5.0-symbols.zip and stored resulting symbols folder at C:\cm3\symbols 12. Launch Windows Command Prompt shell. The following steps represent commands executed within this shell. 13. path %path%;c:\cm3\bin 14. "C:\Program Files\Microsoft Visual Studio 9.0\VC\vcvarsall.bat" 15. cd C:\CM3_CVS_SourceTree\scripts\win 16. upgrade.cmd ERROR I'M GETTING: ============= === package C:\CM3_CVS_SourceTree\m3-sys\cm3 === +++ "cm3 -build -DROOT=C:\\CM3_CVS_SourceTree -DCM3_VERSION_TEXT=d5.5.1 -DCM3_V ERSION_NUMBER=050501 -DCM3_LAST_CHANGED=2007-12-30 && cm3 -ship -DROOT=C:\\CM3_C VS_SourceTree -DCM3_VERSION_TEXT=d5.5.1 -DCM3_VERSION_NUMBER=050501 -DCM3_LAST_C HANGED=2007-12-30" +++ --- building in NT386 --- ignoring ..\src\m3overrides "C:\CM3_CVS_SourceTree\m3-sys\cm3\src\version.quake", line 136: quake runtime er ror: unable to open "C:\CM3_CVS_SourceTree\m3-sys\cm3\src\../NT386.datenow" for reading --procedure-- -line- -file--- include -- version_impl 136 C:\CM3_CVS_SourceTree\m3-sys\cm3\src\version.quake include_dir 20 C:\CM3_CVS_SourceTree\m3-sys\cm3\src\m3makefile 8 C:\CM3_CVS_SourceTree\m3-sys\cm3\NT386\m3make.args Fatal Error: package build failed ERROR: "cm3 -build -DROOT=C:\\CM3_CVS_SourceTree -DCM3_VERSION_TEXT=d5.5.1 -DCM 3_VERSION_NUMBER=050501 -DCM3_LAST_CHANGED=2007-12-30 && cm3 -ship -DROOT=C:\\CM 3_CVS_SourceTree -DCM3_VERSION_TEXT=d5.5.1 -DCM3_VERSION_NUMBER=050501 -DCM3_LAS T_CHANGED=2007-12-30" ERROR: cd C:\CM3_CVS_SourceTree\m3-sys\cm3 ERROR: set INSTALLROOT=c:\cm3 Regards, Randy Share life as it happens with the new Windows Live. Start sharing! ( 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 Wed Jan 16 05:55:39 2008 From: rcoleburn at scires.com (Randy Coleburn) Date: Tue, 15 Jan 2008 23:55:39 -0500 Subject: [M3devel] my status on win32 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> <477EA137.1E75.00D7.1@scires.com> <478D394B.1E75.00D7.1@scires.com> Message-ID: <478D47FB.1E75.00D7.1@scires.com> Jay: In the file version.quake, I made the following edit: changed line: local datefn = "../" & TARGET & ".datenow" to: local datefn = ".." & SL & TARGET & ".datenow" This change has the effect of putting a backward slash in the pathname instead of a forward slash, so we get C:\CM3_CVS_SourceTree\m3-sys\cm3\src\..\NT386.datenow So from that perspective, the change seems good. Unfortunately, I still get the error that this file can't be opened. A quick check of C:\CM3_CVS_SourceTree\m3-sys\cm3\NT386 shows that the file .datenow does not exist. Regards, Randy >>> Jay 1/15/2008 11:03 PM >>> That's not too bad really. 1) I'd recommend putting cm3 at the start of the path instead of the end. 2) Just comment out the offending code to make progress. It's not critical. >> C:\CM3_CVS_SourceTree\m3-sys\cm3\src\../NT386.datenow The code is: C:\CM3_CVS_SourceTree\m3-sys\cm3\src\version.quake or such, included by cm3\src\m3makefile. Does the file exist? Does version.quake use "/" or "SL"? If it uses "/", try replacing with SL (and ampersand for string concat). Could be that a newer binary distributions works better with forward slashes. > 4. > 5. > 6. Launch cygwin from desktop icon. Cygwin is only needed for cvs, I think you realize. Could you send me offline the result of just running "set" after running vcvarsall? I'd like to adapt pylib.py to it maybe. (I can start from 5.1.6 and will try 4.1 at some point.) - Jay Date: Tue, 15 Jan 2008 22:52:59 -0500 From: rcoleburn at scires.com To: m3devel at elegosoft.com; jayk123 at hotmail.com Subject: my status on win32 Jay et al: I've listed below the steps I've undertaken to try and build the current sources on Windows XP. I've also attached a text file showing the output I got when trying to build everything using Jay's upgrade.cmd script. Unfortunately, I'm getting a build error (see below). Please advise on how to resolve. STEPS I TOOK: ========= 1. Download Microsoft Visual Studio 2008 Express Edition All-in-One .ISO file and burn to DVD. http://www.microsoft.com/express/download/ 2. Install Microsoft Visual C++ 2008 Express Edition from DVD. 3. Use "Microsoft Update" service to check for updates / service packs. 4. Download cygwin setup program from http://cygwin.com/ 5. Ran cygwin setup.exe program to install cygwin for all users. Under "Devel" category, make certain to select "cvs" for installation. 6. Launch cygwin from desktop icon. 7. In cygwin command shell window, execute following two commands, making sure to give email as password when prompted for login: cvs -d :pserver:anonymous at modula3.elegosoft.com:/usr/cvs login cvs -d :pserver:anonymous at modula3.elegosoft.com:/usr/cvs checkout cm3 8. Moved resulting C:\cygwin\home\rcoleburn\cm3 to C:\CM3_CVS_SourceTree Note that you should replace "rcoleburn" above with your Windows login username. 9. Download cm3-min-WIN32-NT386-d5.5.0.zip and cm3-min-WIN32-NT386-d5.5.0-symbols.zip from http://modula3.elegosoft.com/cm3/download.html 10. Unzipped cm3-min-WIN32-NT386-d5.5.0.zip and stored resulting cm3 folder at C:\cm3 11. Unzipped cm3-min-WIN32-NT386-d5.5.0-symbols.zip and stored resulting symbols folder at C:\cm3\symbols 12. Launch Windows Command Prompt shell. The following steps represent commands executed within this shell. 13. path %path%;c:\cm3\bin 14. "C:\Program Files\Microsoft Visual Studio 9.0\VC\vcvarsall.bat" 15. cd C:\CM3_CVS_SourceTree\scripts\win 16. upgrade.cmd ERROR I'M GETTING: ============= === package C:\CM3_CVS_SourceTree\m3-sys\cm3 === +++ "cm3 -build -DROOT=C:\\CM3_CVS_SourceTree -DCM3_VERSION_TEXT=d5.5.1 -DCM3_V ERSION_NUMBER=050501 -DCM3_LAST_CHANGED=2007-12-30 && cm3 -ship -DROOT=C:\\CM3_C VS_SourceTree -DCM3_VERSION_TEXT=d5.5.1 -DCM3_VERSION_NUMBER=050501 -DCM3_LAST_C HANGED=2007-12-30" +++ --- building in NT386 --- ignoring ..\src\m3overrides "C:\CM3_CVS_SourceTree\m3-sys\cm3\src\version.quake", line 136: quake runtime er ror: unable to open "C:\CM3_CVS_SourceTree\m3-sys\cm3\src\../NT386.datenow" for reading --procedure-- -line- -file--- include -- version_impl 136 C:\CM3_CVS_SourceTree\m3-sys\cm3\src\version.quake include_dir 20 C:\CM3_CVS_SourceTree\m3-sys\cm3\src\m3makefile 8 C:\CM3_CVS_SourceTree\m3-sys\cm3\NT386\m3make.args Fatal Error: package build failed ERROR: "cm3 -build -DROOT=C:\\CM3_CVS_SourceTree -DCM3_VERSION_TEXT=d5.5.1 -DCM 3_VERSION_NUMBER=050501 -DCM3_LAST_CHANGED=2007-12-30 && cm3 -ship -DROOT=C:\\CM 3_CVS_SourceTree -DCM3_VERSION_TEXT=d5.5.1 -DCM3_VERSION_NUMBER=050501 -DCM3_LAS T_CHANGED=2007-12-30" ERROR: cd C:\CM3_CVS_SourceTree\m3-sys\cm3 ERROR: set INSTALLROOT=c:\cm3 Regards, Randy Share life as it happens with the new Windows Live. Start sharing! ( 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 Jan 16 07:01:42 2008 From: jayk123 at hotmail.com (Jay) Date: Wed, 16 Jan 2008 06:01:42 +0000 Subject: [M3devel] my status on win32 In-Reply-To: <478D47FB.1E75.00D7.1@scires.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> <477EA137.1E75.00D7.1@scires.com> <478D394B.1E75.00D7.1@scires.com> <478D47FB.1E75.00D7.1@scires.com> Message-ID: I think I see the problem. in cm3\src\m3makefile, make this change > if not defined("NOW") include(datefn) > end datefn is only created if certain other variables aren't defined, and do-pkg defines them. I don't know why I don't see this. Later. Could be that the Python scripts have a typo and don't define them.I've been using them more than cmd. If the host is NT, "NOW" is either gotten from an updated cm3.exe, or left to "not available". So the initial cm3 built from older cm3 can't report when it was built, but cm3 built from current cm3 can. I need to change that: 1) to be a function for niceness 2) to make it that way for Posix, for any host but I haven't been using Posix as much lately so not testing it. - Jay Date: Tue, 15 Jan 2008 23:55:39 -0500From: rcoleburn at scires.comTo: m3devel at elegosoft.com; jayk123 at hotmail.comSubject: RE: my status on win32 Jay: In the file version.quake, I made the following edit: changed line: local datefn = "../" & TARGET & ".datenow" to: local datefn = ".." & SL & TARGET & ".datenow" This change has the effect of putting a backward slash in the pathname instead of a forward slash, so we getC:\CM3_CVS_SourceTree\m3-sys\cm3\src\..\NT386.datenow So from that perspective, the change seems good. Unfortunately, I still get the error that this file can't be opened. A quick check of C:\CM3_CVS_SourceTree\m3-sys\cm3\NT386 shows that the file .datenow does not exist. Regards, Randy>>> Jay 1/15/2008 11:03 PM >>>That's not too bad really. 1) I'd recommend putting cm3 at the start of the path instead of the end. 2) Just comment out the offending code to make progress. It's not critical. >> C:\CM3_CVS_SourceTree\m3-sys\cm3\src\../NT386.datenow The code is: C:\CM3_CVS_SourceTree\m3-sys\cm3\src\version.quake or such, included by cm3\src\m3makefile. Does the file exist?Does version.quake use "/" or "SL"? If it uses "/", try replacing with SL (and ampersand for string concat). Could be that a newer binary distributions works better with forward slashes. > 4. > 5. > 6. Launch cygwin from desktop icon. Cygwin is only needed for cvs, I think you realize. Could you send me offline the result of just running "set" after running vcvarsall? I'd like to adapt pylib.py to it maybe. (I can start from 5.1.6 and will try 4.1 at some point.) - Jay Date: Tue, 15 Jan 2008 22:52:59 -0500From: rcoleburn at scires.comTo: m3devel at elegosoft.com; jayk123 at hotmail.comSubject: my status on win32 Jay et al: I've listed below the steps I've undertaken to try and build the current sources on Windows XP. I've also attached a text file showing the output I got when trying to build everything using Jay's upgrade.cmd script. Unfortunately, I'm getting a build error (see below). Please advise on how to resolve. STEPS I TOOK: ========= 1. Download Microsoft Visual Studio 2008 Express Edition All-in-One .ISO file and burn to DVD. http://www.microsoft.com/express/download/ 2. Install Microsoft Visual C++ 2008 Express Edition from DVD. 3. Use "Microsoft Update" service to check for updates / service packs. 4. Download cygwin setup program from http://cygwin.com/ 5. Ran cygwin setup.exe program to install cygwin for all users. Under "Devel" category, make certain to select "cvs" for installation. 6. Launch cygwin from desktop icon. 7. In cygwin command shell window, execute following two commands, making sure to give email as password when prompted for login: cvs -d :pserver:anonymous at modula3.elegosoft.com:/usr/cvs login cvs -d :pserver:anonymous at modula3.elegosoft.com:/usr/cvs checkout cm3 8. Moved resulting C:\cygwin\home\rcoleburn\cm3 to C:\CM3_CVS_SourceTree Note that you should replace "rcoleburn" above with your Windows login username. 9. Download cm3-min-WIN32-NT386-d5.5.0.zip and cm3-min-WIN32-NT386-d5.5.0-symbols.zip from http://modula3.elegosoft.com/cm3/download.html 10. Unzipped cm3-min-WIN32-NT386-d5.5.0.zip and stored resulting cm3 folder at C:\cm3 11. Unzipped cm3-min-WIN32-NT386-d5.5.0-symbols.zip and stored resulting symbols folder at C:\cm3\symbols 12. Launch Windows Command Prompt shell. The following steps represent commands executed within this shell. 13. path %path%;c:\cm3\bin 14. "C:\Program Files\Microsoft Visual Studio 9.0\VC\vcvarsall.bat" 15. cd C:\CM3_CVS_SourceTree\scripts\win 16. upgrade.cmd ERROR I'M GETTING: ============= === package C:\CM3_CVS_SourceTree\m3-sys\cm3 ===+++ "cm3 -build -DROOT=C:\\CM3_CVS_SourceTree -DCM3_VERSION_TEXT=d5.5.1 -DCM3_VERSION_NUMBER=050501 -DCM3_LAST_CHANGED=2007-12-30 && cm3 -ship -DROOT=C:\\CM3_CVS_SourceTree -DCM3_VERSION_TEXT=d5.5.1 -DCM3_VERSION_NUMBER=050501 -DCM3_LAST_CHANGED=2007-12-30" +++--- building in NT386 --- ignoring ..\src\m3overrides "C:\CM3_CVS_SourceTree\m3-sys\cm3\src\version.quake", line 136: quake runtime error: unable to open "C:\CM3_CVS_SourceTree\m3-sys\cm3\src\../NT386.datenow" forreading --procedure-- -line- -file---include -- version_impl 136 C:\CM3_CVS_SourceTree\m3-sys\cm3\src\version.quakeinclude_dir 20 C:\CM3_CVS_SourceTree\m3-sys\cm3\src\m3makefile 8 C:\CM3_CVS_SourceTree\m3-sys\cm3\NT386\m3make.args Fatal Error: package build failedERROR: "cm3 -build -DROOT=C:\\CM3_CVS_SourceTree -DCM3_VERSION_TEXT=d5.5.1 -DCM3_VERSION_NUMBER=050501 -DCM3_LAST_CHANGED=2007-12-30 && cm3 -ship -DROOT=C:\\CM3_CVS_SourceTree -DCM3_VERSION_TEXT=d5.5.1 -DCM3_VERSION_NUMBER=050501 -DCM3_LAST_CHANGED=2007-12-30"ERROR: cd C:\CM3_CVS_SourceTree\m3-sys\cm3ERROR: set INSTALLROOT=c:\cm3 Regards, Randy Share life as it happens with the new Windows Live. Start sharing! _________________________________________________________________ Put your friends on the big screen with Windows Vista? + Windows Live?. http://www.microsoft.com/windows/shop/specialoffers.mspx?ocid=TXT_TAGLM_CPC_MediaCtr_bigscreen_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Wed Jan 16 07:04:48 2008 From: jayk123 at hotmail.com (Jay) Date: Wed, 16 Jan 2008 06:04:48 +0000 Subject: [M3devel] my status on win32 In-Reply-To: <478D47FB.1E75.00D7.1@scires.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> <477EA137.1E75.00D7.1@scires.com> <478D394B.1E75.00D7.1@scires.com> <478D47FB.1E75.00D7.1@scires.com> Message-ID: Note that the file is called "NT386.datenow" in the cm3 directory. I will be changing that too. Outputs don't belong outside of the target directory, unless there is some deliberate need to shield from the frequency of "clean" / "realclean", like if only some other "really really clean" event should cause them to be regenerated. I believe Olaf oked this privately but like I said, I want to change a bit more here, and need to test on Posix. Also there's another file with a dot in front of it, and I generally oppose all "hiding" of files -- Unix dot, or Windows attrib -h. - Jay Date: Tue, 15 Jan 2008 23:55:39 -0500From: rcoleburn at scires.comTo: m3devel at elegosoft.com; jayk123 at hotmail.comSubject: RE: my status on win32 Jay: In the file version.quake, I made the following edit: changed line: local datefn = "../" & TARGET & ".datenow" to: local datefn = ".." & SL & TARGET & ".datenow" This change has the effect of putting a backward slash in the pathname instead of a forward slash, so we getC:\CM3_CVS_SourceTree\m3-sys\cm3\src\..\NT386.datenow So from that perspective, the change seems good. Unfortunately, I still get the error that this file can't be opened. A quick check of C:\CM3_CVS_SourceTree\m3-sys\cm3\NT386 shows that the file .datenow does not exist. Regards, Randy>>> Jay 1/15/2008 11:03 PM >>>That's not too bad really. 1) I'd recommend putting cm3 at the start of the path instead of the end. 2) Just comment out the offending code to make progress. It's not critical. >> C:\CM3_CVS_SourceTree\m3-sys\cm3\src\../NT386.datenow The code is: C:\CM3_CVS_SourceTree\m3-sys\cm3\src\version.quake or such, included by cm3\src\m3makefile. Does the file exist?Does version.quake use "/" or "SL"? If it uses "/", try replacing with SL (and ampersand for string concat). Could be that a newer binary distributions works better with forward slashes. > 4. > 5. > 6. Launch cygwin from desktop icon. Cygwin is only needed for cvs, I think you realize. Could you send me offline the result of just running "set" after running vcvarsall? I'd like to adapt pylib.py to it maybe. (I can start from 5.1.6 and will try 4.1 at some point.) - Jay Date: Tue, 15 Jan 2008 22:52:59 -0500From: rcoleburn at scires.comTo: m3devel at elegosoft.com; jayk123 at hotmail.comSubject: my status on win32 Jay et al: I've listed below the steps I've undertaken to try and build the current sources on Windows XP. I've also attached a text file showing the output I got when trying to build everything using Jay's upgrade.cmd script. Unfortunately, I'm getting a build error (see below). Please advise on how to resolve. STEPS I TOOK: ========= 1. Download Microsoft Visual Studio 2008 Express Edition All-in-One .ISO file and burn to DVD. http://www.microsoft.com/express/download/ 2. Install Microsoft Visual C++ 2008 Express Edition from DVD. 3. Use "Microsoft Update" service to check for updates / service packs. 4. Download cygwin setup program from http://cygwin.com/ 5. Ran cygwin setup.exe program to install cygwin for all users. Under "Devel" category, make certain to select "cvs" for installation. 6. Launch cygwin from desktop icon. 7. In cygwin command shell window, execute following two commands, making sure to give email as password when prompted for login: cvs -d :pserver:anonymous at modula3.elegosoft.com:/usr/cvs login cvs -d :pserver:anonymous at modula3.elegosoft.com:/usr/cvs checkout cm3 8. Moved resulting C:\cygwin\home\rcoleburn\cm3 to C:\CM3_CVS_SourceTree Note that you should replace "rcoleburn" above with your Windows login username. 9. Download cm3-min-WIN32-NT386-d5.5.0.zip and cm3-min-WIN32-NT386-d5.5.0-symbols.zip from http://modula3.elegosoft.com/cm3/download.html 10. Unzipped cm3-min-WIN32-NT386-d5.5.0.zip and stored resulting cm3 folder at C:\cm3 11. Unzipped cm3-min-WIN32-NT386-d5.5.0-symbols.zip and stored resulting symbols folder at C:\cm3\symbols 12. Launch Windows Command Prompt shell. The following steps represent commands executed within this shell. 13. path %path%;c:\cm3\bin 14. "C:\Program Files\Microsoft Visual Studio 9.0\VC\vcvarsall.bat" 15. cd C:\CM3_CVS_SourceTree\scripts\win 16. upgrade.cmd ERROR I'M GETTING: ============= === package C:\CM3_CVS_SourceTree\m3-sys\cm3 ===+++ "cm3 -build -DROOT=C:\\CM3_CVS_SourceTree -DCM3_VERSION_TEXT=d5.5.1 -DCM3_VERSION_NUMBER=050501 -DCM3_LAST_CHANGED=2007-12-30 && cm3 -ship -DROOT=C:\\CM3_CVS_SourceTree -DCM3_VERSION_TEXT=d5.5.1 -DCM3_VERSION_NUMBER=050501 -DCM3_LAST_CHANGED=2007-12-30" +++--- building in NT386 --- ignoring ..\src\m3overrides "C:\CM3_CVS_SourceTree\m3-sys\cm3\src\version.quake", line 136: quake runtime error: unable to open "C:\CM3_CVS_SourceTree\m3-sys\cm3\src\../NT386.datenow" forreading --procedure-- -line- -file---include -- version_impl 136 C:\CM3_CVS_SourceTree\m3-sys\cm3\src\version.quakeinclude_dir 20 C:\CM3_CVS_SourceTree\m3-sys\cm3\src\m3makefile 8 C:\CM3_CVS_SourceTree\m3-sys\cm3\NT386\m3make.args Fatal Error: package build failedERROR: "cm3 -build -DROOT=C:\\CM3_CVS_SourceTree -DCM3_VERSION_TEXT=d5.5.1 -DCM3_VERSION_NUMBER=050501 -DCM3_LAST_CHANGED=2007-12-30 && cm3 -ship -DROOT=C:\\CM3_CVS_SourceTree -DCM3_VERSION_TEXT=d5.5.1 -DCM3_VERSION_NUMBER=050501 -DCM3_LAST_CHANGED=2007-12-30"ERROR: cd C:\CM3_CVS_SourceTree\m3-sys\cm3ERROR: set INSTALLROOT=c:\cm3 Regards, Randy Share life as it happens with the new Windows Live. Start sharing! _________________________________________________________________ Get the power of Windows + Web with the new Windows Live. http://www.windowslive.com?ocid=TXT_TAGHM_Wave2_powerofwindows_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.caltech.edu Wed Jan 16 09:45:47 2008 From: mika at async.caltech.edu (Mika Nystrom) Date: Wed, 16 Jan 2008 00:45:47 -0800 Subject: [M3devel] m3tests, pickles Message-ID: <200801160845.m0G8jlKE064314@camembert.async.caltech.edu> Can I add something tricky to a wish list on regression testing? Tricky because I don't know the best way to go about it. I have spent quite some time with various versions of Modula-3 tracking down issues with Pickles. Usually the problem is that Pickles aren't transferrable between systems, and it turns out that I have included some type, somewhere, that doesn't translate. MUTEX is a good example. First of all it would be very nice if such system dependencies were kept out (for instance, don't know if it's possible, but something like this...) TYPE RealMutex = OBJECT END; TYPE WinMutex = RealMutex OBJECT (* windows fields *) END; TYPE PosixMutex = RealMutex OBJECT (* POSIX fields *) END; TYPE MUTEX = RealMutex; and of course all that a client sees is MUTEX which is the same across systems. However I realize that what I say above may not be possible or practical in all cases. This brings me to the fact that Pickles are sensitive to certain types of bugs (I think), and it would be very nice to check that all OS/processor builds of M3 make compatible Pickles, with the possible exception of things like MUTEX. Of course this can't be done within a single build... Mika From wagner at elegosoft.com Wed Jan 16 10:11:31 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 16 Jan 2008 10:11:31 +0100 Subject: [M3devel] m3tests, pickles In-Reply-To: <200801160845.m0G8jlKE064314@camembert.async.caltech.edu> References: <200801160845.m0G8jlKE064314@camembert.async.caltech.edu> Message-ID: <20080116101131.reooi2rou8swg84k@mail.elegosoft.com> Quoting Mika Nystrom : > > Can I add something tricky to a wish list on regression testing? > Tricky because I don't know the best way to go about it. > > I have spent quite some time with various versions of Modula-3 > tracking down issues with Pickles. Usually the problem is that > Pickles aren't transferrable between systems, and it turns out that > I have included some type, somewhere, that doesn't translate. > MUTEX is a good example. First of all it would be very nice if > such system dependencies were kept out (for instance, don't know > if it's possible, but something like this...) > > TYPE RealMutex = OBJECT END; > > TYPE WinMutex = RealMutex OBJECT (* windows fields *) END; > TYPE PosixMutex = RealMutex OBJECT (* POSIX fields *) END; > > TYPE MUTEX = RealMutex; > > and of course all that a client sees is MUTEX which is the same > across systems. > > However I realize that what I say above may not be possible or > practical in all cases. > > This brings me to the fact that Pickles are sensitive to certain > types of bugs (I think), and it would be very nice to check that > all OS/processor builds of M3 make compatible Pickles, with the > possible exception of things like MUTEX. Of course this can't be > done within a single build... Sure this can and should be done. We just need reference data for all pickles and check them in for comparison somewhere below m3tests. Would you care to add such a test to the m3tests package? The Modula-3 part should could either just output pickles of various structures and leave the comparison to the existing quake code (simple solution) or run the comparison itself and return proper error messages and return codes (preferred solution). Or have I missed something important that makes this approach fail? Of course it will take some time until we've covered all target platforms with out tinderbox setup. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Jan 16 13:59:03 2008 From: rcoleburn at scires.com (Randy Coleburn) Date: Wed, 16 Jan 2008 07:59:03 -0500 Subject: [M3devel] m3tests, pickles In-Reply-To: <200801160845.m0G8jlKE064314@camembert.async.caltech.edu> References: <200801160845.m0G8jlKE064314@camembert.async.caltech.edu> Message-ID: <478DB947.1E75.00D7.1@scires.com> Mika: I've used pickles between various platforms in the past. I use the Pickle2 variant. In my code, I've registered special picklers to deal with mutexes. Since it doesn't make sense to transfer the state of a mutex between computers, I simply recreate/reinitialize the mutex on the receiving computer. Here is an example of an interface and a module that defines a type ServerConfig.T that I transfer between computers using Pickle2 and network objects. I've omitted some of the detail just to show the important stuff about the special pickling definitions and procedures: INTERFACE ServerConfig; CONST Brand = "ServerConfig"; (* prefix for all branded references *) TYPE T <: Public; Public = ConfigSettings.T OBJECT METHODS init (): T; (* initialize to default settings *) ... END; (* Public *) END ServerConfig. MODULE ServerConfig EXPORTS ServerConfig; IMPORT Pickle2 AS Pickle; TYPE PrivateMutex = MUTEX BRANDED Brand & ".PrivateMutex" OBJECT END; REVEAL T = Public BRANDED Brand & ".T" OBJECT mutex: PrivateMutex := NIL; ... METHODS OVERRIDES init := Init; ... END; (* T *) (*-------------------*) (* Pickle Procedures *) (*-------------------*) TYPE Special = Pickle.Special OBJECT OVERRIDES write := WriteSpecial; read := ReadSpecial; END; (* Special *) PROCEDURE WriteSpecial (self: Special; <*UNUSED*>ref: REFANY; <*UNUSED*>writer: Pickle.Writer ) RAISES {Pickle.Error, <*NOWARN*>Wr.Failure, Thread.Alerted} = (* Special pickle writer for ServerConfig.PrivateMutex objects. *) BEGIN (* WriteSpecial *) IF self.sc = TYPECODE(PrivateMutex) THEN (* omit writing the mutex field *) ELSE RAISE Pickle.Error("ServerConfig.WriteSpecial asked to process unrecognized typecode."); (* should never happen *) END; (* if *) END WriteSpecial; PROCEDURE ReadSpecial (self: Special; reader: Pickle.Reader; id: Pickle.RefID ): REFANY RAISES {Pickle.Error, <*NOWARN*>Rd.EndOfFile, Rd.Failure, Thread.Alerted} = (* Special pickle reader for ServerConfig.PrivateMutex objects. *) BEGIN (* ReadSpecial *) IF self.sc = TYPECODE(PrivateMutex) THEN WITH m = NEW(PrivateMutex) DO reader.noteRef(m, id); RETURN m; END; (* with *) ELSE RAISE Pickle.Error("ServerConfig.ReadSpecial asked to process unrecognized typecode."); (* should never happen *) END; (* if *) END ReadSpecial; BEGIN (* ServerConfig module initialization *) Pickle.RegisterSpecial(NEW(Special, sc := TYPECODE(PrivateMutex))); END ServerConfig. Regards, Randy >>> Mika Nystrom 1/16/2008 3:45 AM >>> Can I add something tricky to a wish list on regression testing? Tricky because I don't know the best way to go about it. I have spent quite some time with various versions of Modula-3 tracking down issues with Pickles. Usually the problem is that Pickles aren't transferrable between systems, and it turns out that I have included some type, somewhere, that doesn't translate. MUTEX is a good example. First of all it would be very nice if such system dependencies were kept out (for instance, don't know if it's possible, but something like this...) TYPE RealMutex = OBJECT END; TYPE WinMutex = RealMutex OBJECT (* windows fields *) END; TYPE PosixMutex = RealMutex OBJECT (* POSIX fields *) END; TYPE MUTEX = RealMutex; and of course all that a client sees is MUTEX which is the same across systems. However I realize that what I say above may not be possible or practical in all cases. This brings me to the fact that Pickles are sensitive to certain types of bugs (I think), and it would be very nice to check that all OS/processor builds of M3 make compatible Pickles, with the possible exception of things like MUTEX. Of course this can't be done within a single build... Mika -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcoleburn at scires.com Wed Jan 16 14:25:49 2008 From: rcoleburn at scires.com (Randy Coleburn) Date: Wed, 16 Jan 2008 08:25:49 -0500 Subject: [M3devel] my status on win32 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> <477EA137.1E75.00D7.1@scires.com> <478D394B.1E75.00D7.1@scires.com> <478D47FB.1E75.00D7.1@scires.com> Message-ID: <478DBF8D.1E75.00D7.1@scires.com> Jay: There is no line in the m3makefile dealing with datefn, so I added the whole statement just before the line include("version.quake") Now, I get an error saying that the variable datefn is not defined. If you change to put quotes around datefn in the include statement, you get an error saying it can't open the file. You made a reference in one of your earlier posts about trying 5.1.6 or 4.1, but note that I started with your cm3-min-WIN32-NT386-d5.5.0.zip , not the 5.1.6 or 4.1 versions. Thus, using d5.5.0 as a base, I am trying to run your "upgrade.cmd" to rebuild the sources I checked out from CVS. Since this doesn't work "out-of-the-box", again I say this fits into the "Broken #1" category. If I can get this to work, I don't mind putting together a Windows installer program that will install the whole thing. That way, folks won't have to install cygwin just to get CVS so that they can install a working cm3. Folks will need to install the free Microsoft Visual C as a prerequisite, but then that's not too bad. Having an installer program would make cm3 more friendly to Windows folks. The current 16-step method is too laborious and error-prone for the person just getting started and they will not give cm3 a second try. As the cm3 system evolves and new releases are made, we will need to keep the installer program up-to-date and I don't mind doing that. After someone gets familiar with cm3 they might want to delve into some of the scripts for rebuilding the system, but until then, I think the installer program is the way to go. Regards, Randy >>> Jay 1/16/2008 1:01 AM >>> I think I see the problem. in cm3\src\m3makefile, make this change > if not defined("NOW") include(datefn) > end datefn is only created if certain other variables aren't defined, and do-pkg defines them. I don't know why I don't see this. Later. Could be that the Python scripts have a typo and don't define them. I've been using them more than cmd. If the host is NT, "NOW" is either gotten from an updated cm3.exe, or left to "not available". So the initial cm3 built from older cm3 can't report when it was built, but cm3 built from current cm3 can. I need to change that: 1) to be a function for niceness 2) to make it that way for Posix, for any host but I haven't been using Posix as much lately so not testing it. - Jay Date: Tue, 15 Jan 2008 23:55:39 -0500 From: rcoleburn at scires.com To: m3devel at elegosoft.com; jayk123 at hotmail.com Subject: RE: my status on win32 Jay: In the file version.quake, I made the following edit: changed line: local datefn = "../" & TARGET & ".datenow" to: local datefn = ".." & SL & TARGET & ".datenow" This change has the effect of putting a backward slash in the pathname instead of a forward slash, so we get C:\CM3_CVS_SourceTree\m3-sys\cm3\src\..\NT386.datenow So from that perspective, the change seems good. Unfortunately, I still get the error that this file can't be opened. A quick check of C:\CM3_CVS_SourceTree\m3-sys\cm3\NT386 shows that the file .datenow does not exist. Regards, Randy >>> Jay 1/15/2008 11:03 PM >>> That's not too bad really. 1) I'd recommend putting cm3 at the start of the path instead of the end. 2) Just comment out the offending code to make progress. It's not critical. >> C:\CM3_CVS_SourceTree\m3-sys\cm3\src\../NT386.datenow The code is: C:\CM3_CVS_SourceTree\m3-sys\cm3\src\version.quake or such, included by cm3\src\m3makefile. Does the file exist? Does version.quake use "/" or "SL"? If it uses "/", try replacing with SL (and ampersand for string concat). Could be that a newer binary distributions works better with forward slashes. > 4. > 5. > 6. Launch cygwin from desktop icon. Cygwin is only needed for cvs, I think you realize. Could you send me offline the result of just running "set" after running vcvarsall? I'd like to adapt pylib.py to it maybe. (I can start from 5.1.6 and will try 4.1 at some point.) - Jay Date: Tue, 15 Jan 2008 22:52:59 -0500 From: rcoleburn at scires.com To: m3devel at elegosoft.com; jayk123 at hotmail.com Subject: my status on win32 Jay et al: I've listed below the steps I've undertaken to try and build the current sources on Windows XP. I've also attached a text file showing the output I got when trying to build everything using Jay's upgrade.cmd script. Unfortunately, I'm getting a build error (see below). Please advise on how to resolve. STEPS I TOOK: ========= 1. Download Microsoft Visual Studio 2008 Express Edition All-in-One .ISO file and burn to DVD. http://www.microsoft.com/express/download/ 2. Install Microsoft Visual C++ 2008 Express Edition from DVD. 3. Use "Microsoft Update" service to check for updates / service packs. 4. Download cygwin setup program from http://cygwin.com/ 5. Ran cygwin setup.exe program to install cygwin for all users. Under "Devel" category, make certain to select "cvs" for installation. 6. Launch cygwin from desktop icon. 7. In cygwin command shell window, execute following two commands, making sure to give email as password when prompted for login: cvs -d :pserver:anonymous at modula3.elegosoft.com:/usr/cvs login cvs -d :pserver:anonymous at modula3.elegosoft.com:/usr/cvs checkout cm3 8. Moved resulting C:\cygwin\home\rcoleburn\cm3 to C:\CM3_CVS_SourceTree Note that you should replace "rcoleburn" above with your Windows login username. 9. Download cm3-min-WIN32-NT386-d5.5.0.zip and cm3-min-WIN32-NT386-d5.5.0-symbols.zip from http://modula3.elegosoft.com/cm3/download.html 10. Unzipped cm3-min-WIN32-NT386-d5.5.0.zip and stored resulting cm3 folder at C:\cm3 11. Unzipped cm3-min-WIN32-NT386-d5.5.0-symbols.zip and stored resulting symbols folder at C:\cm3\symbols 12. Launch Windows Command Prompt shell. The following steps represent commands executed within this shell. 13. path %path%;c:\cm3\bin 14. "C:\Program Files\Microsoft Visual Studio 9.0\VC\vcvarsall.bat" 15. cd C:\CM3_CVS_SourceTree\scripts\win 16. upgrade.cmd ERROR I'M GETTING: ============= === package C:\CM3_CVS_SourceTree\m3-sys\cm3 === +++ "cm3 -build -DROOT=C:\\CM3_CVS_SourceTree -DCM3_VERSION_TEXT=d5.5.1 -DCM3_V ERSION_NUMBER=050501 -DCM3_LAST_CHANGED=2007-12-30 && cm3 -ship -DROOT=C:\\CM3_C VS_SourceTree -DCM3_VERSION_TEXT=d5.5.1 -DCM3_VERSION_NUMBER=050501 -DCM3_LAST_C HANGED=2007-12-30" +++ --- building in NT386 --- ignoring ..\src\m3overrides "C:\CM3_CVS_SourceTree\m3-sys\cm3\src\version.quake", line 136: quake runtime er ror: unable to open "C:\CM3_CVS_SourceTree\m3-sys\cm3\src\../NT386.datenow" for reading --procedure-- -line- -file--- include -- version_impl 136 C:\CM3_CVS_SourceTree\m3-sys\cm3\src\version.quake include_dir 20 C:\CM3_CVS_SourceTree\m3-sys\cm3\src\m3makefile 8 C:\CM3_CVS_SourceTree\m3-sys\cm3\NT386\m3make.args Fatal Error: package build failed ERROR: "cm3 -build -DROOT=C:\\CM3_CVS_SourceTree -DCM3_VERSION_TEXT=d5.5.1 -DCM 3_VERSION_NUMBER=050501 -DCM3_LAST_CHANGED=2007-12-30 && cm3 -ship -DROOT=C:\\CM 3_CVS_SourceTree -DCM3_VERSION_TEXT=d5.5.1 -DCM3_VERSION_NUMBER=050501 -DCM3_LAS T_CHANGED=2007-12-30" ERROR: cd C:\CM3_CVS_SourceTree\m3-sys\cm3 ERROR: set INSTALLROOT=c:\cm3 Regards, Randy Share life as it happens with the new Windows Live. Start sharing! ( http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_012008 ) Put your friends on the big screen with Windows Vista* + Windows Live*. Start now! ( http://www.microsoft.com/windows/shop/specialoffers.mspx?ocid=TXT_TAGLM_CPC_MediaCtr_bigscreen_012008 ) -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Wed Jan 16 15:17:16 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 16 Jan 2008 09:17:16 -0500 Subject: [M3devel] m3tests, pickles In-Reply-To: <478DB947.1E75.00D7.1@scires.com> References: <200801160845.m0G8jlKE064314@camembert.async.caltech.edu> <478DB947.1E75.00D7.1@scires.com> Message-ID: <9C071234-4343-4AEB-B4BF-463FEEDFE831@cs.purdue.edu> Perhaps we just need some builtin specials for types like MUTEX that need different handling. Of course, what does it mean to transfer a MUTEX or a thread anyway?! On Jan 16, 2008, at 7:59 AM, Randy Coleburn wrote: > Mika: > > I've used pickles between various platforms in the past. I use the > Pickle2 variant. > > In my code, I've registered special picklers to deal with mutexes. > Since it doesn't make sense to transfer the state of a mutex > between computers, I simply recreate/reinitialize the mutex on the > receiving computer. Here is an example of an interface and a > module that defines a type ServerConfig.T that I transfer between > computers using Pickle2 and network objects. I've omitted some of > the detail just to show the important stuff about the special > pickling definitions and procedures: > > > INTERFACE ServerConfig; > > CONST > Brand = "ServerConfig"; (* prefix for all branded references *) > TYPE > T <: Public; > > Public = ConfigSettings.T OBJECT > METHODS > init (): T; > (* initialize to default settings *) > ... > END; (* Public *) > END ServerConfig. > > > > MODULE ServerConfig EXPORTS ServerConfig; > > IMPORT > Pickle2 AS Pickle; > TYPE > PrivateMutex = MUTEX BRANDED Brand & ".PrivateMutex" OBJECT END; > REVEAL > T = Public BRANDED Brand & ".T" OBJECT > mutex: PrivateMutex := NIL; > ... > METHODS > OVERRIDES > init := Init; > ... > END; (* T *) > > (*-------------------*) > (* Pickle Procedures *) > (*-------------------*) > > TYPE > Special = Pickle.Special OBJECT > OVERRIDES > write := WriteSpecial; > read := ReadSpecial; > END; (* Special *) > > PROCEDURE WriteSpecial (self: Special; > <*UNUSED*>ref: REFANY; > <*UNUSED*>writer: Pickle.Writer > ) > RAISES {Pickle.Error, > <*NOWARN*>Wr.Failure, Thread.Alerted} = > (* Special pickle writer for ServerConfig.PrivateMutex objects. *) > BEGIN (* WriteSpecial *) > IF self.sc = TYPECODE(PrivateMutex) > THEN > (* omit writing the mutex field *) > ELSE > RAISE Pickle.Error("ServerConfig.WriteSpecial asked to > process unrecognized typecode."); (* should never happen *) > END; (* if *) > END WriteSpecial; > > > > PROCEDURE ReadSpecial (self: Special; > reader: Pickle.Reader; > id: Pickle.RefID > ): REFANY > RAISES {Pickle.Error, > <*NOWARN*>Rd.EndOfFile, Rd.Failure, Thread.Alerted} = > (* Special pickle reader for ServerConfig.PrivateMutex objects. *) > BEGIN (* ReadSpecial *) > IF self.sc = TYPECODE(PrivateMutex) > THEN > WITH m = NEW(PrivateMutex) > DO > reader.noteRef(m, id); > RETURN m; > END; (* with *) > ELSE > RAISE Pickle.Error("ServerConfig.ReadSpecial asked to process > unrecognized typecode."); (* should never happen *) > END; (* if *) > END ReadSpecial; > > > > BEGIN (* ServerConfig module initialization *) > Pickle.RegisterSpecial(NEW(Special, sc := TYPECODE(PrivateMutex))); > END ServerConfig. > > Regards, > Randy > > >>> Mika Nystrom 1/16/2008 3:45 AM >>> > > Can I add something tricky to a wish list on regression testing? > Tricky because I don't know the best way to go about it. > > I have spent quite some time with various versions of Modula-3 > tracking down issues with Pickles. Usually the problem is that > Pickles aren't transferrable between systems, and it turns out that > I have included some type, somewhere, that doesn't translate. > MUTEX is a good example. First of all it would be very nice if > such system dependencies were kept out (for instance, don't know > if it's possible, but something like this...) > > TYPE RealMutex = OBJECT END; > > TYPE WinMutex = RealMutex OBJECT (* windows fields *) END; > TYPE PosixMutex = RealMutex OBJECT (* POSIX fields *) END; > > TYPE MUTEX = RealMutex; > > and of course all that a client sees is MUTEX which is the same > across systems. > > However I realize that what I say above may not be possible or > practical in all cases. > > This brings me to the fact that Pickles are sensitive to certain > types of bugs (I think), and it would be very nice to check that > all OS/processor builds of M3 make compatible Pickles, with the > possible exception of things like MUTEX. Of course this can't be > done within a single build... > > Mika > From jayk123 at hotmail.com Wed Jan 16 16:28:52 2008 From: jayk123 at hotmail.com (Jay) Date: Wed, 16 Jan 2008 15:28:52 +0000 Subject: [M3devel] my status on win32 In-Reply-To: <478DBF8D.1E75.00D7.1@scires.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> <477EA137.1E75.00D7.1@scires.com> <478D394B.1E75.00D7.1@scires.com> <478D47FB.1E75.00D7.1@scires.com> <478DBF8D.1E75.00D7.1@scires.com> Message-ID: Randy, yes and no and clarifications. I mention starting with 5.1.6 as a "worst" or "worse" case. The earlier you start, the harder things are -- for me, to ensure it will work. If you merely start with my 5.5.0, well, what are you rebuilding from source for? Heck, you can use any binary distribution, 4.1, 5.1.6, and just use it. They should work. The n steps you/I give are really actually geared for people who WANT to build from source, it is not what people HAVE to do. As well there have been can be source distributions, to cut out CVS. I'll look into the datefn stuff shortly. As to the installer, well, again, yes and no. The need for the installer is very small. All you have to do today is unzip the .zip somewhere and set the path, and possibly the vcvars thing. That's it. I should..now that you are "pressuring" me for ease of use, teach cm3 about the various %devenvdir%, %vcinstalldir% variables, etc. That way as long as the user installed the tools, even if they elected not to change path/lib/include, cm3 can find the compiler and linker. I know everyone wants to preserve the flexibility of quake/cm3.cfg but...besides, cm3 can be pretty darn smart here. IF cm3.cfg defines SYSTEM_CC, leave things along (NT386 cm3.cfg does not today do that). However if there is now SYSTEM_CC and there is no cl.exe/link.exe in %PATH%, it could go on a quick hunt for them. On the lib and include part, well, the dependency on %include% might only be for errno..maybe not worth it. It has been whatever it is forever, like int* _errno(void); #define errno (*_errno)()). Modula-3 engages in rampant header cloning and CErrnoC was only introduced where that was deemed more fragile than usual, and for Windows it probably wasn't actually fragile -- the fragility, if I may be so rudely judgemental, is because so many other systems are so Johnny-come-lately to arriving at the obviously correct threading model that Windows has had all along (since Win95/NT, can't say anything good about Win3.1; I think OS/2 might have had it correct all along too.). Funny, everyone has FINALLY arrived at the correct threading model, only to have start changing again, since the number of cores and machines is set to be much greater than anticipated, the obvious threading model has been deemed too difficult for anyone to use (Win32, Modula-3, Java, .NET, Python, all the same supposedly too difficult model btw), and so some new one is needed, and well, truthfully, the difficulty is not just for dummies on relatively small multiproc boxes not having simple race conditions, the problem is scaling way way up. Sorry that was my usual tangential. Even the unzip and set path would benefit slightly from a GUI installer. I believe there is some easy thing you can do where you write your GUI installer and you put it in the .zip and then you prepend the GUI self extracting .zip/.exe stub, and you can tell it to run a particular command after the extraction. I guess you might use a fancier thing though? That is, are you going to, say, write a gui installer from scratch in Modula-3? It might be a fun exercise. :) And then you could build the self extracting prefix from source etc. This is the hard way I guess, but more interesing. If you can build an msi or use InstallShield or Wix or something, go ahead. If you use widely availabe free as in beer tools, that can be rolled into whatever automation there is to produce distributions, keeping it up to date shouldn't be a problem. I do have to bring up some annoying questions: 1) Does anyone besides me have the capacity to produce distributions? i.e.: Any Win32 machines left at Elego? 2) I know I ramble. So one of my many tangents/questions went unanswered. Say, in the absence of a gui installer, should .zips/.tar.bz files look like cm3-min-/bin/cm3 or bin/cm3 or cm3/bin/cm3 The last one is more directly usable. The first one is very common. This reminds me though Randy, the distribution I made available was "min", so yeah, like if you are doing any gui programming, using any "standard" library besides m3core or libm3, you'd need to build more from source. I can readily provide you a "std" distribution though. It's "always" been a "problem" to make my files available -- no web site hosting for me -- but recently that wasn't a problem, someone picked the files out of ~jkrell on birch and put them on the web site. Good. One more thing -- Olaf, please confirm repeat yourself, 'cause I admit I wasn't sure it was the right thing, but if you insist, ok. "std" should be "all"? I should not continue to imagine there is a new larger group called "all"? And wherever things are missing from std but do build ok, add them? m3cc should be in std? (I admit some big indecisiveness around m3cc. It is far and away the longest thing to build and so the one you really want to skip the most and leave out of whatever package group. I also wonder if on Windows, there should be some check where if sh is not in the $PATH, just silently skip m3cc? You only need MingWin to build what I have on my system for NT386GNU, except you also need msys just for m3cc. msys is actually quite small, like only 20 files..) Oh, sorry, yet another question. The non-gcc backend is excluded from the build on systems that use the gcc backend. For minimization, that is appropriate. For maximizing cross build capability, it is wrong. The packages build fine. I suspect they work. I am not a user of cross build capability yet, so I don't really care. (What I do for NT386/NT386GNU /might/ be considered sort of a cross build, but it is different/easier). They are small packages. - Jay Date: Wed, 16 Jan 2008 08:25:49 -0500From: rcoleburn at scires.comTo: m3devel at elegosoft.com; jayk123 at hotmail.comSubject: Re: [M3devel] my status on win32 Jay: There is no line in the m3makefile dealing with datefn, so I added the whole statement just before the line include("version.quake") Now, I get an error saying that the variable datefn is not defined. If you change to put quotes around datefn in the include statement, you get an error saying it can't open the file. You made a reference in one of your earlier posts about trying 5.1.6 or 4.1, but note that I started with your cm3-min-WIN32-NT386-d5.5.0.zip , not the 5.1.6 or 4.1 versions. Thus, using d5.5.0 as a base, I am trying to run your "upgrade.cmd" to rebuild the sources I checked out from CVS. Since this doesn't work "out-of-the-box", again I say this fits into the "Broken #1" category. If I can get this to work, I don't mind putting together a Windows installer program that will install the whole thing. That way, folks won't have to install cygwin just to get CVS so that they can install a working cm3. Folks will need to install the free Microsoft Visual C as a prerequisite, but then that's not too bad. Having an installer program would make cm3 more friendly to Windows folks. The current 16-step method is too laborious and error-prone for the person just getting started and they will not give cm3 a second try. As the cm3 system evolves and new releases are made, we will need to keep the installer program up-to-date and I don't mind doing that. After someone gets familiar with cm3 they might want to delve into some of the scripts for rebuilding the system, but until then, I think the installer program is the way to go. Regards, Randy>>> Jay 1/16/2008 1:01 AM >>>I think I see the problem. in cm3\src\m3makefile, make this change > if not defined("NOW") include(datefn) > end datefn is only created if certain other variables aren't defined, and do-pkg defines them.I don't know why I don't see this. Later.Could be that the Python scripts have a typo and don't define them.I've been using them more than cmd. If the host is NT, "NOW" is either gotten from an updated cm3.exe, or left to "not available". So the initial cm3 built from older cm3 can't report when it was built, but cm3 built from current cm3 can. I need to change that: 1) to be a function for niceness 2) to make it that way for Posix, for any host but I haven't been using Posix as much lately so not testing it. - Jay Date: Tue, 15 Jan 2008 23:55:39 -0500From: rcoleburn at scires.comTo: m3devel at elegosoft.com; jayk123 at hotmail.comSubject: RE: my status on win32 Jay: In the file version.quake, I made the following edit: changed line: local datefn = "../" & TARGET & ".datenow" to: local datefn = ".." & SL & TARGET & ".datenow" This change has the effect of putting a backward slash in the pathname instead of a forward slash, so we getC:\CM3_CVS_SourceTree\m3-sys\cm3\src\..\NT386.datenow So from that perspective, the change seems good. Unfortunately, I still get the error that this file can't be opened. A quick check of C:\CM3_CVS_SourceTree\m3-sys\cm3\NT386 shows that the file .datenow does not exist. Regards, Randy>>> Jay 1/15/2008 11:03 PM >>>That's not too bad really. 1) I'd recommend putting cm3 at the start of the path instead of the end. 2) Just comment out the offending code to make progress. It's not critical. >> C:\CM3_CVS_SourceTree\m3-sys\cm3\src\../NT386.datenow The code is: C:\CM3_CVS_SourceTree\m3-sys\cm3\src\version.quake or such, included by cm3\src\m3makefile. Does the file exist?Does version.quake use "/" or "SL"? If it uses "/", try replacing with SL (and ampersand for string concat). Could be that a newer binary distributions works better with forward slashes. > 4. > 5. > 6. Launch cygwin from desktop icon. Cygwin is only needed for cvs, I think you realize. Could you send me offline the result of just running "set" after running vcvarsall? I'd like to adapt pylib.py to it maybe. (I can start from 5.1.6 and will try 4.1 at some point.) - Jay Date: Tue, 15 Jan 2008 22:52:59 -0500From: rcoleburn at scires.comTo: m3devel at elegosoft.com; jayk123 at hotmail.comSubject: my status on win32 Jay et al: I've listed below the steps I've undertaken to try and build the current sources on Windows XP. I've also attached a text file showing the output I got when trying to build everything using Jay's upgrade.cmd script. Unfortunately, I'm getting a build error (see below). Please advise on how to resolve. STEPS I TOOK: ========= 1. Download Microsoft Visual Studio 2008 Express Edition All-in-One .ISO file and burn to DVD. http://www.microsoft.com/express/download/ 2. Install Microsoft Visual C++ 2008 Express Edition from DVD. 3. Use "Microsoft Update" service to check for updates / service packs. 4. Download cygwin setup program from http://cygwin.com/ 5. Ran cygwin setup.exe program to install cygwin for all users. Under "Devel" category, make certain to select "cvs" for installation. 6. Launch cygwin from desktop icon. 7. In cygwin command shell window, execute following two commands, making sure to give email as password when prompted for login: cvs -d :pserver:anonymous at modula3.elegosoft.com:/usr/cvs login cvs -d :pserver:anonymous at modula3.elegosoft.com:/usr/cvs checkout cm3 8. Moved resulting C:\cygwin\home\rcoleburn\cm3 to C:\CM3_CVS_SourceTree Note that you should replace "rcoleburn" above with your Windows login username. 9. Download cm3-min-WIN32-NT386-d5.5.0.zip and cm3-min-WIN32-NT386-d5.5.0-symbols.zip from http://modula3.elegosoft.com/cm3/download.html 10. Unzipped cm3-min-WIN32-NT386-d5.5.0.zip and stored resulting cm3 folder at C:\cm3 11. Unzipped cm3-min-WIN32-NT386-d5.5.0-symbols.zip and stored resulting symbols folder at C:\cm3\symbols 12. Launch Windows Command Prompt shell. The following steps represent commands executed within this shell. 13. path %path%;c:\cm3\bin 14. "C:\Program Files\Microsoft Visual Studio 9.0\VC\vcvarsall.bat" 15. cd C:\CM3_CVS_SourceTree\scripts\win 16. upgrade.cmd ERROR I'M GETTING: ============= === package C:\CM3_CVS_SourceTree\m3-sys\cm3 ===+++ "cm3 -build -DROOT=C:\\CM3_CVS_SourceTree -DCM3_VERSION_TEXT=d5.5.1 -DCM3_VERSION_NUMBER=050501 -DCM3_LAST_CHANGED=2007-12-30 && cm3 -ship -DROOT=C:\\CM3_CVS_SourceTree -DCM3_VERSION_TEXT=d5.5.1 -DCM3_VERSION_NUMBER=050501 -DCM3_LAST_CHANGED=2007-12-30" +++--- building in NT386 --- ignoring ..\src\m3overrides "C:\CM3_CVS_SourceTree\m3-sys\cm3\src\version.quake", line 136: quake runtime error: unable to open "C:\CM3_CVS_SourceTree\m3-sys\cm3\src\../NT386.datenow" forreading --procedure-- -line- -file---include -- version_impl 136 C:\CM3_CVS_SourceTree\m3-sys\cm3\src\version.quakeinclude_dir 20 C:\CM3_CVS_SourceTree\m3-sys\cm3\src\m3makefile 8 C:\CM3_CVS_SourceTree\m3-sys\cm3\NT386\m3make.args Fatal Error: package build failedERROR: "cm3 -build -DROOT=C:\\CM3_CVS_SourceTree -DCM3_VERSION_TEXT=d5.5.1 -DCM3_VERSION_NUMBER=050501 -DCM3_LAST_CHANGED=2007-12-30 && cm3 -ship -DROOT=C:\\CM3_CVS_SourceTree -DCM3_VERSION_TEXT=d5.5.1 -DCM3_VERSION_NUMBER=050501 -DCM3_LAST_CHANGED=2007-12-30"ERROR: cd C:\CM3_CVS_SourceTree\m3-sys\cm3ERROR: set INSTALLROOT=c:\cm3 Regards, Randy Share life as it happens with the new Windows Live. Start sharing! Put your friends on the big screen with Windows Vista? + Windows LiveT. Start now! _________________________________________________________________ Get the power of Windows + Web with the new Windows Live. http://www.windowslive.com?ocid=TXT_TAGHM_Wave2_powerofwindows_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Wed Jan 16 16:29:32 2008 From: jayk123 at hotmail.com (Jay) Date: Wed, 16 Jan 2008 15:29:32 +0000 Subject: [M3devel] my status on win32 In-Reply-To: <478DBF8D.1E75.00D7.1@scires.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> <477EA137.1E75.00D7.1@scires.com> <478D394B.1E75.00D7.1@scires.com> <478D47FB.1E75.00D7.1@scires.com> <478DBF8D.1E75.00D7.1@scires.com> Message-ID: Yes I agree it is "broken #1" and shouldn't be this way, but I assure you, really, your results are 99% there. What isn't working is minor and easy to fix and much is working. - Jay Date: Wed, 16 Jan 2008 08:25:49 -0500From: rcoleburn at scires.comTo: m3devel at elegosoft.com; jayk123 at hotmail.comSubject: Re: [M3devel] my status on win32 Jay: There is no line in the m3makefile dealing with datefn, so I added the whole statement just before the line include("version.quake") Now, I get an error saying that the variable datefn is not defined. If you change to put quotes around datefn in the include statement, you get an error saying it can't open the file. You made a reference in one of your earlier posts about trying 5.1.6 or 4.1, but note that I started with your cm3-min-WIN32-NT386-d5.5.0.zip , not the 5.1.6 or 4.1 versions. Thus, using d5.5.0 as a base, I am trying to run your "upgrade.cmd" to rebuild the sources I checked out from CVS. Since this doesn't work "out-of-the-box", again I say this fits into the "Broken #1" category. If I can get this to work, I don't mind putting together a Windows installer program that will install the whole thing. That way, folks won't have to install cygwin just to get CVS so that they can install a working cm3. Folks will need to install the free Microsoft Visual C as a prerequisite, but then that's not too bad. Having an installer program would make cm3 more friendly to Windows folks. The current 16-step method is too laborious and error-prone for the person just getting started and they will not give cm3 a second try. As the cm3 system evolves and new releases are made, we will need to keep the installer program up-to-date and I don't mind doing that. After someone gets familiar with cm3 they might want to delve into some of the scripts for rebuilding the system, but until then, I think the installer program is the way to go. Regards, Randy>>> Jay 1/16/2008 1:01 AM >>>I think I see the problem. in cm3\src\m3makefile, make this change > if not defined("NOW") include(datefn) > end datefn is only created if certain other variables aren't defined, and do-pkg defines them.I don't know why I don't see this. Later.Could be that the Python scripts have a typo and don't define them.I've been using them more than cmd. If the host is NT, "NOW" is either gotten from an updated cm3.exe, or left to "not available". So the initial cm3 built from older cm3 can't report when it was built, but cm3 built from current cm3 can. I need to change that: 1) to be a function for niceness 2) to make it that way for Posix, for any host but I haven't been using Posix as much lately so not testing it. - Jay Date: Tue, 15 Jan 2008 23:55:39 -0500From: rcoleburn at scires.comTo: m3devel at elegosoft.com; jayk123 at hotmail.comSubject: RE: my status on win32 Jay: In the file version.quake, I made the following edit: changed line: local datefn = "../" & TARGET & ".datenow" to: local datefn = ".." & SL & TARGET & ".datenow" This change has the effect of putting a backward slash in the pathname instead of a forward slash, so we getC:\CM3_CVS_SourceTree\m3-sys\cm3\src\..\NT386.datenow So from that perspective, the change seems good. Unfortunately, I still get the error that this file can't be opened. A quick check of C:\CM3_CVS_SourceTree\m3-sys\cm3\NT386 shows that the file .datenow does not exist. Regards, Randy>>> Jay 1/15/2008 11:03 PM >>>That's not too bad really. 1) I'd recommend putting cm3 at the start of the path instead of the end. 2) Just comment out the offending code to make progress. It's not critical. >> C:\CM3_CVS_SourceTree\m3-sys\cm3\src\../NT386.datenow The code is: C:\CM3_CVS_SourceTree\m3-sys\cm3\src\version.quake or such, included by cm3\src\m3makefile. Does the file exist?Does version.quake use "/" or "SL"? If it uses "/", try replacing with SL (and ampersand for string concat). Could be that a newer binary distributions works better with forward slashes. > 4. > 5. > 6. Launch cygwin from desktop icon. Cygwin is only needed for cvs, I think you realize. Could you send me offline the result of just running "set" after running vcvarsall? I'd like to adapt pylib.py to it maybe. (I can start from 5.1.6 and will try 4.1 at some point.) - Jay Date: Tue, 15 Jan 2008 22:52:59 -0500From: rcoleburn at scires.comTo: m3devel at elegosoft.com; jayk123 at hotmail.comSubject: my status on win32 Jay et al: I've listed below the steps I've undertaken to try and build the current sources on Windows XP. I've also attached a text file showing the output I got when trying to build everything using Jay's upgrade.cmd script. Unfortunately, I'm getting a build error (see below). Please advise on how to resolve. STEPS I TOOK: ========= 1. Download Microsoft Visual Studio 2008 Express Edition All-in-One .ISO file and burn to DVD. http://www.microsoft.com/express/download/ 2. Install Microsoft Visual C++ 2008 Express Edition from DVD. 3. Use "Microsoft Update" service to check for updates / service packs. 4. Download cygwin setup program from http://cygwin.com/ 5. Ran cygwin setup.exe program to install cygwin for all users. Under "Devel" category, make certain to select "cvs" for installation. 6. Launch cygwin from desktop icon. 7. In cygwin command shell window, execute following two commands, making sure to give email as password when prompted for login: cvs -d :pserver:anonymous at modula3.elegosoft.com:/usr/cvs login cvs -d :pserver:anonymous at modula3.elegosoft.com:/usr/cvs checkout cm3 8. Moved resulting C:\cygwin\home\rcoleburn\cm3 to C:\CM3_CVS_SourceTree Note that you should replace "rcoleburn" above with your Windows login username. 9. Download cm3-min-WIN32-NT386-d5.5.0.zip and cm3-min-WIN32-NT386-d5.5.0-symbols.zip from http://modula3.elegosoft.com/cm3/download.html 10. Unzipped cm3-min-WIN32-NT386-d5.5.0.zip and stored resulting cm3 folder at C:\cm3 11. Unzipped cm3-min-WIN32-NT386-d5.5.0-symbols.zip and stored resulting symbols folder at C:\cm3\symbols 12. Launch Windows Command Prompt shell. The following steps represent commands executed within this shell. 13. path %path%;c:\cm3\bin 14. "C:\Program Files\Microsoft Visual Studio 9.0\VC\vcvarsall.bat" 15. cd C:\CM3_CVS_SourceTree\scripts\win 16. upgrade.cmd ERROR I'M GETTING: ============= === package C:\CM3_CVS_SourceTree\m3-sys\cm3 ===+++ "cm3 -build -DROOT=C:\\CM3_CVS_SourceTree -DCM3_VERSION_TEXT=d5.5.1 -DCM3_VERSION_NUMBER=050501 -DCM3_LAST_CHANGED=2007-12-30 && cm3 -ship -DROOT=C:\\CM3_CVS_SourceTree -DCM3_VERSION_TEXT=d5.5.1 -DCM3_VERSION_NUMBER=050501 -DCM3_LAST_CHANGED=2007-12-30" +++--- building in NT386 --- ignoring ..\src\m3overrides "C:\CM3_CVS_SourceTree\m3-sys\cm3\src\version.quake", line 136: quake runtime error: unable to open "C:\CM3_CVS_SourceTree\m3-sys\cm3\src\../NT386.datenow" forreading --procedure-- -line- -file---include -- version_impl 136 C:\CM3_CVS_SourceTree\m3-sys\cm3\src\version.quakeinclude_dir 20 C:\CM3_CVS_SourceTree\m3-sys\cm3\src\m3makefile 8 C:\CM3_CVS_SourceTree\m3-sys\cm3\NT386\m3make.args Fatal Error: package build failedERROR: "cm3 -build -DROOT=C:\\CM3_CVS_SourceTree -DCM3_VERSION_TEXT=d5.5.1 -DCM3_VERSION_NUMBER=050501 -DCM3_LAST_CHANGED=2007-12-30 && cm3 -ship -DROOT=C:\\CM3_CVS_SourceTree -DCM3_VERSION_TEXT=d5.5.1 -DCM3_VERSION_NUMBER=050501 -DCM3_LAST_CHANGED=2007-12-30"ERROR: cd C:\CM3_CVS_SourceTree\m3-sys\cm3ERROR: set INSTALLROOT=c:\cm3 Regards, Randy Share life as it happens with the new Windows Live. Start sharing! Put your friends on the big screen with Windows Vista? + Windows LiveT. Start now! _________________________________________________________________ Watch ?Cause Effect,? a show about real people making a real difference. http://im.live.com/Messenger/IM/MTV/?source=text_watchcause -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcoleburn at scires.com Wed Jan 16 17:24:34 2008 From: rcoleburn at scires.com (Randy Coleburn) Date: Wed, 16 Jan 2008 11:24:34 -0500 Subject: [M3devel] my status on win32 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> <477EA137.1E75.00D7.1@scires.com> <478D394B.1E75.00D7.1@scires.com> <478D47FB.1E75.00D7.1@scires.com> <478DBF8D.1E75.00D7.1@scires.com> Message-ID: <478DE973.1E75.00D7.1@scires.com> Jay: Not sure I've clued in to all of your dialog. Sorry. I have in the past used a free tool to build an installer package and I was thinking of using it again. Since the tool is free, we could put all the work I do into the CVS repository so that others could also maintain it. What I am looking to achieve is to have a way where a "normal" Windows user could download a program, run it, and have all of the cm3 packages installed without having to use the MIN distribution to build it up or any other tools to get the sources (like cvs). You could achieve the same thing by having a big ZIP file also I suppose, but having the installer would also let us easily put something in the start menu to launch a command line with all the environment variables set properly via automatic call to vcvars et al. When I get "Reactor" working, it too could be put into the start menu. That just makes it fit in better with the Windows user culture I think. The reason I wanted to rebuild everything is two-fold: 1) ensure it can be done (i.e., test for "Broken #1"), and 2) get all of the rest of the packages built so I could then use cm3 to build "reactor" and my own programs and test them to see if there are any "Broken #2" issues. The MIN distribution is really insufficient to do much of anything except to build the rest of the packages you need. My understanding is that I needed to use CVS to get the current sources, because if I went back to the source archive, it was old and known to be Broken #1 on Windows. I'm glad that you believe the current "Broken #1" situation is easy to fix. Let me know what to do and I'll give it another try. My experience in the past has been that there are 3 conditions to getting cm3 to work properly on windows after it has been installed: 1) make sure your environment variables are set up by vcvars to point to the compiler/linker/libraries (of course if you used a non-Microsoft C compiler/linker you would need to use something other than vcvars); 2) make sure cm3.cfg has the right paths in place to find all the libraries and tools using DOS style short names (no embedded spaces); and 3) make sure C:\cm3\bin is in your path. Of these, #2 & #3 are essentially one-time events, and #1 can be set up by a invoking a batch/command file via a shortcut, so no big deal for me. You could even make #1 a one-time event by modifying the system-level (vice user-level) environment variables. The old cm3install program seemed to do a decent job of #2 for me. Also, I've noted some of your past dialog about accepting either '/' or '\' as a path separator. I'm sure you are aware that on Windows '/' is used often for switches (arguments). Plus Windows also allows spaces to be embedded in the command line, so whatever solution you propose needs to take into account that a valid command line might look like this: C:\My Program Folder\My Program.exe /myArg1 /myArg2 In some situations, this command line would have to be quoted and rendered as: "C:\My Program Folder\My Program.exe" /myArg1 /myArg2 and in places where the backslash is an escape character, I've seen "C:\\My Program Folder\\My Program.exe" /myArg1 /myArg2 Alas, I seem to have rambled a bit also. Sorry. The immediate need for me now is to solve the Broken #1 condition, so please let me know how to fix it and proceed. Regards, Randy >>> Jay 1/16/2008 10:28 AM >>> Randy, yes and no and clarifications. I mention starting with 5.1.6 as a "worst" or "worse" case. The earlier you start, the harder things are -- for me, to ensure it will work. If you merely start with my 5.5.0, well, what are you rebuilding from source for? Heck, you can use any binary distribution, 4.1, 5.1.6, and just use it. They should work. The n steps you/I give are really actually geared for people who WANT to build from source, it is not what people HAVE to do. As well there have been can be source distributions, to cut out CVS. I'll look into the datefn stuff shortly. As to the installer, well, again, yes and no. The need for the installer is very small. All you have to do today is unzip the .zip somewhere and set the path, and possibly the vcvars thing. That's it. I should..now that you are "pressuring" me for ease of use, teach cm3 about the various %devenvdir%, %vcinstalldir% variables, etc. That way as long as the user installed the tools, even if they elected not to change path/lib/include, cm3 can find the compiler and linker. I know everyone wants to preserve the flexibility of quake/cm3.cfg but...besides, cm3 can be pretty darn smart here. IF cm3.cfg defines SYSTEM_CC, leave things along (NT386 cm3.cfg does not today do that). However if there is now SYSTEM_CC and there is no cl.exe/link.exe in %PATH%, it could go on a quick hunt for them. On the lib and include part, well, the dependency on %include% might only be for errno..maybe not worth it. It has been whatever it is forever, like int* _errno(void); #define errno (*_errno)()). Modula-3 engages in rampant header cloning and CErrnoC was only introduced where that was deemed more fragile than usual, and for Windows it probably wasn't actually fragile -- the fragility, if I may be so rudely judgemental, is because so many other systems are so Johnny-come-lately to arriving at the obviously correct threading model that Windows has had all along (since Win95/NT, can't say anything good about Win3.1; I think OS/2 might have had it correct all along too.). Funny, everyone has FINALLY arrived at the correct threading model, only to have start changing again, since the number of cores and machines is set to be much greater than anticipated, the obvious threading model has been deemed too difficult for anyone to use (Win32, Modula-3, Java, .NET, Python, all the same supposedly too difficult model btw), and so some new one is needed, and well, truthfully, the difficulty is not just for dummies on relatively small multiproc boxes not having simple race conditions, the problem is scaling way way up. Sorry that was my usual tangential. Even the unzip and set path would benefit slightly from a GUI installer. I believe there is some easy thing you can do where you write your GUI installer and you put it in the .zip and then you prepend the GUI self extracting .zip/.exe stub, and you can tell it to run a particular command after the extraction. I guess you might use a fancier thing though? That is, are you going to, say, write a gui installer from scratch in Modula-3? It might be a fun exercise. :) And then you could build the self extracting prefix from source etc. This is the hard way I guess, but more interesing. If you can build an msi or use InstallShield or Wix or something, go ahead. If you use widely availabe free as in beer tools, that can be rolled into whatever automation there is to produce distributions, keeping it up to date shouldn't be a problem. I do have to bring up some annoying questions: 1) Does anyone besides me have the capacity to produce distributions? i.e.: Any Win32 machines left at Elego? 2) I know I ramble. So one of my many tangents/questions went unanswered. Say, in the absence of a gui installer, should .zips/.tar.bz files look like cm3-min-/bin/cm3 or bin/cm3 or cm3/bin/cm3 The last one is more directly usable. The first one is very common. This reminds me though Randy, the distribution I made available was "min", so yeah, like if you are doing any gui programming, using any "standard" library besides m3core or libm3, you'd need to build more from source. I can readily provide you a "std" distribution though. It's "always" been a "problem" to make my files available -- no web site hosting for me -- but recently that wasn't a problem, someone picked the files out of ~jkrell on birch and put them on the web site. Good. One more thing -- Olaf, please confirm repeat yourself, 'cause I admit I wasn't sure it was the right thing, but if you insist, ok. "std" should be "all"? I should not continue to imagine there is a new larger group called "all"? And wherever things are missing from std but do build ok, add them? m3cc should be in std? (I admit some big indecisiveness around m3cc. It is far and away the longest thing to build and so the one you really want to skip the most and leave out of whatever package group. I also wonder if on Windows, there should be some check where if sh is not in the $PATH, just silently skip m3cc? You only need MingWin to build what I have on my system for NT386GNU, except you also need msys just for m3cc. msys is actually quite small, like only 20 files..) Oh, sorry, yet another question. The non-gcc backend is excluded from the build on systems that use the gcc backend. For minimization, that is appropriate. For maximizing cross build capability, it is wrong. The packages build fine. I suspect they work. I am not a user of cross build capability yet, so I don't really care. (What I do for NT386/NT386GNU /might/ be considered sort of a cross build, but it is different/easier). They are small packages. - Jay Date: Wed, 16 Jan 2008 08:25:49 -0500 From: rcoleburn at scires.com To: m3devel at elegosoft.com; jayk123 at hotmail.com Subject: Re: [M3devel] my status on win32 Jay: There is no line in the m3makefile dealing with datefn, so I added the whole statement just before the line include("version.quake") Now, I get an error saying that the variable datefn is not defined. If you change to put quotes around datefn in the include statement, you get an error saying it can't open the file. You made a reference in one of your earlier posts about trying 5.1.6 or 4.1, but note that I started with your cm3-min-WIN32-NT386-d5.5.0.zip , not the 5.1.6 or 4.1 versions. Thus, using d5.5.0 as a base, I am trying to run your "upgrade.cmd" to rebuild the sources I checked out from CVS. Since this doesn't work "out-of-the-box", again I say this fits into the "Broken #1" category. If I can get this to work, I don't mind putting together a Windows installer program that will install the whole thing. That way, folks won't have to install cygwin just to get CVS so that they can install a working cm3. Folks will need to install the free Microsoft Visual C as a prerequisite, but then that's not too bad. Having an installer program would make cm3 more friendly to Windows folks. The current 16-step method is too laborious and error-prone for the person just getting started and they will not give cm3 a second try. As the cm3 system evolves and new releases are made, we will need to keep the installer program up-to-date and I don't mind doing that. After someone gets familiar with cm3 they might want to delve into some of the scripts for rebuilding the system, but until then, I think the installer program is the way to go. Regards, Randy >>> Jay 1/16/2008 1:01 AM >>> I think I see the problem. in cm3\src\m3makefile, make this change > if not defined("NOW") include(datefn) > end datefn is only created if certain other variables aren't defined, and do-pkg defines them. I don't know why I don't see this. Later. Could be that the Python scripts have a typo and don't define them. I've been using them more than cmd. If the host is NT, "NOW" is either gotten from an updated cm3.exe, or left to "not available". So the initial cm3 built from older cm3 can't report when it was built, but cm3 built from current cm3 can. I need to change that: 1) to be a function for niceness 2) to make it that way for Posix, for any host but I haven't been using Posix as much lately so not testing it. - Jay Date: Tue, 15 Jan 2008 23:55:39 -0500 From: rcoleburn at scires.com To: m3devel at elegosoft.com; jayk123 at hotmail.com Subject: RE: my status on win32 Jay: In the file version.quake, I made the following edit: changed line: local datefn = "../" & TARGET & ".datenow" to: local datefn = ".." & SL & TARGET & ".datenow" This change has the effect of putting a backward slash in the pathname instead of a forward slash, so we get C:\CM3_CVS_SourceTree\m3-sys\cm3\src\..\NT386.datenow So from that perspective, the change seems good. Unfortunately, I still get the error that this file can't be opened. A quick check of C:\CM3_CVS_SourceTree\m3-sys\cm3\NT386 shows that the file .datenow does not exist. Regards, Randy >>> Jay 1/15/2008 11:03 PM >>> That's not too bad really. 1) I'd recommend putting cm3 at the start of the path instead of the end. 2) Just comment out the offending code to make progress. It's not critical. >> C:\CM3_CVS_SourceTree\m3-sys\cm3\src\../NT386.datenow The code is: C:\CM3_CVS_SourceTree\m3-sys\cm3\src\version.quake or such, included by cm3\src\m3makefile. Does the file exist? Does version.quake use "/" or "SL"? If it uses "/", try replacing with SL (and ampersand for string concat). Could be that a newer binary distributions works better with forward slashes. > 4. > 5. > 6. Launch cygwin from desktop icon. Cygwin is only needed for cvs, I think you realize. Could you send me offline the result of just running "set" after running vcvarsall? I'd like to adapt pylib.py to it maybe. (I can start from 5.1.6 and will try 4.1 at some point.) - Jay Date: Tue, 15 Jan 2008 22:52:59 -0500 From: rcoleburn at scires.com To: m3devel at elegosoft.com; jayk123 at hotmail.com Subject: my status on win32 Jay et al: I've listed below the steps I've undertaken to try and build the current sources on Windows XP. I've also attached a text file showing the output I got when trying to build everything using Jay's upgrade.cmd script. Unfortunately, I'm getting a build error (see below). Please advise on how to resolve. STEPS I TOOK: ========= 1. Download Microsoft Visual Studio 2008 Express Edition All-in-One .ISO file and burn to DVD. http://www.microsoft.com/express/download/ 2. Install Microsoft Visual C++ 2008 Express Edition from DVD. 3. Use "Microsoft Update" service to check for updates / service packs. 4. Download cygwin setup program from http://cygwin.com/ 5. Ran cygwin setup.exe program to install cygwin for all users. Under "Devel" category, make certain to select "cvs" for installation. 6. Launch cygwin from desktop icon. 7. In cygwin command shell window, execute following two commands, making sure to give email as password when prompted for login: cvs -d :pserver:anonymous at modula3.elegosoft.com:/usr/cvs login cvs -d :pserver:anonymous at modula3.elegosoft.com:/usr/cvs checkout cm3 8. Moved resulting C:\cygwin\home\rcoleburn\cm3 to C:\CM3_CVS_SourceTree Note that you should replace "rcoleburn" above with your Windows login username. 9. Download cm3-min-WIN32-NT386-d5.5.0.zip and cm3-min-WIN32-NT386-d5.5.0-symbols.zip from http://modula3.elegosoft.com/cm3/download.html 10. Unzipped cm3-min-WIN32-NT386-d5.5.0.zip and stored resulting cm3 folder at C:\cm3 11. Unzipped cm3-min-WIN32-NT386-d5.5.0-symbols.zip and stored resulting symbols folder at C:\cm3\symbols 12. Launch Windows Command Prompt shell. The following steps represent commands executed within this shell. 13. path %path%;c:\cm3\bin 14. "C:\Program Files\Microsoft Visual Studio 9.0\VC\vcvarsall.bat" 15. cd C:\CM3_CVS_SourceTree\scripts\win 16. upgrade.cmd ERROR I'M GETTING: ============= === package C:\CM3_CVS_SourceTree\m3-sys\cm3 === +++ "cm3 -build -DROOT=C:\\CM3_CVS_SourceTree -DCM3_VERSION_TEXT=d5.5.1 -DCM3_V ERSION_NUMBER=050501 -DCM3_LAST_CHANGED=2007-12-30 && cm3 -ship -DROOT=C:\\CM3_C VS_SourceTree -DCM3_VERSION_TEXT=d5.5.1 -DCM3_VERSION_NUMBER=050501 -DCM3_LAST_C HANGED=2007-12-30" +++ --- building in NT386 --- ignoring ..\src\m3overrides "C:\CM3_CVS_SourceTree\m3-sys\cm3\src\version.quake", line 136: quake runtime er ror: unable to open "C:\CM3_CVS_SourceTree\m3-sys\cm3\src\../NT386.datenow" for reading --procedure-- -line- -file--- include -- version_impl 136 C:\CM3_CVS_SourceTree\m3-sys\cm3\src\version.quake include_dir 20 C:\CM3_CVS_SourceTree\m3-sys\cm3\src\m3makefile 8 C:\CM3_CVS_SourceTree\m3-sys\cm3\NT386\m3make.args Fatal Error: package build failed ERROR: "cm3 -build -DROOT=C:\\CM3_CVS_SourceTree -DCM3_VERSION_TEXT=d5.5.1 -DCM 3_VERSION_NUMBER=050501 -DCM3_LAST_CHANGED=2007-12-30 && cm3 -ship -DROOT=C:\\CM 3_CVS_SourceTree -DCM3_VERSION_TEXT=d5.5.1 -DCM3_VERSION_NUMBER=050501 -DCM3_LAS T_CHANGED=2007-12-30" ERROR: cd C:\CM3_CVS_SourceTree\m3-sys\cm3 ERROR: set INSTALLROOT=c:\cm3 Regards, Randy Share life as it happens with the new Windows Live. Start sharing! ( http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_012008 ) Put your friends on the big screen with Windows Vista* + Windows LiveT. Start now! ( http://www.microsoft.com/windows/shop/specialoffers.mspx?ocid=TXT_TAGLM_CPC_MediaCtr_bigscreen_012008 ) Get the power of Windows + Web with the new Windows Live. Get it now! ( http://www.windowslive.com/?ocid=TXT_TAGHM_Wave2_powerofwindows_012008 ) -------------- next part -------------- An HTML attachment was scrubbed... URL: From darko at darko.org Wed Jan 16 19:28:48 2008 From: darko at darko.org (Darko) Date: Wed, 16 Jan 2008 10:28:48 -0800 Subject: [M3devel] GC question version 2 Message-ID: Ok, a slightly different approach: Can the GC give me a list of all the objects that contain a reference to an object? Would it be thorough (ie not miss any objects)? False positives might be ok. Then I could check the type of each object and update the references myself. It would be reasonable to assume that the references in question were not being changed by any thread during the checking process. Thanks, Darko. From jayk123 at hotmail.com Wed Jan 16 20:13:21 2008 From: jayk123 at hotmail.com (Jay) Date: Wed, 16 Jan 2008 19:13:21 +0000 Subject: [M3devel] my status on win32 In-Reply-To: <478DE973.1E75.00D7.1@scires.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> <477EA137.1E75.00D7.1@scires.com> <478D394B.1E75.00D7.1@scires.com> <478D47FB.1E75.00D7.1@scires.com> <478DBF8D.1E75.00D7.1@scires.com> <478DE973.1E75.00D7.1@scires.com> Message-ID: Hi Randy. I mostly agree and understand. Go ahead with your installer work. :) #2 is no longer needed. The cm3.cfg I use, that is checked in, that is in the newer distributions, just runs plain "cl" and links to plain "kernel32.dll", and doesn't pass any /I switches to cl => therefore it depends on %PATH%, %LIB%, and %INCLUDE%. As I was saying/rambling, we/I can probably teach cm3 a bit so as to not need vcvars. As I recall, but I need to check, when you install VC, there are some variables it sets unconditionally, and some it asks the user if they should be set. The ones it asks about are PATH, LIB, INCLUDE. The ones it sets unconditionally are the "root" of the install. PATH / LIB / INCLUDE are more invasive, more impactful, have more potential to break things. They are also easily derived from the "root". Similarly, the CM3 installer could ask the user if it is ok to modify their %PATH%, and do it in the registry and set the WM_INI_CHANGED or such message so that Explorer picks it up. Need to check MSDN on this. Forward slashes are fine for options. I take a dim view of these space, quoting, escaping issues. I have very mixed experience here. In SOME situations, your command lines pass through various layers of code, with various attempts to handle or ignore the various issues. The result is in my opinion an unpredictable mess. The problem is that people have confused "an array of strings" with "one flat string". At this point the confusion is widespread and deeply ingrained. On Unix I believe people just ignore the issue by not using spaces (or quotes?) on the command line, though escaping issues still remain for other characters. You just have to read the documenation on CreateProcess to realize how messed up this is. c:\program files\foo I believe is interpreted multiple ways until something works. It can be running c:\program with the parameter files\foo, or it can be running c:\program files\foo. Reliable interprocess communication should not be via command lines but via something more strongly typed such as RPC or shared memory or reading/writing a Pickle. I use the command line a lot, and I frequently copy paths from the command line and paste them into the file open dialog, which does not accept forward slashes nor nested double slashes. It should but oh well. Therefore I have goal before much longer to ensure that every path generated and probably reported by cm3 is in the "normal" form. If the user types in a forward slash, perhaps that should be reported back though. And forward slashes should be ok to enter and then get used internally. The need to configure short file names are gone, along with the need to quote them, by virtue of the dependency on environment variables. Paths with spaces can still come in other ways, but not via SYSTEM_CC in a "normal" cm3, for my newfangled revisionist version of "normal". :) Short names really stink, in so many ways. First, they aren't necessary even shorter, they are just of a limited character set. They can be up to twice as long as "long". Try this: mkdir \1.1.1. dir /x 1* Also, wildcard matching "always" (in FindFirstFile/FindNextFile) operates against both long and short, and since short are unpredcitable, wildcard matching therefore is. An example, probably, is: echo > foo.bar echo > food.barf dir *.bar Will probably, but not necessarily, match both files, though you would only expect one match. As well, I don't believe short file names have always been backed up and restored -- for anyone that uses any backup softwre (not me!). So you determine your short name, you backup and restore, and it changes. Or more clearly, recreating files, might get a different name. It's a mess. I would discourage you from persisting short names ever. Names with spaces I discourage but not as strong. For example, in some contexts, there is just one name and there is no ambiguity. Actually in %PATH% there is no ambiguity because the sepArator is the semicolon.I think Win9x different though, sigh. I agree from my "min" distribution, you need to build the rest. I have to admit, I thought the "culture" on this list was to want to and actually build the system from source. I will put a "std" distribution up on birch this week hopefully and hopefully someone will put it on the web page. Maintaining the installer should not be a problem. As long as the licensing and cost and all is right. I have not fixed the build yet, sorry. - Jay Date: Wed, 16 Jan 2008 11:24:34 -0500From: rcoleburn at scires.comTo: m3devel at elegosoft.com; jayk123 at hotmail.comSubject: Re: [M3devel] my status on win32 Jay: Not sure I've clued in to all of your dialog. Sorry. I have in the past used a free tool to build an installer package and I was thinking of using it again. Since the tool is free, we could put all the work I do into the CVS repository so that others could also maintain it. What I am looking to achieve is to have a way where a "normal" Windows user could download a program, run it, and have all of the cm3 packages installed without having to use the MIN distribution to build it up or any other tools to get the sources (like cvs). You could achieve the same thing by having a big ZIP file also I suppose, but having the installer would also let us easily put something in the start menu to launch a command line with all the environment variables set properly via automatic call to vcvars et al. When I get "Reactor" working, it too could be put into the start menu. That just makes it fit in better with the Windows user culture I think. The reason I wanted to rebuild everything is two-fold: 1) ensure it can be done (i.e., test for "Broken #1"), and 2) get all of the rest of the packages built so I could then use cm3 to build "reactor" and my own programs and test them to see if there are any "Broken #2" issues. The MIN distribution is really insufficient to do much of anything except to build the rest of the packages you need. My understanding is that I needed to use CVS to get the current sources, because if I went back to the source archive, it was old and known to be Broken #1 on Windows. I'm glad that you believe the current "Broken #1" situation is easy to fix. Let me know what to do and I'll give it another try. My experience in the past has been that there are 3 conditions to getting cm3 to work properly on windows after it has been installed: 1) make sure your environment variables are set up by vcvars to point to the compiler/linker/libraries (of course if you used a non-Microsoft C compiler/linker you would need to use something other than vcvars); 2) make sure cm3.cfg has the right paths in place to find all the libraries and tools using DOS style short names (no embedded spaces); and 3) make sure C:\cm3\bin is in your path. Of these, #2 & #3 are essentially one-time events, and #1 can be set up by a invoking a batch/command file via a shortcut, so no big deal for me. You could even make #1 a one-time event by modifying the system-level (vice user-level) environment variables. The old cm3install program seemed to do a decent job of #2 for me. Also, I've noted some of your past dialog about accepting either '/' or '\' as a path separator. I'm sure you are aware that on Windows '/' is used often for switches (arguments). Plus Windows also allows spaces to be embedded in the command line, so whatever solution you propose needs to take into account that a valid command line might look like this: C:\My Program Folder\My Program.exe /myArg1 /myArg2 In some situations, this command line would have to be quoted and rendered as: "C:\My Program Folder\My Program.exe" /myArg1 /myArg2 and in places where the backslash is an escape character, I've seen "C:\\My Program Folder\\My Program.exe" /myArg1 /myArg2 Alas, I seem to have rambled a bit also. Sorry. The immediate need for me now is to solve the Broken #1 condition, so please let me know how to fix it and proceed. Regards, Randy>>> Jay 1/16/2008 10:28 AM >>>Randy, yes and no and clarifications. I mention starting with 5.1.6 as a "worst" or "worse" case.The earlier you start, the harder things are -- for me, to ensure it will work. If you merely start with my 5.5.0, well, what are you rebuilding from source for?Heck, you can use any binary distribution, 4.1, 5.1.6, and just use it. They should work. The n steps you/I give are really actually geared for people who WANT to build from source, it is not what people HAVE to do.As well there have been can be source distributions, to cut out CVS. I'll look into the datefn stuff shortly. As to the installer, well, again, yes and no.The need for the installer is very small. All you have to do today is unzip the .zip somewhere and set the path, and possibly the vcvars thing. That's it. I should..now that you are "pressuring" me for ease of use, teach cm3 about the various ?venvdir%, %vcinstalldir% variables, etc. That way as long as the user installed the tools, even if they elected not to change path/lib/include, cm3 can find the compiler and linker. I know everyone wants to preserve the flexibility of quake/cm3.cfg but...besides, cm3 can be pretty darn smart here. IF cm3.cfg defines SYSTEM_CC, leave things along (NT386 cm3.cfg does not today do that). However if there is now SYSTEM_CC and there is no cl.exe/link.exe in %PATH%, it could go on a quick hunt for them. On the lib and include part, well, the dependency on %include% might only be for errno..maybe not worth it. It has been whatever it is forever, like int* _errno(void); #define errno (*_errno)()). Modula-3 engages in rampant header cloning and CErrnoC was only introduced where that was deemed more fragile than usual, and for Windows it probably wasn't actually fragile -- the fragility, if I may be so rudely judgemental, is because so many other systems are so Johnny-come-lately to arriving at the obviously correct threading model that Windows has had all along (since Win95/NT, can't say anything good about Win3.1; I think OS/2 might have had it correct all along too.). Funny, everyone has FINALLY arrived at the correct threading model, only to have start changing again, since the number of cores and machines is set to be much greater than anticipated, the obvious threading model has been deemed too difficult for anyone to use (Win32, Modula-3, Java, .NET, Python, all the same supposedly too difficult model btw), and so some new one is needed, and well, truthfully, the difficulty is not just for dummies on relatively small multiproc boxes not having simple race conditions, the problem is scaling way way up. Sorry that was my usual tangential. Even the unzip and set path would benefit slightly from a GUI installer.I believe there is some easy thing you can do where you write your GUI installer and you put it in the .zip and then you prepend the GUI self extracting .zip/.exe stub, and you can tell it to run a particular command after the extraction. I guess you might use a fancier thing though?That is, are you going to, say, write a gui installer from scratch in Modula-3? It might be a fun exercise. :)And then you could build the self extracting prefix from source etc.This is the hard way I guess, but more interesing.If you can build an msi or use InstallShield or Wix or something, go ahead.If you use widely availabe free as in beer tools, that can be rolled into whatever automation there is to produce distributions, keeping it up to date shouldn't be a problem. I do have to bring up some annoying questions: 1) Does anyone besides me have the capacity to produce distributions? i.e.: Any Win32 machines left at Elego? 2) I know I ramble. So one of my many tangents/questions went unanswered.Say, in the absence of a gui installer, should .zips/.tar.bz files look like cm3-min-/bin/cm3orbin/cm3orcm3/bin/cm3 The last one is more directly usable. The first one is very common. This reminds me though Randy, the distribution I made available was "min", so yeah, like if you are doing any gui programming, using any "standard" library besides m3core or libm3, you'd need to build more from source. I can readily provide you a "std" distribution though.It's "always" been a "problem" to make my files available -- no web site hosting for me -- but recently that wasn't a problem, someone picked the files out of ~jkrell on birch and put them on the web site. Good. One more thing -- Olaf, please confirm repeat yourself, 'cause I admit I wasn't sure it was the right thing, but if you insist, ok. "std" should be "all"? I should not continue to imagine there is a new larger group called "all"? And wherever things are missing from std but do build ok, add them?m3cc should be in std?(I admit some big indecisiveness around m3cc. It is far and away the longest thing to build and so the one you really want to skip the most and leave out of whatever package group. I also wonder if on Windows, there should be some check where if sh is not in the $PATH, just silently skip m3cc? You only need MingWin to build what I have on my system for NT386GNU, except you also need msys just for m3cc. msys is actually quite small, like only 20 files..) Oh, sorry, yet another question.The non-gcc backend is excluded from the build on systems that use the gcc backend.For minimization, that is appropriate.For maximizing cross build capability, it is wrong.The packages build fine. I suspect they work.I am not a user of cross build capability yet, so I don't really care. (What I do for NT386/NT386GNU /might/ be considered sort of a cross build, but it is different/easier).They are small packages. - Jay Date: Wed, 16 Jan 2008 08:25:49 -0500From: rcoleburn at scires.comTo: m3devel at elegosoft.com; jayk123 at hotmail.comSubject: Re: [M3devel] my status on win32 Jay: There is no line in the m3makefile dealing with datefn, so I added the whole statement just before the line include("version.quake") Now, I get an error saying that the variable datefn is not defined. If you change to put quotes around datefn in the include statement, you get an error saying it can't open the file. You made a reference in one of your earlier posts about trying 5.1.6 or 4.1, but note that I started with your cm3-min-WIN32-NT386-d5.5.0.zip , not the 5.1.6 or 4.1 versions. Thus, using d5.5.0 as a base, I am trying to run your "upgrade.cmd" to rebuild the sources I checked out from CVS. Since this doesn't work "out-of-the-box", again I say this fits into the "Broken #1" category. If I can get this to work, I don't mind putting together a Windows installer program that will install the whole thing. That way, folks won't have to install cygwin just to get CVS so that they can install a working cm3. Folks will need to install the free Microsoft Visual C as a prerequisite, but then that's not too bad. Having an installer program would make cm3 more friendly to Windows folks. The current 16-step method is too laborious and error-prone for the person just getting started and they will not give cm3 a second try. As the cm3 system evolves and new releases are made, we will need to keep the installer program up-to-date and I don't mind doing that. After someone gets familiar with cm3 they might want to delve into some of the scripts for rebuilding the system, but until then, I think the installer program is the way to go. Regards, Randy>>> Jay 1/16/2008 1:01 AM >>>I think I see the problem. in cm3\src\m3makefile, make this change > if not defined("NOW") include(datefn) > end datefn is only created if certain other variables aren't defined, and do-pkg defines them.I don't know why I don't see this. Later.Could be that the Python scripts have a typo and don't define them.I've been using them more than cmd. If the host is NT, "NOW" is either gotten from an updated cm3.exe, or left to "not available". So the initial cm3 built from older cm3 can't report when it was built, but cm3 built from current cm3 can. I need to change that: 1) to be a function for niceness 2) to make it that way for Posix, for any host but I haven't been using Posix as much lately so not testing it. - Jay Date: Tue, 15 Jan 2008 23:55:39 -0500From: rcoleburn at scires.comTo: m3devel at elegosoft.com; jayk123 at hotmail.comSubject: RE: my status on win32 Jay: In the file version.quake, I made the following edit: changed line: local datefn = "../" & TARGET & ".datenow" to: local datefn = ".." & SL & TARGET & ".datenow" This change has the effect of putting a backward slash in the pathname instead of a forward slash, so we getC:\CM3_CVS_SourceTree\m3-sys\cm3\src\..\NT386.datenow So from that perspective, the change seems good. Unfortunately, I still get the error that this file can't be opened. A quick check of C:\CM3_CVS_SourceTree\m3-sys\cm3\NT386 shows that the file .datenow does not exist. Regards, Randy>>> Jay 1/15/2008 11:03 PM >>>That's not too bad really. 1) I'd recommend putting cm3 at the start of the path instead of the end. 2) Just comment out the offending code to make progress. It's not critical. >> C:\CM3_CVS_SourceTree\m3-sys\cm3\src\../NT386.datenow The code is: C:\CM3_CVS_SourceTree\m3-sys\cm3\src\version.quake or such, included by cm3\src\m3makefile. Does the file exist?Does version.quake use "/" or "SL"? If it uses "/", try replacing with SL (and ampersand for string concat). Could be that a newer binary distributions works better with forward slashes. > 4. > 5. > 6. Launch cygwin from desktop icon. Cygwin is only needed for cvs, I think you realize. Could you send me offline the result of just running "set" after running vcvarsall? I'd like to adapt pylib.py to it maybe. (I can start from 5.1.6 and will try 4.1 at some point.) - Jay Date: Tue, 15 Jan 2008 22:52:59 -0500From: rcoleburn at scires.comTo: m3devel at elegosoft.com; jayk123 at hotmail.comSubject: my status on win32 Jay et al: I've listed below the steps I've undertaken to try and build the current sources on Windows XP. I've also attached a text file showing the output I got when trying to build everything using Jay's upgrade.cmd script. Unfortunately, I'm getting a build error (see below). Please advise on how to resolve. STEPS I TOOK: ========= 1. Download Microsoft Visual Studio 2008 Express Edition All-in-One .ISO file and burn to DVD. http://www.microsoft.com/express/download/ 2. Install Microsoft Visual C++ 2008 Express Edition from DVD. 3. Use "Microsoft Update" service to check for updates / service packs. 4. Download cygwin setup program from http://cygwin.com/ 5. Ran cygwin setup.exe program to install cygwin for all users. Under "Devel" category, make certain to select "cvs" for installation. 6. Launch cygwin from desktop icon. 7. In cygwin command shell window, execute following two commands, making sure to give email as password when prompted for login: cvs -d :pserver:anonymous at modula3.elegosoft.com:/usr/cvs login cvs -d :pserver:anonymous at modula3.elegosoft.com:/usr/cvs checkout cm3 8. Moved resulting C:\cygwin\home\rcoleburn\cm3 to C:\CM3_CVS_SourceTree Note that you should replace "rcoleburn" above with your Windows login username. 9. Download cm3-min-WIN32-NT386-d5.5.0.zip and cm3-min-WIN32-NT386-d5.5.0-symbols.zip from http://modula3.elegosoft.com/cm3/download.html 10. Unzipped cm3-min-WIN32-NT386-d5.5.0.zip and stored resulting cm3 folder at C:\cm3 11. Unzipped cm3-min-WIN32-NT386-d5.5.0-symbols.zip and stored resulting symbols folder at C:\cm3\symbols 12. Launch Windows Command Prompt shell. The following steps represent commands executed within this shell. 13. path %path%;c:\cm3\bin 14. "C:\Program Files\Microsoft Visual Studio 9.0\VC\vcvarsall.bat" 15. cd C:\CM3_CVS_SourceTree\scripts\win 16. upgrade.cmd ERROR I'M GETTING: ============= === package C:\CM3_CVS_SourceTree\m3-sys\cm3 ===+++ "cm3 -build -DROOT=C:\\CM3_CVS_SourceTree -DCM3_VERSION_TEXT=d5.5.1 -DCM3_VERSION_NUMBER=050501 -DCM3_LAST_CHANGED=2007-12-30 && cm3 -ship -DROOT=C:\\CM3_CVS_SourceTree -DCM3_VERSION_TEXT=d5.5.1 -DCM3_VERSION_NUMBER=050501 -DCM3_LAST_CHANGED=2007-12-30" +++--- building in NT386 --- ignoring ..\src\m3overrides "C:\CM3_CVS_SourceTree\m3-sys\cm3\src\version.quake", line 136: quake runtime error: unable to open "C:\CM3_CVS_SourceTree\m3-sys\cm3\src\../NT386.datenow" forreading --procedure-- -line- -file---include -- version_impl 136 C:\CM3_CVS_SourceTree\m3-sys\cm3\src\version.quakeinclude_dir 20 C:\CM3_CVS_SourceTree\m3-sys\cm3\src\m3makefile 8 C:\CM3_CVS_SourceTree\m3-sys\cm3\NT386\m3make.args Fatal Error: package build failedERROR: "cm3 -build -DROOT=C:\\CM3_CVS_SourceTree -DCM3_VERSION_TEXT=d5.5.1 -DCM3_VERSION_NUMBER=050501 -DCM3_LAST_CHANGED=2007-12-30 && cm3 -ship -DROOT=C:\\CM3_CVS_SourceTree -DCM3_VERSION_TEXT=d5.5.1 -DCM3_VERSION_NUMBER=050501 -DCM3_LAST_CHANGED=2007-12-30"ERROR: cd C:\CM3_CVS_SourceTree\m3-sys\cm3ERROR: set INSTALLROOT=c:\cm3 Regards, Randy Share life as it happens with the new Windows Live. Start sharing! Put your friends on the big screen with Windows Vista? + Windows LiveT. Start now! Get the power of Windows + Web with the new Windows Live. Get it now! _________________________________________________________________ Make distant family not so distant with Windows Vista? + Windows Live?. http://www.microsoft.com/windows/digitallife/keepintouch.mspx?ocid=TXT_TAGLM_CPC_VideoChat_distantfamily_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Wed Jan 16 21:27:40 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 16 Jan 2008 15:27:40 -0500 Subject: [M3devel] GC question version 2 In-Reply-To: References: Message-ID: This might be possible, but probably would force completion of the current GC to get all the references. Again, not a particularly nice thing to be doing. Once again, why not use indirection and weak references. Probably cheaper, more flexible and portable. On Jan 16, 2008, at 1:28 PM, Darko wrote: > Ok, a slightly different approach: Can the GC give me a list of all > the objects that contain a reference to an object? Would it be > thorough (ie not miss any objects)? False positives might be ok. > Then I could check the type of each object and update the > references myself. It would be reasonable to assume that the > references in question were not being changed by any thread during > the checking process. > > Thanks, > Darko. From darko at darko.org Wed Jan 16 21:52:31 2008 From: darko at darko.org (Darko) Date: Wed, 16 Jan 2008 12:52:31 -0800 Subject: [M3devel] GC question version 2 In-Reply-To: References: Message-ID: <96E7F2FE-D050-4B3C-8918-258FE5CE690F@darko.org> Thanks, I probably will have to use some combination of encapsulation and indirection, but that solution isn't cheaper in terms of memory, which might be a problem in what is an all-allocated data structure (ie, every field value is allocated). I'm basically investigating all possible approaches and not against the solution you've suggested. On 16/01/2008, at 12:27 PM, Tony Hosking wrote: > This might be possible, but probably would force completion of the > current GC to get all the references. Again, not a particularly > nice thing to be doing. Once again, why not use indirection and > weak references. Probably cheaper, more flexible and portable. > > On Jan 16, 2008, at 1:28 PM, Darko wrote: > >> Ok, a slightly different approach: Can the GC give me a list of all >> the objects that contain a reference to an object? Would it be >> thorough (ie not miss any objects)? False positives might be ok. >> Then I could check the type of each object and update the >> references myself. It would be reasonable to assume that the >> references in question were not being changed by any thread during >> the checking process. >> >> Thanks, >> Darko. > From wagner at elegosoft.com Wed Jan 16 21:53:32 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 16 Jan 2008 21:53:32 +0100 Subject: [M3devel] my status on win32 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> <477EA137.1E75.00D7.1@scires.com> <478D394B.1E75.00D7.1@scires.com> <478D47FB.1E75.00D7.1@scires.com> <478DBF8D.1E75.00D7.1@scires.com> Message-ID: <20080116215332.ds4sfixao84g4wk4@mail.elegosoft.com> Quoting Jay : > Yes I agree it is "broken #1" and shouldn't be this way, but I > assure you, really, your results are 99% there. What isn't working > is minor and easy to fix and much is working. Jay, could you please just fix the cm3 package so that it compiles without problems in NT386(GNU), too? It should not be too difficult; there are no problems on the POSIX platforms. As for other installers or installation packages, I'm not against them, it is just that somebody must take responsibility and maintain them and keep them up-to-date. I for sure cannot contribute the efforts needed to maintain different installation variants for different targets. It has been much work to get everything working as it is. I'd be very careful with any changes that might have impacts on the system and installation structures. Everything will have to be tested on every platform afterwards, and my experience says that at least half will break regardless how careful you tried to be. For the integrity of the system itself, the regression test suite we've now setup will be a great help in my opinion. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Jan 16 21:55:51 2008 From: rcoleburn at scires.com (Randy Coleburn) Date: Wed, 16 Jan 2008 15:55:51 -0500 Subject: [M3devel] my status on win32 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> <477EA137.1E75.00D7.1@scires.com> <478D394B.1E75.00D7.1@scires.com> <478D47FB.1E75.00D7.1@scires.com> <478DBF8D.1E75.00D7.1@scires.com> <478DE973.1E75.00D7.1@scires.com> Message-ID: <478E2908.1E75.00D7.1@scires.com> Jay: Thanks for your reply. I think most of your goals seem reasonable and I concur that there are nasty problems introduced by spaces and short names. It's a messy situation that neither you nor I created. I was just relaying some of my prior experience in getting things to work. Indeed, for me, I try to avoid spaces always. That's one reason I root my cm3 at "C:\cm3" instead of in "C:\Program Files\cm3" or "C:\Documents and Settings\userhome\cm3". I've noted that with the various Visual Studio and Visual C tools going back for some time now that after you install it, your environment vars for TEMP and TMP get changed to use short names without spaces, so I guess even Microsoft has trouble with spaces. I also recall in the past with cm3 having trouble if my TEMP and TMP vars included spaces, so having Microsoft switch them to use short names without spaces seemed to solve that cm3 problem at least. As for the VC installation, I too recall that on some prior versions it asked you whether you wanted to set the environment vars permanently or to use vcvars. This time, when I installed Visual Studio 2008, it did not ask this question, so I guess it is version dependant. I'm not at the machine right now where I did the install, but later tonight I'll check to see if the VS2008 install set any permanent environment vars. Again, for me, I would like to be able to build everything as the first step in my series of tests. As soon as you can give me a fix to make things build, I can move on to make more progress. Thanks for your help. Regards, Randy >>> Jay 1/16/2008 2:13 PM >>> Hi Randy. I mostly agree and understand. Go ahead with your installer work. :) #2 is no longer needed. The cm3.cfg I use, that is checked in, that is in the newer distributions, just runs plain "cl" and links to plain "kernel32.dll", and doesn't pass any /I switches to cl => therefore it depends on %PATH%, %LIB%, and %INCLUDE%. As I was saying/rambling, we/I can probably teach cm3 a bit so as to not need vcvars. As I recall, but I need to check, when you install VC, there are some variables it sets unconditionally, and some it asks the user if they should be set. The ones it asks about are PATH, LIB, INCLUDE. The ones it sets unconditionally are the "root" of the install. PATH / LIB / INCLUDE are more invasive, more impactful, have more potential to break things. They are also easily derived from the "root". Similarly, the CM3 installer could ask the user if it is ok to modify their %PATH%, and do it in the registry and set the WM_INI_CHANGED or such message so that Explorer picks it up. Need to check MSDN on this. Forward slashes are fine for options. I take a dim view of these space, quoting, escaping issues. I have very mixed experience here. In SOME situations, your command lines pass through various layers of code, with various attempts to handle or ignore the various issues. The result is in my opinion an unpredictable mess. The problem is that people have confused "an array of strings" with "one flat string". At this point the confusion is widespread and deeply ingrained. On Unix I believe people just ignore the issue by not using spaces (or quotes?) on the command line, though escaping issues still remain for other characters. You just have to read the documenation on CreateProcess to realize how messed up this is. c:\program files\foo I believe is interpreted multiple ways until something works. It can be running c:\program with the parameter files\foo, or it can be running c:\program files\foo. Reliable interprocess communication should not be via command lines but via something more strongly typed such as RPC or shared memory or reading/writing a Pickle. I use the command line a lot, and I frequently copy paths from the command line and paste them into the file open dialog, which does not accept forward slashes nor nested double slashes. It should but oh well. Therefore I have goal before much longer to ensure that every path generated and probably reported by cm3 is in the "normal" form. If the user types in a forward slash, perhaps that should be reported back though. And forward slashes should be ok to enter and then get used internally. The need to configure short file names are gone, along with the need to quote them, by virtue of the dependency on environment variables. Paths with spaces can still come in other ways, but not via SYSTEM_CC in a "normal" cm3, for my newfangled revisionist version of "normal". :) Short names really stink, in so many ways. First, they aren't necessary even shorter, they are just of a limited character set. They can be up to twice as long as "long". Try this: mkdir \1.1.1. dir /x 1* Also, wildcard matching "always" (in FindFirstFile/FindNextFile) operates against both long and short, and since short are unpredcitable, wildcard matching therefore is. An example, probably, is: echo > foo.bar echo > food.barf dir *.bar Will probably, but not necessarily, match both files, though you would only expect one match. As well, I don't believe short file names have always been backed up and restored -- for anyone that uses any backup softwre (not me!). So you determine your short name, you backup and restore, and it changes. Or more clearly, recreating files, might get a different name. It's a mess. I would discourage you from persisting short names ever. Names with spaces I discourage but not as strong. For example, in some contexts, there is just one name and there is no ambiguity. Actually in %PATH% there is no ambiguity because the sepArator is the semicolon. I think Win9x different though, sigh. I agree from my "min" distribution, you need to build the rest. I have to admit, I thought the "culture" on this list was to want to and actually build the system from source. I will put a "std" distribution up on birch this week hopefully and hopefully someone will put it on the web page. Maintaining the installer should not be a problem. As long as the licensing and cost and all is right. I have not fixed the build yet, sorry. - Jay Date: Wed, 16 Jan 2008 11:24:34 -0500 From: rcoleburn at scires.com To: m3devel at elegosoft.com; jayk123 at hotmail.com Subject: Re: [M3devel] my status on win32 Jay: Not sure I've clued in to all of your dialog. Sorry. I have in the past used a free tool to build an installer package and I was thinking of using it again. Since the tool is free, we could put all the work I do into the CVS repository so that others could also maintain it. What I am looking to achieve is to have a way where a "normal" Windows user could download a program, run it, and have all of the cm3 packages installed without having to use the MIN distribution to build it up or any other tools to get the sources (like cvs). You could achieve the same thing by having a big ZIP file also I suppose, but having the installer would also let us easily put something in the start menu to launch a command line with all the environment variables set properly via automatic call to vcvars et al. When I get "Reactor" working, it too could be put into the start menu. That just makes it fit in better with the Windows user culture I think. The reason I wanted to rebuild everything is two-fold: 1) ensure it can be done (i.e., test for "Broken #1"), and 2) get all of the rest of the packages built so I could then use cm3 to build "reactor" and my own programs and test them to see if there are any "Broken #2" issues. The MIN distribution is really insufficient to do much of anything except to build the rest of the packages you need. My understanding is that I needed to use CVS to get the current sources, because if I went back to the source archive, it was old and known to be Broken #1 on Windows. I'm glad that you believe the current "Broken #1" situation is easy to fix. Let me know what to do and I'll give it another try. My experience in the past has been that there are 3 conditions to getting cm3 to work properly on windows after it has been installed: 1) make sure your environment variables are set up by vcvars to point to the compiler/linker/libraries (of course if you used a non-Microsoft C compiler/linker you would need to use something other than vcvars); 2) make sure cm3.cfg has the right paths in place to find all the libraries and tools using DOS style short names (no embedded spaces); and 3) make sure C:\cm3\bin is in your path. Of these, #2 & #3 are essentially one-time events, and #1 can be set up by a invoking a batch/command file via a shortcut, so no big deal for me. You could even make #1 a one-time event by modifying the system-level (vice user-level) environment variables. The old cm3install program seemed to do a decent job of #2 for me. Also, I've noted some of your past dialog about accepting either '/' or '\' as a path separator. I'm sure you are aware that on Windows '/' is used often for switches (arguments). Plus Windows also allows spaces to be embedded in the command line, so whatever solution you propose needs to take into account that a valid command line might look like this: C:\My Program Folder\My Program.exe /myArg1 /myArg2 In some situations, this command line would have to be quoted and rendered as: "C:\My Program Folder\My Program.exe" /myArg1 /myArg2 and in places where the backslash is an escape character, I've seen "C:\\My Program Folder\\My Program.exe" /myArg1 /myArg2 Alas, I seem to have rambled a bit also. Sorry. The immediate need for me now is to solve the Broken #1 condition, so please let me know how to fix it and proceed. Regards, Randy >>> Jay 1/16/2008 10:28 AM >>> Randy, yes and no and clarifications. I mention starting with 5.1.6 as a "worst" or "worse" case. The earlier you start, the harder things are -- for me, to ensure it will work. If you merely start with my 5.5.0, well, what are you rebuilding from source for? Heck, you can use any binary distribution, 4.1, 5.1.6, and just use it. They should work. The n steps you/I give are really actually geared for people who WANT to build from source, it is not what people HAVE to do. As well there have been can be source distributions, to cut out CVS. I'll look into the datefn stuff shortly. As to the installer, well, again, yes and no. The need for the installer is very small. All you have to do today is unzip the .zip somewhere and set the path, and possibly the vcvars thing. That's it. I should..now that you are "pressuring" me for ease of use, teach cm3 about the various ?venvdir%, %vcinstalldir% variables, etc. That way as long as the user installed the tools, even if they elected not to change path/lib/include, cm3 can find the compiler and linker. I know everyone wants to preserve the flexibility of quake/cm3.cfg but...besides, cm3 can be pretty darn smart here. IF cm3.cfg defines SYSTEM_CC, leave things along (NT386 cm3.cfg does not today do that). However if there is now SYSTEM_CC and there is no cl.exe/link.exe in %PATH%, it could go on a quick hunt for them. On the lib and include part, well, the dependency on %include% might only be for errno..maybe not worth it. It has been whatever it is forever, like int* _errno(void); #define errno (*_errno)()). Modula-3 engages in rampant header cloning and CErrnoC was only introduced where that was deemed more fragile than usual, and for Windows it probably wasn't actually fragile -- the fragility, if I may be so rudely judgemental, is because so many other systems are so Johnny-come-lately to arriving at the obviously correct threading model that Windows has had all along (since Win95/NT, can't say anything good about Win3.1; I think OS/2 might have had it correct all along too.). Funny, everyone has FINALLY arrived at the correct threading model, only to have start changing again, since the number of cores and machines is set to be much greater than anticipated, the obvious threading model has been deemed too difficult for anyone to use (Win32, Modula-3, Java, .NET, Python, all the same supposedly too difficult model btw), and so some new one is needed, and well, truthfully, the difficulty is not just for dummies on relatively small multiproc boxes not having simple race conditions, the problem is scaling way way up. Sorry that was my usual tangential. Even the unzip and set path would benefit slightly from a GUI installer. I believe there is some easy thing you can do where you write your GUI installer and you put it in the .zip and then you prepend the GUI self extracting .zip/.exe stub, and you can tell it to run a particular command after the extraction. I guess you might use a fancier thing though? That is, are you going to, say, write a gui installer from scratch in Modula-3? It might be a fun exercise. :) And then you could build the self extracting prefix from source etc. This is the hard way I guess, but more interesing. If you can build an msi or use InstallShield or Wix or something, go ahead. If you use widely availabe free as in beer tools, that can be rolled into whatever automation there is to produce distributions, keeping it up to date shouldn't be a problem. I do have to bring up some annoying questions: 1) Does anyone besides me have the capacity to produce distributions? i.e.: Any Win32 machines left at Elego? 2) I know I ramble. So one of my many tangents/questions went unanswered. Say, in the absence of a gui installer, should .zips/.tar.bz files look like cm3-min-/bin/cm3 or bin/cm3 or cm3/bin/cm3 The last one is more directly usable. The first one is very common. This reminds me though Randy, the distribution I made available was "min", so yeah, like if you are doing any gui programming, using any "standard" library besides m3core or libm3, you'd need to build more from source. I can readily provide you a "std" distribution though. It's "always" been a "problem" to make my files available -- no web site hosting for me -- but recently that wasn't a problem, someone picked the files out of ~jkrell on birch and put them on the web site. Good. One more thing -- Olaf, please confirm repeat yourself, 'cause I admit I wasn't sure it was the right thing, but if you insist, ok. "std" should be "all"? I should not continue to imagine there is a new larger group called "all"? And wherever things are missing from std but do build ok, add them? m3cc should be in std? (I admit some big indecisiveness around m3cc. It is far and away the longest thing to build and so the one you really want to skip the most and leave out of whatever package group. I also wonder if on Windows, there should be some check where if sh is not in the $PATH, just silently skip m3cc? You only need MingWin to build what I have on my system for NT386GNU, except you also need msys just for m3cc. msys is actually quite small, like only 20 files..) Oh, sorry, yet another question. The non-gcc backend is excluded from the build on systems that use the gcc backend. For minimization, that is appropriate. For maximizing cross build capability, it is wrong. The packages build fine. I suspect they work. I am not a user of cross build capability yet, so I don't really care. (What I do for NT386/NT386GNU /might/ be considered sort of a cross build, but it is different/easier). They are small packages. - Jay Date: Wed, 16 Jan 2008 08:25:49 -0500 From: rcoleburn at scires.com To: m3devel at elegosoft.com; jayk123 at hotmail.com Subject: Re: [M3devel] my status on win32 Jay: There is no line in the m3makefile dealing with datefn, so I added the whole statement just before the line include("version.quake") Now, I get an error saying that the variable datefn is not defined. If you change to put quotes around datefn in the include statement, you get an error saying it can't open the file. You made a reference in one of your earlier posts about trying 5.1.6 or 4.1, but note that I started with your cm3-min-WIN32-NT386-d5.5.0.zip , not the 5.1.6 or 4.1 versions. Thus, using d5.5.0 as a base, I am trying to run your "upgrade.cmd" to rebuild the sources I checked out from CVS. Since this doesn't work "out-of-the-box", again I say this fits into the "Broken #1" category. If I can get this to work, I don't mind putting together a Windows installer program that will install the whole thing. That way, folks won't have to install cygwin just to get CVS so that they can install a working cm3. Folks will need to install the free Microsoft Visual C as a prerequisite, but then that's not too bad. Having an installer program would make cm3 more friendly to Windows folks. The current 16-step method is too laborious and error-prone for the person just getting started and they will not give cm3 a second try. As the cm3 system evolves and new releases are made, we will need to keep the installer program up-to-date and I don't mind doing that. After someone gets familiar with cm3 they might want to delve into some of the scripts for rebuilding the system, but until then, I think the installer program is the way to go. Regards, Randy >>> Jay 1/16/2008 1:01 AM >>> I think I see the problem. in cm3\src\m3makefile, make this change > if not defined("NOW") include(datefn) > end datefn is only created if certain other variables aren't defined, and do-pkg defines them. I don't know why I don't see this. Later. Could be that the Python scripts have a typo and don't define them. I've been using them more than cmd. If the host is NT, "NOW" is either gotten from an updated cm3.exe, or left to "not available". So the initial cm3 built from older cm3 can't report when it was built, but cm3 built from current cm3 can. I need to change that: 1) to be a function for niceness 2) to make it that way for Posix, for any host but I haven't been using Posix as much lately so not testing it. - Jay Date: Tue, 15 Jan 2008 23:55:39 -0500 From: rcoleburn at scires.com To: m3devel at elegosoft.com; jayk123 at hotmail.com Subject: RE: my status on win32 Jay: In the file version.quake, I made the following edit: changed line: local datefn = "../" & TARGET & ".datenow" to: local datefn = ".." & SL & TARGET & ".datenow" This change has the effect of putting a backward slash in the pathname instead of a forward slash, so we get C:\CM3_CVS_SourceTree\m3-sys\cm3\src\..\NT386.datenow So from that perspective, the change seems good. Unfortunately, I still get the error that this file can't be opened. A quick check of C:\CM3_CVS_SourceTree\m3-sys\cm3\NT386 shows that the file .datenow does not exist. Regards, Randy >>> Jay 1/15/2008 11:03 PM >>> That's not too bad really. 1) I'd recommend putting cm3 at the start of the path instead of the end. 2) Just comment out the offending code to make progress. It's not critical. >> C:\CM3_CVS_SourceTree\m3-sys\cm3\src\../NT386.datenow The code is: C:\CM3_CVS_SourceTree\m3-sys\cm3\src\version.quake or such, included by cm3\src\m3makefile. Does the file exist? Does version.quake use "/" or "SL"? If it uses "/", try replacing with SL (and ampersand for string concat). Could be that a newer binary distributions works better with forward slashes. > 4. > 5. > 6. Launch cygwin from desktop icon. Cygwin is only needed for cvs, I think you realize. Could you send me offline the result of just running "set" after running vcvarsall? I'd like to adapt pylib.py to it maybe. (I can start from 5.1.6 and will try 4.1 at some point.) - Jay Date: Tue, 15 Jan 2008 22:52:59 -0500 From: rcoleburn at scires.com To: m3devel at elegosoft.com; jayk123 at hotmail.com Subject: my status on win32 Jay et al: I've listed below the steps I've undertaken to try and build the current sources on Windows XP. I've also attached a text file showing the output I got when trying to build everything using Jay's upgrade.cmd script. Unfortunately, I'm getting a build error (see below). Please advise on how to resolve. STEPS I TOOK: ========= 1. Download Microsoft Visual Studio 2008 Express Edition All-in-One .ISO file and burn to DVD. http://www.microsoft.com/express/download/ 2. Install Microsoft Visual C++ 2008 Express Edition from DVD. 3. Use "Microsoft Update" service to check for updates / service packs. 4. Download cygwin setup program from http://cygwin.com/ 5. Ran cygwin setup.exe program to install cygwin for all users. Under "Devel" category, make certain to select "cvs" for installation. 6. Launch cygwin from desktop icon. 7. In cygwin command shell window, execute following two commands, making sure to give email as password when prompted for login: cvs -d :pserver:anonymous at modula3.elegosoft.com:/usr/cvs login cvs -d :pserver:anonymous at modula3.elegosoft.com:/usr/cvs checkout cm3 8. Moved resulting C:\cygwin\home\rcoleburn\cm3 to C:\CM3_CVS_SourceTree Note that you should replace "rcoleburn" above with your Windows login username. 9. Download cm3-min-WIN32-NT386-d5.5.0.zip and cm3-min-WIN32-NT386-d5.5.0-symbols.zip from http://modula3.elegosoft.com/cm3/download.html 10. Unzipped cm3-min-WIN32-NT386-d5.5.0.zip and stored resulting cm3 folder at C:\cm3 11. Unzipped cm3-min-WIN32-NT386-d5.5.0-symbols.zip and stored resulting symbols folder at C:\cm3\symbols 12. Launch Windows Command Prompt shell. The following steps represent commands executed within this shell. 13. path %path%;c:\cm3\bin 14. "C:\Program Files\Microsoft Visual Studio 9.0\VC\vcvarsall.bat" 15. cd C:\CM3_CVS_SourceTree\scripts\win 16. upgrade.cmd ERROR I'M GETTING: ============= === package C:\CM3_CVS_SourceTree\m3-sys\cm3 === +++ "cm3 -build -DROOT=C:\\CM3_CVS_SourceTree -DCM3_VERSION_TEXT=d5.5.1 -DCM3_V ERSION_NUMBER=050501 -DCM3_LAST_CHANGED=2007-12-30 && cm3 -ship -DROOT=C:\\CM3_C VS_SourceTree -DCM3_VERSION_TEXT=d5.5.1 -DCM3_VERSION_NUMBER=050501 -DCM3_LAST_C HANGED=2007-12-30" +++ --- building in NT386 --- ignoring ..\src\m3overrides "C:\CM3_CVS_SourceTree\m3-sys\cm3\src\version.quake", line 136: quake runtime er ror: unable to open "C:\CM3_CVS_SourceTree\m3-sys\cm3\src\../NT386.datenow" for reading --procedure-- -line- -file--- include -- version_impl 136 C:\CM3_CVS_SourceTree\m3-sys\cm3\src\version.quake include_dir 20 C:\CM3_CVS_SourceTree\m3-sys\cm3\src\m3makefile 8 C:\CM3_CVS_SourceTree\m3-sys\cm3\NT386\m3make.args Fatal Error: package build failed ERROR: "cm3 -build -DROOT=C:\\CM3_CVS_SourceTree -DCM3_VERSION_TEXT=d5.5.1 -DCM 3_VERSION_NUMBER=050501 -DCM3_LAST_CHANGED=2007-12-30 && cm3 -ship -DROOT=C:\\CM 3_CVS_SourceTree -DCM3_VERSION_TEXT=d5.5.1 -DCM3_VERSION_NUMBER=050501 -DCM3_LAS T_CHANGED=2007-12-30" ERROR: cd C:\CM3_CVS_SourceTree\m3-sys\cm3 ERROR: set INSTALLROOT=c:\cm3 Regards, Randy Share life as it happens with the new Windows Live. Start sharing! ( http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_012008 ) Put your friends on the big screen with Windows Vista* + Windows LiveT. Start now! ( http://www.microsoft.com/windows/shop/specialoffers.mspx?ocid=TXT_TAGLM_CPC_MediaCtr_bigscreen_012008 ) Get the power of Windows + Web with the new Windows Live. Get it now! ( http://www.windowslive.com/?ocid=TXT_TAGHM_Wave2_powerofwindows_012008 ) Make distant family not so distant with Windows Vista* + Windows Live*. Start now! ( http://www.microsoft.com/windows/digitallife/keepintouch.mspx?ocid=TXT_TAGLM_CPC_VideoChat_distantfamily_012008 ) -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Wed Jan 16 22:42:04 2008 From: jayk123 at hotmail.com (Jay) Date: Wed, 16 Jan 2008 21:42:04 +0000 Subject: [M3devel] my status on win32 In-Reply-To: <478E2908.1E75.00D7.1@scires.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> <477EA137.1E75.00D7.1@scires.com> <478D394B.1E75.00D7.1@scires.com> <478D47FB.1E75.00D7.1@scires.com> <478DBF8D.1E75.00D7.1@scires.com> <478DE973.1E75.00D7.1@scires.com> <478E2908.1E75.00D7.1@scires.com> Message-ID: Regarding temp, I find that cm3 doesn't delete the response files qk, qk_1, etc. so I have modified cm3.cfg/NT386/NT386GNU to write the response files into the output directory, so they will be reliably cleaned up at some point. That /might/ divorce cm3 from all interactions with TEMP/TMP. It was tricky, because mklib demands newlines in the response file, spaces aren't adequate, and arglist doesn't always write a response file, such as for short command lines, and the command lines are nested lists, which don't seem to flatten like the docs say, I could find no way to flatten them. When I get back home I think I'll send all my diffs and hope for one big approval and then submit them. Maybe I'll figure out the NT386GNU runtime crash before that. - Jay Date: Wed, 16 Jan 2008 15:55:51 -0500From: rcoleburn at scires.comTo: m3devel at elegosoft.com; jayk123 at hotmail.comSubject: RE: [M3devel] my status on win32 Jay: Thanks for your reply. I think most of your goals seem reasonable and I concur that there are nasty problems introduced by spaces and short names. It's a messy situation that neither you nor I created. I was just relaying some of my prior experience in getting things to work. Indeed, for me, I try to avoid spaces always. That's one reason I root my cm3 at "C:\cm3" instead of in "C:\Program Files\cm3" or "C:\Documents and Settings\userhome\cm3". I've noted that with the various Visual Studio and Visual C tools going back for some time now that after you install it, your environment vars for TEMP and TMP get changed to use short names without spaces, so I guess even Microsoft has trouble with spaces. I also recall in the past with cm3 having trouble if my TEMP and TMP vars included spaces, so having Microsoft switch them to use short names without spaces seemed to solve that cm3 problem at least. As for the VC installation, I too recall that on some prior versions it asked you whether you wanted to set the environment vars permanently or to use vcvars. This time, when I installed Visual Studio 2008, it did not ask this question, so I guess it is version dependant. I'm not at the machine right now where I did the install, but later tonight I'll check to see if the VS2008 install set any permanent environment vars. Again, for me, I would like to be able to build everything as the first step in my series of tests. As soon as you can give me a fix to make things build, I can move on to make more progress. Thanks for your help. Regards, Randy>>> Jay 1/16/2008 2:13 PM >>>Hi Randy. I mostly agree and understand.Go ahead with your installer work. :) #2 is no longer needed. The cm3.cfg I use, that is checked in, that is in the newer distributions, just runs plain "cl" and links to plain "kernel32.dll", and doesn't pass any /I switches to cl => therefore it depends on %PATH%, %LIB%, and %INCLUDE%. As I was saying/rambling, we/I can probably teach cm3 a bit so as to not need vcvars.As I recall, but I need to check, when you install VC, there are some variables it sets unconditionally, and some it asks the user if they should be set. The ones it asks about are PATH, LIB, INCLUDE. The ones it sets unconditionally are the "root" of the install. PATH / LIB / INCLUDE are more invasive, more impactful, have more potential to break things. They are also easily derived from the "root". Similarly, the CM3 installer could ask the user if it is ok to modify their %PATH%, and do it in the registry and set the WM_INI_CHANGED or such message so that Explorer picks it up. Need to check MSDN on this. Forward slashes are fine for options. I take a dim view of these space, quoting, escaping issues.I have very mixed experience here. In SOME situations, your command lines pass through various layers of code, with various attempts to handle or ignore the various issues. The result is in my opinion an unpredictable mess.The problem is that people have confused "an array of strings" with "one flat string". At this point the confusion is widespread and deeply ingrained. On Unix I believe people just ignore the issue by not using spaces (or quotes?) on the command line, though escaping issues still remain for other characters. You just have to read the documenation on CreateProcess to realize how messed up this is.c:\program files\foo I believe is interpreted multiple ways until something works.It can be running c:\program with the parameter files\foo, or it can be running c:\program files\foo. Reliable interprocess communication should not be via command lines but via something more strongly typed such as RPC or shared memory or reading/writing a Pickle. I use the command line a lot, and I frequently copy paths from the command line and paste them into the file open dialog, which does not accept forward slashes nor nested double slashes. It should but oh well. Therefore I have goal before much longer to ensure that every path generated and probably reported by cm3 is in the "normal" form. If the user types in a forward slash, perhaps that should be reported back though. And forward slashes should be ok to enter and then get used internally. The need to configure short file names are gone, along with the need to quote them, by virtue of the dependency on environment variables. Paths with spaces can still come in other ways, but not via SYSTEM_CC in a "normal" cm3, for my newfangled revisionist version of "normal". :) Short names really stink, in so many ways.First, they aren't necessary even shorter, they are just of a limited character set.They can be up to twice as long as "long".Try this: mkdir \1.1.1. dir /x 1* Also, wildcard matching "always" (in FindFirstFile/FindNextFile) operates against both long and short, and since short are unpredcitable, wildcard matching therefore is. An example, probably, is: echo > foo.barecho > food.barfdir *.bar Will probably, but not necessarily, match both files, though you would only expect one match. As well, I don't believe short file names have always been backed up and restored -- for anyone that uses any backup softwre (not me!). So you determine your short name, you backup and restore, and it changes. Or more clearly, recreating files, might get a different name.It's a mess. I would discourage you from persisting short names ever.Names with spaces I discourage but not as strong.For example, in some contexts, there is just one name and there is no ambiguity.Actually in %PATH% there is no ambiguity because the sepArator is the semicolon.I think Win9x different though, sigh. I agree from my "min" distribution, you need to build the rest.I have to admit, I thought the "culture" on this list was to want to and actually build the system from source.I will put a "std" distribution up on birch this week hopefully and hopefully someone will put it on the web page. Maintaining the installer should not be a problem.As long as the licensing and cost and all is right. I have not fixed the build yet, sorry. - Jay Date: Wed, 16 Jan 2008 11:24:34 -0500From: rcoleburn at scires.comTo: m3devel at elegosoft.com; jayk123 at hotmail.comSubject: Re: [M3devel] my status on win32 Jay: Not sure I've clued in to all of your dialog. Sorry. I have in the past used a free tool to build an installer package and I was thinking of using it again. Since the tool is free, we could put all the work I do into the CVS repository so that others could also maintain it. What I am looking to achieve is to have a way where a "normal" Windows user could download a program, run it, and have all of the cm3 packages installed without having to use the MIN distribution to build it up or any other tools to get the sources (like cvs). You could achieve the same thing by having a big ZIP file also I suppose, but having the installer would also let us easily put something in the start menu to launch a command line with all the environment variables set properly via automatic call to vcvars et al. When I get "Reactor" working, it too could be put into the start menu. That just makes it fit in better with the Windows user culture I think. The reason I wanted to rebuild everything is two-fold: 1) ensure it can be done (i.e., test for "Broken #1"), and 2) get all of the rest of the packages built so I could then use cm3 to build "reactor" and my own programs and test them to see if there are any "Broken #2" issues. The MIN distribution is really insufficient to do much of anything except to build the rest of the packages you need. My understanding is that I needed to use CVS to get the current sources, because if I went back to the source archive, it was old and known to be Broken #1 on Windows. I'm glad that you believe the current "Broken #1" situation is easy to fix. Let me know what to do and I'll give it another try. My experience in the past has been that there are 3 conditions to getting cm3 to work properly on windows after it has been installed: 1) make sure your environment variables are set up by vcvars to point to the compiler/linker/libraries (of course if you used a non-Microsoft C compiler/linker you would need to use something other than vcvars); 2) make sure cm3.cfg has the right paths in place to find all the libraries and tools using DOS style short names (no embedded spaces); and 3) make sure C:\cm3\bin is in your path. Of these, #2 & #3 are essentially one-time events, and #1 can be set up by a invoking a batch/command file via a shortcut, so no big deal for me. You could even make #1 a one-time event by modifying the system-level (vice user-level) environment variables. The old cm3install program seemed to do a decent job of #2 for me. Also, I've noted some of your past dialog about accepting either '/' or '\' as a path separator. I'm sure you are aware that on Windows '/' is used often for switches (arguments). Plus Windows also allows spaces to be embedded in the command line, so whatever solution you propose needs to take into account that a valid command line might look like this: C:\My Program Folder\My Program.exe /myArg1 /myArg2 In some situations, this command line would have to be quoted and rendered as: "C:\My Program Folder\My Program.exe" /myArg1 /myArg2 and in places where the backslash is an escape character, I've seen "C:\\My Program Folder\\My Program.exe" /myArg1 /myArg2 Alas, I seem to have rambled a bit also. Sorry. The immediate need for me now is to solve the Broken #1 condition, so please let me know how to fix it and proceed. Regards, Randy>>> Jay 1/16/2008 10:28 AM >>>Randy, yes and no and clarifications. I mention starting with 5.1.6 as a "worst" or "worse" case.The earlier you start, the harder things are -- for me, to ensure it will work. If you merely start with my 5.5.0, well, what are you rebuilding from source for?Heck, you can use any binary distribution, 4.1, 5.1.6, and just use it. They should work. The n steps you/I give are really actually geared for people who WANT to build from source, it is not what people HAVE to do.As well there have been can be source distributions, to cut out CVS. I'll look into the datefn stuff shortly. As to the installer, well, again, yes and no.The need for the installer is very small. All you have to do today is unzip the .zip somewhere and set the path, and possibly the vcvars thing. That's it. I should..now that you are "pressuring" me for ease of use, teach cm3 about the various ?venvdir%, %vcinstalldir% variables, etc. That way as long as the user installed the tools, even if they elected not to change path/lib/include, cm3 can find the compiler and linker. I know everyone wants to preserve the flexibility of quake/cm3.cfg but...besides, cm3 can be pretty darn smart here. IF cm3.cfg defines SYSTEM_CC, leave things along (NT386 cm3.cfg does not today do that). However if there is now SYSTEM_CC and there is no cl.exe/link.exe in %PATH%, it could go on a quick hunt for them. On the lib and include part, well, the dependency on %include% might only be for errno..maybe not worth it. It has been whatever it is forever, like int* _errno(void); #define errno (*_errno)()). Modula-3 engages in rampant header cloning and CErrnoC was only introduced where that was deemed more fragile than usual, and for Windows it probably wasn't actually fragile -- the fragility, if I may be so rudely judgemental, is because so many other systems are so Johnny-come-lately to arriving at the obviously correct threading model that Windows has had all along (since Win95/NT, can't say anything good about Win3.1; I think OS/2 might have had it correct all along too.). Funny, everyone has FINALLY arrived at the correct threading model, only to have start changing again, since the number of cores and machines is set to be much greater than anticipated, the obvious threading model has been deemed too difficult for anyone to use (Win32, Modula-3, Java, .NET, Python, all the same supposedly too difficult model btw), and so some new one is needed, and well, truthfully, the difficulty is not just for dummies on relatively small multiproc boxes not having simple race conditions, the problem is scaling way way up. Sorry that was my usual tangential. Even the unzip and set path would benefit slightly from a GUI installer.I believe there is some easy thing you can do where you write your GUI installer and you put it in the .zip and then you prepend the GUI self extracting .zip/.exe stub, and you can tell it to run a particular command after the extraction. I guess you might use a fancier thing though?That is, are you going to, say, write a gui installer from scratch in Modula-3? It might be a fun exercise. :)And then you could build the self extracting prefix from source etc.This is the hard way I guess, but more interesing.If you can build an msi or use InstallShield or Wix or something, go ahead.If you use widely availabe free as in beer tools, that can be rolled into whatever automation there is to produce distributions, keeping it up to date shouldn't be a problem. I do have to bring up some annoying questions: 1) Does anyone besides me have the capacity to produce distributions? i.e.: Any Win32 machines left at Elego? 2) I know I ramble. So one of my many tangents/questions went unanswered.Say, in the absence of a gui installer, should .zips/.tar.bz files look like cm3-min-/bin/cm3orbin/cm3orcm3/bin/cm3 The last one is more directly usable. The first one is very common. This reminds me though Randy, the distribution I made available was "min", so yeah, like if you are doing any gui programming, using any "standard" library besides m3core or libm3, you'd need to build more from source. I can readily provide you a "std" distribution though.It's "always" been a "problem" to make my files available -- no web site hosting for me -- but recently that wasn't a problem, someone picked the files out of ~jkrell on birch and put them on the web site. Good. One more thing -- Olaf, please confirm repeat yourself, 'cause I admit I wasn't sure it was the right thing, but if you insist, ok. "std" should be "all"? I should not continue to imagine there is a new larger group called "all"? And wherever things are missing from std but do build ok, add them?m3cc should be in std?(I admit some big indecisiveness around m3cc. It is far and away the longest thing to build and so the one you really want to skip the most and leave out of whatever package group. I also wonder if on Windows, there should be some check where if sh is not in the $PATH, just silently skip m3cc? You only need MingWin to build what I have on my system for NT386GNU, except you also need msys just for m3cc. msys is actually quite small, like only 20 files..) Oh, sorry, yet another question.The non-gcc backend is excluded from the build on systems that use the gcc backend.For minimization, that is appropriate.For maximizing cross build capability, it is wrong.The packages build fine. I suspect they work.I am not a user of cross build capability yet, so I don't really care. (What I do for NT386/NT386GNU /might/ be considered sort of a cross build, but it is different/easier).They are small packages. - Jay Date: Wed, 16 Jan 2008 08:25:49 -0500From: rcoleburn at scires.comTo: m3devel at elegosoft.com; jayk123 at hotmail.comSubject: Re: [M3devel] my status on win32 Jay: There is no line in the m3makefile dealing with datefn, so I added the whole statement just before the line include("version.quake") Now, I get an error saying that the variable datefn is not defined. If you change to put quotes around datefn in the include statement, you get an error saying it can't open the file. You made a reference in one of your earlier posts about trying 5.1.6 or 4.1, but note that I started with your cm3-min-WIN32-NT386-d5.5.0.zip , not the 5.1.6 or 4.1 versions. Thus, using d5.5.0 as a base, I am trying to run your "upgrade.cmd" to rebuild the sources I checked out from CVS. Since this doesn't work "out-of-the-box", again I say this fits into the "Broken #1" category. If I can get this to work, I don't mind putting together a Windows installer program that will install the whole thing. That way, folks won't have to install cygwin just to get CVS so that they can install a working cm3. Folks will need to install the free Microsoft Visual C as a prerequisite, but then that's not too bad. Having an installer program would make cm3 more friendly to Windows folks. The current 16-step method is too laborious and error-prone for the person just getting started and they will not give cm3 a second try. As the cm3 system evolves and new releases are made, we will need to keep the installer program up-to-date and I don't mind doing that. After someone gets familiar with cm3 they might want to delve into some of the scripts for rebuilding the system, but until then, I think the installer program is the way to go. Regards, Randy>>> Jay 1/16/2008 1:01 AM >>>I think I see the problem. in cm3\src\m3makefile, make this change > if not defined("NOW") include(datefn) > end datefn is only created if certain other variables aren't defined, and do-pkg defines them.I don't know why I don't see this. Later.Could be that the Python scripts have a typo and don't define them.I've been using them more than cmd. If the host is NT, "NOW" is either gotten from an updated cm3.exe, or left to "not available". So the initial cm3 built from older cm3 can't report when it was built, but cm3 built from current cm3 can. I need to change that: 1) to be a function for niceness 2) to make it that way for Posix, for any host but I haven't been using Posix as much lately so not testing it. - Jay Date: Tue, 15 Jan 2008 23:55:39 -0500From: rcoleburn at scires.comTo: m3devel at elegosoft.com; jayk123 at hotmail.comSubject: RE: my status on win32 Jay: In the file version.quake, I made the following edit: changed line: local datefn = "../" & TARGET & ".datenow" to: local datefn = ".." & SL & TARGET & ".datenow" This change has the effect of putting a backward slash in the pathname instead of a forward slash, so we getC:\CM3_CVS_SourceTree\m3-sys\cm3\src\..\NT386.datenow So from that perspective, the change seems good. Unfortunately, I still get the error that this file can't be opened. A quick check of C:\CM3_CVS_SourceTree\m3-sys\cm3\NT386 shows that the file .datenow does not exist. Regards, Randy>>> Jay 1/15/2008 11:03 PM >>>That's not too bad really. 1) I'd recommend putting cm3 at the start of the path instead of the end. 2) Just comment out the offending code to make progress. It's not critical. >> C:\CM3_CVS_SourceTree\m3-sys\cm3\src\../NT386.datenow The code is: C:\CM3_CVS_SourceTree\m3-sys\cm3\src\version.quake or such, included by cm3\src\m3makefile. Does the file exist?Does version.quake use "/" or "SL"? If it uses "/", try replacing with SL (and ampersand for string concat). Could be that a newer binary distributions works better with forward slashes. > 4. > 5. > 6. Launch cygwin from desktop icon. Cygwin is only needed for cvs, I think you realize. Could you send me offline the result of just running "set" after running vcvarsall? I'd like to adapt pylib.py to it maybe. (I can start from 5.1.6 and will try 4.1 at some point.) - Jay Date: Tue, 15 Jan 2008 22:52:59 -0500From: rcoleburn at scires.comTo: m3devel at elegosoft.com; jayk123 at hotmail.comSubject: my status on win32 Jay et al: I've listed below the steps I've undertaken to try and build the current sources on Windows XP. I've also attached a text file showing the output I got when trying to build everything using Jay's upgrade.cmd script. Unfortunately, I'm getting a build error (see below). Please advise on how to resolve. STEPS I TOOK: ========= 1. Download Microsoft Visual Studio 2008 Express Edition All-in-One .ISO file and burn to DVD. http://www.microsoft.com/express/download/ 2. Install Microsoft Visual C++ 2008 Express Edition from DVD. 3. Use "Microsoft Update" service to check for updates / service packs. 4. Download cygwin setup program from http://cygwin.com/ 5. Ran cygwin setup.exe program to install cygwin for all users. Under "Devel" category, make certain to select "cvs" for installation. 6. Launch cygwin from desktop icon. 7. In cygwin command shell window, execute following two commands, making sure to give email as password when prompted for login: cvs -d :pserver:anonymous at modula3.elegosoft.com:/usr/cvs login cvs -d :pserver:anonymous at modula3.elegosoft.com:/usr/cvs checkout cm3 8. Moved resulting C:\cygwin\home\rcoleburn\cm3 to C:\CM3_CVS_SourceTree Note that you should replace "rcoleburn" above with your Windows login username. 9. Download cm3-min-WIN32-NT386-d5.5.0.zip and cm3-min-WIN32-NT386-d5.5.0-symbols.zip from http://modula3.elegosoft.com/cm3/download.html 10. Unzipped cm3-min-WIN32-NT386-d5.5.0.zip and stored resulting cm3 folder at C:\cm3 11. Unzipped cm3-min-WIN32-NT386-d5.5.0-symbols.zip and stored resulting symbols folder at C:\cm3\symbols 12. Launch Windows Command Prompt shell. The following steps represent commands executed within this shell. 13. path %path%;c:\cm3\bin 14. "C:\Program Files\Microsoft Visual Studio 9.0\VC\vcvarsall.bat" 15. cd C:\CM3_CVS_SourceTree\scripts\win 16. upgrade.cmd ERROR I'M GETTING: ============= === package C:\CM3_CVS_SourceTree\m3-sys\cm3 ===+++ "cm3 -build -DROOT=C:\\CM3_CVS_SourceTree -DCM3_VERSION_TEXT=d5.5.1 -DCM3_VERSION_NUMBER=050501 -DCM3_LAST_CHANGED=2007-12-30 && cm3 -ship -DROOT=C:\\CM3_CVS_SourceTree -DCM3_VERSION_TEXT=d5.5.1 -DCM3_VERSION_NUMBER=050501 -DCM3_LAST_CHANGED=2007-12-30" +++--- building in NT386 --- ignoring ..\src\m3overrides "C:\CM3_CVS_SourceTree\m3-sys\cm3\src\version.quake", line 136: quake runtime error: unable to open "C:\CM3_CVS_SourceTree\m3-sys\cm3\src\../NT386.datenow" forreading --procedure-- -line- -file---include -- version_impl 136 C:\CM3_CVS_SourceTree\m3-sys\cm3\src\version.quakeinclude_dir 20 C:\CM3_CVS_SourceTree\m3-sys\cm3\src\m3makefile 8 C:\CM3_CVS_SourceTree\m3-sys\cm3\NT386\m3make.args Fatal Error: package build failedERROR: "cm3 -build -DROOT=C:\\CM3_CVS_SourceTree -DCM3_VERSION_TEXT=d5.5.1 -DCM3_VERSION_NUMBER=050501 -DCM3_LAST_CHANGED=2007-12-30 && cm3 -ship -DROOT=C:\\CM3_CVS_SourceTree -DCM3_VERSION_TEXT=d5.5.1 -DCM3_VERSION_NUMBER=050501 -DCM3_LAST_CHANGED=2007-12-30"ERROR: cd C:\CM3_CVS_SourceTree\m3-sys\cm3ERROR: set INSTALLROOT=c:\cm3 Regards, Randy Share life as it happens with the new Windows Live. Start sharing! Put your friends on the big screen with Windows Vista? + Windows LiveT. Start now! Get the power of Windows + Web with the new Windows Live. Get it now! Make distant family not so distant with Windows Vista? + Windows LiveT. Start now! _________________________________________________________________ Put your friends on the big screen with Windows Vista? + Windows Live?. http://www.microsoft.com/windows/shop/specialoffers.mspx?ocid=TXT_TAGLM_CPC_MediaCtr_bigscreen_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Wed Jan 16 22:44:02 2008 From: jayk123 at hotmail.com (Jay) Date: Wed, 16 Jan 2008 21:44:02 +0000 Subject: [M3devel] my status on win32 In-Reply-To: <20080116215332.ds4sfixao84g4wk4@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> <477EA137.1E75.00D7.1@scires.com> <478D394B.1E75.00D7.1@scires.com> <478D47FB.1E75.00D7.1@scires.com> <478DBF8D.1E75.00D7.1@scires.com> <20080116215332.ds4sfixao84g4wk4@mail.elegosoft.com> Message-ID: When I get home I don't fall right to sleep... It's been building fine for me... Which reminds me. Randy, just cd over to m3-sys\cm3 and run either: cm3 or cm3 -DROOT= That might work. More likely the second. The problem is possibly related to "scripts". - Jay > Date: Wed, 16 Jan 2008 21:53:32 +0100> From: wagner at elegosoft.com> To: jayk123 at hotmail.com> CC: rcoleburn at scires.com; m3devel at elegosoft.com; m3-support at elego.de> Subject: Re: [M3devel] my status on win32> > Quoting Jay :> > > Yes I agree it is "broken #1" and shouldn't be this way, but I > > assure you, really, your results are 99% there. What isn't working > > is minor and easy to fix and much is working.> > Jay, could you please just fix the cm3 package so that it compiles> without problems in NT386(GNU), too? It should not be too difficult;> there are no problems on the POSIX platforms.> > As for other installers or installation packages, I'm not against them,> it is just that somebody must take responsibility and maintain them> and keep them up-to-date. I for sure cannot contribute the efforts> needed to maintain different installation variants for different> targets. It has been much work to get everything working as it is.> I'd be very careful with any changes that might have impacts on the> system and installation structures. Everything will have to be tested> on every platform afterwards, and my experience says that at least> half will break regardless how careful you tried to be.> > For the integrity of the system itself, the regression test suite> we've now setup will be a great help in my opinion.> > Olaf> -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194> _________________________________________________________________ Get the power of Windows + Web with the new Windows Live. http://www.windowslive.com?ocid=TXT_TAGHM_Wave2_powerofwindows_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Thu Jan 17 12:35:00 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 17 Jan 2008 12:35:00 +0100 Subject: [M3devel] About permissions on sources in the case of sources with permissions for owner only In-Reply-To: References: <998919.97099.qm@web27103.mail.ukl.yahoo.com> Message-ID: <20080117123500.hdmex004is48wook@mail.elegosoft.com> Late follow-up: Quoting Henning Thielemann : > On Wed, 17 Oct 2007, Daniel Alejandro Benavides D. wrote: > >> I got a commentary about files produced by the compiler and the >> files exported to the repository (ship) >> When compiling a package (bilist present on directory list of >> http://users.informatik.uni-halle.de/~thielema/Research/datastruct.tar.bz2 >> ) that has read and write permissions only for the owner >> I got files in LINUXLIBC6 that are readable for the group and other users. >> But when shipped on the 'src' directory they 're just readable for >> the owner (root). > > This is a general problem, not bound to BiList. > > As a work-around I wrote a script which corrects permissions after the > installation. > > $ more cm3ship > cm3 -ship > (chmod -R a+r /usr/local/cm3/pkg ; chmod a+x `find > /usr/local/cm3/pkg -type d`) & > > However, I do not want to call it 'solution'. This has bothered me several times, too. If the user's umask is set wrong, other's won't be able to change his installations. It can both be seen as a bug or a feature though. Today we leave all the permission settings to the OS. At least on POSIX the builder could set the group bit or just apply its own umask (defined in cm3.cfg). I don't know what to do on Windows, though; and on POSIX systems ACLs are used more and more. What do other's think: do we want to add some support for permissions wrt. team working? Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From lemming at henning-thielemann.de Thu Jan 17 12:38:15 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Thu, 17 Jan 2008 12:38:15 +0100 (MET) Subject: [M3devel] About permissions on sources in the case of sources with permissions for owner only In-Reply-To: <20080117123500.hdmex004is48wook@mail.elegosoft.com> References: <998919.97099.qm@web27103.mail.ukl.yahoo.com> <20080117123500.hdmex004is48wook@mail.elegosoft.com> Message-ID: On Thu, 17 Jan 2008, Olaf Wagner wrote: > Late follow-up: > > Quoting Henning Thielemann : > > On Wed, 17 Oct 2007, Daniel Alejandro Benavides D. wrote: > > > >> I got a commentary about files produced by the compiler and the > >> files exported to the repository (ship) > >> When compiling a package (bilist present on directory list of > >> http://users.informatik.uni-halle.de/~thielema/Research/datastruct.tar.bz2 > >> ) that has read and write permissions only for the owner > >> I got files in LINUXLIBC6 that are readable for the group and other users Is this a problem specific to my datastruct package? From wagner at elegosoft.com Thu Jan 17 13:34:46 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 17 Jan 2008 13:34:46 +0100 Subject: [M3devel] About permissions on sources in the case of sources with permissions for owner only In-Reply-To: References: <998919.97099.qm@web27103.mail.ukl.yahoo.com> <20080117123500.hdmex004is48wook@mail.elegosoft.com> Message-ID: <20080117133446.c0klnluuqs08wc48@mail.elegosoft.com> Quoting Henning Thielemann : > On Thu, 17 Jan 2008, Olaf Wagner wrote: > >> Late follow-up: >> >> Quoting Henning Thielemann : >> > On Wed, 17 Oct 2007, Daniel Alejandro Benavides D. wrote: >> > >> >> I got a commentary about files produced by the compiler and the >> >> files exported to the repository (ship) >> >> When compiling a package (bilist present on directory list of >> >> >> http://users.informatik.uni-halle.de/~thielema/Research/datastruct.tar.bz2 >> >> ) that has read and write permissions only for the owner >> >> I got files in LINUXLIBC6 that are readable for the group and other users > > Is this a problem specific to my datastruct package? No, it's a general problem; I was just following up to an old mail. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Jan 18 16:32:21 2008 From: jayk123 at hotmail.com (Jay) Date: Fri, 18 Jan 2008 15:32:21 +0000 Subject: [M3devel] my status on win32 In-Reply-To: <478DE973.1E75.00D7.1@scires.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> <477EA137.1E75.00D7.1@scires.com> <478D394B.1E75.00D7.1@scires.com> <478D47FB.1E75.00D7.1@scires.com> <478DBF8D.1E75.00D7.1@scires.com> <478DE973.1E75.00D7.1@scires.com> Message-ID: Randy, please try with an updated m3-sys/cm3/src/version.quake and report back, thanks. I understand why I wasn't seeing this. - Jay Date: Wed, 16 Jan 2008 11:24:34 -0500From: rcoleburn at scires.comTo: m3devel at elegosoft.com; jayk123 at hotmail.comSubject: Re: [M3devel] my status on win32 Jay: Not sure I've clued in to all of your dialog. Sorry. I have in the past used a free tool to build an installer package and I was thinking of using it again. Since the tool is free, we could put all the work I do into the CVS repository so that others could also maintain it. What I am looking to achieve is to have a way where a "normal" Windows user could download a program, run it, and have all of the cm3 packages installed without having to use the MIN distribution to build it up or any other tools to get the sources (like cvs). You could achieve the same thing by having a big ZIP file also I suppose, but having the installer would also let us easily put something in the start menu to launch a command line with all the environment variables set properly via automatic call to vcvars et al. When I get "Reactor" working, it too could be put into the start menu. That just makes it fit in better with the Windows user culture I think. The reason I wanted to rebuild everything is two-fold: 1) ensure it can be done (i.e., test for "Broken #1"), and 2) get all of the rest of the packages built so I could then use cm3 to build "reactor" and my own programs and test them to see if there are any "Broken #2" issues. The MIN distribution is really insufficient to do much of anything except to build the rest of the packages you need. My understanding is that I needed to use CVS to get the current sources, because if I went back to the source archive, it was old and known to be Broken #1 on Windows. I'm glad that you believe the current "Broken #1" situation is easy to fix. Let me know what to do and I'll give it another try. My experience in the past has been that there are 3 conditions to getting cm3 to work properly on windows after it has been installed: 1) make sure your environment variables are set up by vcvars to point to the compiler/linker/libraries (of course if you used a non-Microsoft C compiler/linker you would need to use something other than vcvars); 2) make sure cm3.cfg has the right paths in place to find all the libraries and tools using DOS style short names (no embedded spaces); and 3) make sure C:\cm3\bin is in your path. Of these, #2 & #3 are essentially one-time events, and #1 can be set up by a invoking a batch/command file via a shortcut, so no big deal for me. You could even make #1 a one-time event by modifying the system-level (vice user-level) environment variables. The old cm3install program seemed to do a decent job of #2 for me. Also, I've noted some of your past dialog about accepting either '/' or '\' as a path separator. I'm sure you are aware that on Windows '/' is used often for switches (arguments). Plus Windows also allows spaces to be embedded in the command line, so whatever solution you propose needs to take into account that a valid command line might look like this: C:\My Program Folder\My Program.exe /myArg1 /myArg2 In some situations, this command line would have to be quoted and rendered as: "C:\My Program Folder\My Program.exe" /myArg1 /myArg2 and in places where the backslash is an escape character, I've seen "C:\\My Program Folder\\My Program.exe" /myArg1 /myArg2 Alas, I seem to have rambled a bit also. Sorry. The immediate need for me now is to solve the Broken #1 condition, so please let me know how to fix it and proceed. Regards, Randy>>> Jay 1/16/2008 10:28 AM >>>Randy, yes and no and clarifications. I mention starting with 5.1.6 as a "worst" or "worse" case.The earlier you start, the harder things are -- for me, to ensure it will work. If you merely start with my 5.5.0, well, what are you rebuilding from source for?Heck, you can use any binary distribution, 4.1, 5.1.6, and just use it. They should work. The n steps you/I give are really actually geared for people who WANT to build from source, it is not what people HAVE to do.As well there have been can be source distributions, to cut out CVS. I'll look into the datefn stuff shortly. As to the installer, well, again, yes and no.The need for the installer is very small. All you have to do today is unzip the .zip somewhere and set the path, and possibly the vcvars thing. That's it. I should..now that you are "pressuring" me for ease of use, teach cm3 about the various ?venvdir%, %vcinstalldir% variables, etc. That way as long as the user installed the tools, even if they elected not to change path/lib/include, cm3 can find the compiler and linker. I know everyone wants to preserve the flexibility of quake/cm3.cfg but...besides, cm3 can be pretty darn smart here. IF cm3.cfg defines SYSTEM_CC, leave things along (NT386 cm3.cfg does not today do that). However if there is now SYSTEM_CC and there is no cl.exe/link.exe in %PATH%, it could go on a quick hunt for them. On the lib and include part, well, the dependency on %include% might only be for errno..maybe not worth it. It has been whatever it is forever, like int* _errno(void); #define errno (*_errno)()). Modula-3 engages in rampant header cloning and CErrnoC was only introduced where that was deemed more fragile than usual, and for Windows it probably wasn't actually fragile -- the fragility, if I may be so rudely judgemental, is because so many other systems are so Johnny-come-lately to arriving at the obviously correct threading model that Windows has had all along (since Win95/NT, can't say anything good about Win3.1; I think OS/2 might have had it correct all along too.). Funny, everyone has FINALLY arrived at the correct threading model, only to have start changing again, since the number of cores and machines is set to be much greater than anticipated, the obvious threading model has been deemed too difficult for anyone to use (Win32, Modula-3, Java, .NET, Python, all the same supposedly too difficult model btw), and so some new one is needed, and well, truthfully, the difficulty is not just for dummies on relatively small multiproc boxes not having simple race conditions, the problem is scaling way way up. Sorry that was my usual tangential. Even the unzip and set path would benefit slightly from a GUI installer.I believe there is some easy thing you can do where you write your GUI installer and you put it in the .zip and then you prepend the GUI self extracting .zip/.exe stub, and you can tell it to run a particular command after the extraction. I guess you might use a fancier thing though?That is, are you going to, say, write a gui installer from scratch in Modula-3? It might be a fun exercise. :)And then you could build the self extracting prefix from source etc.This is the hard way I guess, but more interesing.If you can build an msi or use InstallShield or Wix or something, go ahead.If you use widely availabe free as in beer tools, that can be rolled into whatever automation there is to produce distributions, keeping it up to date shouldn't be a problem. I do have to bring up some annoying questions: 1) Does anyone besides me have the capacity to produce distributions? i.e.: Any Win32 machines left at Elego? 2) I know I ramble. So one of my many tangents/questions went unanswered.Say, in the absence of a gui installer, should .zips/.tar.bz files look like cm3-min-/bin/cm3orbin/cm3orcm3/bin/cm3 The last one is more directly usable. The first one is very common. This reminds me though Randy, the distribution I made available was "min", so yeah, like if you are doing any gui programming, using any "standard" library besides m3core or libm3, you'd need to build more from source. I can readily provide you a "std" distribution though.It's "always" been a "problem" to make my files available -- no web site hosting for me -- but recently that wasn't a problem, someone picked the files out of ~jkrell on birch and put them on the web site. Good. One more thing -- Olaf, please confirm repeat yourself, 'cause I admit I wasn't sure it was the right thing, but if you insist, ok. "std" should be "all"? I should not continue to imagine there is a new larger group called "all"? And wherever things are missing from std but do build ok, add them?m3cc should be in std?(I admit some big indecisiveness around m3cc. It is far and away the longest thing to build and so the one you really want to skip the most and leave out of whatever package group. I also wonder if on Windows, there should be some check where if sh is not in the $PATH, just silently skip m3cc? You only need MingWin to build what I have on my system for NT386GNU, except you also need msys just for m3cc. msys is actually quite small, like only 20 files..) Oh, sorry, yet another question.The non-gcc backend is excluded from the build on systems that use the gcc backend.For minimization, that is appropriate.For maximizing cross build capability, it is wrong.The packages build fine. I suspect they work.I am not a user of cross build capability yet, so I don't really care. (What I do for NT386/NT386GNU /might/ be considered sort of a cross build, but it is different/easier).They are small packages. - Jay Date: Wed, 16 Jan 2008 08:25:49 -0500From: rcoleburn at scires.comTo: m3devel at elegosoft.com; jayk123 at hotmail.comSubject: Re: [M3devel] my status on win32 Jay: There is no line in the m3makefile dealing with datefn, so I added the whole statement just before the line include("version.quake") Now, I get an error saying that the variable datefn is not defined. If you change to put quotes around datefn in the include statement, you get an error saying it can't open the file. You made a reference in one of your earlier posts about trying 5.1.6 or 4.1, but note that I started with your cm3-min-WIN32-NT386-d5.5.0.zip , not the 5.1.6 or 4.1 versions. Thus, using d5.5.0 as a base, I am trying to run your "upgrade.cmd" to rebuild the sources I checked out from CVS. Since this doesn't work "out-of-the-box", again I say this fits into the "Broken #1" category. If I can get this to work, I don't mind putting together a Windows installer program that will install the whole thing. That way, folks won't have to install cygwin just to get CVS so that they can install a working cm3. Folks will need to install the free Microsoft Visual C as a prerequisite, but then that's not too bad. Having an installer program would make cm3 more friendly to Windows folks. The current 16-step method is too laborious and error-prone for the person just getting started and they will not give cm3 a second try. As the cm3 system evolves and new releases are made, we will need to keep the installer program up-to-date and I don't mind doing that. After someone gets familiar with cm3 they might want to delve into some of the scripts for rebuilding the system, but until then, I think the installer program is the way to go. Regards, Randy>>> Jay 1/16/2008 1:01 AM >>>I think I see the problem. in cm3\src\m3makefile, make this change > if not defined("NOW") include(datefn) > end datefn is only created if certain other variables aren't defined, and do-pkg defines them.I don't know why I don't see this. Later.Could be that the Python scripts have a typo and don't define them.I've been using them more than cmd. If the host is NT, "NOW" is either gotten from an updated cm3.exe, or left to "not available". So the initial cm3 built from older cm3 can't report when it was built, but cm3 built from current cm3 can. I need to change that: 1) to be a function for niceness 2) to make it that way for Posix, for any host but I haven't been using Posix as much lately so not testing it. - Jay Date: Tue, 15 Jan 2008 23:55:39 -0500From: rcoleburn at scires.comTo: m3devel at elegosoft.com; jayk123 at hotmail.comSubject: RE: my status on win32 Jay: In the file version.quake, I made the following edit: changed line: local datefn = "../" & TARGET & ".datenow" to: local datefn = ".." & SL & TARGET & ".datenow" This change has the effect of putting a backward slash in the pathname instead of a forward slash, so we getC:\CM3_CVS_SourceTree\m3-sys\cm3\src\..\NT386.datenow So from that perspective, the change seems good. Unfortunately, I still get the error that this file can't be opened. A quick check of C:\CM3_CVS_SourceTree\m3-sys\cm3\NT386 shows that the file .datenow does not exist. Regards, Randy>>> Jay 1/15/2008 11:03 PM >>>That's not too bad really. 1) I'd recommend putting cm3 at the start of the path instead of the end. 2) Just comment out the offending code to make progress. It's not critical. >> C:\CM3_CVS_SourceTree\m3-sys\cm3\src\../NT386.datenow The code is: C:\CM3_CVS_SourceTree\m3-sys\cm3\src\version.quake or such, included by cm3\src\m3makefile. Does the file exist?Does version.quake use "/" or "SL"? If it uses "/", try replacing with SL (and ampersand for string concat). Could be that a newer binary distributions works better with forward slashes. > 4. > 5. > 6. Launch cygwin from desktop icon. Cygwin is only needed for cvs, I think you realize. Could you send me offline the result of just running "set" after running vcvarsall? I'd like to adapt pylib.py to it maybe. (I can start from 5.1.6 and will try 4.1 at some point.) - Jay Date: Tue, 15 Jan 2008 22:52:59 -0500From: rcoleburn at scires.comTo: m3devel at elegosoft.com; jayk123 at hotmail.comSubject: my status on win32 Jay et al: I've listed below the steps I've undertaken to try and build the current sources on Windows XP. I've also attached a text file showing the output I got when trying to build everything using Jay's upgrade.cmd script. Unfortunately, I'm getting a build error (see below). Please advise on how to resolve. STEPS I TOOK: ========= 1. Download Microsoft Visual Studio 2008 Express Edition All-in-One .ISO file and burn to DVD. http://www.microsoft.com/express/download/ 2. Install Microsoft Visual C++ 2008 Express Edition from DVD. 3. Use "Microsoft Update" service to check for updates / service packs. 4. Download cygwin setup program from http://cygwin.com/ 5. Ran cygwin setup.exe program to install cygwin for all users. Under "Devel" category, make certain to select "cvs" for installation. 6. Launch cygwin from desktop icon. 7. In cygwin command shell window, execute following two commands, making sure to give email as password when prompted for login: cvs -d :pserver:anonymous at modula3.elegosoft.com:/usr/cvs login cvs -d :pserver:anonymous at modula3.elegosoft.com:/usr/cvs checkout cm3 8. Moved resulting C:\cygwin\home\rcoleburn\cm3 to C:\CM3_CVS_SourceTree Note that you should replace "rcoleburn" above with your Windows login username. 9. Download cm3-min-WIN32-NT386-d5.5.0.zip and cm3-min-WIN32-NT386-d5.5.0-symbols.zip from http://modula3.elegosoft.com/cm3/download.html 10. Unzipped cm3-min-WIN32-NT386-d5.5.0.zip and stored resulting cm3 folder at C:\cm3 11. Unzipped cm3-min-WIN32-NT386-d5.5.0-symbols.zip and stored resulting symbols folder at C:\cm3\symbols 12. Launch Windows Command Prompt shell. The following steps represent commands executed within this shell. 13. path %path%;c:\cm3\bin 14. "C:\Program Files\Microsoft Visual Studio 9.0\VC\vcvarsall.bat" 15. cd C:\CM3_CVS_SourceTree\scripts\win 16. upgrade.cmd ERROR I'M GETTING: ============= === package C:\CM3_CVS_SourceTree\m3-sys\cm3 ===+++ "cm3 -build -DROOT=C:\\CM3_CVS_SourceTree -DCM3_VERSION_TEXT=d5.5.1 -DCM3_VERSION_NUMBER=050501 -DCM3_LAST_CHANGED=2007-12-30 && cm3 -ship -DROOT=C:\\CM3_CVS_SourceTree -DCM3_VERSION_TEXT=d5.5.1 -DCM3_VERSION_NUMBER=050501 -DCM3_LAST_CHANGED=2007-12-30" +++--- building in NT386 --- ignoring ..\src\m3overrides "C:\CM3_CVS_SourceTree\m3-sys\cm3\src\version.quake", line 136: quake runtime error: unable to open "C:\CM3_CVS_SourceTree\m3-sys\cm3\src\../NT386.datenow" forreading --procedure-- -line- -file---include -- version_impl 136 C:\CM3_CVS_SourceTree\m3-sys\cm3\src\version.quakeinclude_dir 20 C:\CM3_CVS_SourceTree\m3-sys\cm3\src\m3makefile 8 C:\CM3_CVS_SourceTree\m3-sys\cm3\NT386\m3make.args Fatal Error: package build failedERROR: "cm3 -build -DROOT=C:\\CM3_CVS_SourceTree -DCM3_VERSION_TEXT=d5.5.1 -DCM3_VERSION_NUMBER=050501 -DCM3_LAST_CHANGED=2007-12-30 && cm3 -ship -DROOT=C:\\CM3_CVS_SourceTree -DCM3_VERSION_TEXT=d5.5.1 -DCM3_VERSION_NUMBER=050501 -DCM3_LAST_CHANGED=2007-12-30"ERROR: cd C:\CM3_CVS_SourceTree\m3-sys\cm3ERROR: set INSTALLROOT=c:\cm3 Regards, Randy Share life as it happens with the new Windows Live. Start sharing! Put your friends on the big screen with Windows Vista? + Windows LiveT. Start now! Get the power of Windows + Web with the new 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 rcoleburn at scires.com Fri Jan 18 16:58:36 2008 From: rcoleburn at scires.com (Randy Coleburn) Date: Fri, 18 Jan 2008 10:58:36 -0500 Subject: [M3devel] my status on win32 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> <477EA137.1E75.00D7.1@scires.com> <478D394B.1E75.00D7.1@scires.com> <478D47FB.1E75.00D7.1@scires.com> <478DBF8D.1E75.00D7.1@scires.com> <478DE973.1E75.00D7.1@scires.com> Message-ID: <47908659.1E75.00D7.1@scires.com> Jay: Ok. It will be later tonight before I can try again. Thanks! BTW, can you point me to a document/file somewhere that describes the various options for your windows command file scripts? I did experiment further with using the do-cm3-std.cmd and was finally able to get most everything to build, but of course this doesn't rebuild the compiler and core. Had problems with mentor and m3zume not wanting to build/run, so I commented these out in the cmd file to get it to work. Then I had trouble because everything was built with overrides by default, so I had to mess around with changing parameters and rebuilding clean. I've tried building some of my programs and, of course, have run into a few problems due to changes in the system. I've overcome most of these, but I am seeing some strange behavior: 1. pixmaps aren't rendered properly on the screen. They look really bad. I recall having this problem a while back with one of the early 5.x releases, so I guess it was never solved. I've got some old test programs I try to dig out and see if I can find out what is going on. I seem to recall that building standalone in the past seemed to fix the problem, so this is a real mystery. 2. I'm having trouble with bundles not returning all of the data. In the "reactor" program, bundles are used to provide input to the web browser for the page source. I'm seeing cases where not all of the HTML source is making it to the browser. Not sure if this is an I/O problem (maybe buffers not flushed) or if it is something else. It may be that this problem has some impact on #1 above because pixmaps are sometimes stored in the bundles. For the above #1 and #2, these things worked properly on cm3 v4.1. I have the sources to 4.1, so maybe I can use them to figure out what is wrong. On a side note, I found and fixed a major bug in the "reactor" program, so that is good. Now, for another topic that we should probably move to a new email thread: Back in the early days, my company paid Critical Mass, Inc., to customize the Trestle/FormsVBT look and feel to more closely resemble Windows. I have the sources for this work, but of course it is based on v4.1 and the repository code has moved on since then. I am curious if anyone would be interested in me trying to integrate these customizations back into the current source tree, perhaps on a different branch? If we go this route, I may need a little refresher tutorial on the use of branches in CVS. We would want to make it so that the main branch and the customized branch could evolve in sync. That is, if a bug was found in either branch, the fix should be incorporated into both. Regards, Randy >>> Jay 1/18/2008 10:32 AM >>> Randy, please try with an updated m3-sys/cm3/src/version.quake and report back, thanks. I understand why I wasn't seeing this. - Jay Date: Wed, 16 Jan 2008 11:24:34 -0500 From: rcoleburn at scires.com To: m3devel at elegosoft.com; jayk123 at hotmail.com Subject: Re: [M3devel] my status on win32 Jay: Not sure I've clued in to all of your dialog. Sorry. I have in the past used a free tool to build an installer package and I was thinking of using it again. Since the tool is free, we could put all the work I do into the CVS repository so that others could also maintain it. What I am looking to achieve is to have a way where a "normal" Windows user could download a program, run it, and have all of the cm3 packages installed without having to use the MIN distribution to build it up or any other tools to get the sources (like cvs). You could achieve the same thing by having a big ZIP file also I suppose, but having the installer would also let us easily put something in the start menu to launch a command line with all the environment variables set properly via automatic call to vcvars et al. When I get "Reactor" working, it too could be put into the start menu. That just makes it fit in better with the Windows user culture I think. The reason I wanted to rebuild everything is two-fold: 1) ensure it can be done (i.e., test for "Broken #1"), and 2) get all of the rest of the packages built so I could then use cm3 to build "reactor" and my own programs and test them to see if there are any "Broken #2" issues. The MIN distribution is really insufficient to do much of anything except to build the rest of the packages you need. My understanding is that I needed to use CVS to get the current sources, because if I went back to the source archive, it was old and known to be Broken #1 on Windows. I'm glad that you believe the current "Broken #1" situation is easy to fix. Let me know what to do and I'll give it another try. My experience in the past has been that there are 3 conditions to getting cm3 to work properly on windows after it has been installed: 1) make sure your environment variables are set up by vcvars to point to the compiler/linker/libraries (of course if you used a non-Microsoft C compiler/linker you would need to use something other than vcvars); 2) make sure cm3.cfg has the right paths in place to find all the libraries and tools using DOS style short names (no embedded spaces); and 3) make sure C:\cm3\bin is in your path. Of these, #2 & #3 are essentially one-time events, and #1 can be set up by a invoking a batch/command file via a shortcut, so no big deal for me. You could even make #1 a one-time event by modifying the system-level (vice user-level) environment variables. The old cm3install program seemed to do a decent job of #2 for me. Also, I've noted some of your past dialog about accepting either '/' or '\' as a path separator. I'm sure you are aware that on Windows '/' is used often for switches (arguments). Plus Windows also allows spaces to be embedded in the command line, so whatever solution you propose needs to take into account that a valid command line might look like this: C:\My Program Folder\My Program.exe /myArg1 /myArg2 In some situations, this command line would have to be quoted and rendered as: "C:\My Program Folder\My Program.exe" /myArg1 /myArg2 and in places where the backslash is an escape character, I've seen "C:\\My Program Folder\\My Program.exe" /myArg1 /myArg2 Alas, I seem to have rambled a bit also. Sorry. The immediate need for me now is to solve the Broken #1 condition, so please let me know how to fix it and proceed. Regards, Randy >>> Jay 1/16/2008 10:28 AM >>> Randy, yes and no and clarifications. I mention starting with 5.1.6 as a "worst" or "worse" case. The earlier you start, the harder things are -- for me, to ensure it will work. If you merely start with my 5.5.0, well, what are you rebuilding from source for? Heck, you can use any binary distribution, 4.1, 5.1.6, and just use it. They should work. The n steps you/I give are really actually geared for people who WANT to build from source, it is not what people HAVE to do. As well there have been can be source distributions, to cut out CVS. I'll look into the datefn stuff shortly. As to the installer, well, again, yes and no. The need for the installer is very small. All you have to do today is unzip the .zip somewhere and set the path, and possibly the vcvars thing. That's it. I should..now that you are "pressuring" me for ease of use, teach cm3 about the various ?venvdir%, %vcinstalldir% variables, etc. That way as long as the user installed the tools, even if they elected not to change path/lib/include, cm3 can find the compiler and linker. I know everyone wants to preserve the flexibility of quake/cm3.cfg but...besides, cm3 can be pretty darn smart here. IF cm3.cfg defines SYSTEM_CC, leave things along (NT386 cm3.cfg does not today do that). However if there is now SYSTEM_CC and there is no cl.exe/link.exe in %PATH%, it could go on a quick hunt for them. On the lib and include part, well, the dependency on %include% might only be for errno..maybe not worth it. It has been whatever it is forever, like int* _errno(void); #define errno (*_errno)()). Modula-3 engages in rampant header cloning and CErrnoC was only introduced where that was deemed more fragile than usual, and for Windows it probably wasn't actually fragile -- the fragility, if I may be so rudely judgemental, is because so many other systems are so Johnny-come-lately to arriving at the obviously correct threading model that Windows has had all along (since Win95/NT, can't say anything good about Win3.1; I think OS/2 might have had it correct all along too.). Funny, everyone has FINALLY arrived at the correct threading model, only to have start changing again, since the number of cores and machines is set to be much greater than anticipated, the obvious threading model has been deemed too difficult for anyone to use (Win32, Modula-3, Java, .NET, Python, all the same supposedly too difficult model btw), and so some new one is needed, and well, truthfully, the difficulty is not just for dummies on relatively small multiproc boxes not having simple race conditions, the problem is scaling way way up. Sorry that was my usual tangential. Even the unzip and set path would benefit slightly from a GUI installer. I believe there is some easy thing you can do where you write your GUI installer and you put it in the .zip and then you prepend the GUI self extracting .zip/.exe stub, and you can tell it to run a particular command after the extraction. I guess you might use a fancier thing though? That is, are you going to, say, write a gui installer from scratch in Modula-3? It might be a fun exercise. :) And then you could build the self extracting prefix from source etc. This is the hard way I guess, but more interesing. If you can build an msi or use InstallShield or Wix or something, go ahead. If you use widely availabe free as in beer tools, that can be rolled into whatever automation there is to produce distributions, keeping it up to date shouldn't be a problem. I do have to bring up some annoying questions: 1) Does anyone besides me have the capacity to produce distributions? i.e.: Any Win32 machines left at Elego? 2) I know I ramble. So one of my many tangents/questions went unanswered. Say, in the absence of a gui installer, should .zips/.tar.bz files look like cm3-min-/bin/cm3 or bin/cm3 or cm3/bin/cm3 The last one is more directly usable. The first one is very common. This reminds me though Randy, the distribution I made available was "min", so yeah, like if you are doing any gui programming, using any "standard" library besides m3core or libm3, you'd need to build more from source. I can readily provide you a "std" distribution though. It's "always" been a "problem" to make my files available -- no web site hosting for me -- but recently that wasn't a problem, someone picked the files out of ~jkrell on birch and put them on the web site. Good. One more thing -- Olaf, please confirm repeat yourself, 'cause I admit I wasn't sure it was the right thing, but if you insist, ok. "std" should be "all"? I should not continue to imagine there is a new larger group called "all"? And wherever things are missing from std but do build ok, add them? m3cc should be in std? (I admit some big indecisiveness around m3cc. It is far and away the longest thing to build and so the one you really want to skip the most and leave out of whatever package group. I also wonder if on Windows, there should be some check where if sh is not in the $PATH, just silently skip m3cc? You only need MingWin to build what I have on my system for NT386GNU, except you also need msys just for m3cc. msys is actually quite small, like only 20 files..) Oh, sorry, yet another question. The non-gcc backend is excluded from the build on systems that use the gcc backend. For minimization, that is appropriate. For maximizing cross build capability, it is wrong. The packages build fine. I suspect they work. I am not a user of cross build capability yet, so I don't really care. (What I do for NT386/NT386GNU /might/ be considered sort of a cross build, but it is different/easier). They are small packages. - Jay Date: Wed, 16 Jan 2008 08:25:49 -0500 From: rcoleburn at scires.com To: m3devel at elegosoft.com; jayk123 at hotmail.com Subject: Re: [M3devel] my status on win32 Jay: There is no line in the m3makefile dealing with datefn, so I added the whole statement just before the line include("version.quake") Now, I get an error saying that the variable datefn is not defined. If you change to put quotes around datefn in the include statement, you get an error saying it can't open the file. You made a reference in one of your earlier posts about trying 5.1.6 or 4.1, but note that I started with your cm3-min-WIN32-NT386-d5.5.0.zip , not the 5.1.6 or 4.1 versions. Thus, using d5.5.0 as a base, I am trying to run your "upgrade.cmd" to rebuild the sources I checked out from CVS. Since this doesn't work "out-of-the-box", again I say this fits into the "Broken #1" category. If I can get this to work, I don't mind putting together a Windows installer program that will install the whole thing. That way, folks won't have to install cygwin just to get CVS so that they can install a working cm3. Folks will need to install the free Microsoft Visual C as a prerequisite, but then that's not too bad. Having an installer program would make cm3 more friendly to Windows folks. The current 16-step method is too laborious and error-prone for the person just getting started and they will not give cm3 a second try. As the cm3 system evolves and new releases are made, we will need to keep the installer program up-to-date and I don't mind doing that. After someone gets familiar with cm3 they might want to delve into some of the scripts for rebuilding the system, but until then, I think the installer program is the way to go. Regards, Randy >>> Jay 1/16/2008 1:01 AM >>> I think I see the problem. in cm3\src\m3makefile, make this change > if not defined("NOW") include(datefn) > end datefn is only created if certain other variables aren't defined, and do-pkg defines them. I don't know why I don't see this. Later. Could be that the Python scripts have a typo and don't define them. I've been using them more than cmd. If the host is NT, "NOW" is either gotten from an updated cm3.exe, or left to "not available". So the initial cm3 built from older cm3 can't report when it was built, but cm3 built from current cm3 can. I need to change that: 1) to be a function for niceness 2) to make it that way for Posix, for any host but I haven't been using Posix as much lately so not testing it. - Jay Date: Tue, 15 Jan 2008 23:55:39 -0500 From: rcoleburn at scires.com To: m3devel at elegosoft.com; jayk123 at hotmail.com Subject: RE: my status on win32 Jay: In the file version.quake, I made the following edit: changed line: local datefn = "../" & TARGET & ".datenow" to: local datefn = ".." & SL & TARGET & ".datenow" This change has the effect of putting a backward slash in the pathname instead of a forward slash, so we get C:\CM3_CVS_SourceTree\m3-sys\cm3\src\..\NT386.datenow So from that perspective, the change seems good. Unfortunately, I still get the error that this file can't be opened. A quick check of C:\CM3_CVS_SourceTree\m3-sys\cm3\NT386 shows that the file .datenow does not exist. Regards, Randy >>> Jay 1/15/2008 11:03 PM >>> That's not too bad really. 1) I'd recommend putting cm3 at the start of the path instead of the end. 2) Just comment out the offending code to make progress. It's not critical. >> C:\CM3_CVS_SourceTree\m3-sys\cm3\src\../NT386.datenow The code is: C:\CM3_CVS_SourceTree\m3-sys\cm3\src\version.quake or such, included by cm3\src\m3makefile. Does the file exist? Does version.quake use "/" or "SL"? If it uses "/", try replacing with SL (and ampersand for string concat). Could be that a newer binary distributions works better with forward slashes. > 4. > 5. > 6. Launch cygwin from desktop icon. Cygwin is only needed for cvs, I think you realize. Could you send me offline the result of just running "set" after running vcvarsall? I'd like to adapt pylib.py to it maybe. (I can start from 5.1.6 and will try 4.1 at some point.) - Jay Date: Tue, 15 Jan 2008 22:52:59 -0500 From: rcoleburn at scires.com To: m3devel at elegosoft.com; jayk123 at hotmail.com Subject: my status on win32 Jay et al: I've listed below the steps I've undertaken to try and build the current sources on Windows XP. I've also attached a text file showing the output I got when trying to build everything using Jay's upgrade.cmd script. Unfortunately, I'm getting a build error (see below). Please advise on how to resolve. STEPS I TOOK: ========= 1. Download Microsoft Visual Studio 2008 Express Edition All-in-One .ISO file and burn to DVD. http://www.microsoft.com/express/download/ 2. Install Microsoft Visual C++ 2008 Express Edition from DVD. 3. Use "Microsoft Update" service to check for updates / service packs. 4. Download cygwin setup program from http://cygwin.com/ 5. Ran cygwin setup.exe program to install cygwin for all users. Under "Devel" category, make certain to select "cvs" for installation. 6. Launch cygwin from desktop icon. 7. In cygwin command shell window, execute following two commands, making sure to give email as password when prompted for login: cvs -d :pserver:anonymous at modula3.elegosoft.com:/usr/cvs login cvs -d :pserver:anonymous at modula3.elegosoft.com:/usr/cvs checkout cm3 8. Moved resulting C:\cygwin\home\rcoleburn\cm3 to C:\CM3_CVS_SourceTree Note that you should replace "rcoleburn" above with your Windows login username. 9. Download cm3-min-WIN32-NT386-d5.5.0.zip and cm3-min-WIN32-NT386-d5.5.0-symbols.zip from http://modula3.elegosoft.com/cm3/download.html 10. Unzipped cm3-min-WIN32-NT386-d5.5.0.zip and stored resulting cm3 folder at C:\cm3 11. Unzipped cm3-min-WIN32-NT386-d5.5.0-symbols.zip and stored resulting symbols folder at C:\cm3\symbols 12. Launch Windows Command Prompt shell. The following steps represent commands executed within this shell. 13. path %path%;c:\cm3\bin 14. "C:\Program Files\Microsoft Visual Studio 9.0\VC\vcvarsall.bat" 15. cd C:\CM3_CVS_SourceTree\scripts\win 16. upgrade.cmd ERROR I'M GETTING: ============= === package C:\CM3_CVS_SourceTree\m3-sys\cm3 === +++ "cm3 -build -DROOT=C:\\CM3_CVS_SourceTree -DCM3_VERSION_TEXT=d5.5.1 -DCM3_V ERSION_NUMBER=050501 -DCM3_LAST_CHANGED=2007-12-30 && cm3 -ship -DROOT=C:\\CM3_C VS_SourceTree -DCM3_VERSION_TEXT=d5.5.1 -DCM3_VERSION_NUMBER=050501 -DCM3_LAST_C HANGED=2007-12-30" +++ --- building in NT386 --- ignoring ..\src\m3overrides "C:\CM3_CVS_SourceTree\m3-sys\cm3\src\version.quake", line 136: quake runtime er ror: unable to open "C:\CM3_CVS_SourceTree\m3-sys\cm3\src\../NT386.datenow" for reading --procedure-- -line- -file--- include -- version_impl 136 C:\CM3_CVS_SourceTree\m3-sys\cm3\src\version.quake include_dir 20 C:\CM3_CVS_SourceTree\m3-sys\cm3\src\m3makefile 8 C:\CM3_CVS_SourceTree\m3-sys\cm3\NT386\m3make.args Fatal Error: package build failed ERROR: "cm3 -build -DROOT=C:\\CM3_CVS_SourceTree -DCM3_VERSION_TEXT=d5.5.1 -DCM 3_VERSION_NUMBER=050501 -DCM3_LAST_CHANGED=2007-12-30 && cm3 -ship -DROOT=C:\\CM 3_CVS_SourceTree -DCM3_VERSION_TEXT=d5.5.1 -DCM3_VERSION_NUMBER=050501 -DCM3_LAS T_CHANGED=2007-12-30" ERROR: cd C:\CM3_CVS_SourceTree\m3-sys\cm3 ERROR: set INSTALLROOT=c:\cm3 Regards, Randy Share life as it happens with the new Windows Live. Start sharing! ( http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_012008 ) Put your friends on the big screen with Windows Vista* + Windows LiveT. Start now! ( http://www.microsoft.com/windows/shop/specialoffers.mspx?ocid=TXT_TAGLM_CPC_MediaCtr_bigscreen_012008 ) Get the power of Windows + Web with the new Windows Live. Get it now! ( http://www.windowslive.com/?ocid=TXT_TAGHM_Wave2_powerofwindows_012008 ) 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 ) -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcoleburn at scires.com Fri Jan 18 17:10:38 2008 From: rcoleburn at scires.com (Randy Coleburn) Date: Fri, 18 Jan 2008 11:10:38 -0500 Subject: [M3devel] new name for "reactor" Message-ID: <4790892B.1E75.00D7.1@scires.com> I thought I should ask for input from the community before finalizing the new name for "reactor." One of the conditions imposed on making the "reactor" source available is that I have to rename the product and remove all trademarked references. Originally, I chose the name "CM3-IDE" for CM3 Integrated Development Environment, but this name isn't very catchy. I thought about possibly using the name "Catalyst" since a catalyst is something used to accelerate a process and "reactor" certainly fits this definition. A brief search on the web turned up a some other uses of the name, but we may not have a problem if we don't try to trademark the name, or perhaps we could differentiate by calling it "CM3-Catalyst" or "M3-Catalyst". For those that don't know, "reactor" uses a web browser to present its interface. It allows you to quickly browse through all of your source code, create new packages, build and run programs, invoke your favorite editor, run tutorials, browse documentation, etc., etc. With the advent of tabbed browsing, it really makes it nice to understand what is going on when examining your code and when writing code it makes it easy to look up interface definitions etc. If anyone has suggestions on the name to use, please let me know. I'd like to finalize the name within the next few days so I can finalize the code for submission to the repository. Regards, Randy Coleburn -------------- next part -------------- An HTML attachment was scrubbed... URL: From lemming at henning-thielemann.de Fri Jan 18 17:50:42 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Fri, 18 Jan 2008 17:50:42 +0100 (MET) Subject: [M3devel] new name for "reactor" In-Reply-To: <4790892B.1E75.00D7.1@scires.com> References: <4790892B.1E75.00D7.1@scires.com> Message-ID: On Fri, 18 Jan 2008, Randy Coleburn wrote: > I thought about possibly using the name "Catalyst" since a catalyst is > something used to accelerate a process and "reactor" certainly fits this > definition. A brief search on the web turned up a some other uses of > the name, but we may not have a problem if we don't try to trademark the > name, or perhaps we could differentiate by calling it "CM3-Catalyst" or > "M3-Catalyst". I like the name. From jayk123 at hotmail.com Fri Jan 18 22:50:23 2008 From: jayk123 at hotmail.com (Jay) Date: Fri, 18 Jan 2008 21:50:23 +0000 Subject: [M3devel] my status on win32 In-Reply-To: <47908659.1E75.00D7.1@scires.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> <477EA137.1E75.00D7.1@scires.com> <478D394B.1E75.00D7.1@scires.com> <478D47FB.1E75.00D7.1@scires.com> <478DBF8D.1E75.00D7.1@scires.com> <478DE973.1E75.00D7.1@scires.com> <47908659.1E75.00D7.1@scires.com> Message-ID: I'll see about adding usage statements. Basically all the do* scripts accept a "command" and a list of packages. The commands are: realclean clean -- pretty useless imho buildlocal -- the default ship buildship -- build and shpi buildglobal The .sh and .py have a usage explaining this but .cmd is missing it, probably because I didn't fully understand at the time the functionality of the code I was blindy porting. do-* except for do-pkg have an implied list of packages. Maybe you can add to it, would have to check the source. do-pkg requires a list. Most of the rest are not meant to be user-callable -- sysinfo, pkginfo, pkgcmds. make-dist its its own thing. Oh, right -- environment variables. Many things are overridable with them, and need documentation the same. What do folks think of deleting all of scripts\win and having only scripts\python? I guess you have to try them out first, at least.Scripts\python achieves parity pretty much, except for the more logging to files, less logging to the console, that win\make-dist has. Furthermore, out on a limb, what do folks think of deleting most of scripts\*.sh and having just Python? I doubt this will fly and I will try resist mentioning it often. :) In the interest of consensus here, though I doubt it will help, I'd be open to rewriting python in Perl, or possiby even Tcl. I am also willing/interested in discussing the merits of these languages, or an as yet undeveloped one "ideal language" (Modula-3 I don't think is it, sorry), but probably most people will find it a waste of time. Where is the geek-out-really-badly mailing list? :) - Jay Date: Fri, 18 Jan 2008 10:58:36 -0500From: rcoleburn at scires.comTo: m3devel at elegosoft.com; jayk123 at hotmail.comSubject: Re: [M3devel] my status on win32 Jay: Ok. It will be later tonight before I can try again. Thanks! BTW, can you point me to a document/file somewhere that describes the various options for your windows command file scripts? I did experiment further with using the do-cm3-std.cmd and was finally able to get most everything to build, but of course this doesn't rebuild the compiler and core. Had problems with mentor and m3zume not wanting to build/run, so I commented these out in the cmd file to get it to work. Then I had trouble because everything was built with overrides by default, so I had to mess around with changing parameters and rebuilding clean. I've tried building some of my programs and, of course, have run into a few problems due to changes in the system. I've overcome most of these, but I am seeing some strange behavior: 1. pixmaps aren't rendered properly on the screen. They look really bad. I recall having this problem a while back with one of the early 5.x releases, so I guess it was never solved. I've got some old test programs I try to dig out and see if I can find out what is going on. I seem to recall that building standalone in the past seemed to fix the problem, so this is a real mystery. 2. I'm having trouble with bundles not returning all of the data. In the "reactor" program, bundles are used to provide input to the web browser for the page source. I'm seeing cases where not all of the HTML source is making it to the browser. Not sure if this is an I/O problem (maybe buffers not flushed) or if it is something else. It may be that this problem has some impact on #1 above because pixmaps are sometimes stored in the bundles. For the above #1 and #2, these things worked properly on cm3 v4.1. I have the sources to 4.1, so maybe I can use them to figure out what is wrong. On a side note, I found and fixed a major bug in the "reactor" program, so that is good. Now, for another topic that we should probably move to a new email thread: Back in the early days, my company paid Critical Mass, Inc., to customize the Trestle/FormsVBT look and feel to more closely resemble Windows. I have the sources for this work, but of course it is based on v4.1 and the repository code has moved on since then. I am curious if anyone would be interested in me trying to integrate these customizations back into the current source tree, perhaps on a different branch? If we go this route, I may need a little refresher tutorial on the use of branches in CVS. We would want to make it so that the main branch and the customized branch could evolve in sync. That is, if a bug was found in either branch, the fix should be incorporated into both. Regards, Randy>>> Jay 1/18/2008 10:32 AM >>>Randy, please try with an updated m3-sys/cm3/src/version.quake and report back, thanks.I understand why I wasn't seeing this. - Jay Date: Wed, 16 Jan 2008 11:24:34 -0500From: rcoleburn at scires.comTo: m3devel at elegosoft.com; jayk123 at hotmail.comSubject: Re: [M3devel] my status on win32 Jay: Not sure I've clued in to all of your dialog. Sorry. I have in the past used a free tool to build an installer package and I was thinking of using it again. Since the tool is free, we could put all the work I do into the CVS repository so that others could also maintain it. What I am looking to achieve is to have a way where a "normal" Windows user could download a program, run it, and have all of the cm3 packages installed without having to use the MIN distribution to build it up or any other tools to get the sources (like cvs). You could achieve the same thing by having a big ZIP file also I suppose, but having the installer would also let us easily put something in the start menu to launch a command line with all the environment variables set properly via automatic call to vcvars et al. When I get "Reactor" working, it too could be put into the start menu. That just makes it fit in better with the Windows user culture I think. The reason I wanted to rebuild everything is two-fold: 1) ensure it can be done (i.e., test for "Broken #1"), and 2) get all of the rest of the packages built so I could then use cm3 to build "reactor" and my own programs and test them to see if there are any "Broken #2" issues. The MIN distribution is really insufficient to do much of anything except to build the rest of the packages you need. My understanding is that I needed to use CVS to get the current sources, because if I went back to the source archive, it was old and known to be Broken #1 on Windows. I'm glad that you believe the current "Broken #1" situation is easy to fix. Let me know what to do and I'll give it another try. My experience in the past has been that there are 3 conditions to getting cm3 to work properly on windows after it has been installed: 1) make sure your environment variables are set up by vcvars to point to the compiler/linker/libraries (of course if you used a non-Microsoft C compiler/linker you would need to use something other than vcvars); 2) make sure cm3.cfg has the right paths in place to find all the libraries and tools using DOS style short names (no embedded spaces); and 3) make sure C:\cm3\bin is in your path. Of these, #2 & #3 are essentially one-time events, and #1 can be set up by a invoking a batch/command file via a shortcut, so no big deal for me. You could even make #1 a one-time event by modifying the system-level (vice user-level) environment variables. The old cm3install program seemed to do a decent job of #2 for me. Also, I've noted some of your past dialog about accepting either '/' or '\' as a path separator. I'm sure you are aware that on Windows '/' is used often for switches (arguments). Plus Windows also allows spaces to be embedded in the command line, so whatever solution you propose needs to take into account that a valid command line might look like this: C:\My Program Folder\My Program.exe /myArg1 /myArg2 In some situations, this command line would have to be quoted and rendered as: "C:\My Program Folder\My Program.exe" /myArg1 /myArg2 and in places where the backslash is an escape character, I've seen "C:\\My Program Folder\\My Program.exe" /myArg1 /myArg2 Alas, I seem to have rambled a bit also. Sorry. The immediate need for me now is to solve the Broken #1 condition, so please let me know how to fix it and proceed. Regards, Randy>>> Jay 1/16/2008 10:28 AM >>>Randy, yes and no and clarifications. I mention starting with 5.1.6 as a "worst" or "worse" case.The earlier you start, the harder things are -- for me, to ensure it will work. If you merely start with my 5.5.0, well, what are you rebuilding from source for?Heck, you can use any binary distribution, 4.1, 5.1.6, and just use it. They should work. The n steps you/I give are really actually geared for people who WANT to build from source, it is not what people HAVE to do.As well there have been can be source distributions, to cut out CVS. I'll look into the datefn stuff shortly. As to the installer, well, again, yes and no.The need for the installer is very small. All you have to do today is unzip the .zip somewhere and set the path, and possibly the vcvars thing. That's it. I should..now that you are "pressuring" me for ease of use, teach cm3 about the various ?venvdir%, %vcinstalldir% variables, etc. That way as long as the user installed the tools, even if they elected not to change path/lib/include, cm3 can find the compiler and linker. I know everyone wants to preserve the flexibility of quake/cm3.cfg but...besides, cm3 can be pretty darn smart here. IF cm3.cfg defines SYSTEM_CC, leave things along (NT386 cm3.cfg does not today do that). However if there is now SYSTEM_CC and there is no cl.exe/link.exe in %PATH%, it could go on a quick hunt for them. On the lib and include part, well, the dependency on %include% might only be for errno..maybe not worth it. It has been whatever it is forever, like int* _errno(void); #define errno (*_errno)()). Modula-3 engages in rampant header cloning and CErrnoC was only introduced where that was deemed more fragile than usual, and for Windows it probably wasn't actually fragile -- the fragility, if I may be so rudely judgemental, is because so many other systems are so Johnny-come-lately to arriving at the obviously correct threading model that Windows has had all along (since Win95/NT, can't say anything good about Win3.1; I think OS/2 might have had it correct all along too.). Funny, everyone has FINALLY arrived at the correct threading model, only to have start changing again, since the number of cores and machines is set to be much greater than anticipated, the obvious threading model has been deemed too difficult for anyone to use (Win32, Modula-3, Java, .NET, Python, all the same supposedly too difficult model btw), and so some new one is needed, and well, truthfully, the difficulty is not just for dummies on relatively small multiproc boxes not having simple race conditions, the problem is scaling way way up. Sorry that was my usual tangential. Even the unzip and set path would benefit slightly from a GUI installer.I believe there is some easy thing you can do where you write your GUI installer and you put it in the .zip and then you prepend the GUI self extracting .zip/.exe stub, and you can tell it to run a particular command after the extraction. I guess you might use a fancier thing though?That is, are you going to, say, write a gui installer from scratch in Modula-3? It might be a fun exercise. :)And then you could build the self extracting prefix from source etc.This is the hard way I guess, but more interesing.If you can build an msi or use InstallShield or Wix or something, go ahead.If you use widely availabe free as in beer tools, that can be rolled into whatever automation there is to produce distributions, keeping it up to date shouldn't be a problem. I do have to bring up some annoying questions: 1) Does anyone besides me have the capacity to produce distributions? i.e.: Any Win32 machines left at Elego? 2) I know I ramble. So one of my many tangents/questions went unanswered.Say, in the absence of a gui installer, should .zips/.tar.bz files look like cm3-min-/bin/cm3orbin/cm3orcm3/bin/cm3 The last one is more directly usable. The first one is very common. This reminds me though Randy, the distribution I made available was "min", so yeah, like if you are doing any gui programming, using any "standard" library besides m3core or libm3, you'd need to build more from source. I can readily provide you a "std" distribution though.It's "always" been a "problem" to make my files available -- no web site hosting for me -- but recently that wasn't a problem, someone picked the files out of ~jkrell on birch and put them on the web site. Good. One more thing -- Olaf, please confirm repeat yourself, 'cause I admit I wasn't sure it was the right thing, but if you insist, ok. "std" should be "all"? I should not continue to imagine there is a new larger group called "all"? And wherever things are missing from std but do build ok, add them?m3cc should be in std?(I admit some big indecisiveness around m3cc. It is far and away the longest thing to build and so the one you really want to skip the most and leave out of whatever package group. I also wonder if on Windows, there should be some check where if sh is not in the $PATH, just silently skip m3cc? You only need MingWin to build what I have on my system for NT386GNU, except you also need msys just for m3cc. msys is actually quite small, like only 20 files..) Oh, sorry, yet another question.The non-gcc backend is excluded from the build on systems that use the gcc backend.For minimization, that is appropriate.For maximizing cross build capability, it is wrong.The packages build fine. I suspect they work.I am not a user of cross build capability yet, so I don't really care. (What I do for NT386/NT386GNU /might/ be considered sort of a cross build, but it is different/easier).They are small packages. - Jay Date: Wed, 16 Jan 2008 08:25:49 -0500From: rcoleburn at scires.comTo: m3devel at elegosoft.com; jayk123 at hotmail.comSubject: Re: [M3devel] my status on win32 Jay: There is no line in the m3makefile dealing with datefn, so I added the whole statement just before the line include("version.quake") Now, I get an error saying that the variable datefn is not defined. If you change to put quotes around datefn in the include statement, you get an error saying it can't open the file. You made a reference in one of your earlier posts about trying 5.1.6 or 4.1, but note that I started with your cm3-min-WIN32-NT386-d5.5.0.zip , not the 5.1.6 or 4.1 versions. Thus, using d5.5.0 as a base, I am trying to run your "upgrade.cmd" to rebuild the sources I checked out from CVS. Since this doesn't work "out-of-the-box", again I say this fits into the "Broken #1" category. If I can get this to work, I don't mind putting together a Windows installer program that will install the whole thing. That way, folks won't have to install cygwin just to get CVS so that they can install a working cm3. Folks will need to install the free Microsoft Visual C as a prerequisite, but then that's not too bad. Having an installer program would make cm3 more friendly to Windows folks. The current 16-step method is too laborious and error-prone for the person just getting started and they will not give cm3 a second try. As the cm3 system evolves and new releases are made, we will need to keep the installer program up-to-date and I don't mind doing that. After someone gets familiar with cm3 they might want to delve into some of the scripts for rebuilding the system, but until then, I think the installer program is the way to go. Regards, Randy>>> Jay 1/16/2008 1:01 AM >>>I think I see the problem. in cm3\src\m3makefile, make this change > if not defined("NOW") include(datefn) > end datefn is only created if certain other variables aren't defined, and do-pkg defines them.I don't know why I don't see this. Later.Could be that the Python scripts have a typo and don't define them.I've been using them more than cmd. If the host is NT, "NOW" is either gotten from an updated cm3.exe, or left to "not available". So the initial cm3 built from older cm3 can't report when it was built, but cm3 built from current cm3 can. I need to change that: 1) to be a function for niceness 2) to make it that way for Posix, for any host but I haven't been using Posix as much lately so not testing it. - Jay Date: Tue, 15 Jan 2008 23:55:39 -0500From: rcoleburn at scires.comTo: m3devel at elegosoft.com; jayk123 at hotmail.comSubject: RE: my status on win32 Jay: In the file version.quake, I made the following edit: changed line: local datefn = "../" & TARGET & ".datenow" to: local datefn = ".." & SL & TARGET & ".datenow" This change has the effect of putting a backward slash in the pathname instead of a forward slash, so we getC:\CM3_CVS_SourceTree\m3-sys\cm3\src\..\NT386.datenow So from that perspective, the change seems good. Unfortunately, I still get the error that this file can't be opened. A quick check of C:\CM3_CVS_SourceTree\m3-sys\cm3\NT386 shows that the file .datenow does not exist. Regards, Randy>>> Jay 1/15/2008 11:03 PM >>>That's not too bad really. 1) I'd recommend putting cm3 at the start of the path instead of the end. 2) Just comment out the offending code to make progress. It's not critical. >> C:\CM3_CVS_SourceTree\m3-sys\cm3\src\../NT386.datenow The code is: C:\CM3_CVS_SourceTree\m3-sys\cm3\src\version.quake or such, included by cm3\src\m3makefile. Does the file exist?Does version.quake use "/" or "SL"? If it uses "/", try replacing with SL (and ampersand for string concat). Could be that a newer binary distributions works better with forward slashes. > 4. > 5. > 6. Launch cygwin from desktop icon. Cygwin is only needed for cvs, I think you realize. Could you send me offline the result of just running "set" after running vcvarsall? I'd like to adapt pylib.py to it maybe. (I can start from 5.1.6 and will try 4.1 at some point.) - Jay Date: Tue, 15 Jan 2008 22:52:59 -0500From: rcoleburn at scires.comTo: m3devel at elegosoft.com; jayk123 at hotmail.comSubject: my status on win32 Jay et al: I've listed below the steps I've undertaken to try and build the current sources on Windows XP. I've also attached a text file showing the output I got when trying to build everything using Jay's upgrade.cmd script. Unfortunately, I'm getting a build error (see below). Please advise on how to resolve. STEPS I TOOK: ========= 1. Download Microsoft Visual Studio 2008 Express Edition All-in-One .ISO file and burn to DVD. http://www.microsoft.com/express/download/ 2. Install Microsoft Visual C++ 2008 Express Edition from DVD. 3. Use "Microsoft Update" service to check for updates / service packs. 4. Download cygwin setup program from http://cygwin.com/ 5. Ran cygwin setup.exe program to install cygwin for all users. Under "Devel" category, make certain to select "cvs" for installation. 6. Launch cygwin from desktop icon. 7. In cygwin command shell window, execute following two commands, making sure to give email as password when prompted for login: cvs -d :pserver:anonymous at modula3.elegosoft.com:/usr/cvs login cvs -d :pserver:anonymous at modula3.elegosoft.com:/usr/cvs checkout cm3 8. Moved resulting C:\cygwin\home\rcoleburn\cm3 to C:\CM3_CVS_SourceTree Note that you should replace "rcoleburn" above with your Windows login username. 9. Download cm3-min-WIN32-NT386-d5.5.0.zip and cm3-min-WIN32-NT386-d5.5.0-symbols.zip from http://modula3.elegosoft.com/cm3/download.html 10. Unzipped cm3-min-WIN32-NT386-d5.5.0.zip and stored resulting cm3 folder at C:\cm3 11. Unzipped cm3-min-WIN32-NT386-d5.5.0-symbols.zip and stored resulting symbols folder at C:\cm3\symbols 12. Launch Windows Command Prompt shell. The following steps represent commands executed within this shell. 13. path %path%;c:\cm3\bin 14. "C:\Program Files\Microsoft Visual Studio 9.0\VC\vcvarsall.bat" 15. cd C:\CM3_CVS_SourceTree\scripts\win 16. upgrade.cmd ERROR I'M GETTING: ============= === package C:\CM3_CVS_SourceTree\m3-sys\cm3 ===+++ "cm3 -build -DROOT=C:\\CM3_CVS_SourceTree -DCM3_VERSION_TEXT=d5.5.1 -DCM3_VERSION_NUMBER=050501 -DCM3_LAST_CHANGED=2007-12-30 && cm3 -ship -DROOT=C:\\CM3_CVS_SourceTree -DCM3_VERSION_TEXT=d5.5.1 -DCM3_VERSION_NUMBER=050501 -DCM3_LAST_CHANGED=2007-12-30" +++--- building in NT386 --- ignoring ..\src\m3overrides "C:\CM3_CVS_SourceTree\m3-sys\cm3\src\version.quake", line 136: quake runtime error: unable to open "C:\CM3_CVS_SourceTree\m3-sys\cm3\src\../NT386.datenow" forreading --procedure-- -line- -file---include -- version_impl 136 C:\CM3_CVS_SourceTree\m3-sys\cm3\src\version.quakeinclude_dir 20 C:\CM3_CVS_SourceTree\m3-sys\cm3\src\m3makefile 8 C:\CM3_CVS_SourceTree\m3-sys\cm3\NT386\m3make.args Fatal Error: package build failedERROR: "cm3 -build -DROOT=C:\\CM3_CVS_SourceTree -DCM3_VERSION_TEXT=d5.5.1 -DCM3_VERSION_NUMBER=050501 -DCM3_LAST_CHANGED=2007-12-30 && cm3 -ship -DROOT=C:\\CM3_CVS_SourceTree -DCM3_VERSION_TEXT=d5.5.1 -DCM3_VERSION_NUMBER=050501 -DCM3_LAST_CHANGED=2007-12-30"ERROR: cd C:\CM3_CVS_SourceTree\m3-sys\cm3ERROR: set INSTALLROOT=c:\cm3 Regards, Randy Share life as it happens with the new Windows Live. Start sharing! Put your friends on the big screen with Windows Vista? + Windows LiveT. Start now! Get the power of Windows + Web with the new Windows Live. Get it now! 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 jayk123 at hotmail.com Fri Jan 18 23:28:14 2008 From: jayk123 at hotmail.com (Jay) Date: Fri, 18 Jan 2008 22:28:14 +0000 Subject: [M3devel] incremental build always rebuilds cm3, never produces the same thing -- what time is "now"? In-Reply-To: <47908659.1E75.00D7.1@scires.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> <477EA137.1E75.00D7.1@scires.com> <478D394B.1E75.00D7.1@scires.com> <478D47FB.1E75.00D7.1@scires.com> <478DBF8D.1E75.00D7.1@scires.com> <478DE973.1E75.00D7.1@scires.com> <47908659.1E75.00D7.1@scires.com> Message-ID: In m3-sys\cm3, incremental build always rebuilds cm3, never produces the same thing. I know exactly why. My modification to Olaf's timestamping (which I think he approved, but perhaps didn't realize this outcome). Because we generate a source file with the current time, and it always changes. Is this ok with people?I know it has downsides, but it might be ok. You know: 1) incremental build should really never do anything, never writing anything, fast which is important -- never write, or be fast? both? 2) You might want to compare two full builds and determine they are identical; the less of this sort of thing the better If not, what do people suggest for a way to determine when to update the time? The logic before I think was essentially never, unless you went and deleted a specific file. Perhaps that is right, once it is discovered and publicized. Perhaps another output directory is needed -- say / -- that upgrade and make-dist, perhaps, know to delete, and maybe realclean...of cm3? deletes? Hey, maybe just declare an output, with "..", in the m3makefile, so merely clean and realclean update the time, but incremental builds do not? This seems obviously the way to go right now, but still slightly debatable. Like, maybe an accurate timestamp is needed. Maybe if any other source or .lib changes, the timestamp should change -- so, like, m3_back/m3_link could regenerate the file, except that might be too late. Should "now" be less granular than a second? That mitigates the problem but i think is not satisfactory.Should "now" be overridable on the command line or with an environment variable? - 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 Fri Jan 18 23:42:26 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 18 Jan 2008 23:42:26 +0100 Subject: [M3devel] my status on win32 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> <477EA137.1E75.00D7.1@scires.com> <478D394B.1E75.00D7.1@scires.com> <478D47FB.1E75.00D7.1@scires.com> <478DBF8D.1E75.00D7.1@scires.com> <478DE973.1E75.00D7.1@scires.com> <47908659.1E75.00D7.1@scires.com> Message-ID: <20080118234226.8g4fi0mkgwgscwww@mail.elegosoft.com> Quoting Jay : > I'll see about adding usage statements. > Basically all the do* scripts accept a "command" and a list of packages. > The commands are: > realclean > clean -- pretty useless imho > buildlocal -- the default > ship > buildship -- build and shpi > buildglobal Actually, the more useful commands are build -- build with overrides to ROOT buildship (same as buildglobal) -- build with global package pool realclean -- completely delete derived target files > do-pkg requires a list. If you're doing you're own project, this may be what is most useful -- if you use the scripts at all. > What do folks think of deleting all of scripts\win and having only > scripts\python? > I guess you have to try them out first, at least.Scripts\python > achieves parity pretty much, except for the more logging to files, > less logging to the console, that win\make-dist has. > > Furthermore, out on a limb, what do folks think of deleting most of > scripts\*.sh and having just Python? I'd object to this. Shell is POSIX standard, and most of the infrastructure is built on it; Python is nice to have, but should not be a prerequisite to CM3. > I doubt this will fly and I will try resist mentioning it often. :) > In the interest of consensus here, though I doubt it will help, I'd > be open to rewriting python in Perl, or possiby even Tcl. Why? > I am also willing/interested in discussing the merits of these > languages, or an as yet undeveloped one "ideal language" (Modula-3 I > don't think is it, sorry), but probably most people will find it a > waste of time. Where is the geek-out-really-badly mailing list? :) I don't see the point in rewriting the scripts in yet other languages. The purpose of the scripts is to support the installation, administration and maintenance of the CM3 distribution. They were not intended as a general purpose build or automation environment, though they can be used for this purpose to a certain extent. But the main point is that they are useful for the people maintaining the distribution. We could think about rewriting everything in M3 to further reduce the system dependencies, but this would not be as flexible as a general scripting language. Quake would need to be substantially extended, and Python is nice, but a huge software distribution in itself, that should be independent of CM3. POSIX shell is the one common interpreter I have found to be available on almost all systems. (Even when we were programming point-of-sale solutions on DOS in the early 90s we had ksh and other POSIX tools there to emulate the Sun development environment we used on the servers.) OK, on Windows you have to install it (e.g. in form of Cygwin) like Python, but it's still the best choice wrt. availability and portability I've found. For general discussions of the advantages and disadvantage of programming languages, some of the comp.lang.* newsgroups may be the better choice, though I haven't read them for years now and don't know if they're still alive. As for the ideal language -- I don't think that there is any language that could claim this. The advantages and disadvantages depend heavily on the usage context, environment, and skills and understanding of the programmers. (M3 is pretty good 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 rcoleburn at scires.com Fri Jan 18 23:53:45 2008 From: rcoleburn at scires.com (Randy Coleburn) Date: Fri, 18 Jan 2008 17:53:45 -0500 Subject: [M3devel] my status on win32 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> <477EA137.1E75.00D7.1@scires.com> <478D394B.1E75.00D7.1@scires.com> <478D47FB.1E75.00D7.1@scires.com> <478DBF8D.1E75.00D7.1@scires.com> <478DE973.1E75.00D7.1@scires.com> <47908659.1E75.00D7.1@scires.com> Message-ID: <4790E7A7.1E75.00D7.1@scires.com> Jay: What does "buildglobal" mean? How is it different from "buildship"? As far as "scripts" go, I'm an old guy that started out with computers that had real core memory. When the IBM PC revolution hit, I was already a professional and had mastered large computers with network operating systems and even micro-computers with CP/M. I learned DOS and became a good "BAT" batch file programmer (we didn't call them scripting languages back then). I'm still pretty good with Windows CMD files, but have not tackled python. My vote for cm3 on Windows is to avoid making the end user (customer) have to learn or acquire things that aren't native to his environment. Thus, I would argue for use of CMD files on Windows instead of some other scripting language. This same reasoning is why I was pushing for the all-in-one installation program for cm3 on Windows. If all a "Windows person" has to do to get cm3 modula-3 up and running on his box is to run an install program and possibly tweak a few CMD scripts to his/her liking, then it is "easy". Forcing acquisition and installation of other tools/environments just to get started makes things complicated and increases the barrier to startup and acceptance. Just my 2 cents worth. A few years ago, I contributed some BAT/CMD files that could be used to build the entire system on Windows. The only issue is that as the system evolves, you have to keep the package build order up to date. I don't mind trying to help out further in this area. You seem to be very technically capable, so perhaps what I can offer pales in comparison. Thanks for all you are doing. Let me know if/how I can help. Regards, Randy >>> Jay 1/18/2008 4:50 PM >>> I'll see about adding usage statements. Basically all the do* scripts accept a "command" and a list of packages. The commands are: realclean clean -- pretty useless imho buildlocal -- the default ship buildship -- build and shpi buildglobal The .sh and .py have a usage explaining this but .cmd is missing it, probably because I didn't fully understand at the time the functionality of the code I was blindy porting. do-* except for do-pkg have an implied list of packages. Maybe you can add to it, would have to check the source. do-pkg requires a list. Most of the rest are not meant to be user-callable -- sysinfo, pkginfo, pkgcmds. make-dist its its own thing. Oh, right -- environment variables. Many things are overridable with them, and need documentation the same. What do folks think of deleting all of scripts\win and having only scripts\python? I guess you have to try them out first, at least. Scripts\python achieves parity pretty much, except for the more logging to files, less logging to the console, that win\make-dist has. Furthermore, out on a limb, what do folks think of deleting most of scripts\*.sh and having just Python? I doubt this will fly and I will try resist mentioning it often. :) In the interest of consensus here, though I doubt it will help, I'd be open to rewriting python in Perl, or possiby even Tcl. I am also willing/interested in discussing the merits of these languages, or an as yet undeveloped one "ideal language" (Modula-3 I don't think is it, sorry), but probably most people will find it a waste of time. Where is the geek-out-really-badly mailing list? :) - Jay Date: Fri, 18 Jan 2008 10:58:36 -0500 From: rcoleburn at scires.com To: m3devel at elegosoft.com; jayk123 at hotmail.com Subject: Re: [M3devel] my status on win32 Jay: Ok. It will be later tonight before I can try again. Thanks! BTW, can you point me to a document/file somewhere that describes the various options for your windows command file scripts? I did experiment further with using the do-cm3-std.cmd and was finally able to get most everything to build, but of course this doesn't rebuild the compiler and core. Had problems with mentor and m3zume not wanting to build/run, so I commented these out in the cmd file to get it to work. Then I had trouble because everything was built with overrides by default, so I had to mess around with changing parameters and rebuilding clean. I've tried building some of my programs and, of course, have run into a few problems due to changes in the system. I've overcome most of these, but I am seeing some strange behavior: 1. pixmaps aren't rendered properly on the screen. They look really bad. I recall having this problem a while back with one of the early 5.x releases, so I guess it was never solved. I've got some old test programs I try to dig out and see if I can find out what is going on. I seem to recall that building standalone in the past seemed to fix the problem, so this is a real mystery. 2. I'm having trouble with bundles not returning all of the data. In the "reactor" program, bundles are used to provide input to the web browser for the page source. I'm seeing cases where not all of the HTML source is making it to the browser. Not sure if this is an I/O problem (maybe buffers not flushed) or if it is something else. It may be that this problem has some impact on #1 above because pixmaps are sometimes stored in the bundles. For the above #1 and #2, these things worked properly on cm3 v4.1. I have the sources to 4.1, so maybe I can use them to figure out what is wrong. On a side note, I found and fixed a major bug in the "reactor" program, so that is good. Now, for another topic that we should probably move to a new email thread: Back in the early days, my company paid Critical Mass, Inc., to customize the Trestle/FormsVBT look and feel to more closely resemble Windows. I have the sources for this work, but of course it is based on v4.1 and the repository code has moved on since then. I am curious if anyone would be interested in me trying to integrate these customizations back into the current source tree, perhaps on a different branch? If we go this route, I may need a little refresher tutorial on the use of branches in CVS. We would want to make it so that the main branch and the customized branch could evolve in sync. That is, if a bug was found in either branch, the fix should be incorporated into both. Regards, Randy >>> Jay 1/18/2008 10:32 AM >>> Randy, please try with an updated m3-sys/cm3/src/version.quake and report back, thanks. I understand why I wasn't seeing this. - Jay Date: Wed, 16 Jan 2008 11:24:34 -0500 From: rcoleburn at scires.com To: m3devel at elegosoft.com; jayk123 at hotmail.com Subject: Re: [M3devel] my status on win32 Jay: Not sure I've clued in to all of your dialog. Sorry. I have in the past used a free tool to build an installer package and I was thinking of using it again. Since the tool is free, we could put all the work I do into the CVS repository so that others could also maintain it. What I am looking to achieve is to have a way where a "normal" Windows user could download a program, run it, and have all of the cm3 packages installed without having to use the MIN distribution to build it up or any other tools to get the sources (like cvs). You could achieve the same thing by having a big ZIP file also I suppose, but having the installer would also let us easily put something in the start menu to launch a command line with all the environment variables set properly via automatic call to vcvars et al. When I get "Reactor" working, it too could be put into the start menu. That just makes it fit in better with the Windows user culture I think. The reason I wanted to rebuild everything is two-fold: 1) ensure it can be done (i.e., test for "Broken #1"), and 2) get all of the rest of the packages built so I could then use cm3 to build "reactor" and my own programs and test them to see if there are any "Broken #2" issues. The MIN distribution is really insufficient to do much of anything except to build the rest of the packages you need. My understanding is that I needed to use CVS to get the current sources, because if I went back to the source archive, it was old and known to be Broken #1 on Windows. I'm glad that you believe the current "Broken #1" situation is easy to fix. Let me know what to do and I'll give it another try. My experience in the past has been that there are 3 conditions to getting cm3 to work properly on windows after it has been installed: 1) make sure your environment variables are set up by vcvars to point to the compiler/linker/libraries (of course if you used a non-Microsoft C compiler/linker you would need to use something other than vcvars); 2) make sure cm3.cfg has the right paths in place to find all the libraries and tools using DOS style short names (no embedded spaces); and 3) make sure C:\cm3\bin is in your path. Of these, #2 & #3 are essentially one-time events, and #1 can be set up by a invoking a batch/command file via a shortcut, so no big deal for me. You could even make #1 a one-time event by modifying the system-level (vice user-level) environment variables. The old cm3install program seemed to do a decent job of #2 for me. Also, I've noted some of your past dialog about accepting either '/' or '\' as a path separator. I'm sure you are aware that on Windows '/' is used often for switches (arguments). Plus Windows also allows spaces to be embedded in the command line, so whatever solution you propose needs to take into account that a valid command line might look like this: C:\My Program Folder\My Program.exe /myArg1 /myArg2 In some situations, this command line would have to be quoted and rendered as: "C:\My Program Folder\My Program.exe" /myArg1 /myArg2 and in places where the backslash is an escape character, I've seen "C:\\My Program Folder\\My Program.exe" /myArg1 /myArg2 Alas, I seem to have rambled a bit also. Sorry. The immediate need for me now is to solve the Broken #1 condition, so please let me know how to fix it and proceed. Regards, Randy >>> Jay 1/16/2008 10:28 AM >>> Randy, yes and no and clarifications. I mention starting with 5.1.6 as a "worst" or "worse" case. The earlier you start, the harder things are -- for me, to ensure it will work. If you merely start with my 5.5.0, well, what are you rebuilding from source for? Heck, you can use any binary distribution, 4.1, 5.1.6, and just use it. They should work. The n steps you/I give are really actually geared for people who WANT to build from source, it is not what people HAVE to do. As well there have been can be source distributions, to cut out CVS. I'll look into the datefn stuff shortly. As to the installer, well, again, yes and no. The need for the installer is very small. All you have to do today is unzip the .zip somewhere and set the path, and possibly the vcvars thing. That's it. I should..now that you are "pressuring" me for ease of use, teach cm3 about the various ?venvdir%, %vcinstalldir% variables, etc. That way as long as the user installed the tools, even if they elected not to change path/lib/include, cm3 can find the compiler and linker. I know everyone wants to preserve the flexibility of quake/cm3.cfg but...besides, cm3 can be pretty darn smart here. IF cm3.cfg defines SYSTEM_CC, leave things along (NT386 cm3.cfg does not today do that). However if there is now SYSTEM_CC and there is no cl.exe/link.exe in %PATH%, it could go on a quick hunt for them. On the lib and include part, well, the dependency on %include% might only be for errno..maybe not worth it. It has been whatever it is forever, like int* _errno(void); #define errno (*_errno)()). Modula-3 engages in rampant header cloning and CErrnoC was only introduced where that was deemed more fragile than usual, and for Windows it probably wasn't actually fragile -- the fragility, if I may be so rudely judgemental, is because so many other systems are so Johnny-come-lately to arriving at the obviously correct threading model that Windows has had all along (since Win95/NT, can't say anything good about Win3.1; I think OS/2 might have had it correct all along too.). Funny, everyone has FINALLY arrived at the correct threading model, only to have start changing again, since the number of cores and machines is set to be much greater than anticipated, the obvious threading model has been deemed too difficult for anyone to use (Win32, Modula-3, Java, .NET, Python, all the same supposedly too difficult model btw), and so some new one is needed, and well, truthfully, the difficulty is not just for dummies on relatively small multiproc boxes not having simple race conditions, the problem is scaling way way up. Sorry that was my usual tangential. Even the unzip and set path would benefit slightly from a GUI installer. I believe there is some easy thing you can do where you write your GUI installer and you put it in the .zip and then you prepend the GUI self extracting .zip/.exe stub, and you can tell it to run a particular command after the extraction. I guess you might use a fancier thing though? That is, are you going to, say, write a gui installer from scratch in Modula-3? It might be a fun exercise. :) And then you could build the self extracting prefix from source etc. This is the hard way I guess, but more interesing. If you can build an msi or use InstallShield or Wix or something, go ahead. If you use widely availabe free as in beer tools, that can be rolled into whatever automation there is to produce distributions, keeping it up to date shouldn't be a problem. I do have to bring up some annoying questions: 1) Does anyone besides me have the capacity to produce distributions? i.e.: Any Win32 machines left at Elego? 2) I know I ramble. So one of my many tangents/questions went unanswered. Say, in the absence of a gui installer, should .zips/.tar.bz files look like cm3-min-/bin/cm3 or bin/cm3 or cm3/bin/cm3 The last one is more directly usable. The first one is very common. This reminds me though Randy, the distribution I made available was "min", so yeah, like if you are doing any gui programming, using any "standard" library besides m3core or libm3, you'd need to build more from source. I can readily provide you a "std" distribution though. It's "always" been a "problem" to make my files available -- no web site hosting for me -- but recently that wasn't a problem, someone picked the files out of ~jkrell on birch and put them on the web site. Good. One more thing -- Olaf, please confirm repeat yourself, 'cause I admit I wasn't sure it was the right thing, but if you insist, ok. "std" should be "all"? I should not continue to imagine there is a new larger group called "all"? And wherever things are missing from std but do build ok, add them? m3cc should be in std? (I admit some big indecisiveness around m3cc. It is far and away the longest thing to build and so the one you really want to skip the most and leave out of whatever package group. I also wonder if on Windows, there should be some check where if sh is not in the $PATH, just silently skip m3cc? You only need MingWin to build what I have on my system for NT386GNU, except you also need msys just for m3cc. msys is actually quite small, like only 20 files..) Oh, sorry, yet another question. The non-gcc backend is excluded from the build on systems that use the gcc backend. For minimization, that is appropriate. For maximizing cross build capability, it is wrong. The packages build fine. I suspect they work. I am not a user of cross build capability yet, so I don't really care. (What I do for NT386/NT386GNU /might/ be considered sort of a cross build, but it is different/easier). They are small packages. - Jay Date: Wed, 16 Jan 2008 08:25:49 -0500 From: rcoleburn at scires.com To: m3devel at elegosoft.com; jayk123 at hotmail.com Subject: Re: [M3devel] my status on win32 Jay: There is no line in the m3makefile dealing with datefn, so I added the whole statement just before the line include("version.quake") Now, I get an error saying that the variable datefn is not defined. If you change to put quotes around datefn in the include statement, you get an error saying it can't open the file. You made a reference in one of your earlier posts about trying 5.1.6 or 4.1, but note that I started with your cm3-min-WIN32-NT386-d5.5.0.zip , not the 5.1.6 or 4.1 versions. Thus, using d5.5.0 as a base, I am trying to run your "upgrade.cmd" to rebuild the sources I checked out from CVS. Since this doesn't work "out-of-the-box", again I say this fits into the "Broken #1" category. If I can get this to work, I don't mind putting together a Windows installer program that will install the whole thing. That way, folks won't have to install cygwin just to get CVS so that they can install a working cm3. Folks will need to install the free Microsoft Visual C as a prerequisite, but then that's not too bad. Having an installer program would make cm3 more friendly to Windows folks. The current 16-step method is too laborious and error-prone for the person just getting started and they will not give cm3 a second try. As the cm3 system evolves and new releases are made, we will need to keep the installer program up-to-date and I don't mind doing that. After someone gets familiar with cm3 they might want to delve into some of the scripts for rebuilding the system, but until then, I think the installer program is the way to go. Regards, Randy >>> Jay 1/16/2008 1:01 AM >>> I think I see the problem. in cm3\src\m3makefile, make this change > if not defined("NOW") include(datefn) > end datefn is only created if certain other variables aren't defined, and do-pkg defines them. I don't know why I don't see this. Later. Could be that the Python scripts have a typo and don't define them. I've been using them more than cmd. If the host is NT, "NOW" is either gotten from an updated cm3.exe, or left to "not available". So the initial cm3 built from older cm3 can't report when it was built, but cm3 built from current cm3 can. I need to change that: 1) to be a function for niceness 2) to make it that way for Posix, for any host but I haven't been using Posix as much lately so not testing it. - Jay Date: Tue, 15 Jan 2008 23:55:39 -0500 From: rcoleburn at scires.com To: m3devel at elegosoft.com; jayk123 at hotmail.com Subject: RE: my status on win32 Jay: In the file version.quake, I made the following edit: changed line: local datefn = "../" & TARGET & ".datenow" to: local datefn = ".." & SL & TARGET & ".datenow" This change has the effect of putting a backward slash in the pathname instead of a forward slash, so we get C:\CM3_CVS_SourceTree\m3-sys\cm3\src\..\NT386.datenow So from that perspective, the change seems good. Unfortunately, I still get the error that this file can't be opened. A quick check of C:\CM3_CVS_SourceTree\m3-sys\cm3\NT386 shows that the file .datenow does not exist. Regards, Randy >>> Jay 1/15/2008 11:03 PM >>> That's not too bad really. 1) I'd recommend putting cm3 at the start of the path instead of the end. 2) Just comment out the offending code to make progress. It's not critical. >> C:\CM3_CVS_SourceTree\m3-sys\cm3\src\../NT386.datenow The code is: C:\CM3_CVS_SourceTree\m3-sys\cm3\src\version.quake or such, included by cm3\src\m3makefile. Does the file exist? Does version.quake use "/" or "SL"? If it uses "/", try replacing with SL (and ampersand for string concat). Could be that a newer binary distributions works better with forward slashes. > 4. > 5. > 6. Launch cygwin from desktop icon. Cygwin is only needed for cvs, I think you realize. Could you send me offline the result of just running "set" after running vcvarsall? I'd like to adapt pylib.py to it maybe. (I can start from 5.1.6 and will try 4.1 at some point.) - Jay Date: Tue, 15 Jan 2008 22:52:59 -0500 From: rcoleburn at scires.com To: m3devel at elegosoft.com; jayk123 at hotmail.com Subject: my status on win32 Jay et al: I've listed below the steps I've undertaken to try and build the current sources on Windows XP. I've also attached a text file showing the output I got when trying to build everything using Jay's upgrade.cmd script. Unfortunately, I'm getting a build error (see below). Please advise on how to resolve. STEPS I TOOK: ========= 1. Download Microsoft Visual Studio 2008 Express Edition All-in-One .ISO file and burn to DVD. http://www.microsoft.com/express/download/ 2. Install Microsoft Visual C++ 2008 Express Edition from DVD. 3. Use "Microsoft Update" service to check for updates / service packs. 4. Download cygwin setup program from http://cygwin.com/ 5. Ran cygwin setup.exe program to install cygwin for all users. Under "Devel" category, make certain to select "cvs" for installation. 6. Launch cygwin from desktop icon. 7. In cygwin command shell window, execute following two commands, making sure to give email as password when prompted for login: cvs -d :pserver:anonymous at modula3.elegosoft.com:/usr/cvs login cvs -d :pserver:anonymous at modula3.elegosoft.com:/usr/cvs checkout cm3 8. Moved resulting C:\cygwin\home\rcoleburn\cm3 to C:\CM3_CVS_SourceTree Note that you should replace "rcoleburn" above with your Windows login username. 9. Download cm3-min-WIN32-NT386-d5.5.0.zip and cm3-min-WIN32-NT386-d5.5.0-symbols.zip from http://modula3.elegosoft.com/cm3/download.html 10. Unzipped cm3-min-WIN32-NT386-d5.5.0.zip and stored resulting cm3 folder at C:\cm3 11. Unzipped cm3-min-WIN32-NT386-d5.5.0-symbols.zip and stored resulting symbols folder at C:\cm3\symbols 12. Launch Windows Command Prompt shell. The following steps represent commands executed within this shell. 13. path %path%;c:\cm3\bin 14. "C:\Program Files\Microsoft Visual Studio 9.0\VC\vcvarsall.bat" 15. cd C:\CM3_CVS_SourceTree\scripts\win 16. upgrade.cmd ERROR I'M GETTING: ============= === package C:\CM3_CVS_SourceTree\m3-sys\cm3 === +++ "cm3 -build -DROOT=C:\\CM3_CVS_SourceTree -DCM3_VERSION_TEXT=d5.5.1 -DCM3_V ERSION_NUMBER=050501 -DCM3_LAST_CHANGED=2007-12-30 && cm3 -ship -DROOT=C:\\CM3_C VS_SourceTree -DCM3_VERSION_TEXT=d5.5.1 -DCM3_VERSION_NUMBER=050501 -DCM3_LAST_C HANGED=2007-12-30" +++ --- building in NT386 --- ignoring ..\src\m3overrides "C:\CM3_CVS_SourceTree\m3-sys\cm3\src\version.quake", line 136: quake runtime er ror: unable to open "C:\CM3_CVS_SourceTree\m3-sys\cm3\src\../NT386.datenow" for reading --procedure-- -line- -file--- include -- version_impl 136 C:\CM3_CVS_SourceTree\m3-sys\cm3\src\version.quake include_dir 20 C:\CM3_CVS_SourceTree\m3-sys\cm3\src\m3makefile 8 C:\CM3_CVS_SourceTree\m3-sys\cm3\NT386\m3make.args Fatal Error: package build failed ERROR: "cm3 -build -DROOT=C:\\CM3_CVS_SourceTree -DCM3_VERSION_TEXT=d5.5.1 -DCM 3_VERSION_NUMBER=050501 -DCM3_LAST_CHANGED=2007-12-30 && cm3 -ship -DROOT=C:\\CM 3_CVS_SourceTree -DCM3_VERSION_TEXT=d5.5.1 -DCM3_VERSION_NUMBER=050501 -DCM3_LAS T_CHANGED=2007-12-30" ERROR: cd C:\CM3_CVS_SourceTree\m3-sys\cm3 ERROR: set INSTALLROOT=c:\cm3 Regards, Randy Share life as it happens with the new Windows Live. Start sharing! ( http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_012008 ) Put your friends on the big screen with Windows Vista* + Windows LiveT. Start now! ( http://www.microsoft.com/windows/shop/specialoffers.mspx?ocid=TXT_TAGLM_CPC_MediaCtr_bigscreen_012008 ) Get the power of Windows + Web with the new Windows Live. Get it now! ( http://www.windowslive.com/?ocid=TXT_TAGHM_Wave2_powerofwindows_012008 ) 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 ) Helping your favorite cause is as easy as instant messaging. You IM, we give. Learn more. ( http://im.live.com/Messenger/IM/Home/?source=text_hotmail_join ) -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Fri Jan 18 23:57:31 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 18 Jan 2008 23:57:31 +0100 Subject: [M3devel] incremental build always rebuilds cm3, never produces the same thing -- what time is "now"? 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> <477EA137.1E75.00D7.1@scires.com> <478D394B.1E75.00D7.1@scires.com> <478D47FB.1E75.00D7.1@scires.com> <478DBF8D.1E75.00D7.1@scires.com> <478DE973.1E75.00D7.1@scires.com> <47908659.1E75.00D7.1@scires.com> Message-ID: <20080118235731.i77fhwy4ys8k0og4@mail.elegosoft.com> Quoting Jay : > In m3-sys\cm3, incremental build always rebuilds cm3, never produces > the same thing. > > I know exactly why. My modification to Olaf's timestamping (which I > think he approved, > but perhaps didn't realize this outcome). I know of this problem and don't think it's of much importance. > Because we generate a source file with the current time, and it > always changes. It's not only that: we could fix the time and it would still rebuild, because the Version module is always generated, regardless if it's needed or not. Of course this could be fixed, too. > Is this ok with people?I know it has downsides, but it might be ok. > You know: > 1) incremental build should really never do anything, never > writing anything, fast > which is important -- never write, or be fast? both? > 2) You might want to compare two full builds and determine they > are identical; the less of this sort of thing the better > If not, what do people suggest for a way to determine when to update > the time? > The logic before I think was essentially never, unless you went and > deleted a specific file. > Perhaps that is right, once it is discovered and publicized. > Perhaps another output directory is needed -- say / > -- that upgrade and make-dist, perhaps, know to delete, and maybe > realclean...of cm3? deletes? Hey, maybe just declare an output, with > "..", in the m3makefile, so merely clean and realclean update the > time, but incremental builds do not? This seems obviously the way to > go right now, but still slightly debatable. Like, maybe an accurate > timestamp is needed. Maybe if any other source or .lib changes, the > timestamp should change -- so, like, m3_back/m3_link could > regenerate the file, except that might be too late. > > Should "now" be less granular than a second? That mitigates the > problem but i think is not satisfactory.Should "now" be overridable > on the command line or with an environment variable? Again I think it's not worth bothering about. The cm3 package will only be rebuilt by its developers and maintainers, and they can easily disable the mechanism if they want to. Or by end users performing an upgrade, but they should do it based on a script. The correct time to use would indeed be the last modification time of all the sources files compiled and linked into cm3. I've thought about this for half a day, but it would be a hell of an effort to program based on CVS. (If anybody finds an easy solution to do this, I'd be very interested.) The time stamp is just to imprint in releases and snapshots when the compiler was actually built and helps to relate problem reports to system releases. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Jan 19 00:03:18 2008 From: jayk123 at hotmail.com (Jay) Date: Fri, 18 Jan 2008 23:03:18 +0000 Subject: [M3devel] my status on win32 In-Reply-To: <20080118234226.8g4fi0mkgwgscwww@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> <477EA137.1E75.00D7.1@scires.com> <478D394B.1E75.00D7.1@scires.com> <478D47FB.1E75.00D7.1@scires.com> <478DBF8D.1E75.00D7.1@scires.com> <478DE973.1E75.00D7.1@scires.com> <47908659.1E75.00D7.1@scires.com> <20080118234226.8g4fi0mkgwgscwww@mail.elegosoft.com> Message-ID: Ok, that shuts me up well. I will continue to party in the *.py files and mostly avoid the *.sh files. And then, still, *.cmd vs. *.py? I suspect the answer is "The Windows folks, Jay being the most vocal/active at the moment, can do what they want" (which is partly why I am here -- to be in the "partially independent minority". :) ) I stopped reading usenet years ago but from time to time wonder if it might be "useful". I have at least two problems with using Modula-3 here but I might be somewhat or wrong or very wrong. 1) I have been unable to aquire a taste for it. 2) What about bootstrapping? This is a more general and relevant question that I have . >>>> From what version are you expected to be able to boot what version? Is it ok for merely version n to only be bootrappable, or upgradable, from version n (for upgrade) or n - 1 (bootstrap)? Or downgrade from anything > n? "Version n" isn't even well defined..or is that because I don't know about pkgtags? Any increased dependency on Quake worries me here, until I understand this. Yet, unless you can be clever and a) make all new things optional b) write all new things in both M3 and Quake, or M3 and SH, or M3 and whatever, forward progress is entirely blocked in Quake, and that probably can't be the right answer. Arguably either way -- required changes must be possible at any point in the stack at any time. Nothing is unchangable. Don't go crazy. Don't change things for no reason. But if a change is needed, it can be done. OR, alternatively, some things really cannot be changed, as they would require rewriting all or at least a whole heck of a lot of code. The world is round, and that cannot change, until such time as the world is gone, and all of us with it, for example. Modula-3 files have the extensions .m3 and .i3. I could be wrong, but there will never ever be a reason to change that, for example. I can bootstrap on Windows from 5.1.3. I have 4.1 and 3.6 but haven't tried yet. I believe 3.6 won't work since I /think/ cm3 uses WIDECHAR or such. 3.6 definitely still "works" on its own, nice. I am not sure there is any point to those exercises. Having them working independently may be useful for comparison and history, but that is different than booting. - Jay > Date: Fri, 18 Jan 2008 23:42:26 +0100> From: wagner at elegosoft.com> To: jayk123 at hotmail.com> CC: rcoleburn at scires.com; m3devel at elegosoft.com> Subject: Re: [M3devel] my status on win32> > Quoting Jay :> > > I'll see about adding usage statements.> > Basically all the do* scripts accept a "command" and a list of packages.> > The commands are:> > realclean> > clean -- pretty useless imho> > buildlocal -- the default> > ship> > buildship -- build and shpi> > buildglobal> > Actually, the more useful commands are> > build -- build with overrides to ROOT> buildship (same as buildglobal) -- build with global package pool> realclean -- completely delete derived target files> > > do-pkg requires a list.> > If you're doing you're own project, this may be what is most useful> -- if you use the scripts at all.> > > What do folks think of deleting all of scripts\win and having only > > scripts\python?> > I guess you have to try them out first, at least.Scripts\python > > achieves parity pretty much, except for the more logging to files, > > less logging to the console, that win\make-dist has.> >> > Furthermore, out on a limb, what do folks think of deleting most of > > scripts\*.sh and having just Python?> > I'd object to this. Shell is POSIX standard, and most of the> infrastructure is built on it; Python is nice to have, but should> not be a prerequisite to CM3.> > > I doubt this will fly and I will try resist mentioning it often. :)> > In the interest of consensus here, though I doubt it will help, I'd > > be open to rewriting python in Perl, or possiby even Tcl.> > Why?> > > I am also willing/interested in discussing the merits of these > > languages, or an as yet undeveloped one "ideal language" (Modula-3 I > > don't think is it, sorry), but probably most people will find it a > > waste of time. Where is the geek-out-really-badly mailing list? :)> > I don't see the point in rewriting the scripts in yet other languages.> The purpose of the scripts is to support the installation, administration> and maintenance of the CM3 distribution. They were not intended as> a general purpose build or automation environment, though they can> be used for this purpose to a certain extent. But the main point is> that they are useful for the people maintaining the distribution.> > We could think about rewriting everything in M3 to further reduce> the system dependencies, but this would not be as flexible as a> general scripting language. Quake would need to be substantially> extended, and Python is nice, but a huge software distribution in> itself, that should be independent of CM3.> > POSIX shell is the one common interpreter I have found to be available> on almost all systems. (Even when we were programming point-of-sale> solutions on DOS in the early 90s we had ksh and other POSIX tools there> to emulate the Sun development environment we used on the servers.)> OK, on Windows you have to install it (e.g. in form of Cygwin) like> Python, but it's still the best choice wrt. availability and portability> I've found.> > For general discussions of the advantages and disadvantage of> programming languages, some of the comp.lang.* newsgroups may> be the better choice, though I haven't read them for years now> and don't know if they're still alive.> > As for the ideal language -- I don't think that there is any language> that could claim this. The advantages and disadvantages depend heavily> on the usage context, environment, and skills and understanding of the> programmers.> > (M3 is pretty good 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> _________________________________________________________________ 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 Jan 19 00:25:33 2008 From: jayk123 at hotmail.com (Jay) Date: Fri, 18 Jan 2008 23:25:33 +0000 Subject: [M3devel] my status on win32 In-Reply-To: <4790E7A7.1E75.00D7.1@scires.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> <477EA137.1E75.00D7.1@scires.com> <478D394B.1E75.00D7.1@scires.com> <478D47FB.1E75.00D7.1@scires.com> <478DBF8D.1E75.00D7.1@scires.com> <478DE973.1E75.00D7.1@scires.com> <47908659.1E75.00D7.1@scires.com> <4790E7A7.1E75.00D7.1@scires.com> Message-ID: I'm an old guy that started with 143k floppies. :) I don't like calling them "scripts" either. They are "programs", in varying languages, needing "compilation" or not. cmd is an awful language and deserves some derisive label, but Perl and Python seem to strive to be pretty complete and large maintainable well *engineered* systems have been built with them. If I may stretch the point, they are "systems" programming languages, for "system" meaning "large well engineered modular maintainable long lived reliable blah blah system", not "operating system" or in particular "kernel". Perl has some problems. Python has some problems. They both have some "magic" "developer productivity" improvements, and that can be a bad thing, it can lead to programming faster with less design/engineering. Olaf I didn't answer your question "why?" And it is moot. For whatever temporary or permanent condition, I don't like "sh". I have tried to learn it several times and always get lost in a haze of special things to keep in mind, portability concerns, inability to build data structures perhaps. Not that "special things to keep in mind" prevented *.cmd from being created, maybe I put more persistance there, or a younger self. I have run MS-DOS relatively recently and been amazed at how limited command.com is. I don't think portability to .bat is feasible while accomplishing much approaching the *.sh. (Dare I mention a DJGPP port? No such thing exists, but, hey, gcc, consider making garbage collection and threading optional pending further research.., the djgpp posix-ish runtime....seems feasible, not sure what people do with this environment though....and besides, Python exists built with djgpp so whil djgpp might be a viable interesting port, command.com remains irrelevant..) Randy I kind of agree with your sentiment about the "native environment", and reducing dependencies, it is a common one, HOWEVER I believe it is a gray one, and the pay off to compromising it can be substantial. There will be a NT386GNU target, and unless we import ld, as, (and I'm not going to do so) and more, it will likely always require getting cm*.tar.gz and at least one other file onto your system to build m3cc. There was work on a linker written in Modula-3, so in fact, using the system might be possible without gcc/ld/as, or even without Visual C++. However m3core has some C code, so building it, for the forseeable future, will continue to require a C compiler. (I think this C code is cutable, that I have seen -- hand/dtoa, and at least Win32 Errno). It is possible that the cm3 gui installer will prompt "Do you want to be able to build the ENTIRE system, including the compiler from source", and if so, for NT386GNU look for the local installs, else get and install them, or for NT386 plop you in IE's at microsoft.com (EULAs and all that..)." Try installing the free/open Qt for example. It will get MingW for you. In this model, what is extra? Where does one download/dependency end and the next begin? In terms of the user experience, not clear. I am aware of your programs and while they appear well designed/documented/developed, I like to do things myself. I have been tempted to ask "Mind if I delete yours and move mine up into that directory" but thought it maybe too rude. Thanks for the compliment, and you should keep at it (the contributions, not the compliments, or both. :) ) If you want an explanation of something I did, ask. Buildship, buildlocal, buildglobal..uh oh, you did ask.and I doubt I can explain this well, not sure I understand it well. Will try later maybe, or see what anyone else says first. - Jay Date: Fri, 18 Jan 2008 17:53:45 -0500From: rcoleburn at scires.comTo: m3devel at elegosoft.com; jayk123 at hotmail.comSubject: RE: [M3devel] my status on win32 Jay: What does "buildglobal" mean? How is it different from "buildship"? As far as "scripts" go, I'm an old guy that started out with computers that had real core memory. When the IBM PC revolution hit, I was already a professional and had mastered large computers with network operating systems and even micro-computers with CP/M. I learned DOS and became a good "BAT" batch file programmer (we didn't call them scripting languages back then). I'm still pretty good with Windows CMD files, but have not tackled python. My vote for cm3 on Windows is to avoid making the end user (customer) have to learn or acquire things that aren't native to his environment. Thus, I would argue for use of CMD files on Windows instead of some other scripting language. This same reasoning is why I was pushing for the all-in-one installation program for cm3 on Windows. If all a "Windows person" has to do to get cm3 modula-3 up and running on his box is to run an install program and possibly tweak a few CMD scripts to his/her liking, then it is "easy". Forcing acquisition and installation of other tools/environments just to get started makes things complicated and increases the barrier to startup and acceptance. Just my 2 cents worth. A few years ago, I contributed some BAT/CMD files that could be used to build the entire system on Windows. The only issue is that as the system evolves, you have to keep the package build order up to date. I don't mind trying to help out further in this area. You seem to be very technically capable, so perhaps what I can offer pales in comparison. Thanks for all you are doing. Let me know if/how I can help. Regards, Randy>>> Jay 1/18/2008 4:50 PM >>>I'll see about adding usage statements.Basically all the do* scripts accept a "command" and a list of packages.The commands are: realclean clean -- pretty useless imho buildlocal -- the default ship buildship -- build and shpi buildglobal The .sh and .py have a usage explaining this but .cmd is missing it, probably because I didn't fully understand at the time the functionality of the code I was blindy porting. do-* except for do-pkg have an implied list of packages. Maybe you can add to it, would have to check the source. do-pkg requires a list. Most of the rest are not meant to be user-callable -- sysinfo, pkginfo, pkgcmds. make-dist its its own thing. Oh, right -- environment variables. Many things are overridable with them, and need documentation the same. What do folks think of deleting all of scripts\win and having only scripts\python?I guess you have to try them out first, at least.Scripts\python achieves parity pretty much, except for the more logging to files, less logging to the console, that win\make-dist has. Furthermore, out on a limb, what do folks think of deleting most of scripts\*.sh and having just Python?I doubt this will fly and I will try resist mentioning it often. :)In the interest of consensus here, though I doubt it will help, I'd be open to rewriting python in Perl, or possiby even Tcl. I am also willing/interested in discussing the merits of these languages, or an as yet undeveloped one "ideal language" (Modula-3 I don't think is it, sorry), but probably most people will find it a waste of time. Where is the geek-out-really-badly mailing list? :) - Jay Date: Fri, 18 Jan 2008 10:58:36 -0500From: rcoleburn at scires.comTo: m3devel at elegosoft.com; jayk123 at hotmail.comSubject: Re: [M3devel] my status on win32 Jay: Ok. It will be later tonight before I can try again. Thanks! BTW, can you point me to a document/file somewhere that describes the various options for your windows command file scripts? I did experiment further with using the do-cm3-std.cmd and was finally able to get most everything to build, but of course this doesn't rebuild the compiler and core. Had problems with mentor and m3zume not wanting to build/run, so I commented these out in the cmd file to get it to work. Then I had trouble because everything was built with overrides by default, so I had to mess around with changing parameters and rebuilding clean. I've tried building some of my programs and, of course, have run into a few problems due to changes in the system. I've overcome most of these, but I am seeing some strange behavior: 1. pixmaps aren't rendered properly on the screen. They look really bad. I recall having this problem a while back with one of the early 5.x releases, so I guess it was never solved. I've got some old test programs I try to dig out and see if I can find out what is going on. I seem to recall that building standalone in the past seemed to fix the problem, so this is a real mystery. 2. I'm having trouble with bundles not returning all of the data. In the "reactor" program, bundles are used to provide input to the web browser for the page source. I'm seeing cases where not all of the HTML source is making it to the browser. Not sure if this is an I/O problem (maybe buffers not flushed) or if it is something else. It may be that this problem has some impact on #1 above because pixmaps are sometimes stored in the bundles. For the above #1 and #2, these things worked properly on cm3 v4.1. I have the sources to 4.1, so maybe I can use them to figure out what is wrong. On a side note, I found and fixed a major bug in the "reactor" program, so that is good. Now, for another topic that we should probably move to a new email thread: Back in the early days, my company paid Critical Mass, Inc., to customize the Trestle/FormsVBT look and feel to more closely resemble Windows. I have the sources for this work, but of course it is based on v4.1 and the repository code has moved on since then. I am curious if anyone would be interested in me trying to integrate these customizations back into the current source tree, perhaps on a different branch? If we go this route, I may need a little refresher tutorial on the use of branches in CVS. We would want to make it so that the main branch and the customized branch could evolve in sync. That is, if a bug was found in either branch, the fix should be incorporated into both. Regards, Randy>>> Jay 1/18/2008 10:32 AM >>>Randy, please try with an updated m3-sys/cm3/src/version.quake and report back, thanks.I understand why I wasn't seeing this. - Jay Date: Wed, 16 Jan 2008 11:24:34 -0500From: rcoleburn at scires.comTo: m3devel at elegosoft.com; jayk123 at hotmail.comSubject: Re: [M3devel] my status on win32 Jay: Not sure I've clued in to all of your dialog. Sorry. I have in the past used a free tool to build an installer package and I was thinking of using it again. Since the tool is free, we could put all the work I do into the CVS repository so that others could also maintain it. What I am looking to achieve is to have a way where a "normal" Windows user could download a program, run it, and have all of the cm3 packages installed without having to use the MIN distribution to build it up or any other tools to get the sources (like cvs). You could achieve the same thing by having a big ZIP file also I suppose, but having the installer would also let us easily put something in the start menu to launch a command line with all the environment variables set properly via automatic call to vcvars et al. When I get "Reactor" working, it too could be put into the start menu. That just makes it fit in better with the Windows user culture I think. The reason I wanted to rebuild everything is two-fold: 1) ensure it can be done (i.e., test for "Broken #1"), and 2) get all of the rest of the packages built so I could then use cm3 to build "reactor" and my own programs and test them to see if there are any "Broken #2" issues. The MIN distribution is really insufficient to do much of anything except to build the rest of the packages you need. My understanding is that I needed to use CVS to get the current sources, because if I went back to the source archive, it was old and known to be Broken #1 on Windows. I'm glad that you believe the current "Broken #1" situation is easy to fix. Let me know what to do and I'll give it another try. My experience in the past has been that there are 3 conditions to getting cm3 to work properly on windows after it has been installed: 1) make sure your environment variables are set up by vcvars to point to the compiler/linker/libraries (of course if you used a non-Microsoft C compiler/linker you would need to use something other than vcvars); 2) make sure cm3.cfg has the right paths in place to find all the libraries and tools using DOS style short names (no embedded spaces); and 3) make sure C:\cm3\bin is in your path. Of these, #2 & #3 are essentially one-time events, and #1 can be set up by a invoking a batch/command file via a shortcut, so no big deal for me. You could even make #1 a one-time event by modifying the system-level (vice user-level) environment variables. The old cm3install program seemed to do a decent job of #2 for me. Also, I've noted some of your past dialog about accepting either '/' or '\' as a path separator. I'm sure you are aware that on Windows '/' is used often for switches (arguments). Plus Windows also allows spaces to be embedded in the command line, so whatever solution you propose needs to take into account that a valid command line might look like this: C:\My Program Folder\My Program.exe /myArg1 /myArg2 In some situations, this command line would have to be quoted and rendered as: "C:\My Program Folder\My Program.exe" /myArg1 /myArg2 and in places where the backslash is an escape character, I've seen "C:\\My Program Folder\\My Program.exe" /myArg1 /myArg2 Alas, I seem to have rambled a bit also. Sorry. The immediate need for me now is to solve the Broken #1 condition, so please let me know how to fix it and proceed. Regards, Randy>>> Jay 1/16/2008 10:28 AM >>>Randy, yes and no and clarifications. I mention starting with 5.1.6 as a "worst" or "worse" case.The earlier you start, the harder things are -- for me, to ensure it will work. If you merely start with my 5.5.0, well, what are you rebuilding from source for?Heck, you can use any binary distribution, 4.1, 5.1.6, and just use it. They should work. The n steps you/I give are really actually geared for people who WANT to build from source, it is not what people HAVE to do.As well there have been can be source distributions, to cut out CVS. I'll look into the datefn stuff shortly. As to the installer, well, again, yes and no.The need for the installer is very small. All you have to do today is unzip the .zip somewhere and set the path, and possibly the vcvars thing. That's it. I should..now that you are "pressuring" me for ease of use, teach cm3 about the various ?venvdir%, %vcinstalldir% variables, etc. That way as long as the user installed the tools, even if they elected not to change path/lib/include, cm3 can find the compiler and linker. I know everyone wants to preserve the flexibility of quake/cm3.cfg but...besides, cm3 can be pretty darn smart here. IF cm3.cfg defines SYSTEM_CC, leave things along (NT386 cm3.cfg does not today do that). However if there is now SYSTEM_CC and there is no cl.exe/link.exe in %PATH%, it could go on a quick hunt for them. On the lib and include part, well, the dependency on %include% might only be for errno..maybe not worth it. It has been whatever it is forever, like int* _errno(void); #define errno (*_errno)()). Modula-3 engages in rampant header cloning and CErrnoC was only introduced where that was deemed more fragile than usual, and for Windows it probably wasn't actually fragile -- the fragility, if I may be so rudely judgemental, is because so many other systems are so Johnny-come-lately to arriving at the obviously correct threading model that Windows has had all along (since Win95/NT, can't say anything good about Win3.1; I think OS/2 might have had it correct all along too.). Funny, everyone has FINALLY arrived at the correct threading model, only to have start changing again, since the number of cores and machines is set to be much greater than anticipated, the obvious threading model has been deemed too difficult for anyone to use (Win32, Modula-3, Java, .NET, Python, all the same supposedly too difficult model btw), and so some new one is needed, and well, truthfully, the difficulty is not just for dummies on relatively small multiproc boxes not having simple race conditions, the problem is scaling way way up. Sorry that was my usual tangential. Even the unzip and set path would benefit slightly from a GUI installer.I believe there is some easy thing you can do where you write your GUI installer and you put it in the .zip and then you prepend the GUI self extracting .zip/.exe stub, and you can tell it to run a particular command after the extraction. I guess you might use a fancier thing though?That is, are you going to, say, write a gui installer from scratch in Modula-3? It might be a fun exercise. :)And then you could build the self extracting prefix from source etc.This is the hard way I guess, but more interesing.If you can build an msi or use InstallShield or Wix or something, go ahead.If you use widely availabe free as in beer tools, that can be rolled into whatever automation there is to produce distributions, keeping it up to date shouldn't be a problem. I do have to bring up some annoying questions: 1) Does anyone besides me have the capacity to produce distributions? i.e.: Any Win32 machines left at Elego? 2) I know I ramble. So one of my many tangents/questions went unanswered.Say, in the absence of a gui installer, should .zips/.tar.bz files look like cm3-min-/bin/cm3orbin/cm3orcm3/bin/cm3 The last one is more directly usable. The first one is very common. This reminds me though Randy, the distribution I made available was "min", so yeah, like if you are doing any gui programming, using any "standard" library besides m3core or libm3, you'd need to build more from source. I can readily provide you a "std" distribution though.It's "always" been a "problem" to make my files available -- no web site hosting for me -- but recently that wasn't a problem, someone picked the files out of ~jkrell on birch and put them on the web site. Good. One more thing -- Olaf, please confirm repeat yourself, 'cause I admit I wasn't sure it was the right thing, but if you insist, ok. "std" should be "all"? I should not continue to imagine there is a new larger group called "all"? And wherever things are missing from std but do build ok, add them?m3cc should be in std?(I admit some big indecisiveness around m3cc. It is far and away the longest thing to build and so the one you really want to skip the most and leave out of whatever package group. I also wonder if on Windows, there should be some check where if sh is not in the $PATH, just silently skip m3cc? You only need MingWin to build what I have on my system for NT386GNU, except you also need msys just for m3cc. msys is actually quite small, like only 20 files..) Oh, sorry, yet another question.The non-gcc backend is excluded from the build on systems that use the gcc backend.For minimization, that is appropriate.For maximizing cross build capability, it is wrong.The packages build fine. I suspect they work.I am not a user of cross build capability yet, so I don't really care. (What I do for NT386/NT386GNU /might/ be considered sort of a cross build, but it is different/easier).They are small packages. - Jay Date: Wed, 16 Jan 2008 08:25:49 -0500From: rcoleburn at scires.comTo: m3devel at elegosoft.com; jayk123 at hotmail.comSubject: Re: [M3devel] my status on win32 Jay: There is no line in the m3makefile dealing with datefn, so I added the whole statement just before the line include("version.quake") Now, I get an error saying that the variable datefn is not defined. If you change to put quotes around datefn in the include statement, you get an error saying it can't open the file. You made a reference in one of your earlier posts about trying 5.1.6 or 4.1, but note that I started with your cm3-min-WIN32-NT386-d5.5.0.zip , not the 5.1.6 or 4.1 versions. Thus, using d5.5.0 as a base, I am trying to run your "upgrade.cmd" to rebuild the sources I checked out from CVS. Since this doesn't work "out-of-the-box", again I say this fits into the "Broken #1" category. If I can get this to work, I don't mind putting together a Windows installer program that will install the whole thing. That way, folks won't have to install cygwin just to get CVS so that they can install a working cm3. Folks will need to install the free Microsoft Visual C as a prerequisite, but then that's not too bad. Having an installer program would make cm3 more friendly to Windows folks. The current 16-step method is too laborious and error-prone for the person just getting started and they will not give cm3 a second try. As the cm3 system evolves and new releases are made, we will need to keep the installer program up-to-date and I don't mind doing that. After someone gets familiar with cm3 they might want to delve into some of the scripts for rebuilding the system, but until then, I think the installer program is the way to go. Regards, Randy>>> Jay 1/16/2008 1:01 AM >>>I think I see the problem. in cm3\src\m3makefile, make this change > if not defined("NOW") include(datefn) > end datefn is only created if certain other variables aren't defined, and do-pkg defines them.I don't know why I don't see this. Later.Could be that the Python scripts have a typo and don't define them.I've been using them more than cmd. If the host is NT, "NOW" is either gotten from an updated cm3.exe, or left to "not available". So the initial cm3 built from older cm3 can't report when it was built, but cm3 built from current cm3 can. I need to change that: 1) to be a function for niceness 2) to make it that way for Posix, for any host but I haven't been using Posix as much lately so not testing it. - Jay Date: Tue, 15 Jan 2008 23:55:39 -0500From: rcoleburn at scires.comTo: m3devel at elegosoft.com; jayk123 at hotmail.comSubject: RE: my status on win32 Jay: In the file version.quake, I made the following edit: changed line: local datefn = "../" & TARGET & ".datenow" to: local datefn = ".." & SL & TARGET & ".datenow" This change has the effect of putting a backward slash in the pathname instead of a forward slash, so we getC:\CM3_CVS_SourceTree\m3-sys\cm3\src\..\NT386.datenow So from that perspective, the change seems good. Unfortunately, I still get the error that this file can't be opened. A quick check of C:\CM3_CVS_SourceTree\m3-sys\cm3\NT386 shows that the file .datenow does not exist. Regards, Randy>>> Jay 1/15/2008 11:03 PM >>>That's not too bad really. 1) I'd recommend putting cm3 at the start of the path instead of the end. 2) Just comment out the offending code to make progress. It's not critical. >> C:\CM3_CVS_SourceTree\m3-sys\cm3\src\../NT386.datenow The code is: C:\CM3_CVS_SourceTree\m3-sys\cm3\src\version.quake or such, included by cm3\src\m3makefile. Does the file exist?Does version.quake use "/" or "SL"? If it uses "/", try replacing with SL (and ampersand for string concat). Could be that a newer binary distributions works better with forward slashes. > 4. > 5. > 6. Launch cygwin from desktop icon. Cygwin is only needed for cvs, I think you realize. Could you send me offline the result of just running "set" after running vcvarsall? I'd like to adapt pylib.py to it maybe. (I can start from 5.1.6 and will try 4.1 at some point.) - Jay Date: Tue, 15 Jan 2008 22:52:59 -0500From: rcoleburn at scires.comTo: m3devel at elegosoft.com; jayk123 at hotmail.comSubject: my status on win32 Jay et al: I've listed below the steps I've undertaken to try and build the current sources on Windows XP. I've also attached a text file showing the output I got when trying to build everything using Jay's upgrade.cmd script. Unfortunately, I'm getting a build error (see below). Please advise on how to resolve. STEPS I TOOK: ========= 1. Download Microsoft Visual Studio 2008 Express Edition All-in-One .ISO file and burn to DVD. http://www.microsoft.com/express/download/ 2. Install Microsoft Visual C++ 2008 Express Edition from DVD. 3. Use "Microsoft Update" service to check for updates / service packs. 4. Download cygwin setup program from http://cygwin.com/ 5. Ran cygwin setup.exe program to install cygwin for all users. Under "Devel" category, make certain to select "cvs" for installation. 6. Launch cygwin from desktop icon. 7. In cygwin command shell window, execute following two commands, making sure to give email as password when prompted for login: cvs -d :pserver:anonymous at modula3.elegosoft.com:/usr/cvs login cvs -d :pserver:anonymous at modula3.elegosoft.com:/usr/cvs checkout cm3 8. Moved resulting C:\cygwin\home\rcoleburn\cm3 to C:\CM3_CVS_SourceTree Note that you should replace "rcoleburn" above with your Windows login username. 9. Download cm3-min-WIN32-NT386-d5.5.0.zip and cm3-min-WIN32-NT386-d5.5.0-symbols.zip from http://modula3.elegosoft.com/cm3/download.html 10. Unzipped cm3-min-WIN32-NT386-d5.5.0.zip and stored resulting cm3 folder at C:\cm3 11. Unzipped cm3-min-WIN32-NT386-d5.5.0-symbols.zip and stored resulting symbols folder at C:\cm3\symbols 12. Launch Windows Command Prompt shell. The following steps represent commands executed within this shell. 13. path %path%;c:\cm3\bin 14. "C:\Program Files\Microsoft Visual Studio 9.0\VC\vcvarsall.bat" 15. cd C:\CM3_CVS_SourceTree\scripts\win 16. upgrade.cmd ERROR I'M GETTING: ============= === package C:\CM3_CVS_SourceTree\m3-sys\cm3 ===+++ "cm3 -build -DROOT=C:\\CM3_CVS_SourceTree -DCM3_VERSION_TEXT=d5.5.1 -DCM3_VERSION_NUMBER=050501 -DCM3_LAST_CHANGED=2007-12-30 && cm3 -ship -DROOT=C:\\CM3_CVS_SourceTree -DCM3_VERSION_TEXT=d5.5.1 -DCM3_VERSION_NUMBER=050501 -DCM3_LAST_CHANGED=2007-12-30" +++--- building in NT386 --- ignoring ..\src\m3overrides "C:\CM3_CVS_SourceTree\m3-sys\cm3\src\version.quake", line 136: quake runtime error: unable to open "C:\CM3_CVS_SourceTree\m3-sys\cm3\src\../NT386.datenow" forreading --procedure-- -line- -file---include -- version_impl 136 C:\CM3_CVS_SourceTree\m3-sys\cm3\src\version.quakeinclude_dir 20 C:\CM3_CVS_SourceTree\m3-sys\cm3\src\m3makefile 8 C:\CM3_CVS_SourceTree\m3-sys\cm3\NT386\m3make.args Fatal Error: package build failedERROR: "cm3 -build -DROOT=C:\\CM3_CVS_SourceTree -DCM3_VERSION_TEXT=d5.5.1 -DCM3_VERSION_NUMBER=050501 -DCM3_LAST_CHANGED=2007-12-30 && cm3 -ship -DROOT=C:\\CM3_CVS_SourceTree -DCM3_VERSION_TEXT=d5.5.1 -DCM3_VERSION_NUMBER=050501 -DCM3_LAST_CHANGED=2007-12-30"ERROR: cd C:\CM3_CVS_SourceTree\m3-sys\cm3ERROR: set INSTALLROOT=c:\cm3 Regards, Randy Share life as it happens with the new Windows Live. Start sharing! Put your friends on the big screen with Windows Vista? + Windows LiveT. Start now! Get the power of Windows + Web with the new Windows Live. Get it now! 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. _________________________________________________________________ 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 Sat Jan 19 00:38:45 2008 From: jayk123 at hotmail.com (Jay) Date: Fri, 18 Jan 2008 23:38:45 +0000 Subject: [M3devel] NT386GNU diffs In-Reply-To: <4790E7A7.1E75.00D7.1@scires.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> <477EA137.1E75.00D7.1@scires.com> <478D394B.1E75.00D7.1@scires.com> <478D47FB.1E75.00D7.1@scires.com> <478DBF8D.1E75.00D7.1@scires.com> <478DE973.1E75.00D7.1@scires.com> <47908659.1E75.00D7.1@scires.com> <4790E7A7.1E75.00D7.1@scires.com> Message-ID: I think attached is all the diffs I have for NT386GNU. They are: "rewrite" NT386GNU config fileThe diff and result are present.It almost exactly matches NT386.In fact, the targets can perhaps be merged into one configurable target,and NT386GNU be "reclaimed" for the more Posix port people want.But not right now. setjmp to _setjmpThis "works" with Cygwin and MinGW, whereas setjmp doesn't."Works" as in links. I should double check this. Maybe not needed. Just one line.. Changes NT386GNU from Posix to Win32. Any objects to commiting? The result is you can build a lot of NT386GNU, but it won't run.I would say it won't "quite" run, but I can't claim to know all that is wrong. Yes, I understand, getting it to run is very important. This may be progress,but isn't useful yet. - 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 Sat Jan 19 00:42:56 2008 From: jayk123 at hotmail.com (Jay) Date: Fri, 18 Jan 2008 23:42:56 +0000 Subject: [M3devel] m3cc/fopen("rb") In-Reply-To: <4790E7A7.1E75.00D7.1@scires.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> <477EA137.1E75.00D7.1@scires.com> <478D394B.1E75.00D7.1@scires.com> <478D47FB.1E75.00D7.1@scires.com> <478DBF8D.1E75.00D7.1@scires.com> <478DE973.1E75.00D7.1@scires.com> <47908659.1E75.00D7.1@scires.com> <4790E7A7.1E75.00D7.1@scires.com> Message-ID: I changed m3cc to use fopen("rb") instead of fopen("r"), needed for NT386GNU. Yet I just found this: C:\cm3-4.1\binutils-2.7\gas\config\go32.cfg /* Some operating systems, for example DOS, require the use of "wb" mode when opening a binary file for writing. If only "w" is used, the file will not be correct. However, some other systems reject such a mode. This indicates which ../include/fopen-*.h header file we want to include, so that we can get macros that'll do the right thing for this system. */#define WANT_FOPEN_BIN 1 Does it matter? - 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 Jan 19 00:43:51 2008 From: jayk123 at hotmail.com (Jay) Date: Fri, 18 Jan 2008 23:43:51 +0000 Subject: [M3devel] NT386GNU diffs 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> <477EA137.1E75.00D7.1@scires.com> <478D394B.1E75.00D7.1@scires.com> <478D47FB.1E75.00D7.1@scires.com> <478DBF8D.1E75.00D7.1@scires.com> <478DE973.1E75.00D7.1@scires.com> <47908659.1E75.00D7.1@scires.com> <4790E7A7.1E75.00D7.1@scires.com> Message-ID: attached this time.. From: jayk123 at hotmail.comTo: m3devel at elegosoft.comDate: Fri, 18 Jan 2008 23:38:45 +0000Subject: [M3devel] NT386GNU diffs I think attached is all the diffs I have for NT386GNU.They are:"rewrite" NT386GNU config fileThe diff and result are present.It almost exactly matches NT386.In fact, the targets can perhaps be merged into one configurable target,and NT386GNU be "reclaimed" for the more Posix port people want.But not right now.setjmp to _setjmpThis "works" with Cygwin and MinGW, whereas setjmp doesn't."Works" as in links. I should double check this. Maybe not needed.Just one line..Changes NT386GNU from Posix to Win32.Any objects to commiting?The result is you can build a lot of NT386GNU, but it won't run.I would say it won't "quite" run, but I can't claim to know all that is wrong.Yes, I understand, getting it to run is very important. This may be progress,but isn't useful yet. - 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: diff.zip Type: application/x-zip-compressed Size: 11639 bytes Desc: not available URL: From rcoleburn at scires.com Sat Jan 19 01:05:38 2008 From: rcoleburn at scires.com (Randy Coleburn) Date: Fri, 18 Jan 2008 19:05:38 -0500 Subject: [M3devel] my status on win32 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> <477EA137.1E75.00D7.1@scires.com> <478D394B.1E75.00D7.1@scires.com> <478D47FB.1E75.00D7.1@scires.com> <478DBF8D.1E75.00D7.1@scires.com> <478DE973.1E75.00D7.1@scires.com> <47908659.1E75.00D7.1@scires.com> <4790E7A7.1E75.00D7.1@scires.com> Message-ID: <4790F880.1E75.00D7.1@scires.com> >>> Jay 1/18/2008 6:25 PM >>> >>> I'm an old guy that started with 143k floppies. :) Floppies, what a luxury! I had to deal with paper tape, punched cards, and hard-wired plug boards to program old IBM tabulating machines. I've found no better finger muscle exercise than "typing" for hours on an old ITT canary-yellow roll paper teletype machine with a paper tape punch. And no, I don't long for the "good 'ol days" because in many ways they weren't so good... Regards, Randy -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Sat Jan 19 01:29:19 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 19 Jan 2008 00:29:19 +0000 Subject: [M3devel] FW: my status on win32 In-Reply-To: <20080118234226.8g4fi0mkgwgscwww@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> <477EA137.1E75.00D7.1@scires.com> <478D394B.1E75.00D7.1@scires.com> <478D47FB.1E75.00D7.1@scires.com> <478DBF8D.1E75.00D7.1@scires.com> <478DE973.1E75.00D7.1@scires.com> <47908659.1E75.00D7.1@scires.com> <20080118234226.8g4fi0mkgwgscwww@mail.elegosoft.com> Message-ID: darnit something keeps truncating my email. From: jayk123 at hotmail.comTo: wagner at elegosoft.comCC: rcoleburn at scires.com; m3devel at elegosoft.comSubject: RE: [M3devel] my status on win32Date: Fri, 18 Jan 2008 23:03:18 +0000 Ok, that shuts me up well. I will continue to party in the *.py files and mostly avoid the *.sh files. And then, still, *.cmd vs. *.py? I suspect the answer is "The Windows folks, Jay being the most vocal/active at the moment, can do what they want" (which is partly why I am here -- to be in the "partially independent minority". :) )I stopped reading usenet years ago but from time to time wonder if it might be "useful". I have at least two problems with using Modula-3 here but I might be somewhat or wrong or very wrong. 1) I have been unable to aquire a taste for it. 2) What about bootstrapping? This is a more general and relevant question that I have. >>>> From what version are you expected to be able to boot what version? Is it ok for merely version n to only be bootrappable, or upgradable, from version n (for upgrade) or n - 1 (bootstrap)?Or downgrade from anything > n?"Version n" isn't even well defined..or is that because I don't know about pkgtags? Any increased dependency on Quake worries me here, until I understand this. Yet, unless you can be clever and a) make all new things optional b) write all new things in both M3 and Quake, or M3 and SH, or M3 and whatever, forward progress is entirely blocked in Quake, and that probably can't be the right answer. Arguably either way -- required changes must be possible at any point in the stack at any time. Nothing is unchangable. Don't go crazy. Don't change things for no reason. But if a change is needed, it can be done. OR, alternatively, some things really cannot be changed, as they would require rewriting all or at least a whole heck of a lot of code. The world is round, and that cannot change, until such time as the world is gone, and all of us with it, for example. Modula-3 files have the extensions .m3 and .i3. I could be wrong, but there will never ever be a reason to change that, for example. I can bootstrap on Windows from 5.1.3.I have 4.1 and 3.6 but haven't tried yet.I believe 3.6 won't work since I /think/ cm3 uses WIDECHAR or such.3.6 definitely still "works" on its own, nice.I am not sure there is any point to those exercises.Having them working independently may be useful for comparison and history, but that is different than booting. - Jay [snip, deliberate] _________________________________________________________________ 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 Jan 19 01:47:11 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 19 Jan 2008 00:47:11 +0000 Subject: [M3devel] buildlocal vs. buildglobal vs. buildship explanation Message-ID: I'm not sure I can explain this well or if I fully understand it. "Ship" means "Install" Let's say your install is at c:\cm3 and your source is at c:\dev2\cm3 (I would use dev, but Unix took it.) Depending on the state of things, you probably two of many things: c:\cm3\pkg\libm3\nt386\libm3.libc:\cm3\pkg\libm3\nt386\libm3.dllc:\dev2\cm3\m3-libs\libm3\nt386\libm3.libc:\dev2\cm3\m3-libs\libm3\nt386\libm3.dll You will have more in \dev2\cm3\m3-libs\libm3\nt386. When you build stuff, you can use the installed dependencies or the just built dependencies. buildlocal uses the just built dependencies. buildglobal uses the installed dependencies buildship build and ships (installs) each directoryIt does it in one pass: buildship pkg1 pkg1 => build pkg1 ship pkg1 build pkg2 ship pkg2 and NOT build pkg1 build pkg2 ship pkg1 ship pkg2 You may only ship/install outputs that are builtglobal.Outputs are presumed to only be valid if "amidst" dependencies thatmatch the declarations and such they were built against -- i.e. the headers, in C. If you are starting with a minimal install, with just m3core and libm3, then you mustbuildship and you must do it in dependency order. (I just derived this rule, might be wrong.) It only matters for certain types of changes, and then it can really matter. You might change the format of some compiler-produced runtime-consumed data. You might have a bunch of .sos/.dlls. They can only work with each other if they match in certain ways. Again, ways which don't change that often, but sometimes do -- like changing public types. This is why you can get "fingerprint mismatches" -- when code has different notions as to a type definition. I guess that is when the "ship checking" is either inadequate or circumvented. It makes me wonder. What if there was a compilation mode in which all types were opaque. If all record field access to records defined in other packages were implemented by non-inlined dynamically linked getter/setter functions. It would be slow. It would be much more amenable to type changes -- removal/renaming/retyping of existing fields being the remaining "problems". Actually adding would be a problem too, clients of the new could not run against the old. - 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 Sat Jan 19 01:50:35 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 19 Jan 2008 00:50:35 +0000 Subject: [M3devel] FW: buildlocal vs. buildglobal vs. buildship explanation Message-ID: Besides getting truncated, newlines often get stripped from my emails. I wish for working email.. From: jayk123 at hotmail.comTo: m3devel at elegosoft.comSubject: buildlocal vs. buildglobal vs. buildship explanationDate: Sat, 19 Jan 2008 00:47:11 +0000 I'm not sure I can explain this well or if I fully understand it. "Ship" means "Install" Let's say your install is atc:\cm3 and your source is at c:\dev2\cm3 (I would use dev, but Unix took it.) Depending on the state of things, you probably two of many things: c:\cm3\pkg\libm3\nt386\libm3.libc:\cm3\pkg\libm3\nt386\libm3.dllc:\dev2\cm3\m3-libs\libm3\nt386\libm3.libc:\dev2\cm3\m3-libs\libm3\nt386\libm3.dll You will have more in \dev2\cm3\m3-libs\libm3\nt386. When you build stuff, you can use the installed dependencies or the just built dependencies. buildlocal uses the just built dependencies. buildglobal uses the installed dependencies buildship build and ships (installs) each directoryIt does it in one pass: buildship pkg1 pkg1 => build pkg1 ship pkg1 build pkg2 ship pkg2 and NOT build pkg1 build pkg2 ship pkg1 ship pkg2 You may only ship/install outputs that are builtglobal.Outputs are presumed to only be valid if "amidst" dependencies thatmatch the declarations and such they were built against -- i.e. the headers, in C. If you are starting with a minimal install, with just m3core and libm3, then you mustbuildship and you must do it in dependency order. (I just derived this rule, might be wrong.) It only matters for certain types of changes, and then it can really matter. You might change the format of some compiler-produced runtime-consumed data. You might have a bunch of .sos/.dlls. They can only work with each other if they match in certain ways. Again, ways which don't change that often, but sometimes do -- like changing public types. This is why you can get "fingerprint mismatches" -- when code has different notions as to a type definition.I guess that is when the "ship checking" is either inadequate or circumvented. It makes me wonder.What if there was a compilation mode in which all types were opaque.If all record field access to records defined in other packages were implementedby non-inlined dynamically linked getter/setter functions.It would be slow. It would be much more amenable to type changes -- removal/renaming/retyping ofexisting fields being the remaining "problems".Actually adding would be a problem too, clients of the new could not run against the old. - 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 Jan 19 01:56:57 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 19 Jan 2008 00:56:57 +0000 Subject: [M3devel] FW: buildlocal vs. buildglobal vs. buildship explanation Message-ID: one more try darnit.... From: jayk123 at hotmail.comTo: jayk123 at hotmail.comSubject: buildlocal vs.Date: Sat, 19 Jan 2008 00:55:31 +0000 "Ship" means "Install" Let's say your install is at c:\cm3 and your source is at c:\dev2\cm3 (I would use dev, but Unix took it.) Depending on the state of things, you probably two of many things: c:\cm3\pkg\libm3\nt386\libm3.lib c:\cm3\pkg\libm3\nt386\libm3.dll c:\dev2\cm3\m3-libs\libm3\nt386\libm3.lib c:\dev2\cm3\m3-libs\libm3\nt386\libm3.dll You will have much more in \dev2\cm3\m3-libs\libm3\nt386. When you build stuff, you can use the installed dependencies or the just built dependencies. buildlocal uses the just built dependencies. buildglobal uses the installed dependencies buildship build and ships (installs) each directory It does it one pass: buildship pkg1 pkg1 => build pkg1 ship pkg1 build pkg2 ship pkg2 and NOT build pkg1 build pkg2 ship pkg1 ship pkg2 You may only ship/install outputs that are builtglobal. Outputs are presumed to only be valid if "amidst" dependencies that match the declarations and such they were built against -- i.e. the headers, in C. If you are starting with a minimal install, with just m3core and libm3, then you must buildship and you must do it in dependncy order. It only matters for certain types of changes, and then it can really matter. You might change the format of some compiler-produced runtime-consumed data. You might have a bunch of .sos/.dlls. They can only work with each other if they match in certain ways. Again, ways which don't change that often, but sometimes do -- like changing public types. - 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 rcoleburn at scires.com Sat Jan 19 02:35:55 2008 From: rcoleburn at scires.com (Randy Coleburn) Date: Fri, 18 Jan 2008 20:35:55 -0500 Subject: [M3devel] FW: buildlocal vs. buildglobal vs. buildship explanation In-Reply-To: References: Message-ID: <47910DA8.1E75.00D7.1@scires.com> Jay: I understand the cm3 package and build system. I just didn't know what "buildglobal" meant. >From your explanation, I take it that buildglobal = (cm3 -build) + (cm3 -ship) together on a per package basis. If this is true, then buildglobal == buildship; i.e., there is no difference. You stated that the default of the script is buildlocal and I gather buildlocal = (cm3 -build -override). If so, I now see why I was confused. The default for the compiler is not to include the overrides file (at least that is my recollection from the 4.1 days--maybe its different now). So in my way of thinking, buildlocal = (cm3 -build) without doing any shipping. Perhaps a more self-explanatory option name for (cm3 -build -override) would be "buildoverrides". The system won't let you ship a package built with overrides, so that is why I ran into trouble trying to get everything installed using do-cm3-std without passing the buildship or buildglobal option. I've always liked the cm3 way of having a private source package tree where folks work on the code and then having a separate public package tree where folks "ship" their finished product. Yes, I know you wind up having the code in two places, but then you can "clean" up the derived files in your private tree to save space if needed. The old "reactor" documentation did a fairly good job of explaining the cm3 package concept and the idea of public and private repositories. I'm attempting to convert this document into something we can put back in the cvs repository. I have to take out all the trademarks and replace the graphics etc so it is a painful process without the original electronic source. I've resorted to scanning it in via a scanner and making edits. Regards, Randy >>> Jay 1/18/2008 7:56 PM >>> one more try darnit.... From: jayk123 at hotmail.com To: jayk123 at hotmail.com Subject: buildlocal vs. Date: Sat, 19 Jan 2008 00:55:31 +0000 "Ship" means "Install" Let's say your install is at c:\cm3 and your source is at c:\dev2\cm3 (I would use dev, but Unix took it.) Depending on the state of things, you probably two of many things: c:\cm3\pkg\libm3\nt386\libm3.lib c:\cm3\pkg\libm3\nt386\libm3.dll c:\dev2\cm3\m3-libs\libm3\nt386\libm3.lib c:\dev2\cm3\m3-libs\libm3\nt386\libm3.dll You will have much more in \dev2\cm3\m3-libs\libm3\nt386. When you build stuff, you can use the installed dependencies or the just built dependencies. buildlocal uses the just built dependencies. buildglobal uses the installed dependencies buildship build and ships (installs) each directory It does it one pass: buildship pkg1 pkg1 => build pkg1 ship pkg1 build pkg2 ship pkg2 and NOT build pkg1 build pkg2 ship pkg1 ship pkg2 You may only ship/install outputs that are builtglobal. Outputs are presumed to only be valid if "amidst" dependencies that match the declarations and such they were built against -- i.e. the headers, in C. If you are starting with a minimal install, with just m3core and libm3, then you must buildship and you must do it in dependncy order. It only matters for certain types of changes, and then it can really matter. You might change the format of some compiler-produced runtime-consumed data. You might have a bunch of .sos/.dlls. They can only work with each other if they match in certain ways. Again, ways which don't change that often, but sometimes do -- like changing public types. - Jay 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 jayk123 at hotmail.com Sat Jan 19 03:03:00 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 19 Jan 2008 02:03:00 +0000 Subject: [M3devel] FW: buildlocal vs. buildglobal vs. buildship explanation In-Reply-To: <47910DA8.1E75.00D7.1@scires.com> References: <47910DA8.1E75.00D7.1@scires.com> Message-ID: No electronic source? Wow that stinks. cm3 = cm3 -build = "buildglobal" buildglobal != buildship buildglobal means to build against global, but not to ship It is the normal thing to do, I think, when you aren't changing "too much". If you are building something for which all dependencies have already shipped and aren't changing, a typical little utility. Or if you aren't changing the fingerprints of any public types, I think. Certainly if you are only changing code. Not sure about changing the revelations of partially opaque types. But maybe that's a gross simplification of what kind of development occurs. The doubling is mostly good. It fixes a problem well. However, I have some criticism, perhaps rooted in an inadequate understanding, I admit. 1) the ban on shipping having used overrides seems overly strict -- what if the fingerprints match? 2) perhaps some global fingerprint (hash) can be inserted after TARGET, enabling multiple versions to coexist in the same install root? But maybe that's just what you create a seperate install root for, since, I guess bin has to match pkg, so the whole tree is "ruined" anyway. x/* vs. */x in terms of directory layout. And maybe such a fingerprint would need too many bits to be reliable and then be annoyingly long. 3) This is the one I have the most confident understanding of -- as long as you are shipping "everything" all at once, I think shipping with overrides is just fine. There is a question as to what "everything" is. - Jay Date: Fri, 18 Jan 2008 20:35:55 -0500From: rcoleburn at scires.comTo: m3devel at elegosoft.com; jayk123 at hotmail.comSubject: Re: [M3devel] FW: buildlocal vs. buildglobal vs. buildship explanation Jay: I understand the cm3 package and build system. I just didn't know what "buildglobal" meant. >From your explanation, I take it that buildglobal = (cm3 -build) + (cm3 -ship) together on a per package basis. If this is true, then buildglobal == buildship; i.e., there is no difference. You stated that the default of the script is buildlocal and I gather buildlocal = (cm3 -build -override). If so, I now see why I was confused. The default for the compiler is not to include the overrides file (at least that is my recollection from the 4.1 days--maybe its different now). So in my way of thinking, buildlocal = (cm3 -build) without doing any shipping. Perhaps a more self-explanatory option name for (cm3 -build -override) would be "buildoverrides". The system won't let you ship a package built with overrides, so that is why I ran into trouble trying to get everything installed using do-cm3-std without passing the buildship or buildglobal option. I've always liked the cm3 way of having a private source package tree where folks work on the code and then having a separate public package tree where folks "ship" their finished product. Yes, I know you wind up having the code in two places, but then you can "clean" up the derived files in your private tree to save space if needed. The old "reactor" documentation did a fairly good job of explaining the cm3 package concept and the idea of public and private repositories. I'm attempting to convert this document into something we can put back in the cvs repository. I have to take out all the trademarks and replace the graphics etc so it is a painful process without the original electronic source. I've resorted to scanning it in via a scanner and making edits. Regards, Randy>>> Jay 1/18/2008 7:56 PM >>>one more try darnit.... From: jayk123 at hotmail.comTo: jayk123 at hotmail.comSubject: buildlocal vs.Date: Sat, 19 Jan 2008 00:55:31 +0000 "Ship" means "Install" Let's say your install is at c:\cm3 and your source is at c:\dev2\cm3 (I would use dev, but Unix took it.) Depending on the state of things, you probably two of many things: c:\cm3\pkg\libm3\nt386\libm3.lib c:\cm3\pkg\libm3\nt386\libm3.dll c:\dev2\cm3\m3-libs\libm3\nt386\libm3.lib c:\dev2\cm3\m3-libs\libm3\nt386\libm3.dll You will have much more in \dev2\cm3\m3-libs\libm3\nt386. When you build stuff, you can use the installed dependencies or the just built dependencies. buildlocal uses the just built dependencies. buildglobal uses the installed dependencies buildship build and ships (installs) each directory It does it one pass: buildship pkg1 pkg1 => build pkg1 ship pkg1 build pkg2 ship pkg2 and NOT build pkg1 build pkg2 ship pkg1 ship pkg2 You may only ship/install outputs that are builtglobal. Outputs are presumed to only be valid if "amidst" dependencies that match the declarations and such they were built against -- i.e. the headers, in C. If you are starting with a minimal install, with just m3core and libm3, then you must buildship and you must do it in dependncy order. It only matters for certain types of changes, and then it can really matter. You might change the format of some compiler-produced runtime-consumed data. You might have a bunch of .sos/.dlls. They can only work with each other if they match in certain ways. Again, ways which don't change that often, but sometimes do -- like changing public types. - Jay 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 jayk123 at hotmail.com Sat Jan 19 04:18:16 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 19 Jan 2008 03:18:16 +0000 Subject: [M3devel] NT386GNU diffs In-Reply-To: <4790E7A7.1E75.00D7.1@scires.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> <477EA137.1E75.00D7.1@scires.com> <478D394B.1E75.00D7.1@scires.com> <478D47FB.1E75.00D7.1@scires.com> <478DBF8D.1E75.00D7.1@scires.com> <478DE973.1E75.00D7.1@scires.com> <47908659.1E75.00D7.1@scires.com> <4790E7A7.1E75.00D7.1@scires.com> Message-ID: eh, the diffs are small enough - I commited them. The commit includes a stab at documenting how to build this stuff, but importantly, again, the results don't work.. - Jay From: jayk123 at hotmail.comTo: m3devel at elegosoft.comSubject: NT386GNU diffsDate: Fri, 18 Jan 2008 23:38:45 +0000 I think attached is all the diffs I have for NT386GNU.They are:"rewrite" NT386GNU config fileThe diff and result are present.It almost exactly matches NT386.In fact, the targets can perhaps be merged into one configurable target,and NT386GNU be "reclaimed" for the more Posix port people want.But not right now.setjmp to _setjmpThis "works" with Cygwin and MinGW, whereas setjmp doesn't."Works" as in links. I should double check this. Maybe not needed.Just one line..Changes NT386GNU from Posix to Win32.Any objects to commiting?The result is you can build a lot of NT386GNU, but it won't run.I would say it won't "quite" run, but I can't claim to know all that is wrong.Yes, I understand, getting it to run is very important. This may be progress,but isn't useful yet. - Jay 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 Sat Jan 19 04:29:11 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 19 Jan 2008 03:29:11 +0000 Subject: [M3devel] environment variable names? In-Reply-To: <4790E7A7.1E75.00D7.1@scires.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> <477EA137.1E75.00D7.1@scires.com> <478D394B.1E75.00D7.1@scires.com> <478D47FB.1E75.00D7.1@scires.com> <478DBF8D.1E75.00D7.1@scires.com> <478DE973.1E75.00D7.1@scires.com> <47908659.1E75.00D7.1@scires.com> <4790E7A7.1E75.00D7.1@scires.com> Message-ID: Approximately one of these I introduced an therefore might not be in the *.sh.Otherwise I believe these are all NOT my invention, and supported same/similarfor *.sh and *.py. *.cmd lags behind maybe. CM3_ROOT or ROOT is the root of the sourcescripts figures this out basedDOes anyone mind that it doesn't say "SOURCE", e.g. CM3_SOURCE_ROOT? I just introduced this recently: OPTIONALLY there is one generic cm3.cfg, m3-sys\cminstall\src\config\cm3.cfg, that delegates back to the live configuration files in that same directory. That file cannot determine this itself. If you cd around and run cm3, without using do-pkg etc., and you use this new cm3.cfg, you need to set CM3_ROOT or ROOT. CM3_INSTALL or INSTALLROOT are the root of the installed CM3. DOes any mind that the first one doesn't say "ROOT"? e.g. CM3_INSTALL_ROOT? CM3_TARGET or TARGET The target, duh. cm3.cfg sniffs this if $OS == NT386, otherwise not. Does any else mind that such generic global environment variables are queried? ROOT, INSTALLROOT, TARGET? It SEEMS TO ME, the ideal choices would be: CM3_INSTALL_ROOT CM3_SOURCE_ROOT or maybe just CM3_ROOT asis, hey, source is king, source is implied CM3_TARGET and no others. The Quake/.sh/.py code can use whatever it wants internally. It should probably just be left alone but I have to express my perfectionist opinion. :) I am tempted to drop the shorter names from the *.py though, which does make *.py and *.sh a bit less compatible. The scripts could/should also copy one to other for compat (esp. with older builds), reducing any affect here, but that saves people from polluting their global environment at least. ?? - 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 rcoleburn at scires.com Sat Jan 19 06:31:21 2008 From: rcoleburn at scires.com (Randy Coleburn) Date: Sat, 19 Jan 2008 00:31:21 -0500 Subject: [M3devel] pixmap problem Message-ID: <479144D6.1E75.00D7.1@scires.com> I've attached a small zip file containing a simple test program. On Windows XP using the current cm3 from the repository I get the following behavior: a) when the buildstandalone() line is commented out in the m3makefile, the pixmap is rendered poorly on the screen. It has gray streaked lines through it. b) when the buildstandalone() directive is used in the m3makefile, the pixmap is rendered properly on the screen. This program uses pixmaps and bundles. I'm also seeing some problems with bundles, so the two problems may be related, but I'm not sure. Would some of the other developers mind running this simple test program on their platforms and reporting the results. I'd like to know if the problem is limited to Windows NT386 platform, or if it occurs on others. Thanks, Randy Coleburn -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: TestPixmap.zip Type: application/x-zip-compressed Size: 4870 bytes Desc: not available URL: From jayk123 at hotmail.com Sat Jan 19 06:46:37 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 19 Jan 2008 05:46:37 +0000 Subject: [M3devel] strange code? Message-ID: I'm comparing the output of the two backends, since I haven't figured out many gdb commands yet. Well darn the code looks semantically the same around the crash so I'll have to dig differently. Still, why does it bump the stack extra like this: subl $8, %esp <== pushl %eax pushl %edx call _RTLinker__TraceModule addl $16, %esp <== the other backend uses 8 here subl $12, %esp <== pushl $0 call *%eax addl $16, %esp <== the other uses 4 Is it trying to keep the stack 16-aligned? - 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 hosking at cs.purdue.edu Sat Jan 19 09:09:47 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 19 Jan 2008 03:09:47 -0500 Subject: [M3devel] pixmap problem In-Reply-To: <479144D6.1E75.00D7.1@scires.com> References: <479144D6.1E75.00D7.1@scires.com> Message-ID: <0CF197B5-1ADA-4955-904A-7B4ABACE7652@cs.purdue.edu> Looks fine to me on I386_DARWIN. On Jan 19, 2008, at 12:31 AM, Randy Coleburn wrote: > From hosking at cs.purdue.edu Sat Jan 19 09:12:12 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 19 Jan 2008 03:12:12 -0500 Subject: [M3devel] strange code? In-Reply-To: References: Message-ID: Yes, indeed. I believe gcc will try to keep the stack 16-byte aligned. I seem to recall that there are alignment configuration values in the compiler that might cause a crash if set wrong. On Jan 19, 2008, at 12:46 AM, Jay wrote: > I'm comparing the output of the two backends, since I haven't > figured out many gdb commands yet. > Well darn the code looks semantically the same around the crash so > I'll have to dig differently. > > Still, why does it bump the stack extra like this: > > subl $8, %esp <== > pushl %eax > pushl %edx > call _RTLinker__TraceModule > addl $16, %esp <== the other backend uses 8 here > > > subl $12, %esp <== > pushl $0 > call *%eax > addl $16, %esp <== the other uses 4 > > Is it trying to keep the stack 16-aligned? > > - 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 Sat Jan 19 09:52:08 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 19 Jan 2008 08:52:08 +0000 Subject: [M3devel] pixmap problem In-Reply-To: <0CF197B5-1ADA-4955-904A-7B4ABACE7652@cs.purdue.edu> References: <479144D6.1E75.00D7.1@scires.com> <0CF197B5-1ADA-4955-904A-7B4ABACE7652@cs.purdue.edu> Message-ID: I can repro the two different behaviors on XP. I was going to try on PPC_DARWIN but I guess Tony's info suffices. I tried rolling hand.c back to before I changed (months/year ago), since it is involved in bit twiddling, no change, phew. Debugging here is a big humungous pain. NT386 has good stacks and line numbers, but no locals or type info, I'd really sometime like to get Codeview info into those .objs...I think it is documented well enough, but still not necessarily easy, or maybe have a C generating backend partly for this reason (and to bring up more targets, using native tools), and function calls in disassembly I think don't resolve; NT386GNU can't yet build this, though it will soon, but I'm not familiar with gdb and there appears to be no type info. I'm building m3gdb right now, I don't know if it will work, I hope it has type info, and I'm not familiar with the relevant code. In gdb I struggle just to view bytes in memory, add numbers to addresses and see those, etc. I think for MY problem, I'm going to link in C code to dump the structs. There is tracing code and I enabled it, but even it crashes in Text_Length. At least MY problem crashes, hopefully near the problem, whereas your problem goes all the way through to completion with no stopping to hint where the problem is. Darn it. :) on the mock rudeness and :( on the lack of a crash. You write the bundle out and it matches, so that doesn't rule out bundles as being the problem? (darn) And bundles look pretty simple, a bundle is just a generated source file with a constant in it. Maybe newline problems? That wouldn't make sense. I just downloaded some program that might let me separately view the ppm, maybe it'll reveal something. The bad behavior has like regularly spaced solid color veritical bars a few pixels side across the whole picture, and regularly spaced vertical stripes from the correct picture alternating with that. Perhaps someone with ppm/bitmap/graphics experience has seen this behavior and it results from some common pixmap mismanagement we could look for? I have to say this is very surprising. I always wondered, and now I pretty much assume -- Modula-3 never imports/exports data in its dynamic linking, right? It alway imports/exports functions, right? On Windows, functions have an optional optimization, but data must be handled differently at compile time if it is going to be dynamically imported. For functions, if you don't apply the optimization at compile time, the linker will just generate a single instruction thunk instead. That is, given a symbol Foo, there is a symbol __imp__Foo that is a pointer to the actual foo in another .dll/.so. The loader only patches pointers, one per import if you build your .dll correctly, it doesn't patch instructions or code strewn throughout a .dll, just one contiguous array of pointers. MAYBE they don't have to be contiguous for each .dl you import from. That is, if call msvcrt!fopen, msvcrt!fclose, kernel32!Sleep, my .dll/.exe typically has an array: pointer to msvcrt!fopen pointer to msvcrt!fclose null pointer to kernel32!Sleep But perhaps kernel32.dll's pointers and msvcrt.dll's pointers need not be adjacent. So, going back, my point/question is that, if the compiler knows the function is imported, it can call through __imp__Foo instead of calling Foo. But if it calls Foo and you import Foo, the linker will create the function Foo that just jmps through __imp__Foo. That doesn't work for data though. There's no ability to intervenve like that. So for imported data, the compiler must generated a read and dereference of the pointer __imp__Foo for accesses to Foo, if Foo is to be imported. Data imports may be faster when appropriate, but for this reason, I'd say they aren't worth it. And for this reason, I HOPE Modula-3 never imports/exports data. Oh, you could, for data, always reference the pointer __imp_Foo, and if non materializes, create one. However that would suck perf in order to make an uncommon case work. I hope Modula-3 doesn't do that either. :) Though I guess since this global data in question...maybe it is rare??? Later, - Jay > From: hosking at cs.purdue.edu> Date: Sat, 19 Jan 2008 03:09:47 -0500> To: rcoleburn at scires.com> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] pixmap problem> > Looks fine to me on I386_DARWIN.> > On Jan 19, 2008, at 12:31 AM, Randy Coleburn wrote:> > > > _________________________________________________________________ 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 Jan 19 09:55:12 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 19 Jan 2008 08:55:12 +0000 Subject: [M3devel] pixmap problem In-Reply-To: References: <479144D6.1E75.00D7.1@scires.com> <0CF197B5-1ADA-4955-904A-7B4ABACE7652@cs.purdue.edu> Message-ID: and then wouldn't you know...the end of gdb building looks like: Info: resolving _LINES by linking to __imp__LINES (auto-import)Info: resolving _COLS by linking to __imp__COLS (auto-import)Info: resolving _stdscr by linking to __imp__stdscr (auto-import)Info: resolving _curscr by linking to __imp__curscr (auto-import)make[3]: Entering directory `/cygdrive/c/dev2/cm3.2/m3-sys/m3gdb/NT386GNU/gdb'make[4]: Entering directory `/cygdrive/c/dev2/cm3.2/m3-sys/m3gdb/NT386GNU/gdb/doc'make[4]: Nothing to be done for `all'.make[4]: Leaving directory `/cygdrive/c/dev2/cm3.2/m3-sys/m3gdb/NT386GNU/gdb/doc'make[3]: Leaving directory `/cygdrive/c/dev2/cm3.2/m3-sys/m3gdb/NT386GNU/gdb'make[2]: Leaving directory `/cygdrive/c/dev2/cm3.2/m3-sys/m3gdb/NT386GNU/gdb'make[1]: Leaving directory `/cygdrive/c/dev2/cm3.2/m3-sys/m3gdb/NT386GNU'make[1]: Entering directory `/cygdrive/c/dev2/cm3.2/m3-sys/m3gdb/NT386GNU'make[1]: Nothing to be done for `all-target'.make[1]: Leaving directory `/cygdrive/c/dev2/cm3.2/m3-sys/m3gdb/NT386GNU' Fatal Error: unable to copy "gdb/gdb" to "m3gdb": ErrorCode=2: The system cannot find the file specified. ###################### LINK_FILE: ################## But I don't see any errros before that...I think I'm just forgetting to append .exe. - Jay From: jayk123 at hotmail.comSo for imported data, the compiler must generated a read and dereference of the pointer __imp__Foo for accesses to Foo, if Foo is to be imported.Data imports may be faster when appropriate, but for this reason, I'd say they aren't worth it.And for this reason, I HOPE Modula-3 never imports/exports data. Oh, you could, for data, always reference the pointer __imp_Foo, and if non materializes, create one.However that would suck perf in order to make an uncommon case work.I hope Modula-3 doesn't do that either. :)Though I guess since this global data in question...maybe it is rare??? Later, - 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 Sat Jan 19 12:02:59 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 19 Jan 2008 11:02:59 +0000 Subject: [M3devel] more assembly symbols please? Message-ID: Any chance the m3cg output could have, um, some symbols for the global data? It's kind of a pain to decode.. The module/import info is ok a lot, lots of runtime links ok. I think the bad one might be RTHeapInfo but I have to decode the very bare of symbols assembly.. or comments? Like for record fields? Still thinking of sticking a call out to C code...Even OutputDebugString since RTIO isn't working... I looked through the m3cg --help, didn't find anything. Tony? _MM_RTHeapInfo:0 .long _L_1+224 4 .long _MM_RTHeapInfo+528 .long _MM_RTHeapInfo+30812,16 .space 820 .long _L_1+15224 .space 428 .long _L_1+22032 .long _L_1+22036 .long _MM_RTHeapInfo+16040 .space 4 .long _RTHeapInfo_M3 I get to count out to 160 bytes from here..: _L_1:0 .byte 481 .byte 492 .byte 503 .byte 514 .byte 525 .byte 536 .byte 547 .byte 558 .byte 569 .byte 57a .byte 97b .byte 98c .byte 99d .byte 100e .byte 101f .byte 10210 .long _RTHooks__TextLitInfo14 .long _RTHooks__TextLitGetChar18 .long _RTHooks__TextLitGetWideChar1c .long _RTHooks__TextLitGetChars20 .long _RTHooks__TextLitGetWideChars24 .long 228 .long _L_1+162c .long 730 .ascii "shownew"37 .space 138 .long 23c .long _L_1+1640 .long 644 .ascii "update"4a .space 24c .ascii "RTHeapInfo_M3"50 .space 1 .ascii "Init" .space 1 I'll try the C code.. - 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 Sat Jan 19 12:08:19 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 19 Jan 2008 11:08:19 +0000 Subject: [M3devel] more assembly symbols please? In-Reply-To: References: Message-ID: oh I've got two better ideas 1) move RTIO ahead of RTHeapInfo, or earlier, in the unit list 2) paste the RTIO code into RTLinker so calling it doesn't depend on linking!And now I see the command line check for tracing comes after some linking, for good reason. I had set the global to true in the source, and that is probably bad. I'm not sure though within a module if the linking is needed, or if it is only for cross-module references.. - Jay From: jayk123 at hotmail.comTo: m3devel at elegosoft.comDate: Sat, 19 Jan 2008 11:02:59 +0000Subject: [M3devel] more assembly symbols please? Any chance the m3cg output could have, um, some symbols for the global data?It's kind of a pain to decode.. The module/import info is ok a lot, lots of runtime links ok.I think the bad one might be RTHeapInfo but I have to decode the very bare of symbols assembly..or comments? Like for record fields?Still thinking of sticking a call out to C code...Even OutputDebugString since RTIO isn't working... I looked through the m3cg --help, didn't find anything. Tony? _MM_RTHeapInfo:0 .long _L_1+224 4 .long _MM_RTHeapInfo+528 .long _MM_RTHeapInfo+30812,16 .space 820 .long _L_1+15224 .space 428 .long _L_1+22032 .long _L_1+22036 .long _MM_RTHeapInfo+16040 .space 4 .long _RTHeapInfo_M3I get to count out to 160 bytes from here..: _L_1:0 .byte 481 .byte 492 .byte 503 .byte 514 .byte 525 .byte 536 .byte 547 .byte 558 .byte 569 .byte 57a .byte 97b .byte 98c .byte 99d .byte 100e .byte 101f .byte 10210 .long _RTHooks__TextLitInfo14 .long _RTHooks__TextLitGetChar18 .long _RTHooks__TextLitGetWideChar1c .long _RTHooks__TextLitGetChars20 .long _RTHooks__TextLitGetWideChars24 .long 228 .long _L_1+162c .long 730 .ascii "shownew"37 .space 138 .long 23c .long _L_1+1640 .long 644 .ascii "update"4a .space 24c .ascii "RTHeapInfo_M3"50 .space 1 .ascii "Init" .space 1I'll try the C code.. - Jay Connect and share in new ways with Windows Live. Get it 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 jayk123 at hotmail.com Sat Jan 19 12:32:21 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 19 Jan 2008 11:32:21 +0000 Subject: [M3devel] more assembly symbols please? In-Reply-To: References: Message-ID: duh, finally, got it. parameters being passed in the wrong order -- left to right instead of right to left. should have read the assembly of some multi parameter function calls... PROCEDURE RTLinker_PutInt (i: INTEGER; width := 0) = VAR num : ARRAY [0..30] OF CHAR; len := FromInt (ADR (num[0]), i, 10); BEGIN FOR i := 1 TO width - len DO PutChar (' ') END; PutChars (ADR (num[0]), len); END RTLinker_PutInt;Dump of assembler code for function RTLinker__RTLinker_PutInt:0x005de25f : push %ebp0x005de260 : mov %esp,%ebp0x005de262 : sub $0x38,%esp0x005de265 : mov 0x8(%ebp),%edx0x005de268 : sub $0x4,%esp0x005de26b : lea 0xffffffd9(%ebp),%eax0x005de26e : push %eax0x005de26f : push %edx0x005de270 : push $0xa0x005de272 : call 0x5de345 and I AVed writing to the address 0xA.. - 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 Sat Jan 19 15:33:08 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 19 Jan 2008 14:33:08 +0000 Subject: [M3devel] link info still bad. In-Reply-To: References: Message-ID: clarification -- RTLinker still crashes. I put in C code to dump, since it crashes before its own printing would work.A bunch works and then: Module 00682020 ..\src\runtime\common\RTHeapInfo.m3 Imports 006820C0{Import 00000000, Binder 00000000, Next 00603FD0} and then the dumper AV's because the next pointer is bad. 0:000> dc 00603FD000603fd0 8be58955 c0b80845 c900682a 909090c3 U...E...*h......00603fe0 8be58955 80b80845 c900682b e58955c3 U...E...+h...U..00603ff0 ec835657 08458b20 8904c083 2be8a1c2 WV.. .E........+00604000 f4050068 8b000000 dc7d8d00 b8fcc689 h.........}.....00604010 00000007 a5f3c189 758dd789 07b8fcdc ...........u....00604020 89000000 83a5f3c1 5f5e20c4 9090c3c9 ......... ^_....00604030 8be58955 60b80845 c900682c 909090c3 U...E..`,h......00604040 8be58955 00b80845 c900682d 909090c3 U...E...-h...... anything over 0x80000000, or depending on configuration, 0xc0000000, is an invalid user mode pointer on 32bit NT. The address space is usually split 2gig/2gig, the upper 2gig is the kernel memory, the same mappings system side. There is an option to make it 3gig/1gig. If anyone has any hints, please tell me, thanks. If anyone else can build this stuff...? I can commit the printing to be only on this platform... The assembly code output by cm3cg is much harder to read than it should be, even for assembly language.. :( Attached. - Jay From: jayk123 at hotmail.comTo: m3devel at elegosoft.comSubject: RE: [M3devel] more assembly symbols please?Date: Sat, 19 Jan 2008 11:32:21 +0000 duh, finally, got it. parameters being passed in the wrong order -- left to right instead of right to left.should have read the assembly of some multi parameter function calls... PROCEDURE RTLinker_PutInt (i: INTEGER; width := 0) = VAR num : ARRAY [0..30] OF CHAR; len := FromInt (ADR (num[0]), i, 10); BEGIN FOR i := 1 TO width - len DO PutChar (' ') END; PutChars (ADR (num[0]), len); END RTLinker_PutInt;Dump of assembler code for function RTLinker__RTLinker_PutInt:0x005de25f : push %ebp0x005de260 : mov %esp,%ebp0x005de262 : sub $0x38,%esp0x005de265 : mov 0x8(%ebp),%edx0x005de268 : sub $0x4,%esp0x005de26b : lea 0xffffffd9(%ebp),%eax0x005de26e : push %eax0x005de26f : push %edx0x005de270 : push $0xa0x005de272 : call 0x5de345 and I AVed writing to the address 0xA.. - 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: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: RTHeapIn.ms URL: From dabenavidesd at yahoo.es Sat Jan 19 17:54:00 2008 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Sat, 19 Jan 2008 17:54:00 +0100 (CET) Subject: [M3devel] pixmap problem In-Reply-To: Message-ID: <235688.77597.qm@web27110.mail.ukl.yahoo.com> Hi: The TestPixmap does show a nice battery on LINUXLIBC6, Ubuntu Gutsy 2.6.22-14-386, 32 bits machine. Thanks Jay wrote: .hmmessage P { margin:0px; padding:0px } body.hmmessage { FONT-SIZE: 10pt; FONT-FAMILY:Tahoma } I can repro the two different behaviors on XP. I was going to try on PPC_DARWIN but I guess Tony's info suffices. I tried rolling hand.c back to before I changed (months/year ago), since it is involved in bit twiddling, no change, phew. Debugging here is a big humungous pain. NT386 has good stacks and line numbers, but no locals or type info, I'd really sometime like to get Codeview info into those .objs...I think it is documented well enough, but still not necessarily easy, or maybe have a C generating backend partly for this reason (and to bring up more targets, using native tools), and function calls in disassembly I think don't resolve; NT386GNU can't yet build this, though it will soon, but I'm not familiar with gdb and there appears to be no type info. I'm building m3gdb right now, I don't know if it will work, I hope it has type info, and I'm not familiar with the relevant code. In gdb I struggle just to view bytes in memory, add numbers to addresses and see those, etc. I think for MY problem, I'm going to link in C code to dump the structs. There is tracing code and I enabled it, but even it crashes in Text_Length. At least MY problem crashes, hopefully near the problem, whereas your problem goes all the way through to completion with no stopping to hint where the problem is. Darn it. :) on the mock rudeness and :( on the lack of a crash. You write the bundle out and it matches, so that doesn't rule out bundles as being the problem? (darn) And bundles look pretty simple, a bundle is just a generated source file with a constant in it. Maybe newline problems? That wouldn't make sense. I just downloaded some program that might let me separately view the ppm, maybe it'll reveal something. The bad behavior has like regularly spaced solid color veritical bars a few pixels side across the whole picture, and regularly spaced vertical stripes from the correct picture alternating with that. Perhaps someone with ppm/bitmap/graphics experience has seen this behavior and it results from some common pixmap mismanagement we could look for? I have to say this is very surprising. I always wondered, and now I pretty much assume -- Modula-3 never imports/exports data in its dynamic linking, right? It alway imports/exports functions, right? On Windows, functions have an optional optimization, but data must be handled differently at compile time if it is going to be dynamically imported. For functions, if you don't apply the optimization at compile time, the linker will just generate a single instruction thunk instead. That is, given a symbol Foo, there is a symbol __imp__Foo that is a pointer to the actual foo in another .dll/.so. The loader only patches pointers, one per import if you build your .dll correctly, it doesn't patch instructions or code strewn throughout a .dll, just one contiguous array of pointers. MAYBE they don't have to be contiguous for each .dl you import from. That is, if call msvcrt!fopen, msvcrt!fclose, kernel32!Sleep, my .dll/.exe typically has an array: pointer to msvcrt!fopen pointer to msvcrt!fclose null pointer to kernel32!Sleep But perhaps kernel32.dll's pointers and msvcrt.dll's pointers need not be adjacent. So, going back, my point/question is that, if the compiler knows the function is imported, it can call through __imp__Foo instead of calling Foo. But if it calls Foo and you import Foo, the linker will create the function Foo that just jmps through __imp__Foo. That doesn't work for data though. There's no ability to intervenve like that. So for imported data, the compiler must generated a read and dereference of the pointer __imp__Foo for accesses to Foo, if Foo is to be imported. Data imports may be faster when appropriate, but for this reason, I'd say they aren't worth it. And for this reason, I HOPE Modula-3 never imports/exports data. Oh, you could, for data, always reference the pointer __imp_Foo, and if non materializes, create one. However that would suck perf in order to make an uncommon case work. I hope Modula-3 doesn't do that either. :) Though I guess since this global data in question...maybe it is rare??? Later, - Jay --------------------------------- > From: hosking at cs.purdue.edu > Date: Sat, 19 Jan 2008 03:09:47 -0500 > To: rcoleburn at scires.com > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] pixmap problem > > Looks fine to me on I386_DARWIN. > > On Jan 19, 2008, at 12:31 AM, Randy Coleburn wrote: > > > > --------------------------------- Need to know the score, the latest news, or you need your Hotmail?-get your "fix" Check it out. --------------------------------- Web Revelaci?n Yahoo! 2007: Premio Favorita del P?blico - ?Vota tu preferida! -------------- next part -------------- An HTML attachment was scrubbed... URL: From hendrik at topoi.pooq.com Sat Jan 19 18:30:02 2008 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Sat, 19 Jan 2008 12:30:02 -0500 Subject: [M3devel] new name for "reactor" In-Reply-To: <4790892B.1E75.00D7.1@scires.com> References: <4790892B.1E75.00D7.1@scires.com> Message-ID: <20080119173002.GB32561@topoi.pooq.com> On Fri, Jan 18, 2008 at 11:10:38AM -0500, Randy Coleburn wrote: > > Originally, I chose the name "CM3-IDE" for CM3 Integrated Development Environment, but this name isn't very catchy. Actually, CM3-IDE (or perhaps better cm3-ide) isn't bad -- it makes it completely clear what the package is. cm3-catalyst makes people wonder what it does, whether they need it, and whether they should spend disk space to install it. -- hendrik From hosking at cs.purdue.edu Sat Jan 19 18:33:08 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 19 Jan 2008 12:33:08 -0500 Subject: [M3devel] more assembly symbols please? In-Reply-To: References: Message-ID: <2717B275-2548-41BC-BD1E-8742BCE6FA51@cs.purdue.edu> Take a look at the .mc intermediate code output if you want to see that section of the data. There are at least comments. Use m3cgcat - binary < x.mc > x.mo to view it (You can run m3cgcat on any other CM3 install). On Jan 19, 2008, at 6:02 AM, Jay wrote: > Any chance the m3cg output could have, um, some symbols for the > global data? > It's kind of a pain to decode.. > > The module/import info is ok a lot, lots of runtime links ok. > I think the bad one might be RTHeapInfo but I have to decode the > very bare of symbols assembly.. > or comments? Like for record fields? > Still thinking of sticking a call out to C code...Even > OutputDebugString since RTIO isn't working... > > I looked through the m3cg --help, didn't find anything. > > Tony? > > _MM_RTHeapInfo: > 0 .long _L_1+224 > 4 .long _MM_RTHeapInfo+52 > 8 .long _MM_RTHeapInfo+308 > 12,16 .space 8 > 20 .long _L_1+152 > 24 .space 4 > 28 .long _L_1+220 > 32 .long _L_1+220 > 36 .long _MM_RTHeapInfo+160 > 40 .space 4 > .long _RTHeapInfo_M3 > > I get to count out to 160 bytes from here..: > > _L_1: > 0 .byte 48 > 1 .byte 49 > 2 .byte 50 > 3 .byte 51 > 4 .byte 52 > 5 .byte 53 > 6 .byte 54 > 7 .byte 55 > 8 .byte 56 > 9 .byte 57 > a .byte 97 > b .byte 98 > c .byte 99 > d .byte 100 > e .byte 101 > f .byte 102 > 10 .long _RTHooks__TextLitInfo > 14 .long _RTHooks__TextLitGetChar > 18 .long _RTHooks__TextLitGetWideChar > 1c .long _RTHooks__TextLitGetChars > 20 .long _RTHooks__TextLitGetWideChars > 24 .long 2 > 28 .long _L_1+16 > 2c .long 7 > 30 .ascii "shownew" > 37 .space 1 > 38 .long 2 > 3c .long _L_1+16 > 40 .long 6 > 44 .ascii "update" > 4a .space 2 > 4c .ascii "RTHeapInfo_M3" > 50 .space 1 > .ascii "Init" > .space 1 > > I'll try the C code.. > > - Jay > > > > > > Connect and share in new ways with Windows Live. Get it now! From hosking at cs.purdue.edu Sat Jan 19 18:43:16 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 19 Jan 2008 12:43:16 -0500 Subject: [M3devel] new name for "reactor" In-Reply-To: <20080119173002.GB32561@topoi.pooq.com> References: <4790892B.1E75.00D7.1@scires.com> <20080119173002.GB32561@topoi.pooq.com> Message-ID: <8BE9BB1C-5120-4D4E-AEC1-FE1BBF729AA4@cs.purdue.edu> I second this opinion: On Jan 19, 2008, at 12:30 PM, hendrik at topoi.pooq.com wrote: >> Actually, CM3-IDE (or perhaps better cm3-ide) isn't bad -- it >> makes it > completely clear what the package is. cm3-catalyst makes people > wonder > what it does, whether they need it, and whether they should spend disk > space to install it. > > -- hendrik From hosking at cs.purdue.edu Sat Jan 19 18:48:06 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 19 Jan 2008 12:48:06 -0500 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <20080119031134.4B6A510D4625@birch.elegosoft.com> References: <20080119031134.4B6A510D4625@birch.elegosoft.com> Message-ID: So, I am very confused now. Does NT386GNU no longer mean use of the full set of GNU tools m3cc/ld/as, as would be available under Cygwin? I thought the point of this was to be able to run in as much of a GNU environment as possible. GNU to me means the whole toolsuite not just m3cc. To me, a GNU-based environment on Windows holds great attraction, since it consists of tools that I generally always install on Windows, that I know, and are similar to the other platforms I use. On Jan 19, 2008, at 4:11 AM, Jay Krell wrote: > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 08/01/19 04:11:34 > > Modified files: > cm3/m3-libs/m3core/src/runtime/: m3makefile > cm3/m3-sys/cminstall/src/config/: NT386GNU > cm3/m3-sys/m3front/src/builtinInfo/: InfoModule.m3 > cm3/m3-sys/m3middle/src/: Target.m3 > > Log message: > m3-sys/m3middle/src/Target.m3 > m3-libs/m3core/src/runtime/m3makefile > m3-sys\m3front\src\builtinInfo\InfoModule.m3 > > switch NT386GNU to be Win32 instead of POSIX > switch NT386GNU to _setjmp instead of setjmp > jmp_buf size still big like Cygwin > rewrite NT386GNU config file -- almost identical to NT386 > mingwin required for building Modula-3 programs > mingwin AND msys required for building m3cc > > To boot: > > install Python (www.activestate.com) > > have a working NT386 system > get current source > Mine is at c:\dev2\cm3.2 (cm3 is has other paused work, dev was > taken by Unix) > > get and install binary distribution (5.1.3 works, anything newer > should work) > I install to c:\cm3 > copy %CVSROOT%\m3-sys\cminstall\src\config\cm3.cfg to \cm3\bin > \cm3.cfg > > Have a Visual C++ toolset (cl and link) > and run the vcvars link on the start menu (this can/will be made > easier) > Almost any version should work. > if you are using Visual C++ 8.0 (RTM?), rename away its mt.exe > and get a newer from such as from the Platform SDK. Otherwise it > crashes. > This is not specific to NT386GNU, just that I recently removed the > Platform SDK > from my %PATH%. > > cd %CVSROOT%\scripts\python > .\upgrade > > install msys and mingwin from http://www.mingw.org (links to > SourceForge) > for mingwin, you only need the "base" > msys tells you to avoid mingwin make, in favor of msys make, and I > did that > > I install to the defaults > c:\msys\1.0 > c:\mingw > > if you don't install to the defaults, add > \bin and to the start, but which order between the two?) > > if you do install to the defaults, scripts\python will fix path > for you, > if there is no gcc/as/sh on our $PATH > > cd %CVSROOT%\scripts\python > upgrade && bootntgnu > > NOTE THE RESULTING BINARIES DO NOT YET WORK, but this is still > progress. > > These instructions inevitably to be further tested and refined and > placed elsewhere! From jayk123 at hotmail.com Sat Jan 19 19:32:35 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 19 Jan 2008 18:32:35 +0000 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: References: <20080119031134.4B6A510D4625@birch.elegosoft.com> Message-ID: It DOES use m3cc/ld/as, and mklib for building static .libs, though that could probably be gcc/ar/dlltools if I figured it out. "Everything" except m3cc/m3gdb can be built with just MinGWin. Building m3cc requires MSys as well. Building m3gdb requires Cygwin. m3cg is not dependent on cygwin1.dll, nor are any other Modula-3 outputs. m3gdb is dependent on cygwin1.dll. Using Cygwin probably would work..and I could try it to see if it resolves the RTLinker problem. As well, we could have something like, in cm3.cfg you could set MINGWIN_ROOT, MSYS_ROOT, and/or CYGWIN_ROOT, to guide what tools are used, OR we can have some variable: GNU_MODE = 0 % Do not use GNU tools at all -- today's NT386 GNU_MODE = 1 % Use GNU tools minimally -- today's NT386GNU GNU_MODE = 2 % Use GNU tools maximally -- not existant but probably easy Eh..I know, not great.. what do "minimally" and "maximally" mean. I think we have the problem of a) many viable choices b) want to make several of them available c) just don't know what to call things and what the interface should be. As well as an interop question, since jmpbuf does vary in size between cygwin1.dl and everything else. Further down the line, there are other linkers, other compilers, other runtimes. The design here and now might take them into consideration. Gasp..I just realized, there is also another good backend option. parse.c's approach could probably be adapted to Open Watcom AND they might even take the changes (not that I have asked, I just thought of this). And that would net you progress toward a) 32 bit MS-DOS target b) OS/2 target, c) Netware target d) gcc-free Linux target, since the support all of them. Other target possibilities include Digital Mars compiler/linker, CodeWarrior (I know, dead and all), etc. Open Watcom is probably the most interesting since it is open source... - Jay > From: hosking at cs.purdue.edu> Date: Sat, 19 Jan 2008 12:48:06 -0500> To: jkrell at elego.de> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] [M3commit] CVS Update: cm3> > So, I am very confused now. Does NT386GNU no longer mean use of the > full set of GNU tools m3cc/ld/as, as would be available under > Cygwin? I thought the point of this was to be able to run in as much > of a GNU environment as possible. GNU to me means the whole > toolsuite not just m3cc. To me, a GNU-based environment on Windows > holds great attraction, since it consists of tools that I generally > always install on Windows, that I know, and are similar to the other > platforms I use.> > On Jan 19, 2008, at 4:11 AM, Jay Krell wrote:> > > CVSROOT: /usr/cvs> > Changes by: jkrell at birch. 08/01/19 04:11:34> >> > Modified files:> > cm3/m3-libs/m3core/src/runtime/: m3makefile> > cm3/m3-sys/cminstall/src/config/: NT386GNU> > cm3/m3-sys/m3front/src/builtinInfo/: InfoModule.m3> > cm3/m3-sys/m3middle/src/: Target.m3> >> > Log message:> > m3-sys/m3middle/src/Target.m3> > m3-libs/m3core/src/runtime/m3makefile> > m3-sys\m3front\src\builtinInfo\InfoModule.m3> > > > switch NT386GNU to be Win32 instead of POSIX> > switch NT386GNU to _setjmp instead of setjmp> > jmp_buf size still big like Cygwin> > rewrite NT386GNU config file -- almost identical to NT386> > mingwin required for building Modula-3 programs> > mingwin AND msys required for building m3cc> > > > To boot:> > > > install Python (www.activestate.com)> > > > have a working NT386 system> > get current source> > Mine is at c:\dev2\cm3.2 (cm3 is has other paused work, dev was > > taken by Unix)> > > > get and install binary distribution (5.1.3 works, anything newer > > should work)> > I install to c:\cm3> > copy %CVSROOT%\m3-sys\cminstall\src\config\cm3.cfg to \cm3\bin > > \cm3.cfg> > > > Have a Visual C++ toolset (cl and link)> > and run the vcvars link on the start menu (this can/will be made > > easier)> > Almost any version should work.> > if you are using Visual C++ 8.0 (RTM?), rename away its mt.exe> > and get a newer from such as from the Platform SDK. Otherwise it > > crashes.> > This is not specific to NT386GNU, just that I recently removed the > > Platform SDK> > from my %PATH%.> > > > cd %CVSROOT%\scripts\python> > .\upgrade> > > > install msys and mingwin from http://www.mingw.org (links to > > SourceForge)> > for mingwin, you only need the "base"> > msys tells you to avoid mingwin make, in favor of msys make, and I > > did that> > > > I install to the defaults> > c:\msys\1.0> > c:\mingw> > > > if you don't install to the defaults, add> > \bin and > to the start, but which order between the two?)> > > > if you do install to the defaults, scripts\python will fix path > > for you,> > if there is no gcc/as/sh on our $PATH> > > > cd %CVSROOT%\scripts\python> > upgrade && bootntgnu> > > > NOTE THE RESULTING BINARIES DO NOT YET WORK, but this is still > > progress.> > > > These instructions inevitably to be further tested and refined and > > placed elsewhere!> _________________________________________________________________ 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 Jan 19 19:35:09 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 19 Jan 2008 18:35:09 +0000 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: References: <20080119031134.4B6A510D4625@birch.elegosoft.com> Message-ID: ps -- look at m3-sys/cminstall/src/config/NT386GNU. While it is very very similar to NT386, and even outputs foo.lib and foo.lib.sa like NT386, it uses gcc for C compilation, linking, and m3cg for the backend. It is very "GNU" in tools, but not runtime. - Jay From: jayk123 at hotmail.comTo: hosking at cs.purdue.edu; jkrell at elego.deCC: m3devel at elegosoft.comSubject: RE: [M3devel] [M3commit] CVS Update: cm3Date: Sat, 19 Jan 2008 18:32:35 +0000 It DOES use m3cc/ld/as, and mklib for building static .libs, though that could probably be gcc/ar/dlltools if I figured it out."Everything" except m3cc/m3gdb can be built with just MinGWin.Building m3cc requires MSys as well.Building m3gdb requires Cygwin.m3cg is not dependent on cygwin1.dll, nor are any other Modula-3 outputs. m3gdb is dependent on cygwin1.dll. Using Cygwin probably would work..and I could try it to see if it resolves the RTLinker problem. As well, we could have something like, in cm3.cfg you could set MINGWIN_ROOT, MSYS_ROOT, and/or CYGWIN_ROOT, to guide what tools are used, OR we can have some variable: GNU_MODE = 0 % Do not use GNU tools at all -- today's NT386GNU_MODE = 1 % Use GNU tools minimally -- today's NT386GNUGNU_MODE = 2 % Use GNU tools maximally -- not existant but probably easy Eh..I know, not great.. what do "minimally" and "maximally" mean. I think we have the problem of a) many viable choices b) want to make several of them available c) just don't know what to call things and what the interface should be. As well as an interop question, since jmpbuf does vary in size between cygwin1.dl and everything else. Further down the line, there are other linkers, other compilers, other runtimes. The design here and now might take them into consideration.Gasp..I just realized, there is also another good backend option. parse.c's approach could probably be adapted to Open Watcom AND they might even take the changes (not that I have asked, I just thought of this). And that would net you progress toward a) 32 bit MS-DOS target b) OS/2 target, c) Netware target d) gcc-free Linux target, since the support all of them.Other target possibilities include Digital Mars compiler/linker, CodeWarrior (I know, dead and all), etc. Open Watcom is probably the most interesting since it is open source... - Jay > From: hosking at cs.purdue.edu> Date: Sat, 19 Jan 2008 12:48:06 -0500> To: jkrell at elego.de> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] [M3commit] CVS Update: cm3> > So, I am very confused now. Does NT386GNU no longer mean use of the > full set of GNU tools m3cc/ld/as, as would be available under > Cygwin? I thought the point of this was to be able to run in as much > of a GNU environment as possible. GNU to me means the whole > toolsuite not just m3cc. To me, a GNU-based environment on Windows > holds great attraction, since it consists of tools that I generally > always install on Windows, that I know, and are similar to the other > platforms I use.> > On Jan 19, 2008, at 4:11 AM, Jay Krell wrote:> > > CVSROOT: /usr/cvs> > Changes by: jkrell at birch. 08/01/19 04:11:34> >> > Modified files:> > cm3/m3-libs/m3core/src/runtime/: m3makefile> > cm3/m3-sys/cminstall/src/config/: NT386GNU> > cm3/m3-sys/m3front/src/builtinInfo/: InfoModule.m3> > cm3/m3-sys/m3middle/src/: Target.m3> >> > Log message:> > m3-sys/m3middle/src/Target.m3> > m3-libs/m3core/src/runtime/m3makefile> > m3-sys\m3front\src\builtinInfo\InfoModule.m3> > > > switch NT386GNU to be Win32 instead of POSIX> > switch NT386GNU to _setjmp instead of setjmp> > jmp_buf size still big like Cygwin> > rewrite NT386GNU config file -- almost identical to NT386> > mingwin required for building Modula-3 programs> > mingwin AND msys required for building m3cc> > > > To boot:> > > > install Python (www.activestate.com)> > > > have a working NT386 system> > get current source> > Mine is at c:\dev2\cm3.2 (cm3 is has other paused work, dev was > > taken by Unix)> > > > get and install binary distribution (5.1.3 works, anything newer > > should work)> > I install to c:\cm3> > copy %CVSROOT%\m3-sys\cminstall\src\config\cm3.cfg to \cm3\bin > > \cm3.cfg> > > > Have a Visual C++ toolset (cl and link)> > and run the vcvars link on the start menu (this can/will be made > > easier)> > Almost any version should work.> > if you are using Visual C++ 8.0 (RTM?), rename away its mt.exe> > and get a newer from such as from the Platform SDK. Otherwise it > > crashes.> > This is not specific to NT386GNU, just that I recently removed the > > Platform SDK> > from my %PATH%.> > > > cd %CVSROOT%\scripts\python> > .\upgrade> > > > install msys and mingwin from http://www.mingw.org (links to > > SourceForge)> > for mingwin, you only need the "base"> > msys tells you to avoid mingwin make, in favor of msys make, and I > > did that> > > > I install to the defaults> > c:\msys\1.0> > c:\mingw> > > > if you don't install to the defaults, add> > \bin and > to the start, but which order between the two?)> > > > if you do install to the defaults, scripts\python will fix path > > for you,> > if there is no gcc/as/sh on our $PATH> > > > cd %CVSROOT%\scripts\python> > upgrade && bootntgnu> > > > NOTE THE RESULTING BINARIES DO NOT YET WORK, but this is still > > progress.> > > > These instructions inevitably to be further tested and refined and > > placed elsewhere!> 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 Jan 19 19:45:27 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 19 Jan 2008 18:45:27 +0000 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: References: <20080119031134.4B6A510D4625@birch.elegosoft.com> Message-ID: ps -- the need or Visual C++ referenced in the checkin coment is to "boot" -- to build a current cm3 to build the NT386GNU stuff. Just like you need cm3 to do cross builds, except in this case both Modula-3 targets can be fully built on the same machine. Once you build the first time, IF it was working, no Visual C++/SDK requirement. Once a working binary distribution is available, ditto. - Jay From: jayk123 at hotmail.comTo: hosking at cs.purdue.edu; jkrell at elego.deCC: m3devel at elegosoft.comSubject: RE: [M3devel] [M3commit] CVS Update: cm3Date: Sat, 19 Jan 2008 18:35:09 +0000 ps -- look at m3-sys/cminstall/src/config/NT386GNU.While it is very very similar to NT386, and even outputs foo.lib and foo.lib.sa like NT386, it uses gcc for C compilation, linking, and m3cg for the backend.It is very "GNU" in tools, but not runtime. - Jay From: jayk123 at hotmail.comTo: hosking at cs.purdue.edu; jkrell at elego.deCC: m3devel at elegosoft.comSubject: RE: [M3devel] [M3commit] CVS Update: cm3Date: Sat, 19 Jan 2008 18:32:35 +0000 It DOES use m3cc/ld/as, and mklib for building static .libs, though that could probably be gcc/ar/dlltools if I figured it out."Everything" except m3cc/m3gdb can be built with just MinGWin.Building m3cc requires MSys as well.Building m3gdb requires Cygwin.m3cg is not dependent on cygwin1.dll, nor are any other Modula-3 outputs. m3gdb is dependent on cygwin1.dll. Using Cygwin probably would work..and I could try it to see if it resolves the RTLinker problem. As well, we could have something like, in cm3.cfg you could set MINGWIN_ROOT, MSYS_ROOT, and/or CYGWIN_ROOT, to guide what tools are used, OR we can have some variable: GNU_MODE = 0 % Do not use GNU tools at all -- today's NT386GNU_MODE = 1 % Use GNU tools minimally -- today's NT386GNUGNU_MODE = 2 % Use GNU tools maximally -- not existant but probably easy Eh..I know, not great.. what do "minimally" and "maximally" mean. I think we have the problem of a) many viable choices b) want to make several of them available c) just don't know what to call things and what the interface should be. As well as an interop question, since jmpbuf does vary in size between cygwin1.dl and everything else. Further down the line, there are other linkers, other compilers, other runtimes. The design here and now might take them into consideration.Gasp..I just realized, there is also another good backend option. parse.c's approach could probably be adapted to Open Watcom AND they might even take the changes (not that I have asked, I just thought of this). And that would net you progress toward a) 32 bit MS-DOS target b) OS/2 target, c) Netware target d) gcc-free Linux target, since the support all of them.Other target possibilities include Digital Mars compiler/linker, CodeWarrior (I know, dead and all), etc. Open Watcom is probably the most interesting since it is open source... - Jay > From: hosking at cs.purdue.edu> Date: Sat, 19 Jan 2008 12:48:06 -0500> To: jkrell at elego.de> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] [M3commit] CVS Update: cm3> > So, I am very confused now. Does NT386GNU no longer mean use of the > full set of GNU tools m3cc/ld/as, as would be available under > Cygwin? I thought the point of this was to be able to run in as much > of a GNU environment as possible. GNU to me means the whole > toolsuite not just m3cc. To me, a GNU-based environment on Windows > holds great attraction, since it consists of tools that I generally > always install on Windows, that I know, and are similar to the other > platforms I use.> > On Jan 19, 2008, at 4:11 AM, Jay Krell wrote:> > > CVSROOT: /usr/cvs> > Changes by: jkrell at birch. 08/01/19 04:11:34> >> > Modified files:> > cm3/m3-libs/m3core/src/runtime/: m3makefile> > cm3/m3-sys/cminstall/src/config/: NT386GNU> > cm3/m3-sys/m3front/src/builtinInfo/: InfoModule.m3> > cm3/m3-sys/m3middle/src/: Target.m3> >> > Log message:> > m3-sys/m3middle/src/Target.m3> > m3-libs/m3core/src/runtime/m3makefile> > m3-sys\m3front\src\builtinInfo\InfoModule.m3> > > > switch NT386GNU to be Win32 instead of POSIX> > switch NT386GNU to _setjmp instead of setjmp> > jmp_buf size still big like Cygwin> > rewrite NT386GNU config file -- almost identical to NT386> > mingwin required for building Modula-3 programs> > mingwin AND msys required for building m3cc> > > > To boot:> > > > install Python (www.activestate.com)> > > > have a working NT386 system> > get current source> > Mine is at c:\dev2\cm3.2 (cm3 is has other paused work, dev was > > taken by Unix)> > > > get and install binary distribution (5.1.3 works, anything newer > > should work)> > I install to c:\cm3> > copy %CVSROOT%\m3-sys\cminstall\src\config\cm3.cfg to \cm3\bin > > \cm3.cfg> > > > Have a Visual C++ toolset (cl and link)> > and run the vcvars link on the start menu (this can/will be made > > easier)> > Almost any version should work.> > if you are using Visual C++ 8.0 (RTM?), rename away its mt.exe> > and get a newer from such as from the Platform SDK. Otherwise it > > crashes.> > This is not specific to NT386GNU, just that I recently removed the > > Platform SDK> > from my %PATH%.> > > > cd %CVSROOT%\scripts\python> > .\upgrade> > > > install msys and mingwin from http://www.mingw.org (links to > > SourceForge)> > for mingwin, you only need the "base"> > msys tells you to avoid mingwin make, in favor of msys make, and I > > did that> > > > I install to the defaults> > c:\msys\1.0> > c:\mingw> > > > if you don't install to the defaults, add> > \bin and > to the start, but which order between the two?)> > > > if you do install to the defaults, scripts\python will fix path > > for you,> > if there is no gcc/as/sh on our $PATH> > > > cd %CVSROOT%\scripts\python> > upgrade && bootntgnu> > > > NOTE THE RESULTING BINARIES DO NOT YET WORK, but this is still > > progress.> > > > These instructions inevitably to be further tested and refined and > > placed elsewhere!> 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! _________________________________________________________________ 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 Sat Jan 19 19:49:32 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 19 Jan 2008 18:49:32 +0000 Subject: [M3devel] more assembly symbols please? In-Reply-To: <2717B275-2548-41BC-BD1E-8742BCE6FA51@cs.purdue.edu> References: <2717B275-2548-41BC-BD1E-8742BCE6FA51@cs.purdue.edu> Message-ID: Thanks. m3cg -y for full tracing also dumps relevant stuff at the end. I'll try m3cgcat too. I should just be able to build/run an NT386 version. My C tracing does "prove" the problem is RTHeapInfo, but I still haven't figured out why. I've started skimming the code that builds that data...still a ways off from solving this I think. I have some suspicion the linker is moving things around that were otherwise correct, but I am far from proving that or fixing it. I'd like to first verify that the "m3front" / m3cg output is correct. The lack of labels in the as actually is a counter point to the movement theory, hard for linker to get a handle on anything to move around, it's just one blob. - Jay > CC: m3devel at elegosoft.com> From: hosking at cs.purdue.edu> Subject: Re: [M3devel] more assembly symbols please?> Date: Sat, 19 Jan 2008 12:33:08 -0500> To: jayk123 at hotmail.com> > Take a look at the .mc intermediate code output if you want to see > that section of the data. There are at least comments. Use m3cgcat - > binary < x.mc > x.mo to view it (You can run m3cgcat on any other CM3 > install).> > On Jan 19, 2008, at 6:02 AM, Jay wrote:> > > Any chance the m3cg output could have, um, some symbols for the > > global data?> > It's kind of a pain to decode..> >> > The module/import info is ok a lot, lots of runtime links ok.> > I think the bad one might be RTHeapInfo but I have to decode the > > very bare of symbols assembly..> > or comments? Like for record fields?> > Still thinking of sticking a call out to C code...Even > > OutputDebugString since RTIO isn't working...> >> > I looked through the m3cg --help, didn't find anything.> >> > Tony?> >> > _MM_RTHeapInfo:> > 0 .long _L_1+224> > 4 .long _MM_RTHeapInfo+52> > 8 .long _MM_RTHeapInfo+308> > 12,16 .space 8> > 20 .long _L_1+152> > 24 .space 4> > 28 .long _L_1+220> > 32 .long _L_1+220> > 36 .long _MM_RTHeapInfo+160> > 40 .space 4> > .long _RTHeapInfo_M3> >> > I get to count out to 160 bytes from here..:> >> > _L_1:> > 0 .byte 48> > 1 .byte 49> > 2 .byte 50> > 3 .byte 51> > 4 .byte 52> > 5 .byte 53> > 6 .byte 54> > 7 .byte 55> > 8 .byte 56> > 9 .byte 57> > a .byte 97> > b .byte 98> > c .byte 99> > d .byte 100> > e .byte 101> > f .byte 102> > 10 .long _RTHooks__TextLitInfo> > 14 .long _RTHooks__TextLitGetChar> > 18 .long _RTHooks__TextLitGetWideChar> > 1c .long _RTHooks__TextLitGetChars> > 20 .long _RTHooks__TextLitGetWideChars> > 24 .long 2> > 28 .long _L_1+16> > 2c .long 7> > 30 .ascii "shownew"> > 37 .space 1> > 38 .long 2> > 3c .long _L_1+16> > 40 .long 6> > 44 .ascii "update"> > 4a .space 2> > 4c .ascii "RTHeapInfo_M3"> > 50 .space 1> > .ascii "Init"> > .space 1> >> > I'll try the C code..> >> > - Jay> >> >> >> >> >> > 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 wagner at elegosoft.com Sat Jan 19 20:48:10 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 19 Jan 2008 20:48:10 +0100 Subject: [M3devel] my status on win32 In-Reply-To: <47908659.1E75.00D7.1@scires.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> <477EA137.1E75.00D7.1@scires.com> <478D394B.1E75.00D7.1@scires.com> <478D47FB.1E75.00D7.1@scires.com> <478DBF8D.1E75.00D7.1@scires.com> <478DE973.1E75.00D7.1@scires.com> <47908659.1E75.00D7.1@scires.com> Message-ID: <20080119204810.3wmumqgms88sccw4@mail.elegosoft.com> Quoting Randy Coleburn : > 1. pixmaps aren't rendered properly on the screen. They look really > bad. I recall having this problem a while back with one of the early > 5.x releases, so I guess it was never solved. I've got some old test > programs I try to dig out and see if I can find out what is going on. I > seem to recall that building standalone in the past seemed to fix the > problem, so this is a real mystery. Hi Randy, I'm afraid I wasn't able to solve it directly some years ago and then forgot about it due to more urgent tasks. I think we should try to narrow down the location of the problem (i.e. is it in the runtime, code generation, linker, or windows libraries). As you still have the 4.1 code of the Windows libraries, could you first try to build them with the new compiler and see if it makes a difference if you link against them? It may also be worthwhile to compare the commands actually used for linking (use -commands). That is, before we turn to the actual generated code... I still haven't got Windows access here, so I can just suggest what to do... Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From rcoleburn at scires.com Sat Jan 19 22:22:06 2008 From: rcoleburn at scires.com (Randy Coleburn) Date: Sat, 19 Jan 2008 16:22:06 -0500 Subject: [M3devel] reactor: catalyst vs cm3-ide Message-ID: <479223AC.1E75.00D7.1@scires.com> Ok, I've gotten some feedback on the new name for reactor. I've attached a PDF that has two pages: one depicts use of Catalyst, the other CM3-IDE. Please let me know which you prefer. BTW, if anyone else can draw up something better, go for it. I'm not a graphic artist. Regards, Randy -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: newReactor.pdf Type: application/pdf Size: 84104 bytes Desc: not available URL: From rcoleburn at scires.com Sat Jan 19 22:27:09 2008 From: rcoleburn at scires.com (Randy Coleburn) Date: Sat, 19 Jan 2008 16:27:09 -0500 Subject: [M3devel] success with upgrade on NT386 Message-ID: <479224DB.1E75.00D7.1@scires.com> Jay: Thanks for all your help. I checked out your updates last night and was able to do a complete rebuild of the compiler and all packages using the upgrade and do-cmd-std scripts on Windows XP. Regards, Randy -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sun Jan 20 00:46:59 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 19 Jan 2008 18:46:59 -0500 Subject: [M3devel] more assembly symbols please? In-Reply-To: References: <2717B275-2548-41BC-BD1E-8742BCE6FA51@cs.purdue.edu> Message-ID: <1A973B4E-23DD-4B85-B42F-9070E93429BB@cs.purdue.edu> Which linker are you using? Could that be a factor? On Jan 19, 2008, at 1:49 PM, Jay wrote: > Thanks. m3cg -y for full tracing also dumps relevant stuff at the end. > I'll try m3cgcat too. I should just be able to build/run an NT386 > version. > My C tracing does "prove" the problem is RTHeapInfo, but I still > haven't figured out why. > I've started skimming the code that builds that data...still a ways > off from solving this I think. > I have some suspicion the linker is moving things around that were > otherwise correct, but I am far from proving that or fixing it. > I'd like to first verify that the "m3front" / m3cg output is correct. > The lack of labels in the as actually is a counter point to the > movement theory, hard for linker to get a handle on anything to > move around, it's just one blob. > > - Jay > > > > > CC: m3devel at elegosoft.com > > From: hosking at cs.purdue.edu > > Subject: Re: [M3devel] more assembly symbols please? > > Date: Sat, 19 Jan 2008 12:33:08 -0500 > > To: jayk123 at hotmail.com > > > > Take a look at the .mc intermediate code output if you want to see > > that section of the data. There are at least comments. Use m3cgcat - > > binary < x.mc > x.mo to view it (You can run m3cgcat on any other > CM3 > > install). > > > > On Jan 19, 2008, at 6:02 AM, Jay wrote: > > > > > Any chance the m3cg output could have, um, some symbols for the > > > global data? > > > It's kind of a pain to decode.. > > > > > > The module/import info is ok a lot, lots of runtime links ok. > > > I think the bad one might be RTHeapInfo but I have to decode the > > > very bare of symbols assembly.. > > > or comments? Like for record fields? > > > Still thinking of sticking a call out to C code...Even > > > OutputDebugString since RTIO isn't working... > > > > > > I looked through the m3cg --help, didn't find anything. > > > > > > Tony? > > > > > > _MM_RTHeapInfo: > > > 0 .long _L_1+224 > > > 4 .long _MM_RTHeapInfo+52 > > > 8 .long _MM_RTHeapInfo+308 > > > 12,16 .space 8 > > > 20 .long _L_1+152 > > > 24 .space 4 > > > 28 .long _L_1+220 > > > 32 .long _L_1+220 > > > 36 .long _MM_RTHeapInfo+160 > > > 40 .space 4 > > > .long _RTHeapInfo_M3 > > > > > > I get to count out to 160 bytes from here..: > > > > > > _L_1: > > > 0 .byte 48 > > > 1 .byte 49 > > > 2 .byte 50 > > > 3 .byte 51 > > > 4 .byte 52 > > > 5 .byte 53 > > > 6 .byte 54 > > > 7 .byte 55 > > > 8 .byte 56 > > > 9 .byte 57 > > > a .byte 97 > > > b .byte 98 > > > c .byte 99 > > > d .byte 100 > > > e .byte 101 > > > f .byte 102 > > > 10 .long _RTHooks__TextLitInfo > > > 14 .long _RTHooks__TextLitGetChar > > > 18 .long _RTHooks__TextLitGetWideChar > > > 1c .long _RTHooks__TextLitGetChars > > > 20 .long _RTHooks__TextLitGetWideChars > > > 24 .long 2 > > > 28 .long _L_1+16 > > > 2c .long 7 > > > 30 .ascii "shownew" > > > 37 .space 1 > > > 38 .long 2 > > > 3c .long _L_1+16 > > > 40 .long 6 > > > 44 .ascii "update" > > > 4a .space 2 > > > 4c .ascii "RTHeapInfo_M3" > > > 50 .space 1 > > > .ascii "Init" > > > .space 1 > > > > > > I'll try the C code.. > > > > > > - Jay > > > > > > > > > > > > > > > > > > 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 hosking at cs.purdue.edu Sun Jan 20 00:47:41 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 19 Jan 2008 18:47:41 -0500 Subject: [M3devel] my status on win32 In-Reply-To: <20080119204810.3wmumqgms88sccw4@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> <477EA137.1E75.00D7.1@scires.com> <478D394B.1E75.00D7.1@scires.com> <478D47FB.1E75.00D7.1@scires.com> <478DBF8D.1E75.00D7.1@scires.com> <478DE973.1E75.00D7.1@scires.com> <47908659.1E75.00D7.1@scires.com> <20080119204810.3wmumqgms88sccw4@mail.elegosoft.com> Message-ID: I would perhaps suspect a bad library mapping. On Jan 19, 2008, at 2:48 PM, Olaf Wagner wrote: > Quoting Randy Coleburn : >> 1. pixmaps aren't rendered properly on the screen. They look really >> bad. I recall having this problem a while back with one of the early >> 5.x releases, so I guess it was never solved. I've got some old test >> programs I try to dig out and see if I can find out what is going >> on. I >> seem to recall that building standalone in the past seemed to fix the >> problem, so this is a real mystery. > > Hi Randy, > > I'm afraid I wasn't able to solve it directly some years ago and > then forgot about it due to more urgent tasks. > > I think we should try to narrow down the location of the problem > (i.e. is it in the runtime, code generation, linker, or windows > libraries). > > As you still have the 4.1 code of the Windows libraries, could you > first try to build them with the new compiler and see if it makes > a difference if you link against them? > > It may also be worthwhile to compare the commands actually used > for linking (use -commands). That is, before we turn to the actual > generated code... > > I still haven't got Windows access here, so I can just suggest what > to do... > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, > Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Jan 20 00:51:41 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 19 Jan 2008 18:51:41 -0500 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: References: <20080119031134.4B6A510D4625@birch.elegosoft.com> Message-ID: <5BFBD626-F492-4058-9A7A-6CB295753585@cs.purdue.edu> On Jan 19, 2008, at 1:32 PM, Jay wrote: > Gasp..I just realized, there is also another good backend option. > parse.c's approach could probably be adapted to Open Watcom AND > they might even take the changes (not that I have asked, I just > thought of this). And that would net you progress toward a) 32 bit > MS-DOS target b) OS/2 target, c) Netware target d) gcc-free Linux > target, since the support all of them. I would plump for llvm. Apple is using it heavily these days and may be pushing it into their Mac compiler toolchain. > > Other target possibilities include Digital Mars compiler/linker, > CodeWarrior (I know, dead and all), etc. Open Watcom is probably > the most interesting since it is open source... > > - Jay > > > > > From: hosking at cs.purdue.edu > > Date: Sat, 19 Jan 2008 12:48:06 -0500 > > To: jkrell at elego.de > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > > > So, I am very confused now. Does NT386GNU no longer mean use of the > > full set of GNU tools m3cc/ld/as, as would be available under > > Cygwin? I thought the point of this was to be able to run in as much > > of a GNU environment as possible. GNU to me means the whole > > toolsuite not just m3cc. To me, a GNU-based environment on Windows > > holds great attraction, since it consists of tools that I generally > > always install on Windows, that I know, and are similar to the other > > platforms I use. > > > > On Jan 19, 2008, at 4:11 AM, Jay Krell wrote: > > > > > CVSROOT: /usr/cvs > > > Changes by: jkrell at birch. 08/01/19 04:11:34 > > > > > > Modified files: > > > cm3/m3-libs/m3core/src/runtime/: m3makefile > > > cm3/m3-sys/cminstall/src/config/: NT386GNU > > > cm3/m3-sys/m3front/src/builtinInfo/: InfoModule.m3 > > > cm3/m3-sys/m3middle/src/: Target.m3 > > > > > > Log message: > > > m3-sys/m3middle/src/Target.m3 > > > m3-libs/m3core/src/runtime/m3makefile > > > m3-sys\m3front\src\builtinInfo\InfoModule.m3 > > > > > > switch NT386GNU to be Win32 instead of POSIX > > > switch NT386GNU to _setjmp instead of setjmp > > > jmp_buf size still big like Cygwin > > > rewrite NT386GNU config file -- almost identical to NT386 > > > mingwin required for building Modula-3 programs > > > mingwin AND msys required for building m3cc > > > > > > To boot: > > > > > > install Python (www.activestate.com) > > > > > > have a working NT386 system > > > get current source > > > Mine is at c:\dev2\cm3.2 (cm3 is has other paused work, dev was > > > taken by Unix) > > > > > > get and install binary distribution (5.1.3 works, anything newer > > > should work) > > > I install to c:\cm3 > > > copy %CVSROOT%\m3-sys\cminstall\src\config\cm3.cfg to \cm3\bin > > > \cm3.cfg > > > > > > Have a Visual C++ toolset (cl and link) > > > and run the vcvars link on the start menu (this can/will be made > > > easier) > > > Almost any version should work. > > > if you are using Visual C++ 8.0 (RTM?), rename away its mt.exe > > > and get a newer from such as from the Platform SDK. Otherwise it > > > crashes. > > > This is not specific to NT386GNU, just that I recently removed the > > > Platform SDK > > > from my %PATH%. > > > > > > cd %CVSROOT%\scripts\python > > > .\upgrade > > > > > > install msys and mingwin from http://www.mingw.org (links to > > > SourceForge) > > > for mingwin, you only need the "base" > > > msys tells you to avoid mingwin make, in favor of msys make, and I > > > did that > > > > > > I install to the defaults > > > c:\msys\1.0 > > > c:\mingw > > > > > > if you don't install to the defaults, add > > > \bin and > > to the start, but which order between the two?) > > > > > > if you do install to the defaults, scripts\python will fix path > > > for you, > > > if there is no gcc/as/sh on our $PATH > > > > > > cd %CVSROOT%\scripts\python > > > upgrade && bootntgnu > > > > > > NOTE THE RESULTING BINARIES DO NOT YET WORK, but this is still > > > progress. > > > > > > These instructions inevitably to be further tested and refined and > > > placed elsewhere! > > > > > 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 Sun Jan 20 00:52:12 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 19 Jan 2008 18:52:12 -0500 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: References: <20080119031134.4B6A510D4625@birch.elegosoft.com> Message-ID: OK, that's what I had hoped. Sounds good! On Jan 19, 2008, at 1:35 PM, Jay wrote: > ps -- look at m3-sys/cminstall/src/config/NT386GNU. > While it is very very similar to NT386, and even outputs foo.lib > and foo.lib.sa like NT386, it uses gcc for C compilation, linking, > and m3cg for the backend. > It is very "GNU" in tools, but not runtime. > > - Jay > > From: jayk123 at hotmail.com > To: hosking at cs.purdue.edu; jkrell at elego.de > CC: m3devel at elegosoft.com > Subject: RE: [M3devel] [M3commit] CVS Update: cm3 > Date: Sat, 19 Jan 2008 18:32:35 +0000 > > It DOES use m3cc/ld/as, and mklib for building static .libs, though > that could probably be gcc/ar/dlltools if I figured it out. > "Everything" except m3cc/m3gdb can be built with just MinGWin. > Building m3cc requires MSys as well. > Building m3gdb requires Cygwin. > m3cg is not dependent on cygwin1.dll, nor are any other Modula-3 > outputs. m3gdb is dependent on cygwin1.dll. > > Using Cygwin probably would work..and I could try it to see if it > resolves the RTLinker problem. > > As well, we could have something like, in cm3.cfg you could set > MINGWIN_ROOT, MSYS_ROOT, and/or CYGWIN_ROOT, to guide what tools > are used, OR we can have some variable: > > GNU_MODE = 0 % Do not use GNU tools at all -- today's NT386 > GNU_MODE = 1 % Use GNU tools minimally -- today's NT386GNU > GNU_MODE = 2 % Use GNU tools maximally -- not existant but probably > easy > > Eh..I know, not great.. what do "minimally" and "maximally" mean. > > I think we have the problem of a) many viable choices b) want to > make several of them available c) just don't know what to call > things and what the interface should be. As well as an interop > question, since jmpbuf does vary in size between cygwin1.dl and > everything else. > > Further down the line, there are other linkers, other compilers, > other runtimes. The design here and now might take them into > consideration. > Gasp..I just realized, there is also another good backend option. > parse.c's approach could probably be adapted to Open Watcom AND > they might even take the changes (not that I have asked, I just > thought of this). And that would net you progress toward a) 32 bit > MS-DOS target b) OS/2 target, c) Netware target d) gcc-free Linux > target, since the support all of them. > Other target possibilities include Digital Mars compiler/linker, > CodeWarrior (I know, dead and all), etc. Open Watcom is probably > the most interesting since it is open source... > > - Jay > > > > > From: hosking at cs.purdue.edu > > Date: Sat, 19 Jan 2008 12:48:06 -0500 > > To: jkrell at elego.de > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > > > So, I am very confused now. Does NT386GNU no longer mean use of the > > full set of GNU tools m3cc/ld/as, as would be available under > > Cygwin? I thought the point of this was to be able to run in as much > > of a GNU environment as possible. GNU to me means the whole > > toolsuite not just m3cc. To me, a GNU-based environment on Windows > > holds great attraction, since it consists of tools that I generally > > always install on Windows, that I know, and are similar to the other > > platforms I use. > > > > On Jan 19, 2008, at 4:11 AM, Jay Krell wrote: > > > > > CVSROOT: /usr/cvs > > > Changes by: jkrell at birch. 08/01/19 04:11:34 > > > > > > Modified files: > > > cm3/m3-libs/m3core/src/runtime/: m3makefile > > > cm3/m3-sys/cminstall/src/config/: NT386GNU > > > cm3/m3-sys/m3front/src/builtinInfo/: InfoModule.m3 > > > cm3/m3-sys/m3middle/src/: Target.m3 > > > > > > Log message: > > > m3-sys/m3middle/src/Target.m3 > > > m3-libs/m3core/src/runtime/m3makefile > > > m3-sys\m3front\src\builtinInfo\InfoModule.m3 > > > > > > switch NT386GNU to be Win32 instead of POSIX > > > switch NT386GNU to _setjmp instead of setjmp > > > jmp_buf size still big like Cygwin > > > rewrite NT386GNU config file -- almost identical to NT386 > > > mingwin required for building Modula-3 programs > > > mingwin AND msys required for building m3cc > > > > > > To boot: > > > > > > install Python (www.activestate.com) > > > > > > have a working NT386 system > > > get current source > > > Mine is at c:\dev2\cm3.2 (cm3 is has other paused work, dev was > > > taken by Unix) > > > > > > get and install binary distribution (5.1.3 works, anything newer > > > should work) > > > I install to c:\cm3 > > > copy %CVSROOT%\m3-sys\cminstall\src\config\cm3.cfg to \cm3\bin > > > \cm3.cfg > > > > > > Have a Visual C++ toolset (cl and link) > > > and run the vcvars link on the start menu (this can/will be made > > > easier) > > > Almost any version should work. > > > if you are using Visual C++ 8.0 (RTM?), rename away its mt.exe > > > and get a newer from such as from the Platform SDK. Otherwise it > > > crashes. > > > This is not specific to NT386GNU, just that I recently removed the > > > Platform SDK > > > from my %PATH%. > > > > > > cd %CVSROOT%\scripts\python > > > .\upgrade > > > > > > install msys and mingwin from http://www.mingw.org (links to > > > SourceForge) > > > for mingwin, you only need the "base" > > > msys tells you to avoid mingwin make, in favor of msys make, and I > > > did that > > > > > > I install to the defaults > > > c:\msys\1.0 > > > c:\mingw > > > > > > if you don't install to the defaults, add > > > \bin and > > to the start, but which order between the two?) > > > > > > if you do install to the defaults, scripts\python will fix path > > > for you, > > > if there is no gcc/as/sh on our $PATH > > > > > > cd %CVSROOT%\scripts\python > > > upgrade && bootntgnu > > > > > > NOTE THE RESULTING BINARIES DO NOT YET WORK, but this is still > > > progress. > > > > > > These instructions inevitably to be further tested and refined and > > > placed elsewhere! > > > > > 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! From rcoleburn at scires.com Sun Jan 20 03:12:37 2008 From: rcoleburn at scires.com (Randy Coleburn) Date: Sat, 19 Jan 2008 21:12:37 -0500 Subject: [M3devel] my status on win32 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> <477EA137.1E75.00D7.1@scires.com> <478D394B.1E75.00D7.1@scires.com> <478D47FB.1E75.00D7.1@scires.com> <478DBF8D.1E75.00D7.1@scires.com> <478DE973.1E75.00D7.1@scires.com> <47908659.1E75.00D7.1@scires.com> <20080119204810.3wmumqgms88sccw4@mail.elegosoft.com> Message-ID: <479267C2.1E75.00D7.1@scires.com> Hi Tony: Are you suggesting that when the program is built standalone it maps libraries differently? I know there is a difference between dynamic vs. static libraries, but are you suggesting that a different library is being mapped than the vendor's equivalent of the dynamic library? How would I check for this situation? Your suggestion seems plausible since the source is not recompiled; instead, the linker is used to change the way the EXE is put together and that seems to cause the difference in operation as far as pixmaps are concerned. Regards, Randy >>> Tony Hosking 1/19/2008 6:47 PM >>> I would perhaps suspect a bad library mapping. On Jan 19, 2008, at 2:48 PM, Olaf Wagner wrote: > Quoting Randy Coleburn : >> 1. pixmaps aren't rendered properly on the screen. They look really >> bad. I recall having this problem a while back with one of the early >> 5.x releases, so I guess it was never solved. I've got some old test >> programs I try to dig out and see if I can find out what is going >> on. I >> seem to recall that building standalone in the past seemed to fix the >> problem, so this is a real mystery. > > Hi Randy, > > I'm afraid I wasn't able to solve it directly some years ago and > then forgot about it due to more urgent tasks. > > I think we should try to narrow down the location of the problem > (i.e. is it in the runtime, code generation, linker, or windows > libraries). > > As you still have the 4.1 code of the Windows libraries, could you > first try to build them with the new compiler and see if it makes > a difference if you link against them? > > It may also be worthwhile to compare the commands actually used > for linking (use -commands). That is, before we turn to the actual > generated code... > > I still haven't got Windows access here, so I can just suggest what > to do... > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, > Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 > 45 86 95 > http://www.elegosoft.com ( http://www.elegosoft.com/ ) | Gesch?ftsf?hrer: Olaf Wagner | Sitz: > Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > DE163214194 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Sun Jan 20 05:27:43 2008 From: jayk123 at hotmail.com (Jay) Date: Sun, 20 Jan 2008 04:27:43 +0000 Subject: [M3devel] my status on win32 In-Reply-To: <479267C2.1E75.00D7.1@scires.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> <477EA137.1E75.00D7.1@scires.com> <478D394B.1E75.00D7.1@scires.com> <478D47FB.1E75.00D7.1@scires.com> <478DBF8D.1E75.00D7.1@scires.com> <478DE973.1E75.00D7.1@scires.com> <47908659.1E75.00D7.1@scires.com> <20080119204810.3wmumqgms88sccw4@mail.elegosoft.com> <479267C2.1E75.00D7.1@scires.com> Message-ID: What does "mapped" mean here? The way it works, on Modula-3 NT386, and I haven't seen this done quite this way ever on Win32, not so systematically/mechanically/automatically, and I don't know how Posixish systems work here, but the way it works is that for every .dll, CM3 NT386 builds foo.lib and foo.lib.sa. foo.lib is an "import lib", just containing essentially function names and a file name. foo.lib.sa is a regular old static .lib, sa for standalone. You can also just build a static .lib -- for stuff that is never a .dll, for stuff that is only used once, but is broken up into multiple directories. For example m3quake, m3middle, m3objfile, m3back, etc. They are only used by cm3 so are just static .libs, just foo.lib, are built. (If we fix cm3.exe to be copy over itself, and I have some new clever ideas here, it might be profitable, for "developer productivity", to turn these into .dlls -- just so I can cd around and rebuild/reship less.) When you ask to build a standalone executable, we have a list of .libs, foo.lib, bar.lib. They are full paths. For each one, we see if foo.lib.sa exists, and if so, we use that instead of foo.lib. It is all rather simple and clever, but at least to me, it was surprising and new, so I explain it here. Perhaps Posixish systems work very similarly and this is old hat? I know cm3 doesn't implement this for Posix, but ar/ld/gcc could be handling things this way underneath for it. For example, I know on Mac OS X, if you link to a full path to a file, that's what you get. But if you say -Ldirectory -lfoo, ld probes for directory/foo.dylib and then directory/foo.a. So modulo the extensions and unknown to me how you build the things in the first place, same thing. You have to be sure to use the setting to split lib paths like that, otherwise you break dynamic linking. CM3 makes foo.sa.lib with its own mklib. This is also unusual. Normally one would use lib.exe or link.exe /lib for this, or ar/ld/gcc/dlltools. But the CM3 folks were obviously, openly en route to cutting dependencies through reimplementation. I had some initial trouble on NT385GNU building static .libs with ar/ld/gcc/dlltool, so, heck, I just do what NT386 does, and it seems to be working (modulo that SOMETHING is not working :) ). I don't want to stop anyone else from debugging this but if nobody else figures it out I will try. I can repro it easily, thanks for the good repro Randy! (though I wish it would crash instead of mis-display :) ) There is no "vendor's equivalent library" here, it is all just Modula-3 foo.lib or foo.lib.sa. Look at NT386/*.txt, by the .exe. Build one way. Rename away NT386. Build the other way. Compare the directories. You will see what I am talking about. - Jay Date: Sat, 19 Jan 2008 21:12:37 -0500 From: rcoleburn at scires.com To: hosking at cs.purdue.edu; wagner at elegosoft.com CC: m3devel at elegosoft.com Subject: Re: [M3devel] my status on win32 Hi Tony: Are you suggesting that when the program is built standalone it maps libraries differently? I know there is a difference between dynamic vs. static libraries, but are you suggesting that a different library is being mapped than the vendor's equivalent of the dynamic library? How would I check for this situation? Your suggestion seems plausible since the source is not recompiled; instead, the linker is used to change the way the EXE is put together and that seems to cause the difference in operation as far as pixmaps are concerned. Regards, Randy >>> Tony Hosking 1/19/2008 6:47 PM >>> I would perhaps suspect a bad library mapping. On Jan 19, 2008, at 2:48 PM, Olaf Wagner wrote: > Quoting Randy Coleburn : >> 1. pixmaps aren't rendered properly on the screen. They look really >> bad. I recall having this problem a while back with one of the early >> 5.x releases, so I guess it was never solved. I've got some old test >> programs I try to dig out and see if I can find out what is going >> on. I >> seem to recall that building standalone in the past seemed to fix the >> problem, so this is a real mystery. > > Hi Randy, > > I'm afraid I wasn't able to solve it directly some years ago and > then forgot about it due to more urgent tasks. > > I think we should try to narrow down the location of the problem > (i.e. is it in the runtime, code generation, linker, or windows > libraries). > > As you still have the 4.1 code of the Windows libraries, could you > first try to build them with the new compiler and see if it makes > a difference if you link against them? > > It may also be worthwhile to compare the commands actually used > for linking (use -commands). That is, before we turn to the actual > generated code... > > I still haven't got Windows access here, so I can just suggest what > to do... > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, > Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 Jan 20 04:46:03 2008 From: mika at async.caltech.edu (Mika Nystrom) Date: Sat, 19 Jan 2008 19:46:03 -0800 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: Your message of "Sat, 19 Jan 2008 12:48:06 EST." Message-ID: <200801200346.m0K3k3Em023728@camembert.async.caltech.edu> Can I add a perhaps obvious observation? NT386GNU must, of all things, mean that the code will compile and link cleanly, with a minimum of fuss, against Cygwin's headers and libraries. I have never used MS's C tools so I don't know if this is the case with them. It is of course the case when you use GNU ld, etc. When building large software in Modula-3 it's almost inevitable that, since the language is used by so few people, you will have a need to call out to C code (or Fortran code, or some other compiled code, with C interfaces). If you develop on Unix and use Cygwin to port to Windows, it makes no sense to distinguish between NT386 and NT386GNU unless the latter has pretty much the same environment as the Unix system. Mika Tony Hosking writes: >So, I am very confused now. Does NT386GNU no longer mean use of the >full set of GNU tools m3cc/ld/as, as would be available under >Cygwin? I thought the point of this was to be able to run in as much >of a GNU environment as possible. GNU to me means the whole >toolsuite not just m3cc. To me, a GNU-based environment on Windows >holds great attraction, since it consists of tools that I generally >always install on Windows, that I know, and are similar to the other >platforms I use. > >On Jan 19, 2008, at 4:11 AM, Jay Krell wrote: > >> CVSROOT: /usr/cvs >> Changes by: jkrell at birch. 08/01/19 04:11:34 >> >> Modified files: >> cm3/m3-libs/m3core/src/runtime/: m3makefile >> cm3/m3-sys/cminstall/src/config/: NT386GNU >> cm3/m3-sys/m3front/src/builtinInfo/: InfoModule.m3 >> cm3/m3-sys/m3middle/src/: Target.m3 >> >> Log message: >> m3-sys/m3middle/src/Target.m3 >> m3-libs/m3core/src/runtime/m3makefile >> m3-sys\m3front\src\builtinInfo\InfoModule.m3 >> >> switch NT386GNU to be Win32 instead of POSIX >> switch NT386GNU to _setjmp instead of setjmp >> jmp_buf size still big like Cygwin >> rewrite NT386GNU config file -- almost identical to NT386 >> mingwin required for building Modula-3 programs >> mingwin AND msys required for building m3cc >> >> To boot: >> >> install Python (www.activestate.com) >> >> have a working NT386 system >> get current source >> Mine is at c:\dev2\cm3.2 (cm3 is has other paused work, dev was >> taken by Unix) >> >> get and install binary distribution (5.1.3 works, anything newer >> should work) >> I install to c:\cm3 >> copy %CVSROOT%\m3-sys\cminstall\src\config\cm3.cfg to \cm3\bin >> \cm3.cfg >> >> Have a Visual C++ toolset (cl and link) >> and run the vcvars link on the start menu (this can/will be made >> easier) >> Almost any version should work. >> if you are using Visual C++ 8.0 (RTM?), rename away its mt.exe >> and get a newer from such as from the Platform SDK. Otherwise it >> crashes. >> This is not specific to NT386GNU, just that I recently removed the >> Platform SDK >> from my %PATH%. >> >> cd %CVSROOT%\scripts\python >> .\upgrade >> >> install msys and mingwin from http://www.mingw.org (links to >> SourceForge) >> for mingwin, you only need the "base" >> msys tells you to avoid mingwin make, in favor of msys make, and I >> did that >> >> I install to the defaults >> c:\msys\1.0 >> c:\mingw >> >> if you don't install to the defaults, add >> \bin and > to the start, but which order between the two?) >> >> if you do install to the defaults, scripts\python will fix path >> for you, >> if there is no gcc/as/sh on our $PATH >> >> cd %CVSROOT%\scripts\python >> upgrade && bootntgnu >> >> NOTE THE RESULTING BINARIES DO NOT YET WORK, but this is still >> progress. >> >> These instructions inevitably to be further tested and refined and >> placed elsewhere! From jayk123 at hotmail.com Sun Jan 20 05:52:55 2008 From: jayk123 at hotmail.com (Jay) Date: Sun, 20 Jan 2008 04:52:55 +0000 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: References: <20080119031134.4B6A510D4625@birch.elegosoft.com> Message-ID: Good, a happy customer. :) > GNU_MODE = 0 % Do not use GNU tools at all -- today's NT386 > GNU_MODE = 1 % Use GNU tools minimally -- today's NT386GNU > GNU_MODE = 2 % Use GNU tools maximally -- not existant but probably > easy > > Eh..I know, not great.. what do "minimally" and "maximally" mean. I'm still fishing for anyone to provide answers to these less important decisions that I have trouble with. Otherwise maybe no NT Cygwin system. TARGETs = { NT386, NT386GNU, NT386CYGWIN }? TARGETs = { NT386, NT386MINGWIN, NT386CYGWIN }? TARGETs = { NT386 + GNU_MODE }? The one reason I don't favor NT386 + GNU_MODE is that Cygwin has a much larger jmpbuf than the others. I think same TARGET implies code can be linked together, and I think varying jmpbuf implies otherwise. So NT386 and NT386MINGWIN should rarely cross paths with NT386CYGWIN. I also do NOT like this ad-hoc naming style. PPC_DARWIN, I386_DARWIN are much more to my style. The names should be somehow hierarchical, except, I realize, there isn't necessarily one "path" of stuff which to name platforms, though the GNU folks have settled on a way or two. They have triples or quadruples -- processor-hardware-os or such, however this doesn't clearly suffice. Something that accomodates: NT386 + LLVM NT386 + Watcom, linker and/or backend and/or runtime NT386 + Digital Mars linker and/or backend and/or runtime A C generating backend, and then linker/runtime and similar IA64, AMD64 variants would be good. To a large extent, these can be few platforms, subject to configuration, like if all the linkers consume a common file format (not clear), and if all the jmpbufs are the same size (known to be partly true, partly false). Oh and another thing, the runtime dependency is very likely cuttable, however PRESUMABLY real world applications (if there are any) link in a substantial amount of C or C++, in which case, it isn't necessarily cuttable. As well, if I can figure out a good way to do it, switching NT386 from awful slow frequent TlsGetValue/TlsSetValue to manipulating the linked list in fs:0, that would be nice, and might incur a C runtime dependency, but well worth it. The way Modula-3 works here is terrible. Another compromise option is probably __declspec(thread), though there is trickiness there in terms of being in a .dll that isn't used by the .exe. - Jay > CC: jkrell at elego.de; m3devel at elegosoft.com > From: hosking at cs.purdue.edu > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > Date: Sat, 19 Jan 2008 18:52:12 -0500 > To: jayk123 at hotmail.com > > OK, that's what I had hoped. > > Sounds good! > > On Jan 19, 2008, at 1:35 PM, Jay wrote: > > > ps -- look at m3-sys/cminstall/src/config/NT386GNU. > > While it is very very similar to NT386, and even outputs foo.lib > > and foo.lib.sa like NT386, it uses gcc for C compilation, linking, > > and m3cg for the backend. > > It is very "GNU" in tools, but not runtime. > > > > - Jay > > > > From: jayk123 at hotmail.com > > To: hosking at cs.purdue.edu; jkrell at elego.de > > CC: m3devel at elegosoft.com > > Subject: RE: [M3devel] [M3commit] CVS Update: cm3 > > Date: Sat, 19 Jan 2008 18:32:35 +0000 > > > > It DOES use m3cc/ld/as, and mklib for building static .libs, though > > that could probably be gcc/ar/dlltools if I figured it out. > > "Everything" except m3cc/m3gdb can be built with just MinGWin. > > Building m3cc requires MSys as well. > > Building m3gdb requires Cygwin. > > m3cg is not dependent on cygwin1.dll, nor are any other Modula-3 > > outputs. m3gdb is dependent on cygwin1.dll. > > > > Using Cygwin probably would work..and I could try it to see if it > > resolves the RTLinker problem. > > > > As well, we could have something like, in cm3.cfg you could set > > MINGWIN_ROOT, MSYS_ROOT, and/or CYGWIN_ROOT, to guide what tools > > are used, OR we can have some variable: > > > > GNU_MODE = 0 % Do not use GNU tools at all -- today's NT386 > > GNU_MODE = 1 % Use GNU tools minimally -- today's NT386GNU > > GNU_MODE = 2 % Use GNU tools maximally -- not existant but probably > > easy > > > > Eh..I know, not great.. what do "minimally" and "maximally" mean. > > > > I think we have the problem of a) many viable choices b) want to > > make several of them available c) just don't know what to call > > things and what the interface should be. As well as an interop > > question, since jmpbuf does vary in size between cygwin1.dl and > > everything else. > > > > Further down the line, there are other linkers, other compilers, > > other runtimes. The design here and now might take them into > > consideration. > > Gasp..I just realized, there is also another good backend option. > > parse.c's approach could probably be adapted to Open Watcom AND > > they might even take the changes (not that I have asked, I just > > thought of this). And that would net you progress toward a) 32 bit > > MS-DOS target b) OS/2 target, c) Netware target d) gcc-free Linux > > target, since the support all of them. > > Other target possibilities include Digital Mars compiler/linker, > > CodeWarrior (I know, dead and all), etc. Open Watcom is probably > > the most interesting since it is open source... > > > > - Jay > > > > > > > > > From: hosking at cs.purdue.edu > > > Date: Sat, 19 Jan 2008 12:48:06 -0500 > > > To: jkrell at elego.de > > > CC: m3devel at elegosoft.com > > > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > > > > > So, I am very confused now. Does NT386GNU no longer mean use of the > > > full set of GNU tools m3cc/ld/as, as would be available under > > > Cygwin? I thought the point of this was to be able to run in as much > > > of a GNU environment as possible. GNU to me means the whole > > > toolsuite not just m3cc. To me, a GNU-based environment on Windows > > > holds great attraction, since it consists of tools that I generally > > > always install on Windows, that I know, and are similar to the other > > > platforms I use. > > > > > > On Jan 19, 2008, at 4:11 AM, Jay Krell wrote: > > > > > > > CVSROOT: /usr/cvs > > > > Changes by: jkrell at birch. 08/01/19 04:11:34 > > > > > > > > Modified files: > > > > cm3/m3-libs/m3core/src/runtime/: m3makefile > > > > cm3/m3-sys/cminstall/src/config/: NT386GNU > > > > cm3/m3-sys/m3front/src/builtinInfo/: InfoModule.m3 > > > > cm3/m3-sys/m3middle/src/: Target.m3 > > > > > > > > Log message: > > > > m3-sys/m3middle/src/Target.m3 > > > > m3-libs/m3core/src/runtime/m3makefile > > > > m3-sys\m3front\src\builtinInfo\InfoModule.m3 > > > > > > > > switch NT386GNU to be Win32 instead of POSIX > > > > switch NT386GNU to _setjmp instead of setjmp > > > > jmp_buf size still big like Cygwin > > > > rewrite NT386GNU config file -- almost identical to NT386 > > > > mingwin required for building Modula-3 programs > > > > mingwin AND msys required for building m3cc > > > > > > > > To boot: > > > > > > > > install Python (www.activestate.com) > > > > > > > > have a working NT386 system > > > > get current source > > > > Mine is at c:\dev2\cm3.2 (cm3 is has other paused work, dev was > > > > taken by Unix) > > > > > > > > get and install binary distribution (5.1.3 works, anything newer > > > > should work) > > > > I install to c:\cm3 > > > > copy %CVSROOT%\m3-sys\cminstall\src\config\cm3.cfg to \cm3\bin > > > > \cm3.cfg > > > > > > > > Have a Visual C++ toolset (cl and link) > > > > and run the vcvars link on the start menu (this can/will be made > > > > easier) > > > > Almost any version should work. > > > > if you are using Visual C++ 8.0 (RTM?), rename away its mt.exe > > > > and get a newer from such as from the Platform SDK. Otherwise it > > > > crashes. > > > > This is not specific to NT386GNU, just that I recently removed the > > > > Platform SDK > > > > from my %PATH%. > > > > > > > > cd %CVSROOT%\scripts\python > > > > .\upgrade > > > > > > > > install msys and mingwin from http://www.mingw.org (links to > > > > SourceForge) > > > > for mingwin, you only need the "base" > > > > msys tells you to avoid mingwin make, in favor of msys make, and I > > > > did that > > > > > > > > I install to the defaults > > > > c:\msys\1.0 > > > > c:\mingw > > > > > > > > if you don't install to the defaults, add > > > > \bin and > > > to the start, but which order between the two?) > > > > > > > > if you do install to the defaults, scripts\python will fix path > > > > for you, > > > > if there is no gcc/as/sh on our $PATH > > > > > > > > cd %CVSROOT%\scripts\python > > > > upgrade && bootntgnu > > > > > > > > NOTE THE RESULTING BINARIES DO NOT YET WORK, but this is still > > > > progress. > > > > > > > > These instructions inevitably to be further tested and refined and > > > > placed elsewhere! > > > > > > > > > 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 jayk123 at hotmail.com Sun Jan 20 05:56:00 2008 From: jayk123 at hotmail.com (Jay) Date: Sun, 20 Jan 2008 04:56:00 +0000 Subject: [M3devel] more assembly symbols please? In-Reply-To: <1A973B4E-23DD-4B85-B42F-9070E93429BB@cs.purdue.edu> References: <2717B275-2548-41BC-BD1E-8742BCE6FA51@cs.purdue.edu> <1A973B4E-23DD-4B85-B42F-9070E93429BB@cs.purdue.edu> Message-ID: MinGWin (GNU ld) I might try putting together a totally Cygwin system to see if that works, to try to understand where the problem is. This really shouldn't be so hard from the information I have though.. :( Fishing with Cygwin should not be needed.. I can dump the ModuleInfo from C and I can see where the bad one is, I just need to trace through its creation to find where it goes bad... I assume it is NOT related to the fact that assembly/object file names get truncated to 8 characters, RTHeapInfo.m3 => RTHeapIn.m3 but so far that's all I see to "what is special about RTHeapInfo?". - Jay > CC: m3devel at elegosoft.com > From: hosking at cs.purdue.edu > Subject: Re: [M3devel] more assembly symbols please? > Date: Sat, 19 Jan 2008 18:46:59 -0500 > To: jayk123 at hotmail.com > > Which linker are you using? Could that be a factor? > > On Jan 19, 2008, at 1:49 PM, Jay wrote: > > > Thanks. m3cg -y for full tracing also dumps relevant stuff at the end. > > I'll try m3cgcat too. I should just be able to build/run an NT386 > > version. > > My C tracing does "prove" the problem is RTHeapInfo, but I still > > haven't figured out why. > > I've started skimming the code that builds that data...still a ways > > off from solving this I think. > > I have some suspicion the linker is moving things around that were > > otherwise correct, but I am far from proving that or fixing it. > > I'd like to first verify that the "m3front" / m3cg output is correct. > > The lack of labels in the as actually is a counter point to the > > movement theory, hard for linker to get a handle on anything to > > move around, it's just one blob. > > > > - Jay > > > > > > > > > CC: m3devel at elegosoft.com > > > From: hosking at cs.purdue.edu > > > Subject: Re: [M3devel] more assembly symbols please? > > > Date: Sat, 19 Jan 2008 12:33:08 -0500 > > > To: jayk123 at hotmail.com > > > > > > Take a look at the .mc intermediate code output if you want to see > > > that section of the data. There are at least comments. Use m3cgcat - > > > binary < x.mc > x.mo to view it (You can run m3cgcat on any other > > CM3 > > > install). > > > > > > On Jan 19, 2008, at 6:02 AM, Jay wrote: > > > > > > > Any chance the m3cg output could have, um, some symbols for the > > > > global data? > > > > It's kind of a pain to decode.. > > > > > > > > The module/import info is ok a lot, lots of runtime links ok. > > > > I think the bad one might be RTHeapInfo but I have to decode the > > > > very bare of symbols assembly.. > > > > or comments? Like for record fields? > > > > Still thinking of sticking a call out to C code...Even > > > > OutputDebugString since RTIO isn't working... > > > > > > > > I looked through the m3cg --help, didn't find anything. > > > > > > > > Tony? > > > > > > > > _MM_RTHeapInfo: > > > > 0 .long _L_1+224 > > > > 4 .long _MM_RTHeapInfo+52 > > > > 8 .long _MM_RTHeapInfo+308 > > > > 12,16 .space 8 > > > > 20 .long _L_1+152 > > > > 24 .space 4 > > > > 28 .long _L_1+220 > > > > 32 .long _L_1+220 > > > > 36 .long _MM_RTHeapInfo+160 > > > > 40 .space 4 > > > > .long _RTHeapInfo_M3 > > > > > > > > I get to count out to 160 bytes from here..: > > > > > > > > _L_1: > > > > 0 .byte 48 > > > > 1 .byte 49 > > > > 2 .byte 50 > > > > 3 .byte 51 > > > > 4 .byte 52 > > > > 5 .byte 53 > > > > 6 .byte 54 > > > > 7 .byte 55 > > > > 8 .byte 56 > > > > 9 .byte 57 > > > > a .byte 97 > > > > b .byte 98 > > > > c .byte 99 > > > > d .byte 100 > > > > e .byte 101 > > > > f .byte 102 > > > > 10 .long _RTHooks__TextLitInfo > > > > 14 .long _RTHooks__TextLitGetChar > > > > 18 .long _RTHooks__TextLitGetWideChar > > > > 1c .long _RTHooks__TextLitGetChars > > > > 20 .long _RTHooks__TextLitGetWideChars > > > > 24 .long 2 > > > > 28 .long _L_1+16 > > > > 2c .long 7 > > > > 30 .ascii "shownew" > > > > 37 .space 1 > > > > 38 .long 2 > > > > 3c .long _L_1+16 > > > > 40 .long 6 > > > > 44 .ascii "update" > > > > 4a .space 2 > > > > 4c .ascii "RTHeapInfo_M3" > > > > 50 .space 1 > > > > .ascii "Init" > > > > .space 1 > > > > > > > > I'll try the C code.. > > > > > > > > - Jay > > > > > > > > > > > > > > > > > > > > > > > > Connect and share in new ways with Windows Live. Get it now! > > > > > > > > > Shed those extra pounds with MSN and The Biggest Loser! Learn more. > _________________________________________________________________ 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 Jan 20 05:57:49 2008 From: jayk123 at hotmail.com (Jay) Date: Sun, 20 Jan 2008 04:57:49 +0000 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <5BFBD626-F492-4058-9A7A-6CB295753585@cs.purdue.edu> References: <20080119031134.4B6A510D4625@birch.elegosoft.com> <5BFBD626-F492-4058-9A7A-6CB295753585@cs.purdue.edu> Message-ID: Right, agreed, thanks for the reminder. - Jay > CC: jkrell at elego.de; m3devel at elegosoft.com > From: hosking at cs.purdue.edu > > On Jan 19, 2008, at 1:32 PM, Jay wrote: > > > Gasp..I just realized, there is also another good backend option. > > parse.c's approach could probably be adapted to Open Watcom AND > > they might even take the changes (not that I have asked, I just > > thought of this). And that would net you progress toward a) 32 bit > > MS-DOS target b) OS/2 target, c) Netware target d) gcc-free Linux > > target, since the support all of them. > > I would plump for llvm. Apple is using it heavily these days and may > be pushing it into their Mac compiler toolchain. _________________________________________________________________ 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 Jan 20 07:34:14 2008 From: jayk123 at hotmail.com (Jay) Date: Sun, 20 Jan 2008 06:34:14 +0000 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <200801200346.m0K3k3Em023728@camembert.async.caltech.edu> References: Your message of "Sat, 19 Jan 2008 12:48:06 EST." <200801200346.m0K3k3Em023728@camembert.async.caltech.edu> Message-ID: Mika, while I agree such a target might be interesting, and might just about work now, there is another target that is also definitely interesting, and more interesting to some folks, and perhaps more efficient, smaller, faster. There needs to be a way to ask for one or the other. People want one. People want the other. I think I've seen about two people ask for each. Wow a small number. There are tools and there is runtime, and you can pick and chose. But too many choices and people get confused, so there's a need to prepackage some combinations under small names. At the moment, NT386GNU means use GNU tools, but otherwise be like NT386. There are really several variables in all this. There are three threading models available, and they probably all work or could be easily made to. There are two underlying GUI libraries, ditto. There is PERHAPS Win9x compatibility to consider. Cygwin is dropping that in newer versions. What is a "target"? vs. what is a "configuration"? Odds are fairly good that if you merely alter $PATH one way or the other, and undo my small changes below to what m3makefile includes what, and what cm3 assumes OSTYPE is, Cygwin will work, at least as well as I have NT386GNU otherwise working. That is, all three of these targets are so darn similar that is almost just a matter of "configuration" and could perhaps be made so. I am reluctant to blow up the size of jmpbuf to enable arbitrary mixing however. The tricky part is not so much making it work, but what to call it, how to expose it to users, as well as perhaps streamlining the setup. I am better at "making it work" however and am open to suggestions all around. There is yet another direction and it is obviously the direction things were going -- neither GNU nor MS tools. There is already the x86 backend written in Modula-3. It is noticably very much faster than the gcc backend. There is very little C code in the system and it could probably all be rewritten in Modula-3..the beauty of its "optional safety"...though your point is very valid as to outside the system. There is already a start of a runtime linker that loads .objs. The C runtime dependency is very very minimal already. Finish those last two points and you have a "self contained" system , from a certain point of view, a common point of view, though there is still the dependency on kernel32.dll, user32.dll, gdi32.dll, the "OS" as people like to label it, though it is really just another bunch of code in most respects and not something as "special" as people think, and you can be more or less dependent on it as well -- remember that Modula-3 when using the vtalarm threads does its own scheduling (I think), a task people normally think of as provided by an "OS". (I believe Mary Fernandez already wrote a relatively easily retargetable linker and debugger in Modula-3, but I could be wrong.) I just realized another target -- NT386-Interix or such, these days known as "Services for Unix" and I think a free download. This is YET ANOTHER very Posixish environment. As well, there is the question from earlier of "What is Posix?" It's not like Microsoft doesn't provide open/read/write/close. They do. What all is in the Cygwin headers that people want? The availability of sh should have little impact on your Modula-3 code, right? You aren't running command lines in it, right? It's not like portable standard C and C++ can't be compiled just as well, if not better and faster, by the Microsoft compiler. It can be. I realize there are details, levels of ANSI conformity, and there are language extensions on both sides. Now, since I have been debugging stuff lately, I realize there could be a big question as to debuggers. More importantly, debug information format. My experience lately is that this is an either/or choice, and you can't have it both ways. If you are very used to gdb/m3gdb, you must use the GNU tools. But you don't need Cygwin (except to build m3gdb or acquire gdb). If you are very used to windbg/ntsd/cdb/Visual Studio, well you must use the non-gcc backend, the Microsoft C compiler for the little bit of C/C++ if you want to debug it, the Microsoft linker I assume, however you aren't going to be likely happy. The non-gcc backend only outputs line number information, no types, no locals. It's not a pleasant experience, but at least you can see the stack. You can also to some extent use both. You can build your code for either platform and flit around between the two. Or you can flit around between debuggers and deal with a lack of symbols in one, and just poke around in memory, using information gleaned from the other. But again, this doesn't have much to do with Cygwin or not Cygwin. I've only been going at this a short time, so maybe gdb does better with the Cygwin output. I don't know. Sorry for the tone. We are actually in agreement, essentially. I have been largely on the fence and just asking what to call things, and everyone else is clearly on one side or the other. I personally will not use Cygwin if I can help it, but I do use it for cvs and ssh at least. I actually hardlink swaths of it into my Windows directory, the useful command line utilities, that which likely one non-configurable version would suffice -- ie: not gcc/ld/ar/as. If there was one true gcc/ld/ar/as, I would hardlink it in too. Likewise with cl/link. e.g. I have windiff in there, but not cl/link. I don't want that cygwin1.dll dependency and then have to understand the licensing... So the non-Cygwin target came first. It is easier. It is faster. It is what I prefer. Maybe there will be a Cygwin target. Maybe someone else will provide it? It should be clear btw that the real work here was all done for us in gcc/ld, and cm3. The rest is easier. Besides..who is going to do the work here, and who is going to use it? Are Windows users asking for a more Posixish system or are Posix users saying what Windows should be like? Will they move to it? Bah humbug. - Jay > To: hosking at cs.purdue.edu> To: m3devel at elegosoft.com> Date: Sat, 19 Jan 2008 19:46:03 -0800> From: mika at async.caltech.edu> Subject: Re: [M3devel] [M3commit] CVS Update: cm3> > Can I add a perhaps obvious observation?> > NT386GNU must, of all things, mean that the code will compile and> link cleanly, with a minimum of fuss, against Cygwin's headers> and libraries. I have never used MS's C tools so I don't know> if this is the case with them. It is of course the case when> you use GNU ld, etc.> > When building large software in Modula-3 it's almost inevitable> that, since the language is used by so few people, you will have a> need to call out to C code (or Fortran code, or some other compiled> code, with C interfaces). If you develop on Unix and use Cygwin> to port to Windows, it makes no sense to distinguish between NT386> and NT386GNU unless the latter has pretty much the same environment> as the Unix system.> > Mika> > Tony Hosking writes:> >So, I am very confused now. Does NT386GNU no longer mean use of the > >full set of GNU tools m3cc/ld/as, as would be available under > >Cygwin? I thought the point of this was to be able to run in as much > >of a GNU environment as possible. GNU to me means the whole > >toolsuite not just m3cc. To me, a GNU-based environment on Windows > >holds great attraction, since it consists of tools that I generally > >always install on Windows, that I know, and are similar to the other > >platforms I use.> >> >On Jan 19, 2008, at 4:11 AM, Jay Krell wrote:> >> >> CVSROOT: /usr/cvs> >> Changes by: jkrell at birch. 08/01/19 04:11:34> >>> >> Modified files:> >> cm3/m3-libs/m3core/src/runtime/: m3makefile> >> cm3/m3-sys/cminstall/src/config/: NT386GNU> >> cm3/m3-sys/m3front/src/builtinInfo/: InfoModule.m3> >> cm3/m3-sys/m3middle/src/: Target.m3> >>> >> Log message:> >> m3-sys/m3middle/src/Target.m3> >> m3-libs/m3core/src/runtime/m3makefile> >> m3-sys\m3front\src\builtinInfo\InfoModule.m3> >> > >> switch NT386GNU to be Win32 instead of POSIX> >> switch NT386GNU to _setjmp instead of setjmp> >> jmp_buf size still big like Cygwin> >> rewrite NT386GNU config file -- almost identical to NT386> >> mingwin required for building Modula-3 programs> >> mingwin AND msys required for building m3cc> >> > >> To boot:> >> > >> install Python (www.activestate.com)> >> > >> have a working NT386 system> >> get current source> >> Mine is at c:\dev2\cm3.2 (cm3 is has other paused work, dev was > >> taken by Unix)> >> > >> get and install binary distribution (5.1.3 works, anything newer > >> should work)> >> I install to c:\cm3> >> copy %CVSROOT%\m3-sys\cminstall\src\config\cm3.cfg to \cm3\bin > >> \cm3.cfg> >> > >> Have a Visual C++ toolset (cl and link)> >> and run the vcvars link on the start menu (this can/will be made > >> easier)> >> Almost any version should work.> >> if you are using Visual C++ 8.0 (RTM?), rename away its mt.exe> >> and get a newer from such as from the Platform SDK. Otherwise it > >> crashes.> >> This is not specific to NT386GNU, just that I recently removed the > >> Platform SDK> >> from my %PATH%.> >> > >> cd %CVSROOT%\scripts\python> >> .\upgrade> >> > >> install msys and mingwin from http://www.mingw.org (links to > >> SourceForge)> >> for mingwin, you only need the "base"> >> msys tells you to avoid mingwin make, in favor of msys make, and I > >> did that> >> > >> I install to the defaults> >> c:\msys\1.0> >> c:\mingw> >> > >> if you don't install to the defaults, add> >> \bin and >> to the start, but which order between the two?)> >> > >> if you do install to the defaults, scripts\python will fix path > >> for you,> >> if there is no gcc/as/sh on our $PATH> >> > >> cd %CVSROOT%\scripts\python> >> upgrade && bootntgnu> >> > >> NOTE THE RESULTING BINARIES DO NOT YET WORK, but this is still > >> progress.> >> > >> These instructions inevitably to be further tested and refined and > >> placed elsewhere! _________________________________________________________________ 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 Jan 20 13:08:20 2008 From: jayk123 at hotmail.com (Jay) Date: Sun, 20 Jan 2008 12:08:20 +0000 Subject: [M3devel] more assembly symbols please? In-Reply-To: <1A973B4E-23DD-4B85-B42F-9070E93429BB@cs.purdue.edu> References: <2717B275-2548-41BC-BD1E-8742BCE6FA51@cs.purdue.edu> <1A973B4E-23DD-4B85-B42F-9070E93429BB@cs.purdue.edu> Message-ID: Exact same result with MS link. Quite the succesful interop. :) I copied in all the relevant *o and *obj files (avoiding mklib/*.lib as a factor) to C:\dev2\cm3.2\m3-sys\cm3\NT386GNU and selectively from \mingw\lib (like just in the end libcgcc.a for arithmetic helpers) and then link -out:cm3.exe *.io *.mo *.obj comctl32.lib gdi32.lib user32.lib wsock32.lib netapi32.lib libgcc.a kernel32.lib advapi32.lib msvcrt.lib prints the same thing, crashes due to the same data. Which is to say, in the great toolset debate, you can use the gcc back end (and as) for Modula-3, but then either ld or link and probably cl or gcc. :) Except..it still doesn't quite work.. I guess "collect2" is a synonym for ld? - Jay From: jayk123 at hotmail.comTo: hosking at cs.purdue.eduCC: m3devel at elegosoft.comSubject: RE: [M3devel] more assembly symbols please?Date: Sun, 20 Jan 2008 04:56:00 +0000 MinGWin (GNU ld)I might try putting together a totally Cygwin system to see if that works, to try to understand where the problem is.This really shouldn't be so hard from the information I have though.. :(Fishing with Cygwin should not be needed..I can dump the ModuleInfo from C and I can see where the bad one is, I just need to trace through its creation to find where it goes bad...I assume it is NOT related to the fact that assembly/object file names get truncated to 8 characters, RTHeapInfo.m3 => RTHeapIn.m3 but so far that's all I see to "what is special about RTHeapInfo?". - Jay > CC: m3devel at elegosoft.com> From: hosking at cs.purdue.edu> Subject: Re: [M3devel] more assembly symbols please?> Date: Sat, 19 Jan 2008 18:46:59 -0500> To: jayk123 at hotmail.com> > Which linker are you using? Could that be a factor?> > On Jan 19, 2008, at 1:49 PM, Jay wrote:> > > Thanks. m3cg -y for full tracing also dumps relevant stuff at the end.> > I'll try m3cgcat too. I should just be able to build/run an NT386 > > version.> > My C tracing does "prove" the problem is RTHeapInfo, but I still > > haven't figured out why.> > I've started skimming the code that builds that data...still a ways > > off from solving this I think.> > I have some suspicion the linker is moving things around that were > > otherwise correct, but I am far from proving that or fixing it.> > I'd like to first verify that the "m3front" / m3cg output is correct.> > The lack of labels in the as actually is a counter point to the > > movement theory, hard for linker to get a handle on anything to > > move around, it's just one blob.> >> > - Jay> >> >> >> > > CC: m3devel at elegosoft.com> > > From: hosking at cs.purdue.edu> > > Subject: Re: [M3devel] more assembly symbols please?> > > Date: Sat, 19 Jan 2008 12:33:08 -0500> > > To: jayk123 at hotmail.com> > >> > > Take a look at the .mc intermediate code output if you want to see> > > that section of the data. There are at least comments. Use m3cgcat -> > > binary < x.mc > x.mo to view it (You can run m3cgcat on any other > > CM3> > > install).> > >> > > On Jan 19, 2008, at 6:02 AM, Jay wrote:> > >> > > > Any chance the m3cg output could have, um, some symbols for the> > > > global data?> > > > It's kind of a pain to decode..> > > >> > > > The module/import info is ok a lot, lots of runtime links ok.> > > > I think the bad one might be RTHeapInfo but I have to decode the> > > > very bare of symbols assembly..> > > > or comments? Like for record fields?> > > > Still thinking of sticking a call out to C code...Even> > > > OutputDebugString since RTIO isn't working...> > > >> > > > I looked through the m3cg --help, didn't find anything.> > > >> > > > Tony?> > > >> > > > _MM_RTHeapInfo:> > > > 0 .long _L_1+224> > > > 4 .long _MM_RTHeapInfo+52> > > > 8 .long _MM_RTHeapInfo+308> > > > 12,16 .space 8> > > > 20 .long _L_1+152> > > > 24 .space 4> > > > 28 .long _L_1+220> > > > 32 .long _L_1+220> > > > 36 .long _MM_RTHeapInfo+160> > > > 40 .space 4> > > > .long _RTHeapInfo_M3> > > >> > > > I get to count out to 160 bytes from here..:> > > >> > > > _L_1:> > > > 0 .byte 48> > > > 1 .byte 49> > > > 2 .byte 50> > > > 3 .byte 51> > > > 4 .byte 52> > > > 5 .byte 53> > > > 6 .byte 54> > > > 7 .byte 55> > > > 8 .byte 56> > > > 9 .byte 57> > > > a .byte 97> > > > b .byte 98> > > > c .byte 99> > > > d .byte 100> > > > e .byte 101> > > > f .byte 102> > > > 10 .long _RTHooks__TextLitInfo> > > > 14 .long _RTHooks__TextLitGetChar> > > > 18 .long _RTHooks__TextLitGetWideChar> > > > 1c .long _RTHooks__TextLitGetChars> > > > 20 .long _RTHooks__TextLitGetWideChars> > > > 24 .long 2> > > > 28 .long _L_1+16> > > > 2c .long 7> > > > 30 .ascii "shownew"> > > > 37 .space 1> > > > 38 .long 2> > > > 3c .long _L_1+16> > > > 40 .long 6> > > > 44 .ascii "update"> > > > 4a .space 2> > > > 4c .ascii "RTHeapInfo_M3"> > > > 50 .space 1> > > > .ascii "Init"> > > > .space 1> > > >> > > > I'll try the C code..> > > >> > > > - Jay> > > >> > > >> > > >> > > >> > > >> > > > Connect and share in new ways with Windows Live. Get it now!> > >> >> >> > Shed those extra pounds with MSN and The Biggest Loser! Learn more.> 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 wagner at elegosoft.com Sun Jan 20 15:56:49 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Sun, 20 Jan 2008 15:56:49 +0100 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: References: <20080119031134.4B6A510D4625@birch.elegosoft.com> Message-ID: <20080120155649.tl5ghxhnl8o0g4cs@mail.elegosoft.com> Quoting Jay : > Good, a happy customer. :) > >> GNU_MODE = 0 % Do not use GNU tools at all -- today's NT386 >> GNU_MODE = 1 % Use GNU tools minimally -- today's NT386GNU >> GNU_MODE = 2 % Use GNU tools maximally -- not existant but probably >> easy >> >> Eh..I know, not great.. what do "minimally" and "maximally" mean. > > I'm still fishing for anyone to provide answers to these > less important decisions that I have trouble with. > Otherwise maybe no NT Cygwin system. > > TARGETs = { NT386, NT386GNU, NT386CYGWIN }? > TARGETs = { NT386, NT386MINGWIN, NT386CYGWIN }? > TARGETs = { NT386 + GNU_MODE }? > > The one reason I don't favor NT386 + GNU_MODE is that Cygwin has a > much larger jmpbuf than the others. > I think same TARGET implies code can be linked together, and I think > varying jmpbuf implies otherwise. > So NT386 and NT386MINGWIN should rarely cross paths with NT386CYGWIN. I think a new target is called for if I have understood everything right. We need one pure native target (NT386), one pure-Cygwin-based target (NT386_CYGWIN?) and one mix of runtime, gnu tools and mingwin (NT386_MINGWIN?). As NT386GNU already exists, we must decide if we want to use it as we traditionally did (all Cygwin) or the mixed implementation (Mingwin and much Windows RT). > I also do NOT like this ad-hoc naming style. > PPC_DARWIN, I386_DARWIN are much more to my style. > The names should be somehow hierarchical, except, I realize, there > isn't necessarily one "path" of > stuff which to name platforms, though the GNU folks have settled on > a way or two. > They have triples or quadruples -- processor-hardware-os or such, > however this doesn't > clearly suffice. Well, yes, something more systematic would have been better, but to break with the history will cause much trouble for all users and the infrastructure. So I'd rather vote that only new targets get more systematic names. > Something that accomodates: > NT386 + LLVM > NT386 + Watcom, linker and/or backend and/or runtime > NT386 + Digital Mars linker and/or backend and/or runtime > A C generating backend, and then linker/runtime > and similar IA64, AMD64 variants would be good. I'm not sure that a C generating backend would really help matters. This was done in the first implementation of DEC, and they soon abandoned it as C had proven to be a bad choice as intermediate language. I agree it would be great for cross-compilation etc. As far as C and RT dependencies of native Windows compilers go, I don't see why this couldn't be just a question of another cm3.cfg setup. > To a large extent, these can be few platforms, subject to > configuration, like if all > the linkers consume a common file format (not clear), and if all the > jmpbufs are the same > size (known to be partly true, partly false). Yes, jmpbuf is always a problem for user threads and exceptions. On Unix systems the jmpbuf and other important low-level structures are always defined by the system headers and independent of compilers AFAIK, so I'm a bit surprised that it should be different on Windows. But maybe I'm just wrong and haven't just seen the right counter examples... > Oh and another thing, the runtime dependency is very likely cuttable, however > PRESUMABLY real world applications (if there are any) link in a > substantial amount of > C or C++, in which case, it isn't necessarily cuttable. Yes. Real world applications tend to link other libraries (C, C++, Fortran, ...) and even often call other applications like sh etc. > As well, if I can figure out a good way to do it, switching NT386 > from awful slow > frequent TlsGetValue/TlsSetValue to manipulating the linked list in > fs:0, that would be nice, > and might incur a C runtime dependency, but well worth it. The way > Modula-3 works here > is terrible. Another compromise option is probably > __declspec(thread), though there is trickiness there > in terms of being in a .dll that isn't used by the .exe. Such optimizations should be done depending on the target. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Jan 20 17:26:28 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 20 Jan 2008 11:26:28 -0500 Subject: [M3devel] my status on win32 In-Reply-To: <479267C2.1E75.00D7.1@scires.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> <477EA137.1E75.00D7.1@scires.com> <478D394B.1E75.00D7.1@scires.com> <478D47FB.1E75.00D7.1@scires.com> <478DBF8D.1E75.00D7.1@scires.com> <478DE973.1E75.00D7.1@scires.com> <47908659.1E75.00D7.1@scires.com> <20080119204810.3wmumqgms88sccw4@mail.elegosoft.com> <479267C2.1E75.00D7.1@scires.com> Message-ID: I'm not sure what I mean since I am a Windows ignoramus. Jay? On Jan 19, 2008, at 9:12 PM, Randy Coleburn wrote: > Hi Tony: > > Are you suggesting that when the program is built standalone it > maps libraries differently? I know there is a difference between > dynamic vs. static libraries, but are you suggesting that a > different library is being mapped than the vendor's equivalent of > the dynamic library? How would I check for this situation? > > Your suggestion seems plausible since the source is not recompiled; > instead, the linker is used to change the way the EXE is put > together and that seems to cause the difference in operation as far > as pixmaps are concerned. > > Regards, > Randy > > >>> Tony Hosking 1/19/2008 6:47 PM >>> > I would perhaps suspect a bad library mapping. > > On Jan 19, 2008, at 2:48 PM, Olaf Wagner wrote: > > > Quoting Randy Coleburn : > >> 1. pixmaps aren't rendered properly on the screen. They look > really > >> bad. I recall having this problem a while back with one of the > early > >> 5.x releases, so I guess it was never solved. I've got some old > test > >> programs I try to dig out and see if I can find out what is going > >> on. I > >> seem to recall that building standalone in the past seemed to > fix the > >> problem, so this is a real mystery. > > > > Hi Randy, > > > > I'm afraid I wasn't able to solve it directly some years ago and > > then forgot about it due to more urgent tasks. > > > > I think we should try to narrow down the location of the problem > > (i.e. is it in the runtime, code generation, linker, or windows > > libraries). > > > > As you still have the 4.1 code of the Windows libraries, could you > > first try to build them with the new compiler and see if it makes > > a difference if you link against them? > > > > It may also be worthwhile to compare the commands actually used > > for linking (use -commands). That is, before we turn to the actual > > generated code... > > > > I still haven't got Windows access here, so I can just suggest what > > to do... > > > > Olaf > > -- > > Olaf Wagner -- elego Software Solutions GmbH > > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, > > Germany > > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Jan 20 17:48:26 2008 From: jayk123 at hotmail.com (Jay) Date: Sun, 20 Jan 2008 16:48:26 +0000 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <20080120155649.tl5ghxhnl8o0g4cs@mail.elegosoft.com> References: <20080119031134.4B6A510D4625@birch.elegosoft.com> <20080120155649.tl5ghxhnl8o0g4cs@mail.elegosoft.com> Message-ID: > the infrastructure. So I'd rather vote that only new targets get> more systematic names. Of course, though the existing names suggest new names, and not clear the value of the existing NT386GNU. Ie. is there a benefit to keep it in use with some meaning or not? Cygwin does have a larger jmpbuf than msvcr*.dll/mingwin. I think it holds sigaction state besides register state. "NT" and "Win" seem redundant. I386_MINGWIN? I386_CYGWIN? NT386_GNU? NT386_MINGNU? Ok, I admit that NT386_CYGWIN NT386_MINGWIN despite the redundancy, clearly point to existing projects that probably have name recognition. And building from NT386 is reasonable -- as was I saying about existing names influencing new names. A C generating backend gets you perhaps easier retargeting as well. I do see there is "MINGWIN64" out there, for AMD64. Not sure what the state of IA64 is though... (See -- you should avoid saying "32" or "64" in stuff, Win32 => Win, Win64 => Win.) I also would agree that creating one target instead of two is probably a good idea -- seems easier. I am not sure if current state is relevant. I mean, is NT386GNU really working and in use anywhere? Is PM3 in use? If so, then matching their meaning would be good. Or even going beyond that -- to Trestle on X Windows. :) (Though CygwinX doesn't exactly appear active.) And thus the precedent for no underscore. NT386MINGWIN ? NT386MINGNU ? I don't know if "MSYS" needs a place in this name. It is needed for building m3cc. I wonder if a hybrid/adaptive approach will be desired -- if Cygwin is available, the MinGWin target could use it to build m3gdb, since it can't otherwise. Hint for anyone trying out Cygwin and getting an odd mix of paths: mkdir \cygdrive get junction.exe from the former www.sysinternals.com junction \cygdrive\c c:\ now when some Cygwin code passes /cygdrive/c to Win32 code, it will just work, no translation needed. If you have multiple drives, I guess just fully populate each one c:\cygdrive\c => c:\ c:\cygdrive\d => d:\ d:\cygdrive\c => c:\ d:\cygdrive\d => d:\ etc. but I haven't tried that. Or, to reduce the multiplication, set them all up on c: and have d:\cygdrive => c:\cygdrive, e:\cygdrive => c:\cygdrive, etc. - Jay > Date: Sun, 20 Jan 2008 15:56:49 +0100> From: wagner at elegosoft.com> To: m3devel at elegosoft.com> Subject: Re: [M3devel] [M3commit] CVS Update: cm3> > Quoting Jay :> > > Good, a happy customer. :)> >> >> GNU_MODE = 0 % Do not use GNU tools at all -- today's NT386> >> GNU_MODE = 1 % Use GNU tools minimally -- today's NT386GNU> >> GNU_MODE = 2 % Use GNU tools maximally -- not existant but probably> >> easy> >>> >> Eh..I know, not great.. what do "minimally" and "maximally" mean.> >> > I'm still fishing for anyone to provide answers to these> > less important decisions that I have trouble with.> > Otherwise maybe no NT Cygwin system.> >> > TARGETs = { NT386, NT386GNU, NT386CYGWIN }?> > TARGETs = { NT386, NT386MINGWIN, NT386CYGWIN }?> > TARGETs = { NT386 + GNU_MODE }?> >> > The one reason I don't favor NT386 + GNU_MODE is that Cygwin has a > > much larger jmpbuf than the others.> > I think same TARGET implies code can be linked together, and I think > > varying jmpbuf implies otherwise.> > So NT386 and NT386MINGWIN should rarely cross paths with NT386CYGWIN.> > I think a new target is called for if I have understood everything right.> We need one pure native target (NT386), one pure-Cygwin-based target> (NT386_CYGWIN?) and one mix of runtime, gnu tools and mingwin> (NT386_MINGWIN?).> > As NT386GNU already exists, we must decide if we want to use it as> we traditionally did (all Cygwin) or the mixed implementation> (Mingwin and much Windows RT).> > > I also do NOT like this ad-hoc naming style.> > PPC_DARWIN, I386_DARWIN are much more to my style.> > The names should be somehow hierarchical, except, I realize, there > > isn't necessarily one "path" of> > stuff which to name platforms, though the GNU folks have settled on > > a way or two.> > They have triples or quadruples -- processor-hardware-os or such, > > however this doesn't> > clearly suffice.> > Well, yes, something more systematic would have been better, but> to break with the history will cause much trouble for all users and> the infrastructure. So I'd rather vote that only new targets get> more systematic names.> > > Something that accomodates:> > NT386 + LLVM> > NT386 + Watcom, linker and/or backend and/or runtime> > NT386 + Digital Mars linker and/or backend and/or runtime> > A C generating backend, and then linker/runtime> > and similar IA64, AMD64 variants would be good.> > I'm not sure that a C generating backend would really help matters.> This was done in the first implementation of DEC, and they soon> abandoned it as C had proven to be a bad choice as intermediate language.> I agree it would be great for cross-compilation etc.> > As far as C and RT dependencies of native Windows compilers go, I don't> see why this couldn't be just a question of another cm3.cfg setup.> > > To a large extent, these can be few platforms, subject to > > configuration, like if all> > the linkers consume a common file format (not clear), and if all the > > jmpbufs are the same> > size (known to be partly true, partly false).> > Yes, jmpbuf is always a problem for user threads and exceptions.> On Unix systems the jmpbuf and other important low-level structures> are always defined by the system headers and independent of compilers> AFAIK, so I'm a bit surprised that it should be different on Windows.> But maybe I'm just wrong and haven't just seen the right counter> examples...> > > Oh and another thing, the runtime dependency is very likely cuttable, however> > PRESUMABLY real world applications (if there are any) link in a > > substantial amount of> > C or C++, in which case, it isn't necessarily cuttable.> > Yes. Real world applications tend to link other libraries (C, C++,> Fortran, ...) and even often call other applications like sh etc.> > > As well, if I can figure out a good way to do it, switching NT386 > > from awful slow> > frequent TlsGetValue/TlsSetValue to manipulating the linked list in > > fs:0, that would be nice,> > and might incur a C runtime dependency, but well worth it. The way > > Modula-3 works here> > is terrible. Another compromise option is probably > > __declspec(thread), though there is trickiness there> > in terms of being in a .dll that isn't used by the .exe.> > Such optimizations should be done depending on the target.> > Olaf> -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 hosking at cs.purdue.edu Sun Jan 20 18:02:32 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 20 Jan 2008 12:02:32 -0500 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <20080120110109.92CCC10D4628@birch.elegosoft.com> References: <20080120110109.92CCC10D4628@birch.elegosoft.com> Message-ID: Jay, I am particularly disturbed by these changes you just committed because of the nasty reliance they impose on C in this part of the run-time library. Part of the beauty of M3 is that its compiler and libraries are almost entirely programmed in Modula-3. Your change here has been made to satisfy a need to debug a severely broken run- time system. Better in such situations to use a standard debugger rather than pollute the Modula-3 code with nasty reliance on C. If you need to use such hacks in your debugging please do so in your privately checked out working directories rather than imposing them on the rest of us by checking into the main tree. If you need a debugging source tree in which to play then there is ample provision using CVS to fork a development branch that is off the main trunk. Shall I undo these hacks or will you? It is important in a collaborative effort such as this to make sure that we all play nicely in the shared CVS space. In this case I think you have regressed the code base by adding these C-based hacks. Best, -- Tony On Jan 20, 2008, at 12:01 PM, Jay Krell wrote: > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 08/01/20 12:01:09 > > Modified files: > cm3/m3-libs/m3core/src/runtime/common/: RTLinker.i3 RTLinker.m3 > m3makefile > Added files: > cm3/m3-libs/m3core/src/runtime/common/: RTLinkerC.c > > Log message: > allow RTLinker's tracing to work when things are more broken > the default behavior is unchanged, and the behavior with > @M3tracelinker > is preserved > a change in behavior requires modifying RTLinkerC.c and rebuilding > this also enables more verbose tracing From hosking at cs.purdue.edu Sun Jan 20 18:06:03 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 20 Jan 2008 12:06:03 -0500 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: References: <20080119031134.4B6A510D4625@birch.elegosoft.com> <20080120155649.tl5ghxhnl8o0g4cs@mail.elegosoft.com> Message-ID: On Jan 20, 2008, at 11:48 AM, Jay wrote: > > the infrastructure. So I'd rather vote that only new targets get > > more systematic names. > > Of course, though the existing names suggest new names, and > not clear the value of the existing NT386GNU. Ie. is there a benefit > to keep it in use with some meaning or not? Since others have made historic associations for the names we should probably keep their original meaning. I agree with Olaf here. From jayk123 at hotmail.com Sun Jan 20 18:13:52 2008 From: jayk123 at hotmail.com (Jay) Date: Sun, 20 Jan 2008 17:13:52 +0000 Subject: [M3devel] my status on win32 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> <477EA137.1E75.00D7.1@scires.com> <478D394B.1E75.00D7.1@scires.com> <478D47FB.1E75.00D7.1@scires.com> <478DBF8D.1E75.00D7.1@scires.com> <478DE973.1E75.00D7.1@scires.com> <47908659.1E75.00D7.1@scires.com> <20080119204810.3wmumqgms88sccw4@mail.elegosoft.com> <479267C2.1E75.00D7.1@scires.com> Message-ID: I'm not sure what you mean either Tony. :) But you got me thinking. Standalone vs. non standalone are mostly a transparent size optimization. But there is the state sharing vs. not. If there is some: static int i; int GetGlobal(void) { return i; } void SetGlobal(int j) { return i = j; } in a dll then there is just one i process wide. With a static .lib, each client .dll/.so/.exe would get its own i. However Modula-3 doesn't offer standalone .dlls so some of that is moot. The repro is so easy, I'm sure we'll get it before much longer, but I'd like to fix the GNU ModuleInfo first. - Jay > From: hosking at cs.purdue.edu> Date: Sun, 20 Jan 2008 11:26:28 -0500> To: rcoleburn at scires.com> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] my status on win32> > I'm not sure what I mean since I am a Windows ignoramus. Jay?> > On Jan 19, 2008, at 9:12 PM, Randy Coleburn wrote:> > > Hi Tony:> >> > Are you suggesting that when the program is built standalone it > > maps libraries differently? I know there is a difference between > > dynamic vs. static libraries, but are you suggesting that a > > different library is being mapped than the vendor's equivalent of > > the dynamic library? How would I check for this situation?> >> > Your suggestion seems plausible since the source is not recompiled; > > instead, the linker is used to change the way the EXE is put > > together and that seems to cause the difference in operation as far > > as pixmaps are concerned.> >> > Regards,> > Randy> >> > >>> Tony Hosking 1/19/2008 6:47 PM >>>> > I would perhaps suspect a bad library mapping.> >> > On Jan 19, 2008, at 2:48 PM, Olaf Wagner wrote:> >> > > Quoting Randy Coleburn :> > >> 1. pixmaps aren't rendered properly on the screen. They look > > really> > >> bad. I recall having this problem a while back with one of the > > early> > >> 5.x releases, so I guess it was never solved. I've got some old > > test> > >> programs I try to dig out and see if I can find out what is going> > >> on. I> > >> seem to recall that building standalone in the past seemed to > > fix the> > >> problem, so this is a real mystery.> > >> > > Hi Randy,> > >> > > I'm afraid I wasn't able to solve it directly some years ago and> > > then forgot about it due to more urgent tasks.> > >> > > I think we should try to narrow down the location of the problem> > > (i.e. is it in the runtime, code generation, linker, or windows> > > libraries).> > >> > > As you still have the 4.1 code of the Windows libraries, could you> > > first try to build them with the new compiler and see if it makes> > > a difference if you link against them?> > >> > > It may also be worthwhile to compare the commands actually used> > > for linking (use -commands). That is, before we turn to the actual> > > generated code...> > >> > > I still haven't got Windows access here, so I can just suggest what> > > to do...> > >> > > Olaf> > > --> > > Olaf Wagner -- elego Software Solutions GmbH> > > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin,> > > Germany> > > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 Sun Jan 20 18:24:10 2008 From: jayk123 at hotmail.com (Jay) Date: Sun, 20 Jan 2008 17:24:10 +0000 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: References: <20080120110109.92CCC10D4628@birch.elegosoft.com> Message-ID: You guys REALLY don't like C, eh? It's not a hack, any more so than the tracing that was there, and the existing tracing could be not turned on until "much" later in startup, and the debuggers have no type information, even gdb and I think m3gdb just seem to have void* everywhere, true, I could just dump the memory. Either way. I have a contrary view, in that if something is particularly gnarly such that someone had to write printing code, someone might need it in the future, maybe better to leave it available. However, on the other hand..I write this sort of printing all the time and leaving it all in would really blow up the size of the code base, even while most stuff usually works. In this case, printing code has been left there all along, an entire module dedicated to reduce-depending printing. Making it work much better, drastically cutting the dependency, seems reasonable. Actually RTIO should probably be rewritten in C instead of lumping the logging into RTLinker. It is a hack in that respect. I found it kind of disturbing how much RTIO reinvents, integer formating, buffering... (and yes I realize I have both such features under my code in stdio) Anyway, I'm not wedded to it. I wish it were easier to interface C with Modula-3. The type declarations I had to clone should be output by the Modula-3 compiler, and the names I chose should be either the default or easier to get, since they are the names used for Modula-3 code... (I'm not going to jump for a fork. My CVS skills stink. I'll just leave the files uncommited.) - Jay > From: hosking at cs.purdue.edu> Date: Sun, 20 Jan 2008 12:02:32 -0500> To: jkrell at elego.de> CC: m3devel at elegosoft.com; m3commit at elegosoft.com> Subject: Re: [M3devel] [M3commit] CVS Update: cm3> > Jay,> > I am particularly disturbed by these changes you just committed > because of the nasty reliance they impose on C in this part of the > run-time library. Part of the beauty of M3 is that its compiler and > libraries are almost entirely programmed in Modula-3. Your change > here has been made to satisfy a need to debug a severely broken run- > time system. Better in such situations to use a standard debugger > rather than pollute the Modula-3 code with nasty reliance on C. If > you need to use such hacks in your debugging please do so in your > privately checked out working directories rather than imposing them > on the rest of us by checking into the main tree. If you need a > debugging source tree in which to play then there is ample provision > using CVS to fork a development branch that is off the main trunk. > Shall I undo these hacks or will you?> > It is important in a collaborative effort such as this to make sure > that we all play nicely in the shared CVS space. In this case I > think you have regressed the code base by adding these C-based hacks.> > Best,> > -- Tony> > On Jan 20, 2008, at 12:01 PM, Jay Krell wrote:> > > CVSROOT: /usr/cvs> > Changes by: jkrell at birch. 08/01/20 12:01:09> >> > Modified files:> > cm3/m3-libs/m3core/src/runtime/common/: RTLinker.i3 RTLinker.m3> > m3makefile> > Added files:> > cm3/m3-libs/m3core/src/runtime/common/: RTLinkerC.c> >> > Log message:> > allow RTLinker's tracing to work when things are more broken> > the default behavior is unchanged, and the behavior with > > @M3tracelinker> > is preserved> > a change in behavior requires modifying RTLinkerC.c and rebuilding> > this also enables more verbose tracing> _________________________________________________________________ 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 Sun Jan 20 18:52:38 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 20 Jan 2008 12:52:38 -0500 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: References: <20080120110109.92CCC10D4628@birch.elegosoft.com> Message-ID: On Jan 20, 2008, at 12:24 PM, Jay wrote: > You guys REALLY don't like C, eh? > It's not a hack, any more so than the tracing that was there, and > the existing tracing could be not turned on until "much" later in > startup, and the debuggers have no type information, even gdb and I > think m3gdb just seem to have void* everywhere, true, I could just > dump the memory. The debuggers do have most type information on POSIX platforms. It's not that I don't like C, just that your use of it here was a little gratuitous. For this sort of low-level debugging memory dumps are your friend -- if you want to read something a little more symbolic put in a temporary hack in your private space. Just don't make the rest of us swallow it. Jay, I'm not trying to be hypercritical, just trying to preserve some cleanliness in the core library code. Please keep up your great work! Best regards, Tony > > > Either way. > > I have a contrary view, in that if something is particularly gnarly > such that someone had to write printing code, someone might need it > in the future, maybe better to leave it available. However, on the > other hand..I write this sort of printing all the time and leaving > it all in would really blow up the size of the code base, even > while most stuff usually works. > In this case, printing code has been left there all along, an > entire module dedicated to reduce-depending printing. Making it > work much better, drastically cutting the dependency, seems > reasonable. Actually RTIO should probably be rewritten in C instead > of lumping the logging into RTLinker. It is a hack in that respect. > I found it kind of disturbing how much RTIO reinvents, integer > formating, buffering... (and yes I realize I have both such > features under my code in stdio) > > Anyway, I'm not wedded to it. > I wish it were easier to interface C with Modula-3. The type > declarations I had to clone should be output by the Modula-3 > compiler, and the names I chose should be either the default or > easier to get, since they are the names used for Modula-3 code... > > (I'm not going to jump for a fork. My CVS skills stink. I'll just > leave the files uncommited.) > > - Jay > > > > > > From: hosking at cs.purdue.edu > > Date: Sun, 20 Jan 2008 12:02:32 -0500 > > To: jkrell at elego.de > > CC: m3devel at elegosoft.com; m3commit at elegosoft.com > > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > > > Jay, > > > > I am particularly disturbed by these changes you just committed > > because of the nasty reliance they impose on C in this part of the > > run-time library. Part of the beauty of M3 is that its compiler and > > libraries are almost entirely programmed in Modula-3. Your change > > here has been made to satisfy a need to debug a severely broken run- > > time system. Better in such situations to use a standard debugger > > rather than pollute the Modula-3 code with nasty reliance on C. If > > you need to use such hacks in your debugging please do so in your > > privately checked out working directories rather than imposing them > > on the rest of us by checking into the main tree. If you need a > > debugging source tree in which to play then there is ample provision > > using CVS to fork a development branch that is off the main trunk. > > Shall I undo these hacks or will you? > > > > It is important in a collaborative effort such as this to make sure > > that we all play nicely in the shared CVS space. In this case I > > think you have regressed the code base by adding these C-based > hacks. > > > > Best, > > > > -- Tony > > > > On Jan 20, 2008, at 12:01 PM, Jay Krell wrote: > > > > > CVSROOT: /usr/cvs > > > Changes by: jkrell at birch. 08/01/20 12:01:09 > > > > > > Modified files: > > > cm3/m3-libs/m3core/src/runtime/common/: RTLinker.i3 RTLinker.m3 > > > m3makefile > > > Added files: > > > cm3/m3-libs/m3core/src/runtime/common/: RTLinkerC.c > > > > > > Log message: > > > allow RTLinker's tracing to work when things are more broken > > > the default behavior is unchanged, and the behavior with > > > @M3tracelinker > > > is preserved > > > a change in behavior requires modifying RTLinkerC.c and rebuilding > > > this also enables more verbose tracing > > > > > Need to know the score, the latest news, or you need your Hotmail?- > get your "fix". Check it out. From jayk123 at hotmail.com Sun Jan 20 19:13:08 2008 From: jayk123 at hotmail.com (Jay) Date: Sun, 20 Jan 2008 18:13:08 +0000 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: References: <20080120110109.92CCC10D4628@birch.elegosoft.com> Message-ID: Hey I almost have this figured out. I compared RTHeapInfo.ms's MM_RTHeapInfo PPC_DARWIN vs. NT386GNU. They are almost the same. Ok, anyway, I decided, duh, let's disassembly the garbage data and see if it is code. It is. That roughly matches the PPC_DARWIN vs. NT386GNU diff where some numbers were off by 4. Therefore: The module info is this: 0:000> dc 0068113800681138 00681138 00000000 00603de0 00681144 when it should be: 0:000> dc 0068113800681138 xxxxx 00603de0 00681144 Two problems. One clear, one less clear. TYPE (* one of these is generated for each imported interface reference *) ImportInfo = RECORD import : ModulePtr; binder : Binder; (* returns "import" pointer *) next : ImportPtr; END; 4 bytes of padding are between import and binder. Making binder be used for next. Making a pointer to code vs. a pointer to data mixed up. That's a big problem. I understand. What I don't understand is the value of import. I walked the whole list of imports and in every case, the back pointer to the module was actually to the import itself. Huh? Perhaps I went wrong earlier and am off in the weeds..but I don't think so. I mean, the pointers are to self in any case and that's seldom correct data, unless they are empty circular singly linked lists.. I'll dig a bit more.. - Jay full debugging session...email is going to remove the newlines and make it unreadable probably.. Module 0x681020 ..\src\runtime\common\RTHeapInfo.m3 Imports 0x6810c0{Import 0x0, Binder 0x0, Next 0x603d60} (f88.aec): Access violation - code c0000005 (first chance) First chance exceptions are reported before any exception handling. This exception may be expected and handled. eax=8be58955 ebx=00000001 ecx=611030e8 edx=00008889 esi=611021a0 edi=006147e0 eip=006006a0 esp=0022cb70 ebp=0022cba8 iopl=0 nv up ei ng nz na pe nc cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00010286 *** ERROR: Module load completed but symbols could not be loaded for image00400000 image00400000+0x2006a0: 006006a0 8b00 mov eax,dword ptr [eax] ds:0023:8be58955=???????? 0:000> dc 0x681020 00681020 00680fe0 00681054 00681154 00000000 ..h.T.h.T.h..... 00681030 00000000 00680f98 00000000 00680fdc ......h.......h. 00681040 00680fdc 006810c0 00000000 0060053f ..h...h.....?.`. 00681050 00000003 00000000 6c810e28 72d376bc ........(..l.v.r 00681060 1e527894 01000201 00000000 00000000 .xR............. 00681070 00000000 00681004 00000000 00000000 ......h......... 00681080 0068100c 00000000 e545939d 00000000 ..h.......E..... 00681090 00000000 00000000 00000000 00681008 ..............h. 0:000> dc 006810c0 006810c0 00000000 00000000 00603d60 006810cc ........`=`...h. 006810d0 00000000 005fb070 006810d8 00000000 ....p._...h..... 006810e0 005fb4a0 006810e4 00000000 005f1c00 .._...h......._. 006810f0 006810f0 00000000 005f58d0 006810fc ..h......X_...h. 00681100 00000000 00606500 00681108 00000000 .....e`...h..... 00681110 006064f0 00681114 00000000 005f8790 .d`...h......._. 00681120 00681120 00000000 00605350 0068112c .h.....PS`.,.h. 00681130 00000000 00606520 00681138 00000000 .... e`.8.h..... oops, code not data, let's try the next one 0:000> dc 00603d60 00603d60 8be58955 d0b80845 c900681a 909090c3 U...E....h...... 00603d70 8be58955 90b80845 c900681b e58955c3 U...E....h...U.. 00603d80 ec835657 08458b20 8904c083 1bf8a1c2 WV.. .E......... 00603d90 f4050068 8b000000 dc7d8d00 b8fcc689 h.........}..... 00603da0 00000007 a5f3c189 758dd789 07b8fcdc ...........u.... 00603db0 89000000 83a5f3c1 5f5e20c4 9090c3c9 ......... ^_.... 00603dc0 8be58955 70b80845 c900681c 909090c3 U...E..p.h...... 00603dd0 8be58955 10b80845 c900681d 909090c3 U...E....h...... 0:000> dc 006810cc 006810cc 006810cc 00000000 005fb070 006810d8 ..h.....p._...h. 006810dc 00000000 005fb4a0 006810e4 00000000 ......_...h..... 006810ec 005f1c00 006810f0 00000000 005f58d0 .._...h......X_. 006810fc 006810fc 00000000 00606500 00681108 ..h......e`...h. 0068110c 00000000 006064f0 00681114 00000000 .....d`...h..... 0068111c 005f8790 00681120 00000000 00605350 .._. .h.....PS`. 0068112c 0068112c 00000000 00606520 00681138 ,.h..... e`.8.h. 0068113c 00000000 00603de0 00681144 00000000 .....=`.D.h..... 0:000> dc 006810d8 006810d8 006810d8 00000000 005fb4a0 006810e4 ..h......._...h. 006810e8 00000000 005f1c00 006810f0 00000000 ......_...h..... 006810f8 005f58d0 006810fc 00000000 00606500 .X_...h......e`. 00681108 00681108 00000000 006064f0 00681114 ..h......d`...h. 00681118 00000000 005f8790 00681120 00000000 ......_. .h..... 00681128 00605350 0068112c 00000000 00606520 PS`.,.h..... e`. 00681138 00681138 00000000 00603de0 00681144 8.h......=`.D.h. 00681148 00000000 005dfc00 00000000 00680f00 ......].......h. oops, this is code not data 0:000> dc 005fb4a0 005fb4a0 8be58955 80b80845 c90067af 909090c3 U...E....g......005fb4b0 8be58955 40b80845 c90067b1 909090c3 U...E.. at .g......005fb4c0 83e58955 45c738ec 000000dc 08458b00 U....8.E......E.005fb4d0 8b04c083 d8458900 83d8458b 1d7f0ff8 ......E..E......005fb4e0 8308458b e8500cec 00011e94 8910c483 .E....P.........005fb4f0 458be045 cc4589e0 0000f9e9 d8458b00 E..E..E.......E.005fb500 500cec83 0000f2e8 10c48300 8be04589 ...P.........E..005fb510 4589e045 d8458bdc 8e0fc085 000000d0 E..E..E......... let's try the next one 0:000> dc 006810e4 006810e4 006810e4 00000000 005f1c00 006810f0 ..h......._...h.006810f4 00000000 005f58d0 006810fc 00000000 .....X_...h.....00681104 00606500 00681108 00000000 006064f0 .e`...h......d`.00681114 00681114 00000000 005f8790 00681120 ..h......._. .h.00681124 00000000 00605350 0068112c 00000000 ....PS`.,.h.....00681134 00606520 00681138 00000000 00603de0 e`.8.h......=`.00681144 00681144 00000000 005dfc00 00000000 D.h.......].....00681154 00680f00 00000000 6c810e28 00000002 ..h.....(..l.... 0:000> dc 006810e4 006810e4 006810e4 00000000 005f1c00 006810f0 ..h......._...h.006810f4 00000000 005f58d0 006810fc 00000000 .....X_...h.....00681104 00606500 00681108 00000000 006064f0 .e`...h......d`.00681114 00681114 00000000 005f8790 00681120 ..h......._. .h.00681124 00000000 00605350 0068112c 00000000 ....PS`.,.h.....00681134 00606520 00681138 00000000 00603de0 e`.8.h......=`.00681144 00681144 00000000 005dfc00 00000000 D.h.......].....00681154 00680f00 00000000 6c810e28 00000002 ..h.....(..l.... show it to be code btw (I did this earlier, not sure what happened in the log;I cannot represent byte patterns as x86 code by sight, but the disassembly is spot on) 0:000> u 005f1c00 image00400000+0x1f1c00:005f1c00 55 push ebp005f1c01 89e5 mov ebp,esp005f1c03 8b4508 mov eax,dword ptr [ebp+8]005f1c06 b8a0906700 mov eax,offset image00400000+0x2790a0 (006790a0)005f1c0b c9 leave005f1c0c c3 ret005f1c0d 90 nop005f1c0e 90 nop ok, so again let's try the next 0:000> dc 006810f0 006810f0 006810f0 00000000 005f58d0 006810fc ..h......X_...h.00681100 00000000 00606500 00681108 00000000 .....e`...h.....00681110 006064f0 00681114 00000000 005f8790 .d`...h......._.00681120 00681120 00000000 00605350 0068112c .h.....PS`.,.h.00681130 00000000 00606520 00681138 00000000 .... e`.8.h.....00681140 00603de0 00681144 00000000 005dfc00 .=`.D.h.......].00681150 00000000 00680f00 00000000 6c810e28 ......h.....(..l00681160 00000002 00000000 00000000 00000000 ................ 0:000> dc 006810fc 006810fc 006810fc 00000000 00606500 00681108 ..h......e`...h.0068110c 00000000 006064f0 00681114 00000000 .....d`...h.....0068111c 005f8790 00681120 00000000 00605350 .._. .h.....PS`.0068112c 0068112c 00000000 00606520 00681138 ,.h..... e`.8.h.0068113c 00000000 00603de0 00681144 00000000 .....=`.D.h.....0068114c 005dfc00 00000000 00680f00 00000000 ..].......h.....0068115c 6c810e28 00000002 00000000 00000000 (..l............0068116c 00000000 79545452 52536570 33495f43 ....RTTypeSRC_I3 0:000> dc 00681108 00681108 00681108 00000000 006064f0 00681114 ..h......d`...h.00681118 00000000 005f8790 00681120 00000000 ......_. .h.....00681128 00605350 0068112c 00000000 00606520 PS`.,.h..... e`.00681138 00681138 00000000 00603de0 00681144 8.h......=`.D.h.00681148 00000000 005dfc00 00000000 00680f00 ......].......h.00681158 00000000 6c810e28 00000002 00000000 ....(..l........00681168 00000000 00000000 79545452 52536570 ........RTTypeSR00681178 33495f43 00000000 00600750 00681170 C_I3....P.`.p.h. it just keeps going, a pretty good linked listEXCEPT for the padding and the first pointer always looks wrong 0:000> dc 00681114 00681114 00681114 00000000 005f8790 00681120 ..h......._. .h.00681124 00000000 00605350 0068112c 00000000 ....PS`.,.h.....00681134 00606520 00681138 00000000 00603de0 e`.8.h......=`.00681144 00681144 00000000 005dfc00 00000000 D.h.......].....00681154 00680f00 00000000 6c810e28 00000002 ..h.....(..l....00681164 00000000 00000000 00000000 79545452 ............RTTy00681174 52536570 33495f43 00000000 00600750 peSRC_I3....P.`.00681184 00681170 00000000 735c2e2e 725c6372 p.h.......\src\r 0:000> dc 00681120 00681120 00681120 00000000 00605350 0068112c .h.....PS`.,.h.00681130 00000000 00606520 00681138 00000000 .... e`.8.h.....00681140 00603de0 00681144 00000000 005dfc00 .=`.D.h.......].00681150 00000000 00680f00 00000000 6c810e28 ......h.....(..l00681160 00000002 00000000 00000000 00000000 ................00681170 79545452 52536570 33495f43 00000000 RTTypeSRC_I3....00681180 00600750 00681170 00000000 735c2e2e P.`.p.h.......\s00681190 725c6372 69746e75 635c656d 6f6d6d6f rc\runtime\commo 0:000> dc 0068112c 0068112c 0068112c 00000000 00606520 00681138 ,.h..... e`.8.h.0068113c 00000000 00603de0 00681144 00000000 .....=`.D.h.....0068114c 005dfc00 00000000 00680f00 00000000 ..].......h.....0068115c 6c810e28 00000002 00000000 00000000 (..l............0068116c 00000000 79545452 52536570 33495f43 ....RTTypeSRC_I30068117c 00000000 00600750 00681170 00000000 ....P.`.p.h.....0068118c 735c2e2e 725c6372 69746e75 635c656d ..\src\runtime\c0068119c 6f6d6d6f 54525c6e 65707954 2e435253 ommon\RTTypeSRC. 0:000> dc 00681138 00681138 00681138 00000000 00603de0 00681144 8.h......=`.D.h.00681148 00000000 005dfc00 00000000 00680f00 ......].......h.00681158 00000000 6c810e28 00000002 00000000 ....(..l........00681168 00000000 00000000 79545452 52536570 ........RTTypeSR00681178 33495f43 00000000 00600750 00681170 C_I3....P.`.p.h.00681188 00000000 735c2e2e 725c6372 69746e75 ......\src\runti00681198 635c656d 6f6d6d6f 54525c6e 65707954 me\common\RTType006811a8 2e435253 00003369 0068118c 00000000 SRC.i3....h..... 0:000> dc 00681144 00681144 00681144 00000000 005dfc00 00000000 D.h.......]..... 00681154 00680f00 00000000 6c810e28 00000002 ..h.....(..l.... 00681164 00000000 00000000 00000000 79545452 ............RTTy 00681174 52536570 33495f43 00000000 00600750 peSRC_I3....P.`. 00681184 00681170 00000000 735c2e2e 725c6372 p.h.......\src\r 00681194 69746e75 635c656d 6f6d6d6f 54525c6e untime\common\RT 006811a4 65707954 2e435253 00003369 0068118c TypeSRC.i3....h. 006811b4 00000000 00000000 00000000 00000000 ................ another confirmation of a code pointer 0:000> u 005dfc00 image00400000+0x1dfc00: 005dfc00 55 push ebp 005dfc01 89e5 mov ebp,esp 005dfc03 8b4508 mov eax,dword ptr [ebp+8] 005dfc06 b800516700 mov eax,offset image00400000+0x275100 (00675100) 005dfc0b c9 leave 005dfc0c c3 ret 005dfc0d 90 nop 005dfc0e 90 nop 0:000> This is the nice thing about command line debuggers, a textual log. _________________________________________________________________ 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 rcoleburn at scires.com Sun Jan 20 20:10:46 2008 From: rcoleburn at scires.com (Randy Coleburn) Date: Sun, 20 Jan 2008 14:10:46 -0500 Subject: [M3devel] pixmap problem In-Reply-To: <200801200341.m0K3feKM023564@camembert.async.caltech.edu> References: Your message of "Sat, 19 Jan 2008 17:54:00 +0100." <235688.77597.qm@web27110.mail.ukl.yahoo.com> <200801200341.m0K3feKM023564@camembert.async.caltech.edu> Message-ID: <47935664.1E75.00D7.1@scires.com> Mika / Daniel: Thanks for the test info! Well, based on what ya'll are reporting, I think the problem has to do with the NT386 platform. I also don't think it has to do necessarily with the source code. So, there must be something fishy going on in the NT386 world in the linkage step to cause this type of situation when switching between regular and buildstandalone(). Unfortunately, I'm probably not the right person to figure out what is wrong and fix it either. Hey, but at least I produced a short test program that reproduces the problem. Maybe Jay or someone can offer another suggestion on how to fix it. I do know for sure that the TestPixmap program does build and run correctly on cm3 v4.1 for both buildstandalone() and regular. So, there must be something that has changed since then to cause this behavior. Maybe there is some different argument set that needs to get passed to the linker. I don't know. Regards, Randy >>> Mika Nystrom 1/19/2008 10:41 PM >>> It works great on NT386GNU, PM3/Klagenfurt, as well, without the build_standalone. Mika "Daniel Alejandro Benavides D." writes: >--0-1095273535-1200761640=:77597 >Content-Type: text/plain; charset=iso-8859-1 >Content-Transfer-Encoding: 8bit > >Hi: >The TestPixmap does show a nice battery on LINUXLIBC6, Ubuntu Gutsy 2.6.22-14-386, 32 bits machine. > >Thanks > > >Jay wrote: .hmmessage P { margin:0px; padding:0px } body.hmmessage { FONT-SIZE: 10pt; FONT-FAMILY:Tahoma } I can repro > the two different behaviors on XP. > I was going to try on PPC_DARWIN but I guess Tony's info suffices. > > I tried rolling hand.c back to before I changed (months/year ago), since it is involved in bit twiddling, no change, phew. > > Debugging here is a big humungous pain. > NT386 has good stacks and line numbers, but no locals or type info, I'd really sometime like to get Codeview info into those .objs...I think it > is documented well enough, but still not necessarily easy, or maybe have a C generating backend partly for this reason (and to bring up more ta >rgets, using native tools), and function calls in disassembly I think don't resolve; NT386GNU can't yet build this, though it will soon, but I'm > not familiar with gdb and there appears to be no type info. I'm building m3gdb right now, I don't know if it will work, I hope it has type info >, and I'm not familiar with the relevant code. In gdb I struggle just to view bytes in memory, add numbers to addresses and see those, etc. I th >ink for MY problem, I'm going to link in C code to dump the structs. There is tracing code and I enabled it, but even it crashes in Text_Length. > At least MY problem crashes, hopefully near the problem, whereas your problem goes all the way through to completion with > no stopping to hint where the problem is. Darn it. :) on the mock rudeness and :( on the lack of a crash. > > You write the bundle out and it matches, so that doesn't rule out bundles as being the problem? (darn) > And bundles look pretty simple, a bundle is just a generated source file with a constant in it. > Maybe newline problems? That wouldn't make sense. I just downloaded some program that might let me separately view the ppm, maybe it'll reveal >something. > > The bad behavior has like regularly spaced solid color veritical bars a few pixels side across the whole picture, and regularly spaced vertical > stripes from the correct picture alternating with that. Perhaps someone with ppm/bitmap/graphics experience has seen this behavior and it resul >ts from some common pixmap mismanagement we could look for? > > I have to say this is very surprising. > > I always wondered, and now I pretty much assume -- Modula-3 never imports/exports data in its dynamic linking, right? It alway imports/exports >functions, right? > On Windows, functions have an optional optimization, but data must be handled differently at compile time if it is going to be dynamically impo >rted. > For functions, if you don't apply the optimization at compile time, the linker will just generate a single instruction thunk instead. > > That is, given a symbol Foo, there is a symbol __imp__Foo that is a pointer to the actual foo in another .dll/.so. > The loader only patches pointers, one per import if you build your .dll correctly, it doesn't patch instructions or code strewn throughout a .d >ll, just one contiguous array of pointers. MAYBE they don't have to be contiguous for each .dl you import from. > > That is, if call msvcrt!fopen, msvcrt!fclose, kernel32!Sleep, my .dll/.exe typically has an array: > > pointer to msvcrt!fopen > pointer to msvcrt!fclose > null > pointer to kernel32!Sleep > > But perhaps kernel32.dll's pointers and msvcrt.dll's pointers need not be adjacent. > > So, going back, my point/question is that, if the compiler knows the function is imported, it can call through __imp__Foo instead of calling Fo >o. > But if it calls Foo and you import Foo, the linker will create the function Foo that just jmps through __imp__Foo. > That doesn't work for data though. There's no ability to intervenve like that. > So for imported data, the compiler must generated a read and dereference of the pointer __imp__Foo for accesses to Foo, if Foo is to be importe >d. > Data imports may be faster when appropriate, but for this reason, I'd say they aren't worth it. > And for this reason, I HOPE Modula-3 never imports/exports data. > > Oh, you could, for data, always reference the pointer __imp_Foo, and if non materializes, create one. > However that would suck perf in order to make an uncommon case work. > I hope Modula-3 doesn't do that either. :) > Though I guess since this global data in question...maybe it is rare??? > > Later, > - Jay > > > >--------------------------------- > > > From: hosking at cs.purdue.edu >> Date: Sat, 19 Jan 2008 03:09:47 -0500 >> To: rcoleburn at scires.com >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] pixmap problem >> >> Looks fine to me on I386_DARWIN. >> >> On Jan 19, 2008, at 12:31 AM, Randy Coleburn wrote: >> >> > >> > > > >--------------------------------- >Need to know the score, the latest news, or you need your Hotmail*-get your "fix" Check it out. > > >--------------------------------- > >Web Revelaci*n Yahoo! 2007: > Premio Favorita del P*blico - ?Vota tu preferida! >--0-1095273535-1200761640=:77597 >Content-Type: text/html; charset=iso-8859-1 >Content-Transfer-Encoding: 8bit > >Hi:
The TestPixmap does show a nice battery on LINUXLIBC6, Ubuntu Gutsy 2.6.22-14-386, 32 bits machine.

Thanks


Jay &l >t;jayk123 at hotmail.com> wrote:
I can repro the two > different behaviors on XP.
I was going to try on PPC_DARWIN but I guess Tony's info suffices.
 
I tried rolling hand.c back to > before I changed (months/year ago), since it is involved in bit twiddling, no change, phew.
 
Debugging here is a big humungous&nb >sp;pain.
NT386 has good stacks and line numbers, but no locals or type info, I'd really sometime like to get Codeview info into those .objs. >..I think it is documented well enough, but still not necessarily easy, or maybe have a C generating backend partly for this > reason (and to bring up more targets, using native tools), and function calls in disassembly I think don't resolve; NT386GNU can't yet bui >ld this, though it will soon, but I'm not familiar with gdb and there appears to be no type info. I'm building m3gdb right now, I don't know if >it will work, I hope it has type info, and I'm not familiar with the relevant code. In gdb I struggle just to view bytes in memory, add numbers >to addresses and see those, etc. I think for MY problem, I'm going to link in C code to dump the structs. There is tracing code and I enabled it >, but even it crashes in Text_Length. At least MY problem crashes, hopefully near the problem, whereas your problem goes all the way through to >completion with no stopping to hint where the problem is. Darn it. :) on the mock rudeness and :( on the lack of a crash.
 
You wri >te the bundle out and it matches, so that doesn't rule out bundles as being the problem? (darn)
And bundles look pretty > simple, a bundle is just a generated source file with a constant in it.
Maybe newline problems? That wouldn't make sense. I just downl >oaded some program that might let me separately view the ppm, maybe it'll reveal something.
 
The bad behavior has like regularly s >paced solid color veritical bars a few pixels side across the whole picture, and regularly spaced vertical stripes from the correct picture alte >rnating with that. Perhaps someone with ppm/bitmap/graphics experience has seen this behavior and it results from some common pixmap mismanageme >nt we could look for?
 
I have to say this is very surprising.
 
I always wondered, and now I pretty much assume -- Mo >dula-3 never imports/exports data in its dynamic linking, right? It alway imports/exports functions, right?
On Windows, functions have an op >tional optimization, but data must be handled differently at compile time if it is going to be dynamically imported.
For > functions, if you don't apply the optimization at compile time, the linker will just generate a single instruction thunk instead.
 
> That is, given a symbol Foo, there is a symbol __imp__Foo that is a pointer to the actual foo in another .dll/.so.
Th >e loader only patches pointers, one per import if you build your .dll correctly, it doesn't patch instructions or code strewn throughout a >.dll, just one contiguous array of pointers. MAYBE they don't have to be contiguous for each .dl you import from.
 
That is, if cal >l msvcrt!fopen, msvcrt!fclose, kernel32!Sleep, my .dll/.exe typically has an array:
 
pointer to msvcrt!fopen
pointer to msvcrt >!fclose
null
pointer to kernel32!Sleep
 
But perhaps kernel32.dll's pointers and msvcrt.dll's pointers need not be adjacent >.
 
So, going back, my point/question is that, if the compiler knows the function is imported, it can call > through __imp__Foo instead of calling Foo.
But if it calls Foo and you import Foo, the linker will create the function Foo that just jmps t >hrough __imp__Foo.
That doesn't work for data though. There's no ability to intervenve like that.
So for imported data, the compiler mus >t generated a read and dereference of the pointer __imp__Foo for accesses to Foo, if Foo is to be imported.
Data import >s may be faster when appropriate, but for this reason, I'd say they aren't worth it.
And for this reason, I HOPE Modula-3 never imports/expo >rts data.
 
Oh, you could, for data, always reference the pointer __imp_Foo, and if non materializes, create one.
However that >would suck perf in order to make an uncommon case work.
I hope Modula-3 doesn't do that either. :)
Though I guess since this global data > in question...maybe it is rare???
 
Later,
 - Jay



> From: > hosking at cs.purdue.edu
> Date: Sat, 19 Jan 2008 03:09:47 -0500
> To: rcoleburn at scires.com
> CC: m3devel at elegosoft.com
> >Subject: Re: [M3devel] pixmap problem
>
> Looks fine to me on I386_DARWIN.
>
> On Jan 19, 2008, at 12:31 AM, Randy Col >eburn wrote:
>
> > <TestPixmap.zip>
>


Need to know the score, the latest news, or you need your Hotm >ail*-get your "fix" Check it out.

> > >


Web Revelaci*n Yahoo! 2007:
Premio Favorita del P*blico - ?Vota tu preferida! >--0-1095273535-1200761640=:77597-- -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcoleburn at scires.com Sun Jan 20 20:12:45 2008 From: rcoleburn at scires.com (Randy Coleburn) Date: Sun, 20 Jan 2008 14:12:45 -0500 Subject: [M3devel] my status on win32 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> <477EA137.1E75.00D7.1@scires.com> <478D394B.1E75.00D7.1@scires.com> <478D47FB.1E75.00D7.1@scires.com> <478DBF8D.1E75.00D7.1@scires.com> <478DE973.1E75.00D7.1@scires.com> <47908659.1E75.00D7.1@scires.com> <20080119204810.3wmumqgms88sccw4@mail.elegosoft.com> <479267C2.1E75.00D7.1@scires.com><479267C2.1E75.00D7.1@scires.com> Message-ID: <479356DB.1E75.00D7.1@scires.com> "mapped" is probably a poor choice of words here. Sorry. --Randy >>> Jay 1/19/2008 11:27 PM >>> What does "mapped" mean here? The way it works, on Modula-3 NT386, and I haven't seen this done quite this way ever on Win32, not so systematically/mechanically/automatically, and I don't know how Posixish systems work here, but the way it works is that for every .dll, CM3 NT386 builds foo.lib and foo.lib.sa. foo.lib is an "import lib", just containing essentially function names and a file name. foo.lib.sa is a regular old static .lib, sa for standalone. You can also just build a static .lib -- for stuff that is never a .dll, for stuff that is only used once, but is broken up into multiple directories. For example m3quake, m3middle, m3objfile, m3back, etc. They are only used by cm3 so are just static .libs, just foo.lib, are built. (If we fix cm3.exe to be copy over itself, and I have some new clever ideas here, it might be profitable, for "developer productivity", to turn these into .dlls -- just so I can cd around and rebuild/reship less.) When you ask to build a standalone executable, we have a list of .libs, foo.lib, bar.lib. They are full paths. For each one, we see if foo.lib.sa exists, and if so, we use that instead of foo.lib. It is all rather simple and clever, but at least to me, it was surprising and new, so I explain it here. Perhaps Posixish systems work very similarly and this is old hat? I know cm3 doesn't implement this for Posix, but ar/ld/gcc could be handling things this way underneath for it. For example, I know on Mac OS X, if you link to a full path to a file, that's what you get. But if you say -Ldirectory -lfoo, ld probes for directory/foo.dylib and then directory/foo.a. So modulo the extensions and unknown to me how you build the things in the first place, same thing. You have to be sure to use the setting to split lib paths like that, otherwise you break dynamic linking. CM3 makes foo.sa.lib with its own mklib. This is also unusual. Normally one would use lib.exe or link.exe /lib for this, or ar/ld/gcc/dlltools. But the CM3 folks were obviously, openly en route to cutting dependencies through reimplementation. I had some initial trouble on NT385GNU building static .libs with ar/ld/gcc/dlltool, so, heck, I just do what NT386 does, and it seems to be working (modulo that SOMETHING is not working :) ). I don't want to stop anyone else from debugging this but if nobody else figures it out I will try. I can repro it easily, thanks for the good repro Randy! (though I wish it would crash instead of mis-display :) ) There is no "vendor's equivalent library" here, it is all just Modula-3 foo.lib or foo.lib.sa. Look at NT386/*.txt, by the .exe. Build one way. Rename away NT386. Build the other way. Compare the directories. You will see what I am talking about. - Jay Date: Sat, 19 Jan 2008 21:12:37 -0500 From: rcoleburn at scires.com To: hosking at cs.purdue.edu; wagner at elegosoft.com CC: m3devel at elegosoft.com Subject: Re: [M3devel] my status on win32 Hi Tony: Are you suggesting that when the program is built standalone it maps libraries differently? I know there is a difference between dynamic vs. static libraries, but are you suggesting that a different library is being mapped than the vendor's equivalent of the dynamic library? How would I check for this situation? Your suggestion seems plausible since the source is not recompiled; instead, the linker is used to change the way the EXE is put together and that seems to cause the difference in operation as far as pixmaps are concerned. Regards, Randy >>> Tony Hosking 1/19/2008 6:47 PM >>> I would perhaps suspect a bad library mapping. On Jan 19, 2008, at 2:48 PM, Olaf Wagner wrote: > Quoting Randy Coleburn : >> 1. pixmaps aren't rendered properly on the screen. They look really >> bad. I recall having this problem a while back with one of the early >> 5.x releases, so I guess it was never solved. I've got some old test >> programs I try to dig out and see if I can find out what is going >> on. I >> seem to recall that building standalone in the past seemed to fix the >> problem, so this is a real mystery. > > Hi Randy, > > I'm afraid I wasn't able to solve it directly some years ago and > then forgot about it due to more urgent tasks. > > I think we should try to narrow down the location of the problem > (i.e. is it in the runtime, code generation, linker, or windows > libraries). > > As you still have the 4.1 code of the Windows libraries, could you > first try to build them with the new compiler and see if it makes > a difference if you link against them? > > It may also be worthwhile to compare the commands actually used > for linking (use -commands). That is, before we turn to the actual > generated code... > > I still haven't got Windows access here, so I can just suggest what > to do... > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, > Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 > 45 86 95 > http://www.elegosoft.com ( http://www.elegosoft.com/ ) | Gesch?ftsf?hrer: Olaf Wagner | Sitz: > Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > DE163214194 > Helping your favorite cause is as easy as instant messaging. You IM, we give. Learn more. ( http://im.live.com/Messenger/IM/Home/?source=text_hotmail_join ) -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Sun Jan 20 20:48:31 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Sun, 20 Jan 2008 20:48:31 +0100 Subject: [M3devel] pixmap problem In-Reply-To: <47935664.1E75.00D7.1@scires.com> References: Your message of "Sat, 19 Jan 2008 17:54:00 +0100." <235688.77597.qm@web27110.mail.ukl.yahoo.com> <200801200341.m0K3feKM023564@camembert.async.caltech.edu> <47935664.1E75.00D7.1@scires.com> Message-ID: <20080120204831.81poj3gg0084o0g0@mail.elegosoft.com> Quoting Randy Coleburn : > Mika / Daniel: Thanks for the test info! > > Well, based on what ya'll are reporting, I think the problem has to do > with the NT386 platform. I also don't think it has to do necessarily > with the source code. So, there must be something fishy going on in the > NT386 world in the linkage step to cause this type of situation when > switching between regular and buildstandalone(). I must have missed that, browsing the lots of mails on this list recently ;-) > Unfortunately, I'm probably not the right person to figure out what is > wrong and fix it either. Hey, but at least I produced a short test > program that reproduces the problem. This is often the more difficult part. > Maybe Jay or someone can offer another suggestion on how to fix it. I think Jay is the well capable of finding out what's going wrong there. Let's wait for him. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Sun Jan 20 21:41:23 2008 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Sun, 20 Jan 2008 21:41:23 +0100 (CET) Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: Message-ID: <862972.55026.qm@web27105.mail.ukl.yahoo.com> Hi: I think for all the users that maybe NT386GNU is more thought like NT386cygwin, but if we see that GNU tools are used in projects like Mingw, that is a fork of cygwin and with the aim of programs running without the dependency on cygwin dll, that maybe guide us to say that the "old target" NT386GNU should be run with a cygwin enviroment. The NT386_MINGW seems to be a nice name/description for the platform which no depends on cygwin.dll but a MinGW/MSYS enviroment. Certainly I think the gnu toolchain is highly used by both the projects, and as I remember, when installing gcc on cygwin it also offers the mingw tool set to the cygwin enviroment to be installed. So let's say that projects are very related and cooperative, but are not the same. So Jay, m3cc could be built on a cygwin enviroment and m3gdb? If so, we can think in those two separeted platforms? although cooperative for m3 developers. I would like to see m3-lectern packages running on NT386GNU using the filesystem /dev, which is something that I wouldn't expect to be on the proposed NT386_MINGW platform. Thanks Jay wrote: .hmmessage P { margin:0px; padding:0px } body.hmmessage { FONT-SIZE: 10pt; FONT-FAMILY:Tahoma } > the infrastructure. So I'd rather vote that only new targets get > more systematic names. Of course, though the existing names suggest new names, and not clear the value of the existing NT386GNU. Ie. is there a benefit to keep it in use with some meaning or not? Cygwin does have a larger jmpbuf than msvcr*.dll/mingwin. I think it holds sigaction state besides register state. "NT" and "Win" seem redundant. I386_MINGWIN? I386_CYGWIN? NT386_GNU? NT386_MINGNU? Ok, I admit that NT386_CYGWIN NT386_MINGWIN despite the redundancy, clearly point to existing projects that probably have name recognition. And building from NT386 is reasonable -- as was I saying about existing names influencing new names. A C generating backend gets you perhaps easier retargeting as well. I do see there is "MINGWIN64" out there, for AMD64. Not sure what the state of IA64 is though... (See -- you should avoid saying "32" or "64" in stuff, Win32 => Win, Win64 => Win.) I also would agree that creating one target instead of two is probably a good idea -- seems easier. I am not sure if current state is relevant. I mean, is NT386GNU really working and in use anywhere? Is PM3 in use? If so, then matching their meaning would be good. Or even going beyond that -- to Trestle on X Windows. :) (Though CygwinX doesn't exactly appear active.) And thus the precedent for no underscore. NT386MINGWIN ? NT386MINGNU ? I don't know if "MSYS" needs a place in this name. It is needed for building m3cc. I wonder if a hybrid/adaptive approach will be desired -- if Cygwin is available, the MinGWin target could use it to build m3gdb, since it can't otherwise. Hint for anyone trying out Cygwin and getting an odd mix of paths: mkdir \cygdrive get junction.exe from the former www.sysinternals.com junction \cygdrive\c c:\ now when some Cygwin code passes /cygdrive/c to Win32 code, it will just work, no translation needed. If you have multiple drives, I guess just fully populate each one c:\cygdrive\c => c:\ c:\cygdrive\d => d:\ d:\cygdrive\c => c:\ d:\cygdrive\d => d:\ etc. but I haven't tried that. Or, to reduce the multiplication, set them all up on c: and have d:\cygdrive => c:\cygdrive, e:\cygdrive => c:\cygdrive, etc. - Jay --------------------------------- > Date: Sun, 20 Jan 2008 15:56:49 +0100 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > Quoting Jay : > > > Good, a happy customer. :) > > > >> GNU_MODE = 0 % Do not use GNU tools at all -- today's NT386 > >> GNU_MODE = 1 % Use GNU tools minimally -- today's NT386GNU > >> GNU_MODE = 2 % Use GNU tools maximally -- not existant but probably > >> easy > >> > >> Eh..I know, not great.. what do "minimally" and "maximally" mean. > > > > I'm still fishing for anyone to provide answers to these > > less important decisions that I have trouble with. > > Otherwise maybe no NT Cygwin system. > > > > TARGETs = { NT386, NT386GNU, NT386CYGWIN }? > > TARGETs = { NT386, NT386MINGWIN, NT386CYGWIN }? > > TARGETs = { NT386 + GNU_MODE }? > > > > The one reason I don't favor NT386 + GNU_MODE is that Cygwin has a > > much larger jmpbuf than the others. > > I think same TARGET implies code can be linked together, and I think > > varying jmpbuf implies otherwise. > > So NT386 and NT386MINGWIN should rarely cross paths with NT386CYGWIN. > > I think a new target is called for if I have understood everything right. > We need one pure native target (NT386), one pure-Cygwin-based target > (NT386_CYGWIN?) and one mix of runtime, gnu tools and mingwin > (NT386_MINGWIN?). > > As NT386GNU already exists, we must decide if we want to use it as > we traditionally did (all Cygwin) or the mixed implementation > (Mingwin and much Windows RT). > > > I also do NOT like this ad-hoc naming style. > > PPC_DARWIN, I386_DARWIN are much more to my style. > > The names should be somehow hierarchical, except, I realize, there > > isn't necessarily one "path" of > > stuff which to name platforms, though the GNU folks have settled on > > a way or two. > > They have triples or quadruples -- processor-hardware-os or such, > > however this doesn't > > clearly suffice. > > Well, yes, something more systematic would have been better, but > to break with the history will cause much trouble for all users and > the infrastructure. So I'd rather vote that only new targets get > more systematic names. > > > Something that accomodates: > > NT386 + LLVM > > NT386 + Watcom, linker and/or backend and/or runtime > > NT386 + Digital Mars linker and/or backend and/or runtime > > A C generating backend, and then linker/runtime > > and similar IA64, AMD64 variants would be good. > > I'm not sure that a C generating backend would really help matters. > This was done in the first implementation of DEC, and they soon > abandoned it as C had proven to be a bad choice as intermediate language. > I agree it would be great for cross-compilation etc. > > As far as C and RT dependencies of native Windows compilers go, I don't > see why this couldn't be just a question of another cm3.cfg setup. > > > To a large extent, these can be few platforms, subject to > > configuration, like if all > > the linkers consume a common file format (not clear), and if all the > > jmpbufs are the same > > size (known to be partly true, partly false). > > Yes, jmpbuf is always a problem for user threads and exceptions. > On Unix systems the jmpbuf and other important low-level structures > are always defined by the system headers and independent of compilers > AFAIK, so I'm a bit surprised that it should be different on Windows. > But maybe I'm just wrong and haven't just seen the right counter > examples... > > > Oh and another thing, the runtime dependency is very likely cuttable, however > > PRESUMABLY real world applications (if there are any) link in a > > substantial amount of > > C or C++, in which case, it isn't necessarily cuttable. > > Yes. Real world applications tend to link other libraries (C, C++, > Fortran, ...) and even often call other applications like sh etc. > > > As well, if I can figure out a good way to do it, switching NT386 > > from awful slow > > frequent TlsGetValue/TlsSetValue to manipulating the linked list in > > fs:0, that would be nice, > > and might incur a C runtime dependency, but well worth it. The way > > Modula-3 works here > > is terrible. Another compromise option is probably > > __declspec(thread), though there is trickiness there > > in terms of being in a .dll that isn't used by the .exe. > > Such optimizations should be done depending on the target. > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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! --------------------------------- Web Revelaci?n Yahoo! 2007: Premio Favorita del P?blico - ?Vota tu preferida! -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Sun Jan 20 22:03:12 2008 From: jayk123 at hotmail.com (Jay) Date: Sun, 20 Jan 2008 21:03:12 +0000 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <862972.55026.qm@web27105.mail.ukl.yahoo.com> References: <862972.55026.qm@web27105.mail.ukl.yahoo.com> Message-ID: Daniel, yes it's true cygwin has like -mno-cygwin or something. I will have to try that.Currently msys is required to build m3cc and cygwin is required to build m3gdb. m3gdb didn't have any type information anyway, so if you install cygwin, you can just use its gdb. (Note that cygwin is highly modular/package-based, so you can pick and chose what you install, there are many many many choices, so you don't automatically get gdb, you don't automatically even get gcc or ld/binutils.) Otherwise just MinGWin is required. Cygwin might just work. I'll try it before much longer. Is someone going to go ahead and create a new target? I guess I'm about able to. I think I finally fixed the major crash so can..take a break and then continue. Wow that was tedious. Once I can get a MinGWin distribution, I want to look at the pixmap bug, before looking into this new target.. Maybe someone will beat me to it though? /dev does not appear in Cygwin, at least not with cd and ls on my system. I expect /dev/null will work. I do have a very limited installed of Cygwin now, as I was trying to understand roughly what is needed. I don't know what to expect from /dev in Cygwin. You might be asking for too much. $ ls /dev/null/dev/null Jay at jay-win1 /$ ls /proc1312 cpuinfo meminfo registry stat version3936 loadavg partitions self uptime Jay at jay-win1 /$ ls /devls: cannot access /dev: No such file or directory $ ls /dev/tty/dev/tty $ ls /dev/conls: cannot access /dev/con: No such file or directory Jay at jay-win1 /$ ls /dev/fd0/dev/fd0 Jay at jay-win1 /$ ls /dev/fd*ls: cannot access /dev/fd*: No such file or directory Jay at jay-win1 /$ ls /dev/hd0ls: cannot access /dev/hd0: No such file or directory Jay at jay-win1 /$ ls /dev/sc*ls: cannot access /dev/sc*: No such file or directory I'm not sure what all to guess here. fd0 appears but I don't have a floppy disk. $ cat /proc/uptime41101.28 32423.71 Jay at jay-win1 /$ cat /proc/versionCYGWIN_NT-5.1 1.5.25(0.156/4/2) 2007-12-14 19:21 I'm inclined not to make any cygwin binary distributions until further reading of the license... There's still the X Windows vs. Win32 question... - Jay Date: Sun, 20 Jan 2008 21:41:23 +0100From: dabenavidesd at yahoo.esSubject: Re: [M3devel] [M3commit] CVS Update: cm3To: jayk123 at hotmail.com; wagner at elegosoft.com; m3devel at elegosoft.comHi:I think for all the users that maybe NT386GNU is more thought like NT386cygwin, but if we see that GNU tools are used in projects like Mingw, that is a fork of cygwin and with the aim of programs running without the dependency on cygwin dll, that maybe guide us to say that the "old target" NT386GNU should be run with a cygwin enviroment.The NT386_MINGW seems to be a nice name/description for the platform which no depends on cygwin.dll but a MinGW/MSYS enviroment.Certainly I think the gnu toolchain is highly used by both the projects, and as I remember, when installing gcc on cygwin it also offers the mingw tool set to the cygwin enviroment to be installed. So let's say that projects are very related and cooperative, but are not the same.So Jay, m3cc could be built on a cygwin enviroment and m3gdb?If so, we can think in those two separeted platforms? although cooperative for m3 developers.I would like to see m3-lectern packages running on NT386GNU using the filesystem /dev, which is something that I wouldn't expect to be on the proposed NT386_MINGW platform.ThanksJay wrote: > the infrastructure. So I'd rather vote that only new targets get> more systematic names.Of course, though the existing names suggest new names, andnot clear the value of the existing NT386GNU. Ie. is there a benefitto keep it in use with some meaning or not? Cygwin does have a larger jmpbuf than msvcr*.dll/mingwin.I think it holds sigaction state besides register state. "NT" and "Win" seem redundant. I386_MINGWIN? I386_CYGWIN? NT386_GNU? NT386_MINGNU? Ok, I admit that NT386_CYGWIN NT386_MINGWIN despite the redundancy, clearly point to existing projects that probably have name recognition.And building from NT386 is reasonable -- as was I saying about existing names influencing new names. A C generating backend gets you perhaps easier retargeting as well.I do see there is "MINGWIN64" out there, for AMD64.Not sure what the state of IA64 is though...(See -- you should avoid saying "32" or "64" in stuff, Win32 => Win, Win64 => Win.) I also would agree that creating one target instead of two is probably a good idea -- seems easier. I am not sure if current state is relevant. I mean, is NT386GNU really working and in use anywhere? Is PM3 in use?If so, then matching their meaning would be good. Or even going beyond that -- to Trestle on X Windows. :) (Though CygwinX doesn't exactly appear active.) And thus the precedent for no underscore.NT386MINGWIN ?NT386MINGNU ? I don't know if "MSYS" needs a place in this name.It is needed for building m3cc. I wonder if a hybrid/adaptive approach will be desired -- if Cygwin is available, the MinGWin target could use it to build m3gdb, since it can't otherwise. Hint for anyone trying out Cygwin and getting an odd mix of paths:mkdir \cygdriveget junction.exe from the former www.sysinternals.comjunction \cygdrive\c c:\now when some Cygwin code passes /cygdrive/c to Win32 code, it will just work, no translation needed.If you have multiple drives, I guess just fully populate each onec:\cygdrive\c => c:\c:\cygdrive\d => d:\d:\cygdrive\c => c:\d:\cygdrive\d => d:\ etc. but I haven't tried that.Or, to reduce the multiplication, set them all up on c: and have d:\cygdrive => c:\cygdrive, e:\cygdrive => c:\cygdrive, etc. - Jay > Date: Sun, 20 Jan 2008 15:56:49 +0100> From: wagner at elegosoft.com> To: m3devel at elegosoft.com> Subject: Re: [M3devel] [M3commit] CVS Update: cm3> > Quoting Jay :> > > Good, a happy customer. :)> >> >> GNU_MODE = 0 % Do not use GNU tools at all -- today's NT386> >> GNU_MODE = 1 % Use GNU tools minimally -- today's NT386GNU> >> GNU_MODE = 2 % Use GNU tools maximally -- not existant but probably> >> easy> >>> >> Eh..I know, not great.. what do "minimally" and "maximally" mean.> >> > I'm still fishing for anyone to provide answers to these> > less important decisions that I have trouble with.> > Otherwise maybe no NT Cygwin system.> >> > TARGETs = { NT386, NT386GNU, NT386CYGWIN }?> > TARGETs = { NT386, NT386MINGWIN, NT386CYGWIN }?> > TARGETs = { NT386 + GNU_MODE }?> >> > The one reason I don't favor NT386 + GNU_MODE is that Cygwin has a > > much larger jmpbuf than the others.> > I think same TARGET implies code can be linked together, and I think > > varying jmpbuf implies otherwise.> > So NT386 and NT386MINGWIN should rarely cross paths with NT386CYGWIN.> > I think a new target is called for if I have understood everything right.> We need one pure native target (NT386), one pure-Cygwin-based target> (NT386_CYGWIN?) and one mix of runtime, gnu tools and mingwin> (NT386_MINGWIN?).> > As NT386GNU already exists, we must decide if we want to use it as> we traditionally did (all Cygwin) or the mixed implementation> (Mingwin and much Windows RT).> > > I also do NOT like this ad-hoc naming style.> > PPC_DARWIN, I386_DARWIN are much more to my style.> > The names should be somehow hierarchical, except, I realize, there > > isn't necessarily one "path" of> > stuff which to name platforms, though the GNU folks have settled on > > a way or two.> > They have triples or quadruples -- processor-hardware-os or such, > > however this doesn't> > clearly suffice.> > Well, yes, something more systematic would have been better, but> to break with the history will cause much trouble for all users and> the infrastructure. So I'd rather vote that only new targets get> more systematic names.> > > Something that accomodates:> > NT386 + LLVM> > NT386 + Watcom, linker and/or backend and/or runtime> > NT386 + Digital Mars linker and/or backend and/or runtime> > A C generating backend, and then linker/runtime> > and similar IA64, AMD64 variants would be good.> > I'm not sure that a C generating backend would really help matters.> This was done in the first implementation of DEC, and they soon> abandoned it as C had proven to be a bad choice as intermediate language.> I agree it would be great for cross-compilation etc.> > As far as C and RT dependencies of native Windows compilers go, I don't> see why this couldn't be just a question of another cm3.cfg setup.> > > To a large extent, these can be few platforms, subject to > > configuration, like if all> > the linkers consume a common file format (not clear), and if all the > > jmpbufs are the same> > size (known to be partly true, partly false).> > Yes, jmpbuf is always a problem for user threads and exceptions.> On Unix systems the jmpbuf and other important low-level structures> are always defined by the system headers and independent of compilers> AFAIK, so I'm a bit surprised that it should be different on Windows.> But maybe I'm just wrong and haven't just seen the right counter> examples...> > > Oh and another thing, the runtime dependency is very likely cuttable, however> > PRESUMABLY real world applications (if there are any) link in a > > substantial amount of> > C or C++, in which case, it isn't necessarily cuttable.> > Yes. Real world applications tend to link other libraries (C, C++,> Fortran, ...) and even often call other applications like sh etc.> > > As well, if I can figure out a good way to do it, switching NT386 > > from awful slow> > frequent TlsGetValue/TlsSetValue to manipulating the linked list in > > fs:0, that would be nice,> > and might incur a C runtime dependency, but well worth it. The way > > Modula-3 works here> > is terrible. Another compromise option is probably > > __declspec(thread), though there is trickiness there> > in terms of being in a .dll that isn't used by the .exe.> > Such optimizations should be done depending on the target.> > Olaf> -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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! Web Revelaci?n Yahoo! 2007:Premio Favorita del P?blico - ?Vota tu preferida! _________________________________________________________________ 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 Jan 20 22:09:42 2008 From: jayk123 at hotmail.com (Jay) Date: Sun, 20 Jan 2008 21:09:42 +0000 Subject: [M3devel] cygwin users? In-Reply-To: <862972.55026.qm@web27105.mail.ukl.yahoo.com> References: <862972.55026.qm@web27105.mail.ukl.yahoo.com> Message-ID: Does anyone who is asking for Cygwin support actually use it? Or you are all just Unix users? (And MinGW users either?) I mean, are we hearing what people want and will use, or just what ought to exist in some ideal world? - 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 wagner at elegosoft.com Sun Jan 20 22:18:32 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Sun, 20 Jan 2008 22:18:32 +0100 Subject: [M3devel] Open CM3 regression tests Message-ID: <20080120211832.GA26993@elegosoft.com> Hi again everybody, I got a little bit side-tracked during recent days while trying to set up a sensible interface for test status reporting by the poor state of the CM3 WWW presentation. So I tried to improve the presentation and structure of the site. It's still all simple hand-crafted HTML and nothing very fancy, though I think it looks better now than before. Let me know what you think. And I know, the colours will be the most interesting discussion topic ;-) But back to more important issues. There are still a number of problems in the CM3 compiler regression tests that I'd like to discuss and close: either adapt the test, fix the compiler, or document the issue as intended or erroneous behaviour of CM3. Though I've thrown in some names here and there, nobody should hesitate to voice his opinion. Here's the extract of the test run log: CM3_TARGET=FreeBSD4 BINDISTMIN=/home/wagner/cm3-min-POSIX-FreeBSD4-5.4.0.tgz === 2008-01-19 23:43:24 run cm3 compiler and runtime regression test suite in /home/wagner/work/cm3-ws/luthien-2008-01-19-02-30-01 with lastok version Critical Mass Modula-3 version d5.5.1 last updated: 2007-12-30 compiled: 2008-01-19 17:27:13 configuration: /home/wagner/work/cm3-inst/luthien/current/bin/cm3.cfg --- building in FreeBSD4 --- > no errors for p1 to p115 --- p116b --- default IEEE floating point tests from Xerox PARC --- p1/p116b/stderr.pgm 2008-01-20 00:47:20.000000000 +0100 +++ ../src/p1/p116b/stderr.pgm 2008-01-13 00:55:55.000000000 +0100 @@ -17,7 +17,7 @@ Class (MaxFinite*ten) test OK Finite (MaxFinite*ten) test OK IsNaN (MaxFinite*ten) test OK -** Class (zero/zero) test not OK: FALSE should be TRUE + Class (zero/zero) test OK Finite (zero/zero) test OK IsNaN (zero/zero) test OK Sign (zero) test OK @@ -58,7 +58,7 @@ Class MaxFinite*ten test OK Finite MaxFinite*ten test OK IsNaN MaxFinite*ten test OK -** Class zero/zero test not OK: FALSE should be TRUE + Class zero/zero test OK Finite zero/zero test OK IsNaN zero/zero test OK Sign (zero) test OK > Some arithmetic problems. Perhaps Henning Thielemann could have > a look at this? --- p117 --- SUBARRAY (LOOPHOLE) OK again --- p155 --- operations on small sets --- p1/p155/stderr.pgm 2008-01-20 00:48:16.000000000 +0100 +++ ../src/p1/p155/stderr.pgm 2008-01-13 00:55:56.000000000 +0100 @@ -2,7 +2,6 @@ check set q = {} check set r = {a, b} check set x = {a, b, e} -************************ ERROR: check (NOT (p >= x)) failed > This concerns the >= operation on sets. The language definition > says: > > infix <=, >= (x,y: Ordinal) : BOOLEAN > (x,y: Float) : BOOLEAN > (x,y: ADDRESS) : BOOLEAN > (x,y: Set) : BOOLEAN > > In the first three cases, <= returns TRUE if x is at most as large as > y. In the last case, <= returns TRUE if every element of x is an > element of y. In all cases, it is a static error if the type of x is > not assignable to the type of y, or vice versa. The expression x >= y > is equivalent to y <= x. > > So the implementation seems to be plainly wrong. I think the test > for the previous operation <= only succeeds accidentally. --- p156 --- operations on medium-sized sets > OK > until --- p172 --- REAL vs. C's float --- p1/p172/stdout.pgm 2008-01-20 00:49:10.000000000 +0100 +++ ../src/p1/p172/stdout.pgm 2003-03-08 23:36:48.000000000 +0100 @@ -0,0 +1 @@ +23 23 --- p1/p172/stderr.pgm 2008-01-20 00:49:10.000000000 +0100 +++ ../src/p1/p172/stderr.pgm 2003-03-08 23:36:48.000000000 +0100 @@ -1,5 +1,3 @@ -23.4 23 -************************ ERROR: 23.4 instead of 23 > result too exact? > Perhaps Henning again? And Tony? --- p173 --- LONGREAL vs. C's double > OK again until --- p185 --- REAL vs. C float --- p1/p185/stderr.pgm 2008-01-20 00:49:32.000000000 +0100 +++ ../src/p1/p185/stderr.pgm 2003-03-08 23:36:50.000000000 +0100 @@ -1,4 +1,3 @@ -************************ ERROR: 53 instead of 24 > This is another effect of the precision problem. Expression evaluation > seems always to be done with 53 bits of precision (double), and never > with pure reals (23 bits). I assume it will be the same for C on > all PC hardware at least. Should we consider this to be an error or > just document the behaviour? > > I assume it cannot easily be changed, can it? --- p186 --- case statement with large labels > Just some output differences; I seem to have switched core dumps > off in one environment... > > So we can probably ignore these ones. --- r0/r001/stdout.build 2008-01-20 00:50:07.000000000 +0100 +++ ../src/r0/r001/stdout.build 2008-01-13 00:55:57.000000000 +0100 @@ -1,3 +1,3 @@ "../src/Main.m3", line 13: warning: potentially unhandled exception: Main.a 1 warning encountered -Abort trap (core dumped) +Abort trap --- r002 --- stack overflow in the main thread --- r0/r002/stdout.build 2008-01-20 00:50:09.000000000 +0100 +++ ../src/r0/r002/stdout.build 2008-01-13 00:55:57.000000000 +0100 @@ -1 +1 @@ -Bus error (core dumped) +Bus error --- r003 --- b3tests/b002 - improper size for an open array parameter --- r0/r003/stdout.build 2008-01-20 00:50:11.000000000 +0100 +++ ../src/r0/r003/stdout.build 2008-01-13 00:55:57.000000000 +0100 @@ -1,4 +1,4 @@ "../src/Main.m3", line 11: warning: open array passed by value (x) "../src/Main.m3", line 13: warning: large parameter passed by value (40 bytes) (x) 2 warnings encountered -Abort trap (core dumped) +Abort trap --- r004 --- negative size for an open array --- r0/r004/stdout.build 2008-01-20 00:50:13.000000000 +0100 +++ ../src/r0/r004/stdout.build 2008-01-13 00:55:57.000000000 +0100 @@ -1 +1 @@ -Abort trap (core dumped) +Abort trap > That were all the functional tests. Following is only error detection > and handling: > > There seems to be a problem recognizing some recursive declarations: --- e0/e020/stdout.build 2008-01-20 00:50:32.000000000 +0100 +++ ../src/e0/e020/stdout.build 2008-01-09 02:15:42.000000000 +0100 @@ -1 +1 @@ -Bus error (core dumped) +Fatal Error: package build failed --- e021 --- illegal recursive declaration > OK until --- e026 --- two types with the same brand --- e0/e026/stdout.build 2008-01-20 00:50:38.000000000 +0100 +++ ../src/e0/e026/stdout.build 2003-03-08 23:36:13.000000000 +0100 @@ -0,0 +1,3 @@ +"../src/Main.m3", line 8: string: duplicate brand +"../src/Main.m3", line 7: string: duplicate brand +2 errors encountered > This seems to be just different/missing error output. > > Another more obvious example of this is here: --- e029 --- use type instead of value as an initializer --- e0/e029/stdout.build 2008-01-20 00:50:41.000000000 +0100 +++ ../src/e0/e029/stdout.build 2008-01-09 02:15:44.000000000 +0100 @@ -1,11 +1,4 @@ "../src/Main.m3", line 24: warning: variable has type NULL (r) -"../src/Main.m3", line 24: ** INTERNAL CG ERROR *** stack not empty, depth (1) -"../src/Main.m3", line 25: ** INTERNAL CG ERROR *** stack not empty, depth (1) -"../src/Main.m3", line 26: ** INTERNAL CG ERROR *** unaligned load_indirect type=11 s/a=0/8 -"../src/Main.m3", line 26: ** INTERNAL CG ERROR *** unaligned store_indirect type=11 s/a=0/8 -"../src/Main.m3", line 26: ** INTERNAL CG ERROR *** stack not empty, depth (1) -"../src/Main.m3", line 26: ** INTERNAL CG ERROR *** stack not empty, depth (1) -"../src/Main.m3", line 22: ** INTERNAL CG ERROR *** stack not empty, depth (1) -"../src/Main.m3", line 22: 2 code generation errors -8 errors and 1 warning encountered +"../src/Main.m3", line 24: types are not assignable +1 error and 1 warning encountered Fatal Error: package build failed > Just ignore it? > > For reference, here's the extract of the programs' stderr output: >>> test_m3tests error extract: FreeBSD4/p1/p116b/stderr.pgm:** Class (zero/zero) test not OK: FALSE should be TRUE FreeBSD4/p1/p116b/stderr.pgm:** Class zero/zero test not OK: FALSE should be TRUE FreeBSD4/p1/p155/stderr.pgm:************************ ERROR: check (NOT (p >= x)) failed FreeBSD4/p1/p155/stderr.pgm:1 error(s) and 0 warning(s) detected FreeBSD4/p1/p172/stderr.pgm:************************ ERROR: 23.4 instead of 23 FreeBSD4/p1/p172/stderr.pgm:1 error(s) and 0 warning(s) detected FreeBSD4/p1/p185/stderr.pgm:************************ ERROR: 53 instead of 24 FreeBSD4/p1/p185/stderr.pgm:1 error(s) and 0 warning(s) detected FreeBSD4/r0/r001/stderr.pgm:*** FreeBSD4/r0/r001/stderr.pgm:*** runtime error: FreeBSD4/r0/r001/stderr.pgm:*** Unhandled exception: Main.a FreeBSD4/r0/r001/stderr.pgm:*** file "../src/Main.m3", line 13 FreeBSD4/r0/r001/stderr.pgm:*** FreeBSD4/r0/r003/stderr.pgm:*** FreeBSD4/r0/r003/stderr.pgm:*** runtime error: FreeBSD4/r0/r003/stderr.pgm:*** An open array had the wrong shape. FreeBSD4/r0/r003/stderr.pgm:*** file "../src/Main.m3", line 19 FreeBSD4/r0/r003/stderr.pgm:*** FreeBSD4/r0/r004/stderr.pgm:*** FreeBSD4/r0/r004/stderr.pgm:*** runtime error: FreeBSD4/r0/r004/stderr.pgm:*** An enumeration or subrange value was out of range. FreeBSD4/r0/r004/stderr.pgm:*** file "../src/runtime/common/RTAllocator.m3", line 309 FreeBSD4/r0/r004/stderr.pgm:*** >>> 7 in test_m3tests 2008-01-19-02-30-01 /home/wagner/work/cm3-ws/luthien-2008-01-19-02-30-01 === 2008-01-19 23:50:47 cm3 m3tests run done Thanks in advance for your comments, Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From hosking at cs.purdue.edu Sun Jan 20 22:30:11 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 20 Jan 2008 16:30:11 -0500 Subject: [M3devel] cygwin users? In-Reply-To: References: <862972.55026.qm@web27105.mail.ukl.yahoo.com> Message-ID: <8FB801EB-62E4-4DC6-905A-320E4366E011@cs.purdue.edu> On Jan 20, 2008, at 4:09 PM, Jay wrote: > Does anyone who is asking for Cygwin support actually use it? Or > you are all just Unix users? > (And MinGW users either?) I am principally a Unix user, but I am comfortable with Windows when using Cygwin. Thus, I would probably be more comfortable with running CM3 under Cygwin than running under some other Windows configuration. i.e., installing via .sh under Cygwin (same as I do on Unix targets) makes for a more uniform experience for me. > I mean, are we hearing what people want and will use, or just what > ought to exist in some ideal world? > > - Jay > > Climb to the top of the charts! Play the word scramble challenge > with star power. Play now! From hosking at cs.purdue.edu Sun Jan 20 22:38:16 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 20 Jan 2008 16:38:16 -0500 Subject: [M3devel] Open CM3 regression tests In-Reply-To: <20080120211832.GA26993@elegosoft.com> References: <20080120211832.GA26993@elegosoft.com> Message-ID: <9C00EA97-9B43-43BE-9CDF-EEAC9C1321D5@cs.purdue.edu> The set operations are all coded as external C functions -- should be easy enough to fix those. Or are there type issues too? On Jan 20, 2008, at 4:18 PM, Olaf Wagner wrote: > Hi again everybody, > > I got a little bit side-tracked during recent days while trying > to set up a sensible interface for test status reporting > by the poor state of the CM3 WWW presentation. So I tried to improve > the presentation and structure of the site. It's still all simple > hand-crafted HTML and nothing very fancy, though I think it looks > better now than before. Let me know what you think. And I know, > the colours will be the most interesting discussion topic ;-) > > But back to more important issues. There are still a number of > problems in the CM3 compiler regression tests that I'd like to > discuss and close: either adapt the test, fix the compiler, or > document the issue as intended or erroneous behaviour of CM3. > Though I've thrown in some names here and there, nobody should > hesitate to voice his opinion. Here's the extract of the test run > log: > > CM3_TARGET=FreeBSD4 > BINDISTMIN=/home/wagner/cm3-min-POSIX-FreeBSD4-5.4.0.tgz > === 2008-01-19 23:43:24 run cm3 compiler and runtime regression > test suite in /home/wagner/work/cm3-ws/luthien-2008-01-19-02-30-01 > with lastok version > Critical Mass Modula-3 version d5.5.1 > last updated: 2007-12-30 > compiled: 2008-01-19 17:27:13 > configuration: /home/wagner/work/cm3-inst/luthien/current/bin/ > cm3.cfg > > --- building in FreeBSD4 --- > >> no errors for p1 to p115 > > --- p116b --- default IEEE floating point tests from Xerox PARC > --- p1/p116b/stderr.pgm 2008-01-20 00:47:20.000000000 +0100 > +++ ../src/p1/p116b/stderr.pgm 2008-01-13 00:55:55.000000000 +0100 > @@ -17,7 +17,7 @@ > Class (MaxFinite*ten) test OK > Finite (MaxFinite*ten) test OK > IsNaN (MaxFinite*ten) test OK > -** Class (zero/zero) test not OK: FALSE should be TRUE > + Class (zero/zero) test OK > Finite (zero/zero) test OK > IsNaN (zero/zero) test OK > Sign (zero) test OK > @@ -58,7 +58,7 @@ > Class MaxFinite*ten test OK > Finite MaxFinite*ten test OK > IsNaN MaxFinite*ten test OK > -** Class zero/zero test not OK: FALSE should be TRUE > + Class zero/zero test OK > Finite zero/zero test OK > IsNaN zero/zero test OK > Sign (zero) test OK > >> Some arithmetic problems. Perhaps Henning Thielemann could have >> a look at this? > > --- p117 --- SUBARRAY (LOOPHOLE) > OK again > --- p155 --- operations on small sets > --- p1/p155/stderr.pgm 2008-01-20 00:48:16.000000000 +0100 > +++ ../src/p1/p155/stderr.pgm 2008-01-13 00:55:56.000000000 +0100 > @@ -2,7 +2,6 @@ > check set q = {} > check set r = {a, b} > check set x = {a, b, e} > -************************ ERROR: check (NOT (p >= x)) failed > >> This concerns the >= operation on sets. The language definition >> says: >> >> infix <=, >= (x,y: Ordinal) : BOOLEAN >> (x,y: Float) : BOOLEAN >> (x,y: ADDRESS) : BOOLEAN >> (x,y: Set) : BOOLEAN >> >> In the first three cases, <= returns TRUE if x is at most as large as >> y. In the last case, <= returns TRUE if every element of x is an >> element of y. In all cases, it is a static error if the type of x is >> not assignable to the type of y, or vice versa. The expression x >= y >> is equivalent to y <= x. >> >> So the implementation seems to be plainly wrong. I think the test >> for the previous operation <= only succeeds accidentally. > > > --- p156 --- operations on medium-sized sets >> OK >> until > > --- p172 --- REAL vs. C's float > --- p1/p172/stdout.pgm 2008-01-20 00:49:10.000000000 +0100 > +++ ../src/p1/p172/stdout.pgm 2003-03-08 23:36:48.000000000 +0100 > @@ -0,0 +1 @@ > +23 23 > --- p1/p172/stderr.pgm 2008-01-20 00:49:10.000000000 +0100 > +++ ../src/p1/p172/stderr.pgm 2003-03-08 23:36:48.000000000 +0100 > @@ -1,5 +1,3 @@ > -23.4 23 > -************************ ERROR: 23.4 instead of 23 >> result too exact? >> Perhaps Henning again? And Tony? > > --- p173 --- LONGREAL vs. C's double >> OK again until > > --- p185 --- REAL vs. C float > --- p1/p185/stderr.pgm 2008-01-20 00:49:32.000000000 +0100 > +++ ../src/p1/p185/stderr.pgm 2003-03-08 23:36:50.000000000 +0100 > @@ -1,4 +1,3 @@ > -************************ ERROR: 53 instead of 24 > >> This is another effect of the precision problem. Expression >> evaluation >> seems always to be done with 53 bits of precision (double), and never >> with pure reals (23 bits). I assume it will be the same for C on >> all PC hardware at least. Should we consider this to be an error or >> just document the behaviour? >> >> I assume it cannot easily be changed, can it? > > --- p186 --- case statement with large labels >> Just some output differences; I seem to have switched core dumps >> off in one environment... >> >> So we can probably ignore these ones. > > --- r0/r001/stdout.build 2008-01-20 00:50:07.000000000 +0100 > +++ ../src/r0/r001/stdout.build 2008-01-13 00:55:57.000000000 +0100 > @@ -1,3 +1,3 @@ > "../src/Main.m3", line 13: warning: potentially unhandled > exception: Main.a > 1 warning encountered > -Abort trap (core dumped) > +Abort trap > --- r002 --- stack overflow in the main thread > --- r0/r002/stdout.build 2008-01-20 00:50:09.000000000 +0100 > +++ ../src/r0/r002/stdout.build 2008-01-13 00:55:57.000000000 +0100 > @@ -1 +1 @@ > -Bus error (core dumped) > +Bus error > --- r003 --- b3tests/b002 - improper size for an open array parameter > --- r0/r003/stdout.build 2008-01-20 00:50:11.000000000 +0100 > +++ ../src/r0/r003/stdout.build 2008-01-13 00:55:57.000000000 +0100 > @@ -1,4 +1,4 @@ > "../src/Main.m3", line 11: warning: open array passed by value (x) > "../src/Main.m3", line 13: warning: large parameter passed by > value (40 bytes) (x) > 2 warnings encountered > -Abort trap (core dumped) > +Abort trap > --- r004 --- negative size for an open array > --- r0/r004/stdout.build 2008-01-20 00:50:13.000000000 +0100 > +++ ../src/r0/r004/stdout.build 2008-01-13 00:55:57.000000000 +0100 > @@ -1 +1 @@ > -Abort trap (core dumped) > +Abort trap > >> That were all the functional tests. Following is only error detection >> and handling: >> >> There seems to be a problem recognizing some recursive declarations: > > --- e0/e020/stdout.build 2008-01-20 00:50:32.000000000 +0100 > +++ ../src/e0/e020/stdout.build 2008-01-09 02:15:42.000000000 +0100 > @@ -1 +1 @@ > -Bus error (core dumped) > +Fatal Error: package build failed > > --- e021 --- illegal recursive declaration >> OK until > > --- e026 --- two types with the same brand > --- e0/e026/stdout.build 2008-01-20 00:50:38.000000000 +0100 > +++ ../src/e0/e026/stdout.build 2003-03-08 23:36:13.000000000 +0100 > @@ -0,0 +1,3 @@ > +"../src/Main.m3", line 8: string: duplicate brand > +"../src/Main.m3", line 7: string: duplicate brand > +2 errors encountered > >> This seems to be just different/missing error output. >> >> Another more obvious example of this is here: > > --- e029 --- use type instead of value as an initializer > --- e0/e029/stdout.build 2008-01-20 00:50:41.000000000 +0100 > +++ ../src/e0/e029/stdout.build 2008-01-09 02:15:44.000000000 +0100 > @@ -1,11 +1,4 @@ > "../src/Main.m3", line 24: warning: variable has type NULL (r) > -"../src/Main.m3", line 24: ** INTERNAL CG ERROR *** stack not > empty, depth (1) > -"../src/Main.m3", line 25: ** INTERNAL CG ERROR *** stack not > empty, depth (1) > -"../src/Main.m3", line 26: ** INTERNAL CG ERROR *** unaligned > load_indirect type=11 s/a=0/8 > -"../src/Main.m3", line 26: ** INTERNAL CG ERROR *** unaligned > store_indirect type=11 s/a=0/8 > -"../src/Main.m3", line 26: ** INTERNAL CG ERROR *** stack not > empty, depth (1) > -"../src/Main.m3", line 26: ** INTERNAL CG ERROR *** stack not > empty, depth (1) > -"../src/Main.m3", line 22: ** INTERNAL CG ERROR *** stack not > empty, depth (1) > -"../src/Main.m3", line 22: 2 code generation errors > -8 errors and 1 warning encountered > +"../src/Main.m3", line 24: types are not assignable > +1 error and 1 warning encountered > Fatal Error: package build failed > >> Just ignore it? >> >> For reference, here's the extract of the programs' stderr output: > >>>> test_m3tests error extract: > FreeBSD4/p1/p116b/stderr.pgm:** Class (zero/zero) test not OK: > FALSE should be TRUE > FreeBSD4/p1/p116b/stderr.pgm:** Class zero/zero test not OK: FALSE > should be TRUE > FreeBSD4/p1/p155/stderr.pgm:************************ ERROR: check > (NOT (p >= x)) failed > FreeBSD4/p1/p155/stderr.pgm:1 error(s) and 0 warning(s) detected > FreeBSD4/p1/p172/stderr.pgm:************************ ERROR: 23.4 > instead of 23 > FreeBSD4/p1/p172/stderr.pgm:1 error(s) and 0 warning(s) detected > FreeBSD4/p1/p185/stderr.pgm:************************ ERROR: 53 > instead of 24 > FreeBSD4/p1/p185/stderr.pgm:1 error(s) and 0 warning(s) detected > FreeBSD4/r0/r001/stderr.pgm:*** > FreeBSD4/r0/r001/stderr.pgm:*** runtime error: > FreeBSD4/r0/r001/stderr.pgm:*** Unhandled exception: Main.a > FreeBSD4/r0/r001/stderr.pgm:*** file "../src/Main.m3", line 13 > FreeBSD4/r0/r001/stderr.pgm:*** > FreeBSD4/r0/r003/stderr.pgm:*** > FreeBSD4/r0/r003/stderr.pgm:*** runtime error: > FreeBSD4/r0/r003/stderr.pgm:*** An open array had the wrong shape. > FreeBSD4/r0/r003/stderr.pgm:*** file "../src/Main.m3", line 19 > FreeBSD4/r0/r003/stderr.pgm:*** > FreeBSD4/r0/r004/stderr.pgm:*** > FreeBSD4/r0/r004/stderr.pgm:*** runtime error: > FreeBSD4/r0/r004/stderr.pgm:*** An enumeration or subrange value > was out of range. > FreeBSD4/r0/r004/stderr.pgm:*** file "../src/runtime/common/ > RTAllocator.m3", line 309 > FreeBSD4/r0/r004/stderr.pgm:*** >>>> 7 in test_m3tests 2008-01-19-02-30-01 /home/wagner/work/cm3-ws/ >>>> luthien-2008-01-19-02-30-01 > === 2008-01-19 23:50:47 cm3 m3tests run done > > Thanks in advance for your comments, > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, > Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 > 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: > Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > DE163214194 From dabenavidesd at yahoo.es Sun Jan 20 23:30:59 2008 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Sun, 20 Jan 2008 23:30:59 +0100 (CET) Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: Message-ID: <651689.4797.qm@web27107.mail.ukl.yahoo.com> Hi: Yes, there is some kind of support for /dev file system, though I have not used it, I think this documentation is reliable: http://www.cygwin.com/cygwin-ug-net/using-specialnames.html Well after all the things you are right because the license issues maybe affect the decision of some users of making use of cygwin (NT386GNU): Let's suppose that there is some user(s) interested more in WIN32 platform so we can expose a better support for that on NT386_MINGW or in current NT386. The NT386GNU user(s) would be more appropriate for those interested in using more tools of a POSIX enviroment, let's say grep, gaw, POSIX functions of time, x server/client enviroment and all the stuff you can get to work on cygwin. So the second user has to pay (if he needs) attention on the licensing issues of all of the used tools. Thanks for the comments. Daniel Benavides Jay wrote: .hmmessage P { margin:0px; padding:0px } body.hmmessage { FONT-SIZE: 10pt; FONT-FAMILY:Tahoma } Daniel, yes it's true cygwin has like -mno-cygwin or something. I will have to try that. Currently msys is required to build m3cc and cygwin is required to build m3gdb. m3gdb didn't have any type information anyway, so if you install cygwin, you can just use its gdb. (Note that cygwin is highly modular/package-based, so you can pick and chose what you install, there are many many many choices, so you don't automatically get gdb, you don't automatically even get gcc or ld/binutils.) Otherwise just MinGWin is required. Cygwin might just work. I'll try it before much longer. Is someone going to go ahead and create a new target? I guess I'm about able to. I think I finally fixed the major crash so can..take a break and then continue. Wow that was tedious. Once I can get a MinGWin distribution, I want to look at the pixmap bug, before looking into this new target.. Maybe someone will beat me to it though? /dev does not appear in Cygwin, at least not with cd and ls on my system. I expect /dev/null will work. I do have a very limited installed of Cygwin now, as I was trying to understand roughly what is needed. I don't know what to expect from /dev in Cygwin. You might be asking for too much. $ ls /dev/null /dev/null Jay at jay-win1 / $ ls /proc 1312 cpuinfo meminfo registry stat version 3936 loadavg partitions self uptime Jay at jay-win1 / $ ls /dev ls: cannot access /dev: No such file or directory $ ls /dev/tty /dev/tty $ ls /dev/con ls: cannot access /dev/con: No such file or directory Jay at jay-win1 / $ ls /dev/fd0 /dev/fd0 Jay at jay-win1 / $ ls /dev/fd* ls: cannot access /dev/fd*: No such file or directory Jay at jay-win1 / $ ls /dev/hd0 ls: cannot access /dev/hd0: No such file or directory Jay at jay-win1 / $ ls /dev/sc* ls: cannot access /dev/sc*: No such file or directory I'm not sure what all to guess here. fd0 appears but I don't have a floppy disk. $ cat /proc/uptime 41101.28 32423.71 Jay at jay-win1 / $ cat /proc/version CYGWIN_NT-5.1 1.5.25(0.156/4/2) 2007-12-14 19:21 I'm inclined not to make any cygwin binary distributions until further reading of the license... There's still the X Windows vs. Win32 question... - Jay --------------------------------- Date: Sun, 20 Jan 2008 21:41:23 +0100 From: dabenavidesd at yahoo.es Subject: Re: [M3devel] [M3commit] CVS Update: cm3 To: jayk123 at hotmail.com; wagner at elegosoft.com; m3devel at elegosoft.com Hi: I think for all the users that maybe NT386GNU is more thought like NT386cygwin, but if we see that GNU tools are used in projects like Mingw, that is a fork of cygwin and with the aim of programs running without the dependency on cygwin dll, that maybe guide us to say that the "old target" NT386GNU should be run with a cygwin enviroment. The NT386_MINGW seems to be a nice name/description for the platform which no depends on cygwin.dll but a MinGW/MSYS enviroment. Certainly I think the gnu toolchain is highly used by both the projects, and as I remember, when installing gcc on cygwin it also offers the mingw tool set to the cygwin enviroment to be installed. So let's say that projects are very related and cooperative, but are not the same. So Jay, m3cc could be built on a cygwin enviroment and m3gdb? If so, we can think in those two separeted platforms? although cooperative for m3 developers. I would like to see m3-lectern packages running on NT386GNU using the filesystem /dev, which is something that I wouldn't expect to be on the proposed NT386_MINGW platform. Thanks Jay wrote: .ExternalClass .EC_hmmessage P {padding:0px;} .ExternalClass EC_body.hmmessage {font-size:10pt;font-family:Tahoma;} > the infrastructure. So I'd rather vote that only new targets get > more systematic names. Of course, though the existing names suggest new names, and not clear the value of the existing NT386GNU. Ie. is there a benefit to keep it in use with some meaning or not? Cygwin does have a larger jmpbuf than msvcr*.dll/mingwin. I think it holds sigaction state besides register state. "NT" and "Win" seem redundant. I386_MINGWIN? I386_CYGWIN? NT386_GNU? NT386_MINGNU? Ok, I admit that NT386_CYGWIN NT386_MINGWIN despite the redundancy, clearly point to existing projects that probably have name recognition. And building from NT386 is reasonable -- as was I saying about existing names influencing new names. A C generating backend gets you perhaps easier retargeting as well. I do see there is "MINGWIN64" out there, for AMD64. Not sure what the state of IA64 is though... (See -- you should avoid saying "32" or "64" in stuff, Win32 => Win, Win64 => Win.) I also would agree that creating one target instead of two is probably a good idea -- seems easier. I am not sure if current state is relevant. I mean, is NT386GNU really working and in use anywhere? Is PM3 in use? If so, then matching their meaning would be good. Or even going beyond that -- to Trestle on X Windows. :) (Though CygwinX doesn't exactly appear active.) And thus the precedent for no underscore. NT386MINGWIN ? NT386MINGNU ? I don't know if "MSYS" needs a place in this name. It is needed for building m3cc. I wonder if a hybrid/adaptive approach will be desired -- if Cygwin is available, the MinGWin target could use it to build m3gdb, since it can't otherwise. Hint for anyone trying out Cygwin and getting an odd mix of paths: mkdir \cygdrive get junction.exe from the former www.sysinternals.com junction \cygdrive\c c:\ now when some Cygwin code passes /cygdrive/c to Win32 code, it will just work, no translation needed. If you have multiple drives, I guess just fully populate each one c:\cygdrive\c => c:\ c:\cygdrive\d => d:\ d:\cygdrive\c => c:\ d:\cygdrive\d => d:\ etc. but I haven't tried that. Or, to reduce the multiplication, set them all up on c: and have d:\cygdrive => c:\cygdrive, e:\cygdrive => c:\cygdrive, etc. - Jay --------------------------------- > Date: Sun, 20 Jan 2008 15:56:49 +0100 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > Quoting Jay : > > > Good, a happy customer. :) > > > >> GNU_MODE = 0 % Do not use GNU tools at all -- today's NT386 > >> GNU_MODE = 1 % Use GNU tools minimally -- today's NT386GNU > >> GNU_MODE = 2 % Use GNU tools maximally -- not existant but probably > >> easy > >> > >> Eh..I know, not great.. what do "minimally" and "maximally" mean. > > > > I'm still fishing for anyone to provide answers to these > > less important decisions that I have trouble with. > > Otherwise maybe no NT Cygwin system. > > > > TARGETs = { NT386, NT386GNU, NT386CYGWIN }? > > TARGETs = { NT386, NT386MINGWIN, NT386CYGWIN }? > > TARGETs = { NT386 + GNU_MODE }? > > > > The one reason I don't favor NT386 + GNU_MODE is that Cygwin has a > > much larger jmpbuf than the others. > > I think same TARGET implies code can be linked together, and I think > > varying jmpbuf implies otherwise. > > So NT386 and NT386MINGWIN should rarely cross paths with NT386CYGWIN. > > I think a new target is called for if I have understood everything right. > We need one pure native target (NT386), one pure-Cygwin-based target > (NT386_CYGWIN?) and one mix of runtime, gnu tools and mingwin > (NT386_MINGWIN?). > > As NT386GNU already exists, we must decide if we want to use it as > we traditionally did (all Cygwin) or the mixed implementation > (Mingwin and much Windows RT). > > > I also do NOT like this ad-hoc naming style. > > PPC_DARWIN, I386_DARWIN are much more to my style. > > The names should be somehow hierarchical, except, I realize, there > > isn't necessarily one "path" of > > stuff which to name platforms, though the GNU folks have settled on > > a way or two. > > They have triples or quadruples -- processor-hardware-os or such, > > however this doesn't > > clearly suffice. > > Well, yes, something more systematic would have been better, but > to break with the history will cause much trouble for all users and > the infrastructure. So I'd rather vote that only new targets get > more systematic names. > > > Something that accomodates: > > NT386 + LLVM > > NT386 + Watcom, linker and/or backend and/or runtime > > NT386 + Digital Mars linker and/or backend and/or runtime > > A C generating backend, and then linker/runtime > > and similar IA64, AMD64 variants would be good. > > I'm not sure that a C generating backend would really help matters. > This was done in the first implementation of DEC, and they soon > abandoned it as C had proven to be a bad choice as intermediate language. > I agree it would be great for cross-compilation etc. > > As far as C and RT dependencies of native Windows compilers go, I don't > see why this couldn't be just a question of another cm3.cfg setup. > > > To a large extent, these can be few platforms, subject to > > configuration, like if all > > the linkers consume a common file format (not clear), and if all the > > jmpbufs are the same > > size (known to be partly true, partly false). > > Yes, jmpbuf is always a problem for user threads and exceptions. > On Unix systems the jmpbuf and other important low-level structures > are always defined by the system headers and independent of compilers > AFAIK, so I'm a bit surprised that it should be different on Windows. > But maybe I'm just wrong and haven't just seen the right counter > examples... > > > Oh and another thing, the runtime dependency is very likely cuttable, however > > PRESUMABLY real world applications (if there are any) link in a > > substantial amount of > > C or C++, in which case, it isn't necessarily cuttable. > > Yes. Real world applications tend to link other libraries (C, C++, > Fortran, ...) and even often call other applications like sh etc. > > > As well, if I can figure out a good way to do it, switching NT386 > > from awful slow > > frequent TlsGetValue/TlsSetValue to manipulating the linked list in > > fs:0, that would be nice, > > and might incur a C runtime dependency, but well worth it. The way > > Modula-3 works here > > is terrible. Another compromise option is probably > > __declspec(thread), though there is trickiness there > > in terms of being in a .dll that isn't used by the .exe. > > Such optimizations should be done depending on the target. > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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! --------------------------------- Web Revelaci?n Yahoo! 2007: Premio Favorita del P?blico - ?Vota tu preferida! --------------------------------- Shed those extra pounds with MSN and The Biggest Loser! Learn more. --------------------------------- Web Revelaci?n Yahoo! 2007: Premio Favorita del P?blico - ?Vota tu preferida! -------------- next part -------------- An HTML attachment was scrubbed... URL: From dabenavidesd at yahoo.es Sun Jan 20 23:35:02 2008 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Sun, 20 Jan 2008 23:35:02 +0100 (CET) Subject: [M3devel] cygwin users? In-Reply-To: Message-ID: <786049.83427.qm@web27111.mail.ukl.yahoo.com> I guess my discussion is more about of an ideal world for programmers :) that has a lot of discussion, but also for all the users that want to port more easily applications from a (~)Unix platforms to Windows like I would like to do it with m3-lectern packages. Thanks again, Daniel Benavides Jay escribi?: .hmmessage P { margin:0px; padding:0px } body.hmmessage { FONT-SIZE: 10pt; FONT-FAMILY:Tahoma } Does anyone who is asking for Cygwin support actually use it? Or you are all just Unix users? (And MinGW users either?) I mean, are we hearing what people want and will use, or just what ought to exist in some ideal world? - Jay --------------------------------- Climb to the top of the charts! Play the word scramble challenge with star power. Play now! --------------------------------- Web Revelaci?n Yahoo! 2007: Premio Favorita del P?blico - ?Vota tu preferida! -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Sun Jan 20 23:45:32 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Sun, 20 Jan 2008 23:45:32 +0100 Subject: [M3devel] cygwin users? In-Reply-To: References: <862972.55026.qm@web27105.mail.ukl.yahoo.com> Message-ID: <20080120234532.1dstrrusisoscc0s@mail.elegosoft.com> Quoting Jay : > Does anyone who is asking for Cygwin support actually use it? Or you > are all just Unix users? > (And MinGW users either?) > I mean, are we hearing what people want and will use, or just what > ought to exist in some ideal world? I haven been using Cygwin several years ago, and would do so again. Whenever I have to use a Windows system, one of the first things I do is install Cygwin to have a comfortable command line environment I am familiar with. I'd be especially interested in M3-XWindows programs running on Cygwin, as the native Trestle implementation was never complete, IIRC. And X-Servers are really common and easy to install nowadays even on 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 darko at darko.org Mon Jan 21 01:18:59 2008 From: darko at darko.org (Darko) Date: Sun, 20 Jan 2008 16:18:59 -0800 Subject: [M3devel] cygwin users? In-Reply-To: References: <862972.55026.qm@web27105.mail.ukl.yahoo.com> Message-ID: <7EEE72F7-B0D1-42FB-B5D7-4C2E3533F16E@darko.org> I don't use Cygwin, but I use a Unix command line under Windows (I found the basic bash tools compiled to be used standalone under Windows, they might be MinGW based, but I'm not sure). I generally use GUI tools, CodeWarrior on my Mac generally, but also the MS IDE for its debugging tool. I'm interested in the NT/GNU platform mostly for the optimised code generation. I guess I represent the other side to the Unix geeks - it's just another platform to me and I'd like to keep it distinct from Windows, mainly for performance, compatibility and simplicity. I think there are many potential users like me out there, who don't particularly care about Unix. M3's Unix heritage has hindered M3 a little I think. One of the reasons M3 isn't more popular is because there are no simple installers for common "user" platforms. One of the things I'd like to do is create a installer for Windows and Mac OS X with full native API interfaces, a full set of relevant compiled libraries, and a little bit of documentation. That way people can give it a try with the minimum of time invested. People will discover M3 is a great language to program in if people actually get a chance to use it. Thanks for doing all the work you've been doing on the NT platform, Jay, it is much appreciated and has the potential to bring may more users to M3. Darko. On 20/01/2008, at 1:09 PM, Jay wrote: > Does anyone who is asking for Cygwin support actually use it? Or you > are all just Unix users? > (And MinGW users either?) > I mean, are we hearing what people want and will use, or just what > ought to exist in some ideal world? > > - Jay > > Climb to the top of the charts! Play the word scramble challenge > with star power. Play now! From jayk123 at hotmail.com Mon Jan 21 05:45:43 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 21 Jan 2008 04:45:43 +0000 Subject: [M3devel] "one more time before I give in" :) Message-ID: Should the mingwin/msys method just be a configuration of NT386? A command line option to cm3 and/or an environment variable? The targets are nearly the same. The difference just needs to be exposed somehow, so the config file can switch betwen two implementations of a few functions -- compile_c, m3_link, make_lib. If Windows cminstall/src/config/NT386 and cminstall/src/config/NT386GNU, you see very very similar. Maybe they vary just in BUILD_DIR? Or does that break things?Profiling changes BUILD_DIR so I figure it might be ok. I tried making BUILD_DIR not readonly and setting it with cm3 -D, doesn't work. It can probably be set conditionally in the config file based on another variable though, I'd have to check. Besides, it might be nice for a notion of a set of build_dirs that are probed. In particular, you might have some C or C++ code that uses GCC (or Microsoft) extensions. That could also be handled by a different variable, like compile_with_gcc() and compile_with_msvc() in the m3makefile and then cm3 would switch between compile_gcc and compile_msvc instead of the usual compile_c functoin. There is a high degree of interoperabilty between these two or even all three platforms. Perhaps this is a can of worms though. Much potential utility but too complicated to think about? Perhaps I too desperate to have fewer platforms? I do need multiple build_dirs, like three, that is certain. - 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 Mon Jan 21 06:05:03 2008 From: darko at darko.org (Darko) Date: Sun, 20 Jan 2008 21:05:03 -0800 Subject: [M3devel] "one more time before I give in" :) In-Reply-To: References: Message-ID: <1E4B5D9E-F0B1-4E2F-90E6-34385C5CDFB6@darko.org> Can we just have them as separate config files and anyone who wants to switch between them can do so in a script or other method on their own platform? Most people would just choose one and stick to it. We should try to keep it simple and move the complexity to people who want a more complex setup. On 20/01/2008, at 8:45 PM, Jay wrote: > Should the mingwin/msys method just be a configuration of NT386? > A command line option to cm3 and/or an environment variable? > > The targets are nearly the same. > The difference just needs to be exposed somehow, so the config file > can switch betwen two implementations of a few functions -- > compile_c, m3_link, make_lib. > If Windows cminstall/src/config/NT386 and cminstall/src/config/ > NT386GNU, you see very very similar. > > Maybe they vary just in BUILD_DIR? Or does that break things? > Profiling changes BUILD_DIR so I figure it might be ok. > I tried making BUILD_DIR not readonly and setting it with cm3 -D, > doesn't work. > It can probably be set conditionally in the config file based on > another variable though, I'd have to check. > > Besides, it might be nice for a notion of a set of build_dirs that > are probed. > In particular, you might have some C or C++ code that uses GCC (or > Microsoft) extensions. > That could also be handled by a different variable, like > compile_with_gcc() and compile_with_msvc() in the m3makefile and > then cm3 would switch between compile_gcc and compile_msvc instead > of the usual compile_c functoin. > > There is a high degree of interoperabilty between these two or even > all three platforms. > > Perhaps this is a can of worms though. Much potential utility but > too complicated to think about? > > Perhaps I too desperate to have fewer platforms? > I do need multiple build_dirs, like three, that is certain. > > - Jay > > Helping your favorite cause is as easy as instant messaging. You IM, > we give. Learn more. From jayk123 at hotmail.com Mon Jan 21 06:47:28 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 21 Jan 2008 05:47:28 +0000 Subject: [M3devel] next problem (NT386GNU) Message-ID: M3File.m3 PROCEDURE IsReadable (path: TEXT): BOOLEAN = (* We don't really check for readablitiy, just for existence *) BEGIN TRY EVAL FS.Status (path); line 82 RETURN TRUE; EXCEPT OSError.E => RETURN FALSE; END; END IsReadable; -----LINE 82 ----- start_call_direct p.25 0 Struct load_address v.25 0 pop_param Addr load v.26 0 Addr Addr pop_param Addr call_direct p.25 Struct pop StructI'm guessing you only see an import for the first call on purpose, but I will compare with PPC_DARWIN: -----LINE 46 ----- import_procedure FS__Status 2 Struct 0 p.25 declare_indirect 2078421550 -2078421551 declare_param _return 4 4 Addr 2078421550 F F 50 v.62 declare_param p 4 4 Addr 1358456180 F F 50 v.63 start_call_direct p.25 0 Struct load_address v.13 0 pop_param Addr load v.14 0 Addr Addr pop_param Addr call_direct p.25 Struct pop Struct .globl _M3File__IsReadable .def _M3File__IsReadable; .scl 2; .type 32; .endef_M3File__IsReadable: .stabn 68,0,178,LM93-_M3File__IsReadableLM93: pushl %ebp movl %esp, %ebp pushl %edi pushl %esi pushl %ebx subl $300, %espLBB15: .stabn 68,0,181,LM94-_M3File__IsReadableLM94:L157: movl -280(%ebp), %eax andl $0, %eax orl $_L_1, %eax movl %eax, -280(%ebp) movl -284(%ebp), %eax andl $0, %eax movl %eax, -284(%ebp) subl $12, %esp leal -288(%ebp), %eax pushl %eax call _RTHooks__PushEFrame addl $16, %esp leal -288(%ebp), %eax addl $48, %eax subl $12, %esp pushl %eax call __setjmp addl $16, %esp testb %al, %al jne L158 .stabn 68,0,183,LM95-_M3File__IsReadableLM95: movl -288(%ebp), %eax subl $12, %esp pushl %eax call _RTHooks__PopEFrame addl $16, %esp movl $1, -304(%ebp) jmp L159L158: .stabn 68,0,185,LM96-_M3File__IsReadableLM96: movl $0, -304(%ebp)L159:LBE15: movl -304(%ebp), %eax leal -12(%ebp), %esp popl %ebx popl %esi popl %edi leave ret M3File.IsReadable's call to FS.Status is omitted, all files are readable, even if they are not openable, therefore it "finds" cm3.cfg in the current directory and then fails to open it.. later.. ..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 wagner at elegosoft.com Mon Jan 21 08:20:53 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 21 Jan 2008 08:20:53 +0100 Subject: [M3devel] "one more time before I give in" :) In-Reply-To: References: Message-ID: <20080121082053.2ph7hxo5esw0wk0g@mail.elegosoft.com> Quoting Jay : > Should the mingwin/msys method just be a configuration of NT386? > A command line option to cm3 and/or an environment variable? > > The targets are nearly the same. > The difference just needs to be exposed somehow, so the config file > can switch betwen two implementations of a few functions -- > compile_c, m3_link, make_lib. > If Windows cminstall/src/config/NT386 and > cminstall/src/config/NT386GNU, you see very very similar. As long as the M3 and C code is all the same, I'm not against having just different cm3.cfg files. > Maybe they vary just in BUILD_DIR? Or does that break > things?Profiling changes BUILD_DIR so I figure it might be ok. > I tried making BUILD_DIR not readonly and setting it with cm3 -D, > doesn't work. > It can probably be set conditionally in the config file based on > another variable though, I'd have to check. > > Besides, it might be nice for a notion of a set of build_dirs that > are probed. > In particular, you might have some C or C++ code that uses GCC (or > Microsoft) extensions. > That could also be handled by a different variable, like > compile_with_gcc() and compile_with_msvc() in the m3makefile and > then cm3 would switch between compile_gcc and compile_msvc instead > of the usual compile_c functoin. > > There is a high degree of interoperabilty between these two or even > all three platforms. > > Perhaps this is a can of worms though. Much potential utility but > too complicated to think about? > > Perhaps I too desperate to have fewer platforms? > I do need multiple build_dirs, like three, that is certain. Using other build_dirs for derived target files from cm3.cfg should work, too; but we should not diverge too much from the staandard; perhaps just add a _MINGWIN or _CYGWIN suffix? Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Jan 21 08:43:53 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 21 Jan 2008 07:43:53 +0000 Subject: [M3devel] next problem (NT386GNU) Message-ID: I haven't tested a fix but I see the problem. This function returns a struct. There are two struct returning calling conventions. In one, the backend handles it. Which includes the backend knowing there is a return value and its type (or at least its size?). In the other, the front end handles it. In this case, the front end generates passing an extra pointer parameter to the function, and the function's return type is void. The NT calling conventions, all of them, are marked as front end handling it. I assume that is correct, could check. Everything else is marked as back end handling. Now then, somewhere along the line, gcc figures out that the return value isn't used here. The point of the function call is to see if it generates an exception.Gcc removes the function because its return value isn't used, and, well, somehow it doesn't know about the exceptions here. I'll have to see how "raise" is implemented. I think it's by a call to a function that gets the jmpbuf from a thread local and calls longjmp. (Did I mention it is very inefficient?) There are few possible fixes, but nothing completely satisfactory yet in mind. One is have parse.c mark all function calls as having side affects. This is easy, but overly pessimistic. Another is for the front end to mark struct returning functions as having side affects. Better, but still overly pessimistic. Another is for the front end to mark any function that can raise as having side affects. Getting better still. I don't know how to do that but I'll look. This is still a bit overly pessimistic, since what you really want to know is, not the function's side affects, but whether or not it raised. If the function is inlined, the side affects could be optimized away, or if there are enough callers who don't care about the side affects to warrant an optimization, and depending on the cost of computing the side affects, another instance of the function could be made that only raises or not, but no side affects otherwise. This is "advanced" optimization the sort of which tends never to be implemented. I think the best option is anything that can raise is marked as having side affects. I'll see if I can figure that out. You can figure this out by looking at m3cgcat -binary < M3File.mc > 1.txt on PPC_DARWIN and NT386GNU and comparing. Maybe marking all or nearly functions as having side effects isn't so bad. Or at least anything returning a struct. That gets parity with other platforms, even if it is a bit pessimistic. I think I'll do that, and ignore figuring out if raise is called and using that as a filter. The parity angle is good. The good news for all you Unix lovers :) is this bug is relatively portable to Cygwin. True, it is specific to NT386GNU having multiple "calling conventions", which no other platform has. Which again, jokingly, strikes at the question -- What is Posix? What do you want from Cygwin? One thing Cygwin does NOT give you is just one calling convention, alas, this calling convention business stinks. It's not even an NT thing, only an NT386 thing. All the other NT platforms had/have only one calling convention. You can't get far on NT386 without needing to support two calling conventions. The "OS" uses mostly __stdcall -- callee pops -- smaller, faster. But anything that is varargs, such as printf -- pretty much must use caller pops -- __cdecl. As well, __cdecl is the default, so prevalent, and used in most C runtime functions. There is also __fastcall that uses like up to two registers for parameters. I have seen a platform in which printf did the pop, and it depended on the number/size of parameters matching the format string. On most platforms, printf("", 1, 2, 3, 4) just does nothing, but on that platform, it'd unbalance the stack and crash. - Jay From: jayk123 at hotmail.comTo: hosking at cs.purdue.eduCC: m3devel at elegosoft.comSubject: next problem (NT386GNU)Date: Mon, 21 Jan 2008 05:47:28 +0000 M3File.m3 PROCEDURE IsReadable (path: TEXT): BOOLEAN = (* We don't really check for readablitiy, just for existence *) BEGIN TRY EVAL FS.Status (path); line 82 RETURN TRUE; EXCEPT OSError.E => RETURN FALSE; END; END IsReadable; -----LINE 82 ----- start_call_direct p.25 0 Struct load_address v.25 0 pop_param Addr load v.26 0 Addr Addr pop_param Addr call_direct p.25 Struct pop StructI'm guessing you only see an import for the first call on purpose, but I will compare with PPC_DARWIN: -----LINE 46 ----- import_procedure FS__Status 2 Struct 0 p.25 declare_indirect 2078421550 -2078421551 declare_param _return 4 4 Addr 2078421550 F F 50 v.62 declare_param p 4 4 Addr 1358456180 F F 50 v.63 start_call_direct p.25 0 Struct load_address v.13 0 pop_param Addr load v.14 0 Addr Addr pop_param Addr call_direct p.25 Struct pop Struct .globl _M3File__IsReadable .def _M3File__IsReadable; .scl 2; .type 32; .endef_M3File__IsReadable: .stabn 68,0,178,LM93-_M3File__IsReadableLM93: pushl %ebp movl %esp, %ebp pushl %edi pushl %esi pushl %ebx subl $300, %espLBB15: .stabn 68,0,181,LM94-_M3File__IsReadableLM94:L157: movl -280(%ebp), %eax andl $0, %eax orl $_L_1, %eax movl %eax, -280(%ebp) movl -284(%ebp), %eax andl $0, %eax movl %eax, -284(%ebp) subl $12, %esp leal -288(%ebp), %eax pushl %eax call _RTHooks__PushEFrame addl $16, %esp leal -288(%ebp), %eax addl $48, %eax subl $12, %esp pushl %eax call __setjmp addl $16, %esp testb %al, %al jne L158 .stabn 68,0,183,LM95-_M3File__IsReadableLM95: movl -288(%ebp), %eax subl $12, %esp pushl %eax call _RTHooks__PopEFrame addl $16, %esp movl $1, -304(%ebp) jmp L159L158: .stabn 68,0,185,LM96-_M3File__IsReadableLM96: movl $0, -304(%ebp)L159:LBE15: movl -304(%ebp), %eax leal -12(%ebp), %esp popl %ebx popl %esi popl %edi leave ret M3File.IsReadable's call to FS.Status is omitted, all files are readable, even if they are not openable, therefore it "finds" cm3.cfg in the current directory and then fails to open it.. later.. ..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 Mon Jan 21 09:03:44 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 21 Jan 2008 08:03:44 +0000 Subject: [M3devel] FW: next problem (NT386GNU) Message-ID: and again my mail got truncated..Clearly the best option, despite the pessimism, is to mark all struct returning functions has having side affects, as that achieves parity with all the other gcc-based platforms. Optimizing this can be left for later target-independent work that'll probably never happen. Changing the calling convention is almost an option, as there are so few functions in the world foolhardy enough to return structs. If they are all written in Modula-3, then there'd be enough consistency. Sleazy though.I'll see what PM3 does first. - Jay Which again, jokingly, strikes at the question -- What is Posix? What do you want from Cygwin?One thing Cygwin does NOT give you is just one calling convention, alas, this calling convention business stinks. It's not even an NT thing, only an NT386 thing. All the other NT platforms had/have only one calling convention. You can't get far on NT386 without needing to support two calling conventions.The "OS" uses mostly __stdcall -- callee pops -- smaller, faster.But anything that is varargs, such as printf -- pretty much must use caller pops -- __cdecl.As well, __cdecl is the default, so prevalent, and used in most C runtime functions.There is also __fastcall that uses like up to two registers for parameters. I have seen a platform in which printf did the pop, and it depended on the number/size of parameters matching the format string. On most platforms, printf("", 1, 2, 3, 4) just does nothing, but on that platform, it'd unbalance the stack and crash. - Jay From: jayk123 at hotmail.comTo: hosking at cs.purdue.eduCC: m3devel at elegosoft.comSubject: next problem (NT386GNU)Date: Mon, 21 Jan 2008 05:47:28 +0000 M3File.m3 PROCEDURE IsReadable (path: TEXT): BOOLEAN = (* We don't really check for readablitiy, just for existence *) BEGIN TRY EVAL FS.Status (path); line 82 RETURN TRUE; EXCEPT OSError.E => RETURN FALSE; END; END IsReadable; -----LINE 82 ----- start_call_direct p.25 0 Struct load_address v.25 0 pop_param Addr load v.26 0 Addr Addr pop_param Addr call_direct p.25 Struct pop StructI'm guessing you only see an import for the first call on purpose, but I will compare with PPC_DARWIN: -----LINE 46 ----- import_procedure FS__Status 2 Struct 0 p.25 declare_indirect 2078421550 -2078421551 declare_param _return 4 4 Addr 2078421550 F F 50 v.62 declare_param p 4 4 Addr 1358456180 F F 50 v.63 start_call_direct p.25 0 Struct load_address v.13 0 pop_param Addr load v.14 0 Addr Addr pop_param Addr call_direct p.25 Struct pop Struct .globl _M3File__IsReadable .def _M3File__IsReadable; .scl 2; .type 32; .endef_M3File__IsReadable: .stabn 68,0,178,LM93-_M3File__IsReadableLM93: pushl %ebp movl %esp, %ebp pushl %edi pushl %esi pushl %ebx subl $300, %espLBB15: .stabn 68,0,181,LM94-_M3File__IsReadableLM94:L157: movl -280(%ebp), %eax andl $0, %eax orl $_L_1, %eax movl %eax, -280(%ebp) movl -284(%ebp), %eax andl $0, %eax movl %eax, -284(%ebp) subl $12, %esp leal -288(%ebp), %eax pushl %eax call _RTHooks__PushEFrame addl $16, %esp leal -288(%ebp), %eax addl $48, %eax subl $12, %esp pushl %eax call __setjmp addl $16, %esp testb %al, %al jne L158 .stabn 68,0,183,LM95-_M3File__IsReadableLM95: movl -288(%ebp), %eax subl $12, %esp pushl %eax call _RTHooks__PopEFrame addl $16, %esp movl $1, -304(%ebp) jmp L159L158: .stabn 68,0,185,LM96-_M3File__IsReadableLM96: movl $0, -304(%ebp)L159:LBE15: movl -304(%ebp), %eax leal -12(%ebp), %esp popl %ebx popl %esi popl %edi leave ret M3File.IsReadable's call to FS.Status is omitted, all files are readable, even if they are not openable, therefore it "finds" cm3.cfg in the current directory and then fails to open it.. later.. ..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! 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 Jan 21 09:05:32 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 21 Jan 2008 08:05:32 +0000 Subject: [M3devel] next problem (NT386GNU) Message-ID: pm3: IF gnuWin32 THEN CCs[x].args_left_to_right := TRUE; CCs[x].results_on_left := TRUE; CCs[x].standard_structs := TRUE; END;Duh, maybe the backend handles it correctly. I'll try.. - Jay From: jayk123 at hotmail.comTo: m3devel at elegosoft.comSubject: FW: next problem (NT386GNU)Date: Mon, 21 Jan 2008 08:03:44 +0000 and again my mail got truncated..Clearly the best option, despite the pessimism, is to mark all struct returning functions has having side affects, as that achieves parity with all the other gcc-based platforms. Optimizing this can be left for later target-independent work that'll probably never happen. Changing the calling convention is almost an option, as there are so few functions in the world foolhardy enough to return structs. If they are all written in Modula-3, then there'd be enough consistency. Sleazy though.I'll see what PM3 does first. - Jay Which again, jokingly, strikes at the question -- What is Posix? What do you want from Cygwin?One thing Cygwin does NOT give you is just one calling convention, alas, this calling convention business stinks. It's not even an NT thing, only an NT386 thing. All the other NT platforms had/have only one calling convention. You can't get far on NT386 without needing to support two calling conventions.The "OS" uses mostly __stdcall -- callee pops -- smaller, faster.But anything that is varargs, such as printf -- pretty much must use caller pops -- __cdecl.As well, __cdecl is the default, so prevalent, and used in most C runtime functions.There is also __fastcall that uses like up to two registers for parameters. I have seen a platform in which printf did the pop, and it depended on the number/size of parameters matching the format string. On most platforms, printf("", 1, 2, 3, 4) just does nothing, but on that platform, it'd unbalance the stack and crash. - Jay From: jayk123 at hotmail.comTo: hosking at cs.purdue.eduCC: m3devel at elegosoft.comSubject: next problem (NT386GNU)Date: Mon, 21 Jan 2008 05:47:28 +0000 M3File.m3 PROCEDURE IsReadable (path: TEXT): BOOLEAN = (* We don't really check for readablitiy, just for existence *) BEGIN TRY EVAL FS.Status (path); line 82 RETURN TRUE; EXCEPT OSError.E => RETURN FALSE; END; END IsReadable; -----LINE 82 ----- start_call_direct p.25 0 Struct load_address v.25 0 pop_param Addr load v.26 0 Addr Addr pop_param Addr call_direct p.25 Struct pop StructI'm guessing you only see an import for the first call on purpose, but I will compare with PPC_DARWIN: -----LINE 46 ----- import_procedure FS__Status 2 Struct 0 p.25 declare_indirect 2078421550 -2078421551 declare_param _return 4 4 Addr 2078421550 F F 50 v.62 declare_param p 4 4 Addr 1358456180 F F 50 v.63 start_call_direct p.25 0 Struct load_address v.13 0 pop_param Addr load v.14 0 Addr Addr pop_param Addr call_direct p.25 Struct pop Struct .globl _M3File__IsReadable .def _M3File__IsReadable; .scl 2; .type 32; .endef_M3File__IsReadable: .stabn 68,0,178,LM93-_M3File__IsReadableLM93: pushl %ebp movl %esp, %ebp pushl %edi pushl %esi pushl %ebx subl $300, %espLBB15: .stabn 68,0,181,LM94-_M3File__IsReadableLM94:L157: movl -280(%ebp), %eax andl $0, %eax orl $_L_1, %eax movl %eax, -280(%ebp) movl -284(%ebp), %eax andl $0, %eax movl %eax, -284(%ebp) subl $12, %esp leal -288(%ebp), %eax pushl %eax call _RTHooks__PushEFrame addl $16, %esp leal -288(%ebp), %eax addl $48, %eax subl $12, %esp pushl %eax call __setjmp addl $16, %esp testb %al, %al jne L158 .stabn 68,0,183,LM95-_M3File__IsReadableLM95: movl -288(%ebp), %eax subl $12, %esp pushl %eax call _RTHooks__PopEFrame addl $16, %esp movl $1, -304(%ebp) jmp L159L158: .stabn 68,0,185,LM96-_M3File__IsReadableLM96: movl $0, -304(%ebp)L159:LBE15: movl -304(%ebp), %eax leal -12(%ebp), %esp popl %ebx popl %esi popl %edi leave ret M3File.IsReadable's call to FS.Status is omitted, all files are readable, even if they are not openable, therefore it "finds" cm3.cfg in the current directory and then fails to open it.. later.. ..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! Learn more. 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 jayk123 at hotmail.com Mon Jan 21 11:50:28 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 21 Jan 2008 10:50:28 +0000 Subject: [M3devel] gcc/eh/setjmp Message-ID: Folks, try adding -Wunreachable-code to your m3back options and tell me if you don't get loads of warnings. for stuff like: TRY return Foo(); ELSE return FALSE; I get them on NT386GNU and PPC_DARWIN. Functions with TRY need, in gcc parlance: calls_setjmp and the exception/finally blocks need: has_nonlocal_label and functions with RAISE might need: has_nonlocal_goto Luckily, gcc doesn't seem to act on what it figure out. - 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 mika at async.caltech.edu Mon Jan 21 11:54:26 2008 From: mika at async.caltech.edu (Mika Nystrom) Date: Mon, 21 Jan 2008 02:54:26 -0800 Subject: [M3devel] cygwin users? In-Reply-To: Your message of "Sun, 20 Jan 2008 21:09:42 GMT." Message-ID: <200801211054.m0LAsQbx067355@camembert.async.caltech.edu> I develop on FreeBSD but my production system runs under Cygwin. It links with libpq.a, plus various C and Fortran code I wrote myself under Unix. It also builds with make, uses readline, calls /bin/sh, etc., etc., etc. I'm using PM3/Klagenfurt for this, and I'm just DYING to shift it to CM3 one day, because since I need Pickles to work across all architectures I'm using I'm currently in the situation that I can't use Linux in our clustered system (no PM3), nor can I use MacOS (also no PM3). One of my business partners uses Ubuntu, so his computer can't talk to mine, and I have a Mac laptop, so my laptop can't talk to my main systems. Etc. Cygwin is the only of five or six environments that I have to use that can't run CM3. Yes it is probably possible for me to port my code to native Windows (anything is possible), but the beauty of Cygwin is that I can be fairly confident that any code that works on FreeBSD, no matter how weird and Unix-specific, will also work on Cygwin. (Once you know about the pitfalls in Time.T and file semantics.) I am a bona fide "Windows hater". To me, Windows is an especially bloated program loader that for some bizarre reason people have chosen to load the most useful web browsers and music players. I haven't found anything else useful that it does. I have seen people use something called "Visual Studio" on it. Oh yes, I even used it myself once, but I couldn't figure out how to transport the program I wrote to the computer of someone who didn't have "Visual Studio" to run (even after asking some of my former students, who are now programmers at Microsoft), so I gave up on it. I think it is for people like me that Cygwin was invented. Mika Jay writes: >--_674d79e8-e259-4230-8419-f52e99d90089_ >Content-Type: text/plain; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > >Does anyone who is asking for Cygwin support actually use it? Or you are al= >l just Unix users? >(And MinGW users either?) >I mean, are we hearing what people want and will use, or just what ought to= > exist in some ideal world? >=20 > - Jay >_________________________________________________________________ >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= > >--_674d79e8-e259-4230-8419-f52e99d90089_ >Content-Type: text/html; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > > > > >Does anyone who is asking for Cygwin support actu= >ally use it? Or you are all just Unix users?
>(And MinGW users either?)
>I mean, are we hearing what people want and will use, or just what ought to= > exist in some ideal world?
> 
> - Jay

Climb to the top of the charts!=A0Play the word = >scramble challenge with star power. uffle.aspx?icid=3Dstarshuffle_wlmailtextlink_jan' target=3D'_new'>Play now!= > >= > >--_674d79e8-e259-4230-8419-f52e99d90089_-- From lemming at henning-thielemann.de Mon Jan 21 12:51:48 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Mon, 21 Jan 2008 12:51:48 +0100 (MET) Subject: [M3devel] Open CM3 regression tests In-Reply-To: <20080120211832.GA26993@elegosoft.com> References: <20080120211832.GA26993@elegosoft.com> Message-ID: On Sun, 20 Jan 2008, Olaf Wagner wrote: > > no errors for p1 to p115 > > --- p116b --- default IEEE floating point tests from Xerox PARC > --- p1/p116b/stderr.pgm 2008-01-20 00:47:20.000000000 +0100 > +++ ../src/p1/p116b/stderr.pgm 2008-01-13 00:55:55.000000000 +0100 My compiler complains about LONGINT type in src/Test.i3 . I assume that this is the 64 bit support. Seems that I have to upgrade my compiler. In general floating point is a strange issue. You cannot rely on that your machine supports IEEE format, although most machines do. The precision of the same float type can be different on different machines. However, the Float modules shall reflect that. Computation with NaN and Infinity is broken, it should be avoided and in most cases continueing the computation with NaN or Infinity only hides the precise error location. It would be better to abort with an error for a division by zero, overflow and so on. I think one can enable this with FloatModes. From jayk123 at hotmail.com Mon Jan 21 14:19:41 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 21 Jan 2008 13:19:41 +0000 Subject: [M3devel] gcc/eh/setjmp Message-ID: I've been trying sprinkling these bits around, to no avail. I realize another larger step is to communicate much try/except/finally information down, in order to use the native support (which still stinks on Windows). I stupidly plumbed the depths of "CG" to communicate the bits down before seeing what was needed.. - Jay From: jayk123 at hotmail.comTo: m3devel at elegosoft.comSubject: gcc/eh/setjmpDate: Mon, 21 Jan 2008 10:50:28 +0000 Folks, try adding -Wunreachable-code to your m3back options and tell me if you don't get loads of warnings.for stuff like: TRY return Foo();ELSE return FALSE; I get them on NT386GNU and PPC_DARWIN. Functions with TRY need, in gcc parlance: calls_setjmp and the exception/finally blocks need: has_nonlocal_label and functions with RAISE might need: has_nonlocal_goto Luckily, gcc doesn't seem to act on what it figure out. - Jay Helping your favorite cause is as easy as instant messaging. You IM, we give. Learn more. _________________________________________________________________ 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 Jan 21 15:50:06 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 21 Jan 2008 14:50:06 +0000 Subject: [M3devel] code quality.. Message-ID: Unoptimized code quality is really bad, even compared to unoptimized C, even compared to gcc, and optimized code quality isn't great. I have this made up C code. I was verifyingthe struct return calling convention. typedef struct { unsigned a; unsigned b; unsigned c;} d; d F2(unsigned a, unsigned b, unsigned c){ d e; e.a = a * b * c; e.b = 123; e.c = a - b - c; return e;} and then the equivalent Modula-3: INTERFACE T; TYPE T1 = RECORD a,b,c : INTEGEREND; PROCEDURE F2(a,b,c : INTEGER) : T1; END T. MODULE T; PROCEDURE F2(a,b,c : INTEGER) : T1 =VAR e : T1;BEGIN e.a := (a * b * c); e.b := 123; e.c := (a - b - c); RETURN e;END F2; BEGINEND T. Unoptimized Visual C++ 8.0: _F2: 00000000: 55 push ebp 00000001: 8B EC mov ebp,esp 00000003: 83 EC 0C sub esp,0Ch 00000006: 8B 45 0C mov eax,dword ptr [ebp+0Ch] 00000009: 0F AF 45 10 imul eax,dword ptr [ebp+10h] 0000000D: 0F AF 45 14 imul eax,dword ptr [ebp+14h] 00000011: 89 45 F4 mov dword ptr [ebp-0Ch],eax 00000014: C7 45 F8 7B 00 00 mov dword ptr [ebp-8],7Bh 00 0000001B: 8B 4D 0C mov ecx,dword ptr [ebp+0Ch] 0000001E: 2B 4D 10 sub ecx,dword ptr [ebp+10h] 00000021: 2B 4D 14 sub ecx,dword ptr [ebp+14h] 00000024: 89 4D FC mov dword ptr [ebp-4],ecx 00000027: 8B 55 08 mov edx,dword ptr [ebp+8] 0000002A: 8B 45 F4 mov eax,dword ptr [ebp-0Ch] 0000002D: 89 02 mov dword ptr [edx],eax 0000002F: 8B 4D F8 mov ecx,dword ptr [ebp-8] 00000032: 89 4A 04 mov dword ptr [edx+4],ecx 00000035: 8B 45 FC mov eax,dword ptr [ebp-4] 00000038: 89 42 08 mov dword ptr [edx+8],eax 0000003B: 8B 45 08 mov eax,dword ptr [ebp+8] 0000003E: 8B E5 mov esp,ebp 00000040: 5D pop ebp 00000041: C3 ret Visual C++ 8.0 with /O1 It writes the results right into the output. _F2: 00000000: 55 push ebp 00000001: 8B EC mov ebp,esp 00000003: 8B 4D 0C mov ecx,dword ptr [ebp+0Ch] 00000006: 8B 45 08 mov eax,dword ptr [ebp+8] 00000009: 8B D1 mov edx,ecx 0000000B: 0F AF 55 10 imul edx,dword ptr [ebp+10h] 0000000F: 0F AF 55 14 imul edx,dword ptr [ebp+14h] 00000013: 2B 4D 10 sub ecx,dword ptr [ebp+10h] 00000016: 89 10 mov dword ptr [eax],edx 00000018: 2B 4D 14 sub ecx,dword ptr [ebp+14h] 0000001B: C7 40 04 7B 00 00 mov dword ptr [eax+4],7Bh 00 00000022: 89 48 08 mov dword ptr [eax+8],ecx 00000025: 5D pop ebp 00000026: C3 ret with /O2 _F2: 00000000: 8B 4C 24 08 mov ecx,dword ptr [esp+8] 00000004: 8B 54 24 0C mov edx,dword ptr [esp+0Ch] 00000008: 8B 44 24 04 mov eax,dword ptr [esp+4] 0000000C: 56 push esi 0000000D: 8B 74 24 14 mov esi,dword ptr [esp+14h] 00000011: 57 push edi 00000012: 8B F9 mov edi,ecx 00000014: 0F AF FA imul edi,edx 00000017: 0F AF FE imul edi,esi 0000001A: 2B CA sub ecx,edx 0000001C: 89 38 mov dword ptr [eax],edi 0000001E: 2B CE sub ecx,esi 00000020: 5F pop edi 00000021: C7 40 04 7B 00 00 mov dword ptr [eax+4],7Bh 00 00000028: 89 48 08 mov dword ptr [eax+8],ecx 0000002B: 5E pop esi 0000002C: C3 ret gcc 3.4.5 unoptimized _F2: 00000000: 55 push ebp 00000001: 89 E5 mov ebp,esp 00000003: 83 EC 18 sub esp,18h 00000006: 8B 4D 08 mov ecx,dword ptr [ebp+8] 00000009: 8B 45 0C mov eax,dword ptr [ebp+0Ch] 0000000C: 0F AF 45 10 imul eax,dword ptr [ebp+10h] 00000010: 0F AF 45 14 imul eax,dword ptr [ebp+14h] 00000014: 89 45 E8 mov dword ptr [ebp-18h],eax 00000017: C7 45 EC 7B 00 00 mov dword ptr [ebp-14h],7Bh 00 0000001E: 8B 55 10 mov edx,dword ptr [ebp+10h] 00000021: 8B 45 0C mov eax,dword ptr [ebp+0Ch] 00000024: 29 D0 sub eax,edx 00000026: 2B 45 14 sub eax,dword ptr [ebp+14h] 00000029: 89 45 F0 mov dword ptr [ebp-10h],eax 0000002C: 8B 45 E8 mov eax,dword ptr [ebp-18h] 0000002F: 89 01 mov dword ptr [ecx],eax 00000031: 8B 45 EC mov eax,dword ptr [ebp-14h] 00000034: 89 41 04 mov dword ptr [ecx+4],eax 00000037: 8B 45 F0 mov eax,dword ptr [ebp-10h] 0000003A: 89 41 08 mov dword ptr [ecx+8],eax 0000003D: 89 C8 mov eax,ecx 0000003F: C9 leave 00000040: C2 04 00 ret 4 00000043: 90 nop 00000044: 90 nop ...more nops for padding... gcc -O1 _F2: 00000000: 55 push ebp 00000001: 89 E5 mov ebp,esp 00000003: 83 EC 18 sub esp,18h 00000006: 89 5D F8 mov dword ptr [ebp-8],ebx 00000009: 89 75 FC mov dword ptr [ebp-4],esi 0000000C: 8B 45 08 mov eax,dword ptr [ebp+8] 0000000F: 8B 4D 0C mov ecx,dword ptr [ebp+0Ch] 00000012: 8B 5D 10 mov ebx,dword ptr [ebp+10h] 00000015: 8B 75 14 mov esi,dword ptr [ebp+14h] 00000018: 89 CA mov edx,ecx 0000001A: 0F AF D3 imul edx,ebx 0000001D: 0F AF D6 imul edx,esi 00000020: 29 D9 sub ecx,ebx 00000022: 29 F1 sub ecx,esi 00000024: 89 10 mov dword ptr [eax],edx 00000026: C7 40 04 7B 00 00 mov dword ptr [eax+4],7Bh 00 0000002D: 89 48 08 mov dword ptr [eax+8],ecx 00000030: 8B 5D F8 mov ebx,dword ptr [ebp-8] 00000033: 8B 75 FC mov esi,dword ptr [ebp-4] 00000036: 89 EC mov esp,ebp 00000038: 5D pop ebp 00000039: C2 04 00 ret 4 0000003C: 90 nop 0000003D: 90 nop 0000003E: 90 nop 0000003F: 90 nop I didn't investigate all the switches much and simple -O vs. -O1 vs. -O2 vs. -o3all do the same. -O1 -fomit-frame-pointer netted: _F2: 00000000: 83 EC 1C sub esp,1Ch 00000003: 89 5C 24 14 mov dword ptr [esp+14h],ebx 00000007: 89 74 24 18 mov dword ptr [esp+18h],esi 0000000B: 8B 44 24 20 mov eax,dword ptr [esp+20h] 0000000F: 8B 4C 24 24 mov ecx,dword ptr [esp+24h] 00000013: 8B 5C 24 28 mov ebx,dword ptr [esp+28h] 00000017: 8B 74 24 2C mov esi,dword ptr [esp+2Ch] 0000001B: 89 CA mov edx,ecx 0000001D: 0F AF D3 imul edx,ebx 00000020: 0F AF D6 imul edx,esi 00000023: 29 D9 sub ecx,ebx 00000025: 29 F1 sub ecx,esi 00000027: 89 10 mov dword ptr [eax],edx 00000029: C7 40 04 7B 00 00 mov dword ptr [eax+4],7Bh 00 00000030: 89 48 08 mov dword ptr [eax+8],ecx 00000033: 8B 5C 24 14 mov ebx,dword ptr [esp+14h] 00000037: 8B 74 24 18 mov esi,dword ptr [esp+18h] 0000003B: 83 C4 1C add esp,1Ch 0000003E: C2 04 00 ret 4 00000041: 90 nop .. more nops .. Ok, ready, here goes the unoptimized Modula-3.Notice the duplicate copying of the return value and the *doubling* in code size. _T__F2: 00000000: 55 push ebp 00000001: 89 E5 mov ebp,esp 00000003: 57 push edi 00000004: 56 push esi 00000005: 83 EC 30 sub esp,30h 00000008: 8B 55 0C mov edx,dword ptr [ebp+0Ch] 0000000B: 8B 45 10 mov eax,dword ptr [ebp+10h] 0000000E: 0F AF D0 imul edx,eax 00000011: 8B 45 14 mov eax,dword ptr [ebp+14h] 00000014: 0F AF D0 imul edx,eax 00000017: 8B 45 D4 mov eax,dword ptr [ebp-2Ch] 0000001A: 83 E0 00 and eax,0 0000001D: 09 D0 or eax,edx 0000001F: 89 45 D4 mov dword ptr [ebp-2Ch],eax 00000022: 8B 45 D8 mov eax,dword ptr [ebp-28h] 00000025: 83 E0 00 and eax,0 00000028: 83 C8 7B or eax,7Bh 0000002B: 89 45 D8 mov dword ptr [ebp-28h],eax 0000002E: 8B 55 0C mov edx,dword ptr [ebp+0Ch] 00000031: 8B 45 10 mov eax,dword ptr [ebp+10h] 00000034: 29 C2 sub edx,eax 00000036: 8B 45 14 mov eax,dword ptr [ebp+14h] 00000039: 29 C2 sub edx,eax 0000003B: 8B 45 DC mov eax,dword ptr [ebp-24h] 0000003E: 83 E0 00 and eax,0 00000041: 09 D0 or eax,edx 00000043: 89 45 DC mov dword ptr [ebp-24h],eax 00000046: 8B 45 08 mov eax,dword ptr [ebp+8] 00000049: 89 C2 mov edx,eax 0000004B: 8D 45 D4 lea eax,[ebp-2Ch] 0000004E: 8D 7D EC lea edi,[ebp-14h] 00000051: 89 C6 mov esi,eax 00000053: FC cld 00000054: A5 movs dword ptr es:[edi],dword ptr [esi] 00000055: A5 movs dword ptr es:[edi],dword ptr [esi] 00000056: A5 movs dword ptr es:[edi],dword ptr [esi] 00000057: 89 D7 mov edi,edx 00000059: 8D 75 EC lea esi,[ebp-14h] 0000005C: FC cld 0000005D: A5 movs dword ptr es:[edi],dword ptr [esi] 0000005E: A5 movs dword ptr es:[edi],dword ptr [esi] 0000005F: A5 movs dword ptr es:[edi],dword ptr [esi] 00000060: 83 C4 30 add esp,30h 00000063: 5E pop esi 00000064: 5F pop edi 00000065: C9 leave 00000066: C3 ret optimized Modula-3 is better, saves the extra copy, but still not great: _T__F2: 00000000: 55 push ebp 00000001: 89 E5 mov ebp,esp 00000003: 57 push edi 00000004: 56 push esi 00000005: 53 push ebx 00000006: 83 EC 10 sub esp,10h 00000009: 8B 55 0C mov edx,dword ptr [ebp+0Ch] 0000000C: 8B 4D 10 mov ecx,dword ptr [ebp+10h] 0000000F: 8B 5D 14 mov ebx,dword ptr [ebp+14h] 00000012: 89 D0 mov eax,edx 00000014: 0F AF C1 imul eax,ecx 00000017: 0F AF C3 imul eax,ebx 0000001A: 8B 75 E8 mov esi,dword ptr [ebp-18h] 0000001D: 89 45 E8 mov dword ptr [ebp-18h],eax 00000020: 8B 45 EC mov eax,dword ptr [ebp-14h] 00000023: C7 45 EC 7B 00 00 mov dword ptr [ebp-14h],7Bh 00 0000002A: 29 CA sub edx,ecx 0000002C: 29 DA sub edx,ebx Huh what does this next instruction achieve? 0000002E: 8B 45 F0 mov eax,dword ptr [ebp-10h] 00000031: 89 55 F0 mov dword ptr [ebp-10h],edx 00000034: 8B 7D 08 mov edi,dword ptr [ebp+8] 00000037: 8D 75 E8 lea esi,[ebp-18h] 0000003A: FC cld 0000003B: A5 movs dword ptr es:[edi],dword ptr [esi] 0000003C: A5 movs dword ptr es:[edi],dword ptr [esi] 0000003D: A5 movs dword ptr es:[edi],dword ptr [esi] 0000003E: 83 C4 10 add esp,10h 00000041: 5B pop ebx 00000042: 5E pop esi 00000043: 5F pop edi 00000044: C9 leave 00000045: C3 ret and lastly the integrated backend, which runs much faster, and I believe has just one mode,somewhat optimized (but still lacks int64 support): _T__F2: 00000000: 55 push ebp 00000001: 8B EC mov ebp,esp 00000003: 81 EC 18 00 00 00 sub esp,18h 00000009: 53 push ebx 0000000A: 56 push esi 0000000B: 57 push edi 0000000C: 8B 5D 10 mov ebx,dword ptr [ebp+10h] 0000000F: 0F AF 5D 0C imul ebx,dword ptr [ebp+0Ch] 00000013: 0F AF 5D 14 imul ebx,dword ptr [ebp+14h] 00000017: 89 5D F4 mov dword ptr [ebp-0Ch],ebx 0000001A: C7 45 F8 7B 00 00 mov dword ptr [ebp-8],7Bh 00 00000021: 8B 55 0C mov edx,dword ptr [ebp+0Ch] 00000024: 2B 55 10 sub edx,dword ptr [ebp+10h] 00000027: 2B 55 14 sub edx,dword ptr [ebp+14h] 0000002A: 89 55 FC mov dword ptr [ebp-4],edx 0000002D: 8D 75 F4 lea esi,[ebp-0Ch] 00000030: 8B 7D 08 mov edi,dword ptr [ebp+8] 00000033: 8B 4E 00 mov ecx,dword ptr [esi] 00000036: 89 4F 00 mov dword ptr [edi],ecx 00000039: 8B 4E 04 mov ecx,dword ptr [esi+4] 0000003C: 89 4F 04 mov dword ptr [edi+4],ecx 0000003F: 8B 4E 08 mov ecx,dword ptr [esi+8] 00000042: 89 4F 08 mov dword ptr [edi+8],ecx 00000045: 8B C7 mov eax,edi 00000047: 5F pop edi 00000048: 5E pop esi 00000049: 5B pop ebx 0000004A: C9 leave 0000004B: C3 ret I haven't looked at all this in depth, but the doubling in size, the extra copy, that the integrated backend's code is fairly small... - 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 Jan 21 16:22:32 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 21 Jan 2008 15:22:32 +0000 Subject: [M3devel] safety vs. capacity vs. reinvention? Message-ID: I'm constantly noticing fixed sized buffers in the Modula-3 code and reinvention of basic data types and algorithms, such as growable arrays. Something seems off, eh? Here's the latest: -> linking cm3.exec:\\docume~1\\jay\\locals~1\\temp\\cm3\\make-dist\\tmpukymas\\cm3-core-WIN32-NT386GNU-d5.5.1\\pkg\\m3back\\NT386GNU\\m3back.lib c:\\docume~1\\jay\\locals~1\\temp\\cm3\\make-dist\\tmpukymas\\cm3-core-WIN32-NT386GNU-d5.5.1\\pkg\\m3objfile\\NT386GNU\\m3objfile.lib c:\\docume~1\\jay\\locals~1\\temp\\cm3\\make-dist\\tmpukymas\\cm3-core-WIN32-NT386GNU-d5.5.1\\pkg\\m3quake\\NT386GNU\\m3quake.lib c:\\docume~1\\jay\\locals~1\\temp\\cm3\\make-dist\\tmpukymas\\cm3-core-WIN32-NT386GNU-d5.5.1\\pkg\\m3front\\NT386GNU\\m3front.lib c:\\docume~1\\jay\\locals~1\\temp\\cm3\\make-dist\\tmpukymas\\cm3-core-WIN32-NT386GNU-d5.5.1\\pkg\\m3linker\\NT386GNU\\m3link.lib c:\\docume~1\\jay\\locals~1\\temp\\cm3\\make-dist\\tmpukymas\\cm3-core-WIN32-NT386GNU-d5.5.1\\pkg\\m3middle\\NT386GNU\\m3middle.lib c:\\docume~1\\jay\\locals~1\\temp\\cm3\\make-dist\\tmpukymas\\cm3-core-WIN32-NT386GNU-d5.5.1\\pkg\\libm3\\NT386GNU\\m3.lib.sa c:\\docume~1\\jay\\locals~1\\temp\\cm3\\make-dist\\tmpukymas\\cm3-core-WIN32-NT386GNU-d5.5.1\\pkg\\m3core\\NT386GNU\\m3core.lib.sa -lcomctl32 -lwsock32 -lnetapi32 -lgdi32 -luser32 ****** runtime error:*** <*ASSERT*> failed.*** file "..\src\M3ID.m3", line 58*** Stack trace: FP PC Procedure--------- --------- ------------------------------- 0x22f198 0x59e9c3 Add + 0x53 in ..\src\M3ID.m3 0x22f1c8 0x4209cb Txt2ID + 0x14 in ..\src\M3Build.m3 0x22f208 0x478f9f PushText + 0x97 in ..\src\QMachine.m3 0x22f418 0x47c38f DoEscape + 0x341 in ..\src\QMachine.m3 0x22f478 0x476a37 DoCall + 0x568 in ..\src\QMachine.m3 0x22f558 0x475a49 Eval + 0x1845(!) in ..\src\QMachine.m3 0x22f578 0x4764ca CallProc + 0x2b in ..\src\QMachine.m3 0x22f6e8 0x413717 CallProc + 0x156 in ..\src\Builder.m3 0x22f758 0x40e96a BuildProgram + 0x66a in ..\src\Builder.m3 0x22f788 0x402282 BuildPgm + 0x62 in ..\src\Builder.m3......... ......... ... more frames ... PROCEDURE Add (x: TEXT; class: [0..255]): T = VAR t : T; len := Text.Length (x); buf : ARRAY [0..1024] OF CHAR; BEGIN IF len > NUMBER(buf) THEN IO.Put(x); END; <*ASSERT len <= NUMBER (buf) *> Text.SetChars (buf, x); t := FromStr (buf, len); IF (class # 0) THEN classes [t] := class; END; IF (ids[t].text = NIL) THEN ids[t].text := x; END; RETURN t; END Add;The code is escaping imported .libs in order to write them into a response file, since gcc needs the doubled slashes.. I'm using a response file BECAUSE I have a long string.. - 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 Jan 21 16:54:10 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 21 Jan 2008 10:54:10 -0500 Subject: [M3devel] next problem (NT386GNU) In-Reply-To: References: Message-ID: <6E1E4409-F3D9-4982-B179-2D4C9648FDD0@cs.purdue.edu> Surely, when using the gcc-based backend then we should make the backend handle it. The front end handling it is only need for the integrated x86 backend. On Jan 21, 2008, at 2:43 AM, Jay wrote: > I haven't tested a fix but I see the problem. > > This function returns a struct. > There are two struct returning calling conventions. > In one, the backend handles it. Which includes the backend knowing > there is a return value and its type (or at least its size?). > In the other, the front end handles it. In this case, the front end > generates passing an extra pointer parameter to the function, and > the function's return type is void. > > The NT calling conventions, all of them, are marked as front end > handling it. I assume that is correct, could check. > Everything else is marked as back end handling. > > Now then, somewhere along the line, gcc figures out that the return > value isn't used here. > The point of the function call is to see if it generates an exception. > > Gcc removes the function because its return value isn't used, and, > well, somehow it doesn't know about the exceptions here. I'll have > to see how "raise" is implemented. I think it's by a call to a > function that gets the jmpbuf from a thread local and calls > longjmp. (Did I mention it is very inefficient?) > > There are few possible fixes, but nothing completely satisfactory > yet in mind. > > One is have parse.c mark all function calls as having side affects. > This is easy, but overly pessimistic. > Another is for the front end to mark struct returning functions as > having side affects. Better, but still overly pessimistic. > Another is for the front end to mark any function that can raise as > having side affects. Getting better still. I don't know how to do > that but I'll look. This is still a bit overly pessimistic, since > what you really want to know is, not the function's side affects, > but whether or not it raised. If the function is inlined, the side > affects could be optimized away, or if there are enough callers who > don't care about the side affects to warrant an optimization, and > depending on the cost of computing the side affects, another > instance of the function could be made that only raises or not, but > no side affects otherwise. This is "advanced" optimization the sort > of which tends never to be implemented. > > I think the best option is anything that can raise is marked as > having side affects. > I'll see if I can figure that out. > > You can figure this out by looking at m3cgcat -binary < M3File.mc > > 1.txt on PPC_DARWIN and NT386GNU and comparing. > > Maybe marking all or nearly functions as having side effects isn't > so bad. > Or at least anything returning a struct. That gets parity with > other platforms, even if it is a bit pessimistic. > I think I'll do that, and ignore figuring out if raise is called > and using that as a filter. > The parity angle is good. > > The good news for all you Unix lovers :) is this bug is relatively > portable to Cygwin. > True, it is specific to NT386GNU having multiple "calling > conventions", which no other platform has. > Which again, jokingly, strikes at the question -- What is Posix? > What do you want from Cygwin? > One thing Cygwin does NOT give you is just one calling convention, > alas, this calling convention business stinks. It's not even an NT > thing, only an NT386 thing. All the other NT platforms had/have > only one calling convention. > > You can't get far on NT386 without needing to support two calling > conventions. > The "OS" uses mostly __stdcall -- callee pops -- smaller, faster. > But anything that is varargs, such as printf -- pretty much must > use caller pops -- __cdecl. > As well, __cdecl is the default, so prevalent, and used in most C > runtime functions. > There is also __fastcall that uses like up to two registers for > parameters. > > I have seen a platform in which printf did the pop, and it depended > on the number/size of parameters matching the format string. On > most platforms, printf("", 1, 2, 3, 4) just does nothing, but on > that platform, it'd unbalance the stack and crash. > > - Jay > > From: jayk123 at hotmail.com > To: hosking at cs.purdue.edu > CC: m3devel at elegosoft.com > Subject: next problem (NT386GNU) > Date: Mon, 21 Jan 2008 05:47:28 +0000 > > M3File.m3 > > PROCEDURE IsReadable (path: TEXT): BOOLEAN = > (* We don't really check for readablitiy, just for existence *) > BEGIN > TRY > EVAL FS.Status (path); line 82 > RETURN TRUE; > EXCEPT OSError.E => > RETURN FALSE; > END; > END IsReadable; > > -----LINE 82 ----- > start_call_direct p.25 0 Struct > load_address v.25 0 > pop_param Addr > load v.26 0 Addr Addr > pop_param Addr > call_direct p.25 Struct > pop Struct > > > > I'm guessing you only see an import for the first call on purpose, > but I will compare with PPC_DARWIN: > > -----LINE 46 ----- > import_procedure FS__Status 2 Struct 0 p.25 > declare_indirect 2078421550 -2078421551 > declare_param _return 4 4 Addr 2078421550 F F 50 v.62 > declare_param p 4 4 Addr 1358456180 F F 50 v.63 > start_call_direct p.25 0 Struct > load_address v.13 0 > pop_param Addr > load v.14 0 Addr Addr > pop_param Addr > call_direct p.25 Struct > pop Struct > > > .globl _M3File__IsReadable > .def _M3File__IsReadable; .scl 2; .type 32; .endef > _M3File__IsReadable: > .stabn 68,0,178,LM93-_M3File__IsReadable > LM93: > pushl %ebp > movl %esp, %ebp > pushl %edi > pushl %esi > pushl %ebx > subl $300, %esp > LBB15: > .stabn 68,0,181,LM94-_M3File__IsReadable > LM94: > L157: > movl -280(%ebp), %eax > andl $0, %eax > orl $_L_1, %eax > movl %eax, -280(%ebp) > movl -284(%ebp), %eax > andl $0, %eax > movl %eax, -284(%ebp) > subl $12, %esp > leal -288(%ebp), %eax > pushl %eax > call _RTHooks__PushEFrame > addl $16, %esp > leal -288(%ebp), %eax > addl $48, %eax > subl $12, %esp > pushl %eax > call __setjmp > addl $16, %esp > testb %al, %al > jne L158 > .stabn 68,0,183,LM95-_M3File__IsReadable > LM95: > movl -288(%ebp), %eax > subl $12, %esp > pushl %eax > call _RTHooks__PopEFrame > addl $16, %esp > movl $1, -304(%ebp) > jmp L159 > L158: > .stabn 68,0,185,LM96-_M3File__IsReadable > LM96: > movl $0, -304(%ebp) > L159: > LBE15: > movl -304(%ebp), %eax > leal -12(%ebp), %esp > popl %ebx > popl %esi > popl %edi > leave > ret > > > M3File.IsReadable's call to FS.Status is omitted, all files are > readable, even if they are not openable, therefore it "finds" > cm3.cfg in the current directory and then fails to open it.. > > later.. > ..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! Learn more. From hosking at cs.purdue.edu Mon Jan 21 17:01:52 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 21 Jan 2008 11:01:52 -0500 Subject: [M3devel] code quality.. In-Reply-To: References: Message-ID: <241EF32F-F814-4EB0-88A8-B3E413D1F4BE@cs.purdue.edu> Is this having the front-end handle return of structs or the backend? On Jan 21, 2008, at 9:50 AM, Jay wrote: > Unoptimized code quality is really bad, > even compared to unoptimized C, even compared > to gcc, and optimized code quality isn't great. > > I have this made up C code. I was verifying > the struct return calling convention. > > typedef struct { > unsigned a; > unsigned b; > unsigned c; > } d; > > d F2(unsigned a, unsigned b, unsigned c) > { > d e; > e.a = a * b * c; > e.b = 123; > e.c = a - b - c; > return e; > } > > and then the equivalent Modula-3: > > INTERFACE T; > > TYPE T1 = RECORD > a,b,c : INTEGER > END; > > PROCEDURE F2(a,b,c : INTEGER) : T1; > > END T. > > MODULE T; > > PROCEDURE F2(a,b,c : INTEGER) : T1 = > VAR > e : T1; > BEGIN > e.a := (a * b * c); > e.b := 123; > e.c := (a - b - c); > RETURN e; > END F2; > > BEGIN > END T. > > Unoptimized Visual C++ 8.0: > > _F2: > 00000000: 55 push ebp > 00000001: 8B EC mov ebp,esp > 00000003: 83 EC 0C sub esp,0Ch > 00000006: 8B 45 0C mov eax,dword ptr [ebp+0Ch] > 00000009: 0F AF 45 10 imul eax,dword ptr [ebp+10h] > 0000000D: 0F AF 45 14 imul eax,dword ptr [ebp+14h] > 00000011: 89 45 F4 mov dword ptr [ebp-0Ch],eax > 00000014: C7 45 F8 7B 00 00 mov dword ptr [ebp-8],7Bh > 00 > 0000001B: 8B 4D 0C mov ecx,dword ptr [ebp+0Ch] > 0000001E: 2B 4D 10 sub ecx,dword ptr [ebp+10h] > 00000021: 2B 4D 14 sub ecx,dword ptr [ebp+14h] > 00000024: 89 4D FC mov dword ptr [ebp-4],ecx > 00000027: 8B 55 08 mov edx,dword ptr [ebp+8] > 0000002A: 8B 45 F4 mov eax,dword ptr [ebp-0Ch] > 0000002D: 89 02 mov dword ptr [edx],eax > 0000002F: 8B 4D F8 mov ecx,dword ptr [ebp-8] > 00000032: 89 4A 04 mov dword ptr [edx+4],ecx > 00000035: 8B 45 FC mov eax,dword ptr [ebp-4] > 00000038: 89 42 08 mov dword ptr [edx+8],eax > 0000003B: 8B 45 08 mov eax,dword ptr [ebp+8] > 0000003E: 8B E5 mov esp,ebp > 00000040: 5D pop ebp > 00000041: C3 ret > > Visual C++ 8.0 with /O1 > > It writes the results right into the output. > _F2: > 00000000: 55 push ebp > 00000001: 8B EC mov ebp,esp > 00000003: 8B 4D 0C mov ecx,dword ptr [ebp+0Ch] > 00000006: 8B 45 08 mov eax,dword ptr [ebp+8] > 00000009: 8B D1 mov edx,ecx > 0000000B: 0F AF 55 10 imul edx,dword ptr [ebp+10h] > 0000000F: 0F AF 55 14 imul edx,dword ptr [ebp+14h] > 00000013: 2B 4D 10 sub ecx,dword ptr [ebp+10h] > 00000016: 89 10 mov dword ptr [eax],edx > 00000018: 2B 4D 14 sub ecx,dword ptr [ebp+14h] > 0000001B: C7 40 04 7B 00 00 mov dword ptr [eax+4],7Bh > 00 > 00000022: 89 48 08 mov dword ptr [eax+8],ecx > 00000025: 5D pop ebp > 00000026: C3 ret > > with /O2 > > _F2: > 00000000: 8B 4C 24 08 mov ecx,dword ptr [esp+8] > 00000004: 8B 54 24 0C mov edx,dword ptr [esp+0Ch] > 00000008: 8B 44 24 04 mov eax,dword ptr [esp+4] > 0000000C: 56 push esi > 0000000D: 8B 74 24 14 mov esi,dword ptr [esp+14h] > 00000011: 57 push edi > 00000012: 8B F9 mov edi,ecx > 00000014: 0F AF FA imul edi,edx > 00000017: 0F AF FE imul edi,esi > 0000001A: 2B CA sub ecx,edx > 0000001C: 89 38 mov dword ptr [eax],edi > 0000001E: 2B CE sub ecx,esi > 00000020: 5F pop edi > 00000021: C7 40 04 7B 00 00 mov dword ptr [eax+4],7Bh > 00 > 00000028: 89 48 08 mov dword ptr [eax+8],ecx > 0000002B: 5E pop esi > 0000002C: C3 ret > > gcc 3.4.5 unoptimized > > _F2: > 00000000: 55 push ebp > 00000001: 89 E5 mov ebp,esp > 00000003: 83 EC 18 sub esp,18h > 00000006: 8B 4D 08 mov ecx,dword ptr [ebp+8] > 00000009: 8B 45 0C mov eax,dword ptr [ebp+0Ch] > 0000000C: 0F AF 45 10 imul eax,dword ptr [ebp+10h] > 00000010: 0F AF 45 14 imul eax,dword ptr [ebp+14h] > 00000014: 89 45 E8 mov dword ptr [ebp-18h],eax > 00000017: C7 45 EC 7B 00 00 mov dword ptr [ebp-14h],7Bh > 00 > 0000001E: 8B 55 10 mov edx,dword ptr [ebp+10h] > 00000021: 8B 45 0C mov eax,dword ptr [ebp+0Ch] > 00000024: 29 D0 sub eax,edx > 00000026: 2B 45 14 sub eax,dword ptr [ebp+14h] > 00000029: 89 45 F0 mov dword ptr [ebp-10h],eax > 0000002C: 8B 45 E8 mov eax,dword ptr [ebp-18h] > 0000002F: 89 01 mov dword ptr [ecx],eax > 00000031: 8B 45 EC mov eax,dword ptr [ebp-14h] > 00000034: 89 41 04 mov dword ptr [ecx+4],eax > 00000037: 8B 45 F0 mov eax,dword ptr [ebp-10h] > 0000003A: 89 41 08 mov dword ptr [ecx+8],eax > 0000003D: 89 C8 mov eax,ecx > 0000003F: C9 leave > 00000040: C2 04 00 ret 4 > 00000043: 90 nop > 00000044: 90 nop > ...more nops for padding... > > gcc -O1 > > _F2: > 00000000: 55 push ebp > 00000001: 89 E5 mov ebp,esp > 00000003: 83 EC 18 sub esp,18h > 00000006: 89 5D F8 mov dword ptr [ebp-8],ebx > 00000009: 89 75 FC mov dword ptr [ebp-4],esi > 0000000C: 8B 45 08 mov eax,dword ptr [ebp+8] > 0000000F: 8B 4D 0C mov ecx,dword ptr [ebp+0Ch] > 00000012: 8B 5D 10 mov ebx,dword ptr [ebp+10h] > 00000015: 8B 75 14 mov esi,dword ptr [ebp+14h] > 00000018: 89 CA mov edx,ecx > 0000001A: 0F AF D3 imul edx,ebx > 0000001D: 0F AF D6 imul edx,esi > 00000020: 29 D9 sub ecx,ebx > 00000022: 29 F1 sub ecx,esi > 00000024: 89 10 mov dword ptr [eax],edx > 00000026: C7 40 04 7B 00 00 mov dword ptr [eax+4],7Bh > 00 > 0000002D: 89 48 08 mov dword ptr [eax+8],ecx > 00000030: 8B 5D F8 mov ebx,dword ptr [ebp-8] > 00000033: 8B 75 FC mov esi,dword ptr [ebp-4] > 00000036: 89 EC mov esp,ebp > 00000038: 5D pop ebp > 00000039: C2 04 00 ret 4 > 0000003C: 90 nop > 0000003D: 90 nop > 0000003E: 90 nop > 0000003F: 90 nop > > I didn't investigate all the switches much and simple -O vs. -O1 > vs. -O2 vs. -o3 > all do the same. > > -O1 -fomit-frame-pointer netted: > > _F2: > 00000000: 83 EC 1C sub esp,1Ch > 00000003: 89 5C 24 14 mov dword ptr [esp+14h],ebx > 00000007: 89 74 24 18 mov dword ptr [esp+18h],esi > 0000000B: 8B 44 24 20 mov eax,dword ptr [esp+20h] > 0000000F: 8B 4C 24 24 mov ecx,dword ptr [esp+24h] > 00000013: 8B 5C 24 28 mov ebx,dword ptr [esp+28h] > 00000017: 8B 74 24 2C mov esi,dword ptr [esp+2Ch] > 0000001B: 89 CA mov edx,ecx > 0000001D: 0F AF D3 imul edx,ebx > 00000020: 0F AF D6 imul edx,esi > 00000023: 29 D9 sub ecx,ebx > 00000025: 29 F1 sub ecx,esi > 00000027: 89 10 mov dword ptr [eax],edx > 00000029: C7 40 04 7B 00 00 mov dword ptr [eax+4],7Bh > 00 > 00000030: 89 48 08 mov dword ptr [eax+8],ecx > 00000033: 8B 5C 24 14 mov ebx,dword ptr [esp+14h] > 00000037: 8B 74 24 18 mov esi,dword ptr [esp+18h] > 0000003B: 83 C4 1C add esp,1Ch > 0000003E: C2 04 00 ret 4 > 00000041: 90 nop > .. more nops .. > > Ok, ready, here goes the unoptimized Modula-3. > Notice the duplicate copying of the return value and the *doubling* > in code size. > > _T__F2: > 00000000: 55 push ebp > 00000001: 89 E5 mov ebp,esp > 00000003: 57 push edi > 00000004: 56 push esi > 00000005: 83 EC 30 sub esp,30h > 00000008: 8B 55 0C mov edx,dword ptr [ebp+0Ch] > 0000000B: 8B 45 10 mov eax,dword ptr [ebp+10h] > 0000000E: 0F AF D0 imul edx,eax > 00000011: 8B 45 14 mov eax,dword ptr [ebp+14h] > 00000014: 0F AF D0 imul edx,eax > 00000017: 8B 45 D4 mov eax,dword ptr [ebp-2Ch] > 0000001A: 83 E0 00 and eax,0 > 0000001D: 09 D0 or eax,edx > 0000001F: 89 45 D4 mov dword ptr [ebp-2Ch],eax > 00000022: 8B 45 D8 mov eax,dword ptr [ebp-28h] > 00000025: 83 E0 00 and eax,0 > 00000028: 83 C8 7B or eax,7Bh > 0000002B: 89 45 D8 mov dword ptr [ebp-28h],eax > 0000002E: 8B 55 0C mov edx,dword ptr [ebp+0Ch] > 00000031: 8B 45 10 mov eax,dword ptr [ebp+10h] > 00000034: 29 C2 sub edx,eax > 00000036: 8B 45 14 mov eax,dword ptr [ebp+14h] > 00000039: 29 C2 sub edx,eax > 0000003B: 8B 45 DC mov eax,dword ptr [ebp-24h] > 0000003E: 83 E0 00 and eax,0 > 00000041: 09 D0 or eax,edx > 00000043: 89 45 DC mov dword ptr [ebp-24h],eax > 00000046: 8B 45 08 mov eax,dword ptr [ebp+8] > 00000049: 89 C2 mov edx,eax > 0000004B: 8D 45 D4 lea eax,[ebp-2Ch] > 0000004E: 8D 7D EC lea edi,[ebp-14h] > 00000051: 89 C6 mov esi,eax > 00000053: FC cld > 00000054: A5 movs dword ptr es:[edi],dword > ptr [esi] > 00000055: A5 movs dword ptr es:[edi],dword > ptr [esi] > 00000056: A5 movs dword ptr es:[edi],dword > ptr [esi] > 00000057: 89 D7 mov edi,edx > 00000059: 8D 75 EC lea esi,[ebp-14h] > 0000005C: FC cld > 0000005D: A5 movs dword ptr es:[edi],dword > ptr [esi] > 0000005E: A5 movs dword ptr es:[edi],dword > ptr [esi] > 0000005F: A5 movs dword ptr es:[edi],dword > ptr [esi] > 00000060: 83 C4 30 add esp,30h > 00000063: 5E pop esi > 00000064: 5F pop edi > 00000065: C9 leave > 00000066: C3 ret > > optimized Modula-3 is better, saves the extra copy, but still not > great: > > _T__F2: > 00000000: 55 push ebp > 00000001: 89 E5 mov ebp,esp > 00000003: 57 push edi > 00000004: 56 push esi > 00000005: 53 push ebx > 00000006: 83 EC 10 sub esp,10h > 00000009: 8B 55 0C mov edx,dword ptr [ebp+0Ch] > 0000000C: 8B 4D 10 mov ecx,dword ptr [ebp+10h] > 0000000F: 8B 5D 14 mov ebx,dword ptr [ebp+14h] > 00000012: 89 D0 mov eax,edx > 00000014: 0F AF C1 imul eax,ecx > 00000017: 0F AF C3 imul eax,ebx > 0000001A: 8B 75 E8 mov esi,dword ptr [ebp-18h] > 0000001D: 89 45 E8 mov dword ptr [ebp-18h],eax > 00000020: 8B 45 EC mov eax,dword ptr [ebp-14h] > 00000023: C7 45 EC 7B 00 00 mov dword ptr [ebp-14h],7Bh > 00 > 0000002A: 29 CA sub edx,ecx > 0000002C: 29 DA sub edx,ebx > > Huh what does this next instruction achieve? > 0000002E: 8B 45 F0 mov eax,dword ptr [ebp-10h] > 00000031: 89 55 F0 mov dword ptr [ebp-10h],edx > 00000034: 8B 7D 08 mov edi,dword ptr [ebp+8] > 00000037: 8D 75 E8 lea esi,[ebp-18h] > 0000003A: FC cld > 0000003B: A5 movs dword ptr es:[edi],dword > ptr [esi] > 0000003C: A5 movs dword ptr es:[edi],dword > ptr [esi] > 0000003D: A5 movs dword ptr es:[edi],dword > ptr [esi] > 0000003E: 83 C4 10 add esp,10h > 00000041: 5B pop ebx > 00000042: 5E pop esi > 00000043: 5F pop edi > 00000044: C9 leave > 00000045: C3 ret > > and lastly the integrated backend, which runs much faster, and I > believe has just one mode, > somewhat optimized (but still lacks int64 support): > > _T__F2: > 00000000: 55 push ebp > 00000001: 8B EC mov ebp,esp > 00000003: 81 EC 18 00 00 00 sub esp,18h > 00000009: 53 push ebx > 0000000A: 56 push esi > 0000000B: 57 push edi > 0000000C: 8B 5D 10 mov ebx,dword ptr [ebp+10h] > 0000000F: 0F AF 5D 0C imul ebx,dword ptr [ebp+0Ch] > 00000013: 0F AF 5D 14 imul ebx,dword ptr [ebp+14h] > 00000017: 89 5D F4 mov dword ptr [ebp-0Ch],ebx > 0000001A: C7 45 F8 7B 00 00 mov dword ptr [ebp-8],7Bh > 00 > 00000021: 8B 55 0C mov edx,dword ptr [ebp+0Ch] > 00000024: 2B 55 10 sub edx,dword ptr [ebp+10h] > 00000027: 2B 55 14 sub edx,dword ptr [ebp+14h] > 0000002A: 89 55 FC mov dword ptr [ebp-4],edx > 0000002D: 8D 75 F4 lea esi,[ebp-0Ch] > 00000030: 8B 7D 08 mov edi,dword ptr [ebp+8] > 00000033: 8B 4E 00 mov ecx,dword ptr [esi] > 00000036: 89 4F 00 mov dword ptr [edi],ecx > 00000039: 8B 4E 04 mov ecx,dword ptr [esi+4] > 0000003C: 89 4F 04 mov dword ptr [edi+4],ecx > 0000003F: 8B 4E 08 mov ecx,dword ptr [esi+8] > 00000042: 89 4F 08 mov dword ptr [edi+8],ecx > 00000045: 8B C7 mov eax,edi > 00000047: 5F pop edi > 00000048: 5E pop esi > 00000049: 5B pop ebx > 0000004A: C9 leave > 0000004B: C3 ret > > I haven't looked at all this in depth, but the doubling in size, > the extra copy, > that the integrated backend's code is fairly small... > > - Jay > > Shed those extra pounds with MSN and The Biggest Loser! Learn more. From hosking at cs.purdue.edu Mon Jan 21 16:59:35 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 21 Jan 2008 10:59:35 -0500 Subject: [M3devel] gcc/eh/setjmp In-Reply-To: References: Message-ID: I think gcc was forced not to act on it by use of LABEL_PRESERVE_P and FORCED_LABEL as well as making the function containing the TRY non-inlinable, plus lots of other goop to let the flow analyser know that funky stuff was going on at labels for TRY scopes. Take a look at the lines of parse.c that deal with "set_label" when "barrier=TRUE". On Jan 21, 2008, at 5:50 AM, Jay wrote: > Folks, try adding -Wunreachable-code to your m3back options and > tell me if you don't get loads of warnings. > for stuff like: > > TRY > return Foo(); > ELSE > return FALSE; > > I get them on NT386GNU and PPC_DARWIN. > > Functions with TRY need, in gcc parlance: > calls_setjmp > > and the exception/finally blocks need: > has_nonlocal_label > > and functions with RAISE might need: > has_nonlocal_goto > > Luckily, gcc doesn't seem to act on what it figure out. > > - Jay > > > > > > Helping your favorite cause is as easy as instant messaging. You > IM, we give. Learn more. From jayk123 at hotmail.com Mon Jan 21 17:06:37 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 21 Jan 2008 16:06:37 +0000 Subject: [M3devel] gcc/eh/setjmp In-Reply-To: References: Message-ID: Any chance of giving gcc enough or the right information so that -Wunreachable-code can be used without hitting a bunch of false positives? It's not being dumb, not that sort of false positive. It reports every except block and anything after a try { return } except { } as unreachable. - Jay > CC: m3devel at elegosoft.com> From: hosking at cs.purdue.edu> Subject: Re: [M3devel] gcc/eh/setjmp> Date: Mon, 21 Jan 2008 10:59:35 -0500> To: jayk123 at hotmail.com> > I think gcc was forced not to act on it by use of LABEL_PRESERVE_P > and FORCED_LABEL as well as making the function containing the TRY > non-inlinable, plus lots of other goop to let the flow analyser know > that funky stuff was going on at labels for TRY scopes. Take a look > at the lines of parse.c that deal with "set_label" when "barrier=TRUE".> > On Jan 21, 2008, at 5:50 AM, Jay wrote:> > > Folks, try adding -Wunreachable-code to your m3back options and > > tell me if you don't get loads of warnings.> > for stuff like:> >> > TRY> > return Foo();> > ELSE> > return FALSE;> >> > I get them on NT386GNU and PPC_DARWIN.> >> > Functions with TRY need, in gcc parlance:> > calls_setjmp> >> > and the exception/finally blocks need:> > has_nonlocal_label> >> > and functions with RAISE might need:> > has_nonlocal_goto> >> > Luckily, gcc doesn't seem to act on what it figure out.> >> > - Jay> >> >> >> >> >> > Helping your favorite cause is as easy as instant messaging. You > > IM, we give. 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 jayk123 at hotmail.com Mon Jan 21 17:04:45 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 21 Jan 2008 16:04:45 +0000 Subject: [M3devel] code quality.. In-Reply-To: <241EF32F-F814-4EB0-88A8-B3E413D1F4BE@cs.purdue.edu> References: <241EF32F-F814-4EB0-88A8-B3E413D1F4BE@cs.purdue.edu> Message-ID: backend. I think it is correct, if inefficient. - Jay > CC: m3devel at elegosoft.com> From: hosking at cs.purdue.edu> Subject: Re: [M3devel] code quality..> Date: Mon, 21 Jan 2008 11:01:52 -0500> To: jayk123 at hotmail.com> > Is this having the front-end handle return of structs or the backend?> > On Jan 21, 2008, at 9:50 AM, Jay wrote:> > > Unoptimized code quality is really bad,> > even compared to unoptimized C, even compared> > to gcc, and optimized code quality isn't great.> >> > I have this made up C code. I was verifying> > the struct return calling convention.> >> > typedef struct {> > unsigned a;> > unsigned b;> > unsigned c;> > } d;> >> > d F2(unsigned a, unsigned b, unsigned c)> > {> > d e;> > e.a = a * b * c;> > e.b = 123;> > e.c = a - b - c;> > return e;> > }> >> > and then the equivalent Modula-3:> >> > INTERFACE T;> >> > TYPE T1 = RECORD> > a,b,c : INTEGER> > END;> >> > PROCEDURE F2(a,b,c : INTEGER) : T1;> >> > END T.> >> > MODULE T;> >> > PROCEDURE F2(a,b,c : INTEGER) : T1 => > VAR> > e : T1;> > BEGIN> > e.a := (a * b * c);> > e.b := 123;> > e.c := (a - b - c);> > RETURN e;> > END F2;> >> > BEGIN> > END T.> >> > Unoptimized Visual C++ 8.0:> >> > _F2:> > 00000000: 55 push ebp> > 00000001: 8B EC mov ebp,esp> > 00000003: 83 EC 0C sub esp,0Ch> > 00000006: 8B 45 0C mov eax,dword ptr [ebp+0Ch]> > 00000009: 0F AF 45 10 imul eax,dword ptr [ebp+10h]> > 0000000D: 0F AF 45 14 imul eax,dword ptr [ebp+14h]> > 00000011: 89 45 F4 mov dword ptr [ebp-0Ch],eax> > 00000014: C7 45 F8 7B 00 00 mov dword ptr [ebp-8],7Bh> > 00> > 0000001B: 8B 4D 0C mov ecx,dword ptr [ebp+0Ch]> > 0000001E: 2B 4D 10 sub ecx,dword ptr [ebp+10h]> > 00000021: 2B 4D 14 sub ecx,dword ptr [ebp+14h]> > 00000024: 89 4D FC mov dword ptr [ebp-4],ecx> > 00000027: 8B 55 08 mov edx,dword ptr [ebp+8]> > 0000002A: 8B 45 F4 mov eax,dword ptr [ebp-0Ch]> > 0000002D: 89 02 mov dword ptr [edx],eax> > 0000002F: 8B 4D F8 mov ecx,dword ptr [ebp-8]> > 00000032: 89 4A 04 mov dword ptr [edx+4],ecx> > 00000035: 8B 45 FC mov eax,dword ptr [ebp-4]> > 00000038: 89 42 08 mov dword ptr [edx+8],eax> > 0000003B: 8B 45 08 mov eax,dword ptr [ebp+8]> > 0000003E: 8B E5 mov esp,ebp> > 00000040: 5D pop ebp> > 00000041: C3 ret> >> > Visual C++ 8.0 with /O1> >> > It writes the results right into the output.> > _F2:> > 00000000: 55 push ebp> > 00000001: 8B EC mov ebp,esp> > 00000003: 8B 4D 0C mov ecx,dword ptr [ebp+0Ch]> > 00000006: 8B 45 08 mov eax,dword ptr [ebp+8]> > 00000009: 8B D1 mov edx,ecx> > 0000000B: 0F AF 55 10 imul edx,dword ptr [ebp+10h]> > 0000000F: 0F AF 55 14 imul edx,dword ptr [ebp+14h]> > 00000013: 2B 4D 10 sub ecx,dword ptr [ebp+10h]> > 00000016: 89 10 mov dword ptr [eax],edx> > 00000018: 2B 4D 14 sub ecx,dword ptr [ebp+14h]> > 0000001B: C7 40 04 7B 00 00 mov dword ptr [eax+4],7Bh> > 00> > 00000022: 89 48 08 mov dword ptr [eax+8],ecx> > 00000025: 5D pop ebp> > 00000026: C3 ret> >> > with /O2> >> > _F2:> > 00000000: 8B 4C 24 08 mov ecx,dword ptr [esp+8]> > 00000004: 8B 54 24 0C mov edx,dword ptr [esp+0Ch]> > 00000008: 8B 44 24 04 mov eax,dword ptr [esp+4]> > 0000000C: 56 push esi> > 0000000D: 8B 74 24 14 mov esi,dword ptr [esp+14h]> > 00000011: 57 push edi> > 00000012: 8B F9 mov edi,ecx> > 00000014: 0F AF FA imul edi,edx> > 00000017: 0F AF FE imul edi,esi> > 0000001A: 2B CA sub ecx,edx> > 0000001C: 89 38 mov dword ptr [eax],edi> > 0000001E: 2B CE sub ecx,esi> > 00000020: 5F pop edi> > 00000021: C7 40 04 7B 00 00 mov dword ptr [eax+4],7Bh> > 00> > 00000028: 89 48 08 mov dword ptr [eax+8],ecx> > 0000002B: 5E pop esi> > 0000002C: C3 ret> >> > gcc 3.4.5 unoptimized> >> > _F2:> > 00000000: 55 push ebp> > 00000001: 89 E5 mov ebp,esp> > 00000003: 83 EC 18 sub esp,18h> > 00000006: 8B 4D 08 mov ecx,dword ptr [ebp+8]> > 00000009: 8B 45 0C mov eax,dword ptr [ebp+0Ch]> > 0000000C: 0F AF 45 10 imul eax,dword ptr [ebp+10h]> > 00000010: 0F AF 45 14 imul eax,dword ptr [ebp+14h]> > 00000014: 89 45 E8 mov dword ptr [ebp-18h],eax> > 00000017: C7 45 EC 7B 00 00 mov dword ptr [ebp-14h],7Bh> > 00> > 0000001E: 8B 55 10 mov edx,dword ptr [ebp+10h]> > 00000021: 8B 45 0C mov eax,dword ptr [ebp+0Ch]> > 00000024: 29 D0 sub eax,edx> > 00000026: 2B 45 14 sub eax,dword ptr [ebp+14h]> > 00000029: 89 45 F0 mov dword ptr [ebp-10h],eax> > 0000002C: 8B 45 E8 mov eax,dword ptr [ebp-18h]> > 0000002F: 89 01 mov dword ptr [ecx],eax> > 00000031: 8B 45 EC mov eax,dword ptr [ebp-14h]> > 00000034: 89 41 04 mov dword ptr [ecx+4],eax> > 00000037: 8B 45 F0 mov eax,dword ptr [ebp-10h]> > 0000003A: 89 41 08 mov dword ptr [ecx+8],eax> > 0000003D: 89 C8 mov eax,ecx> > 0000003F: C9 leave> > 00000040: C2 04 00 ret 4> > 00000043: 90 nop> > 00000044: 90 nop> > ...more nops for padding...> >> > gcc -O1> >> > _F2:> > 00000000: 55 push ebp> > 00000001: 89 E5 mov ebp,esp> > 00000003: 83 EC 18 sub esp,18h> > 00000006: 89 5D F8 mov dword ptr [ebp-8],ebx> > 00000009: 89 75 FC mov dword ptr [ebp-4],esi> > 0000000C: 8B 45 08 mov eax,dword ptr [ebp+8]> > 0000000F: 8B 4D 0C mov ecx,dword ptr [ebp+0Ch]> > 00000012: 8B 5D 10 mov ebx,dword ptr [ebp+10h]> > 00000015: 8B 75 14 mov esi,dword ptr [ebp+14h]> > 00000018: 89 CA mov edx,ecx> > 0000001A: 0F AF D3 imul edx,ebx> > 0000001D: 0F AF D6 imul edx,esi> > 00000020: 29 D9 sub ecx,ebx> > 00000022: 29 F1 sub ecx,esi> > 00000024: 89 10 mov dword ptr [eax],edx> > 00000026: C7 40 04 7B 00 00 mov dword ptr [eax+4],7Bh> > 00> > 0000002D: 89 48 08 mov dword ptr [eax+8],ecx> > 00000030: 8B 5D F8 mov ebx,dword ptr [ebp-8]> > 00000033: 8B 75 FC mov esi,dword ptr [ebp-4]> > 00000036: 89 EC mov esp,ebp> > 00000038: 5D pop ebp> > 00000039: C2 04 00 ret 4> > 0000003C: 90 nop> > 0000003D: 90 nop> > 0000003E: 90 nop> > 0000003F: 90 nop> >> > I didn't investigate all the switches much and simple -O vs. -O1 > > vs. -O2 vs. -o3> > all do the same.> >> > -O1 -fomit-frame-pointer netted:> >> > _F2:> > 00000000: 83 EC 1C sub esp,1Ch> > 00000003: 89 5C 24 14 mov dword ptr [esp+14h],ebx> > 00000007: 89 74 24 18 mov dword ptr [esp+18h],esi> > 0000000B: 8B 44 24 20 mov eax,dword ptr [esp+20h]> > 0000000F: 8B 4C 24 24 mov ecx,dword ptr [esp+24h]> > 00000013: 8B 5C 24 28 mov ebx,dword ptr [esp+28h]> > 00000017: 8B 74 24 2C mov esi,dword ptr [esp+2Ch]> > 0000001B: 89 CA mov edx,ecx> > 0000001D: 0F AF D3 imul edx,ebx> > 00000020: 0F AF D6 imul edx,esi> > 00000023: 29 D9 sub ecx,ebx> > 00000025: 29 F1 sub ecx,esi> > 00000027: 89 10 mov dword ptr [eax],edx> > 00000029: C7 40 04 7B 00 00 mov dword ptr [eax+4],7Bh> > 00> > 00000030: 89 48 08 mov dword ptr [eax+8],ecx> > 00000033: 8B 5C 24 14 mov ebx,dword ptr [esp+14h]> > 00000037: 8B 74 24 18 mov esi,dword ptr [esp+18h]> > 0000003B: 83 C4 1C add esp,1Ch> > 0000003E: C2 04 00 ret 4> > 00000041: 90 nop> > .. more nops ..> >> > Ok, ready, here goes the unoptimized Modula-3.> > Notice the duplicate copying of the return value and the *doubling* > > in code size.> >> > _T__F2:> > 00000000: 55 push ebp> > 00000001: 89 E5 mov ebp,esp> > 00000003: 57 push edi> > 00000004: 56 push esi> > 00000005: 83 EC 30 sub esp,30h> > 00000008: 8B 55 0C mov edx,dword ptr [ebp+0Ch]> > 0000000B: 8B 45 10 mov eax,dword ptr [ebp+10h]> > 0000000E: 0F AF D0 imul edx,eax> > 00000011: 8B 45 14 mov eax,dword ptr [ebp+14h]> > 00000014: 0F AF D0 imul edx,eax> > 00000017: 8B 45 D4 mov eax,dword ptr [ebp-2Ch]> > 0000001A: 83 E0 00 and eax,0> > 0000001D: 09 D0 or eax,edx> > 0000001F: 89 45 D4 mov dword ptr [ebp-2Ch],eax> > 00000022: 8B 45 D8 mov eax,dword ptr [ebp-28h]> > 00000025: 83 E0 00 and eax,0> > 00000028: 83 C8 7B or eax,7Bh> > 0000002B: 89 45 D8 mov dword ptr [ebp-28h],eax> > 0000002E: 8B 55 0C mov edx,dword ptr [ebp+0Ch]> > 00000031: 8B 45 10 mov eax,dword ptr [ebp+10h]> > 00000034: 29 C2 sub edx,eax> > 00000036: 8B 45 14 mov eax,dword ptr [ebp+14h]> > 00000039: 29 C2 sub edx,eax> > 0000003B: 8B 45 DC mov eax,dword ptr [ebp-24h]> > 0000003E: 83 E0 00 and eax,0> > 00000041: 09 D0 or eax,edx> > 00000043: 89 45 DC mov dword ptr [ebp-24h],eax> > 00000046: 8B 45 08 mov eax,dword ptr [ebp+8]> > 00000049: 89 C2 mov edx,eax> > 0000004B: 8D 45 D4 lea eax,[ebp-2Ch]> > 0000004E: 8D 7D EC lea edi,[ebp-14h]> > 00000051: 89 C6 mov esi,eax> > 00000053: FC cld> > 00000054: A5 movs dword ptr es:[edi],dword > > ptr [esi]> > 00000055: A5 movs dword ptr es:[edi],dword > > ptr [esi]> > 00000056: A5 movs dword ptr es:[edi],dword > > ptr [esi]> > 00000057: 89 D7 mov edi,edx> > 00000059: 8D 75 EC lea esi,[ebp-14h]> > 0000005C: FC cld> > 0000005D: A5 movs dword ptr es:[edi],dword > > ptr [esi]> > 0000005E: A5 movs dword ptr es:[edi],dword > > ptr [esi]> > 0000005F: A5 movs dword ptr es:[edi],dword > > ptr [esi]> > 00000060: 83 C4 30 add esp,30h> > 00000063: 5E pop esi> > 00000064: 5F pop edi> > 00000065: C9 leave> > 00000066: C3 ret> >> > optimized Modula-3 is better, saves the extra copy, but still not > > great:> >> > _T__F2:> > 00000000: 55 push ebp> > 00000001: 89 E5 mov ebp,esp> > 00000003: 57 push edi> > 00000004: 56 push esi> > 00000005: 53 push ebx> > 00000006: 83 EC 10 sub esp,10h> > 00000009: 8B 55 0C mov edx,dword ptr [ebp+0Ch]> > 0000000C: 8B 4D 10 mov ecx,dword ptr [ebp+10h]> > 0000000F: 8B 5D 14 mov ebx,dword ptr [ebp+14h]> > 00000012: 89 D0 mov eax,edx> > 00000014: 0F AF C1 imul eax,ecx> > 00000017: 0F AF C3 imul eax,ebx> > 0000001A: 8B 75 E8 mov esi,dword ptr [ebp-18h]> > 0000001D: 89 45 E8 mov dword ptr [ebp-18h],eax> > 00000020: 8B 45 EC mov eax,dword ptr [ebp-14h]> > 00000023: C7 45 EC 7B 00 00 mov dword ptr [ebp-14h],7Bh> > 00> > 0000002A: 29 CA sub edx,ecx> > 0000002C: 29 DA sub edx,ebx> >> > Huh what does this next instruction achieve?> > 0000002E: 8B 45 F0 mov eax,dword ptr [ebp-10h]> > 00000031: 89 55 F0 mov dword ptr [ebp-10h],edx> > 00000034: 8B 7D 08 mov edi,dword ptr [ebp+8]> > 00000037: 8D 75 E8 lea esi,[ebp-18h]> > 0000003A: FC cld> > 0000003B: A5 movs dword ptr es:[edi],dword > > ptr [esi]> > 0000003C: A5 movs dword ptr es:[edi],dword > > ptr [esi]> > 0000003D: A5 movs dword ptr es:[edi],dword > > ptr [esi]> > 0000003E: 83 C4 10 add esp,10h> > 00000041: 5B pop ebx> > 00000042: 5E pop esi> > 00000043: 5F pop edi> > 00000044: C9 leave> > 00000045: C3 ret> >> > and lastly the integrated backend, which runs much faster, and I > > believe has just one mode,> > somewhat optimized (but still lacks int64 support):> >> > _T__F2:> > 00000000: 55 push ebp> > 00000001: 8B EC mov ebp,esp> > 00000003: 81 EC 18 00 00 00 sub esp,18h> > 00000009: 53 push ebx> > 0000000A: 56 push esi> > 0000000B: 57 push edi> > 0000000C: 8B 5D 10 mov ebx,dword ptr [ebp+10h]> > 0000000F: 0F AF 5D 0C imul ebx,dword ptr [ebp+0Ch]> > 00000013: 0F AF 5D 14 imul ebx,dword ptr [ebp+14h]> > 00000017: 89 5D F4 mov dword ptr [ebp-0Ch],ebx> > 0000001A: C7 45 F8 7B 00 00 mov dword ptr [ebp-8],7Bh> > 00> > 00000021: 8B 55 0C mov edx,dword ptr [ebp+0Ch]> > 00000024: 2B 55 10 sub edx,dword ptr [ebp+10h]> > 00000027: 2B 55 14 sub edx,dword ptr [ebp+14h]> > 0000002A: 89 55 FC mov dword ptr [ebp-4],edx> > 0000002D: 8D 75 F4 lea esi,[ebp-0Ch]> > 00000030: 8B 7D 08 mov edi,dword ptr [ebp+8]> > 00000033: 8B 4E 00 mov ecx,dword ptr [esi]> > 00000036: 89 4F 00 mov dword ptr [edi],ecx> > 00000039: 8B 4E 04 mov ecx,dword ptr [esi+4]> > 0000003C: 89 4F 04 mov dword ptr [edi+4],ecx> > 0000003F: 8B 4E 08 mov ecx,dword ptr [esi+8]> > 00000042: 89 4F 08 mov dword ptr [edi+8],ecx> > 00000045: 8B C7 mov eax,edi> > 00000047: 5F pop edi> > 00000048: 5E pop esi> > 00000049: 5B pop ebx> > 0000004A: C9 leave> > 0000004B: C3 ret> >> > I haven't looked at all this in depth, but the doubling in size, > > the extra copy,> > that the integrated backend's code is fairly small...> >> > - Jay> >> > 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 Mon Jan 21 17:10:19 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 21 Jan 2008 16:10:19 +0000 Subject: [M3devel] next problem (NT386GNU) In-Reply-To: <6E1E4409-F3D9-4982-B179-2D4C9648FDD0@cs.purdue.edu> References: <6E1E4409-F3D9-4982-B179-2D4C9648FDD0@cs.purdue.edu> Message-ID: agreed once I thought about it I guess that explains left to right as well. Parameters are always left to right from a higher level point of view, and if that is wrong, the compiler will reorder. "everything" works now - Jay > CC: m3devel at elegosoft.com> From: hosking at cs.purdue.edu> Subject: Re: next problem (NT386GNU)> Date: Mon, 21 Jan 2008 10:54:10 -0500> To: jayk123 at hotmail.com> > Surely, when using the gcc-based backend then we should make the > backend handle it. The front end handling it is only need for the > integrated x86 backend.> > On Jan 21, 2008, at 2:43 AM, Jay wrote:> > > I haven't tested a fix but I see the problem.> >> > This function returns a struct.> > There are two struct returning calling conventions.> > In one, the backend handles it. Which includes the backend knowing > > there is a return value and its type (or at least its size?).> > In the other, the front end handles it. In this case, the front end > > generates passing an extra pointer parameter to the function, and > > the function's return type is void.> >> > The NT calling conventions, all of them, are marked as front end > > handling it. I assume that is correct, could check.> > Everything else is marked as back end handling.> >> > Now then, somewhere along the line, gcc figures out that the return > > value isn't used here.> > The point of the function call is to see if it generates an exception.> >> > Gcc removes the function because its return value isn't used, and, > > well, somehow it doesn't know about the exceptions here. I'll have > > to see how "raise" is implemented. I think it's by a call to a > > function that gets the jmpbuf from a thread local and calls > > longjmp. (Did I mention it is very inefficient?)> >> > There are few possible fixes, but nothing completely satisfactory > > yet in mind.> >> > One is have parse.c mark all function calls as having side affects. > > This is easy, but overly pessimistic.> > Another is for the front end to mark struct returning functions as > > having side affects. Better, but still overly pessimistic.> > Another is for the front end to mark any function that can raise as > > having side affects. Getting better still. I don't know how to do > > that but I'll look. This is still a bit overly pessimistic, since > > what you really want to know is, not the function's side affects, > > but whether or not it raised. If the function is inlined, the side > > affects could be optimized away, or if there are enough callers who > > don't care about the side affects to warrant an optimization, and > > depending on the cost of computing the side affects, another > > instance of the function could be made that only raises or not, but > > no side affects otherwise. This is "advanced" optimization the sort > > of which tends never to be implemented.> >> > I think the best option is anything that can raise is marked as > > having side affects.> > I'll see if I can figure that out.> >> > You can figure this out by looking at m3cgcat -binary < M3File.mc > > > 1.txt on PPC_DARWIN and NT386GNU and comparing.> >> > Maybe marking all or nearly functions as having side effects isn't > > so bad.> > Or at least anything returning a struct. That gets parity with > > other platforms, even if it is a bit pessimistic.> > I think I'll do that, and ignore figuring out if raise is called > > and using that as a filter.> > The parity angle is good.> >> > The good news for all you Unix lovers :) is this bug is relatively > > portable to Cygwin.> > True, it is specific to NT386GNU having multiple "calling > > conventions", which no other platform has.> > Which again, jokingly, strikes at the question -- What is Posix? > > What do you want from Cygwin?> > One thing Cygwin does NOT give you is just one calling convention, > > alas, this calling convention business stinks. It's not even an NT > > thing, only an NT386 thing. All the other NT platforms had/have > > only one calling convention.> >> > You can't get far on NT386 without needing to support two calling > > conventions.> > The "OS" uses mostly __stdcall -- callee pops -- smaller, faster.> > But anything that is varargs, such as printf -- pretty much must > > use caller pops -- __cdecl.> > As well, __cdecl is the default, so prevalent, and used in most C > > runtime functions.> > There is also __fastcall that uses like up to two registers for > > parameters.> >> > I have seen a platform in which printf did the pop, and it depended > > on the number/size of parameters matching the format string. On > > most platforms, printf("", 1, 2, 3, 4) just does nothing, but on > > that platform, it'd unbalance the stack and crash.> >> > - Jay> >> > From: jayk123 at hotmail.com> > To: hosking at cs.purdue.edu> > CC: m3devel at elegosoft.com> > Subject: next problem (NT386GNU)> > Date: Mon, 21 Jan 2008 05:47:28 +0000> >> > M3File.m3> >> > PROCEDURE IsReadable (path: TEXT): BOOLEAN => > (* We don't really check for readablitiy, just for existence *)> > BEGIN> > TRY> > EVAL FS.Status (path); line 82> > RETURN TRUE;> > EXCEPT OSError.E =>> > RETURN FALSE;> > END;> > END IsReadable;> >> > -----LINE 82 -----> > start_call_direct p.25 0 Struct> > load_address v.25 0> > pop_param Addr> > load v.26 0 Addr Addr> > pop_param Addr> > call_direct p.25 Struct> > pop Struct> >> >> >> > I'm guessing you only see an import for the first call on purpose, > > but I will compare with PPC_DARWIN:> >> > -----LINE 46 -----> > import_procedure FS__Status 2 Struct 0 p.25> > declare_indirect 2078421550 -2078421551> > declare_param _return 4 4 Addr 2078421550 F F 50 v.62> > declare_param p 4 4 Addr 1358456180 F F 50 v.63> > start_call_direct p.25 0 Struct> > load_address v.13 0> > pop_param Addr> > load v.14 0 Addr Addr> > pop_param Addr> > call_direct p.25 Struct> > pop Struct> >> >> > .globl _M3File__IsReadable> > .def _M3File__IsReadable; .scl 2; .type 32; .endef> > _M3File__IsReadable:> > .stabn 68,0,178,LM93-_M3File__IsReadable> > LM93:> > pushl %ebp> > movl %esp, %ebp> > pushl %edi> > pushl %esi> > pushl %ebx> > subl $300, %esp> > LBB15:> > .stabn 68,0,181,LM94-_M3File__IsReadable> > LM94:> > L157:> > movl -280(%ebp), %eax> > andl $0, %eax> > orl $_L_1, %eax> > movl %eax, -280(%ebp)> > movl -284(%ebp), %eax> > andl $0, %eax> > movl %eax, -284(%ebp)> > subl $12, %esp> > leal -288(%ebp), %eax> > pushl %eax> > call _RTHooks__PushEFrame> > addl $16, %esp> > leal -288(%ebp), %eax> > addl $48, %eax> > subl $12, %esp> > pushl %eax> > call __setjmp> > addl $16, %esp> > testb %al, %al> > jne L158> > .stabn 68,0,183,LM95-_M3File__IsReadable> > LM95:> > movl -288(%ebp), %eax> > subl $12, %esp> > pushl %eax> > call _RTHooks__PopEFrame> > addl $16, %esp> > movl $1, -304(%ebp)> > jmp L159> > L158:> > .stabn 68,0,185,LM96-_M3File__IsReadable> > LM96:> > movl $0, -304(%ebp)> > L159:> > LBE15:> > movl -304(%ebp), %eax> > leal -12(%ebp), %esp> > popl %ebx> > popl %esi> > popl %edi> > leave> > ret> >> >> > M3File.IsReadable's call to FS.Status is omitted, all files are > > readable, even if they are not openable, therefore it "finds" > > cm3.cfg in the current directory and then fails to open it..> >> > later..> > ..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! 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 jayk123 at hotmail.com Mon Jan 21 17:36:47 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 21 Jan 2008 16:36:47 +0000 Subject: [M3devel] broken record... Message-ID: Looking at the file names I'm about to announce are available... User could set OS_TYPE in config file or environment variable CM3_OSTYPE, to Posix or Win32, and everything else could go along.. POSIX-NT386GNU => paths all start with forward slash, Trestle is on X Windows, threads might be pthreads; WIN32-NT386GNU => paths tend toward backslashes, Trestle on Win32, threads are native, tools are GNU. Oh, and I guess people like libfoo.a, even though "lib" and ".a" seem redundant? Or don't care? - 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 Mon Jan 21 17:41:48 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 21 Jan 2008 16:41:48 +0000 Subject: [M3devel] NT386GNU distribution available Message-ID: Here, in my user directory on birch, is the first CM3 NT386GNU release.It is MinGWin based FOR NOW.This needs to be changed SOON. Install MinGWin. (Search the web for it.)set PATH=c:\MinGW\bin;%PATH% (The default install location is c:\MinGW, not MinGWin.) The MinGWin that Qt gives you is too old, from around 2004.It doesn't support "response files" (aka long command lines). If you want to rebuild m3cg: Install MSys. It is at the same place as MinGWin. set PATH=c:\msys\1.0\bin;%PATH% else consider set OMIT_GCC=yes depending on if you run the various scripts. If you install to these exact paths, scripts\python\pylib.py will use them automatically. Optionally install Python. I recommend it. Extract one or more of the archives. They will extract to like: cm3-min-WIN32-NT386GNU-d5.5.1\bin\cm3.exe You can rename it cm3, or for purposes of backup/restore, xcopy /fivery \cm3-min-WIN32-NT386GNU-d5.5.1 \cm3 (For extra good testing, first rmdir /q/s \cm3.) set PATH=c:\cm3\bin;%PATH% This is important, since various code will tend to assume NT386 unless overridden. set CM3_TARGET=NT386GNU Someone please weigh in on zip vs. tar.bz2 on the other Win32 platforms.For reference, MinGWin doesn't include tar/bzip2, MSys does, Cygwinhas tons of optional stuff, they are in there, probably the base. And then go to scripts\python and run whatever: upgrade or make-dist or do-cm3-core or do-cm3-base but not currently do-cm3-std scripts\win\upgrade works too. Do remember to set CM3_TARGET=NT386GNU. You will probably at some point be prompted to set CM3_ROOT to the root of the sourcetree as well. If you run "scripts", it will be set for you.If you cd around and run cm3, it won't. \cm3\bin\cm3.cfg delegates out to the source tree.Except the one in the distributions do not.But if you run upgrade, you'll have such a thing. If you want to rebuild cm3cg from source: cd m3-sys\m3cc\gcc\gcc\m3cg cvs update -j 1.46 -j 1.45 parse.c or thereabouts to get back enough of a __stdcall fix to build a lot. If you want to bootstrap without a previous NT386GNU distribution but with a previous NT386 build, try like this: Get a working NT386 system. Get current source (except parse.c). If your system is not current, scripts\python\upgrade This will work as far back as cm3-min-WIN32-NT386-5.1.3. scripts\python\bootntgnu which is really just roughly: do-pkg realclean m3core libm3 m3cc do-pkg buildship m3core libm3 m3cc set CM3_TARGET=NT386GNU Now you have the equivalent of the minimum distribution and can build whatever. do-pkg .... If you want to rollback a bit but not completely, scripts\win\pkggnu_clean.cmd is very simple and just deletes all the NT386GNU directories under $INSTALLROOT\pkg. There are "min", "core", and "base" distributions.Kind of subtle names, eh?"min" is sufficient.The binaries are all not "strippped". Last minute errata: There is bin\cm3.cfg and bin\NT386GNU. They are identical. The intent was only to have cm3.cfg there. The system builds itself, so that's pretty good. I forgot to include m3gdb, but it should probably be in a separate "GNU" archive? Someone move the files to a web download place? (and you can move, not copy, I can easily recreate the files) - Jay _________________________________________________________________ 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 Mon Jan 21 17:57:29 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 21 Jan 2008 11:57:29 -0500 Subject: [M3devel] gcc/eh/setjmp In-Reply-To: References: Message-ID: <0ECB2F81-C843-409C-AB24-A837EA93F083@cs.purdue.edu> Yeah, we should be able to do that. I wonder if setting DECL_NONLOCAL on barrier labels will do the trick? On Jan 21, 2008, at 11:06 AM, Jay wrote: > Any chance of giving gcc enough or the right information so that - > Wunreachable-code can be used without hitting a bunch of false > positives? It's not being dumb, not that sort of false positive. It > reports every except block and anything after a try { return } > except { } as unreachable. > > - Jay > > > > > CC: m3devel at elegosoft.com > > From: hosking at cs.purdue.edu > > Subject: Re: [M3devel] gcc/eh/setjmp > > Date: Mon, 21 Jan 2008 10:59:35 -0500 > > To: jayk123 at hotmail.com > > > > I think gcc was forced not to act on it by use of LABEL_PRESERVE_P > > and FORCED_LABEL as well as making the function containing the TRY > > non-inlinable, plus lots of other goop to let the flow analyser know > > that funky stuff was going on at labels for TRY scopes. Take a look > > at the lines of parse.c that deal with "set_label" when > "barrier=TRUE". > > > > On Jan 21, 2008, at 5:50 AM, Jay wrote: > > > > > Folks, try adding -Wunreachable-code to your m3back options and > > > tell me if you don't get loads of warnings. > > > for stuff like: > > > > > > TRY > > > return Foo(); > > > ELSE > > > return FALSE; > > > > > > I get them on NT386GNU and PPC_DARWIN. > > > > > > Functions with TRY need, in gcc parlance: > > > calls_setjmp > > > > > > and the exception/finally blocks need: > > > has_nonlocal_label > > > > > > and functions with RAISE might need: > > > has_nonlocal_goto > > > > > > Luckily, gcc doesn't seem to act on what it figure out. > > > > > > - Jay > > > > > > > > > > > > > > > > > > Helping your favorite cause is as easy as instant messaging. You > > > IM, we give. Learn more. > > > > > Shed those extra pounds with MSN and The Biggest Loser! Learn more. From hosking at cs.purdue.edu Mon Jan 21 18:01:28 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 21 Jan 2008 12:01:28 -0500 Subject: [M3devel] next problem (NT386GNU) In-Reply-To: References: <6E1E4409-F3D9-4982-B179-2D4C9648FDD0@cs.purdue.edu> Message-ID: I just need to fix m3cc/cm3cg to emit the stdcall parameter information for imported procedures. It is simply a matter of not ignoring declare_param for import_procedure chunks. This means maintaining a current_function_decl (and possibly a current_param_count) stack (since import_procedure can occur inside a declare_procedure chunk). I know what needs doing, but have not much free time right now... On Jan 21, 2008, at 11:10 AM, Jay wrote: > agreed once I thought about it > I guess that explains left to right as well. > Parameters are always left to right from a higher level point of > view, and if that is wrong, the compiler will reorder. > > "everything" works now > > - Jay > > > > > CC: m3devel at elegosoft.com > > From: hosking at cs.purdue.edu > > Subject: Re: next problem (NT386GNU) > > Date: Mon, 21 Jan 2008 10:54:10 -0500 > > To: jayk123 at hotmail.com > > > > Surely, when using the gcc-based backend then we should make the > > backend handle it. The front end handling it is only need for the > > integrated x86 backend. > > > > On Jan 21, 2008, at 2:43 AM, Jay wrote: > > > > > I haven't tested a fix but I see the problem. > > > > > > This function returns a struct. > > > There are two struct returning calling conventions. > > > In one, the backend handles it. Which includes the backend knowing > > > there is a return value and its type (or at least its size?). > > > In the other, the front end handles it. In this case, the front > end > > > generates passing an extra pointer parameter to the function, and > > > the function's return type is void. > > > > > > The NT calling conventions, all of them, are marked as front end > > > handling it. I assume that is correct, could check. > > > Everything else is marked as back end handling. > > > > > > Now then, somewhere along the line, gcc figures out that the > return > > > value isn't used here. > > > The point of the function call is to see if it generates an > exception. > > > > > > Gcc removes the function because its return value isn't used, and, > > > well, somehow it doesn't know about the exceptions here. I'll have > > > to see how "raise" is implemented. I think it's by a call to a > > > function that gets the jmpbuf from a thread local and calls > > > longjmp. (Did I mention it is very inefficient?) > > > > > > There are few possible fixes, but nothing completely satisfactory > > > yet in mind. > > > > > > One is have parse.c mark all function calls as having side > affects. > > > This is easy, but overly pessimistic. > > > Another is for the front end to mark struct returning functions as > > > having side affects. Better, but still overly pessimistic. > > > Another is for the front end to mark any function that can > raise as > > > having side affects. Getting better still. I don't know how to do > > > that but I'll look. This is still a bit overly pessimistic, since > > > what you really want to know is, not the function's side affects, > > > but whether or not it raised. If the function is inlined, the side > > > affects could be optimized away, or if there are enough callers > who > > > don't care about the side affects to warrant an optimization, and > > > depending on the cost of computing the side affects, another > > > instance of the function could be made that only raises or not, > but > > > no side affects otherwise. This is "advanced" optimization the > sort > > > of which tends never to be implemented. > > > > > > I think the best option is anything that can raise is marked as > > > having side affects. > > > I'll see if I can figure that out. > > > > > > You can figure this out by looking at m3cgcat -binary < > M3File.mc > > > > 1.txt on PPC_DARWIN and NT386GNU and comparing. > > > > > > Maybe marking all or nearly functions as having side effects isn't > > > so bad. > > > Or at least anything returning a struct. That gets parity with > > > other platforms, even if it is a bit pessimistic. > > > I think I'll do that, and ignore figuring out if raise is called > > > and using that as a filter. > > > The parity angle is good. > > > > > > The good news for all you Unix lovers :) is this bug is relatively > > > portable to Cygwin. > > > True, it is specific to NT386GNU having multiple "calling > > > conventions", which no other platform has. > > > Which again, jokingly, strikes at the question -- What is Posix? > > > What do you want from Cygwin? > > > One thing Cygwin does NOT give you is just one calling convention, > > > alas, this calling convention business stinks. It's not even an NT > > > thing, only an NT386 thing. All the other NT platforms had/have > > > only one calling convention. > > > > > > You can't get far on NT386 without needing to support two calling > > > conventions. > > > The "OS" uses mostly __stdcall -- callee pops -- smaller, faster. > > > But anything that is varargs, such as printf -- pretty much must > > > use caller pops -- __cdecl. > > > As well, __cdecl is the default, so prevalent, and used in most C > > > runtime functions. > > > There is also __fastcall that uses like up to two registers for > > > parameters. > > > > > > I have seen a platform in which printf did the pop, and it > depended > > > on the number/size of parameters matching the format string. On > > > most platforms, printf("", 1, 2, 3, 4) just does nothing, but on > > > that platform, it'd unbalance the stack and crash. > > > > > > - Jay > > > > > > From: jayk123 at hotmail.com > > > To: hosking at cs.purdue.edu > > > CC: m3devel at elegosoft.com > > > Subject: next problem (NT386GNU) > > > Date: Mon, 21 Jan 2008 05:47:28 +0000 > > > > > > M3File.m3 > > > > > > PROCEDURE IsReadable (path: TEXT): BOOLEAN = > > > (* We don't really check for readablitiy, just for existence *) > > > BEGIN > > > TRY > > > EVAL FS.Status (path); line 82 > > > RETURN TRUE; > > > EXCEPT OSError.E => > > > RETURN FALSE; > > > END; > > > END IsReadable; > > > > > > -----LINE 82 ----- > > > start_call_direct p.25 0 Struct > > > load_address v.25 0 > > > pop_param Addr > > > load v.26 0 Addr Addr > > > pop_param Addr > > > call_direct p.25 Struct > > > pop Struct > > > > > > > > > > > > I'm guessing you only see an import for the first call on purpose, > > > but I will compare with PPC_DARWIN: > > > > > > -----LINE 46 ----- > > > import_procedure FS__Status 2 Struct 0 p.25 > > > declare_indirect 2078421550 -2078421551 > > > declare_param _return 4 4 Addr 2078421550 F F 50 v.62 > > > declare_param p 4 4 Addr 1358456180 F F 50 v.63 > > > start_call_direct p.25 0 Struct > > > load_address v.13 0 > > > pop_param Addr > > > load v.14 0 Addr Addr > > > pop_param Addr > > > call_direct p.25 Struct > > > pop Struct > > > > > > > > > .globl _M3File__IsReadable > > > .def _M3File__IsReadable; .scl 2; .type 32; .endef > > > _M3File__IsReadable: > > > .stabn 68,0,178,LM93-_M3File__IsReadable > > > LM93: > > > pushl %ebp > > > movl %esp, %ebp > > > pushl %edi > > > pushl %esi > > > pushl %ebx > > > subl $300, %esp > > > LBB15: > > > .stabn 68,0,181,LM94-_M3File__IsReadable > > > LM94: > > > L157: > > > movl -280(%ebp), %eax > > > andl $0, %eax > > > orl $_L_1, %eax > > > movl %eax, -280(%ebp) > > > movl -284(%ebp), %eax > > > andl $0, %eax > > > movl %eax, -284(%ebp) > > > subl $12, %esp > > > leal -288(%ebp), %eax > > > pushl %eax > > > call _RTHooks__PushEFrame > > > addl $16, %esp > > > leal -288(%ebp), %eax > > > addl $48, %eax > > > subl $12, %esp > > > pushl %eax > > > call __setjmp > > > addl $16, %esp > > > testb %al, %al > > > jne L158 > > > .stabn 68,0,183,LM95-_M3File__IsReadable > > > LM95: > > > movl -288(%ebp), %eax > > > subl $12, %esp > > > pushl %eax > > > call _RTHooks__PopEFrame > > > addl $16, %esp > > > movl $1, -304(%ebp) > > > jmp L159 > > > L158: > > > .stabn 68,0,185,LM96-_M3File__IsReadable > > > LM96: > > > movl $0, -304(%ebp) > > > L159: > > > LBE15: > > > movl -304(%ebp), %eax > > > leal -12(%ebp), %esp > > > popl %ebx > > > popl %esi > > > popl %edi > > > leave > > > ret > > > > > > > > > M3File.IsReadable's call to FS.Status is omitted, all files are > > > readable, even if they are not openable, therefore it "finds" > > > cm3.cfg in the current directory and then fails to open it.. > > > > > > later.. > > > ..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! Learn > more. > > > > > Shed those extra pounds with MSN and The Biggest Loser! Learn more. From hosking at cs.purdue.edu Mon Jan 21 18:02:12 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 21 Jan 2008 12:02:12 -0500 Subject: [M3devel] broken record... In-Reply-To: References: Message-ID: <659E4F4F-3A52-4269-9F4F-790613E14530@cs.purdue.edu> On Jan 21, 2008, at 11:36 AM, Jay wrote: > Looking at the file names I'm about to announce are available... > > User could set OS_TYPE in config file or environment variable > CM3_OSTYPE, to Posix or Win32, and everything else could go along.. > POSIX-NT386GNU => paths all start with forward slash, Trestle is on > X Windows, threads might be pthreads; WIN32-NT386GNU => paths tend > toward backslashes, Trestle on Win32, threads are native, tools are > GNU. > > Oh, and I guess people like libfoo.a, even though "lib" and ".a" > seem redundant? Don't care really. Standard on Unix is lib*.a. > > Or don't care? > > - Jay > > > > > > Climb to the top of the charts! Play the word scramble challenge > with star power. Play now! From jayk123 at hotmail.com Mon Jan 21 23:16:54 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 21 Jan 2008 22:16:54 +0000 Subject: [M3devel] next problem (NT386GNU) In-Reply-To: References: <6E1E4409-F3D9-4982-B179-2D4C9648FDD0@cs.purdue.edu> Message-ID: Understood. Put back my parse.c in the meantime? Also, the front end could do this, right? And probably without a stack? It could compute "effective parameter size" and pass that down. Backend could then divide by 4 and claim that is the signature, that number of parameters. Would have to see how passing a struct works out anyway -- one parameter or one per field. - Jay > CC: m3devel at elegosoft.com > From: hosking at cs.purdue.edu > Subject: Re: next problem (NT386GNU) > Date: Mon, 21 Jan 2008 12:01:28 -0500 > To: jayk123 at hotmail.com > > I just need to fix m3cc/cm3cg to emit the stdcall parameter > information for imported procedures. It is simply a matter of not > ignoring declare_param for import_procedure chunks. This means > maintaining a current_function_decl (and possibly a > current_param_count) stack (since import_procedure can occur inside a > declare_procedure chunk). I know what needs doing, but have not much > free time right now... > > On Jan 21, 2008, at 11:10 AM, Jay wrote: > > > agreed once I thought about it > > I guess that explains left to right as well. > > Parameters are always left to right from a higher level point of > > view, and if that is wrong, the compiler will reorder. > > > > "everything" works now > > > > - Jay > > > > > > > > > CC: m3devel at elegosoft.com > > > From: hosking at cs.purdue.edu > > > Subject: Re: next problem (NT386GNU) > > > Date: Mon, 21 Jan 2008 10:54:10 -0500 > > > To: jayk123 at hotmail.com > > > > > > Surely, when using the gcc-based backend then we should make the > > > backend handle it. The front end handling it is only need for the > > > integrated x86 backend. > > > > > > On Jan 21, 2008, at 2:43 AM, Jay wrote: > > > > > > > I haven't tested a fix but I see the problem. > > > > > > > > This function returns a struct. > > > > There are two struct returning calling conventions. > > > > In one, the backend handles it. Which includes the backend knowing > > > > there is a return value and its type (or at least its size?). > > > > In the other, the front end handles it. In this case, the front > > end > > > > generates passing an extra pointer parameter to the function, and > > > > the function's return type is void. > > > > > > > > The NT calling conventions, all of them, are marked as front end > > > > handling it. I assume that is correct, could check. > > > > Everything else is marked as back end handling. > > > > > > > > Now then, somewhere along the line, gcc figures out that the > > return > > > > value isn't used here. > > > > The point of the function call is to see if it generates an > > exception. > > > > > > > > Gcc removes the function because its return value isn't used, and, > > > > well, somehow it doesn't know about the exceptions here. I'll have > > > > to see how "raise" is implemented. I think it's by a call to a > > > > function that gets the jmpbuf from a thread local and calls > > > > longjmp. (Did I mention it is very inefficient?) > > > > > > > > There are few possible fixes, but nothing completely satisfactory > > > > yet in mind. > > > > > > > > One is have parse.c mark all function calls as having side > > affects. > > > > This is easy, but overly pessimistic. > > > > Another is for the front end to mark struct returning functions as > > > > having side affects. Better, but still overly pessimistic. > > > > Another is for the front end to mark any function that can > > raise as > > > > having side affects. Getting better still. I don't know how to do > > > > that but I'll look. This is still a bit overly pessimistic, since > > > > what you really want to know is, not the function's side affects, > > > > but whether or not it raised. If the function is inlined, the side > > > > affects could be optimized away, or if there are enough callers > > who > > > > don't care about the side affects to warrant an optimization, and > > > > depending on the cost of computing the side affects, another > > > > instance of the function could be made that only raises or not, > > but > > > > no side affects otherwise. This is "advanced" optimization the > > sort > > > > of which tends never to be implemented. > > > > > > > > I think the best option is anything that can raise is marked as > > > > having side affects. > > > > I'll see if I can figure that out. > > > > > > > > You can figure this out by looking at m3cgcat -binary < > > M3File.mc > > > > > 1.txt on PPC_DARWIN and NT386GNU and comparing. > > > > > > > > Maybe marking all or nearly functions as having side effects isn't > > > > so bad. > > > > Or at least anything returning a struct. That gets parity with > > > > other platforms, even if it is a bit pessimistic. > > > > I think I'll do that, and ignore figuring out if raise is called > > > > and using that as a filter. > > > > The parity angle is good. > > > > > > > > The good news for all you Unix lovers :) is this bug is relatively > > > > portable to Cygwin. > > > > True, it is specific to NT386GNU having multiple "calling > > > > conventions", which no other platform has. > > > > Which again, jokingly, strikes at the question -- What is Posix? > > > > What do you want from Cygwin? > > > > One thing Cygwin does NOT give you is just one calling convention, > > > > alas, this calling convention business stinks. It's not even an NT > > > > thing, only an NT386 thing. All the other NT platforms had/have > > > > only one calling convention. > > > > > > > > You can't get far on NT386 without needing to support two calling > > > > conventions. > > > > The "OS" uses mostly __stdcall -- callee pops -- smaller, faster. > > > > But anything that is varargs, such as printf -- pretty much must > > > > use caller pops -- __cdecl. > > > > As well, __cdecl is the default, so prevalent, and used in most C > > > > runtime functions. > > > > There is also __fastcall that uses like up to two registers for > > > > parameters. > > > > > > > > I have seen a platform in which printf did the pop, and it > > depended > > > > on the number/size of parameters matching the format string. On > > > > most platforms, printf("", 1, 2, 3, 4) just does nothing, but on > > > > that platform, it'd unbalance the stack and crash. > > > > > > > > - Jay > > > > > > > > From: jayk123 at hotmail.com > > > > To: hosking at cs.purdue.edu > > > > CC: m3devel at elegosoft.com > > > > Subject: next problem (NT386GNU) > > > > Date: Mon, 21 Jan 2008 05:47:28 +0000 > > > > > > > > M3File.m3 > > > > > > > > PROCEDURE IsReadable (path: TEXT): BOOLEAN = > > > > (* We don't really check for readablitiy, just for existence *) > > > > BEGIN > > > > TRY > > > > EVAL FS.Status (path); line 82 > > > > RETURN TRUE; > > > > EXCEPT OSError.E => > > > > RETURN FALSE; > > > > END; > > > > END IsReadable; > > > > > > > > -----LINE 82 ----- > > > > start_call_direct p.25 0 Struct > > > > load_address v.25 0 > > > > pop_param Addr > > > > load v.26 0 Addr Addr > > > > pop_param Addr > > > > call_direct p.25 Struct > > > > pop Struct > > > > > > > > > > > > > > > > I'm guessing you only see an import for the first call on purpose, > > > > but I will compare with PPC_DARWIN: > > > > > > > > -----LINE 46 ----- > > > > import_procedure FS__Status 2 Struct 0 p.25 > > > > declare_indirect 2078421550 -2078421551 > > > > declare_param _return 4 4 Addr 2078421550 F F 50 v.62 > > > > declare_param p 4 4 Addr 1358456180 F F 50 v.63 > > > > start_call_direct p.25 0 Struct > > > > load_address v.13 0 > > > > pop_param Addr > > > > load v.14 0 Addr Addr > > > > pop_param Addr > > > > call_direct p.25 Struct > > > > pop Struct > > > > > > > > > > > > .globl _M3File__IsReadable > > > > .def _M3File__IsReadable; .scl 2; .type 32; .endef > > > > _M3File__IsReadable: > > > > .stabn 68,0,178,LM93-_M3File__IsReadable > > > > LM93: > > > > pushl %ebp > > > > movl %esp, %ebp > > > > pushl %edi > > > > pushl %esi > > > > pushl %ebx > > > > subl $300, %esp > > > > LBB15: > > > > .stabn 68,0,181,LM94-_M3File__IsReadable > > > > LM94: > > > > L157: > > > > movl -280(%ebp), %eax > > > > andl $0, %eax > > > > orl $_L_1, %eax > > > > movl %eax, -280(%ebp) > > > > movl -284(%ebp), %eax > > > > andl $0, %eax > > > > movl %eax, -284(%ebp) > > > > subl $12, %esp > > > > leal -288(%ebp), %eax > > > > pushl %eax > > > > call _RTHooks__PushEFrame > > > > addl $16, %esp > > > > leal -288(%ebp), %eax > > > > addl $48, %eax > > > > subl $12, %esp > > > > pushl %eax > > > > call __setjmp > > > > addl $16, %esp > > > > testb %al, %al > > > > jne L158 > > > > .stabn 68,0,183,LM95-_M3File__IsReadable > > > > LM95: > > > > movl -288(%ebp), %eax > > > > subl $12, %esp > > > > pushl %eax > > > > call _RTHooks__PopEFrame > > > > addl $16, %esp > > > > movl $1, -304(%ebp) > > > > jmp L159 > > > > L158: > > > > .stabn 68,0,185,LM96-_M3File__IsReadable > > > > LM96: > > > > movl $0, -304(%ebp) > > > > L159: > > > > LBE15: > > > > movl -304(%ebp), %eax > > > > leal -12(%ebp), %esp > > > > popl %ebx > > > > popl %esi > > > > popl %edi > > > > leave > > > > ret > > > > > > > > > > > > M3File.IsReadable's call to FS.Status is omitted, all files are > > > > readable, even if they are not openable, therefore it "finds" > > > > cm3.cfg in the current directory and then fails to open it.. > > > > > > > > later.. > > > > ..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! Learn > > more. > > > > > > > > > Shed those extra pounds with MSN and The Biggest Loser! Learn more. > _________________________________________________________________ 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 Jan 21 23:32:32 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 21 Jan 2008 17:32:32 -0500 Subject: [M3devel] next problem (NT386GNU) In-Reply-To: References: <6E1E4409-F3D9-4982-B179-2D4C9648FDD0@cs.purdue.edu> Message-ID: <1A6EC7D6-32B2-44AD-933F-6976040A7D7F@cs.purdue.edu> I'd prefer to have the backend do it properly based on properly declared types. I'd prefer to keep this code out of the current mainline of parse.c -- you could fork a temporary branch if necessary. On Jan 21, 2008, at 5:16 PM, Jay wrote: > Understood. Put back my parse.c in the meantime? > > Also, the front end could do this, right? And probably without a > stack? > It could compute "effective parameter size" and pass that down. > Backend could then divide by 4 and claim that is the signature, > that number of parameters. > > Would have to see how passing a struct works out anyway -- one > parameter > or one per field. > > - Jay > > > > CC: m3devel at elegosoft.com > > From: hosking at cs.purdue.edu > > Subject: Re: next problem (NT386GNU) > > Date: Mon, 21 Jan 2008 12:01:28 -0500 > > To: jayk123 at hotmail.com > > > > I just need to fix m3cc/cm3cg to emit the stdcall parameter > > information for imported procedures. It is simply a matter of not > > ignoring declare_param for import_procedure chunks. This means > > maintaining a current_function_decl (and possibly a > > current_param_count) stack (since import_procedure can occur > inside a > > declare_procedure chunk). I know what needs doing, but have not much > > free time right now... > > > > On Jan 21, 2008, at 11:10 AM, Jay wrote: > > > > > agreed once I thought about it > > > I guess that explains left to right as well. > > > Parameters are always left to right from a higher level point of > > > view, and if that is wrong, the compiler will reorder. > > > > > > "everything" works now > > > > > > - Jay > > > > > > > > > > > > > CC: m3devel at elegosoft.com > > > > From: hosking at cs.purdue.edu > > > > Subject: Re: next problem (NT386GNU) > > > > Date: Mon, 21 Jan 2008 10:54:10 -0500 > > > > To: jayk123 at hotmail.com > > > > > > > > Surely, when using the gcc-based backend then we should make the > > > > backend handle it. The front end handling it is only need for > the > > > > integrated x86 backend. > > > > > > > > On Jan 21, 2008, at 2:43 AM, Jay wrote: > > > > > > > > > I haven't tested a fix but I see the problem. > > > > > > > > > > This function returns a struct. > > > > > There are two struct returning calling conventions. > > > > > In one, the backend handles it. Which includes the backend > knowing > > > > > there is a return value and its type (or at least its size?). > > > > > In the other, the front end handles it. In this case, the > front > > > end > > > > > generates passing an extra pointer parameter to the > function, and > > > > > the function's return type is void. > > > > > > > > > > The NT calling conventions, all of them, are marked as > front end > > > > > handling it. I assume that is correct, could check. > > > > > Everything else is marked as back end handling. > > > > > > > > > > Now then, somewhere along the line, gcc figures out that the > > > return > > > > > value isn't used here. > > > > > The point of the function call is to see if it generates an > > > exception. > > > > > > > > > > Gcc removes the function because its return value isn't > used, and, > > > > > well, somehow it doesn't know about the exceptions here. > I'll have > > > > > to see how "raise" is implemented. I think it's by a call to a > > > > > function that gets the jmpbuf from a thread local and calls > > > > > longjmp. (Did I mention it is very inefficient?) > > > > > > > > > > There are few possible fixes, but nothing completely > satisfactory > > > > > yet in mind. > > > > > > > > > > One is have parse.c mark all function calls as having side > > > affects. > > > > > This is easy, but overly pessimistic. > > > > > Another is for the front end to mark struct returning > functions as > > > > > having side affects. Better, but still overly pessimistic. > > > > > Another is for the front end to mark any function that can > > > raise as > > > > > having side affects. Getting better still. I don't know how > to do > > > > > that but I'll look. This is still a bit overly pessimistic, > since > > > > > what you really want to know is, not the function's side > affects, > > > > > but whether or not it raised. If the function is inlined, > the side > > > > > affects could be optimized away, or if there are enough > callers > > > who > > > > > don't care about the side affects to warrant an > optimization, and > > > > > depending on the cost of computing the side affects, another > > > > > instance of the function could be made that only raises or > not, > > > but > > > > > no side affects otherwise. This is "advanced" optimization the > > > sort > > > > > of which tends never to be implemented. > > > > > > > > > > I think the best option is anything that can raise is > marked as > > > > > having side affects. > > > > > I'll see if I can figure that out. > > > > > > > > > > You can figure this out by looking at m3cgcat -binary < > > > M3File.mc > > > > > > 1.txt on PPC_DARWIN and NT386GNU and comparing. > > > > > > > > > > Maybe marking all or nearly functions as having side > effects isn't > > > > > so bad. > > > > > Or at least anything returning a struct. That gets parity with > > > > > other platforms, even if it is a bit pessimistic. > > > > > I think I'll do that, and ignore figuring out if raise is > called > > > > > and using that as a filter. > > > > > The parity angle is good. > > > > > > > > > > The good news for all you Unix lovers :) is this bug is > relatively > > > > > portable to Cygwin. > > > > > True, it is specific to NT386GNU having multiple "calling > > > > > conventions", which no other platform has. > > > > > Which again, jokingly, strikes at the question -- What is > Posix? > > > > > What do you want from Cygwin? > > > > > One thing Cygwin does NOT give you is just one calling > convention, > > > > > alas, this calling convention business stinks. It's not > even an NT > > > > > thing, only an NT386 thing. All the other NT platforms had/ > have > > > > > only one calling convention. > > > > > > > > > > You can't get far on NT386 without needing to support two > calling > > > > > conventions. > > > > > The "OS" uses mostly __stdcall -- callee pops -- smaller, > faster. > > > > > But anything that is varargs, such as printf -- pretty much > must > > > > > use caller pops -- __cdecl. > > > > > As well, __cdecl is the default, so prevalent, and used in > most C > > > > > runtime functions. > > > > > There is also __fastcall that uses like up to two registers > for > > > > > parameters. > > > > > > > > > > I have seen a platform in which printf did the pop, and it > > > depended > > > > > on the number/size of parameters matching the format > string. On > > > > > most platforms, printf("", 1, 2, 3, 4) just does nothing, > but on > > > > > that platform, it'd unbalance the stack and crash. > > > > > > > > > > - Jay > > > > > > > > > > From: jayk123 at hotmail.com > > > > > To: hosking at cs.purdue.edu > > > > > CC: m3devel at elegosoft.com > > > > > Subject: next problem (NT386GNU) > > > > > Date: Mon, 21 Jan 2008 05:47:28 +0000 > > > > > > > > > > M3File.m3 > > > > > > > > > > PROCEDURE IsReadable (path: TEXT): BOOLEAN = > > > > > (* We don't really check for readablitiy, just for > existence *) > > > > > BEGIN > > > > > TRY > > > > > EVAL FS.Status (path); line 82 > > > > > RETURN TRUE; > > > > > EXCEPT OSError.E => > > > > > RETURN FALSE; > > > > > END; > > > > > END IsReadable; > > > > > > > > > > -----LINE 82 ----- > > > > > start_call_direct p.25 0 Struct > > > > > load_address v.25 0 > > > > > pop_param Addr > > > > > load v.26 0 Addr Addr > > > > > pop_param Addr > > > > > call_direct p.25 Struct > > > > > pop Struct > > > > > > > > > > > > > > > > > > > > I'm guessing you only see an import for the first call on > purpose, > > > > > but I will compare with PPC_DARWIN: > > > > > > > > > > -----LINE 46 ----- > > > > > import_procedure FS__Status 2 Struct 0 p.25 > > > > > declare_indirect 2078421550 -2078421551 > > > > > declare_param _return 4 4 Addr 2078421550 F F 50 v.62 > > > > > declare_param p 4 4 Addr 1358456180 F F 50 v.63 > > > > > start_call_direct p.25 0 Struct > > > > > load_address v.13 0 > > > > > pop_param Addr > > > > > load v.14 0 Addr Addr > > > > > pop_param Addr > > > > > call_direct p.25 Struct > > > > > pop Struct > > > > > > > > > > > > > > > .globl _M3File__IsReadable > > > > > .def _M3File__IsReadable; .scl 2; .type 32; .endef > > > > > _M3File__IsReadable: > > > > > .stabn 68,0,178,LM93-_M3File__IsReadable > > > > > LM93: > > > > > pushl %ebp > > > > > movl %esp, %ebp > > > > > pushl %edi > > > > > pushl %esi > > > > > pushl %ebx > > > > > subl $300, %esp > > > > > LBB15: > > > > > .stabn 68,0,181,LM94-_M3File__IsReadable > > > > > LM94: > > > > > L157: > > > > > movl -280(%ebp), %eax > > > > > andl $0, %eax > > > > > orl $_L_1, %eax > > > > > movl %eax, -280(%ebp) > > > > > movl -284(%ebp), %eax > > > > > andl $0, %eax > > > > > movl %eax, -284(%ebp) > > > > > subl $12, %esp > > > > > leal -288(%ebp), %eax > > > > > pushl %eax > > > > > call _RTHooks__PushEFrame > > > > > addl $16, %esp > > > > > leal -288(%ebp), %eax > > > > > addl $48, %eax > > > > > subl $12, %esp > > > > > pushl %eax > > > > > call __setjmp > > > > > addl $16, %esp > > > > > testb %al, %al > > > > > jne L158 > > > > > .stabn 68,0,183,LM95-_M3File__IsReadable > > > > > LM95: > > > > > movl -288(%ebp), %eax > > > > > subl $12, %esp > > > > > pushl %eax > > > > > call _RTHooks__PopEFrame > > > > > addl $16, %esp > > > > > movl $1, -304(%ebp) > > > > > jmp L159 > > > > > L158: > > > > > .stabn 68,0,185,LM96-_M3File__IsReadable > > > > > LM96: > > > > > movl $0, -304(%ebp) > > > > > L159: > > > > > LBE15: > > > > > movl -304(%ebp), %eax > > > > > leal -12(%ebp), %esp > > > > > popl %ebx > > > > > popl %esi > > > > > popl %edi > > > > > leave > > > > > ret > > > > > > > > > > > > > > > M3File.IsReadable's call to FS.Status is omitted, all files > are > > > > > readable, even if they are not openable, therefore it "finds" > > > > > cm3.cfg in the current directory and then fails to open it.. > > > > > > > > > > later.. > > > > > ..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! Learn > > > more. > > > > > > > > > > > > > Shed those extra pounds with MSN and The Biggest Loser! Learn > more. > > > > Climb to the top of the charts! Play the word scramble challenge > with star power. Play now! From jayk123 at hotmail.com Tue Jan 22 00:01:44 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 21 Jan 2008 23:01:44 +0000 Subject: [M3devel] platform/build_dir is a big tuple? Message-ID: I just realized... As I said, there are several variables. "platform" is a big tuple architecture -- x86, ppc, sparc OS -- NT, Linux, Darwin, Solaris ostype -- win32, posix This probably not -- embodied instead by C runtime and threading model C compiler -- Visual C++, gcc, Sun, Watcom, DigitalMars, Metrowerks and version thereof Linker -- Visual C++, gcc/ld, C runtime -- msvc*, linuxlibc6, cygwin (newline) executable format -- aout, elf, pe (witness the three Linux x86 targets; yes, I know aout is dead and the elf target probably also) oh..maybe object file format -- coff, elf, mach-o Threading model -- vtalarm, pthreads, Win32 backend -- integrated, gcc, C generating Windows library -- X Windows, Windows naming convention -- Unix/Posix, Windows, grumpy Unix Many combinations make sense and work -- two threading models on most systems. Many combinations do not -- Win32 threads on most. Maybe call this "native" threads. Many combinations interoperate -- gcc and Visual C++ output the same .obj file format But you don't want to mix jmpbuf size with the wrong C runtime Naming conventions are sometimes arbitrary, sometimes not, depending on if the linker is given precise paths or like on Mac it probes (is that how a bunch work?). Each variable could contribute a little bit to BUILD_DIR OS -- n, l, d, s This would probably come first and be spelled out. NT, Linux, Solaris architecture -- x, p, s, mi (mips), a (alpha), m6 (m68k or just 6), a (amd64) This might be longer too -- x86, PPC, SPARC C compiler -- ms6, ms7,ms71, ms8, g2, g3, g4, mw6, mw7, mw8, w Linker -- g, m C runtime -- m, g (glibc), c Executable format -- a, e, p (or w for Windows), m (mach-o), pef obj format -- c, e, m threading model -- v, p, w; or v and n (native) backend -- i, g, c Windowing library -- x, w naming convention -- u or p, m (Microsoft) or w (windows), g Ok, I know, crazy, unwieldy, crazy long directory names, but somehow seems true. Imagine there was an "integrated linker". It could consume at least three different obj formats and output at least three different executable formats (elf, pe/coff, mach-o). A smaller version of this however is to let the user set OSTYPE and NAMING_CONVENTION, and perhaps a few other variables (Windowing library is one obviously missing), in the config, honor them, and possibly build up BUILD_DIR in this way. Several variables can be omited..well mainly obj format. That seems to vary the least or vary along with compiler/linker. - 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 Jan 22 00:06:41 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 21 Jan 2008 23:06:41 +0000 Subject: [M3devel] next problem (NT386GNU) In-Reply-To: <1A6EC7D6-32B2-44AD-933F-6976040A7D7F@cs.purdue.edu> References: <6E1E4409-F3D9-4982-B179-2D4C9648FDD0@cs.purdue.edu> <1A6EC7D6-32B2-44AD-933F-6976040A7D7F@cs.purdue.edu> Message-ID: I don't want to deal with learning about CVS branches, please. I can try the __cdecl thunk hack I had nearly working, over in m3-win\import-libs. It's lame compared to my parse.c though. Given void __stdcall Foo(int a, struct {int a, b}), or rather Foo 12, it would generate one source file/.obj void __stdcall F(int a, int b, int c); void __stdcall Fstdcall(int a, int b, int c) { return Fstdcall(a b c); } another source file/.obj void __stdcall Fstdcall(int a, int b, int c); void __cdecl F(int a, int b, int c) { return Fstdcall(a b c); } If I could put parse.c back, I could limit this to functions that take structs. Or at least one function in particular that I know is a current problem. Limiting this hack would be good. - Jay > CC: m3devel at elegosoft.com > From: hosking at cs.purdue.edu > Subject: Re: next problem (NT386GNU) > Date: Mon, 21 Jan 2008 17:32:32 -0500 > To: jayk123 at hotmail.com > > I'd prefer to have the backend do it properly based on properly > declared types. I'd prefer to keep this code out of the current > mainline of parse.c -- you could fork a temporary branch if necessary. > > On Jan 21, 2008, at 5:16 PM, Jay wrote: > > > Understood. Put back my parse.c in the meantime? > > > > Also, the front end could do this, right? And probably without a > > stack? > > It could compute "effective parameter size" and pass that down. > > Backend could then divide by 4 and claim that is the signature, > > that number of parameters. > > > > Would have to see how passing a struct works out anyway -- one > > parameter > > or one per field. > > > > - Jay > > > > > > > CC: m3devel at elegosoft.com > > > From: hosking at cs.purdue.edu > > > Subject: Re: next problem (NT386GNU) > > > Date: Mon, 21 Jan 2008 12:01:28 -0500 > > > To: jayk123 at hotmail.com > > > > > > I just need to fix m3cc/cm3cg to emit the stdcall parameter > > > information for imported procedures. It is simply a matter of not > > > ignoring declare_param for import_procedure chunks. This means > > > maintaining a current_function_decl (and possibly a > > > current_param_count) stack (since import_procedure can occur > > inside a > > > declare_procedure chunk). I know what needs doing, but have not much > > > free time right now... > > > > > > On Jan 21, 2008, at 11:10 AM, Jay wrote: > > > > > > > agreed once I thought about it > > > > I guess that explains left to right as well. > > > > Parameters are always left to right from a higher level point of > > > > view, and if that is wrong, the compiler will reorder. > > > > > > > > "everything" works now > > > > > > > > - Jay > > > > > > > > > > > > > > > > > CC: m3devel at elegosoft.com > > > > > From: hosking at cs.purdue.edu > > > > > Subject: Re: next problem (NT386GNU) > > > > > Date: Mon, 21 Jan 2008 10:54:10 -0500 > > > > > To: jayk123 at hotmail.com > > > > > > > > > > Surely, when using the gcc-based backend then we should make the > > > > > backend handle it. The front end handling it is only need for > > the > > > > > integrated x86 backend. > > > > > > > > > > On Jan 21, 2008, at 2:43 AM, Jay wrote: > > > > > > > > > > > I haven't tested a fix but I see the problem. > > > > > > > > > > > > This function returns a struct. > > > > > > There are two struct returning calling conventions. > > > > > > In one, the backend handles it. Which includes the backend > > knowing > > > > > > there is a return value and its type (or at least its size?). > > > > > > In the other, the front end handles it. In this case, the > > front > > > > end > > > > > > generates passing an extra pointer parameter to the > > function, and > > > > > > the function's return type is void. > > > > > > > > > > > > The NT calling conventions, all of them, are marked as > > front end > > > > > > handling it. I assume that is correct, could check. > > > > > > Everything else is marked as back end handling. > > > > > > > > > > > > Now then, somewhere along the line, gcc figures out that the > > > > return > > > > > > value isn't used here. > > > > > > The point of the function call is to see if it generates an > > > > exception. > > > > > > > > > > > > Gcc removes the function because its return value isn't > > used, and, > > > > > > well, somehow it doesn't know about the exceptions here. > > I'll have > > > > > > to see how "raise" is implemented. I think it's by a call to a > > > > > > function that gets the jmpbuf from a thread local and calls > > > > > > longjmp. (Did I mention it is very inefficient?) > > > > > > > > > > > > There are few possible fixes, but nothing completely > > satisfactory > > > > > > yet in mind. > > > > > > > > > > > > One is have parse.c mark all function calls as having side > > > > affects. > > > > > > This is easy, but overly pessimistic. > > > > > > Another is for the front end to mark struct returning > > functions as > > > > > > having side affects. Better, but still overly pessimistic. > > > > > > Another is for the front end to mark any function that can > > > > raise as > > > > > > having side affects. Getting better still. I don't know how > > to do > > > > > > that but I'll look. This is still a bit overly pessimistic, > > since > > > > > > what you really want to know is, not the function's side > > affects, > > > > > > but whether or not it raised. If the function is inlined, > > the side > > > > > > affects could be optimized away, or if there are enough > > callers > > > > who > > > > > > don't care about the side affects to warrant an > > optimization, and > > > > > > depending on the cost of computing the side affects, another > > > > > > instance of the function could be made that only raises or > > not, > > > > but > > > > > > no side affects otherwise. This is "advanced" optimization the > > > > sort > > > > > > of which tends never to be implemented. > > > > > > > > > > > > I think the best option is anything that can raise is > > marked as > > > > > > having side affects. > > > > > > I'll see if I can figure that out. > > > > > > > > > > > > You can figure this out by looking at m3cgcat -binary < > > > > M3File.mc > > > > > > > 1.txt on PPC_DARWIN and NT386GNU and comparing. > > > > > > > > > > > > Maybe marking all or nearly functions as having side > > effects isn't > > > > > > so bad. > > > > > > Or at least anything returning a struct. That gets parity with > > > > > > other platforms, even if it is a bit pessimistic. > > > > > > I think I'll do that, and ignore figuring out if raise is > > called > > > > > > and using that as a filter. > > > > > > The parity angle is good. > > > > > > > > > > > > The good news for all you Unix lovers :) is this bug is > > relatively > > > > > > portable to Cygwin. > > > > > > True, it is specific to NT386GNU having multiple "calling > > > > > > conventions", which no other platform has. > > > > > > Which again, jokingly, strikes at the question -- What is > > Posix? > > > > > > What do you want from Cygwin? > > > > > > One thing Cygwin does NOT give you is just one calling > > convention, > > > > > > alas, this calling convention business stinks. It's not > > even an NT > > > > > > thing, only an NT386 thing. All the other NT platforms had/ > > have > > > > > > only one calling convention. > > > > > > > > > > > > You can't get far on NT386 without needing to support two > > calling > > > > > > conventions. > > > > > > The "OS" uses mostly __stdcall -- callee pops -- smaller, > > faster. > > > > > > But anything that is varargs, such as printf -- pretty much > > must > > > > > > use caller pops -- __cdecl. > > > > > > As well, __cdecl is the default, so prevalent, and used in > > most C > > > > > > runtime functions. > > > > > > There is also __fastcall that uses like up to two registers > > for > > > > > > parameters. > > > > > > > > > > > > I have seen a platform in which printf did the pop, and it > > > > depended > > > > > > on the number/size of parameters matching the format > > string. On > > > > > > most platforms, printf("", 1, 2, 3, 4) just does nothing, > > but on > > > > > > that platform, it'd unbalance the stack and crash. > > > > > > > > > > > > - Jay > > > > > > > > > > > > From: jayk123 at hotmail.com > > > > > > To: hosking at cs.purdue.edu > > > > > > CC: m3devel at elegosoft.com > > > > > > Subject: next problem (NT386GNU) > > > > > > Date: Mon, 21 Jan 2008 05:47:28 +0000 > > > > > > > > > > > > M3File.m3 > > > > > > > > > > > > PROCEDURE IsReadable (path: TEXT): BOOLEAN = > > > > > > (* We don't really check for readablitiy, just for > > existence *) > > > > > > BEGIN > > > > > > TRY > > > > > > EVAL FS.Status (path); line 82 > > > > > > RETURN TRUE; > > > > > > EXCEPT OSError.E => > > > > > > RETURN FALSE; > > > > > > END; > > > > > > END IsReadable; > > > > > > > > > > > > -----LINE 82 ----- > > > > > > start_call_direct p.25 0 Struct > > > > > > load_address v.25 0 > > > > > > pop_param Addr > > > > > > load v.26 0 Addr Addr > > > > > > pop_param Addr > > > > > > call_direct p.25 Struct > > > > > > pop Struct > > > > > > > > > > > > > > > > > > > > > > > > I'm guessing you only see an import for the first call on > > purpose, > > > > > > but I will compare with PPC_DARWIN: > > > > > > > > > > > > -----LINE 46 ----- > > > > > > import_procedure FS__Status 2 Struct 0 p.25 > > > > > > declare_indirect 2078421550 -2078421551 > > > > > > declare_param _return 4 4 Addr 2078421550 F F 50 v.62 > > > > > > declare_param p 4 4 Addr 1358456180 F F 50 v.63 > > > > > > start_call_direct p.25 0 Struct > > > > > > load_address v.13 0 > > > > > > pop_param Addr > > > > > > load v.14 0 Addr Addr > > > > > > pop_param Addr > > > > > > call_direct p.25 Struct > > > > > > pop Struct > > > > > > > > > > > > > > > > > > .globl _M3File__IsReadable > > > > > > .def _M3File__IsReadable; .scl 2; .type 32; .endef > > > > > > _M3File__IsReadable: > > > > > > .stabn 68,0,178,LM93-_M3File__IsReadable > > > > > > LM93: > > > > > > pushl %ebp > > > > > > movl %esp, %ebp > > > > > > pushl %edi > > > > > > pushl %esi > > > > > > pushl %ebx > > > > > > subl $300, %esp > > > > > > LBB15: > > > > > > .stabn 68,0,181,LM94-_M3File__IsReadable > > > > > > LM94: > > > > > > L157: > > > > > > movl -280(%ebp), %eax > > > > > > andl $0, %eax > > > > > > orl $_L_1, %eax > > > > > > movl %eax, -280(%ebp) > > > > > > movl -284(%ebp), %eax > > > > > > andl $0, %eax > > > > > > movl %eax, -284(%ebp) > > > > > > subl $12, %esp > > > > > > leal -288(%ebp), %eax > > > > > > pushl %eax > > > > > > call _RTHooks__PushEFrame > > > > > > addl $16, %esp > > > > > > leal -288(%ebp), %eax > > > > > > addl $48, %eax > > > > > > subl $12, %esp > > > > > > pushl %eax > > > > > > call __setjmp > > > > > > addl $16, %esp > > > > > > testb %al, %al > > > > > > jne L158 > > > > > > .stabn 68,0,183,LM95-_M3File__IsReadable > > > > > > LM95: > > > > > > movl -288(%ebp), %eax > > > > > > subl $12, %esp > > > > > > pushl %eax > > > > > > call _RTHooks__PopEFrame > > > > > > addl $16, %esp > > > > > > movl $1, -304(%ebp) > > > > > > jmp L159 > > > > > > L158: > > > > > > .stabn 68,0,185,LM96-_M3File__IsReadable > > > > > > LM96: > > > > > > movl $0, -304(%ebp) > > > > > > L159: > > > > > > LBE15: > > > > > > movl -304(%ebp), %eax > > > > > > leal -12(%ebp), %esp > > > > > > popl %ebx > > > > > > popl %esi > > > > > > popl %edi > > > > > > leave > > > > > > ret > > > > > > > > > > > > > > > > > > M3File.IsReadable's call to FS.Status is omitted, all files > > are > > > > > > readable, even if they are not openable, therefore it "finds" > > > > > > cm3.cfg in the current directory and then fails to open it.. > > > > > > > > > > > > later.. > > > > > > ..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! Learn > > > > more. > > > > > > > > > > > > > > > > > Shed those extra pounds with MSN and The Biggest Loser! Learn > > more. > > > > > > > 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 jayk123 at hotmail.com Tue Jan 22 00:17:32 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 21 Jan 2008 23:17:32 +0000 Subject: [M3devel] branching a file? In-Reply-To: <1A6EC7D6-32B2-44AD-933F-6976040A7D7F@cs.purdue.edu> References: <6E1E4409-F3D9-4982-B179-2D4C9648FDD0@cs.purdue.edu> <1A6EC7D6-32B2-44AD-933F-6976040A7D7F@cs.purdue.edu> Message-ID: In Perforce, if you want to make a file that starts out as a copy of another, but then diverges, NOT in a different branch, but one that will coexist in a different file name or path, you can use "integrate" to create the file initially. Does CVS have that? Or just copy and be done? e.g.: p4 integrate NT386GNU NT386_MINGWIN or p4 integrate NT386 NT386_MINGWIN (The first is more accurate, these files are almost identical, and really I'd like to have less duplication here somehow, like by copying all of the config files to bin\config and having them include bits and pieces -- reasonable? It used to look something like that, right?) (Integrate is also the command for merging branches. I little strange naming there all around.) - 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 Jan 22 00:56:27 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 21 Jan 2008 18:56:27 -0500 Subject: [M3devel] next problem (NT386GNU) In-Reply-To: References: <6E1E4409-F3D9-4982-B179-2D4C9648FDD0@cs.purdue.edu> <1A6EC7D6-32B2-44AD-933F-6976040A7D7F@cs.purdue.edu> Message-ID: I should be able to get cm3cg doing the right thing by the end of the week. On Jan 21, 2008, at 6:06 PM, Jay wrote: > I don't want to deal with learning about CVS branches, please. > > I can try the __cdecl thunk hack I had nearly working, over in m3- > win\import-libs. > It's lame compared to my parse.c though. > > Given void __stdcall Foo(int a, struct {int a, b}), or rather Foo 12, > > it would generate > > one source file/.obj > void __stdcall F(int a, int b, int c); > void __stdcall Fstdcall(int a, int b, int c) { return Fstdcall > (a b c); } > > another source file/.obj > void __stdcall Fstdcall(int a, int b, int c); > void __cdecl F(int a, int b, int c) { return Fstdcall(a b c); } > > If I could put parse.c back, I could limit this to functions that > take structs. > Or at least one function in particular that I know is a current > problem. > Limiting this hack would be good. > > - Jay > > > > CC: m3devel at elegosoft.com > > From: hosking at cs.purdue.edu > > Subject: Re: next problem (NT386GNU) > > Date: Mon, 21 Jan 2008 17:32:32 -0500 > > To: jayk123 at hotmail.com > > > > I'd prefer to have the backend do it properly based on properly > > declared types. I'd prefer to keep this code out of the current > > mainline of parse.c -- you could fork a temporary branch if > necessary. > > > > On Jan 21, 2008, at 5:16 PM, Jay wrote: > > > > > Understood. Put back my parse.c in the meantime? > > > > > > Also, the front end could do this, right? And probably without a > > > stack? > > > It could compute "effective parameter size" and pass that down. > > > Backend could then divide by 4 and claim that is the signature, > > > that number of parameters. > > > > > > Would have to see how passing a struct works out anyway -- one > > > parameter > > > or one per field. > > > > > > - Jay > > > > > > > > > > CC: m3devel at elegosoft.com > > > > From: hosking at cs.purdue.edu > > > > Subject: Re: next problem (NT386GNU) > > > > Date: Mon, 21 Jan 2008 12:01:28 -0500 > > > > To: jayk123 at hotmail.com > > > > > > > > I just need to fix m3cc/cm3cg to emit the stdcall parameter > > > > information for imported procedures. It is simply a matter of > not > > > > ignoring declare_param for import_procedure chunks. This means > > > > maintaining a current_function_decl (and possibly a > > > > current_param_count) stack (since import_procedure can occur > > > inside a > > > > declare_procedure chunk). I know what needs doing, but have > not much > > > > free time right now... > > > > > > > > On Jan 21, 2008, at 11:10 AM, Jay wrote: > > > > > > > > > agreed once I thought about it > > > > > I guess that explains left to right as well. > > > > > Parameters are always left to right from a higher level > point of > > > > > view, and if that is wrong, the compiler will reorder. > > > > > > > > > > "everything" works now > > > > > > > > > > - Jay > > > > > > > > > > > > > > > > > > > > > CC: m3devel at elegosoft.com > > > > > > From: hosking at cs.purdue.edu > > > > > > Subject: Re: next problem (NT386GNU) > > > > > > Date: Mon, 21 Jan 2008 10:54:10 -0500 > > > > > > To: jayk123 at hotmail.com > > > > > > > > > > > > Surely, when using the gcc-based backend then we should > make the > > > > > > backend handle it. The front end handling it is only need > for > > > the > > > > > > integrated x86 backend. > > > > > > > > > > > > On Jan 21, 2008, at 2:43 AM, Jay wrote: > > > > > > > > > > > > > I haven't tested a fix but I see the problem. > > > > > > > > > > > > > > This function returns a struct. > > > > > > > There are two struct returning calling conventions. > > > > > > > In one, the backend handles it. Which includes the backend > > > knowing > > > > > > > there is a return value and its type (or at least its > size?). > > > > > > > In the other, the front end handles it. In this case, the > > > front > > > > > end > > > > > > > generates passing an extra pointer parameter to the > > > function, and > > > > > > > the function's return type is void. > > > > > > > > > > > > > > The NT calling conventions, all of them, are marked as > > > front end > > > > > > > handling it. I assume that is correct, could check. > > > > > > > Everything else is marked as back end handling. > > > > > > > > > > > > > > Now then, somewhere along the line, gcc figures out > that the > > > > > return > > > > > > > value isn't used here. > > > > > > > The point of the function call is to see if it > generates an > > > > > exception. > > > > > > > > > > > > > > Gcc removes the function because its return value isn't > > > used, and, > > > > > > > well, somehow it doesn't know about the exceptions here. > > > I'll have > > > > > > > to see how "raise" is implemented. I think it's by a > call to a > > > > > > > function that gets the jmpbuf from a thread local and > calls > > > > > > > longjmp. (Did I mention it is very inefficient?) > > > > > > > > > > > > > > There are few possible fixes, but nothing completely > > > satisfactory > > > > > > > yet in mind. > > > > > > > > > > > > > > One is have parse.c mark all function calls as having side > > > > > affects. > > > > > > > This is easy, but overly pessimistic. > > > > > > > Another is for the front end to mark struct returning > > > functions as > > > > > > > having side affects. Better, but still overly pessimistic. > > > > > > > Another is for the front end to mark any function that can > > > > > raise as > > > > > > > having side affects. Getting better still. I don't know > how > > > to do > > > > > > > that but I'll look. This is still a bit overly > pessimistic, > > > since > > > > > > > what you really want to know is, not the function's side > > > affects, > > > > > > > but whether or not it raised. If the function is inlined, > > > the side > > > > > > > affects could be optimized away, or if there are enough > > > callers > > > > > who > > > > > > > don't care about the side affects to warrant an > > > optimization, and > > > > > > > depending on the cost of computing the side affects, > another > > > > > > > instance of the function could be made that only raises or > > > not, > > > > > but > > > > > > > no side affects otherwise. This is "advanced" > optimization the > > > > > sort > > > > > > > of which tends never to be implemented. > > > > > > > > > > > > > > I think the best option is anything that can raise is > > > marked as > > > > > > > having side affects. > > > > > > > I'll see if I can figure that out. > > > > > > > > > > > > > > You can figure this out by looking at m3cgcat -binary < > > > > > M3File.mc > > > > > > > > 1.txt on PPC_DARWIN and NT386GNU and comparing. > > > > > > > > > > > > > > Maybe marking all or nearly functions as having side > > > effects isn't > > > > > > > so bad. > > > > > > > Or at least anything returning a struct. That gets > parity with > > > > > > > other platforms, even if it is a bit pessimistic. > > > > > > > I think I'll do that, and ignore figuring out if raise is > > > called > > > > > > > and using that as a filter. > > > > > > > The parity angle is good. > > > > > > > > > > > > > > The good news for all you Unix lovers :) is this bug is > > > relatively > > > > > > > portable to Cygwin. > > > > > > > True, it is specific to NT386GNU having multiple "calling > > > > > > > conventions", which no other platform has. > > > > > > > Which again, jokingly, strikes at the question -- What is > > > Posix? > > > > > > > What do you want from Cygwin? > > > > > > > One thing Cygwin does NOT give you is just one calling > > > convention, > > > > > > > alas, this calling convention business stinks. It's not > > > even an NT > > > > > > > thing, only an NT386 thing. All the other NT platforms > had/ > > > have > > > > > > > only one calling convention. > > > > > > > > > > > > > > You can't get far on NT386 without needing to support two > > > calling > > > > > > > conventions. > > > > > > > The "OS" uses mostly __stdcall -- callee pops -- smaller, > > > faster. > > > > > > > But anything that is varargs, such as printf -- pretty > much > > > must > > > > > > > use caller pops -- __cdecl. > > > > > > > As well, __cdecl is the default, so prevalent, and used in > > > most C > > > > > > > runtime functions. > > > > > > > There is also __fastcall that uses like up to two > registers > > > for > > > > > > > parameters. > > > > > > > > > > > > > > I have seen a platform in which printf did the pop, and it > > > > > depended > > > > > > > on the number/size of parameters matching the format > > > string. On > > > > > > > most platforms, printf("", 1, 2, 3, 4) just does nothing, > > > but on > > > > > > > that platform, it'd unbalance the stack and crash. > > > > > > > > > > > > > > - Jay > > > > > > > > > > > > > > From: jayk123 at hotmail.com > > > > > > > To: hosking at cs.purdue.edu > > > > > > > CC: m3devel at elegosoft.com > > > > > > > Subject: next problem (NT386GNU) > > > > > > > Date: Mon, 21 Jan 2008 05:47:28 +0000 > > > > > > > > > > > > > > M3File.m3 > > > > > > > > > > > > > > PROCEDURE IsReadable (path: TEXT): BOOLEAN = > > > > > > > (* We don't really check for readablitiy, just for > > > existence *) > > > > > > > BEGIN > > > > > > > TRY > > > > > > > EVAL FS.Status (path); line 82 > > > > > > > RETURN TRUE; > > > > > > > EXCEPT OSError.E => > > > > > > > RETURN FALSE; > > > > > > > END; > > > > > > > END IsReadable; > > > > > > > > > > > > > > -----LINE 82 ----- > > > > > > > start_call_direct p.25 0 Struct > > > > > > > load_address v.25 0 > > > > > > > pop_param Addr > > > > > > > load v.26 0 Addr Addr > > > > > > > pop_param Addr > > > > > > > call_direct p.25 Struct > > > > > > > pop Struct > > > > > > > > > > > > > > > > > > > > > > > > > > > > I'm guessing you only see an import for the first call on > > > purpose, > > > > > > > but I will compare with PPC_DARWIN: > > > > > > > > > > > > > > -----LINE 46 ----- > > > > > > > import_procedure FS__Status 2 Struct 0 p.25 > > > > > > > declare_indirect 2078421550 -2078421551 > > > > > > > declare_param _return 4 4 Addr 2078421550 F F 50 v.62 > > > > > > > declare_param p 4 4 Addr 1358456180 F F 50 v.63 > > > > > > > start_call_direct p.25 0 Struct > > > > > > > load_address v.13 0 > > > > > > > pop_param Addr > > > > > > > load v.14 0 Addr Addr > > > > > > > pop_param Addr > > > > > > > call_direct p.25 Struct > > > > > > > pop Struct > > > > > > > > > > > > > > > > > > > > > .globl _M3File__IsReadable > > > > > > > .def _M3File__IsReadable; .scl 2; .type 32; .endef > > > > > > > _M3File__IsReadable: > > > > > > > .stabn 68,0,178,LM93-_M3File__IsReadable > > > > > > > LM93: > > > > > > > pushl %ebp > > > > > > > movl %esp, %ebp > > > > > > > pushl %edi > > > > > > > pushl %esi > > > > > > > pushl %ebx > > > > > > > subl $300, %esp > > > > > > > LBB15: > > > > > > > .stabn 68,0,181,LM94-_M3File__IsReadable > > > > > > > LM94: > > > > > > > L157: > > > > > > > movl -280(%ebp), %eax > > > > > > > andl $0, %eax > > > > > > > orl $_L_1, %eax > > > > > > > movl %eax, -280(%ebp) > > > > > > > movl -284(%ebp), %eax > > > > > > > andl $0, %eax > > > > > > > movl %eax, -284(%ebp) > > > > > > > subl $12, %esp > > > > > > > leal -288(%ebp), %eax > > > > > > > pushl %eax > > > > > > > call _RTHooks__PushEFrame > > > > > > > addl $16, %esp > > > > > > > leal -288(%ebp), %eax > > > > > > > addl $48, %eax > > > > > > > subl $12, %esp > > > > > > > pushl %eax > > > > > > > call __setjmp > > > > > > > addl $16, %esp > > > > > > > testb %al, %al > > > > > > > jne L158 > > > > > > > .stabn 68,0,183,LM95-_M3File__IsReadable > > > > > > > LM95: > > > > > > > movl -288(%ebp), %eax > > > > > > > subl $12, %esp > > > > > > > pushl %eax > > > > > > > call _RTHooks__PopEFrame > > > > > > > addl $16, %esp > > > > > > > movl $1, -304(%ebp) > > > > > > > jmp L159 > > > > > > > L158: > > > > > > > .stabn 68,0,185,LM96-_M3File__IsReadable > > > > > > > LM96: > > > > > > > movl $0, -304(%ebp) > > > > > > > L159: > > > > > > > LBE15: > > > > > > > movl -304(%ebp), %eax > > > > > > > leal -12(%ebp), %esp > > > > > > > popl %ebx > > > > > > > popl %esi > > > > > > > popl %edi > > > > > > > leave > > > > > > > ret > > > > > > > > > > > > > > > > > > > > > M3File.IsReadable's call to FS.Status is omitted, all > files > > > are > > > > > > > readable, even if they are not openable, therefore it > "finds" > > > > > > > cm3.cfg in the current directory and then fails to open > it.. > > > > > > > > > > > > > > later.. > > > > > > > ..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! > Learn > > > > > more. > > > > > > > > > > > > > > > > > > > > > Shed those extra pounds with MSN and The Biggest Loser! Learn > > > more. > > > > > > > > > > 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". Check it out. From darko at darko.org Tue Jan 22 06:37:40 2008 From: darko at darko.org (Darko) Date: Mon, 21 Jan 2008 21:37:40 -0800 Subject: [M3devel] NT386GNU distribution available In-Reply-To: References: Message-ID: <54D13F89-4394-4508-AA47-531956BC43F3@darko.org> Do you have a link for the distribution, or did I miss something? - Darko On 21/01/2008, at 8:41 AM, Jay wrote: > Here, in my user directory on birch, is the first CM3 NT386GNU > release. > It is MinGWin based FOR NOW. > This needs to be changed SOON. > > Install MinGWin. (Search the web for it.) > set PATH=c:\MinGW\bin;%PATH% > > (The default install location is c:\MinGW, not MinGWin.) > > The MinGWin that Qt gives you is too old, from around 2004. > It doesn't support "response files" (aka long command lines). > > If you want to rebuild m3cg: > > Install MSys. It is at the same place as MinGWin. > set PATH=c:\msys\1.0\bin;%PATH% > > else consider > > set OMIT_GCC=yes > > depending on if you run the various scripts. > > If you install to these exact paths, scripts\python\pylib.py > will use them automatically. > > Optionally install Python. I recommend it. > > Extract one or more of the archives. > They will extract to like: > > cm3-min-WIN32-NT386GNU-d5.5.1\bin\cm3.exe > > You can rename it cm3, or for purposes of backup/restore, > xcopy /fivery \cm3-min-WIN32-NT386GNU-d5.5.1 \cm3 > > (For extra good testing, first rmdir /q/s \cm3.) > > set PATH=c:\cm3\bin;%PATH% > > This is important, since various code will tend to assume NT386 > unless overridden. > > set CM3_TARGET=NT386GNU > > Someone please weigh in on zip vs. tar.bz2 on the other Win32 > platforms. > For reference, MinGWin doesn't include tar/bzip2, MSys does, Cygwin > has tons of optional stuff, they are in there, probably the base. > > And then go to scripts\python and run whatever: > upgrade > or make-dist > or do-cm3-core > or do-cm3-base > but not currently do-cm3-std > > scripts\win\upgrade works too. > > Do remember to set CM3_TARGET=NT386GNU. > > You will probably at some point be prompted to set CM3_ROOT to the > root of the source > tree as well. If you run "scripts", it will be set for you. > If you cd around and run cm3, it won't. > > \cm3\bin\cm3.cfg delegates out to the source tree. > Except the one in the distributions do not. > But if you run upgrade, you'll have such a thing. > > If you want to rebuild cm3cg from source: > cd m3-sys\m3cc\gcc\gcc\m3cg > cvs update -j 1.46 -j 1.45 parse.c > > or thereabouts to get back enough of a __stdcall fix to build a lot. > > If you want to bootstrap without a previous NT386GNU distribution > but with > a previous NT386 build, try like this: > > Get a working NT386 system. > Get current source (except parse.c). > If your system is not current, > scripts\python\upgrade > This will work as far back as cm3-min-WIN32-NT386-5.1.3. > scripts\python\bootntgnu > which is really just roughly: > do-pkg realclean m3core libm3 m3cc > do-pkg buildship m3core libm3 m3cc > set CM3_TARGET=NT386GNU > Now you have the equivalent of the minimum distribution and > can build whatever. > do-pkg .... > > If you want to rollback a bit but not completely, scripts\win > \pkggnu_clean.cmd is > very simple and just deletes all the NT386GNU directories under > $INSTALLROOT\pkg. > > There are "min", "core", and "base" distributions. > Kind of subtle names, eh? > "min" is sufficient. > The binaries are all not "strippped". > > Last minute errata: > There is bin\cm3.cfg and bin\NT386GNU. They are identical. > The intent was only to have cm3.cfg there. > > The system builds itself, so that's pretty good. > > I forgot to include m3gdb, but it should probably be in a separate > "GNU" archive? > > Someone move the files to a web download place? > (and you can move, not copy, I can easily recreate the files) > > - Jay > > Shed those extra pounds with MSN and The Biggest Loser! Learn more. From wagner at elegosoft.com Tue Jan 22 08:10:49 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 22 Jan 2008 08:10:49 +0100 Subject: [M3devel] next problem (NT386GNU) In-Reply-To: References: <6E1E4409-F3D9-4982-B179-2D4C9648FDD0@cs.purdue.edu> <1A6EC7D6-32B2-44AD-933F-6976040A7D7F@cs.purdue.edu> Message-ID: <20080122081049.74tzfvozwo4wwwow@mail.elegosoft.com> Quoting Jay : > I don't want to deal with learning about CVS branches, please. I don't understand the problems some people seem to have with CVS. Creating a branch is really simple: o create a branch tag, for example: cvs tag -b devel_nt386gnu_gcc_opt files(s) o update to that branch: cvs up -r devel_nt386gnu_gcc_opt files(s) That's it. The tag is now `sticky' on the files, i.e. remembered in the CVS/Entries files in your workspace. From now on you're using the branch for the mentioned files. To restore them to the latest main trunk version, use cvs up -A files(s) And Jay, as a Windows user you probably don't like to use the cvs commandline in Cygwin; just install CVS-NT and tortoise (Randy did, too). It may be more convenient for you. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Jan 22 08:26:25 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 22 Jan 2008 07:26:25 +0000 Subject: [M3devel] NT386GNU distribution available In-Reply-To: <54D13F89-4394-4508-AA47-531956BC43F3@darko.org> References: <54D13F89-4394-4508-AA47-531956BC43F3@darko.org> Message-ID: Sorry I do not. All I can do is scp the files to my home directory on birch and have "someone else" make them available otherwise. I made them world readable. If you have access to birch, look in ~jkrell. I'm not an ssh/scp expert, but this might work: scp yourname at m3.elegosoft.com:~jkrell/*.bz2 . I don't now if ~ works here. I should have listed the file names, sorry. Later. I think I deleted all the native Win32 files so that will net you three files all relevant. Or if you can ls in the directory...the "min" one imho is the most interesting, you can build the others easily from it. Maybe try bootstrapping as kind of detailed below? :) (That should be tested as well.) Maybe Trestle tonight, we'll see.. - Jay > CC: m3devel at elegosoft.com> From: darko at darko.org> To: jayk123 at hotmail.com> Subject: Re: [M3devel] NT386GNU distribution available> Date: Mon, 21 Jan 2008 21:37:40 -0800> > Do you have a link for the distribution, or did I miss something?> > - Darko> > On 21/01/2008, at 8:41 AM, Jay wrote:> > > Here, in my user directory on birch, is the first CM3 NT386GNU > > release.> > It is MinGWin based FOR NOW.> > This needs to be changed SOON.> >> > Install MinGWin. (Search the web for it.)> > set PATH=c:\MinGW\bin;%PATH%> >> > (The default install location is c:\MinGW, not MinGWin.)> >> > The MinGWin that Qt gives you is too old, from around 2004.> > It doesn't support "response files" (aka long command lines).> >> > If you want to rebuild m3cg:> >> > Install MSys. It is at the same place as MinGWin.> > set PATH=c:\msys\1.0\bin;%PATH%> >> > else consider> >> > set OMIT_GCC=yes> >> > depending on if you run the various scripts.> >> > If you install to these exact paths, scripts\python\pylib.py> > will use them automatically.> >> > Optionally install Python. I recommend it.> >> > Extract one or more of the archives.> > They will extract to like:> >> > cm3-min-WIN32-NT386GNU-d5.5.1\bin\cm3.exe> >> > You can rename it cm3, or for purposes of backup/restore,> > xcopy /fivery \cm3-min-WIN32-NT386GNU-d5.5.1 \cm3> >> > (For extra good testing, first rmdir /q/s \cm3.)> >> > set PATH=c:\cm3\bin;%PATH%> >> > This is important, since various code will tend to assume NT386 > > unless overridden.> >> > set CM3_TARGET=NT386GNU> >> > Someone please weigh in on zip vs. tar.bz2 on the other Win32 > > platforms.> > For reference, MinGWin doesn't include tar/bzip2, MSys does, Cygwin> > has tons of optional stuff, they are in there, probably the base.> >> > And then go to scripts\python and run whatever:> > upgrade> > or make-dist> > or do-cm3-core> > or do-cm3-base> > but not currently do-cm3-std> >> > scripts\win\upgrade works too.> >> > Do remember to set CM3_TARGET=NT386GNU.> >> > You will probably at some point be prompted to set CM3_ROOT to the > > root of the source> > tree as well. If you run "scripts", it will be set for you.> > If you cd around and run cm3, it won't.> >> > \cm3\bin\cm3.cfg delegates out to the source tree.> > Except the one in the distributions do not.> > But if you run upgrade, you'll have such a thing.> >> > If you want to rebuild cm3cg from source:> > cd m3-sys\m3cc\gcc\gcc\m3cg> > cvs update -j 1.46 -j 1.45 parse.c> >> > or thereabouts to get back enough of a __stdcall fix to build a lot.> >> > If you want to bootstrap without a previous NT386GNU distribution > > but with> > a previous NT386 build, try like this:> >> > Get a working NT386 system.> > Get current source (except parse.c).> > If your system is not current,> > scripts\python\upgrade> > This will work as far back as cm3-min-WIN32-NT386-5.1.3.> > scripts\python\bootntgnu> > which is really just roughly:> > do-pkg realclean m3core libm3 m3cc> > do-pkg buildship m3core libm3 m3cc> > set CM3_TARGET=NT386GNU> > Now you have the equivalent of the minimum distribution and > > can build whatever.> > do-pkg ....> >> > If you want to rollback a bit but not completely, scripts\win > > \pkggnu_clean.cmd is> > very simple and just deletes all the NT386GNU directories under > > $INSTALLROOT\pkg.> >> > There are "min", "core", and "base" distributions.> > Kind of subtle names, eh?> > "min" is sufficient.> > The binaries are all not "strippped".> >> > Last minute errata:> > There is bin\cm3.cfg and bin\NT386GNU. They are identical.> > The intent was only to have cm3.cfg there.> >> > The system builds itself, so that's pretty good.> >> > I forgot to include m3gdb, but it should probably be in a separate > > "GNU" archive?> >> > Someone move the files to a web download place?> > (and you can move, not copy, I can easily recreate the files)> >> > - Jay> >> > 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 jayk123 at hotmail.com Tue Jan 22 08:34:35 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 22 Jan 2008 07:34:35 +0000 Subject: [M3devel] next problem (NT386GNU) In-Reply-To: <20080122081049.74tzfvozwo4wwwow@mail.elegosoft.com> References: <6E1E4409-F3D9-4982-B179-2D4C9648FDD0@cs.purdue.edu> <1A6EC7D6-32B2-44AD-933F-6976040A7D7F@cs.purdue.edu> <20080122081049.74tzfvozwo4wwwow@mail.elegosoft.com> Message-ID: Olaf, yes and no. How do I then bring the files into mainline? Which Tinderbox is testing them? This is impossible question probably, because Tinderbox for private changes probably doesn't scale well. But it would be nice. And other than private branches, submitting diffs would be nice. Or, as well, these can be crutches for bad changes, and people can abuse the Tinderbox. It's tough though, because a multi machine Tinderbox can always easily do much more diligence than one developer and his local machines. (What's the Win32 Tinderbox story, I wonder? I guess first I can see if Mozilla has one, and if not, it probably doesn't exist, if so, it does :) ) I don't mind the command line, but I'm a bit slow learning new tools. I find new source control systems daunting. I'm quite expert with Perforce though including branching, integrating, resolving, etc.. You don't have to be in Cygwin (sh) to use cvs, but it's true, one very annoying thing about all these forward-slash-requiring tools is I lose the usefulness of command line completion in cmd. Cmd is quite good at editing command lines, keeping output and command line history (set the scrollback to 9999), copy/paste, and is very fast, nothing else that I have tried competes. Most are even merely slower on their video output except maybe the actual text ones. The F8 feature, command line completion against history, which I can't explain well, is really great. MSys comes up with awful colors that I couldn't figure out how to change. Cygwin makes all your paths be /cygdrive/c/... which is just ugly and long. MSys/MinGWin are much nicer with merely /c... I installed TortoiseCVS but it didn't work..I need to look into how to get it to use ssh. But as well, if my work doesn't suck too much, it should be fine for mainline. Look at diffs is really also slow. I've done best by always saving away an .orig file and then windiff. Otherwise 1) is very slow 2) textual diffs...I use the command line all the time, but for viewing diffs...it's really insufficient. - Jay > Date: Tue, 22 Jan 2008 08:10:49 +0100> From: wagner at elegosoft.com> To: m3devel at elegosoft.com> Subject: Re: [M3devel] next problem (NT386GNU)> > Quoting Jay :> > > I don't want to deal with learning about CVS branches, please.> > I don't understand the problems some people seem to have with CVS.> Creating a branch is really simple:> > o create a branch tag, for example:> > cvs tag -b devel_nt386gnu_gcc_opt files(s)> > o update to that branch:> > cvs up -r devel_nt386gnu_gcc_opt files(s)> > That's it. The tag is now `sticky' on the files, i.e. remembered> in the CVS/Entries files in your workspace. From now on you're> using the branch for the mentioned files. To restore them to the> latest main trunk version, use> > cvs up -A files(s)> > And Jay, as a Windows user you probably don't like to use the cvs> commandline in Cygwin; just install CVS-NT and tortoise (Randy did,> too). It may be more convenient for you.> > Olaf> -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 Tue Jan 22 08:53:03 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 22 Jan 2008 08:53:03 +0100 Subject: [M3devel] NT386GNU distribution available In-Reply-To: References: <54D13F89-4394-4508-AA47-531956BC43F3@darko.org> Message-ID: <20080122085303.zxbo59ixickk4gos@mail.elegosoft.com> Quoting Jay : > Sorry I do not. All I can do is scp the files to my home directory > on birch and have "someone else" make them available otherwise. > I made them world readable. You could at least make the appropriate entries to the www/download.html page in the same format as the others are. Perhaps we should just add a directory with an automatic index generation for this kind of new archives like for the generated snapshots. I've now added the links. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Jan 22 09:20:52 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 22 Jan 2008 09:20:52 +0100 Subject: [M3devel] next problem (NT386GNU) In-Reply-To: References: <6E1E4409-F3D9-4982-B179-2D4C9648FDD0@cs.purdue.edu> <1A6EC7D6-32B2-44AD-933F-6976040A7D7F@cs.purdue.edu> <20080122081049.74tzfvozwo4wwwow@mail.elegosoft.com> Message-ID: <20080122092052.4osfqyffkkggcs48@mail.elegosoft.com> Quoting Jay : > Olaf, yes and no. > > How do I then bring the files into mainline? A merge is done by using -j (join) insted of -r during update: cvs up -j tag1 [-j tag2] file(s) > Which Tinderbox is testing them? Currently no platforms except for FreeBSD 6 and Debian Linux are tested and displayed in the tinderbox. Unless you or Randy set up a build host running the regression test scripts, it may take a little bit longer for daily test results on Windows to be available. But I'm still waiting for the result shipping implementation and procedure description anyway. Should be available soon, I've heard ;-) Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Jan 22 09:32:52 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 22 Jan 2008 08:32:52 +0000 Subject: [M3devel] NT386GNU distribution available In-Reply-To: <20080122085303.zxbo59ixickk4gos@mail.elegosoft.com> References: <54D13F89-4394-4508-AA47-531956BC43F3@darko.org> <20080122085303.zxbo59ixickk4gos@mail.elegosoft.com> Message-ID: I add entries in download.html and they say ~jkrell/foo or /usr/home/jkrell/foo and the machine updates download.html every so often and done? I didn't/don't know if I could do anything from my end, or what it would be. Thanks! - Jay > Date: Tue, 22 Jan 2008 08:53:03 +0100> From: wagner at elegosoft.com> To: m3devel at elegosoft.com> Subject: Re: [M3devel] NT386GNU distribution available> > Quoting Jay :> > > Sorry I do not. All I can do is scp the files to my home directory > > on birch and have "someone else" make them available otherwise.> > I made them world readable.> > You could at least make the appropriate entries to the www/download.html> page in the same format as the others are.> > Perhaps we should just add a directory with an automatic index generation> for this kind of new archives like for the generated snapshots.> > I've now added the links.> > Olaf> -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 Jan 22 09:43:20 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 22 Jan 2008 08:43:20 +0000 Subject: [M3devel] next problem (NT386GNU) In-Reply-To: <20080122092052.4osfqyffkkggcs48@mail.elegosoft.com> References: <6E1E4409-F3D9-4982-B179-2D4C9648FDD0@cs.purdue.edu> <1A6EC7D6-32B2-44AD-933F-6976040A7D7F@cs.purdue.edu> <20080122081049.74tzfvozwo4wwwow@mail.elegosoft.com> <20080122092052.4osfqyffkkggcs48@mail.elegosoft.com> Message-ID: Any idea how? Oh I see...sounds easier than expected..I was thinking of doing cross builds on your machines or finding some Win32 hosting/colocation, but.. http://en.wikipedia.org/wiki/Tinderbox_%28software%29 >> Mozilla's tinderbox is written in Perl >> Tinderbox is composed of a server with clients running builds and reporting status via mail. probably easy enough to just run it on a machine of mine.. http://www.mozilla.org/projects/tinderbox/index.html -- version 2 http://www.johnkeiser.com/mozilla/tbox3.html -- version 3 - Jay > Date: Tue, 22 Jan 2008 09:20:52 +0100> From: wagner at elegosoft.com> To: jayk123 at hotmail.com> CC: m3devel at elegosoft.com> Subject: RE: [M3devel] next problem (NT386GNU)> > Quoting Jay :> > > Olaf, yes and no.> >> > How do I then bring the files into mainline?> > A merge is done by using -j (join) insted of -r during update:> > cvs up -j tag1 [-j tag2] file(s)> > > Which Tinderbox is testing them?> > Currently no platforms except for FreeBSD 6 and Debian Linux are> tested and displayed in the tinderbox.> > Unless you or Randy set up a build host running the regression test> scripts, it may take a little bit longer for daily test results on> Windows to be available.> > But I'm still waiting for the result shipping implementation and> procedure description anyway. Should be available soon, I've heard ;-)> > Olaf> -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 Tue Jan 22 11:48:56 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 22 Jan 2008 10:48:56 +0000 Subject: [M3devel] platform/build_dir is a big tuple? In-Reply-To: References: Message-ID: Final answer? I played around with this but just can't accept platforms/build_dirs like: ntx86msmsmscm3msn ntx86gccgcccm3cgmsn ntx86gccgcccm3cgxn ntx86-gggggmn ntx86-ggixn ntx86_mmmimm Ok, I have one more name here, and then a bit of a change, or a stronger statement of something I had already said. NT386MINGNU Ok, I think we (me!) are confusing host and target, MOSTLY. And cm3 might not have them quite divided appropriately. What is a "host"? What is a "target"? MinGWin and Visual C++ output similar results, targetingthe same runtime (usually), threading library, windowing library.There is a chance for exception handling to diverge however.Well, speaking of Visual C++ the C/C++ compiler and MinGWinthe gcc environment, yes, very different, not interoperable.MinGWin uses what gcc calls "sjlj" -- setjmp/longjmp exceptions.Very inefficient. But heck, gcc doesn't support __try/__except/__finally,only C++ exceptions, and interop of C++ is often not great,what with name mangling and all. NT386GNU's OUTPUT uses a different runtime, unless you trim dependencies, possibly a different threading library, possibly a different windowing library. All this probably configurable. Again exception handling is a sore point in that it is the primary C runtime dependency of Modula-3. If you use Cygwin but say -mno-cygwin, that means you are targeting NT386. (and don't use pthreads or X Windows; behavior of exceptions/setjmp/longjmp TBD -- really, need to not use the -mno-cygwin headers in that case; I'll check). Perhaps m3core.dll should export m3_setjmp/m3_longjmp.. Either one can do a cross build to the other.Two cm3.exes, two sets of outputs, that either can produce. NT386 can use gcc or the integrated backend. And the gcc it uses can be MinGWin or Cygwin. (theoretically and probably soon reality) NT386GNU can use either as well! (also currently theory, but a real possibility) It isn't GNU tools, it is GNU runtime. One small area with cm3 might fall down just slightly is that of cross builds where host and target have different naming conventions. -lfoo vs. foo.lib, foo.o vs. foo.obj are an aspect of the host and I vaguely recall that cm3 ties naming convention to ostype. The appending of .exe is a target characteristics, but the others are not really. Naming convention is really a host thing and not a target thing. The config files are a mix of host and target information, mostly actually host, except for the one line that says TARGET. Most of the target variation is in cm3, which always can do any, and cm3cg (which might be nice to be similar, but that's another matter and not likely to ever change, except when AMD64 is the last architecture standing. :) ) If Windows had "rpath", then SL would be split between HOST_SL and TARGET_SL.As it stands, SL is HOST_SL. Consider as well the various versions of Visual C++.They output mostly the same, very interoperable. Consider optimization switches. Host or target?Consider version of gcc or Visual C++? Host or target?Well, inevitably, the host has an affect on the target. If not the for the host, the target would not even exist. Bugs in the host produce bugs in the target. etc. (And realize that Cygwin runs on top of an OS built witha Microsoft compiler, so really there is interop, but sometimes through a layer.) So there's a risk of saying there is six+ combinations. (host cygwin, host mingwin, host native) x (target nt386, target nt386gnu) But generally the host is assumed not a factor. I guess "LIBC" could be seperated into several options... You could actually have code that needs one runtime or another, and they could link together, depending on what they do.. This is something I don't know if cm3 handles, or anything I have seen. I should be able to build a static .lib, that includes some C code, that imbues its clients with build time dependencies. Well, I guess #pragma comment(linker) is this. So the next tasks are roughly: Merge my NT386 and NT386GNU files. Switching on a variable such as backend mode. Introduce a "new" (old) NT386GNU file, perhaps more like what was already there. Change NT386GNU back to Posix. Build NT386GNU. oh, one more point...while these are two targets from cm3's point of view, they are PROBABLY the same target to cm3cg and so only one is needed. I have to check if configure differentiates between i686-pc-cygwin and i686-pc-mingwin... but I guess it should... It might actually be profitable to have two bloated cm3cg.exe's. And they should ship to \cm3\pkg\m3cc\target\host or host\target and cm3 should know which to run. Blech..four of them when one would suffice? The detail being mainly what the paths to .libs look like, unfortunate. Possibly cm3 can bridge this gap using that "broken" feature that symlinks libs into the target directory, using NTFS hard links, if installroot and root are on the same volume... (or symlinks on Vista). Or maybe convert the paths as appropriate, hacky, but saves an extra cm3cg.exe which is good to avoid. (all the more reason to lump all targets into one file, so that the host x target matrix collapses to just one axis, host; and then you can write stuff in Perl/Python/Java/C# to collapse that to just one, except for the underlying runtime/interpreter...) Oh, cm3cg isn't the issue. It is always sitting in the correct directory and reads one file and writes one file, no slashes. The issue is gcc as the linker. Again, this is a host issue..and cm3 or the config file definitely should do the translation. - Jay From: jayk123 at hotmail.comTo: m3devel at elegosoft.comDate: Mon, 21 Jan 2008 23:01:44 +0000Subject: [M3devel] platform/build_dir is a big tuple? _________________________________________________________________ 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 Tue Jan 22 14:00:12 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 22 Jan 2008 13:00:12 +0000 Subject: [M3devel] platform/build_dir is a big tuple? In-Reply-To: References: Message-ID: I'm still torn over that any NT386 target could have a choice of three threading models (win32, pthread, vtalarm), two windowing libraries (ms, x), two (three) compilers (ms, mingwin, cygwin), two (three) linkers (ms, mingwn, cygwin), various runtimes (msvc various versions, cygwin, mingwin (discouraged)) etc. Appending a short string of unreadable bits to BUILD_DIR is very temptingin order to easily generate and test the combinatorial possibilities. backend: 0 integrated, 1 gcc already a setting (with four values) ccompiler/linker: 0 ms, 1 gcc (these could be split, and could allocate more bits...) maybe 00 ms, 01 cygwin, 10 ming maybe define enum up front that allows for watcom, metrowerks, digitalmars, llvm etc. maybe use a decimal digit for all these, and 0 is reserved, maybe. threading: 0 win32, 1 pthreads drop vtalarm, or use two bits? windowing: 0 ms, 1 x cruntime: 0 ms, 1 cyg There is also a ming runtime, discouraged There also really N ms runtimes, ming offers several: msvcrt.dll, msvcr70.dll, msvcr71.dll, msvcr80.dll, msvcr90.dll... but jmpbuf presumbly doesn't change again could allocate multiple bits.. cruntime I guess determines oSTYPE Win32 or Posix, thoughit loses its meaning mostly, and X vs. not-X is usually decide the same... The three most common combinations: 00000 -- NT386 11111 -- NT386GNU 11000 -- NT386MINGNU but several others would work 11101 -- cygwin with native windowing 11011 -- cygwin with native threads 11001 -- cygwin with native threads and native windowing BUILD_DIR would be NT386-$(config)as a special case perhaps, the three commoncases could be translated to the above strings. But the underlying implementation would be a few bools/enums,and iterating through them would be easy, while special casingand skipping deemed invalid combinations, like ms runtime and pthreads,and possibly ms runtime and x windows. Really, it might surprise folks, but really, basically every single combination works. Compilers are very independent of headers and libs and headers and libs are very independent of compilers, aside from a few language extensions like __stdcall. You can generally mix runtimes in the same process, just as you can mix them on the same machine, you just need to be careful about what you pass to what. If you call fopen, be sure pass the result back to the matching fclose, malloc/free, etc. Startup code, to the extent that it matters, might be a problem, but really, just avoid C++ globals with constructors/destructors anyway, they are always a problem. Modula-3 has its own startup code, and if you were to write "main" in C and link in Modula-3 static .libs, that probably doesn't work...might actually be better to play into whatever the platform's C++ constructor story is, as problematic as they (probably always?) are -- i.e. unpredictable/hard-to-control ordering. (bad editing...and maybe use hex for compression..) Bringing back cminstall is almost interesting, to promptthe user, or probe their system, though Quake/cm3 can probe at runtime.if os == windows_nt system_cc | findstr version | findstr gcc else system_cc | findstr visual c++else system_cc | grep version | grep gcc else system_cc | grep visual c++end inefficient. anyway, I'll merge current NT386GNU into NT386 and make it chosehow to compile/link which are the main variables today. and then decide about cygwin, but probably do like the above, sinceit'll totally share code with NT386 except the naming conventionsand the removal of the -mno-cygwin switch.. I know this seems overly complicated, but it should be exposableeasily enough to users by hiding the choices, presenting three basic ones,and still allow all the obvious and perhaps useful knobs, and iterating throughthe combinations, without creating a combinatorial explosion of source filesor Modula-3 or Quake code. ...Jay From: jayk123 at hotmail.comTo: m3devel at elegosoft.comDate: Tue, 22 Jan 2008 10:48:56 +0000Subject: Re: [M3devel] platform/build_dir is a big tuple? Final answer? I played around with this but just can't accept platforms/build_dirs like: ntx86msmsmscm3msn ntx86gccgcccm3cgmsn ntx86gccgcccm3cgxn ntx86-gggggmn ntx86-ggixn ntx86_mmmimmOk, I have one more name here, and then a bit of a change, or a stronger statement of something I had already said.NT386MINGNUOk, I think we (me!) are confusing host and target, MOSTLY.And cm3 might not have them quite divided appropriately.What is a "host"? What is a "target"?MinGWin and Visual C++ output similar results, targetingthe same runtime (usually), threading library, windowing library.There is a chance for exception handling to diverge however.Well, speaking of Visual C++ the C/C++ compiler and MinGWinthe gcc environment, yes, very different, not interoperable.MinGWin uses what gcc calls "sjlj" -- setjmp/longjmp exceptions.Very inefficient. But heck, gcc doesn't support __try/__except/__finally,only C++ exceptions, and interop of C++ is often not great,what with name mangling and all.NT386GNU's OUTPUT uses a different runtime, unless you trim dependencies, possibly a different threading library, possibly a different windowing library. All this probably configurable. Again exception handling is a sore point in that it is the primary C runtime dependency of Modula-3. If you use Cygwin but say -mno-cygwin, that means you are targeting NT386. (and don't use pthreads or X Windows; behavior of exceptions/setjmp/longjmp TBD -- really, need to not use the -mno-cygwin headers in that case; I'll check).Perhaps m3core.dll should export m3_setjmp/m3_longjmp..Either one can do a cross build to the other.Two cm3.exes, two sets of outputs, that either can produce.NT386 can use gcc or the integrated backend. And the gcc it uses can be MinGWin or Cygwin. (theoretically and probably soon reality) NT386GNU can use either as well! (also currently theory, but a real possibility) It isn't GNU tools, it is GNU runtime.One small area with cm3 might fall down just slightly is that of cross builds where host and target have different naming conventions. -lfoo vs. foo.lib, foo.o vs. foo.obj are an aspect of the host and I vaguely recall that cm3 ties naming convention to ostype. The appending of .exe is a target characteristics, but the others are not really. Naming convention is really a host thing and not a target thing.The config files are a mix of host and target information, mostly actually host, except for the one line that says TARGET. Most of the target variation is in cm3, which always can do any, and cm3cg (which might be nice to be similar, but that's another matter and not likely to ever change, except when AMD64 is the last architecture standing. :) )If Windows had "rpath", then SL would be split between HOST_SL and TARGET_SL.As it stands, SL is HOST_SL.Consider as well the various versions of Visual C++.They output mostly the same, very interoperable.Consider optimization switches. Host or target?Consider version of gcc or Visual C++? Host or target?Well, inevitably, the host has an affect on the target. If not the for the host, the target would not even exist. Bugs in the host produce bugs in the target. etc.(And realize that Cygwin runs on top of an OS built witha Microsoft compiler, so really there is interop, but sometimes through a layer.) So there's a risk of saying there is six+ combinations.(host cygwin, host mingwin, host native) x (target nt386, target nt386gnu) But generally the host is assumed not a factor. I guess "LIBC" could be seperated into several options...You could actually have code that needs one runtime or another, and they couldlink together, depending on what they do.. This is something I don't know if cm3 handles, or anything I have seen. I should be able to build a static .lib, that includes some C code, that imbues its clients with build time dependencies. Well, I guess #pragma comment(linker) is this.So the next tasks are roughly: Merge my NT386 and NT386GNU files. Switching on a variable such as backend mode. Introduce a "new" (old) NT386GNU file, perhaps more like what was already there. Change NT386GNU back to Posix. Build NT386GNU. oh, one more point...while these are two targets from cm3's point of view, they are PROBABLY the same target to cm3cgand so only one is needed. I have to check if configure differentiates between i686-pc-cygwin and i686-pc-mingwin...but I guess it should...It might actually be profitable to have two bloated cm3cg.exe's.And they should ship to \cm3\pkg\m3cc\target\host or host\target and cm3 should know which to run.Blech..four of them when one would suffice?The detail being mainly what the paths to .libs look like, unfortunate.Possibly cm3 can bridge this gap using that "broken" feature that symlinks libs into the target directory,using NTFS hard links, if installroot and root are on the same volume... (or symlinks on Vista).Or maybe convert the paths as appropriate, hacky, but saves an extra cm3cg.exe which is good to avoid. (all the more reason to lump all targets into one file, so that the host x target matrix collapses to just one axis, host; andthen you can write stuff in Perl/Python/Java/C# to collapse that to just one, except for the underlying runtime/interpreter...) Oh, cm3cg isn't the issue. It is always sitting in the correct directory and reads one file and writes one file, no slashes.The issue is gcc as the linker. Again, this is a host issue..and cm3 or the config file definitely should do the translation. - Jay From: jayk123 at hotmail.comTo: m3devel at elegosoft.comDate: Mon, 21 Jan 2008 23:01:44 +0000Subject: [M3devel] platform/build_dir is a big tuple? 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 wagner at elegosoft.com Tue Jan 22 14:29:22 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 22 Jan 2008 14:29:22 +0100 Subject: [M3devel] platform/build_dir is a big tuple? In-Reply-To: References: Message-ID: <20080122142922.k73w5es5j4gckso4@mail.elegosoft.com> All this may be useful during development, but it is not really useful for a software distribution to our users, I think. Nobody will understand it :-( We need to keep things more simple. We don't need to support everything out of the box. Instead, we should offer some sensible default combinations of everyhing you describe. First of all: we don't distribute cross compilers (at least until now). This is a special topic reserved for adding new platforms. Runtime and compilers used do not necessarily need to be distinguished by target or build dir, in many cases different cm3.cfg may suffice. Until now, threading models are also no choice that needs to be visible at this level. There's one default model for every target, and the user can change it by recompiling. And if we should really agree that changing the target naming scheme is a good idea, we should o use a systematic one with not more than 4 elements (better still, 3 (e.g. --)) o don't use cryptic abbreviations that will confuse most people Just my 2 cents, Olaf Quoting Jay : > I'm still torn over that any NT386 target could have a choice of > three threading models (win32, pthread, vtalarm), two windowing > libraries (ms, x), two (three) compilers (ms, mingwin, cygwin), two > (three) linkers (ms, mingwn, cygwin), various runtimes (msvc various > versions, cygwin, mingwin (discouraged)) etc. > > Appending a short string of unreadable bits to BUILD_DIR is very > temptingin order to easily generate and test the combinatorial > possibilities. > > backend: 0 integrated, 1 gcc already a setting (with four values) > > ccompiler/linker: 0 ms, 1 gcc (these could be split, and could > allocate more bits...) maybe 00 ms, 01 cygwin, 10 ming maybe define > enum up front that allows for watcom, metrowerks, digitalmars, llvm > etc. > maybe use a decimal digit for all these, and 0 is reserved, maybe. > > threading: 0 win32, 1 pthreads drop vtalarm, or use two bits? > > windowing: 0 ms, 1 x > > cruntime: 0 ms, 1 cyg There is also a ming runtime, discouraged > There also really N ms runtimes, ming offers several: msvcrt.dll, > msvcr70.dll, msvcr71.dll, msvcr80.dll, msvcr90.dll... but jmpbuf > presumbly doesn't change again could allocate multiple bits.. > > cruntime I guess determines oSTYPE Win32 or Posix, thoughit loses > its meaning mostly, and X vs. not-X is usually decide the same... > > The three most common combinations: 00000 -- NT386 11111 -- > NT386GNU 11000 -- NT386MINGNU > > but several others would work 11101 -- cygwin with native windowing > 11011 -- cygwin with native threads 11001 -- cygwin with native > threads and native windowing > BUILD_DIR would be NT386-$(config)as a special case perhaps, the > three commoncases could be translated to the above strings. > > But the underlying implementation would be a few bools/enums,and > iterating through them would be easy, while special casingand > skipping deemed invalid combinations, like ms runtime and > pthreads,and possibly ms runtime and x windows. > Really, it might surprise folks, but really, basically every single > combination works. > Compilers are very independent of headers and libs and headers and > libs are very independent of compilers, aside from a few language > extensions like __stdcall. You can generally mix runtimes in the > same process, just as you can mix them on the same machine, you just > need to be careful about what you pass to what. If you call fopen, > be sure pass the result back to the matching fclose, malloc/free, > etc. Startup code, to the extent that it matters, might be a > problem, but really, just avoid C++ globals with > constructors/destructors anyway, they are always a problem. Modula-3 > has its own startup code, and if you were to write "main" in C and > link in Modula-3 static .libs, that probably doesn't work...might > actually be better to play into whatever the platform's C++ > constructor story is, as problematic as they (probably always?) are > -- i.e. unpredictable/hard-to-control ordering. > > (bad editing...and maybe use hex for compression..) > > Bringing back cminstall is almost interesting, to promptthe user, or > probe their system, though Quake/cm3 can probe at runtime.if os == > windows_nt system_cc | findstr version | findstr gcc else > system_cc | findstr visual c++else system_cc | grep version | grep > gcc else system_cc | grep visual c++end > > inefficient. > > anyway, I'll merge current NT386GNU into NT386 and make it chosehow > to compile/link which are the main variables today. > and then decide about cygwin, but probably do like the above, > sinceit'll totally share code with NT386 except the naming > conventionsand the removal of the -mno-cygwin switch.. > > I know this seems overly complicated, but it should be > exposableeasily enough to users by hiding the choices, presenting > three basic ones,and still allow all the obvious and perhaps useful > knobs, and iterating throughthe combinations, without creating a > combinatorial explosion of source filesor Modula-3 or Quake code. > ...Jay > > > From: jayk123 at hotmail.comTo: m3devel at elegosoft.comDate: Tue, 22 Jan > 2008 10:48:56 +0000Subject: Re: [M3devel] platform/build_dir is a > big tuple? > > > Final answer? I played around with this but just can't accept > platforms/build_dirs like: ntx86msmsmscm3msn ntx86gccgcccm3cgmsn > ntx86gccgcccm3cgxn ntx86-gggggmn ntx86-ggixn ntx86_mmmimmOk, I > have one more name here, and then a bit of a change, or a stronger > statement of something I had already said.NT386MINGNUOk, I think we > (me!) are confusing host and target, MOSTLY.And cm3 might not have > them quite divided appropriately.What is a "host"? What is a > "target"?MinGWin and Visual C++ output similar results, targetingthe > same runtime (usually), threading library, windowing library.There > is a chance for exception handling to diverge however.Well, speaking > of Visual C++ the C/C++ compiler and MinGWinthe gcc environment, > yes, very different, not interoperable.MinGWin uses what gcc calls > "sjlj" -- setjmp/longjmp exceptions.Very inefficient. But heck, gcc > doesn't support __try/__except/__finally,only C++ exceptions, and > interop of C++ is often not great,what with name mangling and > all.NT386GNU's OUTPUT uses a different runtime, unless you trim > dependencies, possibly a different threading library, possibly a > different windowing library. All this probably configurable. Again > exception handling is a sore point in that it is the primary C > runtime dependency of Modula-3. If you use Cygwin but say > -mno-cygwin, that means you are targeting NT386. (and don't use > pthreads or X Windows; behavior of exceptions/setjmp/longjmp TBD -- > really, need to not use the -mno-cygwin headers in that case; I'll > check).Perhaps m3core.dll should export > m3_setjmp/m3_longjmp..Either one can do a cross build to the > other.Two cm3.exes, two sets of outputs, that either can > produce.NT386 can use gcc or the integrated backend. And the gcc > it uses can be MinGWin or Cygwin. (theoretically and probably soon > reality) NT386GNU can use either as well! (also currently theory, > but a real possibility) It isn't GNU tools, it is GNU runtime.One > small area with cm3 might fall down just slightly is that of > cross builds where host and target have different naming > conventions. -lfoo vs. foo.lib, foo.o vs. foo.obj are an aspect > of the host and I vaguely recall that cm3 ties naming convention > to ostype. The appending of .exe is a target characteristics, but > the others are not really. Naming convention is really a host > thing and not a target thing.The config files are a mix of host and > target information, mostly actually host, except for the one line > that says TARGET. Most of the target variation is in cm3, which > always can do any, and cm3cg (which might be nice to be similar, > but that's another matter and not likely to ever change, except > when AMD64 is the last architecture standing. :) )If Windows had > "rpath", then SL would be split between HOST_SL and TARGET_SL.As it > stands, SL is HOST_SL.Consider as well the various versions of > Visual C++.They output mostly the same, very interoperable.Consider > optimization switches. Host or target?Consider version of gcc or > Visual C++? Host or target?Well, inevitably, the host has an affect > on the target. If not the for the host, the target would not even > exist. Bugs in the host produce bugs in the target. etc.(And > realize that Cygwin runs on top of an OS built witha Microsoft > compiler, so really there is interop, but sometimes through a > layer.) So there's a risk of saying there is six+ > combinations.(host cygwin, host mingwin, host native) x (target > nt386, target nt386gnu) But generally the host is assumed not a > factor. I guess "LIBC" could be seperated into several options...You > could actually have code that needs one runtime or another, and > they couldlink together, depending on what they do.. This is > something I don't know if cm3 handles, or anything I have seen. I > should be able to build a static .lib, that includes some C code, > that imbues its clients with build time dependencies. Well, I > guess #pragma comment(linker) is this.So the next tasks are > roughly: Merge my NT386 and NT386GNU files. Switching on a > variable such as backend mode. Introduce a "new" (old) NT386GNU > file, perhaps more like what was already there. Change NT386GNU > back to Posix. Build NT386GNU. oh, one more point...while these > are two targets from cm3's point of view, they are PROBABLY the > same target to cm3cgand so only one is needed. I have to check if > configure differentiates between i686-pc-cygwin and > i686-pc-mingwin...but I guess it should...It might actually be > profitable to have two bloated cm3cg.exe's.And they should ship to > \cm3\pkg\m3cc\target\host or host\target and cm3 should know which > to run.Blech..four of them when one would suffice?The detail being > mainly what the paths to .libs look like, unfortunate.Possibly cm3 > can bridge this gap using that "broken" feature that symlinks libs > into the target directory,using NTFS hard links, if installroot and > root are on the same volume... (or symlinks on Vista).Or maybe > convert the paths as appropriate, hacky, but saves an extra > cm3cg.exe which is good to avoid. (all the more reason to lump all > targets into one file, so that the host x target matrix collapses > to just one axis, host; andthen you can write stuff in > Perl/Python/Java/C# to collapse that to just one, except for the > underlying runtime/interpreter...) Oh, cm3cg isn't the issue. It is > always sitting in the correct directory and reads one file and > writes one file, no slashes.The issue is gcc as the linker. Again, > this is a host issue..and cm3 or the config file definitely should > do the translation. - Jay > > > From: jayk123 at hotmail.comTo: m3devel at elegosoft.comDate: Mon, 21 Jan > 2008 23:01:44 +0000Subject: [M3devel] platform/build_dir is a big > tuple? > > 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 -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Jan 22 15:29:04 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 22 Jan 2008 14:29:04 +0000 Subject: [M3devel] platform/build_dir is a big tuple? In-Reply-To: <20080122142922.k73w5es5j4gckso4@mail.elegosoft.com> References: <20080122142922.k73w5es5j4gckso4@mail.elegosoft.com> Message-ID: I know, I've heard it many times from smart people, but sorry I can't resist. I will strive for a balance. In particular I'm thinking NT386 sets a few globals as described include NT386.commonNT386GNU sets a few globals as described include NT386.commonNT386MINGNU sets a few globals as described include NT386.common NT386.common will not be the simplest. CM3 might know about a few more of these globals than it already does. Under the covers, there is already lots and lots and lots of complexity and always will be (look at the stuff I debugged, which I admit was half stupid since PM3 had half the diffs -- I didn't find their config file to see about the double alignment though, so I was stuck debugging that afaik). - Jay > Date: Tue, 22 Jan 2008 14:29:22 +0100> From: wagner at elegosoft.com> To: m3devel at elegosoft.com> Subject: Re: [M3devel] platform/build_dir is a big tuple?> > All this may be useful during development, but it is not really> useful for a software distribution to our users, I think.> > Nobody will understand it :-( We need to keep things more simple.> > We don't need to support everything out of the box. Instead, we should> offer some sensible default combinations of everyhing you describe.> > First of all: we don't distribute cross compilers (at least until now).> This is a special topic reserved for adding new platforms.> > Runtime and compilers used do not necessarily need to be distinguished> by target or build dir, in many cases different cm3.cfg may suffice.> > Until now, threading models are also no choice that needs to be> visible at this level. There's one default model for every target,> and the user can change it by recompiling.> > And if we should really agree that changing the target naming scheme> is a good idea, we should> > o use a systematic one with not more than 4 elements (better still,> 3 (e.g. --))> o don't use cryptic abbreviations that will confuse most people> > Just my 2 cents,> > Olaf> > Quoting Jay :> > I'm still torn over that any NT386 target could have a choice of > > three threading models (win32, pthread, vtalarm), two windowing > > libraries (ms, x), two (three) compilers (ms, mingwin, cygwin), two > > (three) linkers (ms, mingwn, cygwin), various runtimes (msvc various > > versions, cygwin, mingwin (discouraged)) etc.> >> > Appending a short string of unreadable bits to BUILD_DIR is very > > temptingin order to easily generate and test the combinatorial > > possibilities.> >> > backend: 0 integrated, 1 gcc already a setting (with four values)> >> > ccompiler/linker: 0 ms, 1 gcc (these could be split, and could > > allocate more bits...) maybe 00 ms, 01 cygwin, 10 ming maybe define > > enum up front that allows for watcom, metrowerks, digitalmars, llvm > > etc.> > maybe use a decimal digit for all these, and 0 is reserved, maybe.> >> > threading: 0 win32, 1 pthreads drop vtalarm, or use two bits?> >> > windowing: 0 ms, 1 x> >> > cruntime: 0 ms, 1 cyg There is also a ming runtime, discouraged > > There also really N ms runtimes, ming offers several: msvcrt.dll, > > msvcr70.dll, msvcr71.dll, msvcr80.dll, msvcr90.dll... but jmpbuf > > presumbly doesn't change again could allocate multiple bits..> >> > cruntime I guess determines oSTYPE Win32 or Posix, thoughit loses > > its meaning mostly, and X vs. not-X is usually decide the same...> >> > The three most common combinations: 00000 -- NT386 11111 -- > > NT386GNU 11000 -- NT386MINGNU> >> > but several others would work 11101 -- cygwin with native windowing > > 11011 -- cygwin with native threads 11001 -- cygwin with native > > threads and native windowing> > BUILD_DIR would be NT386-$(config)as a special case perhaps, the > > three commoncases could be translated to the above strings.> >> > But the underlying implementation would be a few bools/enums,and > > iterating through them would be easy, while special casingand > > skipping deemed invalid combinations, like ms runtime and > > pthreads,and possibly ms runtime and x windows.> > Really, it might surprise folks, but really, basically every single > > combination works.> > Compilers are very independent of headers and libs and headers and > > libs are very independent of compilers, aside from a few language > > extensions like __stdcall. You can generally mix runtimes in the > > same process, just as you can mix them on the same machine, you just > > need to be careful about what you pass to what. If you call fopen, > > be sure pass the result back to the matching fclose, malloc/free, > > etc. Startup code, to the extent that it matters, might be a > > problem, but really, just avoid C++ globals with > > constructors/destructors anyway, they are always a problem. Modula-3 > > has its own startup code, and if you were to write "main" in C and > > link in Modula-3 static .libs, that probably doesn't work...might > > actually be better to play into whatever the platform's C++ > > constructor story is, as problematic as they (probably always?) are > > -- i.e. unpredictable/hard-to-control ordering.> >> > (bad editing...and maybe use hex for compression..)> >> > Bringing back cminstall is almost interesting, to promptthe user, or > > probe their system, though Quake/cm3 can probe at runtime.if os == > > windows_nt system_cc | findstr version | findstr gcc else > > system_cc | findstr visual c++else system_cc | grep version | grep > > gcc else system_cc | grep visual c++end> >> > inefficient.> >> > anyway, I'll merge current NT386GNU into NT386 and make it chosehow > > to compile/link which are the main variables today.> > and then decide about cygwin, but probably do like the above, > > sinceit'll totally share code with NT386 except the naming > > conventionsand the removal of the -mno-cygwin switch..> >> > I know this seems overly complicated, but it should be > > exposableeasily enough to users by hiding the choices, presenting > > three basic ones,and still allow all the obvious and perhaps useful > > knobs, and iterating throughthe combinations, without creating a > > combinatorial explosion of source filesor Modula-3 or Quake code.> > ...Jay> >> >> > From: jayk123 at hotmail.comTo: m3devel at elegosoft.comDate: Tue, 22 Jan > > 2008 10:48:56 +0000Subject: Re: [M3devel] platform/build_dir is a > > big tuple?> >> >> > Final answer? I played around with this but just can't accept > > platforms/build_dirs like: ntx86msmsmscm3msn ntx86gccgcccm3cgmsn > > ntx86gccgcccm3cgxn ntx86-gggggmn ntx86-ggixn ntx86_mmmimmOk, I > > have one more name here, and then a bit of a change, or a stronger > > statement of something I had already said.NT386MINGNUOk, I think we > > (me!) are confusing host and target, MOSTLY.And cm3 might not have > > them quite divided appropriately.What is a "host"? What is a > > "target"?MinGWin and Visual C++ output similar results, targetingthe > > same runtime (usually), threading library, windowing library.There > > is a chance for exception handling to diverge however.Well, speaking > > of Visual C++ the C/C++ compiler and MinGWinthe gcc environment, > > yes, very different, not interoperable.MinGWin uses what gcc calls > > "sjlj" -- setjmp/longjmp exceptions.Very inefficient. But heck, gcc > > doesn't support __try/__except/__finally,only C++ exceptions, and > > interop of C++ is often not great,what with name mangling and > > all.NT386GNU's OUTPUT uses a different runtime, unless you trim > > dependencies, possibly a different threading library, possibly a > > different windowing library. All this probably configurable. Again > > exception handling is a sore point in that it is the primary C > > runtime dependency of Modula-3. If you use Cygwin but say > > -mno-cygwin, that means you are targeting NT386. (and don't use > > pthreads or X Windows; behavior of exceptions/setjmp/longjmp TBD -- > > really, need to not use the -mno-cygwin headers in that case; I'll > > check).Perhaps m3core.dll should export > > m3_setjmp/m3_longjmp..Either one can do a cross build to the > > other.Two cm3.exes, two sets of outputs, that either can > > produce.NT386 can use gcc or the integrated backend. And the gcc > > it uses can be MinGWin or Cygwin. (theoretically and probably soon > > reality) NT386GNU can use either as well! (also currently theory, > > but a real possibility) It isn't GNU tools, it is GNU runtime.One > > small area with cm3 might fall down just slightly is that of > > cross builds where host and target have different naming > > conventions. -lfoo vs. foo.lib, foo.o vs. foo.obj are an aspect > > of the host and I vaguely recall that cm3 ties naming convention > > to ostype. The appending of .exe is a target characteristics, but > > the others are not really. Naming convention is really a host > > thing and not a target thing.The config files are a mix of host and > > target information, mostly actually host, except for the one line > > that says TARGET. Most of the target variation is in cm3, which > > always can do any, and cm3cg (which might be nice to be similar, > > but that's another matter and not likely to ever change, except > > when AMD64 is the last architecture standing. :) )If Windows had > > "rpath", then SL would be split between HOST_SL and TARGET_SL.As it > > stands, SL is HOST_SL.Consider as well the various versions of > > Visual C++.They output mostly the same, very interoperable.Consider > > optimization switches. Host or target?Consider version of gcc or > > Visual C++? Host or target?Well, inevitably, the host has an affect > > on the target. If not the for the host, the target would not even > > exist. Bugs in the host produce bugs in the target. etc.(And > > realize that Cygwin runs on top of an OS built witha Microsoft > > compiler, so really there is interop, but sometimes through a > > layer.) So there's a risk of saying there is six+ > > combinations.(host cygwin, host mingwin, host native) x (target > > nt386, target nt386gnu) But generally the host is assumed not a > > factor. I guess "LIBC" could be seperated into several options...You > > could actually have code that needs one runtime or another, and > > they couldlink together, depending on what they do.. This is > > something I don't know if cm3 handles, or anything I have seen. I > > should be able to build a static .lib, that includes some C code, > > that imbues its clients with build time dependencies. Well, I > > guess #pragma comment(linker) is this.So the next tasks are > > roughly: Merge my NT386 and NT386GNU files. Switching on a > > variable such as backend mode. Introduce a "new" (old) NT386GNU > > file, perhaps more like what was already there. Change NT386GNU > > back to Posix. Build NT386GNU. oh, one more point...while these > > are two targets from cm3's point of view, they are PROBABLY the > > same target to cm3cgand so only one is needed. I have to check if > > configure differentiates between i686-pc-cygwin and > > i686-pc-mingwin...but I guess it should...It might actually be > > profitable to have two bloated cm3cg.exe's.And they should ship to > > \cm3\pkg\m3cc\target\host or host\target and cm3 should know which > > to run.Blech..four of them when one would suffice?The detail being > > mainly what the paths to .libs look like, unfortunate.Possibly cm3 > > can bridge this gap using that "broken" feature that symlinks libs > > into the target directory,using NTFS hard links, if installroot and > > root are on the same volume... (or symlinks on Vista).Or maybe > > convert the paths as appropriate, hacky, but saves an extra > > cm3cg.exe which is good to avoid. (all the more reason to lump all > > targets into one file, so that the host x target matrix collapses > > to just one axis, host; andthen you can write stuff in > > Perl/Python/Java/C# to collapse that to just one, except for the > > underlying runtime/interpreter...) Oh, cm3cg isn't the issue. It is > > always sitting in the correct directory and reads one file and > > writes one file, no slashes.The issue is gcc as the linker. Again, > > this is a host issue..and cm3 or the config file definitely should > > do the translation. - Jay> >> >> > From: jayk123 at hotmail.comTo: m3devel at elegosoft.comDate: Mon, 21 Jan > > 2008 23:01:44 +0000Subject: [M3devel] platform/build_dir is a big > > tuple?> >> > 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> > > > -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 Jan 22 17:54:37 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 22 Jan 2008 16:54:37 +0000 Subject: [M3devel] platform/build_dir is a big tuple? In-Reply-To: References: <20080122142922.k73w5es5j4gckso4@mail.elegosoft.com> Message-ID: This is essentially in now. I understand all those points, but there are pluses and minuses either way. Including: > 3 (e.g. --)) "variant", that's space for arbitrary variation, it's not one variable. This scheme acknowledges two common variables and leaves slush to try to cope with what else there is. Of course, it would be a big advance over what is there. And yes I realize you lose somehow one way or another. Anyway, if what I have is acceptable, or shows an acceptable direction that is *almost* complete (it is definitely not quite complete, since Cygwin isn't active yet), I can start winding down this topic. :) The scheme I have..I kind of already said this..TARGET will always be NT386, and it is configurable. Three of the configurations are recognized and given made up short readable build_dir.To me, from the user perspective, build_dir is a critical aspect of target, so you can kind of give the appearance of targets without adding full scale new targets, which I realize would be "ok". The rest, if you try them, get mechnical build_dir. What I haven't worked out yet is, like..before there was the TARGET/CM3_TARGET environment variables. Those should probably remain and get translated..which actually pretty much already works -- the environment variable will map not to a target, but to a config file name, and it will handle everything. I haven't tried this. I left the old targets for temporary compat. Later... arch-os-variant is fine I'd like to check what the four element gnu configurations. arch-os-variant won't apply for the two "new" targets I'm working on presumably, since they derive from the existing NT386. I assume given NT386, and essentially NT386GNU, nobody would argue for introducing I386_NT_MINGWIN or I386_NT_CYGWIN, but maybe. And yes I know, sorry, I'm being a bit of a jerk, asking for something, getting it, and then not taking it. If people do want I386_NT_MINGIN or X86_NT_MINGNU, ok with me. - Jay From: jayk123 at hotmail.comTo: wagner at elegosoft.com; m3devel at elegosoft.comDate: Tue, 22 Jan 2008 14:29:04 +0000Subject: Re: [M3devel] platform/build_dir is a big tuple? I know, I've heard it many times from smart people, but sorry I can't resist. I will strive for a balance. In particular I'm thinking NT386 sets a few globals as described include NT386.commonNT386GNU sets a few globals as described include NT386.commonNT386MINGNU sets a few globals as described include NT386.commonNT386.common will not be the simplest. CM3 might know about a few more of these globals than it already does. Under the covers, there is already lots and lots and lots of complexity and always will be (look at the stuff I debugged, which I admit was half stupid since PM3 had half the diffs -- I didn't find their config file to see about the double alignment though, so I was stuck debugging that afaik). - Jay > Date: Tue, 22 Jan 2008 14:29:22 +0100> From: wagner at elegosoft.com> To: m3devel at elegosoft.com> Subject: Re: [M3devel] platform/build_dir is a big tuple?> > All this may be useful during development, but it is not really> useful for a software distribution to our users, I think.> > Nobody will understand it :-( We need to keep things more simple.> > We don't need to support everything out of the box. Instead, we should> offer some sensible default combinations of everyhing you describe.> > First of all: we don't distribute cross compilers (at least until now).> This is a special topic reserved for adding new platforms.> > Runtime and compilers used do not necessarily need to be distinguished> by target or build dir, in many cases different cm3.cfg may suffice.> > Until now, threading models are also no choice that needs to be> visible at this level. There's one default model for every target,> and the user can change it by recompiling.> > And if we should really agree that changing the target naming scheme> is a good idea, we should> > o use a systematic one with not more than 4 elements (better still,> 3 (e.g. --))> o don't use cryptic abbreviations that will confuse most people> > Just my 2 cents,> > Olaf> > Quoting Jay :> > I'm still torn over that any NT386 target could have a choice of > > three threading models (win32, pthread, vtalarm), two windowing > > libraries (ms, x), two (three) compilers (ms, mingwin, cygwin), two > > (three) linkers (ms, mingwn, cygwin), various runtimes (msvc various > > versions, cygwin, mingwin (discouraged)) etc.> >> > Appending a short string of unreadable bits to BUILD_DIR is very > > temptingin order to easily generate and test the combinatorial > > possibilities.> >> > backend: 0 integrated, 1 gcc already a setting (with four values)> >> > ccompiler/linker: 0 ms, 1 gcc (these could be split, and could > > allocate more bits...) maybe 00 ms, 01 cygwin, 10 ming maybe define > > enum up front that allows for watcom, metrowerks, digitalmars, llvm > > etc.> > maybe use a decimal digit for all these, and 0 is reserved, maybe.> >> > threading: 0 win32, 1 pthreads drop vtalarm, or use two bits?> >> > windowing: 0 ms, 1 x> >> > cruntime: 0 ms, 1 cyg There is also a ming runtime, discouraged > > There also really N ms runtimes, ming offers several: msvcrt.dll, > > msvcr70.dll, msvcr71.dll, msvcr80.dll, msvcr90.dll... but jmpbuf > > presumbly doesn't change again could allocate multiple bits..> >> > cruntime I guess determines oSTYPE Win32 or Posix, thoughit loses > > its meaning mostly, and X vs. not-X is usually decide the same...> >> > The three most common combinations: 00000 -- NT386 11111 -- > > NT386GNU 11000 -- NT386MINGNU> >> > but several others would work 11101 -- cygwin with native windowing > > 11011 -- cygwin with native threads 11001 -- cygwin with native > > threads and native windowing> > BUILD_DIR would be NT386-$(config)as a special case perhaps, the > > three commoncases could be translated to the above strings.> >> > But the underlying implementation would be a few bools/enums,and > > iterating through them would be easy, while special casingand > > skipping deemed invalid combinations, like ms runtime and > > pthreads,and possibly ms runtime and x windows.> > Really, it might surprise folks, but really, basically every single > > combination works.> > Compilers are very independent of headers and libs and headers and > > libs are very independent of compilers, aside from a few language > > extensions like __stdcall. You can generally mix runtimes in the > > same process, just as you can mix them on the same machine, you just > > need to be careful about what you pass to what. If you call fopen, > > be sure pass the result back to the matching fclose, malloc/free, > > etc. Startup code, to the extent that it matters, might be a > > problem, but really, just avoid C++ globals with > > constructors/destructors anyway, they are always a problem. Modula-3 > > has its own startup code, and if you were to write "main" in C and > > link in Modula-3 static .libs, that probably doesn't work...might > > actually be better to play into whatever the platform's C++ > > constructor story is, as problematic as they (probably always?) are > > -- i.e. unpredictable/hard-to-control ordering.> >> > (bad editing...and maybe use hex for compression..)> >> > Bringing back cminstall is almost interesting, to promptthe user, or > > probe their system, though Quake/cm3 can probe at runtime.if os == > > windows_nt system_cc | findstr version | findstr gcc else > > system_cc | findstr visual c++else system_cc | grep version | grep > > gcc else system_cc | grep visual c++end> >> > inefficient.> >> > anyway, I'll merge current NT386GNU into NT386 and make it chosehow > > to compile/link which are the main variables today.> > and then decide about cygwin, but probably do like the above, > > sinceit'll totally share code with NT386 except the naming > > conventionsand the removal of the -mno-cygwin switch..> >> > I know this seems overly complicated, but it should be > > exposableeasily enough to users by hiding the choices, presenting > > three basic ones,and still allow all the obvious and perhaps useful > > knobs, and iterating throughthe combinations, without creating a > > combinatorial explosion of source filesor Modula-3 or Quake code.> > ...Jay> >> >> > From: jayk123 at hotmail.comTo: m3devel at elegosoft.comDate: Tue, 22 Jan > > 2008 10:48:56 +0000Subject: Re: [M3devel] platform/build_dir is a > > big tuple?> >> >> > Final answer? I played around with this but just can't accept > > platforms/build_dirs like: ntx86msmsmscm3msn ntx86gccgcccm3cgmsn > > ntx86gccgcccm3cgxn ntx86-gggggmn ntx86-ggixn ntx86_mmmimmOk, I > > have one more name here, and then a bit of a change, or a stronger > > statement of something I had already said.NT386MINGNUOk, I think we > > (me!) are confusing host and target, MOSTLY.And cm3 might not have > > them quite divided appropriately.What is a "host"? What is a > > "target"?MinGWin and Visual C++ output similar results, targetingthe > > same runtime (usually), threading library, windowing library.There > > is a chance for exception handling to diverge however.Well, speaking > > of Visual C++ the C/C++ compiler and MinGWinthe gcc environment, > > yes, very different, not interoperable.MinGWin uses what gcc calls > > "sjlj" -- setjmp/longjmp exceptions.Very inefficient. But heck, gcc > > doesn't support __try/__except/__finally,only C++ exceptions, and > > interop of C++ is often not great,what with name mangling and > > all.NT386GNU's OUTPUT uses a different runtime, unless you trim > > dependencies, possibly a different threading library, possibly a > > different windowing library. All this probably configurable. Again > > exception handling is a sore point in that it is the primary C > > runtime dependency of Modula-3. If you use Cygwin but say > > -mno-cygwin, that means you are targeting NT386. (and don't use > > pthreads or X Windows; behavior of exceptions/setjmp/longjmp TBD -- > > really, need to not use the -mno-cygwin headers in that case; I'll > > check).Perhaps m3core.dll should export > > m3_setjmp/m3_longjmp..Either one can do a cross build to the > > other.Two cm3.exes, two sets of outputs, that either can > > produce.NT386 can use gcc or the integrated backend. And the gcc > > it uses can be MinGWin or Cygwin. (theoretically and probably soon > > reality) NT386GNU can use either as well! (also currently theory, > > but a real possibility) It isn't GNU tools, it is GNU runtime.One > > small area with cm3 might fall down just slightly is that of > > cross builds where host and target have different naming > > conventions. -lfoo vs. foo.lib, foo.o vs. foo.obj are an aspect > > of the host and I vaguely recall that cm3 ties naming convention > > to ostype. The appending of .exe is a target characteristics, but > > the others are not really. Naming convention is really a host > > thing and not a target thing.The config files are a mix of host and > > target information, mostly actually host, except for the one line > > that says TARGET. Most of the target variation is in cm3, which > > always can do any, and cm3cg (which might be nice to be similar, > > but that's another matter and not likely to ever change, except > > when AMD64 is the last architecture standing. :) )If Windows had > > "rpath", then SL would be split between HOST_SL and TARGET_SL.As it > > stands, SL is HOST_SL.Consider as well the various versions of > > Visual C++.They output mostly the same, very interoperable.Consider > > optimization switches. Host or target?Consider version of gcc or > > Visual C++? Host or target?Well, inevitably, the host has an affect > > on the target. If not the for the host, the target would not even > > exist. Bugs in the host produce bugs in the target. etc.(And > > realize that Cygwin runs on top of an OS built witha Microsoft > > compiler, so really there is interop, but sometimes through a > > layer.) So there's a risk of saying there is six+ > > combinations.(host cygwin, host mingwin, host native) x (target > > nt386, target nt386gnu) But generally the host is assumed not a > > factor. I guess "LIBC" could be seperated into several options...You > > could actually have code that needs one runtime or another, and > > they couldlink together, depending on what they do.. This is > > something I don't know if cm3 handles, or anything I have seen. I > > should be able to build a static .lib, that includes some C code, > > that imbues its clients with build time dependencies. Well, I > > guess #pragma comment(linker) is this.So the next tasks are > > roughly: Merge my NT386 and NT386GNU files. Switching on a > > variable such as backend mode. Introduce a "new" (old) NT386GNU > > file, perhaps more like what was already there. Change NT386GNU > > back to Posix. Build NT386GNU. oh, one more point...while these > > are two targets from cm3's point of view, they are PROBABLY the > > same target to cm3cgand so only one is needed. I have to check if > > configure differentiates between i686-pc-cygwin and > > i686-pc-mingwin...but I guess it should...It might actually be > > profitable to have two bloated cm3cg.exe's.And they should ship to > > \cm3\pkg\m3cc\target\host or host\target and cm3 should know which > > to run.Blech..four of them when one would suffice?The detail being > > mainly what the paths to .libs look like, unfortunate.Possibly cm3 > > can bridge this gap using that "broken" feature that symlinks libs > > into the target directory,using NTFS hard links, if installroot and > > root are on the same volume... (or symlinks on Vista).Or maybe > > convert the paths as appropriate, hacky, but saves an extra > > cm3cg.exe which is good to avoid. (all the more reason to lump all > > targets into one file, so that the host x target matrix collapses > > to just one axis, host; andthen you can write stuff in > > Perl/Python/Java/C# to collapse that to just one, except for the > > underlying runtime/interpreter...) Oh, cm3cg isn't the issue. It is > > always sitting in the correct directory and reads one file and > > writes one file, no slashes.The issue is gcc as the linker. Again, > > this is a host issue..and cm3 or the config file definitely should > > do the translation. - Jay> >> >> > From: jayk123 at hotmail.comTo: m3devel at elegosoft.comDate: Mon, 21 Jan > > 2008 23:01:44 +0000Subject: [M3devel] platform/build_dir is a big > > tuple?> >> > 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> > > > -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 hosking at cs.purdue.edu Tue Jan 22 18:50:44 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 22 Jan 2008 12:50:44 -0500 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <20080122163601.6245410D4608@birch.elegosoft.com> References: <20080122163601.6245410D4608@birch.elegosoft.com> Message-ID: <9C3615E5-FEDB-4AAB-BFC7-AFE867C94241@cs.purdue.edu> Do we really want to build all the Windows interfaces even on non- Windows hosts? Yuck. On Jan 22, 2008, at 5:36 PM, Jay Krell wrote: > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 08/01/22 17:36:01 > > Modified files: > cm3/m3-sys/cm3/src/: M3Backend.m3 m3makefile > cm3/scripts/: backup-pkgs.sh boot-cm3-build-on-target.sh > boot-cm3-core.sh boot-cm3-with-m3.sh > copy-bootarchives.sh do-cm3-core.sh > make-bin-dist-min.sh pack-crossbuild.sh pkginfo.sh > Removed files: > cm3/m3-sys/cm3/src/: M3BackPosix.m3 M3BackWin32.m3 > > Log message: > put integrated backend into all hosts, so that cross builds work > a bit more; built on PPC_DARWIN (ie: built on Posix, where it's > an actual diff; what this will enable for me is a "semi-cros" > from a NT386GNU cm3.exe to NT386/NT386MINGNU. And it's fairly cheap, > the integrated backend is nothing compared to cm3cg. > did not run all the .sh files, just upgrade.sh > Note that m3staloneback is relatively unused, probably for > debugging, left alone. > mklib should come in as well for cross purposes but left that > alone too. > There are warnings in WinDef.m3 about <*WINAPI*> on function pointer > types. Perhaps they can be deferred and only trigger if the types > are used? If the types are called? ie: make the pragma understood, > but > don't support calling using calling conventions not supported by > target From hosking at cs.purdue.edu Tue Jan 22 18:54:04 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 22 Jan 2008 12:54:04 -0500 Subject: [M3devel] platform/build_dir is a big tuple? In-Reply-To: <20080122142922.k73w5es5j4gckso4@mail.elegosoft.com> References: <20080122142922.k73w5es5j4gckso4@mail.elegosoft.com> Message-ID: <2AB0D273-C3B8-4D46-BCC1-4D032692DCB0@cs.purdue.edu> On Jan 22, 2008, at 8:29 AM, Olaf Wagner wrote: > All this may be useful during development, but it is not really > useful for a software distribution to our users, I think. > > Nobody will understand it :-( We need to keep things more simple. > > We don't need to support everything out of the box. Instead, we should > offer some sensible default combinations of everyhing you describe. > > First of all: we don't distribute cross compilers (at least until > now). > This is a special topic reserved for adding new platforms. Precisely why I don't like many of the recent changes. I don't want to build Windows interfaces and gorp for a non-Windows platform. Jay, can you *please* back these changes out? > > Runtime and compilers used do not necessarily need to be distinguished > by target or build dir, in many cases different cm3.cfg may suffice. > > Until now, threading models are also no choice that needs to be > visible at this level. There's one default model for every target, > and the user can change it by recompiling. > > And if we should really agree that changing the target naming scheme > is a good idea, we should > > o use a systematic one with not more than 4 elements (better still, > 3 (e.g. --)) > o don't use cryptic abbreviations that will confuse most people > > Just my 2 cents, > > Olaf > > Quoting Jay : >> I'm still torn over that any NT386 target could have a choice of >> three threading models (win32, pthread, vtalarm), two windowing >> libraries (ms, x), two (three) compilers (ms, mingwin, cygwin), >> two (three) linkers (ms, mingwn, cygwin), various runtimes (msvc >> various versions, cygwin, mingwin (discouraged)) etc. >> >> Appending a short string of unreadable bits to BUILD_DIR is very >> temptingin order to easily generate and test the combinatorial >> possibilities. >> >> backend: 0 integrated, 1 gcc already a setting (with four values) >> >> ccompiler/linker: 0 ms, 1 gcc (these could be split, and could >> allocate more bits...) maybe 00 ms, 01 cygwin, 10 ming maybe >> define enum up front that allows for watcom, metrowerks, >> digitalmars, llvm etc. >> maybe use a decimal digit for all these, and 0 is reserved, maybe. >> >> threading: 0 win32, 1 pthreads drop vtalarm, or use two bits? >> >> windowing: 0 ms, 1 x >> >> cruntime: 0 ms, 1 cyg There is also a ming runtime, discouraged >> There also really N ms runtimes, ming offers several: >> msvcrt.dll, msvcr70.dll, msvcr71.dll, msvcr80.dll, >> msvcr90.dll... but jmpbuf presumbly doesn't change again could >> allocate multiple bits.. >> >> cruntime I guess determines oSTYPE Win32 or Posix, thoughit loses >> its meaning mostly, and X vs. not-X is usually decide the same... >> >> The three most common combinations: 00000 -- NT386 11111 -- >> NT386GNU 11000 -- NT386MINGNU >> >> but several others would work 11101 -- cygwin with native >> windowing 11011 -- cygwin with native threads 11001 -- cygwin >> with native threads and native windowing >> BUILD_DIR would be NT386-$(config)as a special case perhaps, the >> three commoncases could be translated to the above strings. >> >> But the underlying implementation would be a few bools/enums,and >> iterating through them would be easy, while special casingand >> skipping deemed invalid combinations, like ms runtime and >> pthreads,and possibly ms runtime and x windows. >> Really, it might surprise folks, but really, basically every >> single combination works. >> Compilers are very independent of headers and libs and headers >> and libs are very independent of compilers, aside from a few >> language extensions like __stdcall. You can generally mix >> runtimes in the same process, just as you can mix them on the >> same machine, you just need to be careful about what you pass to >> what. If you call fopen, be sure pass the result back to the >> matching fclose, malloc/free, etc. Startup code, to the extent >> that it matters, might be a problem, but really, just avoid C++ >> globals with constructors/destructors anyway, they are always a >> problem. Modula-3 has its own startup code, and if you were to >> write "main" in C and link in Modula-3 static .libs, that >> probably doesn't work...might actually be better to play into >> whatever the platform's C++ constructor story is, as problematic >> as they (probably always?) are -- i.e. unpredictable/hard-to- >> control ordering. >> >> (bad editing...and maybe use hex for compression..) >> >> Bringing back cminstall is almost interesting, to promptthe user, >> or probe their system, though Quake/cm3 can probe at runtime.if >> os == windows_nt system_cc | findstr version | findstr gcc >> else system_cc | findstr visual c++else system_cc | grep >> version | grep gcc else system_cc | grep visual c++end >> >> inefficient. >> >> anyway, I'll merge current NT386GNU into NT386 and make it >> chosehow to compile/link which are the main variables today. >> and then decide about cygwin, but probably do like the above, >> sinceit'll totally share code with NT386 except the naming >> conventionsand the removal of the -mno-cygwin switch.. >> >> I know this seems overly complicated, but it should be >> exposableeasily enough to users by hiding the choices, presenting >> three basic ones,and still allow all the obvious and perhaps >> useful knobs, and iterating throughthe combinations, without >> creating a combinatorial explosion of source filesor Modula-3 or >> Quake code. >> ...Jay >> >> >> From: jayk123 at hotmail.comTo: m3devel at elegosoft.comDate: Tue, 22 >> Jan 2008 10:48:56 +0000Subject: Re: [M3devel] platform/build_dir >> is a big tuple? >> >> >> Final answer? I played around with this but just can't accept >> platforms/build_dirs like: ntx86msmsmscm3msn >> ntx86gccgcccm3cgmsn ntx86gccgcccm3cgxn ntx86-gggggmn ntx86- >> ggixn ntx86_mmmimmOk, I have one more name here, and then a bit >> of a change, or a stronger statement of something I had already >> said.NT386MINGNUOk, I think we (me!) are confusing host and >> target, MOSTLY.And cm3 might not have them quite divided >> appropriately.What is a "host"? What is a "target"?MinGWin and >> Visual C++ output similar results, targetingthe same runtime >> (usually), threading library, windowing library.There is a chance >> for exception handling to diverge however.Well, speaking of >> Visual C++ the C/C++ compiler and MinGWinthe gcc environment, >> yes, very different, not interoperable.MinGWin uses what gcc >> calls "sjlj" -- setjmp/longjmp exceptions.Very inefficient. But >> heck, gcc doesn't support __try/__except/__finally,only C++ >> exceptions, and interop of C++ is often not great,what with name >> mangling and all.NT386GNU's OUTPUT uses a different runtime, >> unless you trim dependencies, possibly a different threading >> library, possibly a different windowing library. All this >> probably configurable. Again exception handling is a sore point >> in that it is the primary C runtime dependency of Modula-3. If >> you use Cygwin but say -mno-cygwin, that means you are targeting >> NT386. (and don't use pthreads or X Windows; behavior of >> exceptions/setjmp/longjmp TBD -- really, need to not use the - >> mno-cygwin headers in that case; I'll check).Perhaps m3core.dll >> should export m3_setjmp/m3_longjmp..Either one can do a cross >> build to the other.Two cm3.exes, two sets of outputs, that either >> can produce.NT386 can use gcc or the integrated backend. And the >> gcc it uses can be MinGWin or Cygwin. (theoretically and probably >> soon reality) NT386GNU can use either as well! (also currently >> theory, but a real possibility) It isn't GNU tools, it is GNU >> runtime.One small area with cm3 might fall down just slightly is >> that of cross builds where host and target have different >> naming conventions. -lfoo vs. foo.lib, foo.o vs. foo.obj are an >> aspect of the host and I vaguely recall that cm3 ties naming >> convention to ostype. The appending of .exe is a target >> characteristics, but the others are not really. Naming >> convention is really a host thing and not a target thing.The >> config files are a mix of host and target information, mostly >> actually host, except for the one line that says TARGET. Most of >> the target variation is in cm3, which always can do any, and >> cm3cg (which might be nice to be similar, but that's another >> matter and not likely to ever change, except when AMD64 is the >> last architecture standing. :) )If Windows had "rpath", then SL >> would be split between HOST_SL and TARGET_SL.As it stands, SL is >> HOST_SL.Consider as well the various versions of Visual C++.They >> output mostly the same, very interoperable.Consider optimization >> switches. Host or target?Consider version of gcc or Visual C++? >> Host or target?Well, inevitably, the host has an affect on the >> target. If not the for the host, the target would not even >> exist. Bugs in the host produce bugs in the target. etc.(And >> realize that Cygwin runs on top of an OS built witha Microsoft >> compiler, so really there is interop, but sometimes through a >> layer.) So there's a risk of saying there is six+ combinations. >> (host cygwin, host mingwin, host native) x (target nt386, target >> nt386gnu) But generally the host is assumed not a factor. I >> guess "LIBC" could be seperated into several options...You could >> actually have code that needs one runtime or another, and they >> couldlink together, depending on what they do.. This is something >> I don't know if cm3 handles, or anything I have seen. I should be >> able to build a static .lib, that includes some C code, that >> imbues its clients with build time dependencies. Well, I guess >> #pragma comment(linker) is this.So the next tasks are roughly: >> Merge my NT386 and NT386GNU files. Switching on a variable such >> as backend mode. Introduce a "new" (old) NT386GNU file, >> perhaps more like what was already there. Change NT386GNU back >> to Posix. Build NT386GNU. oh, one more point...while these are >> two targets from cm3's point of view, they are PROBABLY the same >> target to cm3cgand so only one is needed. I have to check if >> configure differentiates between i686-pc-cygwin and i686-pc- >> mingwin...but I guess it should...It might actually be profitable >> to have two bloated cm3cg.exe's.And they should ship to \cm3\pkg >> \m3cc\target\host or host\target and cm3 should know which to >> run.Blech..four of them when one would suffice?The detail being >> mainly what the paths to .libs look like, unfortunate.Possibly >> cm3 can bridge this gap using that "broken" feature that symlinks >> libs into the target directory,using NTFS hard links, if >> installroot and root are on the same volume... (or symlinks on >> Vista).Or maybe convert the paths as appropriate, hacky, but >> saves an extra cm3cg.exe which is good to avoid. (all the more >> reason to lump all targets into one file, so that the host x >> target matrix collapses to just one axis, host; andthen you can >> write stuff in Perl/Python/Java/C# to collapse that to just one, >> except for the underlying runtime/interpreter...) Oh, cm3cg isn't >> the issue. It is always sitting in the correct directory and >> reads one file and writes one file, no slashes.The issue is gcc >> as the linker. Again, this is a host issue..and cm3 or the config >> file definitely should do the translation. - Jay >> >> >> From: jayk123 at hotmail.comTo: m3devel at elegosoft.comDate: Mon, 21 >> Jan 2008 23:01:44 +0000Subject: [M3devel] platform/build_dir is a >> big tuple? >> >> 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 > > > > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, > Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 > 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: > Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > DE163214194 > From rcoleburn at scires.com Tue Jan 22 20:48:38 2008 From: rcoleburn at scires.com (Randy Coleburn) Date: Tue, 22 Jan 2008 14:48:38 -0500 Subject: [M3devel] next problem (NT386GNU) In-Reply-To: References: <6E1E4409-F3D9-4982-B179-2D4C9648FDD0@cs.purdue.edu> <1A6EC7D6-32B2-44AD-933F-6976040A7D7F@cs.purdue.edu> <20080122081049.74tzfvozwo4wwwow@mail.elegosoft.com> Message-ID: <47960244.1E75.00D7.1@scires.com> Jay / Olaf: I installed CVSNT and TortoiseCVS. I am having some trouble with "update" however. When I try to update the whole tree, it begins working, but after a little while I start seeing messages that checksums didn't match on certain files and that it will refetch. Then, after just a little longer, it stops responding. I've left it running for hours, but no new lines scroll by saying it is doing anything. Finally, I just hit cancel and it promptly stops and informs me it aborted the operation, as if it been waiting all along for me to tell it to give up. Now, if I update individual files or selected files, it seems to work no problem. And, I've been able to check out the whole repository, and yes it does take some time to pull everything down. I can also do diffs on selected files. I've also used it to commit a few files to the repository. So, it is working fine, except for update. Either something is amiss, or I'm not doing something just right. I am about to consider going back to cygwin and running its version of cvs on my tree to see if it will do the update, but I seem to recall reading somewhere that is not good to mix between cvs and cvsnt on the same tree. Jay, I too have used WinDiff for a long time. But, with the CVSNT and Tortoise installs, I also installed WinMerge. ( http://winmerge.org/ ) I'm still learning more about it, but so far, I have enjoyed it better than WinDiff because in addition to letting you see the diffs, it also lets you selectively merge diffs between the files using a GUI. It also integrates nicely with TortoiseCVS. Jay, you can get command line completion in Windows, but you have to make a registry tweak. There are actually two tweaks: one for filename completion and one for pathname completion. They are quite simple. See instructions below: Enable automatic completion for the computer as follows: a. Click Start, click Run, type regedit, and then click OK. b. Locate and click the HKEY_LOCAL_MACHINE\Software\Microsoft\Command Processor key c. Double-click the CompletionChar value and type 9 as the value; Windows converts it to hexadecimal. d. Double-click the PathCompletionChar value and type 9 as the value; Windows converts it to hexadecimal. e. Quit Registry Editor. Note that this modification allows you to press the TAB key while in a command prompt window in order to perform automatic filename and pathname completion. (You may have to restart or log in again before this modification will take affect.) Regards, Randy >>> Jay 1/22/2008 2:34 AM >>> Olaf, yes and no. How do I then bring the files into mainline? Which Tinderbox is testing them? This is impossible question probably, because Tinderbox for private changes probably doesn't scale well. But it would be nice. And other than private branches, submitting diffs would be nice. Or, as well, these can be crutches for bad changes, and people can abuse the Tinderbox. It's tough though, because a multi machine Tinderbox can always easily do much more diligence than one developer and his local machines. (What's the Win32 Tinderbox story, I wonder? I guess first I can see if Mozilla has one, and if not, it probably doesn't exist, if so, it does :) ) I don't mind the command line, but I'm a bit slow learning new tools. I find new source control systems daunting. I'm quite expert with Perforce though including branching, integrating, resolving, etc.. You don't have to be in Cygwin (sh) to use cvs, but it's true, one very annoying thing about all these forward-slash-requiring tools is I lose the usefulness of command line completion in cmd. Cmd is quite good at editing command lines, keeping output and command line history (set the scrollback to 9999), copy/paste, and is very fast, nothing else that I have tried competes. Most are even merely slower on their video output except maybe the actual text ones. The F8 feature, command line completion against history, which I can't explain well, is really great. MSys comes up with awful colors that I couldn't figure out how to change. Cygwin makes all your paths be /cygdrive/c/... which is just ugly and long. MSys/MinGWin are much nicer with merely /c... I installed TortoiseCVS but it didn't work..I need to look into how to get it to use ssh. But as well, if my work doesn't suck too much, it should be fine for mainline. Look at diffs is really also slow. I've done best by always saving away an .orig file and then windiff. Otherwise 1) is very slow 2) textual diffs...I use the command line all the time, but for viewing diffs...it's really insufficient. - Jay > Date: Tue, 22 Jan 2008 08:10:49 +0100 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] next problem (NT386GNU) > > Quoting Jay : > > > I don't want to deal with learning about CVS branches, please. > > I don't understand the problems some people seem to have with CVS. > Creating a branch is really simple: > > o create a branch tag, for example: > > cvs tag -b devel_nt386gnu_gcc_opt files(s) > > o update to that branch: > > cvs up -r devel_nt386gnu_gcc_opt files(s) > > That's it. The tag is now `sticky' on the files, i.e. remembered > in the CVS/Entries files in your workspace. From now on you're > using the branch for the mentioned files. To restore them to the > latest main trunk version, use > > cvs up -A files(s) > > And Jay, as a Windows user you probably don't like to use the cvs > commandline in Cygwin; just install CVS-NT and tortoise (Randy did, > too). It may be more convenient for you. > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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". Check it out. ( http://www.msnmobilefix.com/Default.aspx ) -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcoleburn at scires.com Tue Jan 22 21:03:45 2008 From: rcoleburn at scires.com (Randy Coleburn) Date: Tue, 22 Jan 2008 15:03:45 -0500 Subject: [M3devel] platform/build_dir is a big tuple? In-Reply-To: References: Message-ID: <479605CF.1E75.00D7.1@scires.com> Jay: For my part on Windows, I am happy to stay with the underlying OS, the native windows threading, the integrated backend, and use the free Microsoft Visual Studio tools. I don't really want to have to install/use cygwin or any of the other variants. When I see target = NT386, this list is what I am expecting. For the cm3 newbie coming from a Microsoft Windows environment, I think this list would be the most appealing and pose the least barrier to getting starting. Yes, I still will work on the installer program once I'm satisfied that I have a good working cm3 on Windows. Of course, I am just one voice. If you can and want to provide for all of the other variants on windows, that is ok with me. Just don't do away with what I have now. Regards, Randy >>> Jay 1/22/2008 8:00 AM >>> I'm still torn over that any NT386 target could have a choice of three threading models (win32, pthread, vtalarm), two windowing libraries (ms, x), two (three) compilers (ms, mingwin, cygwin), two (three) linkers (ms, mingwn, cygwin), various runtimes (msvc various versions, cygwin, mingwin (discouraged)) etc. Appending a short string of unreadable bits to BUILD_DIR is very tempting in order to easily generate and test the combinatorial possibilities. backend: 0 integrated, 1 gcc already a setting (with four values) ccompiler/linker: 0 ms, 1 gcc (these could be split, and could allocate more bits...) maybe 00 ms, 01 cygwin, 10 ming maybe define enum up front that allows for watcom, metrowerks, digitalmars, llvm etc. maybe use a decimal digit for all these, and 0 is reserved, maybe. threading: 0 win32, 1 pthreads drop vtalarm, or use two bits? windowing: 0 ms, 1 x cruntime: 0 ms, 1 cyg There is also a ming runtime, discouraged There also really N ms runtimes, ming offers several: msvcrt.dll, msvcr70.dll, msvcr71.dll, msvcr80.dll, msvcr90.dll... but jmpbuf presumbly doesn't change again could allocate multiple bits.. cruntime I guess determines oSTYPE Win32 or Posix, though it loses its meaning mostly, and X vs. not-X is usually decide the same... The three most common combinations: 00000 -- NT386 11111 -- NT386GNU 11000 -- NT386MINGNU but several others would work 11101 -- cygwin with native windowing 11011 -- cygwin with native threads 11001 -- cygwin with native threads and native windowing BUILD_DIR would be NT386-$(config) as a special case perhaps, the three common cases could be translated to the above strings. But the underlying implementation would be a few bools/enums, and iterating through them would be easy, while special casing and skipping deemed invalid combinations, like ms runtime and pthreads, and possibly ms runtime and x windows. Really, it might surprise folks, but really, basically every single combination works. Compilers are very independent of headers and libs and headers and libs are very independent of compilers, aside from a few language extensions like __stdcall. You can generally mix runtimes in the same process, just as you can mix them on the same machine, you just need to be careful about what you pass to what. If you call fopen, be sure pass the result back to the matching fclose, malloc/free, etc. Startup code, to the extent that it matters, might be a problem, but really, just avoid C++ globals with constructors/destructors anyway, they are always a problem. Modula-3 has its own startup code, and if you were to write "main" in C and link in Modula-3 static .libs, that probably doesn't work...might actually be better to play into whatever the platform's C++ constructor story is, as problematic as they (probably always?) are -- i.e. unpredictable/hard-to-control ordering. (bad editing...and maybe use hex for compression..) Bringing back cminstall is almost interesting, to prompt the user, or probe their system, though Quake/cm3 can probe at runtime. if os == windows_nt system_cc | findstr version | findstr gcc else system_cc | findstr visual c++ else system_cc | grep version | grep gcc else system_cc | grep visual c++ end inefficient. anyway, I'll merge current NT386GNU into NT386 and make it chose how to compile/link which are the main variables today. and then decide about cygwin, but probably do like the above, since it'll totally share code with NT386 except the naming conventions and the removal of the -mno-cygwin switch.. I know this seems overly complicated, but it should be exposable easily enough to users by hiding the choices, presenting three basic ones, and still allow all the obvious and perhaps useful knobs, and iterating through the combinations, without creating a combinatorial explosion of source files or Modula-3 or Quake code. ...Jay From: jayk123 at hotmail.com To: m3devel at elegosoft.com Date: Tue, 22 Jan 2008 10:48:56 +0000 Subject: Re: [M3devel] platform/build_dir is a big tuple? Final answer? I played around with this but just can't accept platforms/build_dirs like: ntx86msmsmscm3msn ntx86gccgcccm3cgmsn ntx86gccgcccm3cgxn ntx86-gggggmn ntx86-ggixn ntx86_mmmimm Ok, I have one more name here, and then a bit of a change, or a stronger statement of something I had already said. NT386MINGNU Ok, I think we (me!) are confusing host and target, MOSTLY. And cm3 might not have them quite divided appropriately. What is a "host"? What is a "target"? MinGWin and Visual C++ output similar results, targeting the same runtime (usually), threading library, windowing library. There is a chance for exception handling to diverge however. Well, speaking of Visual C++ the C/C++ compiler and MinGWin the gcc environment, yes, very different, not interoperable. MinGWin uses what gcc calls "sjlj" -- setjmp/longjmp exceptions. Very inefficient. But heck, gcc doesn't support __try/__except/__finally, only C++ exceptions, and interop of C++ is often not great, what with name mangling and all. NT386GNU's OUTPUT uses a different runtime, unless you trim dependencies, possibly a different threading library, possibly a different windowing library. All this probably configurable. Again exception handling is a sore point in that it is the primary C runtime dependency of Modula-3. If you use Cygwin but say -mno-cygwin, that means you are targeting NT386. (and don't use pthreads or X Windows; behavior of exceptions/setjmp/longjmp TBD -- really, need to not use the -mno-cygwin headers in that case; I'll check). Perhaps m3core.dll should export m3_setjmp/m3_longjmp.. Either one can do a cross build to the other. Two cm3.exes, two sets of outputs, that either can produce. NT386 can use gcc or the integrated backend. And the gcc it uses can be MinGWin or Cygwin. (theoretically and probably soon reality) NT386GNU can use either as well! (also currently theory, but a real possibility) It isn't GNU tools, it is GNU runtime. One small area with cm3 might fall down just slightly is that of cross builds where host and target have different naming conventions. -lfoo vs. foo.lib, foo.o vs. foo.obj are an aspect of the host and I vaguely recall that cm3 ties naming convention to ostype. The appending of .exe is a target characteristics, but the others are not really. Naming convention is really a host thing and not a target thing. The config files are a mix of host and target information, mostly actually host, except for the one line that says TARGET. Most of the target variation is in cm3, which always can do any, and cm3cg (which might be nice to be similar, but that's another matter and not likely to ever change, except when AMD64 is the last architecture standing. :) ) If Windows had "rpath", then SL would be split between HOST_SL and TARGET_SL. As it stands, SL is HOST_SL. Consider as well the various versions of Visual C++. They output mostly the same, very interoperable. Consider optimization switches. Host or target? Consider version of gcc or Visual C++? Host or target? Well, inevitably, the host has an affect on the target. If not the for the host, the target would not even exist. Bugs in the host produce bugs in the target. etc. (And realize that Cygwin runs on top of an OS built with a Microsoft compiler, so really there is interop, but sometimes through a layer.) So there's a risk of saying there is six+ combinations. (host cygwin, host mingwin, host native) x (target nt386, target nt386gnu) But generally the host is assumed not a factor. I guess "LIBC" could be seperated into several options... You could actually have code that needs one runtime or another, and they could link together, depending on what they do.. This is something I don't know if cm3 handles, or anything I have seen. I should be able to build a static .lib, that includes some C code, that imbues its clients with build time dependencies. Well, I guess #pragma comment(linker) is this. So the next tasks are roughly: Merge my NT386 and NT386GNU files. Switching on a variable such as backend mode. Introduce a "new" (old) NT386GNU file, perhaps more like what was already there. Change NT386GNU back to Posix. Build NT386GNU. oh, one more point...while these are two targets from cm3's point of view, they are PROBABLY the same target to cm3cg and so only one is needed. I have to check if configure differentiates between i686-pc-cygwin and i686-pc-mingwin... but I guess it should... It might actually be profitable to have two bloated cm3cg.exe's. And they should ship to \cm3\pkg\m3cc\target\host or host\target and cm3 should know which to run. Blech..four of them when one would suffice? The detail being mainly what the paths to .libs look like, unfortunate. Possibly cm3 can bridge this gap using that "broken" feature that symlinks libs into the target directory, using NTFS hard links, if installroot and root are on the same volume... (or symlinks on Vista). Or maybe convert the paths as appropriate, hacky, but saves an extra cm3cg.exe which is good to avoid. (all the more reason to lump all targets into one file, so that the host x target matrix collapses to just one axis, host; and then you can write stuff in Perl/Python/Java/C# to collapse that to just one, except for the underlying runtime/interpreter...) Oh, cm3cg isn't the issue. It is always sitting in the correct directory and reads one file and writes one file, no slashes. The issue is gcc as the linker. Again, this is a host issue..and cm3 or the config file definitely should do the translation. - Jay From: jayk123 at hotmail.com To: m3devel at elegosoft.com Date: Mon, 21 Jan 2008 23:01:44 +0000 Subject: [M3devel] platform/build_dir is a big tuple? 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 wagner at elegosoft.com Tue Jan 22 23:48:06 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 22 Jan 2008 23:48:06 +0100 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <9C3615E5-FEDB-4AAB-BFC7-AFE867C94241@cs.purdue.edu> References: <20080122163601.6245410D4608@birch.elegosoft.com> <9C3615E5-FEDB-4AAB-BFC7-AFE867C94241@cs.purdue.edu> Message-ID: <20080122234806.me1n09816o08gc80@mail.elegosoft.com> Quoting Tony Hosking : > Do we really want to build all the Windows interfaces even on > non-Windows hosts? Yuck. I'd suggest to build that conditional, Jay. Olaf > On Jan 22, 2008, at 5:36 PM, Jay Krell wrote: > >> CVSROOT: /usr/cvs >> Changes by: jkrell at birch. 08/01/22 17:36:01 >> >> Modified files: >> cm3/m3-sys/cm3/src/: M3Backend.m3 m3makefile >> cm3/scripts/: backup-pkgs.sh boot-cm3-build-on-target.sh >> boot-cm3-core.sh boot-cm3-with-m3.sh >> copy-bootarchives.sh do-cm3-core.sh >> make-bin-dist-min.sh pack-crossbuild.sh pkginfo.sh >> Removed files: >> cm3/m3-sys/cm3/src/: M3BackPosix.m3 M3BackWin32.m3 >> >> Log message: >> put integrated backend into all hosts, so that cross builds work >> a bit more; built on PPC_DARWIN (ie: built on Posix, where it's >> an actual diff; what this will enable for me is a "semi-cros" >> from a NT386GNU cm3.exe to NT386/NT386MINGNU. And it's fairly cheap, >> the integrated backend is nothing compared to cm3cg. >> did not run all the .sh files, just upgrade.sh >> Note that m3staloneback is relatively unused, probably for >> debugging, left alone. >> mklib should come in as well for cross purposes but left that alone too. >> There are warnings in WinDef.m3 about <*WINAPI*> on function pointer >> types. Perhaps they can be deferred and only trigger if the types >> are used? If the types are called? ie: make the pragma understood, but >> don't support calling using calling conventions not supported by target -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Jan 23 00:04:35 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 23 Jan 2008 00:04:35 +0100 Subject: [M3devel] next problem (NT386GNU) In-Reply-To: <47960244.1E75.00D7.1@scires.com> References: <6E1E4409-F3D9-4982-B179-2D4C9648FDD0@cs.purdue.edu> <1A6EC7D6-32B2-44AD-933F-6976040A7D7F@cs.purdue.edu> <20080122081049.74tzfvozwo4wwwow@mail.elegosoft.com> <47960244.1E75.00D7.1@scires.com> Message-ID: <20080123000435.kjtci5bewwcss448@mail.elegosoft.com> Quoting Randy Coleburn : > Jay / Olaf: > > I installed CVSNT and TortoiseCVS. I am having some trouble with > "update" however. When I try to update the whole tree, it begins > working, but after a little while I start seeing messages that checksums > didn't match on certain files and that it will refetch. Then, after > just a little longer, it stops responding. I've left it running for > hours, but no new lines scroll by saying it is doing anything. Finally, > I just hit cancel and it promptly stops and informs me it aborted the > operation, as if it been waiting all along for me to tell it to give > up. > > Now, if I update individual files or selected files, it seems to work > no problem. And, I've been able to check out the whole repository, and > yes it does take some time to pull everything down. I can also do diffs > on selected files. I've also used it to commit a few files to the > repository. > > So, it is working fine, except for update. Either something is amiss, > or I'm not doing something just right. I am about to consider going > back to cygwin and running its version of cvs on my tree to see if it > will do the update, but I seem to recall reading somewhere that is not > good to mix between cvs and cvsnt on the same tree. This is strange. I've never seen that myself before. A complete update or checkout should take several minutes via encrypted TCP/IP, but not longer (depending on the line bandwidth and latency, of course). Just today I've heard of a customer who suffers from random connection problems with Subversion and Windows 2000 workstations; the theory there being that some TCP/IP parameters are set very strange and the whole protocol stack is not up to the task in its default configuration. This does not happen on XT or Vista, though, who seem to have incorporated significant improvements. (It's all rather strange to me, since I'm a Unix person myself and used to stable networking.) So depending on your OS you might want to tweak the TCP parameters a little bit to see if it improves. Hard-core debugging of this problem will need careful use of tcpdump and produce megabytes of logs; but perhaps just using the cvs trace option (cvs -t up ...) will give some indication if there's another problem than the underlying connection. There's also nothing against checking out a different workspace with the Cygwin cvs to see if that works better. We've made good experiences with CVSNT though. If the problem persists, we could also try to do some tcpdumping on the server side (Ronny Forberger would be the one to do it), but this will take some preparation time. @Ronny, perhaps you've got another idea? 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 ronny.forberger at elegosoft.com Wed Jan 23 00:53:02 2008 From: ronny.forberger at elegosoft.com (Ronny Forberger) Date: Wed, 23 Jan 2008 00:53:02 +0100 Subject: [M3devel] next problem (NT386GNU) In-Reply-To: <20080123000435.kjtci5bewwcss448@mail.elegosoft.com> References: <6E1E4409-F3D9-4982-B179-2D4C9648FDD0@cs.purdue.edu> <1A6EC7D6-32B2-44AD-933F-6976040A7D7F@cs.purdue.edu> <20080122081049.74tzfvozwo4wwwow@mail.elegosoft.com> <47960244.1E75.00D7.1@scires.com> <20080123000435.kjtci5bewwcss448@mail.elegosoft.com> Message-ID: <479681DE.8020104@elegosoft.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Olaf Wagner schrieb: > Quoting Randy Coleburn : > >> Jay / Olaf: >> >> I installed CVSNT and TortoiseCVS. I am having some trouble with >> "update" however. When I try to update the whole tree, it begins >> working, but after a little while I start seeing messages that >> checksums >> didn't match on certain files and that it will refetch. Then, after >> just a little longer, it stops responding. I've left it running for >> hours, but no new lines scroll by saying it is doing anything. >> Finally, >> I just hit cancel and it promptly stops and informs me it aborted the >> operation, as if it been waiting all along for me to tell it to give >> up. >> >> Now, if I update individual files or selected files, it seems to work >> no problem. And, I've been able to check out the whole repository, >> and >> yes it does take some time to pull everything down. I can also do >> diffs >> on selected files. I've also used it to commit a few files to the >> repository. >> >> So, it is working fine, except for update. Either something is amiss, >> or I'm not doing something just right. I am about to consider going >> back to cygwin and running its version of cvs on my tree to see if it >> will do the update, but I seem to recall reading somewhere that is not >> good to mix between cvs and cvsnt on the same tree. > > This is strange. I've never seen that myself before. A complete > update or checkout should take several minutes via encrypted > TCP/IP, but not longer (depending on the line bandwidth and latency, > of course). > > Just today I've heard of a customer who suffers from random connection > problems with Subversion and Windows 2000 workstations; the theory > there > being that some TCP/IP parameters are set very strange and the whole > protocol stack is not up to the task in its default configuration. > This does not happen on XT or Vista, though, who seem to have > incorporated > significant improvements. (It's all rather strange to me, since I'm a > Unix person myself and used to stable networking.) > > So depending on your OS you might want to tweak the TCP parameters a > little bit to see if it improves. Hard-core debugging of this problem > will need careful use of tcpdump and produce megabytes of logs; > but perhaps just using the cvs trace option (cvs -t up ...) will > give some indication if there's another problem than the underlying > connection. > > There's also nothing against checking out a different workspace > with the Cygwin cvs to see if that works better. We've made good > experiences with CVSNT though. > > If the problem persists, we could also try to do some tcpdumping on > the server side (Ronny Forberger would be the one to do it), but this > will take some preparation time. > > @Ronny, perhaps you've got another idea? Maybe try to enable debug mode on the cvs core programme (cvsnt). Not sure if dumping network traffic might help. You can also watch the cvs command running by logging on to modula3.elegosoft.com via ssh. You should really first check quality of your network connection to modula3.elegosoft.com and possibly try if update works with other implentations of cvs. Cheers, 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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHloHdXa9RCz+1wnMRAi7uAKCLvz8DqU/SeiHr/2FGum0BWOLHNACgl6R8 mk+bxc060/81T2l4IUwpEQU= =Xe1T -----END PGP SIGNATURE----- From jayk123 at hotmail.com Wed Jan 23 03:49:26 2008 From: jayk123 at hotmail.com (Jay) Date: Wed, 23 Jan 2008 02:49:26 +0000 Subject: [M3devel] enum for backend mode? In-Reply-To: <2AB0D273-C3B8-4D46-BCC1-4D032692DCB0@cs.purdue.edu> References: <20080122142922.k73w5es5j4gckso4@mail.elegosoft.com> <2AB0D273-C3B8-4D46-BCC1-4D032692DCB0@cs.purdue.edu> Message-ID: I'll be passing around backend mode a little more. Should we make it an enum? Good names are hard to come up with here. Here's my lame strawman: BackendMode = { IntegratedProducesObject, IntegratedProducedAssembly, QuakeProducesObject, QuakeProducesAssembly }; I have these changes almost done but am going to remove them pending discussion. I don't really like these names. They are long and still not all clear. Long would be ok if they were perfectly clear, imho. These names do correlate well with the nearby comments, which get roughly repeated for every use of the magic numbers. "quake" is usually called "m3back" or such, the name of the Quake function. I find both descriptions a bit short and therefore unclear. I don't think IntegratedProducingAssembly and QuakeProducingObject "really" exist. There is m3staloneback -- QuakeProducingObject or Assembly, and the code is available for IntegratedProducingAssembly, I guess esp. for debugging, but you can just as well link /dump /disasm -- but I don't think these are really in use. Therefore, perhaps merely Object and Assembly, though Integrated vs. not is a significant aspect not represented.. - 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 Wed Jan 23 04:33:24 2008 From: jayk123 at hotmail.com (Jay) Date: Wed, 23 Jan 2008 03:33:24 +0000 Subject: [M3devel] platform/build_dir is a big tuple? In-Reply-To: <2AB0D273-C3B8-4D46-BCC1-4D032692DCB0@cs.purdue.edu> References: <20080122142922.k73w5es5j4gckso4@mail.elegosoft.com> <2AB0D273-C3B8-4D46-BCC1-4D032692DCB0@cs.purdue.edu> Message-ID: Ok now? It's just types and the warnings should be gone. ps: I think all compilers should be cross-capable in one executable if that is easy. CM3 is, except for the missing integrated backend and mklib. Others like Java are. Not easy with gcc/cm3cg darn which makes some of CM3's functionality moot. And the missing linker... - Jay > From: hosking at cs.purdue.edu> > Precisely why I don't like many of the recent changes. I don't want > to build Windows interfaces and gorp for a non-Windows platform. > Jay, can you *please* back these changes 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 jayk123 at hotmail.com Wed Jan 23 04:45:44 2008 From: jayk123 at hotmail.com (Jay) Date: Wed, 23 Jan 2008 03:45:44 +0000 Subject: [M3devel] pixmap problem In-Reply-To: <20080120204831.81poj3gg0084o0g0@mail.elegosoft.com> References: Your message of "Sat, 19 Jan 2008 17:54:00 +0100." <235688.77597.qm@web27110.mail.ukl.yahoo.com> <200801200341.m0K3feKM023564@camembert.async.caltech.edu> <47935664.1E75.00D7.1@scires.com> <20080120204831.81poj3gg0084o0g0@mail.elegosoft.com> Message-ID: Please give me a few days on the NT386/GNU stuff first, thanks. - Jay > Date: Sun, 20 Jan 2008 20:48:31 +0100> From: wagner at elegosoft.com> To: m3devel at elegosoft.com> Subject: Re: [M3devel] pixmap problem> > Quoting Randy Coleburn :> > > Mika / Daniel: Thanks for the test info!> >> > Well, based on what ya'll are reporting, I think the problem has to do> > with the NT386 platform. I also don't think it has to do necessarily> > with the source code. So, there must be something fishy going on in the> > NT386 world in the linkage step to cause this type of situation when> > switching between regular and buildstandalone().> > I must have missed that, browsing the lots of mails on this list> recently ;-)> > > Unfortunately, I'm probably not the right person to figure out what is> > wrong and fix it either. Hey, but at least I produced a short test> > program that reproduces the problem.> > This is often the more difficult part.> > > Maybe Jay or someone can offer another suggestion on how to fix it.> > I think Jay is the well capable of finding out what's going wrong there.> Let's wait for him.> > Olaf> -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 hosking at cs.purdue.edu Wed Jan 23 05:51:48 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 22 Jan 2008 23:51:48 -0500 Subject: [M3devel] platform/build_dir is a big tuple? In-Reply-To: References: <20080122142922.k73w5es5j4gckso4@mail.elegosoft.com> <2AB0D273-C3B8-4D46-BCC1-4D032692DCB0@cs.purdue.edu> Message-ID: <4BF6B109-55C1-4B71-830D-3B61219CF66F@cs.purdue.edu> Hmm, perhaps I overreacted. :-) On Jan 22, 2008, at 10:33 PM, Jay wrote: > Ok now? It's just types and the warnings should be gone. > > ps: I think all compilers should be cross-capable in one executable > if that is easy. CM3 is, except > for the missing integrated backend and mklib. > Others like Java are. Not easy with gcc/cm3cg darn which makes some > of CM3's functionality moot. > And the missing linker... > > - Jay > > From: hosking at cs.purdue.edu > > > > Precisely why I don't like many of the recent changes. I don't want > > to build Windows interfaces and gorp for a non-Windows platform. > > Jay, can you *please* back these changes out? > > Need to know the score, the latest news, or you need your Hotmail?- > get your "fix". Check it out. From jayk123 at hotmail.com Wed Jan 23 06:26:06 2008 From: jayk123 at hotmail.com (Jay) Date: Wed, 23 Jan 2008 05:26:06 +0000 Subject: [M3devel] next problem (NT386GNU) In-Reply-To: <479681DE.8020104@elegosoft.com> References: <6E1E4409-F3D9-4982-B179-2D4C9648FDD0@cs.purdue.edu> <1A6EC7D6-32B2-44AD-933F-6976040A7D7F@cs.purdue.edu> <20080122081049.74tzfvozwo4wwwow@mail.elegosoft.com> <47960244.1E75.00D7.1@scires.com> <20080123000435.kjtci5bewwcss448@mail.elegosoft.com> <479681DE.8020104@elegosoft.com> Message-ID: Here's a little Windows hack?trick?technique from memory for dividing down long running commands that might help. in_each_dir.cmd for /f %%a in ('dir /b /ad') do cd %%a && %* cd %CVSROOT% in_each_dir cvs update -dAP If the problem is one that you merely want to parallelize with a possible loss in logging, because it is actually a reliable but slow and parallelizable operation, you can do like: in_each_dir start cvs update -dAP or in_each_dir start /min cvs update -dAP That doesn't seem the case here so just use it serially. I'm quite proud of this one line of cmd. :) (while at the time..cmd stinks...) Could it be newlines vs. carriagereturn-newlines? I find checkouts takes a while, but heck, I'm using wireless and often forget -z3. My CVS knowledge continues to be lame..something like cvs -z3 checkout cm3/scripts as a way to limit the initial checkout and then cd %CM3_ROOT% for %a in (m3-sys m3-libs m3-ui etc.) do cvs update -dAP %a to do it piecemeal. See, what I'd like is to get either all the toplevel directories but empty, or all the directories but no files, so I can use in_each_dir to enumerate. A more complete solution that logs each command to its own file and combines the exit codes is left as an exercise. :) I've never debugged networking stuff and hope never to. I recently installed the Windows network tracing free download thingy for the first time, I forget why, didn't use it much, and have since reinstalled the OS and don't plan on reinstalling the tracer. It did appear quite nice, flexible, great gui for forming filters and such, etc... TortoiseSVN has worked fine for me, on a small tree. I will try TortoiseCVS again some time. I think I didn't tell it about ssh. - Jay > Date: Wed, 23 Jan 2008 00:53:02 +0100> From: ronny.forberger at elegosoft.com> To: rcoleburn at scires.com> CC: m3devel at elegosoft.com; jayk123 at hotmail.com> Subject: Re: [M3devel] next problem (NT386GNU)> > -----BEGIN PGP SIGNED MESSAGE-----> Hash: SHA1> > Olaf Wagner schrieb:> > Quoting Randy Coleburn :> >> >> Jay / Olaf:> >>> >> I installed CVSNT and TortoiseCVS. I am having some trouble with> >> "update" however. When I try to update the whole tree, it begins> >> working, but after a little while I start seeing messages that> >> checksums> >> didn't match on certain files and that it will refetch. Then, after> >> just a little longer, it stops responding. I've left it running for> >> hours, but no new lines scroll by saying it is doing anything.> >> Finally,> >> I just hit cancel and it promptly stops and informs me it aborted the> >> operation, as if it been waiting all along for me to tell it to give> >> up.> >>> >> Now, if I update individual files or selected files, it seems to work> >> no problem. And, I've been able to check out the whole repository,> >> and> >> yes it does take some time to pull everything down. I can also do> >> diffs> >> on selected files. I've also used it to commit a few files to the> >> repository.> >>> >> So, it is working fine, except for update. Either something is amiss,> >> or I'm not doing something just right. I am about to consider going> >> back to cygwin and running its version of cvs on my tree to see if it> >> will do the update, but I seem to recall reading somewhere that is not> >> good to mix between cvs and cvsnt on the same tree.> >> > This is strange. I've never seen that myself before. A complete> > update or checkout should take several minutes via encrypted> > TCP/IP, but not longer (depending on the line bandwidth and latency,> > of course).> >> > Just today I've heard of a customer who suffers from random connection> > problems with Subversion and Windows 2000 workstations; the theory> > there> > being that some TCP/IP parameters are set very strange and the whole> > protocol stack is not up to the task in its default configuration.> > This does not happen on XT or Vista, though, who seem to have> > incorporated> > significant improvements. (It's all rather strange to me, since I'm a> > Unix person myself and used to stable networking.)> >> > So depending on your OS you might want to tweak the TCP parameters a> > little bit to see if it improves. Hard-core debugging of this problem> > will need careful use of tcpdump and produce megabytes of logs;> > but perhaps just using the cvs trace option (cvs -t up ...) will> > give some indication if there's another problem than the underlying> > connection.> >> > There's also nothing against checking out a different workspace> > with the Cygwin cvs to see if that works better. We've made good> > experiences with CVSNT though.> >> > If the problem persists, we could also try to do some tcpdumping on> > the server side (Ronny Forberger would be the one to do it), but this> > will take some preparation time.> >> > @Ronny, perhaps you've got another idea?> Maybe try to enable debug mode on the cvs core programme (cvsnt). Not> sure if dumping network traffic might help. You can also watch the cvs> command running by logging on to modula3.elegosoft.com via ssh.> > You should really first check quality of your network connection to> modula3.elegosoft.com and possibly try if update works with other> implentations of cvs.> > Cheers,> > 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> -----BEGIN PGP SIGNATURE-----> Version: GnuPG v1.4.6 (GNU/Linux)> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org> > iD8DBQFHloHdXa9RCz+1wnMRAi7uAKCLvz8DqU/SeiHr/2FGum0BWOLHNACgl6R8> mk+bxc060/81T2l4IUwpEQU=> =Xe1T> -----END PGP SIGNATURE-----> _________________________________________________________________ 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 Jan 23 06:58:55 2008 From: mika at async.caltech.edu (Mika Nystrom) Date: Tue, 22 Jan 2008 21:58:55 -0800 Subject: [M3devel] next problem (NT386GNU) In-Reply-To: Your message of "Wed, 23 Jan 2008 00:04:35 +0100." <20080123000435.kjtci5bewwcss448@mail.elegosoft.com> Message-ID: <200801230558.m0N5wtQ4034198@camembert.async.caltech.edu> I think Windows 2000 is well known for having some exceptionally nasty bugs in its TCP implementation. In fact my Modula-3 code has special workarounds for win2k: it doesn't download more than a few kilobytes at a time---if you try more, the network card sometimes goes catatonic. There are some notes on it here and there on the Internet. Not sure what the cause is. Mika Olaf Wagner writes: >Quoting Randy Coleburn : > >> Jay / Olaf: >> >> I installed CVSNT and TortoiseCVS. I am having some trouble with >> "update" however. When I try to update the whole tree, it begins >> working, but after a little while I start seeing messages that checksums >> didn't match on certain files and that it will refetch. Then, after >> just a little longer, it stops responding. I've left it running for >> hours, but no new lines scroll by saying it is doing anything. Finally, >> I just hit cancel and it promptly stops and informs me it aborted the >> operation, as if it been waiting all along for me to tell it to give >> up. >> >> Now, if I update individual files or selected files, it seems to work >> no problem. And, I've been able to check out the whole repository, and >> yes it does take some time to pull everything down. I can also do diffs >> on selected files. I've also used it to commit a few files to the >> repository. >> >> So, it is working fine, except for update. Either something is amiss, >> or I'm not doing something just right. I am about to consider going >> back to cygwin and running its version of cvs on my tree to see if it >> will do the update, but I seem to recall reading somewhere that is not >> good to mix between cvs and cvsnt on the same tree. > >This is strange. I've never seen that myself before. A complete >update or checkout should take several minutes via encrypted >TCP/IP, but not longer (depending on the line bandwidth and latency, >of course). > >Just today I've heard of a customer who suffers from random connection >problems with Subversion and Windows 2000 workstations; the theory there >being that some TCP/IP parameters are set very strange and the whole >protocol stack is not up to the task in its default configuration. >This does not happen on XT or Vista, though, who seem to have incorporated >significant improvements. (It's all rather strange to me, since I'm a >Unix person myself and used to stable networking.) > >So depending on your OS you might want to tweak the TCP parameters a >little bit to see if it improves. Hard-core debugging of this problem >will need careful use of tcpdump and produce megabytes of logs; >but perhaps just using the cvs trace option (cvs -t up ...) will >give some indication if there's another problem than the underlying >connection. > >There's also nothing against checking out a different workspace >with the Cygwin cvs to see if that works better. We've made good >experiences with CVSNT though. > >If the problem persists, we could also try to do some tcpdumping on >the server side (Ronny Forberger would be the one to do it), but this >will take some preparation time. > >@Ronny, perhaps you've got another idea? > >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 jayk123 at hotmail.com Wed Jan 23 07:28:01 2008 From: jayk123 at hotmail.com (Jay) Date: Wed, 23 Jan 2008 06:28:01 +0000 Subject: [M3devel] next problem (NT386GNU) In-Reply-To: <200801230558.m0N5wtQ4034198@camembert.async.caltech.edu> References: Your message of "Wed, 23 Jan 2008 00:04:35 +0100." <20080123000435.kjtci5bewwcss448@mail.elegosoft.com> <200801230558.m0N5wtQ4034198@camembert.async.caltech.edu> Message-ID: (I never used Windows 2000 much, but NT 4 worked solidly for a long time (didn't use CVS on it), hard to imagine Windows 2000 regressed much. XP and 2003 are solid, Vista I think is holding up in /this area/. There is the whole IPv4 vs. IPv6 transition still ongoing around the world. I really think Windows is better than its given credit for. Not Win9x, but NT. The Apple BS about being on a solid Unix foundation and all that..it's not like NT doesn't have same model, the same user/kernel isolation.....) Besides..if Cygwin CVS works fine (for me and I think for Randy), either a) it's not the network, or 2) Cygwin has workarounds and TortoiseCVS/CVSNT do not. I doubt #2, but almost anything is possible. Granted, I don't have TortoiseCVS/CVSNT working yet, didn't configure ssh for it. At some hypothetical point I install Win95/98/NT3.x/NT4/Win2000 in virtual machines and see how Modula-3 fairs.. I know the current binaries won't work on Win95/NT3.x due to Interlocked stuff, and some dependency on new processors, same thing (ie: you could inline or statically link such functions, and work on older OS but not on a 386). People should speak up if they expect pre-XP or 386/486/regular old Pentium support. And even then, the processors continue to progress at a surprising-to-me rate, MMX, SSE, SSE2, etc. (Not to mention AMD64..I have an unfortunate hardware situation at home there, might need to get another machine soon...or swap machines in a way I'd rather not..but this is getting ahead of things) - Jay > To: wagner at elegosoft.com> Date: Tue, 22 Jan 2008 21:58:55 -0800> From: mika at async.caltech.edu> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] next problem (NT386GNU)> > > I think Windows 2000 is well known for having some exceptionally> nasty bugs in its TCP implementation. In fact my Modula-3 code has> special workarounds for win2k: it doesn't download more than a few> kilobytes at a time---if you try more, the network card sometimes> goes catatonic. There are some notes on it here and there on the> Internet. Not sure what the cause is.> > Mika > > Olaf Wagner writes:> >Quoting Randy Coleburn :> >> >> Jay / Olaf:> >>> >> I installed CVSNT and TortoiseCVS. I am having some trouble with> >> "update" however. When I try to update the whole tree, it begins> >> working, but after a little while I start seeing messages that checksums> >> didn't match on certain files and that it will refetch. Then, after> >> just a little longer, it stops responding. I've left it running for> >> hours, but no new lines scroll by saying it is doing anything. Finally,> >> I just hit cancel and it promptly stops and informs me it aborted the> >> operation, as if it been waiting all along for me to tell it to give> >> up.> >>> >> Now, if I update individual files or selected files, it seems to work> >> no problem. And, I've been able to check out the whole repository, and> >> yes it does take some time to pull everything down. I can also do diffs> >> on selected files. I've also used it to commit a few files to the> >> repository.> >>> >> So, it is working fine, except for update. Either something is amiss,> >> or I'm not doing something just right. I am about to consider going> >> back to cygwin and running its version of cvs on my tree to see if it> >> will do the update, but I seem to recall reading somewhere that is not> >> good to mix between cvs and cvsnt on the same tree.> >> >This is strange. I've never seen that myself before. A complete> >update or checkout should take several minutes via encrypted> >TCP/IP, but not longer (depending on the line bandwidth and latency,> >of course).> >> >Just today I've heard of a customer who suffers from random connection> >problems with Subversion and Windows 2000 workstations; the theory there> >being that some TCP/IP parameters are set very strange and the whole> >protocol stack is not up to the task in its default configuration.> >This does not happen on XT or Vista, though, who seem to have incorporated> >significant improvements. (It's all rather strange to me, since I'm a> >Unix person myself and used to stable networking.)> >> >So depending on your OS you might want to tweak the TCP parameters a> >little bit to see if it improves. Hard-core debugging of this problem> >will need careful use of tcpdump and produce megabytes of logs;> >but perhaps just using the cvs trace option (cvs -t up ...) will> >give some indication if there's another problem than the underlying> >connection.> >> >There's also nothing against checking out a different workspace> >with the Cygwin cvs to see if that works better. We've made good> >experiences with CVSNT though.> >> >If the problem persists, we could also try to do some tcpdumping on> >the server side (Ronny Forberger would be the one to do it), but this> >will take some preparation time.> >> >@Ronny, perhaps you've got another idea?> >> >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 _________________________________________________________________ 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 Wed Jan 23 08:06:20 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Wed, 23 Jan 2008 08:06:20 +0100 (MET) Subject: [M3devel] platform/build_dir is a big tuple? In-Reply-To: <479605CF.1E75.00D7.1@scires.com> References: <479605CF.1E75.00D7.1@scires.com> Message-ID: On Tue, 22 Jan 2008, Randy Coleburn wrote: > Jay: > > For my part on Windows, I am happy to stay with the underlying OS, the > native windows threading, the integrated backend, and use the free > Microsoft Visual Studio tools. I don't really want to have to > install/use cygwin or any of the other variants. When I see target = > NT386, this list is what I am expecting. For the cm3 newbie coming from > a Microsoft Windows environment, I think this list would be the most > appealing and pose the least barrier to getting starting. Yes, I still > will work on the installer program once I'm satisfied that I have a good > working cm3 on Windows. One year ago I was in the situation to port one of my Modula-3 programs from Linux to Windows in order to hand it over to a Windows user. As I never use Windows, I have only a plain Windows installation on my machine with almost no tools other than cm3. I was glad to be able to run cm3 immediately and to find all libraries that I needed in binary form without Cygwin dependencies - otherwise not only I had to install that on my machine but I also would have to persuade the other Windows guy to install it as well. Summarized I strongly vote for NT386 being Windows with least dependencies on other packages. From jayk123 at hotmail.com Wed Jan 23 08:37:28 2008 From: jayk123 at hotmail.com (Jay) Date: Wed, 23 Jan 2008 07:37:28 +0000 Subject: [M3devel] platform/build_dir is a big tuple? In-Reply-To: References: <479605CF.1E75.00D7.1@scires.com> Message-ID: Let me cut to the chase, again: Everyone will probably be satisfied. For a very small "everyone". :) The underlying implementation shall be "heavily" parameterized. There shall be three visible pre packaged configurations. Power users, and clever and crazy people can experiment beyond those three. The EXACT three configurations is SLIGHTLY up in the air, but is likely to be: NT386 same as today, integrated backend, Win32 GUI, msvc*.dll, native win32 kernel threads, native backslashy paths (and perhaps increased compat with forward slashes, some of that is already in, m3core, but not yet cm3), Visual C++ compiler and linker. NT386MINGNU same as today's (recent) NT386GNU, but with Trestle-on-Win32 also working external backend, gcc compiler and linker, but otherwise same as NT386 One small wrinkle here is there is no m3gdb, but you can use the m3gdb from the next one, or Cygwin's gdb. NT386GNU As GNU as possible. pthreads (uncertain), X Windows (CygwinX), Cygwin C library, stupid looking paths that start /cygdrive, wierdo symlinks that don't interoperate well with the rest of the system (attempting to run cc.exe crashes ntvdm.exe, for example), "link" makes file system links (or at least strange files) instead of linking programs, a slow and perhaps fragile copy-immediately implementation of fork, problems running one type of program from another because you don't know which command line parameters and which environment variables represent paths or lists of paths and therefore how to translate them, etc. The underlying parameters, which are largely independent and which you can change individually, but which you will actually just ignore usually, shall be: modula-3 backend integrated 0 cm3cg 1 This might be replaced by the existing 0-3 variable. C compiler Visual C++ cl 0 gcc 1 In future this could be redefined as decimal digit or a character to accomodate other choices. linker Visual C++ link 0 gcc 1 In future this could be redefined as decimal digit or a character to accomodate other choices. Threading library Native Win32 kernel threads 0 Cygwin pthreads which are probably layered on native Win32 kernel threads 1 This is the one area where people have suggested using native Win32 functionality instead of Cygwin vtalaram user threads probably not available fiber user threads probably not available This would have been better than vtalaram, but not Win9x compatible If anyone wanted user vtlaram or fiber, this could be extended. It probably always should have been fibers instead of setjmp/longjmp where fibers are available... Window library Native Win32 gui 0 (hopefully with bugs to be worked out) X Windows via CygwinX 1 (hopefully the binaries are X server agnostic, and even work against a remote Unix machine?) C library native msvcr* through Visual C++ or MinGWin 0 Cygwin and its path oddities 1 The current notion of "OSTYPE" becomes much less useful here, as it previously embodied multiple factors. It wasn't all that useful anyway, imho, but as a way to reduce the matrix of targets down to two, the same two in multiple places. Now, in a few places, you check a more specific variable. Theoretically, I don't have to change cm3 here, just the config file and some m3makefiles. Because, tricky tricky, the main thing cm3 cares about is the backend "mode", and that does match up above with the 0/1. There are actually 4 modes and I should maybe hoist that up to be the variable, very maybe. A few m3makefiles will have to change, in small ways. Therefore, NT386 is all 0s, NT386GNU shall be all 1s, except maybe threading, and NT386MINGNU shall be a mix -- backend, C compiler, linker 1, the rest 0. Besides that, what I haven't in my head yet, is that individual m3makefiles should be able to ask for one compiler or the other. The base system won't do that, but user systems could, if they have some code that depends on one compiler or the other and they are going to link it together. For this purpose, for exposing these features to users, possibly values other than "0" and "1" are needed. If the configuration is one of these three combinations, build_dir is translated as shown. Otherwise, it is "NT386-" plus the unreadable string of 0s and 1s. This is essentially already commited. NT386 works this way. NT386MINGNU works this, but is for now called NT386GNU, and doesn't have any Trestle yet. The new/old Cygwin NT386GNU isn't active yet, but easily should be. There are three config files, NT386, NT386MINGNU, NT386GNU, they are all just a few lines and then include NT386.common. Oh, one more thing I haven't worked out is how the user asks for one target or another. It is probably via the environment variable CM3_TARGET, though in reality, "TARGET" for all of these shall be NT386. Any questions? Don't ask me when Cygwin NT386GNU will be active or when the names will flip. I will try it soon. This is essentiallyalready in the tree, with a little bit of "temporary, for compat" sprinkled in to avoid renaming NT386GNU/MINGNU just yet, and the Cygwinish stuff not active, no X Windows on NT386 yet..groundwork is laid, I think I've stopped thinking through the indecisiveness, I just keep hearing the two extreme sides, the Windows users who want Windows (do you even care about the gcc backend? It's slow. It generates inefficient code. It supports Longint) and a few Unix users who might reluctantly use Windows a little more if their backend slowed down and their libraries changed... Personally my main goal here is to not feel guilty about not finishing the LONGINT support yet in the integrated backend. I'd still like to finish that, but it was taking embarassingly long. I'd also like an uber-cross build environment, where I can build anything from anything. Getting cm3cg working was part of that. I'm not sure I have the patience to build gcc and ld/binutils that many times though. - Jay > Date: Wed, 23 Jan 2008 08:06:20 +0100> From: lemming at henning-thielemann.de> Subject: Re: [M3devel] platform/build_dir is a big tuple?> To: rcoleburn at scires.com> CC: m3devel at elegosoft.com; jayk123 at hotmail.com> > > On Tue, 22 Jan 2008, Randy Coleburn wrote:> > > Jay:> >> > For my part on Windows, I am happy to stay with the underlying OS, the> > native windows threading, the integrated backend, and use the free> > Microsoft Visual Studio tools. I don't really want to have to> > install/use cygwin or any of the other variants. When I see target => > NT386, this list is what I am expecting. For the cm3 newbie coming from> > a Microsoft Windows environment, I think this list would be the most> > appealing and pose the least barrier to getting starting. Yes, I still> > will work on the installer program once I'm satisfied that I have a good> > working cm3 on Windows.> > One year ago I was in the situation to port one of my Modula-3 programs> from Linux to Windows in order to hand it over to a Windows user. As I> never use Windows, I have only a plain Windows installation on my machine> with almost no tools other than cm3. I was glad to be able to run cm3> immediately and to find all libraries that I needed in binary form without> Cygwin dependencies - otherwise not only I had to install that on my> machine but I also would have to persuade the other Windows guy to install> it as well. Summarized I strongly vote for NT386 being Windows with least> dependencies on other packages. _________________________________________________________________ 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 Jan 23 08:22:54 2008 From: mika at async.caltech.edu (Mika Nystrom) Date: Tue, 22 Jan 2008 23:22:54 -0800 Subject: [M3devel] platform/build_dir is a big tuple? In-Reply-To: Your message of "Wed, 23 Jan 2008 08:06:20 +0100." Message-ID: <200801230722.m0N7Msbc036278@camembert.async.caltech.edu> Henning Thielemann writes: > >On Tue, 22 Jan 2008, Randy Coleburn wrote: > >> Jay: >> >> For my part on Windows, I am happy to stay with the underlying OS, the >> native windows threading, the integrated backend, and use the free >> Microsoft Visual Studio tools. I don't really want to have to >> install/use cygwin or any of the other variants. When I see target = >> NT386, this list is what I am expecting. For the cm3 newbie coming from >> a Microsoft Windows environment, I think this list would be the most >> appealing and pose the least barrier to getting starting. Yes, I still >> will work on the installer program once I'm satisfied that I have a good >> working cm3 on Windows. > >One year ago I was in the situation to port one of my Modula-3 programs >from Linux to Windows in order to hand it over to a Windows user. As I >never use Windows, I have only a plain Windows installation on my machine >with almost no tools other than cm3. I was glad to be able to run cm3 >immediately and to find all libraries that I needed in binary form without >Cygwin dependencies - otherwise not only I had to install that on my >machine but I also would have to persuade the other Windows guy to install >it as well. Summarized I strongly vote for NT386 being Windows with least >dependencies on other packages. My experience was almost the opposite. I had a complicated system running on Unix, using Modula-3 for most of its implementation but all sorts of other dirty glue to run properly, and various calls to libc routines. A couple of Windows people told me "please run this stuff on our machine [we don't care how you do it]". I promptly installed Cygwin and got the whole thing running with a fairly small amount of fuss. Accordingly, I vote for NT386GNU being a Cygwin thing that looks as much like Unix as possible! I can certainly see the other point of view, but is there a great need for something between these two extremes? If I were the one putting together Modula-3 compilers for Windows, I'd do those two (not sure which one first) and not worry about all the other permutations of threading libraries, compilers, etc. Mika From jayk123 at hotmail.com Wed Jan 23 08:49:28 2008 From: jayk123 at hotmail.com (Jay) Date: Wed, 23 Jan 2008 07:49:28 +0000 Subject: [M3devel] platform/build_dir is a big tuple? In-Reply-To: References: <479605CF.1E75.00D7.1@scires.com> Message-ID: > If anyone wanted user vtlaram or fiber, this could be extended. > It probably always should have been fibers instead of setjmp/longjmp where fibers are available... Oh, sorry, Modula-3 has never to my knowledge used user/vtalarm threads. If anyone does want to take over their own scheduling and have an N:M model, fibers are perhaps the way to go, unless you need Win9x. Fibers take care of creating a stack and swapping register context, whereas setjmp/longjmp only swap register context and I suspect Modula-3 uses them in a non-conformant but generally-compatible way. I haven't looked into this yet. For exceptions, ok. For thread switching, probably not. But I'd have to look at how it's implemented.. user mode threads, fibers..are problematic. For example Win32 critical sections can be taken recursively, on the same thread. Fibers can move around between threads and therefore cannot take them recursively. All in all, as said below, I'm inclined to omit support for user mode threads on Windows. I ASSUME the Cygwin pthreads are a thin wrapper over Windows, except...except there is the condition variables...not sure they can be layered over thinly... As I said, this is one bit I am uncertan of. Maybe just always use native Win32 threads. It would be a perhaps interesting curiosity to see if cygwin binaries tend to only depend on cygwin .dlls and not win32 .dlls, as a "proof" of the "completeness" of the layer/wrapping. (though as to the quality, see below.) Of course, cygwin code can still use win32..your m3makefile might actually check target==nt386 to know "the truth". But I doubt anyone would use this flexibility. - Jay From: jayk123 at hotmail.comTo: lemming at henning-thielemann.de; rcoleburn at scires.comCC: m3devel at elegosoft.comSubject: RE: [M3devel] platform/build_dir is a big tuple?Date: Wed, 23 Jan 2008 07:37:28 +0000 Let me cut to the chase, again: Everyone will probably be satisfied. For a very small "everyone". :) The underlying implementation shall be "heavily" parameterized.There shall be three visible pre packaged configurations.Power users, and clever and crazy people can experiment beyond those three.The EXACT three configurations is SLIGHTLY up in the air, but is likely to be: NT386 same as today, integrated backend, Win32 GUI, msvc*.dll, native win32 kernel threads, native backslashy paths (and perhaps increased compat with forward slashes, some of that is already in, m3core, but not yet cm3), Visual C++ compiler and linker. NT386MINGNU same as today's (recent) NT386GNU, but with Trestle-on-Win32 also working external backend, gcc compiler and linker, but otherwise same as NT386 One small wrinkle here is there is no m3gdb, but you can use the m3gdb from the next one, or Cygwin's gdb. NT386GNU As GNU as possible. pthreads (uncertain), X Windows (CygwinX), Cygwin C library, stupid looking paths that start /cygdrive, wierdo symlinks that don't interoperate well with the rest of the system (attempting to run cc.exe crashes ntvdm.exe, for example), "link" makes file system links (or at least strange files) instead of linking programs, a slow and perhaps fragile copy-immediately implementation of fork, problems running one type of program from another because you don't know which command line parameters and which environment variables represent paths or lists of paths and therefore how to translate them, etc. The underlying parameters, which are largely independent and which you can change individually, but which you will actually just ignore usually, shall be: modula-3 backend integrated 0 cm3cg 1 This might be replaced by the existing 0-3 variable. C compiler Visual C++ cl 0 gcc 1 In future this could be redefined as decimal digit or a character to accomodate other choices. linker Visual C++ link 0 gcc 1 In future this could be redefined as decimal digit or a character to accomodate other choices. Threading library Native Win32 kernel threads 0 Cygwin pthreads which are probably layered on native Win32 kernel threads 1 This is the one area where people have suggested using native Win32 functionality instead of Cygwin vtalaram user threads probably not available fiber user threads probably not available This would have been better than vtalaram, but not Win9x compatible If anyone wanted user vtlaram or fiber, this could be extended. It probably always should have been fibers instead of setjmp/longjmp where fibers are available... Window library Native Win32 gui 0 (hopefully with bugs to be worked out) X Windows via CygwinX 1 (hopefully the binaries are X server agnostic, and even work against a remote Unix machine?) C library native msvcr* through Visual C++ or MinGWin 0 Cygwin and its path oddities 1 The current notion of "OSTYPE" becomes much less useful here, as it previously embodied multiple factors. It wasn't all that useful anyway, imho, but as a way to reduce the matrix of targets down to two, the same two in multiple places. Now, in a few places, you check a more specific variable. Theoretically, I don't have to change cm3 here, just the config file and some m3makefiles. Because, tricky tricky, the main thing cm3 cares about is the backend "mode", and that does match up above with the 0/1. There are actually 4 modes and I should maybe hoist that up to be the variable, very maybe. A few m3makefiles will have to change, in small ways. Therefore, NT386 is all 0s, NT386GNU shall be all 1s, except maybe threading, and NT386MINGNU shall be a mix -- backend, C compiler, linker 1, the rest 0. Besides that, what I haven't in my head yet, is that individual m3makefiles should be able to ask for one compiler or the other. The base system won't do that, but user systems could, if they have some code that depends on one compiler or the other and they are going to link it together. For this purpose, for exposing these features to users, possibly values other than "0" and "1" are needed. If the configuration is one of these three combinations, build_dir is translated as shown.Otherwise, it is "NT386-" plus the unreadable string of 0s and 1s. This is essentially already commited. NT386 works this way. NT386MINGNU works this, but is for now called NT386GNU, and doesn't have any Trestle yet. The new/old Cygwin NT386GNU isn't active yet, but easily should be. There are three config files, NT386, NT386MINGNU, NT386GNU, they are all just a few lines and then include NT386.common. Oh, one more thing I haven't worked out is how the user asks for one target or another.It is probably via the environment variable CM3_TARGET, though in reality, "TARGET" for all of these shall be NT386. Any questions?Don't ask me when Cygwin NT386GNU will be active or when the names will flip. I will try it soon. This is essentiallyalready in the tree, with a little bit of "temporary, for compat" sprinkled in to avoid renaming NT386GNU/MINGNU just yet, and the Cygwinish stuff not active, no X Windows on NT386 yet..groundwork is laid, I think I've stopped thinking through the indecisiveness, I just keep hearing the two extreme sides, the Windows users who want Windows (do you even care about the gcc backend? It's slow. It generates inefficient code. It supports Longint) and a few Unix users who might reluctantly use Windows a little more if their backend slowed down and their libraries changed... Personally my main goal here is to not feel guilty about not finishing the LONGINT support yet in the integrated backend.I'd still like to finish that, but it was taking embarassingly long. I'd also like an uber-cross build environment, where I can build anything from anything. Getting cm3cg working was part of that. I'm not sure I have the patience to build gcc and ld/binutils that many times though. - Jay > Date: Wed, 23 Jan 2008 08:06:20 +0100> From: lemming at henning-thielemann.de> Subject: Re: [M3devel] platform/build_dir is a big tuple?> To: rcoleburn at scires.com> CC: m3devel at elegosoft.com; jayk123 at hotmail.com> > > On Tue, 22 Jan 2008, Randy Coleburn wrote:> > > Jay:> >> > For my part on Windows, I am happy to stay with the underlying OS, the> > native windows threading, the integrated backend, and use the free> > Microsoft Visual Studio tools. I don't really want to have to> > install/use cygwin or any of the other variants. When I see target => > NT386, this list is what I am expecting. For the cm3 newbie coming from> > a Microsoft Windows environment, I think this list would be the most> > appealing and pose the least barrier to getting starting. Yes, I still> > will work on the installer program once I'm satisfied that I have a good> > working cm3 on Windows.> > One year ago I was in the situation to port one of my Modula-3 programs> from Linux to Windows in order to hand it over to a Windows user. As I> never use Windows, I have only a plain Windows installation on my machine> with almost no tools other than cm3. I was glad to be able to run cm3> immediately and to find all libraries that I needed in binary form without> Cygwin dependencies - otherwise not only I had to install that on my> machine but I also would have to persuade the other Windows guy to install> it as well. Summarized I strongly vote for NT386 being Windows with least> dependencies on other packages. 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 mika at async.caltech.edu Wed Jan 23 08:50:49 2008 From: mika at async.caltech.edu (Mika Nystrom) Date: Tue, 22 Jan 2008 23:50:49 -0800 Subject: [M3devel] platform/build_dir is a big tuple? In-Reply-To: Your message of "Wed, 23 Jan 2008 07:37:28 GMT." Message-ID: <200801230750.m0N7onlw036945@camembert.async.caltech.edu> This sounds wonderful!! Mika P.S. Personally I don't care about pthreads, user threads, or any other kind of threads. I think Modula-3 threads are beautiful (one of the real strengths of the language, in fact), and good as never see a need to delve any lower than that. Win32 threads work fine on the old NT386GNU. There were no pthreads back then, and probably Win32 threads are better than user threads anyhow... (in the sense of requiring fewest "anti-blocking" hacks). Of course there might be someone out there who doesn't agree, and needs Modula-3 threads to be built on pthreads for some reason... Jay writes: >--_6a1e3166-9b30-4149-b10d-8b7fe22a1ec0_ >Content-Type: text/plain; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > >Let me cut to the chase, again: >=20 > Everyone will probably be satisfied.=20 > For a very small "everyone". :)=20 >=20 >The underlying implementation shall be "heavily" parameterized. >There shall be three visible pre packaged configurations. >Power users, and clever and crazy people can experiment beyond those three. >The EXACT three configurations is SLIGHTLY up in the air, but is likely to = >be: >=20 >NT386 > same as today, integrated backend, Win32 GUI, msvc*.dll, native win32 ker= >nel threads, native backslashy paths (and perhaps increased compat with for= >ward slashes, some of that is already in, m3core, but not yet cm3), Visual = >C++ compiler and linker. >=20 >NT386MINGNU > same as today's (recent) NT386GNU, but with Trestle-on-Win32 also working= >=20 > external backend, gcc compiler and linker, but otherwise same as NT386 > One small wrinkle here is there is no m3gdb, but you can use the m3gdb fr= >om the next one, or Cygwin's gdb. >=20 >NT386GNU > As GNU as possible. pthreads (uncertain), X Windows (CygwinX), Cygwin C l= >ibrary, stupid looking paths that start /cygdrive, wierdo symlinks that don= >'t interoperate well with the rest of the system (attempting to run cc.exe = >crashes ntvdm.exe, for example), "link" makes file system links (or at leas= >t strange files) instead of linking programs, a slow and perhaps fragile co= >py-immediately implementation of fork, problems running one type of program= > from another because you don't know which command line parameters and whic= >h environment variables represent paths or lists of paths and therefore how= > to translate them, etc.=20 >The underlying parameters, which are largely independent and which you can = >change individually, but which you will actually just ignore usually, shall= > be: >=20 > modula-3 backend > integrated 0 > cm3cg 1 > This might be replaced by the existing 0-3 variable. >=20 > C compiler =20 > Visual C++ cl 0 > gcc 1 > In future this could be redefined as decimal digit or a character to ac= >comodate other choices. >=20 > linker > Visual C++ link 0 > gcc 1 > In future this could be redefined as decimal digit or a character to ac= >comodate other choices. >=20 > Threading library > Native Win32 kernel threads 0 > Cygwin pthreads which are probably layered on native Win32 kernel thre= >ads 1 > This is the one area where people have suggested using native Win32 fu= >nctionality instead of Cygwin > vtalaram user threads probably not available > fiber user threads probably not available > This would have been better than vtalaram, but not Win9x compatib= >le > If anyone wanted user vtlaram or fiber, this could be extended. It pro= >bably always should have been fibers instead of setjmp/longjmp where fibers= > are available... >=20 > Window library > Native Win32 gui 0 (hopefully with bugs to be worked out)=20 > X Windows via CygwinX 1 (hopefully the binaries are X server agnostic= >, and even work against a remote Unix machine?) >=20 > C library > native msvcr* through Visual C++ or MinGWin 0 > Cygwin and its path oddities 1=20 >=20 >The current notion of "OSTYPE" becomes much less useful here, as it previou= >sly embodied multiple factors. > It wasn't all that useful anyway, imho, but as a way to reduce the matrix = >of targets down to two, the same two in multiple places. Now, in a few plac= >es, you check a more specific variable. Theoretically, I don't have to chan= >ge cm3 here, just the config file and some m3makefiles. Because, tricky tri= >cky, the main thing cm3 cares about is the backend "mode", and that does ma= >tch up above with the 0/1. There are actually 4 modes and I should maybe ho= >ist that up to be the variable, very maybe. A few m3makefiles will have to = >change, in small ways. >=20 > Therefore, NT386 is all 0s, NT386GNU shall be all 1s, except maybe thread= >ing, and NT386MINGNU shall be a mix -- backend, C compiler, linker 1, the r= >est 0. Besides that, what I haven't in my head yet, is that individual m3ma= >kefiles should be able to ask for one compiler or the other. The base syste= >m won't do that, but user systems could, if they have some code that depend= >s on one compiler or the other and they are going to link it together. For = >this purpose, for exposing these features to users, possibly values other t= >han "0" and "1" are needed. >=20 >If the configuration is one of these three combinations, build_dir is trans= >lated as shown. >Otherwise, it is "NT386-" plus the unreadable string of 0s and 1s. >=20 >This is essentially already commited. NT386 works this way. NT386MINGNU wor= >ks this, but is for now called NT386GNU, and doesn't have any Trestle yet. = >The new/old Cygwin NT386GNU isn't active yet, but easily should be. >=20 >There are three config files, NT386, NT386MINGNU, NT386GNU, they are all ju= >st a few lines and then include NT386.common. >=20 >Oh, one more thing I haven't worked out is how the user asks for one target= > or another. >It is probably via the environment variable CM3_TARGET, though in reality, = >"TARGET" for all of these shall be NT386. >=20 >Any questions? >Don't ask me when Cygwin NT386GNU will be active or when the names will fli= >p. I will try it soon. >=20 >This is essentiallyalready in the tree, with a little bit of "temporary, fo= >r compat" sprinkled in to avoid renaming NT386GNU/MINGNU just yet, and the = >Cygwinish stuff not active, no X Windows on NT386 yet..groundwork is laid, = >I think I've stopped thinking through the indecisiveness, I just keep heari= >ng the two extreme sides, the Windows users who want Windows (do you even c= >are about the gcc backend? It's slow. It generates inefficient code. It sup= >ports Longint) and a few Unix users who might reluctantly use Windows a lit= >tle more if their backend slowed down and their libraries changed... >=20 >Personally my main goal here is to not feel guilty about not finishing the = >LONGINT support yet in the integrated backend. >I'd still like to finish that, but it was taking embarassingly long. >=20 >I'd also like an uber-cross build environment, where I can build anything f= >rom anything. Getting cm3cg working was part of that. I'm not sure I have t= >he patience to build gcc and ld/binutils that many times though. >=20 > - Jay > > > >> Date: Wed, 23 Jan 2008 08:06:20 +0100> From: lemming at henning-thielemann.d= >e> Subject: Re: [M3devel] platform/build_dir is a big tuple?> To: rcoleburn= >@scires.com> CC: m3devel at elegosoft.com; jayk123 at hotmail.com> > > On Tue, 22= > Jan 2008, Randy Coleburn wrote:> > > Jay:> >> > For my part on Windows, I = >am happy to stay with the underlying OS, the> > native windows threading, t= >he integrated backend, and use the free> > Microsoft Visual Studio tools. I= > don't really want to have to> > install/use cygwin or any of the other var= >iants. When I see target =3D> > NT386, this list is what I am expecting. Fo= >r the cm3 newbie coming from> > a Microsoft Windows environment, I think th= >is list would be the most> > appealing and pose the least barrier to gettin= >g starting. Yes, I still> > will work on the installer program once I'm sat= >isfied that I have a good> > working cm3 on Windows.> > One year ago I was = >in the situation to port one of my Modula-3 programs> from Linux to Windows= > in order to hand it over to a Windows user. As I> never use Windows, I hav= >e only a plain Windows installation on my machine> with almost no tools oth= >er than cm3. I was glad to be able to run cm3> immediately and to find all = >libraries that I needed in binary form without> Cygwin dependencies - other= >wise not only I had to install that on my> machine but I also would have to= > persuade the other Windows guy to install> it as well. Summarized I strong= >ly vote for NT386 being Windows with least> dependencies on other packages. >_________________________________________________________________ >Connect and share in new ways with Windows Live. >http://www.windowslive.com/share.html?ocid=3DTXT_TAGHM_Wave2_sharelife_0120= >08= > >--_6a1e3166-9b30-4149-b10d-8b7fe22a1ec0_ >Content-Type: text/html; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > > > > >Let me cut to the chase, again:
> 
> Everyone will probably be satisfied.
> For a very small "everyone". :)
> 
>The underlying implementation shall be "heavily" parameterized.
>There shall be three visible pre packaged configurations.
>Power users, and clever and crazy people can experiment beyond those three.= >
>The EXACT three configurations is SLIGHTLY up in the air, but is likely to = >be:
> 
>NT386
>  same as today, integrated backend, Win32 GUI, msvc*.dll, native win3= >2 kernel threads, native backslashy paths (and perhaps increased compat wit= >h forward slashes, some of that is already in, m3core, but not yet cm3), Vi= >sual C++ compiler and linker.
> 
>NT386MINGNU
>  same as today's (recent) NT386GNU, but with Trestle-on-Win32 al= >so working
>   external backend, gcc compiler and linker, but otherwise same = >as NT386
>  One small wrinkle here is there is no m3gdb, but you can use the m3g= >db from the next one, or Cygwin's gdb.
> 
>NT386GNU
>  As GNU as possible. pthreads (uncertain), X Windows (CygwinX), Cygwi= >n C library, stupid looking paths that start /cygdrive, wierdo symlinks tha= >t don't interoperate well with the rest of the system (attempting to run cc= >.exe crashes ntvdm.exe, for example), "link" makes file system links (or at= > least strange files) instead of linking programs, a slow and perhaps = >fragile copy-immediately implementation of fork, problems running one type = >of program from another because you don't know which command line parameter= >s and which environment variables represent paths or lists of paths and the= >refore how to translate them, etc.

>The underlying parameters, which are largely independent and which you can = >change individually, but which you will actually just ignore usually, = >shall be:
> 
>  modula-3 backend
>     integrated 0
>     cm3cg 1
>   This might be replaced by the existing 0-3 variable.
> 
>  C compiler 
>    Visual C++ cl 0
>    gcc 1
>    In future this could be redefined as decimal digit or a = >character to accomodate other choices.
> 
>  linker
>     Visual C++ link 0
>     gcc 1
>    In future this could be redefined as decimal digit or a = >character to accomodate other choices.
> 
>   Threading library
>     Native Win32 kernel threads 0
>     Cygwin pthreads which are probably layered on nati= >ve Win32 kernel threads 1
>     This is the one area where people have suggested u= >sing native Win32 functionality instead of Cygwin
>     vtalaram user threads probably not available
>     fiber user threads probably not available
>          This would have been= > better than vtalaram, but not Win9x compatible
>     If anyone wanted user vtlaram or fiber, this could= > be extended. It probably always should have been fibers instead of setjmp/= >longjmp where fibers are available...
> 
>   Window library
>      Native Win32 gui 0 (hopefully with bugs to b= >e worked out)
>      X Windows via CygwinX 1 (hopefully the binar= >ies are X server agnostic, and even work against a remote Unix machine?)> > 
>    C library
>      native msvcr* through Visual C++ or MinGWin = >0
>      Cygwin and its path oddities 1
> 
>The current notion of "OSTYPE" becomes much less useful here, as it previou= >sly embodied multiple factors.
> It wasn't all that useful anyway, imho, but as a way to reduce the ma= >trix of targets down to two, the same two in multiple places. Now, in a few= > places, you check a more specific variable. Theoretically, I don't have to= > change cm3 here, just the config file and some m3makefiles. Because, trick= >y tricky, the main thing cm3 cares about is the backend "mode", and that do= >es match up above with the 0/1. There are actually 4 modes and I should may= >be hoist that up to be the variable, very maybe. A few m3makefiles will hav= >e to change, in small ways.
> 
>  Therefore, NT386 is all 0s, NT386GNU shall be all 1s, exce= >pt maybe threading, and NT386MINGNU shall be a mix -- backend, C = >compiler, linker 1, the rest 0. Besides that, what I haven't in my head yet= >, is that individual m3makefiles should be able to ask for one compiler or = >the other. The base system won't do that, but user systems could, if they h= >ave some code that depends on one compiler or the other and they are going = >to link it together. For this purpose, for exposing these features to users= >, possibly values other than "0" and "1" are needed.
> 
>If the configuration is one of these three combinations, build_dir is trans= >lated as shown.
>Otherwise, it is "NT386-" plus the unreadable string of 0s and 1s.
> 
>This is essentially already commited. NT386 works this way. NT386MINGNU wor= >ks this, but is for now called NT386GNU, and doesn't have any Trestle yet. = >The new/old Cygwin NT386GNU isn't active yet, but easily should be.
> 
>There are three config files, NT386, NT386MINGNU, NT386GNU, they are all ju= >st a few lines and then include NT386.common.
> 
>Oh, one more thing I haven't worked out is how the user asks for one target= > or another.
>It is probably via the environment variable CM3_TARGET, though in reality, = >"TARGET" for all of these shall be NT386.
> 
>Any questions?
>Don't ask me when Cygwin NT386GNU will be active or when the names will fli= >p. I will try it soon.
> 
>This is essentiallyalready in the tree, with a little bit of "temp= >orary, for compat" sprinkled in to avoid renaming NT386GNU/MINGNU just yet,= > and the Cygwinish stuff not active, no X Windows on NT386 yet..groundwork = >is laid, I think I've stopped thinking through the indecisiveness, I just k= >eep hearing the two extreme sides, the Windows users who want Windows (do y= >ou even care about the gcc backend? It's slow. It generates inefficient cod= >e. It supports Longint) and a few Unix users who might reluctantly use Wind= >ows a little more if their backend slowed down and their libraries changed.= >..
> 
>Personally my main goal here is to not feel guilty about not finishing the = >LONGINT support yet in the integrated backend.
>I'd still like to finish that, but it was taking embarassingly long.
> 
>I'd also like an uber-cross build environment, where I can build anything f= >rom anything. Getting cm3cg working was part of that. I'm not sure I have t= >he patience to build gcc and ld/binutils that many times though.
> 
>   - Jay


> >
>
>> Date: Wed, 23 Jan 2008 08:06:20 +0100
> From: lemming at henning-th= >ielemann.de
> Subject: Re: [M3devel] platform/build_dir is a big tupl= >e?
> To: rcoleburn at scires.com
> CC: m3devel at elegosoft.com; jayk= >123 at hotmail.com
>
>
> On Tue, 22 Jan 2008, Randy Colebu= >rn wrote:
>
> > Jay:
> >
> > For my part = >on Windows, I am happy to stay with the underlying OS, the
> > nat= >ive windows threading, the integrated backend, and use the free
> >= >; Microsoft Visual Studio tools. I don't really want to have to
> >= >; install/use cygwin or any of the other variants. When I see target =3D>> > NT386, this list is what I am expecting. For the cm3 newbie comi= >ng from
> > a Microsoft Windows environment, I think this list wou= >ld be the most
> > appealing and pose the least barrier to getting= > starting. Yes, I still
> > will work on the installer program onc= >e I'm satisfied that I have a good
> > working cm3 on Windows.
= >>
> One year ago I was in the situation to port one of my Modula-= >3 programs
> from Linux to Windows in order to hand it over to a Wind= >ows user. As I
> never use Windows, I have only a plain Windows insta= llation on my machine
> with almost no tools other than cm3. I was gl= >ad to be able to run cm3
> immediately and to find all libraries that= > I needed in binary form without
> Cygwin dependencies - otherwise no= >t only I had to install that on my
> machine but I also would have to= > persuade the other Windows guy to install
> it as well. Summarized I= > strongly vote for NT386 being Windows with least
> dependencies on o= >ther packages.


Connect and share in new ways with Window= >s Live. ave2_sharelife_012008' target=3D'_new'>Get it now! >= > >--_6a1e3166-9b30-4149-b10d-8b7fe22a1ec0_-- From jayk123 at hotmail.com Wed Jan 23 09:11:21 2008 From: jayk123 at hotmail.com (Jay) Date: Wed, 23 Jan 2008 08:11:21 +0000 Subject: [M3devel] ABIs and combinatorial configuration explosion in another project Message-ID: Our main concern here is jmpbuf size. And possibly exception interop. C++ throw should run Modula-3 finally en route to the C++ catch, and vice versa. Bonus points if each language can catch each other's exceptions, by type. Oh and interop with other Modula-3 compilers. :) Btw, you can see how profiling munges build_dir, same thing. http://www.boost.org/more/separate_compilation.html#static_or_dynamic Preventing Compiler ABI Clashes There are some compilers (mostly Microsoft Windows compilers again!), which feature a range of compiler switches that alter the ABI of C++ classes and functions. By way of example, consider Borland's compiler which has the following options:-b (on or off - effects enum sizes). -Vx (on or off - empty members). -Ve (on or off - empty base classes). -aX (alignment - 5 options). -pX (Calling convention - 4 options). -VmX (member pointer size and layout - 5 options). -VC (on or off, changes name mangling). -Vl (on or off, changes struct layout). These options are provided in addition to those affecting which runtime library is used (more on which later); the total number of combinations of options can be obtained by multiplying together the individual options above, so that gives 2*2*2*5*4*5*2*2 = 3200 combinations! The problem is that users often expect to be able to build the Boost libraries and then just link to them and have everything just plain work, no matter what their project settings are. Irrespective of whether this is a reasonable expectation or not, without some means of managing this issue, the user may well find that their program will experience strange and hard to track down crashes at runtime unless the library they link to was built with the same options as their project (changes to the default alignment setting are a prime culprit). One way to manage this is with "prefix and suffix" headers: these headers invoke compiler specific #pragma directives to instruct the compiler that whatever code follows was built (or is to be built) with a specific set of compiler ABI settings. .... For example the regex libraries get named as follows when built with Visual Studio .NET 2003:boost_regex-vc71-mt-1_31.lib boost_regex-vc71-mt-gd-1_31.lib libboost_regex-vc71-mt-1_31.lib libboost_regex-vc71-mt-gd-1_31.lib libboost_regex-vc71-mt-s-1_31.lib libboost_regex-vc71-mt-sgd-1_31.lib libboost_regex-vc71-s-1_31.lib libboost_regex-vc71-sgd-1_31.lib The difficulty now is selecting which of these the user should link his or her code to. _________________________________________________________________ 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 Wed Jan 23 09:27:55 2008 From: jayk123 at hotmail.com (Jay) Date: Wed, 23 Jan 2008 08:27:55 +0000 Subject: [M3devel] platform/build_dir is a big tuple? In-Reply-To: <200801230722.m0N7Msbc036278@camembert.async.caltech.edu> References: Your message of "Wed, 23 Jan 2008 08:06:20 +0100." <200801230722.m0N7Msbc036278@camembert.async.caltech.edu> Message-ID: > but is there a great need for something between these two extremes? Unclear I agree. It was useful as a stepping stone to the other extreme. The problems with it were "portable", though PM3 already solved one of them. It's the closest thing *today* to NT386 that supports LONGINT and mitigates my guilt about that. :) IN FACT, oh crap I thought I was done thinking about this. In fact the NT386 distribution could include cm3cg/as and whenever source uses LONGINT, compile it with it. Hacky. Hopefully to be avoided by really fixing the integrated backend. There do exist MinGWin and MSys, so I'm not the one who thought of this in-between.There is even "GCW" but it seems stillborn. Anyway, I'm pretty sure this discusion can wind down now. :) (I didn't say end, I said wind down. :) ) Unless anyone really dislikes how I've structured the config files and my upcoming cm3 changes that I think will be very very very small. I'm thinking..TARGET will remain NT386, NT386GNU will all but go away, as a target, it will live on as a "configuration", of which cm3 knows nothing, OS_TYPE will vary, and it will determine jmpbuf size..is that sleazy? Integrated backend vs. non integrated backend will determine the calling convention issues. Backend mode is correct asis. Alternatives to keying off of OS_TYPE in cm3: 1) Key off a new variable called currently "CLibrary", usually ignored. But on NT386 has the values 0 and 1. 2) Have the config file set jmpbuf size itself, and have cm3 know about that new variable. Hard to argue with that. The config file already has the power to subtley destroy things through script, witness double alignment. 3) look into why cygwin has a larger jmpbuf, if msvc*dll setjmp can be used instead, or m3core.dll can have its own m3_setjmp and export it. Might be better to call it something more abstract, like m3_try_for_except and m3_try_for_finally. 4) Blow up the jmpbuf size unconditionally on NT386. Bigger than necessary should work fine, but is wasteful. #3 Looking into the cygwin jmpbuf is pretty much an absolute. Heck, maybe it's just padding for the future, or maybe only used depending on something... 5) Abandon 386 and move on to AMD64. :) - Jay _________________________________________________________________ Shed those extra pounds with MSN and The Biggest Loser! http://biggestloser.msn.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcoleburn at scires.com Wed Jan 23 09:50:10 2008 From: rcoleburn at scires.com (Randy Coleburn) Date: Wed, 23 Jan 2008 03:50:10 -0500 Subject: [M3devel] new problem on NT386 Message-ID: <4796B970.1E75.00D7.1@scires.com> As you know, I am working to finalize the new Reactor. I've run into a new problem that did not exist on cm3 v5.2.6 or on cm3 v4.1, so I am hoping someone, perhaps Jay, can shed some light. Reactor uses quake function calls to invoke operations like build, clean, ship, etc. I have determined that the change directory (cd) call is not working properly. Here is an example quake function used by Reactor to build a package: proc build_package (pkg, options) is exec ("cd", pkg, "| cm3", options) end If I had a package "Hello" located in C:\MyPkgs\Hello, here is what the exec call looks like: exec ("cd C:\MyPkgs\Hello | cm3") What is happening is that the "cd" is ignored and "cm3" is being called in the current directory (whichever that happens to be). Thus, the cm3.exe can't find the sources for the package. I've gone back to the old v5.2.6, and this wrong behavior does not occur. Instead, everything works as it should. So something has changed since that point in time that is causing a problem. Any ideas? Regards, Randy -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Wed Jan 23 10:11:15 2008 From: jayk123 at hotmail.com (Jay) Date: Wed, 23 Jan 2008 09:11:15 +0000 Subject: [M3devel] new problem on NT386 In-Reply-To: <4796B970.1E75.00D7.1@scires.com> References: <4796B970.1E75.00D7.1@scires.com> Message-ID: Surprising, but I'm sure it is trivial. For now try this: exec ("cmd", "/c \"", pkg, "| cm3", options, "\"") and if that doesn't work > "foo.cmd" in write(pkg, "| cm3", options) end exec("foo.cmd") or in the very unlikely change THAT doesn't work, exec("cmd /c foo.cmd") or exec("cmd", "/c", "foo.cmd") See version.quake for examples. cd %cvsroot% dir /s/b version.quake I'm embarrased about my proficiency with cmd and Quake. :) Actually for an even better related example maybe, look at m3cc\m3makefile and m3gdb\m3makefile. dir /s/b %cvsroot%\m3makefile | findstr /i m3cc have quick edit turned on in your cmd double click the output, right click once maybe (it's hard to remember verbally the muscle memory here) and then file.open, paste the Windows command line is nice! until you to start "programming it" with cmd (and then it can be nice, but not for long).... You will be sitting in the target directory likely so you don't need a unique file name. I have been prepending "private" temporary files with "_m3", like "_m3responsefile.txt", "_m3something.cmd". CM3 uses ".M3" but I don't like hidden files as that achieves on Unix, they just hide stuff that inevitably should be visible. (I keep going back and forth about the "@" characters in config files. For now, I have revealed the once per directory mklib and link/gcc, and the occasional C compilation, but kept hidden the repeated runs of m3cg and as; don't worry, this only applies to NT386 and my config-no-install directory.) What, Reactor is implemented in Quake instead of Modula-3? :) Later, - Jay Date: Wed, 23 Jan 2008 03:50:10 -0500From: rcoleburn at scires.comTo: m3devel at elegosoft.comSubject: [M3devel] new problem on NT386 As you know, I am working to finalize the new Reactor. I've run into a new problem that did not exist on cm3 v5.2.6 or on cm3 v4.1, so I am hoping someone, perhaps Jay, can shed some light. Reactor uses quake function calls to invoke operations like build, clean, ship, etc. I have determined that the change directory (cd) call is not working properly. Here is an example quake function used by Reactor to build a package: proc build_package (pkg, options) is exec ("cd", pkg, "| cm3", options)end If I had a package "Hello" located in C:\MyPkgs\Hello, here is what the exec call looks like: exec ("cd C:\MyPkgs\Hello | cm3") What is happening is that the "cd" is ignored and "cm3" is being called in the current directory (whichever that happens to be). Thus, the cm3.exe can't find the sources for the package. I've gone back to the old v5.2.6, and this wrong behavior does not occur. Instead, everything works as it should. So something has changed since that point in time that is causing a problem. Any ideas? Regards, Randy _________________________________________________________________ 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 rcoleburn at scires.com Wed Jan 23 11:29:31 2008 From: rcoleburn at scires.com (Randy Coleburn) Date: Wed, 23 Jan 2008 05:29:31 -0500 Subject: [M3devel] new problem on NT386 In-Reply-To: <4796B970.1E75.00D7.1@scires.com> References: <4796B970.1E75.00D7.1@scires.com> Message-ID: <4796D0BA.1E75.00D7.1@scires.com> OK, scratch what I said in my prior message about the "cd" not working. I ran some more tests and I'm not sure anymore. Jay, what has changed in the way quake, cm3, and cm3.cfg interact since v5.2.6? What I am seeing is that when Reactor is built using the current cm3, the output that should be going to the web browser is instead going to the console log. This is strange. The same exact code compiled under 5.2.6 works correctly (output goes to browser). Also, there are some strange differences in the output and the results are different. Not only are the results different, they are wrong under the new system, while they are correct under 5.2.6. Indeed, the build operation on the new system does not even find the correct package. Reactor is written in Modula-3, but it does use some quake helper functions. Here are the quake sources that Reactor is using for the clean and build procedures: proc clean_package (pkg) is exec ("cd", pkg, "| cm3 -verbose -clean") end proc build_package (pkg, options) is exec ("cd", pkg, "| cm3 -verbose", options) end As you can see, I've turned on the -verbose cm3 option to make the differences clear. Now, what I present next is the verbose output of 4 different operations, in the following order: 1. clean_package on 5.2.6 2. build_package on 5.2.6 3. clean_package on current cm3 4. build_package on current cm3 #1 and #2 work fine, while #3 and #4 do not. The source code for the Reactor package is the exact same in all 4 runs, the difference is that in 1 & 2 the source is built on v5.2.6, while in #3 & #4 it is built on the current cm3 checked out from the repository a few days ago. ==================================================================================== #1: Here is the result of running a clean operation followed by a build operation on the 5.2.6 cm3 system. (This version is correct!) cd C:\DOCUME~1\rcolebur\MYDOCU~1\CM3_ID~1\hello | cm3 -verbose -clean EVAL ("m3make.args") rm .M3SHIP rm .M3OVERRIDES rm Hello.mc rm Hello.ms rm Hello.mo rm Hello_m.o rm .M3EXPORTS rm hello.exe rm hello.mx rm .M3WEB rm hello.map rm hello.lst rm _m3main.c rm _m3main.o rm _m3main.obj rm .M3WEB seconds #times operation 0.02 16 removing temporary files 0.03 other --------------------------------------------------- 0.05 TOTAL rm m3make.args cd .. ================================================================================= #2: Now, the build operation on 5.2.6 (again, this is correct): cd C:\DOCUME~1\rcolebur\MYDOCU~1\CM3_ID~1\hello | cm3 -verbose EVAL ("m3make.args") rm .M3SHIP rm .M3OVERRIDES inhale hello.mx inhale c:\cm3\pkg\m3core\NT386\m3core.lib reading "c:\cm3\pkg\m3core\NT386\m3core.m3x": 0 seconds no source to match imported link unit M3_BUILTIN.i3 inhale c:\cm3\pkg\libm3\NT386\m3.lib reading "c:\cm3\pkg\libm3\NT386\m3.m3x": 0 seconds checking Hello.m3 checking IO.i3 in library c:\cm3\pkg\libm3\NT386\m3.lib checking Wr.i3 in library c:\cm3\pkg\libm3\NT386\m3.lib checking Thread.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking RTHooks.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking TextCat.m3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking TextLiteral.m3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking RTThread.m3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking RTType.m3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking RTDebug.m3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking RTAllocator.m3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking RTHooks.m3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking ThreadWin32.m3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking OSConfig.i3 in library c:\cm3\pkg\libm3\NT386\m3.lib checking OSConfigWin32.m3 in library c:\cm3\pkg\libm3\NT386\m3.lib checking AtomList.i3 in library c:\cm3\pkg\libm3\NT386\m3.lib checking Atom.i3 in library c:\cm3\pkg\libm3\NT386\m3.lib checking Atom.m3 in library c:\cm3\pkg\libm3\NT386\m3.lib checking AtomList.m3 in library c:\cm3\pkg\libm3\NT386\m3.lib checking Wr.m3 in library c:\cm3\pkg\libm3\NT386\m3.lib checking Rd.i3 in library c:\cm3\pkg\libm3\NT386\m3.lib checking Rd.m3 in library c:\cm3\pkg\libm3\NT386\m3.lib checking IO.m3 in library c:\cm3\pkg\libm3\NT386\m3.lib checking Main.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking FloatMode.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking FloatMode.m3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking Lex.i3 in library c:\cm3\pkg\libm3\NT386\m3.lib checking Word.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking Word.m3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking Lex.m3 in library c:\cm3\pkg\libm3\NT386\m3.lib checking OSError.i3 in library c:\cm3\pkg\libm3\NT386\m3.lib checking OSErrorWin32.m3 in library c:\cm3\pkg\libm3\NT386\m3.lib checking Fmt.i3 in library c:\cm3\pkg\libm3\NT386\m3.lib checking Extended.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking Extended.m3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking LongReal.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking LongReal.m3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking Real.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking Real.m3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking Fmt.m3 in library c:\cm3\pkg\libm3\NT386\m3.lib checking FileWr.i3 in library c:\cm3\pkg\libm3\NT386\m3.lib checking Pathname.i3 in library c:\cm3\pkg\libm3\NT386\m3.lib checking TextSeq.i3 in library c:\cm3\pkg\libm3\NT386\m3.lib checking Text.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking TextClass.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking M3_BUILTIN.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking TextClass.m3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking TextSub.m3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking Text.m3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking TextSeq.m3 in library c:\cm3\pkg\libm3\NT386\m3.lib checking PathnameWin32.m3 in library c:\cm3\pkg\libm3\NT386\m3.lib checking File.i3 in library c:\cm3\pkg\libm3\NT386\m3.lib checking Time.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking TimeWin32.m3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking FileWr.m3 in library c:\cm3\pkg\libm3\NT386\m3.lib checking FileRd.i3 in library c:\cm3\pkg\libm3\NT386\m3.lib checking FileRd.m3 in library c:\cm3\pkg\libm3\NT386\m3.lib checking Stdio.i3 in library c:\cm3\pkg\libm3\NT386\m3.lib checking Stdio.m3 in library c:\cm3\pkg\libm3\NT386\m3.lib checking WrClass.i3 in library c:\cm3\pkg\libm3\NT386\m3.lib checking Process.i3 in library c:\cm3\pkg\libm3\NT386\m3.lib checking ProcessWin32.m3 in library c:\cm3\pkg\libm3\NT386\m3.lib checking WinBase.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking Ctypes.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking BasicCtypes.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking WinDef.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking WinBaseTypes.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking WinDef.m3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking WinNT.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking WinNT.m3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking RTProcess.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking RTProcess.m3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking OSErrorWin32.i3 in library c:\cm3\pkg\libm3\NT386\m3.lib checking M3toC.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking M3toC.m3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking LazyConsole.i3 in library c:\cm3\pkg\libm3\NT386\m3.lib checking FileWin32.i3 in library c:\cm3\pkg\libm3\NT386\m3.lib checking Pipe.i3 in library c:\cm3\pkg\libm3\NT386\m3.lib checking PipeWin32.m3 in library c:\cm3\pkg\libm3\NT386\m3.lib checking Pipe.m3 in library c:\cm3\pkg\libm3\NT386\m3.lib checking FileWin32.m3 in library c:\cm3\pkg\libm3\NT386\m3.lib checking LazyConsole.m3 in library c:\cm3\pkg\libm3\NT386\m3.lib checking WinCon.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking Terminal.i3 in library c:\cm3\pkg\libm3\NT386\m3.lib checking Terminal.m3 in library c:\cm3\pkg\libm3\NT386\m3.lib checking TimeWin32.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking WinError.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking RegularFile.i3 in library c:\cm3\pkg\libm3\NT386\m3.lib checking RegularFile.m3 in library c:\cm3\pkg\libm3\NT386\m3.lib checking Text8CString.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking Text8CString.m3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking Text8.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking Text8.m3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking Cstring.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking Cstdlib.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking Cstddef.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking Text8Short.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking Text8Short.m3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking RTOS.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking RTOS.m3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking RTIO.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking RTIO.m3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking RTException.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking RT0.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking RT0.m3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking RTExFrame.m3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking RTException.m3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking RTHeapRep.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking RTHeapDep.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking RTMachine.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking Csetjmp.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking RTHeapDep.m3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking RTCollector.m3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking RTHeapRep.m3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking RTType.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking TextLiteral.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking RuntimeError.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking RuntimeError.m3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking ThreadF.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking RTPerfTool.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking RTPerfTool.m3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking RTParams.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking RTParams.m3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking RTMisc.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking RTMisc.m3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking RTVM.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking RTHeapMap.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking RTHeapMap.m3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking RTHeapEvent.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking RTWeakRef.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking RTCollectorSRC.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking RTCollector.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking RTMapOp.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking RTTypeMap.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking RTTypeMap.m3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking RTMapOp.m3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking RTModule.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking RTLinker.m3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking RTLinkerX.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking RTHeapInfo.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking RTHeapInfo.m3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking RTThreadInit.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking RTSignal.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking RTSignal.m3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking RTTypeSRC.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking RTLinker.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking ThreadContext.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking RTError.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking RTError.m3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking RTMachInfo.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking RTMachInfo.m3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking RTProcedureSRC.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking RTProcedure.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking Fingerprint.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking Fingerprint.m3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking RTProcedure.m3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking Poly.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking Poly.m3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking PolyBasis.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking PolyBasis.m3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking RTAllocCnts.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking RTArgs.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking RTArgs.m3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking Compiler.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking Compiler.m3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking RTThread.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking RTExFrame.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking RdClass.i3 in library c:\cm3\pkg\libm3\NT386\m3.lib checking FS.i3 in library c:\cm3\pkg\libm3\NT386\m3.lib checking FSWin32.m3 in library c:\cm3\pkg\libm3\NT386\m3.lib checking FS.m3 in library c:\cm3\pkg\libm3\NT386\m3.lib checking OSWin32.i3 in library c:\cm3\pkg\libm3\NT386\m3.lib checking OSWin32.m3 in library c:\cm3\pkg\libm3\NT386\m3.lib checking TextSeqRep.i3 in library c:\cm3\pkg\libm3\NT386\m3.lib checking String16.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking String16.m3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking String8.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking String8.m3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking Text16.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking Text16.m3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking Text16Short.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking Text16Short.m3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking TextCat.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking TextSub.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking ExtendedFloat.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking ExtendedFloat.m3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking LongFloat.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking LongFloat.m3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking RealFloat.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking RealFloat.m3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking FmtBufF.i3 in library c:\cm3\pkg\libm3\NT386\m3.lib checking FmtBuf.i3 in library c:\cm3\pkg\libm3\NT386\m3.lib checking FmtBuf.m3 in library c:\cm3\pkg\libm3\NT386\m3.lib checking Convert.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking Convert.m3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking CConvert.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking CConvert.m3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking FmtBufTest.i3 in library c:\cm3\pkg\libm3\NT386\m3.lib checking FPU.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking FPU.m3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking DragonT.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking DragonT.m3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking RealRep.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking DragonInt.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking DragonInt.m3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking LongRealRep.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking IEEESpecial.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking IEEESpecial.m3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking UnsafeRd.i3 in library c:\cm3\pkg\libm3\NT386\m3.lib checking UnsafeWr.i3 in library c:\cm3\pkg\libm3\NT386\m3.lib checking AtomAtomTbl.i3 in library c:\cm3\pkg\libm3\NT386\m3.lib checking AtomAtomTbl.m3 in library c:\cm3\pkg\libm3\NT386\m3.lib checking WinSock.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking WinSock.m3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking Env.i3 in library c:\cm3\pkg\libm3\NT386\m3.lib checking Env.m3 in library c:\cm3\pkg\libm3\NT386\m3.lib checking MutexRep.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking WinGDI.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking WinGDI.m3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking Scheduler.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking RTHeap.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking RTHeap.m3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking RTAllocator.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking RTDebug.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib Compiling Hello.m3 (new source) m3front ..\src\Hello.m3 -unfold_nested_procs -check_procs -w1 exhale hello.mx linking hello.exe generate _m3main.obj C:\PROGRA~1\MID05A~1\VC\bin\LINK @C:\DOCUME~1\rcolebur\LOCALS~1\Temp\qk > hello.lst m3_link => 0 seconds #times operation 0.02 3 inhaling library link info 0.03 224 merging new link info 0.02 1 generating _m3main.c 0.11 1 linking 0.02 3 garbage collection --------------------------------------------------- 0.19 TOTAL rm m3make.args cd .. ================================================================================= #3: Here is the clean operation on the current cm3 system (this is different, and wrong): calling clean_package("C:\DOCUME~1\cm3\MYDOCU~1\CM3_ID~1\hello") EVAL ("cm3.cfg") mkdir NT386 --- cleaning NT386 --- cd NT386 Looking in .. ignoring ..\anim3D.dll (not a directory) ignoring ..\anim3D.pdb (not a directory) ignoring ..\binIO.dll (not a directory) ignoring ..\binIO.pdb (not a directory) ignoring ..\BitVector.dll (not a directory) ignoring ..\BitVector.pdb (not a directory) ignoring ..\Calculator.exe (not a directory) ignoring ..\Calculator.pdb (not a directory) ignoring ..\CheckForNetObjD.exe (not a directory) ignoring ..\CheckForNetObjD.pdb (not a directory) ignoring ..\cm3-d5.5.0.exe (not a directory) ignoring ..\cm3-d5.5.0.pdb (not a directory) ignoring ..\cm3-d5.5.1.exe (not a directory) ignoring ..\cm3-d5.5.1.pdb (not a directory) ignoring ..\cm3.cfg (not a directory) ignoring ..\cm3.exe (not a directory) ignoring ..\cm3.pdb (not a directory) ignoring ..\cm3ide.exe (not a directory) ignoring ..\cm3ide.pdb (not a directory) ignoring ..\cm3Proj.CMD (not a directory) ignoring ..\cm3SetupCmdEnv.CMD (not a directory) ignoring ..\cm3StartIDE.CMD (not a directory) ignoring ..\cm3v41.cfg (not a directory) ignoring ..\cmpdir.exe (not a directory) ignoring ..\cmpdir.pdb (not a directory) ignoring ..\cmpfp.pdb (not a directory) ignoring ..\cmvbt.dll (not a directory) ignoring ..\cmvbt.pdb (not a directory) ignoring ..\Cube.exe (not a directory) ignoring ..\Cube.pdb (not a directory) ignoring ..\CV_Banner.exe (not a directory) ignoring ..\CV_Banner.pdb (not a directory) ignoring ..\CV_Client.exe (not a directory) ignoring ..\CV_Client.pdb (not a directory) ignoring ..\CV_ListConfigDefns.exe (not a directory) ignoring ..\CV_ListConfigDefns.pdb (not a directory) ignoring ..\CV_MessageTool.exe (not a directory) ignoring ..\CV_MessageTool.pdb (not a directory) ignoring ..\CV_Server.exe (not a directory) ignoring ..\CV_Server.pdb (not a directory) ignoring ..\CV_Shutdown.exe (not a directory) ignoring ..\CV_Shutdown.pdb (not a directory) ignoring ..\cygwin1.dll (not a directory) ignoring ..\db.dll (not a directory) ignoring ..\db.pdb (not a directory) ignoring ..\debug.dll (not a directory) ignoring ..\debug.pdb (not a directory) ignoring ..\deepcopy.dll (not a directory) ignoring ..\deepcopy.pdb (not a directory) ignoring ..\DiGraph.dll (not a directory) ignoring ..\DiGraph.pdb (not a directory) ignoring ..\dirfp.exe (not a directory) ignoring ..\dirfp.pdb (not a directory) ignoring ..\Documentation_cm3Proj.htm (not a directory) ignoring ..\Documentation_cm3Proj.pdf (not a directory) ignoring ..\Documentation_CM3SetupCmdEnv.htm (not a directory) ignoring ..\Documentation_CM3SetupCmdEnv.pdf (not a directory) ignoring ..\Documentation_CM3StartIDE.htm (not a directory) ignoring ..\Documentation_CM3StartIDE.pdf (not a directory) ignoring ..\DummyNavServer.exe (not a directory) ignoring ..\DummyNavServer.pdb (not a directory) ignoring ..\embutils.dll (not a directory) ignoring ..\embutils.pdb (not a directory) ignoring ..\events.dll (not a directory) ignoring ..\events.pdb (not a directory) ignoring ..\fisheye.exe (not a directory) ignoring ..\fisheye.pdb (not a directory) ignoring ..\fix_nl.exe (not a directory) ignoring ..\fix_nl.pdb (not a directory) ignoring ..\foo2.pdb (not a directory) ignoring ..\formsedit.exe (not a directory) ignoring ..\formsedit.pdb (not a directory) ignoring ..\formsview.pdb (not a directory) ignoring ..\Geometry.dll (not a directory) ignoring ..\Geometry.pdb (not a directory) ignoring ..\gzip.exe (not a directory) ignoring ..\http.dll (not a directory) ignoring ..\http.pdb (not a directory) ignoring ..\juno-compiler.dll (not a directory) ignoring ..\juno-compiler.pdb (not a directory) ignoring ..\juno-machine.dll (not a directory) ignoring ..\juno-machine.pdb (not a directory) ignoring ..\Juno.exe (not a directory) ignoring ..\Juno.pdb (not a directory) ignoring ..\jvideo.dll (not a directory) ignoring ..\jvideo.pdb (not a directory) ignoring ..\libbuf.dll (not a directory) ignoring ..\libbuf.pdb (not a directory) ignoring ..\libCV.dll (not a directory) ignoring ..\libCV.pdb (not a directory) ignoring ..\libdump.pdb (not a directory) ignoring ..\libGUI.dll (not a directory) ignoring ..\libGUI.pdb (not a directory) ignoring ..\libSciRes3.dll (not a directory) ignoring ..\libSciRes3.pdb (not a directory) ignoring ..\libsio.dll (not a directory) ignoring ..\libsio.pdb (not a directory) ignoring ..\listfuncs.dll (not a directory) ignoring ..\listfuncs.pdb (not a directory) ignoring ..\m3.dll (not a directory) ignoring ..\m3.pdb (not a directory) ignoring ..\m3back.pdb (not a directory) ignoring ..\m3browser.exe (not a directory) ignoring ..\m3browser.pdb (not a directory) ignoring ..\m3bundle.exe (not a directory) ignoring ..\m3bundle.pdb (not a directory) ignoring ..\m3cgcat.pdb (not a directory) ignoring ..\m3cggen.pdb (not a directory) ignoring ..\m3codeview.dll (not a directory) ignoring ..\m3codeview.pdb (not a directory) ignoring ..\m3core.dll (not a directory) ignoring ..\m3core.pdb (not a directory) ignoring ..\m3formsvbt.dll (not a directory) ignoring ..\m3formsvbt.pdb (not a directory) ignoring ..\m3formsvbtpixmaps.dll (not a directory) ignoring ..\m3formsvbtpixmaps.pdb (not a directory) ignoring ..\m3markup.dll (not a directory) ignoring ..\m3markup.pdb (not a directory) ignoring ..\m3mg.dll (not a directory) ignoring ..\m3mg.pdb (not a directory) ignoring ..\m3mgkit.dll (not a directory) ignoring ..\m3mgkit.pdb (not a directory) ignoring ..\m3netobj.dll (not a directory) ignoring ..\m3netobj.pdb (not a directory) ignoring ..\m3parseparams.dll (not a directory) ignoring ..\m3parseparams.pdb (not a directory) ignoring ..\m3scan.dll (not a directory) ignoring ..\m3scan.pdb (not a directory) ignoring ..\m3slisp.dll (not a directory) ignoring ..\m3slisp.pdb (not a directory) ignoring ..\m3smalldb.dll (not a directory) ignoring ..\m3smalldb.pdb (not a directory) ignoring ..\m3tcl.dll (not a directory) ignoring ..\m3tcl.pdb (not a directory) ignoring ..\m3tcp.dll (not a directory) ignoring ..\m3tcp.pdb (not a directory) ignoring ..\m3tk-misc.dll (not a directory) ignoring ..\m3tk-misc.pdb (not a directory) ignoring ..\m3tk.dll (not a directory) ignoring ..\m3tk.pdb (not a directory) ignoring ..\m3tohtml.exe (not a directory) ignoring ..\m3tohtml.pdb (not a directory) ignoring ..\m3totex.exe (not a directory) ignoring ..\m3totex.pdb (not a directory) ignoring ..\m3ui.dll (not a directory) ignoring ..\m3ui.pdb (not a directory) ignoring ..\m3vbtkit.dll (not a directory) ignoring ..\m3vbtkit.pdb (not a directory) ignoring ..\m3zeus.dll (not a directory) ignoring ..\m3zeus.pdb (not a directory) ignoring ..\m3zume.exe (not a directory) ignoring ..\m3zume.pdb (not a directory) ignoring ..\MakeShortPath.cmd (not a directory) ignoring ..\mentor.exe (not a directory) ignoring ..\mentor.pdb (not a directory) ignoring ..\metasyn.dll (not a directory) ignoring ..\metasyn.pdb (not a directory) ignoring ..\mklib.exe (not a directory) ignoring ..\mklib.pdb (not a directory) ignoring ..\netobjd.exe (not a directory) ignoring ..\netobjd.pdb (not a directory) ignoring ..\NT386 (derived object directory) ignoring ..\obliq (not a directory) ignoring ..\obliq-anim.exe (not a directory) ignoring ..\obliq-anim.pdb (not a directory) ignoring ..\obliq-min.exe (not a directory) ignoring ..\obliq-min.pdb (not a directory) ignoring ..\obliq-std.exe (not a directory) ignoring ..\obliq-std.pdb (not a directory) ignoring ..\obliq-ui.exe (not a directory) ignoring ..\obliq-ui.pdb (not a directory) ignoring ..\obliq.dll (not a directory) ignoring ..\obliq.pdb (not a directory) ignoring ..\obliqlibanim.dll (not a directory) ignoring ..\obliqlibanim.pdb (not a directory) ignoring ..\obliqlibemb.dll (not a directory) ignoring ..\obliqlibemb.pdb (not a directory) ignoring ..\obliqlibm3.dll (not a directory) ignoring ..\obliqlibm3.pdb (not a directory) ignoring ..\obliqlibui.dll (not a directory) ignoring ..\obliqlibui.pdb (not a directory) ignoring ..\obliqparse.dll (not a directory) ignoring ..\obliqparse.pdb (not a directory) ignoring ..\obliqprint.dll (not a directory) ignoring ..\obliqprint.pdb (not a directory) ignoring ..\obliqrt.dll (not a directory) ignoring ..\obliqrt.pdb (not a directory) ignoring ..\obliqsrv (not a directory) ignoring ..\obliqsrv-std.exe (not a directory) ignoring ..\obliqsrv-std.pdb (not a directory) ignoring ..\obliqsrv-ui.exe (not a directory) ignoring ..\obliqsrv-ui.pdb (not a directory) ignoring ..\odbc.dll (not a directory) ignoring ..\odbc.pdb (not a directory) ignoring ..\opengl.dll (not a directory) ignoring ..\opengl.pdb (not a directory) ignoring ..\patternmatching.dll (not a directory) ignoring ..\patternmatching.pdb (not a directory) ignoring ..\PklFonts.pdb (not a directory) ignoring ..\rdwr.dll (not a directory) ignoring ..\rdwr.pdb (not a directory) ignoring ..\recordheap (not a directory) ignoring ..\RehearseCode.exe (not a directory) ignoring ..\RehearseCode.pdb (not a directory) ignoring ..\replayheap.exe (not a directory) ignoring ..\replayheap.pdb (not a directory) ignoring ..\serial2.dll (not a directory) ignoring ..\serial2.pdb (not a directory) ignoring ..\serialio.dll (not a directory) ignoring ..\serialio.pdb (not a directory) ignoring ..\set.dll (not a directory) ignoring ..\set.pdb (not a directory) ignoring ..\sgml.dll (not a directory) ignoring ..\sgml.pdb (not a directory) ignoring ..\sharedobj.dll (not a directory) ignoring ..\sharedobj.pdb (not a directory) ignoring ..\shobjcodegen.exe (not a directory) ignoring ..\shobjcodegen.pdb (not a directory) ignoring ..\showheap.exe (not a directory) ignoring ..\showheap.pdb (not a directory) ignoring ..\shownew.exe (not a directory) ignoring ..\shownew.pdb (not a directory) ignoring ..\showthread.exe (not a directory) ignoring ..\showthread.pdb (not a directory) ignoring ..\SortedTableExtras.dll (not a directory) ignoring ..\SortedTableExtras.pdb (not a directory) ignoring ..\stable.dll (not a directory) ignoring ..\stable.pdb (not a directory) ignoring ..\stablegen.exe (not a directory) ignoring ..\stablegen.pdb (not a directory) ignoring ..\stubgen.exe (not a directory) ignoring ..\stubgen.pdb (not a directory) ignoring ..\synex.dll (not a directory) ignoring ..\synex.pdb (not a directory) ignoring ..\synwr.dll (not a directory) ignoring ..\synwr.pdb (not a directory) ignoring ..\table-list.dll (not a directory) ignoring ..\table-list.pdb (not a directory) ignoring ..\tar.exe (not a directory) ignoring ..\TempFiles.dll (not a directory) ignoring ..\TempFiles.pdb (not a directory) ignoring ..\TestPixmap.pdb (not a directory) ignoring ..\UDP.dll (not a directory) ignoring ..\UDP.pdb (not a directory) ignoring ..\uniq.pdb (not a directory) ignoring ..\videovbt.dll (not a directory) ignoring ..\videovbt.pdb (not a directory) ignoring ..\visobliq.exe (not a directory) ignoring ..\visobliq.pdb (not a directory) ignoring ..\vocgi.exe (not a directory) ignoring ..\vocgi.pdb (not a directory) ignoring ..\voquery.exe (not a directory) ignoring ..\voquery.pdb (not a directory) ignoring ..\vorun.exe (not a directory) ignoring ..\vorun.pdb (not a directory) ignoring ..\vostart (not a directory) ignoring ..\vostart.cmd (not a directory) ignoring ..\web.dll (not a directory) ignoring ..\web.pdb (not a directory) ignoring ..\webvbt.dll (not a directory) ignoring ..\webvbt.pdb (not a directory) ignoring ..\windowsResources.dll (not a directory) ignoring ..\windowsResources.pdb (not a directory) ignoring ..\zapNT386.cmd (not a directory) EVAL ("m3make.args") rm .M3SHIP rm .M3OVERRIDES rm .M3EXPORTS rm prog.exe rm prog.mx rm .M3WEB rm prog.map rm prog.lst rm _m3main.c rm _m3main.o rm _m3main.obj rm .M3WEB seconds #times operation 0.01 3 garbage collection 0.04 other --------------------------------------------------- 0.05 TOTAL rm m3make.args cd .. is_empty (NT386) => rmdir NT386 ================================================================================= #4: Here is the build operation on the current cm3 (this is different from v5.2.6 and wrong--it does not find the package to build!): calling build_package("C:\DOCUME~1\cm3\MYDOCU~1\CM3_ID~1\hello", "") EVAL ("cm3.cfg") mkdir NT386 --- building in NT386 --- cd NT386 Looking in .. ignoring ..\anim3D.dll (not a directory) ignoring ..\anim3D.pdb (not a directory) ignoring ..\binIO.dll (not a directory) ignoring ..\binIO.pdb (not a directory) ignoring ..\BitVector.dll (not a directory) ignoring ..\BitVector.pdb (not a directory) ignoring ..\Calculator.exe (not a directory) ignoring ..\Calculator.pdb (not a directory) ignoring ..\CheckForNetObjD.exe (not a directory) ignoring ..\CheckForNetObjD.pdb (not a directory) ignoring ..\cm3-d5.5.0.exe (not a directory) ignoring ..\cm3-d5.5.0.pdb (not a directory) ignoring ..\cm3-d5.5.1.exe (not a directory) ignoring ..\cm3-d5.5.1.pdb (not a directory) ignoring ..\cm3.cfg (not a directory) ignoring ..\cm3.exe (not a directory) ignoring ..\cm3.pdb (not a directory) ignoring ..\cm3ide.exe (not a directory) ignoring ..\cm3ide.pdb (not a directory) ignoring ..\cm3Proj.CMD (not a directory) ignoring ..\cm3SetupCmdEnv.CMD (not a directory) ignoring ..\cm3StartIDE.CMD (not a directory) ignoring ..\cm3v41.cfg (not a directory) ignoring ..\cmpdir.exe (not a directory) ignoring ..\cmpdir.pdb (not a directory) ignoring ..\cmpfp.pdb (not a directory) ignoring ..\cmvbt.dll (not a directory) ignoring ..\cmvbt.pdb (not a directory) ignoring ..\Cube.exe (not a directory) ignoring ..\Cube.pdb (not a directory) ignoring ..\CV_Banner.exe (not a directory) ignoring ..\CV_Banner.pdb (not a directory) ignoring ..\CV_Client.exe (not a directory) ignoring ..\CV_Client.pdb (not a directory) ignoring ..\CV_ListConfigDefns.exe (not a directory) ignoring ..\CV_ListConfigDefns.pdb (not a directory) ignoring ..\CV_MessageTool.exe (not a directory) ignoring ..\CV_MessageTool.pdb (not a directory) ignoring ..\CV_Server.exe (not a directory) ignoring ..\CV_Server.pdb (not a directory) ignoring ..\CV_Shutdown.exe (not a directory) ignoring ..\CV_Shutdown.pdb (not a directory) ignoring ..\cygwin1.dll (not a directory) ignoring ..\db.dll (not a directory) ignoring ..\db.pdb (not a directory) ignoring ..\debug.dll (not a directory) ignoring ..\debug.pdb (not a directory) ignoring ..\deepcopy.dll (not a directory) ignoring ..\deepcopy.pdb (not a directory) ignoring ..\DiGraph.dll (not a directory) ignoring ..\DiGraph.pdb (not a directory) ignoring ..\dirfp.exe (not a directory) ignoring ..\dirfp.pdb (not a directory) ignoring ..\Documentation_cm3Proj.htm (not a directory) ignoring ..\Documentation_cm3Proj.pdf (not a directory) ignoring ..\Documentation_CM3SetupCmdEnv.htm (not a directory) ignoring ..\Documentation_CM3SetupCmdEnv.pdf (not a directory) ignoring ..\Documentation_CM3StartIDE.htm (not a directory) ignoring ..\Documentation_CM3StartIDE.pdf (not a directory) ignoring ..\DummyNavServer.exe (not a directory) ignoring ..\DummyNavServer.pdb (not a directory) ignoring ..\embutils.dll (not a directory) ignoring ..\embutils.pdb (not a directory) ignoring ..\events.dll (not a directory) ignoring ..\events.pdb (not a directory) ignoring ..\fisheye.exe (not a directory) ignoring ..\fisheye.pdb (not a directory) ignoring ..\fix_nl.exe (not a directory) ignoring ..\fix_nl.pdb (not a directory) ignoring ..\foo2.pdb (not a directory) ignoring ..\formsedit.exe (not a directory) ignoring ..\formsedit.pdb (not a directory) ignoring ..\formsview.pdb (not a directory) ignoring ..\Geometry.dll (not a directory) ignoring ..\Geometry.pdb (not a directory) ignoring ..\gzip.exe (not a directory) ignoring ..\http.dll (not a directory) ignoring ..\http.pdb (not a directory) ignoring ..\juno-compiler.dll (not a directory) ignoring ..\juno-compiler.pdb (not a directory) ignoring ..\juno-machine.dll (not a directory) ignoring ..\juno-machine.pdb (not a directory) ignoring ..\Juno.exe (not a directory) ignoring ..\Juno.pdb (not a directory) ignoring ..\jvideo.dll (not a directory) ignoring ..\jvideo.pdb (not a directory) ignoring ..\libbuf.dll (not a directory) ignoring ..\libbuf.pdb (not a directory) ignoring ..\libCV.dll (not a directory) ignoring ..\libCV.pdb (not a directory) ignoring ..\libdump.pdb (not a directory) ignoring ..\libGUI.dll (not a directory) ignoring ..\libGUI.pdb (not a directory) ignoring ..\libSciRes3.dll (not a directory) ignoring ..\libSciRes3.pdb (not a directory) ignoring ..\libsio.dll (not a directory) ignoring ..\libsio.pdb (not a directory) ignoring ..\listfuncs.dll (not a directory) ignoring ..\listfuncs.pdb (not a directory) ignoring ..\m3.dll (not a directory) ignoring ..\m3.pdb (not a directory) ignoring ..\m3back.pdb (not a directory) ignoring ..\m3browser.exe (not a directory) ignoring ..\m3browser.pdb (not a directory) ignoring ..\m3bundle.exe (not a directory) ignoring ..\m3bundle.pdb (not a directory) ignoring ..\m3cgcat.pdb (not a directory) ignoring ..\m3cggen.pdb (not a directory) ignoring ..\m3codeview.dll (not a directory) ignoring ..\m3codeview.pdb (not a directory) ignoring ..\m3core.dll (not a directory) ignoring ..\m3core.pdb (not a directory) ignoring ..\m3formsvbt.dll (not a directory) ignoring ..\m3formsvbt.pdb (not a directory) ignoring ..\m3formsvbtpixmaps.dll (not a directory) ignoring ..\m3formsvbtpixmaps.pdb (not a directory) ignoring ..\m3markup.dll (not a directory) ignoring ..\m3markup.pdb (not a directory) ignoring ..\m3mg.dll (not a directory) ignoring ..\m3mg.pdb (not a directory) ignoring ..\m3mgkit.dll (not a directory) ignoring ..\m3mgkit.pdb (not a directory) ignoring ..\m3netobj.dll (not a directory) ignoring ..\m3netobj.pdb (not a directory) ignoring ..\m3parseparams.dll (not a directory) ignoring ..\m3parseparams.pdb (not a directory) ignoring ..\m3scan.dll (not a directory) ignoring ..\m3scan.pdb (not a directory) ignoring ..\m3slisp.dll (not a directory) ignoring ..\m3slisp.pdb (not a directory) ignoring ..\m3smalldb.dll (not a directory) ignoring ..\m3smalldb.pdb (not a directory) ignoring ..\m3tcl.dll (not a directory) ignoring ..\m3tcl.pdb (not a directory) ignoring ..\m3tcp.dll (not a directory) ignoring ..\m3tcp.pdb (not a directory) ignoring ..\m3tk-misc.dll (not a directory) ignoring ..\m3tk-misc.pdb (not a directory) ignoring ..\m3tk.dll (not a directory) ignoring ..\m3tk.pdb (not a directory) ignoring ..\m3tohtml.exe (not a directory) ignoring ..\m3tohtml.pdb (not a directory) ignoring ..\m3totex.exe (not a directory) ignoring ..\m3totex.pdb (not a directory) ignoring ..\m3ui.dll (not a directory) ignoring ..\m3ui.pdb (not a directory) ignoring ..\m3vbtkit.dll (not a directory) ignoring ..\m3vbtkit.pdb (not a directory) ignoring ..\m3zeus.dll (not a directory) ignoring ..\m3zeus.pdb (not a directory) ignoring ..\m3zume.exe (not a directory) ignoring ..\m3zume.pdb (not a directory) ignoring ..\MakeShortPath.cmd (not a directory) ignoring ..\mentor.exe (not a directory) ignoring ..\mentor.pdb (not a directory) ignoring ..\metasyn.dll (not a directory) ignoring ..\metasyn.pdb (not a directory) ignoring ..\mklib.exe (not a directory) ignoring ..\mklib.pdb (not a directory) ignoring ..\netobjd.exe (not a directory) ignoring ..\netobjd.pdb (not a directory) ignoring ..\NT386 (derived object directory) ignoring ..\obliq (not a directory) ignoring ..\obliq-anim.exe (not a directory) ignoring ..\obliq-anim.pdb (not a directory) ignoring ..\obliq-min.exe (not a directory) ignoring ..\obliq-min.pdb (not a directory) ignoring ..\obliq-std.exe (not a directory) ignoring ..\obliq-std.pdb (not a directory) ignoring ..\obliq-ui.exe (not a directory) ignoring ..\obliq-ui.pdb (not a directory) ignoring ..\obliq.dll (not a directory) ignoring ..\obliq.pdb (not a directory) ignoring ..\obliqlibanim.dll (not a directory) ignoring ..\obliqlibanim.pdb (not a directory) ignoring ..\obliqlibemb.dll (not a directory) ignoring ..\obliqlibemb.pdb (not a directory) ignoring ..\obliqlibm3.dll (not a directory) ignoring ..\obliqlibm3.pdb (not a directory) ignoring ..\obliqlibui.dll (not a directory) ignoring ..\obliqlibui.pdb (not a directory) ignoring ..\obliqparse.dll (not a directory) ignoring ..\obliqparse.pdb (not a directory) ignoring ..\obliqprint.dll (not a directory) ignoring ..\obliqprint.pdb (not a directory) ignoring ..\obliqrt.dll (not a directory) ignoring ..\obliqrt.pdb (not a directory) ignoring ..\obliqsrv (not a directory) ignoring ..\obliqsrv-std.exe (not a directory) ignoring ..\obliqsrv-std.pdb (not a directory) ignoring ..\obliqsrv-ui.exe (not a directory) ignoring ..\obliqsrv-ui.pdb (not a directory) ignoring ..\odbc.dll (not a directory) ignoring ..\odbc.pdb (not a directory) ignoring ..\opengl.dll (not a directory) ignoring ..\opengl.pdb (not a directory) ignoring ..\patternmatching.dll (not a directory) ignoring ..\patternmatching.pdb (not a directory) ignoring ..\PklFonts.pdb (not a directory) ignoring ..\rdwr.dll (not a directory) ignoring ..\rdwr.pdb (not a directory) ignoring ..\recordheap (not a directory) ignoring ..\RehearseCode.exe (not a directory) ignoring ..\RehearseCode.pdb (not a directory) ignoring ..\replayheap.exe (not a directory) ignoring ..\replayheap.pdb (not a directory) ignoring ..\serial2.dll (not a directory) ignoring ..\serial2.pdb (not a directory) ignoring ..\serialio.dll (not a directory) ignoring ..\serialio.pdb (not a directory) ignoring ..\set.dll (not a directory) ignoring ..\set.pdb (not a directory) ignoring ..\sgml.dll (not a directory) ignoring ..\sgml.pdb (not a directory) ignoring ..\sharedobj.dll (not a directory) ignoring ..\sharedobj.pdb (not a directory) ignoring ..\shobjcodegen.exe (not a directory) ignoring ..\shobjcodegen.pdb (not a directory) ignoring ..\showheap.exe (not a directory) ignoring ..\showheap.pdb (not a directory) ignoring ..\shownew.exe (not a directory) ignoring ..\shownew.pdb (not a directory) ignoring ..\showthread.exe (not a directory) ignoring ..\showthread.pdb (not a directory) ignoring ..\SortedTableExtras.dll (not a directory) ignoring ..\SortedTableExtras.pdb (not a directory) ignoring ..\stable.dll (not a directory) ignoring ..\stable.pdb (not a directory) ignoring ..\stablegen.exe (not a directory) ignoring ..\stablegen.pdb (not a directory) ignoring ..\stubgen.exe (not a directory) ignoring ..\stubgen.pdb (not a directory) ignoring ..\synex.dll (not a directory) ignoring ..\synex.pdb (not a directory) ignoring ..\synwr.dll (not a directory) ignoring ..\synwr.pdb (not a directory) ignoring ..\table-list.dll (not a directory) ignoring ..\table-list.pdb (not a directory) ignoring ..\tar.exe (not a directory) ignoring ..\TempFiles.dll (not a directory) ignoring ..\TempFiles.pdb (not a directory) ignoring ..\TestPixmap.pdb (not a directory) ignoring ..\UDP.dll (not a directory) ignoring ..\UDP.pdb (not a directory) ignoring ..\uniq.pdb (not a directory) ignoring ..\videovbt.dll (not a directory) ignoring ..\videovbt.pdb (not a directory) ignoring ..\visobliq.exe (not a directory) ignoring ..\visobliq.pdb (not a directory) ignoring ..\vocgi.exe (not a directory) ignoring ..\vocgi.pdb (not a directory) ignoring ..\voquery.exe (not a directory) ignoring ..\voquery.pdb (not a directory) ignoring ..\vorun.exe (not a directory) ignoring ..\vorun.pdb (not a directory) ignoring ..\vostart (not a directory) ignoring ..\vostart.cmd (not a directory) ignoring ..\web.dll (not a directory) ignoring ..\web.pdb (not a directory) ignoring ..\webvbt.dll (not a directory) ignoring ..\webvbt.pdb (not a directory) ignoring ..\windowsResources.dll (not a directory) ignoring ..\windowsResources.pdb (not a directory) ignoring ..\zapNT386.cmd (not a directory) cm3: found nothing to build. rm m3make.args seconds #times operation 0.02 2 garbage collection 0.02 other --------------------------------------------------- 0.04 TOTAL cd .. is_empty (NT386) => rmdir NT386 Regards, Randy -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Wed Jan 23 12:20:02 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 23 Jan 2008 12:20:02 +0100 Subject: [M3devel] platform/build_dir is a big tuple? In-Reply-To: References: <479605CF.1E75.00D7.1@scires.com> Message-ID: <20080123122002.6rcdyji1us4okkww@mail.elegosoft.com> Quoting Henning Thielemann : > > On Tue, 22 Jan 2008, Randy Coleburn wrote: > >> Jay: >> >> For my part on Windows, I am happy to stay with the underlying OS, the >> native windows threading, the integrated backend, and use the free >> Microsoft Visual Studio tools. I don't really want to have to >> install/use cygwin or any of the other variants. When I see target = >> NT386, this list is what I am expecting. For the cm3 newbie coming from >> a Microsoft Windows environment, I think this list would be the most >> appealing and pose the least barrier to getting starting. Yes, I still >> will work on the installer program once I'm satisfied that I have a good >> working cm3 on Windows. > > One year ago I was in the situation to port one of my Modula-3 programs > from Linux to Windows in order to hand it over to a Windows user. As I > never use Windows, I have only a plain Windows installation on my machine > with almost no tools other than cm3. I was glad to be able to run cm3 > immediately and to find all libraries that I needed in binary form without > Cygwin dependencies - otherwise not only I had to install that on my > machine but I also would have to persuade the other Windows guy to install > it as well. Summarized I strongly vote for NT386 being Windows with least > dependencies on other packages. There has never been a question about this. But there are other who prefer something more POSIXish like Cygwin, which is why other targets like NT386GNU (or NT386_CYGWIN or whatever) are 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 wagner at elegosoft.com Wed Jan 23 12:39:37 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 23 Jan 2008 12:39:37 +0100 Subject: [M3devel] new problem on NT386 In-Reply-To: <4796D0BA.1E75.00D7.1@scires.com> References: <4796B970.1E75.00D7.1@scires.com> <4796D0BA.1E75.00D7.1@scires.com> Message-ID: <20080123123937.onc4m6fa4gg8ogg0@mail.elegosoft.com> Quoting Randy Coleburn : > OK, scratch what I said in my prior message about the "cd" not > working. I ran some more tests and I'm not sure anymore. > > Jay, what has changed in the way quake, cm3, and cm3.cfg interact > since v5.2.6? > > What I am seeing is that when Reactor is built using the current > cm3, the output that should be going to the web browser is instead > going to the console log. This is strange. The same exact code > compiled under 5.2.6 works correctly (output goes to browser). > > Also, there are some strange differences in the output and the > results are different. Not only are the results different, they are > wrong under the new system, while they are correct under 5.2.6. > Indeed, the build operation on the new system does not even find the > correct package. > > Reactor is written in Modula-3, but it does use some quake helper > functions. Here are the quake sources that Reactor is using for the > clean and build procedures: > > proc clean_package (pkg) is > exec ("cd", pkg, "| cm3 -verbose -clean") > end > proc build_package (pkg, options) is > exec ("cd", pkg, "| cm3 -verbose", options) > end > As you can see, I've turned on the -verbose cm3 option to make the > differences clear. I don't understand these: | is the pipe symbol even for cmd.exe, isn't it? Shouldn't these commands just read `cd pkg && cm3 -verbose ...'? && should work for /bin/sh as well as for cme.exe, IIRC. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jayk123 at hotmail.com Wed Jan 23 13:37:29 2008 From: jayk123 at hotmail.com (Jay) Date: Wed, 23 Jan 2008 12:37:29 +0000 Subject: [M3devel] new problem on NT386 In-Reply-To: <20080123123937.onc4m6fa4gg8ogg0@mail.elegosoft.com> References: <4796B970.1E75.00D7.1@scires.com> <4796D0BA.1E75.00D7.1@scires.com> <20080123123937.onc4m6fa4gg8ogg0@mail.elegosoft.com> Message-ID: Oops good point Olaf. Yes && works with cmd. If the first command succeeds, the second is run. Succeeds as in exit code is 0. I assume "pkg" contained "enough content to make it work", but if indeed it is a directory, no go. I wasn't really reading the content oops sorry. But yet Randy said it worked with 5.2.6. Randy, you reminded me of a good point though. Upgrade.py plays a new game with config files, one which I like so far, but maybe isn't so great. I don't remember if I updated upgrade.cmd to this new model. In either case, to remove variables, to remove changes, look at your cm3.cfg. Read it a bit. Is it a stub that looks for another config file to include? If so, undo that on your machine. Find the other file, it is cvsroot\m3-sys\cminstall\src\config\nt386, and copy that over \cm3\bin\cm3.cfg, and try again. In either case I'm sure this is not a big deal.... Can you make the code available to me somehow? I do need to get some real work done during the week(s) but the weekend... - Jay > Date: Wed, 23 Jan 2008 12:39:37 +0100> From: wagner at elegosoft.com> To: m3devel at elegosoft.com> Subject: Re: [M3devel] new problem on NT386> > Quoting Randy Coleburn :> > > OK, scratch what I said in my prior message about the "cd" not > > working. I ran some more tests and I'm not sure anymore.> >> > Jay, what has changed in the way quake, cm3, and cm3.cfg interact > > since v5.2.6?> >> > What I am seeing is that when Reactor is built using the current > > cm3, the output that should be going to the web browser is instead > > going to the console log. This is strange. The same exact code > > compiled under 5.2.6 works correctly (output goes to browser).> >> > Also, there are some strange differences in the output and the > > results are different. Not only are the results different, they are > > wrong under the new system, while they are correct under 5.2.6. > > Indeed, the build operation on the new system does not even find the > > correct package.> >> > Reactor is written in Modula-3, but it does use some quake helper > > functions. Here are the quake sources that Reactor is using for the > > clean and build procedures:> >> > proc clean_package (pkg) is> > exec ("cd", pkg, "| cm3 -verbose -clean")> > end> > proc build_package (pkg, options) is> > exec ("cd", pkg, "| cm3 -verbose", options)> > end> > As you can see, I've turned on the -verbose cm3 option to make the > > differences clear.> > I don't understand these: | is the pipe symbol even for cmd.exe, isn't> it?> > Shouldn't these commands just read `cd pkg && cm3 -verbose ...'?> > && should work for /bin/sh as well as for cme.exe, IIRC.> > Olaf> -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194> _________________________________________________________________ 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 Jan 23 13:48:28 2008 From: jayk123 at hotmail.com (Jay) Date: Wed, 23 Jan 2008 12:48:28 +0000 Subject: [M3devel] platform/build_dir is a big tuple? In-Reply-To: <20080123122002.6rcdyji1us4okkww@mail.elegosoft.com> References: <479605CF.1E75.00D7.1@scires.com> <20080123122002.6rcdyji1us4okkww@mail.elegosoft.com> Message-ID: Good point Olaf, thanks for refocusing us. (and here I go again...) The behavior of NT386 is not in question. I churned the underlying code (just the default config file, which "hopefully" nobody has to change at all) and it can/does now share with others, but "nobody should notice anything" that is using NT386 (famous last words..nothing under my sleeve...) NT386GNU's behavior is the question. I made it more like NT386 that some/all folks desire while still using the gcc backend, which is goodness, from a certain point of view, but not everything. Perhaps nobody wants the in between behavior, granted. However if there are people really eager for LONGINT on NT386, then "NT386MINGNU" will be it for now. That's it's critical innovation, perhaps. I was taking too long on the integrated backend changes. I still have stuff sitting around there. And a slower build, with less efficient code without the -O flag but oh well. >> (or NT386_CYGWIN or whatever) I assume that name is out of the question. But if we are still talking about this (!) and still open to such changes, then I like NT386_CYGWIN, NT386_MINGWIN, NT386_MINGNU, I386_CYGWIN, I386_MINGWIN, I386_NT_CYG, I386_NT_?, and simlar with "x86" replacing I386, or maybe I686, maybe drop the "i". I used to use a system that didn't like leading numbers on file names, only latter, but I think that's now always allowed. If we must derive from (and keep) the existing NT386 and NT386GNU names, then NT386MINGNU I like. In any case, my plan remains, for the actual "target" to be NT386. These other names are only file names and have less impact on the system. As well, you know that function over in m3cc\m3makefile and m3gdb\m3makefile? How does that compare with the GNU_PLATFORM defined in the individual config files? Seems redundant, eh? So that reduces slightly this impact. As I said..cm3.exe itself has only a few differences between NT386 and other similar, and adequate bits via "backend mode" and perhaps "os type". cm3 cares about jmpbuf size but it doesn't care about threading library, window library, c library. Maybe hopefully some day it will care about exception handling model but for now, the same across all targets. Really we're talking about 10, maybe 30 lines of diff to push this stuff much further along..depending on how much Cygwin "just works". - Jay > From: wagner at elegosoft.com >> > it as well. Summarized I strongly vote for NT386 being Windows with least> > dependencies on other packages.> > There has never been a question about this. But there are other who> prefer something more POSIXish like Cygwin, which is why other targets> like NT386GNU (or NT386_CYGWIN or whatever) are needed.> > Olaf _________________________________________________________________ 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 Wed Jan 23 13:50:13 2008 From: jayk123 at hotmail.com (Jay) Date: Wed, 23 Jan 2008 12:50:13 +0000 Subject: [M3devel] new problem on NT386 In-Reply-To: References: <4796B970.1E75.00D7.1@scires.com> <4796D0BA.1E75.00D7.1@scires.com> <20080123123937.onc4m6fa4gg8ogg0@mail.elegosoft.com> Message-ID: forgot to answer that, yes. There's good online documentation for cmd viewable from any host. :) - Jay > > I don't understand these: | is the pipe symbol even for cmd.exe, isn't> it?> > Olaf _________________________________________________________________ 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 Jan 23 16:20:47 2008 From: jayk123 at hotmail.com (Jay) Date: Wed, 23 Jan 2008 15:20:47 +0000 Subject: [M3devel] license.. Message-ID: Where must the Critical Mass notice be displayed? See for example cminstall/src/config/NT386*. Did they remove all the individual Digital notices? I'll check later.. I'm not against licensing and all, but I dislike big banners *everywhere*, in every file. One little file per directory I guess ok, still kind of obnoxious. It's not up to me obviously, it's up to the original author. We have it far from the worst, I realize. I have seen some humungous per-file banners. The banners are often the vast majority of the file... (all the more reason to smush files together :) ) - 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 rcoleburn at scires.com Wed Jan 23 18:31:16 2008 From: rcoleburn at scires.com (Randy Coleburn) Date: Wed, 23 Jan 2008 12:31:16 -0500 Subject: [M3devel] new problem on NT386 In-Reply-To: References: <4796B970.1E75.00D7.1@scires.com> <4796D0BA.1E75.00D7.1@scires.com> <20080123123937.onc4m6fa4gg8ogg0@mail.elegosoft.com> Message-ID: <47973393.1E75.00D7.1@scires.com> Jay: Reactor uses quake to invoke procedures that do the build, link, ship, edit, start browser, etc. The user can customize these quake procedures, if needed. The default procedures all cd to the package root. The package should contain a "src" folder and optionally, one or more target folders, e.g. "NT386". So, after cd to the package root, "cm3" is invoked to do the build/clean/ship type work with the package root as the "current dir". A writer is set up to capture the output of the quake calls and the output of this writer is fed back into the browser window so the user can see the progress of the compile/ship/clean/etc. As for "&&" vs. "|", I am not a quake guru, but the pipe symbol has worked in all versions of reactor on all platforms up to this point as a command separator in the built-in quake exec() function call. As for my cm3.cfg, it is the one that came from your MIN distribution that I used to get started, with one exception. There is a place early in the file where INSTALL_ROOT = "c:\\cm3" is commented out. If I run reactor with cm3.cfg this way, it gets a runtime exception "array subscript out of range" in module M3Path.m3 at line 410. So, I un-commented this line and reactor runs without the error, but alas it is having the other aforementioned problems. I have attached the cm3.cfg file that I use in the v5.2.6 tests as cm3.cfg.526 I have attached the cm3.cfg file that I use in the vd5.5.1 tests as cm3.cfg.d551 You should note that Reactor was written by Critical Mass for v4.1 and they had a deep understanding of the system. If the underlying system changes in a way that breaks some deep understanding reliance on the v4.1 architecture, reactor will most likely misbehave. At this point I don't think I am at liberty to give you the source code to look at. My agreement with the Critical Mass license holders is that I had to make certain changes before releasing the code. As for the cm3.cfg at m3-sys\cminstall\src\config\nt386, I took a look at it. It seems to include a NT386.common file. I have not tried this variant yet. If I need to try it, let me know. And, do I have to copy NT386 to cm3\bin as cm3.cfg and then also copy the NT386.common file to cm3\bin? There seems to be a lot of stuff going on under the covers that I don't understand about finding locations for things. I see code in reactor where it tries to locate certain things. It seems the cm3.exe is doing similar stuff. I always thought that the cm3.cfg that was in the INSTALL_ROOT bin folder is the one that rules. Let me know if this is not the case. Regards, Randy >>> Jay 1/23/2008 7:37 AM >>> Oops good point Olaf. Yes && works with cmd. If the first command succeeds, the second is run. Succeeds as in exit code is 0. I assume "pkg" contained "enough content to make it work", but if indeed it is a directory, no go. I wasn't really reading the content oops sorry. But yet Randy said it worked with 5.2.6. Randy, you reminded me of a good point though. Upgrade.py plays a new game with config files, one which I like so far, but maybe isn't so great. I don't remember if I updated upgrade.cmd to this new model. In either case, to remove variables, to remove changes, look at your cm3.cfg. Read it a bit. Is it a stub that looks for another config file to include? If so, undo that on your machine. Find the other file, it is cvsroot\m3-sys\cminstall\src\config\nt386, and copy that over \cm3\bin\cm3.cfg, and try again. In either case I'm sure this is not a big deal.... Can you make the code available to me somehow? I do need to get some real work done during the week(s) but the weekend... - Jay > Date: Wed, 23 Jan 2008 12:39:37 +0100 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] new problem on NT386 > > Quoting Randy Coleburn : > > > OK, scratch what I said in my prior message about the "cd" not > > working. I ran some more tests and I'm not sure anymore. > > > > Jay, what has changed in the way quake, cm3, and cm3.cfg interact > > since v5.2.6? > > > > What I am seeing is that when Reactor is built using the current > > cm3, the output that should be going to the web browser is instead > > going to the console log. This is strange. The same exact code > > compiled under 5.2.6 works correctly (output goes to browser). > > > > Also, there are some strange differences in the output and the > > results are different. Not only are the results different, they are > > wrong under the new system, while they are correct under 5.2.6. > > Indeed, the build operation on the new system does not even find the > > correct package. > > > > Reactor is written in Modula-3, but it does use some quake helper > > functions. Here are the quake sources that Reactor is using for the > > clean and build procedures: > > > > proc clean_package (pkg) is > > exec ("cd", pkg, "| cm3 -verbose -clean") > > end > > proc build_package (pkg, options) is > > exec ("cd", pkg, "| cm3 -verbose", options) > > end > > As you can see, I've turned on the -verbose cm3 option to make the > > differences clear. > > I don't understand these: | is the pipe symbol even for cmd.exe, isn't > it? > > Shouldn't these commands just read `cd pkg && cm3 -verbose ...'? > > && should work for /bin/sh as well as for cme.exe, IIRC. > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > Helping your favorite cause is as easy as instant messaging. You IM, we give. Learn more. ( 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: cm3.cfg.526 Type: application/octet-stream Size: 14465 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: cm3.cfg.d551 Type: application/octet-stream Size: 18873 bytes Desc: not available URL: From wagner at elegosoft.com Wed Jan 23 19:32:16 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 23 Jan 2008 19:32:16 +0100 Subject: [M3devel] new problem on NT386 In-Reply-To: <479734AB.1E75.00D7.1@scires.com> References: <4796B970.1E75.00D7.1@scires.com> <4796D0BA.1E75.00D7.1@scires.com> <20080123123937.onc4m6fa4gg8ogg0@mail.elegosoft.com> <479734AB.1E75.00D7.1@scires.com> Message-ID: <20080123193216.4hun5uus8hwksw88@mail.elegosoft.com> Quoting Randy Coleburn : > Olaf: > > The pipe symbol is used by reactor in the quake exec() calls. I did > not program this; it was done by CMass Inc. My experience has been that > the pipe worked as a command separator in the quake exec() call, even on > the Unix systems. I agree it looks strange, but then, I'm not a quake > expert. Is this documented anywhere? The online doc says exec(...) The arguments are catenated and passed to the operating system to be executed as a child process. The command may start `-' or `@'. These are stripped before the command is passed to the command interpreter. A prefix of `@' indicates that the default action of printing the command to the standard output stream before execution should be overridden. A prefix character of `-' overrides quake's default action of aborting if it detects an error return code after executing the command. I've never seen it, and it seems a really strange choice to me, since it would make it impossible to use pipes within a command. OK, I've found it, but didn't know it ever existed ;-) Here is the diff: % cvs diff -u -r 1.3 -r 1.4 m3-sys/m3quake/src/QMachine.m3 Index: m3-sys/m3quake/src/QMachine.m3 =================================================================== RCS file: /usr/cvs/cm3/m3-sys/m3quake/src/QMachine.m3,v retrieving revision 1.3 retrieving revision 1.4 diff -u -u -r1.3 -r1.4 --- m3-sys/m3quake/src/QMachine.m3 25 Jun 2003 14:36:32 -0000 1.3 +++ m3-sys/m3quake/src/QMachine.m3 16 Oct 2005 13:43:32 -0000 1.4 @@ -1354,7 +1354,6 @@ quake_in : Pipe.T; process_out : Pipe.T; wr : Wr.T := CurWr (t); - wd : TEXT; inbuf : ARRAY [0..255] OF CHAR; BEGIN info.command := ""; @@ -1396,8 +1395,6 @@ Err (t, "write failed" & OSErr (ec)); END; - wd := ExtractInitialDir (info.command); - args [0] := t.sh_option; args [1] := info.command; n_shell_args := 2; @@ -1410,7 +1407,7 @@ (* fire up the subprocess *) handle := Process.Create (t.shell, SUBARRAY (args, 0, n_shell_args), stdin := stdin, stdout := process_out, - stderr := process_out, wd := wd); + stderr := process_out); (* close our copy of the writing end of the output pipe *) process_out.close (); LOOP (* send anything coming through the pipe to the quake output file *) @@ -1439,38 +1436,6 @@ RETURN info; END ExecCommand; -PROCEDURE ExtractInitialDir (VAR cmd: TEXT): TEXT = - (* search for "cd |" or "cd ;" prefix in "cmd". - If it's found, return "" and remove the prefix from "cmd". - Otherwise, return "NIL". *) - VAR - len := Text.Length (cmd); - buf : ARRAY [0..99] OF CHAR; - start, stop: INTEGER; - dir: TEXT; - BEGIN - IF (len < 5) THEN RETURN NIL; END; - Text.SetChars (buf, cmd); - start := 0; - WHILE (start < len) AND (buf[start] = ' ') DO INC (start); END; - IF (start+4 >= len) THEN RETURN NIL; END; - IF (buf[start] # 'c') THEN RETURN NIL; END; - IF (buf[start+1] # 'd') THEN RETURN NIL; END; - IF (buf[start+2] # ' ') THEN RETURN NIL; END; - INC (start, 3); - WHILE (start < len) AND (buf[start] = ' ') DO INC (start); END; - stop := start; - WHILE (stop < len) AND (buf[stop] # ' ') - AND (buf[stop] # '|') AND (buf[stop] # ';') DO INC (stop); END; - IF (stop <= start) THEN RETURN NIL; END; - dir := Text.FromChars (SUBARRAY (buf, start, stop - start)); - WHILE (stop < len) AND (buf[stop] = ' ') DO INC (stop); END; - IF (stop >= len) THEN RETURN NIL; END; - IF (buf[stop] # '|') AND (buf[stop] # ';') THEN RETURN NIL; END; - cmd := Text.Sub (cmd, stop+1); - RETURN dir; - END ExtractInitialDir; - PROCEDURE KillProcess (handle: Process.T) = BEGIN IF (handle # NIL) THEN Obviously it has been remove by rillig (Robert Illig?): revision 1.4 date: 2005-10-16 13:43:32 +0000; author: rillig; state: Exp; lines: +1 -36; Removed the superfluous and error prone ExtractInitialDir procedure, which had tried to parse the shell command, and if it starts with "cd ", changed to that directory itself. So it only looked for cd dir | and then changed the directory accordingly, but it really was an undocumented hack and is not needed. I'd suggest to just use 'cd dir &&' instead. If that doesn't work, please let me know. A grep through the sources for 'cd .*\|' should reveal all occurences. If you need more enhanced execution functions, I can also contribute a module with much better abstractions for running commands. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Jan 23 20:55:21 2008 From: rcoleburn at scires.com (Randy Coleburn) Date: Wed, 23 Jan 2008 14:55:21 -0500 Subject: [M3devel] new problem on NT386 In-Reply-To: <20080123193216.4hun5uus8hwksw88@mail.elegosoft.com> References: <4796B970.1E75.00D7.1@scires.com> <4796D0BA.1E75.00D7.1@scires.com> <20080123123937.onc4m6fa4gg8ogg0@mail.elegosoft.com> <479734AB.1E75.00D7.1@scires.com> <20080123193216.4hun5uus8hwksw88@mail.elegosoft.com> Message-ID: <47975558.1E75.00D7.1@scires.com> Olaf: THANKS! It is obvious that these changes to QMachine are responsible for the problems. It would have taken me forever to find this. Thanks so much! I changed the quake procedures to use "&&" instead of "|" and the build/ship routines seem to work again. Indeed, I even went back and put the comment back in Jay's cm3.cfg and it still works without crashing in M3Path. This is very good! Now, I am not real good at parsing thru these text diff files, but am I seeing there was also a change to QMachine that involves how the output is being redirected? What I am observing in reactor, is that the build/ship/clean/etc output is not being shown in the browser window. Since these functions are being called via a quake procedure, if the QMachine has been altered somehow not to allow this output to be redirected, then reactor is going to have a real problem. The output of these quake routines is showing up in the console log window instead of being redirected back to the browser as it was in 4.1 and 5.2.6. Regards, Randy >>> Olaf Wagner 1/23/2008 1:32 PM >>> Quoting Randy Coleburn : > Olaf: > > The pipe symbol is used by reactor in the quake exec() calls. I did > not program this; it was done by CMass Inc. My experience has been that > the pipe worked as a command separator in the quake exec() call, even on > the Unix systems. I agree it looks strange, but then, I'm not a quake > expert. Is this documented anywhere? The online doc says exec(...) The arguments are catenated and passed to the operating system to be executed as a child process. The command may start `-' or `@'. These are stripped before the command is passed to the command interpreter. A prefix of `@' indicates that the default action of printing the command to the standard output stream before execution should be overridden. A prefix character of `-' overrides quake's default action of aborting if it detects an error return code after executing the command. I've never seen it, and it seems a really strange choice to me, since it would make it impossible to use pipes within a command. OK, I've found it, but didn't know it ever existed ;-) Here is the diff: % cvs diff -u -r 1.3 -r 1.4 m3-sys/m3quake/src/QMachine.m3 Index: m3-sys/m3quake/src/QMachine.m3 =================================================================== RCS file: /usr/cvs/cm3/m3-sys/m3quake/src/QMachine.m3,v retrieving revision 1.3 retrieving revision 1.4 diff -u -u -r1.3 -r1.4 --- m3-sys/m3quake/src/QMachine.m3 25 Jun 2003 14:36:32 -0000 1.3 +++ m3-sys/m3quake/src/QMachine.m3 16 Oct 2005 13:43:32 -0000 1.4 @@ -1354,7 +1354,6 @@ quake_in : Pipe.T; process_out : Pipe.T; wr : Wr.T := CurWr (t); - wd : TEXT; inbuf : ARRAY [0..255] OF CHAR; BEGIN info.command := ""; @@ -1396,8 +1395,6 @@ Err (t, "write failed" & OSErr (ec)); END; - wd := ExtractInitialDir (info.command); - args [0] := t.sh_option; args [1] := info.command; n_shell_args := 2; @@ -1410,7 +1407,7 @@ (* fire up the subprocess *) handle := Process.Create (t.shell, SUBARRAY (args, 0, n_shell_args), stdin := stdin, stdout := process_out, - stderr := process_out, wd := wd); + stderr := process_out); (* close our copy of the writing end of the output pipe *) process_out.close (); LOOP (* send anything coming through the pipe to the quake output file *) @@ -1439,38 +1436,6 @@ RETURN info; END ExecCommand; -PROCEDURE ExtractInitialDir (VAR cmd: TEXT): TEXT = - (* search for "cd |" or "cd ;" prefix in "cmd". - If it's found, return "" and remove the prefix from "cmd". - Otherwise, return "NIL". *) - VAR - len := Text.Length (cmd); - buf : ARRAY [0..99] OF CHAR; - start, stop: INTEGER; - dir: TEXT; - BEGIN - IF (len < 5) THEN RETURN NIL; END; - Text.SetChars (buf, cmd); - start := 0; - WHILE (start < len) AND (buf[start] = ' ') DO INC (start); END; - IF (start+4 >= len) THEN RETURN NIL; END; - IF (buf[start] # 'c') THEN RETURN NIL; END; - IF (buf[start+1] # 'd') THEN RETURN NIL; END; - IF (buf[start+2] # ' ') THEN RETURN NIL; END; - INC (start, 3); - WHILE (start < len) AND (buf[start] = ' ') DO INC (start); END; - stop := start; - WHILE (stop < len) AND (buf[stop] # ' ') - AND (buf[stop] # '|') AND (buf[stop] # ';') DO INC (stop); END; - IF (stop <= start) THEN RETURN NIL; END; - dir := Text.FromChars (SUBARRAY (buf, start, stop - start)); - WHILE (stop < len) AND (buf[stop] = ' ') DO INC (stop); END; - IF (stop >= len) THEN RETURN NIL; END; - IF (buf[stop] # '|') AND (buf[stop] # ';') THEN RETURN NIL; END; - cmd := Text.Sub (cmd, stop+1); - RETURN dir; - END ExtractInitialDir; - PROCEDURE KillProcess (handle: Process.T) = BEGIN IF (handle # NIL) THEN Obviously it has been remove by rillig (Robert Illig?): revision 1.4 date: 2005-10-16 13:43:32 +0000; author: rillig; state: Exp; lines: +1 -36; Removed the superfluous and error prone ExtractInitialDir procedure, which had tried to parse the shell command, and if it starts with "cd ", changed to that directory itself. So it only looked for cd dir | and then changed the directory accordingly, but it really was an undocumented hack and is not needed. I'd suggest to just use 'cd dir &&' instead. If that doesn't work, please let me know. A grep through the sources for 'cd .*\|' should reveal all occurences. If you need more enhanced execution functions, I can also contribute a module with much better abstractions for running commands. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com ( http://www.elegosoft.com/ ) | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Wed Jan 23 21:38:35 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 23 Jan 2008 15:38:35 -0500 Subject: [M3devel] platform/build_dir is a big tuple? In-Reply-To: References: <479605CF.1E75.00D7.1@scires.com> Message-ID: <9402FB12-D4AF-458A-93B8-3A6973D88CFE@cs.purdue.edu> On Jan 23, 2008, at 2:49 AM, Jay wrote: > > If anyone wanted user vtlaram or fiber, this could be > extended. > > It probably always should have been fibers instead of setjmp/ > longjmp where fibers are available... > > Oh, sorry, Modula-3 has never to my knowledge used user/vtalarm > threads. ThreadPosix uses user/vtalarm threads. Swicthing is done using setjmp/longjmp or setcontext/getcontext depending on platform. ON modern POSIX platforms it should always use the latter. > > > If anyone does want to take over their own scheduling and have an > N:M model, fibers are perhaps the way to go, unless you need Win9x. > Fibers take care of creating a stack and swapping register context, > whereas setjmp/longjmp only swap register context and I suspect > Modula-3 uses them in a non-conformant but generally-compatible > way. I haven't looked into this yet. For exceptions, ok. For thread > switching, probably not. > But I'd have to look at how it's implemented.. > > user mode threads, fibers..are problematic. For example Win32 > critical sections can be taken recursively, on the same thread. > Fibers can move around between threads and therefore cannot take > them recursively. > > All in all, as said below, I'm inclined to omit support for user > mode threads on Windows. > I ASSUME the Cygwin pthreads are a thin wrapper over Windows, > except...except there is the condition variables...not sure they > can be layered over thinly... As I said, this is one bit I am > uncertan of. Maybe just always use native Win32 threads. > It would be a perhaps interesting curiosity to see if cygwin > binaries tend to only depend on cygwin .dlls and not win32 .dlls, > as a "proof" of the "completeness" of the layer/wrapping. (though > as to the quality, see below.) Of course, cygwin code can still use > win32..your m3makefile might actually check target==nt386 to know > "the truth". But I doubt anyone would use this flexibility. > > - Jay > > From: jayk123 at hotmail.com > To: lemming at henning-thielemann.de; rcoleburn at scires.com > CC: m3devel at elegosoft.com > Subject: RE: [M3devel] platform/build_dir is a big tuple? > Date: Wed, 23 Jan 2008 07:37:28 +0000 > > Let me cut to the chase, again: > > Everyone will probably be satisfied. > For a very small "everyone". :) > > The underlying implementation shall be "heavily" parameterized. > There shall be three visible pre packaged configurations. > Power users, and clever and crazy people can experiment beyond > those three. > The EXACT three configurations is SLIGHTLY up in the air, but is > likely to be: > > NT386 > same as today, integrated backend, Win32 GUI, msvc*.dll, native > win32 kernel threads, native backslashy paths (and perhaps > increased compat with forward slashes, some of that is already in, > m3core, but not yet cm3), Visual C++ compiler and linker. > > NT386MINGNU > same as today's (recent) NT386GNU, but with Trestle-on-Win32 also > working > external backend, gcc compiler and linker, but otherwise same as > NT386 > One small wrinkle here is there is no m3gdb, but you can use the > m3gdb from the next one, or Cygwin's gdb. > > NT386GNU > As GNU as possible. pthreads (uncertain), X Windows (CygwinX), > Cygwin C library, stupid looking paths that start /cygdrive, wierdo > symlinks that don't interoperate well with the rest of the system > (attempting to run cc.exe crashes ntvdm.exe, for example), "link" > makes file system links (or at least strange files) instead of > linking programs, a slow and perhaps fragile copy-immediately > implementation of fork, problems running one type of program from > another because you don't know which command line parameters and > which environment variables represent paths or lists of paths and > therefore how to translate them, etc. > > The underlying parameters, which are largely independent and which > you can change individually, but which you will actually just > ignore usually, shall be: > > modula-3 backend > integrated 0 > cm3cg 1 > This might be replaced by the existing 0-3 variable. > > C compiler > Visual C++ cl 0 > gcc 1 > In future this could be redefined as decimal digit or a > character to accomodate other choices. > > linker > Visual C++ link 0 > gcc 1 > In future this could be redefined as decimal digit or a > character to accomodate other choices. > > Threading library > Native Win32 kernel threads 0 > Cygwin pthreads which are probably layered on native Win32 > kernel threads 1 > This is the one area where people have suggested using native > Win32 functionality instead of Cygwin > vtalaram user threads probably not available > fiber user threads probably not available > This would have been better than vtalaram, but not Win9x > compatible > If anyone wanted user vtlaram or fiber, this could be > extended. It probably always should have been fibers instead of > setjmp/longjmp where fibers are available... > > Window library > Native Win32 gui 0 (hopefully with bugs to be worked out) > X Windows via CygwinX 1 (hopefully the binaries are X server > agnostic, and even work against a remote Unix machine?) > > C library > native msvcr* through Visual C++ or MinGWin 0 > Cygwin and its path oddities 1 > > The current notion of "OSTYPE" becomes much less useful here, as it > previously embodied multiple factors. > It wasn't all that useful anyway, imho, but as a way to reduce the > matrix of targets down to two, the same two in multiple places. > Now, in a few places, you check a more specific variable. > Theoretically, I don't have to change cm3 here, just the config > file and some m3makefiles. Because, tricky tricky, the main thing > cm3 cares about is the backend "mode", and that does match up above > with the 0/1. There are actually 4 modes and I should maybe hoist > that up to be the variable, very maybe. A few m3makefiles will have > to change, in small ways. > > Therefore, NT386 is all 0s, NT386GNU shall be all 1s, except > maybe threading, and NT386MINGNU shall be a mix -- backend, C > compiler, linker 1, the rest 0. Besides that, what I haven't in my > head yet, is that individual m3makefiles should be able to ask for > one compiler or the other. The base system won't do that, but user > systems could, if they have some code that depends on one compiler > or the other and they are going to link it together. For this > purpose, for exposing these features to users, possibly values > other than "0" and "1" are needed. > > If the configuration is one of these three combinations, build_dir > is translated as shown. > Otherwise, it is "NT386-" plus the unreadable string of 0s and 1s. > > This is essentially already commited. NT386 works this way. > NT386MINGNU works this, but is for now called NT386GNU, and doesn't > have any Trestle yet. The new/old Cygwin NT386GNU isn't active yet, > but easily should be. > > There are three config files, NT386, NT386MINGNU, NT386GNU, they > are all just a few lines and then include NT386.common. > > Oh, one more thing I haven't worked out is how the user asks for > one target or another. > It is probably via the environment variable CM3_TARGET, though in > reality, "TARGET" for all of these shall be NT386. > > Any questions? > Don't ask me when Cygwin NT386GNU will be active or when the names > will flip. I will try it soon. > > This is essentiallyalready in the tree, with a little bit of > "temporary, for compat" sprinkled in to avoid renaming NT386GNU/ > MINGNU just yet, and the Cygwinish stuff not active, no X Windows > on NT386 yet..groundwork is laid, I think I've stopped thinking > through the indecisiveness, I just keep hearing the two extreme > sides, the Windows users who want Windows (do you even care about > the gcc backend? It's slow. It generates inefficient code. It > supports Longint) and a few Unix users who might reluctantly use > Windows a little more if their backend slowed down and their > libraries changed... > > Personally my main goal here is to not feel guilty about not > finishing the LONGINT support yet in the integrated backend. > I'd still like to finish that, but it was taking embarassingly long. > > I'd also like an uber-cross build environment, where I can build > anything from anything. Getting cm3cg working was part of that. I'm > not sure I have the patience to build gcc and ld/binutils that many > times though. > > - Jay > > > > > Date: Wed, 23 Jan 2008 08:06:20 +0100 > > From: lemming at henning-thielemann.de > > Subject: Re: [M3devel] platform/build_dir is a big tuple? > > To: rcoleburn at scires.com > > CC: m3devel at elegosoft.com; jayk123 at hotmail.com > > > > > > On Tue, 22 Jan 2008, Randy Coleburn wrote: > > > > > Jay: > > > > > > For my part on Windows, I am happy to stay with the underlying > OS, the > > > native windows threading, the integrated backend, and use the free > > > Microsoft Visual Studio tools. I don't really want to have to > > > install/use cygwin or any of the other variants. When I see > target = > > > NT386, this list is what I am expecting. For the cm3 newbie > coming from > > > a Microsoft Windows environment, I think this list would be the > most > > > appealing and pose the least barrier to getting starting. Yes, > I still > > > will work on the installer program once I'm satisfied that I > have a good > > > working cm3 on Windows. > > > > One year ago I was in the situation to port one of my Modula-3 > programs > > from Linux to Windows in order to hand it over to a Windows user. > As I > > never use Windows, I have only a plain Windows installation on my > machine > > with almost no tools other than cm3. I was glad to be able to run > cm3 > > immediately and to find all libraries that I needed in binary > form without > > Cygwin dependencies - otherwise not only I had to install that on my > > machine but I also would have to persuade the other Windows guy > to install > > it as well. Summarized I strongly vote for NT386 being Windows > with least > > dependencies on other packages. > > > 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 wagner at elegosoft.com Wed Jan 23 22:10:01 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 23 Jan 2008 22:10:01 +0100 Subject: [M3devel] new problem on NT386 In-Reply-To: <47975558.1E75.00D7.1@scires.com> References: <4796B970.1E75.00D7.1@scires.com> <4796D0BA.1E75.00D7.1@scires.com> <20080123123937.onc4m6fa4gg8ogg0@mail.elegosoft.com> <479734AB.1E75.00D7.1@scires.com> <20080123193216.4hun5uus8hwksw88@mail.elegosoft.com> <47975558.1E75.00D7.1@scires.com> Message-ID: <20080123221001.8pbvhkjdc8408w80@mail.elegosoft.com> Quoting Randy Coleburn : > Olaf: > > THANKS! It is obvious that these changes to QMachine are responsible > for the problems. It would have taken me forever to find this. Thanks > so much! > > I changed the quake procedures to use "&&" instead of "|" and the > build/ship routines seem to work again. Indeed, I even went back and > put the comment back in Jay's cm3.cfg and it still works without > crashing in M3Path. This is very good! > > Now, I am not real good at parsing thru these text diff files, but am I > seeing there was also a change to QMachine that involves how the output > is being redirected? > > What I am observing in reactor, is that the build/ship/clean/etc output > is not being shown in the browser window. Since these functions are > being called via a quake procedure, if the QMachine has been altered > somehow not to allow this output to be redirected, then reactor is going > to have a real problem. The output of these quake routines is showing > up in the console log window instead of being redirected back to the > browser as it was in 4.1 and 5.2.6. Randy, I've added compatibilit procedures that should show the old (queer) behaviour: cm3_exec and try_cm3_exec. The semantics were changed in this commit: revision 1.5 date: 2005-10-17 21:00:36 +0000; author: rillig; state: Exp; lines: +4 -20; Don't pass the stdout and stderr from child processes through quake. This makes the quake code simpler and also allows the user to redirect the stdout and the stderr to different files. Before, the stdout and stderr had been merged by quake and then printed on stdout. I think the main goal of the quake changes was to make CM3 and PM3 compatible; but this now seems to break the old Reactor code. So try if cm3_exec instead of just exec will cure your problem. You'll have to rebuild the m3quake package of course. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Jan 23 22:37:53 2008 From: rcoleburn at scires.com (Randy Coleburn) Date: Wed, 23 Jan 2008 16:37:53 -0500 Subject: [M3devel] new problem on NT386 In-Reply-To: <20080123221001.8pbvhkjdc8408w80@mail.elegosoft.com> References: <4796B970.1E75.00D7.1@scires.com> <4796D0BA.1E75.00D7.1@scires.com> <20080123123937.onc4m6fa4gg8ogg0@mail.elegosoft.com> <479734AB.1E75.00D7.1@scires.com> <20080123193216.4hun5uus8hwksw88@mail.elegosoft.com> <47975558.1E75.00D7.1@scires.com> <20080123221001.8pbvhkjdc8408w80@mail.elegosoft.com> Message-ID: <47976D5F.1E75.00D7.1@scires.com> Olaf: I grabbed the new QMachine via cvs and rebuilt & shipped the m3quake package, then rebuilt reactor (now cm3_ide) to take advantage of it. I replaced the exec calls with cm3_exec(). At first glance, things were working better in that the output is now going back to the browser. Great! But, when I tried to compile a simple "HelloWorld" program, I ran into some errors. See attached PDF file. Does any of this make sense to you? Note that this same HelloWorld program was compiling before the QMachine change, its just that the output went to the wrong window. Regards, Randy >>> Olaf Wagner 1/23/2008 4:10 PM >>> Quoting Randy Coleburn : > Olaf: > > THANKS! It is obvious that these changes to QMachine are responsible > for the problems. It would have taken me forever to find this. Thanks > so much! > > I changed the quake procedures to use "&&" instead of "|" and the > build/ship routines seem to work again. Indeed, I even went back and > put the comment back in Jay's cm3.cfg and it still works without > crashing in M3Path. This is very good! > > Now, I am not real good at parsing thru these text diff files, but am I > seeing there was also a change to QMachine that involves how the output > is being redirected? > > What I am observing in reactor, is that the build/ship/clean/etc output > is not being shown in the browser window. Since these functions are > being called via a quake procedure, if the QMachine has been altered > somehow not to allow this output to be redirected, then reactor is going > to have a real problem. The output of these quake routines is showing > up in the console log window instead of being redirected back to the > browser as it was in 4.1 and 5.2.6. Randy, I've added compatibilit procedures that should show the old (queer) behaviour: cm3_exec and try_cm3_exec. The semantics were changed in this commit: revision 1.5 date: 2005-10-17 21:00:36 +0000; author: rillig; state: Exp; lines: +4 -20; Don't pass the stdout and stderr from child processes through quake. This makes the quake code simpler and also allows the user to redirect the stdout and the stderr to different files. Before, the stdout and stderr had been merged by quake and then printed on stdout. I think the main goal of the quake changes was to make CM3 and PM3 compatible; but this now seems to break the old Reactor code. So try if cm3_exec instead of just exec will cure your problem. You'll have to rebuild the m3quake package of course. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com ( http://www.elegosoft.com/ ) | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: buildHello.pdf Type: application/pdf Size: 30627 bytes Desc: not available URL: From wagner at elegosoft.com Wed Jan 23 23:23:10 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 23 Jan 2008 23:23:10 +0100 Subject: [M3devel] new problem on NT386 In-Reply-To: <47976D5F.1E75.00D7.1@scires.com> References: <4796B970.1E75.00D7.1@scires.com> <4796D0BA.1E75.00D7.1@scires.com> <20080123123937.onc4m6fa4gg8ogg0@mail.elegosoft.com> <479734AB.1E75.00D7.1@scires.com> <20080123193216.4hun5uus8hwksw88@mail.elegosoft.com> <47975558.1E75.00D7.1@scires.com> <20080123221001.8pbvhkjdc8408w80@mail.elegosoft.com> <47976D5F.1E75.00D7.1@scires.com> Message-ID: <20080123232310.5znrlsr5ywwgc4o0@mail.elegosoft.com> Quoting Randy Coleburn : > Olaf: > > I grabbed the new QMachine via cvs and rebuilt & shipped the m3quake > package, then rebuilt reactor (now cm3_ide) to take advantage of it. I > replaced the exec calls with cm3_exec(). > > At first glance, things were working better in that the output is now > going back to the browser. Great! > > But, when I tried to compile a simple "HelloWorld" program, I ran into > some errors. See attached PDF file. Does any of this make sense to > you? > > Note that this same HelloWorld program was compiling before the > QMachine change, its just that the output went to the wrong window. It seems I've made a mistake by forgetting to initialize the std file handles. Please try again, Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Jan 24 00:05:12 2008 From: jayk123 at hotmail.com (Jay) Date: Wed, 23 Jan 2008 23:05:12 +0000 Subject: [M3devel] new problem on NT386 In-Reply-To: <20080123232310.5znrlsr5ywwgc4o0@mail.elegosoft.com> References: <4796B970.1E75.00D7.1@scires.com> <4796D0BA.1E75.00D7.1@scires.com> <20080123123937.onc4m6fa4gg8ogg0@mail.elegosoft.com> <479734AB.1E75.00D7.1@scires.com> <20080123193216.4hun5uus8hwksw88@mail.elegosoft.com> <47975558.1E75.00D7.1@scires.com> <20080123221001.8pbvhkjdc8408w80@mail.elegosoft.com> <47976D5F.1E75.00D7.1@scires.com> <20080123232310.5znrlsr5ywwgc4o0@mail.elegosoft.com> Message-ID: Catching up, just to clearly confirm: | and && have the same meaning in cmd as in sh. | is the pipe, the stdout of the left is the stdin of the right stderr probably is separate, and you should in general imho throw in "2>&1" to avoid hangs that can occur if stderr is used. && is kind of like && in C, boolean and, shortcircuiting. I was unaware of this stuff in Quake. cmd is actually documented online, can read those docs from any host, not just windows, the online docs appear similar to what you can find on a live system. Randy, I ask again, can what you have be made available to anyone to assist with any problems? It seems you have no outstanding problems, so currently moot. Btw, Microsoft nmake handles cd specially as well. Normally each nmake command is a separate process, but a few are "emulated", cd and set. And cd can cross drives, but cd /d does not, which is the opposite of cmd, where cd /d is needed to cross drives, and cd does not.. Later. - Jay > Date: Wed, 23 Jan 2008 23:23:10 +0100> From: wagner at elegosoft.com> To: rcoleburn at scires.com> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] new problem on NT386> > Quoting Randy Coleburn :> > > Olaf:> >> > I grabbed the new QMachine via cvs and rebuilt & shipped the m3quake> > package, then rebuilt reactor (now cm3_ide) to take advantage of it. I> > replaced the exec calls with cm3_exec().> >> > At first glance, things were working better in that the output is now> > going back to the browser. Great!> >> > But, when I tried to compile a simple "HelloWorld" program, I ran into> > some errors. See attached PDF file. Does any of this make sense to> > you?> >> > Note that this same HelloWorld program was compiling before the> > QMachine change, its just that the output went to the wrong window.> > It seems I've made a mistake by forgetting to initialize the std> file handles.> > Please try again,> > Olaf> -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 Thu Jan 24 00:08:20 2008 From: jayk123 at hotmail.com (Jay) Date: Wed, 23 Jan 2008 23:08:20 +0000 Subject: [M3devel] platform/build_dir is a big tuple? In-Reply-To: <9402FB12-D4AF-458A-93B8-3A6973D88CFE@cs.purdue.edu> References: <479605CF.1E75.00D7.1@scires.com> <9402FB12-D4AF-458A-93B8-3A6973D88CFE@cs.purdue.edu> Message-ID: below > From: hosking at cs.purdue.edu> Subject: Re: [M3devel] platform/build_dir is a big tuple?> > On Jan 23, 2008, at 2:49 AM, Jay wrote:> > > Oh, sorry, Modula-3 has never to my knowledge used user/vtalarm > > threads.> > ThreadPosix uses user/vtalarm threads. Swicthing is done using > setjmp/longjmp or setcontext/getcontext depending on platform. ON > modern POSIX platforms it should always use the latter. Oops, I meant on Windows! The use of setjmp/longjmp is not ANSI C conformant, right? I kind of suspect how it'd work without having looked it but I don't have quite in my head. Will look later and know better, just curious, no matter. - 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 Thu Jan 24 00:23:20 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 24 Jan 2008 00:23:20 +0100 Subject: [M3devel] Archive Upload to CM3 WWW Message-ID: <20080124002320.c3lzxz55mso8gs00@mail.elegosoft.com> All those m3-users with ssh access can now upload installation archives they have built to birch.elegosoft.com:/var/www/modula3.elegosoft.com/cm3/uploaded-archives The archives must conform to the standard naming scheme: cm3-{min,std,all,core,base,doc}-{POSIX,WIN32,WIN,WIN64}-*-*.\ {tar.gz,tar.bz,tar.bz2,tgz,tbz,zip} for example cm3-min-WIN32-NT386GNU-d5.5.1.tar.bz2 cm3-min-POSIX-LINUXLIBC6-d5.5.0.tgz You may also add a corresponding description in a file with the same name and added .html or .txt suffix. Please don't copy anything else to this directory; I trust that the service will not be misused. A new index is generated every 5 minutes. You'll find the index under Installation / Uploaded Archives on the CM3 WWW pages. The URL is http://modula3.elegosoft.com/cm3/snaps/snapshot-index.html We can extend the naming scheme if necessary; it's probably a bit limited currently. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Jan 24 01:51:33 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 23 Jan 2008 19:51:33 -0500 Subject: [M3devel] platform/build_dir is a big tuple? In-Reply-To: References: <479605CF.1E75.00D7.1@scires.com> <9402FB12-D4AF-458A-93B8-3A6973D88CFE@cs.purdue.edu> Message-ID: <66444C15-4C87-4444-AECF-A97D79CF461D@cs.purdue.edu> Yes, setjmp/longjmp hacking (changing fields to cause thread switches) breaks on some implementations (Linux) that encrypt the fields to prevent exploits. setcontext/getcontext are the modern POSIX calls that should be used for user-threading on POSIX. On Jan 23, 2008, at 6:08 PM, Jay wrote: > below > > > From: hosking at cs.purdue.edu > > Subject: Re: [M3devel] platform/build_dir is a big tuple? > > > > On Jan 23, 2008, at 2:49 AM, Jay wrote: > > > > > Oh, sorry, Modula-3 has never to my knowledge used user/vtalarm > > > threads. > > > > ThreadPosix uses user/vtalarm threads. Swicthing is done using > > setjmp/longjmp or setcontext/getcontext depending on platform. ON > > modern POSIX platforms it should always use the latter. > > Oops, I meant on Windows! > > The use of setjmp/longjmp is not ANSI C conformant, right? I kind > of suspect how it'd work without having looked it but I don't have > quite in my head. Will look later and know better, just curious, no > matter. > > > - Jay > > Shed those extra pounds with MSN and The Biggest Loser! Learn more. From neels at elego.de Thu Jan 24 14:47:17 2008 From: neels at elego.de (Neels Janosch Hofmeyr) Date: Thu, 24 Jan 2008 14:47:17 +0100 Subject: [M3devel] minimal binary d5.5.0 fails on Ubuntu 7.10 Message-ID: <479896E5.3090106@elego.de> Hello m3-support and m3devel, I tried to bootstrap cm3 on Ubuntu 7.10 using the newer d5.5.0 binaries. Upon running cd scripts ./do-cm3-core.sh buildship I got a series of errors, ending in a segmentation fault. I am now going back to the 5.4.0 minimal binary. For interest, find the error output below. Regards, Neels neels at oubantu:~/cm3-build/scripts $ ./do-cm3-core.sh buildship CM3C = /home/neels/cm3-build/scripts/pkgmap.sh -c "cm3 -build -DROOT='/home/neels/cm3-build' && cm3 -ship -DROOT='/home/neels/cm3-build' " m3gc-simple m3core libm3 patternmatching m3middle m3linker m3front m3quake m3cc cm3 m3scanner m3tools m3cgcat m3cggen m3bundle bitvector digraph parseparams realgeometry set slisp sortedtableextras table-list tempfiles === package /home/neels/cm3-build/m3-libs/m3gc-simple === +++ cm3 -build -DROOT='/home/neels/cm3-build' && cm3 -ship -DROOT='/home/neels/cm3-build' +++ --- building in LINUXLIBC6 --- new source -> compiling sysdeps.c -> archiving libm3gcdefs.a --- shipping from LINUXLIBC6 --- . => /usr/local/cm3/pkg/m3gc-simple/LINUXLIBC6 .M3EXPORTS libm3gcdefs.so.5 libm3gcdefs.a libm3gcdefs.m3x .M3WEB ../src/runtime => /usr/local/cm3/pkg/m3gc-simple/src/runtime RTVM.c ../src/runtime/LINUXLIBC6 => /usr/local/cm3/pkg/m3gc-simple/src/runtime/LINUXLIBC6 sysdeps.c . => /usr/local/cm3/lib libm3gcdefs.a ==> /home/neels/cm3-build/m3-libs/m3gc-simple done === package /home/neels/cm3-build/m3-libs/m3core === +++ cm3 -build -DROOT='/home/neels/cm3-build' && cm3 -ship -DROOT='/home/neels/cm3-build' +++ --- building in LINUXLIBC6 --- ignoring ../src/m3overrides new source -> compiling RTHooks.i3 RTHooks.i3: In function 'RTHooks_I3': RTHooks.i3:141: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling RT0.i3 RT0.i3: In function 'RT0_I3': RT0.i3:230: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling RuntimeError.i3 RuntimeError.i3: In function 'RuntimeError_I3': RuntimeError.i3:63: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling Word.i3 Word.i3: In function 'Word_I3': Word.i3:67: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling RTException.i3 RTException.i3: In function 'RTException_I3': RTException.i3:34: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling RTHooks.m3 RTHooks.m3: In function 'RTHooks_M3': RTHooks.m3:130: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling RT0.m3 RT0.m3:10: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling Compiler.i3 Compiler.i3: In function 'Compiler_I3': Compiler.i3:42: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling RuntimeError.m3 RuntimeError.m3: In function 'RuntimeError_M3': RuntimeError.m3:61: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling Compiler.m3 Compiler.m3: In function 'Compiler_M3': Compiler.m3:11: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling RTAllocator.i3 RTAllocator.i3: In function 'RTAllocator_I3': RTAllocator.i3:79: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling RTType.i3 RTType.i3: In function 'RTType_I3': RTType.i3:65: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling Uucontext.i3 Uucontext.i3: In function 'Uucontext_I3': Uucontext.i3:195: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling Utypes.i3 Utypes.i3: In function 'Utypes_I3': Utypes.i3:108: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling BasicCtypes.i3 BasicCtypes.i3: In function 'BasicCtypes_I3': BasicCtypes.i3:33: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling Ctypes.i3 Ctypes.i3: In function 'Ctypes_I3': Ctypes.i3:67: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling Usignal.i3 Usignal.i3: In function 'Usignal_I3': Usignal.i3:199: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling Csetjmp.i3 Csetjmp.i3: In function 'Csetjmp_I3': Csetjmp.i3:29: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling RTMachine.i3 RTMachine.i3: In function 'RTMachine_I3': RTMachine.i3:87: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling Upthread.i3 Upthread.i3: In function 'Upthread_I3': Upthread.i3:343: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling Utime.i3 Utime.i3: In function 'Utime_I3': Utime.i3:182: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling RTHeapDep.i3 RTHeapDep.i3: In function 'RTHeapDep_I3': RTHeapDep.i3:74: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling RTHeapRep.i3 RTHeapRep.i3: In function 'RTHeapRep_I3': RTHeapRep.i3:310: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling Thread.i3 Thread.i3: In function 'Thread_I3': Thread.i3:120: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling FloatMode.i3 FloatMode.i3: In function 'FloatMode_I3': FloatMode.i3:123: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling ThreadF.i3 ThreadF.i3: In function 'ThreadF_I3': ThreadF.i3:110: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling RTOS.i3 RTOS.i3: In function 'RTOS_I3': RTOS.i3:44: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling RTMisc.i3 RTMisc.i3: In function 'RTMisc_I3': RTMisc.i3:29: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling RTHeap.i3 RTHeap.i3: In function 'RTHeap_I3': RTHeap.i3:44: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling Cstdlib.i3 Cstdlib.i3: In function 'Cstdlib_I3': Cstdlib.i3:34: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling Cstddef.i3 Cstddef.i3: In function 'Cstddef_I3': Cstddef.i3:14: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling RTAllocCnts.i3 RTAllocCnts.i3: In function 'RTAllocCnts_I3': RTAllocCnts.i3:22: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling RTAllocator.m3 RTAllocator.m3: In function 'RTAllocator_M3': RTAllocator.m3:387: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling RTAllocStats.i3 RTAllocStats.i3: In function 'RTAllocStats_I3': RTAllocStats.i3:39: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling Convert.i3 Convert.i3: In function 'Convert_I3': Convert.i3:111: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling TextClass.i3 TextClass.i3: In function 'TextClass_I3': TextClass.i3:46: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling Text.i3 Text.i3: In function 'Text_I3': Text.i3:81: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling RTProcedureSRC.i3 RTProcedureSRC.i3: In function 'RTProcedureSRC_I3': RTProcedureSRC.i3:28: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling Fingerprint.i3 Fingerprint.i3: In function 'Fingerprint_I3': Fingerprint.i3:63: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling RTProcedure.i3 RTProcedure.i3: In function 'RTProcedure_I3': RTProcedure.i3:32: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling RTStack.i3 RTStack.i3: In function 'RTStack_I3': RTStack.i3:53: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling RTAllocStats.m3 "../src/runtime/common/RTAllocStats.m3", line 46: undefined runtime symbol !! (RTHooks.AllocateTracedRef) *** *** runtime error: *** Segmentation violation - possible attempt to dereference NIL *** pc = 0x811e7ff = StartCall + 0x19 in ../src/values/Procedure.m3 *** Aborted (core dumped) *** execution of failed *** -- Neels Janosch Hofmeyr Software Developer neels at elego.de Public Key: http://binarchy.net/neels/neels.hofmeyr.public.key.asc elego Software Solutions GmbH http://www.elegosoft.com Gustav-Meyer-Allee 25, Geb?ude 12 HRB 77719 13355 Berlin, Germany Amtsgericht Charlottenburg Tel.: +49 30 23 45 86 96 Sitz der Gesellschaft: Berlin Fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Olaf Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From mika at async.caltech.edu Thu Jan 24 15:41:50 2008 From: mika at async.caltech.edu (Mika Nystrom) Date: Thu, 24 Jan 2008 06:41:50 -0800 Subject: [M3devel] minimal binary d5.5.0 fails on Ubuntu 7.10 In-Reply-To: Your message of "Thu, 24 Jan 2008 14:47:17 +0100." <479896E5.3090106@elego.de> Message-ID: <200801241441.m0OEfo13084214@camembert.async.caltech.edu> I think this is the broken cm3.cfg . Search for -g in cm3.cfg and replace it with -gstabs+ This thing bites a lot! I think it got me twice to the extent that I had to ask this mailing list. Several other times that it had me scratching my head and then thinking "oh it's that cm3.cfg thing again..." cm3.cfg in general is pretty weird. I know the compiler looks in at least two places for it. (Undocumented behavior.) Mika Neels Janosch Hofmeyr writes: >This is an OpenPGP/MIME signed message (RFC 2440 and 3156) >--------------enigBBB9AF364E0AAD943688858C >Content-Type: text/plain; charset=UTF-8; format=flowed >Content-Transfer-Encoding: quoted-printable > >Hello m3-support and m3devel, > >I tried to bootstrap cm3 on Ubuntu 7.10 using the newer d5.5.0 binaries. = > >Upon running > cd scripts > ./do-cm3-core.sh buildship > >I got a series of errors, ending in a segmentation fault. I am now going = > >back to the 5.4.0 minimal binary. For interest, find the error output bel= >ow. > >Regards, >Neels > > >neels at oubantu:~/cm3-build/scripts >$ ./do-cm3-core.sh buildship >CM3C =3D >/home/neels/cm3-build/scripts/pkgmap.sh -c "cm3 -build =20 >-DROOT=3D'/home/neels/cm3-build' && cm3 -ship=20 >-DROOT=3D'/home/neels/cm3-build' " m3gc-simple m3core libm3=20 >patternmatching m3middle m3linker m3front m3quake m3cc cm3 m3scanner=20 >m3tools m3cgcat m3cggen m3bundle bitvector digraph parseparams=20 >realgeometry set slisp sortedtableextras table-list tempfiles >=3D=3D=3D package /home/neels/cm3-build/m3-libs/m3gc-simple =3D=3D=3D > +++ cm3 -build -DROOT=3D'/home/neels/cm3-build' && cm3 -ship=20 >-DROOT=3D'/home/neels/cm3-build' +++ >--- building in LINUXLIBC6 --- > >new source -> compiling sysdeps.c > -> archiving libm3gcdefs.a >--- shipping from LINUXLIBC6 --- > >=2E =3D> /usr/local/cm3/pkg/m3gc-simple/LINUXLIBC6 > .M3EXPORTS libm3gcdefs.so.5 libm3gcdefs.a libm3gcdefs.m3x > .M3WEB =20 >=2E./src/runtime =3D> /usr/local/cm3/pkg/m3gc-simple/src/runtime > RTVM.c =20 >=2E./src/runtime/LINUXLIBC6 =3D>=20 >/usr/local/cm3/pkg/m3gc-simple/src/runtime/LINUXLIBC6 > sysdeps.c =20 >=2E =3D> /usr/local/cm3/lib > libm3gcdefs.a =20 > =3D=3D> /home/neels/cm3-build/m3-libs/m3gc-simple done > >=3D=3D=3D package /home/neels/cm3-build/m3-libs/m3core =3D=3D=3D > +++ cm3 -build -DROOT=3D'/home/neels/cm3-build' && cm3 -ship=20 >-DROOT=3D'/home/neels/cm3-build' +++ >--- building in LINUXLIBC6 --- > >ignoring ../src/m3overrides > >new source -> compiling RTHooks.i3 >RTHooks.i3: In function 'RTHooks_I3': >RTHooks.i3:141: internal compiler error: Segmentation fault >Please submit a full bug report, >with preprocessed source if appropriate. >See for instructions. >new source -> compiling RT0.i3 >RT0.i3: In function 'RT0_I3': >RT0.i3:230: internal compiler error: Segmentation fault >Please submit a full bug report, >with preprocessed source if appropriate. >See for instructions. >new source -> compiling RuntimeError.i3 >RuntimeError.i3: In function 'RuntimeError_I3': >RuntimeError.i3:63: internal compiler error: Segmentation fault >Please submit a full bug report, >with preprocessed source if appropriate. >See for instructions. >new source -> compiling Word.i3 >Word.i3: In function 'Word_I3': >Word.i3:67: internal compiler error: Segmentation fault >Please submit a full bug report, >with preprocessed source if appropriate. >See for instructions. >new source -> compiling RTException.i3 >RTException.i3: In function 'RTException_I3': >RTException.i3:34: internal compiler error: Segmentation fault >Please submit a full bug report, >with preprocessed source if appropriate. >See for instructions. >new source -> compiling RTHooks.m3 >RTHooks.m3: In function 'RTHooks_M3': >RTHooks.m3:130: internal compiler error: Segmentation fault >Please submit a full bug report, >with preprocessed source if appropriate. >See for instructions. >new source -> compiling RT0.m3 >RT0.m3:10: internal compiler error: Segmentation fault >Please submit a full bug report, >with preprocessed source if appropriate. >See for instructions. >new source -> compiling Compiler.i3 >Compiler.i3: In function 'Compiler_I3': >Compiler.i3:42: internal compiler error: Segmentation fault >Please submit a full bug report, >with preprocessed source if appropriate. >See for instructions. >new source -> compiling RuntimeError.m3 >RuntimeError.m3: In function 'RuntimeError_M3': >RuntimeError.m3:61: internal compiler error: Segmentation fault >Please submit a full bug report, >with preprocessed source if appropriate. >See for instructions. >new source -> compiling Compiler.m3 >Compiler.m3: In function 'Compiler_M3': >Compiler.m3:11: internal compiler error: Segmentation fault >Please submit a full bug report, >with preprocessed source if appropriate. >See for instructions. >new source -> compiling RTAllocator.i3 >RTAllocator.i3: In function 'RTAllocator_I3': >RTAllocator.i3:79: internal compiler error: Segmentation fault >Please submit a full bug report, >with preprocessed source if appropriate. >See for instructions. >new source -> compiling RTType.i3 >RTType.i3: In function 'RTType_I3': >RTType.i3:65: internal compiler error: Segmentation fault >Please submit a full bug report, >with preprocessed source if appropriate. >See for instructions. >new source -> compiling Uucontext.i3 >Uucontext.i3: In function 'Uucontext_I3': >Uucontext.i3:195: internal compiler error: Segmentation fault >Please submit a full bug report, >with preprocessed source if appropriate. >See for instructions. >new source -> compiling Utypes.i3 >Utypes.i3: In function 'Utypes_I3': >Utypes.i3:108: internal compiler error: Segmentation fault >Please submit a full bug report, >with preprocessed source if appropriate. >See for instructions. >new source -> compiling BasicCtypes.i3 >BasicCtypes.i3: In function 'BasicCtypes_I3': >BasicCtypes.i3:33: internal compiler error: Segmentation fault >Please submit a full bug report, >with preprocessed source if appropriate. >See for instructions. >new source -> compiling Ctypes.i3 Ctypes.i3: In function 'Ctypes_I3': >Ctypes.i3:67: internal compiler error: Segmentation fault >Please submit a full bug report, >with preprocessed source if appropriate. >See for instructions. >new source -> compiling Usignal.i3 >Usignal.i3: In function 'Usignal_I3': >Usignal.i3:199: internal compiler error: Segmentation fault >Please submit a full bug report, >with preprocessed source if appropriate. >See for instructions. >new source -> compiling Csetjmp.i3 >Csetjmp.i3: In function 'Csetjmp_I3': >Csetjmp.i3:29: internal compiler error: Segmentation fault >Please submit a full bug report, >with preprocessed source if appropriate. >See for instructions. >new source -> compiling RTMachine.i3 >RTMachine.i3: In function 'RTMachine_I3': >RTMachine.i3:87: internal compiler error: Segmentation fault >Please submit a full bug report, >with preprocessed source if appropriate. >See for instructions. >new source -> compiling Upthread.i3 >Upthread.i3: In function 'Upthread_I3': >Upthread.i3:343: internal compiler error: Segmentation fault >Please submit a full bug report, >with preprocessed source if appropriate. >See for instructions. >new source -> compiling Utime.i3 >Utime.i3: In function 'Utime_I3': >Utime.i3:182: internal compiler error: Segmentation fault >Please submit a full bug report, >with preprocessed source if appropriate. >See for instructions. >new source -> compiling RTHeapDep.i3 >RTHeapDep.i3: In function 'RTHeapDep_I3': >RTHeapDep.i3:74: internal compiler error: Segmentation fault >Please submit a full bug report, >with preprocessed source if appropriate. >See for instructions. >new source -> compiling RTHeapRep.i3 >RTHeapRep.i3: In function 'RTHeapRep_I3': >RTHeapRep.i3:310: internal compiler error: Segmentation fault >Please submit a full bug report, >with preprocessed source if appropriate. >See for instructions. >new source -> compiling Thread.i3 >Thread.i3: In function 'Thread_I3': >Thread.i3:120: internal compiler error: Segmentation fault >Please submit a full bug report, >with preprocessed source if appropriate. >See for instructions. >new source -> compiling FloatMode.i3 >FloatMode.i3: In function 'FloatMode_I3': >FloatMode.i3:123: internal compiler error: Segmentation fault >Please submit a full bug report, >with preprocessed source if appropriate. >See for instructions. >new source -> compiling ThreadF.i3 >ThreadF.i3: In function 'ThreadF_I3': >ThreadF.i3:110: internal compiler error: Segmentation fault >Please submit a full bug report, >with preprocessed source if appropriate. >See for instructions. >new source -> compiling RTOS.i3 >RTOS.i3: In function 'RTOS_I3': >RTOS.i3:44: internal compiler error: Segmentation fault >Please submit a full bug report, >with preprocessed source if appropriate. >See for instructions. >new source -> compiling RTMisc.i3 >RTMisc.i3: In function 'RTMisc_I3': >RTMisc.i3:29: internal compiler error: Segmentation fault >Please submit a full bug report, >with preprocessed source if appropriate. >See for instructions. >new source -> compiling RTHeap.i3 >RTHeap.i3: In function 'RTHeap_I3': >RTHeap.i3:44: internal compiler error: Segmentation fault >Please submit a full bug report, >with preprocessed source if appropriate. >See for instructions. >new source -> compiling Cstdlib.i3 >Cstdlib.i3: In function 'Cstdlib_I3': >Cstdlib.i3:34: internal compiler error: Segmentation fault >Please submit a full bug report, >with preprocessed source if appropriate. >See for instructions. >new source -> compiling Cstddef.i3 >Cstddef.i3: In function 'Cstddef_I3': >Cstddef.i3:14: internal compiler error: Segmentation fault >Please submit a full bug report, >with preprocessed source if appropriate. >See for instructions. >new source -> compiling RTAllocCnts.i3 >RTAllocCnts.i3: In function 'RTAllocCnts_I3': >RTAllocCnts.i3:22: internal compiler error: Segmentation fault >Please submit a full bug report, >with preprocessed source if appropriate. >See for instructions. >new source -> compiling RTAllocator.m3 >RTAllocator.m3: In function 'RTAllocator_M3': >RTAllocator.m3:387: internal compiler error: Segmentation fault >Please submit a full bug report, >with preprocessed source if appropriate. >See for instructions. >new source -> compiling RTAllocStats.i3 >RTAllocStats.i3: In function 'RTAllocStats_I3': >RTAllocStats.i3:39: internal compiler error: Segmentation fault >Please submit a full bug report, >with preprocessed source if appropriate. >See for instructions. >new source -> compiling Convert.i3 >Convert.i3: In function 'Convert_I3': >Convert.i3:111: internal compiler error: Segmentation fault >Please submit a full bug report, >with preprocessed source if appropriate. >See for instructions. >new source -> compiling TextClass.i3 >TextClass.i3: In function 'TextClass_I3': >TextClass.i3:46: internal compiler error: Segmentation fault >Please submit a full bug report, >with preprocessed source if appropriate. >See for instructions. >new source -> compiling Text.i3 >Text.i3: In function 'Text_I3': >Text.i3:81: internal compiler error: Segmentation fault >Please submit a full bug report, >with preprocessed source if appropriate. >See for instructions. >new source -> compiling RTProcedureSRC.i3 >RTProcedureSRC.i3: In function 'RTProcedureSRC_I3': >RTProcedureSRC.i3:28: internal compiler error: Segmentation fault >Please submit a full bug report, >with preprocessed source if appropriate. >See for instructions. >new source -> compiling Fingerprint.i3 >Fingerprint.i3: In function 'Fingerprint_I3': >Fingerprint.i3:63: internal compiler error: Segmentation fault >Please submit a full bug report, >with preprocessed source if appropriate. >See for instructions. >new source -> compiling RTProcedure.i3 >RTProcedure.i3: In function 'RTProcedure_I3': >RTProcedure.i3:32: internal compiler error: Segmentation fault >Please submit a full bug report, >with preprocessed source if appropriate. >See for instructions. >new source -> compiling RTStack.i3 >RTStack.i3: In function 'RTStack_I3': >RTStack.i3:53: internal compiler error: Segmentation fault >Please submit a full bug report, >with preprocessed source if appropriate. >See for instructions. >new source -> compiling RTAllocStats.m3 >"../src/runtime/common/RTAllocStats.m3", line 46: undefined runtime=20 >symbol !! (RTHooks.AllocateTracedRef) > > >*** >*** runtime error: >*** Segmentation violation - possible attempt to dereference NIL >*** pc =3D 0x811e7ff =3D StartCall + 0x19 in ../src/values/Procedure.m= >3 >*** > >Aborted (core dumped) > *** execution of failed *** > > >--=20 >Neels Janosch Hofmeyr >Software Developer > >neels at elego.de >Public Key: http://binarchy.net/neels/neels.hofmeyr.public.key.asc > >elego Software Solutions GmbH http://www.elegosoft.com >Gustav-Meyer-Allee 25, Geb=C3=A4ude 12 HRB 77719 >13355 Berlin, Germany Amtsgericht Charlottenburg >Tel.: +49 30 23 45 86 96 Sitz der Gesellschaft: Berlin >Fax: +49 30 23 45 86 95 Gesch=C3=A4ftsf=C3=BChrer: Olaf W= >agner > > > >--------------enigBBB9AF364E0AAD943688858C >Content-Type: application/pgp-signature; name="signature.asc" >Content-Description: OpenPGP digital signature >Content-Disposition: attachment; filename="signature.asc" > >-----BEGIN PGP SIGNATURE----- >Version: GnuPG v1.4.6 (GNU/Linux) > >iD8DBQFHmJbkRpHEG7B8Y+ARAtjGAJ47SAvF3xSFUuQT0gd5ZF2OLbOX9wCg12+B >bD8Jx13qOgK+5OasBdztrYg= >=IPcA >-----END PGP SIGNATURE----- > >--------------enigBBB9AF364E0AAD943688858C-- From hendrik at topoi.pooq.com Thu Jan 24 15:44:36 2008 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Thu, 24 Jan 2008 09:44:36 -0500 Subject: [M3devel] license.. In-Reply-To: References: Message-ID: <20080124144436.GC18598@topoi.pooq.com> On Wed, Jan 23, 2008 at 03:20:47PM +0000, Jay wrote: > > I'm not against licensing and all, but I dislike big banners *everywhere*, in every file. > One little file per directory I guess ok, still kind of obnoxious. > It's not up to me obviously, it's up to the original author. > We have it far from the worst, I realize. I have seen some humungous per-file banners. > The banners are often the vast majority of the file... > (all the more reason to smush files together :) ) One of the things I hate about Eiffel is that every class has to be in its own file. Java is almost as bad. It doesn't formally have this restriction, but except for a few very local classes, you pretty well have to follow it anyway. I really like the way you can put multiple classes into one file in Modula 3. Now if I could only have modules within modules too, or at least multiple modules per file, I'd be happy. The way you want break a program up into files -- or don't -- depends on pragmatics, such as the tools you are comfortable with in the operating environment, and not on the way you want to express your program in your programming language. I'm in favour of a greater disconnect between syntactic struture and division into files. Huge copyright banners are an excellent example of how pragmatics affect programming. -- hendrik From wagner at elegosoft.com Thu Jan 24 16:34:03 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 24 Jan 2008 16:34:03 +0100 Subject: [M3devel] minimal binary d5.5.0 fails on Ubuntu 7.10 In-Reply-To: <200801241441.m0OEfo13084214@camembert.async.caltech.edu> References: <200801241441.m0OEfo13084214@camembert.async.caltech.edu> Message-ID: <20080124163403.d91ldw5m8s84gw88@mail.elegosoft.com> Quoting Mika Nystrom : > > I think this is the broken cm3.cfg . > > Search for -g in cm3.cfg and replace it with -gstabs+ > > This thing bites a lot! I think it got me twice to the extent that > I had to ask this mailing list. Several other times that it had > me scratching my head and then thinking "oh it's that cm3.cfg thing > again..." The problem here is that dwarf debugging format which was in wide use seems to be discontinued and now produces segmentation faults if used with gcc or at least cm3cg :-/ Perhaps it's just nor correctly supported in the CM3 gcc backend. There's another possibility for `wrong' update: it does not suffice to run do-cm3-core.sh, you probably need to perform a full upgrade with scripts/upgrade.sh. > cm3.cfg in general is pretty weird. I know the compiler looks > in at least two places for it. (Undocumented behavior.) The compiler looks o based on an environment variable ((C)M3CONFIG?) o in the current directory o in the directory where the cm3 binary resides IIRC. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From lemming at henning-thielemann.de Thu Jan 24 16:39:57 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Thu, 24 Jan 2008 16:39:57 +0100 (MET) Subject: [M3devel] license.. In-Reply-To: <20080124144436.GC18598@topoi.pooq.com> References: <20080124144436.GC18598@topoi.pooq.com> Message-ID: On Thu, 24 Jan 2008 hendrik at topoi.pooq.com wrote: > On Wed, Jan 23, 2008 at 03:20:47PM +0000, Jay wrote: > > > > I'm not against licensing and all, but I dislike big banners *everywhere*, in every file. > > One little file per directory I guess ok, still kind of obnoxious. > > It's not up to me obviously, it's up to the original author. > > We have it far from the worst, I realize. I have seen some humungous per-file banners. > > The banners are often the vast majority of the file... > > (all the more reason to smush files together :) ) > > One of the things I hate about Eiffel is that every class has to be in > its own file. > > Java is almost as bad. It doesn't formally have this restriction, but > except for a few very local classes, you pretty well have to follow it > anyway. > > I really like the way you can put multiple classes into one file in > Modula 3. But you should not do so, because qualification gives more natural names if the module name reflects the name of its main type. In anticipation of generic modules it is also a good idea to call the main type T. I found it good style, also in other programming languages, to setup one module per (important) data type. Sooner or later there are enough functions in the module to justify this separate unit. From mika at async.caltech.edu Thu Jan 24 16:58:21 2008 From: mika at async.caltech.edu (Mika Nystrom) Date: Thu, 24 Jan 2008 07:58:21 -0800 Subject: [M3devel] license.. In-Reply-To: Your message of "Thu, 24 Jan 2008 16:39:57 +0100." Message-ID: <200801241558.m0OFwLIG086411@camembert.async.caltech.edu> Henning Thielemann writes: > >On Thu, 24 Jan 2008 hendrik at topoi.pooq.com wrote: > >> On Wed, Jan 23, 2008 at 03:20:47PM +0000, Jay wrote: >> > >> > I'm not against licensing and all, but I dislike big banners *everywhere*, in every file. >> > One little file per directory I guess ok, still kind of obnoxious. >> > It's not up to me obviously, it's up to the original author. >> > We have it far from the worst, I realize. I have seen some humungous per-file banners. >> > The banners are often the vast majority of the file... >> > (all the more reason to smush files together :) ) >> >> One of the things I hate about Eiffel is that every class has to be in >> its own file. >> >> Java is almost as bad. It doesn't formally have this restriction, but >> except for a few very local classes, you pretty well have to follow it >> anyway. >> >> I really like the way you can put multiple classes into one file in >> Modula 3. > >But you should not do so, because qualification gives more natural names >if the module name reflects the name of its main type. In anticipation of >generic modules it is also a good idea to call the main type T. I found it >good style, also in other programming languages, to setup one module per >(important) data type. Sooner or later there are enough functions in the >module to justify this separate unit. It would be Really Nice to be able to instantiate more than one generic in a single file, I think.... (As it is, using lots of generics in M3 involves writing lots of Quake code.) Mika P.S. I do not believe the language specification makes any reference whatever to the concent of source "files". There is no reason you couldn't have a single file containing: INTERFACE A; TYPE T = RECORD x : SomeType END; END A. INTERFACE B; IMPORT A; TYPE T = A.T; END B. (Two modules in one file.) The stylistic matter of whether to declare more than one type in an interface is a separate issue, I think. From jayk123 at hotmail.com Thu Jan 24 17:06:46 2008 From: jayk123 at hotmail.com (Jay) Date: Thu, 24 Jan 2008 16:06:46 +0000 Subject: [M3devel] license.. In-Reply-To: References: <20080124144436.GC18598@topoi.pooq.com> Message-ID: oh boy.. I'm slightly on the fence here but tend toward the fewer files answer.The open question to me is, is programming more type based or module based? If your modules all have one primary type, then I claim it is really type based masquerading as module based. Lately in C I have: typedef struct Foo_t { .. } Foo_t; typedef struct Bar_t { .. } Bar_t; Bar_DoSomething(Bar_t* ...) { } Foo_DoSomething(Foo_t* ...) { } My code is all about types and not so much about "modules" or "facilities" or "subsystems". The types may be groupable into much, but it seems a secondary thing. I'm thinking of inventing a new programming language called Typo-3. :) - Jay > Date: Thu, 24 Jan 2008 16:39:57 +0100> From: lemming at henning-thielemann.de> To: hendrik at topoi.pooq.com> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] license..> > > On Thu, 24 Jan 2008 hendrik at topoi.pooq.com wrote:> > > On Wed, Jan 23, 2008 at 03:20:47PM +0000, Jay wrote:> > >> > > I'm not against licensing and all, but I dislike big banners *everywhere*, in every file.> > > One little file per directory I guess ok, still kind of obnoxious.> > > It's not up to me obviously, it's up to the original author.> > > We have it far from the worst, I realize. I have seen some humungous per-file banners.> > > The banners are often the vast majority of the file...> > > (all the more reason to smush files together :) )> >> > One of the things I hate about Eiffel is that every class has to be in> > its own file.> >> > Java is almost as bad. It doesn't formally have this restriction, but> > except for a few very local classes, you pretty well have to follow it> > anyway.> >> > I really like the way you can put multiple classes into one file in> > Modula 3.> > But you should not do so, because qualification gives more natural names> if the module name reflects the name of its main type. In anticipation of> generic modules it is also a good idea to call the main type T. I found it> good style, also in other programming languages, to setup one module per> (important) data type. Sooner or later there are enough functions in the> module to justify this separate unit.> _________________________________________________________________ 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 Jan 24 19:30:08 2008 From: jayk123 at hotmail.com (Jay) Date: Thu, 24 Jan 2008 18:30:08 +0000 Subject: [M3devel] minimal binary d5.5.0 fails on Ubuntu 7.10 In-Reply-To: <200801241441.m0OEfo13084214@camembert.async.caltech.edu> References: Your message of "Thu, 24 Jan 2008 14:47:17 +0100." <479896E5.3090106@elego.de> <200801241441.m0OEfo13084214@camembert.async.caltech.edu> Message-ID: I thought Dwarf, or Dwarf2 was the preferred format. Weird all around. On "NT386GNU", as I recall, -ggdb crashes, -g is equiv to -stabs+, which is a little more info than -gstabs. I have to check again to see if there are types. I assume we can't submit bug reports due to having a custom front end unless you can repro with C/C++/Ada/Java. Right I saw the probing for cm3.cfg in the code and was surprised, I only knew the place it was actually present. - Jay > To: neels at elego.de> Date: Thu, 24 Jan 2008 06:41:50 -0800> From: mika at async.caltech.edu> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] minimal binary d5.5.0 fails on Ubuntu 7.10> > > I think this is the broken cm3.cfg .> > Search for -g in cm3.cfg and replace it with -gstabs+> > This thing bites a lot! I think it got me twice to the extent that> I had to ask this mailing list. Several other times that it had> me scratching my head and then thinking "oh it's that cm3.cfg thing> again..."> > cm3.cfg in general is pretty weird. I know the compiler looks> in at least two places for it. (Undocumented behavior.)> > Mika> > Neels Janosch Hofmeyr writes:> >This is an OpenPGP/MIME signed message (RFC 2440 and 3156)> >--------------enigBBB9AF364E0AAD943688858C> >Content-Type: text/plain; charset=UTF-8; format=flowed> >Content-Transfer-Encoding: quoted-printable> >> >Hello m3-support and m3devel,> >> >I tried to bootstrap cm3 on Ubuntu 7.10 using the newer d5.5.0 binaries. => >> >Upon running> > cd scripts> > ./do-cm3-core.sh buildship> >> >I got a series of errors, ending in a segmentation fault. I am now going => >> >back to the 5.4.0 minimal binary. For interest, find the error output bel=> >ow.> >> >Regards,> >Neels> >> >> >neels at oubantu:~/cm3-build/scripts> >$ ./do-cm3-core.sh buildship> >CM3C =3D> >/home/neels/cm3-build/scripts/pkgmap.sh -c "cm3 -build =20> >-DROOT=3D'/home/neels/cm3-build' && cm3 -ship=20> >-DROOT=3D'/home/neels/cm3-build' " m3gc-simple m3core libm3=20> >patternmatching m3middle m3linker m3front m3quake m3cc cm3 m3scanner=20> >m3tools m3cgcat m3cggen m3bundle bitvector digraph parseparams=20> >realgeometry set slisp sortedtableextras table-list tempfiles> >=3D=3D=3D package /home/neels/cm3-build/m3-libs/m3gc-simple =3D=3D=3D> > +++ cm3 -build -DROOT=3D'/home/neels/cm3-build' && cm3 -ship=20> >-DROOT=3D'/home/neels/cm3-build' +++> >--- building in LINUXLIBC6 ---> >> >new source -> compiling sysdeps.c> > -> archiving libm3gcdefs.a> >--- shipping from LINUXLIBC6 ---> >> >=2E =3D> /usr/local/cm3/pkg/m3gc-simple/LINUXLIBC6> > .M3EXPORTS libm3gcdefs.so.5 libm3gcdefs.a libm3gcdefs.m3x> > .M3WEB =20> >=2E./src/runtime =3D> /usr/local/cm3/pkg/m3gc-simple/src/runtime> > RTVM.c =20> >=2E./src/runtime/LINUXLIBC6 =3D>=20> >/usr/local/cm3/pkg/m3gc-simple/src/runtime/LINUXLIBC6> > sysdeps.c =20> >=2E =3D> /usr/local/cm3/lib> > libm3gcdefs.a =20> > =3D=3D> /home/neels/cm3-build/m3-libs/m3gc-simple done> >> >=3D=3D=3D package /home/neels/cm3-build/m3-libs/m3core =3D=3D=3D> > +++ cm3 -build -DROOT=3D'/home/neels/cm3-build' && cm3 -ship=20> >-DROOT=3D'/home/neels/cm3-build' +++> >--- building in LINUXLIBC6 ---> >> >ignoring ../src/m3overrides> >> >new source -> compiling RTHooks.i3> >RTHooks.i3: In function 'RTHooks_I3':> >RTHooks.i3:141: internal compiler error: Segmentation fault> >Please submit a full bug report,> >with preprocessed source if appropriate.> >See for instructions.> >new source -> compiling RT0.i3> >RT0.i3: In function 'RT0_I3':> >RT0.i3:230: internal compiler error: Segmentation fault> >Please submit a full bug report,> >with preprocessed source if appropriate.> >See for instructions.> >new source -> compiling RuntimeError.i3> >RuntimeError.i3: In function 'RuntimeError_I3':> >RuntimeError.i3:63: internal compiler error: Segmentation fault> >Please submit a full bug report,> >with preprocessed source if appropriate.> >See for instructions.> >new source -> compiling Word.i3> >Word.i3: In function 'Word_I3':> >Word.i3:67: internal compiler error: Segmentation fault> >Please submit a full bug report,> >with preprocessed source if appropriate.> >See for instructions.> >new source -> compiling RTException.i3> >RTException.i3: In function 'RTException_I3':> >RTException.i3:34: internal compiler error: Segmentation fault> >Please submit a full bug report,> >with preprocessed source if appropriate.> >See for instructions.> >new source -> compiling RTHooks.m3> >RTHooks.m3: In function 'RTHooks_M3':> >RTHooks.m3:130: internal compiler error: Segmentation fault> >Please submit a full bug report,> >with preprocessed source if appropriate.> >See for instructions.> >new source -> compiling RT0.m3> >RT0.m3:10: internal compiler error: Segmentation fault> >Please submit a full bug report,> >with preprocessed source if appropriate.> >See for instructions.> >new source -> compiling Compiler.i3> >Compiler.i3: In function 'Compiler_I3':> >Compiler.i3:42: internal compiler error: Segmentation fault> >Please submit a full bug report,> >with preprocessed source if appropriate.> >See for instructions.> >new source -> compiling RuntimeError.m3> >RuntimeError.m3: In function 'RuntimeError_M3':> >RuntimeError.m3:61: internal compiler error: Segmentation fault> >Please submit a full bug report,> >with preprocessed source if appropriate.> >See for instructions.> >new source -> compiling Compiler.m3> >Compiler.m3: In function 'Compiler_M3':> >Compiler.m3:11: internal compiler error: Segmentation fault> >Please submit a full bug report,> >with preprocessed source if appropriate.> >See for instructions.> >new source -> compiling RTAllocator.i3> >RTAllocator.i3: In function 'RTAllocator_I3':> >RTAllocator.i3:79: internal compiler error: Segmentation fault> >Please submit a full bug report,> >with preprocessed source if appropriate.> >See for instructions.> >new source -> compiling RTType.i3> >RTType.i3: In function 'RTType_I3':> >RTType.i3:65: internal compiler error: Segmentation fault> >Please submit a full bug report,> >with preprocessed source if appropriate.> >See for instructions.> >new source -> compiling Uucontext.i3> >Uucontext.i3: In function 'Uucontext_I3':> >Uucontext.i3:195: internal compiler error: Segmentation fault> >Please submit a full bug report,> >with preprocessed source if appropriate.> >See for instructions.> >new source -> compiling Utypes.i3> >Utypes.i3: In function 'Utypes_I3':> >Utypes.i3:108: internal compiler error: Segmentation fault> >Please submit a full bug report,> >with preprocessed source if appropriate.> >See for instructions.> >new source -> compiling BasicCtypes.i3> >BasicCtypes.i3: In function 'BasicCtypes_I3':> >BasicCtypes.i3:33: internal compiler error: Segmentation fault> >Please submit a full bug report,> >with preprocessed source if appropriate.> >See for instructions.> >new source -> compiling Ctypes.i3> Ctypes.i3: In function 'Ctypes_I3':> >Ctypes.i3:67: internal compiler error: Segmentation fault> >Please submit a full bug report,> >with preprocessed source if appropriate.> >See for instructions.> >new source -> compiling Usignal.i3> >Usignal.i3: In function 'Usignal_I3':> >Usignal.i3:199: internal compiler error: Segmentation fault> >Please submit a full bug report,> >with preprocessed source if appropriate.> >See for instructions.> >new source -> compiling Csetjmp.i3> >Csetjmp.i3: In function 'Csetjmp_I3':> >Csetjmp.i3:29: internal compiler error: Segmentation fault> >Please submit a full bug report,> >with preprocessed source if appropriate.> >See for instructions.> >new source -> compiling RTMachine.i3> >RTMachine.i3: In function 'RTMachine_I3':> >RTMachine.i3:87: internal compiler error: Segmentation fault> >Please submit a full bug report,> >with preprocessed source if appropriate.> >See for instructions.> >new source -> compiling Upthread.i3> >Upthread.i3: In function 'Upthread_I3':> >Upthread.i3:343: internal compiler error: Segmentation fault> >Please submit a full bug report,> >with preprocessed source if appropriate.> >See for instructions.> >new source -> compiling Utime.i3> >Utime.i3: In function 'Utime_I3':> >Utime.i3:182: internal compiler error: Segmentation fault> >Please submit a full bug report,> >with preprocessed source if appropriate.> >See for instructions.> >new source -> compiling RTHeapDep.i3> >RTHeapDep.i3: In function 'RTHeapDep_I3':> >RTHeapDep.i3:74: internal compiler error: Segmentation fault> >Please submit a full bug report,> >with preprocessed source if appropriate.> >See for instructions.> >new source -> compiling RTHeapRep.i3> >RTHeapRep.i3: In function 'RTHeapRep_I3':> >RTHeapRep.i3:310: internal compiler error: Segmentation fault> >Please submit a full bug report,> >with preprocessed source if appropriate.> >See for instructions.> >new source -> compiling Thread.i3> >Thread.i3: In function 'Thread_I3':> >Thread.i3:120: internal compiler error: Segmentation fault> >Please submit a full bug report,> >with preprocessed source if appropriate.> >See for instructions.> >new source -> compiling FloatMode.i3> >FloatMode.i3: In function 'FloatMode_I3':> >FloatMode.i3:123: internal compiler error: Segmentation fault> >Please submit a full bug report,> >with preprocessed source if appropriate.> >See for instructions.> >new source -> compiling ThreadF.i3> >ThreadF.i3: In function 'ThreadF_I3':> >ThreadF.i3:110: internal compiler error: Segmentation fault> >Please submit a full bug report,> >with preprocessed source if appropriate.> >See for instructions.> >new source -> compiling RTOS.i3> >RTOS.i3: In function 'RTOS_I3':> >RTOS.i3:44: internal compiler error: Segmentation fault> >Please submit a full bug report,> >with preprocessed source if appropriate.> >See for instructions.> >new source -> compiling RTMisc.i3> >RTMisc.i3: In function 'RTMisc_I3':> >RTMisc.i3:29: internal compiler error: Segmentation fault> >Please submit a full bug report,> >with preprocessed source if appropriate.> >See for instructions.> >new source -> compiling RTHeap.i3> >RTHeap.i3: In function 'RTHeap_I3':> >RTHeap.i3:44: internal compiler error: Segmentation fault> >Please submit a full bug report,> >with preprocessed source if appropriate.> >See for instructions.> >new source -> compiling Cstdlib.i3> >Cstdlib.i3: In function 'Cstdlib_I3':> >Cstdlib.i3:34: internal compiler error: Segmentation fault> >Please submit a full bug report,> >with preprocessed source if appropriate.> >See for instructions.> >new source -> compiling Cstddef.i3> >Cstddef.i3: In function 'Cstddef_I3':> >Cstddef.i3:14: internal compiler error: Segmentation fault> >Please submit a full bug report,> >with preprocessed source if appropriate.> >See for instructions.> >new source -> compiling RTAllocCnts.i3> >RTAllocCnts.i3: In function 'RTAllocCnts_I3':> >RTAllocCnts.i3:22: internal compiler error: Segmentation fault> >Please submit a full bug report,> >with preprocessed source if appropriate.> >See for instructions.> >new source -> compiling RTAllocator.m3> >RTAllocator.m3: In function 'RTAllocator_M3':> >RTAllocator.m3:387: internal compiler error: Segmentation fault> >Please submit a full bug report,> >with preprocessed source if appropriate.> >See for instructions.> >new source -> compiling RTAllocStats.i3> >RTAllocStats.i3: In function 'RTAllocStats_I3':> >RTAllocStats.i3:39: internal compiler error: Segmentation fault> >Please submit a full bug report,> >with preprocessed source if appropriate.> >See for instructions.> >new source -> compiling Convert.i3> >Convert.i3: In function 'Convert_I3':> >Convert.i3:111: internal compiler error: Segmentation fault> >Please submit a full bug report,> >with preprocessed source if appropriate.> >See for instructions.> >new source -> compiling TextClass.i3> >TextClass.i3: In function 'TextClass_I3':> >TextClass.i3:46: internal compiler error: Segmentation fault> >Please submit a full bug report,> >with preprocessed source if appropriate.> >See for instructions.> >new source -> compiling Text.i3> >Text.i3: In function 'Text_I3':> >Text.i3:81: internal compiler error: Segmentation fault> >Please submit a full bug report,> >with preprocessed source if appropriate.> >See for instructions.> >new source -> compiling RTProcedureSRC.i3> >RTProcedureSRC.i3: In function 'RTProcedureSRC_I3':> >RTProcedureSRC.i3:28: internal compiler error: Segmentation fault> >Please submit a full bug report,> >with preprocessed source if appropriate.> >See for instructions.> >new source -> compiling Fingerprint.i3> >Fingerprint.i3: In function 'Fingerprint_I3':> >Fingerprint.i3:63: internal compiler error: Segmentation fault> >Please submit a full bug report,> >with preprocessed source if appropriate.> >See for instructions.> >new source -> compiling RTProcedure.i3> >RTProcedure.i3: In function 'RTProcedure_I3':> >RTProcedure.i3:32: internal compiler error: Segmentation fault> >Please submit a full bug report,> >with preprocessed source if appropriate.> >See for instructions.> >new source -> compiling RTStack.i3> >RTStack.i3: In function 'RTStack_I3':> >RTStack.i3:53: internal compiler error: Segmentation fault> >Please submit a full bug report,> >with preprocessed source if appropriate.> >See for instructions.> >new source -> compiling RTAllocStats.m3> >"../src/runtime/common/RTAllocStats.m3", line 46: undefined runtime=20> >symbol !! (RTHooks.AllocateTracedRef)> >> >> >***> >*** runtime error:> >*** Segmentation violation - possible attempt to dereference NIL> >*** pc =3D 0x811e7ff =3D StartCall + 0x19 in ../src/values/Procedure.m=> >3> >***> >> >Aborted (core dumped)> > *** execution of failed ***> >> >> >--=20> >Neels Janosch Hofmeyr> >Software Developer> >> >neels at elego.de> >Public Key: http://binarchy.net/neels/neels.hofmeyr.public.key.asc> >> >elego Software Solutions GmbH http://www.elegosoft.com> >Gustav-Meyer-Allee 25, Geb=C3=A4ude 12 HRB 77719> >13355 Berlin, Germany Amtsgericht Charlottenburg> >Tel.: +49 30 23 45 86 96 Sitz der Gesellschaft: Berlin> >Fax: +49 30 23 45 86 95 Gesch=C3=A4ftsf=C3=BChrer: Olaf W=> >agner> >> >> >> >--------------enigBBB9AF364E0AAD943688858C> >Content-Type: application/pgp-signature; name="signature.asc"> >Content-Description: OpenPGP digital signature> >Content-Disposition: attachment; filename="signature.asc"> >> >-----BEGIN PGP SIGNATURE-----> >Version: GnuPG v1.4.6 (GNU/Linux)> >> >iD8DBQFHmJbkRpHEG7B8Y+ARAtjGAJ47SAvF3xSFUuQT0gd5ZF2OLbOX9wCg12+B> >bD8Jx13qOgK+5OasBdztrYg=> >=IPcA> >-----END PGP SIGNATURE-----> >> >--------------enigBBB9AF364E0AAD943688858C-- _________________________________________________________________ Shed those extra pounds with MSN and The Biggest Loser! http://biggestloser.msn.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From neels at elego.de Thu Jan 24 22:09:47 2008 From: neels at elego.de (Neels Janosch Hofmeyr) Date: Thu, 24 Jan 2008 22:09:47 +0100 Subject: [M3devel] segmentation fault upon ./install-cm3-compiler.sh upgrade Message-ID: <4798FE9B.1090204@elego.de> Hi lists, I am trying to install cm3 5.4.0 on Ubuntu 7.10. I know that it worked on 7.4, and am doing the exact same steps. I have now tried it with cm3-min-...-5.4.0, just as I did last year. But now, I get this output: neels at oubantu:~/cm3-build/scripts $ ./install-cm3-compiler.sh upgrade cp /usr/local/cm3/bin/cm3 /usr/local/cm3/bin/cm3-5.4.0 cp /usr/local/cm3/bin/cm3cg /usr/local/cm3/bin/cm3cg-5.4.0 Segmentation fault (core dumped) cp /home/neels/cm3-build/m3-sys/cm3/LINUXLIBC6/cm3 /usr/local/cm3/bin/cm3- cp /home/neels/cm3-build/m3-sys/m3cc/LINUXLIBC6/cm3cg /usr/local/cm3/bin/cm3cg- cp /usr/local/cm3/bin/cm3- /usr/local/cm3/bin/cm3 cp /usr/local/cm3/bin/cm3cg- /usr/local/cm3/bin/cm3cg I have done this a second time, making sure everything is cleaned out and monitored things. From adding a `set -x' in the install-cm3-compiler.sh, it becomes obvious that `/usr/local/cm3/bin/cm3 -version' exits with a Segmentation Fault. After doing ./cminstall (the minimal binary install), cm3 -version said $ /usr/local/cm3/bin/cm3 -version Critical Mass Modula-3 version 5.4.0 last updated: 2006-10-11 configuration: /usr/local/cm3/bin/cm3.cfg After doing ./do-cm3-core.sh buildship, it still said the same. So, somewhere in install-cm3-compiler.sh, a disfunctional cm3 binary gets installed in /usr/local/cm3/bin/, after which cm3 yields only segmentation faults. After install-cm3-compiler.sh, cm3 -version says $ /usr/local/cm3/bin/cm3 -version *** *** runtime error: *** Segmentation violation - possible attempt to dereference NIL *** pc = 0x9e841069 *** Aborted (core dumped) Trying to backtrace in gdb apparently doesn't work -- I don't know how to compile debugging symbols into it. Giving up. I think now is the time to remove the statement "[cm3 is] easy-to-use [and] easy-to-install" from modula3.elegosoft.com. No piece of software I have ever encountered is as difficult to use and as impossible to install as critical mass modula3. I *am* following all the instructions! argh, Neels -- Neels Janosch Hofmeyr Software Developer neels at elego.de Public Key: http://binarchy.net/neels/neels.hofmeyr.public.key.asc elego Software Solutions GmbH http://www.elegosoft.com Gustav-Meyer-Allee 25, Geb?ude 12 HRB 77719 13355 Berlin, Germany Amtsgericht Charlottenburg Tel.: +49 30 23 45 86 96 Sitz der Gesellschaft: Berlin Fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Olaf Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From neels at elego.de Thu Jan 24 22:23:13 2008 From: neels at elego.de (Neels Janosch Hofmeyr) Date: Thu, 24 Jan 2008 22:23:13 +0100 Subject: [M3devel] minimal binary d5.5.0 fails on Ubuntu 7.10 In-Reply-To: <200801241441.m0OEfo13084214@camembert.async.caltech.edu> References: <200801241441.m0OEfo13084214@camembert.async.caltech.edu> Message-ID: <479901C1.5060208@elego.de> Well, back to trying cm3-min-POSIX-LINUXLIBC6-d5.5.0.tgz, I tried Mikas suggestion ("Search for -g in cm3.cfg and replace it with -gstabs+"), after which I get the following output: $ ./do-cm3-core.sh buildship CM3C = /home/neels/cm3-build/scripts/pkgmap.sh -c "cm3 -build -DROOT='/home/neels/cm3-build' && cm3 -ship -DROOT='/home/neels/cm3-build' " m3gc-simple m3core libm3 patternmatching m3middle m3linker m3front m3quake m3cc cm3 m3scanner m3tools m3cgcat m3cggen m3bundle bitvector digraph parseparams realgeometry set slisp sortedtableextras table-list tempfiles === package /home/neels/cm3-build/m3-libs/m3gc-simple === +++ cm3 -build -DROOT='/home/neels/cm3-build' && cm3 -ship -DROOT='/home/neels/cm3-build' +++ --- building in LINUXLIBC6 --- new source -> compiling sysdeps.c -> archiving libm3gcdefs.a --- shipping from LINUXLIBC6 --- . => /usr/local/cm3/pkg/m3gc-simple/LINUXLIBC6 .M3EXPORTS libm3gcdefs.so.5 libm3gcdefs.a libm3gcdefs.m3x .M3WEB ../src/runtime => /usr/local/cm3/pkg/m3gc-simple/src/runtime RTVM.c ../src/runtime/LINUXLIBC6 => /usr/local/cm3/pkg/m3gc-simple/src/runtime/LINUXLIBC6 sysdeps.c . => /usr/local/cm3/lib libm3gcdefs.a ==> /home/neels/cm3-build/m3-libs/m3gc-simple done === package /home/neels/cm3-build/m3-libs/m3core === +++ cm3 -build -DROOT='/home/neels/cm3-build' && cm3 -ship -DROOT='/home/neels/cm3-build' +++ --- building in LINUXLIBC6 --- ignoring ../src/m3overrides new source -> compiling RTHooks.i3 new source -> compiling RT0.i3 new source -> compiling RuntimeError.i3 new source -> compiling Word.i3 new source -> compiling RTException.i3 new source -> compiling RTHooks.m3 new source -> compiling RT0.m3 new source -> compiling Compiler.i3 new source -> compiling RuntimeError.m3 new source -> compiling Compiler.m3 new source -> compiling RTAllocator.i3 new source -> compiling RTType.i3 new source -> compiling Uucontext.i3 new source -> compiling Utypes.i3 new source -> compiling BasicCtypes.i3 new source -> compiling Ctypes.i3 new source -> compiling Usignal.i3 new source -> compiling Csetjmp.i3 new source -> compiling RTMachine.i3 new source -> compiling Upthread.i3 new source -> compiling Utime.i3 new source -> compiling RTHeapDep.i3 new source -> compiling RTHeapRep.i3 new source -> compiling Thread.i3 new source -> compiling FloatMode.i3 new source -> compiling ThreadF.i3 new source -> compiling RTOS.i3 new source -> compiling RTMisc.i3 new source -> compiling RTHeap.i3 new source -> compiling Cstdlib.i3 new source -> compiling Cstddef.i3 new source -> compiling RTAllocCnts.i3 new source -> compiling RTAllocator.m3 new source -> compiling RTAllocStats.i3 new source -> compiling Convert.i3 new source -> compiling TextClass.i3 new source -> compiling Text.i3 new source -> compiling RTProcedureSRC.i3 new source -> compiling Fingerprint.i3 new source -> compiling RTProcedure.i3 new source -> compiling RTStack.i3 new source -> compiling RTAllocStats.m3 "../src/runtime/common/RTAllocStats.m3", line 46: undefined runtime symbol !! (RTHooks.AllocateTracedRef) *** *** runtime error: *** Segmentation violation - possible attempt to dereference NIL *** pc = 0x811e7ff = StartCall + 0x19 in ../src/values/Procedure.m3 *** Aborted (core dumped) *** execution of failed *** It looks a little better, but still doesn't work. Any more ideas? Mika Nystrom wrote: > I think this is the broken cm3.cfg . > > Search for -g in cm3.cfg and replace it with -gstabs+ > > This thing bites a lot! I think it got me twice to the extent that > I had to ask this mailing list. Several other times that it had > me scratching my head and then thinking "oh it's that cm3.cfg thing > again..." > > cm3.cfg in general is pretty weird. I know the compiler looks > in at least two places for it. (Undocumented behavior.) > > Mika > > Neels Janosch Hofmeyr writes: > >> This is an OpenPGP/MIME signed message (RFC 2440 and 3156) >> --------------enigBBB9AF364E0AAD943688858C >> Content-Type: text/plain; charset=UTF-8; format=flowed >> Content-Transfer-Encoding: quoted-printable >> >> Hello m3-support and m3devel, >> >> I tried to bootstrap cm3 on Ubuntu 7.10 using the newer d5.5.0 binaries. = >> >> Upon running >> cd scripts >> ./do-cm3-core.sh buildship >> >> I got a series of errors, ending in a segmentation fault. I am now going = >> >> back to the 5.4.0 minimal binary. For interest, find the error output bel= >> ow. >> >> Regards, >> Neels >> >> >> neels at oubantu:~/cm3-build/scripts >> $ ./do-cm3-core.sh buildship >> CM3C =3D >> /home/neels/cm3-build/scripts/pkgmap.sh -c "cm3 -build =20 >> -DROOT=3D'/home/neels/cm3-build' && cm3 -ship=20 >> -DROOT=3D'/home/neels/cm3-build' " m3gc-simple m3core libm3=20 >> patternmatching m3middle m3linker m3front m3quake m3cc cm3 m3scanner=20 >> m3tools m3cgcat m3cggen m3bundle bitvector digraph parseparams=20 >> realgeometry set slisp sortedtableextras table-list tempfiles >> =3D=3D=3D package /home/neels/cm3-build/m3-libs/m3gc-simple =3D=3D=3D >> +++ cm3 -build -DROOT=3D'/home/neels/cm3-build' && cm3 -ship=20 >> -DROOT=3D'/home/neels/cm3-build' +++ >> --- building in LINUXLIBC6 --- >> >> new source -> compiling sysdeps.c >> -> archiving libm3gcdefs.a >> --- shipping from LINUXLIBC6 --- >> >> =2E =3D> /usr/local/cm3/pkg/m3gc-simple/LINUXLIBC6 >> .M3EXPORTS libm3gcdefs.so.5 libm3gcdefs.a libm3gcdefs.m3x >> .M3WEB =20 >> =2E./src/runtime =3D> /usr/local/cm3/pkg/m3gc-simple/src/runtime >> RTVM.c =20 >> =2E./src/runtime/LINUXLIBC6 =3D>=20 >> /usr/local/cm3/pkg/m3gc-simple/src/runtime/LINUXLIBC6 >> sysdeps.c =20 >> =2E =3D> /usr/local/cm3/lib >> libm3gcdefs.a =20 >> =3D=3D> /home/neels/cm3-build/m3-libs/m3gc-simple done >> >> =3D=3D=3D package /home/neels/cm3-build/m3-libs/m3core =3D=3D=3D >> +++ cm3 -build -DROOT=3D'/home/neels/cm3-build' && cm3 -ship=20 >> -DROOT=3D'/home/neels/cm3-build' +++ >> --- building in LINUXLIBC6 --- >> >> ignoring ../src/m3overrides >> >> new source -> compiling RTHooks.i3 >> RTHooks.i3: In function 'RTHooks_I3': >> RTHooks.i3:141: internal compiler error: Segmentation fault >> Please submit a full bug report, >> with preprocessed source if appropriate. >> See for instructions. >> new source -> compiling RT0.i3 >> RT0.i3: In function 'RT0_I3': >> RT0.i3:230: internal compiler error: Segmentation fault >> Please submit a full bug report, >> with preprocessed source if appropriate. >> See for instructions. >> new source -> compiling RuntimeError.i3 >> RuntimeError.i3: In function 'RuntimeError_I3': >> RuntimeError.i3:63: internal compiler error: Segmentation fault >> Please submit a full bug report, >> with preprocessed source if appropriate. >> See for instructions. >> new source -> compiling Word.i3 >> Word.i3: In function 'Word_I3': >> Word.i3:67: internal compiler error: Segmentation fault >> Please submit a full bug report, >> with preprocessed source if appropriate. >> See for instructions. >> new source -> compiling RTException.i3 >> RTException.i3: In function 'RTException_I3': >> RTException.i3:34: internal compiler error: Segmentation fault >> Please submit a full bug report, >> with preprocessed source if appropriate. >> See for instructions. >> new source -> compiling RTHooks.m3 >> RTHooks.m3: In function 'RTHooks_M3': >> RTHooks.m3:130: internal compiler error: Segmentation fault >> Please submit a full bug report, >> with preprocessed source if appropriate. >> See for instructions. >> new source -> compiling RT0.m3 >> RT0.m3:10: internal compiler error: Segmentation fault >> Please submit a full bug report, >> with preprocessed source if appropriate. >> See for instructions. >> new source -> compiling Compiler.i3 >> Compiler.i3: In function 'Compiler_I3': >> Compiler.i3:42: internal compiler error: Segmentation fault >> Please submit a full bug report, >> with preprocessed source if appropriate. >> See for instructions. >> new source -> compiling RuntimeError.m3 >> RuntimeError.m3: In function 'RuntimeError_M3': >> RuntimeError.m3:61: internal compiler error: Segmentation fault >> Please submit a full bug report, >> with preprocessed source if appropriate. >> See for instructions. >> new source -> compiling Compiler.m3 >> Compiler.m3: In function 'Compiler_M3': >> Compiler.m3:11: internal compiler error: Segmentation fault >> Please submit a full bug report, >> with preprocessed source if appropriate. >> See for instructions. >> new source -> compiling RTAllocator.i3 >> RTAllocator.i3: In function 'RTAllocator_I3': >> RTAllocator.i3:79: internal compiler error: Segmentation fault >> Please submit a full bug report, >> with preprocessed source if appropriate. >> See for instructions. >> new source -> compiling RTType.i3 >> RTType.i3: In function 'RTType_I3': >> RTType.i3:65: internal compiler error: Segmentation fault >> Please submit a full bug report, >> with preprocessed source if appropriate. >> See for instructions. >> new source -> compiling Uucontext.i3 >> Uucontext.i3: In function 'Uucontext_I3': >> Uucontext.i3:195: internal compiler error: Segmentation fault >> Please submit a full bug report, >> with preprocessed source if appropriate. >> See for instructions. >> new source -> compiling Utypes.i3 >> Utypes.i3: In function 'Utypes_I3': >> Utypes.i3:108: internal compiler error: Segmentation fault >> Please submit a full bug report, >> with preprocessed source if appropriate. >> See for instructions. >> new source -> compiling BasicCtypes.i3 >> BasicCtypes.i3: In function 'BasicCtypes_I3': >> BasicCtypes.i3:33: internal compiler error: Segmentation fault >> Please submit a full bug report, >> with preprocessed source if appropriate. >> See for instructions. >> new source -> compiling Ctypes.i3 >> > Ctypes.i3: In function 'Ctypes_I3': > >> Ctypes.i3:67: internal compiler error: Segmentation fault >> Please submit a full bug report, >> with preprocessed source if appropriate. >> See for instructions. >> new source -> compiling Usignal.i3 >> Usignal.i3: In function 'Usignal_I3': >> Usignal.i3:199: internal compiler error: Segmentation fault >> Please submit a full bug report, >> with preprocessed source if appropriate. >> See for instructions. >> new source -> compiling Csetjmp.i3 >> Csetjmp.i3: In function 'Csetjmp_I3': >> Csetjmp.i3:29: internal compiler error: Segmentation fault >> Please submit a full bug report, >> with preprocessed source if appropriate. >> See for instructions. >> new source -> compiling RTMachine.i3 >> RTMachine.i3: In function 'RTMachine_I3': >> RTMachine.i3:87: internal compiler error: Segmentation fault >> Please submit a full bug report, >> with preprocessed source if appropriate. >> See for instructions. >> new source -> compiling Upthread.i3 >> Upthread.i3: In function 'Upthread_I3': >> Upthread.i3:343: internal compiler error: Segmentation fault >> Please submit a full bug report, >> with preprocessed source if appropriate. >> See for instructions. >> new source -> compiling Utime.i3 >> Utime.i3: In function 'Utime_I3': >> Utime.i3:182: internal compiler error: Segmentation fault >> Please submit a full bug report, >> with preprocessed source if appropriate. >> See for instructions. >> new source -> compiling RTHeapDep.i3 >> RTHeapDep.i3: In function 'RTHeapDep_I3': >> RTHeapDep.i3:74: internal compiler error: Segmentation fault >> Please submit a full bug report, >> with preprocessed source if appropriate. >> See for instructions. >> new source -> compiling RTHeapRep.i3 >> RTHeapRep.i3: In function 'RTHeapRep_I3': >> RTHeapRep.i3:310: internal compiler error: Segmentation fault >> Please submit a full bug report, >> with preprocessed source if appropriate. >> See for instructions. >> new source -> compiling Thread.i3 >> Thread.i3: In function 'Thread_I3': >> Thread.i3:120: internal compiler error: Segmentation fault >> Please submit a full bug report, >> with preprocessed source if appropriate. >> See for instructions. >> new source -> compiling FloatMode.i3 >> FloatMode.i3: In function 'FloatMode_I3': >> FloatMode.i3:123: internal compiler error: Segmentation fault >> Please submit a full bug report, >> with preprocessed source if appropriate. >> See for instructions. >> new source -> compiling ThreadF.i3 >> ThreadF.i3: In function 'ThreadF_I3': >> ThreadF.i3:110: internal compiler error: Segmentation fault >> Please submit a full bug report, >> with preprocessed source if appropriate. >> See for instructions. >> new source -> compiling RTOS.i3 >> RTOS.i3: In function 'RTOS_I3': >> RTOS.i3:44: internal compiler error: Segmentation fault >> Please submit a full bug report, >> with preprocessed source if appropriate. >> See for instructions. >> new source -> compiling RTMisc.i3 >> RTMisc.i3: In function 'RTMisc_I3': >> RTMisc.i3:29: internal compiler error: Segmentation fault >> Please submit a full bug report, >> with preprocessed source if appropriate. >> See for instructions. >> new source -> compiling RTHeap.i3 >> RTHeap.i3: In function 'RTHeap_I3': >> RTHeap.i3:44: internal compiler error: Segmentation fault >> Please submit a full bug report, >> with preprocessed source if appropriate. >> See for instructions. >> new source -> compiling Cstdlib.i3 >> Cstdlib.i3: In function 'Cstdlib_I3': >> Cstdlib.i3:34: internal compiler error: Segmentation fault >> Please submit a full bug report, >> with preprocessed source if appropriate. >> See for instructions. >> new source -> compiling Cstddef.i3 >> Cstddef.i3: In function 'Cstddef_I3': >> Cstddef.i3:14: internal compiler error: Segmentation fault >> Please submit a full bug report, >> with preprocessed source if appropriate. >> See for instructions. >> new source -> compiling RTAllocCnts.i3 >> RTAllocCnts.i3: In function 'RTAllocCnts_I3': >> RTAllocCnts.i3:22: internal compiler error: Segmentation fault >> Please submit a full bug report, >> with preprocessed source if appropriate. >> See for instructions. >> new source -> compiling RTAllocator.m3 >> RTAllocator.m3: In function 'RTAllocator_M3': >> RTAllocator.m3:387: internal compiler error: Segmentation fault >> Please submit a full bug report, >> with preprocessed source if appropriate. >> See for instructions. >> new source -> compiling RTAllocStats.i3 >> RTAllocStats.i3: In function 'RTAllocStats_I3': >> RTAllocStats.i3:39: internal compiler error: Segmentation fault >> Please submit a full bug report, >> with preprocessed source if appropriate. >> See for instructions. >> new source -> compiling Convert.i3 >> Convert.i3: In function 'Convert_I3': >> Convert.i3:111: internal compiler error: Segmentation fault >> Please submit a full bug report, >> with preprocessed source if appropriate. >> See for instructions. >> new source -> compiling TextClass.i3 >> TextClass.i3: In function 'TextClass_I3': >> TextClass.i3:46: internal compiler error: Segmentation fault >> Please submit a full bug report, >> with preprocessed source if appropriate. >> See for instructions. >> new source -> compiling Text.i3 >> Text.i3: In function 'Text_I3': >> Text.i3:81: internal compiler error: Segmentation fault >> Please submit a full bug report, >> with preprocessed source if appropriate. >> See for instructions. >> new source -> compiling RTProcedureSRC.i3 >> RTProcedureSRC.i3: In function 'RTProcedureSRC_I3': >> RTProcedureSRC.i3:28: internal compiler error: Segmentation fault >> Please submit a full bug report, >> with preprocessed source if appropriate. >> See for instructions. >> new source -> compiling Fingerprint.i3 >> Fingerprint.i3: In function 'Fingerprint_I3': >> Fingerprint.i3:63: internal compiler error: Segmentation fault >> Please submit a full bug report, >> with preprocessed source if appropriate. >> See for instructions. >> new source -> compiling RTProcedure.i3 >> RTProcedure.i3: In function 'RTProcedure_I3': >> RTProcedure.i3:32: internal compiler error: Segmentation fault >> Please submit a full bug report, >> with preprocessed source if appropriate. >> See for instructions. >> new source -> compiling RTStack.i3 >> RTStack.i3: In function 'RTStack_I3': >> RTStack.i3:53: internal compiler error: Segmentation fault >> Please submit a full bug report, >> with preprocessed source if appropriate. >> See for instructions. >> new source -> compiling RTAllocStats.m3 >> "../src/runtime/common/RTAllocStats.m3", line 46: undefined runtime=20 >> symbol !! (RTHooks.AllocateTracedRef) >> >> >> *** >> *** runtime error: >> *** Segmentation violation - possible attempt to dereference NIL >> *** pc =3D 0x811e7ff =3D StartCall + 0x19 in ../src/values/Procedure.m= >> 3 >> *** >> >> Aborted (core dumped) >> *** execution of failed *** >> >> >> --=20 >> Neels Janosch Hofmeyr >> Software Developer >> >> neels at elego.de >> Public Key: http://binarchy.net/neels/neels.hofmeyr.public.key.asc >> >> elego Software Solutions GmbH http://www.elegosoft.com >> Gustav-Meyer-Allee 25, Geb=C3=A4ude 12 HRB 77719 >> 13355 Berlin, Germany Amtsgericht Charlottenburg >> Tel.: +49 30 23 45 86 96 Sitz der Gesellschaft: Berlin >> Fax: +49 30 23 45 86 95 Gesch=C3=A4ftsf=C3=BChrer: Olaf W= >> agner >> >> >> >> --------------enigBBB9AF364E0AAD943688858C >> Content-Type: application/pgp-signature; name="signature.asc" >> Content-Description: OpenPGP digital signature >> Content-Disposition: attachment; filename="signature.asc" >> >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG v1.4.6 (GNU/Linux) >> >> iD8DBQFHmJbkRpHEG7B8Y+ARAtjGAJ47SAvF3xSFUuQT0gd5ZF2OLbOX9wCg12+B >> bD8Jx13qOgK+5OasBdztrYg= >> =IPcA >> -----END PGP SIGNATURE----- >> >> --------------enigBBB9AF364E0AAD943688858C-- >> -- Neels Janosch Hofmeyr Software Developer neels at elego.de Public Key: http://binarchy.net/neels/neels.hofmeyr.public.key.asc elego Software Solutions GmbH http://www.elegosoft.com Gustav-Meyer-Allee 25, Geb?ude 12 HRB 77719 13355 Berlin, Germany Amtsgericht Charlottenburg Tel.: +49 30 23 45 86 96 Sitz der Gesellschaft: Berlin Fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Olaf Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From neels at elego.de Thu Jan 24 22:40:24 2008 From: neels at elego.de (Neels Janosch Hofmeyr) Date: Thu, 24 Jan 2008 22:40:24 +0100 Subject: [M3devel] segmentation fault upon ./install-cm3-compiler.sh upgrade In-Reply-To: <4798FE9B.1090204@elego.de> References: <4798FE9B.1090204@elego.de> Message-ID: <479905C8.7080003@elego.de> btw, I am using the "stable release" source tarballs with the 5.4.0 minimal binary as available on the download page. http://modula3.elegosoft.com/cm3/cm3-min-POSIX-LINUXLIBC6-5.4.0.tgz http://modula3.elegosoft.com/cm3/cm3-src-sys-5.4.0.tgz http://modula3.elegosoft.com/cm3/cm3-src-gnu-5.4.0.tgz http://modula3.elegosoft.com/cm3/cm3-src-std-5.4.0.tgz Neels Janosch Hofmeyr wrote: > Hi lists, > > I am trying to install cm3 5.4.0 on Ubuntu 7.10. I know that it worked > on 7.4, and am doing the exact same steps. I have now tried it with > cm3-min-...-5.4.0, just as I did last year. > > But now, I get this output: > > neels at oubantu:~/cm3-build/scripts > $ ./install-cm3-compiler.sh upgrade > cp /usr/local/cm3/bin/cm3 /usr/local/cm3/bin/cm3-5.4.0 > cp /usr/local/cm3/bin/cm3cg /usr/local/cm3/bin/cm3cg-5.4.0 > Segmentation fault (core dumped) > cp /home/neels/cm3-build/m3-sys/cm3/LINUXLIBC6/cm3 > /usr/local/cm3/bin/cm3- > cp /home/neels/cm3-build/m3-sys/m3cc/LINUXLIBC6/cm3cg > /usr/local/cm3/bin/cm3cg- > cp /usr/local/cm3/bin/cm3- /usr/local/cm3/bin/cm3 > cp /usr/local/cm3/bin/cm3cg- /usr/local/cm3/bin/cm3cg > > I have done this a second time, making sure everything is cleaned out > and monitored things. From adding a `set -x' in the > install-cm3-compiler.sh, it becomes obvious that > `/usr/local/cm3/bin/cm3 -version' exits with a Segmentation Fault. > > After doing ./cminstall (the minimal binary install), cm3 -version said > $ /usr/local/cm3/bin/cm3 -version > Critical Mass Modula-3 version 5.4.0 > last updated: 2006-10-11 > configuration: /usr/local/cm3/bin/cm3.cfg > > After doing ./do-cm3-core.sh buildship, it still said the same. > So, somewhere in install-cm3-compiler.sh, a disfunctional cm3 binary > gets installed in /usr/local/cm3/bin/, after which cm3 yields only > segmentation faults. > > After install-cm3-compiler.sh, cm3 -version says > $ /usr/local/cm3/bin/cm3 -version > > > *** > *** runtime error: > *** Segmentation violation - possible attempt to dereference NIL > *** pc = 0x9e841069 > *** > > Aborted (core dumped) > > Trying to backtrace in gdb apparently doesn't work -- I don't know how > to compile debugging symbols into it. Giving up. > > I think now is the time to remove the statement "[cm3 is] easy-to-use > [and] easy-to-install" from modula3.elegosoft.com. No piece of > software I have ever encountered is as difficult to use and as > impossible to install as critical mass modula3. I *am* following all > the instructions! > > argh, > Neels > -- Neels Janosch Hofmeyr Software Developer neels at elego.de Public Key: http://binarchy.net/neels/neels.hofmeyr.public.key.asc elego Software Solutions GmbH http://www.elegosoft.com Gustav-Meyer-Allee 25, Geb?ude 12 HRB 77719 13355 Berlin, Germany Amtsgericht Charlottenburg Tel.: +49 30 23 45 86 96 Sitz der Gesellschaft: Berlin Fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Olaf Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From jayk123 at hotmail.com Thu Jan 24 22:48:17 2008 From: jayk123 at hotmail.com (Jay) Date: Thu, 24 Jan 2008 21:48:17 +0000 Subject: [M3devel] segmentation fault upon ./install-cm3-compiler.sh upgrade In-Reply-To: <479905C8.7080003@elego.de> References: <4798FE9B.1090204@elego.de> <479905C8.7080003@elego.de> Message-ID: Personally I would try checking out the current tree. And I thought there was a 5.5.x build to start from. I'd try it. And if the existing binaries don't have symbols, and you can't build the system, find a system you can build or cross build from and get symbols in there and then debug it here. Symbols can be very valuable and I have mixed thoughts on stripped binaries. Maybe I'll get around to running this x86 Linux stuff in a virtual or physical machine sometime soon. Hopefully this gets solved before I resort to it. - Jay > Date: Thu, 24 Jan 2008 22:40:24 +0100> From: neels at elego.de> To: m3devel at elego.de; m3-support at elego.de> Subject: Re: [M3devel] segmentation fault upon ./install-cm3-compiler.sh upgrade> > btw, I am using the "stable release" source tarballs with the 5.4.0 > minimal binary as available on the download page.> http://modula3.elegosoft.com/cm3/cm3-min-POSIX-LINUXLIBC6-5.4.0.tgz> http://modula3.elegosoft.com/cm3/cm3-src-sys-5.4.0.tgz> http://modula3.elegosoft.com/cm3/cm3-src-gnu-5.4.0.tgz> http://modula3.elegosoft.com/cm3/cm3-src-std-5.4.0.tgz> > Neels Janosch Hofmeyr wrote:> > Hi lists,> >> > I am trying to install cm3 5.4.0 on Ubuntu 7.10. I know that it worked > > on 7.4, and am doing the exact same steps. I have now tried it with > > cm3-min-...-5.4.0, just as I did last year.> >> > But now, I get this output:> >> > neels at oubantu:~/cm3-build/scripts> > $ ./install-cm3-compiler.sh upgrade> > cp /usr/local/cm3/bin/cm3 /usr/local/cm3/bin/cm3-5.4.0> > cp /usr/local/cm3/bin/cm3cg /usr/local/cm3/bin/cm3cg-5.4.0> > Segmentation fault (core dumped)> > cp /home/neels/cm3-build/m3-sys/cm3/LINUXLIBC6/cm3 > > /usr/local/cm3/bin/cm3-> > cp /home/neels/cm3-build/m3-sys/m3cc/LINUXLIBC6/cm3cg > > /usr/local/cm3/bin/cm3cg-> > cp /usr/local/cm3/bin/cm3- /usr/local/cm3/bin/cm3> > cp /usr/local/cm3/bin/cm3cg- /usr/local/cm3/bin/cm3cg> >> > I have done this a second time, making sure everything is cleaned out > > and monitored things. From adding a `set -x' in the > > install-cm3-compiler.sh, it becomes obvious that > > `/usr/local/cm3/bin/cm3 -version' exits with a Segmentation Fault.> >> > After doing ./cminstall (the minimal binary install), cm3 -version said> > $ /usr/local/cm3/bin/cm3 -version> > Critical Mass Modula-3 version 5.4.0> > last updated: 2006-10-11> > configuration: /usr/local/cm3/bin/cm3.cfg> >> > After doing ./do-cm3-core.sh buildship, it still said the same.> > So, somewhere in install-cm3-compiler.sh, a disfunctional cm3 binary > > gets installed in /usr/local/cm3/bin/, after which cm3 yields only > > segmentation faults.> >> > After install-cm3-compiler.sh, cm3 -version says> > $ /usr/local/cm3/bin/cm3 -version> >> >> > ***> > *** runtime error:> > *** Segmentation violation - possible attempt to dereference NIL> > *** pc = 0x9e841069> > ***> >> > Aborted (core dumped)> >> > Trying to backtrace in gdb apparently doesn't work -- I don't know how > > to compile debugging symbols into it. Giving up.> >> > I think now is the time to remove the statement "[cm3 is] easy-to-use > > [and] easy-to-install" from modula3.elegosoft.com. No piece of > > software I have ever encountered is as difficult to use and as > > impossible to install as critical mass modula3. I *am* following all > > the instructions!> >> > argh,> > Neels> >> > -- > Neels Janosch Hofmeyr> Software Developer> > neels at elego.de> Public Key: http://binarchy.net/neels/neels.hofmeyr.public.key.asc> > elego Software Solutions GmbH http://www.elegosoft.com> Gustav-Meyer-Allee 25, Geb?ude 12 HRB 77719> 13355 Berlin, Germany Amtsgericht Charlottenburg> Tel.: +49 30 23 45 86 96 Sitz der Gesellschaft: Berlin> Fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Olaf Wagner> > _________________________________________________________________ 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 neels at elego.de Thu Jan 24 22:59:16 2008 From: neels at elego.de (Neels Janosch Hofmeyr) Date: Thu, 24 Jan 2008 22:59:16 +0100 Subject: [M3devel] segmentation fault upon ./install-cm3-compiler.sh upgrade In-Reply-To: References: <4798FE9B.1090204@elego.de> <479905C8.7080003@elego.de> Message-ID: <47990A34.7070909@elego.de> Jay wrote: > Personally I would try checking out the current tree. that's worth another try... > And I thought there was a 5.5.x build to start from. I'd try it. I have, see my previous mail: "minimal binary d5.5.0 fails on Ubuntu 7.10" > Connect and share in new ways with Windows Live. Get it now! > no thanks. -- Neels Janosch Hofmeyr Software Developer neels at elego.de Public Key: http://binarchy.net/neels/neels.hofmeyr.public.key.asc elego Software Solutions GmbH http://www.elegosoft.com Gustav-Meyer-Allee 25, Geb?ude 12 HRB 77719 13355 Berlin, Germany Amtsgericht Charlottenburg Tel.: +49 30 23 45 86 96 Sitz der Gesellschaft: Berlin Fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Olaf Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From wagner at elegosoft.com Thu Jan 24 23:03:22 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 24 Jan 2008 23:03:22 +0100 Subject: [M3devel] segmentation fault upon ./install-cm3-compiler.sh upgrade In-Reply-To: <479905C8.7080003@elego.de> References: <4798FE9B.1090204@elego.de> <479905C8.7080003@elego.de> Message-ID: <20080124230322.vl12nlls4kosoocs@mail.elegosoft.com> Quoting Neels Janosch Hofmeyr : > btw, I am using the "stable release" source tarballs with the 5.4.0 > minimal binary as available on the download page. > http://modula3.elegosoft.com/cm3/cm3-min-POSIX-LINUXLIBC6-5.4.0.tgz > http://modula3.elegosoft.com/cm3/cm3-src-sys-5.4.0.tgz > http://modula3.elegosoft.com/cm3/cm3-src-gnu-5.4.0.tgz > http://modula3.elegosoft.com/cm3/cm3-src-std-5.4.0.tgz Hi Neels, 5.4.0 is rather old now. I assume Ubuntu has made some incompatible changes to its kernel or C library interfaces that the old cm3 binary cannot cope with. What about trying one the more recent installation archives, like d.5.5.1? Once you have a working cm3 and cm3cg, compiling the rest should be no problem. Stable releases cannot necessarily be expected to run on newer operating systems when the ABI changes, as they don't adapt themselves ;-) Try this, for example: http://modula3.elegosoft.com/cm3/snaps/cm3-min-POSIX-LINUXLIBC6-d5.5.1-2008-01-24-03-35-01.tgz It should also be possible to get a backtrace of the cm3 crash within gdb. There should be debugging symbols in the distributed binaries. What does bt show? If debugging symbols are missing, we've got to fix that. Olaf > Neels Janosch Hofmeyr wrote: >> Hi lists, >> >> I am trying to install cm3 5.4.0 on Ubuntu 7.10. I know that it >> worked on 7.4, and am doing the exact same steps. I have now tried >> it with cm3-min-...-5.4.0, just as I did last year. >> >> But now, I get this output: >> >> neels at oubantu:~/cm3-build/scripts >> $ ./install-cm3-compiler.sh upgrade >> cp /usr/local/cm3/bin/cm3 /usr/local/cm3/bin/cm3-5.4.0 >> cp /usr/local/cm3/bin/cm3cg /usr/local/cm3/bin/cm3cg-5.4.0 >> Segmentation fault (core dumped) >> cp /home/neels/cm3-build/m3-sys/cm3/LINUXLIBC6/cm3 /usr/local/cm3/bin/cm3- >> cp /home/neels/cm3-build/m3-sys/m3cc/LINUXLIBC6/cm3cg >> /usr/local/cm3/bin/cm3cg- >> cp /usr/local/cm3/bin/cm3- /usr/local/cm3/bin/cm3 >> cp /usr/local/cm3/bin/cm3cg- /usr/local/cm3/bin/cm3cg >> >> I have done this a second time, making sure everything is cleaned >> out and monitored things. From adding a `set -x' in the >> install-cm3-compiler.sh, it becomes obvious that >> `/usr/local/cm3/bin/cm3 -version' exits with a Segmentation Fault. >> >> After doing ./cminstall (the minimal binary install), cm3 -version said >> $ /usr/local/cm3/bin/cm3 -version >> Critical Mass Modula-3 version 5.4.0 >> last updated: 2006-10-11 >> configuration: /usr/local/cm3/bin/cm3.cfg >> >> After doing ./do-cm3-core.sh buildship, it still said the same. >> So, somewhere in install-cm3-compiler.sh, a disfunctional cm3 >> binary gets installed in /usr/local/cm3/bin/, after which cm3 >> yields only segmentation faults. >> >> After install-cm3-compiler.sh, cm3 -version says >> $ /usr/local/cm3/bin/cm3 -version >> >> >> *** >> *** runtime error: >> *** Segmentation violation - possible attempt to dereference NIL >> *** pc = 0x9e841069 >> *** >> >> Aborted (core dumped) >> >> Trying to backtrace in gdb apparently doesn't work -- I don't know >> how to compile debugging symbols into it. Giving up. >> >> I think now is the time to remove the statement "[cm3 is] >> easy-to-use [and] easy-to-install" from modula3.elegosoft.com. No >> piece of software I have ever encountered is as difficult to use >> and as impossible to install as critical mass modula3. I *am* >> following all the instructions! >> >> argh, >> Neels >> > > -- > Neels Janosch Hofmeyr > Software Developer > > neels at elego.de > Public Key: http://binarchy.net/neels/neels.hofmeyr.public.key.asc > > elego Software Solutions GmbH http://www.elegosoft.com > Gustav-Meyer-Allee 25, Geb?ude 12 HRB 77719 > 13355 Berlin, Germany Amtsgericht Charlottenburg > Tel.: +49 30 23 45 86 96 Sitz der Gesellschaft: Berlin > Fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Olaf Wagner -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From neels at elego.de Thu Jan 24 23:11:08 2008 From: neels at elego.de (Neels Janosch Hofmeyr) Date: Thu, 24 Jan 2008 23:11:08 +0100 Subject: [M3devel] segmentation fault upon ./install-cm3-compiler.sh upgrade In-Reply-To: <20080124230322.vl12nlls4kosoocs@mail.elegosoft.com> References: <4798FE9B.1090204@elego.de> <479905C8.7080003@elego.de> <20080124230322.vl12nlls4kosoocs@mail.elegosoft.com> Message-ID: <47990CFC.8080609@elego.de> Olaf Wagner wrote: > Quoting Neels Janosch Hofmeyr : > >> btw, I am using the "stable release" source tarballs with the 5.4.0 > > Hi Neels, > > 5.4.0 is rather old now. I assume Ubuntu has made some incompatible > changes to its kernel or C library interfaces that the old cm3 binary > cannot cope with. What about trying one the more recent installation > archives, like d.5.5.1? Once you have a working cm3 and cm3cg, compiling > the rest should be no problem. Stable releases cannot necessarily be > expected to run on newer operating systems when the ABI changes, as they > don't adapt themselves ;-) > > Try this, for example: > > http://modula3.elegosoft.com/cm3/snaps/cm3-min-POSIX-LINUXLIBC6-d5.5.1-2008-01-24-03-35-01.tgz > I'll try it next. btw, I am writing an instructions text for installing on ubuntu 7.10 along the way... > > It should also be possible to get a backtrace of the cm3 crash > within gdb. There should be debugging symbols in the distributed > binaries. What does bt show? I tried bt, it shows nothing: $ gdb /usr/local/cm3/bin/cm3 GNU gdb 6.6-debian Copyright (C) 2006 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i486-linux-gnu"... Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1". (gdb) run -version Starting program: /usr/local/cm3/bin/cm3 -version Program received signal SIGSEGV, Segmentation fault. 0x9e841069 in ?? () (gdb) bt #0 0x9e841069 in ?? () Cannot access memory at address 0xf05fc929 (gdb) > > If debugging symbols are missing, we've got to fix that. Well, that doesn't mean debugging symbols are missing, sometimes this kind of thing happens anyway (right?). > > Olaf > >> Neels Janosch Hofmeyr wrote: >>> Hi lists, >>> >>> I am trying to install cm3 5.4.0 on Ubuntu 7.10. I know that it >>> worked on 7.4, and am doing the exact same steps. I have now tried >>> it with cm3-min-...-5.4.0, just as I did last year. >>> >>> But now, I get this output: >>> >>> neels at oubantu:~/cm3-build/scripts >>> $ ./install-cm3-compiler.sh upgrade >>> cp /usr/local/cm3/bin/cm3 /usr/local/cm3/bin/cm3-5.4.0 >>> cp /usr/local/cm3/bin/cm3cg /usr/local/cm3/bin/cm3cg-5.4.0 >>> Segmentation fault (core dumped) >>> cp /home/neels/cm3-build/m3-sys/cm3/LINUXLIBC6/cm3 >>> /usr/local/cm3/bin/cm3- >>> cp /home/neels/cm3-build/m3-sys/m3cc/LINUXLIBC6/cm3cg >>> /usr/local/cm3/bin/cm3cg- >>> cp /usr/local/cm3/bin/cm3- /usr/local/cm3/bin/cm3 >>> cp /usr/local/cm3/bin/cm3cg- /usr/local/cm3/bin/cm3cg >>> >>> I have done this a second time, making sure everything is cleaned >>> out and monitored things. From adding a `set -x' in the >>> install-cm3-compiler.sh, it becomes obvious that >>> `/usr/local/cm3/bin/cm3 -version' exits with a Segmentation Fault. >>> >>> After doing ./cminstall (the minimal binary install), cm3 -version said >>> $ /usr/local/cm3/bin/cm3 -version >>> Critical Mass Modula-3 version 5.4.0 >>> last updated: 2006-10-11 >>> configuration: /usr/local/cm3/bin/cm3.cfg >>> >>> After doing ./do-cm3-core.sh buildship, it still said the same. >>> So, somewhere in install-cm3-compiler.sh, a disfunctional cm3 >>> binary gets installed in /usr/local/cm3/bin/, after which cm3 >>> yields only segmentation faults. >>> >>> After install-cm3-compiler.sh, cm3 -version says >>> $ /usr/local/cm3/bin/cm3 -version >>> >>> >>> *** >>> *** runtime error: >>> *** Segmentation violation - possible attempt to dereference NIL >>> *** pc = 0x9e841069 >>> *** >>> >>> Aborted (core dumped) >>> >>> Trying to backtrace in gdb apparently doesn't work -- I don't know >>> how to compile debugging symbols into it. Giving up. >>> >>> I think now is the time to remove the statement "[cm3 is] >>> easy-to-use [and] easy-to-install" from modula3.elegosoft.com. No >>> piece of software I have ever encountered is as difficult to use >>> and as impossible to install as critical mass modula3. I *am* >>> following all the instructions! >>> >>> argh, >>> Neels >>> >> >> -- >> Neels Janosch Hofmeyr >> Software Developer >> >> neels at elego.de >> Public Key: http://binarchy.net/neels/neels.hofmeyr.public.key.asc >> >> elego Software Solutions GmbH http://www.elegosoft.com >> Gustav-Meyer-Allee 25, Geb?ude 12 HRB 77719 >> 13355 Berlin, Germany Amtsgericht Charlottenburg >> Tel.: +49 30 23 45 86 96 Sitz der Gesellschaft: Berlin >> Fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Olaf Wagner > > > -- Neels Janosch Hofmeyr Software Developer neels at elego.de Public Key: http://binarchy.net/neels/neels.hofmeyr.public.key.asc elego Software Solutions GmbH http://www.elegosoft.com Gustav-Meyer-Allee 25, Geb?ude 12 HRB 77719 13355 Berlin, Germany Amtsgericht Charlottenburg Tel.: +49 30 23 45 86 96 Sitz der Gesellschaft: Berlin Fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Olaf Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From neels at elego.de Thu Jan 24 23:21:39 2008 From: neels at elego.de (Neels Janosch Hofmeyr) Date: Thu, 24 Jan 2008 23:21:39 +0100 Subject: [M3devel] snapshots checksums are missing Message-ID: <47990F73.3010707@elego.de> btw, on http://modula3.elegosoft.com/cm3/checksums.php3 , I can't find checksums for the daily snapshots. At least not for cm3-min-POSIX-LINUXLIBC6-d5.5.1-2008-01-24-03-35-01.tgz or any other d5.5.1 tarball -- Neels Janosch Hofmeyr Software Developer neels at elego.de Public Key: http://binarchy.net/neels/neels.hofmeyr.public.key.asc elego Software Solutions GmbH http://www.elegosoft.com Gustav-Meyer-Allee 25, Geb?ude 12 HRB 77719 13355 Berlin, Germany Amtsgericht Charlottenburg Tel.: +49 30 23 45 86 96 Sitz der Gesellschaft: Berlin Fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Olaf Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From jayk123 at hotmail.com Thu Jan 24 23:32:08 2008 From: jayk123 at hotmail.com (Jay) Date: Thu, 24 Jan 2008 22:32:08 +0000 Subject: [M3devel] segmentation fault upon ./install-cm3-compiler.sh upgrade In-Reply-To: <47990CFC.8080609@elego.de> References: <4798FE9B.1090204@elego.de> <479905C8.7080003@elego.de> <20080124230322.vl12nlls4kosoocs@mail.elegosoft.com> <47990CFC.8080609@elego.de> Message-ID: > Stable releases cannot necessarily be > expected to run on newer operating systems when the ABI changes, as they > don't adapt themselves ;-) Wow. No stable ABI? What's up with that? I understand that building with current headers/libs might not work on older systems, but building with older headers/libs should almost always work on newer systems, AT LEAST at the ABI level, if not at the exact behavioral level, that's much harder, if there is to be any change or any bug fixes. People get away with the craziest things, like double frees (ok, not in safe Modula-3), only to have newer better heaps be more strict and catch them... > Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1". Is that normal? > Program received signal SIGSEGV, Segmentation fault. > 0x9e841069 in ?? () > (gdb) bt > #0 0x9e841069 in ?? () > Cannot access memory at address 0xf05fc929 > (gdb) If the above is normal..can you break on main? And..I don't know what the name is...a bisection search..for how far it gets before it crashes? You know, either systematically, or at least randomly, step over and step into function calls, if you go to far and it crashes, step into next time instead of step over. > > If debugging symbols are missing, we've got to fix that. Sorry, I was speculating, based mainly on "strip" appear in scripts/*.sh, didn't look if it is used. > Well, that doesn't mean debugging symbols are missing, sometimes this > kind of thing happens anyway (right?). Right. - Jay > Date: Thu, 24 Jan 2008 23:11:08 +0100> From: neels at elego.de> To: wagner at elegosoft.com> CC: m3devel at elego.de; m3-support at elego.de> Subject: Re: [M3devel] segmentation fault upon ./install-cm3-compiler.sh upgrade> > > > Olaf Wagner wrote:> > Quoting Neels Janosch Hofmeyr :> >> >> btw, I am using the "stable release" source tarballs with the 5.4.0> >> > Hi Neels,> >> > 5.4.0 is rather old now. I assume Ubuntu has made some incompatible> > changes to its kernel or C library interfaces that the old cm3 binary> > cannot cope with. What about trying one the more recent installation> > archives, like d.5.5.1? Once you have a working cm3 and cm3cg, compiling> > the rest should be no problem. Stable releases cannot necessarily be> > expected to run on newer operating systems when the ABI changes, as they> > don't adapt themselves ;-)> >> > Try this, for example:> >> > http://modula3.elegosoft.com/cm3/snaps/cm3-min-POSIX-LINUXLIBC6-d5.5.1-2008-01-24-03-35-01.tgz > >> I'll try it next.> btw, I am writing an instructions text for installing on ubuntu 7.10 > along the way...> >> > It should also be possible to get a backtrace of the cm3 crash> > within gdb. There should be debugging symbols in the distributed> > binaries. What does bt show?> I tried bt, it shows nothing:> > $ gdb /usr/local/cm3/bin/cm3> GNU gdb 6.6-debian> Copyright (C) 2006 Free Software Foundation, Inc.> GDB is free software, covered by the GNU General Public License, and you are> welcome to change it and/or distribute copies of it under certain > conditions.> Type "show copying" to see the conditions.> There is absolutely no warranty for GDB. Type "show warranty" for details.> This GDB was configured as "i486-linux-gnu"...> Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1".> (gdb) run -version> Starting program: /usr/local/cm3/bin/cm3 -version> > Program received signal SIGSEGV, Segmentation fault.> 0x9e841069 in ?? ()> (gdb) bt> #0 0x9e841069 in ?? ()> Cannot access memory at address 0xf05fc929> (gdb)> > >> > If debugging symbols are missing, we've got to fix that.> Well, that doesn't mean debugging symbols are missing, sometimes this > kind of thing happens anyway (right?).> >> > Olaf> >> >> Neels Janosch Hofmeyr wrote:> >>> Hi lists,> >>>> >>> I am trying to install cm3 5.4.0 on Ubuntu 7.10. I know that it > >>> worked on 7.4, and am doing the exact same steps. I have now tried > >>> it with cm3-min-...-5.4.0, just as I did last year.> >>>> >>> But now, I get this output:> >>>> >>> neels at oubantu:~/cm3-build/scripts> >>> $ ./install-cm3-compiler.sh upgrade> >>> cp /usr/local/cm3/bin/cm3 /usr/local/cm3/bin/cm3-5.4.0> >>> cp /usr/local/cm3/bin/cm3cg /usr/local/cm3/bin/cm3cg-5.4.0> >>> Segmentation fault (core dumped)> >>> cp /home/neels/cm3-build/m3-sys/cm3/LINUXLIBC6/cm3 > >>> /usr/local/cm3/bin/cm3-> >>> cp /home/neels/cm3-build/m3-sys/m3cc/LINUXLIBC6/cm3cg > >>> /usr/local/cm3/bin/cm3cg-> >>> cp /usr/local/cm3/bin/cm3- /usr/local/cm3/bin/cm3> >>> cp /usr/local/cm3/bin/cm3cg- /usr/local/cm3/bin/cm3cg> >>>> >>> I have done this a second time, making sure everything is cleaned > >>> out and monitored things. From adding a `set -x' in the > >>> install-cm3-compiler.sh, it becomes obvious that > >>> `/usr/local/cm3/bin/cm3 -version' exits with a Segmentation Fault.> >>>> >>> After doing ./cminstall (the minimal binary install), cm3 -version said> >>> $ /usr/local/cm3/bin/cm3 -version> >>> Critical Mass Modula-3 version 5.4.0> >>> last updated: 2006-10-11> >>> configuration: /usr/local/cm3/bin/cm3.cfg> >>>> >>> After doing ./do-cm3-core.sh buildship, it still said the same.> >>> So, somewhere in install-cm3-compiler.sh, a disfunctional cm3 > >>> binary gets installed in /usr/local/cm3/bin/, after which cm3 > >>> yields only segmentation faults.> >>>> >>> After install-cm3-compiler.sh, cm3 -version says> >>> $ /usr/local/cm3/bin/cm3 -version> >>>> >>>> >>> ***> >>> *** runtime error:> >>> *** Segmentation violation - possible attempt to dereference NIL> >>> *** pc = 0x9e841069> >>> ***> >>>> >>> Aborted (core dumped)> >>>> >>> Trying to backtrace in gdb apparently doesn't work -- I don't know > >>> how to compile debugging symbols into it. Giving up.> >>>> >>> I think now is the time to remove the statement "[cm3 is] > >>> easy-to-use [and] easy-to-install" from modula3.elegosoft.com. No > >>> piece of software I have ever encountered is as difficult to use > >>> and as impossible to install as critical mass modula3. I *am* > >>> following all the instructions!> >>>> >>> argh,> >>> Neels> >>>> >>> >> -- > >> Neels Janosch Hofmeyr> >> Software Developer> >>> >> neels at elego.de> >> Public Key: http://binarchy.net/neels/neels.hofmeyr.public.key.asc> >>> >> elego Software Solutions GmbH http://www.elegosoft.com> >> Gustav-Meyer-Allee 25, Geb?ude 12 HRB 77719> >> 13355 Berlin, Germany Amtsgericht Charlottenburg> >> Tel.: +49 30 23 45 86 96 Sitz der Gesellschaft: Berlin> >> Fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Olaf Wagner> >> >> >> > -- > Neels Janosch Hofmeyr> Software Developer> > neels at elego.de> Public Key: http://binarchy.net/neels/neels.hofmeyr.public.key.asc> > elego Software Solutions GmbH http://www.elegosoft.com> Gustav-Meyer-Allee 25, Geb?ude 12 HRB 77719> 13355 Berlin, Germany Amtsgericht Charlottenburg> Tel.: +49 30 23 45 86 96 Sitz der Gesellschaft: Berlin> Fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Olaf Wagner> > _________________________________________________________________ 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 Jan 24 23:35:19 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 24 Jan 2008 23:35:19 +0100 Subject: [M3devel] segmentation fault upon ./install-cm3-compiler.sh upgrade In-Reply-To: <47990CFC.8080609@elego.de> References: <4798FE9B.1090204@elego.de> <479905C8.7080003@elego.de> <20080124230322.vl12nlls4kosoocs@mail.elegosoft.com> <47990CFC.8080609@elego.de> Message-ID: <20080124233519.s3o34cbsmc8kocs8@mail.elegosoft.com> Quoting Neels Janosch Hofmeyr : > Olaf Wagner wrote: >> Quoting Neels Janosch Hofmeyr : >> >>> btw, I am using the "stable release" source tarballs with the 5.4.0 >> >> Hi Neels, >> >> 5.4.0 is rather old now. I assume Ubuntu has made some incompatible >> changes to its kernel or C library interfaces that the old cm3 binary >> cannot cope with. What about trying one the more recent installation >> archives, like d.5.5.1? Once you have a working cm3 and cm3cg, compiling >> the rest should be no problem. Stable releases cannot necessarily be >> expected to run on newer operating systems when the ABI changes, as they >> don't adapt themselves ;-) >> >> Try this, for example: >> >> http://modula3.elegosoft.com/cm3/snaps/cm3-min-POSIX-LINUXLIBC6-d5.5.1-2008-01-24-03-35-01.tgz > I'll try it next. > btw, I am writing an instructions text for installing on ubuntu 7.10 > along the way... >> >> It should also be possible to get a backtrace of the cm3 crash >> within gdb. There should be debugging symbols in the distributed >> binaries. What does bt show? > I tried bt, it shows nothing: > > $ gdb /usr/local/cm3/bin/cm3 > GNU gdb 6.6-debian > Copyright (C) 2006 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and you are > welcome to change it and/or distribute copies of it under certain conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for details. > This GDB was configured as "i486-linux-gnu"... > Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1". > (gdb) run -version > Starting program: /usr/local/cm3/bin/cm3 -version > > Program received signal SIGSEGV, Segmentation fault. > 0x9e841069 in ?? () > (gdb) bt > #0 0x9e841069 in ?? () > Cannot access memory at address 0xf05fc929 > (gdb) Seems to be a random address. My guess would be that Ubuntu now encrypts its jmp_buf data, too, and you are using M3 UTHREADS. Try some runtime arguments to get some more data: @M3debugthreads, @M3nopreemption, @M3novm, @M3nogc Perhaps we get some clues. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Jan 24 23:38:24 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 24 Jan 2008 23:38:24 +0100 Subject: [M3devel] snapshots checksums are missing In-Reply-To: <47990F73.3010707@elego.de> References: <47990F73.3010707@elego.de> Message-ID: <20080124233824.aqrb8ki1kcsww48o@mail.elegosoft.com> Quoting Neels Janosch Hofmeyr : > btw, on > > http://modula3.elegosoft.com/cm3/checksums.php3 > > , I can't find checksums for the daily snapshots. At least not for > > cm3-min-POSIX-LINUXLIBC6-d5.5.1-2008-01-24-03-35-01.tgz > > or any other d5.5.1 tarball There are none so far :-). Are you afraid or is the archive broken? Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From neels at elego.de Thu Jan 24 23:42:11 2008 From: neels at elego.de (Neels Janosch Hofmeyr) Date: Thu, 24 Jan 2008 23:42:11 +0100 Subject: [M3devel] still errors with cm3-min-POSIX-LINUXLIBC6-d5.5.1-2008-01-24-03-35-01 Message-ID: <47991443.2050809@elego.de> Using the cm3-min-POSIX-LINUXLIBC6-d5.5.1-2008-01-24-03-35-01.tgz in conjunction with the 5.4.0 source tarballs, I get, : $ cm3 -version Critical Mass Modula-3 version d5.5.1-2008-01-24-03-35-01 last updated: 2007-12-30 compiled: 2008-01-24 03:54:37 configuration: /usr/local/cm3/bin/cm3.cfg neels at oubantu:~/cm3-build/scripts $ vim ~/cm3-build/m3-libs/m3gc-simple/src/runtime/LINUXLIBC6/sysdeps.c {to remove the asm/ipc.h, as described on the known problems page} neels at oubantu:~/cm3-build/scripts $ ./do-cm3-core.sh buildship CM3C = /home/neels/cm3-build/scripts/pkgmap.sh -c "cm3 -build -DROOT='/home/neels/cm3-build' && cm3 -ship -DROOT='/home/neels/cm3-build' " m3gc-simple m3core libm3 patternmatching m3middle m3linker m3front m3quake m3cc cm3 m3scanner m3tools m3cgcat m3cggen m3bundle bitvector digraph parseparams realgeometry set slisp sortedtableextras table-list tempfiles === package /home/neels/cm3-build/m3-libs/m3gc-simple === +++ cm3 -build -DROOT='/home/neels/cm3-build' && cm3 -ship -DROOT='/home/neels/cm3-build' +++ --- building in LINUXLIBC6 --- new source -> compiling RTVM.c new source -> compiling sysdeps.c -> archiving libm3gcdefs.a --- shipping from LINUXLIBC6 --- . => /usr/local/cm3/pkg/m3gc-simple/LINUXLIBC6 .M3EXPORTS libm3gcdefs.so.5 libm3gcdefs.a libm3gcdefs.m3x .M3WEB ../src/runtime => /usr/local/cm3/pkg/m3gc-simple/src/runtime RTVM.c ../src/runtime/LINUXLIBC6 => /usr/local/cm3/pkg/m3gc-simple/src/runtime/LINUXLIBC6 sysdeps.c . => /usr/local/cm3/lib libm3gcdefs.a ==> /home/neels/cm3-build/m3-libs/m3gc-simple done === package /home/neels/cm3-build/m3-libs/m3core === +++ cm3 -build -DROOT='/home/neels/cm3-build' && cm3 -ship -DROOT='/home/neels/cm3-build' +++ --- building in LINUXLIBC6 --- ignoring ../src/m3overrides new source -> compiling RTHooks.i3 new source -> compiling RT0.i3 new source -> compiling RuntimeError.i3 new source -> compiling Word.i3 new source -> compiling RTException.i3 new source -> compiling RTHooks.m3 new source -> compiling RT0.m3 new source -> compiling Compiler.i3 new source -> compiling RuntimeError.m3 new source -> compiling Compiler.m3 new source -> compiling RTAllocator.i3 new source -> compiling RTType.i3 new source -> compiling Uucontext.i3 new source -> compiling Utypes.i3 new source -> compiling BasicCtypes.i3 new source -> compiling Ctypes.i3 new source -> compiling Usignal.i3 new source -> compiling Csetjmp.i3 new source -> compiling RTMachine.i3 new source -> compiling Upthread.i3 new source -> compiling Utime.i3 new source -> compiling RTHeapDep.i3 new source -> compiling RTHeapRep.i3 new source -> compiling Thread.i3 new source -> compiling FloatMode.i3 new source -> compiling ThreadF.i3 new source -> compiling RTOS.i3 new source -> compiling RTMisc.i3 new source -> compiling RTHeap.i3 new source -> compiling Cstdlib.i3 new source -> compiling Cstddef.i3 new source -> compiling RTAllocCnts.i3 new source -> compiling RTAllocator.m3 new source -> compiling RTAllocStats.i3 new source -> compiling Convert.i3 new source -> compiling TextClass.i3 new source -> compiling Text.i3 new source -> compiling RTProcedureSRC.i3 new source -> compiling Fingerprint.i3 new source -> compiling RTProcedure.i3 new source -> compiling RTStack.i3 new source -> compiling RTAllocStats.m3 "../src/runtime/common/RTAllocStats.m3", line 46: undefined runtime symbol !! (RTHooks.AllocateTracedRef) *** *** runtime error: *** Segmentation violation - possible attempt to dereference NIL *** pc = 0x816f27f = StartCall + 0x19 in ../src/values/Procedure.m3 *** Aborted (core dumped) *** execution of failed *** trying to backtrace yields this: neels at oubantu:~/cm3-build/m3-libs/m3core $ gdb /usr/local/cm3/bin/cm3 GNU gdb 6.6-debian Copyright (C) 2006 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i486-linux-gnu"... (no debugging symbols found) Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1". (gdb) run -build -DROOT='/home/neels/cm3-build' Starting program: /usr/local/cm3/bin/cm3 -build -DROOT='/home/neels/cm3-build' (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) [Thread debugging using libthread_db enabled] [New Thread -1210534224 (LWP 6710)] (no debugging symbols found) [New Thread -1210807408 (LWP 6713)] Program received signal SIG64, Real-time event 64. [Switching to Thread -1210807408 (LWP 6713)] 0xffffe410 in __kernel_vsyscall () (gdb) bt #0 0xffffe410 in __kernel_vsyscall () #1 0xb7ee0676 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/i686/cmov/libpthread.so.0 #2 0x082ac2d0 in ?? () #3 0x08b5c1a0 in ?? () #4 0x08b5c3a8 in ?? () #5 0xb7d48198 in ?? () #6 0x082abeb2 in ?? () #7 0xb7d4a0b0 in ?? () #8 0x082ab578 in ?? () #9 0xb7ede541 in pthread_mutex_lock () from /lib/tls/i686/cmov/libpthread.so.0 #10 0x082ac932 in ?? () #11 0xb7d4a174 in ?? () #12 0xb7d4a0b0 in ?? () #13 0xb7d4a0c0 in ?? () #14 0x00000000 in ?? () (gdb) c Continuing. Program received signal SIG64, Real-time event 64. 0xffffe410 in __kernel_vsyscall () (gdb) c Continuing. --- building in LINUXLIBC6 --- ignoring ../src/m3overrides Program received signal SIG64, Real-time event 64. 0xffffe410 in __kernel_vsyscall () (gdb) c Continuing. Program received signal SIG64, Real-time event 64. 0xffffe410 in __kernel_vsyscall () (gdb) c Continuing. Program received signal SIG64, Real-time event 64. 0xffffe410 in __kernel_vsyscall () (gdb) c Continuing. Program received signal SIG64, Real-time event 64. 0xffffe410 in __kernel_vsyscall () (gdb) c Continuing. Program received signal SIG64, Real-time event 64. 0xffffe410 in __kernel_vsyscall () (gdb) c Continuing. Program received signal SIG64, Real-time event 64. 0xffffe410 in __kernel_vsyscall () (gdb) c Continuing. new source -> compiling RTAllocStats.m3 Program received signal SIG64, Real-time event 64. 0xffffe410 in __kernel_vsyscall () (gdb) c Continuing. Program received signal SIG64, Real-time event 64. 0xffffe410 in __kernel_vsyscall () (gdb) c Continuing. Program received signal SIG64, Real-time event 64. 0xffffe410 in __kernel_vsyscall () (gdb) c Continuing. Program received signal SIG64, Real-time event 64. 0xffffe410 in __kernel_vsyscall () (gdb) c Continuing. "../src/runtime/common/RTAllocStats.m3", line 46: undefined runtime symbol !! (RTHooks.AllocateTracedRef) Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1210534224 (LWP 6710)] 0x0816f27f in ?? () (gdb) c Continuing. *** *** runtime error: *** Segmentation violation - possible attempt to dereference NIL *** pc = 0x816f27f = StartCall + 0x19 in ../src/values/Procedure.m3 *** Program received signal SIGABRT, Aborted. 0xffffe410 in __kernel_vsyscall () (gdb) bt #0 0xffffe410 in __kernel_vsyscall () #1 0xb7db6875 in raise () from /lib/tls/i686/cmov/libc.so.6 #2 0xb7db8201 in abort () from /lib/tls/i686/cmov/libc.so.6 #3 0x082a8daf in ?? () #4 0x080159a4 in ?? () #5 0x082d31a4 in ?? () #6 0xbfe7f578 in ?? () #7 0x0829e3c4 in ?? () #8 0x0000004d in ?? () #9 0x082d31a4 in ?? () #10 0xbfe7f588 in ?? () #11 0x08298aa1 in ?? () #12 0x01b514e0 in ?? () #13 0x082d31a4 in ?? () #14 0xbfe7f598 in ?? () #15 0x0829bd25 in ?? () #16 0x00000000 in ?? () (gdb) c Continuing. Program terminated with signal SIGABRT, Aborted. The program no longer exists. (gdb) This happens both with "-gstabs+" and "-g" in cm3.cfg (Mikas hint reversed). Next, I'll try to checkout the sources from CVS... if that makes any sense. -- Neels Janosch Hofmeyr Software Developer neels at elego.de Public Key: http://binarchy.net/neels/neels.hofmeyr.public.key.asc elego Software Solutions GmbH http://www.elegosoft.com Gustav-Meyer-Allee 25, Geb?ude 12 HRB 77719 13355 Berlin, Germany Amtsgericht Charlottenburg Tel.: +49 30 23 45 86 96 Sitz der Gesellschaft: Berlin Fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Olaf Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From neels at elego.de Thu Jan 24 23:44:58 2008 From: neels at elego.de (Neels Janosch Hofmeyr) Date: Thu, 24 Jan 2008 23:44:58 +0100 Subject: [M3devel] segmentation fault upon ./install-cm3-compiler.sh upgrade In-Reply-To: <20080124233519.s3o34cbsmc8kocs8@mail.elegosoft.com> References: <4798FE9B.1090204@elego.de> <479905C8.7080003@elego.de> <20080124230322.vl12nlls4kosoocs@mail.elegosoft.com> <47990CFC.8080609@elego.de> <20080124233519.s3o34cbsmc8kocs8@mail.elegosoft.com> Message-ID: <479914EA.3060902@elego.de> Olaf Wagner wrote: > > Try some runtime arguments to get some more data: > @M3debugthreads, @M3nopreemption, @M3novm, @M3nogc Sorry, I don't understand... -- Neels Janosch Hofmeyr Software Developer neels at elego.de Public Key: http://binarchy.net/neels/neels.hofmeyr.public.key.asc elego Software Solutions GmbH http://www.elegosoft.com Gustav-Meyer-Allee 25, Geb?ude 12 HRB 77719 13355 Berlin, Germany Amtsgericht Charlottenburg Tel.: +49 30 23 45 86 96 Sitz der Gesellschaft: Berlin Fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Olaf Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From neels at elego.de Thu Jan 24 23:46:03 2008 From: neels at elego.de (Neels Janosch Hofmeyr) Date: Thu, 24 Jan 2008 23:46:03 +0100 Subject: [M3devel] snapshots checksums are missing In-Reply-To: <20080124233824.aqrb8ki1kcsww48o@mail.elegosoft.com> References: <47990F73.3010707@elego.de> <20080124233824.aqrb8ki1kcsww48o@mail.elegosoft.com> Message-ID: <4799152B.2090906@elego.de> Olaf Wagner wrote: > Quoting Neels Janosch Hofmeyr : > >> btw, on >> >> http://modula3.elegosoft.com/cm3/checksums.php3 >> >> , I can't find checksums for the daily snapshots. At least not for >> >> cm3-min-POSIX-LINUXLIBC6-d5.5.1-2008-01-24-03-35-01.tgz >> >> or any other d5.5.1 tarball > > There are none so far :-). Are you afraid or is the archive broken? No, I'm just including the checksums in the instructions text for completeness. Just wanted to double check... nevermind though. -- Neels Janosch Hofmeyr Software Developer neels at elego.de Public Key: http://binarchy.net/neels/neels.hofmeyr.public.key.asc elego Software Solutions GmbH http://www.elegosoft.com Gustav-Meyer-Allee 25, Geb?ude 12 HRB 77719 13355 Berlin, Germany Amtsgericht Charlottenburg Tel.: +49 30 23 45 86 96 Sitz der Gesellschaft: Berlin Fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Olaf Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From hosking at cs.purdue.edu Thu Jan 24 23:46:31 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 24 Jan 2008 17:46:31 -0500 Subject: [M3devel] segmentation fault upon ./install-cm3-compiler.sh upgrade In-Reply-To: <479914EA.3060902@elego.de> References: <4798FE9B.1090204@elego.de> <479905C8.7080003@elego.de> <20080124230322.vl12nlls4kosoocs@mail.elegosoft.com> <47990CFC.8080609@elego.de> <20080124233519.s3o34cbsmc8kocs8@mail.elegosoft.com> <479914EA.3060902@elego.de> Message-ID: <80025F80-FDA6-4E9D-AC2A-73C6498A6EA0@cs.purdue.edu> I'm pretty sure these problems are a result of needing to use a new bootstrap compiler. On Jan 24, 2008, at 5:44 PM, Neels Janosch Hofmeyr wrote: > > > Olaf Wagner wrote: >> >> Try some runtime arguments to get some more data: >> @M3debugthreads, @M3nopreemption, @M3novm, @M3nogc > Sorry, I don't understand... > > -- > Neels Janosch Hofmeyr > Software Developer > > neels at elego.de > Public Key: http://binarchy.net/neels/neels.hofmeyr.public.key.asc > > elego Software Solutions GmbH http://www.elegosoft.com > Gustav-Meyer-Allee 25, Geb?ude 12 HRB 77719 > 13355 Berlin, Germany Amtsgericht Charlottenburg > Tel.: +49 30 23 45 86 96 Sitz der Gesellschaft: Berlin > Fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Olaf Wagner > > From hosking at cs.purdue.edu Thu Jan 24 23:47:24 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 24 Jan 2008 17:47:24 -0500 Subject: [M3devel] still errors with cm3-min-POSIX-LINUXLIBC6-d5.5.1-2008-01-24-03-35-01 In-Reply-To: <47991443.2050809@elego.de> References: <47991443.2050809@elego.de> Message-ID: <0ABA0093-F7F5-440F-98B7-7AFD4317FAC6@cs.purdue.edu> On Jan 24, 2008, at 5:42 PM, Neels Janosch Hofmeyr wrote: > Using the > cm3-min-POSIX-LINUXLIBC6-d5.5.1-2008-01-24-03-35-01.tgz > in conjunction with the 5.4.0 source tarballs, I get, : > > $ cm3 -version > Critical Mass Modula-3 version d5.5.1-2008-01-24-03-35-01 > last updated: 2007-12-30 > compiled: 2008-01-24 03:54:37 > configuration: /usr/local/cm3/bin/cm3.cfg > > neels at oubantu:~/cm3-build/scripts > $ vim ~/cm3-build/m3-libs/m3gc-simple/src/runtime/LINUXLIBC6/sysdeps.c > {to remove the asm/ipc.h, as described on the known problems page} > > neels at oubantu:~/cm3-build/scripts > $ ./do-cm3-core.sh buildship > CM3C = > /home/neels/cm3-build/scripts/pkgmap.sh -c "cm3 -build -DROOT='/ > home/neels/cm3-build' && cm3 -ship -DROOT='/home/neels/cm3-build' > " m3gc-simple m3core libm3 patternmatching m3middle m3linker > m3front m3quake m3cc cm3 m3scanner m3tools m3cgcat m3cggen m3bundle > bitvector digraph parseparams realgeometry set slisp > sortedtableextras table-list tempfiles > === package /home/neels/cm3-build/m3-libs/m3gc-simple === > +++ cm3 -build -DROOT='/home/neels/cm3-build' && cm3 -ship - > DROOT='/home/neels/cm3-build' +++ > --- building in LINUXLIBC6 --- > > new source -> compiling RTVM.c > new source -> compiling sysdeps.c > -> archiving libm3gcdefs.a > --- shipping from LINUXLIBC6 --- > > . => /usr/local/cm3/pkg/m3gc-simple/LINUXLIBC6 > .M3EXPORTS libm3gcdefs.so.5 libm3gcdefs.a libm3gcdefs.m3x > .M3WEB ../src/runtime => /usr/local/cm3/pkg/m3gc-simple/ > src/runtime > RTVM.c ../src/runtime/LINUXLIBC6 => /usr/local/cm3/pkg/ > m3gc-simple/src/runtime/LINUXLIBC6 > sysdeps.c . => /usr/local/cm3/lib > libm3gcdefs.a ==> /home/neels/cm3-build/m3-libs/m3gc-simple done > > === package /home/neels/cm3-build/m3-libs/m3core === > +++ cm3 -build -DROOT='/home/neels/cm3-build' && cm3 -ship - > DROOT='/home/neels/cm3-build' +++ > --- building in LINUXLIBC6 --- > > ignoring ../src/m3overrides > > new source -> compiling RTHooks.i3 > new source -> compiling RT0.i3 > new source -> compiling RuntimeError.i3 > new source -> compiling Word.i3 > new source -> compiling RTException.i3 > new source -> compiling RTHooks.m3 > new source -> compiling RT0.m3 > new source -> compiling Compiler.i3 > new source -> compiling RuntimeError.m3 > new source -> compiling Compiler.m3 > new source -> compiling RTAllocator.i3 > new source -> compiling RTType.i3 > new source -> compiling Uucontext.i3 > new source -> compiling Utypes.i3 > new source -> compiling BasicCtypes.i3 > new source -> compiling Ctypes.i3 > new source -> compiling Usignal.i3 > new source -> compiling Csetjmp.i3 > new source -> compiling RTMachine.i3 > new source -> compiling Upthread.i3 > new source -> compiling Utime.i3 > new source -> compiling RTHeapDep.i3 > new source -> compiling RTHeapRep.i3 > new source -> compiling Thread.i3 > new source -> compiling FloatMode.i3 > new source -> compiling ThreadF.i3 > new source -> compiling RTOS.i3 > new source -> compiling RTMisc.i3 > new source -> compiling RTHeap.i3 > new source -> compiling Cstdlib.i3 > new source -> compiling Cstddef.i3 > new source -> compiling RTAllocCnts.i3 > new source -> compiling RTAllocator.m3 > new source -> compiling RTAllocStats.i3 > new source -> compiling Convert.i3 > new source -> compiling TextClass.i3 > new source -> compiling Text.i3 > new source -> compiling RTProcedureSRC.i3 > new source -> compiling Fingerprint.i3 > new source -> compiling RTProcedure.i3 > new source -> compiling RTStack.i3 > new source -> compiling RTAllocStats.m3 > "../src/runtime/common/RTAllocStats.m3", line 46: undefined runtime > symbol !! This is a new library function: you need newer sources. > (RTHooks.AllocateTracedRef) > > > *** > *** runtime error: > *** Segmentation violation - possible attempt to dereference NIL > *** pc = 0x816f27f = StartCall + 0x19 in ../src/values/Procedure.m3 > *** > > Aborted (core dumped) > *** execution of failed *** > > > trying to backtrace yields this: > > neels at oubantu:~/cm3-build/m3-libs/m3core > $ gdb /usr/local/cm3/bin/cm3 > GNU gdb 6.6-debian > Copyright (C) 2006 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, > and you are > welcome to change it and/or distribute copies of it under certain > conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for > details. > This GDB was configured as "i486-linux-gnu"... > (no debugging symbols found) > Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so. > 1". > (gdb) run -build -DROOT='/home/neels/cm3-build' > Starting program: /usr/local/cm3/bin/cm3 -build -DROOT='/home/ > neels/cm3-build' > (no debugging symbols found) > (no debugging symbols found) > (no debugging symbols found) > (no debugging symbols found) > [Thread debugging using libthread_db enabled] > [New Thread -1210534224 (LWP 6710)] > (no debugging symbols found) > [New Thread -1210807408 (LWP 6713)] > > Program received signal SIG64, Real-time event 64. > [Switching to Thread -1210807408 (LWP 6713)] > 0xffffe410 in __kernel_vsyscall () > (gdb) bt > #0 0xffffe410 in __kernel_vsyscall () > #1 0xb7ee0676 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/ > i686/cmov/libpthread.so.0 > #2 0x082ac2d0 in ?? () > #3 0x08b5c1a0 in ?? () > #4 0x08b5c3a8 in ?? () > #5 0xb7d48198 in ?? () > #6 0x082abeb2 in ?? () > #7 0xb7d4a0b0 in ?? () > #8 0x082ab578 in ?? () > #9 0xb7ede541 in pthread_mutex_lock () from /lib/tls/i686/cmov/ > libpthread.so.0 > #10 0x082ac932 in ?? () > #11 0xb7d4a174 in ?? () > #12 0xb7d4a0b0 in ?? () > #13 0xb7d4a0c0 in ?? () > #14 0x00000000 in ?? () > (gdb) c > Continuing. > > Program received signal SIG64, Real-time event 64. > 0xffffe410 in __kernel_vsyscall () > (gdb) c > Continuing. > --- building in LINUXLIBC6 --- > > ignoring ../src/m3overrides > > > Program received signal SIG64, Real-time event 64. > 0xffffe410 in __kernel_vsyscall () > (gdb) c > Continuing. > > Program received signal SIG64, Real-time event 64. > 0xffffe410 in __kernel_vsyscall () > (gdb) c > Continuing. > > Program received signal SIG64, Real-time event 64. > 0xffffe410 in __kernel_vsyscall () > (gdb) c > Continuing. > > Program received signal SIG64, Real-time event 64. > 0xffffe410 in __kernel_vsyscall () > (gdb) c > Continuing. > > Program received signal SIG64, Real-time event 64. > 0xffffe410 in __kernel_vsyscall () > (gdb) c > Continuing. > > Program received signal SIG64, Real-time event 64. > 0xffffe410 in __kernel_vsyscall () > (gdb) c > Continuing. > new source -> compiling RTAllocStats.m3 > > Program received signal SIG64, Real-time event 64. > 0xffffe410 in __kernel_vsyscall () > (gdb) c > Continuing. > > Program received signal SIG64, Real-time event 64. > 0xffffe410 in __kernel_vsyscall () > (gdb) c > Continuing. > > Program received signal SIG64, Real-time event 64. > 0xffffe410 in __kernel_vsyscall () > (gdb) c > Continuing. > > Program received signal SIG64, Real-time event 64. > 0xffffe410 in __kernel_vsyscall () > (gdb) c > Continuing. > "../src/runtime/common/RTAllocStats.m3", line 46: undefined runtime > symbol !! (RTHooks.AllocateTracedRef) > > Program received signal SIGSEGV, Segmentation fault. > [Switching to Thread -1210534224 (LWP 6710)] > 0x0816f27f in ?? () > (gdb) c > Continuing. > > > *** > *** runtime error: > *** Segmentation violation - possible attempt to dereference NIL > *** pc = 0x816f27f = StartCall + 0x19 in ../src/values/Procedure.m3 > *** > > > Program received signal SIGABRT, Aborted. > 0xffffe410 in __kernel_vsyscall () > (gdb) bt > #0 0xffffe410 in __kernel_vsyscall () > #1 0xb7db6875 in raise () from /lib/tls/i686/cmov/libc.so.6 > #2 0xb7db8201 in abort () from /lib/tls/i686/cmov/libc.so.6 > #3 0x082a8daf in ?? () > #4 0x080159a4 in ?? () > #5 0x082d31a4 in ?? () > #6 0xbfe7f578 in ?? () > #7 0x0829e3c4 in ?? () > #8 0x0000004d in ?? () > #9 0x082d31a4 in ?? () > #10 0xbfe7f588 in ?? () > #11 0x08298aa1 in ?? () > #12 0x01b514e0 in ?? () > #13 0x082d31a4 in ?? () > #14 0xbfe7f598 in ?? () > #15 0x0829bd25 in ?? () > #16 0x00000000 in ?? () > (gdb) c > Continuing. > > Program terminated with signal SIGABRT, Aborted. > The program no longer exists. > (gdb) > > > This happens both with "-gstabs+" and "-g" in cm3.cfg (Mikas hint > reversed). > > Next, I'll try to checkout the sources from CVS... if that makes > any sense. > > -- > Neels Janosch Hofmeyr > Software Developer > > neels at elego.de > Public Key: http://binarchy.net/neels/neels.hofmeyr.public.key.asc > > elego Software Solutions GmbH http://www.elegosoft.com > Gustav-Meyer-Allee 25, Geb?ude 12 HRB 77719 > 13355 Berlin, Germany Amtsgericht Charlottenburg > Tel.: +49 30 23 45 86 96 Sitz der Gesellschaft: Berlin > Fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Olaf Wagner > > From neels at elego.de Thu Jan 24 23:54:24 2008 From: neels at elego.de (Neels Janosch Hofmeyr) Date: Thu, 24 Jan 2008 23:54:24 +0100 Subject: [M3devel] segmentation fault upon ./install-cm3-compiler.sh upgrade In-Reply-To: <80025F80-FDA6-4E9D-AC2A-73C6498A6EA0@cs.purdue.edu> References: <4798FE9B.1090204@elego.de> <479905C8.7080003@elego.de> <20080124230322.vl12nlls4kosoocs@mail.elegosoft.com> <47990CFC.8080609@elego.de> <20080124233519.s3o34cbsmc8kocs8@mail.elegosoft.com> <479914EA.3060902@elego.de> <80025F80-FDA6-4E9D-AC2A-73C6498A6EA0@cs.purdue.edu> Message-ID: <47991720.1030307@elego.de> Tony Hosking wrote: > I'm pretty sure these problems are a result of needing to use a new > bootstrap compiler. How can I build one from source? (does this question make sense?) -- Neels Janosch Hofmeyr Software Developer neels at elego.de Public Key: http://binarchy.net/neels/neels.hofmeyr.public.key.asc elego Software Solutions GmbH http://www.elegosoft.com Gustav-Meyer-Allee 25, Geb?ude 12 HRB 77719 13355 Berlin, Germany Amtsgericht Charlottenburg Tel.: +49 30 23 45 86 96 Sitz der Gesellschaft: Berlin Fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Olaf Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From neels at elego.de Thu Jan 24 23:57:12 2008 From: neels at elego.de (Neels Janosch Hofmeyr) Date: Thu, 24 Jan 2008 23:57:12 +0100 Subject: [M3devel] still errors with cm3-min-POSIX-LINUXLIBC6-d5.5.1-2008-01-24-03-35-01 In-Reply-To: <0ABA0093-F7F5-440F-98B7-7AFD4317FAC6@cs.purdue.edu> References: <47991443.2050809@elego.de> <0ABA0093-F7F5-440F-98B7-7AFD4317FAC6@cs.purdue.edu> Message-ID: <479917C8.1080106@elego.de> Tony Hosking wrote: >> "../src/runtime/common/RTAllocStats.m3", line 46: undefined runtime >> symbol !! > > This is a new library function: you need newer sources. > This seems to do the trick (checked out from CVS)... waiting for the compile to complete. -- Neels Janosch Hofmeyr Software Developer neels at elego.de Public Key: http://binarchy.net/neels/neels.hofmeyr.public.key.asc elego Software Solutions GmbH http://www.elegosoft.com Gustav-Meyer-Allee 25, Geb?ude 12 HRB 77719 13355 Berlin, Germany Amtsgericht Charlottenburg Tel.: +49 30 23 45 86 96 Sitz der Gesellschaft: Berlin Fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Olaf Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From jayk123 at hotmail.com Fri Jan 25 00:02:48 2008 From: jayk123 at hotmail.com (Jay) Date: Thu, 24 Jan 2008 23:02:48 +0000 Subject: [M3devel] segmentation fault upon ./install-cm3-compiler.sh upgrade In-Reply-To: <47991720.1030307@elego.de> References: <4798FE9B.1090204@elego.de> <479905C8.7080003@elego.de> <20080124230322.vl12nlls4kosoocs@mail.elegosoft.com> <47990CFC.8080609@elego.de> <20080124233519.s3o34cbsmc8kocs8@mail.elegosoft.com> <479914EA.3060902@elego.de> <80025F80-FDA6-4E9D-AC2A-73C6498A6EA0@cs.purdue.edu> <47991720.1030307@elego.de> Message-ID: You do it by building the compiler but not building the runtime, upgrade the compiler, rebuild the runtime, rebuild the compiler again clean, update the compiler again. upgrade.sh does this. The thing about @M3novm, @M3debugwhatever, etc. these are command line switches. The Modula-3 runtime (libm3core.so) looks for them and alters its behavior in various ways. For example @M3vm was needed to debug slightly older runtimes without incurrent kind of bogus faults. Anything starting with "@M3" is considered reserved for libm3core.so. - Jay > Date: Thu, 24 Jan 2008 23:54:24 +0100> From: neels at elego.de> To: hosking at cs.purdue.edu> CC: m3devel at elego.de; m3-support at elego.de> Subject: Re: [M3devel] segmentation fault upon ./install-cm3-compiler.sh upgrade> > > Tony Hosking wrote:> > I'm pretty sure these problems are a result of needing to use a new > > bootstrap compiler.> How can I build one from source? (does this question make sense?)> > -- > Neels Janosch Hofmeyr> Software Developer> > neels at elego.de> Public Key: http://binarchy.net/neels/neels.hofmeyr.public.key.asc> > elego Software Solutions GmbH http://www.elegosoft.com> Gustav-Meyer-Allee 25, Geb?ude 12 HRB 77719> 13355 Berlin, Germany Amtsgericht Charlottenburg> Tel.: +49 30 23 45 86 96 Sitz der Gesellschaft: Berlin> Fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Olaf Wagner> > _________________________________________________________________ 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 Fri Jan 25 00:19:27 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 25 Jan 2008 00:19:27 +0100 Subject: [M3devel] snapshots checksums are missing In-Reply-To: <47990F73.3010707@elego.de> References: <47990F73.3010707@elego.de> Message-ID: <20080125001927.92eud7h544gs0csg@mail.elegosoft.com> Quoting Neels Janosch Hofmeyr : > btw, on > > http://modula3.elegosoft.com/cm3/checksums.php3 > > , I can't find checksums for the daily snapshots. At least not for > > cm3-min-POSIX-LINUXLIBC6-d5.5.1-2008-01-24-03-35-01.tgz > > or any other d5.5.1 tarball Fixed :) Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Fri Jan 25 00:53:48 2008 From: rcoleburn at scires.com (Randy Coleburn) Date: Thu, 24 Jan 2008 18:53:48 -0500 Subject: [M3devel] INSTALL_ROOT and PKG_USE in cm3.cfg Message-ID: <4798DEB8.1E75.00D7.1@scires.com> Jay: The cm3.cfg that comes with your minimal binary installation on Windows (NT386) has the following lines: *---------------------------------------- % INSTALL_ROOT = BEGIN_CONFIG % "Where should CM3 be installed?" % 7 %-- user specified install root % END_CONFIG % INSTALL_ROOT = "c:\\cm3" if not defined("INSTALL_ROOT") if not equal ($INSTALLROOT, "") INSTALL_ROOT = $INSTALLROOT else INSTALL_ROOT = (path() & "\\..") end end BIN_INSTALL = INSTALL_ROOT & "\\bin ( file://\bin )" % executables LIB_INSTALL = INSTALL_ROOT & "\\lib ( file://\lib )" % libraries PKG_INSTALL = INSTALL_ROOT & "\\pkg ( file://\pkg )" % packages DOC_INSTALL = INSTALL_ROOT & "\\doc ( file://\doc )" % documents EMACS_INSTALL = INSTALL_ROOT & "\\elisp ( file://\elisp )" % emacs lisp code MAN_INSTALL = INSTALL_ROOT & "\\man ( file://\man )" % man pages HTML_INSTALL = INSTALL_ROOT & "\\www ( file://\www )" % public hypertext % % On some systems (e.g. AFS) you must install public files in a different % place from where you use them. If that is the case for your system, % specify the "use" location here, otherwise leave them alone. % %USE_ROOT = INSTALL_ROOT BIN_USE = BIN_INSTALL % executables LIB_USE = LIB_INSTALL % libraries PKG_USE = PKG_INSTALL % packages *---------------------------------------- Notice that the lines for INSTALL_ROOT and USE_ROOT are commented out. The Reactor program is coded to grab several variables out of cm3.cfg. For example, build_dir := M3Config.Get ("BUILD_DIR"); system_root := M3Config.Get ("PKG_USE"); doc_root := M3Config.Get ("DOC_INSTALL"); initial_browser := M3Config.Get ("INITIAL_CM3_IDE_BROWSER"); initial_editor := M3Config.Get ("INITIAL_CM3_IDE_EDITOR"); What is happening on my installation is that PKG_USE winds up being "\..\PKG". This is not a valid path and it is causing all sorts of trouble for Reactor. The reason it is getting set this way is that the ELSE branch of the, if not defined("INSTALL_ROOT"), is getting executed resulting in INSTALL_ROOT=\.. I'm not sure why this is coded this way. How do you suggest this should be repaired? Note, I have not checked all of the cm3.cfg variants for the other target platforms, but in order for reactor to work properly, it must be able to find a valid "PKG_USE" in the cm3.cfg. Regards, Randy -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Fri Jan 25 01:24:08 2008 From: jayk123 at hotmail.com (Jay) Date: Fri, 25 Jan 2008 00:24:08 +0000 Subject: [M3devel] INSTALL_ROOT and PKG_USE in cm3.cfg In-Reply-To: <4798DEB8.1E75.00D7.1@scires.com> References: <4798DEB8.1E75.00D7.1@scires.com> Message-ID: Blech. My way is more automatic and "portable" in the sense that you can move installations around and they keep working. As well, with my way, you just extract an archive and go, no setup/cminstall, no editing of the cm3.cfg file, just set %PATH% and run vcvars, and vcvars I think I can remove the need for. path() is a builtin Quake function that returns the directory of the currently being run Quake code. But yet Reactor. To unblock yourself, remove my code, add back the commented out, fix the path to match your particular install, don't submit the file. Perhaps move the current checked in file over to the config-no-install directory and then put config's file back in the old style, that requires running cminstall. My workflow will keep working, since it probes for config-no-install first. - Jay Date: Thu, 24 Jan 2008 18:53:48 -0500From: rcoleburn at scires.comTo: jay123 at hotmail.comCC: m3devel at elegosoft.comSubject: [M3devel] INSTALL_ROOT and PKG_USE in cm3.cfg Jay: The cm3.cfg that comes with your minimal binary installation on Windows (NT386) has the following lines: ----------------------------------------- % INSTALL_ROOT = BEGIN_CONFIG% "Where should CM3 be installed?"% 7 %-- user specified install root% END_CONFIG % INSTALL_ROOT = "c:\\cm3" if not defined("INSTALL_ROOT") if not equal ($INSTALLROOT, "") INSTALL_ROOT = $INSTALLROOT else INSTALL_ROOT = (path() & "\\..") endend BIN_INSTALL = INSTALL_ROOT & "\\bin" % executablesLIB_INSTALL = INSTALL_ROOT & "\\lib" % librariesPKG_INSTALL = INSTALL_ROOT & "\\pkg" % packagesDOC_INSTALL = INSTALL_ROOT & "\\doc" % documentsEMACS_INSTALL = INSTALL_ROOT & "\\elisp" % emacs lisp codeMAN_INSTALL = INSTALL_ROOT & "\\man" % man pagesHTML_INSTALL = INSTALL_ROOT & "\\www" % public hypertext %% On some systems (e.g. AFS) you must install public files in a different% place from where you use them. If that is the case for your system,% specify the "use" location here, otherwise leave them alone.%%USE_ROOT = INSTALL_ROOTBIN_USE = BIN_INSTALL % executablesLIB_USE = LIB_INSTALL % librariesPKG_USE = PKG_INSTALL % packages ----------------------------------------- Notice that the lines for INSTALL_ROOT and USE_ROOT are commented out. The Reactor program is coded to grab several variables out of cm3.cfg. For example, build_dir := M3Config.Get ("BUILD_DIR"); system_root := M3Config.Get ("PKG_USE"); doc_root := M3Config.Get ("DOC_INSTALL"); initial_browser := M3Config.Get ("INITIAL_CM3_IDE_BROWSER"); initial_editor := M3Config.Get ("INITIAL_CM3_IDE_EDITOR"); What is happening on my installation is that PKG_USE winds up being "\..\PKG". This is not a valid path and it is causing all sorts of trouble for Reactor. The reason it is getting set this way is that the ELSE branch of the, if not defined("INSTALL_ROOT"), is getting executed resulting in INSTALL_ROOT=\.. I'm not sure why this is coded this way. How do you suggest this should be repaired? Note, I have not checked all of the cm3.cfg variants for the other target platforms, but in order for reactor to work properly, it must be able to find a valid "PKG_USE" in the cm3.cfg. Regards, Randy _________________________________________________________________ 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 neels at elego.de Fri Jan 25 01:45:22 2008 From: neels at elego.de (Neels Janosch Hofmeyr) Date: Fri, 25 Jan 2008 01:45:22 +0100 Subject: [M3devel] CM3 5.5.1 works on Ubuntu 7.10! Message-ID: <47993122.2030201@elego.de> Thanks Olaf, Tony, Mika and Jay, I have cm3 working on Ubuntu 7.10! Complete instructions are given in the attached file. After all, it _does_ look quite simple. But only once you know how. Please let me know if you have any improvements waiting. I'll check this file into the CVS somewhere. We need to add these instructions to modula3.elegosoft.com, so that others do not take the same "shortcuts" I did. If noone else feels like doing it, I will. But right now, it's way past bedtime. All the best, Neels -- Neels Janosch Hofmeyr Software Developer neels at elego.de Public Key: http://binarchy.net/neels/neels.hofmeyr.public.key.asc elego Software Solutions GmbH http://www.elegosoft.com Gustav-Meyer-Allee 25, Geb?ude 12 HRB 77719 13355 Berlin, Germany Amtsgericht Charlottenburg Tel.: +49 30 23 45 86 96 Sitz der Gesellschaft: Berlin Fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Olaf Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: install-cm3-on-ubuntu-7-10.txt Type: application/vnd.ms-powerpoint Size: 9673 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From neels at elego.de Fri Jan 25 01:55:36 2008 From: neels at elego.de (Neels Janosch Hofmeyr) Date: Fri, 25 Jan 2008 01:55:36 +0100 Subject: [M3devel] CM3 5.5.1 works on Ubuntu 7.10! In-Reply-To: <47993122.2030201@elego.de> References: <47993122.2030201@elego.de> Message-ID: <47993388.9030909@elego.de> Well, I've got a change myself. Some libfoo.a need to be libfoo.so for 5.5.1. Wow, does your mail client also think the attachment is a PowerPoint Document? Well, in fact it's a plain ASCII text file. Neels Janosch Hofmeyr wrote: > Thanks Olaf, Tony, Mika and Jay, I have cm3 working on Ubuntu 7.10! > Complete instructions are given in the attached file. After all, it > _does_ look quite simple. But only once you know how. Please let me > know if you have any improvements waiting. I'll check this file into > the CVS somewhere. > > We need to add these instructions to modula3.elegosoft.com, so that > others do not take the same "shortcuts" I did. If noone else feels > like doing it, I will. But right now, it's way past bedtime. > > All the best, > Neels > -- Neels Janosch Hofmeyr Software Developer neels at elego.de Public Key: http://binarchy.net/neels/neels.hofmeyr.public.key.asc elego Software Solutions GmbH http://www.elegosoft.com Gustav-Meyer-Allee 25, Geb?ude 12 HRB 77719 13355 Berlin, Germany Amtsgericht Charlottenburg Tel.: +49 30 23 45 86 96 Sitz der Gesellschaft: Berlin Fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Olaf Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: install-cm3-on-ubuntu-7-10.txt Type: application/vnd.ms-powerpoint Size: 9628 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From rcoleburn at scires.com Fri Jan 25 02:06:09 2008 From: rcoleburn at scires.com (Randy Coleburn) Date: Thu, 24 Jan 2008 20:06:09 -0500 Subject: [M3devel] INSTALL_ROOT and PKG_USE in cm3.cfg In-Reply-To: References: <4798DEB8.1E75.00D7.1@scires.com> Message-ID: <4798EFAE.1E75.00D7.1@scires.com> Jay: That's the reason I asked before making a change. I don't want to break or mess up what you are doing. I can get around the problem easily for me. I just remove the comment from the %INSTALL_ROOT="c:\\cm3" and "everything" is ok. I'm hoping we can come up with a way that works for everyone. Once the CM3_IDE (formerly known as Reactor) package is in the repository and part of the standard distribution, it would be best if folks don't have to go around editing cm3.cfg to make it work properly. Now, you are saying your way is more automatic and portable. I like these words. Is there a way we can set something in cm3.cfg that I can key off of for CM3_IDE/Reactor? I don't mind changing the code to accommodate. The big thing for CM3_IDE/Reactor, is that it needs to know where to look for the cm3 installation because it has to find all of the subdirs, like doc, examples, etc. BTW, I still don't see why all this "works" since I am getting "\.." as my INSTALL_ROOT. Regards, Randy >>> Jay 1/24/2008 7:24 PM >>> Blech. My way is more automatic and "portable" in the sense that you can move installations around and they keep working. As well, with my way, you just extract an archive and go, no setup/cminstall, no editing of the cm3.cfg file, just set %PATH% and run vcvars, and vcvars I think I can remove the need for. path() is a builtin Quake function that returns the directory of the currently being run Quake code. But yet Reactor. To unblock yourself, remove my code, add back the commented out, fix the path to match your particular install, don't submit the file. Perhaps move the current checked in file over to the config-no-install directory and then put config's file back in the old style, that requires running cminstall. My workflow will keep working, since it probes for config-no-install first. - Jay Date: Thu, 24 Jan 2008 18:53:48 -0500 From: rcoleburn at scires.com To: jay123 at hotmail.com CC: m3devel at elegosoft.com Subject: [M3devel] INSTALL_ROOT and PKG_USE in cm3.cfg Jay: The cm3.cfg that comes with your minimal binary installation on Windows (NT386) has the following lines: ----------------------------------------- % INSTALL_ROOT = BEGIN_CONFIG % "Where should CM3 be installed?" % 7 %-- user specified install root % END_CONFIG % INSTALL_ROOT = "c:\\cm3" if not defined("INSTALL_ROOT") if not equal ($INSTALLROOT, "") INSTALL_ROOT = $INSTALLROOT else INSTALL_ROOT = (path() & "\\..") end end BIN_INSTALL = INSTALL_ROOT & "\\bin" % executables LIB_INSTALL = INSTALL_ROOT & "\\lib" % libraries PKG_INSTALL = INSTALL_ROOT & "\\pkg" % packages DOC_INSTALL = INSTALL_ROOT & "\\doc" % documents EMACS_INSTALL = INSTALL_ROOT & "\\elisp" % emacs lisp code MAN_INSTALL = INSTALL_ROOT & "\\man" % man pages HTML_INSTALL = INSTALL_ROOT & "\\www" % public hypertext % % On some systems (e.g. AFS) you must install public files in a different % place from where you use them. If that is the case for your system, % specify the "use" location here, otherwise leave them alone. % %USE_ROOT = INSTALL_ROOT BIN_USE = BIN_INSTALL % executables LIB_USE = LIB_INSTALL % libraries PKG_USE = PKG_INSTALL % packages ----------------------------------------- Notice that the lines for INSTALL_ROOT and USE_ROOT are commented out. The Reactor program is coded to grab several variables out of cm3.cfg. For example, build_dir := M3Config.Get ("BUILD_DIR"); system_root := M3Config.Get ("PKG_USE"); doc_root := M3Config.Get ("DOC_INSTALL"); initial_browser := M3Config.Get ("INITIAL_CM3_IDE_BROWSER"); initial_editor := M3Config.Get ("INITIAL_CM3_IDE_EDITOR"); What is happening on my installation is that PKG_USE winds up being "\..\PKG". This is not a valid path and it is causing all sorts of trouble for Reactor. The reason it is getting set this way is that the ELSE branch of the, if not defined("INSTALL_ROOT"), is getting executed resulting in INSTALL_ROOT=\.. I'm not sure why this is coded this way. How do you suggest this should be repaired? Note, I have not checked all of the cm3.cfg variants for the other target platforms, but in order for reactor to work properly, it must be able to find a valid "PKG_USE" in the cm3.cfg. Regards, Randy 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 jayk123 at hotmail.com Fri Jan 25 02:33:40 2008 From: jayk123 at hotmail.com (Jay) Date: Fri, 25 Jan 2008 01:33:40 +0000 Subject: [M3devel] INSTALL_ROOT and PKG_USE in cm3.cfg In-Reply-To: <4798EFAE.1E75.00D7.1@scires.com> References: <4798DEB8.1E75.00D7.1@scires.com> <4798EFAE.1E75.00D7.1@scires.com> Message-ID: I'm not sure what versions of cm3 have path(). I did think I saw it missing the other day. That could be your problem.m3cgcat also doesn't like my config file, it wants to open it to find TARGET, not sure it uses it at all, but it wants it. When I run mcgcat, I first put back a TARGET line in my cm3.cfg. And then remove it. This is very related. I would suspect that whoever reads the files MIGHT find it acceptable to RUN them. Running them doesn't mean compiling or linking or anything, those are functions that the "host" would chose to call or not. But toplevel can have arbitrary code so maybe this is not great. Reactor is a persistant web server though, right? It should be ok "running" the file, esp. since it doesn't start often. The "normal" alternative that other folks use is to run cminstall, which I find all but useless. In terms of my workflow, you can go ahead and copy NT386 to the config-no-install directory. I'll survive. Randy you should try debugging stuff. Quake is readily debuggabe through printing. if defined("path") write("path is defined") write("path is " & path()) else write("path is not defined") end error("") I put in error so I stop after my printing and don't go and build stuff when my intent was just to run a snippet of Quake. - Jay Date: Thu, 24 Jan 2008 20:06:09 -0500From: rcoleburn at scires.comTo: jay123 at hotmail.com; jayk123 at hotmail.comCC: m3devel at elegosoft.comSubject: RE: [M3devel] INSTALL_ROOT and PKG_USE in cm3.cfg Jay: That's the reason I asked before making a change. I don't want to break or mess up what you are doing. I can get around the problem easily for me. I just remove the comment from the %INSTALL_ROOT="c:\\cm3" and "everything" is ok. I'm hoping we can come up with a way that works for everyone. Once the CM3_IDE (formerly known as Reactor) package is in the repository and part of the standard distribution, it would be best if folks don't have to go around editing cm3.cfg to make it work properly. Now, you are saying your way is more automatic and portable. I like these words. Is there a way we can set something in cm3.cfg that I can key off of for CM3_IDE/Reactor? I don't mind changing the code to accommodate. The big thing for CM3_IDE/Reactor, is that it needs to know where to look for the cm3 installation because it has to find all of the subdirs, like doc, examples, etc. BTW, I still don't see why all this "works" since I am getting "\.." as my INSTALL_ROOT. Regards, Randy>>> Jay 1/24/2008 7:24 PM >>>Blech. My way is more automatic and "portable" in the sense that you can move installations around and they keep working. As well, with my way, you just extract an archive and go, no setup/cminstall, no editing of the cm3.cfg file, just set %PATH% and run vcvars, and vcvars I think I can remove the need for. path() is a builtin Quake function that returns the directory of the currently being run Quake code. But yet Reactor.To unblock yourself, remove my code, add back the commented out, fix the path to match your particular install, don't submit the file. Perhaps move the current checked in file over to the config-no-install directory and then put config's file back in the old style, that requires running cminstall. My workflow will keep working, since it probes for config-no-install first. - Jay Date: Thu, 24 Jan 2008 18:53:48 -0500From: rcoleburn at scires.comTo: jay123 at hotmail.comCC: m3devel at elegosoft.comSubject: [M3devel] INSTALL_ROOT and PKG_USE in cm3.cfg Jay: The cm3.cfg that comes with your minimal binary installation on Windows (NT386) has the following lines: ----------------------------------------- % INSTALL_ROOT = BEGIN_CONFIG% "Where should CM3 be installed?"% 7 %-- user specified install root% END_CONFIG % INSTALL_ROOT = "c:\\cm3" if not defined("INSTALL_ROOT") if not equal ($INSTALLROOT, "") INSTALL_ROOT = $INSTALLROOT else INSTALL_ROOT = (path() & "\\..") endend BIN_INSTALL = INSTALL_ROOT & "\\bin" % executablesLIB_INSTALL = INSTALL_ROOT & "\\lib" % librariesPKG_INSTALL = INSTALL_ROOT & "\\pkg" % packagesDOC_INSTALL = INSTALL_ROOT & "\\doc" % documentsEMACS_INSTALL = INSTALL_ROOT & "\\elisp" % emacs lisp codeMAN_INSTALL = INSTALL_ROOT & "\\man" % man pagesHTML_INSTALL = INSTALL_ROOT & "\\www" % public hypertext %% On some systems (e.g. AFS) you must install public files in a different% place from where you use them. If that is the case for your system,% specify the "use" location here, otherwise leave them alone.%%USE_ROOT = INSTALL_ROOTBIN_USE = BIN_INSTALL % executablesLIB_USE = LIB_INSTALL % librariesPKG_USE = PKG_INSTALL % packages ----------------------------------------- Notice that the lines for INSTALL_ROOT and USE_ROOT are commented out. The Reactor program is coded to grab several variables out of cm3.cfg. For example, build_dir := M3Config.Get ("BUILD_DIR"); system_root := M3Config.Get ("PKG_USE"); doc_root := M3Config.Get ("DOC_INSTALL"); initial_browser := M3Config.Get ("INITIAL_CM3_IDE_BROWSER"); initial_editor := M3Config.Get ("INITIAL_CM3_IDE_EDITOR"); What is happening on my installation is that PKG_USE winds up being "\..\PKG". This is not a valid path and it is causing all sorts of trouble for Reactor. The reason it is getting set this way is that the ELSE branch of the, if not defined("INSTALL_ROOT"), is getting executed resulting in INSTALL_ROOT=\.. I'm not sure why this is coded this way. How do you suggest this should be repaired? Note, I have not checked all of the cm3.cfg variants for the other target platforms, but in order for reactor to work properly, it must be able to find a valid "PKG_USE" in the cm3.cfg. Regards, Randy 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 rodney.bates at wichita.edu Fri Jan 25 02:33:15 2008 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Thu, 24 Jan 2008 19:33:15 -0600 Subject: [M3devel] SIG64 from gdb (was still errors with cm3-min-POSIX-LINUXLIBC6-d5.5.1-2008-01-24-03-35-01) In-Reply-To: <47991443.2050809@elego.de> References: <47991443.2050809@elego.de> Message-ID: <47993C5B.8020505@wichita.edu> See embedded comments at end: Neels Janosch Hofmeyr wrote: > Using the > cm3-min-POSIX-LINUXLIBC6-d5.5.1-2008-01-24-03-35-01.tgz > in conjunction with the 5.4.0 source tarballs, I get, : > ... snip ... > $ cm3 -version > Critical Mass Modula-3 version d5.5.1-2008-01-24-03-35-01 > last updated: 2007-12-30 > compiled: 2008-01-24 03:54:37 > configuration: /usr/local/cm3/bin/cm3.cfg > (gdb) c > Continuing. > > Program received signal SIG64, Real-time event 64. > 0xffffe410 in __kernel_vsyscall () > (gdb) c > Continuing. > --- building in LINUXLIBC6 --- > > ignoring ../src/m3overrides > > > Program received signal SIG64, Real-time event 64. > 0xffffe410 in __kernel_vsyscall () > (gdb) c > Continuing. This is secondary to the original problem, but the SIG64 stops are false stops in gdb. In the phtreads implementation, SIG64 is used internally as a normal event, and you don't want gdb to stop there. (Unless, maybe, you're debugging the use of SIG64 :-) ) To prevent this happening in gdb, type: handle SIG64 nostop noprint pass I checked in an update to m3gdb around Oct. 8, that makes m3gdb adopt this behavior by default, when debugging a program that uses pthreads. From the checkin log text: 6) When PThreads are used, automatically set m3gdb to silently pass SIG64 to the program. Otherwise, this also would cause false stops. -- ------------------------------------------------------------- Rodney 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 Fri Jan 25 03:07:29 2008 From: rcoleburn at scires.com (Randy Coleburn) Date: Thu, 24 Jan 2008 21:07:29 -0500 Subject: [M3devel] INSTALL_ROOT and PKG_USE in cm3.cfg In-Reply-To: References: <4798DEB8.1E75.00D7.1@scires.com> <4798EFAE.1E75.00D7.1@scires.com> Message-ID: <4798FE0E.1E75.00D7.1@scires.com> Jay: Not sure exactly what you mean by: >I'm not sure what versions of cm3 have path(). I did think I saw it missing the other day. I assume you are not referring to the path env variable. Is this some built-in quake function or a function you have written in quake? The version of cm3.cfg that I am using is the one that *you* put in the minimal binary installation for windows. Reactor does indeed "run" the cm3.cfg in that it uses quake to load and interpret this file. What is the significance of doing the copy you suggest below? >In terms of my workflow, you can go ahead and copy NT386 to the config-no-install directory. I'll survive. I'm not trying to be obtuse here. It's just that you have been working on the windows distribution and all these scripts etc for a while now. I don't want to mess up anything you are doing and I know I don't have a deep understanding of all this, so I am reluctant to change anything like cm3.cfg for my needs. My goal is to make the CM3-IDE (old Reactor) available to everyone. As I said before, it does "run" the cm3.cfg and it needs to use this somehow to come up with a valid "PKG_USE" which should point to the "pkg" folder inside the cm3 installation root. Regards, Randy >>> Jay 1/24/2008 8:33 PM >>> I'm not sure what versions of cm3 have path(). I did think I saw it missing the other day. That could be your problem. m3cgcat also doesn't like my config file, it wants to open it to find TARGET, not sure it uses it at all, but it wants it. When I run mcgcat, I first put back a TARGET line in my cm3.cfg. And then remove it. This is very related. I would suspect that whoever reads the files MIGHT find it acceptable to RUN them. Running them doesn't mean compiling or linking or anything, those are functions that the "host" would chose to call or not. But toplevel can have arbitrary code so maybe this is not great. Reactor is a persistant web server though, right? It should be ok "running" the file, esp. since it doesn't start often. The "normal" alternative that other folks use is to run cminstall, which I find all but useless. In terms of my workflow, you can go ahead and copy NT386 to the config-no-install directory. I'll survive. Randy you should try debugging stuff. Quake is readily debuggabe through printing. if defined("path") write("path is defined") write("path is " & path()) else write("path is not defined") end error("") I put in error so I stop after my printing and don't go and build stuff when my intent was just to run a snippet of Quake. - Jay Date: Thu, 24 Jan 2008 20:06:09 -0500 From: rcoleburn at scires.com To: jay123 at hotmail.com; jayk123 at hotmail.com CC: m3devel at elegosoft.com Subject: RE: [M3devel] INSTALL_ROOT and PKG_USE in cm3.cfg Jay: That's the reason I asked before making a change. I don't want to break or mess up what you are doing. I can get around the problem easily for me. I just remove the comment from the %INSTALL_ROOT="c:\\cm3" and "everything" is ok. I'm hoping we can come up with a way that works for everyone. Once the CM3_IDE (formerly known as Reactor) package is in the repository and part of the standard distribution, it would be best if folks don't have to go around editing cm3.cfg to make it work properly. Now, you are saying your way is more automatic and portable. I like these words. Is there a way we can set something in cm3.cfg that I can key off of for CM3_IDE/Reactor? I don't mind changing the code to accommodate. The big thing for CM3_IDE/Reactor, is that it needs to know where to look for the cm3 installation because it has to find all of the subdirs, like doc, examples, etc. BTW, I still don't see why all this "works" since I am getting "\.." as my INSTALL_ROOT. Regards, Randy >>> Jay 1/24/2008 7:24 PM >>> Blech. My way is more automatic and "portable" in the sense that you can move installations around and they keep working. As well, with my way, you just extract an archive and go, no setup/cminstall, no editing of the cm3.cfg file, just set %PATH% and run vcvars, and vcvars I think I can remove the need for. path() is a builtin Quake function that returns the directory of the currently being run Quake code. But yet Reactor. To unblock yourself, remove my code, add back the commented out, fix the path to match your particular install, don't submit the file. Perhaps move the current checked in file over to the config-no-install directory and then put config's file back in the old style, that requires running cminstall. My workflow will keep working, since it probes for config-no-install first. - Jay Date: Thu, 24 Jan 2008 18:53:48 -0500 From: rcoleburn at scires.com To: jay123 at hotmail.com CC: m3devel at elegosoft.com Subject: [M3devel] INSTALL_ROOT and PKG_USE in cm3.cfg Jay: The cm3.cfg that comes with your minimal binary installation on Windows (NT386) has the following lines: ----------------------------------------- % INSTALL_ROOT = BEGIN_CONFIG % "Where should CM3 be installed?" % 7 %-- user specified install root % END_CONFIG % INSTALL_ROOT = "c:\\cm3" if not defined("INSTALL_ROOT") if not equal ($INSTALLROOT, "") INSTALL_ROOT = $INSTALLROOT else INSTALL_ROOT = (path() & "\\..") end end BIN_INSTALL = INSTALL_ROOT & "\\bin" % executables LIB_INSTALL = INSTALL_ROOT & "\\lib" % libraries PKG_INSTALL = INSTALL_ROOT & "\\pkg" % packages DOC_INSTALL = INSTALL_ROOT & "\\doc" % documents EMACS_INSTALL = INSTALL_ROOT & "\\elisp" % emacs lisp code MAN_INSTALL = INSTALL_ROOT & "\\man" % man pages HTML_INSTALL = INSTALL_ROOT & "\\www" % public hypertext % % On some systems (e.g. AFS) you must install public files in a different % place from where you use them. If that is the case for your system, % specify the "use" location here, otherwise leave them alone. % %USE_ROOT = INSTALL_ROOT BIN_USE = BIN_INSTALL % executables LIB_USE = LIB_INSTALL % libraries PKG_USE = PKG_INSTALL % packages ----------------------------------------- Notice that the lines for INSTALL_ROOT and USE_ROOT are commented out. The Reactor program is coded to grab several variables out of cm3.cfg. For example, build_dir := M3Config.Get ("BUILD_DIR"); system_root := M3Config.Get ("PKG_USE"); doc_root := M3Config.Get ("DOC_INSTALL"); initial_browser := M3Config.Get ("INITIAL_CM3_IDE_BROWSER"); initial_editor := M3Config.Get ("INITIAL_CM3_IDE_EDITOR"); What is happening on my installation is that PKG_USE winds up being "\..\PKG". This is not a valid path and it is causing all sorts of trouble for Reactor. The reason it is getting set this way is that the ELSE branch of the, if not defined("INSTALL_ROOT"), is getting executed resulting in INSTALL_ROOT=\.. I'm not sure why this is coded this way. How do you suggest this should be repaired? Note, I have not checked all of the cm3.cfg variants for the other target platforms, but in order for reactor to work properly, it must be able to find a valid "PKG_USE" in the cm3.cfg. Regards, Randy 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 ) 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 jayk123 at hotmail.com Fri Jan 25 03:23:51 2008 From: jayk123 at hotmail.com (Jay) Date: Fri, 25 Jan 2008 02:23:51 +0000 Subject: [M3devel] INSTALL_ROOT and PKG_USE in cm3.cfg In-Reply-To: <4798FE0E.1E75.00D7.1@scires.com> References: <4798DEB8.1E75.00D7.1@scires.com> <4798EFAE.1E75.00D7.1@scires.com> <4798FE0E.1E75.00D7.1@scires.com> Message-ID: Randy, don't worry, whatever you do, I'll be able to recover from. Just try editing your \cm3\bin\cm3.cfg file to say INSTALLROOT="c:\cm3" or whatever. Remove the path() function as a variable. See what happens. Maybe it's the problem, maybe not. It is something that I changed, and is worth trying the old way. Use write() and error() to print the other variables. Can you make the stuff you are working on available? To just some people? - Jay Date: Thu, 24 Jan 2008 21:07:29 -0500From: rcoleburn at scires.comTo: jay123 at hotmail.com; jayk123 at hotmail.comCC: m3devel at elegosoft.comSubject: Re: [M3devel] INSTALL_ROOT and PKG_USE in cm3.cfg Jay: Not sure exactly what you mean by:>I'm not sure what versions of cm3 have path(). I did think I saw it missing the other day. I assume you are not referring to the path env variable. Is this some built-in quake function or a function you have written in quake? The version of cm3.cfg that I am using is the one that *you* put in the minimal binary installation for windows. Reactor does indeed "run" the cm3.cfg in that it uses quake to load and interpret this file. What is the significance of doing the copy you suggest below? >In terms of my workflow, you can go ahead and copy NT386 to the config-no-install directory. I'll survive. I'm not trying to be obtuse here. It's just that you have been working on the windows distribution and all these scripts etc for a while now. I don't want to mess up anything you are doing and I know I don't have a deep understanding of all this, so I am reluctant to change anything like cm3.cfg for my needs. My goal is to make the CM3-IDE (old Reactor) available to everyone. As I said before, it does "run" the cm3.cfg and it needs to use this somehow to come up with a valid "PKG_USE" which should point to the "pkg" folder inside the cm3 installation root. Regards, Randy >>> Jay 1/24/2008 8:33 PM >>>I'm not sure what versions of cm3 have path(). I did think I saw it missing the other day.That could be your problem.m3cgcat also doesn't like my config file, it wants to open it to find TARGET, not sure it uses it at all, but it wants it. When I run mcgcat, I first put back a TARGET line in my cm3.cfg. And then remove it.This is very related.I would suspect that whoever reads the files MIGHT find it acceptable to RUN them.Running them doesn't mean compiling or linking or anything, those are functions that the "host" would chose to call or not. But toplevel can have arbitrary code so maybe this is not great. Reactor is a persistant web server though, right? It should be ok "running" the file, esp. since it doesn't start often. The "normal" alternative that other folks use is to run cminstall, which I find all but useless. In terms of my workflow, you can go ahead and copy NT386 to the config-no-install directory. I'll survive. Randy you should try debugging stuff. Quake is readily debuggabe through printing. if defined("path") write("path is defined") write("path is " & path())else write("path is not defined")enderror("") I put in error so I stop after my printing and don't go and build stuff when my intent was just to run a snippet of Quake. - Jay Date: Thu, 24 Jan 2008 20:06:09 -0500From: rcoleburn at scires.comTo: jay123 at hotmail.com; jayk123 at hotmail.comCC: m3devel at elegosoft.comSubject: RE: [M3devel] INSTALL_ROOT and PKG_USE in cm3.cfg Jay: That's the reason I asked before making a change. I don't want to break or mess up what you are doing. I can get around the problem easily for me. I just remove the comment from the %INSTALL_ROOT="c:\\cm3" and "everything" is ok. I'm hoping we can come up with a way that works for everyone. Once the CM3_IDE (formerly known as Reactor) package is in the repository and part of the standard distribution, it would be best if folks don't have to go around editing cm3.cfg to make it work properly. Now, you are saying your way is more automatic and portable. I like these words. Is there a way we can set something in cm3.cfg that I can key off of for CM3_IDE/Reactor? I don't mind changing the code to accommodate. The big thing for CM3_IDE/Reactor, is that it needs to know where to look for the cm3 installation because it has to find all of the subdirs, like doc, examples, etc. BTW, I still don't see why all this "works" since I am getting "\.." as my INSTALL_ROOT. Regards, Randy>>> Jay 1/24/2008 7:24 PM >>>Blech. My way is more automatic and "portable" in the sense that you can move installations around and they keep working. As well, with my way, you just extract an archive and go, no setup/cminstall, no editing of the cm3.cfg file, just set %PATH% and run vcvars, and vcvars I think I can remove the need for. path() is a builtin Quake function that returns the directory of the currently being run Quake code. But yet Reactor.To unblock yourself, remove my code, add back the commented out, fix the path to match your particular install, don't submit the file. Perhaps move the current checked in file over to the config-no-install directory and then put config's file back in the old style, that requires running cminstall. My workflow will keep working, since it probes for config-no-install first. - Jay Date: Thu, 24 Jan 2008 18:53:48 -0500From: rcoleburn at scires.comTo: jay123 at hotmail.comCC: m3devel at elegosoft.comSubject: [M3devel] INSTALL_ROOT and PKG_USE in cm3.cfg Jay: The cm3.cfg that comes with your minimal binary installation on Windows (NT386) has the following lines: ----------------------------------------- % INSTALL_ROOT = BEGIN_CONFIG% "Where should CM3 be installed?"% 7 %-- user specified install root% END_CONFIG % INSTALL_ROOT = "c:\\cm3" if not defined("INSTALL_ROOT") if not equal ($INSTALLROOT, "") INSTALL_ROOT = $INSTALLROOT else INSTALL_ROOT = (path() & "\\..") endend BIN_INSTALL = INSTALL_ROOT & "\\bin" % executablesLIB_INSTALL = INSTALL_ROOT & "\\lib" % librariesPKG_INSTALL = INSTALL_ROOT & "\\pkg" % packagesDOC_INSTALL = INSTALL_ROOT & "\\doc" % documentsEMACS_INSTALL = INSTALL_ROOT & "\\elisp" % emacs lisp codeMAN_INSTALL = INSTALL_ROOT & "\\man" % man pagesHTML_INSTALL = INSTALL_ROOT & "\\www" % public hypertext %% On some systems (e.g. AFS) you must install public files in a different% place from where you use them. If that is the case for your system,% specify the "use" location here, otherwise leave them alone.%%USE_ROOT = INSTALL_ROOTBIN_USE = BIN_INSTALL % executablesLIB_USE = LIB_INSTALL % librariesPKG_USE = PKG_INSTALL % packages ----------------------------------------- Notice that the lines for INSTALL_ROOT and USE_ROOT are commented out. The Reactor program is coded to grab several variables out of cm3.cfg. For example, build_dir := M3Config.Get ("BUILD_DIR"); system_root := M3Config.Get ("PKG_USE"); doc_root := M3Config.Get ("DOC_INSTALL"); initial_browser := M3Config.Get ("INITIAL_CM3_IDE_BROWSER"); initial_editor := M3Config.Get ("INITIAL_CM3_IDE_EDITOR"); What is happening on my installation is that PKG_USE winds up being "\..\PKG". This is not a valid path and it is causing all sorts of trouble for Reactor. The reason it is getting set this way is that the ELSE branch of the, if not defined("INSTALL_ROOT"), is getting executed resulting in INSTALL_ROOT=\.. I'm not sure why this is coded this way. How do you suggest this should be repaired? Note, I have not checked all of the cm3.cfg variants for the other target platforms, but in order for reactor to work properly, it must be able to find a valid "PKG_USE" in the cm3.cfg. Regards, Randy 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. 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 rcoleburn at scires.com Fri Jan 25 03:48:28 2008 From: rcoleburn at scires.com (Randy Coleburn) Date: Thu, 24 Jan 2008 21:48:28 -0500 Subject: [M3devel] INSTALL_ROOT and PKG_USE in cm3.cfg In-Reply-To: References: <4798DEB8.1E75.00D7.1@scires.com> <4798EFAE.1E75.00D7.1@scires.com> <4798FE0E.1E75.00D7.1@scires.com> Message-ID: <479907A8.1E75.00D7.1@scires.com> Jay: I've already edited my version of cm3.cfg to make it work for me. I don't know what the path() function does. The path() function is only used in the following code: if not defined("INSTALL_ROOT") if not equal ($INSTALLROOT, "") INSTALL_ROOT = $INSTALLROOT else INSTALL_ROOT = (path() & "\\..") end end Since this code is not executed when I define INSTALL_ROOT as "c:\\cm3", there is no need to remove it for my use. I've already confirmed that the other variables I need get set correctly inside CM3-IDE/Reactor once the INSTALL_ROOT is set properly. Note that a bunch of variables inside cm3.cfg depend on INSTALL_ROOT. I'm still want to find a solution for the general user population. Regards, Randy >>> Jay 1/24/2008 9:23 PM >>> Randy, don't worry, whatever you do, I'll be able to recover from. Just try editing your \cm3\bin\cm3.cfg file to say INSTALLROOT="c:\cm3" or whatever. Remove the path() function as a variable. See what happens. Maybe it's the problem, maybe not. It is something that I changed, and is worth trying the old way. Use write() and error() to print the other variables. Can you make the stuff you are working on available? To just some people? - Jay Date: Thu, 24 Jan 2008 21:07:29 -0500 From: rcoleburn at scires.com To: jay123 at hotmail.com; jayk123 at hotmail.com CC: m3devel at elegosoft.com Subject: Re: [M3devel] INSTALL_ROOT and PKG_USE in cm3.cfg Jay: Not sure exactly what you mean by: >I'm not sure what versions of cm3 have path(). I did think I saw it missing the other day. I assume you are not referring to the path env variable. Is this some built-in quake function or a function you have written in quake? The version of cm3.cfg that I am using is the one that *you* put in the minimal binary installation for windows. Reactor does indeed "run" the cm3.cfg in that it uses quake to load and interpret this file. What is the significance of doing the copy you suggest below? >In terms of my workflow, you can go ahead and copy NT386 to the config-no-install directory. I'll survive. I'm not trying to be obtuse here. It's just that you have been working on the windows distribution and all these scripts etc for a while now. I don't want to mess up anything you are doing and I know I don't have a deep understanding of all this, so I am reluctant to change anything like cm3.cfg for my needs. My goal is to make the CM3-IDE (old Reactor) available to everyone. As I said before, it does "run" the cm3.cfg and it needs to use this somehow to come up with a valid "PKG_USE" which should point to the "pkg" folder inside the cm3 installation root. Regards, Randy >>> Jay 1/24/2008 8:33 PM >>> I'm not sure what versions of cm3 have path(). I did think I saw it missing the other day. That could be your problem. m3cgcat also doesn't like my config file, it wants to open it to find TARGET, not sure it uses it at all, but it wants it. When I run mcgcat, I first put back a TARGET line in my cm3.cfg. And then remove it. This is very related. I would suspect that whoever reads the files MIGHT find it acceptable to RUN them. Running them doesn't mean compiling or linking or anything, those are functions that the "host" would chose to call or not. But toplevel can have arbitrary code so maybe this is not great. Reactor is a persistant web server though, right? It should be ok "running" the file, esp. since it doesn't start often. The "normal" alternative that other folks use is to run cminstall, which I find all but useless. In terms of my workflow, you can go ahead and copy NT386 to the config-no-install directory. I'll survive. Randy you should try debugging stuff. Quake is readily debuggabe through printing. if defined("path") write("path is defined") write("path is " & path()) else write("path is not defined") end error("") I put in error so I stop after my printing and don't go and build stuff when my intent was just to run a snippet of Quake. - Jay Date: Thu, 24 Jan 2008 20:06:09 -0500 From: rcoleburn at scires.com To: jay123 at hotmail.com; jayk123 at hotmail.com CC: m3devel at elegosoft.com Subject: RE: [M3devel] INSTALL_ROOT and PKG_USE in cm3.cfg Jay: That's the reason I asked before making a change. I don't want to break or mess up what you are doing. I can get around the problem easily for me. I just remove the comment from the %INSTALL_ROOT="c:\\cm3" and "everything" is ok. I'm hoping we can come up with a way that works for everyone. Once the CM3_IDE (formerly known as Reactor) package is in the repository and part of the standard distribution, it would be best if folks don't have to go around editing cm3.cfg to make it work properly. Now, you are saying your way is more automatic and portable. I like these words. Is there a way we can set something in cm3.cfg that I can key off of for CM3_IDE/Reactor? I don't mind changing the code to accommodate. The big thing for CM3_IDE/Reactor, is that it needs to know where to look for the cm3 installation because it has to find all of the subdirs, like doc, examples, etc. BTW, I still don't see why all this "works" since I am getting "\.." as my INSTALL_ROOT. Regards, Randy >>> Jay 1/24/2008 7:24 PM >>> Blech. My way is more automatic and "portable" in the sense that you can move installations around and they keep working. As well, with my way, you just extract an archive and go, no setup/cminstall, no editing of the cm3.cfg file, just set %PATH% and run vcvars, and vcvars I think I can remove the need for. path() is a builtin Quake function that returns the directory of the currently being run Quake code. But yet Reactor. To unblock yourself, remove my code, add back the commented out, fix the path to match your particular install, don't submit the file. Perhaps move the current checked in file over to the config-no-install directory and then put config's file back in the old style, that requires running cminstall. My workflow will keep working, since it probes for config-no-install first. - Jay Date: Thu, 24 Jan 2008 18:53:48 -0500 From: rcoleburn at scires.com To: jay123 at hotmail.com CC: m3devel at elegosoft.com Subject: [M3devel] INSTALL_ROOT and PKG_USE in cm3.cfg Jay: The cm3.cfg that comes with your minimal binary installation on Windows (NT386) has the following lines: ----------------------------------------- % INSTALL_ROOT = BEGIN_CONFIG % "Where should CM3 be installed?" % 7 %-- user specified install root % END_CONFIG % INSTALL_ROOT = "c:\\cm3" if not defined("INSTALL_ROOT") if not equal ($INSTALLROOT, "") INSTALL_ROOT = $INSTALLROOT else INSTALL_ROOT = (path() & "\\..") end end BIN_INSTALL = INSTALL_ROOT & "\\bin" % executables LIB_INSTALL = INSTALL_ROOT & "\\lib" % libraries PKG_INSTALL = INSTALL_ROOT & "\\pkg" % packages DOC_INSTALL = INSTALL_ROOT & "\\doc" % documents EMACS_INSTALL = INSTALL_ROOT & "\\elisp" % emacs lisp code MAN_INSTALL = INSTALL_ROOT & "\\man" % man pages HTML_INSTALL = INSTALL_ROOT & "\\www" % public hypertext % % On some systems (e.g. AFS) you must install public files in a different % place from where you use them. If that is the case for your system, % specify the "use" location here, otherwise leave them alone. % %USE_ROOT = INSTALL_ROOT BIN_USE = BIN_INSTALL % executables LIB_USE = LIB_INSTALL % libraries PKG_USE = PKG_INSTALL % packages ----------------------------------------- Notice that the lines for INSTALL_ROOT and USE_ROOT are commented out. The Reactor program is coded to grab several variables out of cm3.cfg. For example, build_dir := M3Config.Get ("BUILD_DIR"); system_root := M3Config.Get ("PKG_USE"); doc_root := M3Config.Get ("DOC_INSTALL"); initial_browser := M3Config.Get ("INITIAL_CM3_IDE_BROWSER"); initial_editor := M3Config.Get ("INITIAL_CM3_IDE_EDITOR"); What is happening on my installation is that PKG_USE winds up being "\..\PKG". This is not a valid path and it is causing all sorts of trouble for Reactor. The reason it is getting set this way is that the ELSE branch of the, if not defined("INSTALL_ROOT"), is getting executed resulting in INSTALL_ROOT=\.. I'm not sure why this is coded this way. How do you suggest this should be repaired? Note, I have not checked all of the cm3.cfg variants for the other target platforms, but in order for reactor to work properly, it must be able to find a valid "PKG_USE" in the cm3.cfg. Regards, Randy 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 ) 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 ) 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 ) -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcoleburn at scires.com Fri Jan 25 06:07:28 2008 From: rcoleburn at scires.com (Randy Coleburn) Date: Fri, 25 Jan 2008 00:07:28 -0500 Subject: [M3devel] INSTALL_ROOT and PKG_USE in cm3.cfg In-Reply-To: References: <4798DEB8.1E75.00D7.1@scires.com> <4798EFAE.1E75.00D7.1@scires.com> <4798FE0E.1E75.00D7.1@scires.com> <479907A8.1E75.00D7.1@scires.com> Message-ID: <4799283C.1E75.00D7.1@scires.com> Jay: Based on your description of path(), I don't think it is working correctly. My INSTALL_ROOT is turning up as "\.." instead of "C:\cm3\bin\.." If this path() function worked as advertised, I think your solution might work. Reactor/CM3-IDE is running from C:\cm3\bin, so when it uses quake to evaluate cm3.cfg, shouldn't it come up with "C:\cm3\bin\.." for the path? Maybe it does, and if so, then the ".." in the path may be confusing internally when it tries to make paths like "C:\cm3\bin\..\pkg". I don't know. Just a thought. Regards, Randy >>> Jay 1/24/2008 11:44 PM >>> 1) the general user population could revert back to cminstall; nobody else complained except me (a common occurence), and Olaf did improve it; I'd have to deign to putting together such a distribution yuck. Perhaps when a nice GUI installer comes along it won't feel so bad. 2) Again, can you make the stuff you are working on available? To just some people? path() returns the directory of the currently executing Quake code. And in this case, the file is in the directory that contains cm3.exe, so it is cm3.exe's directory, which we know is INSTALLROOT\bin, so go up one with .. and we have INSTALLROOT. It's a little unsightly to have ".." in all the resulting paths, but I think it is worth it. It could be fixed in a number of ways. 1) add a function PathDotDot or PathUp to cm3 2) more generally add a function PathCanonicalize to cm3. Or heck, move more and more of this stuff into cm3. I asked about this recently -- what are the requirements for compatibility with older tools. It is that unanswered, and presuming "the worst", besides my persistant distaste for Modula-3, that keeps me writing Quake code.. - Jay Date: Thu, 24 Jan 2008 21:48:28 -0500 From: rcoleburn at scires.com To: jay123 at hotmail.com; jayk123 at hotmail.com CC: m3devel at elegosoft.com Subject: Re: [M3devel] INSTALL_ROOT and PKG_USE in cm3.cfg Jay: I've already edited my version of cm3.cfg to make it work for me. I don't know what the path() function does. The path() function is only used in the following code: if not defined("INSTALL_ROOT") if not equal ($INSTALLROOT, "") INSTALL_ROOT = $INSTALLROOT else INSTALL_ROOT = (path() & "\\..") end end Since this code is not executed when I define INSTALL_ROOT as "c:\\cm3", there is no need to remove it for my use. I've already confirmed that the other variables I need get set correctly inside CM3-IDE/Reactor once the INSTALL_ROOT is set properly. Note that a bunch of variables inside cm3.cfg depend on INSTALL_ROOT. I'm still want to find a solution for the general user population. Regards, Randy >>> Jay 1/24/2008 9:23 PM >>> Randy, don't worry, whatever you do, I'll be able to recover from. Just try editing your \cm3\bin\cm3.cfg file to say INSTALLROOT="c:\cm3" or whatever. Remove the path() function as a variable. See what happens. Maybe it's the problem, maybe not. It is something that I changed, and is worth trying the old way. Use write() and error() to print the other variables. Can you make the stuff you are working on available? To just some people? - Jay Date: Thu, 24 Jan 2008 21:07:29 -0500 From: rcoleburn at scires.com To: jay123 at hotmail.com; jayk123 at hotmail.com CC: m3devel at elegosoft.com Subject: Re: [M3devel] INSTALL_ROOT and PKG_USE in cm3.cfg Jay: Not sure exactly what you mean by: >I'm not sure what versions of cm3 have path(). I did think I saw it missing the other day. I assume you are not referring to the path env variable. Is this some built-in quake function or a function you have written in quake? The version of cm3.cfg that I am using is the one that *you* put in the minimal binary installation for windows. Reactor does indeed "run" the cm3.cfg in that it uses quake to load and interpret this file. What is the significance of doing the copy you suggest below? >In terms of my workflow, you can go ahead and copy NT386 to the config-no-install directory. I'll survive. I'm not trying to be obtuse here. It's just that you have been working on the windows distribution and all these scripts etc for a while now. I don't want to mess up anything you are doing and I know I don't have a deep understanding of all this, so I am reluctant to change anything like cm3.cfg for my needs. My goal is to make the CM3-IDE (old Reactor) available to everyone. As I said before, it does "run" the cm3.cfg and it needs to use this somehow to come up with a valid "PKG_USE" which should point to the "pkg" folder inside the cm3 installation root. Regards, Randy >>> Jay 1/24/2008 8:33 PM >>> I'm not sure what versions of cm3 have path(). I did think I saw it missing the other day. That could be your problem. m3cgcat also doesn't like my config file, it wants to open it to find TARGET, not sure it uses it at all, but it wants it. When I run mcgcat, I first put back a TARGET line in my cm3.cfg. And then remove it. This is very related. I would suspect that whoever reads the files MIGHT find it acceptable to RUN them. Running them doesn't mean compiling or linking or anything, those are functions that the "host" would chose to call or not. But toplevel can have arbitrary code so maybe this is not great. Reactor is a persistant web server though, right? It should be ok "running" the file, esp. since it doesn't start often. The "normal" alternative that other folks use is to run cminstall, which I find all but useless. In terms of my workflow, you can go ahead and copy NT386 to the config-no-install directory. I'll survive. Randy you should try debugging stuff. Quake is readily debuggabe through printing. if defined("path") write("path is defined") write("path is " & path()) else write("path is not defined") end error("") I put in error so I stop after my printing and don't go and build stuff when my intent was just to run a snippet of Quake. - Jay Date: Thu, 24 Jan 2008 20:06:09 -0500 From: rcoleburn at scires.com To: jay123 at hotmail.com; jayk123 at hotmail.com CC: m3devel at elegosoft.com Subject: RE: [M3devel] INSTALL_ROOT and PKG_USE in cm3.cfg Jay: That's the reason I asked before making a change. I don't want to break or mess up what you are doing. I can get around the problem easily for me. I just remove the comment from the %INSTALL_ROOT="c:\\cm3" and "everything" is ok. I'm hoping we can come up with a way that works for everyone. Once the CM3_IDE (formerly known as Reactor) package is in the repository and part of the standard distribution, it would be best if folks don't have to go around editing cm3.cfg to make it work properly. Now, you are saying your way is more automatic and portable. I like these words. Is there a way we can set something in cm3.cfg that I can key off of for CM3_IDE/Reactor? I don't mind changing the code to accommodate. The big thing for CM3_IDE/Reactor, is that it needs to know where to look for the cm3 installation because it has to find all of the subdirs, like doc, examples, etc. BTW, I still don't see why all this "works" since I am getting "\.." as my INSTALL_ROOT. Regards, Randy >>> Jay 1/24/2008 7:24 PM >>> Blech. My way is more automatic and "portable" in the sense that you can move installations around and they keep working. As well, with my way, you just extract an archive and go, no setup/cminstall, no editing of the cm3.cfg file, just set %PATH% and run vcvars, and vcvars I think I can remove the need for. path() is a builtin Quake function that returns the directory of the currently being run Quake code. But yet Reactor. To unblock yourself, remove my code, add back the commented out, fix the path to match your particular install, don't submit the file. Perhaps move the current checked in file over to the config-no-install directory and then put config's file back in the old style, that requires running cminstall. My workflow will keep working, since it probes for config-no-install first. - Jay Date: Thu, 24 Jan 2008 18:53:48 -0500 From: rcoleburn at scires.com To: jay123 at hotmail.com CC: m3devel at elegosoft.com Subject: [M3devel] INSTALL_ROOT and PKG_USE in cm3.cfg Jay: The cm3.cfg that comes with your minimal binary installation on Windows (NT386) has the following lines: ----------------------------------------- % INSTALL_ROOT = BEGIN_CONFIG % "Where should CM3 be installed?" % 7 %-- user specified install root % END_CONFIG % INSTALL_ROOT = "c:\\cm3" if not defined("INSTALL_ROOT") if not equal ($INSTALLROOT, "") INSTALL_ROOT = $INSTALLROOT else INSTALL_ROOT = (path() & "\\..") end end BIN_INSTALL = INSTALL_ROOT & "\\bin" % executables LIB_INSTALL = INSTALL_ROOT & "\\lib" % libraries PKG_INSTALL = INSTALL_ROOT & "\\pkg" % packages DOC_INSTALL = INSTALL_ROOT & "\\doc" % documents EMACS_INSTALL = INSTALL_ROOT & "\\elisp" % emacs lisp code MAN_INSTALL = INSTALL_ROOT & "\\man" % man pages HTML_INSTALL = INSTALL_ROOT & "\\www" % public hypertext % % On some systems (e.g. AFS) you must install public files in a different % place from where you use them. If that is the case for your system, % specify the "use" location here, otherwise leave them alone. % %USE_ROOT = INSTALL_ROOT BIN_USE = BIN_INSTALL % executables LIB_USE = LIB_INSTALL % libraries PKG_USE = PKG_INSTALL % packages ----------------------------------------- Notice that the lines for INSTALL_ROOT and USE_ROOT are commented out. The Reactor program is coded to grab several variables out of cm3.cfg. For example, build_dir := M3Config.Get ("BUILD_DIR"); system_root := M3Config.Get ("PKG_USE"); doc_root := M3Config.Get ("DOC_INSTALL"); initial_browser := M3Config.Get ("INITIAL_CM3_IDE_BROWSER"); initial_editor := M3Config.Get ("INITIAL_CM3_IDE_EDITOR"); What is happening on my installation is that PKG_USE winds up being "\..\PKG". This is not a valid path and it is causing all sorts of trouble for Reactor. The reason it is getting set this way is that the ELSE branch of the, if not defined("INSTALL_ROOT"), is getting executed resulting in INSTALL_ROOT=\.. I'm not sure why this is coded this way. How do you suggest this should be repaired? Note, I have not checked all of the cm3.cfg variants for the other target platforms, but in order for reactor to work properly, it must be able to find a valid "PKG_USE" in the cm3.cfg. Regards, Randy 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 ) 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 ) 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 ) 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 ) -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Fri Jan 25 06:19:31 2008 From: jayk123 at hotmail.com (Jay) Date: Fri, 25 Jan 2008 05:19:31 +0000 Subject: [M3devel] INSTALL_ROOT and PKG_USE in cm3.cfg In-Reply-To: <4799283C.1E75.00D7.1@scires.com> References: <4798DEB8.1E75.00D7.1@scires.com> <4798EFAE.1E75.00D7.1@scires.com> <4798FE0E.1E75.00D7.1@scires.com> <479907A8.1E75.00D7.1@scires.com> <4799283C.1E75.00D7.1@scires.com> Message-ID: >> shouldn't it come up with "C:\cm3\bin\.." for the path? Correct. >> be confusing internally when it tries to make paths like "C:\cm3\bin\..\pkg". I don't know. Just a thought No. It works fine. I've been building this way a while now, no problems. YOU built this way I believe, just not using Reactor. It looks a little ugly if you see it, I admit, but it's worth it. I usually bootstrap from circa 5.1.6 and surely from 5.5.0 or .1 itself. I had been bootstrapping from something in between but haven't lately. So I can't vouch for all that many builds. I'm also using this code on PPC_LINUX and PPC_DARWIN (should be called PPC_MACOSX but oh well) successfully (look in m3-sys\cminstall\src\config-no-install). I have seen path() return empty with some older builds, but not with current builds. Where I have seen it, I added in if defined() to cope and something more that I forget, maybe just the "normal" thing, like to bootstrap from an older build, and it gets overwritten during the bootstrap, once there is a current cm3.exe. I should check, I should check the history, and consistently workaround for all the files with this construct (ie. config-no-install and NT386). The documentation says it returns the path or directory of cm3.exe. But I did find that to be false, but the function is still useful. It seems to return the path of the current Quake code. I haven't looked at the implementation (yet). Something is different in the Reactor path. >>> 2) Again again, can you make the stuff you are working on available? To just some people? ? - Jay Date: Fri, 25 Jan 2008 00:07:28 -0500From: rcoleburn at scires.comTo: jay123 at hotmail.com; jayk123 at hotmail.comCC: m3devel at elegosoft.comSubject: RE: [M3devel] INSTALL_ROOT and PKG_USE in cm3.cfg Jay: Based on your description of path(), I don't think it is working correctly. My INSTALL_ROOT is turning up as "\.." instead of "C:\cm3\bin\.." If this path() function worked as advertised, I think your solution might work. Reactor/CM3-IDE is running from C:\cm3\bin, so when it uses quake to evaluate cm3.cfg, shouldn't it come up with "C:\cm3\bin\.." for the path? Maybe it does, and if so, then the ".." in the path may be confusing internally when it tries to make paths like "C:\cm3\bin\..\pkg". I don't know. Just a thought. Regards, Randy>>> Jay 1/24/2008 11:44 PM >>>1) the general user population could revert back to cminstall; nobody else complained except me (a common occurence), and Olaf did improve it; I'd have to deign to putting together such a distribution yuck. Perhaps when a nice GUI installer comes along it won't feel so bad.2) Again, can you make the stuff you are working on available? To just some people? path() returns the directory of the currently executing Quake code.And in this case, the file is in the directory that contains cm3.exe, so it is cm3.exe's directory, which we know is INSTALLROOT\bin, so go up one with .. and we have INSTALLROOT. It's a little unsightly to have ".." in all the resulting paths, but I think it is worth it. It could be fixed in a number of ways. 1) add a function PathDotDot or PathUp to cm3 2) more generally add a function PathCanonicalize to cm3. Or heck, move more and more of this stuff into cm3. I asked about this recently -- what are the requirements for compatibility with older tools. It is that unanswered, and presuming "the worst", besides my persistant distaste for Modula-3, that keeps me writing Quake code.. - Jay Date: Thu, 24 Jan 2008 21:48:28 -0500From: rcoleburn at scires.comTo: jay123 at hotmail.com; jayk123 at hotmail.comCC: m3devel at elegosoft.comSubject: Re: [M3devel] INSTALL_ROOT and PKG_USE in cm3.cfg Jay: I've already edited my version of cm3.cfg to make it work for me. I don't know what the path() function does. The path() function is only used in the following code: if not defined("INSTALL_ROOT") if not equal ($INSTALLROOT, "") INSTALL_ROOT = $INSTALLROOT else INSTALL_ROOT = (path() & "\\..") endend Since this code is not executed when I define INSTALL_ROOT as "c:\\cm3", there is no need to remove it for my use. I've already confirmed that the other variables I need get set correctly inside CM3-IDE/Reactor once the INSTALL_ROOT is set properly. Note that a bunch of variables inside cm3.cfg depend on INSTALL_ROOT. I'm still want to find a solution for the general user population. Regards, Randy>>> Jay 1/24/2008 9:23 PM >>>Randy, don't worry, whatever you do, I'll be able to recover from. Just try editing your \cm3\bin\cm3.cfg file to say INSTALLROOT="c:\cm3" or whatever.Remove the path() function as a variable.See what happens. Maybe it's the problem, maybe not. It is something that I changed, and is worth trying the old way. Use write() and error() to print the other variables. Can you make the stuff you are working on available? To just some people? - Jay Date: Thu, 24 Jan 2008 21:07:29 -0500From: rcoleburn at scires.comTo: jay123 at hotmail.com; jayk123 at hotmail.comCC: m3devel at elegosoft.comSubject: Re: [M3devel] INSTALL_ROOT and PKG_USE in cm3.cfg Jay: Not sure exactly what you mean by:>I'm not sure what versions of cm3 have path(). I did think I saw it missing the other day. I assume you are not referring to the path env variable. Is this some built-in quake function or a function you have written in quake? The version of cm3.cfg that I am using is the one that *you* put in the minimal binary installation for windows. Reactor does indeed "run" the cm3.cfg in that it uses quake to load and interpret this file. What is the significance of doing the copy you suggest below? >In terms of my workflow, you can go ahead and copy NT386 to the config-no-install directory. I'll survive. I'm not trying to be obtuse here. It's just that you have been working on the windows distribution and all these scripts etc for a while now. I don't want to mess up anything you are doing and I know I don't have a deep understanding of all this, so I am reluctant to change anything like cm3.cfg for my needs. My goal is to make the CM3-IDE (old Reactor) available to everyone. As I said before, it does "run" the cm3.cfg and it needs to use this somehow to come up with a valid "PKG_USE" which should point to the "pkg" folder inside the cm3 installation root. Regards, Randy >>> Jay 1/24/2008 8:33 PM >>>I'm not sure what versions of cm3 have path(). I did think I saw it missing the other day.That could be your problem.m3cgcat also doesn't like my config file, it wants to open it to find TARGET, not sure it uses it at all, but it wants it. When I run mcgcat, I first put back a TARGET line in my cm3.cfg. And then remove it.This is very related.I would suspect that whoever reads the files MIGHT find it acceptable to RUN them.Running them doesn't mean compiling or linking or anything, those are functions that the "host" would chose to call or not. But toplevel can have arbitrary code so maybe this is not great. Reactor is a persistant web server though, right? It should be ok "running" the file, esp. since it doesn't start often. The "normal" alternative that other folks use is to run cminstall, which I find all but useless. In terms of my workflow, you can go ahead and copy NT386 to the config-no-install directory. I'll survive. Randy you should try debugging stuff. Quake is readily debuggabe through printing. if defined("path") write("path is defined") write("path is " & path())else write("path is not defined")enderror("") I put in error so I stop after my printing and don't go and build stuff when my intent was just to run a snippet of Quake. - Jay Date: Thu, 24 Jan 2008 20:06:09 -0500From: rcoleburn at scires.comTo: jay123 at hotmail.com; jayk123 at hotmail.comCC: m3devel at elegosoft.comSubject: RE: [M3devel] INSTALL_ROOT and PKG_USE in cm3.cfg Jay: That's the reason I asked before making a change. I don't want to break or mess up what you are doing. I can get around the problem easily for me. I just remove the comment from the %INSTALL_ROOT="c:\\cm3" and "everything" is ok. I'm hoping we can come up with a way that works for everyone. Once the CM3_IDE (formerly known as Reactor) package is in the repository and part of the standard distribution, it would be best if folks don't have to go around editing cm3.cfg to make it work properly. Now, you are saying your way is more automatic and portable. I like these words. Is there a way we can set something in cm3.cfg that I can key off of for CM3_IDE/Reactor? I don't mind changing the code to accommodate. The big thing for CM3_IDE/Reactor, is that it needs to know where to look for the cm3 installation because it has to find all of the subdirs, like doc, examples, etc. BTW, I still don't see why all this "works" since I am getting "\.." as my INSTALL_ROOT. Regards, Randy>>> Jay 1/24/2008 7:24 PM >>>Blech. My way is more automatic and "portable" in the sense that you can move installations around and they keep working. As well, with my way, you just extract an archive and go, no setup/cminstall, no editing of the cm3.cfg file, just set %PATH% and run vcvars, and vcvars I think I can remove the need for. path() is a builtin Quake function that returns the directory of the currently being run Quake code. But yet Reactor.To unblock yourself, remove my code, add back the commented out, fix the path to match your particular install, don't submit the file. Perhaps move the current checked in file over to the config-no-install directory and then put config's file back in the old style, that requires running cminstall. My workflow will keep working, since it probes for config-no-install first. - Jay Date: Thu, 24 Jan 2008 18:53:48 -0500From: rcoleburn at scires.comTo: jay123 at hotmail.comCC: m3devel at elegosoft.comSubject: [M3devel] INSTALL_ROOT and PKG_USE in cm3.cfg Jay: The cm3.cfg that comes with your minimal binary installation on Windows (NT386) has the following lines: ----------------------------------------- % INSTALL_ROOT = BEGIN_CONFIG% "Where should CM3 be installed?"% 7 %-- user specified install root% END_CONFIG % INSTALL_ROOT = "c:\\cm3" if not defined("INSTALL_ROOT") if not equal ($INSTALLROOT, "") INSTALL_ROOT = $INSTALLROOT else INSTALL_ROOT = (path() & "\\..") endend BIN_INSTALL = INSTALL_ROOT & "\\bin" % executablesLIB_INSTALL = INSTALL_ROOT & "\\lib" % librariesPKG_INSTALL = INSTALL_ROOT & "\\pkg" % packagesDOC_INSTALL = INSTALL_ROOT & "\\doc" % documentsEMACS_INSTALL = INSTALL_ROOT & "\\elisp" % emacs lisp codeMAN_INSTALL = INSTALL_ROOT & "\\man" % man pagesHTML_INSTALL = INSTALL_ROOT & "\\www" % public hypertext %% On some systems (e.g. AFS) you must install public files in a different% place from where you use them. If that is the case for your system,% specify the "use" location here, otherwise leave them alone.%%USE_ROOT = INSTALL_ROOTBIN_USE = BIN_INSTALL % executablesLIB_USE = LIB_INSTALL % librariesPKG_USE = PKG_INSTALL % packages ----------------------------------------- Notice that the lines for INSTALL_ROOT and USE_ROOT are commented out. The Reactor program is coded to grab several variables out of cm3.cfg. For example, build_dir := M3Config.Get ("BUILD_DIR"); system_root := M3Config.Get ("PKG_USE"); doc_root := M3Config.Get ("DOC_INSTALL"); initial_browser := M3Config.Get ("INITIAL_CM3_IDE_BROWSER"); initial_editor := M3Config.Get ("INITIAL_CM3_IDE_EDITOR"); What is happening on my installation is that PKG_USE winds up being "\..\PKG". This is not a valid path and it is causing all sorts of trouble for Reactor. The reason it is getting set this way is that the ELSE branch of the, if not defined("INSTALL_ROOT"), is getting executed resulting in INSTALL_ROOT=\.. I'm not sure why this is coded this way. How do you suggest this should be repaired? Note, I have not checked all of the cm3.cfg variants for the other target platforms, but in order for reactor to work properly, it must be able to find a valid "PKG_USE" in the cm3.cfg. Regards, Randy 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. Play now! 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". 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 wagner at elegosoft.com Fri Jan 25 08:06:33 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 25 Jan 2008 08:06:33 +0100 Subject: [M3devel] CM3 5.5.1 works on Ubuntu 7.10! In-Reply-To: <47993122.2030201@elego.de> References: <47993122.2030201@elego.de> Message-ID: <20080125080633.72gtexb6m8cocwsk@mail.elegosoft.com> Quoting Neels Janosch Hofmeyr : > Thanks Olaf, Tony, Mika and Jay, I have cm3 working on Ubuntu 7.10! > Complete instructions are given in the attached file. After all, it > _does_ look quite simple. But only once you know how. Please let me > know if you have any improvements waiting. I'll check this file into > the CVS somewhere. > > We need to add these instructions to modula3.elegosoft.com, so that > others do not take the same "shortcuts" I did. If noone else feels like > doing it, I will. But right now, it's way past bedtime. Would you care to load up your archive to birch.elegosoft.com:/var/www/modula3.elegosoft.com/cm3/uploaded-archives ? And check-in your instructions to cm3/www and link them in? That would be great. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From stsp at elego.de Fri Jan 25 10:35:35 2008 From: stsp at elego.de (Stefan Sperling) Date: Fri, 25 Jan 2008 10:35:35 +0100 Subject: [M3devel] CM3 5.5.1 works on Ubuntu 7.10! In-Reply-To: <47993388.9030909@elego.de> References: <47993122.2030201@elego.de> <47993388.9030909@elego.de> Message-ID: <20080125093535.GA27717@jack.stsp.name> On Fri, Jan 25, 2008 at 01:55:36AM +0100, Neels Janosch Hofmeyr wrote: > Wow, does your mail client also think the attachment is a PowerPoint > Document? Well, in fact it's a plain ASCII text file. Yes, the mime-type is wrong. Mutt tells me: [-- Attachment #2: install-cm3-on-ubuntu-7-10.txt --] [-- Type: application/vnd.ms-powerpoint, Encoding: base64, Size: 12K --] [-- application/vnd.ms-powerpoint is unsupported (use 'v' to view this part) --] -- Stefan Sperling Software Developer elego Software Solutions GmbH HRB 77719 Gustav-Meyer-Allee 25, Gebaeude 12 Tel: +49 30 23 45 86 96 13355 Berlin Fax: +49 30 23 45 86 95 http://www.elego.de Geschaeftsfuehrer: Olaf Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From wagner at elegosoft.com Fri Jan 25 11:09:59 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 25 Jan 2008 11:09:59 +0100 Subject: [M3devel] INSTALL_ROOT and PKG_USE in cm3.cfg In-Reply-To: References: <4798DEB8.1E75.00D7.1@scires.com> <4798EFAE.1E75.00D7.1@scires.com> <4798FE0E.1E75.00D7.1@scires.com> <479907A8.1E75.00D7.1@scires.com> <4799283C.1E75.00D7.1@scires.com> Message-ID: <20080125110959.5oc8u98w0w8csc80@mail.elegosoft.com> Quoting Jay : > using this code on PPC_LINUX and PPC_DARWIN (should be called > PPC_MACOSX but oh well) Actually I did the port on a plain DARWIN system from opendarwin.org when this was still alive. So there should be no dependency on MacOS X extensions. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Fri Jan 25 11:23:10 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 25 Jan 2008 11:23:10 +0100 Subject: [M3devel] INSTALL_ROOT and PKG_USE in cm3.cfg In-Reply-To: References: <4798DEB8.1E75.00D7.1@scires.com> <4798EFAE.1E75.00D7.1@scires.com> <4798FE0E.1E75.00D7.1@scires.com> <479907A8.1E75.00D7.1@scires.com> <4799283C.1E75.00D7.1@scires.com> Message-ID: <20080125112310.9qfns8rzx5gckgck@mail.elegosoft.com> Quoting Jay : > I have seen path() return empty with some older builds, but not with > current builds. > Where I have seen it, I added in if defined() to cope and something > more that I forget, maybe just the "normal" thing, like to bootstrap > from an older build, and it gets overwritten during the bootstrap, > once there is a current cm3.exe. I should check, I should check the > history, and consistently workaround for all the files with this > construct (ie. config-no-install and NT386). > > The documentation says it returns the path or directory of cm3.exe. > But I did find that to be false, but the function is still useful. > It seems to return the path of the current Quake code. I haven't > looked at the implementation (yet). Where did you read that? http://modula3.elegosoft.com/cm3/doc/help/cm3/quake.html says path() Returns the directory of the currently executing file as a string Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Jan 25 11:29:28 2008 From: jayk123 at hotmail.com (Jay) Date: Fri, 25 Jan 2008 10:29:28 +0000 Subject: [M3devel] INSTALL_ROOT and PKG_USE in cm3.cfg In-Reply-To: <20080125110959.5oc8u98w0w8csc80@mail.elegosoft.com> References: <4798DEB8.1E75.00D7.1@scires.com> <4798EFAE.1E75.00D7.1@scires.com> <4798FE0E.1E75.00D7.1@scires.com> <479907A8.1E75.00D7.1@scires.com> <4799283C.1E75.00D7.1@scires.com> <20080125110959.5oc8u98w0w8csc80@mail.elegosoft.com> Message-ID: ok, but independent of what it's actual dependencies are...how many people run Darwin? How many people run Mac OS X? How many people have heard of Darwin (not Charles)? How many people have heard of Mac OS X? Even among the unusual people who might read anything related to Modula-3 and own a Macintosh running Mac OS X? I know it's not a popularity contest but.. NT386 should be called Windows. The name "NT" will probably gradually fade into obscurity and the name "Windows" will live on much longe. Posix and Unix will probably be forgotten and people will only have heard of "Linux". The PPC_DARWIN port has an optional dependency on X Windows..is that available for plain Darwin or only with Mac OS X? Anyway..it's just a gut feeling I have as to what names people would look for and find less surprising. I was surprised by "Darwin", therefore would be.. :) MacX is maybe a better compromise to be shorter. or Macintosh for verbosity and without so many initials.. (NT386 may be short and typable but every letter is a syllable and I think economy of syllables is also important....(not clear if prounounced "eight" or "eighty") Or maybe just Mac, assuming nobody thinks there will ever be a port to pre MacX, which could be called OldMac or MacClassic or Mac9 anyway if necessary.. :) LINUX, LINUXELF, LINUXLIBC6? Please. Couldn't Linux have been recycled for LINUXLIBC6?Does anyone have Linux 1.2 around? That's the version I've run the most, long ago. :) Anyway I don't care THAT much and I will resist suggesting any more names for any preexisting targets or criticizing them. They almost all stink, esp. the active ones. :) Are the older FreeBSD ABIs so inferior that it is worth having newer ones? They didn't have pthreads back then and they do now? - Jay > Date: Fri, 25 Jan 2008 11:09:59 +0100> From: wagner at elegosoft.com> To: m3devel at elegosoft.com> Subject: Re: [M3devel] INSTALL_ROOT and PKG_USE in cm3.cfg> > Quoting Jay :> > > using this code on PPC_LINUX and PPC_DARWIN (should be called > > PPC_MACOSX but oh well)> > Actually I did the port on a plain DARWIN system from opendarwin.org> when this was still alive. So there should be no dependency on MacOS X> extensions.> > Olaf> -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 Fri Jan 25 11:38:17 2008 From: mika at async.caltech.edu (Mika Nystrom) Date: Fri, 25 Jan 2008 02:38:17 -0800 Subject: [M3devel] INSTALL_ROOT and PKG_USE in cm3.cfg In-Reply-To: Your message of "Fri, 25 Jan 2008 10:29:28 GMT." Message-ID: <200801251038.m0PAcHVv014819@camembert.async.caltech.edu> I'm not sure about this MACOSX business. This is what I see when I log in to my Mac: (94)rover:~>ssh -Y lapdog Last login: Tue Jan 22 00:33:21 2008 from rover Welcome to Darwin! [lapdog:~] mika% uname -a Darwin lapdog 8.11.0 Darwin Kernel Version 8.11.0: Wed Oct 10 18:26:00 PDT 2007; root:xnu-792.24.17~1/RELEASE_PPC Power Macintosh powerpc [lapdog:~] mika% Jay writes: >--_587094ee-5029-41f3-88b0-f4a35ad4e834_ >Content-Type: text/plain; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > >ok, but independent of what it's actual dependencies are...how many people = >run Darwin? How many people run Mac OS X? How many people have heard of Dar= >win (not Charles)? How many people have heard of Mac OS X? Even among the u= >nusual people who might read anything related to Modula-3 and own a Macinto= >sh running Mac OS X? I know it's not a popularity contest but.. NT386 shoul= >d be called Windows. The name "NT" will probably gradually fade into obscur= >ity and the name "Windows" will live on much longe. Posix and Unix will pro= >bably be forgotten and people will only have heard of "Linux". >=20 >The PPC_DARWIN port has an optional dependency on X Windows..is that availa= >ble for plain Darwin or only with Mac OS X? >=20 >Anyway..it's just a gut feeling I have as to what names people would look f= >or and find less surprising. >I was surprised by "Darwin", therefore would be.. :) >MacX is maybe a better compromise to be shorter. >or Macintosh for verbosity and without so many initials.. (NT386 may be sho= >rt and typable but every letter is a syllable and I think economy of syllab= >les is also important....(not clear if prounounced "eight" or "eighty") >Or maybe just Mac, assuming nobody thinks there will ever be a port to pre = >MacX, which could be called OldMac or MacClassic or Mac9 anyway if necessar= >y.. :) >=20 >LINUX, LINUXELF, LINUXLIBC6? Please. >Couldn't Linux have been recycled for LINUXLIBC6?Does anyone have Linux 1.2= > around? >That's the version I've run the most, long ago. :) >=20 >Anyway I don't care THAT much and I will resist suggesting any more names f= >or any preexisting targets or criticizing them. >They almost all stink, esp. the active ones. :) >Are the older FreeBSD ABIs so inferior that it is worth having newer ones? = >They didn't have pthreads back then and they do now? >=20 > - Jay > > > >> Date: Fri, 25 Jan 2008 11:09:59 +0100> From: wagner at elegosoft.com> To: m3= >devel at elegosoft.com> Subject: Re: [M3devel] INSTALL_ROOT and PKG_USE in cm3= >.cfg> > Quoting Jay :> > > using this code on PPC_LINU= >X and PPC_DARWIN (should be called > > PPC_MACOSX but oh well)> > Actually = >I did the port on a plain DARWIN system from opendarwin.org> when this was = >still alive. So there should be no dependency on MacOS X> extensions.> > Ol= >af> -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 2= >5 / 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 Cha= >rlottenburg HRB 77719 | USt-IdNr: DE163214194>=20 >_________________________________________________________________ >Helping your favorite cause is as easy as instant messaging.=A0You IM, we g= >ive. >http://im.live.com/Messenger/IM/Home/?source=3Dtext_hotmail_join= > >--_587094ee-5029-41f3-88b0-f4a35ad4e834_ >Content-Type: text/html; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > > > > >ok, but independent of what it's actual dependenc= >ies are...how many people run Darwin? How many people run Mac OS X? How man= >y people have heard of Darwin (not Charles)? How many people have heard of = >Mac OS X? Even among the unusual people who might read anything related to = >Modula-3 and own a Macintosh running Mac OS X? I know it's not a popul= >arity contest but.. NT386 should be called Windows. The name "NT" will prob= >ably gradually fade into obscurity and the name "Windows" will live on much= > longe. Posix and Unix will probably be forgotten and people will only have= > heard of "Linux".
> 
>The PPC_DARWIN port has an optional dependency on X Windows..is that availa= >ble for plain Darwin or only with Mac OS X?
> 
>Anyway..it's just a gut feeling I have as to what names people would look f= >or and find less surprising.
>I was surprised by "Darwin", therefore would be.. :)
>MacX is maybe a better compromise to be shorter.
>or Macintosh for verbosity and without so many initials.. (NT386 may be sho= >rt and typable but every letter is a syllable and I think economy of syllab= >les is also important....(not clear if prounounced "eight" or "eighty")
>Or maybe just Mac, assuming nobody thinks there will ever be a port to pre = >MacX, which could be called OldMac or MacClassic or Mac9 anyway if necessar= >y.. :)
> 
>LINUX, LINUXELF, LINUXLIBC6? Please.
>Couldn't Linux have been recycled for LINUXLIBC6?
Does anyone have Linux= > 1.2 around?
>That's the version I've run the most, long ago. :)
> 
>Anyway I don't care THAT much and I will resist suggesting any more names f= >or any preexisting targets or criticizing them.
>They almost all stink, esp. the active ones. :)
>Are the older FreeBSD ABIs so inferior that it is worth having newer ones? = >They didn't have pthreads back then and they do now?
> 
> - Jay


> >
>
>> Date: Fri, 25 Jan 2008 11:09:59 +0100
> From: wagner at elegosoft.c= >om
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] INSTALL= >_ROOT and PKG_USE in cm3.cfg
>
> Quoting Jay <jayk123 at hotma= >il.com>:
>
> > using this code on PPC_LINUX and PPC_DARW= >IN (should be called
> > PPC_MACOSX but oh well)
>
>= > Actually I did the port on a plain DARWIN system from opendarwin.org
&g= >t; when this was still alive. So there should be no dependency on MacOS XR>> extensions.
>
> 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 2= >345 869 fax: +49 30 23 45 86 95
> http://www.elegosoft.com | Gesch=E4= >ftsf=FChrer: Olaf Wagner | Sitz: Berlin
> Handelregister: Amtsgericht= > Charlottenburg HRB 77719 | USt-IdNr: DE163214194
>


/>Helping your favorite cause is as easy as instant messaging.=A0You IM, w= >e give. ail_join' target=3D'_new'>Learn more. >= > >--_587094ee-5029-41f3-88b0-f4a35ad4e834_-- From jayk123 at hotmail.com Fri Jan 25 11:39:19 2008 From: jayk123 at hotmail.com (Jay) Date: Fri, 25 Jan 2008 10:39:19 +0000 Subject: [M3devel] INSTALL_ROOT and PKG_USE in cm3.cfg In-Reply-To: <20080125112310.9qfns8rzx5gckgck@mail.elegosoft.com> References: <4798DEB8.1E75.00D7.1@scires.com> <4798EFAE.1E75.00D7.1@scires.com> <4798FE0E.1E75.00D7.1@scires.com> <479907A8.1E75.00D7.1@scires.com> <4799283C.1E75.00D7.1@scires.com> <20080125112310.9qfns8rzx5gckgck@mail.elegosoft.com> Message-ID: Oops I must have just misinterpreted that. executing, executable, .exe.. - Jay > Date: Fri, 25 Jan 2008 11:23:10 +0100> From: wagner at elegosoft.com> To: m3devel at elegosoft.com> Subject: Re: [M3devel] INSTALL_ROOT and PKG_USE in cm3.cfg> > Quoting Jay :> > I have seen path() return empty with some older builds, but not with > > current builds.> > Where I have seen it, I added in if defined() to cope and something > > more that I forget, maybe just the "normal" thing, like to bootstrap > > from an older build, and it gets overwritten during the bootstrap, > > once there is a current cm3.exe. I should check, I should check the > > history, and consistently workaround for all the files with this > > construct (ie. config-no-install and NT386).> >> > The documentation says it returns the path or directory of cm3.exe.> > But I did find that to be false, but the function is still useful. > > It seems to return the path of the current Quake code. I haven't > > looked at the implementation (yet).> > Where did you read that?> > http://modula3.elegosoft.com/cm3/doc/help/cm3/quake.html says> > path() Returns the directory of the currently executing file as a string> > Olaf> -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 Fri Jan 25 12:26:09 2008 From: jayk123 at hotmail.com (Jay) Date: Fri, 25 Jan 2008 11:26:09 +0000 Subject: [M3devel] INSTALL_ROOT and PKG_USE in cm3.cfg In-Reply-To: <200801251038.m0PAcHVv014819@camembert.async.caltech.edu> References: Your message of "Fri, 25 Jan 2008 10:29:28 GMT." <200801251038.m0PAcHVv014819@camembert.async.caltech.edu> Message-ID: true.. It looks like binary releases of Darwin are no longer made and apparently there are no instructions for building it from source...though that is the source presumably from which part of MacOSX is built.. > To: jayk123 at hotmail.com> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] INSTALL_ROOT and PKG_USE in cm3.cfg > Date: Fri, 25 Jan 2008 02:38:17 -0800> From: mika at async.caltech.edu> > I'm not sure about this MACOSX business.> > This is what I see when I log in to my Mac:> > (94)rover:~>ssh -Y lapdog> Last login: Tue Jan 22 00:33:21 2008 from rover> Welcome to Darwin!> [lapdog:~] mika% uname -a> Darwin lapdog 8.11.0 Darwin Kernel Version 8.11.0: Wed Oct 10 18:26:00 PDT 2007; root:xnu-792.24.17~1/RELEASE_PPC Power Macintosh powerpc> [lapdog:~] mika% > > > > Jay writes:> >--_587094ee-5029-41f3-88b0-f4a35ad4e834_> >Content-Type: text/plain; charset="iso-8859-1"> >Content-Transfer-Encoding: quoted-printable> >> >ok, but independent of what it's actual dependencies are...how many people => >run Darwin? How many people run Mac OS X? How many people have heard of Dar=> >win (not Charles)? How many people have heard of Mac OS X? Even among the u=> >nusual people who might read anything related to Modula-3 and own a Macinto=> >sh running Mac OS X? I know it's not a popularity contest but.. NT386 shoul=> >d be called Windows. The name "NT" will probably gradually fade into obscur=> >ity and the name "Windows" will live on much longe. Posix and Unix will pro=> >bably be forgotten and people will only have heard of "Linux".> >=20> >The PPC_DARWIN port has an optional dependency on X Windows..is that availa=> >ble for plain Darwin or only with Mac OS X?> >=20> >Anyway..it's just a gut feeling I have as to what names people would look f=> >or and find less surprising.> >I was surprised by "Darwin", therefore would be.. :)> >MacX is maybe a better compromise to be shorter.> >or Macintosh for verbosity and without so many initials.. (NT386 may be sho=> >rt and typable but every letter is a syllable and I think economy of syllab=> >les is also important....(not clear if prounounced "eight" or "eighty")> >Or maybe just Mac, assuming nobody thinks there will ever be a port to pre => >MacX, which could be called OldMac or MacClassic or Mac9 anyway if necessar=> >y.. :)> >=20> >LINUX, LINUXELF, LINUXLIBC6? Please.> >Couldn't Linux have been recycled for LINUXLIBC6?Does anyone have Linux 1.2=> > around?> >That's the version I've run the most, long ago. :)> >=20> >Anyway I don't care THAT much and I will resist suggesting any more names f=> >or any preexisting targets or criticizing them.> >They almost all stink, esp. the active ones. :)> >Are the older FreeBSD ABIs so inferior that it is worth having newer ones? => >They didn't have pthreads back then and they do now?> >=20> > - Jay> >> >> >> >> Date: Fri, 25 Jan 2008 11:09:59 +0100> From: wagner at elegosoft.com> To: m3=> >devel at elegosoft.com> Subject: Re: [M3devel] INSTALL_ROOT and PKG_USE in cm3=> >.cfg> > Quoting Jay :> > > using this code on PPC_LINU=> >X and PPC_DARWIN (should be called > > PPC_MACOSX but oh well)> > Actually => >I did the port on a plain DARWIN system from opendarwin.org> when this was => >still alive. So there should be no dependency on MacOS X> extensions.> > Ol=> >af> -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 2=> >5 / 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 Cha=> >rlottenburg HRB 77719 | USt-IdNr: DE163214194>=20> >_________________________________________________________________> >Helping your favorite cause is as easy as instant messaging.=A0You IM, we g=> >ive.> >http://im.live.com/Messenger/IM/Home/?source=3Dtext_hotmail_join=> >> >--_587094ee-5029-41f3-88b0-f4a35ad4e834_> >Content-Type: text/html; charset="iso-8859-1"> >Content-Transfer-Encoding: quoted-printable> >> >> >> >> >> >ok, but independent of what it's actual dependenc=> >ies are...how many people run Darwin? How many people run Mac OS X? How man=> >y people have heard of Darwin (not Charles)? How many people have heard of => >Mac OS X? Even among the unusual people who might read anything related to => >Modula-3 and own a Macintosh running Mac OS X? I know it's not a popul=> >arity contest but.. NT386 should be called Windows. The name "NT" will prob=> >ably gradually fade into obscurity and the name "Windows" will live on much=> > longe. Posix and Unix will probably be forgotten and people will only have=> > heard of "Linux".
> > 
> >The PPC_DARWIN port has an optional dependency on X Windows..is that availa=> >ble for plain Darwin or only with Mac OS X?
> > 
> >Anyway..it's just a gut feeling I have as to what names people would look f=> >or and find less surprising.
> >I was surprised by "Darwin", therefore would be.. :)
> >MacX is maybe a better compromise to be shorter.
> >or Macintosh for verbosity and without so many initials.. (NT386 may be sho=> >rt and typable but every letter is a syllable and I think economy of syllab=> >les is also important....(not clear if prounounced "eight" or "eighty")
> >Or maybe just Mac, assuming nobody thinks there will ever be a port to pre => >MacX, which could be called OldMac or MacClassic or Mac9 anyway if necessar=> >y.. :)
> > 
> >LINUX, LINUXELF, LINUXLIBC6? Please.
> >Couldn't Linux have been recycled for LINUXLIBC6?
Does anyone have Linux=> > 1.2 around?
> >That's the version I've run the most, long ago. :)
> > 
> >Anyway I don't care THAT much and I will resist suggesting any more names f=> >or any preexisting targets or criticizing them.
> >They almost all stink, esp. the active ones. :)
> >Are the older FreeBSD ABIs so inferior that it is worth having newer ones? => >They didn't have pthreads back then and they do now?
> > 
> > - Jay


> >> >
> >
> >> Date: Fri, 25 Jan 2008 11:09:59 +0100
> From: wagner at elegosoft.c=> >om
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] INSTALL=> >_ROOT and PKG_USE in cm3.cfg
>
> Quoting Jay <jayk123 at hotma=> >il.com>:
>
> > using this code on PPC_LINUX and PPC_DARW=> >IN (should be called
> > PPC_MACOSX but oh well)
>
>=> > Actually I did the port on a plain DARWIN system from opendarwin.org
&g=> >t; when this was still alive. So there should be no dependency on MacOS X >R>> extensions.
>
> 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 2=> >345 869 fax: +49 30 23 45 86 95
> http://www.elegosoft.com | Gesch=E4=> >ftsf=FChrer: Olaf Wagner | Sitz: Berlin
> Handelregister: Amtsgericht=> > Charlottenburg HRB 77719 | USt-IdNr: DE163214194
>


> />Helping your favorite cause is as easy as instant messaging.=A0You IM, w=> >e give. >ail_join' target=3D'_new'>Learn more.> >=> >> >--_587094ee-5029-41f3-88b0-f4a35ad4e834_-- _________________________________________________________________ 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 Fri Jan 25 13:36:49 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 25 Jan 2008 13:36:49 +0100 Subject: [M3devel] INSTALL_ROOT and PKG_USE in cm3.cfg In-Reply-To: References: <4798DEB8.1E75.00D7.1@scires.com> <4798EFAE.1E75.00D7.1@scires.com> <4798FE0E.1E75.00D7.1@scires.com> <479907A8.1E75.00D7.1@scires.com> <4799283C.1E75.00D7.1@scires.com> <20080125110959.5oc8u98w0w8csc80@mail.elegosoft.com> Message-ID: <20080125133649.vq9xj54iqok00so0@mail.elegosoft.com> I just wanted to point out why it's call PPC_DARWIN. Now that the OpenDarwin project has closed down, it may indeed seem strange. But many of the names can only be understood based on their history. I'm with you that they are neither systematic nor intuitive. I think I could even be persuaded to support a general renaming, if the scheme and concepts are well considered before. Quoting Jay : > The PPC_DARWIN port has an optional dependency on X Windows..is that > available for plain Darwin or only with Mac OS X? Yes. Actually the X in X Windows and MacOS X refer to completely different things. MacOS X does not support X Windows out of the box, it uses Aqua as GUI. > I was surprised by "Darwin", therefore would be.. :) That's why I tried to explain it ;-) > LINUX, LINUXELF, LINUXLIBC6? Please. > Couldn't Linux have been recycled for LINUXLIBC6?Does anyone have > Linux 1.2 around? It could be done now, but it couldn't when it was created. > Are the older FreeBSD ABIs so inferior that it is worth having newer > ones? They didn't have pthreads back then and they do now? There are ABI changes with every major release of FreeBSD (and also Linux, Solaris, and other operating systems if I am not much mistaken). Of course, everyone strives for compatibility of the often used and most important interfaces, but there is a grey zone where data structures common to the kernel and userland are touched, and they need to be updated (in order to not hinder improvement) more often than you'd think. If such an update annoys or disturbs users often enough, new interface abstractions tend to appear that should avoid the problem for future releases (for example, changes of the jmp_buf structure break threading code --> new interfaces for thread context access are defined). The M3 runtime is somewhat special and differs from the C runtime in that it makes use of quite a number of not always well-defined system interfaces. We also try to eliminate these dependencies (VM calls, jmp_buf structure, whole threading, ...) Actually I think I was the first one to port any pthread package to FreeBSD (when working for a company building POS solutions, but we could never release the code) back in the 1.5 and 2.x days. I used a pthreads implementation by Frank Mueller. Official pthread support came much later. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From hosking at cs.purdue.edu Fri Jan 25 15:28:46 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 25 Jan 2008 09:28:46 -0500 Subject: [M3devel] segmentation fault upon ./install-cm3-compiler.sh upgrade In-Reply-To: <47991720.1030307@elego.de> References: <4798FE9B.1090204@elego.de> <479905C8.7080003@elego.de> <20080124230322.vl12nlls4kosoocs@mail.elegosoft.com> <47990CFC.8080609@elego.de> <20080124233519.s3o34cbsmc8kocs8@mail.elegosoft.com> <479914EA.3060902@elego.de> <80025F80-FDA6-4E9D-AC2A-73C6498A6EA0@cs.purdue.edu> <47991720.1030307@elego.de> Message-ID: Build and ship packages in the following order: m3middle m3linker m3front m3quake cm3 This builds a bootstrap compiler using the *old* libraries. Use the binary this creates to build your system. On Jan 24, 2008, at 5:54 PM, Neels Janosch Hofmeyr wrote: > > Tony Hosking wrote: >> I'm pretty sure these problems are a result of needing to use a >> new bootstrap compiler. > How can I build one from source? (does this question make sense?) > > -- > Neels Janosch Hofmeyr > Software Developer > > neels at elego.de > Public Key: http://binarchy.net/neels/neels.hofmeyr.public.key.asc > > elego Software Solutions GmbH http://www.elegosoft.com > Gustav-Meyer-Allee 25, Geb?ude 12 HRB 77719 > 13355 Berlin, Germany Amtsgericht Charlottenburg > Tel.: +49 30 23 45 86 96 Sitz der Gesellschaft: Berlin > Fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Olaf Wagner > > From hosking at cs.purdue.edu Fri Jan 25 15:39:22 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 25 Jan 2008 09:39:22 -0500 Subject: [M3devel] INSTALL_ROOT and PKG_USE in cm3.cfg In-Reply-To: References: <4798DEB8.1E75.00D7.1@scires.com> <4798EFAE.1E75.00D7.1@scires.com> <4798FE0E.1E75.00D7.1@scires.com> <479907A8.1E75.00D7.1@scires.com> <4799283C.1E75.00D7.1@scires.com> <20080125110959.5oc8u98w0w8csc80@mail.elegosoft.com> Message-ID: <2157F648-47CC-4C3F-BD9E-07D14841C238@cs.purdue.edu> On Jan 25, 2008, at 5:29 AM, Jay wrote: > ok, but independent of what it's actual dependencies are...how many > people run Darwin? How many people run Mac OS X? How many people > have heard of Darwin (not Charles)? How many people have heard of > Mac OS X? Even among the unusual people who might read anything > related to Modula-3 and own a Macintosh running Mac OS X? I know > it's not a popularity contest but.. NT386 should be called Windows. > The name "NT" will probably gradually fade into obscurity and the > name "Windows" will live on much longe. Posix and Unix will > probably be forgotten and people will only have heard of "Linux". > > The PPC_DARWIN port has an optional dependency on X Windows..is > that available for plain Darwin or only with Mac OS X? Darwin makes sense given that it works on both MacOSX and open source Darwin. > Anyway..it's just a gut feeling I have as to what names people > would look for and find less surprising. > I was surprised by "Darwin", therefore would be.. :) Folks installing from source the way M3 requires generally are familiar with this terminology. If we had binary installers then naturally OSX would make sense. > MacX is maybe a better compromise to be shorter. > or Macintosh for verbosity and without so many initials.. (NT386 > may be short and typable but every letter is a syllable and I think > economy of syllables is also important....(not clear if prounounced > "eight" or "eighty") > Or maybe just Mac, assuming nobody thinks there will ever be a port > to pre MacX, which could be called OldMac or MacClassic or Mac9 > anyway if necessary.. :) > > LINUX, LINUXELF, LINUXLIBC6? Please. > Couldn't Linux have been recycled for LINUXLIBC6? > Does anyone have Linux 1.2 around? > That's the version I've run the most, long ago. :) You must understand that the naming schemes grew organically over the past 20 years or so (before Linux was even widely known!), and when Windows was definitely not NT and never would have supported M3. > Anyway I don't care THAT much and I will resist suggesting any more > names for any preexisting targets or criticizing them. > They almost all stink, esp. the active ones. :) > Are the older FreeBSD ABIs so inferior that it is worth having > newer ones? They didn't have pthreads back then and they do now? Keeping the old distros around with their old names is a convenient historical record that I have frequently used to implement functionality on new systems. For example, much of the current Solaris exception handling (which uses native stack unwinding rather than setjmp/longjmp) was derived from DS3100 and ALPHA_OSF! Remember, the average M3 installer from source will need to be somewhat familiar with the target names. We should also strive to allow easier installs from RPMS on Linux, Fink on OSX, and binary installers on Windows that will cater to the masses! > > > - Jay > > > > > Date: Fri, 25 Jan 2008 11:09:59 +0100 > > From: wagner at elegosoft.com > > To: m3devel at elegosoft.com > > Subject: Re: [M3devel] INSTALL_ROOT and PKG_USE in cm3.cfg > > > > Quoting Jay : > > > > > using this code on PPC_LINUX and PPC_DARWIN (should be called > > > PPC_MACOSX but oh well) > > > > Actually I did the port on a plain DARWIN system from opendarwin.org > > when this was still alive. So there should be no dependency on > MacOS X > > extensions. > > > > Olaf > > -- > > Olaf Wagner -- elego Software Solutions GmbH > > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 Fri Jan 25 15:40:00 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 25 Jan 2008 09:40:00 -0500 Subject: [M3devel] INSTALL_ROOT and PKG_USE in cm3.cfg In-Reply-To: <200801251038.m0PAcHVv014819@camembert.async.caltech.edu> References: <200801251038.m0PAcHVv014819@camembert.async.caltech.edu> Message-ID: <1A4B11E5-3935-4662-AD1F-CDFB0CB940CB@cs.purdue.edu> Precisely! On Jan 25, 2008, at 5:38 AM, Mika Nystrom wrote: > I'm not sure about this MACOSX business. > > This is what I see when I log in to my Mac: > > (94)rover:~>ssh -Y lapdog > Last login: Tue Jan 22 00:33:21 2008 from rover > Welcome to Darwin! > [lapdog:~] mika% uname -a > Darwin lapdog 8.11.0 Darwin Kernel Version 8.11.0: Wed Oct 10 > 18:26:00 PDT 2007; root:xnu-792.24.17~1/RELEASE_PPC Power Macintosh > powerpc > [lapdog:~] mika% > > > > Jay writes: >> --_587094ee-5029-41f3-88b0-f4a35ad4e834_ >> Content-Type: text/plain; charset="iso-8859-1" >> Content-Transfer-Encoding: quoted-printable >> >> ok, but independent of what it's actual dependencies are...how >> many people = >> run Darwin? How many people run Mac OS X? How many people have >> heard of Dar= >> win (not Charles)? How many people have heard of Mac OS X? Even >> among the u= >> nusual people who might read anything related to Modula-3 and own >> a Macinto= >> sh running Mac OS X? I know it's not a popularity contest but.. >> NT386 shoul= >> d be called Windows. The name "NT" will probably gradually fade >> into obscur= >> ity and the name "Windows" will live on much longe. Posix and Unix >> will pro= >> bably be forgotten and people will only have heard of "Linux". >> =20 >> The PPC_DARWIN port has an optional dependency on X Windows..is >> that availa= >> ble for plain Darwin or only with Mac OS X? >> =20 >> Anyway..it's just a gut feeling I have as to what names people >> would look f= >> or and find less surprising. >> I was surprised by "Darwin", therefore would be.. :) >> MacX is maybe a better compromise to be shorter. >> or Macintosh for verbosity and without so many initials.. (NT386 >> may be sho= >> rt and typable but every letter is a syllable and I think economy >> of syllab= >> les is also important....(not clear if prounounced "eight" or >> "eighty") >> Or maybe just Mac, assuming nobody thinks there will ever be a >> port to pre = >> MacX, which could be called OldMac or MacClassic or Mac9 anyway if >> necessar= >> y.. :) >> =20 >> LINUX, LINUXELF, LINUXLIBC6? Please. >> Couldn't Linux have been recycled for LINUXLIBC6?Does anyone have >> Linux 1.2= >> around? >> That's the version I've run the most, long ago. :) >> =20 >> Anyway I don't care THAT much and I will resist suggesting any >> more names f= >> or any preexisting targets or criticizing them. >> They almost all stink, esp. the active ones. :) >> Are the older FreeBSD ABIs so inferior that it is worth having >> newer ones? = >> They didn't have pthreads back then and they do now? >> =20 >> - Jay >> >> >> >>> Date: Fri, 25 Jan 2008 11:09:59 +0100> From: >>> wagner at elegosoft.com> To: m3= >> devel at elegosoft.com> Subject: Re: [M3devel] INSTALL_ROOT and >> PKG_USE in cm3= >> .cfg> > Quoting Jay :> > > using this code on >> PPC_LINU= >> X and PPC_DARWIN (should be called > > PPC_MACOSX but oh well)> > >> Actually = >> I did the port on a plain DARWIN system from opendarwin.org> when >> this was = >> still alive. So there should be no dependency on MacOS X> >> extensions.> > Ol= >> af> -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav- >> Meyer-Allee 2= >> 5 / 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 Cha= >> rlottenburg HRB 77719 | USt-IdNr: DE163214194>=20 >> _________________________________________________________________ >> Helping your favorite cause is as easy as instant messaging.=A0You >> IM, we g= >> ive. >> http://im.live.com/Messenger/IM/Home/?source=3Dtext_hotmail_join= >> >> --_587094ee-5029-41f3-88b0-f4a35ad4e834_ >> Content-Type: text/html; charset="iso-8859-1" >> Content-Transfer-Encoding: quoted-printable >> >> >> >> >> >> ok, but independent of what it's actual >> dependenc= >> ies are...how many people run Darwin? How many people run Mac OS >> X? How man= >> y people have heard of Darwin (not Charles)? How many people have >> heard of = >> Mac OS X? Even among the unusual people who might read anything >> related to = >> Modula-3 and own a Macintosh running Mac OS X? I know it's >> not a popul= >> arity contest but.. NT386 should be called Windows. The name "NT" >> will prob= >> ably gradually fade into obscurity and the name "Windows" will >> live on much= >> longe. Posix and Unix will probably be forgotten and people will >> only have= >> heard of "Linux".
>>  
>> The PPC_DARWIN port has an optional dependency on X Windows..is >> that availa= >> ble for plain Darwin or only with Mac OS X?
>>  
>> Anyway..it's just a gut feeling I have as to what names people >> would look f= >> or and find less surprising.
>> I was surprised by "Darwin", therefore would be.. :)
>> MacX is maybe a better compromise to be shorter.
>> or Macintosh for verbosity and without so many initials.. (NT386 >> may be sho= >> rt and typable but every letter is a syllable and I think economy >> of syllab= >> les is also important....(not clear if prounounced "eight" or >> "eighty")
>> Or maybe just Mac, assuming nobody thinks there will ever be a >> port to pre = >> MacX, which could be called OldMac or MacClassic or Mac9 anyway if >> necessar= >> y.. :)
>>  
>> LINUX, LINUXELF, LINUXLIBC6? Please.
>> Couldn't Linux have been recycled for LINUXLIBC6?
Does anyone >> have Linux= >> 1.2 around?
>> That's the version I've run the most, long ago. :)
>>  
>> Anyway I don't care THAT much and I will resist suggesting any >> more names f= >> or any preexisting targets or criticizing them.
>> They almost all stink, esp. the active ones. :)
>> Are the older FreeBSD ABIs so inferior that it is worth having >> newer ones? = >> They didn't have pthreads back then and they do now?
>>  
>>  - Jay


>> >>
>>
>> > Date: Fri, 25 Jan 2008 11:09:59 +0100
> From: >> wagner at elegosoft.c= >> om
> To: m3devel at elegosoft.com
> Subject: Re: >> [M3devel] INSTALL= >> _ROOT and PKG_USE in cm3.cfg
>
> Quoting Jay >> <jayk123 at hotma= >> il.com>:
>
> > using this code on PPC_LINUX and >> PPC_DARW= >> IN (should be called
> > PPC_MACOSX but oh well)
> >>
>= >> Actually I did the port on a plain DARWIN system from >> opendarwin.org
&g= >> t; when this was still alive. So there should be no dependency on >> MacOS X> R>> extensions.
>
> 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 2= >> 345 869 fax: +49 30 23 45 86 95
> http://www.elegosoft.com | >> Gesch=E4= >> ftsf=FChrer: Olaf Wagner | Sitz: Berlin
> Handelregister: >> Amtsgericht= >> Charlottenburg HRB 77719 | USt-IdNr: DE163214194
> >>


> />Helping your favorite cause is as easy as instant >> messaging.=A0You IM, w= >> e give. > source=3Dtext_hotm= >> ail_join' target=3D'_new'>Learn more. >> = >> >> --_587094ee-5029-41f3-88b0-f4a35ad4e834_-- From hosking at cs.purdue.edu Fri Jan 25 15:49:53 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 25 Jan 2008 09:49:53 -0500 Subject: [M3devel] INSTALL_ROOT and PKG_USE in cm3.cfg In-Reply-To: <1A4B11E5-3935-4662-AD1F-CDFB0CB940CB@cs.purdue.edu> References: <200801251038.m0PAcHVv014819@camembert.async.caltech.edu> <1A4B11E5-3935-4662-AD1F-CDFB0CB940CB@cs.purdue.edu> Message-ID: Latest Darwin source is still at http://www.opensource.apple.com/ darwinsource/ On Jan 25, 2008, at 9:40 AM, Tony Hosking wrote: > Precisely! > > On Jan 25, 2008, at 5:38 AM, Mika Nystrom wrote: > >> I'm not sure about this MACOSX business. >> >> This is what I see when I log in to my Mac: >> >> (94)rover:~>ssh -Y lapdog >> Last login: Tue Jan 22 00:33:21 2008 from rover >> Welcome to Darwin! >> [lapdog:~] mika% uname -a >> Darwin lapdog 8.11.0 Darwin Kernel Version 8.11.0: Wed Oct 10 >> 18:26:00 PDT 2007; root:xnu-792.24.17~1/RELEASE_PPC Power >> Macintosh powerpc >> [lapdog:~] mika% >> >> >> >> Jay writes: >>> --_587094ee-5029-41f3-88b0-f4a35ad4e834_ >>> Content-Type: text/plain; charset="iso-8859-1" >>> Content-Transfer-Encoding: quoted-printable >>> >>> ok, but independent of what it's actual dependencies are...how >>> many people = >>> run Darwin? How many people run Mac OS X? How many people have >>> heard of Dar= >>> win (not Charles)? How many people have heard of Mac OS X? Even >>> among the u= >>> nusual people who might read anything related to Modula-3 and own >>> a Macinto= >>> sh running Mac OS X? I know it's not a popularity contest but.. >>> NT386 shoul= >>> d be called Windows. The name "NT" will probably gradually fade >>> into obscur= >>> ity and the name "Windows" will live on much longe. Posix and >>> Unix will pro= >>> bably be forgotten and people will only have heard of "Linux". >>> =20 >>> The PPC_DARWIN port has an optional dependency on X Windows..is >>> that availa= >>> ble for plain Darwin or only with Mac OS X? >>> =20 >>> Anyway..it's just a gut feeling I have as to what names people >>> would look f= >>> or and find less surprising. >>> I was surprised by "Darwin", therefore would be.. :) >>> MacX is maybe a better compromise to be shorter. >>> or Macintosh for verbosity and without so many initials.. (NT386 >>> may be sho= >>> rt and typable but every letter is a syllable and I think economy >>> of syllab= >>> les is also important....(not clear if prounounced "eight" or >>> "eighty") >>> Or maybe just Mac, assuming nobody thinks there will ever be a >>> port to pre = >>> MacX, which could be called OldMac or MacClassic or Mac9 anyway >>> if necessar= >>> y.. :) >>> =20 >>> LINUX, LINUXELF, LINUXLIBC6? Please. >>> Couldn't Linux have been recycled for LINUXLIBC6?Does anyone have >>> Linux 1.2= >>> around? >>> That's the version I've run the most, long ago. :) >>> =20 >>> Anyway I don't care THAT much and I will resist suggesting any >>> more names f= >>> or any preexisting targets or criticizing them. >>> They almost all stink, esp. the active ones. :) >>> Are the older FreeBSD ABIs so inferior that it is worth having >>> newer ones? = >>> They didn't have pthreads back then and they do now? >>> =20 >>> - Jay >>> >>> >>> >>>> Date: Fri, 25 Jan 2008 11:09:59 +0100> From: >>>> wagner at elegosoft.com> To: m3= >>> devel at elegosoft.com> Subject: Re: [M3devel] INSTALL_ROOT and >>> PKG_USE in cm3= >>> .cfg> > Quoting Jay :> > > using this code >>> on PPC_LINU= >>> X and PPC_DARWIN (should be called > > PPC_MACOSX but oh well)> > >>> Actually = >>> I did the port on a plain DARWIN system from opendarwin.org> when >>> this was = >>> still alive. So there should be no dependency on MacOS X> >>> extensions.> > Ol= >>> af> -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav- >>> Meyer-Allee 2= >>> 5 / 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 Cha= >>> rlottenburg HRB 77719 | USt-IdNr: DE163214194>=20 >>> _________________________________________________________________ >>> Helping your favorite cause is as easy as instant >>> messaging.=A0You IM, we g= >>> ive. >>> http://im.live.com/Messenger/IM/Home/?source=3Dtext_hotmail_join= >>> >>> --_587094ee-5029-41f3-88b0-f4a35ad4e834_ >>> Content-Type: text/html; charset="iso-8859-1" >>> Content-Transfer-Encoding: quoted-printable >>> >>> >>> >>> >>> >>> ok, but independent of what it's actual >>> dependenc= >>> ies are...how many people run Darwin? How many people run Mac OS >>> X? How man= >>> y people have heard of Darwin (not Charles)? How many people have >>> heard of = >>> Mac OS X? Even among the unusual people who might read anything >>> related to = >>> Modula-3 and own a Macintosh running Mac OS X? I know it's >>> not a popul= >>> arity contest but.. NT386 should be called Windows. The name "NT" >>> will prob= >>> ably gradually fade into obscurity and the name "Windows" will >>> live on much= >>> longe. Posix and Unix will probably be forgotten and people will >>> only have= >>> heard of "Linux".
>>>  
>>> The PPC_DARWIN port has an optional dependency on X Windows..is >>> that availa= >>> ble for plain Darwin or only with Mac OS X?
>>>  
>>> Anyway..it's just a gut feeling I have as to what names people >>> would look f= >>> or and find less surprising.
>>> I was surprised by "Darwin", therefore would be.. :)
>>> MacX is maybe a better compromise to be shorter.
>>> or Macintosh for verbosity and without so many initials.. (NT386 >>> may be sho= >>> rt and typable but every letter is a syllable and I think economy >>> of syllab= >>> les is also important....(not clear if prounounced "eight" or >>> "eighty")
>>> Or maybe just Mac, assuming nobody thinks there will ever be a >>> port to pre = >>> MacX, which could be called OldMac or MacClassic or Mac9 anyway >>> if necessar= >>> y.. :)
>>>  
>>> LINUX, LINUXELF, LINUXLIBC6? Please.
>>> Couldn't Linux have been recycled for LINUXLIBC6?
Does anyone >>> have Linux= >>> 1.2 around?
>>> That's the version I've run the most, long ago. :)
>>>  
>>> Anyway I don't care THAT much and I will resist suggesting any >>> more names f= >>> or any preexisting targets or criticizing them.
>>> They almost all stink, esp. the active ones. :)
>>> Are the older FreeBSD ABIs so inferior that it is worth having >>> newer ones? = >>> They didn't have pthreads back then and they do now?
>>>  
>>>  - Jay


>>> >>>
>>>
>>> > Date: Fri, 25 Jan 2008 11:09:59 +0100
> From: >>> wagner at elegosoft.c= >>> om
> To: m3devel at elegosoft.com
> Subject: Re: >>> [M3devel] INSTALL= >>> _ROOT and PKG_USE in cm3.cfg
>
> Quoting Jay >>> <jayk123 at hotma= >>> il.com>:
>
> > using this code on PPC_LINUX >>> and PPC_DARW= >>> IN (should be called
> > PPC_MACOSX but oh well) >>>
>
>= >>> Actually I did the port on a plain DARWIN system from >>> opendarwin.org
&g= >>> t; when this was still alive. So there should be no dependency on >>> MacOS X>> R>> extensions.
>
> 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 2= >>> 345 869 fax: +49 30 23 45 86 95
> http://www.elegosoft.com >>> | Gesch=E4= >>> ftsf=FChrer: Olaf Wagner | Sitz: Berlin
> Handelregister: >>> Amtsgericht= >>> Charlottenburg HRB 77719 | USt-IdNr: DE163214194
> >>>


>> />Helping your favorite cause is as easy as instant >>> messaging.=A0You IM, w= >>> e give. >> source=3Dtext_hotm= >>> ail_join' target=3D'_new'>Learn more. >>> = >>> >>> --_587094ee-5029-41f3-88b0-f4a35ad4e834_-- From jayk123 at hotmail.com Fri Jan 25 16:07:20 2008 From: jayk123 at hotmail.com (Jay) Date: Fri, 25 Jan 2008 15:07:20 +0000 Subject: [M3devel] INSTALL_ROOT and PKG_USE in cm3.cfg In-Reply-To: <20080125133649.vq9xj54iqok00so0@mail.elegosoft.com> References: <4798DEB8.1E75.00D7.1@scires.com> <4798EFAE.1E75.00D7.1@scires.com> <4798FE0E.1E75.00D7.1@scires.com> <479907A8.1E75.00D7.1@scires.com> <4799283C.1E75.00D7.1@scires.com> <20080125110959.5oc8u98w0w8csc80@mail.elegosoft.com> <20080125133649.vq9xj54iqok00so0@mail.elegosoft.com> Message-ID: > I'm with you that they are neither systematic nor intuitive.> I think I could even be persuaded to support a general renaming,> if the scheme and concepts are well considered before. Uh oh... [big ramble...] Darwin: I was surprised, but I understood. I know a lot of the history and I get it. I used the LINUXELF port briefly, or maybe the LINUX (a.out) one. I guess hypothetically you can still boot LINUX 1.2 on either modern hardware or VMs?????? Anyone reporting 10 year uptimes?? Unix ABI: I'm surprised the compat is so bad. Microsoft does an excellent job of ABI compat, but behavioral compat is another matter. > Yes. Actually the X in X Windows and MacOS X refer to completely different> things. MacOS X does not support X Windows out of the box, it uses> Aqua as GUI. I understand. I believe Aqua is mostly just a marketing term even. Apple's got a bazillion different libraries to do the same thing. Want to draw on the screen -- QuickDraw (deprecated) or CoreGraphics, OpenGL.. Want to have a text editor -- TextEdit, MSLTE, and something else, and third party like "WASTE". Want to get a mouse click -- there's two event managers. Want to open a file -- there's like four or more sets of APIs -- FSSpec, FSRef, stdio, unixio, maybe something in Cocoa. Even in the kernel they have multiple frameworks I believe. It appears to be a big random mishmash. They had two APIs for LoadLibrary/GetProcAddress, and then later add dlopen. A lot of this is historical too. They have history back to the early 1980s and they have migration story after migration story after migration story, gradually breaking all existing source code and binaries, but never eveything quite at once. At this point, nothing produced before around the year 2000 can run on an Intel Mac or a PowerPC Mac running 10.5. 10.4 on PowerPC could run stuff going way way back -- 68K even. People used to have access to video memory at fixed addresses, "low memory globals" all kinds of crazy stuff. (Really, I understand -- MacOS X is 10 or Unix. I don't know how/if they are ever going to get to 11. They were up to about version 10 via gradual incrementing through the years. System 7 was a breathrough kind of in the late 80's early 90's, System 7.1ish when the PPC came out in 1994, gradually up to around 7.5, then rapidly through 8 and 9 when Jobs returned before they release Mac OS X. I know a lot here..it's annoying... We had "fat Mac" circa 1984/1985 with 512meg and two floppy drives, a 68020 Mac II, etc. If you see the movie The Firm, when lawyer/actionhero Tom Cruise uses his computer, it plays the Mac floppy disk noise.) And by breathrough, I mean it actually sucked. They had no or nearly no protected memory user/kernel split until this century. Shared library sorts of things were loaded completely into memory at boot time generally. Microsoft beat them by 5+ years, Unix beat by far more. But now it's a fairly level playing field -- everyone has about the same architecture. Except all the low end (free) Unixes seemed to take forever to admit they needed threads, and I doubt any of them scale well. I think they resisted just to avoid being like NT, waiting and waiting and finally giving in, thus some of the ABI issues, no threads, "Linux threads", and finally NPTL -- native pthreads library -- kernel threads. And just when everyone arrived at the same place, along comes web apps distributed across a cluster, too many cores per chip for anyone to schedule... [editing has ripped things away from what they related oh well...] You can have all the smarts you want about your workload and manually schedule (fibers, vtalarm threads), but you'll never likely be able to control what CPU you are on and thus you will generally lose, unless there is only one CPU. I kind of assume we (the larger we m3devel, but indeed, perhaps every pair of developers :) ) would never be able to agree on names. I think the easiest to agree to plan is to leave it alone. But, um, I agree! If we, um, could agree on a scheme and set of names, I'd go for it. I am a little more optimistic than this...but I hesitate, briefly, to suggest... The GNU folks have a system, of triples or more recently quadruples. Something like processor-'hardware'-kernel, I forget and can't look now. 'hardware' seems to be 'unknown' or 'pc' a bunch, so I don't know what it is. uname seems to be the ingredients of most of this. i686-pc-cygwin i686-pc-nt i686-pc-linux ppc-mac-darwin? ppc-mac-classic 68k-mac-classic I figure to vet the design it helps to come up with many examples, even of platforms that don't matter. Maybe even to deal with the msdos mess, could be 16bit, 286, 386.. I agree with you that a double seems to almost always suffice. If you look at the existing names (from memory), I think you can derive something like: {X86,AMD64,PPC,PPC64,ALPHA,MIPS,ARM,SH,SPARC,68K,VAX,IA64,HPPA}_{LINUX,SOLARIS,NT,OSF1,OS2,NEXT,MSDOS,VMS,Mac,OldMac,AIX,HPUX,FreeBSD,NetBSD,OpenBSD} and cover almost the whole problem. This doesn't address the elephants that seems to have finally left the room -- compiler, linker, window library, thread library, C library, modula-3 backend. Probably most platforms should be a 2-tuple but there should guidance on how to build n-tuples. ?? x86-nt-msc-mslink-msgui-kthr-msvcr -- native just call it x86-nt ? x86-nt-gcc-gld-msgui-kthr-msvcr -- mingwin x86-nt-gcc-gld-xwin-kthr-cyg -- nt386gnu x86-nt-gcc-gld-xwin-pthr-cyg -- nt386gnu with pthreads x86-linux-gcc-gld-vga-nothr-newlibx86-linux-icc-glc-nowin-nptl-glibc -- icc Intel compiler x86-linux-gcc-gcc-qtopia-uthread-glibc These names are too long. The n-tuples open up many issues, such as variables that really almost never vary given what preceds them. Linux doesn't always use gcc, but almost. Or whether or not a configuration is link compatible with another. Varying the compiler tends not to break link compatibility, that isn't automatic, it isn't free i general, but the compiler authors usually make it so. You all can see if n-tuples matter for the vast majority of platforms, but they, perhaps matter for x86-nt. But there is a big huge out of this that is in place, as I have said many times.. platform is nt386, everything else is something else, a "configuration" perhaps. Perhaps there should be a few more quake variables specced that cm3 can/should know about. Perhaps all of the target dependencies should be moved into the configuration file?????? I think there's so little, it makes little difference either way. Perhaps the notion of target drops away entire in cm3 and it's all just configuration and has less meaning? I mean..you know, what is the meaning? it's jmpbuf size, it gcc configuration, it's build_dir, those strike me as the majority of what "target" means. alignment, integer-size (always 32...except alpha), whether to use the integrated backend, and if so, a few other variables. I haven't allowed for versions -- FreeBSD4, FreeBSD5, FreeBSD6. I also think, I hate to say, you might want to account for "fat binaries". On a Mac, you can build up for four architectures into one binary. x86,AMD64,PPC,PPC64. However that really strikes at my crazy cross idea and putting in .sh files that call out to the right binary. I heard NextStep/OpenStep ran on four architectures way back when -- 68k, x86, SPARC, HPPA, not to mention the variant the x86 variant that ran in NT (with gcc). Even Win32 lets you build hybrid 16bit/32bit or 16bit/64bit binaries, since there is an "MS-DOS" stub. This is why, of course, you end up with ad-hoc names. Because the extra variables are usually missing, and they vary differently depending on context, so just make up something. Perhaps you use the doubles I gave, and then you are allowed to append a dash and an arbitrary extra string. Oh, sorry, you already said that. You called it "variant". I guess that's it. {x86,AMD64,...}_{NT,SOLARIS,LINUX}{_optional variant} Here are some possible names from this system: X86_NT (WIN? MSWIN?) X86_NT_MINGNU X86_NT_GNU X86_SOLARIS X86_SOLARIS_GNU SPARC_SOLARIS SPARC_SOLARIS_GNU PPC_MAC X86_MAC AMD64_MAC PPC64_MAC IA64_VMS VAX_VMS ALPHA_VMS MIPS_ULTRIX MIPS_IRIX IA64_NT AMD64_NT MIPS_NT PPC_NT PPC_XBOX ? X86_XBOX ? PPC_AIX (Is POWER interesting?) PPC601_AIX ? PPC603_AIX ? G3_MAC ? G4_MAC ? G5_MAC ? PPCG3_MAC ? PPCG4_MAC ? (doesn't run on G3) PPCG4_MAC ? (64 bit, lame names...) X86_MSDOS ? X86_DJGPP ? X86_NT_MWERKS ? X86_NT_DIGITALMARS ? X86_NT_SYMANTEC ? X86_NT_BORLAND ? C_NT ? outputs C code... hm. not right, C gets converted to something else. ALPHA_OSF1 ALPHA_TRU64 ? ALPHA32_NT ? X86_NT_WATCOM ? X86_WINCE ? ARM_WINCE ? ARM_CE ? ARM_MSCE ? ARM_SYMBIAN ? ARM_PALM ? ARM_PALMOS ? X86_BEOS ? 68000_OLDMAC ? 68020_OLDMAC ? Obviously the vast vast vast vast majority of these don't matter, but as I said it helps to see how a bunch of platforms work out to vet the design. I've held back from...6502_APPLEII, 65816_APPLEIIGS.. 6502_C64 :) 65816_SNES ? (Super Nintendo game console) 6502_NES ? (Nintendo...) MIPS_PLAYSTATION ? ?_SONYPS2 ? PPC_SONYPS3 (Linux runs on this, and maybe previous) SH_DREAMCAST ? (NetBSD runs on this... as does CE) X86_XBOX ? MSBOX ? PPC_XBOX360 (or is it PPC64? Oh, and for these things, you probably need to say MS or LINUX) PPC_MSXBOX360 PPC_?XBOX and maybe some virtual machine targets: JVM_ANY ?JAVA_ANY ? MSDOTNET_ANY ?MSIL_ANY ? LLVM_NT ? Is x86 generically named and people can tweak it. Or call it 686 or I686 and if anyone really has an old processor, they can still tweak and rename and keep the name. Sorry if this is all very annoying. I'm ok with doing nothing here. Ultimately as I said, there isn't even that much code involved, as I recall. It seems to me if you move about 50 lines of cm3 out of cm3 into quake, the matter becomes even less "important", because the config file would be the only thing that cared and would only need to make sense to itself. - Jay > Date: Fri, 25 Jan 2008 13:36:49 +0100> From: wagner at elegosoft.com> To: jayk123 at hotmail.com> CC: m3devel at elegosoft.com> Subject: RE: [M3devel] INSTALL_ROOT and PKG_USE in cm3.cfg> > I just wanted to point out why it's call PPC_DARWIN. Now that the> OpenDarwin project has closed down, it may indeed seem strange.> But many of the names can only be understood based on their history.> I'm with you that they are neither systematic nor intuitive.> I think I could even be persuaded to support a general renaming,> if the scheme and concepts are well considered before.> > Quoting Jay :> > > The PPC_DARWIN port has an optional dependency on X Windows..is that > > available for plain Darwin or only with Mac OS X?> > Yes. Actually the X in X Windows and MacOS X refer to completely different> things. MacOS X does not support X Windows out of the box, it uses> Aqua as GUI.> > > I was surprised by "Darwin", therefore would be.. :)> That's why I tried to explain it ;-)> > > LINUX, LINUXELF, LINUXLIBC6? Please.> > Couldn't Linux have been recycled for LINUXLIBC6?Does anyone have > > Linux 1.2 around?> > It could be done now, but it couldn't when it was created.> > > Are the older FreeBSD ABIs so inferior that it is worth having newer > > ones? They didn't have pthreads back then and they do now?> > There are ABI changes with every major release of FreeBSD (and also> Linux, Solaris, and other operating systems if I am not much mistaken).> Of course, everyone strives for compatibility of the often used and> most important interfaces, but there is a grey zone where data> structures common to the kernel and userland are touched, and they> need to be updated (in order to not hinder improvement) more often> than you'd think. If such an update annoys or disturbs users often> enough, new interface abstractions tend to appear that should> avoid the problem for future releases (for example, changes of the> jmp_buf structure break threading code --> new interfaces for thread> context access are defined). The M3 runtime is somewhat special and> differs from the C runtime in that it makes use of quite a number of not> always well-defined system interfaces. We also try to eliminate these> dependencies (VM calls, jmp_buf structure, whole threading, ...)> > Actually I think I was the first one to port any pthread package to> FreeBSD (when working for a company building POS solutions, but we could> never release the code) back in the 1.5 and 2.x days. I used a pthreads> implementation by Frank Mueller.> Official pthread support came much later.> > Olaf> -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194> _________________________________________________________________ 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 Jan 25 16:13:20 2008 From: jayk123 at hotmail.com (Jay) Date: Fri, 25 Jan 2008 15:13:20 +0000 Subject: [M3devel] INSTALL_ROOT and PKG_USE in cm3.cfg In-Reply-To: References: <200801251038.m0PAcHVv014819@camembert.async.caltech.edu> <1A4B11E5-3935-4662-AD1F-CDFB0CB940CB@cs.purdue.edu> Message-ID: Is it usable?buildable? I don't think so but I am curious. Maybe research later, but there are way more pressing matters... I'm fine either way. I think I've said more than my piece, many times over. :) Very cathartic, and less damaging than doing anything to the code. :) Yes yes, I know the names but I don't know what others would know. And I know renaming makes tracking history hard, depending on source control, but pretty much no matter what. This is a huge reason not to rename. History can be super valuable. That's why I took forever to get over the hump and push all the NT386 content into NT386.Common instead of doing it a bit earlier, and I'm still not sure it was a good idea. The code is highly shared though. Perhaps it should be smushed all into NT386 in the source tree and three variants extracted in the build. NT386 seems to have the fewest people that give a damn so... - Jay > From: hosking at cs.purdue.edu> Date: Fri, 25 Jan 2008 09:49:53 -0500> To: hosking at cs.purdue.edu> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] INSTALL_ROOT and PKG_USE in cm3.cfg> > Latest Darwin source is still at http://www.opensource.apple.com/ > darwinsource/> > On Jan 25, 2008, at 9:40 AM, Tony Hosking wrote:> > > Precisely!> >> > On Jan 25, 2008, at 5:38 AM, Mika Nystrom wrote:> >> >> I'm not sure about this MACOSX business.> >>> >> This is what I see when I log in to my Mac:> >>> >> (94)rover:~>ssh -Y lapdog> >> Last login: Tue Jan 22 00:33:21 2008 from rover> >> Welcome to Darwin!> >> [lapdog:~] mika% uname -a> >> Darwin lapdog 8.11.0 Darwin Kernel Version 8.11.0: Wed Oct 10 > >> 18:26:00 PDT 2007; root:xnu-792.24.17~1/RELEASE_PPC Power > >> Macintosh powerpc> >> [lapdog:~] mika%> >>> >>> >>> >> Jay writes:> >>> --_587094ee-5029-41f3-88b0-f4a35ad4e834_> >>> Content-Type: text/plain; charset="iso-8859-1"> >>> Content-Transfer-Encoding: quoted-printable> >>>> >>> ok, but independent of what it's actual dependencies are...how > >>> many people => >>> run Darwin? How many people run Mac OS X? How many people have > >>> heard of Dar=> >>> win (not Charles)? How many people have heard of Mac OS X? Even > >>> among the u=> >>> nusual people who might read anything related to Modula-3 and own > >>> a Macinto=> >>> sh running Mac OS X? I know it's not a popularity contest but.. > >>> NT386 shoul=> >>> d be called Windows. The name "NT" will probably gradually fade > >>> into obscur=> >>> ity and the name "Windows" will live on much longe. Posix and > >>> Unix will pro=> >>> bably be forgotten and people will only have heard of "Linux".> >>> =20> >>> The PPC_DARWIN port has an optional dependency on X Windows..is > >>> that availa=> >>> ble for plain Darwin or only with Mac OS X?> >>> =20> >>> Anyway..it's just a gut feeling I have as to what names people > >>> would look f=> >>> or and find less surprising.> >>> I was surprised by "Darwin", therefore would be.. :)> >>> MacX is maybe a better compromise to be shorter.> >>> or Macintosh for verbosity and without so many initials.. (NT386 > >>> may be sho=> >>> rt and typable but every letter is a syllable and I think economy > >>> of syllab=> >>> les is also important....(not clear if prounounced "eight" or > >>> "eighty")> >>> Or maybe just Mac, assuming nobody thinks there will ever be a > >>> port to pre => >>> MacX, which could be called OldMac or MacClassic or Mac9 anyway > >>> if necessar=> >>> y.. :)> >>> =20> >>> LINUX, LINUXELF, LINUXLIBC6? Please.> >>> Couldn't Linux have been recycled for LINUXLIBC6?Does anyone have > >>> Linux 1.2=> >>> around?> >>> That's the version I've run the most, long ago. :)> >>> =20> >>> Anyway I don't care THAT much and I will resist suggesting any > >>> more names f=> >>> or any preexisting targets or criticizing them.> >>> They almost all stink, esp. the active ones. :)> >>> Are the older FreeBSD ABIs so inferior that it is worth having > >>> newer ones? => >>> They didn't have pthreads back then and they do now?> >>> =20> >>> - Jay> >>>> >>>> >>>> >>>> Date: Fri, 25 Jan 2008 11:09:59 +0100> From: > >>>> wagner at elegosoft.com> To: m3=> >>> devel at elegosoft.com> Subject: Re: [M3devel] INSTALL_ROOT and > >>> PKG_USE in cm3=> >>> .cfg> > Quoting Jay :> > > using this code > >>> on PPC_LINU=> >>> X and PPC_DARWIN (should be called > > PPC_MACOSX but oh well)> > > >>> Actually => >>> I did the port on a plain DARWIN system from opendarwin.org> when > >>> this was => >>> still alive. So there should be no dependency on MacOS X> > >>> extensions.> > Ol=> >>> af> -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav- > >>> Meyer-Allee 2=> >>> 5 / 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 Cha=> >>> rlottenburg HRB 77719 | USt-IdNr: DE163214194>=20> >>> _________________________________________________________________> >>> Helping your favorite cause is as easy as instant > >>> messaging.=A0You IM, we g=> >>> ive.> >>> http://im.live.com/Messenger/IM/Home/?source=3Dtext_hotmail_join=> >>>> >>> --_587094ee-5029-41f3-88b0-f4a35ad4e834_> >>> Content-Type: text/html; charset="iso-8859-1"> >>> Content-Transfer-Encoding: quoted-printable> >>>> >>> > >>> > >>> > >>> > >>> ok, but independent of what it's actual > >>> dependenc=> >>> ies are...how many people run Darwin? How many people run Mac OS > >>> X? How man=> >>> y people have heard of Darwin (not Charles)? How many people have > >>> heard of => >>> Mac OS X? Even among the unusual people who might read anything > >>> related to => >>> Modula-3 and own a Macintosh running Mac OS X? I know it's > >>> not a popul=> >>> arity contest but.. NT386 should be called Windows. The name "NT" > >>> will prob=> >>> ably gradually fade into obscurity and the name "Windows" will > >>> live on much=> >>> longe. Posix and Unix will probably be forgotten and people will > >>> only have=> >>> heard of "Linux".
> >>>  
> >>> The PPC_DARWIN port has an optional dependency on X Windows..is > >>> that availa=> >>> ble for plain Darwin or only with Mac OS X?
> >>>  
> >>> Anyway..it's just a gut feeling I have as to what names people > >>> would look f=> >>> or and find less surprising.
> >>> I was surprised by "Darwin", therefore would be.. :)
> >>> MacX is maybe a better compromise to be shorter.
> >>> or Macintosh for verbosity and without so many initials.. (NT386 > >>> may be sho=> >>> rt and typable but every letter is a syllable and I think economy > >>> of syllab=> >>> les is also important....(not clear if prounounced "eight" or > >>> "eighty")
> >>> Or maybe just Mac, assuming nobody thinks there will ever be a > >>> port to pre => >>> MacX, which could be called OldMac or MacClassic or Mac9 anyway > >>> if necessar=> >>> y.. :)
> >>>  
> >>> LINUX, LINUXELF, LINUXLIBC6? Please.
> >>> Couldn't Linux have been recycled for LINUXLIBC6?
Does anyone > >>> have Linux=> >>> 1.2 around?
> >>> That's the version I've run the most, long ago. :)
> >>>  
> >>> Anyway I don't care THAT much and I will resist suggesting any > >>> more names f=> >>> or any preexisting targets or criticizing them.
> >>> They almost all stink, esp. the active ones. :)
> >>> Are the older FreeBSD ABIs so inferior that it is worth having > >>> newer ones? => >>> They didn't have pthreads back then and they do now?
> >>>  
> >>>  - Jay


> >>>> >>>
> >>>
> >>> > Date: Fri, 25 Jan 2008 11:09:59 +0100
> From: > >>> wagner at elegosoft.c=> >>> om
> To: m3devel at elegosoft.com
> Subject: Re: > >>> [M3devel] INSTALL=> >>> _ROOT and PKG_USE in cm3.cfg
>
> Quoting Jay > >>> <jayk123 at hotma=> >>> il.com>:
>
> > using this code on PPC_LINUX > >>> and PPC_DARW=> >>> IN (should be called
> > PPC_MACOSX but oh well) > >>>
>
>=> >>> Actually I did the port on a plain DARWIN system from > >>> opendarwin.org
&g=> >>> t; when this was still alive. So there should be no dependency on > >>> MacOS X >>> R>> extensions.
>
> 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 2=> >>> 345 869 fax: +49 30 23 45 86 95
> http://www.elegosoft.com > >>> | Gesch=E4=> >>> ftsf=FChrer: Olaf Wagner | Sitz: Berlin
> Handelregister: > >>> Amtsgericht=> >>> Charlottenburg HRB 77719 | USt-IdNr: DE163214194
> > >>>


>>> />Helping your favorite cause is as easy as instant > >>> messaging.=A0You IM, w=> >>> e give. >>> source=3Dtext_hotm=> >>> ail_join' target=3D'_new'>Learn more.> >>> => >>>> >>> --_587094ee-5029-41f3-88b0-f4a35ad4e834_--> _________________________________________________________________ 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 Jan 25 16:14:06 2008 From: jayk123 at hotmail.com (Jay) Date: Fri, 25 Jan 2008 15:14:06 +0000 Subject: [M3devel] INSTALL_ROOT and PKG_USE in cm3.cfg In-Reply-To: References: <4798DEB8.1E75.00D7.1@scires.com> <4798EFAE.1E75.00D7.1@scires.com> <4798FE0E.1E75.00D7.1@scires.com> <479907A8.1E75.00D7.1@scires.com> <4799283C.1E75.00D7.1@scires.com> <20080125110959.5oc8u98w0w8csc80@mail.elegosoft.com> <20080125133649.vq9xj54iqok00so0@mail.elegosoft.com> Message-ID: truncated again! > From: jayk123 at hotmail.com> To: wagner at elegosoft.com> Date: Fri, 25 Jan 2008 15:07:20 +0000> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] INSTALL_ROOT and PKG_USE in cm3.cfg> > > I'm with you that they are neither systematic nor intuitive.> I think I could even be persuaded to support a general renaming,> if the scheme and concepts are well considered before.> Uh oh...> [big ramble...]> > Darwin: I was surprised, but I understood.> > I know a lot of the history and I get it.> I used the LINUXELF port briefly, or maybe the LINUX (a.out) one.> I guess hypothetically you can still boot LINUX 1.2 on either modern hardware or VMs??????> Anyone reporting 10 year uptimes??> > Unix ABI: I'm surprised the compat is so bad. Microsoft does an excellent job of ABI compat, but behavioral compat is another matter.> > > Yes. Actually the X in X Windows and MacOS X refer to completely different> things. MacOS X does not support X Windows out of the box, it uses> Aqua as GUI.> I understand. I believe Aqua is mostly just a marketing term even.> Apple's got a bazillion different libraries to do the same thing.> Want to draw on the screen -- QuickDraw (deprecated) or CoreGraphics, OpenGL..> Want to have a text editor -- TextEdit, MSLTE, and something else, and third party like "WASTE".> Want to get a mouse click -- there's two event managers.> Want to open a file -- there's like four or more sets of APIs -- FSSpec, FSRef, stdio, unixio, maybe something in Cocoa.> Even in the kernel they have multiple frameworks I believe.> It appears to be a big random mishmash.> They had two APIs for LoadLibrary/GetProcAddress, and then later add dlopen _________________________________________________________________ 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 Jan 25 16:21:26 2008 From: jayk123 at hotmail.com (Jay) Date: Fri, 25 Jan 2008 15:21:26 +0000 Subject: [M3devel] FW: INSTALL_ROOT and PKG_USE in cm3.cfg In-Reply-To: <20080125133649.vq9xj54iqok00so0@mail.elegosoft.com> References: <4798DEB8.1E75.00D7.1@scires.com> <4798EFAE.1E75.00D7.1@scires.com> <4798FE0E.1E75.00D7.1@scires.com> <479907A8.1E75.00D7.1@scires.com> <4799283C.1E75.00D7.1@scires.com> <20080125110959.5oc8u98w0w8csc80@mail.elegosoft.com> <20080125133649.vq9xj54iqok00so0@mail.elegosoft.com> Message-ID: This was truncated, and there is a little of value perhaps...except probably just leave all the targets alone and focus on the much less disruptive decision for how to name all the many future targets. :) and the more productive work of bringing them up (I'm thinking, after NT386GNUish stuff, of looking into PPC_{NETBSD,OPENBSD} or NBSD,OBSD. I've got the hardware and the CDs at least.. and then if I'm feeling crazy, X86_DJGPP aka X86_MSDOS or such, and then X86_SOLARIS maybe..I've got X86 and PPC32 you see, grasping at where to go...oh, and AMD64_NT, AMD64_SOLARIS does that exist? Might have to get a new machine for that, but as long as its available in laptop form factor I'm game. (AMD64_F|N|OBSD too, I wonder if AMD64_DJGPP will materialize :) oh but this takes wasting money but AMD64_DARWIN; OLPC is en route but I don't think that merits work, it's just X86_LINUX, I mean LINUXLIBC6.. :) ). No idea how far I'll get here but they are thoughts at least. And fix the Pixmap bug... I basically below just agree with what Olaf already said -- processor-os-variant. Variant is "random", but doing better is probably impossible, and variant is bound to be needed somewhere sometime. And it can be empty so no harm. - Jay From: jayk123 at hotmail.comTo: wagner at elegosoft.comCC: m3devel at elegosoft.comSubject: RE: [M3devel] INSTALL_ROOT and PKG_USE in cm3.cfgDate: Fri, 25 Jan 2008 15:07:20 +0000 > I'm with you that they are neither systematic nor intuitive.> I think I could even be persuaded to support a general renaming,> if the scheme and concepts are well considered before.Uh oh...[big ramble...] Darwin: I was surprised, but I understood. I know a lot of the history and I get it.I used the LINUXELF port briefly, or maybe the LINUX (a.out) one.I guess hypothetically you can still boot LINUX 1.2 on either modern hardware or VMs??????Anyone reporting 10 year uptimes?? Unix ABI: I'm surprised the compat is so bad. Microsoft does an excellent job of ABI compat, but behavioral compat is another matter. > Yes. Actually the X in X Windows and MacOS X refer to completely different> things. MacOS X does not support X Windows out of the box, it uses> Aqua as GUI.I understand. I believe Aqua is mostly just a marketing term even.Apple's got a bazillion different libraries to do the same thing.Want to draw on the screen -- QuickDraw (deprecated) or CoreGraphics, OpenGL..Want to have a text editor -- TextEdit, MSLTE, and something else, and third party like "WASTE".Want to get a mouse click -- there's two event managers.Want to open a file -- there's like four or more sets of APIs -- FSSpec, FSRef, stdio, unixio, maybe something in Cocoa.Even in the kernel they have multiple frameworks I believe.It appears to be a big random mishmash.They had two APIs for LoadLibrary/GetProcAddress, and then later add dlopen.A lot of this is historical too.They have history back to the early 1980s and they have migration story after migration story after migration story, gradually breaking all existing source code and binaries, but never eveything quite at once. At this point, nothing produced before around the year 2000 can run on an Intel Mac or a PowerPC Mac running 10.5. 10.4 on PowerPC could run stuff going way way back -- 68K even. People used to have access to video memory at fixed addresses, "low memory globals" all kinds of crazy stuff. (Really, I understand -- MacOS X is 10 or Unix. I don't know how/if they are ever going to get to 11. They were up to about version 10 via gradual incrementing through the years. System 7 was a breathrough kind of in the late 80's early 90's, System 7.1ish when the PPC came out in 1994, gradually up to around 7.5, then rapidly through 8 and 9 when Jobs returned before they release Mac OS X. I know a lot here..it's annoying... We had "fat Mac" circa 1984/1985 with 512meg and two floppy drives, a 68020 Mac II, etc.If you see the movie The Firm, when lawyer/actionhero Tom Cruise uses his computer, it plays the Mac floppy disk noise.)And by breathrough, I mean it actually sucked. They had no or nearly no protected memory user/kernel split until this century. Shared library sorts of things were loaded completely into memory at boot time generally. Microsoft beat them by 5+ years, Unix beat by far more. But now it's a fairly level playing field -- everyone has about the same architecture. Except all the low end (free) Unixes seemed to take forever to admit they needed threads, and I doubt any of them scale well. I think they resisted just to avoid being like NT, waiting and waiting and finally giving in, thus some of the ABI issues, no threads, "Linux threads", and finally NPTL -- native pthreads library -- kernel threads. And just when everyone arrived at the same place, along comes web apps distributed across a cluster, too many cores per chip for anyone to schedule... [editing has ripped things away from what they related oh well...] You can have all the smarts you want about your workload and manually schedule (fibers, vtalarm threads), but you'll never likely be able to control what CPU you are on and thus you will generally lose, unless there is only one CPU. I kind of assume we (the larger we m3devel, but indeed, perhaps every pair of developers :) ) would never be able to agree on names. I think the easiest to agree to plan is to leave it alone.But, um, I agree! If we, um, could agree on a scheme and set of names, I'd go for it.I am a little more optimistic than this...but I hesitate, briefly, to suggest... The GNU folks have a system, of triples or more recently quadruples.Something like processor-'hardware'-kernel, I forget and can't look now.'hardware' seems to be 'unknown' or 'pc' a bunch, so I don't know what it is.uname seems to be the ingredients of most of this.i686-pc-cygwini686-pc-nti686-pc-linuxppc-mac-darwin?ppc-mac-classic68k-mac-classic I figure to vet the design it helps to come up with many examples, even of platforms that don't matter.Maybe even to deal with the msdos mess, could be 16bit, 286, 386.. I agree with you that a double seems to almost always suffice. If you look at the existing names (from memory), I think you can derive something like:{X86,AMD64,PPC,PPC64,ALPHA,MIPS,ARM,SH,SPARC,68K,VAX,IA64,HPPA}_{LINUX,SOLARIS,NT,OSF1,OS2,NEXT,MSDOS,VMS,Mac,OldMac,AIX,HPUX,FreeBSD,NetBSD,OpenBSD} and cover almost the whole problem. This doesn't address the elephants that seems to have finally left the room -- compiler, linker, window library, thread library, C library, modula-3 backend. Probably most platforms should be a 2-tuple but there should guidance on how to build n-tuples.?? x86-nt-msc-mslink-msgui-kthr-msvcr -- native just call it x86-nt ?x86-nt-gcc-gld-msgui-kthr-msvcr -- mingwinx86-nt-gcc-gld-xwin-kthr-cyg -- nt386gnux86-nt-gcc-gld-xwin-pthr-cyg -- nt386gnu with pthreadsx86-linux-gcc-gld-vga-nothr-newlibx86-linux-icc-glc-nowin-nptl-glibc -- icc Intel compilerx86-linux-gcc-gcc-qtopia-uthread-glibc These names are too long. The n-tuples open up many issues, such as variables that really almost never vary given what preceds them.Linux doesn't always use gcc, but almost.Or whether or not a configuration is link compatible with another.Varying the compiler tends not to break link compatibility, that isn't automatic, it isn't free i general, but the compiler authors usually make it so. You all can see if n-tuples matter for the vast majority of platforms, but they, perhaps matter for x86-nt.But there is a big huge out of this that is in place, as I have said many times.. platform is nt386, everything else is something else, a "configuration" perhaps. Perhaps there should be a few more quake variables specced that cm3 can/should know about. Perhaps all of the target dependencies should be moved into the configuration file?????? I think there's so little, it makes little difference either way. Perhaps the notion of target drops away entire in cm3 and it's all just configuration and has less meaning?I mean..you know, what is the meaning? it's jmpbuf size, it gcc configuration, it's build_dir, those strike me as the majority of what "target" means. alignment, integer-size (always 32...except alpha), whether to use the integrated backend, and if so, a few other variables. I haven't allowed for versions -- FreeBSD4, FreeBSD5, FreeBSD6. I also think, I hate to say, you might want to account for "fat binaries".On a Mac, you can build up for four architectures into one binary.x86,AMD64,PPC,PPC64.However that really strikes at my crazy cross idea and putting in .sh files that call out to the right binary.I heard NextStep/OpenStep ran on four architectures way back when -- 68k, x86, SPARC, HPPA, not to mention the variant the x86 variant that ran in NT (with gcc). Even Win32 lets you build hybrid 16bit/32bit or 16bit/64bit binaries, since there is an "MS-DOS" stub. This is why, of course, you end up with ad-hoc names. Because the extra variables are usually missing, and they vary differently depending on context, so just make up something. Perhaps you use the doubles I gave, and then you are allowed to append a dash and an arbitrary extra string.Oh, sorry, you already said that. You called it "variant". I guess that's it. {x86,AMD64,...}_{NT,SOLARIS,LINUX}{_optional variant} Here are some possible names from this system: X86_NT (WIN? MSWIN?)X86_NT_MINGNUX86_NT_GNUX86_SOLARISX86_SOLARIS_GNUSPARC_SOLARISSPARC_SOLARIS_GNUPPC_MACX86_MACAMD64_MACPPC64_MACIA64_VMSVAX_VMSALPHA_VMSMIPS_ULTRIXMIPS_IRIXIA64_NTAMD64_NTMIPS_NTPPC_NTPPC_XBOX ?X86_XBOX ?PPC_AIX (Is POWER interesting?)PPC601_AIX ?PPC603_AIX ?G3_MAC ?G4_MAC ?G5_MAC ?PPCG3_MAC ?PPCG4_MAC ? (doesn't run on G3)PPCG4_MAC ? (64 bit, lame names...)X86_MSDOS ?X86_DJGPP ? X86_NT_MWERKS ?X86_NT_DIGITALMARS ?X86_NT_SYMANTEC ?X86_NT_BORLAND ?C_NT ? outputs C code... hm. not right, C gets converted to something else.ALPHA_OSF1 ALPHA_TRU64 ?ALPHA32_NT ?X86_NT_WATCOM ?X86_WINCE ?ARM_WINCE ?ARM_CE ?ARM_MSCE ?ARM_SYMBIAN ?ARM_PALM ?ARM_PALMOS ?X86_BEOS ?68000_OLDMAC ?68020_OLDMAC ? Obviously the vast vast vast vast majority of these don't matter, but as I said it helps to see how a bunch of platforms work out to vet the design. I've held back from...6502_APPLEII, 65816_APPLEIIGS.. 6502_C64 :)65816_SNES ? (Super Nintendo game console) 6502_NES ? (Nintendo...)MIPS_PLAYSTATION ??_SONYPS2 ?PPC_SONYPS3 (Linux runs on this, and maybe previous) SH_DREAMCAST ? (NetBSD runs on this... as does CE)X86_XBOX ? MSBOX ?PPC_XBOX360 (or is it PPC64? Oh, and for these things, you probably need to say MS or LINUX)PPC_MSXBOX360PPC_?XBOX and maybe some virtual machine targets:JVM_ANY ?JAVA_ANY ?MSDOTNET_ANY ?MSIL_ANY ?LLVM_NT ? Is x86 generically named and people can tweak it. Or call it 686 or I686 and if anyone really has an old processor, they can still tweak and rename and keep the name. Sorry if this is all very annoying. I'm ok with doing nothing here. Ultimately as I said, there isn't even that much code involved, as I recall.It seems to me if you move about 50 lines of cm3 out of cm3 into quake, the matter becomes even less "important", because the config file would be the only thing that cared and would only need to make sense to itself. - Jay > Date: Fri, 25 Jan 2008 13:36:49 +0100> From: wagner at elegosoft.com> To: jayk123 at hotmail.com> CC: m3devel at elegosoft.com> Subject: RE: [M3devel] INSTALL_ROOT and PKG_USE in cm3.cfg> > I just wanted to point out why it's call PPC_DARWIN. Now that the> OpenDarwin project has closed down, it may indeed seem strange.> But many of the names can only be understood based on their history.> I'm with you that they are neither systematic nor intuitive.> I think I could even be persuaded to support a general renaming,> if the scheme and concepts are well considered before.> > Quoting Jay :> > > The PPC_DARWIN port has an optional dependency on X Windows..is that > > available for plain Darwin or only with Mac OS X?> > Yes. Actually the X in X Windows and MacOS X refer to completely different> things. MacOS X does not support X Windows out of the box, it uses> Aqua as GUI.> > > I was surprised by "Darwin", therefore would be.. :)> That's why I tried to explain it ;-)> > > LINUX, LINUXELF, LINUXLIBC6? Please.> > Couldn't Linux have been recycled for LINUXLIBC6?Does anyone have > > Linux 1.2 around?> > It could be done now, but it couldn't when it was created.> > > Are the older FreeBSD ABIs so inferior that it is worth having newer > > ones? They didn't have pthreads back then and they do now?> > There are ABI changes with every major release of FreeBSD (and also> Linux, Solaris, and other operating systems if I am not much mistaken).> Of course, everyone strives for compatibility of the often used and> most important interfaces, but there is a grey zone where data> structures common to the kernel and userland are touched, and they> need to be updated (in order to not hinder improvement) more often> than you'd think. If such an update annoys or disturbs users often> enough, new interface abstractions tend to appear that should> avoid the problem for future releases (for example, changes of the> jmp_buf structure break threading code --> new interfaces for thread> context access are defined). The M3 runtime is somewhat special and> differs from the C runtime in that it makes use of quite a number of not> always well-defined system interfaces. We also try to eliminate these> dependencies (VM calls, jmp_buf structure, whole threading, ...)> > Actually I think I was the first one to port any pthread package to> FreeBSD (when working for a company building POS solutions, but we could> never release the code) back in the 1.5 and 2.x days. I used a pthreads> implementation by Frank Mueller.> Official pthread support came much later.> > Olaf> -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194> Helping your favorite cause is as easy as instant messaging. You IM, we give. Learn more. _________________________________________________________________ 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 Jan 25 16:41:31 2008 From: jayk123 at hotmail.com (Jay) Date: Fri, 25 Jan 2008 15:41:31 +0000 Subject: [M3devel] m3devel vs. m3support? In-Reply-To: <20080125133649.vq9xj54iqok00so0@mail.elegosoft.com> References: <4798DEB8.1E75.00D7.1@scires.com> <4798EFAE.1E75.00D7.1@scires.com> <4798FE0E.1E75.00D7.1@scires.com> <479907A8.1E75.00D7.1@scires.com> <4799283C.1E75.00D7.1@scires.com> <20080125110959.5oc8u98w0w8csc80@mail.elegosoft.com> <20080125133649.vq9xj54iqok00so0@mail.elegosoft.com> Message-ID: I noticed at the end of the Ubuntu instructions: "see m3-support for help" Which got me thinking: Is m3devel for developers who USE m3, or the developers OF m3. I'm not sure. In particular, is it lower level, discussing how to bring up new targets, how to change the compiler or higher level help with learning the language? Is m3support for support of developers who use m3 (as indicated above), or for infrastructure support for developer OF m3, like fixing networking connectivity to birch or unusual stuff like that? I thought it was the second. AND/OR m3devel is both, if you were to split in half, you'd only have 2 people on each list and you wouldn't need a list? :) (somewhat the small community is a bonus for me, fewer people to piss off if I make a mistake, somewhat it is depressingly small...) - 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 wagner at elegosoft.com Fri Jan 25 18:02:37 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 25 Jan 2008 18:02:37 +0100 Subject: [M3devel] m3devel vs. m3support? In-Reply-To: References: <4798DEB8.1E75.00D7.1@scires.com> <4798EFAE.1E75.00D7.1@scires.com> <4798FE0E.1E75.00D7.1@scires.com> <479907A8.1E75.00D7.1@scires.com> <4799283C.1E75.00D7.1@scires.com> <20080125110959.5oc8u98w0w8csc80@mail.elegosoft.com> <20080125133649.vq9xj54iqok00so0@mail.elegosoft.com> Message-ID: <20080125180237.xderhsyo00wgksgo@mail.elegosoft.com> Quoting Jay : > I noticed at the end of the Ubuntu instructions: > "see m3-support for help" > > Which got me thinking: > > Is m3devel for developers who USE m3, or the developers OF m3. > I'm not sure. In particular, is it lower level, discussing how to > bring up new targets, how to change the compiler > or higher level help with learning the language? > > Is m3support for support of developers who use m3 (as indicated > above), or for infrastructure support for developer OF m3, like > fixing networking connectivity to birch or unusual stuff like that? > I thought it was the second. > > AND/OR m3devel is both, if you were to split in half, you'd only > have 2 people on each list and you wouldn't need a list? :) > > (somewhat the small community is a bonus for me, fewer people to > piss off if I make a mistake, somewhat it is depressingly small...) m3devel was created for developers of M3 and developers using M3. It's a rather technical group. You need to subscribe to it to be able to post. m3-support is (currently) an Elego-internal list of M3-capable users willing to help anybody running into problems with the system. It is basically just a sendmail alias as far as I know, so everybody can freely send mail to it. There is no archive of the mails (or I don't know of it). m3-support is used on all the M3 WWW pages. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Sat Jan 26 07:11:28 2008 From: mika at async.caltech.edu (Mika Nystrom) Date: Fri, 25 Jan 2008 22:11:28 -0800 Subject: [M3devel] INSTALL_ROOT and PKG_USE in cm3.cfg In-Reply-To: Your message of "Fri, 25 Jan 2008 13:36:49 +0100." <20080125133649.vq9xj54iqok00so0@mail.elegosoft.com> Message-ID: <200801260611.m0Q6BS8r045276@camembert.async.caltech.edu> >> LINUX, LINUXELF, LINUXLIBC6? Please. >> Couldn't Linux have been recycled for LINUXLIBC6?Does anyone have >> Linux 1.2 around? > >It could be done now, but it couldn't when it was created. Please don't recycle the names. That's just dumb. More people than you'd think use old hardware and software for reasons that may be out of their control. Mika From jayk123 at hotmail.com Sat Jan 26 10:13:35 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 26 Jan 2008 09:13:35 +0000 Subject: [M3devel] INSTALL_ROOT and PKG_USE in cm3.cfg In-Reply-To: <200801260611.m0Q6BS8r045276@camembert.async.caltech.edu> References: Your message of "Fri, 25 Jan 2008 13:36:49 +0100." <20080125133649.vq9xj54iqok00so0@mail.elegosoft.com> <200801260611.m0Q6BS8r045276@camembert.async.caltech.edu> Message-ID: I'm on the fence. People always miss that changing new software doesn't necessarily impact old software/hardware. Do the LINUX/LINUXELF targets still work? Will they ever again? If they did, couldn't they be renamed as well? X86_LINUX (LINUXLIBC6) X86_LINUX1 or X86_LINUX1_ELF X86_LINUX1_AOUT 1 as in kernel 1.x Or possibly even merged with one and only X86_LINUX and just vary in the configuration file. (Does the codegen even vary across these architectures, or just the the linking options and maybe file format output by as?) Name evolution is tough. There's often some ideal short name Foo and then only in the future you realize you have to differentiate NewAndImprovedFoo or FooX or Foo2 from Foo aka FooClassic aka Foo1 aka OldFoo. FooSr, FooJr, FooIII. Historical records I think are the bigger sale. But sometimes you are just left with cruft upon cruft upon cruft for some hypothetical compat. In this case, it's not a big deal. - Jay > To: wagner at elegosoft.com> Date: Fri, 25 Jan 2008 22:11:28 -0800> From: mika at async.caltech.edu> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] INSTALL_ROOT and PKG_USE in cm3.cfg> > >> LINUX, LINUXELF, LINUXLIBC6? Please.> >> Couldn't Linux have been recycled for LINUXLIBC6?Does anyone have > >> Linux 1.2 around?> >> >It could be done now, but it couldn't when it was created.> > Please don't recycle the names. That's just dumb. More people> than you'd think use old hardware and software for reasons that may> be out of their control.> > Mika _________________________________________________________________ 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 Sun Jan 27 15:03:27 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Sun, 27 Jan 2008 15:03:27 +0100 Subject: [M3devel] Open CM3 regression tests In-Reply-To: <9C00EA97-9B43-43BE-9CDF-EEAC9C1321D5@cs.purdue.edu> References: <20080120211832.GA26993@elegosoft.com> <9C00EA97-9B43-43BE-9CDF-EEAC9C1321D5@cs.purdue.edu> Message-ID: <20080127150327.mh686v2hx4w080w4@mail.elegosoft.com> Quoting Tony Hosking : > The set operations are all coded as external C functions -- should be > easy enough to fix those. Or are there type issues too? Sorry for the long delay. I'm afraid I don't really understand how set operations are implemented after a quick look. I thought it was all done in the Word modules, but these seem to be only self-referring M3 definitions. I'm sure you can point me to the correct location for the >= operation faster than I'll need to find it; I'll have a look at it then. Thanks in advance, Olaf >> --- p155 --- operations on small sets >> --- p1/p155/stderr.pgm 2008-01-20 00:48:16.000000000 +0100 >> +++ ../src/p1/p155/stderr.pgm 2008-01-13 00:55:56.000000000 +0100 >> @@ -2,7 +2,6 @@ >> check set q = {} >> check set r = {a, b} >> check set x = {a, b, e} >> -************************ ERROR: check (NOT (p >= x)) failed >> >>> This concerns the >= operation on sets. The language definition >>> says: >>> >>> infix <=, >= (x,y: Ordinal) : BOOLEAN >>> (x,y: Float) : BOOLEAN >>> (x,y: ADDRESS) : BOOLEAN >>> (x,y: Set) : BOOLEAN >>> >>> In the first three cases, <= returns TRUE if x is at most as large as >>> y. In the last case, <= returns TRUE if every element of x is an >>> element of y. In all cases, it is a static error if the type of x is >>> not assignable to the type of y, or vice versa. The expression x >= y >>> is equivalent to y <= x. >>> >>> So the implementation seems to be plainly wrong. I think the test >>> for the previous operation <= only succeeds accidentally. -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Jan 27 15:26:35 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Sun, 27 Jan 2008 15:26:35 +0100 Subject: [M3devel] Open CM3 regression tests In-Reply-To: References: <20080120211832.GA26993@elegosoft.com> Message-ID: <20080127152635.91rtdsvgsoo4080g@mail.elegosoft.com> Quoting Henning Thielemann : > On Sun, 20 Jan 2008, Olaf Wagner wrote: > >> > no errors for p1 to p115 >> >> --- p116b --- default IEEE floating point tests from Xerox PARC >> --- p1/p116b/stderr.pgm 2008-01-20 00:47:20.000000000 +0100 >> +++ ../src/p1/p116b/stderr.pgm 2008-01-13 00:55:55.000000000 +0100 > > My compiler complains about LONGINT type in src/Test.i3 . I assume that > this is the 64 bit support. Seems that I have to upgrade my compiler. > > In general floating point is a strange issue. You cannot rely on that your > machine supports IEEE format, although most machines do. The precision of > the same float type can be different on different machines. However, the > Float modules shall reflect that. Computation with NaN and Infinity is > broken, it should be avoided and in most cases continueing the computation > with NaN or Infinity only hides the precise error location. It would be > better to abort with an error for a division by zero, overflow and so on. > I think one can enable this with FloatModes. I don't really understand the consequences of what you say above: are the tests wrong and should be adapted, or is the implementation broken for IEEE-default (where most of the FloatMode procedures simply raise exceptions; if so, can we fix that for these platforms), or do we simply rely on broken hardware (x86 floating point processors)? It seems that FloatMode is only implemented for very few targets: DS3100 DS3100_OSF IRIX5 SOLsun SPARC SUN386 VAX. All the others use the default. Will we simply have to implement the missing functionality for all platforms? If so, can e.g. SUN386 be easily adapted to other x86 platforms (FreeBSD4, LINUXLIBC6, I386_DARWIN, NetBSD2_i386)? That would be a start. As I said, I'm no expert in this domain, and would rather rely on others knowledge there. If you don't have a compiler that is up-to-date, you can always use workspaces on birch.elegosoft.com for tests. The regression tests on this machine use CM3 installations at m3 at birch:~/cm3$ ls /home/m3/work/cm3-inst/birch.elegosoft.com/ current last-ok prev-ok rel-5.4.0. If you don't have login access but need it, just let me know. Of course this applies to everybody wanting to work on the tests or other improvements (as long as there aren't hundreds of requests at least :-). Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Sun Jan 27 15:52:04 2008 From: mika at async.caltech.edu (Mika Nystrom) Date: Sun, 27 Jan 2008 06:52:04 -0800 Subject: [M3devel] Open CM3 regression tests In-Reply-To: Your message of "Sun, 27 Jan 2008 15:26:35 +0100." <20080127152635.91rtdsvgsoo4080g@mail.elegosoft.com> Message-ID: <200801271452.m0REq4Oi093531@camembert.async.caltech.edu> Olaf Wagner writes: ... >I don't really understand the consequences of what you say above: >are the tests wrong and should be adapted, or is the implementation >broken for IEEE-default (where most of the FloatMode procedures simply >raise exceptions; if so, can we fix that for these platforms), or do >we simply rely on broken hardware (x86 floating point processors)? > >It seems that FloatMode is only implemented for very few targets: >DS3100 DS3100_OSF IRIX5 SOLsun SPARC SUN386 VAX. All the others use >the default. Will we simply have to implement the missing functionality >for all platforms? If so, can e.g. SUN386 be easily adapted to other >x86 platforms (FreeBSD4, LINUXLIBC6, I386_DARWIN, NetBSD2_i386)? >That would be a start. Hmm this reminds me of something I read a long time ago. My recollection is that what we have is effectively the second implementation of floating point in Modula-3. At some point during the design, I think someone talked to Bill Kahan, and he (or someone like him) persuaded them that the only right way to do floating-point is to provide an interface for turning on and off floating point exceptions. I believe that at least on DS3100, the floating point exceptions (if enabled) are actually turned into bona fide, catch-able, Modula-3 exceptions. It's a little odd because I suppose you can have code like this... TRY x := a/b EXCEPT SomeFloatingException ... END even though no exceptions are declared to be RAISEd anywhere... I think very few programming languages actually support IEEE754 the way Kahan originally envisioned it. Modula-3 on DS3100 is one of the few that actually approach the original intent (most of the others have "fortran" somewhere in their names, and usually only accomplish the goal with compiler flags). It would be very neat if this work could be extended to the modern targets. x86 FP also isn't really that broken---the 8087 was actually to some extent the reference implementation of IEEE754. It works fine if you write back the results between operations. The problem is that it uses higher (EXTENDED) precision internally, so if you keep intermediate values in FP registers you get smaller rounding errors than expected. It's mainly a problem if you are doing step-by-step comparison debugging with an x86 and a non-x86 and you can't somehow tell your compiler to flush intermediate results to memory. Mika From hosking at cs.purdue.edu Sun Jan 27 16:36:04 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 27 Jan 2008 10:36:04 -0500 Subject: [M3devel] Open CM3 regression tests In-Reply-To: <20080127150327.mh686v2hx4w080w4@mail.elegosoft.com> References: <20080120211832.GA26993@elegosoft.com> <9C00EA97-9B43-43BE-9CDF-EEAC9C1321D5@cs.purdue.edu> <20080127150327.mh686v2hx4w080w4@mail.elegosoft.com> Message-ID: <1DA9FA59-6DFF-430C-90C5-F1D30003607A@cs.purdue.edu> The set operations are coded in cm3/m3-libs/m3core/src/Csupport/ Common/hand.c. I notice Jay has made a number of changes here since September -- I wonder if they have broken something. On Jan 27, 2008, at 9:03 AM, Olaf Wagner wrote: > Quoting Tony Hosking : >> The set operations are all coded as external C functions -- should be >> easy enough to fix those. Or are there type issues too? > > Sorry for the long delay. I'm afraid I don't really understand how > set operations are implemented after a quick look. I thought it was > all done in the Word modules, but these seem to be only self-referring > M3 definitions. I'm sure you can point me to the correct location for > the >= operation faster than I'll need to find it; I'll have a look at > it then. > > Thanks in advance, > > Olaf > >>> --- p155 --- operations on small sets >>> --- p1/p155/stderr.pgm 2008-01-20 00:48:16.000000000 +0100 >>> +++ ../src/p1/p155/stderr.pgm 2008-01-13 00:55:56.000000000 +0100 >>> @@ -2,7 +2,6 @@ >>> check set q = {} >>> check set r = {a, b} >>> check set x = {a, b, e} >>> -************************ ERROR: check (NOT (p >= x)) failed >>> >>>> This concerns the >= operation on sets. The language definition >>>> says: >>>> >>>> infix <=, >= (x,y: Ordinal) : BOOLEAN >>>> (x,y: Float) : BOOLEAN >>>> (x,y: ADDRESS) : BOOLEAN >>>> (x,y: Set) : BOOLEAN >>>> >>>> In the first three cases, <= returns TRUE if x is at most as >>>> large as >>>> y. In the last case, <= returns TRUE if every element of x is an >>>> element of y. In all cases, it is a static error if the type of >>>> x is >>>> not assignable to the type of y, or vice versa. The expression x >>>> >= y >>>> is equivalent to y <= x. >>>> >>>> So the implementation seems to be plainly wrong. I think the test >>>> for the previous operation <= only succeeds accidentally. > > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, > Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 > 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: > Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > DE163214194 > From roland.illig at gmx.de Sun Jan 27 17:23:02 2008 From: roland.illig at gmx.de (Roland Illig) Date: Sun, 27 Jan 2008 17:23:02 +0100 Subject: [M3devel] reactor: catalyst vs cm3-ide In-Reply-To: <479223AC.1E75.00D7.1@scires.com> References: <479223AC.1E75.00D7.1@scires.com> Message-ID: <479CAFE6.8050601@gmx.de> Randy Coleburn wrote: > Ok, I've gotten some feedback on the new name for reactor. > > I've attached a PDF that has two pages: one depicts use of Catalyst, > the other CM3-IDE. > > Please let me know which you prefer. If these are going to become logos of any kind, I don't like them both. - They use lots of different font shapes and sizes. This makes the image rather complicated. A logo should use at most one font shape. - There are lots of components in the logo. To view them all, it takes a long time. A logo should be as simple that one can recognize it at a glance. - What does the battery have to do with Modula-3? - How does it relate to the light bulb? - What does the "With Power" on the light bulb mean? Is it important for the logo? - Is there any prior art for these kinds of logos? Roland From dmuysers at hotmail.com Sun Jan 27 18:02:05 2008 From: dmuysers at hotmail.com (Dirk Muysers) Date: Sun, 27 Jan 2008 18:02:05 +0100 Subject: [M3devel] reactor: catalyst vs cm3-ide In-Reply-To: <479223AC.1E75.00D7.1@scires.com> <479CAFE6.8050601@gmx.de> References: <479223AC.1E75.00D7.1@scires.com> <479CAFE6.8050601@gmx.de> Message-ID: What others have done along the same lines: Have a look at the Cocotron (http://www.cocotron.org/Info) -------------------------------------------------- From: "Roland Illig" Sent: Sunday, January 27, 2008 5:23 PM To: "Randy Coleburn" Cc: Subject: Re: [M3devel] reactor: catalyst vs cm3-ide > Randy Coleburn wrote: >> Ok, I've gotten some feedback on the new name for reactor. >> I've attached a PDF that has two pages: one depicts use of Catalyst, >> the other CM3-IDE. >> Please let me know which you prefer. > > If these are going to become logos of any kind, I don't like them both. > > - They use lots of different font shapes and sizes. This makes the image > rather complicated. A logo should use at most one font shape. > > - There are lots of components in the logo. To view them all, it takes a > long time. A logo should be as simple that one can recognize it at a > glance. > > - What does the battery have to do with Modula-3? > > - How does it relate to the light bulb? > > - What does the "With Power" on the light bulb mean? Is it important for > the logo? > > - Is there any prior art for these kinds of logos? > > Roland > From wagner at elegosoft.com Sun Jan 27 18:55:30 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Sun, 27 Jan 2008 18:55:30 +0100 Subject: [M3devel] Open CM3 regression tests In-Reply-To: <1DA9FA59-6DFF-430C-90C5-F1D30003607A@cs.purdue.edu> References: <20080120211832.GA26993@elegosoft.com> <9C00EA97-9B43-43BE-9CDF-EEAC9C1321D5@cs.purdue.edu> <20080127150327.mh686v2hx4w080w4@mail.elegosoft.com> <1DA9FA59-6DFF-430C-90C5-F1D30003607A@cs.purdue.edu> Message-ID: <20080127185530.e255i76vcwckss4o@mail.elegosoft.com> Quoting Tony Hosking : > The set operations are coded in > cm3/m3-libs/m3core/src/Csupport/Common/hand.c. > > I notice Jay has made a number of changes here since September -- I > wonder if they have broken something. I tried different revisions of this file with no difference in the test results. I then took the latest version and added some printfs, and they got never displayed. So I checked what gets linked, but the symbols in question don't occur in the test program: % nm hand.o U __divdi3 U __moddi3 000001e0 R _highbits 00000140 R _lowbits 00000000 T m3_div 000000ac T m3_divL 000001d4 T m3_mod 0000026c T m3_modL U printf 00000494 T set_difference 00000554 T set_eq 0000061c T set_ge 000006ac T set_gt 00000434 T set_intersection 0000077c T set_le 0000080c T set_lt 000003a8 T set_member 000005b8 T set_ne 000008d8 T set_range 000009d8 T set_singleton 000004f4 T set_sym_difference 000003d4 T set_union % nm /usr/local/cm3/pkg/m3core/FreeBSD4/libm3core.so.5 | grep set_ 000243d0 T set_difference 00024490 T set_eq 00024558 T set_ge 000245fc T set_gt 00024370 T set_intersection 000246e0 T set_le 00024784 T set_lt 000242e4 T set_member 000244f4 T set_ne 00024864 T set_range 00024998 T set_singleton 00024430 T set_sym_difference 00024310 T set_union % ldd FreeBSD4/p1/p155/FreeBSD4/pgm FreeBSD4/p1/p155/FreeBSD4/pgm: libtest.so.5 => /d/home/wagner/work/cm3/m3-sys/m3tests/FreeBSD4/libtest.so.5 (0x28085000) libm3.so.5 => /usr/local/cm3/pkg/libm3/FreeBSD4/libm3.so.5 (0x28088000) libm3core.so.5 => /usr/local/cm3/pkg/m3core/FreeBSD4/libm3core.so.5 (0x281aa000) libm.so.4 => /lib/libm.so.4 (0x28a2d000) libpthread.so.2 => /lib/libpthread.so.2 (0x28a46000) libc.so.6 => /lib/libc.so.6 (0x28a6a000) % nm /usr/local/cm3/pkg/m3core/FreeBSD4/libm3core.so.5 | grep set_ 000243d0 T set_difference 00024490 T set_eq 00024558 T set_ge 000245fc T set_gt 00024370 T set_intersection 000246e0 T set_le 00024784 T set_lt 000242e4 T set_member 000244f4 T set_ne 00024864 T set_range 00024998 T set_singleton 00024430 T set_sym_difference 00024310 T set_union luthien [~/work/cm3/m3-sys/m3tests] wagner % ldd FreeBSD4/p1/p155/FreeBSD4/pgm FreeBSD4/p1/p155/FreeBSD4/pgm: libtest.so.5 => /d/home/wagner/work/cm3/m3-sys/m3tests/FreeBSD4/libtest.so.5 (0x28085000) libm3.so.5 => /usr/local/cm3/pkg/libm3/FreeBSD4/libm3.so.5 (0x28088000) libm3core.so.5 => /usr/local/cm3/pkg/m3core/FreeBSD4/libm3core.so.5 (0x281aa000) libm.so.4 => /lib/libm.so.4 (0x28a2d000) libpthread.so.2 => /lib/libpthread.so.2 (0x28a46000) libc.so.6 => /lib/libc.so.6 (0x28a6a000) luthien [~/work/cm3/m3-sys/m3tests] wagner % nm -C -u FreeBSD4/p1/p155/FreeBSD4/pgm U Main_I3 U RTHooks_I3 U RTHooks__CheckLoadTracedRef U RTHooks__Concat U RTHooks__PopEFrame U RTHooks__PushEFrame U RTHooks__TextLitGetChar U RTHooks__TextLitGetChars U RTHooks__TextLitGetWideChar U RTHooks__TextLitGetWideChars U RTHooks__TextLitInfo U RTLinker__AddUnit U RTLinker__InitRuntime U RTProcess__Exit U Stdio_I3 U Test_I3 U Test__checkM U Test__done U Wr_I3 U Wr__Flush U Wr__PutText w _Jv_RegisterClasses w __deregister_frame_info w __register_frame_info U _init_tls U _setjmp U atexit U exit Now I'm rather confused 8-/ Any ideas? Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From rcoleburn at scires.com Sun Jan 27 18:59:32 2008 From: rcoleburn at scires.com (Randy Coleburn) Date: Sun, 27 Jan 2008 12:59:32 -0500 Subject: [M3devel] reactor: catalyst vs cm3-ide In-Reply-To: <479CAFE6.8050601@gmx.de> References: <479223AC.1E75.00D7.1@scires.com> <479CAFE6.8050601@gmx.de> Message-ID: <479C8034.1E75.00D7.1@scires.com> Hi Roland: Thanks for your feedback and to the other folks that responded. At this point, I've elected to go with the CM3-IDE name instead of Catalyst. Despite the fact that several folks like "Catalyst" (it is a more catchy name and easier to pronounce), it did not intuitively convey the purpose of the program and it conflicts with another trademarked name in the industry. As for the graphics, I'm not a trained graphic artist or logo designer. I just tried to put something together that would satisfy the license requirements so we could make this software package available to the community. One of the conditions was that we remove use of the prior trademarked name and logo/graphic. Back a few years ago, Olly Stephens came up with the idea of using the battery theme to show the "power" of Modula-3. In trying to come up with something for CM3-IDE, I went back to Olly's battery theme and embellished it a bit. Here is the message that I was trying to convey: The CM3-IDE light bulb is powered by the Modula-3 battery to perform great things for the developer, including creating, building, running, maintaining, and browsing source code packages. Once we get the CM3-IDE package into the repository, the CM3 community is welcome to improve it and change any of the graphics. I will be putting all of my original artwork in the repository to provide a starting point for anyone who wants to modify the graphics. The original art work was done in Microsoft PowerPoint 2003 and exported to TIF format, then cropped, resized, and converted to GIF as needed for use in the application. I used IrfanView to do the conversions and manipulations from TIF to GIF. An announcement will go out on the m3devel news list as soon as the package has been put in the repository. I am working to finalize the arrangements this week so hopefully you will see it real soon. Regards, Randy >>> Roland Illig 1/27/2008 11:23 AM >>> Randy Coleburn wrote: > Ok, I've gotten some feedback on the new name for reactor. > > I've attached a PDF that has two pages: one depicts use of Catalyst, > the other CM3-IDE. > > Please let me know which you prefer. If these are going to become logos of any kind, I don't like them both. - They use lots of different font shapes and sizes. This makes the image rather complicated. A logo should use at most one font shape. - There are lots of components in the logo. To view them all, it takes a long time. A logo should be as simple that one can recognize it at a glance. - What does the battery have to do with Modula-3? - How does it relate to the light bulb? - What does the "With Power" on the light bulb mean? Is it important for the logo? - Is there any prior art for these kinds of logos? Roland -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Sun Jan 27 21:31:00 2008 From: jayk123 at hotmail.com (Jay) Date: Sun, 27 Jan 2008 20:31:00 +0000 Subject: [M3devel] Open CM3 regression tests In-Reply-To: <20080127185530.e255i76vcwckss4o@mail.elegosoft.com> References: <20080120211832.GA26993@elegosoft.com> <9C00EA97-9B43-43BE-9CDF-EEAC9C1321D5@cs.purdue.edu> <20080127150327.mh686v2hx4w080w4@mail.elegosoft.com> <1DA9FA59-6DFF-430C-90C5-F1D30003607A@cs.purdue.edu> <20080127185530.e255i76vcwckss4o@mail.elegosoft.com> Message-ID: The functions are only used if the set doesn't fit in an integer. I'll try to look at this today. - Jay > Date: Sun, 27 Jan 2008 18:55:30 +0100> From: wagner at elegosoft.com> To: hosking at cs.purdue.edu> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] Open CM3 regression tests> > Quoting Tony Hosking :> > > The set operations are coded in > > cm3/m3-libs/m3core/src/Csupport/Common/hand.c.> >> > I notice Jay has made a number of changes here since September -- I> > wonder if they have broken something.> > I tried different revisions of this file with no difference in the> test results. I then took the latest version and added some printfs,> and they got never displayed. So I checked what gets linked, but the> symbols in question don't occur in the test program:> > % nm hand.o> U __divdi3> U __moddi3> 000001e0 R _highbits> 00000140 R _lowbits> 00000000 T m3_div> 000000ac T m3_divL> 000001d4 T m3_mod> 0000026c T m3_modL> U printf> 00000494 T set_difference> 00000554 T set_eq> 0000061c T set_ge> 000006ac T set_gt> 00000434 T set_intersection> 0000077c T set_le> 0000080c T set_lt> 000003a8 T set_member> 000005b8 T set_ne> 000008d8 T set_range> 000009d8 T set_singleton> 000004f4 T set_sym_difference> 000003d4 T set_union> > % nm /usr/local/cm3/pkg/m3core/FreeBSD4/libm3core.so.5 | grep set_> 000243d0 T set_difference> 00024490 T set_eq> 00024558 T set_ge> 000245fc T set_gt> 00024370 T set_intersection> 000246e0 T set_le> 00024784 T set_lt> 000242e4 T set_member> 000244f4 T set_ne> 00024864 T set_range> 00024998 T set_singleton> 00024430 T set_sym_difference> 00024310 T set_union> > % ldd FreeBSD4/p1/p155/FreeBSD4/pgm> FreeBSD4/p1/p155/FreeBSD4/pgm:> libtest.so.5 => > /d/home/wagner/work/cm3/m3-sys/m3tests/FreeBSD4/libtest.so.5 > (0x28085000)> libm3.so.5 => /usr/local/cm3/pkg/libm3/FreeBSD4/libm3.so.5 > (0x28088000)> libm3core.so.5 => > /usr/local/cm3/pkg/m3core/FreeBSD4/libm3core.so.5 (0x281aa000)> libm.so.4 => /lib/libm.so.4 (0x28a2d000)> libpthread.so.2 => /lib/libpthread.so.2 (0x28a46000)> libc.so.6 => /lib/libc.so.6 (0x28a6a000)> > % nm /usr/local/cm3/pkg/m3core/FreeBSD4/libm3core.so.5 | grep set_> 000243d0 T set_difference> 00024490 T set_eq> 00024558 T set_ge> 000245fc T set_gt> 00024370 T set_intersection> 000246e0 T set_le> 00024784 T set_lt> 000242e4 T set_member> 000244f4 T set_ne> 00024864 T set_range> 00024998 T set_singleton> 00024430 T set_sym_difference> 00024310 T set_union> luthien [~/work/cm3/m3-sys/m3tests] wagner> % ldd FreeBSD4/p1/p155/FreeBSD4/pgm> FreeBSD4/p1/p155/FreeBSD4/pgm:> libtest.so.5 => > /d/home/wagner/work/cm3/m3-sys/m3tests/FreeBSD4/libtest.so.5 > (0x28085000)> libm3.so.5 => /usr/local/cm3/pkg/libm3/FreeBSD4/libm3.so.5 > (0x28088000)> libm3core.so.5 => > /usr/local/cm3/pkg/m3core/FreeBSD4/libm3core.so.5 (0x281aa000)> libm.so.4 => /lib/libm.so.4 (0x28a2d000)> libpthread.so.2 => /lib/libpthread.so.2 (0x28a46000)> libc.so.6 => /lib/libc.so.6 (0x28a6a000)> luthien [~/work/cm3/m3-sys/m3tests] wagner> % nm -C -u FreeBSD4/p1/p155/FreeBSD4/pgm> U Main_I3> U RTHooks_I3> U RTHooks__CheckLoadTracedRef> U RTHooks__Concat> U RTHooks__PopEFrame> U RTHooks__PushEFrame> U RTHooks__TextLitGetChar> U RTHooks__TextLitGetChars> U RTHooks__TextLitGetWideChar> U RTHooks__TextLitGetWideChars> U RTHooks__TextLitInfo> U RTLinker__AddUnit> U RTLinker__InitRuntime> U RTProcess__Exit> U Stdio_I3> U Test_I3> U Test__checkM> U Test__done> U Wr_I3> U Wr__Flush> U Wr__PutText> w _Jv_RegisterClasses> w __deregister_frame_info> w __register_frame_info> U _init_tls> U _setjmp> U atexit> U exit> > Now I'm rather confused 8-/> > Any ideas?> > Olaf> -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194> _________________________________________________________________ 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 Sun Jan 27 21:33:34 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 27 Jan 2008 15:33:34 -0500 Subject: [M3devel] Open CM3 regression tests In-Reply-To: <20080127185530.e255i76vcwckss4o@mail.elegosoft.com> References: <20080120211832.GA26993@elegosoft.com> <9C00EA97-9B43-43BE-9CDF-EEAC9C1321D5@cs.purdue.edu> <20080127150327.mh686v2hx4w080w4@mail.elegosoft.com> <1DA9FA59-6DFF-430C-90C5-F1D30003607A@cs.purdue.edu> <20080127185530.e255i76vcwckss4o@mail.elegosoft.com> Message-ID: <417F5D6F-D9A1-41C0-8B2F-58056170C5F4@cs.purdue.edu> Are your sets larger than a single word? The M3 frontend compiles small sets (elements <= BITSIZE(Word.T)) differently from large (elements > BITSIZE(Word.T)). The out-of-line set operations are only for large sets. On Jan 27, 2008, at 12:55 PM, Olaf Wagner wrote: > Quoting Tony Hosking : > >> The set operations are coded in cm3/m3-libs/m3core/src/Csupport/ >> Common/hand.c. >> >> I notice Jay has made a number of changes here since September -- I >> wonder if they have broken something. > > I tried different revisions of this file with no difference in the > test results. I then took the latest version and added some printfs, > and they got never displayed. So I checked what gets linked, but the > symbols in question don't occur in the test program: > > % nm hand.o > U __divdi3 > U __moddi3 > 000001e0 R _highbits > 00000140 R _lowbits > 00000000 T m3_div > 000000ac T m3_divL > 000001d4 T m3_mod > 0000026c T m3_modL > U printf > 00000494 T set_difference > 00000554 T set_eq > 0000061c T set_ge > 000006ac T set_gt > 00000434 T set_intersection > 0000077c T set_le > 0000080c T set_lt > 000003a8 T set_member > 000005b8 T set_ne > 000008d8 T set_range > 000009d8 T set_singleton > 000004f4 T set_sym_difference > 000003d4 T set_union > > % nm /usr/local/cm3/pkg/m3core/FreeBSD4/libm3core.so.5 | grep set_ > 000243d0 T set_difference > 00024490 T set_eq > 00024558 T set_ge > 000245fc T set_gt > 00024370 T set_intersection > 000246e0 T set_le > 00024784 T set_lt > 000242e4 T set_member > 000244f4 T set_ne > 00024864 T set_range > 00024998 T set_singleton > 00024430 T set_sym_difference > 00024310 T set_union > > % ldd FreeBSD4/p1/p155/FreeBSD4/pgm > FreeBSD4/p1/p155/FreeBSD4/pgm: > libtest.so.5 => /d/home/wagner/work/cm3/m3-sys/m3tests/ > FreeBSD4/libtest.so.5 (0x28085000) > libm3.so.5 => /usr/local/cm3/pkg/libm3/FreeBSD4/libm3.so.5 > (0x28088000) > libm3core.so.5 => /usr/local/cm3/pkg/m3core/FreeBSD4/ > libm3core.so.5 (0x281aa000) > libm.so.4 => /lib/libm.so.4 (0x28a2d000) > libpthread.so.2 => /lib/libpthread.so.2 (0x28a46000) > libc.so.6 => /lib/libc.so.6 (0x28a6a000) > > % nm /usr/local/cm3/pkg/m3core/FreeBSD4/libm3core.so.5 | grep set_ > 000243d0 T set_difference > 00024490 T set_eq > 00024558 T set_ge > 000245fc T set_gt > 00024370 T set_intersection > 000246e0 T set_le > 00024784 T set_lt > 000242e4 T set_member > 000244f4 T set_ne > 00024864 T set_range > 00024998 T set_singleton > 00024430 T set_sym_difference > 00024310 T set_union > luthien [~/work/cm3/m3-sys/m3tests] wagner > % ldd FreeBSD4/p1/p155/FreeBSD4/pgm > FreeBSD4/p1/p155/FreeBSD4/pgm: > libtest.so.5 => /d/home/wagner/work/cm3/m3-sys/m3tests/ > FreeBSD4/libtest.so.5 (0x28085000) > libm3.so.5 => /usr/local/cm3/pkg/libm3/FreeBSD4/libm3.so.5 > (0x28088000) > libm3core.so.5 => /usr/local/cm3/pkg/m3core/FreeBSD4/ > libm3core.so.5 (0x281aa000) > libm.so.4 => /lib/libm.so.4 (0x28a2d000) > libpthread.so.2 => /lib/libpthread.so.2 (0x28a46000) > libc.so.6 => /lib/libc.so.6 (0x28a6a000) > luthien [~/work/cm3/m3-sys/m3tests] wagner > % nm -C -u FreeBSD4/p1/p155/FreeBSD4/pgm > U Main_I3 > U RTHooks_I3 > U RTHooks__CheckLoadTracedRef > U RTHooks__Concat > U RTHooks__PopEFrame > U RTHooks__PushEFrame > U RTHooks__TextLitGetChar > U RTHooks__TextLitGetChars > U RTHooks__TextLitGetWideChar > U RTHooks__TextLitGetWideChars > U RTHooks__TextLitInfo > U RTLinker__AddUnit > U RTLinker__InitRuntime > U RTProcess__Exit > U Stdio_I3 > U Test_I3 > U Test__checkM > U Test__done > U Wr_I3 > U Wr__Flush > U Wr__PutText > w _Jv_RegisterClasses > w __deregister_frame_info > w __register_frame_info > U _init_tls > U _setjmp > U atexit > U exit > > Now I'm rather confused 8-/ > > Any ideas? > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, > Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 > 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: > Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > DE163214194 > From jayk123 at hotmail.com Sun Jan 27 21:44:52 2008 From: jayk123 at hotmail.com (Jay) Date: Sun, 27 Jan 2008 20:44:52 +0000 Subject: [M3devel] Open CM3 regression tests In-Reply-To: <417F5D6F-D9A1-41C0-8B2F-58056170C5F4@cs.purdue.edu> References: <20080120211832.GA26993@elegosoft.com> <9C00EA97-9B43-43BE-9CDF-EEAC9C1321D5@cs.purdue.edu> <20080127150327.mh686v2hx4w080w4@mail.elegosoft.com> <1DA9FA59-6DFF-430C-90C5-F1D30003607A@cs.purdue.edu> <20080127185530.e255i76vcwckss4o@mail.elegosoft.com> <417F5D6F-D9A1-41C0-8B2F-58056170C5F4@cs.purdue.edu> Message-ID: Yes. C:\dev2\cm3.2\m3-sys\m3tests\src\p1\p155\Main.m3 (* Copyright (C) 1994, Digital Equipment Corporation. *)(* All rights reserved. *)(* See the file COPYRIGHT for a full description. *) (* Last modified on Tue Oct 27 14:49:19 PST 1992 by kalsow *)(* modified on Wed Oct 10 13:15:01 1990 by saxe *) (* Set operators on a small set type. *) MODULE Main;IMPORT Test, Wr;FROM Stdio IMPORT stderr; TYPE Elt = {a, b, c, d, e}; Set = SET OF Elt; VAR x: Set; CONST p = Set{Elt.a, Elt.c, Elt.e}; q = Set{}; r = Set{Elt.a .. Elt.b, Elt.a .. Elt.a (* , Elt.d .. Elt.b *)}; PROCEDURE m( s: TEXT ) = BEGIN TRY Wr.PutText (stderr, s & "\n"); Wr.Flush (stderr); EXCEPT ELSE END; END m; BEGIN m ("check set p = {a, c, e}"); Test.checkM (Elt.a IN p, "Elt.a IN p"); Test.checkM (NOT (Elt.b IN p), "NOT (Elt.b IN p)"); Test.checkM (Elt.c IN p, "Elt.c IN p"); Test.checkM (NOT (Elt.d IN p), "NOT (Elt.d IN p)"); Test.checkM (Elt.e IN p, "(Elt.e IN p"); m ("check set q = {}"); Test.checkM (NOT (Elt.a IN q), "NOT (Elt.a IN q)"); Test.checkM (NOT (Elt.b IN q), "NOT (Elt.b IN q)"); Test.checkM (NOT (Elt.c IN q), "NOT (Elt.c IN q)"); Test.checkM (NOT (Elt.d IN q), "NOT (Elt.d IN q)"); Test.checkM (NOT (Elt.e IN q), "NOT (Elt.e IN q)"); m ("check set r = {a, b}"); Test.checkM (Elt.a IN r, "Elt.a IN r"); Test.checkM (Elt.b IN r, "Elt.b IN r"); Test.checkM (NOT (Elt.c IN r), "NOT (Elt.c IN r)"); Test.checkM (NOT (Elt.d IN r), "NOT (Elt.d IN r)"); Test.checkM (NOT (Elt.e IN r), "NOT (Elt.e IN r)"); Test.checkM (r = Set{Elt.b, Elt.a}, "r = Set{Elt.b, Elt.a}"); (** Test.checkM (-p = Set{Elt.d, Elt.b}); **) (** Test.checkM (+p = p); **) Test.checkM (p - p = q, "check (p - p = q)"); Test.checkM ((p - r) * (r - p) = q, "check ((p - r) * (r - p) = q)"); Test.checkM (p - r = Set{Elt.c, Elt.e}, "check (p - r = Set{Elt.c, Elt.e})"); Test.checkM (p + p = p, "check (p + p = p)"); Test.checkM (p + r = Set{Elt.a, Elt.b, Elt.c, Elt.e}, "check (p + r = Set{Elt.a, Elt.b, Elt.c, Elt.e})"); (** Test.checkM (-(-(r)) = r); **) Test.checkM (p * r = Set{Elt.a}, "check (p * r = Set{Elt.a})"); Test.checkM (p * q = Set{}, "check (p * q = Set{})"); Test.checkM (p # q, "check (p # q)"); Test.checkM (q < p, "check (q < p)"); Test.checkM (NOT (p < r), "check (NOT (p < r))"); Test.checkM (NOT (p > r), "check (NOT (p > r))"); Test.checkM (NOT (p = r), "check (NOT (p = r))"); Test.checkM ((p / r) = (Set{Elt.b, Elt.c, Elt.e}), "check ((p / r) = (Set{Elt.b, Elt.c, Elt.e}))"); Test.checkM (r / q = q / r, "check (r / q = q / r)"); Test.checkM (r / p / r / p / q / r = r, "check (r / p / r / p / q / r = r)"); Test.checkM (p / r - r / p = q, "check (p / r - r / p = q)"); x := p; x := x + Set{Elt.b}; (*INCL(x, Elt.b);*) (* x = { a, b, c, e } *) Test.checkM (x > p, "check (x > p)"); Test.checkM (x >= p, "check (x >= p)"); Test.checkM (p <= x, "check (p <= x)"); Test.checkM (p # x, "check (p # x)"); x := x - Set{Elt.c}; (*EXCL(x, Elt.c);*) (* x = { a, b, e } *) m ("check set x = {a, b, e}"); Test.checkM (Elt.a IN x, "Elt.a IN x"); Test.checkM (Elt.b IN x, "Elt.b IN x"); Test.checkM (NOT (Elt.c IN x), "NOT (Elt.c IN x)"); Test.checkM (NOT (Elt.d IN x), "NOT (Elt.d IN x)"); Test.checkM (Elt.e IN x, "Elt.e IN x"); Test.checkM (NOT (p <= x), "check (NOT (p <= x))"); Test.checkM (NOT (p >= x), "check (NOT (p >= x))"); Test.checkM (x = r + Set{Elt.e}, "check (x = r + Set{Elt.e})"); Test.done ();END Main. -Jay > From: hosking at cs.purdue.edu> Date: Sun, 27 Jan 2008 15:33:34 -0500> To: wagner at elegosoft.com> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] Open CM3 regression tests> > Are your sets larger than a single word? The M3 frontend compiles > small sets (elements <= BITSIZE(Word.T)) differently from large > (elements > BITSIZE(Word.T)). The out-of-line set operations are > only for large sets.> > > On Jan 27, 2008, at 12:55 PM, Olaf Wagner wrote:> > > Quoting Tony Hosking :> >> >> The set operations are coded in cm3/m3-libs/m3core/src/Csupport/ > >> Common/hand.c.> >>> >> I notice Jay has made a number of changes here since September -- I> >> wonder if they have broken something.> >> > I tried different revisions of this file with no difference in the> > test results. I then took the latest version and added some printfs,> > and they got never displayed. So I checked what gets linked, but the> > symbols in question don't occur in the test program:> >> > % nm hand.o> > U __divdi3> > U __moddi3> > 000001e0 R _highbits> > 00000140 R _lowbits> > 00000000 T m3_div> > 000000ac T m3_divL> > 000001d4 T m3_mod> > 0000026c T m3_modL> > U printf> > 00000494 T set_difference> > 00000554 T set_eq> > 0000061c T set_ge> > 000006ac T set_gt> > 00000434 T set_intersection> > 0000077c T set_le> > 0000080c T set_lt> > 000003a8 T set_member> > 000005b8 T set_ne> > 000008d8 T set_range> > 000009d8 T set_singleton> > 000004f4 T set_sym_difference> > 000003d4 T set_union> >> > % nm /usr/local/cm3/pkg/m3core/FreeBSD4/libm3core.so.5 | grep set_> > 000243d0 T set_difference> > 00024490 T set_eq> > 00024558 T set_ge> > 000245fc T set_gt> > 00024370 T set_intersection> > 000246e0 T set_le> > 00024784 T set_lt> > 000242e4 T set_member> > 000244f4 T set_ne> > 00024864 T set_range> > 00024998 T set_singleton> > 00024430 T set_sym_difference> > 00024310 T set_union> >> > % ldd FreeBSD4/p1/p155/FreeBSD4/pgm> > FreeBSD4/p1/p155/FreeBSD4/pgm:> > libtest.so.5 => /d/home/wagner/work/cm3/m3-sys/m3tests/ > > FreeBSD4/libtest.so.5 (0x28085000)> > libm3.so.5 => /usr/local/cm3/pkg/libm3/FreeBSD4/libm3.so.5 > > (0x28088000)> > libm3core.so.5 => /usr/local/cm3/pkg/m3core/FreeBSD4/ > > libm3core.so.5 (0x281aa000)> > libm.so.4 => /lib/libm.so.4 (0x28a2d000)> > libpthread.so.2 => /lib/libpthread.so.2 (0x28a46000)> > libc.so.6 => /lib/libc.so.6 (0x28a6a000)> >> > % nm /usr/local/cm3/pkg/m3core/FreeBSD4/libm3core.so.5 | grep set_> > 000243d0 T set_difference> > 00024490 T set_eq> > 00024558 T set_ge> > 000245fc T set_gt> > 00024370 T set_intersection> > 000246e0 T set_le> > 00024784 T set_lt> > 000242e4 T set_member> > 000244f4 T set_ne> > 00024864 T set_range> > 00024998 T set_singleton> > 00024430 T set_sym_difference> > 00024310 T set_union> > luthien [~/work/cm3/m3-sys/m3tests] wagner> > % ldd FreeBSD4/p1/p155/FreeBSD4/pgm> > FreeBSD4/p1/p155/FreeBSD4/pgm:> > libtest.so.5 => /d/home/wagner/work/cm3/m3-sys/m3tests/ > > FreeBSD4/libtest.so.5 (0x28085000)> > libm3.so.5 => /usr/local/cm3/pkg/libm3/FreeBSD4/libm3.so.5 > > (0x28088000)> > libm3core.so.5 => /usr/local/cm3/pkg/m3core/FreeBSD4/ > > libm3core.so.5 (0x281aa000)> > libm.so.4 => /lib/libm.so.4 (0x28a2d000)> > libpthread.so.2 => /lib/libpthread.so.2 (0x28a46000)> > libc.so.6 => /lib/libc.so.6 (0x28a6a000)> > luthien [~/work/cm3/m3-sys/m3tests] wagner> > % nm -C -u FreeBSD4/p1/p155/FreeBSD4/pgm> > U Main_I3> > U RTHooks_I3> > U RTHooks__CheckLoadTracedRef> > U RTHooks__Concat> > U RTHooks__PopEFrame> > U RTHooks__PushEFrame> > U RTHooks__TextLitGetChar> > U RTHooks__TextLitGetChars> > U RTHooks__TextLitGetWideChar> > U RTHooks__TextLitGetWideChars> > U RTHooks__TextLitInfo> > U RTLinker__AddUnit> > U RTLinker__InitRuntime> > U RTProcess__Exit> > U Stdio_I3> > U Test_I3> > U Test__checkM> > U Test__done> > U Wr_I3> > U Wr__Flush> > U Wr__PutText> > w _Jv_RegisterClasses> > w __deregister_frame_info> > w __register_frame_info> > U _init_tls> > U _setjmp> > U atexit> > U exit> >> > Now I'm rather confused 8-/> >> > Any ideas?> >> > Olaf> > -- > > Olaf Wagner -- elego Software Solutions GmbH> > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, > > Germany> > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 > > 45 86 95> > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: > > Berlin> > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > > DE163214194> >> _________________________________________________________________ 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 Sun Jan 27 21:54:55 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Sun, 27 Jan 2008 21:54:55 +0100 Subject: [M3devel] Open CM3 regression tests In-Reply-To: <417F5D6F-D9A1-41C0-8B2F-58056170C5F4@cs.purdue.edu> References: <20080120211832.GA26993@elegosoft.com> <9C00EA97-9B43-43BE-9CDF-EEAC9C1321D5@cs.purdue.edu> <20080127150327.mh686v2hx4w080w4@mail.elegosoft.com> <1DA9FA59-6DFF-430C-90C5-F1D30003607A@cs.purdue.edu> <20080127185530.e255i76vcwckss4o@mail.elegosoft.com> <417F5D6F-D9A1-41C0-8B2F-58056170C5F4@cs.purdue.edu> Message-ID: <20080127215455.4q09uyuj8ko40k4w@mail.elegosoft.com> Quoting Tony Hosking : > Are your sets larger than a single word? The M3 frontend compiles > small sets (elements <= BITSIZE(Word.T)) differently from large > (elements > BITSIZE(Word.T)). The out-of-line set operations are only > for large sets. These are small sets. There are other tests for large sets, which seem to succeed. So obviously the problem is in the cm3cg backend, as in m3middle set_compare will only write Cmd (u, OpName [op]); Int (u, s); TName (u, t); which then gets read by the actual code generator. I guess one of you guys will be much faster tracking this down through the gcc tree construction and manipulation code. It's been several years that I have had a look at that. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From hosking at cs.purdue.edu Sun Jan 27 22:31:22 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 27 Jan 2008 16:31:22 -0500 Subject: [M3devel] Open CM3 regression tests In-Reply-To: <20080127215455.4q09uyuj8ko40k4w@mail.elegosoft.com> References: <20080120211832.GA26993@elegosoft.com> <9C00EA97-9B43-43BE-9CDF-EEAC9C1321D5@cs.purdue.edu> <20080127150327.mh686v2hx4w080w4@mail.elegosoft.com> <1DA9FA59-6DFF-430C-90C5-F1D30003607A@cs.purdue.edu> <20080127185530.e255i76vcwckss4o@mail.elegosoft.com> <417F5D6F-D9A1-41C0-8B2F-58056170C5F4@cs.purdue.edu> <20080127215455.4q09uyuj8ko40k4w@mail.elegosoft.com> Message-ID: <45340E89-F1AD-40CC-BF84-77607A35D4A8@cs.purdue.edu> It is the *front* end that compiles small sets into word operations. The backend doesn't even see small sets. So, this suggests that the small sets are failing due to some interaction between the front end and back end. On Jan 27, 2008, at 3:54 PM, Olaf Wagner wrote: > Quoting Tony Hosking : > >> Are your sets larger than a single word? The M3 frontend compiles >> small sets (elements <= BITSIZE(Word.T)) differently from large >> (elements > BITSIZE(Word.T)). The out-of-line set operations are >> only >> for large sets. > > These are small sets. There are other tests for large sets, which seem > to succeed. > > So obviously the problem is in the cm3cg backend, as in m3middle > set_compare will only write > > Cmd (u, OpName [op]); > Int (u, s); > TName (u, t); > > which then gets read by the actual code generator. > I guess one of you guys will be much faster tracking this down > through the gcc tree construction and manipulation code. It's been > several years that I have had a look at that. > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, > Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 > 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: > Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > DE163214194 > From wagner at elegosoft.com Sun Jan 27 23:11:57 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Sun, 27 Jan 2008 23:11:57 +0100 Subject: [M3devel] Open CM3 regression tests In-Reply-To: <45340E89-F1AD-40CC-BF84-77607A35D4A8@cs.purdue.edu> References: <20080120211832.GA26993@elegosoft.com> <9C00EA97-9B43-43BE-9CDF-EEAC9C1321D5@cs.purdue.edu> <20080127150327.mh686v2hx4w080w4@mail.elegosoft.com> <1DA9FA59-6DFF-430C-90C5-F1D30003607A@cs.purdue.edu> <20080127185530.e255i76vcwckss4o@mail.elegosoft.com> <417F5D6F-D9A1-41C0-8B2F-58056170C5F4@cs.purdue.edu> <20080127215455.4q09uyuj8ko40k4w@mail.elegosoft.com> <45340E89-F1AD-40CC-BF84-77607A35D4A8@cs.purdue.edu> Message-ID: <20080127231157.7y1adg5bksw08o0k@mail.elegosoft.com> Quoting Tony Hosking : > It is the *front* end that compiles small sets into word operations. > The backend doesn't even see small sets. So, this suggests that the > small sets are failing due to some interaction between the front end > and back end. Sorry if I seem to be a bit slow (I've caught a bronchitis again and perhaps cannot think as clearly as I should)... So you think the error is in m3-sys/m3front/src/exprs/SetExpr.m3 in PROCEDURE Compare (a, b: Expr.T; VAR sign: INTEGER): BOOLEAN = and PROCEDURE Visit (VAR s: VisitState): BOOLEAN = or rather in m3middle while writing the intermediate representation? Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Jan 28 00:18:05 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 27 Jan 2008 18:18:05 -0500 Subject: [M3devel] Open CM3 regression tests In-Reply-To: <20080127231157.7y1adg5bksw08o0k@mail.elegosoft.com> References: <20080120211832.GA26993@elegosoft.com> <9C00EA97-9B43-43BE-9CDF-EEAC9C1321D5@cs.purdue.edu> <20080127150327.mh686v2hx4w080w4@mail.elegosoft.com> <1DA9FA59-6DFF-430C-90C5-F1D30003607A@cs.purdue.edu> <20080127185530.e255i76vcwckss4o@mail.elegosoft.com> <417F5D6F-D9A1-41C0-8B2F-58056170C5F4@cs.purdue.edu> <20080127215455.4q09uyuj8ko40k4w@mail.elegosoft.com> <45340E89-F1AD-40CC-BF84-77607A35D4A8@cs.purdue.edu> <20080127231157.7y1adg5bksw08o0k@mail.elegosoft.com> Message-ID: I would be surprised if the front-end is wrong, but it might be. It might also be some strange interaction with the backend. I can put this on my stack of things to look at, but it will be a little while as I catch up with other things -- I've only just begun to regain usable sight in one of my eyes after scratching a cornea last week. On Jan 27, 2008, at 5:11 PM, Olaf Wagner wrote: > Quoting Tony Hosking : > >> It is the *front* end that compiles small sets into word operations. >> The backend doesn't even see small sets. So, this suggests that the >> small sets are failing due to some interaction between the front end >> and back end. > > Sorry if I seem to be a bit slow (I've caught a bronchitis again > and perhaps cannot think as clearly as I should)... So you think > the error is in m3-sys/m3front/src/exprs/SetExpr.m3 in > > PROCEDURE Compare (a, b: Expr.T; VAR sign: INTEGER): BOOLEAN = > and > PROCEDURE Visit (VAR s: VisitState): BOOLEAN = > > or rather in m3middle while writing the intermediate representation? > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, > Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Jan 28 10:48:31 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 28 Jan 2008 09:48:31 +0000 Subject: [M3devel] heap vs. stack? (sort of) Message-ID: Is it possible to have this pattern in Modula-3: PROCEDURE Parse (nm: TEXT; host: BOOLEAN): T = VAR len := Text.Length (nm); buf: ARRAY [0..255] OF CHAR; BEGIN IF (len <= NUMBER (buf)) THEN RETURN DoParse (nm, SUBARRAY (buf, 0, len), host); ELSE RETURN DoParse (nm, NEW (REF ARRAY OF CHAR, len)^, host); END; END Parse; PROCEDURE DoParse (nm_txt: TEXT; VAR nm: ARRAY OF CHAR; host: BOOLEAN): T = without the extra function? There are places in M3Path.m3 that duplicate code otherwise, one branch acting on a local stack allocated array, the other acting on a heap allocated array when the stack array is too small, but otherwise identical code. So far I have not figured out how. Local variables cannot be open array. SUBARRAY returns an ARRAY and not a REF ARRAY... It seems that parameters can be open arrays but local variables cannot, and that seems wrong.. parameters and locals so often share characteristics... - 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 Jan 28 12:29:31 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 28 Jan 2008 11:29:31 +0000 Subject: [M3devel] nt386gnu threads? Message-ID: Can anyone confirm my read that PM3's NT386GNU used user/vtalarm threads? PM3 appears to have no PThread support ant its NT386GNU appears to have OS_TYPE=POSIX. Heck, even its NT386 has OS_TYPE=POSIX, but its NT386 is probably dead/broken. 1) I'm too lazy to tediously rewrite Cygwin's pthread.h et. al. into Modula-3. 2) The thread library you pick is not an independent decision. The Modula-3 File I/O libraries interact with the threading library at least a little bit. The path of less resistance seems to be user/vtalarm threads for now, until such time as Cygwin Upthread.i3 is written. (That is, neither pthreads nor win32 satisfied my laziness; I'm going to try user/vtalarm threads, see how it goes; I'm sure they aren't very good, but...) - Jay _________________________________________________________________ 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 Mon Jan 28 12:39:10 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Mon, 28 Jan 2008 12:39:10 +0100 (MET) Subject: [M3devel] heap vs. stack? (sort of) In-Reply-To: References: Message-ID: On Mon, 28 Jan 2008, Jay wrote: > Is it possible to have this pattern in Modula-3: > > PROCEDURE Parse (nm: TEXT; host: BOOLEAN): T = VAR len := Text.Length (nm); buf: ARRAY [0..255] OF CHAR; BEGIN IF (len <= NUMBER (buf)) THEN RETURN DoParse (nm, SUBARRAY (buf, 0, len), host); ELSE RETURN DoParse (nm, NEW (REF ARRAY OF CHAR, len)^, host); END; END Parse; > > PROCEDURE DoParse (nm_txt: TEXT; VAR nm: ARRAY OF CHAR; host: BOOLEAN): T = I think it is a good idea to encapsulate the common code in DoParse. If DoParse needs local variables, it can be turned into a local PROCEDURE of Parse. On the other hand I doubt that it is sensible to reserve 256 bytes on the stack also if they are not used, or only a part of them are used. What's bad about always using NEW? I think Modula-3's memory management has optimizations for small amounts of memory. From mika at async.caltech.edu Mon Jan 28 13:04:50 2008 From: mika at async.caltech.edu (Mika Nystrom) Date: Mon, 28 Jan 2008 04:04:50 -0800 Subject: [M3devel] nt386gnu threads? In-Reply-To: Your message of "Mon, 28 Jan 2008 11:29:31 GMT." Message-ID: <200801281204.m0SC4oNp025190@camembert.async.caltech.edu> I am almost certain it uses Win32 threads. Attached: ThreadWin32.m3 from PM3-Klagenfurt Mika Jay writes: >--_ddef1601-2afe-4ff4-9567-11d7fc5d354a_ >Content-Type: text/plain; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > >Can anyone confirm my read that PM3's NT386GNU used user/vtalarm threads? .... (* Copyright (C) 1994, Digital Equipment Corporation *) (* All rights reserved. *) (* See the file COPYRIGHT for a full description. *) (* *) (* portions Copyright 1996, Critical Mass, Inc. *) (* *) (* Last modified on Fri Apr 26 10:21:56 PDT 1996 by heydon *) (* modified on Thu Jun 15 09:06:37 PDT 1995 by kalsow *) (* modified on Tue Oct 4 10:34:00 PDT 1994 by isard *) (* modified on Tue May 4 10:20:03 PDT 1993 by mjordan *) (* modified on Wed Apr 21 16:31:21 PDT 1993 by mcjones *) (* modified on Fri Mar 26 15:04:39 PST 1993 by birrell *) UNSAFE MODULE ThreadWin32 EXPORTS Scheduler, Thread, ThreadF, RTThreadInit, RTHooks; IMPORT RTHeapRep, RTLinker, RTMisc, WinBase, WinDef, WinNT, ThreadContext; IMPORT Word; (*** IMPORT RTIO; ***) (*----------------------------------------- Exceptions, types and globals ---*) VAR cm: WinBase.LPCRITICAL_SECTION; (* Global lock for internals of Mutex and Condition *) default_stack: WinDef.DWORD := 16384; nextId: Id := 1; REVEAL Mutex = BRANDED "MUTEX Win32-1.0" OBJECT cs: WinBase.LPCRITICAL_SECTION := NIL; held: BOOLEAN := FALSE; (* LL = self.cs *) (* Because critical sections are thread re-entrant *) END; Condition = BRANDED "Thread.Condition Win32-1.0" OBJECT waiters: T := NIL; (* LL = cm *) (* List of threads waiting on this CV. *) END; T = BRANDED "Thread.T Win32-1.0" OBJECT next, prev: T := NIL; (* LL = threadMu; global doubly-linked, circular list of all threads *) nextIdle: T := NIL; (* LL = threadMu; global list of idle threads *) handle: WinNT.HANDLE := NIL; (* LL = threadMu; thread handle in Windows *) stackbase: ADDRESS := NIL; (* LL = threadMu; base of thread stack for use by GC *) closure: Closure := NIL; (* LL = threadMu *) result: REFANY := NIL; (* LL = threadMu; if not self.completed, used only by self; if self.completed, read-only. *) cond: Condition; (* LL = threadMu; wait here to join, or for rebirth *) waitingOn: Condition := NIL; (* LL = cm; CV that we're blocked on *) nextWaiter: T := NIL; (* LL = cm; queue of threads waiting on the same CV *) waitSema: WinNT.HANDLE := NIL; (* binary semaphore for blocking during "Wait" *) alertable: BOOLEAN := FALSE; (* LL = cm; distinguishes between "Wait" and "AlertWait" *) alerted: BOOLEAN := FALSE; (* LL = cm; the alert flag, of course *) completed: BOOLEAN := FALSE; (* LL = threadMu; indicates that "result" is set *) joined: BOOLEAN := FALSE; (* LL = threadMu; "Join" or "AlertJoin" has already returned *) id: Id; (* LL = threadMu; unique ID of this thread *) slot: INTEGER; (* LL = threadMu; index into global array of active, slotted threads *) END; (*------------------------------------------- Caches of critical sections ---*) CONST CSectCacheSize = 20; (* Everything should work OK if these are 0 *) VAR cSectCache: ARRAY [0..CSectCacheSize-1] OF WinBase.LPCRITICAL_SECTION; cSectCacheContents := 0; PROCEDURE AllocCSect(m: Mutex) = (* LL = 0 *) (* If we can take a critical section from the cache, do so; otherwise create it. In any case, register the containing Mutex with the GC so that we can clean-up on de-allocation. *) VAR mcs: WinBase.LPCRITICAL_SECTION := NIL; lost_race := FALSE; BEGIN WinBase.EnterCriticalSection(cm); IF cSectCacheContents > 0 THEN DEC(cSectCacheContents); m.cs := cSectCache[cSectCacheContents]; ELSE WinBase.LeaveCriticalSection(cm); mcs := NEW(WinBase.LPCRITICAL_SECTION); WinBase.EnterCriticalSection(cm); IF (m.cs = NIL) THEN m.cs := mcs; WinBase.InitializeCriticalSection(m.cs); ELSE (* somebody else beat us thru the preceding NEW *) lost_race := TRUE; END; END; WinBase.LeaveCriticalSection(cm); IF lost_race THEN DISPOSE (mcs); ELSE RTHeapRep.RegisterFinalCleanup(m, FreeCSect); END; END AllocCSect; PROCEDURE FreeCSect(r: REFANY (*Mutex*) ) = (* LL < cm *) (* Must not dereference any traced REF when called from GC *) VAR m: Mutex := r; BEGIN WinBase.EnterCriticalSection(cm); IF m.cs # NIL THEN IF cSectCacheContents < CSectCacheSize THEN cSectCache[cSectCacheContents] := m.cs; INC(cSectCacheContents); ELSE WinBase.DeleteCriticalSection(m.cs); DISPOSE(m.cs); END; m.cs := NIL; END; WinBase.LeaveCriticalSection(cm) END FreeCSect; (*----------------------------------------------------------------- Mutex ---*) (* Note: RTHooks.{Unlock,Lock}Mutex are the routines called directly by the compiler. Acquire and Release are the routines exported through the Thread interface *) PROCEDURE Acquire (m: Mutex) = BEGIN LockMutex (m); END Acquire; PROCEDURE Release (m: Mutex) = BEGIN UnlockMutex (m); END Release; PROCEDURE (*RTHooks.*)LockMutex (m: Mutex) = BEGIN IF (m.cs = NIL) THEN AllocCSect(m); END; WinBase.EnterCriticalSection(m.cs); IF m.held THEN Die("attempt to lock mutex already locked by self") END; m.held := TRUE; END LockMutex; PROCEDURE (*RTHooks.*)UnlockMutex(m: Mutex) = BEGIN IF NOT m.held THEN Die("attempt to release an unlocked mutex") END; m.held := FALSE; WinBase.LeaveCriticalSection(m.cs); END UnlockMutex; (*---------------------------------------- Condition variables and Alerts ---*) PROCEDURE InnerWait(m: Mutex; c: Condition; self: T) = (* LL = cm+m on entry; LL = m on exit *) BEGIN <* ASSERT( (self.waitingOn=NIL) AND (self.nextWaiter=NIL) ) *> self.waitingOn := c; self.nextWaiter := c.waiters; c.waiters := self; WinBase.LeaveCriticalSection(cm); UnlockMutex(m); IF WinBase.WaitForSingleObject(self.waitSema, WinBase.INFINITE) # 0 THEN Choke(); END; LockMutex(m); END InnerWait; PROCEDURE InnerTestAlert(self: T) RAISES {Alerted} = (* LL = cm on entry; LL = cm on normal exit, 0 on exception exit *) (* If self.alerted, clear "alerted", leave cm and raise "Alerted". *) BEGIN IF self.alerted THEN self.alerted := FALSE; WinBase.LeaveCriticalSection(cm); RAISE Alerted END; END InnerTestAlert; PROCEDURE AlertWait (m: Mutex; c: Condition) RAISES {Alerted} = (* LL = m *) VAR self := Self(); BEGIN IF self = NIL THEN Die("AlertWait called from non-Modula-3 thread") END; WinBase.EnterCriticalSection(cm); InnerTestAlert(self); self.alertable := TRUE; InnerWait(m, c, self); WinBase.EnterCriticalSection(cm); InnerTestAlert(self); WinBase.LeaveCriticalSection(cm); END AlertWait; PROCEDURE Wait (m: Mutex; c: Condition) = (* LL = m *) VAR self := Self(); BEGIN IF self = NIL THEN Die("Wait called from non-Modula-3 thread") END; WinBase.EnterCriticalSection(cm); InnerWait(m, c, self); END Wait; PROCEDURE DequeueHead(c: Condition) = (* LL = cm *) VAR t: T; prevCount: WinDef.LONG; BEGIN t := c.waiters; c.waiters := t.nextWaiter; t.nextWaiter := NIL; t.waitingOn := NIL; t.alertable := FALSE; IF WinBase.ReleaseSemaphore(t.waitSema, 1, ADR(prevCount)) = 0 THEN Choke(); END; END DequeueHead; PROCEDURE Signal (c: Condition) = BEGIN WinBase.EnterCriticalSection(cm); IF c.waiters # NIL THEN DequeueHead(c) END; WinBase.LeaveCriticalSection(cm); END Signal; PROCEDURE Broadcast (c: Condition) = BEGIN WinBase.EnterCriticalSection(cm); WHILE c.waiters # NIL DO DequeueHead(c) END; WinBase.LeaveCriticalSection(cm); END Broadcast; PROCEDURE Alert(t: T) = VAR prevCount: WinDef.LONG; prev, next: T; BEGIN IF t = NIL THEN Die("Alert called from non-Modula-3 thread") END; WinBase.EnterCriticalSection(cm); t.alerted := TRUE; IF t.alertable THEN (* Dequeue from any CV and unblock from the semaphore *) IF t.waitingOn # NIL THEN next := t.waitingOn.waiters; prev := NIL; WHILE next # t DO <* ASSERT(next#NIL) *> prev := next; next := next.nextWaiter; END; IF prev = NIL THEN t.waitingOn.waiters := t.nextWaiter ELSE prev.nextWaiter := t.nextWaiter; END; t.nextWaiter := NIL; t.waitingOn := NIL; END; t.alertable := FALSE; IF WinBase.ReleaseSemaphore(t.waitSema, 1, ADR(prevCount)) = 0 THEN Choke(); END; END; WinBase.LeaveCriticalSection(cm); END Alert; PROCEDURE TestAlert(): BOOLEAN = VAR self := Self(); result: BOOLEAN; BEGIN IF self = NIL THEN (* Not created by Fork; not alertable *) RETURN FALSE ELSE WinBase.EnterCriticalSection(cm); result := self.alerted; IF result THEN self.alerted := FALSE END; WinBase.LeaveCriticalSection(cm); RETURN result END; END TestAlert; (*------------------------------------------------------------------ Self ---*) VAR threadIndex: WinDef.DWORD; (* read-only; TLS (Thread Local Storage) index *) VAR (* LL = threadMu *) n_slotted := 0; next_slot := 1; slots : REF ARRAY OF T; (* NOTE: we don't use slots[0]. *) PROCEDURE Self (): T = (* If not the initial thread and not created by Fork, returns NIL *) VAR t: T; x := LOOPHOLE(WinBase.TlsGetValue(threadIndex), INTEGER); BEGIN IF (x < 1) THEN RETURN NIL; END; t := slots[x]; IF (t.slot # x) THEN Die ("thread with bad slot!"); END; RETURN t; END Self; PROCEDURE SetSelf (t: T) = (* LL = 0 *) BEGIN IF (slots [t.slot] # t) THEN Die ("unslotted thread!"); END; IF WinBase.TlsSetValue(threadIndex, LOOPHOLE(t.slot, WinDef.LPVOID)) = 0 THEN Choke(); END; END SetSelf; PROCEDURE AssignSlot (t: T): INTEGER = (* LL = threadMu *) BEGIN (* make sure we have room to register this guy *) IF (slots = NIL) THEN slots := NEW (REF ARRAY OF T, 20); END; IF (n_slotted >= LAST (slots^)) THEN ExpandSlots (); END; (* look for an empty slot *) WHILE (slots [next_slot] # NIL) DO INC (next_slot); IF (next_slot >= NUMBER (slots^)) THEN next_slot := 1; END; END; INC (n_slotted); t.slot := next_slot; slots [next_slot] := t; RETURN t.slot; END AssignSlot; PROCEDURE FreeSlot (t: T) = (* LL = threadMu *) BEGIN DEC (n_slotted); WITH z = slots [t.slot] DO IF (z # t) THEN Die ("unslotted thread!"); END; z := NIL; END; t.slot := 0; END FreeSlot; PROCEDURE ExpandSlots () = VAR n := NUMBER (slots^); new := NEW (REF ARRAY OF T, n+n); BEGIN SUBARRAY (new^, 0, n) := slots^; slots := new; END ExpandSlots; (*------------------------------------------------------------ Fork, Join ---*) CONST MaxIdle = 20; VAR (* LL=threadMu *) threadMu: Mutex; allThreads: T := NIL; (* global list of registered threads *) idleThreads: T := NIL; (* global list of idle threads *) nIdle := 0; PROCEDURE CreateT(): T = (* LL < threadMu, because allocated a traced reference may cause the allocator to start a collection which will call SuspendOthers which will try to acquire threadMu. *) BEGIN RETURN NEW(T, waitSema := WinBase.CreateSemaphore(NIL, 0, 1, NIL), cond := NEW(Condition)); END CreateT; (* ThreadBase calls ThreadMain after finding (approximately) where its stack begins. This dance ensures that all of ThreadMain's traced references are within the stack scanned by the collector. *) PROCEDURE ThreadBase(param: WinDef.DWORD): WinDef.DWORD = VAR self: T; x := LOOPHOLE(param, INTEGER); BEGIN LockMutex(threadMu); self := slots[x]; self.stackbase := ADR(self); UnlockMutex(threadMu); ThreadMain(self); RETURN 0; END ThreadBase; PROCEDURE ThreadMain(self: T) = TYPE ObjRef = UNTRACED REF MethodList; MethodList = UNTRACED REF RECORD typecode: INTEGER; method0: ADDRESS END; VAR next_self: T; cl: Closure; res: REFANY; BEGIN LOOP (* The incarnation loop. *) SetSelf (self); LockMutex(threadMu); cl := self.closure; self.id := nextId; INC (nextId); UnlockMutex(threadMu); IF (cl = NIL) THEN Die ("NIL closure passed to Thread.Fork!"); ELSIF (LOOPHOLE (cl, ObjRef)^^.method0 = NIL) THEN Die ("NIL apply method passed to Thread.Fork!"); END; res := cl.apply(); next_self := NIL; IF nIdle < MaxIdle THEN (* apparently the cache isn't full, although we don't hold threadMu so we can't be certain... *) next_self := NEW(T); END; LockMutex(threadMu); self.result := res; self.completed := TRUE; IF next_self # NIL THEN (* transplant the guts of "self" into next_self *) next_self.handle := self.handle; next_self.stackbase := self.stackbase; next_self.waitSema := self.waitSema; next_self.cond := self.cond; (* put "next_self" on the list of all threads *) next_self.next := allThreads; next_self.prev := allThreads.prev; allThreads.prev.next := next_self; allThreads.prev := next_self; (* put "next_self" on the list of idle threads *) next_self.nextIdle := idleThreads; idleThreads := next_self; INC(nIdle); (* finish making "self" an orphan *) IF allThreads = self THEN allThreads := self.next; END; self.next.prev := self.prev; self.prev.next := self.next; self.next := NIL; self.prev := NIL; self.handle := NIL; self.stackbase := NIL; END; UnlockMutex(threadMu); Broadcast(self.cond); (* let everybody know that "self" is done *) IF next_self = NIL THEN EXIT; END; self := next_self; IF WinBase.WaitForSingleObject(self.waitSema, WinBase.INFINITE) # 0 THEN Choke(); END; END; (* remove ourself from the list of all threads *) LockMutex(threadMu); IF allThreads = self THEN allThreads := self.next; END; self.next.prev := self.prev; self.prev.next := self.next; self.next := NIL; self.prev := NIL; IF WinBase.CloseHandle(self.waitSema) = 0 THEN Choke() END; IF WinBase.CloseHandle(self.handle) = 0 THEN Choke() END; self.handle := NIL; self.waitSema := NIL; FreeSlot (self); UnlockMutex(threadMu); END ThreadMain; PROCEDURE Fork(closure: Closure): T = VAR t: T := NIL; id, stack_size: WinDef.DWORD; prevCount: WinDef.LONG; new_born: BOOLEAN; BEGIN (* determine the initial size of the stack for this thread *) stack_size := default_stack; TYPECASE closure OF SizedClosure (scl) => IF scl.stackSize # 0 THEN stack_size := scl.stackSize * BYTESIZE(INTEGER); END; ELSE (*skip*) END; (* try the cache for a thread *) LockMutex(threadMu); IF nIdle > 0 THEN new_born := FALSE; <* ASSERT(idleThreads # NIL) *> DEC(nIdle); t := idleThreads; idleThreads := t.nextIdle; t.nextIdle := NIL; t.slot := AssignSlot (t); ELSE (* empty cache => we need a fresh thread *) new_born := TRUE; UnlockMutex(threadMu); t := CreateT(); LockMutex(threadMu); t.slot := AssignSlot (t); t.handle := WinBase.CreateThread(NIL, stack_size, LOOPHOLE(ThreadBase, WinBase.LPTHREAD_START_ROUTINE), LOOPHOLE(t.slot,WinDef.LPVOID), WinBase.CREATE_SUSPENDED, ADR(id)); t.next := allThreads; t.prev := allThreads.prev; allThreads.prev.next := t; allThreads.prev := t; END; IF (t.handle = NIL) THEN Choke() END; t.closure := closure; UnlockMutex(threadMu); IF new_born THEN IF WinBase.ResumeThread(t.handle) = -1 THEN Choke() END; ELSE IF WinBase.ReleaseSemaphore(t.waitSema, 1, ADR(prevCount)) = 0 THEN Choke(); END; END; RETURN t END Fork; PROCEDURE Join(t: T): REFANY = VAR res: REFANY; BEGIN LockMutex(threadMu); IF t.joined THEN Die("attempt to join with thread twice"); END; WHILE NOT t.completed DO Wait(threadMu, t.cond) END; res := t.result; t.result := NIL; t.joined := TRUE; UnlockMutex(threadMu); RETURN res; END Join; PROCEDURE AlertJoin(t: T): REFANY RAISES {Alerted} = VAR res: REFANY; BEGIN LockMutex(threadMu); TRY IF t.joined THEN Die("attempt to join with thread twice"); END; WHILE NOT t.completed DO AlertWait(threadMu, t.cond) END; res := t.result; t.result := NIL; t.joined := TRUE; FINALLY UnlockMutex(threadMu); END; RETURN res; END AlertJoin; (*------------------------------------------------ timer-based preemption ---*) PROCEDURE SetSwitchingInterval (<*UNUSED*> usec: CARDINAL) = BEGIN END SetSwitchingInterval; (*---------------------------------------------------- Scheduling support ---*) PROCEDURE Pause(n: LONGREAL) = VAR amount, thisTime: LONGREAL; CONST Limit = FLOAT(LAST(CARDINAL), LONGREAL) / 1000.0D0 - 1.0D0; BEGIN amount := n; WHILE amount > 0.0D0 DO thisTime := MIN (Limit, amount); amount := amount - thisTime; WinBase.Sleep(ROUND(thisTime*1000.0D0)); END; END Pause; PROCEDURE AlertPause(n: LONGREAL) RAISES {Alerted} = VAR amount, thisTime: LONGREAL; CONST Limit = FLOAT(LAST(CARDINAL), LONGREAL) / 1000.0D0 - 1.0D0; VAR self: T; BEGIN self := Self(); amount := n; WHILE amount > 0.0D0 DO thisTime := MIN (Limit, amount); amount := amount - thisTime; WinBase.EnterCriticalSection(cm); InnerTestAlert(self); self.alertable := TRUE; <* ASSERT(self.waitingOn = NIL) *> WinBase.LeaveCriticalSection(cm); EVAL WinBase.WaitForSingleObject(self.waitSema, ROUND(thisTime*1.0D3)); WinBase.EnterCriticalSection(cm); self.alertable := FALSE; IF self.alerted THEN (* Sadly, the alert might have happened after we timed out on the semaphore and before we entered "cm". In that case, we need to decrement the semaphore's count *) EVAL WinBase.WaitForSingleObject(self.waitSema, 0); InnerTestAlert(self); END; WinBase.LeaveCriticalSection(cm); END; END AlertPause; PROCEDURE Yield() = BEGIN WinBase.Sleep(0); END Yield; (*--------------------------------------------------- Stack size controls ---*) PROCEDURE GetDefaultStackSize(): CARDINAL= BEGIN RETURN default_stack DIV BYTESIZE (INTEGER); END GetDefaultStackSize; PROCEDURE MinDefaultStackSize(new_min: CARDINAL)= BEGIN default_stack := MAX (default_stack, new_min * BYTESIZE (INTEGER)); END MinDefaultStackSize; PROCEDURE IncDefaultStackSize(inc: CARDINAL)= BEGIN INC (default_stack, inc * BYTESIZE (INTEGER)); END IncDefaultStackSize; (*-------------------------------------------- Exception handling support ---*) VAR handlersIndex: INTEGER; PROCEDURE GetCurrentHandlers(): ADDRESS= BEGIN RETURN WinBase.TlsGetValue(handlersIndex); END GetCurrentHandlers; PROCEDURE SetCurrentHandlers(h: ADDRESS)= BEGIN EVAL WinBase.TlsSetValue(handlersIndex, h); END SetCurrentHandlers; PROCEDURE PushEFrame (frame: ADDRESS) = TYPE Frame = UNTRACED REF RECORD next: ADDRESS END; VAR f := LOOPHOLE (frame, Frame); BEGIN f.next := WinBase.TlsGetValue(handlersIndex); EVAL WinBase.TlsSetValue(handlersIndex, f); END PushEFrame; PROCEDURE PopEFrame (frame: ADDRESS) = BEGIN EVAL WinBase.TlsSetValue(handlersIndex, frame); END PopEFrame; (*--------------------------------------------- Garbage collector support ---*) VAR suspend_mu : Mutex; suspend_cnt : CARDINAL := 0; (* LL = suspend_mu *) PROCEDURE SuspendOthers () = (* LL=0. Always bracketed with ResumeOthers, which will unlock threadMu *) VAR t: T; self := Self (); cnt: CARDINAL; BEGIN LOCK suspend_mu DO cnt := suspend_cnt; INC (suspend_cnt); END; IF (cnt = 0) THEN LockMutex(threadMu); WinBase.EnterCriticalSection(cm); (* We must hold 'cm' to guarantee that no suspended thread holds it. Otherwise, when the collector tries to acquire a mutex or signal a condition, it will deadlock with the suspended thread that holds 'cm'. *) t := self.next; WHILE (t # self) DO IF WinBase.SuspendThread(t.handle) = -1 THEN Choke() END; t := t.next; END; WinBase.LeaveCriticalSection(cm); END; END SuspendOthers; PROCEDURE ResumeOthers () = (* LL=threadMu. Always preceded by SuspendOthers, which locks threadMu *) VAR t: T; self := Self (); cnt: CARDINAL; BEGIN LOCK suspend_mu DO DEC (suspend_cnt); cnt := suspend_cnt; END; IF (cnt = 0) THEN t := self.next; WHILE (t # self) DO IF WinBase.ResumeThread(t.handle) = -1 THEN Choke() END; t := t.next; END; UnlockMutex(threadMu); END; END ResumeOthers; PROCEDURE ProcessStacks (p: PROCEDURE (start, stop: ADDRESS)) = (* LL=threadMu. Only called within {SuspendOthers, ResumeOthers} *) CONST UserRegs = Word.Or(ThreadContext.CONTEXT_CONTROL, ThreadContext.CONTEXT_INTEGER); VAR t := allThreads; context: ThreadContext.CONTEXT; fixed_SP: ADDRESS; BEGIN REPEAT IF (t.stackbase # NIL) THEN context.ContextFlags := UserRegs; IF WinBase.GetThreadContext(t.handle, ADR(context))=0 THEN Choke() END; fixed_SP := LOOPHOLE (context.Esp, ADDRESS); IF (t.stackbase - fixed_SP) > 10000 THEN fixed_SP := VerifySP (fixed_SP, t.stackbase); END; p(fixed_SP, t.stackbase); (* Process the stack *) p(ADR(context.Edi), ADR(context.Eip)); (* Process the registers *) END; t := t.next; UNTIL (t = allThreads); END ProcessStacks; PROCEDURE VerifySP (start, stop: ADDRESS): ADDRESS = (* Apparently, Win95 will lie about a thread's stack pointer! *) (* Verify that the claimed stack pages are really readable... *) CONST PageSize = 4096; CONST N = BYTESIZE (info); VAR info: WinNT.MEMORY_BASIC_INFORMATION; BEGIN (****** RTIO.PutText ("GC: suspicious stack: ["); RTIO.PutAddr (start); RTIO.PutText (".."); RTIO.PutAddr (stop); RTIO.PutText ("]\n"); RTIO.Flush (); ******) info.BaseAddress := LOOPHOLE (stop-1, ADDRESS); LOOP IF (info.BaseAddress <= start) THEN info.BaseAddress := start; EXIT; END; IF WinBase.VirtualQuery (info.BaseAddress, ADR (info), N) # N THEN Choke(); END; (******* RTIO.PutText (" --> "); RTIO.PutAddr (info.BaseAddress); RTIO.PutText (" "); RTIO.PutAddr (info.AllocationBase); RTIO.PutText (" "); RTIO.PutHex (info.AllocationProtect); RTIO.PutText (" "); RTIO.PutHex (info.RegionSize); RTIO.PutText (" "); RTIO.PutHex (info.State); RTIO.PutText (" "); RTIO.PutHex (info.Protect); RTIO.PutText (" "); RTIO.PutHex (info.Type); RTIO.PutText ("\n"); *******) (* is this chunk readable? *) IF (info.Protect # WinNT.PAGE_READWRITE) AND (info.Protect # WinNT.PAGE_READONLY) THEN (* nope, return the base of the last good chunk *) INC (info.BaseAddress, info.RegionSize); EXIT; END; (* yep, try the next chunk *) DEC (info.BaseAddress, PageSize); END; (******** RTIO.PutText (" ==> ["); RTIO.PutAddr (info.BaseAddress); RTIO.PutText (".."); RTIO.PutAddr (stop); RTIO.PutText ("]"); RTIO.PutText ("\n"); RTIO.Flush (); *******) RETURN info.BaseAddress; END VerifySP; (*------------------------------------------------------------ misc. junk ---*) PROCEDURE MyId(): Id RAISES {}= VAR self := Self (); BEGIN RETURN self.id; END MyId; (*---------------------------------------------------------------- errors ---*) PROCEDURE Die(msg: TEXT) = BEGIN RTMisc.FatalError ("ThreadWin32.m3", 721, "Thread client error: ", msg); END Die; PROCEDURE Choke() = BEGIN RTMisc.FatalErrorI ( "ThreadWin32.m3, line 726: Windows OS failure, GetLastError = ", WinBase.GetLastError ()); END Choke; (*-------------------------------------------------------- Initialization ---*) PROCEDURE Init() = VAR self: T; threadhandle, processhandle: WinNT.HANDLE; BEGIN handlersIndex := WinBase.TlsAlloc(); IF handlersIndex < 0 THEN Choke() END; threadIndex := WinBase.TlsAlloc(); IF threadIndex < 0 THEN Choke() END; cm := NEW(WinBase.LPCRITICAL_SECTION); WinBase.InitializeCriticalSection(cm); suspend_mu := NEW(Mutex); suspend_cnt := 0; threadMu := NEW(Mutex); self := CreateT(); LockMutex(threadMu); threadhandle := WinBase.GetCurrentThread(); processhandle := WinBase.GetCurrentProcess(); IF WinBase.DuplicateHandle(processhandle, threadhandle, processhandle, LOOPHOLE(ADR(self.handle), WinNT.PHANDLE), 0, 0, WinNT.DUPLICATE_SAME_ACCESS) = 0 THEN Choke(); END; self.slot := AssignSlot (self); self.id := nextId; INC (nextId); self.next := self; self.prev := self; allThreads := self; self.stackbase := RTLinker.info.bottom_of_stack; IF self.stackbase = NIL THEN Choke(); END; UnlockMutex(threadMu); SetSelf (self); END Init; BEGIN END ThreadWin32. From jayk123 at hotmail.com Mon Jan 28 13:25:20 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 28 Jan 2008 12:25:20 +0000 Subject: [M3devel] nt386gnu threads? Message-ID: ok, I partially take that back. It looks like pthreads are the path of least resistance.. but still probably not great perf since cygwin pthread mutexes are kernel objects.. (Win32 critical sections only involve the kernel if there is contention, Win32 mutexes are kernel objects.) - Jay From: jayk123 at hotmail.comTo: m3devel at elegosoft.comSubject: nt386gnu threads?Date: Mon, 28 Jan 2008 11:29:31 +0000 Can anyone confirm my read that PM3's NT386GNU used user/vtalarm threads?PM3 appears to have no PThread support ant its NT386GNU appears to have OS_TYPE=POSIX.Heck, even its NT386 has OS_TYPE=POSIX, but its NT386 is probably dead/broken. 1) I'm too lazy to tediously rewrite Cygwin's pthread.h et. al. into Modula-3.2) The thread library you pick is not an independent decision. The Modula-3 File I/O libraries interact with the threading library at least a little bit. The path of less resistance seems to be user/vtalarm threads for now, untilsuch time as Cygwin Upthread.i3 is written.(That is, neither pthreads nor win32 satisfied my laziness; I'm going to try user/vtalarm threads, see how it goes; I'm sure they aren't very good, but...) - Jay 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 neels at elego.de Mon Jan 28 13:25:40 2008 From: neels at elego.de (Neels Janosch Hofmeyr) Date: Mon, 28 Jan 2008 13:25:40 +0100 Subject: [M3devel] new unknown qualification errors Message-ID: <479DC9C4.30505@elego.de> Hi devel, I am trying to compile the suplib with the new 5.5.1 snapshot cm3. It worked fine with 5.4.0, but now I get errors I cannot figure out how to correct: ===> suplib --- building in LINUXLIBC6 --- new source -> compiling StatBufOffT64.m3 "../src/StatBufOffT64.m3", line 40: unknown qualification '.' (asLong) "../src/StatBufOffT64.m3", line 45: unknown qualification '.' (assignOffT) 2 errors encountered new source -> compiling Ugzip.m3 "../src/Ugzip.m3", line 63: unknown qualification '.' (DisableSwitching) "../src/Ugzip.m3", line 67: unknown qualification '.' (EnableSwitching) "../src/Ugzip.m3", line 74: unknown qualification '.' (DisableSwitching) "../src/Ugzip.m3", line 78: unknown qualification '.' (EnableSwitching) 4 errors encountered new source -> compiling CVTree.m3 "../src/CVTree.m3", line 315: unknown qualification '.' (DisableSwitching) "../src/CVTree.m3", line 319: unknown qualification '.' (EnableSwitching) "../src/CVTree.m3", line 325: unknown qualification '.' (DisableSwitching) "../src/CVTree.m3", line 329: unknown qualification '.' (EnableSwitching) "../src/CVTree.m3", line 335: unknown qualification '.' (DisableSwitching) "../src/CVTree.m3", line 339: unknown qualification '.' (EnableSwitching) 6 errors encountered compilation failed => not building library "libsuplib.a" Fatal Error: package build failed I need help with all of these. However, I tried investigating the first one: Utypes.asLong() By coincidence, I saw that in FSPosix.m3, a line saying status.size := Utypes.asLong(statBuf.st_size); was changed to status.size := ORD(statBuf.st_size); Reading the log for the linux/Utypes.i3 gets me confused. It says how to make a off_t from a long, but doesn't say anything about the reverse direction. Is ORD(x) always the way to go? Here is the log extract: revision 1.4 date: 2007-11-29 03:53:15 +0100; author: hosking; state: Exp; lines: +0 -3; commitid: 3xU0vDzVxflBSpHs; Remove residual implementations of Utypes.asLong and Utypes.assignOffT. ---------------------------- revision 1.3 date: 2004-01-30 18:45:34 +0100; author: wagner; state: Exp; lines: +1 -0; add a procedure to assign values to off_t variables, as they may now be structured types, depending on the platform: PROCEDURE expandAssign(VAR dest: off_t; src: long) Well, where would API changes like these be documented, if I ever need to look them up on my own? Thanks, -- Neels Janosch Hofmeyr Software Developer neels at elego.de Public Key: http://binarchy.net/neels/neels.hofmeyr.public.key.asc elego Software Solutions GmbH http://www.elegosoft.com Gustav-Meyer-Allee 25, Geb?ude 12 HRB 77719 13355 Berlin, Germany Amtsgericht Charlottenburg Tel.: +49 30 23 45 86 96 Sitz der Gesellschaft: Berlin Fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Olaf Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From jayk123 at hotmail.com Mon Jan 28 13:37:12 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 28 Jan 2008 12:37:12 +0000 Subject: [M3devel] heap vs. stack? (sort of) In-Reply-To: References: Message-ID: I totally want common code, there's just no point in moving it into a separate function. For now I used a separate function, and I made it nested. I also tried WITH that got its value from "PickBuffer", also a useless function but at least small, but functions can't return open arrays. The problem with heap allocation is that it is slow. This code is optimizing it away in the first place for "small" strings, that's not my doing. Of course you have to pick some heuristic "small" and hope not to blow too much wasted stack. 256 bytes of stack is not small sometimes. It appears that nested functions have to occur up in the variable section but that is very dificult to glean from the documentation or the error messages. Blech. - Jay > Date: Mon, 28 Jan 2008 12:39:10 +0100> From: lemming at henning-thielemann.de> Subject: Re: [M3devel] heap vs. stack? (sort of)> To: jayk123 at hotmail.com> CC: m3devel at elegosoft.com> > > On Mon, 28 Jan 2008, Jay wrote:> > > Is it possible to have this pattern in Modula-3:> >> > PROCEDURE Parse (nm: TEXT; host: BOOLEAN): T = VAR len := Text.Length (nm); buf: ARRAY [0..255] OF CHAR; BEGIN IF (len <= NUMBER (buf)) THEN RETURN DoParse (nm, SUBARRAY (buf, 0, len), host); ELSE RETURN DoParse (nm, NEW (REF ARRAY OF CHAR, len)^, host); END; END Parse;> >> > PROCEDURE DoParse (nm_txt: TEXT; VAR nm: ARRAY OF CHAR; host: BOOLEAN): T => > I think it is a good idea to encapsulate the common code in DoParse. If> DoParse needs local variables, it can be turned into a local PROCEDURE of> Parse. On the other hand I doubt that it is sensible to reserve 256 bytes> on the stack also if they are not used, or only a part of them are used.> What's bad about always using NEW? I think Modula-3's memory management> has optimizations for small amounts of memory. _________________________________________________________________ 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 Jan 28 13:38:38 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 28 Jan 2008 12:38:38 +0000 Subject: [M3devel] nt386gnu threads? In-Reply-To: <200801281204.m0SC4oNp025190@camembert.async.caltech.edu> References: Your message of "Mon, 28 Jan 2008 11:29:31 GMT." <200801281204.m0SC4oNp025190@camembert.async.caltech.edu> Message-ID: Um, so the file exists..does it get compiled? Did you look at the m3makefiles? I skimmed the m3makefiles. I have not tried building PM3 myself. - Jay > To: jayk123 at hotmail.com> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] nt386gnu threads? > Date: Mon, 28 Jan 2008 04:04:50 -0800> From: mika at async.caltech.edu> > I am almost certain it uses Win32 threads. Attached: ThreadWin32.m3> from PM3-Klagenfurt> > Mika> > Jay writes:> >--_ddef1601-2afe-4ff4-9567-11d7fc5d354a_> >Content-Type: text/plain; charset="iso-8859-1"> >Content-Transfer-Encoding: quoted-printable> >> >Can anyone confirm my read that PM3's NT386GNU used user/vtalarm threads?> ....> > > (* Copyright (C) 1994, Digital Equipment Corporation *)> (* All rights reserved. *)> (* See the file COPYRIGHT for a full description. *)> (* *)> (* portions Copyright 1996, Critical Mass, Inc. *)> (* *)> (* Last modified on Fri Apr 26 10:21:56 PDT 1996 by heydon *)> (* modified on Thu Jun 15 09:06:37 PDT 1995 by kalsow *)> (* modified on Tue Oct 4 10:34:00 PDT 1994 by isard *)> (* modified on Tue May 4 10:20:03 PDT 1993 by mjordan *)> (* modified on Wed Apr 21 16:31:21 PDT 1993 by mcjones *)> (* modified on Fri Mar 26 15:04:39 PST 1993 by birrell *)> > UNSAFE MODULE ThreadWin32> EXPORTS Scheduler, Thread, ThreadF, RTThreadInit, RTHooks;> > IMPORT RTHeapRep, RTLinker, RTMisc, WinBase, WinDef, WinNT, ThreadContext;> IMPORT Word;> (*** IMPORT RTIO; ***)> > (*----------------------------------------- Exceptions, types and globals ---*)> > VAR> cm: WinBase.LPCRITICAL_SECTION;> (* Global lock for internals of Mutex and Condition *)> > default_stack: WinDef.DWORD := 16384;> > nextId: Id := 1;> > REVEAL> Mutex = BRANDED "MUTEX Win32-1.0" OBJECT> cs: WinBase.LPCRITICAL_SECTION := NIL;> held: BOOLEAN := FALSE;> (* LL = self.cs *)> (* Because critical sections are thread re-entrant *)> END;> > Condition = BRANDED "Thread.Condition Win32-1.0" OBJECT> waiters: T := NIL;> (* LL = cm *)> (* List of threads waiting on this CV. *)> END;> > T = BRANDED "Thread.T Win32-1.0" OBJECT> next, prev: T := NIL;> (* LL = threadMu; global doubly-linked, circular list of all threads *)> nextIdle: T := NIL;> (* LL = threadMu; global list of idle threads *)> handle: WinNT.HANDLE := NIL;> (* LL = threadMu; thread handle in Windows *)> stackbase: ADDRESS := NIL;> (* LL = threadMu; base of thread stack for use by GC *)> closure: Closure := NIL;> (* LL = threadMu *)> result: REFANY := NIL;> (* LL = threadMu; if not self.completed, used only by self;> if self.completed, read-only. *)> cond: Condition;> (* LL = threadMu; wait here to join, or for rebirth *)> waitingOn: Condition := NIL;> (* LL = cm; CV that we're blocked on *)> nextWaiter: T := NIL;> (* LL = cm; queue of threads waiting on the same CV *)> waitSema: WinNT.HANDLE := NIL;> (* binary semaphore for blocking during "Wait" *)> alertable: BOOLEAN := FALSE;> (* LL = cm; distinguishes between "Wait" and "AlertWait" *)> alerted: BOOLEAN := FALSE;> (* LL = cm; the alert flag, of course *)> completed: BOOLEAN := FALSE;> (* LL = threadMu; indicates that "result" is set *)> joined: BOOLEAN := FALSE;> (* LL = threadMu; "Join" or "AlertJoin" has already returned *)> id: Id;> (* LL = threadMu; unique ID of this thread *)> slot: INTEGER;> (* LL = threadMu; index into global array of active, slotted threads *)> END;> > (*------------------------------------------- Caches of critical sections ---*)> > CONST> CSectCacheSize = 20;> (* Everything should work OK if these are 0 *)> > VAR> cSectCache: ARRAY [0..CSectCacheSize-1] OF WinBase.LPCRITICAL_SECTION;> cSectCacheContents := 0;> > PROCEDURE AllocCSect(m: Mutex) => (* LL = 0 *)> (* If we can take a critical section from the cache, > do so; otherwise create it. In any case, register the containing> Mutex with the GC so that we can clean-up on de-allocation. *)> VAR mcs: WinBase.LPCRITICAL_SECTION := NIL; lost_race := FALSE;> BEGIN> WinBase.EnterCriticalSection(cm);> IF cSectCacheContents > 0 THEN> DEC(cSectCacheContents);> m.cs := cSectCache[cSectCacheContents];> ELSE> WinBase.LeaveCriticalSection(cm);> mcs := NEW(WinBase.LPCRITICAL_SECTION);> WinBase.EnterCriticalSection(cm);> IF (m.cs = NIL) THEN> m.cs := mcs;> WinBase.InitializeCriticalSection(m.cs);> ELSE> (* somebody else beat us thru the preceding NEW *)> lost_race := TRUE;> END;> END;> WinBase.LeaveCriticalSection(cm);> > IF lost_race> THEN DISPOSE (mcs);> ELSE RTHeapRep.RegisterFinalCleanup(m, FreeCSect);> END;> END AllocCSect;> > PROCEDURE FreeCSect(r: REFANY (*Mutex*) ) => (* LL < cm *)> (* Must not dereference any traced REF when called from GC *)> VAR m: Mutex := r;> BEGIN> WinBase.EnterCriticalSection(cm);> IF m.cs # NIL THEN> IF cSectCacheContents < CSectCacheSize THEN> cSectCache[cSectCacheContents] := m.cs;> INC(cSectCacheContents);> ELSE> WinBase.DeleteCriticalSection(m.cs);> DISPOSE(m.cs);> END;> m.cs := NIL;> END;> WinBase.LeaveCriticalSection(cm)> END FreeCSect;> > (*----------------------------------------------------------------- Mutex ---*)> (* Note: RTHooks.{Unlock,Lock}Mutex are the routines called directly by> the compiler. Acquire and Release are the routines exported through> the Thread interface *)> > PROCEDURE Acquire (m: Mutex) => BEGIN> LockMutex (m);> END Acquire;> > PROCEDURE Release (m: Mutex) => BEGIN> UnlockMutex (m);> END Release;> > PROCEDURE (*RTHooks.*)LockMutex (m: Mutex) => BEGIN> IF (m.cs = NIL) THEN AllocCSect(m); END;> WinBase.EnterCriticalSection(m.cs);> IF m.held THEN Die("attempt to lock mutex already locked by self") END;> m.held := TRUE;> END LockMutex;> > PROCEDURE (*RTHooks.*)UnlockMutex(m: Mutex) => BEGIN> IF NOT m.held THEN Die("attempt to release an unlocked mutex") END;> m.held := FALSE;> WinBase.LeaveCriticalSection(m.cs);> END UnlockMutex;> > (*---------------------------------------- Condition variables and Alerts ---*)> > PROCEDURE InnerWait(m: Mutex; c: Condition; self: T) => (* LL = cm+m on entry; LL = m on exit *)> BEGIN> <* ASSERT( (self.waitingOn=NIL) AND (self.nextWaiter=NIL) ) *>> self.waitingOn := c;> self.nextWaiter := c.waiters;> c.waiters := self;> WinBase.LeaveCriticalSection(cm);> UnlockMutex(m);> IF WinBase.WaitForSingleObject(self.waitSema, WinBase.INFINITE) # 0 THEN> Choke();> END;> LockMutex(m);> END InnerWait;> > PROCEDURE InnerTestAlert(self: T) RAISES {Alerted} => (* LL = cm on entry; LL = cm on normal exit, 0 on exception exit *)> (* If self.alerted, clear "alerted", leave cm and raise> "Alerted". *)> BEGIN> IF self.alerted THEN> self.alerted := FALSE;> WinBase.LeaveCriticalSection(cm);> RAISE Alerted> END;> END InnerTestAlert;> > PROCEDURE AlertWait (m: Mutex; c: Condition) RAISES {Alerted} => (* LL = m *)> VAR self := Self();> BEGIN> IF self = NIL THEN Die("AlertWait called from non-Modula-3 thread") END;> WinBase.EnterCriticalSection(cm);> InnerTestAlert(self);> self.alertable := TRUE;> InnerWait(m, c, self);> WinBase.EnterCriticalSection(cm);> InnerTestAlert(self);> WinBase.LeaveCriticalSection(cm);> END AlertWait;> > PROCEDURE Wait (m: Mutex; c: Condition) => (* LL = m *)> VAR self := Self();> BEGIN> IF self = NIL THEN Die("Wait called from non-Modula-3 thread") END;> WinBase.EnterCriticalSection(cm);> InnerWait(m, c, self);> END Wait;> > PROCEDURE DequeueHead(c: Condition) => (* LL = cm *)> VAR t: T; prevCount: WinDef.LONG;> BEGIN> t := c.waiters; c.waiters := t.nextWaiter;> t.nextWaiter := NIL;> t.waitingOn := NIL;> t.alertable := FALSE;> IF WinBase.ReleaseSemaphore(t.waitSema, 1, ADR(prevCount)) = 0 THEN> Choke();> END;> END DequeueHead;> > PROCEDURE Signal (c: Condition) => BEGIN> WinBase.EnterCriticalSection(cm);> IF c.waiters # NIL THEN DequeueHead(c) END;> WinBase.LeaveCriticalSection(cm);> END Signal;> > PROCEDURE Broadcast (c: Condition) => BEGIN> WinBase.EnterCriticalSection(cm);> WHILE c.waiters # NIL DO DequeueHead(c) END;> WinBase.LeaveCriticalSection(cm);> END Broadcast;> > PROCEDURE Alert(t: T) => VAR prevCount: WinDef.LONG; prev, next: T;> BEGIN> IF t = NIL THEN Die("Alert called from non-Modula-3 thread") END;> WinBase.EnterCriticalSection(cm);> t.alerted := TRUE;> IF t.alertable THEN> (* Dequeue from any CV and unblock from the semaphore *)> IF t.waitingOn # NIL THEN> next := t.waitingOn.waiters; prev := NIL;> WHILE next # t DO> <* ASSERT(next#NIL) *>> prev := next; next := next.nextWaiter;> END;> IF prev = NIL THEN> t.waitingOn.waiters := t.nextWaiter> ELSE> prev.nextWaiter := t.nextWaiter;> END;> t.nextWaiter := NIL;> t.waitingOn := NIL;> END;> t.alertable := FALSE;> IF WinBase.ReleaseSemaphore(t.waitSema, 1, ADR(prevCount)) = 0 THEN> Choke();> END;> END;> WinBase.LeaveCriticalSection(cm);> END Alert;> > PROCEDURE TestAlert(): BOOLEAN => VAR self := Self(); result: BOOLEAN;> BEGIN> IF self = NIL THEN> (* Not created by Fork; not alertable *)> RETURN FALSE> ELSE> WinBase.EnterCriticalSection(cm);> result := self.alerted; IF result THEN self.alerted := FALSE END;> WinBase.LeaveCriticalSection(cm);> RETURN result> END;> END TestAlert;> > (*------------------------------------------------------------------ Self ---*)> > VAR> threadIndex: WinDef.DWORD;> (* read-only; TLS (Thread Local Storage) index *)> > VAR (* LL = threadMu *)> n_slotted := 0;> next_slot := 1;> slots : REF ARRAY OF T; (* NOTE: we don't use slots[0]. *)> > PROCEDURE Self (): T => (* If not the initial thread and not created by Fork, returns NIL *)> VAR t: T; x := LOOPHOLE(WinBase.TlsGetValue(threadIndex), INTEGER);> BEGIN> IF (x < 1) THEN RETURN NIL; END;> t := slots[x];> IF (t.slot # x) THEN Die ("thread with bad slot!"); END;> RETURN t;> END Self;> > PROCEDURE SetSelf (t: T) => (* LL = 0 *)> BEGIN> IF (slots [t.slot] # t) THEN Die ("unslotted thread!"); END;> IF WinBase.TlsSetValue(threadIndex, LOOPHOLE(t.slot, WinDef.LPVOID)) = 0> THEN Choke();> END;> END SetSelf;> > PROCEDURE AssignSlot (t: T): INTEGER => (* LL = threadMu *)> BEGIN> (* make sure we have room to register this guy *)> IF (slots = NIL) THEN slots := NEW (REF ARRAY OF T, 20); END;> IF (n_slotted >= LAST (slots^)) THEN ExpandSlots (); END;> > (* look for an empty slot *)> WHILE (slots [next_slot] # NIL) DO> INC (next_slot);> IF (next_slot >= NUMBER (slots^)) THEN next_slot := 1; END;> END;> > INC (n_slotted);> t.slot := next_slot;> slots [next_slot] := t;> RETURN t.slot;> END AssignSlot;> > PROCEDURE FreeSlot (t: T) => (* LL = threadMu *)> BEGIN> DEC (n_slotted);> WITH z = slots [t.slot] DO> IF (z # t) THEN Die ("unslotted thread!"); END;> z := NIL;> END;> t.slot := 0;> END FreeSlot;> > PROCEDURE ExpandSlots () => VAR n := NUMBER (slots^); new := NEW (REF ARRAY OF T, n+n);> BEGIN> SUBARRAY (new^, 0, n) := slots^;> slots := new;> END ExpandSlots;> > (*------------------------------------------------------------ Fork, Join ---*)> > CONST> MaxIdle = 20;> > VAR (* LL=threadMu *)> threadMu: Mutex;> allThreads: T := NIL; (* global list of registered threads *)> idleThreads: T := NIL; (* global list of idle threads *)> nIdle := 0;> > PROCEDURE CreateT(): T => (* LL < threadMu, because allocated a traced reference may cause> the allocator to start a collection which will call SuspendOthers> which will try to acquire threadMu. *)> BEGIN> RETURN NEW(T, waitSema := WinBase.CreateSemaphore(NIL, 0, 1, NIL),> cond := NEW(Condition));> END CreateT;> > (* ThreadBase calls ThreadMain after finding (approximately) where> its stack begins. This dance ensures that all of ThreadMain's> traced references are within the stack scanned by the collector. *)> > PROCEDURE ThreadBase(param: WinDef.DWORD): WinDef.DWORD => VAR self: T; x := LOOPHOLE(param, INTEGER);> BEGIN> LockMutex(threadMu);> self := slots[x];> self.stackbase := ADR(self);> UnlockMutex(threadMu);> ThreadMain(self);> RETURN 0;> END ThreadBase;> > PROCEDURE ThreadMain(self: T) => TYPE> ObjRef = UNTRACED REF MethodList;> MethodList = UNTRACED REF RECORD typecode: INTEGER; method0: ADDRESS END;> VAR next_self: T; cl: Closure; res: REFANY;> BEGIN> LOOP (* The incarnation loop. *)> SetSelf (self);> > LockMutex(threadMu);> cl := self.closure;> self.id := nextId; INC (nextId);> UnlockMutex(threadMu);> > IF (cl = NIL) THEN> Die ("NIL closure passed to Thread.Fork!");> ELSIF (LOOPHOLE (cl, ObjRef)^^.method0 = NIL) THEN> Die ("NIL apply method passed to Thread.Fork!");> END;> > res := cl.apply();> > next_self := NIL;> IF nIdle < MaxIdle THEN> (* apparently the cache isn't full, although we don't hold threadMu> so we can't be certain... *)> next_self := NEW(T);> END;> > LockMutex(threadMu);> self.result := res;> self.completed := TRUE;> > IF next_self # NIL THEN> (* transplant the guts of "self" into next_self *)> next_self.handle := self.handle;> next_self.stackbase := self.stackbase;> next_self.waitSema := self.waitSema;> next_self.cond := self.cond;> > (* put "next_self" on the list of all threads *)> next_self.next := allThreads;> next_self.prev := allThreads.prev;> allThreads.prev.next := next_self;> allThreads.prev := next_self;> > (* put "next_self" on the list of idle threads *)> next_self.nextIdle := idleThreads;> idleThreads := next_self;> INC(nIdle);> > (* finish making "self" an orphan *)> IF allThreads = self THEN allThreads := self.next; END;> self.next.prev := self.prev;> self.prev.next := self.next;> self.next := NIL;> self.prev := NIL;> self.handle := NIL;> self.stackbase := NIL;> END;> UnlockMutex(threadMu);> > Broadcast(self.cond); (* let everybody know that "self" is done *)> > IF next_self = NIL THEN EXIT; END;> self := next_self;> IF WinBase.WaitForSingleObject(self.waitSema, WinBase.INFINITE) # 0 THEN> Choke();> END;> END;> > (* remove ourself from the list of all threads *)> LockMutex(threadMu);> IF allThreads = self THEN allThreads := self.next; END;> self.next.prev := self.prev;> self.prev.next := self.next;> self.next := NIL;> self.prev := NIL;> IF WinBase.CloseHandle(self.waitSema) = 0 THEN Choke() END;> IF WinBase.CloseHandle(self.handle) = 0 THEN Choke() END;> self.handle := NIL;> self.waitSema := NIL;> FreeSlot (self);> UnlockMutex(threadMu);> END ThreadMain;> > PROCEDURE Fork(closure: Closure): T => VAR> t: T := NIL;> id, stack_size: WinDef.DWORD;> prevCount: WinDef.LONG;> new_born: BOOLEAN;> BEGIN> (* determine the initial size of the stack for this thread *)> stack_size := default_stack;> TYPECASE closure OF SizedClosure (scl) =>> IF scl.stackSize # 0 THEN > stack_size := scl.stackSize * BYTESIZE(INTEGER);> END;> ELSE (*skip*)> END;> > (* try the cache for a thread *)> LockMutex(threadMu);> IF nIdle > 0 THEN> new_born := FALSE;> <* ASSERT(idleThreads # NIL) *>> DEC(nIdle);> t := idleThreads;> idleThreads := t.nextIdle;> t.nextIdle := NIL;> t.slot := AssignSlot (t);> ELSE (* empty cache => we need a fresh thread *)> new_born := TRUE;> UnlockMutex(threadMu);> t := CreateT();> LockMutex(threadMu);> t.slot := AssignSlot (t);> t.handle := WinBase.CreateThread(NIL, stack_size,> LOOPHOLE(ThreadBase, WinBase.LPTHREAD_START_ROUTINE),> LOOPHOLE(t.slot,WinDef.LPVOID), WinBase.CREATE_SUSPENDED, ADR(id));> t.next := allThreads;> t.prev := allThreads.prev;> allThreads.prev.next := t;> allThreads.prev := t;> END;> IF (t.handle = NIL) THEN Choke() END;> t.closure := closure;> UnlockMutex(threadMu);> > IF new_born THEN> IF WinBase.ResumeThread(t.handle) = -1 THEN Choke() END;> ELSE> IF WinBase.ReleaseSemaphore(t.waitSema, 1, ADR(prevCount)) = 0 THEN> Choke();> END;> END;> > RETURN t> END Fork;> > PROCEDURE Join(t: T): REFANY => VAR res: REFANY;> BEGIN> LockMutex(threadMu);> IF t.joined THEN Die("attempt to join with thread twice"); END;> WHILE NOT t.completed DO Wait(threadMu, t.cond) END;> res := t.result;> t.result := NIL;> t.joined := TRUE;> UnlockMutex(threadMu);> RETURN res;> END Join;> > PROCEDURE AlertJoin(t: T): REFANY RAISES {Alerted} => VAR res: REFANY;> BEGIN> LockMutex(threadMu);> TRY> IF t.joined THEN Die("attempt to join with thread twice"); END;> WHILE NOT t.completed DO AlertWait(threadMu, t.cond) END;> res := t.result;> t.result := NIL;> t.joined := TRUE;> FINALLY> UnlockMutex(threadMu);> END;> RETURN res;> END AlertJoin;> > (*------------------------------------------------ timer-based preemption ---*)> > PROCEDURE SetSwitchingInterval (<*UNUSED*> usec: CARDINAL) => BEGIN> END SetSwitchingInterval;> > (*---------------------------------------------------- Scheduling support ---*)> > PROCEDURE Pause(n: LONGREAL) => VAR amount, thisTime: LONGREAL;> CONST Limit = FLOAT(LAST(CARDINAL), LONGREAL) / 1000.0D0 - 1.0D0;> BEGIN> amount := n;> WHILE amount > 0.0D0 DO> thisTime := MIN (Limit, amount);> amount := amount - thisTime;> WinBase.Sleep(ROUND(thisTime*1000.0D0));> END;> END Pause;> > PROCEDURE AlertPause(n: LONGREAL) RAISES {Alerted} => VAR amount, thisTime: LONGREAL;> CONST Limit = FLOAT(LAST(CARDINAL), LONGREAL) / 1000.0D0 - 1.0D0;> VAR self: T;> BEGIN> self := Self();> amount := n;> WHILE amount > 0.0D0 DO> thisTime := MIN (Limit, amount);> amount := amount - thisTime;> WinBase.EnterCriticalSection(cm);> InnerTestAlert(self);> self.alertable := TRUE;> <* ASSERT(self.waitingOn = NIL) *>> WinBase.LeaveCriticalSection(cm);> EVAL WinBase.WaitForSingleObject(self.waitSema, ROUND(thisTime*1.0D3));> WinBase.EnterCriticalSection(cm);> self.alertable := FALSE;> IF self.alerted THEN> (* Sadly, the alert might have happened after we timed out on the> semaphore and before we entered "cm". In that case, we need to> decrement the semaphore's count *)> EVAL WinBase.WaitForSingleObject(self.waitSema, 0);> InnerTestAlert(self);> END;> WinBase.LeaveCriticalSection(cm);> END;> END AlertPause;> > PROCEDURE Yield() => BEGIN> WinBase.Sleep(0);> END Yield;> > (*--------------------------------------------------- Stack size controls ---*)> > PROCEDURE GetDefaultStackSize(): CARDINAL=> BEGIN> RETURN default_stack DIV BYTESIZE (INTEGER);> END GetDefaultStackSize;> > PROCEDURE MinDefaultStackSize(new_min: CARDINAL)=> BEGIN> default_stack := MAX (default_stack, new_min * BYTESIZE (INTEGER));> END MinDefaultStackSize;> > PROCEDURE IncDefaultStackSize(inc: CARDINAL)=> BEGIN> INC (default_stack, inc * BYTESIZE (INTEGER));> END IncDefaultStackSize;> > (*-------------------------------------------- Exception handling support ---*)> > VAR handlersIndex: INTEGER;> > PROCEDURE GetCurrentHandlers(): ADDRESS=> BEGIN> RETURN WinBase.TlsGetValue(handlersIndex);> END GetCurrentHandlers;> > PROCEDURE SetCurrentHandlers(h: ADDRESS)=> BEGIN> EVAL WinBase.TlsSetValue(handlersIndex, h);> END SetCurrentHandlers;> > PROCEDURE PushEFrame (frame: ADDRESS) => TYPE Frame = UNTRACED REF RECORD next: ADDRESS END;> VAR f := LOOPHOLE (frame, Frame);> BEGIN> f.next := WinBase.TlsGetValue(handlersIndex);> EVAL WinBase.TlsSetValue(handlersIndex, f);> END PushEFrame;> > PROCEDURE PopEFrame (frame: ADDRESS) => BEGIN> EVAL WinBase.TlsSetValue(handlersIndex, frame);> END PopEFrame;> > (*--------------------------------------------- Garbage collector support ---*)> > VAR> suspend_mu : Mutex;> suspend_cnt : CARDINAL := 0; (* LL = suspend_mu *)> > PROCEDURE SuspendOthers () => (* LL=0. Always bracketed with ResumeOthers, which will unlock threadMu *)> VAR t: T; self := Self (); cnt: CARDINAL;> BEGIN> LOCK suspend_mu DO> cnt := suspend_cnt;> INC (suspend_cnt);> END;> > IF (cnt = 0) THEN> LockMutex(threadMu);> > WinBase.EnterCriticalSection(cm);> (* We must hold 'cm' to guarantee that no suspended thread holds it.> Otherwise, when the collector tries to acquire a mutex or signal> a condition, it will deadlock with the suspended thread that> holds 'cm'. *)> > t := self.next;> WHILE (t # self) DO> IF WinBase.SuspendThread(t.handle) = -1 THEN Choke() END;> t := t.next;> END;> WinBase.LeaveCriticalSection(cm);> END;> END SuspendOthers;> > PROCEDURE ResumeOthers () => (* LL=threadMu. Always preceded by SuspendOthers, which locks threadMu *)> VAR t: T; self := Self (); cnt: CARDINAL;> BEGIN> LOCK suspend_mu DO> DEC (suspend_cnt);> cnt := suspend_cnt;> END;> > IF (cnt = 0) THEN> t := self.next;> WHILE (t # self) DO> IF WinBase.ResumeThread(t.handle) = -1 THEN Choke() END;> t := t.next;> END;> UnlockMutex(threadMu);> END;> END ResumeOthers;> > PROCEDURE ProcessStacks (p: PROCEDURE (start, stop: ADDRESS)) => (* LL=threadMu. Only called within {SuspendOthers, ResumeOthers} *)> CONST UserRegs = Word.Or(ThreadContext.CONTEXT_CONTROL,> ThreadContext.CONTEXT_INTEGER);> VAR t := allThreads; context: ThreadContext.CONTEXT; fixed_SP: ADDRESS;> BEGIN> REPEAT> IF (t.stackbase # NIL) THEN> context.ContextFlags := UserRegs;> IF WinBase.GetThreadContext(t.handle, ADR(context))=0 THEN Choke() END;> fixed_SP := LOOPHOLE (context.Esp, ADDRESS);> IF (t.stackbase - fixed_SP) > 10000 THEN> fixed_SP := VerifySP (fixed_SP, t.stackbase);> END;> p(fixed_SP, t.stackbase); (* Process the stack *)> p(ADR(context.Edi), ADR(context.Eip)); (* Process the registers *)> END;> t := t.next;> UNTIL (t = allThreads);> END ProcessStacks;> > PROCEDURE VerifySP (start, stop: ADDRESS): ADDRESS => (* Apparently, Win95 will lie about a thread's stack pointer! *)> (* Verify that the claimed stack pages are really readable... *)> CONST PageSize = 4096;> CONST N = BYTESIZE (info);> VAR info: WinNT.MEMORY_BASIC_INFORMATION;> BEGIN> > (******> RTIO.PutText ("GC: suspicious stack: [");> RTIO.PutAddr (start);> RTIO.PutText ("..");> RTIO.PutAddr (stop);> RTIO.PutText ("]\n");> RTIO.Flush ();> ******)> > info.BaseAddress := LOOPHOLE (stop-1, ADDRESS);> LOOP> IF (info.BaseAddress <= start) THEN> info.BaseAddress := start;> EXIT;> END;> > IF WinBase.VirtualQuery (info.BaseAddress, ADR (info), N) # N THEN> Choke();> END;> > (*******> RTIO.PutText (" --> "); RTIO.PutAddr (info.BaseAddress);> RTIO.PutText (" "); RTIO.PutAddr (info.AllocationBase);> RTIO.PutText (" "); RTIO.PutHex (info.AllocationProtect);> RTIO.PutText (" "); RTIO.PutHex (info.RegionSize);> RTIO.PutText (" "); RTIO.PutHex (info.State);> RTIO.PutText (" "); RTIO.PutHex (info.Protect);> RTIO.PutText (" "); RTIO.PutHex (info.Type);> RTIO.PutText ("\n");> *******)> > (* is this chunk readable? *)> IF (info.Protect # WinNT.PAGE_READWRITE)> AND (info.Protect # WinNT.PAGE_READONLY) THEN> (* nope, return the base of the last good chunk *)> INC (info.BaseAddress, info.RegionSize);> EXIT;> END;> > (* yep, try the next chunk *)> DEC (info.BaseAddress, PageSize);> END;> > (********> RTIO.PutText (" ==> [");> RTIO.PutAddr (info.BaseAddress);> RTIO.PutText ("..");> RTIO.PutAddr (stop);> RTIO.PutText ("]");> RTIO.PutText ("\n");> RTIO.Flush ();> *******)> > RETURN info.BaseAddress;> END VerifySP;> > (*------------------------------------------------------------ misc. junk ---*)> > PROCEDURE MyId(): Id RAISES {}=> VAR self := Self ();> BEGIN> RETURN self.id;> END MyId;> > (*---------------------------------------------------------------- errors ---*)> > PROCEDURE Die(msg: TEXT) => BEGIN> RTMisc.FatalError ("ThreadWin32.m3", 721, "Thread client error: ", msg);> END Die;> > PROCEDURE Choke() => BEGIN> RTMisc.FatalErrorI (> "ThreadWin32.m3, line 726: Windows OS failure, GetLastError = ",> WinBase.GetLastError ());> END Choke;> > (*-------------------------------------------------------- Initialization ---*)> > > PROCEDURE Init() => VAR> self: T;> threadhandle, processhandle: WinNT.HANDLE;> BEGIN> handlersIndex := WinBase.TlsAlloc();> IF handlersIndex < 0 THEN Choke() END;> > threadIndex := WinBase.TlsAlloc();> IF threadIndex < 0 THEN Choke() END;> > cm := NEW(WinBase.LPCRITICAL_SECTION);> WinBase.InitializeCriticalSection(cm);> > suspend_mu := NEW(Mutex);> suspend_cnt := 0;> > threadMu := NEW(Mutex);> self := CreateT();> > LockMutex(threadMu);> threadhandle := WinBase.GetCurrentThread();> processhandle := WinBase.GetCurrentProcess();> IF WinBase.DuplicateHandle(processhandle, threadhandle, processhandle,> LOOPHOLE(ADR(self.handle), WinNT.PHANDLE), 0,> 0, WinNT.DUPLICATE_SAME_ACCESS) = 0 THEN> Choke();> END;> self.slot := AssignSlot (self);> self.id := nextId; INC (nextId);> self.next := self;> self.prev := self;> allThreads := self;> self.stackbase := RTLinker.info.bottom_of_stack;> IF self.stackbase = NIL THEN Choke(); END;> UnlockMutex(threadMu);> SetSelf (self);> END Init;> > BEGIN> END ThreadWin32. _________________________________________________________________ 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 Jan 28 13:50:54 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 28 Jan 2008 12:50:54 +0000 Subject: [M3devel] new unknown qualification errors In-Reply-To: <479DC9C4.30505@elego.de> References: <479DC9C4.30505@elego.de> Message-ID: (Btw, I find these error messages poor. It should say asLong is not defined in module X, or type T in module X, and give full paths to the two relevant files..meanwhile, my cm3 is outputing user-unfriendly forward slashes on Windows so I could perhaps blow past uninteresting problems oops :) ) - Jay > Date: Mon, 28 Jan 2008 13:25:40 +0100> From: neels at elego.de> To: m3devel at elego.de> Subject: [M3devel] new unknown qualification errors> > Hi devel,> > I am trying to compile the suplib with the new 5.5.1 snapshot cm3. It > worked fine with 5.4.0, but now I get errors I cannot figure out how to > correct:> > ===> suplib> --- building in LINUXLIBC6 ---> > new source -> compiling StatBufOffT64.m3> "../src/StatBufOffT64.m3", line 40: unknown qualification '.' (asLong)> "../src/StatBufOffT64.m3", line 45: unknown qualification '.' (assignOffT)> 2 errors encountered> new source -> compiling Ugzip.m3> "../src/Ugzip.m3", line 63: unknown qualification '.' (DisableSwitching)> "../src/Ugzip.m3", line 67: unknown qualification '.' (EnableSwitching)> "../src/Ugzip.m3", line 74: unknown qualification '.' (DisableSwitching)> "../src/Ugzip.m3", line 78: unknown qualification '.' (EnableSwitching)> 4 errors encountered> new source -> compiling CVTree.m3> "../src/CVTree.m3", line 315: unknown qualification '.' (DisableSwitching)> "../src/CVTree.m3", line 319: unknown qualification '.' (EnableSwitching)> "../src/CVTree.m3", line 325: unknown qualification '.' (DisableSwitching)> "../src/CVTree.m3", line 329: unknown qualification '.' (EnableSwitching)> "../src/CVTree.m3", line 335: unknown qualification '.' (DisableSwitching)> "../src/CVTree.m3", line 339: unknown qualification '.' (EnableSwitching)> 6 errors encountered> compilation failed => not building library "libsuplib.a"> Fatal Error: package build failed> > > I need help with all of these. However, I tried investigating the first > one: Utypes.asLong()> > By coincidence, I saw that in FSPosix.m3, a line saying> status.size := Utypes.asLong(statBuf.st_size);> was changed to> status.size := ORD(statBuf.st_size);> > Reading the log for the linux/Utypes.i3 gets me confused. It says how to > make a off_t from a long, but doesn't say anything about the reverse > direction. Is ORD(x) always the way to go? Here is the log extract:> > revision 1.4> date: 2007-11-29 03:53:15 +0100; author: hosking; state: Exp; lines: > +0 -3; commitid: 3xU0vDzVxflBSpHs;> Remove residual implementations of Utypes.asLong and Utypes.assignOffT.> ----------------------------> revision 1.3> date: 2004-01-30 18:45:34 +0100; author: wagner; state: Exp; lines: > +1 -0;> add a procedure to assign values to off_t variables, as they may now be> structured types, depending on the platform:> > PROCEDURE expandAssign(VAR dest: off_t; src: long)> > > Well, where would API changes like these be documented, if I ever need > to look them up on my own?> Thanks,> > -- > Neels Janosch Hofmeyr> Software Developer> > neels at elego.de> Public Key: http://binarchy.net/neels/neels.hofmeyr.public.key.asc> > elego Software Solutions GmbH http://www.elegosoft.com> Gustav-Meyer-Allee 25, Geb?ude 12 HRB 77719> 13355 Berlin, Germany Amtsgericht Charlottenburg> Tel.: +49 30 23 45 86 96 Sitz der Gesellschaft: Berlin> Fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Olaf Wagner> > _________________________________________________________________ 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 dabenavidesd at yahoo.es Mon Jan 28 13:51:43 2008 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Mon, 28 Jan 2008 13:51:43 +0100 (CET) Subject: [M3devel] new unknown qualification errors In-Reply-To: <479DC9C4.30505@elego.de> Message-ID: <762336.53722.qm@web27110.mail.ukl.yahoo.com> Hi Neels: If I rememeber this happen since some time ago. Just look this post of mine, you need to change the IMPORT and the lines that compiler complains: https://mail.elegosoft.com/pipermail/m3devel/2008-January/000806.html: importing Scheduler instead of SchedulerPosix Then replace the call for the functions of SchedulerPosix for Scheduler I think that would solve that problem. Thanks, Daniel Benavides Neels Janosch Hofmeyr escribi?: Hi devel, I am trying to compile the suplib with the new 5.5.1 snapshot cm3. It worked fine with 5.4.0, but now I get errors I cannot figure out how to correct: ===> suplib --- building in LINUXLIBC6 --- new source -> compiling StatBufOffT64.m3 "../src/StatBufOffT64.m3", line 40: unknown qualification '.' (asLong) "../src/StatBufOffT64.m3", line 45: unknown qualification '.' (assignOffT) 2 errors encountered new source -> compiling Ugzip.m3 "../src/Ugzip.m3", line 63: unknown qualification '.' (DisableSwitching) "../src/Ugzip.m3", line 67: unknown qualification '.' (EnableSwitching) "../src/Ugzip.m3", line 74: unknown qualification '.' (DisableSwitching) "../src/Ugzip.m3", line 78: unknown qualification '.' (EnableSwitching) 4 errors encountered new source -> compiling CVTree.m3 "../src/CVTree.m3", line 315: unknown qualification '.' (DisableSwitching) "../src/CVTree.m3", line 319: unknown qualification '.' (EnableSwitching) "../src/CVTree.m3", line 325: unknown qualification '.' (DisableSwitching) "../src/CVTree.m3", line 329: unknown qualification '.' (EnableSwitching) "../src/CVTree.m3", line 335: unknown qualification '.' (DisableSwitching) "../src/CVTree.m3", line 339: unknown qualification '.' (EnableSwitching) 6 errors encountered compilation failed => not building library "libsuplib.a" Fatal Error: package build failed I need help with all of these. However, I tried investigating the first one: Utypes.asLong() By coincidence, I saw that in FSPosix.m3, a line saying status.size := Utypes.asLong(statBuf.st_size); was changed to status.size := ORD(statBuf.st_size); Reading the log for the linux/Utypes.i3 gets me confused. It says how to make a off_t from a long, but doesn't say anything about the reverse direction. Is ORD(x) always the way to go? Here is the log extract: revision 1.4 date: 2007-11-29 03:53:15 +0100; author: hosking; state: Exp; lines: +0 -3; commitid: 3xU0vDzVxflBSpHs; Remove residual implementations of Utypes.asLong and Utypes.assignOffT. ---------------------------- revision 1.3 date: 2004-01-30 18:45:34 +0100; author: wagner; state: Exp; lines: +1 -0; add a procedure to assign values to off_t variables, as they may now be structured types, depending on the platform: PROCEDURE expandAssign(VAR dest: off_t; src: long) Well, where would API changes like these be documented, if I ever need to look them up on my own? Thanks, -- Neels Janosch Hofmeyr Software Developer neels at elego.de Public Key: http://binarchy.net/neels/neels.hofmeyr.public.key.asc elego Software Solutions GmbH http://www.elegosoft.com Gustav-Meyer-Allee 25, Geb?ude 12 HRB 77719 13355 Berlin, Germany Amtsgericht Charlottenburg Tel.: +49 30 23 45 86 96 Sitz der Gesellschaft: Berlin Fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Olaf Wagner --------------------------------- ?Con Mascota por primera vez? - S? un mejor Amigo Entra en Yahoo! Respuestas. -------------- next part -------------- An HTML attachment was scrubbed... URL: From neels at elego.de Mon Jan 28 14:30:29 2008 From: neels at elego.de (Neels Janosch Hofmeyr) Date: Mon, 28 Jan 2008 14:30:29 +0100 Subject: [M3devel] new unknown qualification errors In-Reply-To: <762336.53722.qm@web27110.mail.ukl.yahoo.com> References: <762336.53722.qm@web27110.mail.ukl.yahoo.com> Message-ID: <479DD8F5.1090001@elego.de> Thanks Daniel, that seems to work. However, if SchedulerPosix does not support these calls (DisableSwitching and EnableSwitching), do we not end up with concurreny problems? (This assuming that the Scheduler internally calls SchedulerPosix on POSIX platforms, which I am just wildly guessing...) Thanks again, Neels Daniel Alejandro Benavides D. wrote: > Hi Neels: > If I rememeber this happen since some time ago. Just look this post of > mine, you need to change the IMPORT and the lines that compiler complains: > https://mail.elegosoft.com/pipermail/m3devel/2008-January/000806.html: > importing Scheduler instead of SchedulerPosix > Then replace the call for the functions of SchedulerPosix for Scheduler > I think that would solve that problem. > > Thanks, > > Daniel Benavides > > > > > > */Neels Janosch Hofmeyr /* escribi?: > > Hi devel, > > I am trying to compile the suplib with the new 5.5.1 snapshot cm3. It > worked fine with 5.4.0, but now I get errors I cannot figure out > how to > correct: > > ===> suplib > --- building in LINUXLIBC6 --- > > new source -> compiling StatBufOffT64.m3 > "../src/StatBufOffT64.m3", line 40: unknown qualification '.' (asLong) > "../src/StatBufOffT64.m3", line 45: unknown qualification '.' > (assignOffT) > 2 errors encountered > new source -> compiling Ugzip.m3 > "../src/Ugzip.m3", line 63: unknown qualification '.' > (DisableSwitching) > "../src/Ugzip.m3", line 67: unknown qualification '.' > (EnableSwitching) > "../src/Ugzip.m3", line 74: unknown qualification '.' > (DisableSwitching) > "../src/Ugzip.m3", line 78: unknown qualification '.' > (EnableSwitching) > 4 errors encountered > new source -> compiling CVTree.m3 > "../src/CVTree.m3", line 315: unknown qualification '.' > (DisableSwitching) > "../src/CVTree.m3", line 319: unknown qualification '.' > (EnableSwitching) > "../src/CVTree.m3", line 325: unknown qualification '.' > (DisableSwitching) > "../src/CVTree.m3", line 329: unknown qualification '.' > (EnableSwitching) > "../src/CVTree.m3", line 335: unknown qualification '.' > (DisableSwitching) > "../src/CVTree.m3", line 339: unknown qualification '.' > (EnableSwitching) > 6 errors encountered > compilation failed => not building library "libsuplib.a" > Fatal Error: package build failed > > > I need help with all of these. However, I tried investigating the > first > one: Utypes.asLong() > > By coincidence, I saw that in FSPosix.m3, a line saying > status.size := Utypes.asLong(statBuf.st_size); > was changed to > status.size := ORD(statBuf.st_size); > > Reading the log for the linux/Utypes.i3 gets me confused. It says > how to > make a off_t from a long, but doesn't say anything about the reverse > direction. Is ORD(x) always the way to go? Here is the log extract: > > revision 1.4 > date: 2007-11-29 03:53:15 +0100; author: hosking; state: Exp; lines: > +0 -3; commitid: 3xU0vDzVxflBSpHs; > Remove residual implementations of Utypes.asLong and > Utypes.assignOffT. > ---------------------------- > revision 1.3 > date: 2004-01-30 18:45:34 +0100; author: wagner; state: Exp; lines: > +1 -0; > add a procedure to assign values to off_t variables, as they may > now be > structured types, depending on the platform: > > PROCEDURE expandAssign(VAR dest: off_t; src: long) > > > Well, where would API changes like these be documented, if I ever > need > to look them up on my own? > Thanks, > > -- > Neels Janosch Hofmeyr > Software Developer > > neels at elego.de > Public Key: http://binarchy.net/neels/neels.hofmeyr.public.key.asc > > elego Software Solutions GmbH http://www.elegosoft.com > Gustav-Meyer-Allee 25, Geb?ude 12 HRB 77719 > 13355 Berlin, Germany Amtsgericht Charlottenburg > Tel.: +49 30 23 45 86 96 Sitz der Gesellschaft: Berlin > Fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Olaf Wagner > > > > > ?Con Mascota por primera vez? - S? un mejor Amigo > Entra en Yahoo! Respuestas > . -- Neels Janosch Hofmeyr Software Developer neels at elego.de Public Key: http://binarchy.net/neels/neels.hofmeyr.public.key.asc elego Software Solutions GmbH http://www.elegosoft.com Gustav-Meyer-Allee 25, Geb?ude 12 HRB 77719 13355 Berlin, Germany Amtsgericht Charlottenburg Tel.: +49 30 23 45 86 96 Sitz der Gesellschaft: Berlin Fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Olaf Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From lemming at henning-thielemann.de Mon Jan 28 14:38:37 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Mon, 28 Jan 2008 14:38:37 +0100 (MET) Subject: [M3devel] heap vs. stack? (sort of) In-Reply-To: References: Message-ID: On Mon, 28 Jan 2008, Jay wrote: > I totally want common code, there's just no point in moving it into a separate function. Are you concerned about efficiency or about readability? In the first case maybe <* INLINE *> helps? > I also tried WITH that got its value from "PickBuffer", also a useless > function but at least small, but functions can't return open arrays. Functions can return pointers to open arrays - isn't this enough? From neels at elego.de Mon Jan 28 14:40:12 2008 From: neels at elego.de (Neels Janosch Hofmeyr) Date: Mon, 28 Jan 2008 14:40:12 +0100 Subject: [M3devel] Utypes.asLong / Utypes.assignOffT Message-ID: <479DDB3C.4020300@elego.de> Hi, after some problems have been resolved, I still cannot figure out these errors: ===> suplib --- building in LINUXLIBC6 --- new source -> compiling StatBufOffT64.m3 "../src/StatBufOffT64.m3", line 40: unknown qualification '.' (asLong) "../src/StatBufOffT64.m3", line 45: unknown qualification '.' (assignOffT) They are trying to access the procedures Utypes.asLong Utypes.assignOffT Apparently, Utypes.asLong(..) can simply be replaced by ORD(..). Is this correct?? Concerning assignOffT, the commit log speaks of a function called PROCEDURE expandAssign(VAR dest: off_t; src: long) , but this function does not exist anywhere in the cm3 source tree (grep -r expandAssign yielded no results). How do I fix this line in suplib/src/StatBufOffT64.m3 (ll.43-46)? PROCEDURE SetStatSize(VAR st: struct_stat; size: CARDINAL) = BEGIN Utypes.assignOffT(st.st_size, size); END SetStatSize; "../src/StatBufOffT64.m3", line 45: unknown qualification '.' (assignOffT) Thanks -- Neels Janosch Hofmeyr Software Developer neels at elego.de Public Key: http://binarchy.net/neels/neels.hofmeyr.public.key.asc elego Software Solutions GmbH http://www.elegosoft.com Gustav-Meyer-Allee 25, Geb?ude 12 HRB 77719 13355 Berlin, Germany Amtsgericht Charlottenburg Tel.: +49 30 23 45 86 96 Sitz der Gesellschaft: Berlin Fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Olaf Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From jayk123 at hotmail.com Mon Jan 28 15:00:46 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 28 Jan 2008 14:00:46 +0000 Subject: [M3devel] heap vs. stack? (sort of) In-Reply-To: References: Message-ID: Both. In thinking about how to write the code, there is no point in splitting the code into two functions. They are each small and the one is only called once. The language should in general not force me to write functions merely to work over the type system. <*inline*> is not implemented by the integrated backend. I assume every function call I write will not be inlined. > Functions can return pointers to open arrays - isn't this enough? Yes that might help. I had tried like PROCEDURE PickBuffer(VAR buf: ARRAY OF CHAR; len: INTEGER): ARRAY OF CHAR = BEGIN IF len <= NUMBER(buf) RETURN buf; END; RETURN NEW ARRAY OF CHAR (len); END PickBuffer; PROCEDURE Parse(...) VAR stack: ARRAY [0..255] OF CHAR; BEGIN ... WITH buf = PickBuffer(stack, len) DO use buf END; END Parse but I couldn't come up with a PickBuffer that the compiler liked. PickBuffer is still a bit iffy. More generally in C++ I would implement that as a template class where one of the parameters is how much to preallocate. In C I would implement it as a struct and some functions and the initialization function would take the preallocated buffer and size. Surely Modula-3 can do either/both of those patterns well and it doesn't have to be reimplemented over and over. The Modula-3 code I see around the system is way more low level and repetitive than seems appropriate, more so than C code that I write. Another example is that it definitely appears that if I try to compile code with a path like \a\b\c\d\e\f\g\h\a\b\c\d\e\f\g...\foo.m3 that has more than around 32 path separators, I'll just get some random failures since the code just "gives up". M3Path has an array of 32 to store the positions of path separators. That whole chunk of code, to remove \.\ I'll probably rewrite to be both more efficient and have no such capacity limits. For \.\ it is trivial. For \..\ it takes a bit of cleverness -- rather than rely on any indefinite amount of storage, what you can do is first reverse the string, then whenever you se .., bump up a counter, whenever you see not .., bump it down, only copy from source to dest when the counter is zero. Roughly. Of course...maybe better here...count the slashes, if there are more than ~30, do the heap alloc, as in the previous pattern. Though it'd be nice, since it is possible, to handle arbitrarily long paths without the heap alloc. In a compacting garbage collection system, heap alloc can be roughly the cost of incrementing an integer. I do not assume Modula-3 has that, though maybe, and I do not assume it has particularly fast heap allocation. I have seen heap allocation just be very slow in general and I avoid it whenever possible/easy/correct. There are competing desires here of course. 1 Be fast. 2 Don't have fixed sized limits. (and esp. don't crash when you go past them! as I complained about recently..) 3 Don't use "too much" stack, however much that is. The easiest way to do #2 and #3 is always heap alloc exactly how much you need, but that kills #1. - Jay > Date: Mon, 28 Jan 2008 14:38:37 +0100> From: lemming at henning-thielemann.de> Subject: RE: [M3devel] heap vs. stack? (sort of)> To: jayk123 at hotmail.com> CC: m3devel at elegosoft.com> > > On Mon, 28 Jan 2008, Jay wrote:> > > I totally want common code, there's just no point in moving it into a separate function.> > Are you concerned about efficiency or about readability? In the first case> maybe <* INLINE *> helps?> > > I also tried WITH that got its value from "PickBuffer", also a useless> > function but at least small, but functions can't return open arrays.> > Functions can return pointers to open arrays - isn't this enough? _________________________________________________________________ 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 hendrik at topoi.pooq.com Mon Jan 28 15:46:29 2008 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Mon, 28 Jan 2008 09:46:29 -0500 Subject: [M3devel] heap vs. stack? (sort of) In-Reply-To: References: Message-ID: <20080128144629.GB1732@topoi.pooq.com> On Mon, Jan 28, 2008 at 02:00:46PM +0000, Jay wrote: > Both. > In thinking about how to write the code, there is no point in splitting the code into two functions. > They are each small and the one is only called once. > The language should in general not force me to write functions merely to work over the type system. > <*inline*> is not implemented by the integrated backend. I assume every function call I write will not be inlined. > > > Functions can return pointers to open arrays - isn't this enough? > > Yes that might help. > I had tried like > > PROCEDURE PickBuffer(VAR buf: ARRAY OF CHAR; len: INTEGER): ARRAY OF CHAR = > BEGIN > IF len <= NUMBER(buf) RETURN buf; > END; > RETURN NEW ARRAY OF CHAR (len); > END PickBuffer; > > PROCEDURE Parse(...) > VAR > stack: ARRAY [0..255] OF CHAR; > BEGIN > ... > WITH buf = PickBuffer(stack, len) DO use buf > END; > END Parse > > but I couldn't come up with a PickBuffer that the compiler liked. > > PickBuffer is still a bit iffy. > > More generally in C++ I would implement that as a template class where one of the parameters is how much to preallocate. In C I would implement it as a struct and some functions and the initialization function would take the preallocated buffer and size. > > Surely Modula-3 can do either/both of those patterns well and it doesn't have to be reimplemented over and over. > > The Modula-3 code I see around the system is way more low level and repetitive than seems appropriate, more so than C code that I write. > > Another example is that it definitely appears that if I try to compile code with a path like > \a\b\c\d\e\f\g\h\a\b\c\d\e\f\g...\foo.m3 > > that has more than around 32 path separators, I'll just get some random failures since the code just "gives up". > M3Path has an array of 32 to store the positions of path separators. > That whole chunk of code, to remove \.\ I'll probably rewrite to be both more efficient and have no such capacity limits. > For \.\ it is trivial. > For \..\ it takes a bit of cleverness -- rather than rely on any indefinite amount of storage, what you can do is first reverse the string, then whenever you se .., bump up a counter, whenever you see not .., bump it down, only copy from source to dest when the counter is zero. Roughly. If you are talking about paths for naming files, you might want to consider that (on Unix systems at least) '..' does not back out of a symbolic link, but may go somewhere else entirely. Whether you want this behaviour is, of course, up to you. -- hendrik From jayk123 at hotmail.com Mon Jan 28 16:40:59 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 28 Jan 2008 15:40:59 +0000 Subject: [M3devel] heap vs. stack? (sort of) In-Reply-To: <20080128144629.GB1732@topoi.pooq.com> References: <20080128144629.GB1732@topoi.pooq.com> Message-ID: > consider that (on Unix systems at least) '..' does not back out of a > symbolic link, but may go somewhere else entirely. Whether you want > this behaviour is, of course, up to you. cm3 does this. Not up to me or you probably. See m3-sys/cm3/src/M3Path.m3 PROCEDURE FixPath (VAR p: ARRAY OF CHAR; host: BOOLEAN): TEXT = (* remove redundant "/arc/../" and "/./" segments *) VAR os := os_map [host]; len, x, s0, s1, s2: INTEGER; info: SepInfo; - Jay > Date: Mon, 28 Jan 2008 09:46:29 -0500> From: hendrik at topoi.pooq.com> To: m3devel at elegosoft.com> Subject: Re: [M3devel] heap vs. stack? (sort of)> > On Mon, Jan 28, 2008 at 02:00:46PM +0000, Jay wrote:> > Both.> > In thinking about how to write the code, there is no point in splitting the code into two functions.> > They are each small and the one is only called once.> > The language should in general not force me to write functions merely to work over the type system.> > <*inline*> is not implemented by the integrated backend. I assume every function call I write will not be inlined.> > > > > Functions can return pointers to open arrays - isn't this enough?> > > > Yes that might help.> > I had tried like> > > > PROCEDURE PickBuffer(VAR buf: ARRAY OF CHAR; len: INTEGER): ARRAY OF CHAR => > BEGIN> > IF len <= NUMBER(buf) RETURN buf;> > END;> > RETURN NEW ARRAY OF CHAR (len);> > END PickBuffer;> > > > PROCEDURE Parse(...)> > VAR> > stack: ARRAY [0..255] OF CHAR;> > BEGIN> > ...> > WITH buf = PickBuffer(stack, len) DO use buf> > END;> > END Parse> > > > but I couldn't come up with a PickBuffer that the compiler liked.> > > > PickBuffer is still a bit iffy.> > > > More generally in C++ I would implement that as a template class where one of the parameters is how much to preallocate. In C I would implement it as a struct and some functions and the initialization function would take the preallocated buffer and size.> > > > Surely Modula-3 can do either/both of those patterns well and it doesn't have to be reimplemented over and over.> > > > The Modula-3 code I see around the system is way more low level and repetitive than seems appropriate, more so than C code that I write.> > > > Another example is that it definitely appears that if I try to compile code with a path like> > \a\b\c\d\e\f\g\h\a\b\c\d\e\f\g...\foo.m3> > > > that has more than around 32 path separators, I'll just get some random failures since the code just "gives up".> > M3Path has an array of 32 to store the positions of path separators.> > That whole chunk of code, to remove \.\ I'll probably rewrite to be both more efficient and have no such capacity limits.> > For \.\ it is trivial.> > For \..\ it takes a bit of cleverness -- rather than rely on any indefinite amount of storage, what you can do is first reverse the string, then whenever you se .., bump up a counter, whenever you see not .., bump it down, only copy from source to dest when the counter is zero. Roughly.> > If you are talking about paths for naming files, you might want to > consider that (on Unix systems at least) '..' does not back out of a > symbolic link, but may go somewhere else entirely. Whether you want > this behaviour is, of course, up to you.> > -- hendrik _________________________________________________________________ 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 Jan 28 17:02:25 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 28 Jan 2008 11:02:25 -0500 Subject: [M3devel] nt386gnu threads? In-Reply-To: References: Message-ID: <591840BD-4494-4A2C-AC0F-CD017338E5ED@cs.purdue.edu> On Jan 28, 2008, at 6:29 AM, Jay wrote: > Can anyone confirm my read that PM3's NT386GNU used user/vtalarm > threads? Indeed. Pthread support has only been available in CM3 since I started on it in in 2006. Thus, unless it was using Win32 threads it had to have been SIGVTALRM based (ie, implemented as in ThreadPosix.m3). > PM3 appears to have no PThread support ant its NT386GNU appears to > have OS_TYPE=POSIX. > Heck, even its NT386 has OS_TYPE=POSIX, but its NT386 is probably > dead/broken. > > 1) I'm too lazy to tediously rewrite Cygwin's pthread.h et. al. > into Modula-3. I am unfamiliar with Cygwin pthread support. Are they layered on win32 threads? It is not terribly hard to write Upthread.i3 and friends. > 2) The thread library you pick is not an independent decision. > The Modula-3 File I/O libraries interact with the threading > library at least a little bit. The POSIX file IO libraries are known to function with both ThreadPThread and ThreadPosix (SIGVTALRM). Thus, you should be able to use them cleanly if the Cygwin-based Modula-3 implementation takes on a purely/mainly POSIX personality (as many of us have argued it should!). > The path of less resistance seems to be user/vtalarm threads for > now, until > such time as Cygwin Upthread.i3 is written. Yes, indeed. > (That is, neither pthreads nor win32 satisfied my laziness; I'm > going to try user/vtalarm threads, see how it goes; I'm sure they > aren't very good, but...) Certainly, you won't get any multicore benefit with SIGVTALRM-based threads. From hosking at cs.purdue.edu Mon Jan 28 17:16:13 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 28 Jan 2008 11:16:13 -0500 Subject: [M3devel] new unknown qualification errors In-Reply-To: <479DD8F5.1090001@elego.de> References: <762336.53722.qm@web27110.mail.ukl.yahoo.com> <479DD8F5.1090001@elego.de> Message-ID: <758D5468-25A7-4853-BD61-F012890358A6@cs.purdue.edu> On Jan 28, 2008, at 8:30 AM, Neels Janosch Hofmeyr wrote: > Thanks Daniel, that seems to work. > > However, if SchedulerPosix does not support these calls > (DisableSwitching and EnableSwitching), do we not end up with > concurreny problems? (This assuming that the Scheduler internally > calls SchedulerPosix on POSIX platforms, which I am just wildly > guessing...) The calls to Schedule.DisableSwitching/EnableSwitching turn into different things for different threading subsystems. The reason is because SIGVTALRM-based thread scheduling (ThreadPosix) can cause thread switches in library code that is not thread-safe. Thus, certain system calls need to be wrapped in DisableSwitching/ EnableSwitching calls which prevent user-level threads switches. With system thread scheduling (ThreadPThread) the library calls are known to be thread-safe (since we link with a pthreads-aware C library) so DisableSwitching/EnableSwitching can be implemented as a no-op. The purpose of this is to allow suplib (and CVSup) to be compiled for all POSIX targets (both pthreads and user-threads). So, short answer to your question is: no, we don't end up with concurrency problems. > > Thanks again, > Neels > > Daniel Alejandro Benavides D. wrote: >> Hi Neels: >> If I rememeber this happen since some time ago. Just look this >> post of mine, you need to change the IMPORT and the lines that >> compiler complains: >> https://mail.elegosoft.com/pipermail/m3devel/2008-January/ >> 000806.html: >> importing Scheduler instead of SchedulerPosix Then replace the >> call for the functions of SchedulerPosix for Scheduler >> I think that would solve that problem. >> >> Thanks, >> >> Daniel Benavides >> >> >> >> >> */Neels Janosch Hofmeyr /* escribi?: >> >> Hi devel, >> >> I am trying to compile the suplib with the new 5.5.1 snapshot >> cm3. It >> worked fine with 5.4.0, but now I get errors I cannot figure out >> how to >> correct: >> >> ===> suplib >> --- building in LINUXLIBC6 --- >> >> new source -> compiling StatBufOffT64.m3 >> "../src/StatBufOffT64.m3", line 40: unknown qualification >> '.' (asLong) >> "../src/StatBufOffT64.m3", line 45: unknown qualification '.' >> (assignOffT) >> 2 errors encountered >> new source -> compiling Ugzip.m3 >> "../src/Ugzip.m3", line 63: unknown qualification '.' >> (DisableSwitching) >> "../src/Ugzip.m3", line 67: unknown qualification '.' >> (EnableSwitching) >> "../src/Ugzip.m3", line 74: unknown qualification '.' >> (DisableSwitching) >> "../src/Ugzip.m3", line 78: unknown qualification '.' >> (EnableSwitching) >> 4 errors encountered >> new source -> compiling CVTree.m3 >> "../src/CVTree.m3", line 315: unknown qualification '.' >> (DisableSwitching) >> "../src/CVTree.m3", line 319: unknown qualification '.' >> (EnableSwitching) >> "../src/CVTree.m3", line 325: unknown qualification '.' >> (DisableSwitching) >> "../src/CVTree.m3", line 329: unknown qualification '.' >> (EnableSwitching) >> "../src/CVTree.m3", line 335: unknown qualification '.' >> (DisableSwitching) >> "../src/CVTree.m3", line 339: unknown qualification '.' >> (EnableSwitching) >> 6 errors encountered >> compilation failed => not building library "libsuplib.a" >> Fatal Error: package build failed >> >> >> I need help with all of these. However, I tried investigating the >> first >> one: Utypes.asLong() >> >> By coincidence, I saw that in FSPosix.m3, a line saying >> status.size := Utypes.asLong(statBuf.st_size); >> was changed to >> status.size := ORD(statBuf.st_size); >> >> Reading the log for the linux/Utypes.i3 gets me confused. It says >> how to >> make a off_t from a long, but doesn't say anything about the >> reverse >> direction. Is ORD(x) always the way to go? Here is the log >> extract: >> >> revision 1.4 >> date: 2007-11-29 03:53:15 +0100; author: hosking; state: Exp; >> lines: >> +0 -3; commitid: 3xU0vDzVxflBSpHs; >> Remove residual implementations of Utypes.asLong and >> Utypes.assignOffT. >> ---------------------------- >> revision 1.3 >> date: 2004-01-30 18:45:34 +0100; author: wagner; state: Exp; >> lines: >> +1 -0; >> add a procedure to assign values to off_t variables, as they may >> now be >> structured types, depending on the platform: >> >> PROCEDURE expandAssign(VAR dest: off_t; src: long) >> >> >> Well, where would API changes like these be documented, if I ever >> need >> to look them up on my own? >> Thanks, >> >> -- Neels Janosch Hofmeyr >> Software Developer >> >> neels at elego.de >> Public Key: http://binarchy.net/neels/ >> neels.hofmeyr.public.key.asc >> >> elego Software Solutions GmbH http://www.elegosoft.com >> Gustav-Meyer-Allee 25, Geb?ude 12 HRB 77719 >> 13355 Berlin, Germany Amtsgericht Charlottenburg >> Tel.: +49 30 23 45 86 96 Sitz der Gesellschaft: Berlin >> Fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Olaf Wagner >> >> >> >> >> ?Con Mascota por primera vez? - S? un mejor Amigo >> Entra en Yahoo! Respuestas > *http://es.answers.yahoo.com/dir/ >> index;_ylc=X3oDMTE4ZWhyZjU0BF9TAzIxMTQ3MTQzMjIEc2VjA0Jhbm5lcgRzbGsDQW >> NxdWlzaXRpb24-?link=over&sid=XXXXXXXX>. > > -- > Neels Janosch Hofmeyr > Software Developer > > neels at elego.de > Public Key: http://binarchy.net/neels/neels.hofmeyr.public.key.asc > > elego Software Solutions GmbH http://www.elegosoft.com > Gustav-Meyer-Allee 25, Geb?ude 12 HRB 77719 > 13355 Berlin, Germany Amtsgericht Charlottenburg > Tel.: +49 30 23 45 86 96 Sitz der Gesellschaft: Berlin > Fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Olaf Wagner > > From jayk123 at hotmail.com Mon Jan 28 17:19:48 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 28 Jan 2008 16:19:48 +0000 Subject: [M3devel] nt386gnu threads? In-Reply-To: <591840BD-4494-4A2C-AC0F-CD017338E5ED@cs.purdue.edu> References: <591840BD-4494-4A2C-AC0F-CD017338E5ED@cs.purdue.edu> Message-ID: I understand how to write pthread.i3 but it is tedious and I am lazy. This idea that the headers have to be rewritten in Modula-3 bugs me. I realize it purchases my "crazy cross" but it's not the only way -- the native headers distributed to other machines could work....but then I realize it buys writing more Modula-3 and less C, and I'm not sure that's valuable. :) For now I've copied/pasted bits and pieces around to get m3core.dll to build. It builds. I believe Cygwin Pthreads are layered on Win32 threads. I'm sure they add cost oh well. Yes NT386GNU will use Cygwin and it'll be slow. NT386MINGNU will use cm3cg and only build slowly. It is painfully noticable how much more slowly NT386GNU m3cc builds than NT386MINGNU m3cc, presumably due to the underlying slower bash/sed/make etc. All just twiddle the slashes around... I did twiddle M3Path to print like c:/cm3 and accept either input. I probably will stil make it accept either input, since from a certain point of view, that is more correct. Oh, I had treating \ and / the same on all platforms -- surely \ never occurs anyway on Unix... :) The Cygwin stuff was either out of date for vtalarm, or I was building the wrong files and thought it was broken. So I went back to pthreads. Besides, vtalarm threads put you in the shady business of creating stacks and such.. - Jay > CC: m3devel at elegosoft.com> From: hosking at cs.purdue.edu> Subject: Re: [M3devel] nt386gnu threads?> Date: Mon, 28 Jan 2008 11:02:25 -0500> To: jayk123 at hotmail.com> > > On Jan 28, 2008, at 6:29 AM, Jay wrote:> > > Can anyone confirm my read that PM3's NT386GNU used user/vtalarm > > threads?> > Indeed. Pthread support has only been available in CM3 since I > started on it in in 2006. Thus, unless it was using Win32 threads it > had to have been SIGVTALRM based (ie, implemented as in ThreadPosix.m3).> > > PM3 appears to have no PThread support ant its NT386GNU appears to > > have OS_TYPE=POSIX.> > Heck, even its NT386 has OS_TYPE=POSIX, but its NT386 is probably > > dead/broken.> >> > 1) I'm too lazy to tediously rewrite Cygwin's pthread.h et. al. > > into Modula-3.> > I am unfamiliar with Cygwin pthread support. Are they layered on > win32 threads? It is not terribly hard to write Upthread.i3 and > friends.> > > 2) The thread library you pick is not an independent decision.> > The Modula-3 File I/O libraries interact with the threading > > library at least a little bit.> > The POSIX file IO libraries are known to function with both > ThreadPThread and ThreadPosix (SIGVTALRM). Thus, you should be able > to use them cleanly if the Cygwin-based Modula-3 implementation takes > on a purely/mainly POSIX personality (as many of us have argued it > should!).> > > The path of less resistance seems to be user/vtalarm threads for > > now, until> > such time as Cygwin Upthread.i3 is written.> > Yes, indeed.> > > (That is, neither pthreads nor win32 satisfied my laziness; I'm > > going to try user/vtalarm threads, see how it goes; I'm sure they > > aren't very good, but...)> > Certainly, you won't get any multicore benefit with SIGVTALRM-based > threads.> _________________________________________________________________ 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 Jan 28 17:26:45 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 28 Jan 2008 16:26:45 +0000 Subject: [M3devel] Open CM3 regression tests In-Reply-To: <20080127185530.e255i76vcwckss4o@mail.elegosoft.com> References: <20080120211832.GA26993@elegosoft.com> <9C00EA97-9B43-43BE-9CDF-EEAC9C1321D5@cs.purdue.edu> <20080127150327.mh686v2hx4w080w4@mail.elegosoft.com> <1DA9FA59-6DFF-430C-90C5-F1D30003607A@cs.purdue.edu> <20080127185530.e255i76vcwckss4o@mail.elegosoft.com> Message-ID: The tests don't even build on Windows and it was going to take more than 5 minutes fix that. They are slightly full of sh. :) (I never tire of this joke. :) ) My current plan is: get NT386GNU working -- I can already build cm3 and it fails an assertion about pthread_mutex_something failing. Hey, maybe I should fix some of the declarations.. :) or go back to my Mac briefly to investigate and/or give Tony a day :) - Jay From: jayk123 at hotmail.comTo: wagner at elegosoft.com; hosking at cs.purdue.eduCC: m3devel at elegosoft.comSubject: RE: [M3devel] Open CM3 regression testsDate: Sun, 27 Jan 2008 20:31:00 +0000 The functions are only used if the set doesn't fit in an integer.I'll try to look at this today. - Jay > Date: Sun, 27 Jan 2008 18:55:30 +0100> From: wagner at elegosoft.com> To: hosking at cs.purdue.edu> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] Open CM3 regression tests> > Quoting Tony Hosking :> > > The set operations are coded in > > cm3/m3-libs/m3core/src/Csupport/Common/hand.c.> >> > I notice Jay has made a number of changes here since September -- I> > wonder if they have broken something.> > I tried different revisions of this file with no difference in the> test results. I then took the latest version and added some printfs,> and they got never displayed. So I checked what gets linked, but the> symbols in question don't occur in the test program:> > % nm hand.o> U __divdi3> U __moddi3> 000001e0 R _highbits> 00000140 R _lowbits> 00000000 T m3_div> 000000ac T m3_divL> 000001d4 T m3_mod> 0000026c T m3_modL> U printf> 00000494 T set_difference> 00000554 T set_eq> 0000061c T set_ge> 000006ac T set_gt> 00000434 T set_intersection> 0000077c T set_le> 0000080c T set_lt> 000003a8 T set_member> 000005b8 T set_ne> 000008d8 T set_range> 000009d8 T set_singleton> 000004f4 T set_sym_difference> 000003d4 T set_union> > % nm /usr/local/cm3/pkg/m3core/FreeBSD4/libm3core.so.5 | grep set_> 000243d0 T set_difference> 00024490 T set_eq> 00024558 T set_ge> 000245fc T set_gt> 00024370 T set_intersection> 000246e0 T set_le> 00024784 T set_lt> 000242e4 T set_member> 000244f4 T set_ne> 00024864 T set_range> 00024998 T set_singleton> 00024430 T set_sym_difference> 00024310 T set_union> > % ldd FreeBSD4/p1/p155/FreeBSD4/pgm> FreeBSD4/p1/p155/FreeBSD4/pgm:> libtest.so.5 => > /d/home/wagner/work/cm3/m3-sys/m3tests/FreeBSD4/libtest.so.5 > (0x28085000)> libm3.so.5 => /usr/local/cm3/pkg/libm3/FreeBSD4/libm3.so.5 > (0x28088000)> libm3core.so.5 => > /usr/local/cm3/pkg/m3core/FreeBSD4/libm3core.so.5 (0x281aa000)> libm.so.4 => /lib/libm.so.4 (0x28a2d000)> libpthread.so.2 => /lib/libpthread.so.2 (0x28a46000)> libc.so.6 => /lib/libc.so.6 (0x28a6a000)> > % nm /usr/local/cm3/pkg/m3core/FreeBSD4/libm3core.so.5 | grep set_> 000243d0 T set_difference> 00024490 T set_eq> 00024558 T set_ge> 000245fc T set_gt> 00024370 T set_intersection> 000246e0 T set_le> 00024784 T set_lt> 000242e4 T set_member> 000244f4 T set_ne> 00024864 T set_range> 00024998 T set_singleton> 00024430 T set_sym_difference> 00024310 T set_union> luthien [~/work/cm3/m3-sys/m3tests] wagner> % ldd FreeBSD4/p1/p155/FreeBSD4/pgm> FreeBSD4/p1/p155/FreeBSD4/pgm:> libtest.so.5 => > /d/home/wagner/work/cm3/m3-sys/m3tests/FreeBSD4/libtest.so.5 > (0x28085000)> libm3.so.5 => /usr/local/cm3/pkg/libm3/FreeBSD4/libm3.so.5 > (0x28088000)> libm3core.so.5 => > /usr/local/cm3/pkg/m3core/FreeBSD4/libm3core.so.5 (0x281aa000)> libm.so.4 => /lib/libm.so.4 (0x28a2d000)> libpthread.so.2 => /lib/libpthread.so.2 (0x28a46000)> libc.so.6 => /lib/libc.so.6 (0x28a6a000)> luthien [~/work/cm3/m3-sys/m3tests] wagner> % nm -C -u FreeBSD4/p1/p155/FreeBSD4/pgm> U Main_I3> U RTHooks_I3> U RTHooks__CheckLoadTracedRef> U RTHooks__Concat> U RTHooks__PopEFrame> U RTHooks__PushEFrame> U RTHooks__TextLitGetChar> U RTHooks__TextLitGetChars> U RTHooks__TextLitGetWideChar> U RTHooks__TextLitGetWideChars> U RTHooks__TextLitInfo> U RTLinker__AddUnit> U RTLinker__InitRuntime> U RTProcess__Exit> U Stdio_I3> U Test_I3> U Test__checkM> U Test__done> U Wr_I3> U Wr__Flush> U Wr__PutText> w _Jv_RegisterClasses> w __deregister_frame_info> w __register_frame_info> U _init_tls> U _setjmp> U atexit> U exit> > Now I'm rather confused 8-/> > Any ideas?> > Olaf> -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194> 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 neels at elego.de Mon Jan 28 17:35:41 2008 From: neels at elego.de (Neels Janosch Hofmeyr) Date: Mon, 28 Jan 2008 17:35:41 +0100 Subject: [M3devel] Utypes.asLong / Utypes.assignOffT In-Reply-To: <479DDB3C.4020300@elego.de> References: <479DDB3C.4020300@elego.de> Message-ID: <479E045D.2000903@elego.de> Apparently, the answer to this is trivial. I found the missing functions in a CVS diff: -PROCEDURE asLong (val: off_t): long = - BEGIN - RETURN val; - END asLong; - -PROCEDURE assignOffT (VAR dest: off_t; src: long) = - BEGIN - dest := src; - END assignOffT; So, just replacing all occurences of these functions with direct assignments compiles without problems. y := Utypes.asLong(x) ==becomes==> y := ORD(x); x := Utypes.assignOffT(y) ==becomes==> x := y; Obviously, CVSup needs to be updated so that it compiles with the most recent CM3! The suplib still uses the obsoleted procedures asLong and assignOffT. Shall I write a mail to Mr. Polstra? Neels Neels Janosch Hofmeyr wrote: > Hi, > > after some problems have been resolved, I still cannot figure out > these errors: > > ===> suplib > --- building in LINUXLIBC6 --- > > new source -> compiling StatBufOffT64.m3 > "../src/StatBufOffT64.m3", line 40: unknown qualification '.' (asLong) > "../src/StatBufOffT64.m3", line 45: unknown qualification '.' > (assignOffT) > > They are trying to access the procedures > Utypes.asLong > Utypes.assignOffT > > Apparently, Utypes.asLong(..) can simply be replaced by ORD(..). Is > this correct?? > > Concerning assignOffT, the commit log speaks of a function called > PROCEDURE expandAssign(VAR dest: off_t; src: long) > , but this function does not exist anywhere in the cm3 source tree > (grep -r expandAssign yielded no results). > > > How do I fix this line in suplib/src/StatBufOffT64.m3 (ll.43-46)? > > PROCEDURE SetStatSize(VAR st: struct_stat; size: CARDINAL) = > BEGIN > Utypes.assignOffT(st.st_size, size); > END SetStatSize; > > "../src/StatBufOffT64.m3", line 45: unknown qualification '.' > (assignOffT) > > > Thanks > -- Neels Janosch Hofmeyr Software Developer neels at elego.de Public Key: http://binarchy.net/neels/neels.hofmeyr.public.key.asc elego Software Solutions GmbH http://www.elegosoft.com Gustav-Meyer-Allee 25, Geb?ude 12 HRB 77719 13355 Berlin, Germany Amtsgericht Charlottenburg Tel.: +49 30 23 45 86 96 Sitz der Gesellschaft: Berlin Fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Olaf Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From hosking at cs.purdue.edu Mon Jan 28 17:38:34 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 28 Jan 2008 11:38:34 -0500 Subject: [M3devel] heap vs. stack? (sort of) In-Reply-To: References: Message-ID: <3FB18C3C-0AE9-482F-AAAB-1196A81F73FB@cs.purdue.edu> <*INLINE*> currently does nothing with CM3. However, the gcc-based backend will inline procedures when optimizations are turned on. On Jan 28, 2008, at 8:38 AM, Henning Thielemann wrote: > > On Mon, 28 Jan 2008, Jay wrote: > >> I totally want common code, there's just no point in moving it >> into a separate function. > > Are you concerned about efficiency or about readability? In the > first case > maybe <* INLINE *> helps? > >> I also tried WITH that got its value from "PickBuffer", also a >> useless >> function but at least small, but functions can't return open arrays. > > Functions can return pointers to open arrays - isn't this enough? From hosking at cs.purdue.edu Mon Jan 28 17:43:35 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 28 Jan 2008 11:43:35 -0500 Subject: [M3devel] heap vs. stack? (sort of) In-Reply-To: References: Message-ID: <5DF1BB14-913D-460B-9F42-BA96B0B3682B@cs.purdue.edu> Modula-3 heap allocation is just bumping a pointer. The M3 GC is a copying (ie, compacting) collector. Fast path allocation doesn't even need synchronization since every thread allocates from its own private heap buffer. On Jan 28, 2008, at 9:00 AM, Jay wrote: > Both. > In thinking about how to write the code, there is no point in > splitting the code into two functions. > They are each small and the one is only called once. > The language should in general not force me to write functions > merely to work over the type system. > <*inline*> is not implemented by the integrated backend. I assume > every function call I write will not be inlined. > > > Functions can return pointers to open arrays - isn't this enough? > > Yes that might help. > I had tried like > > PROCEDURE PickBuffer(VAR buf: ARRAY OF CHAR; len: INTEGER): ARRAY > OF CHAR = > BEGIN > IF len <= NUMBER(buf) > RETURN buf; > END; > RETURN NEW ARRAY OF CHAR (len); > END PickBuffer; > > PROCEDURE Parse(...) > VAR > stack: ARRAY [0..255] OF CHAR; > BEGIN > ... > WITH buf = PickBuffer(stack, len) DO > use buf > END; > END Parse > > but I couldn't come up with a PickBuffer that the compiler liked. > > PickBuffer is still a bit iffy. > > More generally in C++ I would implement that as a template class > where one of the parameters is how much to preallocate. In C I > would implement it as a struct and some functions and the > initialization function would take the preallocated buffer and size. > > Surely Modula-3 can do either/both of those patterns well and it > doesn't have to be reimplemented over and over. > > The Modula-3 code I see around the system is way more low level and > repetitive than seems appropriate, more so than C code that I write. > > Another example is that it definitely appears that if I try to > compile code with a path like > \a\b\c\d\e\f\g\h\a\b\c\d\e\f\g...\foo.m3 > > that has more than around 32 path separators, I'll just get some > random failures since the code just "gives up". > M3Path has an array of 32 to store the positions of path separators. > That whole chunk of code, to remove \.\ I'll probably rewrite to be > both more efficient and have no such capacity limits. > For \.\ it is trivial. > For \..\ it takes a bit of cleverness -- rather than rely on any > indefinite amount of storage, what you can do is first reverse the > string, then whenever you se .., bump up a counter, whenever you > see not .., bump it down, only copy from source to dest when the > counter is zero. Roughly. > > Of course...maybe better here...count the slashes, if there are > more than ~30, do the heap alloc, as in the previous pattern. > Though it'd be nice, since it is possible, to handle arbitrarily > long paths without the heap alloc. > > In a compacting garbage collection system, heap alloc can be > roughly the cost of incrementing an integer. > I do not assume Modula-3 has that, though maybe, and I do not > assume it has particularly fast heap allocation. > I have seen heap allocation just be very slow in general and I > avoid it whenever possible/easy/correct. > > There are competing desires here of course. > 1 Be fast. > 2 Don't have fixed sized limits. (and esp. don't crash when you > go past them! as I complained about recently..) > 3 Don't use "too much" stack, however much that is. > > The easiest way to do #2 and #3 is always heap alloc exactly how > much you need, but that kills #1. > > - Jay > > > > > Date: Mon, 28 Jan 2008 14:38:37 +0100 > > From: lemming at henning-thielemann.de > > Subject: RE: [M3devel] heap vs. stack? (sort of) > > To: jayk123 at hotmail.com > > CC: m3devel at elegosoft.com > > > > > > On Mon, 28 Jan 2008, Jay wrote: > > > > > I totally want common code, there's just no point in moving it > into a separate function. > > > > Are you concerned about efficiency or about readability? In the > first case > > maybe <* INLINE *> helps? > > > > > I also tried WITH that got its value from "PickBuffer", also a > useless > > > function but at least small, but functions can't return open > arrays. > > > > Functions can return pointers to open arrays - isn't this enough? > > > Connect and share in new ways with Windows Live. Get it now! From hosking at cs.purdue.edu Mon Jan 28 17:55:24 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 28 Jan 2008 11:55:24 -0500 Subject: [M3devel] heap vs. stack? (sort of) In-Reply-To: References: Message-ID: <99035865-C3FD-45CB-8508-5D9C6B010D44@cs.purdue.edu> I actually find this idiom for avoiding heap allocation (assuming it really is expensive in the first place) particularly elegant. In any case, what's wrong with defining a generic procedure: PROCEDURE Apply (p: PROCEDURE(nm: ARRAY OF CHAR); nm: TEXT): T = VAR len := Text.Length(nm); buf: ARRAY [0..255] OF CHAR; BEGIN IF len <= NUMBER(buf) THEN RETURN p(SUBARRAY(buf, 0, len)); ELSE RETURN p(NEW(REF ARRAY OF CHAR, len)^); END; END Apply; and then use Apply to apply a nested procedure to the appropriate text at each place you need it? On Jan 28, 2008, at 4:48 AM, Jay wrote: > Is it possible to have this pattern in Modula-3: > > PROCEDURE Parse (nm: TEXT; host: BOOLEAN): T = > VAR len := Text.Length (nm); buf: ARRAY [0..255] OF CHAR; > BEGIN > IF (len <= NUMBER (buf)) > THEN RETURN DoParse (nm, SUBARRAY (buf, 0, len), host); > ELSE RETURN DoParse (nm, NEW (REF ARRAY OF CHAR, len)^, host); > END; > END Parse; > > PROCEDURE DoParse (nm_txt: TEXT; VAR nm: ARRAY OF CHAR; host: > BOOLEAN): T = > > without the extra function? > > There are places in M3Path.m3 that duplicate code otherwise, one > branch acting on a local stack allocated array, the other acting on > a heap allocated array when the stack array is too small, but > otherwise identical code. > > So far I have not figured out how. Local variables cannot be open > array. SUBARRAY returns an ARRAY and not a REF ARRAY... It seems > that parameters can be open arrays but local variables cannot, and > that seems wrong.. parameters and locals so often share > characteristics... > > - 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 Jan 28 17:55:39 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 28 Jan 2008 11:55:39 -0500 Subject: [M3devel] heap vs. stack? (sort of) In-Reply-To: <5DF1BB14-913D-460B-9F42-BA96B0B3682B@cs.purdue.edu> References: <5DF1BB14-913D-460B-9F42-BA96B0B3682B@cs.purdue.edu> Message-ID: I should say CM3 here. On Jan 28, 2008, at 11:43 AM, Tony Hosking wrote: > Modula-3 heap allocation is just bumping a pointer. The M3 GC is a > copying (ie, compacting) collector. Fast path allocation doesn't > even need synchronization since every thread allocates from its own > private heap buffer. > > On Jan 28, 2008, at 9:00 AM, Jay wrote: > >> Both. >> In thinking about how to write the code, there is no point in >> splitting the code into two functions. >> They are each small and the one is only called once. >> The language should in general not force me to write functions >> merely to work over the type system. >> <*inline*> is not implemented by the integrated backend. I assume >> every function call I write will not be inlined. >> >> > Functions can return pointers to open arrays - isn't this enough? >> >> Yes that might help. >> I had tried like >> >> PROCEDURE PickBuffer(VAR buf: ARRAY OF CHAR; len: INTEGER): ARRAY >> OF CHAR = >> BEGIN >> IF len <= NUMBER(buf) >> RETURN buf; >> END; >> RETURN NEW ARRAY OF CHAR (len); >> END PickBuffer; >> >> PROCEDURE Parse(...) >> VAR >> stack: ARRAY [0..255] OF CHAR; >> BEGIN >> ... >> WITH buf = PickBuffer(stack, len) DO >> use buf >> END; >> END Parse >> >> but I couldn't come up with a PickBuffer that the compiler liked. >> >> PickBuffer is still a bit iffy. >> >> More generally in C++ I would implement that as a template class >> where one of the parameters is how much to preallocate. In C I >> would implement it as a struct and some functions and the >> initialization function would take the preallocated buffer and size. >> >> Surely Modula-3 can do either/both of those patterns well and it >> doesn't have to be reimplemented over and over. >> >> The Modula-3 code I see around the system is way more low level >> and repetitive than seems appropriate, more so than C code that I >> write. >> >> Another example is that it definitely appears that if I try to >> compile code with a path like >> \a\b\c\d\e\f\g\h\a\b\c\d\e\f\g...\foo.m3 >> >> that has more than around 32 path separators, I'll just get some >> random failures since the code just "gives up". >> M3Path has an array of 32 to store the positions of path separators. >> That whole chunk of code, to remove \.\ I'll probably rewrite to >> be both more efficient and have no such capacity limits. >> For \.\ it is trivial. >> For \..\ it takes a bit of cleverness -- rather than rely on any >> indefinite amount of storage, what you can do is first reverse the >> string, then whenever you se .., bump up a counter, whenever you >> see not .., bump it down, only copy from source to dest when the >> counter is zero. Roughly. >> >> Of course...maybe better here...count the slashes, if there are >> more than ~30, do the heap alloc, as in the previous pattern. >> Though it'd be nice, since it is possible, to handle arbitrarily >> long paths without the heap alloc. >> >> In a compacting garbage collection system, heap alloc can be >> roughly the cost of incrementing an integer. >> I do not assume Modula-3 has that, though maybe, and I do not >> assume it has particularly fast heap allocation. >> I have seen heap allocation just be very slow in general and I >> avoid it whenever possible/easy/correct. >> >> There are competing desires here of course. >> 1 Be fast. >> 2 Don't have fixed sized limits. (and esp. don't crash when you >> go past them! as I complained about recently..) >> 3 Don't use "too much" stack, however much that is. >> >> The easiest way to do #2 and #3 is always heap alloc exactly how >> much you need, but that kills #1. >> >> - Jay >> >> >> >> > Date: Mon, 28 Jan 2008 14:38:37 +0100 >> > From: lemming at henning-thielemann.de >> > Subject: RE: [M3devel] heap vs. stack? (sort of) >> > To: jayk123 at hotmail.com >> > CC: m3devel at elegosoft.com >> > >> > >> > On Mon, 28 Jan 2008, Jay wrote: >> > >> > > I totally want common code, there's just no point in moving it >> into a separate function. >> > >> > Are you concerned about efficiency or about readability? In the >> first case >> > maybe <* INLINE *> helps? >> > >> > > I also tried WITH that got its value from "PickBuffer", also a >> useless >> > > function but at least small, but functions can't return open >> arrays. >> > >> > Functions can return pointers to open arrays - isn't this enough? >> >> >> Connect and share in new ways with Windows Live. Get it now! From hosking at cs.purdue.edu Mon Jan 28 18:03:10 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 28 Jan 2008 12:03:10 -0500 Subject: [M3devel] nt386gnu threads? In-Reply-To: References: <591840BD-4494-4A2C-AC0F-CD017338E5ED@cs.purdue.edu> Message-ID: <2AEEE262-57C1-4D62-AB21-CA977F6C273E@cs.purdue.edu> On Jan 28, 2008, at 11:19 AM, Jay wrote: > I understand how to write pthread.i3 but it is tedious and I am > lazy. This idea that the headers have to be rewritten in Modula-3 > bugs me. I realize it purchases my "crazy cross" but it's not the > only way -- the native headers distributed to other machines could > work....but then I realize it buys writing more Modula-3 and less > C, and I'm not sure that's valuable. :) > > For now I've copied/pasted bits and pieces around to get m3core.dll > to build. It builds. > I believe Cygwin Pthreads are layered on Win32 threads. > I'm sure they add cost oh well. > Yes NT386GNU will use Cygwin and it'll be slow. > NT386MINGNU will use cm3cg and only build slowly. > > It is painfully noticable how much more slowly NT386GNU m3cc builds > than NT386MINGNU m3cc, presumably due to the underlying slower bash/ > sed/make etc. > > All just twiddle the slashes around... I did twiddle M3Path to > print like c:/cm3 and accept either input. I probably will stil > make it accept either input, since from a certain point of view, > that is more correct. Oh, I had treating \ and / the same on all > platforms -- surely \ never occurs anyway on Unix... :) Not sure: can \ be used as an escape in file names? > The Cygwin stuff was either out of date for vtalarm, or I was > building the wrong files and thought it was broken. So I went back > to pthreads. Besides, vtalarm threads put you in the shady business > of creating stacks and such.. I think NT386GNU always used Win32 threads. > > > - Jay > > > > CC: m3devel at elegosoft.com > > From: hosking at cs.purdue.edu > > Subject: Re: [M3devel] nt386gnu threads? > > Date: Mon, 28 Jan 2008 11:02:25 -0500 > > To: jayk123 at hotmail.com > > > > > > On Jan 28, 2008, at 6:29 AM, Jay wrote: > > > > > Can anyone confirm my read that PM3's NT386GNU used user/vtalarm > > > threads? > > > > Indeed. Pthread support has only been available in CM3 since I > > started on it in in 2006. Thus, unless it was using Win32 threads it > > had to have been SIGVTALRM based (ie, implemented as in > ThreadPosix.m3). > > > > > PM3 appears to have no PThread support ant its NT386GNU appears to > > > have OS_TYPE=POSIX. > > > Heck, even its NT386 has OS_TYPE=POSIX, but its NT386 is probably > > > dead/broken. > > > > > > 1) I'm too lazy to tediously rewrite Cygwin's pthread.h et. al. > > > into Modula-3. > > > > I am unfamiliar with Cygwin pthread support. Are they layered on > > win32 threads? It is not terribly hard to write Upthread.i3 and > > friends. > > > > > 2) The thread library you pick is not an independent decision. > > > The Modula-3 File I/O libraries interact with the threading > > > library at least a little bit. > > > > The POSIX file IO libraries are known to function with both > > ThreadPThread and ThreadPosix (SIGVTALRM). Thus, you should be able > > to use them cleanly if the Cygwin-based Modula-3 implementation > takes > > on a purely/mainly POSIX personality (as many of us have argued it > > should!). > > > > > The path of less resistance seems to be user/vtalarm threads for > > > now, until > > > such time as Cygwin Upthread.i3 is written. > > > > Yes, indeed. > > > > > (That is, neither pthreads nor win32 satisfied my laziness; I'm > > > going to try user/vtalarm threads, see how it goes; I'm sure they > > > aren't very good, but...) > > > > Certainly, you won't get any multicore benefit with SIGVTALRM-based > > threads. > > > > > Helping your favorite cause is as easy as instant messaging. You > IM, we give. Learn more. From hosking at cs.purdue.edu Mon Jan 28 18:04:46 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 28 Jan 2008 12:04:46 -0500 Subject: [M3devel] Utypes.asLong / Utypes.assignOffT In-Reply-To: <479E045D.2000903@elego.de> References: <479DDB3C.4020300@elego.de> <479E045D.2000903@elego.de> Message-ID: <4C6699EA-187B-455D-A7D0-63A69FABF1B7@cs.purdue.edu> You will need to use VAL as I noted to handle the fact that off_t is LONGINT on some targets and INTEGER on others. On Jan 28, 2008, at 11:35 AM, Neels Janosch Hofmeyr wrote: > Apparently, the answer to this is trivial. I found the missing > functions in a CVS diff: > > -PROCEDURE asLong (val: off_t): long = > - BEGIN > - RETURN val; > - END asLong; > - > -PROCEDURE assignOffT (VAR dest: off_t; src: long) = > - BEGIN > - dest := src; > - END assignOffT; > > So, just replacing all occurences of these functions with direct > assignments compiles without problems. > y := Utypes.asLong(x) ==becomes==> y := ORD(x); > x := Utypes.assignOffT(y) ==becomes==> x := y; > > Obviously, CVSup needs to be updated so that it compiles with the > most recent CM3! The suplib still uses the obsoleted procedures > asLong and assignOffT. Shall I write a mail to Mr. Polstra? > > Neels > > Neels Janosch Hofmeyr wrote: >> Hi, >> >> after some problems have been resolved, I still cannot figure out >> these errors: >> >> ===> suplib >> --- building in LINUXLIBC6 --- >> >> new source -> compiling StatBufOffT64.m3 >> "../src/StatBufOffT64.m3", line 40: unknown qualification >> '.' (asLong) >> "../src/StatBufOffT64.m3", line 45: unknown qualification >> '.' (assignOffT) >> >> They are trying to access the procedures >> Utypes.asLong >> Utypes.assignOffT >> >> Apparently, Utypes.asLong(..) can simply be replaced by ORD(..). >> Is this correct?? >> >> Concerning assignOffT, the commit log speaks of a function called >> PROCEDURE expandAssign(VAR dest: off_t; src: long) >> , but this function does not exist anywhere in the cm3 source tree >> (grep -r expandAssign yielded no results). >> >> >> How do I fix this line in suplib/src/StatBufOffT64.m3 (ll.43-46)? >> >> PROCEDURE SetStatSize(VAR st: struct_stat; size: CARDINAL) = >> BEGIN >> Utypes.assignOffT(st.st_size, size); >> END SetStatSize; >> >> "../src/StatBufOffT64.m3", line 45: unknown qualification >> '.' (assignOffT) >> >> >> Thanks >> > > -- > Neels Janosch Hofmeyr > Software Developer > > neels at elego.de > Public Key: http://binarchy.net/neels/neels.hofmeyr.public.key.asc > > elego Software Solutions GmbH http://www.elegosoft.com > Gustav-Meyer-Allee 25, Geb?ude 12 HRB 77719 > 13355 Berlin, Germany Amtsgericht Charlottenburg > Tel.: +49 30 23 45 86 96 Sitz der Gesellschaft: Berlin > Fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Olaf Wagner > > From neels at elego.de Mon Jan 28 18:11:30 2008 From: neels at elego.de (Neels Janosch Hofmeyr) Date: Mon, 28 Jan 2008 18:11:30 +0100 Subject: [M3devel] Utypes.asLong / Utypes.assignOffT In-Reply-To: <4C6699EA-187B-455D-A7D0-63A69FABF1B7@cs.purdue.edu> References: <479DDB3C.4020300@elego.de> <479E045D.2000903@elego.de> <4C6699EA-187B-455D-A7D0-63A69FABF1B7@cs.purdue.edu> Message-ID: <479E0CC2.1020206@elego.de> So, if I understand correctly, this should read y := Utypes.asLong(x) ==becomes==> y := ORD(x); x := Utypes.assignOffT(y) ==becomes==> x := VAL(y); right? Tony Hosking wrote: > You will need to use VAL as I noted to handle the fact that off_t is > LONGINT on some targets and INTEGER on others. > > On Jan 28, 2008, at 11:35 AM, Neels Janosch Hofmeyr wrote: > >> Apparently, the answer to this is trivial. I found the missing >> functions in a CVS diff: >> >> -PROCEDURE asLong (val: off_t): long = >> - BEGIN >> - RETURN val; >> - END asLong; >> - >> -PROCEDURE assignOffT (VAR dest: off_t; src: long) = >> - BEGIN >> - dest := src; >> - END assignOffT; >> >> So, just replacing all occurences of these functions with direct >> assignments compiles without problems. >> y := Utypes.asLong(x) ==becomes==> y := ORD(x); >> x := Utypes.assignOffT(y) ==becomes==> x := y; >> >> Obviously, CVSup needs to be updated so that it compiles with the >> most recent CM3! The suplib still uses the obsoleted procedures >> asLong and assignOffT. Shall I write a mail to Mr. Polstra? >> >> Neels >> >> Neels Janosch Hofmeyr wrote: >>> Hi, >>> >>> after some problems have been resolved, I still cannot figure out >>> these errors: >>> >>> ===> suplib >>> --- building in LINUXLIBC6 --- >>> >>> new source -> compiling StatBufOffT64.m3 >>> "../src/StatBufOffT64.m3", line 40: unknown qualification '.' (asLong) >>> "../src/StatBufOffT64.m3", line 45: unknown qualification '.' >>> (assignOffT) >>> >>> They are trying to access the procedures >>> Utypes.asLong >>> Utypes.assignOffT >>> >>> Apparently, Utypes.asLong(..) can simply be replaced by ORD(..). Is >>> this correct?? >>> >>> Concerning assignOffT, the commit log speaks of a function called >>> PROCEDURE expandAssign(VAR dest: off_t; src: long) >>> , but this function does not exist anywhere in the cm3 source tree >>> (grep -r expandAssign yielded no results). >>> >>> >>> How do I fix this line in suplib/src/StatBufOffT64.m3 (ll.43-46)? >>> >>> PROCEDURE SetStatSize(VAR st: struct_stat; size: CARDINAL) = >>> BEGIN >>> Utypes.assignOffT(st.st_size, size); >>> END SetStatSize; >>> >>> "../src/StatBufOffT64.m3", line 45: unknown qualification '.' >>> (assignOffT) >>> >>> >>> Thanks >>> >> >> -- >> Neels Janosch Hofmeyr >> Software Developer >> >> neels at elego.de >> Public Key: http://binarchy.net/neels/neels.hofmeyr.public.key.asc >> >> elego Software Solutions GmbH http://www.elegosoft.com >> Gustav-Meyer-Allee 25, Geb?ude 12 HRB 77719 >> 13355 Berlin, Germany Amtsgericht Charlottenburg >> Tel.: +49 30 23 45 86 96 Sitz der Gesellschaft: Berlin >> Fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Olaf Wagner >> >> > -- Neels Janosch Hofmeyr Software Developer neels at elego.de Public Key: http://binarchy.net/neels/neels.hofmeyr.public.key.asc elego Software Solutions GmbH http://www.elegosoft.com Gustav-Meyer-Allee 25, Geb?ude 12 HRB 77719 13355 Berlin, Germany Amtsgericht Charlottenburg Tel.: +49 30 23 45 86 96 Sitz der Gesellschaft: Berlin Fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Olaf Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From neels at elego.de Mon Jan 28 18:22:21 2008 From: neels at elego.de (Neels Janosch Hofmeyr) Date: Mon, 28 Jan 2008 18:22:21 +0100 Subject: [M3devel] Utypes.asLong / Utypes.assignOffT In-Reply-To: <479E0CC2.1020206@elego.de> References: <479DDB3C.4020300@elego.de> <479E045D.2000903@elego.de> <4C6699EA-187B-455D-A7D0-63A69FABF1B7@cs.purdue.edu> <479E0CC2.1020206@elego.de> Message-ID: <479E0F4D.3050809@elego.de> Duh, that was definitely wrong. If anything, it should read y := Utypes.asLong(x) ==becomes==> y := ORD(x); x := Utypes.assignOffT(y) ==becomes==> x := VAL(y, Utypes.off_t); So, is this correct, now? Neels Janosch Hofmeyr wrote: > So, if I understand correctly, this should read > > y := Utypes.asLong(x) ==becomes==> y := ORD(x); > x := Utypes.assignOffT(y) ==becomes==> x := VAL(y); > > right? > > Tony Hosking wrote: >> You will need to use VAL as I noted to handle the fact that off_t is >> LONGINT on some targets and INTEGER on others. >> >> On Jan 28, 2008, at 11:35 AM, Neels Janosch Hofmeyr wrote: >> >>> Apparently, the answer to this is trivial. I found the missing >>> functions in a CVS diff: >>> >>> -PROCEDURE asLong (val: off_t): long = >>> - BEGIN >>> - RETURN val; >>> - END asLong; >>> - >>> -PROCEDURE assignOffT (VAR dest: off_t; src: long) = >>> - BEGIN >>> - dest := src; >>> - END assignOffT; >>> >>> So, just replacing all occurences of these functions with direct >>> assignments compiles without problems. >>> y := Utypes.asLong(x) ==becomes==> y := ORD(x); >>> x := Utypes.assignOffT(y) ==becomes==> x := y; >>> >>> Obviously, CVSup needs to be updated so that it compiles with the >>> most recent CM3! The suplib still uses the obsoleted procedures >>> asLong and assignOffT. Shall I write a mail to Mr. Polstra? >>> >>> Neels >>> >>> Neels Janosch Hofmeyr wrote: >>>> Hi, >>>> >>>> after some problems have been resolved, I still cannot figure out >>>> these errors: >>>> >>>> ===> suplib >>>> --- building in LINUXLIBC6 --- >>>> >>>> new source -> compiling StatBufOffT64.m3 >>>> "../src/StatBufOffT64.m3", line 40: unknown qualification '.' (asLong) >>>> "../src/StatBufOffT64.m3", line 45: unknown qualification '.' >>>> (assignOffT) >>>> >>>> They are trying to access the procedures >>>> Utypes.asLong >>>> Utypes.assignOffT >>>> >>>> Apparently, Utypes.asLong(..) can simply be replaced by ORD(..). Is >>>> this correct?? >>>> >>>> Concerning assignOffT, the commit log speaks of a function called >>>> PROCEDURE expandAssign(VAR dest: off_t; src: long) >>>> , but this function does not exist anywhere in the cm3 source tree >>>> (grep -r expandAssign yielded no results). >>>> >>>> >>>> How do I fix this line in suplib/src/StatBufOffT64.m3 (ll.43-46)? >>>> >>>> PROCEDURE SetStatSize(VAR st: struct_stat; size: CARDINAL) = >>>> BEGIN >>>> Utypes.assignOffT(st.st_size, size); >>>> END SetStatSize; >>>> >>>> "../src/StatBufOffT64.m3", line 45: unknown qualification '.' >>>> (assignOffT) >>>> >>>> >>>> Thanks >>>> >>> >>> -- >>> Neels Janosch Hofmeyr >>> Software Developer >>> >>> neels at elego.de >>> Public Key: http://binarchy.net/neels/neels.hofmeyr.public.key.asc >>> >>> elego Software Solutions GmbH http://www.elegosoft.com >>> Gustav-Meyer-Allee 25, Geb?ude 12 HRB 77719 >>> 13355 Berlin, Germany Amtsgericht Charlottenburg >>> Tel.: +49 30 23 45 86 96 Sitz der Gesellschaft: Berlin >>> Fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Olaf Wagner >>> >>> >> > -- Neels Janosch Hofmeyr Software Developer neels at elego.de Public Key: http://binarchy.net/neels/neels.hofmeyr.public.key.asc elego Software Solutions GmbH http://www.elegosoft.com Gustav-Meyer-Allee 25, Geb?ude 12 HRB 77719 13355 Berlin, Germany Amtsgericht Charlottenburg Tel.: +49 30 23 45 86 96 Sitz der Gesellschaft: Berlin Fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Olaf Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From jayk123 at hotmail.com Mon Jan 28 18:27:19 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 28 Jan 2008 17:27:19 +0000 Subject: [M3devel] nt386gnu threads? In-Reply-To: <2AEEE262-57C1-4D62-AB21-CA977F6C273E@cs.purdue.edu> References: <591840BD-4494-4A2C-AC0F-CD017338E5ED@cs.purdue.edu> <2AEEE262-57C1-4D62-AB21-CA977F6C273E@cs.purdue.edu> Message-ID: > > platforms -- surely \ never occurs anyway on Unix... :)> > Not sure: can \ be used as an escape in file names? Escaping? At the libc/kernel level? Are you serious? I assume they are taken literally and either accepted or rejected. I can try some stuff later. But, even if they are accepted literally, nobody uses them. FURTHERMORE, there is way too much low level parsing of paths. It's a big huge mess. They should probably be parsed into a higher level for internal manipulation and then regurgiated into an external form for the lower level APIs and for human display. Of course, abstraction abstraction abstraction show me the real thing already. :) > I think NT386GNU always used Win32 threads. I think not, but nobody has really said anything with certainty. I am not placing bets either way. I have the PM3 source from Elegosoft locally, simple cvs checkout. I haven't built it. It doesn't show much sign of using native Win32 threads, but I realize building the source and looking at the binaries is much more conclusive than reading the source. As well, what is PM3-Klagenfurt compard to what I am looking at? Should I go and get its source? And, what matters anyway? I think this Cygwin port is going to be mostly garbage anyway, and using pthreads does enhance the garbage somewhat what with pthread_once and pthread_cond, that NT doesn't have until Vista (sigh). Oh..I am remembering why it matters. Direct Win32 threads would be nice but you'd have to weed out other stuff, the dependency from the File APIs to the threading library. Once thie "port" is working and available, maybe someone else who actually uses it can improve it? (Bueller?) I'd like to get back to adding longint support to the integrated backend and possibly bringing up other targets.. I mean, heck, I'm no big user/fan of Unix, but running Unix natively has got to be better than this mismash.. And the pixmap bug, and the set regression test.. :) - 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 rcoleburn at scires.com Mon Jan 28 19:15:42 2008 From: rcoleburn at scires.com (Randy Coleburn) Date: Mon, 28 Jan 2008 13:15:42 -0500 Subject: [M3devel] cm3.cfg variables for IDE In-Reply-To: References: <591840BD-4494-4A2C-AC0F-CD017338E5ED@cs.purdue.edu> <2AEEE262-57C1-4D62-AB21-CA977F6C273E@cs.purdue.edu> Message-ID: <479DD57E.1E75.00D7.1@scires.com> Jay: I thought I should let you know what I understand to be the variables that the IDE is looking to find in cm3.cfg. That way, as you work through any changes to the various cm3.cfg, you can make sure these requirements are met. INSTALL_ROOT (e.g., c:\cm3) BUILD_DIR (e.g., NT386) PKG_USE (e.g., c:\cm3\pkg) DOC_INSTALL (e.g., c:\cm3\doc) INITIAL_CM3_IDE_BROWSER (e.g., c:\progra~1\intern~1\iexplore.exe) INITIAL_CM3_IDE_EDITOR (e.g., c:\progra~1\window~1\accessories\wordpad.exe) Now, of these 6 listed above, the first three: INSTALL_ROOT, BUILD_DIR and PKG_USE, are the most critical for the IDE. DOC_INSTALL can be omitted, in which case the IDE will substitute INSTALL_ROOT\doc If INITIAL_CM3_IDE_BROWSER and/or INITIAL_CM3_IDE_EDITOR are not defined, the IDE will prompt the user via its console log window for the complete paths to these two programs; thus their definition can be omitted from the cm3.cfg. The IDE will store the user's input for subsequent reuse in its own private cfg file. This file is stored in the user's home folder or as specified in the optional CM3_IDE_HOME environment variable. The CM3_IDE_HOME environment variable should point to the path of the user's primary private package repository. CM3_IDE_HOME should NOT be defined in cm3.cfg. If anyone wants to keep the cminstall program up-to-date, they should replace INITIAL_REACTOR_BROWSER and INITIAL_REACTOR_EDITOR with INITIAL_CM3_IDE_BROWSER and/or INITIAL_CM3_IDE_EDITOR . Regards, Randy -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon Jan 28 19:27:04 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 28 Jan 2008 13:27:04 -0500 Subject: [M3devel] nt386gnu threads? In-Reply-To: References: <591840BD-4494-4A2C-AC0F-CD017338E5ED@cs.purdue.edu> <2AEEE262-57C1-4D62-AB21-CA977F6C273E@cs.purdue.edu> Message-ID: <8A226653-07FE-4222-9D54-ADB55D6358CB@cs.purdue.edu> On Jan 28, 2008, at 12:27 PM, Jay wrote: > And the pixmap bug, and the set regression test.. :) :-) And the backend (for me to add stdcall tags), and a known bug in pthreads on FreeBSD, ... It's great that there is so much activity in CM3 these days though. > > > - Jay > > > Connect and share in new ways with Windows Live. Get it now! From jayk123 at hotmail.com Mon Jan 28 19:33:18 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 28 Jan 2008 18:33:18 +0000 Subject: [M3devel] nt386gnu threads? In-Reply-To: <8A226653-07FE-4222-9D54-ADB55D6358CB@cs.purdue.edu> References: <591840BD-4494-4A2C-AC0F-CD017338E5ED@cs.purdue.edu> <2AEEE262-57C1-4D62-AB21-CA977F6C273E@cs.purdue.edu> <8A226653-07FE-4222-9D54-ADB55D6358CB@cs.purdue.edu> Message-ID: I believe I'll have an ok workaround for the stdcall stuff. I think I even know how to fix it "properly". First I want the non-gui NT386GNU to work. It builds *now*, but doesn't work. - Jay > CC: m3devel at elegosoft.com> From: hosking at cs.purdue.edu> Subject: Re: [M3devel] nt386gnu threads?> Date: Mon, 28 Jan 2008 13:27:04 -0500> To: jayk123 at hotmail.com> > > On Jan 28, 2008, at 12:27 PM, Jay wrote:> > > And the pixmap bug, and the set regression test.. :)> > :-) And the backend (for me to add stdcall tags), and a known bug in > pthreads on FreeBSD, ...> > It's great that there is so much activity in CM3 these days though.> > >> >> > - 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 Jan 28 19:40:04 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 28 Jan 2008 18:40:04 +0000 Subject: [M3devel] cm3.cfg variables for IDE In-Reply-To: <479DD57E.1E75.00D7.1@scires.com> References: <591840BD-4494-4A2C-AC0F-CD017338E5ED@cs.purdue.edu> <2AEEE262-57C1-4D62-AB21-CA977F6C273E@cs.purdue.edu> <479DD57E.1E75.00D7.1@scires.com> Message-ID: There are other ways to do this...rather than run iexplore, you can use ShellExecute and run a url or something, or find the clsid of mshtml.dll maybe. For wordpad, again ShellExecute wil tend to find it. Notice how if you say start.run and type wordpad, it finds it? Or "start wordpad" from the command line? "start" ~ ShellExecute, instead of CreateProcess. "Shell" meaning the GUI shell -- Windows Explorer. Wordpad and notepad stink as text editors. And notepad doesn't like Unix newlines. I assume that's why wordepad. Someting should be done, like, in the grand gui installer, where it lists some freeware/shareware editors and offers to download and install and set them as the editor for you. Stuf like TextEdit, TextPad, UltraEdit...I think all of those exist, though somewhat I'm guesing based on the obvious formula. :) As well if it locate msdev or devenv that would be super. As I was saying the other day, I believe msdev and devenv are easily findable via normal installs, except not on my machines. :) I need to go through the environment you sent. The way this stuff works in Modula-3 today is..unnecessarily old fashioned...I'm all for simplicity, but having a bajillion environment variables does not seem to be the thing. Or a bajillion line user editor text files. Or short file names anywhere! Just do a backup/restore and see if those names survive. They might. They might not. Oh well, true, nobody ever backs anything up. Still, xcopy your software from one machine to another and see if the paths still work -- definitely it's hard to do that for free, but you can keep the cost down. - Jay Date: Mon, 28 Jan 2008 13:15:42 -0500From: rcoleburn at scires.comTo: jayk123 at hotmail.comCC: m3devel at elegosoft.comSubject: cm3.cfg variables for IDE Jay: I thought I should let you know what I understand to be the variables that the IDE is looking to find in cm3.cfg. That way, as you work through any changes to the various cm3.cfg, you can make sure these requirements are met. INSTALL_ROOT (e.g., c:\cm3)BUILD_DIR (e.g., NT386)PKG_USE (e.g., c:\cm3\pkg) DOC_INSTALL (e.g., c:\cm3\doc)INITIAL_CM3_IDE_BROWSER (e.g., c:\progra~1\intern~1\iexplore.exe)INITIAL_CM3_IDE_EDITOR (e.g., c:\progra~1\window~1\accessories\wordpad.exe) Now, of these 6 listed above, the first three: INSTALL_ROOT, BUILD_DIR and PKG_USE, are the most critical for the IDE. DOC_INSTALL can be omitted, in which case the IDE will substitute INSTALL_ROOT\doc If INITIAL_CM3_IDE_BROWSER and/or INITIAL_CM3_IDE_EDITOR are not defined, the IDE will prompt the user via its console log window for the complete paths to these two programs; thus their definition can be omitted from the cm3.cfg. The IDE will store the user's input for subsequent reuse in its own private cfg file. This file is stored in the user's home folder or as specified in the optional CM3_IDE_HOME environment variable. The CM3_IDE_HOME environment variable should point to the path of the user's primary private package repository. CM3_IDE_HOME should NOT be defined in cm3.cfg. If anyone wants to keep the cminstall program up-to-date, they should replace INITIAL_REACTOR_BROWSER and INITIAL_REACTOR_EDITOR with INITIAL_CM3_IDE_BROWSER and/or INITIAL_CM3_IDE_EDITOR . Regards, Randy _________________________________________________________________ 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 Jan 28 19:54:47 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 28 Jan 2008 18:54:47 +0000 Subject: [M3devel] NT386/NT386GNU/NT386MINGNU? In-Reply-To: <479DD57E.1E75.00D7.1@scires.com> References: <591840BD-4494-4A2C-AC0F-CD017338E5ED@cs.purdue.edu> <2AEEE262-57C1-4D62-AB21-CA977F6C273E@cs.purdue.edu> <479DD57E.1E75.00D7.1@scires.com> Message-ID: NT386/NT386GNU/NT386MINGNU My "vision" of these is pretty much in now.My weirdo target vs. configuration split. They are all TARGET = NT386. That's the "odd" part.TARGET = NT386GNU doesn't really mean anything.BUILD_DIR varies.OS_TYPE varies.Some other things vary. Does it suck or is it ok or is it great? Should they just be targets instead? This question is really aimed at the people who work on it, who have added new targets in the past, and who have perhaps thought about the SOLsun vs. SOLgnu split. How do you specify which you want? There are a few ways. Just use one usual cm3.cfg file next to cm3.exe (granted, you have to have around like four files, since they share code, NT386 and NT386GNU includes NT386.Common, NT386MINGNU includes NT386). or set the M3CONFIG variable; I've been doing that, right into the source tree. Or possibly CM3_TARGET + CM3_OSTYPE + CM3_GCC_BACKEND The Python code sniffs those. I've been trying that too. Or uname. Again the Python code sniffs. In the compiler, TARGET = NT386 + OS_TYPE == POSIX means Cygwin means a larger jmpbuf. Sleazy or reasonable? I think reasonable. There are still missing parts but it is taking shape. NT386GNU now builds, but you can't run the results at all, they crash.Been there before. :)(But it's obvious where to start here -- fix Upthread.i3.) m3makefiles have to cope, at least in m3core.They always did. You know, there are directories named POSIX, NT386, cygwin, pthread.That is, neither include(OS_TYPE) nor include(TARGET) were ever always correct. Sometimes there was special logic.Now there is just slightly more logic.Reasonable? One bit I feel guilty about is probably too much dependency on OS_TYPE.Some of that should probably be on C_LIBRARY and OS_TYPE should fall away ifC_LIBRARY / THREAD_LIBRARY / WINDOW_LIBRARY are used.I changed them from 0 and 1 to more readable like MS, GNU, X, CYG.There's also C_COMPILER = MS or GNULINKER = MS or GNU The primary users of these variables are NT386.Common. NT386GNU, NT386, NT386MINGNU are little stubs that set some variables and include it. Naming conventions isn't working correctly right now, must have been some oversight by me. Still much to do. Folks who favor one coniguration or the other should benchmark the build times.I should report them.The integrated backend is FAST.Cygwin is SLOW. For goodness sakes, look at how it implements fork(). It does an immediate selective copy, erring toward copying stuff. Yeah, it's nice and impressive that it even works, I realize.MinGWin is in betwen. AND you /should/ be able to target the Cygwin runtime using the integrated backend, and either compiler/lnker. That is, if you really want those forward slashes, and a fast build, that should be totally doable.I was thinking of making NT386FASTGNU, but it's not clear if it is builds fast or runs fast -- builds fast. Well, a native build of that would be in between. cm3 would still pay for Cygwin, but the backend would still be faster for most of its work. :) later, - 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 Jan 28 20:00:35 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 28 Jan 2008 19:00:35 +0000 Subject: [M3devel] NT386/NT386GNU/NT386MINGNU? In-Reply-To: References: <591840BD-4494-4A2C-AC0F-CD017338E5ED@cs.purdue.edu> <2AEEE262-57C1-4D62-AB21-CA977F6C273E@cs.purdue.edu> <479DD57E.1E75.00D7.1@scires.com> Message-ID: ps: NT386MINGNU really does not capture it -- it should like NT386_GNUTOOLS or NT386_GCCBACKEND As I've said, there's a bunch of independent variables, and precanned combinations are nice to have, but hard to chose just which ones and hard to name them... - Jay From: jayk123 at hotmail.comTo: m3devel at elegosoft.comDate: Mon, 28 Jan 2008 18:54:47 +0000Subject: [M3devel] NT386/NT386GNU/NT386MINGNU? NT386/NT386GNU/NT386MINGNU My "vision" of these is pretty much in now.My weirdo target vs. configuration split.They are all TARGET = NT386. That's the "odd" part.TARGET = NT386GNU doesn't really mean anything.BUILD_DIR varies.OS_TYPE varies.Some other things vary.Does it suck or is it ok or is it great?Should they just be targets instead?This question is really aimed at the people who work on it, who have added new targets in the past, and who have perhaps thought about the SOLsun vs. SOLgnu split.How do you specify which you want?There are a few ways. Just use one usual cm3.cfg file next to cm3.exe (granted, you have to have around like four files, since they share code, NT386 and NT386GNU includes NT386.Common, NT386MINGNU includes NT386). or set the M3CONFIG variable; I've been doing that, right into the source tree. Or possibly CM3_TARGET + CM3_OSTYPE + CM3_GCC_BACKEND The Python code sniffs those. I've been trying that too. Or uname. Again the Python code sniffs.In the compiler, TARGET = NT386 + OS_TYPE == POSIX means Cygwin means a larger jmpbuf. Sleazy or reasonable? I think reasonable.There are still missing parts but it is taking shape.NT386GNU now builds, but you can't run the results at all, they crash.Been there before. :)(But it's obvious where to start here -- fix Upthread.i3.)m3makefiles have to cope, at least in m3core.They always did. You know, there are directories named POSIX, NT386, cygwin, pthread.That is, neither include(OS_TYPE) nor include(TARGET) were ever always correct.Sometimes there was special logic.Now there is just slightly more logic.Reasonable?One bit I feel guilty about is probably too much dependency on OS_TYPE.Some of that should probably be on C_LIBRARY and OS_TYPE should fall away ifC_LIBRARY / THREAD_LIBRARY / WINDOW_LIBRARY are used.I changed them from 0 and 1 to more readable like MS, GNU, X, CYG.There's also C_COMPILER = MS or GNULINKER = MS or GNU The primary users of these variables are NT386.Common.NT386GNU, NT386, NT386MINGNU are little stubs that set some variables and include it.Naming conventions isn't working correctly right now, must have been some oversight by me.Still much to do.Folks who favor one coniguration or the other should benchmark the build times.I should report them.The integrated backend is FAST.Cygwin is SLOW. For goodness sakes, look at how it implements fork(). It does an immediate selective copy, erring toward copying stuff. Yeah, it's nice and impressive that it even works, I realize.MinGWin is in betwen. AND you /should/ be able to target the Cygwin runtime using the integrated backend, and either compiler/lnker.That is, if you really want those forward slashes, and a fast build, that should be totally doable.I was thinking of making NT386FASTGNU, but it's not clear if it is builds fast or runs fast -- builds fast.Well, a native build of that would be in between. cm3 would still pay for Cygwin, but the backend would still be faster for most of its work. :) later, - 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 Mon Jan 28 20:32:19 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 28 Jan 2008 14:32:19 -0500 Subject: [M3devel] cm3.cfg variables for IDE In-Reply-To: References: <591840BD-4494-4A2C-AC0F-CD017338E5ED@cs.purdue.edu> <2AEEE262-57C1-4D62-AB21-CA977F6C273E@cs.purdue.edu> <479DD57E.1E75.00D7.1@scires.com> Message-ID: It is not so much old-fashioned as consistent across platforms (Unix, Windows, etc.). Ideally, the same install procedure and environment variables make sense on all platforms. Don't fork the install for different platforms if at all possible. On Jan 28, 2008, at 1:40 PM, Jay wrote: > There are other ways to do this...rather than run iexplore, you can > use ShellExecute and run a url or something, or find the clsid of > mshtml.dll maybe. For wordpad, again ShellExecute wil tend to find > it. Notice how if you say start.run and type wordpad, it finds it? > Or "start wordpad" from the command line? "start" ~ ShellExecute, > instead of CreateProcess. "Shell" meaning the GUI shell -- Windows > Explorer. > > Wordpad and notepad stink as text editors. And notepad doesn't like > Unix newlines. I assume that's why wordepad. > Someting should be done, like, in the grand gui installer, where it > lists some freeware/shareware editors and offers to download and > install and set them as the editor for you. Stuf like TextEdit, > TextPad, UltraEdit...I think all of those exist, though somewhat > I'm guesing based on the obvious formula. :) > As well if it locate msdev or devenv that would be super. > > As I was saying the other day, I believe msdev and devenv are > easily findable via normal installs, except not on my machines. :) > I need to go through the environment you sent. > > The way this stuff works in Modula-3 today is..unnecessarily old > fashioned...I'm all for simplicity, but having a bajillion > environment variables does not seem to be the thing. Or a bajillion > line user editor text files. Or short file names anywhere! Just do > a backup/restore and see if those names survive. They might. They > might not. Oh well, true, nobody ever backs anything up. Still, > xcopy your software from one machine to another and see if the > paths still work -- definitely it's hard to do that for free, but > you can keep the cost down. > > - Jay > > > Date: Mon, 28 Jan 2008 13:15:42 -0500From: rcoleburn at scires.comTo: > jayk123 at hotmail.comCC: m3devel at elegosoft.comSubject: cm3.cfg > variables for IDE > > Jay: > > I thought I should let you know what I understand to be the > variables that the IDE is looking to find in cm3.cfg. That way, as > you work through any changes to the various cm3.cfg, you can make > sure these requirements are met From jayk123 at hotmail.com Mon Jan 28 22:33:57 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 28 Jan 2008 21:33:57 +0000 Subject: [M3devel] cm3.cfg variables for IDE In-Reply-To: References: <591840BD-4494-4A2C-AC0F-CD017338E5ED@cs.purdue.edu> <2AEEE262-57C1-4D62-AB21-CA977F6C273E@cs.purdue.edu> <479DD57E.1E75.00D7.1@scires.com> Message-ID: Make it easier on Windows... ? Right? Windows is the oddball anyway, right? Ok, that's not a great excuse. Do people tend to have firefox or firefox-bin on $PATH on Unix, if they have it on their machines? Or they have "shortcuts" on their "start menus"? I know this totally Windows termonilogy but I have used KDE and GNOME and they seem pretty isomorphic in this area. Ok, I guess they are the K menu the Foot menu. I don't know what they call "shortcuts". Is anyone, um, interested in adopting spaces in their file paths on Unix and work out the kinks? I for one put my compiler, linker, headers, libs without spaces, AND the environment variable based approach I put in makes spaces work anyway. Less luck with IE though. The code is likely forked in terms of where it runs stuff. CreateProcess vs. exec. Not that Windows doesn't have stuff that looks more like exec, or esp. system(), but still some chance that it is forked. So going down the Windows CreateProcess path, it could optionally use ShellExecute, and that will more leaf-only paths like "wordpad.exe" and "iexplore.exe" "just work". Here is another idea. There are environment variables for %programfiles% and %programfiles(x86)%. How about letting environment variables be used here? Well, heck, they are already are allowed, in Quake, with a leading dollar sign. BROWSER = $ProgramFiles & "\internet explorer\iexplore.exe" or somesuch. Not sure you could reference x86 IE from a 64bit process, what with hose parens in the variable name.. darnit. I've got to an AMD64 machine for home soon... If these are "paths to files" and not "command lines", then spaces are unambiguous. As well, CreateProcess is a little funky, but one of its parameters is a file path, not a command line and using that might help here, might. - Jay > CC: rcoleburn at scires.com; m3devel at elegosoft.com> From: hosking at cs.purdue.edu> Subject: Re: [M3devel] cm3.cfg variables for IDE> Date: Mon, 28 Jan 2008 14:32:19 -0500> To: jayk123 at hotmail.com> > It is not so much old-fashioned as consistent across platforms (Unix, > Windows, etc.). Ideally, the same install procedure and environment > variables make sense on all platforms. Don't fork the install for > different platforms if at all possible.> > On Jan 28, 2008, at 1:40 PM, Jay wrote:> > > There are other ways to do this...rather than run iexplore, you can > > use ShellExecute and run a url or something, or find the clsid of > > mshtml.dll maybe. For wordpad, again ShellExecute wil tend to find > > it. Notice how if you say start.run and type wordpad, it finds it? > > Or "start wordpad" from the command line? "start" ~ ShellExecute, > > instead of CreateProcess. "Shell" meaning the GUI shell -- Windows > > Explorer.> >> > Wordpad and notepad stink as text editors. And notepad doesn't like > > Unix newlines. I assume that's why wordepad.> > Someting should be done, like, in the grand gui installer, where it > > lists some freeware/shareware editors and offers to download and > > install and set them as the editor for you. Stuf like TextEdit, > > TextPad, UltraEdit...I think all of those exist, though somewhat > > I'm guesing based on the obvious formula. :)> > As well if it locate msdev or devenv that would be super.> >> > As I was saying the other day, I believe msdev and devenv are > > easily findable via normal installs, except not on my machines. :) > > I need to go through the environment you sent.> >> > The way this stuff works in Modula-3 today is..unnecessarily old > > fashioned...I'm all for simplicity, but having a bajillion > > environment variables does not seem to be the thing. Or a bajillion > > line user editor text files. Or short file names anywhere! Just do > > a backup/restore and see if those names survive. They might. They > > might not. Oh well, true, nobody ever backs anything up. Still, > > xcopy your software from one machine to another and see if the > > paths still work -- definitely it's hard to do that for free, but > > you can keep the cost down.> >> > - Jay> >> >> > Date: Mon, 28 Jan 2008 13:15:42 -0500From: rcoleburn at scires.comTo: > > jayk123 at hotmail.comCC: m3devel at elegosoft.comSubject: cm3.cfg > > variables for IDE> >> > Jay:> >> > I thought I should let you know what I understand to be the > > variables that the IDE is looking to find in cm3.cfg. That way, as > > you work through any changes to the various cm3.cfg, you can make > > sure these requirements are met> _________________________________________________________________ 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 Jan 28 22:35:51 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 28 Jan 2008 21:35:51 +0000 Subject: [M3devel] cm3.cfg variables for IDE In-Reply-To: References: <591840BD-4494-4A2C-AC0F-CD017338E5ED@cs.purdue.edu> <2AEEE262-57C1-4D62-AB21-CA977F6C273E@cs.purdue.edu> <479DD57E.1E75.00D7.1@scires.com> Message-ID: or heck, just spec these as command lines, or command line prefixes, instead of file names and say "start iexplore" and "start wordpad". If you want to wait for them to exit, try "start /wait". If it doesn't quite work the first time, try "cmd start wordpad" or "cmd start /wait wordpad", that probably is needed. No more path to configure. No more install.... - Jay From: jayk123 at hotmail.comTo: hosking at cs.purdue.eduCC: rcoleburn at scires.com; m3devel at elegosoft.comSubject: RE: [M3devel] cm3.cfg variables for IDEDate: Mon, 28 Jan 2008 21:33:57 +0000 Make it easier on Windows... ? Right?Windows is the oddball anyway, right? Ok, that's not a great excuse. Do people tend to have firefox or firefox-bin on $PATH on Unix, if they have it on their machines?Or they have "shortcuts" on their "start menus"? I know this totally Windows termonilogy but I have used KDE and GNOME and they seem pretty isomorphic in this area. Ok, I guess they are the K menu the Foot menu. I don't know what they call "shortcuts". Is anyone, um, interested in adopting spaces in their file paths on Unix and work out the kinks?I for one put my compiler, linker, headers, libs without spaces, AND the environment variable based approach I put in makes spaces work anyway.Less luck with IE though. The code is likely forked in terms of where it runs stuff. CreateProcess vs. exec. Not that Windows doesn't have stuff that looks more like exec, or esp. system(), but still some chance that it is forked. So going down the Windows CreateProcess path, it could optionally use ShellExecute, and that will more leaf-only paths like "wordpad.exe" and "iexplore.exe" "just work". Here is another idea. There are environment variables for %programfiles% and %programfiles(x86)%.How about letting environment variables be used here?Well, heck, they are already are allowed, in Quake, with a leading dollar sign.BROWSER = $ProgramFiles & "\internet explorer\iexplore.exe" or somesuch.Not sure you could reference x86 IE from a 64bit process, what with hose parens in the variable name.. darnit.I've got to an AMD64 machine for home soon... If these are "paths to files" and not "command lines", then spaces are unambiguous.As well, CreateProcess is a little funky, but one of its parameters is a file path, not a command line and using that might help here, might. - Jay > CC: rcoleburn at scires.com; m3devel at elegosoft.com> From: hosking at cs.purdue.edu> Subject: Re: [M3devel] cm3.cfg variables for IDE> Date: Mon, 28 Jan 2008 14:32:19 -0500> To: jayk123 at hotmail.com> > It is not so much old-fashioned as consistent across platforms (Unix, > Windows, etc.). Ideally, the same install procedure and environment > variables make sense on all platforms. Don't fork the install for > different platforms if at all possible.> > On Jan 28, 2008, at 1:40 PM, Jay wrote:> > > There are other ways to do this...rather than run iexplore, you can > > use ShellExecute and run a url or something, or find the clsid of > > mshtml.dll maybe. For wordpad, again ShellExecute wil tend to find > > it. Notice how if you say start.run and type wordpad, it finds it? > > Or "start wordpad" from the command line? "start" ~ ShellExecute, > > instead of CreateProcess. "Shell" meaning the GUI shell -- Windows > > Explorer.> >> > Wordpad and notepad stink as text editors. And notepad doesn't like > > Unix newlines. I assume that's why wordepad.> > Someting should be done, like, in the grand gui installer, where it > > lists some freeware/shareware editors and offers to download and > > install and set them as the editor for you. Stuf like TextEdit, > > TextPad, UltraEdit...I think all of those exist, though somewhat > > I'm guesing based on the obvious formula. :)> > As well if it locate msdev or devenv that would be super.> >> > As I was saying the other day, I believe msdev and devenv are > > easily findable via normal installs, except not on my machines. :) > > I need to go through the environment you sent.> >> > The way this stuff works in Modula-3 today is..unnecessarily old > > fashioned...I'm all for simplicity, but having a bajillion > > environment variables does not seem to be the thing. Or a bajillion > > line user editor text files. Or short file names anywhere! Just do > > a backup/restore and see if those names survive. They might. They > > might not. Oh well, true, nobody ever backs anything up. Still, > > xcopy your software from one machine to another and see if the > > paths still work -- definitely it's hard to do that for free, but > > you can keep the cost down.> >> > - Jay> >> >> > Date: Mon, 28 Jan 2008 13:15:42 -0500From: rcoleburn at scires.comTo: > > jayk123 at hotmail.comCC: m3devel at elegosoft.comSubject: cm3.cfg > > variables for IDE> >> > Jay:> >> > I thought I should let you know what I understand to be the > > variables that the IDE is looking to find in cm3.cfg. That way, as > > you work through any changes to the various cm3.cfg, you can make > > sure these requirements are met> 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 wagner at elegosoft.com Mon Jan 28 23:31:30 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 28 Jan 2008 23:31:30 +0100 Subject: [M3devel] cm3.cfg variables for IDE In-Reply-To: References: <591840BD-4494-4A2C-AC0F-CD017338E5ED@cs.purdue.edu> <2AEEE262-57C1-4D62-AB21-CA977F6C273E@cs.purdue.edu> <479DD57E.1E75.00D7.1@scires.com> Message-ID: <20080128233130.qzbxmy3wg444o84k@mail.elegosoft.com> Quoting Jay : > Do people tend to have firefox or firefox-bin on $PATH on Unix, if > they have it on their machines? People I know use all sorts of browsers on Unix: firefox, mozilla, opera, conquerer, ... > Or they have "shortcuts" on their "start menus"? > I know this totally Windows termonilogy but I have used KDE and > GNOME and they seem pretty isomorphic in this area. > Ok, I guess they are the K menu the Foot menu. I don't know what > they call "shortcuts". I still use fvwm and avoid all more enhanced desktops if possible ;-) > Is anyone, um, interested in adopting spaces in their file paths on > Unix and work out the kinks? This has been tried before, but it will break all simple usage of command line utilities (and there are hundreds of these). I personally don't see the point of using spaces in file names, but opinions may differ on this topic. As for the rest: I'd like to see a list of those settings an installer should find out for itself (as they are platform dependent and there is no real choice for the user) and those that are truly user-selectable due to personal preferences etc. These may also depend on the platform. Such a document may might be a start for an installer redesign (if we don't go for the system-dependent installation packages at last). It will be a tedious work to do that 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 rcoleburn at scires.com Mon Jan 28 23:34:19 2008 From: rcoleburn at scires.com (Randy Coleburn) Date: Mon, 28 Jan 2008 17:34:19 -0500 Subject: [M3devel] cm3.cfg variables for IDE In-Reply-To: References: <591840BD-4494-4A2C-AC0F-CD017338E5ED@cs.purdue.edu> <2AEEE262-57C1-4D62-AB21-CA977F6C273E@cs.purdue.edu> <479DD57E.1E75.00D7.1@scires.com> Message-ID: <479E121A.1E75.00D7.1@scires.com> Jay: I understand about use of the "shell" in Windows to find stuff. I use the "start" command all the time. I'm not ASKING for how best to fix/change/improve the current situation. I'm just STATING what is required for now. Anyone is welcome to improve upon things later. I'm just trying to get this "out the door" so it is available to everyone. At one point in time, circa cm3 v4.1, all of this did in fact work; and, it worked across multiple platforms. If we can get the IDE into the repository, we can migrate it along with the rest of cm3 as the system evolves. No, I don't use WordPad or Notepad as my primary editor for m3 code. I use CRiSP, but that is beside the point. The original CMass Reactor designers tried to come up with some reasonable defaults for the various platforms that would work in virtually all cases. CMInstall used notepad as the default editor for Windows because all Windows systems were known to have notepad installed by default. On Unix, it used a different default, probably vi or something. During the CMInstall dialog, my recollection is that it probed your system for "known" editors and browsers and let you pick from a list of what it found, or you could override its default choices by specifying whatever you wanted. At run-time, the IDE has a configuration screen where you can change these selections again. So, the idea was to make sure Reactor worked out-of-the-box, and let the user customize it to make the experience better, e.g., choose your favorite editor, source code control system, etc. Bottom line, for now we need to make sure INSTALL_ROOT, BUILD_DIR and PKG_USE are defined in cm3.cfg for all platforms. Otherwise, the user is going to run into trouble and we will have to deal with a bunch of support requests. Going forward, we can adapt the IDE code to do whatever works best for everyone. Regards, Randy >>> Jay 1/28/2008 1:40 PM >>> There are other ways to do this...rather than run iexplore, you can use ShellExecute and run a url or something, or find the clsid of mshtml.dll maybe. For wordpad, again ShellExecute wil tend to find it. Notice how if you say start.run and type wordpad, it finds it? Or "start wordpad" from the command line? "start" ~ ShellExecute, instead of CreateProcess. "Shell" meaning the GUI shell -- Windows Explorer. Wordpad and notepad stink as text editors. And notepad doesn't like Unix newlines. I assume that's why wordepad. Someting should be done, like, in the grand gui installer, where it lists some freeware/shareware editors and offers to download and install and set them as the editor for you. Stuf like TextEdit, TextPad, UltraEdit...I think all of those exist, though somewhat I'm guesing based on the obvious formula. :) As well if it locate msdev or devenv that would be super. As I was saying the other day, I believe msdev and devenv are easily findable via normal installs, except not on my machines. :) I need to go through the environment you sent. The way this stuff works in Modula-3 today is..unnecessarily old fashioned... I'm all for simplicity, but having a bajillion environment variables does not seem to be the thing. Or a bajillion line user editor text files. Or short file names anywhere! Just do a backup/restore and see if those names survive. They might. They might not. Oh well, true, nobody ever backs anything up. Still, xcopy your software from one machine to another and see if the paths still work -- definitely it's hard to do that for free, but you can keep the cost down. - Jay Date: Mon, 28 Jan 2008 13:15:42 -0500 From: rcoleburn at scires.com To: jayk123 at hotmail.com CC: m3devel at elegosoft.com Subject: cm3.cfg variables for IDE Jay: I thought I should let you know what I understand to be the variables that the IDE is looking to find in cm3.cfg. That way, as you work through any changes to the various cm3.cfg, you can make sure these requirements are met. INSTALL_ROOT (e.g., c:\cm3) BUILD_DIR (e.g., NT386) PKG_USE (e.g., c:\cm3\pkg) DOC_INSTALL (e.g., c:\cm3\doc) INITIAL_CM3_IDE_BROWSER (e.g., c:\progra~1\intern~1\iexplore.exe) INITIAL_CM3_IDE_EDITOR (e.g., c:\progra~1\window~1\accessories\wordpad.exe) Now, of these 6 listed above, the first three: INSTALL_ROOT, BUILD_DIR and PKG_USE, are the most critical for the IDE. DOC_INSTALL can be omitted, in which case the IDE will substitute INSTALL_ROOT\doc If INITIAL_CM3_IDE_BROWSER and/or INITIAL_CM3_IDE_EDITOR are not defined, the IDE will prompt the user via its console log window for the complete paths to these two programs; thus their definition can be omitted from the cm3.cfg. The IDE will store the user's input for subsequent reuse in its own private cfg file. This file is stored in the user's home folder or as specified in the optional CM3_IDE_HOME environment variable. The CM3_IDE_HOME environment variable should point to the path of the user's primary private package repository. CM3_IDE_HOME should NOT be defined in cm3.cfg. If anyone wants to keep the cminstall program up-to-date, they should replace INITIAL_REACTOR_BROWSER and INITIAL_REACTOR_EDITOR with INITIAL_CM3_IDE_BROWSER and/or INITIAL_CM3_IDE_EDITOR . Regards, Randy 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 wagner at elegosoft.com Mon Jan 28 23:48:43 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 28 Jan 2008 23:48:43 +0100 Subject: [M3devel] Open CM3 regression tests In-Reply-To: References: <20080120211832.GA26993@elegosoft.com> <9C00EA97-9B43-43BE-9CDF-EEAC9C1321D5@cs.purdue.edu> <20080127150327.mh686v2hx4w080w4@mail.elegosoft.com> <1DA9FA59-6DFF-430C-90C5-F1D30003607A@cs.purdue.edu> <20080127185530.e255i76vcwckss4o@mail.elegosoft.com> Message-ID: <20080128234843.c4sc4uzy4gs8wk8c@mail.elegosoft.com> Quoting Jay : > The tests don't even build on Windows and it was going to take more > than 5 minutes fix that. > They are slightly full of sh. :) (I never tire of this joke. :) ) > My current plan is: > get NT386GNU working -- I can already build cm3 and it fails an > assertion about pthread_mutex_something failing. Hey, maybe I should > fix some of the declarations.. :) > or go back to my Mac briefly to investigate > and/or give Tony a day :) Hi Jay, don't try to do too much all at once -- take your time, there's no heed to hurry. This is an open source project :-) If I were you, I'd finish the Windows ports you are working on first, and then help Randy with his bitmap and m3ide problems. It's all up to you of course. What exactly in m3tests is slightly full of sh? I just fixed one missing abstraction, but except for some definitions at the top of the m3makefile, the rest should be quake. As for the regression test framework in scripts/regression, we can run that in NT386GNU / Cygwin if needed. It may be slow, but that should be OK. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Jan 29 00:49:32 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 28 Jan 2008 18:49:32 -0500 Subject: [M3devel] cm3.cfg variables for IDE In-Reply-To: References: <591840BD-4494-4A2C-AC0F-CD017338E5ED@cs.purdue.edu> <2AEEE262-57C1-4D62-AB21-CA977F6C273E@cs.purdue.edu> <479DD57E.1E75.00D7.1@scires.com> Message-ID: <770ED7C9-B8D5-42EC-A7A1-C54EAFDEB1AB@cs.purdue.edu> On Jan 28, 2008, at 4:33 PM, Jay wrote: > Make it easier on Windows... ? Right? > Windows is the oddball anyway, right? Ok, that's not a great excuse. > > Do people tend to have firefox or firefox-bin on $PATH on Unix, if > they have it on their machines? > Or they have "shortcuts" on their "start menus"? Nope. Not on Mac OS X. > I know this totally Windows termonilogy but I have used KDE and > GNOME and they seem pretty isomorphic in this area. > Ok, I guess they are the K menu the Foot menu. I don't know what > they call "shortcuts". > > Is anyone, um, interested in adopting spaces in their file paths on > Unix and work out the kinks? > I for one put my compiler, linker, headers, libs without spaces, > AND the environment variable based approach I put in makes spaces > work anyway. > Less luck with IE though. > > The code is likely forked in terms of where it runs stuff. > CreateProcess vs. exec. Not that Windows doesn't have stuff that > looks more like exec, or esp. system(), but still some chance that > it is forked. So going down the Windows CreateProcess path, it > could optionally use ShellExecute, and that will more leaf-only > paths like "wordpad.exe" and "iexplore.exe" "just work". > > Here is another idea. There are environment variables for % > programfiles% and %programfiles(x86)%. > How about letting environment variables be used here? > Well, heck, they are already are allowed, in Quake, with a leading > dollar sign. > BROWSER = $ProgramFiles & "\internet explorer\iexplore.exe" or > somesuch. > Not sure you could reference x86 IE from a 64bit process, what with > hose parens in the variable name.. darnit. > I've got to an AMD64 machine for home soon... > > If these are "paths to files" and not "command lines", then spaces > are unambiguous. > As well, CreateProcess is a little funky, but one of its parameters > is a file path, not a command line and using that might help here, > might. > > - Jay > > > > > CC: rcoleburn at scires.com; m3devel at elegosoft.com > > From: hosking at cs.purdue.edu > > Subject: Re: [M3devel] cm3.cfg variables for IDE > > Date: Mon, 28 Jan 2008 14:32:19 -0500 > > To: jayk123 at hotmail.com > > > > It is not so much old-fashioned as consistent across platforms > (Unix, > > Windows, etc.). Ideally, the same install procedure and environment > > variables make sense on all platforms. Don't fork the install for > > different platforms if at all possible. > > > > On Jan 28, 2008, at 1:40 PM, Jay wrote: > > > > > There are other ways to do this...rather than run iexplore, you > can > > > use ShellExecute and run a url or something, or find the clsid of > > > mshtml.dll maybe. For wordpad, again ShellExecute wil tend to find > > > it. Notice how if you say start.run and type wordpad, it finds it? > > > Or "start wordpad" from the command line? "start" ~ ShellExecute, > > > instead of CreateProcess. "Shell" meaning the GUI shell -- Windows > > > Explorer. > > > > > > Wordpad and notepad stink as text editors. And notepad doesn't > like > > > Unix newlines. I assume that's why wordepad. > > > Someting should be done, like, in the grand gui installer, > where it > > > lists some freeware/shareware editors and offers to download and > > > install and set them as the editor for you. Stuf like TextEdit, > > > TextPad, UltraEdit...I think all of those exist, though somewhat > > > I'm guesing based on the obvious formula. :) > > > As well if it locate msdev or devenv that would be super. > > > > > > As I was saying the other day, I believe msdev and devenv are > > > easily findable via normal installs, except not on my machines. :) > > > I need to go through the environment you sent. > > > > > > The way this stuff works in Modula-3 today is..unnecessarily old > > > fashioned...I'm all for simplicity, but having a bajillion > > > environment variables does not seem to be the thing. Or a > bajillion > > > line user editor text files. Or short file names anywhere! Just do > > > a backup/restore and see if those names survive. They might. They > > > might not. Oh well, true, nobody ever backs anything up. Still, > > > xcopy your software from one machine to another and see if the > > > paths still work -- definitely it's hard to do that for free, but > > > you can keep the cost down. > > > > > > - Jay > > > > > > > > > Date: Mon, 28 Jan 2008 13:15:42 -0500From: rcoleburn at scires.comTo: > > > jayk123 at hotmail.comCC: m3devel at elegosoft.comSubject: cm3.cfg > > > variables for IDE > > > > > > Jay: > > > > > > I thought I should let you know what I understand to be the > > > variables that the IDE is looking to find in cm3.cfg. That way, as > > > you work through any changes to the various cm3.cfg, you can make > > > sure these requirements are met > > > > > 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 Tue Jan 29 00:50:55 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 28 Jan 2008 18:50:55 -0500 Subject: [M3devel] cm3.cfg variables for IDE In-Reply-To: <479E121A.1E75.00D7.1@scires.com> References: <591840BD-4494-4A2C-AC0F-CD017338E5ED@cs.purdue.edu> <2AEEE262-57C1-4D62-AB21-CA977F6C273E@cs.purdue.edu> <479DD57E.1E75.00D7.1@scires.com> <479E121A.1E75.00D7.1@scires.com> Message-ID: <73F72170-FD22-476F-A307-1E9DE9331CA4@cs.purdue.edu> Hear, hear. Jay, please listen to this -- it is important! On Jan 28, 2008, at 5:34 PM, Randy Coleburn wrote: > Jay: > > I understand about use of the "shell" in Windows to find stuff. I > use the "start" command all the time. > > I'm not ASKING for how best to fix/change/improve the current > situation. I'm just STATING what is required for now. Anyone is > welcome to improve upon things later. I'm just trying to get this > "out the door" so it is available to everyone. > > At one point in time, circa cm3 v4.1, all of this did in fact work; > and, it worked across multiple platforms. If we can get the IDE > into the repository, we can migrate it along with the rest of cm3 > as the system evolves. > > No, I don't use WordPad or Notepad as my primary editor for m3 > code. I use CRiSP, but that is beside the point. The original > CMass Reactor designers tried to come up with some reasonable > defaults for the various platforms that would work in virtually all > cases. CMInstall used notepad as the default editor for Windows > because all Windows systems were known to have notepad installed by > default. On Unix, it used a different default, probably vi or > something. During the CMInstall dialog, my recollection is that it > probed your system for "known" editors and browsers and let you > pick from a list of what it found, or you could override its > default choices by specifying whatever you wanted. At run-time, > the IDE has a configuration screen where you can change these > selections again. > > So, the idea was to make sure Reactor worked out-of-the-box, and > let the user customize it to make the experience better, e.g., > choose your favorite editor, source code control system, etc. > > Bottom line, for now we need to make sure INSTALL_ROOT, BUILD_DIR > and PKG_USE are defined in cm3.cfg for all platforms. Otherwise, > the user is going to run into trouble and we will have to deal with > a bunch of support requests. > > Going forward, we can adapt the IDE code to do whatever works best > for everyone. > > Regards, > Randy > > >>> Jay 1/28/2008 1:40 PM >>> > There are other ways to do this...rather than run iexplore, you can > use ShellExecute and run a url or something, or find the clsid of > mshtml.dll maybe. For wordpad, again ShellExecute wil tend to find > it. Notice how if you say start.run and type wordpad, it finds it? > Or "start wordpad" from the command line? "start" ~ ShellExecute, > instead of CreateProcess. "Shell" meaning the GUI shell -- Windows > Explorer. > > Wordpad and notepad stink as text editors. And notepad doesn't like > Unix newlines. I assume that's why wordepad. > Someting should be done, like, in the grand gui installer, where it > lists some freeware/shareware editors and offers to download and > install and set them as the editor for you. Stuf like TextEdit, > TextPad, UltraEdit...I think all of those exist, though somewhat > I'm guesing based on the obvious formula. :) > As well if it locate msdev or devenv that would be super. > > As I was saying the other day, I believe msdev and devenv are > easily findable via normal installs, except not on my machines. :) > I need to go through the environment you sent. > > The way this stuff works in Modula-3 today is..unnecessarily old > fashioned... > I'm all for simplicity, but having a bajillion environment > variables does not seem to be the thing. Or a bajillion line user > editor text files. Or short file names anywhere! Just do a backup/ > restore and see if those names survive. They might. They might not. > Oh well, true, nobody ever backs anything up. Still, xcopy your > software from one machine to another and see if the paths still > work -- definitely it's hard to do that for free, but you can keep > the cost down. > > - Jay > > Date: Mon, 28 Jan 2008 13:15:42 -0500 > From: rcoleburn at scires.com > To: jayk123 at hotmail.com > CC: m3devel at elegosoft.com > Subject: cm3.cfg variables for IDE > > Jay: > > I thought I should let you know what I understand to be the > variables that the IDE is looking to find in cm3.cfg. That way, as > you work through any changes to the various cm3.cfg, you can make > sure these requirements are met. > > INSTALL_ROOT (e.g., c:\cm3) > BUILD_DIR (e.g., NT386) > PKG_USE (e.g., c:\cm3\pkg) > > DOC_INSTALL (e.g., c:\cm3\doc) > INITIAL_CM3_IDE_BROWSER (e.g., c:\progra~1\intern~1\iexplore.exe) > INITIAL_CM3_IDE_EDITOR (e.g., c:\progra~1\window~1\accessories > \wordpad.exe) > > Now, of these 6 listed above, the first three: INSTALL_ROOT, > BUILD_DIR and PKG_USE, are the most critical for the IDE. > > DOC_INSTALL can be omitted, in which case the IDE will substitute > INSTALL_ROOT\doc > > If INITIAL_CM3_IDE_BROWSER and/or INITIAL_CM3_IDE_EDITOR are not > defined, the IDE will prompt the user via its console log window > for the complete paths to these two programs; thus their definition > can be omitted from the cm3.cfg. The IDE will store the user's > input for subsequent reuse in its own private cfg file. This file > is stored in the user's home folder or as specified in the optional > CM3_IDE_HOME environment variable. The CM3_IDE_HOME environment > variable should point to the path of the user's primary private > package repository. CM3_IDE_HOME should NOT be defined in cm3.cfg. > > If anyone wants to keep the cminstall program up-to-date, they should > replace INITIAL_REACTOR_BROWSER and INITIAL_REACTOR_EDITOR > with INITIAL_CM3_IDE_BROWSER and/or INITIAL_CM3_IDE_EDITOR . > > Regards, > Randy > > Connect and share in new ways with Windows Live. Get it now! From hosking at cs.purdue.edu Tue Jan 29 01:02:45 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 28 Jan 2008 19:02:45 -0500 Subject: [M3devel] Utypes.asLong / Utypes.assignOffT In-Reply-To: <479E0F4D.3050809@elego.de> References: <479DDB3C.4020300@elego.de> <479E045D.2000903@elego.de> <4C6699EA-187B-455D-A7D0-63A69FABF1B7@cs.purdue.edu> <479E0CC2.1020206@elego.de> <479E0F4D.3050809@elego.de> Message-ID: Yes! On Jan 28, 2008, at 12:22 PM, Neels Janosch Hofmeyr wrote: > Duh, that was definitely wrong. If anything, it should read > > y := Utypes.asLong(x) ==becomes==> y := ORD(x); > x := Utypes.assignOffT(y) ==becomes==> x := VAL(y, Utypes.off_t); > > So, is this correct, now? > > Neels Janosch Hofmeyr wrote: >> So, if I understand correctly, this should read >> >> y := Utypes.asLong(x) ==becomes==> y := ORD(x); >> x := Utypes.assignOffT(y) ==becomes==> x := VAL(y); >> >> right? >> >> Tony Hosking wrote: >>> You will need to use VAL as I noted to handle the fact that off_t >>> is LONGINT on some targets and INTEGER on others. >>> >>> On Jan 28, 2008, at 11:35 AM, Neels Janosch Hofmeyr wrote: >>> >>>> Apparently, the answer to this is trivial. I found the missing >>>> functions in a CVS diff: >>>> >>>> -PROCEDURE asLong (val: off_t): long = >>>> - BEGIN >>>> - RETURN val; >>>> - END asLong; >>>> - >>>> -PROCEDURE assignOffT (VAR dest: off_t; src: long) = >>>> - BEGIN >>>> - dest := src; >>>> - END assignOffT; >>>> >>>> So, just replacing all occurences of these functions with direct >>>> assignments compiles without problems. >>>> y := Utypes.asLong(x) ==becomes==> y := ORD(x); >>>> x := Utypes.assignOffT(y) ==becomes==> x := y; >>>> >>>> Obviously, CVSup needs to be updated so that it compiles with >>>> the most recent CM3! The suplib still uses the obsoleted >>>> procedures asLong and assignOffT. Shall I write a mail to Mr. >>>> Polstra? >>>> >>>> Neels >>>> >>>> Neels Janosch Hofmeyr wrote: >>>>> Hi, >>>>> >>>>> after some problems have been resolved, I still cannot figure >>>>> out these errors: >>>>> >>>>> ===> suplib >>>>> --- building in LINUXLIBC6 --- >>>>> >>>>> new source -> compiling StatBufOffT64.m3 >>>>> "../src/StatBufOffT64.m3", line 40: unknown qualification >>>>> '.' (asLong) >>>>> "../src/StatBufOffT64.m3", line 45: unknown qualification >>>>> '.' (assignOffT) >>>>> >>>>> They are trying to access the procedures >>>>> Utypes.asLong >>>>> Utypes.assignOffT >>>>> >>>>> Apparently, Utypes.asLong(..) can simply be replaced by ORD >>>>> (..). Is this correct?? >>>>> >>>>> Concerning assignOffT, the commit log speaks of a function called >>>>> PROCEDURE expandAssign(VAR dest: off_t; src: long) >>>>> , but this function does not exist anywhere in the cm3 source >>>>> tree (grep -r expandAssign yielded no results). >>>>> >>>>> >>>>> How do I fix this line in suplib/src/StatBufOffT64.m3 (ll.43-46)? >>>>> >>>>> PROCEDURE SetStatSize(VAR st: struct_stat; size: CARDINAL) = >>>>> BEGIN >>>>> Utypes.assignOffT(st.st_size, size); >>>>> END SetStatSize; >>>>> >>>>> "../src/StatBufOffT64.m3", line 45: unknown qualification >>>>> '.' (assignOffT) >>>>> >>>>> >>>>> Thanks >>>>> >>>> >>>> -- >>>> Neels Janosch Hofmeyr >>>> Software Developer >>>> >>>> neels at elego.de >>>> Public Key: http://binarchy.net/neels/neels.hofmeyr.public.key.asc >>>> >>>> elego Software Solutions GmbH http://www.elegosoft.com >>>> Gustav-Meyer-Allee 25, Geb?ude 12 HRB 77719 >>>> 13355 Berlin, Germany Amtsgericht Charlottenburg >>>> Tel.: +49 30 23 45 86 96 Sitz der Gesellschaft: >>>> Berlin >>>> Fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Olaf >>>> Wagner >>>> >>>> >>> >> > > -- > Neels Janosch Hofmeyr > Software Developer > > neels at elego.de > Public Key: http://binarchy.net/neels/neels.hofmeyr.public.key.asc > > elego Software Solutions GmbH http://www.elegosoft.com > Gustav-Meyer-Allee 25, Geb?ude 12 HRB 77719 > 13355 Berlin, Germany Amtsgericht Charlottenburg > Tel.: +49 30 23 45 86 96 Sitz der Gesellschaft: Berlin > Fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Olaf Wagner > > From jayk123 at hotmail.com Tue Jan 29 01:38:26 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 29 Jan 2008 00:38:26 +0000 Subject: [M3devel] Open CM3 regression tests In-Reply-To: <20080128234843.c4sc4uzy4gs8wk8c@mail.elegosoft.com> References: <20080120211832.GA26993@elegosoft.com> <9C00EA97-9B43-43BE-9CDF-EEAC9C1321D5@cs.purdue.edu> <20080127150327.mh686v2hx4w080w4@mail.elegosoft.com> <1DA9FA59-6DFF-430C-90C5-F1D30003607A@cs.purdue.edu> <20080127185530.e255i76vcwckss4o@mail.elegosoft.com> <20080128234843.c4sc4uzy4gs8wk8c@mail.elegosoft.com> Message-ID: I was stuck on the use of "ln". I know, it should be easy, just copy stuff..or use Cygwin ln, but it kept not working and I moved on for now. I know it's an easy thing but I was being lazy and there are alternatives if it languishes long, I can try on Mac, or PPC_LINUX (which has other problems perhaps that need working out, maybe just that dynamic linking is broken, I put it in hold for now). > As for the regression test framework in scripts/regression, we can> run that in NT386GNU / Cygwin if needed. It may be slow, but that Agreed! Or, for tests failing on all systems, I can use non-Windows. > don't try to do too much all at once -- take your time, there's> no heed to hurry. I've heard this many times already. :) I am taking my time. You have not seen my hurry. And you hopefully never will. :) - Jay > Date: Mon, 28 Jan 2008 23:48:43 +0100> From: wagner at elegosoft.com> To: jayk123 at hotmail.com> CC: m3devel at elegosoft.com> Subject: RE: [M3devel] Open CM3 regression tests> > Quoting Jay :> > > The tests don't even build on Windows and it was going to take more > > than 5 minutes fix that.> > They are slightly full of sh. :) (I never tire of this joke. :) )> > My current plan is:> > get NT386GNU working -- I can already build cm3 and it fails an > > assertion about pthread_mutex_something failing. Hey, maybe I should > > fix some of the declarations.. :)> > or go back to my Mac briefly to investigate> > and/or give Tony a day :)> > Hi Jay,> > don't try to do too much all at once -- take your time, there's> no heed to hurry. This is an open source project :-)> > If I were you, I'd finish the Windows ports you are working on first,> and then help Randy with his bitmap and m3ide problems. It's all> up to you of course.> > What exactly in m3tests is slightly full of sh? I just fixed one> missing abstraction, but except for some definitions at the> top of the m3makefile, the rest should be quake.> > As for the regression test framework in scripts/regression, we can> run that in NT386GNU / Cygwin if needed. It may be slow, but that> should be OK.> > Olaf> -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 Jan 29 01:40:27 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 29 Jan 2008 00:40:27 +0000 Subject: [M3devel] cm3.cfg variables for IDE In-Reply-To: <770ED7C9-B8D5-42EC-A7A1-C54EAFDEB1AB@cs.purdue.edu> References: <591840BD-4494-4A2C-AC0F-CD017338E5ED@cs.purdue.edu> <2AEEE262-57C1-4D62-AB21-CA977F6C273E@cs.purdue.edu> <479DD57E.1E75.00D7.1@scires.com> <770ED7C9-B8D5-42EC-A7A1-C54EAFDEB1AB@cs.purdue.edu> Message-ID: Right, I've got a Mac...bite my tongue bite my tongue... :) (someday maybe we'll get this stuff working on MacClassic and 68K. :) ) - Jay > CC: rcoleburn at scires.com; m3devel at elegosoft.com> From: hosking at cs.purdue.edu> Subject: Re: [M3devel] cm3.cfg variables for IDE> Date: Mon, 28 Jan 2008 18:49:32 -0500> To: jayk123 at hotmail.com> > > On Jan 28, 2008, at 4:33 PM, Jay wrote:> > > Make it easier on Windows... ? Right?> > Windows is the oddball anyway, right? Ok, that's not a great excuse.> >> > Do people tend to have firefox or firefox-bin on $PATH on Unix, if > > they have it on their machines?> > Or they have "shortcuts" on their "start menus"?> > Nope. Not on Mac OS X. _________________________________________________________________ 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 Jan 29 01:46:50 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 29 Jan 2008 00:46:50 +0000 Subject: [M3devel] cm3.cfg variables for IDE In-Reply-To: <20080128233130.qzbxmy3wg444o84k@mail.elegosoft.com> References: <591840BD-4494-4A2C-AC0F-CD017338E5ED@cs.purdue.edu> <2AEEE262-57C1-4D62-AB21-CA977F6C273E@cs.purdue.edu> <479DD57E.1E75.00D7.1@scires.com> <20080128233130.qzbxmy3wg444o84k@mail.elegosoft.com> Message-ID: > Date: Mon, 28 Jan 2008 23:31:30 +0100> From: wagner at elegosoft.com> > Quoting Jay :> > Do people tend to have firefox or firefox-bin on $PATH on Unix, if > > they have it on their machines?> > People I know use all sorts of browsers on Unix: firefox, mozilla,> opera, conquerer, ... That wasn't my complete point, but partly. Do people have their browser in $PATH? Such that a full path isn't needed? I guess the answer is sometimes yes sometimes no. > > I still use fvwm and avoid all more enhanced desktops if possible ;-)> > > Is anyone, um, interested in adopting spaces in their file paths on > > Unix and work out the kinks?> > This has been tried before, but it will break all simple usage> of command line utilities (and there are hundreds of these).> I personally don't see the point of using spaces in file names,> but opinions may differ on this topic. I agree it is pretty pointless, but yet unfortunately on Windows there is "Program Files" and such and it's not going away. The biggest problem with quoting is you never know how many layers are going to quote/unquote. Really it's a major type system problem...one flat string vs. an array of strings. If only we typed in our command lines in a little gui with a box per parameter. :) cm3/cm3cg is very clever in one way here. cm3cg always gets its input and output from the current working directory. Boom, so many annoying problems gone. :) I don't think "hundreds" of utilities are relevant here, just a few. cc, ld, libtool, cl, link, cm3, cm3cg (not), and a little bit over in m3cc/m3gdb make sed sh. Ok, nevermind...just that I see those short paths..what a hack, they aren't even guaranteeably available, the option can be turned off....once this stuff is in I'll try to take a look at and fix it, only for the small number of visible cases, not the hundreds of cases. - 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 Jan 29 01:48:20 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 29 Jan 2008 00:48:20 +0000 Subject: [M3devel] Open CM3 regression tests In-Reply-To: <20080128234843.c4sc4uzy4gs8wk8c@mail.elegosoft.com> References: <20080120211832.GA26993@elegosoft.com> <9C00EA97-9B43-43BE-9CDF-EEAC9C1321D5@cs.purdue.edu> <20080127150327.mh686v2hx4w080w4@mail.elegosoft.com> <1DA9FA59-6DFF-430C-90C5-F1D30003607A@cs.purdue.edu> <20080127185530.e255i76vcwckss4o@mail.elegosoft.com> <20080128234843.c4sc4uzy4gs8wk8c@mail.elegosoft.com> Message-ID: > As for the regression test framework in scripts/regression, we can> run that in NT386GNU / Cygwin if needed. It may be slow, but that> Agreed! Or, for tests failing on all systems, I can use non-Windows. I was actually thinking of m3tests here, but yes, that too. - 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 Tue Jan 29 02:25:41 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 29 Jan 2008 02:25:41 +0100 Subject: [M3devel] Open CM3 regression tests In-Reply-To: References: <20080120211832.GA26993@elegosoft.com> <9C00EA97-9B43-43BE-9CDF-EEAC9C1321D5@cs.purdue.edu> <20080127150327.mh686v2hx4w080w4@mail.elegosoft.com> <1DA9FA59-6DFF-430C-90C5-F1D30003607A@cs.purdue.edu> <20080127185530.e255i76vcwckss4o@mail.elegosoft.com> <20080128234843.c4sc4uzy4gs8wk8c@mail.elegosoft.com> Message-ID: <20080129022541.0m78eettvocc00wo@mail.elegosoft.com> Quoting Jay : > I was stuck on the use of "ln". > I know, it should be easy, just copy stuff..or use Cygwin ln, but it > kept not working and I moved on for now. I can try to fix that. Let me know of anything else that does not work on Windows. > I know it's an easy thing but I was being lazy and there are > alternatives if it languishes long, I can try on Mac, or PPC_LINUX > (which has other problems perhaps that need working out, maybe just > that dynamic linking is broken, I put it in hold for now). You need to set DYLD_LIBRARY_PATH to m3test/PPC_DARWIN for Darwin, as there's a local library which gets used in all tests. Dynamic linking seems to work differently on Darwin from most other Unix systems I know. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Jan 29 11:45:12 2008 From: mika at async.caltech.edu (Mika Nystrom) Date: Tue, 29 Jan 2008 02:45:12 -0800 Subject: [M3devel] nt386gnu threads? In-Reply-To: Your message of "Mon, 28 Jan 2008 16:19:48 GMT." Message-ID: <200801291045.m0TAjCDM062661@camembert.async.caltech.edu> 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 From hosking at cs.purdue.edu Tue Jan 29 14:08:38 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 29 Jan 2008 08:08:38 -0500 Subject: [M3devel] nt386gnu threads? In-Reply-To: <200801291045.m0TAjCDM062661@camembert.async.caltech.edu> References: <200801291045.m0TAjCDM062661@camembert.async.caltech.edu> Message-ID: 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 From jayk123 at hotmail.com Tue Jan 29 20:43:43 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 29 Jan 2008 19:43:43 +0000 Subject: [M3devel] nt386gnu threads? In-Reply-To: References: <200801291045.m0TAjCDM062661@camembert.async.caltech.edu> Message-ID: I wasn't aware of this, but I don't think it is the problem, not having looked at it yet. Building in m3cc is very independent of cm3 one it gets going. So maybe this is just slow upon slow, sleep upon Cygwin.I should run some numbers with all my whining. Has anyone else built either NT386GNU or NT386MINGNU? MINGNU should be fairly easy to build now and work, for non-gui. GNU fairly easy to build but doesn't work. Possibly I broke it over the weekend, didn't test as much as previously. - 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> _________________________________________________________________ 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 Thu Jan 31 01:34:25 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 31 Jan 2008 01:34:25 +0100 Subject: [M3devel] quake extensions for tests / RFC Message-ID: <20080131013425.f1wph3ypkwc8wkw8@mail.elegosoft.com> Hi, I've added a utilities library package from the DCVS project and a whole bunch of quake builtin functions based on it. As I've often found that just the functions I'd need to express something in quake without using platform dependent means (exec cmd) are not available, I've now decided to add some. Most of them are string and file system related. There are standard text and text array functions, and functions that deal with files, directories, and their content. A third group are three new exec calls: one to execute a command list with the usual redirection options known from shell; one to pipe the contents of a quake variable to an external program, and one to capture the contents of an external program in a quake variable (shell's process or command substitution). I think they will be rather useful. I've also added some standard functions that were always missing in quake: a generic len() function (length of text, array, table), embedded quake code evaluation from a string (quake), and string encode and decode (from libm3). There are 80 short quake tests added in m3quake/test/src/m3makefile which can be run by a simple `cm3 -build'. Before I proceed, I'd like to hear comments about the interfaces and functionality, and especially the function names (always the part that takes most of the time in programming ;-). Several things could probably be better named or improved by adding or altering some parameters. Let me know what you think about it before these functions get used in CM3 packages. I'll write up an HTML documentation and add it to the existing quake language description (which is already a bit old and needs an update) on the WWW pages during the next days. Find attached the function overview and tests. Olaf PS: Some things are still missing and may be added during the next weeks, like directory stacks, system information access and pathname functions. -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 -------------- system information ------------------ hostname() --> text command execution ----------------- q_exec( cmd ) --> int # execute with redirections (>, >>,...) q_exec_put( cmd, text ) --> int # execute cmd with stdin from text q_exec_get( cmd ) --> [int, text] # execute cmd and return output text utilities -------------- split( text, seps ) --> text[] sub( text, off, len ) --> text skipl( text ) --> text skipr( text ) --> text compress( text ) --> text squeeze( text ) --> text pos( text, text ) --> int contains( text, text ) --> boolean bool( text ) --> boolean subst_chars( text, a, b ) --> text del_chars( text, a, b ) --> text subst( text, a, b, n ) --> text subst_env( text ) --> text add_prefix( text[], text ) --> text[] add_suffix( text[], text ) --> text[] file system utilities --------------------- pn -> pathname: text dir -> pn ( not yet; really needed? pn_native( pn ) --> text pn_posix( pn ) --> text pn_win( pn ) --> text pn_root( pn ) --> text pn_sep() --> text ) fs_exists( pn ) --> boolean fs_readable( pn ) --> boolean fs_writable( pn ) --> boolean fs_executable( pn ) --> boolean fs_isdir( pn ) --> boolean fs_isfile( pn ) --> boolean fs_lsdirs( pn, baseonly ) --> text[] fs_lsfiles( pn, baseonly ) --> text[] ( fs_canonical_pn( pn ) --> text ) fs_touch( pn ) # update access time of file fs_rm( pn ) # remove file fs_rmdir( pn ) # remove dir fs_rmrec( pn ) # remove dir and everything below fs_mkdir( pn ) # create directories (mkdir -p) fs_cp( pn, pn ) # copy file fs_contents( pn ) --> text # return file contents as text fs_putfile( pn, text ) # (over)write text into file directory stack --------------- ( not yet pushd( dir ) popd() setwd( dir ) getwd() --> text ) -------------- next part -------------- proc test( code, expected ) is write( "quake(", code, ")", CR, "expected: ", expected, CR, "result: ") quake( code ) write( CR ) end proc quote( s ) is return encode( s ) end proc header( id ) is write( CR, "------ " & id & " ------------------------------------------------------------------", CR ) end proc section( name ) is write( CR, CR, "---------------------------------------" & "---------------------------------------", CR ) write( name ) write( CR, "---------------------------------------" & "---------------------------------------", CR, CR ) end oks = [] kos = [] proc summary() is section( "summary" ) nok = len( oks ) nko = len( kos ) write( nok, " tests succeeded:", CR, oks, CR, CR ) write( nko, " tests failed:", CR, kos, CR ) end proc check( id, code, expected ) is header( id ) write( "quake(", quote(code), ")", CR, "expected: ", sub(quote(expected), 0, 68), CR) quake( code ) write( "result: " & sub(quote(res), 0, 68), CR ) if equal( res & "", expected & "") write( "==> OK", CR ) oks += id %return "T" else write( "==> FAILED", CR ) kos += id %return "" end end proc checkExec( id, code ) is header( id ) write( "quake(", code, ") --> " ) quake( code ) if equal( res, 0 ) write( "OK", CR ) oks += id else write( "FAILED", CR ) kos += id end end write( "quake extension tests", CR, CR ) proc findexe( cmd ) is write( "findexe(" & cmd & ")", CR ) local paths = [] if equal( OS_TYPE, "WIN32" ) paths = split( $PATH, ";" ) else paths = split( $PATH, ":" ) end local p = "" foreach p in paths local pn = p & SL & cmd if fs_isfile( pn ) and fs_executable( pn ) return pn end if equal( OS_TYPE, "WIN32" ) local ext = "" foreach ext in [ "exe", "cmd", "bat" ] local pne = pn & "." & ext if fs_isfile( pne ) and fs_executable( pne ) return pne end end end end return "false" end %----------------------------------------------------------------------------- section( "string function tests" ) %tx = "x = 3 write(\"x = \" & x, CR)" %test( tx, "x = 3" ) t = "a = \" \t ha ha\" res = skipl( a )" check( "t001", t, "ha ha" ) t = "a = \" ha\" res = skipl( a )" check( "t002", t, "ha" ) t = "a = \" ha \" res = skipr( a ) & \"x\"" check( "t003", t, " hax" ) t = "a = \" ha \" res = compress( a ) & \"x\"" check( "t004", t, "hax" ) t = "a = \"apple plum orange\" b = split(a, \" \") res = b[0] & b[2]" check( "t005", t, "appleorange" ) t = "a = \"applepie\" res = sub(a, 5, 3)" check( "t006", t, "pie" ) t = "a = \"applepie\" res = sub(a, 7, 3)" check( "t007", t, "e" ) t = "a = \"a\n\n\nb\n\n\n\nc\n\" res = squeeze(a)" check( "t008", t, "a\n\nb\n\nc\n" ) t = "a = \"applepie\" res = tcontains(a, \"pie\")" check( "t009", t, "TRUE" ) t = "a = \"applepie\" res = tcontains(a, \"pies\")" check( "t010", t, "" ) t = "a = \"applepie\" res = pos(a, \"pie\")" check( "t011", t, 5 ) t = "a = \"applepie\" res = pos(a, \"pies\")" check( "t012", t, "-1" ) t = "a = \"applepie\" n = pos(a, \"pie\") res = sub(a, n, 1)" check( "t013", t, "p" ) t = "res = bool(\"true\")" check( "t014", t, "TRUE") t = "res = bool(\"tRuE\")" check( "t015", t, "TRUE") t = "res = bool(\"TRUE\")" check( "t016", t, "TRUE") t = "res = bool(\"y\")" check( "t017", t, "TRUE") t = "res = bool(\"yes\")" check( "t018", t, "TRUE") t = "res = bool(\"Y\")" check( "t019", t, "TRUE") t = "res = bool(\"YES \")" check( "t020", t, "TRUE") t = "res = bool(\"no\")" check( "t021", t, "") t = "res = bool(\"false\")" check( "t022", t, "") t = "res = bool(\"foo\")" check( "t023", t, "") t = "res = bool(\"0\")" check( "t024", t, "") t = "res = bool(\"1\")" check( "t025", t, "TRUE") t = "a = \"aabaacabbbaccbca\" res = subst_chars(a, \"b\", \"d\")" check( "t026", t, "aadaacadddaccdca") t = "a = \"aabaacabbbaccbca\" res = subst_chars(a, \"bc\", \"dd\")" check( "t027", t, "aadaadadddadddda") t = "a = \"aabaacabbbaccbca\" res = del_chars(a, \"b\")" check( "t028", t, "aaaacaaccca") t = "a = \"aabaacabbbaccbca\" res = del_chars(a, \"bc\")" check( "t029", t, "aaaaaaa") t = "a = \"aabaacabbbaaccbca\" res = subst(a, \"aa\", \" 42 \", 1)" check( "t030", t, " 42 baacabbbaaccbca") t = "a = \"aabaacabbbaaccbca\" res = subst(a, \"aa\", \" 42 \", 2)" check( "t031", t, " 42 b 42 cabbbaaccbca") t = "a = \"aabaacabbbaaccbca\" res = subst(a, \"aa\", \" 42 \", 99)" check( "t032", t, " 42 b 42 cabbb 42 ccbca") t = "a = [ \"a\", \"b\", \"c\" ] res = add_prefix(a, \"pre-\")" check( "t033", t, [ "pre-a", "pre-b", "pre-c" ] ) t = "a = [ \"a\", \"b\", \"c\" ] res = add_suffix(a, \"-suf\")" check( "t034", t, [ "a-suf", "b-suf", "c-suf" ] ) t = "a = \"0123456789\"res = len( a )" check( "t035", t, "10") t = "a = [ \"a\", \"b\", \"c\" ] res = len( a )" check( "t036", t, "3") t = "a = { \"a\" : \"b\", \"c\" : \"d\" } res = len( a )" check( "t037", t, "2") %----------------------------------------------------------------------------- section( "large string tests" ) SP = " " write( "16", SP ) b = "0123456789abcdef" write( "32", SP ) b = b & b write( "64", SP ) b = b & b write( "128", SP ) b = b & b write( "256", SP ) b = b & b write( "512", SP ) b = b & b write( "1k", SP ) b = b & b write( "2k", SP ) b = b & b write( "4k", SP ) b = b & b write( "8k", SP ) b = b & b write( "16k", SP ) b = b & b write( "32k", SP ) b = b & b write( "64k", SP ) b = b & b write( "128k", SP ) b = b & b write( "256k", SP ) b = b & b write( "512k", SP ) b = b & b write( "1m", SP ) b = b & b write( "OK", CR ) t = "a = subst_chars(b, \"bc\", \"xy\") res = subst_chars(b, \"xy\", \"bc\")" check( "t100", t, b) t = "res = sub(del_chars(b, \"0123456789cdef\"), 0, 10)" check( "t101", t, "ababababab") t = "res = len( b )" check( "t102", t, "1048576") %----------------------------------------------------------------------------- section( "file system tests" ) f = "res = fs_exists(\".\")" check( "f001", f, "TRUE" ) f = "res = fs_exists(\"..\")" check( "f002", f, "TRUE" ) f = "res = fs_exists(\"..\" & SL & \"src\")" check( "f003", f, "TRUE" ) f = "res = fs_isdir(\".\")" check( "f004", f, "TRUE" ) f = "res = fs_isdir(\"..\")" check( "f005", f, "TRUE" ) f = "res = fs_isdir(\"..\" & SL & \"src\")" check( "f006", f, "TRUE" ) f = "res = fs_isfile(\".\")" check( "f007", f, "" ) f = "res = fs_isfile(\"..\")" check( "f008", f, "" ) f = "res = fs_isfile(\"..\" & SL & \"src\")" check( "f009", f, "" ) f = "res = fs_isfile(\"..\" & SL & \"src\" & SL & \"m3makefile\")" check( "f010", f, "TRUE" ) f = "res = fs_isdir(\"..\" & SL & \"src\" & SL & \"m3makefile\")" check( "f011", f, "" ) more = findexe( "more" ) f = "res = fs_executable( more )" check( "f012", f, "TRUE" ) f = "res = fs_writable( more )" check( "f013", f, "" ) f = "res = fs_writable(\"..\" & SL & \"src\" & SL & \"m3makefile\")" check( "f014", f, "TRUE" ) %write( pn, CR ) cm3 = findexe( "cm3" ) %write( pn , CR ) orange = "orange" data = "line1\nline2\line3\n" f = "fs_putfile( orange, data ) res = fs_contents( orange )" check( "f015", f, data ) dirs = "a" & SL & "b" dirs_0 = dirs & SL & "c" dirs_1 = dirs & SL & "cc" dirs_2 = dirs & SL & "ccc" dirs_3 = "a" & SL & "bb" fn_a = dirs_0 & SL & "a" fn_b = dirs_0 & SL & "b" fn_c = dirs_0 & SL & "c" write( CR, "--------------------------------------", CR ) write( "dirs = ", dirs, CR ) write( "dirs_0 = ", dirs_0, CR ) write( "dirs_1 = ", dirs_1, CR ) write( "dirs_2 = ", dirs_2, CR ) write( "dirs_3 = ", dirs_3, CR ) write( "fn_a = ", fn_a, CR ) write( "fn_b = ", fn_b, CR ) write( "fn_c = ", fn_c, CR ) f = "fs_mkdir( dirs_0 ) res = fs_isdir( dirs_0 )" check( "f016", f, "TRUE" ) f = "fs_mkdir( dirs_1 ) res = fs_isdir( dirs_1 )" check( "f017", f, "TRUE" ) f = "fs_mkdir( dirs_2 ) res = fs_isdir( dirs_2 )" check( "f018", f, "TRUE" ) f = "fs_mkdir( dirs_3 ) res = fs_isdir( dirs_3 )" check( "f019", f, "TRUE" ) f = "res = fs_lsdirs( dirs, \"\" )" check( "f020", f, [dirs_0, dirs_1, dirs_2] ) f = "res = fs_lsdirs( dirs, \"T\" )" check( "f021", f, "c cc ccc" ) f = "fs_touch( fn_a ) res = fs_isfile( fn_a )" check( "f022", f, "TRUE" ) f = "fs_touch( fn_b ) res = fs_isfile( fn_b )" check( "f023", f, "TRUE" ) f = "fs_touch( fn_c ) res = fs_isfile( fn_c )" check( "f024", f, "TRUE" ) f = "res = fs_lsfiles( dirs_0, \"\" )" check( "f025", f, [fn_a, fn_b, fn_c] ) f = "res = fs_lsfiles( dirs_0, \"T\" )" check( "f026", f, "a b c" ) f = "res = fs_lsfiles( dirs, \"T\" )" check( "f027", f, "" ) f = "fs_rmfile(fn_b) res = fs_lsfiles( dirs_0, \"T\" )" check( "f028", f, "a c" ) f = "fs_rmfile(fn_b) res = fs_lsfiles( dirs_0, \"T\" )" check( "f029", f, "a c" ) f = "fs_rmdir(dirs_3) res = fs_lsdirs( \"a\", \"T\" )" check( "f030", f, "b" ) f = "fs_rmdir(dirs_3) res = fs_lsdirs( \"a\", \"T\" )" check( "f031", f, "b" ) f = "fs_rmrec(dirs) res = fs_lsdirs( \"a\", \"T\" )" check( "f032", f, "" ) f = "fs_touch(dirs) res = fs_lsfiles( \"a\", \"T\" )" check( "f033", f, "b" ) apple = "apple" f = "fs_cp( orange, apple ) res = fs_contents( apple )" check( "f034", f, data ) apple2 = "a" & SL & apple f = "fs_cp( orange, apple2 ) res = fs_contents( apple2 )" check( "f035", f, data ) f = "res = fs_lsfiles( \"a\", \"T\" )" check( "f036", f, "b apple" ) f = "fs_rmfile(apple2) res = fs_lsfiles( \"a\", \"T\" )" check( "f037", f, "b" ) %f = "fs_cp( orange, \"a\" ) res = fs_contents( apple2 )" %check( "f038", f, data ) f = "fs_rmrec(\"a\") res = fs_lsdirs( \".\", \"T\" )" check( "f099", f, "" ) %----------------------------------------------------------------------------- section( "exec tests" ) header( "e001" ) res = q_exec_get( "ls -l" ) write( "rc = ", res[0], CR, "out = ", res[1], CR ) checkExec( "e002", "res = q_exec( \"cm3 -version > cm3.version\" )" ) checkExec( "e003", "res = q_exec( \"rm cm3.version\" )" ) header( "e004" ) a = "a\nb\n\c" res = q_exec_put( "cat -", a ) write( CR, "tests done", CR ) summary() -------------- next part -------------- --- building in FreeBSD4 --- quake extension tests ------------------------------------------------------------------------------ string function tests ------------------------------------------------------------------------------ ------ t001 ------------------------------------------------------------------ quake("a = \" \t ha ha\" res = skipl( a )") expected: "ha ha" result: "ha ha" ==> OK ------ t002 ------------------------------------------------------------------ quake("a = \" ha\" res = skipl( a )") expected: "ha" result: "ha" ==> OK ------ t003 ------------------------------------------------------------------ quake("a = \" ha \" res = skipr( a ) & \"x\"") expected: " hax" result: " hax" ==> OK ------ t004 ------------------------------------------------------------------ quake("a = \" ha \" res = compress( a ) & \"x\"") expected: "hax" result: "hax" ==> OK ------ t005 ------------------------------------------------------------------ quake("a = \"apple plum orange\" b = split(a, \" \") res = b[0] & b[2]") expected: "appleorange" result: "appleorange" ==> OK ------ t006 ------------------------------------------------------------------ quake("a = \"applepie\" res = sub(a, 5, 3)") expected: "pie" result: "pie" ==> OK ------ t007 ------------------------------------------------------------------ quake("a = \"applepie\" res = sub(a, 7, 3)") expected: "e" result: "e" ==> OK ------ t008 ------------------------------------------------------------------ quake("a = \"a\n\n\nb\n\n\n\nc\n\" res = squeeze(a)") expected: "a\n\nb\n\nc\n" result: "a\n\nb\n\nc\n" ==> OK ------ t009 ------------------------------------------------------------------ quake("a = \"applepie\" res = tcontains(a, \"pie\")") expected: "TRUE" result: "TRUE" ==> OK ------ t010 ------------------------------------------------------------------ quake("a = \"applepie\" res = tcontains(a, \"pies\")") expected: "" result: "" ==> OK ------ t011 ------------------------------------------------------------------ quake("a = \"applepie\" res = pos(a, \"pie\")") expected: "5" result: "5" ==> OK ------ t012 ------------------------------------------------------------------ quake("a = \"applepie\" res = pos(a, \"pies\")") expected: "-1" result: "-1" ==> OK ------ t013 ------------------------------------------------------------------ quake("a = \"applepie\" n = pos(a, \"pie\") res = sub(a, n, 1)") expected: "p" result: "p" ==> OK ------ t014 ------------------------------------------------------------------ quake("res = bool(\"true\")") expected: "TRUE" result: "TRUE" ==> OK ------ t015 ------------------------------------------------------------------ quake("res = bool(\"tRuE\")") expected: "TRUE" result: "TRUE" ==> OK ------ t016 ------------------------------------------------------------------ quake("res = bool(\"TRUE\")") expected: "TRUE" result: "TRUE" ==> OK ------ t017 ------------------------------------------------------------------ quake("res = bool(\"y\")") expected: "TRUE" result: "TRUE" ==> OK ------ t018 ------------------------------------------------------------------ quake("res = bool(\"yes\")") expected: "TRUE" result: "TRUE" ==> OK ------ t019 ------------------------------------------------------------------ quake("res = bool(\"Y\")") expected: "TRUE" result: "TRUE" ==> OK ------ t020 ------------------------------------------------------------------ quake("res = bool(\"YES \")") expected: "TRUE" result: "TRUE" ==> OK ------ t021 ------------------------------------------------------------------ quake("res = bool(\"no\")") expected: "" result: "" ==> OK ------ t022 ------------------------------------------------------------------ quake("res = bool(\"false\")") expected: "" result: "" ==> OK ------ t023 ------------------------------------------------------------------ quake("res = bool(\"foo\")") expected: "" result: "" ==> OK ------ t024 ------------------------------------------------------------------ quake("res = bool(\"0\")") expected: "" result: "" ==> OK ------ t025 ------------------------------------------------------------------ quake("res = bool(\"1\")") expected: "TRUE" result: "TRUE" ==> OK ------ t026 ------------------------------------------------------------------ quake("a = \"aabaacabbbaccbca\" res = subst_chars(a, \"b\", \"d\")") expected: "aadaacadddaccdca" result: "aadaacadddaccdca" ==> OK ------ t027 ------------------------------------------------------------------ quake("a = \"aabaacabbbaccbca\" res = subst_chars(a, \"bc\", \"dd\")") expected: "aadaadadddadddda" result: "aadaadadddadddda" ==> OK ------ t028 ------------------------------------------------------------------ quake("a = \"aabaacabbbaccbca\" res = del_chars(a, \"b\")") expected: "aaaacaaccca" result: "aaaacaaccca" ==> OK ------ t029 ------------------------------------------------------------------ quake("a = \"aabaacabbbaccbca\" res = del_chars(a, \"bc\")") expected: "aaaaaaa" result: "aaaaaaa" ==> OK ------ t030 ------------------------------------------------------------------ quake("a = \"aabaacabbbaaccbca\" res = subst(a, \"aa\", \" 42 \", 1)") expected: " 42 baacabbbaaccbca" result: " 42 baacabbbaaccbca" ==> OK ------ t031 ------------------------------------------------------------------ quake("a = \"aabaacabbbaaccbca\" res = subst(a, \"aa\", \" 42 \", 2)") expected: " 42 b 42 cabbbaaccbca" result: " 42 b 42 cabbbaaccbca" ==> OK ------ t032 ------------------------------------------------------------------ quake("a = \"aabaacabbbaaccbca\" res = subst(a, \"aa\", \" 42 \", 99)") expected: " 42 b 42 cabbb 42 ccbca" result: " 42 b 42 cabbb 42 ccbca" ==> OK ------ t033 ------------------------------------------------------------------ quake("a = [ \"a\", \"b\", \"c\" ] res = add_prefix(a, \"pre-\")") expected: "pre-a pre-b pre-c" result: "pre-a pre-b pre-c" ==> OK ------ t034 ------------------------------------------------------------------ quake("a = [ \"a\", \"b\", \"c\" ] res = add_suffix(a, \"-suf\")") expected: "a-suf b-suf c-suf" result: "a-suf b-suf c-suf" ==> OK ------ t035 ------------------------------------------------------------------ quake("a = \"0123456789\"res = len( a )") expected: "10" result: "10" ==> OK ------ t036 ------------------------------------------------------------------ quake("a = [ \"a\", \"b\", \"c\" ] res = len( a )") expected: "3" result: "3" ==> OK ------ t037 ------------------------------------------------------------------ quake("a = { \"a\" : \"b\", \"c\" : \"d\" } res = len( a )") expected: "2" result: "2" ==> OK ------------------------------------------------------------------------------ large string tests ------------------------------------------------------------------------------ 16 32 64 128 256 512 1k 2k 4k 8k 16k 32k 64k 128k 256k 512k 1m OK ------ t100 ------------------------------------------------------------------ quake("a = subst_chars(b, \"bc\", \"xy\") res = subst_chars(b, \"xy\", \"bc\")") expected: "0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef012 result: "0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef012 ==> OK ------ t101 ------------------------------------------------------------------ quake("res = sub(del_chars(b, \"0123456789cdef\"), 0, 10)") expected: "ababababab" result: "ababababab" ==> OK ------ t102 ------------------------------------------------------------------ quake("res = len( b )") expected: "1048576" result: "1048576" ==> OK ------------------------------------------------------------------------------ file system tests ------------------------------------------------------------------------------ ------ f001 ------------------------------------------------------------------ quake("res = fs_exists(\".\")") expected: "TRUE" result: "TRUE" ==> OK ------ f002 ------------------------------------------------------------------ quake("res = fs_exists(\"..\")") expected: "TRUE" result: "TRUE" ==> OK ------ f003 ------------------------------------------------------------------ quake("res = fs_exists(\"..\" & SL & \"src\")") expected: "TRUE" result: "TRUE" ==> OK ------ f004 ------------------------------------------------------------------ quake("res = fs_isdir(\".\")") expected: "TRUE" result: "TRUE" ==> OK ------ f005 ------------------------------------------------------------------ quake("res = fs_isdir(\"..\")") expected: "TRUE" result: "TRUE" ==> OK ------ f006 ------------------------------------------------------------------ quake("res = fs_isdir(\"..\" & SL & \"src\")") expected: "TRUE" result: "TRUE" ==> OK ------ f007 ------------------------------------------------------------------ quake("res = fs_isfile(\".\")") expected: "" result: "" ==> OK ------ f008 ------------------------------------------------------------------ quake("res = fs_isfile(\"..\")") expected: "" result: "" ==> OK ------ f009 ------------------------------------------------------------------ quake("res = fs_isfile(\"..\" & SL & \"src\")") expected: "" result: "" ==> OK ------ f010 ------------------------------------------------------------------ quake("res = fs_isfile(\"..\" & SL & \"src\" & SL & \"m3makefile\")") expected: "TRUE" result: "TRUE" ==> OK ------ f011 ------------------------------------------------------------------ quake("res = fs_isdir(\"..\" & SL & \"src\" & SL & \"m3makefile\")") expected: "" result: "" ==> OK findexe(more) ------ f012 ------------------------------------------------------------------ quake("res = fs_executable( more )") expected: "TRUE" result: "TRUE" ==> OK ------ f013 ------------------------------------------------------------------ quake("res = fs_writable( more )") expected: "" result: "" ==> OK ------ f014 ------------------------------------------------------------------ quake("res = fs_writable(\"..\" & SL & \"src\" & SL & \"m3makefile\")") expected: "TRUE" result: "TRUE" ==> OK findexe(cm3) ------ f015 ------------------------------------------------------------------ quake("fs_putfile( orange, data ) res = fs_contents( orange )") expected: "line1\nline2line3\n" result: "line1\nline2line3\n" ==> OK -------------------------------------- dirs = a/b dirs_0 = a/b/c dirs_1 = a/b/cc dirs_2 = a/b/ccc dirs_3 = a/bb fn_a = a/b/c/a fn_b = a/b/c/b fn_c = a/b/c/c ------ f016 ------------------------------------------------------------------ quake("fs_mkdir( dirs_0 ) res = fs_isdir( dirs_0 )") expected: "TRUE" result: "TRUE" ==> OK ------ f017 ------------------------------------------------------------------ quake("fs_mkdir( dirs_1 ) res = fs_isdir( dirs_1 )") expected: "TRUE" result: "TRUE" ==> OK ------ f018 ------------------------------------------------------------------ quake("fs_mkdir( dirs_2 ) res = fs_isdir( dirs_2 )") expected: "TRUE" result: "TRUE" ==> OK ------ f019 ------------------------------------------------------------------ quake("fs_mkdir( dirs_3 ) res = fs_isdir( dirs_3 )") expected: "TRUE" result: "TRUE" ==> OK ------ f020 ------------------------------------------------------------------ quake("res = fs_lsdirs( dirs, \"\" )") expected: "a/b/c a/b/cc a/b/ccc" result: "a/b/c a/b/cc a/b/ccc" ==> OK ------ f021 ------------------------------------------------------------------ quake("res = fs_lsdirs( dirs, \"T\" )") expected: "c cc ccc" result: "c cc ccc" ==> OK ------ f022 ------------------------------------------------------------------ quake("fs_touch( fn_a ) res = fs_isfile( fn_a )") expected: "TRUE" result: "TRUE" ==> OK ------ f023 ------------------------------------------------------------------ quake("fs_touch( fn_b ) res = fs_isfile( fn_b )") expected: "TRUE" result: "TRUE" ==> OK ------ f024 ------------------------------------------------------------------ quake("fs_touch( fn_c ) res = fs_isfile( fn_c )") expected: "TRUE" result: "TRUE" ==> OK ------ f025 ------------------------------------------------------------------ quake("res = fs_lsfiles( dirs_0, \"\" )") expected: "a/b/c/a a/b/c/b a/b/c/c" result: "a/b/c/a a/b/c/b a/b/c/c" ==> OK ------ f026 ------------------------------------------------------------------ quake("res = fs_lsfiles( dirs_0, \"T\" )") expected: "a b c" result: "a b c" ==> OK ------ f027 ------------------------------------------------------------------ quake("res = fs_lsfiles( dirs, \"T\" )") expected: "" result: "" ==> OK ------ f028 ------------------------------------------------------------------ quake("fs_rmfile(fn_b) res = fs_lsfiles( dirs_0, \"T\" )") expected: "a c" result: "a c" ==> OK ------ f029 ------------------------------------------------------------------ quake("fs_rmfile(fn_b) res = fs_lsfiles( dirs_0, \"T\" )") expected: "a c" result: "a c" ==> OK ------ f030 ------------------------------------------------------------------ quake("fs_rmdir(dirs_3) res = fs_lsdirs( \"a\", \"T\" )") expected: "b" result: "b" ==> OK ------ f031 ------------------------------------------------------------------ quake("fs_rmdir(dirs_3) res = fs_lsdirs( \"a\", \"T\" )") expected: "b" result: "b" ==> OK ------ f032 ------------------------------------------------------------------ quake("fs_rmrec(dirs) res = fs_lsdirs( \"a\", \"T\" )") expected: "" result: "" ==> OK ------ f033 ------------------------------------------------------------------ quake("fs_touch(dirs) res = fs_lsfiles( \"a\", \"T\" )") expected: "b" result: "b" ==> OK ------ f034 ------------------------------------------------------------------ quake("fs_cp( orange, apple ) res = fs_contents( apple )") expected: "line1\nline2line3\n" result: "line1\nline2line3\n" ==> OK ------ f035 ------------------------------------------------------------------ quake("fs_cp( orange, apple2 ) res = fs_contents( apple2 )") expected: "line1\nline2line3\n" result: "line1\nline2line3\n" ==> OK ------ f036 ------------------------------------------------------------------ quake("res = fs_lsfiles( \"a\", \"T\" )") expected: "b apple" result: "b apple" ==> OK ------ f037 ------------------------------------------------------------------ quake("fs_rmfile(apple2) res = fs_lsfiles( \"a\", \"T\" )") expected: "b" result: "b" ==> OK ------ f099 ------------------------------------------------------------------ quake("fs_rmrec(\"a\") res = fs_lsdirs( \".\", \"T\" )") expected: "" result: "" ==> OK ------------------------------------------------------------------------------ exec tests ------------------------------------------------------------------------------ ------ e001 ------------------------------------------------------------------ rc = 0 out = total 8 -rw-rw-r-- 1 wagner wheel 17 31 Jan 00:59 apple -rw-rw-r-- 1 wagner wheel 17 29 Jan 18:43 ls-1 -rw-rw-r-- 1 wagner wheel 97 31 Jan 00:59 m3make.args -rw-rw-r-- 1 wagner wheel 17 31 Jan 00:59 orange ------ e002 ------------------------------------------------------------------ quake(res = q_exec( "cm3 -version > cm3.version" )) --> OK ------ e003 ------------------------------------------------------------------ quake(res = q_exec( "rm cm3.version" )) --> OK ------ e004 ------------------------------------------------------------------ a b c tests done ------------------------------------------------------------------------------ summary ------------------------------------------------------------------------------ 80 tests succeeded: t001 t002 t003 t004 t005 t006 t007 t008 t009 t010 t011 t012 t013 t014 t015 t016 t017 t018 t019 t020 t021 t022 t023 t024 t025 t026 t027 t028 t029 t030 t031 t032 t033 t034 t035 t036 t037 t100 t101 t102 f001 f002 f003 f004 f005 f006 f007 f008 f009 f010 f011 f012 f013 f014 f015 f016 f017 f018 f019 f020 f021 f022 f023 f024 f025 f026 f027 f028 f029 f030 f031 f032 f033 f034 f035 f036 f037 f099 e002 e003 0 tests failed: From wagner at elegosoft.com Thu Jan 31 12:43:04 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 31 Jan 2008 12:43:04 +0100 Subject: [M3devel] Looking for CM3 Tinderbox regression test participants, was: Re: M3 concerns In-Reply-To: <20080105143235.ujed2tl3ksogws8k@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> Message-ID: <20080131124304.w0aq9ygt2ckw4okc@mail.elegosoft.com> 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 Thu Jan 31 17:22:23 2008 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Thu, 31 Jan 2008 10:22:23 -0600 Subject: [M3devel] [Fwd: Sanity check request regarding CT arithmetic] Message-ID: <47A1F5BF.3070201@wichita.edu> 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 From hosking at cs.purdue.edu Thu Jan 31 18:29:21 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 31 Jan 2008 12:29:21 -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: <22926B17-1317-4B74-9024-AADFF81ED88A@cs.purdue.edu> I can contribute: see below... 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 I can do OS X 10.4. > o I386_DARWIN I can do OS X 10.4. > o SOLgnu on any Solaris version I can do Solaris 10 T2000. > o SOLsun " I can do Solaris 10 T2000. > o LINUXLIBC6 on RedHat, Fedora, Ubuntu, Suse Linux (have I forgotten > some variants?) I can do these too if noone else wants to take up the cause. > 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 could fire up the one in the corner of my office that is lying dormant if there is need... :-) > > 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 Thu Jan 31 18:44:05 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 31 Jan 2008 12:44:05 -0500 Subject: [M3devel] [Fwd: Sanity check request regarding CT arithmetic] In-Reply-To: <47A1F5BF.3070201@wichita.edu> References: <47A1F5BF.3070201@wichita.edu> Message-ID: <338F5FD0-A818-4792-A583-A17B72EF956D@cs.purdue.edu> 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 > > From wagner at elegosoft.com Thu Jan 31 20:03:17 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 31 Jan 2008 20:03:17 +0100 Subject: [M3devel] Looking for CM3 Tinderbox regression test participants, was: Re: M3 concerns In-Reply-To: <22926B17-1317-4B74-9024-AADFF81ED88A@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> <22926B17-1317-4B74-9024-AADFF81ED88A@cs.purdue.edu> Message-ID: <20080131200317.uwy41vdfkw40o04g@mail.elegosoft.com> Great! Just go ahead and try one target of your choice; I dare say you should have no problem with the setup. (Solaris would be great, as this is a completely different architecture, and our last Sun died some time ago.) If it works OK, we should soon see the results in the tinderbox. We can then add others one by one. As you're the first to respond, you've got the free choice what and how much you will take over; running the tests regularly will cost some resources in form of disk space and cpu, of course. I'd like to set up a reliable network, that's why I want to progress cautiously and observe the effects and impacts. If I can be of any hlep, just let me know; as you've got ssh access already, everything *should* just work... ;-) Thanks in advance, Olaf Quoting Tony Hosking : > I can contribute: see below... > >> o PPC_DARWIN on MacOS X 10.4 or 10.5 > > I can do OS X 10.4. > >> o I386_DARWIN > > I can do OS X 10.4. > >> o SOLgnu on any Solaris version > > I can do Solaris 10 T2000. > >> o SOLsun " > > I can do Solaris 10 T2000. > >> o LINUXLIBC6 on RedHat, Fedora, Ubuntu, Suse Linux (have I forgotten >> some variants?) > > I can do these too if noone else wants to take up the cause. > >> o ALPHA_OSF -- is anybody still using Alphas? > > I could fire up the one in the corner of my office that is lying > dormant if there is need... :-) -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Jan 31 20:23:39 2008 From: jayk123 at hotmail.com (Jay) Date: Thu, 31 Jan 2008 19:23:39 +0000 Subject: [M3devel] Looking for CM3 Tinderbox regression test participants, was: Re: M3 concerns In-Reply-To: <20080131200317.uwy41vdfkw40o04g@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> <22926B17-1317-4B74-9024-AADFF81ED88A@cs.purdue.edu> <20080131200317.uwy41vdfkw40o04g@mail.elegosoft.com> Message-ID: I intendto try first PPC_DARWIN, PPC_LINUX, NT386* but no promises, esp. on regularity, my machines are mostly laptops that sleep a lot, and then maybe other x86 and PPC after that (including maybe try to bring up new ones..another thread..) - Jay > Date: Thu, 31 Jan 2008 20:03:17 +0100> From: wagner at elegosoft.com> To: hosking at cs.purdue.edu> CC: m3devel at elegosoft.com; m3-support at elego.de; tobermueller at elego.de; admins at elego.de> Subject: Re: [M3devel] Looking for CM3 Tinderbox regression test participants, was: Re: M3 concerns> > Great!> > Just go ahead and try one target of your choice; I dare say you should> have no problem with the setup. (Solaris would be great, as this is> a completely different architecture, and our last Sun died some time ago.)> > If it works OK, we should soon see the results in the tinderbox.> We can then add others one by one. As you're the first to respond,> you've got the free choice what and how much you will take over;> running the tests regularly will cost some resources in form of disk> space and cpu, of course. I'd like to set up a reliable network,> that's why I want to progress cautiously and observe the effects and> impacts.> > If I can be of any hlep, just let me know; as you've got ssh access> already, everything *should* just work... ;-)> > Thanks in advance,> > Olaf> > Quoting Tony Hosking :> > > I can contribute: see below...> >> > >> o PPC_DARWIN on MacOS X 10.4 or 10.5> >> > I can do OS X 10.4.> >> >> o I386_DARWIN> >> > I can do OS X 10.4.> >> >> o SOLgnu on any Solaris version> >> > I can do Solaris 10 T2000.> >> >> o SOLsun "> >> > I can do Solaris 10 T2000.> >> >> o LINUXLIBC6 on RedHat, Fedora, Ubuntu, Suse Linux (have I forgotten> >> some variants?)> >> > I can do these too if noone else wants to take up the cause.> >> >> o ALPHA_OSF -- is anybody still using Alphas?> >> > I could fire up the one in the corner of my office that is lying> > dormant if there is need... :-)> -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 Thu Jan 31 20:31:28 2008 From: jayk123 at hotmail.com (Jay) Date: Thu, 31 Jan 2008 19:31:28 +0000 Subject: [M3devel] what platforms/architectures interest people? In-Reply-To: <20080131200317.uwy41vdfkw40o04g@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> <22926B17-1317-4B74-9024-AADFF81ED88A@cs.purdue.edu> <20080131200317.uwy41vdfkw40o04g@mail.elegosoft.com> Message-ID: This is getting way ahead of things, but I was wondering what platforms/architectures interest folks? *_NETBSD (maybe NBSD for short?) *_OPENBSD (OBSD?) *_FREEBSD (FBSD?) MIPS_* SH_* ARM_* (there is some ARM stuff) ALPHA_* IA64_* AMD64_* *_WINCE (mainly ARM, but many possible -- x86, MIPS, PPC, SH) X86_DJGPP ?? SPARC_LINUX ?? SPARC_*BSD ?? Personally I only have PPC, x86, and AMD64 hardware, all laptops, and the rest aren't available in laptops afaik (ok, WINCE devices are small). I'd be willing to try PPC_*BSD, X86_*BSD|SOLARIS, AMD64_LINUX|NT|SOLARIS. Itanium 1 hardware is under $500 on eBay, Itanium 2 under $1000. Far from a laptop but slightly tempting in terms of aggressive porting. At least they run Windows. :) Or is everything pretty dead by now but x86 and AMD64? (other than cell phones, hand helds, game consoles). I was also think expanding the use of the integrated backend would be interesting. - Jay _________________________________________________________________ Shed those extra pounds with MSN and The Biggest Loser! http://biggestloser.msn.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcoleburn at scires.com Thu Jan 31 23:53:30 2008 From: rcoleburn at scires.com (Randy Coleburn) Date: Thu, 31 Jan 2008 17:53:30 -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: <47A20B17.1E75.00D7.1@scires.com> Olaf: I'll take a look at the requirements and see if I can set something up for testing NT386 on Windows XP and perhaps on Windows 2000. Regards, Randy >>> Olaf Wagner 1/31/2008 6:43 AM >>> 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 ( 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 rcoleburn at scires.com Thu Jan 31 23:56:05 2008 From: rcoleburn at scires.com (Randy Coleburn) Date: Thu, 31 Jan 2008 17:56:05 -0500 Subject: [M3devel] what platforms/architectures interest people? 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> <22926B17-1317-4B74-9024-AADFF81ED88A@cs.purdue.edu> <20080131200317.uwy41vdfkw40o04g@mail.elegosoft.com> Message-ID: <47A20BB2.1E75.00D7.1@scires.com> Jay: The platforms I use most for Modula-3 are Windows (NT/2000/XP) and HP-UX. I also may have occasion to use SPARC and Solaris. Of course, the list will change over time. Regards, Randy >>> Jay 1/31/2008 2:31 PM >>> This is getting way ahead of things, but I was wondering what platforms/architectures interest folks? *_NETBSD (maybe NBSD for short?) *_OPENBSD (OBSD?) *_FREEBSD (FBSD?) MIPS_* SH_* ARM_* (there is some ARM stuff) ALPHA_* IA64_* AMD64_* *_WINCE (mainly ARM, but many possible -- x86, MIPS, PPC, SH) X86_DJGPP ?? SPARC_LINUX ?? SPARC_*BSD ?? Personally I only have PPC, x86, and AMD64 hardware, all laptops, and the rest aren't available in laptops afaik (ok, WINCE devices are small). I'd be willing to try PPC_*BSD, X86_*BSD|SOLARIS, AMD64_LINUX|NT|SOLARIS. Itanium 1 hardware is under $500 on eBay, Itanium 2 under $1000. Far from a laptop but slightly tempting in terms of aggressive porting. At least they run Windows. :) Or is everything pretty dead by now but x86 and AMD64? (other than cell phones, hand helds, game consoles). I was also think expanding the use of the integrated backend would be interesting. - Jay 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 Thu Jan 3 11:58:38 2008 From: jayk123 at hotmail.com (Jay) Date: Thu, 03 Jan 2008 10:58:38 -0000 Subject: [M3devel] M3 concerns In-Reply-To: <200801030010.m030AgKN099099@camembert.async.caltech.edu> References: Your message of "Wed, 02 Jan 2008 14:32:02 EST." <477BA060.1E75.00D7.1@scires.com> <200801030010.m030AgKN099099@camembert.async.caltech.edu> Message-ID: This is in reference to me. I have been making pretty small safe tested changes. But yeah I am impatient and impulsive and do commit small bits, usually well tested. I do have more than one copy of the source and at least once recently checked in from the wrong copy. And scripts/python is new and presumably as yet unused so I don't see the harm in churn there. I've been able to build the system many times under Windows for quite a while, since around whenever scripts/win/* was commited. Over a year ago I think. I think self-buildability is a fairly good test already. Please let me know what the errors are. As for your code itself not working, well I can't promise as much and maybe you can't send it, but if you can provide source with problems I might be able to look into it. There was a problem bootstrapping from 5.2.6, since merely things weren't built in the right order, with the int64 work, but I fixed that a while ago. I haven't really touched the gui stuff. And the various gui apps do look very clunky, a bit hard to figure out how to use, and maybe flaky and unreliable. I guess I should try them on other systems. One thing I changed which should be discussed more is the entry code for .dlls. That's what the C/C++ interop question was about. I think where it is "wrong", you will get a link warning, but I didn't check that. It is "only" on the config file, though not sure that's a mitigating factor or not -- how much do people maintain local config files vs. take the checked in one and apply any diffs. The checked in Windows one is now designed to not need any diffs, so then saying people can change it is a bit hypocritical. So I guess I should remove that one line. I use mainly Windows but have Mac PowerPC and /maybe/ can commit to using others, like Linux PowerPC and other x86 systems (Solaris x86 anyone? :), Linux, FreeBSD, NetBSD)..gotta be a laptop though :) and VMware/VirtualPC are ok. (Nothing seems to compare in producitivity to merely older versions of Visual C++ (5.0, 6.0) and aggressive use of find in files, esp. because of the ease of keyboard use. I've been using "TextWrangler" on the Mac and it is ok but not as good, less keyboard accessible, annoying how each find-in-files opens a new window (even though VC can be annoying for lack of new windows there, usually not)..."kate" on Linux was ok, used it a bit, will try a bit more..) - Jay > To: rcoleburn at scires.com > Date: Wed, 2 Jan 2008 16:10:42 -0800 > From: mika at async.caltech.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] M3 concerns > > > I can happily volunteer FreeBSD 4.x and 5.x (i386) systems, Windows > 2000, and, I believe, Digital Unix 4.0 systems to run nightly > (daily?) builds. Unfortunately I am of course a bit short on Time, > which is probably what's lacking the most, anyhow... > > Mika > > "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. > > > >--=__Part103621A2.1__= > >Content-Type: text/plain; charset=US-ASCII > >Content-Transfer-Encoding: quoted-printable > > > >Tony: > >=20 > >I'm thinking that with a little work we could set up an automated set of = > >builds and regression tests that would make available a "scoreboard" via a = > >web interface where everyone could see the results. That way, as problems = > >are uncovered, folks could begin working on them. > >=20 > >For an example of how all this works, take a look at the scoreboard set up = > >for the ACE+TAO+CIAO projects. An overview is at http://www.dre.vanderbilt= > >.edu/Scoreboard/ . They provide instructions for setting up your own = > >daily build and scoreboard at https://svn.dre.vanderbilt.edu/viewvc/autobui= > >ld/trunk/README?revision=3DHEAD . You can see the scoreboard in operation = > >at http://remedy.nl/ . > >=20 > >Regards, > >Randy > > > >>>> Tony Hosking 1/2/2008 1:36 PM >>> > > > >On Jan 2, 2008, at 11:31 AM, Randy Coleburn wrote: > > > >> I've seen quite a number of m3commit and m3devel messages lately. =20 > >> Many of these give the appearance of "thinking out loud" with =20 > >> various commits followed by apparent reversals. In many cases the =20 > >> m3commit log messages are terse and don't give the rationale behind =20 > >> the change. > > > >Yes, I agree. Also, I tend to avoid committing multiple small =20 > >patches and rather defer until I have had a chance to test everything =20 > >and let it stabilize, before checking in as one single commit. So, =20 > >less frequent, coherent commits, are preferable to many smaller, =20 > >incoherent commits. > > > >> For those of us in the M3 community who rely upon the stability of =20 > >> the libraries and core M3 principles, these types of messages cause =20 > >> concern. While I appreciate everyone's efforts to move forward, I =20 > >> don't want to abandon the great care that went into formulating =20 > >> this language. > > > >Indeed. > > > >> Question: As various people make contributions and changes, is =20 > >> there any group of folks who is verifying that the changes don't =20 > >> break existing code or core principles? Another idea would be to =20 > >> have a series of test batteries that have to be passed before =20 > >> changes can be accepted. I know of a number of projects where many =20 > >> people contribute, but the contributions have to be vetted by =20 > >> passing some tests. > > > >I try to verify that all my code doesn't break existing code (though =20 > >I admit GC/thread subsystems can be devilish to completely verify). =20 > >We do need to have some sort of procedures in place for deciding what =20 > >commits make sense and should go into the CVS head. Tentative work =20 > >should always be done to a CVS branch until it can be vetted. > > > >> Without these types of controls, I fear that good forward progress =20 > >> will inevitably be hampered or compromised by changes made by =20 > >> someone who hasn't completely thought out and tested the =20 > >> ramifications of those changes. > > > >Agree! > > > >> For example, I've tried to get cm3 working for me on Windows XP =20 > >> several times. I still can't seem to get the "current" system to =20 > >> build correctly on XP. In the past, I have on occasion gotten the =20 > >> "system" to build, but then some of my programs don't work =20 > >> correctly when rebuilt using the new cm3. Thus, some changes =20 > >> somewhere have "broken" my code, yet all of my code uses the "safe" =20 > >> subset of the language. If I go back to my old reliable cm3 =20 > >> version 4.1 (the last one put out before Critical Mass, Inc. threw =20 > >> in the towel), my code compiles and works, even on Windows XP, even =20 > >> using Trestle, FormsVBT, NetObj, cross-platform pickles (e.g., =20 > >> pickles shared between Windows & Unix boxes), etc.! Much of my =20 > >> code was originally developed under Windows NT, so I think it is a =20 > >> tribute to the original language developers that my code and their =20 > >> compiler work through various OS version upgrades (NT, 2000, XP) =20 > >> and changes to the underlying C/C++ compilers used to build the =20 > >> core components. > > > >I thought we were getting closer to stability in this regard, though =20 > >I am not a heavy Windows user and have never built CM3 on Windows. > > > >> I would appreciate constructive feedback on this topic. > > > >It would be great to have a set of regression tests run on a regular =20 > >basis to ensure that checkins don't break things. What good =20 > >candidates do we have? cm3 itself I suppose. Any others? I can =20 > >probably devise a couple of thread and GC stress tests pretty =20 > >easily. Anyone willing to set up a testing regime? I have machines =20 > >that could be used to test on several supported platforms on a =20 > >nightly basis even. > > > >> > >> Regards, > >> Randy Coleburn > >> > >> > >> Randy C. Coleburn, CISSP > >> Senior Systems Engineer, Communications, Networks, & Electronics =20 > >> Division (CNE) > >> Corporate & Atlanta Information Systems Security Manager (ISSM) > >> Scientific Research Corporation > >> 2300 Windy Ridge Parkway, Suite 400 South, Atlanta, Georgia 30339 > >> voice: (770) 989-9464, email: RColeburn at SciRes.com, fax: (770) =20 > >> 989-9497 > >> > >> Quality Policy: "SRC CNE Division is committed to delivering =20 > >> continually improving research & engineering excellence that meets =20 > >> or exceeds customer requirements." > > > > > > > >--=__Part103621A2.1__= > >Content-Type: text/html; charset=US-ASCII > >Content-Transfer-Encoding: quoted-printable > >Content-Description: HTML > > > > > > >"> > > > > > >
Tony:
> >
 
> >
I'm thinking that with a little work we could set up an automated set = > >of builds and regression tests that would make available a "scoreboard" = > >via a web interface where everyone could see the results.  That way, = > >as problems are uncovered, folks could begin working on them.
> >
 
> >
For an example of how all this works, take a look at the scoreboard = > >set up for the ACE+TAO+CIAO projects.  An overview is at >tp://www.dre.vanderbilt.edu/Scoreboard/">http://www.dre.vanderbilt.edu/Scor= > >eboard/ .  They provide instructions for setting up your own = > >daily build and scoreboard at >wvc/autobuild/trunk/README?revision=3DHEAD">https://svn.dre.vanderbilt.edu/= > >viewvc/autobuild/trunk/README?revision=3DHEAD .  You can see = > >the scoreboard in operation at http://remedy.= > >nl/ .
> >
 
> >
Regards,
> >
Randy
> >

>>> Tony Hosking <hosking at cs.purdue.edu> 1/2/2008 = > >1:36 PM >>>

On Jan 2, 2008, at 11:31 AM, Randy Coleburn = > >wrote:

> I've seen quite a number of m3commit and m3devel = > >messages lately.  
> Many of these give the appearance of = > >"thinking out loud" with 
> various commits followed by = > >apparent reversals.  In many cases the 
> m3commit log = > >messages are terse and don't give the rationale behind 
> the = > >change.

Yes, I agree.  Also, I tend to avoid committing = > >multiple small 
patches and rather defer until I have had a = > >chance to test everything 
and let it stabilize, before checking = > >in as one single commit.   So, 
less frequent, coherent = > >commits, are preferable to many smaller, 
incoherent commits.
<= > >BR>>  For those of us in the M3 community who rely upon the = > >stability of 
> the libraries and core M3 principles, these = > >types of messages cause 
> concern.  While I appreciate = > >everyone's efforts to move forward, I 
> don't want to abandon = > >the great care that went into formulating 
> this language.
= > >
Indeed.

>  Question:  As various people make = > >contributions and changes, is 
> there any group of folks who = > >is verifying that the changes don't 
> break existing code or = > >core principles?  Another idea would be to 
> have a = > >series of test batteries that have to be passed before 
> = > >changes can be accepted.  I know of a number of projects where = > >many 
> people contribute, but the contributions have to be = > >vetted by 
> passing some tests.

I try to verify that = > >all my code doesn't break existing code (though 
I admit = > >GC/thread subsystems can be devilish to completely verify).   = > >
We do need to have some sort of procedures in place for deciding = > >what 
commits make sense and should go into the CVS head.  = > >Tentative work 
should always be done to a CVS branch until it = > >can be vetted.

>  Without these types of controls, I fear = > >that good forward progress 
> will inevitably be hampered or = > >compromised by changes made by 
> someone who hasn't completely= > > thought out and tested the 
> ramifications of those = > >changes.

Agree!

>  For example, I've tried to get = > >cm3 working for me on Windows XP 
> several times.  I = > >still can't seem to get the "current" system to 
> build = > >correctly on XP.  In the past, I have on occasion gotten the  = > >
> "system" to build, but then some of my programs don't work  = > >
> correctly when rebuilt using the new cm3.  Thus, some = > >changes 
> somewhere have "broken" my code, yet all of my code = > >uses the "safe" 
> subset of the language.  If I go back = > >to my old reliable cm3 
> version 4.1 (the last one put out = > >before Critical Mass, Inc. threw 
> in the towel), my code = > >compiles and works, even on Windows XP, even 
> using Trestle, = > >FormsVBT, NetObj, cross-platform pickles (e.g., 
> pickles = > >shared between Windows & Unix boxes), etc.!  Much of my  = > >
> code was originally developed under Windows NT, so I think it is = > >a 
> tribute to the original language developers that my code = > >and their 
> compiler work through various OS version upgrades = > >(NT, 2000, XP) 
> and changes to the underlying C/C++ = > >compilers used to build the 
> core components.

I = > >thought we were getting closer to stability in this regard, though  = > >
I am not a heavy Windows user and have never built CM3 on Windows.
<= > >BR>>  I would appreciate constructive feedback on this topic.
>R>It would be great to have a set of regression tests run on a regular = > >;
basis to ensure that checkins don't break things.  What = > >good 
candidates do we have?  cm3 itself I suppose.  = > >Any others?  I can 
probably devise a couple of thread and = > >GC stress tests pretty 
easily.  Anyone willing to set up a = > >testing regime? I have machines 
that could be used to test on = > >several supported platforms on a 
nightly basis even.

><= > >BR>> Regards,
> Randy Coleburn
>
>
> Randy C. = > >Coleburn, CISSP
> Senior Systems Engineer, Communications, Networks, = > >& Electronics 
> Division (CNE)
> Corporate & = > >Atlanta Information Systems Security Manager (ISSM)
> Scientific = > >Research Corporation
> 2300 Windy Ridge Parkway, Suite 400 South, = > >Atlanta, Georgia 30339
> voice: (770) 989-9464, email: RColeburn at SciR= > >es.com, fax: (770) 
> 989-9497
>
> Quality = > >Policy:  "SRC CNE Division is committed to delivering 
> = > >continually improving research & engineering excellence that meets = > >;
> or exceeds customer requirements."


>L> > > > >--=__Part103621A2.1__=-- _________________________________________________________________ Don't get caught with egg on your face. Play Chicktionary! http://club.live.com/chicktionary.aspx?icid=chick_wlhmtextlink1_dec -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Sat Jan 12 03:47:50 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 12 Jan 2008 02:47:50 -0000 Subject: [M3devel] I need CVS help again In-Reply-To: <20080112012216.k4d438pquc0sw8os@mail.elegosoft.com> References: <478807B4.2080100@wichita.edu> <20080112012216.k4d438pquc0sw8os@mail.elegosoft.com> Message-ID: [tangent as usual :)] I find the CVS usage model "ok", but I would like a choice of another one. I would like to know there is a conflict before it changes any of my files, or AT LEAST the ones with conflicts. And then I want to easily browse the conflicting changes, possibly applying them manually locally, so that CVS can do the merge automatically. In Perforce the way this works is it goes ahead and changes all the files with no merging at all to be done and then you have several choices for the merges and conflicts. You can accept the automatic ones, reviewing them or not before accepting them. For conflicts you can accept theirs or yours or bring up an editor with something like what CVS does, but you can also put it off a bit -- but can't commit (submit) before resolving. A missing or unclear thing though is if you can have it accept automatic merges within a file where possible, and then yours/theirs on the conflicts. Duh I just had a really obvious epiphany finally. I need to try out TortoiseCVS and its nearest competing Mac and Linux analogs. That'll probably make me much more satisified. :) (Reminder to any other folks to try the GUIs if they aren't experts with the command line.) TortoiseSVN has been nice to use for example. - Jay > Date: Sat, 12 Jan 2008 01:22:16 +0100> From: wagner at elegosoft.com> To: m3devel at elegosoft.com> Subject: Re: [M3devel] I need CVS help again> > Quoting "Rodney M. Bates" :> > > I have gotten myself into this jam before, as a result of trying to> > develop/test on more than one local machine with more than one M3> > installation. I have more questions on how to figure out what happened> > and how to fix it.> >> > I did a cvs update when, I guess, I had local uncommitted edits.> > I got messages saying that changes were being merged and there were> > conflicts. For example, I now have local files named:> >> > .#m3-eval.c.1.12> > m3-eval.c> >> > and in CVS/Entries, the line:> >> > /m3-eval.c/1.14/Result of merge...> >> > Have I correctly surmised that this all means> >> > 1) prior to the update, CVS/Entries would have said:> >> > /m3-eval/c/1.12...> >> > meaning 1.12 was the last version cvs knew I had,> >> > 2) But my local m3-eval.c had local changes relative to 1.12,> >> > 3) And .#m3-eval.c.1.12 is a copy of that locally changed> > m3-eval.c, as it was prior to the cvs update,> > Yes, this should be your original file.> > > 4) The latest version cvs has in its repository is 1.14, and> > Yes.> > > 5) My current local m3-eval.c was generated by merging version> > 1.14 from the repository with what is now in .#m3-eval.c.1.12?> > Yes.> You should simply find the comflicts in m3-eval.c by looking for> lines with <<<< and ===== and >>>>.> Often they are easy to edit manually.> > > Is there a simple way to get cvs to diff between its stored> > version 1.12 and my .#m3-eval.1.12?> > You can checkout any version into your workspace and compare locally:> > cvs up -p -r 1.12 m3-eval.c > m3-eval.c.1.12> cvs up -p -r 1.14 m3-eval.c > m3-eval.c.1.14> > diff -u .m3-eval.c.1.12 \#m3-eval.1.12> ...> > HTH,> > Olaf> -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194> _________________________________________________________________ Watch ?Cause Effect,? a show about real people making a real difference. http://im.live.com/Messenger/IM/MTV/?source=text_watchcause -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sun Jan 13 04:10:57 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 13 Jan 2008 03:10:57 -0000 Subject: [M3devel] could someone add __stdcall name mangling to m3cc please? In-Reply-To: References: Your message of "Wed, 09 Jan 2008 17:25:31 PST." <200801100131.m0A1VQYS034516@camembert.async.caltech.edu> <6D467648-44A7-48DC-AB8D-27B3AC19EBB0@cs.purdue.edu> <80BC3E7C-2DA6-4765-9053-A52950700404@cs.purdue.edu> Message-ID: <0FD0008E-575E-4362-8B78-A125EF9FFD07@cs.purdue.edu> Yup. On Jan 12, 2008, at 7:51 PM, Jay wrote: > > current_param_count > > Must this code use globals? > > - Jay > > > From: jayk123 at hotmail.com > To: hosking at cs.purdue.edu > CC: m3devel at elegosoft.com > Subject: RE: [M3devel] could someone add __stdcall name mangling to > m3cc please? > Date: Sun, 13 Jan 2008 00:49:10 +0000 > > I commited something LIKE this, that lets m3core.dll link. > (The below had several errors. Failing to loop, failing to > terminate the list correctly, only getting function pointers or > functions instead of both, for some reason the Windows *.i3 files > use a mix.) > > libm3.dll has a boring pathname format problem, ld doesn't like c: > \foo\../bar.lib and I got sidetracked.. > > It MIGHT not work for SOME functions, a link error -- if taking > __int64 or small structs by value, in a __stdcall function. > I'll see if that comes up as I progress through the system slowly. > > - Jay > > > > CC: m3devel at elegosoft.com > > From: hosking at cs.purdue.edu > > Subject: Re: [M3devel] could someone add __stdcall name mangling > to m3cc please? > > Date: Sat, 12 Jan 2008 19:06:35 -0500 > > To: jayk123 at hotmail.com > > > > It will need to be a little cleaner than that -- I'd rather gather > > the parameters as declared and enter them into the function type. It > > means not ignoring the parameter decls: see m3cg_declare_param check > > for current_param_count==0. To do this it needs to be a little bit > > smarter about managing current_function_decl -- probably a stack. > > > > On Jan 12, 2008, at 2:57 PM, Jay wrote: > > > > > Something like this????? > > > > > > > =================================================================== > > > RCS file: /usr/cvs/cm3/m3-sys/m3cc/gcc/gcc/m3cg/parse.c,v > > > retrieving revision 1.41 > > > diff -r1.41 parse.c > > > 3066a3070 > > > > tree atypes = NULL_TREE); > > > 3091c3095,3102 > > > < TREE_TYPE (p) = build_function_type (return_type, NULL_TREE); > > > --- > > > > /* for NT386 __stdcall, we just need to declare the right number > > > > of parameters > > > > */ > > > > if (--n_params== 0) { > > > > atypes = tree_cons (NULL_TREE, t_word, atypes); > > > > } > > > > > > > > TREE_TYPE (p) = build_function_type (return_type, atypes); > > > > > > haven't even compiled it yet.. > > > > > > - Jay > > > > > > > > > > > > > > > > > > > > > > From: jayk123 at hotmail.com > > > > To: hosking at cs.purdue.edu > > > > Date: Sat, 12 Jan 2008 18:13:27 +0000 > > > > CC: m3devel at elegosoft.com > > > > Subject: Re: [M3devel] could someone add __stdcall name mangling > > > to m3cc please? > > > > > > > > Tony, Sorry, I didn't mean to check those in. Those were wild > > > guesses that I hadn't tested yet.I put it back. Thanks for > catching > > > that. > > > > > > > > - Jay > > > > > > > > > > > > > > > > > CC: m3devel at elegosoft.com> From: hosking at cs.purdue.edu> > > > Subject: Re: [M3devel] could someone add __stdcall name > mangling to > > > m3cc please?> Date: Sat, 12 Jan 2008 10:41:26 -0500> To: > > > jayk123 at hotmail.com> > I'm not sure what you were trying to do > with > > > parse.c by adding a > parameter (nargs*4) to the stdcall > attribute, > > > but that probably > doesn't do anything interesting. The problem > > > appears to be because > on external function decls the parameter > > > decls are currently being > ignored by cm3cg. If I fix parse.c to > > > add the params for those then > it should work properly with the > > > stdcall attribute.> > On Jan 12, 2008, at 8:27 AM, Jay wrote:> > > > > > Thanks, but not quite. The number of parameters times four > needs to > > > > > be appended to the name, in decimal.> > But I'm just getting > > > 0.> > That is, gcc is handling the underlying detail, but you > > > aren't > > giving it enough infomrmation.> > I'll see if I can > bang > > > out those temporary wrappers automatically.. > > (a Quake > > > programming challenge, that I've already invented the hard > > > part > > > of I think -- Quake can't do math..)> >> > - Jay> >> >> > > CC: > > > m3devel at elegosoft.com> > > From: hosking at cs.purdue.edu> > > > > > Subject: Re: [M3devel] could someone add __stdcall name mangling > > > > > to m3cc please?> > > Date: Fri, 11 Jan 2008 13:16:44 -0500> > > > > > To: jayk123 at hotmail.com> > >> > > I just added support for this. > > > Let me know if it seems to work (or> > > not! :-) ).> > >> > >> > > > > > > On Jan 10, 2008, at 7:40 AM, Jay wrote:> > >> > > > Could someone > > > out there (Tony?) familiar with the gcc backend> > > > have it not > > > ignore call_conv and if call_conv is 1, append> > > > an at symbol > > > and the number of bytes of parameters to the function> > > > > name?> > > > > > > (Even for zero, e.g. Sleep at 0, GetFileAttributes at 4).> > > > > > > This would be I guess at least for "imported" functions.> > > >> > > > > > > Not clear about calling function pointers, probably needs> > > > > > > modification.> > > > call_conv 0 is "__cdecl" is push right to > > > left, caller cleans up> > > > call_conv 1 is "__stdcall" is push > > > right to left, callee cleans up> > > > There are various > synonyms.> > > > > > > With no command line switches, __cdecl is the compiler > > > default.> > > > __stdcall is deemed more efficient, and is very > > > widely used.> > > >> > > > Not clear about functions > implemented in > > > Modula-3.> > > > Probably won't occur? Maybe for callbacks? > > > WindowProcs, thread> > > > entry point?> > > >> > > > This could/ > > > should be for NT386GNU only.> > > > The hypothetical other NT > > > targets only have one calling convention> > > > each.> > > >> > > > > > > > I COULD do something sleazy here and generate little adapter> > > > > > > > functions, over in m3-win/import-libs esp.> > > >> > > > I'm still > > > checking out pm3 to see what it does here.> > > > (as in cvs > > > checkout, not "looking at")> > > >> > > > This'll clear up:> > > > >> > > > > > > RTOS.m3:27: undefined reference to `_FatalExit'> > > > > > > RTOS.mo: In function `RTOS__GetMemory':> > > > RTOS.m3:75: > > > undefined reference to `_VirtualAlloc'> > > > RTOS.m3:85: > undefined > > > reference to `_VirtualAlloc'> > > > RTOS.mo: In function > > > `RTOS__InitMemory':> > > > RTOS.m3:96: undefined reference to > > > `_VirtualAlloc'> > > > RTOS.m3:100: undefined reference to > > > `_GetSystemInfo'> > > > RTOS.mo: In function `RTOS__Write':> > > > > > > RTOS.m3:118: undefined reference to `_AllocConsole'> > > > > > > RTOS.m3:119: undefined reference to `_GetStdHandle'> > > > > > > RTOS.m3:122: undefined reference to `_WriteFile'> > > > > > > RTPerfTool.mo: In function `RTPerfTool__Start':> > > > > > > RTPerfTool.m3:19: undefined reference to `_ReadFile'> > > > > > > RTPerfTool.m3:22: undefined reference to `_CloseHandle'> > > > > > > RTPerfTool.mo: In function `RTPerfTool__Close':> > > > > > > RTPerfTool.m3:28: undefined reference to `_CloseHandle'> > > > > > > RTPerfTool.mo: In function `RTPerfTool__Send':> > > > > > > RTPerfTool.m3:34: undefined reference to `_WriteFile'> > > > > > > RTPerfTool.mo: In function `RTPerfTool__PrepHandle':> > > > > > > RTPerfTool.m3:58: undefined reference to `_GetCurrentProcess'> > > > > > > RTPerfTool.m3:59: undefined reference to `_DuplicateHandle'> > > > > > > etc.> > > >> > > > I did think I was past these. I thought I > > > built m3core and libm3> > > > including linking (having even > > > modified cm3.cfg)> > > > COULD be I'm using the wrong .libs, but:> > > > > > >> > > > C:\cygwin\lib\w32api>nm libkernel32.a | findstr > > > CreateFile> > > > 00000000 I __imp__CreateFileW at 28> > > > 00000000 > > > T _CreateFileW at 28> > > > 00000000 I > __imp__CreateFileMappingW at 24> > > > > > > 00000000 T _CreateFileMappingW at 24> > > > 00000000 I > > > __imp__CreateFileMappingA at 24> > > > 00000000 T > > > _CreateFileMappingA at 24> > > > 00000000 I __imp__CreateFileA at 28> > > > > > > > 00000000 T _CreateFileA at 28> > > >> > > > C:\cygwin\lib\w32api>cd > > > \MinGW\lib> > > >> > > > C:\MinGW\lib>nm libkernel32.a | findstr > > > CreateFile> > > > 00000000 I __imp__CreateFileW at 28> > > > 00000000 > > > T _CreateFileW at 28> > > > 00000000 I > __imp__CreateFileMappingW at 24> > > > > > > 00000000 T _CreateFileMappingW at 24> > > > 00000000 I > > > __imp__CreateFileMappingA at 24> > > > 00000000 T > > > _CreateFileMappingA at 24> > > > 00000000 I __imp__CreateFileA at 28> > > > > > > > 00000000 T _CreateFileA at 28> > > >> > > > I think at least THREE > > > calling conventions should be supported --> > > > __cdecl, > > > __stdcall, __fastcall --> > > > but oh well. We can live without > > > __fastcall.> > > > Watcom has another calling convention, > > > "watcall", and they let you> > > > describe calling conventions > > > with #pragmas, neat.> > > >> > > > Thanks,> > > > - Jay> > > >> > > > > > > > Share life as it happens with the new Windows Live. Start > sharing! > > > > > >> >> >> > Make distant family not so distant with Windows > > > Vista? + Windows > > Live?. Start now!> > > > > > _________________________________________________________________ > > > > Watch ?Cause Effect,? a show about real people making a real > > > difference > > > > > > > > > Get the power of Windows + Web with the new Windows Live. Get > it now! > > > > > Watch ?Cause Effect,? a show about real people making a real > difference. Learn more > Watch ?Cause Effect,? a show about real people making a real > difference. Learn more From jayk123 at hotmail.com Wed Jan 16 04:29:40 2008 From: jayk123 at hotmail.com (Jay) Date: Wed, 16 Jan 2008 03:29:40 -0000 Subject: [M3devel] "crazy cross" In-Reply-To: <1DDFAB54-77B6-4593-B309-2C767D4F1FAC@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> <1DDFAB54-77B6-4593-B309-2C767D4F1FAC@cs.purdue.edu> Message-ID: Yeah, but many small bits of string are hard to put together into a useful ball. :) Platitude (I think is the word): Finding the right balance can be difficult, and it is neither one extreme nor the other. I don't like having to search so many different directories and files, I like more stuff readily at hand. And layering so many things together..do-cm3-std calls do-pkg calls syinfo calls cm3 can also be confusing, at least at first, but once known, I guess not, whereas smushed together code can remain confusing to maintain longer term. I'm the odd one out here though. I'd rather the current liberal BSD-ish licenses. I think multithreading would be good. I'm leary of what functionality is in cm3 vs. above. I think more should be in it. I actually like a model where you cd around and run some command it builds from the current directory and on down. But possibly escaping that part of the tree to rebuild dependencies, if they are out of date. Currently we have two choices: cd around to specific packages and run cmd cd to the specific scripts directory and do-pkg a specific list Kind of not not ideal somehow. Maybe all I really want is do-pkg to leave the cm3 command line options -- the local defines -- in its callers environment somehow for cm3 to pickup. So run do-pkg env and then cd around and run cm3. Anyway, much more bugs me than is important and these things are by far not the most important. I'd be happier merely to have quake provide move_file. :) And for it to batch up compilation of C perhaps. But then I get creedy and want to batch up cm3cg runs..back to where I was.. :) So -- dynamic linking is where people draw the line, but not one process running another? That seems dubious. Debugging-wise, there is this issue of "entry points". Where can I easily stop and resume? You are referring to cm3 outputs .ic (I think it is) files and then cm3cg can be run over them, easily, independently, without starting the pipeline all the way back before Modula-3 parsing. The entry points remain in the shipping product/configuration, even though they are "never" taken advantage of there..even if cm3 doesn't run cm3cg, the cost of mapping in a larger executable in a demand-paged environment is neglible, except as it pulls in dependencies on additional .dlls/.sos, though I expect (I will check), cm3cg's dependencies are light and a subset or equal to cm3's, so that's zero. I don't have an answer here, debugging entry points vs. optimized runtime. Debuggability and performance are very often open opposing forces (see the static_link thread :) ) Sometimes you can have the debug path as an option and the perf path by default, but of course, every fork, every if, (every conditional branch, conditional move (x86), predicated instruction (IA64) -- though I guess sometimes the conditions are the same) is another multiplication out of test cases and inevitably reduced coverage. - Jay > CC: m3devel at elegosoft.com> From: hosking at cs.purdue.edu> Subject: Re: [M3devel] "crazy cross"> Date: Tue, 15 Jan 2008 18:51:44 -0500> To: jayk123 at hotmail.com> > > On Jan 15, 2008, at 6:24 PM, Jay wrote:> > >> > I forgot some vaguely related things.> >> > Do people worry about optimizing away creating new processes?> > Perhaps.> > > Could m3cg be built as an .so/.dll? Probably.> > Tricky given gcc's nature.> > But, m3middle could be glued to gcc to build gcc's trees > directly...though I strongly prefer the current arrangement.> > > And ok license-wise?> > Um, no. FSF have been generally opposed to the way the Modula-3 > backend is a thin front-end veneer over gcc, since we get to use > their compiler without infecting M3 with the GPL/LGPL. Of course, it > would probably be preferable to have CM3 under the GPL/LGPL> > > Could m3cg be run once per package instead of once per source?> > Possibly, though right now m3cg does not use the gcc front-end > driver. To be honest, I prefer the separation of concerns between > m3middle and the gcc-based backend. It is much easier for debugging > and development.> > > gcc and cl both can be:> > cl -c foo.c bar.c> > gcc -c foo.c bar.c> > Currently in NT386GNU I depend on -o,> > gcc -c foo.c -o foo.obj> > Would need to handle that, not a big deal.> >> > Also, in the scheme below, either cm3.sh/cm3.cmd would have a > > switch to merely print the "real" cm3's path, or, just as well, > > sysinfo.sh et. al. would know how to find it, save that process.> >> > Furthermore -- multithreaded build?> >> > I believe, maybe absent bootstrapping, that cm3 could read "all" > > the m3makefiles, work out the dependency graph trivially, and build > > things in parallel. Bootstrappinging works too. It builds only what > > you say, in the right order. The Python scripts can implement this > > easily enough.> > I would strongly prefer to see functionality remain decomposed as it > currently is. Tangled balls of string are tough to understand, > maintain, and develop.> > >> > - Jay> >> > ----------------------------------------> >> CC: m3devel at elegosoft.com> >> From: hosking at cs.purdue.edu> >> Subject: Re: [M3devel] "crazy cross"> >> Date: Tue, 15 Jan 2008 08:47:13 -0500> >> To: jayk123 at hotmail.com> >>> >>> >> On Jan 15, 2008, at 2:00 AM, Jay wrote:> >>> >>> It looks like at least cm3 is "always" target-independent.> >>> Whatever target is defined to in cm3.cfg, if it is one of the built> >>> in known ones, cm3 will generate code for. Except maybe NT386,> >>> though it need not be -- cm3 could have both the .obj and "gcc> >>> tree" writing backends both linked into it and dynamically chose> >>> between them.> >>> >> Yes, the cm3 front-end will generate .mo/.io files for any target on> >> any other host. The gcc-based backend runs as a separate process> >> (there are license issues with linking the gcc-based backend directly> >> with the front-end).> >>> >>> Maybe it already does.> >>> cm3 operates at a fairly high level when using gcc, and the target> >>> specific stuff is just some data about the name of setjmp, the> >>> sizeof jmp_buf, etc..> >>>> >>> The "only" "problem" is then m3cg/as/ld/link.> >>> m3cg could be moved to $CM3_INSTALL/pkg/x/HOST/TARGET.> >>> >> True!> >>> >>> cm3, along with everything else, could be $CM3_INSTALL/pkg/x/HOST> >>> leaving $CM3_INSTALL/bin/cm3 that is sh and $CM3_INSTALL/bin/cm3.py> >>> or cm3.cmd that calls out to cm3.> >>> >> Possibly.> >>> >>> "Fixing" as/ld, well, I don't suppose they tend to be target> >>> neutral do they? You'd have to import them like gcc and build them> >>> n times. Gaining a much slower build, much larger tree.> >>> >> Indeed.> >>> >>> I suppose anyone could do this themselves, and change cm3.cfg> >>> appropriately. Doing things "officially" this way for one "big"> >>> distribution, probably folks would not go for.> >>> >> This is how bootstraps to other targets typically go: cm3 *.m3-> >>> *.mo. Copy .mo files to target. Build cm3cg for target. cm3cg> >> *.mo->*.ms as *.ms->*.o ld *.o->libs/execs.> >>> >>> >>>> >>>> >>> - Jay> >>>> >>>> >>>> >>> From: jayk123 at hotmail.com> >>> To: m3devel at elegosoft.com> >>> Subject: "crazy cross"> >>> Date: Sat, 5 Jan 2008 01:22:13 +0000> >>>> >>> You've all heard of "Canadian cross"?> >>>> >>> It is cross-building a cross-compiler.> >>> I'm sitting in Windows. I'm going to build a compiler that is going> >>> to run on Linux that is going to target Solaris.> >>> For one example.> >>>> >>> You've all seen that Apple has switches like so:> >>>> >>> gcc -arch i386 ppc ppc64 x86_64 hello.c> >>> and poof out comes a binary that runs natively on four architectures> >>>> >>> I don't like the "inconvenience" of non cross systems and having to> >>> have all the machines/OSes just to build the binaries.> >>> I realize that you hit the wall if you actually want to test the> >>> results. So cross building only gets so much.> >>> Of course I also don't want to multiply out build times for tools...> >>>> >>> Ok, well what is the possibility of:> >>>> >>> cm3 -target NT386> >>> cm3 -target NT386 -target PPC_DARWIN> >>>> >>> ? In my crazy imagination, you have:> >>>> >>> \cm3\bin\cm3.cmd> >>> %~dp0..\libexec\%processor_architecture%\%TARGET%\cm3.exe %*> >>>> >>> \cm3\bin\cm3> >>> #!/bin/sh> >>> dirname(dirname($0))/libexec/`uname whatever`/$TARGET/cm3 $@> >>>> >>> Thus it becomes POSSIBLE to have an n x m matrix, host x target,> >>> and be able to build> >>> "anything" from one environment.> >>>> >>> Actually the targets could all be merged into one .exe or> >>> be .dll/.sos.> >>> Except the code isn't setup for that.> >>>> >>> Interesting?> >>>> >>> I guess the hard part is the C code and linking?> >>> The Modula-3 stuff is already setup to do most of this?> >>> (partly by virtue of all that header rewriting that I labeled> >>> sleazy)> >>>> >>> - Jay> >>>> >>>> >>>> >>> Share life as it happens with the new Windows Live. Start sharing!> >>>> >>> Share life as it happens with the new Windows Live. Start sharing!> >>> >> > _________________________________________________________________> > Watch ?Cause Effect,? a show about real people making a real > > difference.> > http://im.live.com/Messenger/IM/MTV/?source=text_watchcause> _________________________________________________________________ Watch ?Cause Effect,? a show about real people making a real difference. http://im.live.com/Messenger/IM/MTV/?source=text_watchcause -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Wed Jan 23 03:45:43 2008 From: jayk123 at hotmail.com (Jay) Date: Wed, 23 Jan 2008 02:45:43 -0000 Subject: [M3devel] platform/build_dir is a big tuple? In-Reply-To: <2AB0D273-C3B8-4D46-BCC1-4D032692DCB0@cs.purdue.edu> References: <20080122142922.k73w5es5j4gckso4@mail.elegosoft.com> <2AB0D273-C3B8-4D46-BCC1-4D032692DCB0@cs.purdue.edu> Message-ID: Two of the types are dead and the calling convention doesn't matter. If the function has any parameters, a LOOPHOLE is needed, if it has no pararemeters, as the types are declared, the calling convention has no affect. So fixing the warnings are trivial and will be done momentarily. - Jay From: jayk123 at hotmail.comTo: hosking at cs.purdue.edu; wagner at elegosoft.comCC: m3devel at elegosoft.comSubject: RE: [M3devel] platform/build_dir is a big tuple?Date: Wed, 23 Jan 2008 02:25:39 +0000 > Precisely why I don't like many of the recent changes. I don't want > to build Windows interfaces and gorp for a non-Windows platform. It is *just* types. (I didn't read the code entirely, but it appears so).Other than the three or so types marked WINAPI, which I could see about moving/removing,*types* work fine across architectures.You could produce and consume these types in pure Modula-3 on any platform.That kernel32.dll happens to traffic in them is just coincidence.Except maybe those function pointer types with WINAPI.What's wrong with that?As long as I can fix the warnings I think these should say.Not that there aren't lots of warnings in the build already, but I don't like having any. - Jay > From: hosking at cs.purdue.edu> Date: Tue, 22 Jan 2008 12:54:04 -0500> To: wagner at elegosoft.com> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] platform/build_dir is a big tuple?> > > On Jan 22, 2008, at 8:29 AM, Olaf Wagner wrote:> > > All this may be useful during development, but it is not really> > useful for a software distribution to our users, I think.> >> > Nobody will understand it :-( We need to keep things more simple.> >> > We don't need to support everything out of the box. Instead, we should> > offer some sensible default combinations of everyhing you describe.> >> > First of all: we don't distribute cross compilers (at least until > > now).> > This is a special topic reserved for adding new platforms.> > Precisely why I don't like many of the recent changes. I don't want > to build Windows interfaces and gorp for a non-Windows platform. > Jay, can you *please* back these changes out?> > >> > Runtime and compilers used do not necessarily need to be distinguished> > by target or build dir, in many cases different cm3.cfg may suffice.> >> > Until now, threading models are also no choice that needs to be> > visible at this level. There's one default model for every target,> > and the user can change it by recompiling.> >> > And if we should really agree that changing the target naming scheme> > is a good idea, we should> >> > o use a systematic one with not more than 4 elements (better still,> > 3 (e.g. --))> > o don't use cryptic abbreviations that will confuse most people> >> > Just my 2 cents,> >> > Olaf> >> > Quoting Jay :> >> I'm still torn over that any NT386 target could have a choice of > >> three threading models (win32, pthread, vtalarm), two windowing > >> libraries (ms, x), two (three) compilers (ms, mingwin, cygwin), > >> two (three) linkers (ms, mingwn, cygwin), various runtimes (msvc > >> various versions, cygwin, mingwin (discouraged)) etc.> >>> >> Appending a short string of unreadable bits to BUILD_DIR is very > >> temptingin order to easily generate and test the combinatorial > >> possibilities.> >>> >> backend: 0 integrated, 1 gcc already a setting (with four values)> >>> >> ccompiler/linker: 0 ms, 1 gcc (these could be split, and could > >> allocate more bits...) maybe 00 ms, 01 cygwin, 10 ming maybe > >> define enum up front that allows for watcom, metrowerks, > >> digitalmars, llvm etc.> >> maybe use a decimal digit for all these, and 0 is reserved, maybe.> >>> >> threading: 0 win32, 1 pthreads drop vtalarm, or use two bits?> >>> >> windowing: 0 ms, 1 x> >>> >> cruntime: 0 ms, 1 cyg There is also a ming runtime, discouraged > >> There also really N ms runtimes, ming offers several: > >> msvcrt.dll, msvcr70.dll, msvcr71.dll, msvcr80.dll, > >> msvcr90.dll... but jmpbuf presumbly doesn't change again could > >> allocate multiple bits..> >>> >> cruntime I guess determines oSTYPE Win32 or Posix, thoughit loses > >> its meaning mostly, and X vs. not-X is usually decide the same...> >>> >> The three most common combinations: 00000 -- NT386 11111 -- > >> NT386GNU 11000 -- NT386MINGNU> >>> >> but several others would work 11101 -- cygwin with native > >> windowing 11011 -- cygwin with native threads 11001 -- cygwin > >> with native threads and native windowing> >> BUILD_DIR would be NT386-$(config)as a special case perhaps, the > >> three commoncases could be translated to the above strings.> >>> >> But the underlying implementation would be a few bools/enums,and > >> iterating through them would be easy, while special casingand > >> skipping deemed invalid combinations, like ms runtime and > >> pthreads,and possibly ms runtime and x windows.> >> Really, it might surprise folks, but really, basically every > >> single combination works.> >> Compilers are very independent of headers and libs and headers > >> and libs are very independent of compilers, aside from a few > >> language extensions like __stdcall. You can generally mix > >> runtimes in the same process, just as you can mix them on the > >> same machine, you just need to be careful about what you pass to > >> what. If you call fopen, be sure pass the result back to the > >> matching fclose, malloc/free, etc. Startup code, to the extent > >> that it matters, might be a problem, but really, just avoid C++ > >> globals with constructors/destructors anyway, they are always a > >> problem. Modula-3 has its own startup code, and if you were to > >> write "main" in C and link in Modula-3 static .libs, that > >> probably doesn't work...might actually be better to play into > >> whatever the platform's C++ constructor story is, as problematic > >> as they (probably always?) are -- i.e. unpredictable/hard-to- > >> control ordering.> >>> >> (bad editing...and maybe use hex for compression..)> >>> >> Bringing back cminstall is almost interesting, to promptthe user, > >> or probe their system, though Quake/cm3 can probe at runtime.if > >> os == windows_nt system_cc | findstr version | findstr gcc > >> else system_cc | findstr visual c++else system_cc | grep > >> version | grep gcc else system_cc | grep visual c++end> >>> >> inefficient.> >>> >> anyway, I'll merge current NT386GNU into NT386 and make it > >> chosehow to compile/link which are the main variables today.> >> and then decide about cygwin, but probably do like the above, > >> sinceit'll totally share code with NT386 except the naming > >> conventionsand the removal of the -mno-cygwin switch..> >>> >> I know this seems overly complicated, but it should be > >> exposableeasily enough to users by hiding the choices, presenting > >> three basic ones,and still allow all the obvious and perhaps > >> useful knobs, and iterating throughthe combinations, without > >> creating a combinatorial explosion of source filesor Modula-3 or > >> Quake code.> >> ...Jay> >>> >>> >> From: jayk123 at hotmail.comTo: m3devel at elegosoft.comDate: Tue, 22 > >> Jan 2008 10:48:56 +0000Subject: Re: [M3devel] platform/build_dir > >> is a big tuple?> >>> >>> >> Final answer? I played around with this but just can't accept > >> platforms/build_dirs like: ntx86msmsmscm3msn > >> ntx86gccgcccm3cgmsn ntx86gccgcccm3cgxn ntx86-gggggmn ntx86- > >> ggixn ntx86_mmmimmOk, I have one more name here, and then a bit > >> of a change, or a stronger statement of something I had already > >> said.NT386MINGNUOk, I think we (me!) are confusing host and > >> target, MOSTLY.And cm3 might not have them quite divided > >> appropriately.What is a "host"? What is a "target"?MinGWin and > >> Visual C++ output similar results, targetingthe same runtime > >> (usually), threading library, windowing library.There is a chance > >> for exception handling to diverge however.Well, speaking of > >> Visual C++ the C/C++ compiler and MinGWinthe gcc environment, > >> yes, very different, not interoperable.MinGWin uses what gcc > >> calls "sjlj" -- setjmp/longjmp exceptions.Very inefficient. But > >> heck, gcc doesn't support __try/__except/__finally,only C++ > >> exceptions, and interop of C++ is often not great,what with name > >> mangling and all.NT386GNU's OUTPUT uses a different runtime, > >> unless you trim dependencies, possibly a different threading > >> library, possibly a different windowing library. All this > >> probably configurable. Again exception handling is a sore point > >> in that it is the primary C runtime dependency of Modula-3. If > >> you use Cygwin but say -mno-cygwin, that means you are targeting > >> NT386. (and don't use pthreads or X Windows; behavior of > >> exceptions/setjmp/longjmp TBD -- really, need to not use the - > >> mno-cygwin headers in that case; I'll check).Perhaps m3core.dll > >> should export m3_setjmp/m3_longjmp..Either one can do a cross > >> build to the other.Two cm3.exes, two sets of outputs, that either > >> can produce.NT386 can use gcc or the integrated backend. And the > >> gcc it uses can be MinGWin or Cygwin. (theoretically and probably > >> soon reality) NT386GNU can use either as well! (also currently > >> theory, but a real possibility) It isn't GNU tools, it is GNU > >> runtime.One small area with cm3 might fall down just slightly is > >> that of cross builds where host and target have different > >> naming conventions. -lfoo vs. foo.lib, foo.o vs. foo.obj are an > >> aspect of the host and I vaguely recall that cm3 ties naming > >> convention to ostype. The appending of .exe is a target > >> characteristics, but the others are not really. Naming > >> convention is really a host thing and not a target thing.The > >> config files are a mix of host and target information, mostly > >> actually host, except for the one line that says TARGET. Most of > >> the target variation is in cm3, which always can do any, and > >> cm3cg (which might be nice to be similar, but that's another > >> matter and not likely to ever change, except when AMD64 is the > >> last architecture standing. :) )If Windows had "rpath", then SL > >> would be split between HOST_SL and TARGET_SL.As it stands, SL is > >> HOST_SL.Consider as well the various versions of Visual C++.They > >> output mostly the same, very interoperable.Consider optimization > >> switches. Host or target?Consider version of gcc or Visual C++? > >> Host or target?Well, inevitably, the host has an affect on the > >> target. If not the for the host, the target would not even > >> exist. Bugs in the host produce bugs in the target. etc.(And > >> realize that Cygwin runs on top of an OS built witha Microsoft > >> compiler, so really there is interop, but sometimes through a > >> layer.) So there's a risk of saying there is six+ combinations. > >> (host cygwin, host mingwin, host native) x (target nt386, target > >> nt386gnu) But generally the host is assumed not a factor. I > >> guess "LIBC" could be seperated into several options...You could > >> actually have code that needs one runtime or another, and they > >> couldlink together, depending on what they do.. This is something > >> I don't know if cm3 handles, or anything I have seen. I should be > >> able to build a static .lib, that includes some C code, that > >> imbues its clients with build time dependencies. Well, I guess > >> #pragma comment(linker) is this.So the next tasks are roughly: > >> Merge my NT386 and NT386GNU files. Switching on a variable such > >> as backend mode. Introduce a "new" (old) NT386GNU file, > >> perhaps more like what was already there. Change NT386GNU back > >> to Posix. Build NT386GNU. oh, one more point...while these are > >> two targets from cm3's point of view, they are PROBABLY the same > >> target to cm3cgand so only one is needed. I have to check if > >> configure differentiates between i686-pc-cygwin and i686-pc- > >> mingwin...but I guess it should...It might actually be profitable > >> to have two bloated cm3cg.exe's.And they should ship to \cm3\pkg > >> \m3cc\target\host or host\target and cm3 should know which to > >> run.Blech..four of them when one would suffice?The detail being > >> mainly what the paths to .libs look like, unfortunate.Possibly > >> cm3 can bridge this gap using that "broken" feature that symlinks > >> libs into the target directory,using NTFS hard links, if > >> installroot and root are on the same volume... (or symlinks on > >> Vista).Or maybe convert the paths as appropriate, hacky, but > >> saves an extra cm3cg.exe which is good to avoid. (all the more > >> reason to lump all targets into one file, so that the host x > >> target matrix collapses to just one axis, host; andthen you can > >> write stuff in Perl/Python/Java/C# to collapse that to just one, > >> except for the underlying runtime/interpreter...) Oh, cm3cg isn't > >> the issue. It is always sitting in the correct directory and > >> reads one file and writes one file, no slashes.The issue is gcc > >> as the linker. Again, this is a host issue..and cm3 or the config > >> file definitely should do the translation. - Jay> >>> >>> >> From: jayk123 at hotmail.comTo: m3devel at elegosoft.comDate: Mon, 21 > >> Jan 2008 23:01:44 +0000Subject: [M3devel] platform/build_dir is a > >> big tuple?> >>> >> 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> >> >> >> > -- > > Olaf Wagner -- elego Software Solutions GmbH> > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, > > Germany> > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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". 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 Sun Jan 20 04:42:02 2008 From: mika at async.caltech.edu (Mika Nystrom) Date: Sun, 20 Jan 2008 03:42:02 -0000 Subject: [M3devel] pixmap problem In-Reply-To: Your message of "Sat, 19 Jan 2008 17:54:00 +0100." <235688.77597.qm@web27110.mail.ukl.yahoo.com> Message-ID: <200801200341.m0K3feKM023564@camembert.async.caltech.edu> It works great on NT386GNU, PM3/Klagenfurt, as well, without the build_standalone. Mika "Daniel Alejandro Benavides D." writes: >--0-1095273535-1200761640=:77597 >Content-Type: text/plain; charset=iso-8859-1 >Content-Transfer-Encoding: 8bit > >Hi: >The TestPixmap does show a nice battery on LINUXLIBC6, Ubuntu Gutsy 2.6.22-14-386, 32 bits machine. > >Thanks > > >Jay wrote: .hmmessage P { margin:0px; padding:0px } body.hmmessage { FONT-SIZE: 10pt; FONT-FAMILY:Tahoma } I can repro > the two different behaviors on XP. > I was going to try on PPC_DARWIN but I guess Tony's info suffices. > > I tried rolling hand.c back to before I changed (months/year ago), since it is involved in bit twiddling, no change, phew. > > Debugging here is a big humungous pain. > NT386 has good stacks and line numbers, but no locals or type info, I'd really sometime like to get Codeview info into those .objs...I think it > is documented well enough, but still not necessarily easy, or maybe have a C generating backend partly for this reason (and to bring up more ta >rgets, using native tools), and function calls in disassembly I think don't resolve; NT386GNU can't yet build this, though it will soon, but I'm > not familiar with gdb and there appears to be no type info. I'm building m3gdb right now, I don't know if it will work, I hope it has type info >, and I'm not familiar with the relevant code. In gdb I struggle just to view bytes in memory, add numbers to addresses and see those, etc. I th >ink for MY problem, I'm going to link in C code to dump the structs. There is tracing code and I enabled it, but even it crashes in Text_Length. > At least MY problem crashes, hopefully near the problem, whereas your problem goes all the way through to completion with > no stopping to hint where the problem is. Darn it. :) on the mock rudeness and :( on the lack of a crash. > > You write the bundle out and it matches, so that doesn't rule out bundles as being the problem? (darn) > And bundles look pretty simple, a bundle is just a generated source file with a constant in it. > Maybe newline problems? That wouldn't make sense. I just downloaded some program that might let me separately view the ppm, maybe it'll reveal >something. > > The bad behavior has like regularly spaced solid color veritical bars a few pixels side across the whole picture, and regularly spaced vertical > stripes from the correct picture alternating with that. Perhaps someone with ppm/bitmap/graphics experience has seen this behavior and it resul >ts from some common pixmap mismanagement we could look for? > > I have to say this is very surprising. > > I always wondered, and now I pretty much assume -- Modula-3 never imports/exports data in its dynamic linking, right? It alway imports/exports >functions, right? > On Windows, functions have an optional optimization, but data must be handled differently at compile time if it is going to be dynamically impo >rted. > For functions, if you don't apply the optimization at compile time, the linker will just generate a single instruction thunk instead. > > That is, given a symbol Foo, there is a symbol __imp__Foo that is a pointer to the actual foo in another .dll/.so. > The loader only patches pointers, one per import if you build your .dll correctly, it doesn't patch instructions or code strewn throughout a .d >ll, just one contiguous array of pointers. MAYBE they don't have to be contiguous for each .dl you import from. > > That is, if call msvcrt!fopen, msvcrt!fclose, kernel32!Sleep, my .dll/.exe typically has an array: > > pointer to msvcrt!fopen > pointer to msvcrt!fclose > null > pointer to kernel32!Sleep > > But perhaps kernel32.dll's pointers and msvcrt.dll's pointers need not be adjacent. > > So, going back, my point/question is that, if the compiler knows the function is imported, it can call through __imp__Foo instead of calling Fo >o. > But if it calls Foo and you import Foo, the linker will create the function Foo that just jmps through __imp__Foo. > That doesn't work for data though. There's no ability to intervenve like that. > So for imported data, the compiler must generated a read and dereference of the pointer __imp__Foo for accesses to Foo, if Foo is to be importe >d. > Data imports may be faster when appropriate, but for this reason, I'd say they aren't worth it. > And for this reason, I HOPE Modula-3 never imports/exports data. > > Oh, you could, for data, always reference the pointer __imp_Foo, and if non materializes, create one. > However that would suck perf in order to make an uncommon case work. > I hope Modula-3 doesn't do that either. :) > Though I guess since this global data in question...maybe it is rare??? > > Later, > - Jay > > > >--------------------------------- > > > From: hosking at cs.purdue.edu >> Date: Sat, 19 Jan 2008 03:09:47 -0500 >> To: rcoleburn at scires.com >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] pixmap problem >> >> Looks fine to me on I386_DARWIN. >> >> On Jan 19, 2008, at 12:31 AM, Randy Coleburn wrote: >> >> > >> > > > >--------------------------------- >Need to know the score, the latest news, or you need your Hotmail?-get your "fix" Check it out. > > >--------------------------------- > >Web Revelaci?n Yahoo! 2007: > Premio Favorita del P?blico - ?Vota tu preferida! >--0-1095273535-1200761640=:77597 >Content-Type: text/html; charset=iso-8859-1 >Content-Transfer-Encoding: 8bit > >Hi:
The TestPixmap does show a nice battery on LINUXLIBC6, Ubuntu Gutsy 2.6.22-14-386, 32 bits machine.

Thanks


Jay &l >t;jayk123 at hotmail.com> wrote:
I can repro the two > different behaviors on XP.
I was going to try on PPC_DARWIN but I guess Tony's info suffices.
 
I tried rolling hand.c back to > before I changed (months/year ago), since it is involved in bit twiddling, no change, phew.
 
Debugging here is a big humungous&nb >sp;pain.
NT386 has good stacks and line numbers, but no locals or type info, I'd really sometime like to get Codeview info into those .objs. >..I think it is documented well enough, but still not necessarily easy, or maybe have a C generating backend partly for this > reason (and to bring up more targets, using native tools), and function calls in disassembly I think don't resolve; NT386GNU can't yet bui >ld this, though it will soon, but I'm not familiar with gdb and there appears to be no type info. I'm building m3gdb right now, I don't know if >it will work, I hope it has type info, and I'm not familiar with the relevant code. In gdb I struggle just to view bytes in memory, add numbers >to addresses and see those, etc. I think for MY problem, I'm going to link in C code to dump the structs. There is tracing code and I enabled it >, but even it crashes in Text_Length. At least MY problem crashes, hopefully near the problem, whereas your problem goes all the way through to >completion with no stopping to hint where the problem is. Darn it. :) on the mock rudeness and :( on the lack of a crash.
 
You wri >te the bundle out and it matches, so that doesn't rule out bundles as being the problem? (darn)
And bundles look pretty > simple, a bundle is just a generated source file with a constant in it.
Maybe newline problems? That wouldn't make sense. I just downl >oaded some program that might let me separately view the ppm, maybe it'll reveal something.
 
The bad behavior has like regularly s >paced solid color veritical bars a few pixels side across the whole picture, and regularly spaced vertical stripes from the correct picture alte >rnating with that. Perhaps someone with ppm/bitmap/graphics experience has seen this behavior and it results from some common pixmap mismanageme >nt we could look for?
 
I have to say this is very surprising.
 
I always wondered, and now I pretty much assume -- Mo >dula-3 never imports/exports data in its dynamic linking, right? It alway imports/exports functions, right?
On Windows, functions have an op >tional optimization, but data must be handled differently at compile time if it is going to be dynamically imported.
For > functions, if you don't apply the optimization at compile time, the linker will just generate a single instruction thunk instead.
 
> That is, given a symbol Foo, there is a symbol __imp__Foo that is a pointer to the actual foo in another .dll/.so.
Th >e loader only patches pointers, one per import if you build your .dll correctly, it doesn't patch instructions or code strewn throughout a >.dll, just one contiguous array of pointers. MAYBE they don't have to be contiguous for each .dl you import from.
 
That is, if cal >l msvcrt!fopen, msvcrt!fclose, kernel32!Sleep, my .dll/.exe typically has an array:
 
pointer to msvcrt!fopen
pointer to msvcrt >!fclose
null
pointer to kernel32!Sleep
 
But perhaps kernel32.dll's pointers and msvcrt.dll's pointers need not be adjacent >.
 
So, going back, my point/question is that, if the compiler knows the function is imported, it can call > through __imp__Foo instead of calling Foo.
But if it calls Foo and you import Foo, the linker will create the function Foo that just jmps t >hrough __imp__Foo.
That doesn't work for data though. There's no ability to intervenve like that.
So for imported data, the compiler mus >t generated a read and dereference of the pointer __imp__Foo for accesses to Foo, if Foo is to be imported.
Data import >s may be faster when appropriate, but for this reason, I'd say they aren't worth it.
And for this reason, I HOPE Modula-3 never imports/expo >rts data.
 
Oh, you could, for data, always reference the pointer __imp_Foo, and if non materializes, create one.
However that >would suck perf in order to make an uncommon case work.
I hope Modula-3 doesn't do that either. :)
Though I guess since this global data > in question...maybe it is rare???
 
Later,
 - Jay



> From: > hosking at cs.purdue.edu
> Date: Sat, 19 Jan 2008 03:09:47 -0500
> To: rcoleburn at scires.com
> CC: m3devel at elegosoft.com
> >Subject: Re: [M3devel] pixmap problem
>
> Looks fine to me on I386_DARWIN.
>
> On Jan 19, 2008, at 12:31 AM, Randy Col >eburn wrote:
>
> > <TestPixmap.zip>
>


Need to know the score, the latest news, or you need your Hotm >ail?-get your "fix" Check it out.

> > >


Web Revelaci?n Yahoo! 2007:
Premio Favorita del P?blico - ?Vota tu preferida! >--0-1095273535-1200761640=:77597-- From rcoleburn at scires.com Thu Jan 24 03:51:41 2008 From: rcoleburn at scires.com (Randy Coleburn) Date: Thu, 24 Jan 2008 02:51:41 -0000 Subject: [M3devel] new problem on NT386 In-Reply-To: <20080123232310.5znrlsr5ywwgc4o0@mail.elegosoft.com> References: <4796B970.1E75.00D7.1@scires.com> <4796D0BA.1E75.00D7.1@scires.com> <20080123123937.onc4m6fa4gg8ogg0@mail.elegosoft.com> <479734AB.1E75.00D7.1@scires.com> <20080123193216.4hun5uus8hwksw88@mail.elegosoft.com> <47975558.1E75.00D7.1@scires.com> <20080123221001.8pbvhkjdc8408w80@mail.elegosoft.com> <47976D5F.1E75.00D7.1@scires.com> <20080123232310.5znrlsr5ywwgc4o0@mail.elegosoft.com> Message-ID: <4797B66F.1E75.00D7.1@scires.com> Olaf: Thanks. This is looking very promising now. Regards, Randy >>> Olaf Wagner 1/23/2008 5:23 PM >>> Quoting Randy Coleburn : > Olaf: > > I grabbed the new QMachine via cvs and rebuilt & shipped the m3quake > package, then rebuilt reactor (now cm3_ide) to take advantage of it. I > replaced the exec calls with cm3_exec(). > > At first glance, things were working better in that the output is now > going back to the browser. Great! > > But, when I tried to compile a simple "HelloWorld" program, I ran into > some errors. See attached PDF file. Does any of this make sense to > you? > > Note that this same HelloWorld program was compiling before the > QMachine change, its just that the output went to the wrong window. It seems I've made a mistake by forgetting to initialize the std file handles. Please try again, Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com ( http://www.elegosoft.com/ ) | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Fri Jan 25 05:44:41 2008 From: jayk123 at hotmail.com (Jay) Date: Fri, 25 Jan 2008 04:44:41 -0000 Subject: [M3devel] INSTALL_ROOT and PKG_USE in cm3.cfg In-Reply-To: <479907A8.1E75.00D7.1@scires.com> References: <4798DEB8.1E75.00D7.1@scires.com> <4798EFAE.1E75.00D7.1@scires.com> <4798FE0E.1E75.00D7.1@scires.com> <479907A8.1E75.00D7.1@scires.com> Message-ID: 1) the general user population could revert back to cminstall; nobody else complained except me (a common occurence), and Olaf did improve it; I'd have to deign to putting together such a distribution yuck. Perhaps when a nice GUI installer comes along it won't feel so bad. 2) Again, can you make the stuff you are working on available? To just some people? path() returns the directory of the currently executing Quake code. And in this case, the file is in the directory that contains cm3.exe, so it is cm3.exe's directory, which we know is INSTALLROOT\bin, so go up one with .. and we have INSTALLROOT. It's a little unsightly to have ".." in all the resulting paths, but I think it is worth it. It could be fixed in a number of ways. 1) add a function PathDotDot or PathUp to cm3 2) more generally add a function PathCanonicalize to cm3. Or heck, move more and more of this stuff into cm3. I asked about this recently -- what are the requirements for compatibility with older tools. It is that unanswered, and presuming "the worst", besides my persistant distaste for Modula-3, that keeps me writing Quake code.. - Jay Date: Thu, 24 Jan 2008 21:48:28 -0500From: rcoleburn at scires.comTo: jay123 at hotmail.com; jayk123 at hotmail.comCC: m3devel at elegosoft.comSubject: Re: [M3devel] INSTALL_ROOT and PKG_USE in cm3.cfg Jay: I've already edited my version of cm3.cfg to make it work for me. I don't know what the path() function does. The path() function is only used in the following code: if not defined("INSTALL_ROOT") if not equal ($INSTALLROOT, "") INSTALL_ROOT = $INSTALLROOT else INSTALL_ROOT = (path() & "\\..") endend Since this code is not executed when I define INSTALL_ROOT as "c:\\cm3", there is no need to remove it for my use. I've already confirmed that the other variables I need get set correctly inside CM3-IDE/Reactor once the INSTALL_ROOT is set properly. Note that a bunch of variables inside cm3.cfg depend on INSTALL_ROOT. I'm still want to find a solution for the general user population. Regards, Randy>>> Jay 1/24/2008 9:23 PM >>>Randy, don't worry, whatever you do, I'll be able to recover from. Just try editing your \cm3\bin\cm3.cfg file to say INSTALLROOT="c:\cm3" or whatever.Remove the path() function as a variable.See what happens. Maybe it's the problem, maybe not. It is something that I changed, and is worth trying the old way. Use write() and error() to print the other variables. Can you make the stuff you are working on available? To just some people? - Jay Date: Thu, 24 Jan 2008 21:07:29 -0500From: rcoleburn at scires.comTo: jay123 at hotmail.com; jayk123 at hotmail.comCC: m3devel at elegosoft.comSubject: Re: [M3devel] INSTALL_ROOT and PKG_USE in cm3.cfg Jay: Not sure exactly what you mean by:>I'm not sure what versions of cm3 have path(). I did think I saw it missing the other day. I assume you are not referring to the path env variable. Is this some built-in quake function or a function you have written in quake? The version of cm3.cfg that I am using is the one that *you* put in the minimal binary installation for windows. Reactor does indeed "run" the cm3.cfg in that it uses quake to load and interpret this file. What is the significance of doing the copy you suggest below? >In terms of my workflow, you can go ahead and copy NT386 to the config-no-install directory. I'll survive. I'm not trying to be obtuse here. It's just that you have been working on the windows distribution and all these scripts etc for a while now. I don't want to mess up anything you are doing and I know I don't have a deep understanding of all this, so I am reluctant to change anything like cm3.cfg for my needs. My goal is to make the CM3-IDE (old Reactor) available to everyone. As I said before, it does "run" the cm3.cfg and it needs to use this somehow to come up with a valid "PKG_USE" which should point to the "pkg" folder inside the cm3 installation root. Regards, Randy >>> Jay 1/24/2008 8:33 PM >>>I'm not sure what versions of cm3 have path(). I did think I saw it missing the other day.That could be your problem.m3cgcat also doesn't like my config file, it wants to open it to find TARGET, not sure it uses it at all, but it wants it. When I run mcgcat, I first put back a TARGET line in my cm3.cfg. And then remove it.This is very related.I would suspect that whoever reads the files MIGHT find it acceptable to RUN them.Running them doesn't mean compiling or linking or anything, those are functions that the "host" would chose to call or not. But toplevel can have arbitrary code so maybe this is not great. Reactor is a persistant web server though, right? It should be ok "running" the file, esp. since it doesn't start often. The "normal" alternative that other folks use is to run cminstall, which I find all but useless. In terms of my workflow, you can go ahead and copy NT386 to the config-no-install directory. I'll survive. Randy you should try debugging stuff. Quake is readily debuggabe through printing. if defined("path") write("path is defined") write("path is " & path())else write("path is not defined")enderror("") I put in error so I stop after my printing and don't go and build stuff when my intent was just to run a snippet of Quake. - Jay Date: Thu, 24 Jan 2008 20:06:09 -0500From: rcoleburn at scires.comTo: jay123 at hotmail.com; jayk123 at hotmail.comCC: m3devel at elegosoft.comSubject: RE: [M3devel] INSTALL_ROOT and PKG_USE in cm3.cfg Jay: That's the reason I asked before making a change. I don't want to break or mess up what you are doing. I can get around the problem easily for me. I just remove the comment from the %INSTALL_ROOT="c:\\cm3" and "everything" is ok. I'm hoping we can come up with a way that works for everyone. Once the CM3_IDE (formerly known as Reactor) package is in the repository and part of the standard distribution, it would be best if folks don't have to go around editing cm3.cfg to make it work properly. Now, you are saying your way is more automatic and portable. I like these words. Is there a way we can set something in cm3.cfg that I can key off of for CM3_IDE/Reactor? I don't mind changing the code to accommodate. The big thing for CM3_IDE/Reactor, is that it needs to know where to look for the cm3 installation because it has to find all of the subdirs, like doc, examples, etc. BTW, I still don't see why all this "works" since I am getting "\.." as my INSTALL_ROOT. Regards, Randy>>> Jay 1/24/2008 7:24 PM >>>Blech. My way is more automatic and "portable" in the sense that you can move installations around and they keep working. As well, with my way, you just extract an archive and go, no setup/cminstall, no editing of the cm3.cfg file, just set %PATH% and run vcvars, and vcvars I think I can remove the need for. path() is a builtin Quake function that returns the directory of the currently being run Quake code. But yet Reactor.To unblock yourself, remove my code, add back the commented out, fix the path to match your particular install, don't submit the file. Perhaps move the current checked in file over to the config-no-install directory and then put config's file back in the old style, that requires running cminstall. My workflow will keep working, since it probes for config-no-install first. - Jay Date: Thu, 24 Jan 2008 18:53:48 -0500From: rcoleburn at scires.comTo: jay123 at hotmail.comCC: m3devel at elegosoft.comSubject: [M3devel] INSTALL_ROOT and PKG_USE in cm3.cfg Jay: The cm3.cfg that comes with your minimal binary installation on Windows (NT386) has the following lines: ----------------------------------------- % INSTALL_ROOT = BEGIN_CONFIG% "Where should CM3 be installed?"% 7 %-- user specified install root% END_CONFIG % INSTALL_ROOT = "c:\\cm3" if not defined("INSTALL_ROOT") if not equal ($INSTALLROOT, "") INSTALL_ROOT = $INSTALLROOT else INSTALL_ROOT = (path() & "\\..") endend BIN_INSTALL = INSTALL_ROOT & "\\bin" % executablesLIB_INSTALL = INSTALL_ROOT & "\\lib" % librariesPKG_INSTALL = INSTALL_ROOT & "\\pkg" % packagesDOC_INSTALL = INSTALL_ROOT & "\\doc" % documentsEMACS_INSTALL = INSTALL_ROOT & "\\elisp" % emacs lisp codeMAN_INSTALL = INSTALL_ROOT & "\\man" % man pagesHTML_INSTALL = INSTALL_ROOT & "\\www" % public hypertext %% On some systems (e.g. AFS) you must install public files in a different% place from where you use them. If that is the case for your system,% specify the "use" location here, otherwise leave them alone.%%USE_ROOT = INSTALL_ROOTBIN_USE = BIN_INSTALL % executablesLIB_USE = LIB_INSTALL % librariesPKG_USE = PKG_INSTALL % packages ----------------------------------------- Notice that the lines for INSTALL_ROOT and USE_ROOT are commented out. The Reactor program is coded to grab several variables out of cm3.cfg. For example, build_dir := M3Config.Get ("BUILD_DIR"); system_root := M3Config.Get ("PKG_USE"); doc_root := M3Config.Get ("DOC_INSTALL"); initial_browser := M3Config.Get ("INITIAL_CM3_IDE_BROWSER"); initial_editor := M3Config.Get ("INITIAL_CM3_IDE_EDITOR"); What is happening on my installation is that PKG_USE winds up being "\..\PKG". This is not a valid path and it is causing all sorts of trouble for Reactor. The reason it is getting set this way is that the ELSE branch of the, if not defined("INSTALL_ROOT"), is getting executed resulting in INSTALL_ROOT=\.. I'm not sure why this is coded this way. How do you suggest this should be repaired? Note, I have not checked all of the cm3.cfg variants for the other target platforms, but in order for reactor to work properly, it must be able to find a valid "PKG_USE" in the cm3.cfg. Regards, Randy 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. Play now! 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 rodney.bates at wichita.edu Wed Jan 30 04:15:54 2008 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Wed, 30 Jan 2008 03:15:54 -0000 Subject: [M3devel] Sanity check request regarding CT arithmetic Message-ID: <479FEFA0.5040309@wichita.edu> 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 From jayk123 at hotmail.com Tue Jan 1 22:33:18 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 1 Jan 2008 21:33:18 +0000 Subject: [M3devel] efficient "safe" Modula-3? Message-ID: How can I write this in idiomatic Modula-3: date : Date.T Fmt.FN( (* heap alloc *) "%04s-%02s-%02s %02s:%02s:%02s", ARRAY OF TEXT{ (* heap alloc? easily avoided, but just over the limit *) Fmt.Int(date.year), (* heap alloc *) Fmt.Int(ORD(date.month) + 1), (* heap alloc *) Fmt.Int(date.day), (* heap alloc *) Fmt.Int(date.hour), (* heap alloc *) Fmt.Int(date.minute), (* heap alloc *) Fmt.Int(date.second) (* heap alloc *) }))); to be more like in performance to: Date_t date; /* Win32 SYSTEMTIME essentially */ char Buffer[sizeof("2008-01-01 20:29:58")]; sprintf( Buffer, "%04u-%02u-%02u %02u:%02u:%02u", date.year, ORD(date.month) + 1, date.day, date.hour, date.minute, date.second); or, ok: Date_t date; /* Win32 SYSTEMTIME essentially */ char* Buffer = (char*) malloc(sizeof("2008-01-01 20:29:58")); /* deliberate heap alloc for long lived string */ if (Buffer== NULL) ... sprintf( Buffer, "%04u-%02u-%02u %02u:%02u:%02u", date.year, ORD(date.month) + 1, date.day, date.hour, date.minute, date.second); Unnecessary heap allocations bug me. I seem to see a fair amount of tedious Modula-3 code around to avoid heap allocs,folks manually managing growing arrays instead of using something generic and efficient. Can "safe" code be efficient and convenient to write? (and yes, I know about snprintf, sprintf_s, etc.) - Jay _________________________________________________________________ The best games are on Xbox 360. Click here for a special offer on an Xbox 360 Console. http://www.xbox.com/en-US/hardware/wheretobuy/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Tue Jan 1 21:17:51 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 1 Jan 2008 20:17:51 +0000 Subject: [M3devel] time/date/version functions in Quake? Message-ID: Hi. This is per Olaf. Quake code in m3-sys\cm3\src\version.quake wants/needs the time/date like so: C:\dev2\cm3.2\m3-sys\m3quake>\cm3\bin\cm3.exe -version Critical Mass Modula-3 version d5.5.1 last updated: 2007-12-30 compiled: 2008-01-01 19:59:32 <=== configuration: \cm3\bin\cm3.cfg In UTC (universal coordinated time, also known as "greenwich mean time (GMT)")Currently this is via an application specific global variable in m3quake called "CM3_VERSION_NOW"."Currently", as in, I just did it, it is committed. (I'm impatient and impulsive and love coding, take me or leave me...) C:\dev2\cm3.2\m3-sys\m3quake>findstr /s NOW * src\QMachine.m3: "CM3_VERSION_NOW", It's only used on Windows, because I haven't yet tested elsewhere. Olaf wants to consider something more general, as I understand.Some little extra feature in Quake, new built in function(s)/variable(s) (probably function(s)).Maybe something like Unix date (er, probably less general than that)or strftime, or something. I'm skeptical that resolution to the second is useful here, seems overly precise. Please discuss/decide/spec. :)(I don't care much. I'd be content just to change the variable to a function and decide on a name that isn't ALL CAPS, though those were my own doing in the first place, as well as learning the best idiom for those few lines of code, such as hopefully to avoid the six+ extra heap allocs for the TEXTs before concating them, like something involving a small fixed sized buffer on the stack maybe? :) ) (Not clear how much "safety" a "competent programmer" needs and if it is all worth it...obviously has its place, but...) Oh, and to be a bit obnoxious -- maybe the higher level version.quake should be pushed into Modula-3 code????I mean..something like..some stamp that is applied to all binaries? You know, like on Windows, there are these nice version resources.Putting them in every file automatically would be nice, unless overridden by the use -- typical override wouldbe provision of all Win32 resources, and hopefully that'd include a version resource. I /know/ I am confusing issues -- universal injection of such data, vs. implementation in Quake vs. Modula-3.Any conventions/mechanisms for other platforms?The Mac has/had version resources, but these days that'd probably involve creating 10 more files and directories per executable.I can research it though easily enough.. On Windows it would be an extra dependency, on a resource compiler, but they are ubuiquitous.They come with all commercial toolsets and many free ones. - Jay _________________________________________________________________ Don't get caught with egg on your face. Play Chicktionary! http://club.live.com/chicktionary.aspx?icid=chick_wlhmtextlink1_dec -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Wed Jan 2 11:18:33 2008 From: jayk123 at hotmail.com (Jay) Date: Wed, 2 Jan 2008 10:18:33 +0000 Subject: [M3devel] FW: time/date/version functions in Quake? Message-ID: The one I got from m3devel had most newlines removed such as to be hard to read, AND got /slightly/ truncated (just the signature). Let's try this. I will change the global to datetime() shortly. I was thinking of GetDateTimeStamp() but others probably don't like my verbosity and it is not consistent with the terse lowercasing "Romans". - Jay From: jayk123 at hotmail.comTo: m3devel at elegosoft.comCC: wagner at elegosoft.comSubject: time/date/version functions in Quake?Date: Tue, 1 Jan 2008 20:17:51 +0000 Hi. This is per Olaf. Quake code in m3-sys\cm3\src\version.quake wants/needs the time/date like so: C:\dev2\cm3.2\m3-sys\m3quake>\cm3\bin\cm3.exe -version Critical Mass Modula-3 version d5.5.1 last updated: 2007-12-30 compiled: 2008-01-01 19:59:32 <=== configuration: \cm3\bin\cm3.cfg In UTC (universal coordinated time, also known as "greenwich mean time (GMT)")Currently this is via an application specific global variable in m3quake called "CM3_VERSION_NOW"."Currently", as in, I just did it, it is committed. (I'm impatient and impulsive and love coding, take me or leave me...) C:\dev2\cm3.2\m3-sys\m3quake>findstr /s NOW * src\QMachine.m3: "CM3_VERSION_NOW", It's only used on Windows, because I haven't yet tested elsewhere.Olaf wants to consider something more general, as I understand.Some little extra feature in Quake, new built in function(s)/variable(s) (probably function(s)).Maybe something like Unix date (er, probably less general than that)or strftime, or something.I'm skeptical that resolution to the second is useful here, seems overly precise.Please discuss/decide/spec. :)(I don't care much. I'd be content just to change the variable to a function and decide on a name that isn't ALL CAPS,though those were my own doing in the first place, as well as learning the best idiom for those few lines of code,such as hopefully to avoid the six+ extra heap allocs for the TEXTs before concating them, like something involvinga small fixed sized buffer on the stack maybe? :) ) (Not clear how much "safety" a "competent programmer"needs and if it is all worth it...obviously has its place, but...)Oh, and to be a bit obnoxious -- maybe the higher level version.quake should be pushed into Modula-3 code????I mean..something like..some stamp that is applied to all binaries?You know, like on Windows, there are these nice version resources.Putting them in every file automatically would be nice, unless overridden by the use -- typical override wouldbe provision of all Win32 resources, and hopefully that'd include a version resource. I /know/ I am confusing issues -- universal injection of such data, vs. implementation in Quake vs. Modula-3.Any conventions/mechanisms for other platforms?The Mac has/had version resources, but these days that'd probably involve creating 10 more files and directories per executable.I can research it though easily enough..On Windows it would be an extra dependency, on a resource compiler, but they are ubuiquitous.They come with all commercial toolsets and many free ones. - Jay _________________________________________________________________ The best games are on Xbox 360. Click here for a special offer on an Xbox 360 Console. http://www.xbox.com/en-US/hardware/wheretobuy/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Wed Jan 2 11:22:28 2008 From: jayk123 at hotmail.com (Jay) Date: Wed, 2 Jan 2008 10:22:28 +0000 Subject: [M3devel] FW: "where to root archives?" In-Reply-To: <20071230162432.C498A10D4596@birch.elegosoft.com> References: <20071230162432.C498A10D4596@birch.elegosoft.com> Message-ID: More messed up formating in the first copy I got from m3devel. I'm going to have to send things to myself first, or experiment to see how to avoid newline deletion. I often add spaces to the start/end of lines to avoid this problem. It's sad that mere email doesn't really work... :( I realize wordwrap vs. linejoin vs. leaveonly are hard to decide about... - Jay From: jayk123 at hotmail.comTo: m3devel at elegosoft.comSubject: "where to root archives?"Date: Mon, 31 Dec 2007 11:04:53 +0000 "where to root archives?"Maybe this is along the lines of "how to format my code?"Religous and unanswerable and strong proponents of every answer?but:A) *.zip|*.tar.gz|*.tar.bz2 shall be named cm3.* or B) cm3-.* ok, no question here, B is it.And shall contain the structure: 1) more than one file/directory at the root bin/cm3(.exe) pkg/libm3/...or 2) root contains only one directory, and it has a version in its name (and target probably) cm3-/bin/cm3(.exe) cm3-/pkg/libm3/.. or 3) root contains only one directory, with no version in its name cm3/bin/cm3(.exe) cm3/pkg/libm3/.. #1 is what the current cminstall-using distributions use I believe.Since it is wrapped by an installer, doesn't really matter.Note though that the enclosing archive is also formed this way I think, but with fewer than 10 files.It seems clearly the worst, unless you know about the tar -C or unzip -d switches, though tar -C doesn'tcreate the output directory, unzip -d does.#2 is VERY popular and tempting for me#3 is what the Win32 builds use currently (scripts/win/make-dist.cmd) It has the advantage of being more directly useable. cd \ unzip cm3-.zip and it goes into \cm3, a reasonable default, but could be preexisting (unzip does prompt I think) If it went to cm3-version, you'd probably want to either rename it, or create a link to it, Window having varying support for different types of links on different versions, not sure if use is widespread. fsutil hardlink create creates file hard links on XP+ mklink creates hardlinks and symlinks on Vista+ probably only file hardlinks and file or directory symlinks At some point, directory links were avoided because a) not required by Posix? b) allows creating cycles I see cycles now on my default installs and have crashed stuff as a result. :( junction from www.sysinternals.com creates directory linkes on...Win2000+? (This is all NTFS only of course, or over SMB to other file systems; actually stupid fsutil demands a local file system, even though underlying CreateHardLink works over SMB..) #2 seems safer, and user can immediatley rename to #3 after extraction.Oh, and in the Explorer GUI, the default is to extract in a directory with the same name as the basename of the archive.That makes #1 slightly better and the others slightly worse. Inevitably it seems the command line is doomed to always check before extracting anyway.. unzip -l foo.zip | more tar tfz foo.tar.gz | more Besides that, it still impresses and bugs me how much smaller .tar.bz2 is vs. anything else...but the Explorer support or .zip filesis also somewhat compelling...except that you have to use the command line with CM3 anyway.... - Jay The best games are on Xbox 360. Click here for a special offer on an Xbox 360 Console. Get it now! _________________________________________________________________ i?m is proud to present Cause Effect, a series about real people making a difference. http://im.live.com/Messenger/IM/MTV/?source=text_Cause_Effect -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Wed Jan 2 12:21:48 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 2 Jan 2008 12:21:48 +0100 Subject: [M3devel] cvs question: how to know what I have changed on my machine? In-Reply-To: References: <20071230163328.GB5689@elegosoft.com> Message-ID: <20080102112147.GA12332@elegosoft.com> On Mon, Dec 31, 2007 at 09:48:26AM +0000, Jay wrote: > > I swear I looked for this on the web, several times. :) > What is the right/fast way to see what I have changed in cvs? > Is it really to go to the top of the tree and say cvs diff? > Some source control system I have used, makes "checked in" files > read only, requires you to "check out", and keeps track of what > you checked out. > This model seems quite nice. cvs works recursively from the current directory by default. To check what has changed you use cvs -nq up which simulates an update and lets you know the status of changes. To get more details, you use cvs -q diff -u [files] | less This is of course what I do most of the times. There may be other ways. > There is a fallback if the network is needed and not available. > It is a little annoying, the inevitable failed save, but it is well > worth it. CVS use an optimistic approach wrt. locking, and it works well in practice. Locks or watches can be set if one really wants to, but this needs the cooperation of all users. See `cvs edit' and `cvs watchers' for details. > I've been doing cvs diff but it seem terribly inefficient. > Same question for Subversion, though I haven't looked. > It at least seems to rapidly know what I have changed, on my puny > tree, > and I know it also saves away all the originals, so diff is a client > only operation. In Subversion, diff is a client operation wrt. the base vesion you checked out, because that is held as backup copy in your workspace. This leads to workspaces which occupy twice the amount of space, but is sometimes worth the effort. > Oh another question -- how to view history? In CVS, the history for one file is called log. Use `cvs log file' to view it. To get a complete history of changes, use the cvs2cl utility, which accumulates changes recursively into ChangeLog files. It's what you can see at http://modula3.elegosoft.com/cm3/ChangeLog for the cm3 repository. > Like, what i keep doing is navigating to individual files on the web. > It's fairly tedious. > It'd be nice if checkins at right about the same time, with the same > comment, > where packaged up in the ui, like Perforce (well, for it, it is just > one change).... > I usually look at the diffs after commit, besides before. I'd suggest to do commits at package level (to always have a consistent version checked-in) and look at the diffs before commit. There are some more suggestions in http://modula3.elegosoft.com/cm3/cm3-cm-rules.html Olaf > Thanks, > - Jay > _________________________________________________________________ > > Share life as it happens with the new Windows Live. Share now! -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From lemming at henning-thielemann.de Wed Jan 2 12:20:14 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Wed, 02 Jan 2008 12:20:14 +0100 (CET) Subject: [M3devel] cvs question: how to know what I have changed on my machine? In-Reply-To: References: <20071230163328.GB5689@elegosoft.com> Message-ID: On Mon, 31 Dec 2007, Jay wrote: > I swear I looked for this on the web, several times. :) > What is the right/fast way to see what I have changed in cvs? > Is it really to go to the top of the tree and say cvs diff? Yes, if you want to see the lines which changed. Otherwise 'status' gives more of an overview. I rarely use that, but most oftenly type just 'update' because that marks all modified files with 'M' and added files with 'A'. From wagner at elegosoft.com Wed Jan 2 12:24:51 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 2 Jan 2008 12:24:51 +0100 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: References: <20071230162432.C498A10D4596@birch.elegosoft.com> Message-ID: <20080102112451.GB12332@elegosoft.com> On Mon, Dec 31, 2007 at 10:44:37AM +0000, Jay wrote: > > Olaf, > 1) I PERSONALLY really don't like hidden files. > Most things that people hide aren't worth hiding and might be worth > seeing. > Rename the . file you create? > Besides that, get this.. > I have a low end Western Digital NAS. > It runs Linux but it's very much a "sealed box" "appliance". > The source to the thing is available of course. > It has files that start with dot. > They show as hidden -- and they cannot be unhidden. > This caused me problems trying to copy the source over itself, since > on Windows "hidden" is somewhat "protected", kind of like "read only". > So that just makes me further dislike this notion. > 2) You created the .datenow file outside the output directory on > purpose? > So it doesn't get cleaned as often? No, I just used existing quake code there; I've got no objection to change name and location. The code got copied from DCVS and in turn from CVSup. I just recycled 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 Wed Jan 2 12:28:03 2008 From: jayk123 at hotmail.com (Jay) Date: Wed, 2 Jan 2008 11:28:03 +0000 Subject: [M3devel] cvs question: how to know what I have changed on my machine? In-Reply-To: <20080102112147.GA12332@elegosoft.com> References: <20071230163328.GB5689@elegosoft.com> <20080102112147.GA12332@elegosoft.com> Message-ID: I look before and after, fyi, not just after, and do strive for coherence, within the limits of CVS (I think it's still only one file at a time, rapidly, one right after the other). Thanks for the other tips. cvs diff seems so inefficient. SVN's double diskspace is definitely worthwhile vs. CVS, but the way it should REALLY work is have the files be initially read only on the client, make me "check them out", which would save a copy and save some state locally as to what is checked out. No cooperation with others should be needed here. Perforce does this all correctly.. it seems pretty obvious and simple how to impelement this well. Ok, actually Perforce doesn't save the local copy. But it does know what you checked out, so it only goes to the server for the small number of files. So nobody gets it quite right, that I know, that I have used, yet, really, it seems so obvious and simple and inefficient and convenient...... sorry about the annoying ad, it's not my doing > Date: Wed, 2 Jan 2008 12:21:48 +0100> To: jayk123 at hotmail.com> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] cvs question: how to know what I have changed on my machine?> From: wagner at elegosoft.com> > On Mon, Dec 31, 2007 at 09:48:26AM +0000, Jay wrote:> > > > I swear I looked for this on the web, several times. :)> > What is the right/fast way to see what I have changed in cvs?> > Is it really to go to the top of the tree and say cvs diff?> > Some source control system I have used, makes "checked in" files> > read only, requires you to "check out", and keeps track of what> > you checked out.> > This model seems quite nice.> > cvs works recursively from the current directory by default.> To check what has changed you use> > cvs -nq up> > which simulates an update and lets you know the status of changes.> > To get more details, you use> > cvs -q diff -u [files] | less> > This is of course what I do most of the times. There may be other> ways.> > > There is a fallback if the network is needed and not available.> > It is a little annoying, the inevitable failed save, but it is well> > worth it.> > CVS use an optimistic approach wrt. locking, and it works well in> practice. Locks or watches can be set if one really wants to, but> this needs the cooperation of all users. See `cvs edit' and> `cvs watchers' for details.> > > I've been doing cvs diff but it seem terribly inefficient.> > Same question for Subversion, though I haven't looked.> > It at least seems to rapidly know what I have changed, on my puny> > tree,> > and I know it also saves away all the originals, so diff is a client> > only operation.> > In Subversion, diff is a client operation wrt. the base vesion you> checked out, because that is held as backup copy in your workspace.> This leads to workspaces which occupy twice the amount of space,> but is sometimes worth the effort.> > > Oh another question -- how to view history?> > In CVS, the history for one file is called log. Use `cvs log file' to> view it. To get a complete history of changes, use the cvs2cl> utility, which accumulates changes recursively into ChangeLog files.> It's what you can see at http://modula3.elegosoft.com/cm3/ChangeLog> for the cm3 repository.> > > Like, what i keep doing is navigating to individual files on the web.> > It's fairly tedious.> > It'd be nice if checkins at right about the same time, with the same> > comment,> > where packaged up in the ui, like Perforce (well, for it, it is just> > one change)....> > I usually look at the diffs after commit, besides before.> > I'd suggest to do commits at package level (to always have a> consistent version checked-in) and look at the diffs before commit.> There are some more suggestions in > > http://modula3.elegosoft.com/cm3/cm3-cm-rules.html> > Olaf> > 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 _________________________________________________________________ Share life as it happens with the new Windows Live. http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_122007 -------------- next part -------------- An HTML attachment was scrubbed... URL: From lemming at henning-thielemann.de Wed Jan 2 12:28:18 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Wed, 02 Jan 2008 12:28:18 +0100 (CET) Subject: [M3devel] efficient "safe" Modula-3? In-Reply-To: References: Message-ID: On Tue, 1 Jan 2008, Jay wrote: > How can I write this in idiomatic Modula-3: > date : Date.T Fmt.FN( (* heap alloc *) "%04s-%02s-%02s %02s:%02s:%02s", ARRAY OF TEXT{ (* heap alloc? easily avoided, but just over the limit *) Fmt.Int(date.year), (* heap alloc *) Fmt.Int(ORD(date.month) + 1), (* heap alloc *) Fmt.Int(date.day), (* heap alloc *) Fmt.Int(date.hour), (* heap alloc *) Fmt.Int(date.minute), (* heap alloc *) Fmt.Int(date.second) (* heap alloc *) }))); I think that this solution is the most elegant one can do. It's still not entirely safe, because the number of arguments may not match the number of placeholders in the format string. GCC checks this for printf and friends, but I'm afraid this is restricted to the standard format strings. Even more safe, but maybe less readable and less efficient is Fmt.Int(date.year) & "-" & Fmt.Int(date.month+1) & "-" ... People have even invented dependently typed languages in order to get functions like printf typed in a statically safe manner: http://en.wikipedia.org/wiki/Cayenne_(programming_language) From mika at async.caltech.edu Wed Jan 2 13:47:24 2008 From: mika at async.caltech.edu (Mika Nystrom) Date: Wed, 02 Jan 2008 04:47:24 -0800 Subject: [M3devel] efficient "safe" Modula-3? In-Reply-To: Your message of "Wed, 02 Jan 2008 12:28:18 +0100." Message-ID: <200801021247.m02ClO9D076834@camembert.async.caltech.edu> Well it's hard (i.e., impossible) to do a safe sprintf in Modula-3 that doesn't require heap allocations. Fast idiomatic Modula-3 would involve using procedures to append to an ARRAY OF CHAR, and then passing it a SUBARRAY as you go down the string. If the format string is constant, as it is in most cases, why don't you write a printf compiler? :) Something that can write to a Wr.T, maybe. By the way, from the point of view of performance, the worst piece of the Modula-3 system that I have found is Scan.LongReal. It's horrid! (At least with PM3, but I think CM3 still has problems.) The libraries I have that need to read lots of numbers from disk files use the C routines strtod and strtol for that reason. The performance loss here, in my experience, dwarfs any memory allocator/garbage collector performance issues from the code you attached... Mika Henning Thielemann writes: > >On Tue, 1 Jan 2008, Jay wrote: > >> How can I write this in idiomatic Modula-3: > >> date : Date.T Fmt.FN( (* heap alloc *) "%04s-%02s-%02s %02s:%02s:%02s", ARRAY OF TEXT{ (* heap alloc? easily avoided, but just over t >he limit *) Fmt.Int(date.year), (* heap alloc *) Fmt.Int(ORD(date.month) + 1), (* heap alloc *) Fmt.Int(date.day), (* heap alloc *) Fmt.In >t(date.hour), (* heap alloc *) Fmt.Int(date.minute), (* heap alloc *) Fmt.Int(date.second) (* heap alloc *) }))); > > I think that this solution is the most elegant one can do. It's still not >entirely safe, because the number of arguments may not match the number of >placeholders in the format string. GCC checks this for printf and friends, >but I'm afraid this is restricted to the standard format strings. > Even more safe, but maybe less readable and less efficient is > Fmt.Int(date.year) & "-" & Fmt.Int(date.month+1) & "-" ... > > People have even invented dependently typed languages in order to get >functions like printf typed in a statically safe manner: > http://en.wikipedia.org/wiki/Cayenne_(programming_language) From rcoleburn at scires.com Wed Jan 2 17:31:54 2008 From: rcoleburn at scires.com (Randy Coleburn) Date: Wed, 02 Jan 2008 11:31:54 -0500 Subject: [M3devel] M3 concerns Message-ID: <477B7629.1E75.00D7.1@scires.com> I've seen quite a number of m3commit and m3devel messages lately. Many of these give the appearance of "thinking out loud" with various commits followed by apparent reversals. In many cases the m3commit log messages are terse and don't give the rationale behind the change. For those of us in the M3 community who rely upon the stability of the libraries and core M3 principles, these types of messages cause concern. While I appreciate everyone's efforts to move forward, I don't want to abandon the great care that went into formulating this language. Question: As various people make contributions and changes, is there any group of folks who is verifying that the changes don't break existing code or core principles? Another idea would be to have a series of test batteries that have to be passed before changes can be accepted. I know of a number of projects where many people contribute, but the contributions have to be vetted by passing some tests. Without these types of controls, I fear that good forward progress will inevitably be hampered or compromised by changes made by someone who hasn't completely thought out and tested the ramifications of those changes. For example, I've tried to get cm3 working for me on Windows XP several times. I still can't seem to get the "current" system to build correctly on XP. In the past, I have on occasion gotten the "system" to build, but then some of my programs don't work correctly when rebuilt using the new cm3. Thus, some changes somewhere have "broken" my code, yet all of my code uses the "safe" subset of the language. If I go back to my old reliable cm3 version 4.1 (the last one put out before Critical Mass, Inc. threw in the towel), my code compiles and works, even on Windows XP, even using Trestle, FormsVBT, NetObj, cross-platform pickles (e.g., pickles shared between Windows & Unix boxes), etc.! Much of my code was originally developed under Windows NT, so I think it is a tribute to the original language developers that my code and their compiler work through various OS version upgrades (NT, 2000, XP) and changes to the underlying C/C++ compilers used to build the core components. I would appreciate constructive feedback on this topic. Regards, Randy Coleburn Randy C. Coleburn, CISSP Senior Systems Engineer, Communications, Networks, & Electronics Division (CNE) Corporate & Atlanta Information Systems Security Manager (ISSM) Scientific Research Corporation 2300 Windy Ridge Parkway, Suite 400 South, Atlanta, Georgia 30339 voice: (770) 989-9464, email: RColeburn at SciRes.com, fax: (770) 989-9497 Quality Policy: "SRC CNE Division is committed to delivering continually improving research & engineering excellence that meets or exceeds customer requirements." -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Wed Jan 2 19:36:10 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 2 Jan 2008 13:36:10 -0500 Subject: [M3devel] M3 concerns In-Reply-To: <477B7629.1E75.00D7.1@scires.com> References: <477B7629.1E75.00D7.1@scires.com> Message-ID: On Jan 2, 2008, at 11:31 AM, Randy Coleburn wrote: > I've seen quite a number of m3commit and m3devel messages lately. > Many of these give the appearance of "thinking out loud" with > various commits followed by apparent reversals. In many cases the > m3commit log messages are terse and don't give the rationale behind > the change. Yes, I agree. Also, I tend to avoid committing multiple small patches and rather defer until I have had a chance to test everything and let it stabilize, before checking in as one single commit. So, less frequent, coherent commits, are preferable to many smaller, incoherent commits. > For those of us in the M3 community who rely upon the stability of > the libraries and core M3 principles, these types of messages cause > concern. While I appreciate everyone's efforts to move forward, I > don't want to abandon the great care that went into formulating > this language. Indeed. > Question: As various people make contributions and changes, is > there any group of folks who is verifying that the changes don't > break existing code or core principles? Another idea would be to > have a series of test batteries that have to be passed before > changes can be accepted. I know of a number of projects where many > people contribute, but the contributions have to be vetted by > passing some tests. I try to verify that all my code doesn't break existing code (though I admit GC/thread subsystems can be devilish to completely verify). We do need to have some sort of procedures in place for deciding what commits make sense and should go into the CVS head. Tentative work should always be done to a CVS branch until it can be vetted. > Without these types of controls, I fear that good forward progress > will inevitably be hampered or compromised by changes made by > someone who hasn't completely thought out and tested the > ramifications of those changes. Agree! > For example, I've tried to get cm3 working for me on Windows XP > several times. I still can't seem to get the "current" system to > build correctly on XP. In the past, I have on occasion gotten the > "system" to build, but then some of my programs don't work > correctly when rebuilt using the new cm3. Thus, some changes > somewhere have "broken" my code, yet all of my code uses the "safe" > subset of the language. If I go back to my old reliable cm3 > version 4.1 (the last one put out before Critical Mass, Inc. threw > in the towel), my code compiles and works, even on Windows XP, even > using Trestle, FormsVBT, NetObj, cross-platform pickles (e.g., > pickles shared between Windows & Unix boxes), etc.! Much of my > code was originally developed under Windows NT, so I think it is a > tribute to the original language developers that my code and their > compiler work through various OS version upgrades (NT, 2000, XP) > and changes to the underlying C/C++ compilers used to build the > core components. I thought we were getting closer to stability in this regard, though I am not a heavy Windows user and have never built CM3 on Windows. > I would appreciate constructive feedback on this topic. It would be great to have a set of regression tests run on a regular basis to ensure that checkins don't break things. What good candidates do we have? cm3 itself I suppose. Any others? I can probably devise a couple of thread and GC stress tests pretty easily. Anyone willing to set up a testing regime? I have machines that could be used to test on several supported platforms on a nightly basis even. > > Regards, > Randy Coleburn > > > Randy C. Coleburn, CISSP > Senior Systems Engineer, Communications, Networks, & Electronics > Division (CNE) > Corporate & Atlanta Information Systems Security Manager (ISSM) > Scientific Research Corporation > 2300 Windy Ridge Parkway, Suite 400 South, Atlanta, Georgia 30339 > voice: (770) 989-9464, email: RColeburn at SciRes.com, fax: (770) > 989-9497 > > Quality Policy: "SRC CNE Division is committed to delivering > continually improving research & engineering excellence that meets > or exceeds customer requirements." From rcoleburn at scires.com Wed Jan 2 20:32:02 2008 From: rcoleburn at scires.com (Randy Coleburn) Date: Wed, 02 Jan 2008 14:32:02 -0500 Subject: [M3devel] M3 concerns In-Reply-To: References: <477B7629.1E75.00D7.1@scires.com> Message-ID: <477BA060.1E75.00D7.1@scires.com> Tony: I'm thinking that with a little work we could set up an automated set of builds and regression tests that would make available a "scoreboard" via a web interface where everyone could see the results. That way, as problems are uncovered, folks could begin working on them. For an example of how all this works, take a look at the scoreboard set up for the ACE+TAO+CIAO projects. An overview is at http://www.dre.vanderbilt.edu/Scoreboard/ . They provide instructions for setting up your own daily build and scoreboard at https://svn.dre.vanderbilt.edu/viewvc/autobuild/trunk/README?revision=HEAD . You can see the scoreboard in operation at http://remedy.nl/ . Regards, Randy >>> Tony Hosking 1/2/2008 1:36 PM >>> On Jan 2, 2008, at 11:31 AM, Randy Coleburn wrote: > I've seen quite a number of m3commit and m3devel messages lately. > Many of these give the appearance of "thinking out loud" with > various commits followed by apparent reversals. In many cases the > m3commit log messages are terse and don't give the rationale behind > the change. Yes, I agree. Also, I tend to avoid committing multiple small patches and rather defer until I have had a chance to test everything and let it stabilize, before checking in as one single commit. So, less frequent, coherent commits, are preferable to many smaller, incoherent commits. > For those of us in the M3 community who rely upon the stability of > the libraries and core M3 principles, these types of messages cause > concern. While I appreciate everyone's efforts to move forward, I > don't want to abandon the great care that went into formulating > this language. Indeed. > Question: As various people make contributions and changes, is > there any group of folks who is verifying that the changes don't > break existing code or core principles? Another idea would be to > have a series of test batteries that have to be passed before > changes can be accepted. I know of a number of projects where many > people contribute, but the contributions have to be vetted by > passing some tests. I try to verify that all my code doesn't break existing code (though I admit GC/thread subsystems can be devilish to completely verify). We do need to have some sort of procedures in place for deciding what commits make sense and should go into the CVS head. Tentative work should always be done to a CVS branch until it can be vetted. > Without these types of controls, I fear that good forward progress > will inevitably be hampered or compromised by changes made by > someone who hasn't completely thought out and tested the > ramifications of those changes. Agree! > For example, I've tried to get cm3 working for me on Windows XP > several times. I still can't seem to get the "current" system to > build correctly on XP. In the past, I have on occasion gotten the > "system" to build, but then some of my programs don't work > correctly when rebuilt using the new cm3. Thus, some changes > somewhere have "broken" my code, yet all of my code uses the "safe" > subset of the language. If I go back to my old reliable cm3 > version 4.1 (the last one put out before Critical Mass, Inc. threw > in the towel), my code compiles and works, even on Windows XP, even > using Trestle, FormsVBT, NetObj, cross-platform pickles (e.g., > pickles shared between Windows & Unix boxes), etc.! Much of my > code was originally developed under Windows NT, so I think it is a > tribute to the original language developers that my code and their > compiler work through various OS version upgrades (NT, 2000, XP) > and changes to the underlying C/C++ compilers used to build the > core components. I thought we were getting closer to stability in this regard, though I am not a heavy Windows user and have never built CM3 on Windows. > I would appreciate constructive feedback on this topic. It would be great to have a set of regression tests run on a regular basis to ensure that checkins don't break things. What good candidates do we have? cm3 itself I suppose. Any others? I can probably devise a couple of thread and GC stress tests pretty easily. Anyone willing to set up a testing regime? I have machines that could be used to test on several supported platforms on a nightly basis even. > > Regards, > Randy Coleburn > > > Randy C. Coleburn, CISSP > Senior Systems Engineer, Communications, Networks, & Electronics > Division (CNE) > Corporate & Atlanta Information Systems Security Manager (ISSM) > Scientific Research Corporation > 2300 Windy Ridge Parkway, Suite 400 South, Atlanta, Georgia 30339 > voice: (770) 989-9464, email: RColeburn at SciRes.com, fax: (770) > 989-9497 > > Quality Policy: "SRC CNE Division is committed to delivering > continually improving research & engineering excellence that meets > or exceeds customer requirements." -------------- next part -------------- An HTML attachment was scrubbed... URL: From kschleiser at elego.de Wed Jan 2 21:51:00 2008 From: kschleiser at elego.de (Kaspar Schleiser) Date: Wed, 02 Jan 2008 21:51:00 +0100 Subject: [M3devel] M3 concerns In-Reply-To: <477BA060.1E75.00D7.1@scires.com> References: <477B7629.1E75.00D7.1@scires.com> <477BA060.1E75.00D7.1@scires.com> Message-ID: <477BF934.80805@elego.de> Hey all, Randy Coleburn wrote: > I'm thinking that with a little work we could set up an automated set of builds and regression tests that would make available a "scoreboard" via a web interface where everyone could see the results. That way, as problems are uncovered, folks could begin working on them. Just to let you know, we at elego have set up a tinderbox based automated build system which should be ready for production soon. Regards, Kaspar Schleiser From lemming at henning-thielemann.de Wed Jan 2 22:51:23 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Wed, 02 Jan 2008 22:51:23 +0100 (CET) Subject: [M3devel] M3 concerns In-Reply-To: References: <477B7629.1E75.00D7.1@scires.com> Message-ID: On Wed, 2 Jan 2008, Tony Hosking wrote: > > I would appreciate constructive feedback on this topic. > > It would be great to have a set of regression tests run on a regular > basis to ensure that checkins don't break things. What good > candidates do we have? cm3 itself I suppose. Any others? Do you mean m3-sys/m3tests ? From mika at async.caltech.edu Thu Jan 3 01:10:42 2008 From: mika at async.caltech.edu (Mika Nystrom) Date: Wed, 02 Jan 2008 16:10:42 -0800 Subject: [M3devel] M3 concerns In-Reply-To: Your message of "Wed, 02 Jan 2008 14:32:02 EST." <477BA060.1E75.00D7.1@scires.com> Message-ID: <200801030010.m030AgKN099099@camembert.async.caltech.edu> I can happily volunteer FreeBSD 4.x and 5.x (i386) systems, Windows 2000, and, I believe, Digital Unix 4.0 systems to run nightly (daily?) builds. Unfortunately I am of course a bit short on Time, which is probably what's lacking the most, anyhow... Mika "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. > >--=__Part103621A2.1__= >Content-Type: text/plain; charset=US-ASCII >Content-Transfer-Encoding: quoted-printable > >Tony: >=20 >I'm thinking that with a little work we could set up an automated set of = >builds and regression tests that would make available a "scoreboard" via a = >web interface where everyone could see the results. That way, as problems = >are uncovered, folks could begin working on them. >=20 >For an example of how all this works, take a look at the scoreboard set up = >for the ACE+TAO+CIAO projects. An overview is at http://www.dre.vanderbilt= >.edu/Scoreboard/ . They provide instructions for setting up your own = >daily build and scoreboard at https://svn.dre.vanderbilt.edu/viewvc/autobui= >ld/trunk/README?revision=3DHEAD . You can see the scoreboard in operation = >at http://remedy.nl/ . >=20 >Regards, >Randy > >>>> Tony Hosking 1/2/2008 1:36 PM >>> > >On Jan 2, 2008, at 11:31 AM, Randy Coleburn wrote: > >> I've seen quite a number of m3commit and m3devel messages lately. =20 >> Many of these give the appearance of "thinking out loud" with =20 >> various commits followed by apparent reversals. In many cases the =20 >> m3commit log messages are terse and don't give the rationale behind =20 >> the change. > >Yes, I agree. Also, I tend to avoid committing multiple small =20 >patches and rather defer until I have had a chance to test everything =20 >and let it stabilize, before checking in as one single commit. So, =20 >less frequent, coherent commits, are preferable to many smaller, =20 >incoherent commits. > >> For those of us in the M3 community who rely upon the stability of =20 >> the libraries and core M3 principles, these types of messages cause =20 >> concern. While I appreciate everyone's efforts to move forward, I =20 >> don't want to abandon the great care that went into formulating =20 >> this language. > >Indeed. > >> Question: As various people make contributions and changes, is =20 >> there any group of folks who is verifying that the changes don't =20 >> break existing code or core principles? Another idea would be to =20 >> have a series of test batteries that have to be passed before =20 >> changes can be accepted. I know of a number of projects where many =20 >> people contribute, but the contributions have to be vetted by =20 >> passing some tests. > >I try to verify that all my code doesn't break existing code (though =20 >I admit GC/thread subsystems can be devilish to completely verify). =20 >We do need to have some sort of procedures in place for deciding what =20 >commits make sense and should go into the CVS head. Tentative work =20 >should always be done to a CVS branch until it can be vetted. > >> Without these types of controls, I fear that good forward progress =20 >> will inevitably be hampered or compromised by changes made by =20 >> someone who hasn't completely thought out and tested the =20 >> ramifications of those changes. > >Agree! > >> For example, I've tried to get cm3 working for me on Windows XP =20 >> several times. I still can't seem to get the "current" system to =20 >> build correctly on XP. In the past, I have on occasion gotten the =20 >> "system" to build, but then some of my programs don't work =20 >> correctly when rebuilt using the new cm3. Thus, some changes =20 >> somewhere have "broken" my code, yet all of my code uses the "safe" =20 >> subset of the language. If I go back to my old reliable cm3 =20 >> version 4.1 (the last one put out before Critical Mass, Inc. threw =20 >> in the towel), my code compiles and works, even on Windows XP, even =20 >> using Trestle, FormsVBT, NetObj, cross-platform pickles (e.g., =20 >> pickles shared between Windows & Unix boxes), etc.! Much of my =20 >> code was originally developed under Windows NT, so I think it is a =20 >> tribute to the original language developers that my code and their =20 >> compiler work through various OS version upgrades (NT, 2000, XP) =20 >> and changes to the underlying C/C++ compilers used to build the =20 >> core components. > >I thought we were getting closer to stability in this regard, though =20 >I am not a heavy Windows user and have never built CM3 on Windows. > >> I would appreciate constructive feedback on this topic. > >It would be great to have a set of regression tests run on a regular =20 >basis to ensure that checkins don't break things. What good =20 >candidates do we have? cm3 itself I suppose. Any others? I can =20 >probably devise a couple of thread and GC stress tests pretty =20 >easily. Anyone willing to set up a testing regime? I have machines =20 >that could be used to test on several supported platforms on a =20 >nightly basis even. > >> >> Regards, >> Randy Coleburn >> >> >> Randy C. Coleburn, CISSP >> Senior Systems Engineer, Communications, Networks, & Electronics =20 >> Division (CNE) >> Corporate & Atlanta Information Systems Security Manager (ISSM) >> Scientific Research Corporation >> 2300 Windy Ridge Parkway, Suite 400 South, Atlanta, Georgia 30339 >> voice: (770) 989-9464, email: RColeburn at SciRes.com, fax: (770) =20 >> 989-9497 >> >> Quality Policy: "SRC CNE Division is committed to delivering =20 >> continually improving research & engineering excellence that meets =20 >> or exceeds customer requirements." > > > >--=__Part103621A2.1__= >Content-Type: text/html; charset=US-ASCII >Content-Transfer-Encoding: quoted-printable >Content-Description: HTML > > >"> > > >
Tony:
>
 
>
I'm thinking that with a little work we could set up an automated set = >of builds and regression tests that would make available a "scoreboard" = >via a web interface where everyone could see the results.  That way, = >as problems are uncovered, folks could begin working on them.
>
 
>
For an example of how all this works, take a look at the scoreboard = >set up for the ACE+TAO+CIAO projects.  An overview is at tp://www.dre.vanderbilt.edu/Scoreboard/">http://www.dre.vanderbilt.edu/Scor= >eboard/ .  They provide instructions for setting up your own = >daily build and scoreboard at wvc/autobuild/trunk/README?revision=3DHEAD">https://svn.dre.vanderbilt.edu/= >viewvc/autobuild/trunk/README?revision=3DHEAD .  You can see = >the scoreboard in operation at http://remedy.= >nl/ .
>
 
>
Regards,
>
Randy
>

>>> Tony Hosking <hosking at cs.purdue.edu> 1/2/2008 = >1:36 PM >>>

On Jan 2, 2008, at 11:31 AM, Randy Coleburn = >wrote:

> I've seen quite a number of m3commit and m3devel = >messages lately.  
> Many of these give the appearance of = >"thinking out loud" with 
> various commits followed by = >apparent reversals.  In many cases the 
> m3commit log = >messages are terse and don't give the rationale behind 
> the = >change.

Yes, I agree.  Also, I tend to avoid committing = >multiple small 
patches and rather defer until I have had a = >chance to test everything 
and let it stabilize, before checking = >in as one single commit.   So, 
less frequent, coherent = >commits, are preferable to many smaller, 
incoherent commits.
<= >BR>>  For those of us in the M3 community who rely upon the = >stability of 
> the libraries and core M3 principles, these = >types of messages cause 
> concern.  While I appreciate = >everyone's efforts to move forward, I 
> don't want to abandon = >the great care that went into formulating 
> this language.
= >
Indeed.

>  Question:  As various people make = >contributions and changes, is 
> there any group of folks who = >is verifying that the changes don't 
> break existing code or = >core principles?  Another idea would be to 
> have a = >series of test batteries that have to be passed before 
> = >changes can be accepted.  I know of a number of projects where = >many 
> people contribute, but the contributions have to be = >vetted by 
> passing some tests.

I try to verify that = >all my code doesn't break existing code (though 
I admit = >GC/thread subsystems can be devilish to completely verify).   = >
We do need to have some sort of procedures in place for deciding = >what 
commits make sense and should go into the CVS head.  = >Tentative work 
should always be done to a CVS branch until it = >can be vetted.

>  Without these types of controls, I fear = >that good forward progress 
> will inevitably be hampered or = >compromised by changes made by 
> someone who hasn't completely= > thought out and tested the 
> ramifications of those = >changes.

Agree!

>  For example, I've tried to get = >cm3 working for me on Windows XP 
> several times.  I = >still can't seem to get the "current" system to 
> build = >correctly on XP.  In the past, I have on occasion gotten the  = >
> "system" to build, but then some of my programs don't work  = >
> correctly when rebuilt using the new cm3.  Thus, some = >changes 
> somewhere have "broken" my code, yet all of my code = >uses the "safe" 
> subset of the language.  If I go back = >to my old reliable cm3 
> version 4.1 (the last one put out = >before Critical Mass, Inc. threw 
> in the towel), my code = >compiles and works, even on Windows XP, even 
> using Trestle, = >FormsVBT, NetObj, cross-platform pickles (e.g., 
> pickles = >shared between Windows & Unix boxes), etc.!  Much of my  = >
> code was originally developed under Windows NT, so I think it is = >a 
> tribute to the original language developers that my code = >and their 
> compiler work through various OS version upgrades = >(NT, 2000, XP) 
> and changes to the underlying C/C++ = >compilers used to build the 
> core components.

I = >thought we were getting closer to stability in this regard, though  = >
I am not a heavy Windows user and have never built CM3 on Windows.
<= >BR>>  I would appreciate constructive feedback on this topic.
R>It would be great to have a set of regression tests run on a regular = >;
basis to ensure that checkins don't break things.  What = >good 
candidates do we have?  cm3 itself I suppose.  = >Any others?  I can 
probably devise a couple of thread and = >GC stress tests pretty 
easily.  Anyone willing to set up a = >testing regime? I have machines 
that could be used to test on = >several supported platforms on a 
nightly basis even.

><= >BR>> Regards,
> Randy Coleburn
>
>
> Randy C. = >Coleburn, CISSP
> Senior Systems Engineer, Communications, Networks, = >& Electronics 
> Division (CNE)
> Corporate & = >Atlanta Information Systems Security Manager (ISSM)
> Scientific = >Research Corporation
> 2300 Windy Ridge Parkway, Suite 400 South, = >Atlanta, Georgia 30339
> voice: (770) 989-9464, email: RColeburn at SciR= >es.com, fax: (770) 
> 989-9497
>
> Quality = >Policy:  "SRC CNE Division is committed to delivering 
> = >continually improving research & engineering excellence that meets = >;
> or exceeds customer requirements."


L> > >--=__Part103621A2.1__=-- From dabenavidesd at yahoo.es Thu Jan 3 04:52:51 2008 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Thu, 3 Jan 2008 04:52:51 +0100 (CET) Subject: [M3devel] cm3 winvbt concerns Message-ID: <846332.60063.qm@web27115.mail.ukl.yahoo.com> Hi all: Talking about Windows state, the gui packet (winvbt used in mentor, juno, etc, ..) needs to be checked, at least as I see the problem that Jay and maybe Randy are seeing was reported in a 2003 post on comp.lang.modula3: http://groups.google.com/group/comp.lang.modula3/browse_thread/thread/cffb2c2cfda5d9b7/a1822c17c9381925#a1822c17c9381925 Looking more closely, I think there is some code that need to be completed as is documented on the file WinContext.m3 at the procedure: PushStroke (below is a url to show you the comment on that function of dec src that is equal implemented on cm3): http://www.cs.tut.fi/lintula/manual/modula3/m3sources/html/ui/src/winvbt/WinContext.m3.html#PushStroke It says: (* * The main omission is that I don't deal with pixmaps! * * Refer back to XGC.ResolveStrokeGC to see just how much functionality * is missing! *) The comment refers to this function that is implemented in xvbt implementation: http://modula3.elegosoft.com/cm3/doc/help/gen_html/ui/src/xvbt/XGC.m3.html#ResolveStrokeGC I got into this function (PushPixmap of WinContext ) because the assert fails at WinContext.PushPixmap in the line: *** <*ASSERT*> failed. *** file "..\src\winvbt\WinContext.m3", line 165 : brush := WinGDI.CreatePatternBrush (pst.pmtable[pm].hbmp); brush gets NIL. I suspect that is because of the (pst.pmtable[pm].hbmp) argument is not correct. If you have a m3browser winnt machine (pcname named) with latest cm3, this is the url of the procedure implementation: http://pcname:3829/SWinContext.i3.PushPixmap#PushPixmap Or in the cvs online this is the source file of that function: http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/~checkout~/cm3/m3-ui/ui/src/winvbt/WinContext.m3?rev=1.1.1.2;content-type=text%2Fplain Also, the function doesn't exist on the old implementation of winvbt (of dec src): http://www.cs.tut.fi/lintula/manual/modula3/m3sources/html/ui/src/winvbt/WinContext.m3.html One can look more further, but let me know what do you think. Daniel Benavides --------------------------------- ?Chef por primera vez? - S? un mejor Cocinillas. Entra en Yahoo! Respuestas. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Thu Jan 3 23:09:22 2008 From: jayk123 at hotmail.com (Jay) Date: Thu, 3 Jan 2008 22:09:22 +0000 Subject: [M3devel] PPC_LINUX breaks Message-ID: I can't build PPC_LINUX. I can build the compiler with 5.2.6 but then stuck at building m3core with current compiler. There are several problems. Some I can fix, some stump me. This platform still uses non-PTHREADs. I figure that is worth fixing, but maybe afterward? [jay at localhost m3core]$ /tmp/make-dist/compiler_with_self/bin/cm3 -override -DROOT='/dev2/cm3' new source -> compiling Uucontext.i3 "../src/unix/linux-ppc/Uucontext.i3", line 102: syntax error: missing ']' 1 error encountered [jay at localhost m3core]$ cvs diff src/unix/linux-ppc/Uucontext.i3 Index: src/unix/linux-ppc/Uucontext.i3 =================================================================== RCS file: /usr/cvs/cm3/m3-libs/m3core/src/unix/linux-ppc/Uucontext.i3,v retrieving revision 1.1 diff -r1.1 Uucontext.i3 102c102 < vrregs: ARRAY[0..32,0..4] OF unsigned_int; --- > vrregs: ARRAY[0..32 * 4] OF unsigned_int; new source -> compiling Uucontext.i3 "../src/unix/linux-ppc/Uucontext.i3", line 92: undefined (double) "../src/unix/linux-ppc/Uucontext.i3", line 93: undefined (double) "../src/unix/linux-ppc/Uucontext.i3", line 94: undefined (unsigned_int) "../src/unix/linux-ppc/Uucontext.i3", line 102: undefined (unsigned_int) "../src/unix/linux-ppc/Uucontext.i3", line 103: undefined (unsigned_int) "../src/unix/linux-ppc/Uucontext.i3", line 104: undefined (unsigned_int) "../src/unix/linux-ppc/Uucontext.i3", line 105: undefined (unsigned_int) "../src/unix/linux-ppc/Uucontext.i3", line 149: undefined (char) "../src/unix/linux-ppc/Uucontext.i3", line 10: warning: not used (unsigned_short) "../src/unix/linux-ppc/Uucontext.i3", line 11: warning: not used (unsigned_short_int) 8 errors and 2 warnings encountered [jay at localhost m3core]$ cvs diff src/unix/linux-ppc/Uucontext.i3 Index: src/unix/linux-ppc/Uucontext.i3 =================================================================== RCS file: /usr/cvs/cm3/m3-libs/m3core/src/unix/linux-ppc/Uucontext.i3,v retrieving revision 1.1 diff -r1.1 Uucontext.i3 10,11c10,11 < IMPORT int, unsigned_long, unsigned_long_int, unsigned_short, void_star, < unsigned_short_int; --- > IMPORT int, unsigned_long, unsigned_long_int, void_star, > double, unsigned_int, char; new source -> compiling RTSignal.m3 "../src/runtime/PPC_LINUX/RTSignal.m3", line 82: undefined (Usignal.struct_sigcontext) 1 error encountered [jay at localhost m3core]$ cvs diff src/runtime/PPC_LINUX/RTSignal.m3 Index: src/runtime/PPC_LINUX/RTSignal.m3 =================================================================== RCS file: /usr/cvs/cm3/m3-libs/m3core/src/runtime/PPC_LINUX/RTSignal.m3,v retrieving revision 1.1 diff -r1.1 RTSignal.m3 10c10 < IMPORT RTError, RTProcess, Csignal, Usignal, Uprocess; --- > IMPORT RTError, RTProcess, Csignal, Usignal, Uprocess, Uucontext; 82c82 < scp : Usignal.struct_sigcontext; --- > scp : Uucontext.struct_sigcontext; new source -> compiling RTSignal.m3 "../src/runtime/PPC_LINUX/RTSignal.m3", line 85: unknown qualification '.' (eip) 1 error encountered This I looked into a while. The problem is obvious, the fix is not. For now I replaced whatever.eip with 0. Sometimes PowerPC calls eip srr0, but sometimes not. The first thing I found reading about PowerPC is that there's no instruction counter register, because it is rarely needed directly in code. But anyway, it's still need for traps/exceptions. I'll look at an old winnt.h. And then I am stuck on: new source -> compiling RTThread.m3 "../src/runtime/PPC_LINUX/RTThread.m3", line 88: unknown qualification '.' (sa_handler) "../src/runtime/PPC_LINUX/RTThread.m3", line 89: unknown qualification '.' (empty_sigset_t) "../src/runtime/PPC_LINUX/RTThread.m3", line 91: incompatible types (act) "../src/runtime/PPC_LINUX/RTThread.m3", line 91: VAR actual must be a designator (oact) "../src/runtime/PPC_LINUX/RTThread.m3", line 96: incompatible types (set) "../src/runtime/PPC_LINUX/RTThread.m3", line 96: VAR actual must be a designator (oset) "../src/runtime/PPC_LINUX/RTThread.m3", line 101: incompatible types (set) "../src/runtime/PPC_LINUX/RTThread.m3", line 101: VAR actual must be a designator (oset) "../src/runtime/PPC_LINUX/RTThread.m3", line 108: unknown qualification '.' (sigmask) 9 errors encountered The code: PROCEDURE setup_sigvtalrm (handler: Usignal.SignalHandler) = VAR x: Usignal.struct_sigaction; BEGIN x.sa_handler := LOOPHOLE (handler, Usignal.SignalActionHandler); (* line 88*) x.sa_mask := Usignal.empty_sigset_t; (*89*) x.sa_flags := Usignal.SA_RESTART; (*90*) EVAL Usignal.sigaction (Usignal.SIGVTALRM, ADR (x), NIL); (*91*) END setup_sigvtalrm; Other platforms get away without this stuff by using just "signal" which takes fewer parameters. I ASSUME PPC_LINUX as some interest in more parameters in order to implement vtalarm based threads, instead of pthreads. Usignal does define these types..unless I am looking at the wrong one. Or heck, even the obvious wrong one. Except..overrides..the local package..stuff doesn't need an override to refer to itself, right? Non-standalone binaries also don't work. I think I reported that two weeks ago. I figured that'd come afterward.. There is also: new source -> compiling Long.m3 GenWord.mg: In function `Long__Divide': GenWord.mg:13: Internal compiler error in emit_library_call_value_1, at calls.c:3684 Please submit a full bug report, with preprocessed source if appropriate. See for instructions. though I thought I had gotten past that by building m3cc. Not likely a Modula-3 problem and I could always get around it by making LONGINT only 32 bits (I think "long" is dumb in a name...). [jay at localhost m3core]$ uname -a Linux localhost.localdomain 2.6.15-rc5.ydl.1 #1 Wed Jan 4 16:25:38 EST 2006 ppc ppc ppc GNU/Linux [jay at localhost m3core]$ gcc -v Reading specs from /usr/lib/gcc/ppc64-yellowdog-linux/3.4.4/specs Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --disable-checking --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-java-awt=gtk --host=ppc64-yellowdog-linux --build=ppc64-yellowdog-linux --target=ppc64-yellowdog-linux --with-cpu=default32 Thread model: posix gcc version 3.4.4 20050721 (Yellow Dog 3.4.4-2.ydl.2) This is like Yellow Dog 4.x or so. I don't know why all the ppc64 references. This is an iBook G3 -- 32bit. I guess maybe it can build both -- oh, not that this gcc is in use. Nor do I expect it matters. - Jay _________________________________________________________________ The best games are on Xbox 360. Click here for a special offer on an Xbox 360 Console. http://www.xbox.com/en-US/hardware/wheretobuy/ From jayk123 at hotmail.com Thu Jan 3 23:51:46 2008 From: jayk123 at hotmail.com (Jay) Date: Thu, 3 Jan 2008 22:51:46 +0000 Subject: [M3devel] PPC_LINUX breaks Message-ID: I'll try upgrade.sh instead of my make-dist.py. I got the same gcc error on PPC_DRAWIN too, but that was definitely without building m3cc. Also from an older build. - Jay ---------------------------------------- > From: jayk123 at hotmail.com > To: m3devel at elegosoft.com > Subject: PPC_LINUX breaks > Date: Thu, 3 Jan 2008 22:09:22 +0000 > > > I can't build PPC_LINUX. > > > I can build the compiler with 5.2.6 but then stuck at building m3core with current compiler. > There are several problems. > Some I can fix, some stump me. > This platform still uses non-PTHREADs. > I figure that is worth fixing, but maybe afterward? > > > [jay at localhost m3core]$ /tmp/make-dist/compiler_with_self/bin/cm3 -override -DROOT='/dev2/cm3' > > > new source -> compiling Uucontext.i3 > "../src/unix/linux-ppc/Uucontext.i3", line 102: syntax error: missing ']' > 1 error encountered > > > [jay at localhost m3core]$ cvs diff src/unix/linux-ppc/Uucontext.i3 > Index: src/unix/linux-ppc/Uucontext.i3 > =================================================================== > RCS file: /usr/cvs/cm3/m3-libs/m3core/src/unix/linux-ppc/Uucontext.i3,v > retrieving revision 1.1 > diff -r1.1 Uucontext.i3 > 102c102 > < vrregs: ARRAY[0..32,0..4] OF unsigned_int; > --- >> vrregs: ARRAY[0..32 * 4] OF unsigned_int; > > > new source -> compiling Uucontext.i3 > "../src/unix/linux-ppc/Uucontext.i3", line 92: undefined (double) > "../src/unix/linux-ppc/Uucontext.i3", line 93: undefined (double) > "../src/unix/linux-ppc/Uucontext.i3", line 94: undefined (unsigned_int) > "../src/unix/linux-ppc/Uucontext.i3", line 102: undefined (unsigned_int) > "../src/unix/linux-ppc/Uucontext.i3", line 103: undefined (unsigned_int) > "../src/unix/linux-ppc/Uucontext.i3", line 104: undefined (unsigned_int) > "../src/unix/linux-ppc/Uucontext.i3", line 105: undefined (unsigned_int) > "../src/unix/linux-ppc/Uucontext.i3", line 149: undefined (char) > "../src/unix/linux-ppc/Uucontext.i3", line 10: warning: not used (unsigned_short) > "../src/unix/linux-ppc/Uucontext.i3", line 11: warning: not used (unsigned_short_int) > 8 errors and 2 warnings encountered > > > [jay at localhost m3core]$ cvs diff src/unix/linux-ppc/Uucontext.i3 > Index: src/unix/linux-ppc/Uucontext.i3 > =================================================================== > RCS file: /usr/cvs/cm3/m3-libs/m3core/src/unix/linux-ppc/Uucontext.i3,v > retrieving revision 1.1 > diff -r1.1 Uucontext.i3 > 10,11c10,11 > < IMPORT int, unsigned_long, unsigned_long_int, unsigned_short, void_star, > < unsigned_short_int; > --- >> IMPORT int, unsigned_long, unsigned_long_int, void_star, >> double, unsigned_int, char; > > > > new source -> compiling RTSignal.m3 > "../src/runtime/PPC_LINUX/RTSignal.m3", line 82: undefined (Usignal.struct_sigcontext) > 1 error encountered > > [jay at localhost m3core]$ cvs diff src/runtime/PPC_LINUX/RTSignal.m3 > Index: src/runtime/PPC_LINUX/RTSignal.m3 > =================================================================== > RCS file: /usr/cvs/cm3/m3-libs/m3core/src/runtime/PPC_LINUX/RTSignal.m3,v > retrieving revision 1.1 > diff -r1.1 RTSignal.m3 > 10c10 > < IMPORT RTError, RTProcess, Csignal, Usignal, Uprocess; > --- >> IMPORT RTError, RTProcess, Csignal, Usignal, Uprocess, Uucontext; > 82c82 > < scp : Usignal.struct_sigcontext; > --- >> scp : Uucontext.struct_sigcontext; > > > new source -> compiling RTSignal.m3 > "../src/runtime/PPC_LINUX/RTSignal.m3", line 85: unknown qualification '.' (eip) > 1 error encountered > > This I looked into a while. The problem is obvious, the fix is not. > For now I replaced whatever.eip with 0. > Sometimes PowerPC calls eip srr0, but sometimes not. > The first thing I found reading about PowerPC is that there's no instruction > counter register, because it is rarely needed directly in code. > But anyway, it's still need for traps/exceptions. > I'll look at an old winnt.h. > > > And then I am stuck on: > > > new source -> compiling RTThread.m3 > "../src/runtime/PPC_LINUX/RTThread.m3", line 88: unknown qualification '.' (sa_handler) > "../src/runtime/PPC_LINUX/RTThread.m3", line 89: unknown qualification '.' (empty_sigset_t) > "../src/runtime/PPC_LINUX/RTThread.m3", line 91: incompatible types (act) > "../src/runtime/PPC_LINUX/RTThread.m3", line 91: VAR actual must be a designator (oact) > "../src/runtime/PPC_LINUX/RTThread.m3", line 96: incompatible types (set) > "../src/runtime/PPC_LINUX/RTThread.m3", line 96: VAR actual must be a designator (oset) > "../src/runtime/PPC_LINUX/RTThread.m3", line 101: incompatible types (set) > "../src/runtime/PPC_LINUX/RTThread.m3", line 101: VAR actual must be a designator (oset) > "../src/runtime/PPC_LINUX/RTThread.m3", line 108: unknown qualification '.' (sigmask) > 9 errors encountered > > > The code: > > > PROCEDURE setup_sigvtalrm (handler: Usignal.SignalHandler) = > VAR x: Usignal.struct_sigaction; > BEGIN > x.sa_handler := LOOPHOLE (handler, Usignal.SignalActionHandler); (* line 88*) > x.sa_mask := Usignal.empty_sigset_t; (*89*) > x.sa_flags := Usignal.SA_RESTART; (*90*) > EVAL Usignal.sigaction (Usignal.SIGVTALRM, ADR (x), NIL); (*91*) > END setup_sigvtalrm; > > > Other platforms get away without this stuff by using just "signal" which > takes fewer parameters. I ASSUME PPC_LINUX as some interest in more parameters > in order to implement vtalarm based threads, instead of pthreads. > > > Usignal does define these types..unless I am looking at the wrong one. > Or heck, even the obvious wrong one. > > > Except..overrides..the local package..stuff doesn't need an override to refer to itself, right? > > > Non-standalone binaries also don't work. I think I reported that two weeks ago. > I figured that'd come afterward.. > > > There is also: > new source -> compiling Long.m3 > GenWord.mg: In function `Long__Divide': > GenWord.mg:13: Internal compiler error in emit_library_call_value_1, at calls.c:3684 > Please submit a full bug report, > with preprocessed source if appropriate. > See for instructions. > > > though I thought I had gotten past that by building m3cc. > Not likely a Modula-3 problem and I could always get around it > by making LONGINT only 32 bits (I think "long" is dumb in a name...). > > > [jay at localhost m3core]$ uname -a > Linux localhost.localdomain 2.6.15-rc5.ydl.1 #1 Wed Jan 4 16:25:38 EST 2006 ppc ppc ppc GNU/Linux > > > [jay at localhost m3core]$ gcc -v > Reading specs from /usr/lib/gcc/ppc64-yellowdog-linux/3.4.4/specs > Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --disable-checking --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-java-awt=gtk --host=ppc64-yellowdog-linux --build=ppc64-yellowdog-linux --target=ppc64-yellowdog-linux --with-cpu=default32 > Thread model: posix > gcc version 3.4.4 20050721 (Yellow Dog 3.4.4-2.ydl.2) > > > This is like Yellow Dog 4.x or so. > I don't know why all the ppc64 references. This is an iBook G3 -- 32bit. > I guess maybe it can build both -- oh, not that this gcc is in use. > Nor do I expect it matters. > > > - Jay > _________________________________________________________________ > The best games are on Xbox 360. Click here for a special offer on an Xbox 360 Console. > http://www.xbox.com/en-US/hardware/wheretobuy/ _________________________________________________________________ The best games are on Xbox 360. Click here for a special offer on an Xbox 360 Console. http://www.xbox.com/en-US/hardware/wheretobuy/ From jayk123 at hotmail.com Fri Jan 4 02:55:25 2008 From: jayk123 at hotmail.com (Jay) Date: Fri, 4 Jan 2008 01:55:25 +0000 Subject: [M3devel] test Message-ID: I think this is down again. - Jay _________________________________________________________________ Don't get caught with egg on your face. Play Chicktionary! http://club.live.com/chicktionary.aspx?icid=chick_wlhmtextlink1_dec -------------- next part -------------- An HTML attachment was scrubbed... URL: From stsp at elego.de Fri Jan 4 15:15:23 2008 From: stsp at elego.de (Stefan Sperling) Date: Fri, 4 Jan 2008 15:15:23 +0100 Subject: [M3devel] PPC_LINUX breaks In-Reply-To: References: Message-ID: <20080104141523.GC1459@ted.stsp.lan> On Thu, Jan 03, 2008 at 10:09:22PM +0000, Jay wrote: > > I can't build PPC_LINUX. It's been broken at least since the 5.4 release was made. Back then I failed to build it, and we decided to drop it from the 5.4 release. It needs fixing. -- Stefan Sperling Software Developer elego Software Solutions GmbH HRB 77719 Gustav-Meyer-Allee 25, Gebaeude 12 Tel: +49 30 23 45 86 96 13355 Berlin Fax: +49 30 23 45 86 95 http://www.elego.de Geschaeftsfuehrer: Olaf Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From hosking at cs.purdue.edu Fri Jan 4 15:43:31 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 4 Jan 2008 09:43:31 -0500 Subject: [M3devel] PPC_LINUX breaks In-Reply-To: <20080104141523.GC1459@ted.stsp.lan> References: <20080104141523.GC1459@ted.stsp.lan> Message-ID: <65C183A8-6102-49E9-9C38-8D59C966E42D@cs.purdue.edu> Has anyone built PPC_LINUX? I've never tried. On Jan 4, 2008, at 9:15 AM, Stefan Sperling wrote: > On Thu, Jan 03, 2008 at 10:09:22PM +0000, Jay wrote: >> >> I can't build PPC_LINUX. > > It's been broken at least since the 5.4 release was made. > > Back then I failed to build it, and we decided to drop > it from the 5.4 release. It needs fixing. > > -- > Stefan Sperling Software Developer > elego Software Solutions GmbH HRB 77719 > Gustav-Meyer-Allee 25, Gebaeude 12 Tel: +49 30 23 45 86 96 > 13355 Berlin Fax: +49 30 23 45 86 95 > http://www.elego.de Geschaeftsfuehrer: Olaf Wagner From dabenavidesd at yahoo.es Fri Jan 4 19:34:29 2008 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Fri, 4 Jan 2008 19:34:29 +0100 (CET) Subject: [M3devel] Ubuntu Gutsy problems Message-ID: <122805.74554.qm@web27110.mail.ukl.yahoo.com> Hi all: I'm trying to compile the first step bootstrap compiler on ubuntu gutsy 2.6.22-14-386, and I get into segmentation fault: adminfbd at fbd-desktop:/home/daniel/code/cm3/scripts$ sudo ./do-pkg.sh buildship m3core CM3C = /home/daniel/code/cm3/scripts/pkgmap.sh -c "/usr/local/cm3/bin/cm3 -build -DROOT='/home/daniel/code/cm3' && /usr/local/cm3/bin/cm3 -ship -DROOT='/home/daniel/code/cm3' " m3core === package /home/daniel/code/cm3/m3-libs/m3core === +++ /usr/local/cm3/bin/cm3 -build -DROOT='/home/daniel/code/cm3' && /usr/local/cm3/bin/cm3 -ship -DROOT='/home/daniel/code/cm3' +++ --- building in LINUXLIBC6 --- ignoring ../src/m3overrides new source -> compiling RTHooks.i3 RTHooks.i3: In function 'RTHooks_I3': RTHooks.i3:146: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling RT0.i3 RT0.i3: In function 'RT0_I3': RT0.i3:230: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling RuntimeError.i3 RuntimeError.i3: In function 'RuntimeError_I3': I used the new binaries of the d5.5.0 branch. Thanks --------------------------------- Web Revelaci?n Yahoo! 2007: Premio Favorita del P?blico - ?Vota tu preferida! -------------- next part -------------- An HTML attachment was scrubbed... URL: From dabenavidesd at yahoo.es Fri Jan 4 19:42:40 2008 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Fri, 4 Jan 2008 19:42:40 +0100 (CET) Subject: [M3devel] Ubuntu Gutsy problems In-Reply-To: <122805.74554.qm@web27110.mail.ukl.yahoo.com> Message-ID: <735847.33274.qm@web27102.mail.ukl.yahoo.com> Hi: Here is a stacktrace of cm3cg, compiled with a gcc 4.1 compiler (of this machine). daniel at fbd-desktop:~$ gdb cm3cg GNU gdb 6.6-debian Copyright (C) 2006 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i486-linux-gnu"... Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1". (gdb) run RTHooks.ic -o RTHooks.is -g Starting program: /usr/local/cm3/bin/cm3cg RTHooks.ic -o RTHooks.is -g Program received signal SIGSEGV, Segmentation fault. 0x080d8e6d in gen_field_die () (gdb) where #0 0x080d8e6d in gen_field_die () #1 0x080dc988 in gen_decl_die () #2 0x080d9d61 in gen_type_die () #3 0x080dcb45 in gen_decl_die () #4 0x080dcd34 in dwarf2out_decl () #5 0x080dcd55 in dwarf2out_type_decl () #6 0x08050178 in debug_struct () #7 0x080505ea in m3cg_declare_formal () #8 0x080515b6 in m3_parse_file () #9 0x082682aa in toplev_main () #10 0x080568ca in main () "Daniel Alejandro Benavides D." escribi?: Hi all: I'm trying to compile the first step bootstrap compiler on ubuntu gutsy 2.6.22-14-386, and I get into segmentation fault: adminfbd at fbd-desktop:/home/daniel/code/cm3/scripts$ sudo ./do-pkg.sh buildship m3core CM3C = /home/daniel/code/cm3/scripts/pkgmap.sh -c "/usr/local/cm3/bin/cm3 -build -DROOT='/home/daniel/code/cm3' && /usr/local/cm3/bin/cm3 -ship -DROOT='/home/daniel/code/cm3' " m3core === package /home/daniel/code/cm3/m3-libs/m3core === +++ /usr/local/cm3/bin/cm3 -build -DROOT='/home/daniel/code/cm3' && /usr/local/cm3/bin/cm3 -ship -DROOT='/home/daniel/code/cm3' +++ --- building in LINUXLIBC6 --- ignoring ../src/m3overrides new source -> compiling RTHooks.i3 RTHooks.i3: In function 'RTHooks_I3': RTHooks.i3:146: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling RT0.i3 RT0.i3: In function 'RT0_I3': RT0.i3:230: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling RuntimeError.i3 RuntimeError.i3: In function 'RuntimeError_I3': I used the new binaries of the d5.5.0 branch. Thanks --------------------------------- Web Revelaci?n Yahoo! 2007: Premio Favorita del P?blico - ?Vota tu preferida! --------------------------------- Web Revelaci?n Yahoo! 2007: Premio Favorita del P?blico - ?Vota tu preferida! -------------- next part -------------- An HTML attachment was scrubbed... URL: From dabenavidesd at yahoo.es Fri Jan 4 19:58:49 2008 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Fri, 4 Jan 2008 19:58:49 +0100 (CET) Subject: [M3devel] Ubuntu Gutsy problems In-Reply-To: <735847.33274.qm@web27102.mail.ukl.yahoo.com> Message-ID: <546440.55084.qm@web27111.mail.ukl.yahoo.com> Hi: It gets compiled well when using -gstabs command line option of cm3cg, as Tony marked on this post, so for now we can change the cm3.cfg debug variable of m3_backend: https://mail.elegosoft.com/pipermail/m3devel/2007-June/000238.html proc m3_backend (source, object, optimize, debug) is local args = [ "-quiet", source, "-o", object ] if optimize args += "-O" end if debug args += "-gstabs" end (gdb) run RTHooks.ic -o RTHooks.is -gstabs Starting program: /usr/local/cm3/bin/cm3cg RTHooks.ic -o RTHooks.is -gstabs RTHooks_I3 Execution times (seconds) TOTAL : 0.02 0.00 0.02 596 kB Program exited normally. (gdb) Thanks "Daniel Alejandro Benavides D." escribi?: Hi: Here is a stacktrace of cm3cg, compiled with a gcc 4.1 compiler (of this machine). daniel at fbd-desktop:~$ gdb cm3cg GNU gdb 6.6-debian Copyright (C) 2006 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i486-linux-gnu"... Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1". (gdb) run RTHooks.ic -o RTHooks.is -g Starting program: /usr/local/cm3/bin/cm3cg RTHooks.ic -o RTHooks.is -g Program received signal SIGSEGV, Segmentation fault. 0x080d8e6d in gen_field_die () (gdb) where #0 0x080d8e6d in gen_field_die () #1 0x080dc988 in gen_decl_die () #2 0x080d9d61 in gen_type_die () #3 0x080dcb45 in gen_decl_die () #4 0x080dcd34 in dwarf2out_decl () #5 0x080dcd55 in dwarf2out_type_decl () #6 0x08050178 in debug_struct () #7 0x080505ea in m3cg_declare_formal () #8 0x080515b6 in m3_parse_file () #9 0x082682aa in toplev_main () #10 0x080568ca in main () "Daniel Alejandro Benavides D." escribi?: Hi all: I'm trying to compile the first step bootstrap compiler on ubuntu gutsy 2.6.22-14-386, and I get into segmentation fault: adminfbd at fbd-desktop:/home/daniel/code/cm3/scripts$ sudo ./do-pkg.sh buildship m3core CM3C = /home/daniel/code/cm3/scripts/pkgmap.sh -c "/usr/local/cm3/bin/cm3 -build -DROOT='/home/daniel/code/cm3' && /usr/local/cm3/bin/cm3 -ship -DROOT='/home/daniel/code/cm3' " m3core === package /home/daniel/code/cm3/m3-libs/m3core === +++ /usr/local/cm3/bin/cm3 -build -DROOT='/home/daniel/code/cm3' && /usr/local/cm3/bin/cm3 -ship -DROOT='/home/daniel/code/cm3' +++ --- building in LINUXLIBC6 --- ignoring ../src/m3overrides new source -> compiling RTHooks.i3 RTHooks.i3: In function 'RTHooks_I3': RTHooks.i3:146: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling RT0.i3 RT0.i3: In function 'RT0_I3': RT0.i3:230: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling RuntimeError.i3 RuntimeError.i3: In function 'RuntimeError_I3': I used the new binaries of the d5.5.0 branch. Thanks --------------------------------- Web Revelaci?n Yahoo! 2007: Premio Favorita del P?blico - ?Vota tu preferida! --------------------------------- Web Revelaci?n Yahoo! 2007: Premio Favorita del P?blico - ?Vota tu preferida! --------------------------------- Web Revelaci?n Yahoo! 2007: Premio Favorita del P?blico - ?Vota tu preferida! -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Fri Jan 4 20:17:23 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 4 Jan 2008 14:17:23 -0500 Subject: [M3devel] Ubuntu Gutsy problems In-Reply-To: <735847.33274.qm@web27102.mail.ukl.yahoo.com> References: <735847.33274.qm@web27102.mail.ukl.yahoo.com> Message-ID: <70ABAF58-FC5A-4FBB-8CCC-BEC58BAC73E4@cs.purdue.edu> Did you update your m3cg backend? Also, make sure your config file has "-gstabs" defined in the debug portion of the arguments to the m3_backend. It seems you are suffering from a lag between the 4.1 backend and config file and the newer one. On Jan 4, 2008, at 1:42 PM, Daniel Alejandro Benavides D. wrote: > Hi: > Here is a stacktrace of cm3cg, compiled with a gcc 4.1 compiler (of > this machine). > > daniel at fbd-desktop:~$ gdb cm3cg > GNU gdb 6.6-debian > Copyright (C) 2006 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, > and you are > welcome to change it and/or distribute copies of it under certain > conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for > details. > This GDB was configured as "i486-linux-gnu"... > Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so. > 1". > (gdb) run RTHooks.ic -o RTHooks.is -g > Starting program: /usr/local/cm3/bin/cm3cg RTHooks.ic -o RTHooks.is -g > > Program received signal SIGSEGV, Segmentation fault. > 0x080d8e6d in gen_field_die () > (gdb) where > #0 0x080d8e6d in gen_field_die () > #1 0x080dc988 in gen_decl_die () > #2 0x080d9d61 in gen_type_die () > #3 0x080dcb45 in gen_decl_die () > #4 0x080dcd34 in dwarf2out_decl () > #5 0x080dcd55 in dwarf2out_type_decl () > #6 0x08050178 in debug_struct () > #7 0x080505ea in m3cg_declare_formal () > #8 0x080515b6 in m3_parse_file () > #9 0x082682aa in toplev_main () > #10 0x080568ca in main () > > > "Daniel Alejandro Benavides D." escribi?: > Hi all: > I'm trying to compile the first step bootstrap compiler on ubuntu > gutsy 2.6.22-14-386, and I get into segmentation fault: > > adminfbd at fbd-desktop:/home/daniel/code/cm3/scripts$ sudo ./do- > pkg.sh buildship m3core > CM3C = > /home/daniel/code/cm3/scripts > /pkgmap.sh -c "/usr/local/cm3/bin/cm3 -build -DROOT='/home/daniel/ > code/cm3' && /usr/local/cm3/bin/cm3 -ship -DROOT='/home/daniel/ > code/cm3' " m3core > === package /home/daniel/code/cm3/m3-libs/m3core === > +++ /usr/local/cm3/bin/cm3 -build -DROOT='/home/daniel/code/cm3' > && /usr/local/cm3/bin/cm3 -ship -DROOT='/home/daniel/code/cm3' +++ > --- building in LINUXLIBC6 --- > > ignoring ../src/m3overrides > > new source -> compiling RTHooks.i3 > RTHooks.i3: In function 'RTHooks_I3': > RTHooks.i3:146: internal compiler error: Segmentation fault > Please submit a full bug report, > with preprocessed source if appropriate. > See for instructions. > new source -> compiling RT0.i3 > RT0.i3: In function 'RT0_I3': > RT0.i3:230: internal compiler error: Segmentation fault > Please submit a full bug report, > with preprocessed source if appropriate. > See for instructions. > new source -> compiling RuntimeError.i3 > RuntimeError.i3: In function 'RuntimeError_I3': > > I used the new binaries of the d5.5.0 branch. > > Thanks > > Web Revelaci?n Yahoo! 2007: > Premio Favorita del P?blico - ?Vota tu preferida! > > > Web Revelaci?n Yahoo! 2007: > Premio Favorita del P?blico - ?Vota tu preferida! From jayk123 at hotmail.com Fri Jan 4 20:58:45 2008 From: jayk123 at hotmail.com (Jay) Date: Fri, 4 Jan 2008 19:58:45 +0000 Subject: [M3devel] PPC_LINUX breaks In-Reply-To: <65C183A8-6102-49E9-9C38-8D59C966E42D@cs.purdue.edu> References: <20080104141523.GC1459@ted.stsp.lan> <65C183A8-6102-49E9-9C38-8D59C966E42D@cs.purdue.edu> Message-ID: I figured out a bunch here. a) the diffs I showed. b) "nip" is "next instruction pointer"; that's what you want in the SegV function. And the last parameter should be void_star instead of int. You can use like pt_regs.nip for the old definition or uc_regs.gprregs[PT_NIP] for the new definition. I have diffs here. c) Usignal.i3 had the stuff vtalarm stuff removed, which PPC_LINUX still uses, "POSIX threads" vs. "PThreads" (oh the names..), though perhaps broken by setjmp/longjmp "scrambling". Is it possible to break up an interface into linux-common/foo.i3 linux-ppc/foo.i3 I think not. Shall we just go ahead and translate LINUX_PPC pthread.h into Modula-3? (Btw, doesn't anyone find all this header rewriting sleazy? Or they have to maintain compat anyway so no problem?) The error messages are poor. Let's say I.T does not exist. VAR x : I.T; (* no error *) x.foo = bar; (* "unknown qualification" *) FROM I IMPORT T; (* "T not exported" -- better, but should say T does not exist I was fumbling around with needing a module to say "EXPORTS" or to capitalize the Interface directive in m3makefile, neither of which seemed right *) - Jay > From: hosking at cs.purdue.edu > Date: Fri, 4 Jan 2008 09:43:31 -0500 > To: stsp at elego.de > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] PPC_LINUX breaks > > Has anyone built PPC_LINUX? I've never tried. > > On Jan 4, 2008, at 9:15 AM, Stefan Sperling wrote: > > > On Thu, Jan 03, 2008 at 10:09:22PM +0000, Jay wrote: > >> > >> I can't build PPC_LINUX. > > > > It's been broken at least since the 5.4 release was made. > > > > Back then I failed to build it, and we decided to drop > > it from the 5.4 release. It needs fixing. > > > > -- > > Stefan Sperling Software Developer > > elego Software Solutions GmbH HRB 77719 > > Gustav-Meyer-Allee 25, Gebaeude 12 Tel: +49 30 23 45 86 96 > > 13355 Berlin Fax: +49 30 23 45 86 95 > > http://www.elego.de Geschaeftsfuehrer: Olaf Wagner > _________________________________________________________________ Share life as it happens with the new Windows Live. http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Fri Jan 4 21:45:06 2008 From: jayk123 at hotmail.com (Jay) Date: Fri, 4 Jan 2008 20:45:06 +0000 Subject: [M3devel] PPC_LINUX breaks In-Reply-To: References: <20080104141523.GC1459@ted.stsp.lan> <65C183A8-6102-49E9-9C38-8D59C966E42D@cs.purdue.edu> Message-ID: I'm confused here on what got deleted. I keep seeing it present. I swear I saw the diff though.. :( Browing CVS is such a pain. - Jay From: jayk123 at hotmail.com To: hosking at cs.purdue.edu; stsp at elego.de Date: Fri, 4 Jan 2008 19:58:45 +0000 CC: m3devel at elegosoft.com Subject: Re: [M3devel] PPC_LINUX breaks I figured out a bunch here. a) the diffs I showed. b) "nip" is "next instruction pointer"; that's what you want in the SegV function. And the last parameter should be void_star instead of int. You can use like pt_regs.nip for the old definition or uc_regs.gprregs[PT_NIP] for the new definition. I have diffs here. c) Usignal.i3 had the stuff vtalarm stuff removed, which PPC_LINUX still uses, "POSIX threads" vs. "PThreads" (oh the names..), though perhaps broken by setjmp/longjmp "scrambling". Is it possible to break up an interface into linux-common/foo.i3 linux-ppc/foo.i3 I think not. Shall we just go ahead and translate LINUX_PPC pthread.h into Modula-3? (Btw, doesn't anyone find all this header rewriting sleazy? Or they have to maintain compat anyway so no problem?) The error messages are poor. Let's say I.T does not exist. VAR x : I.T; (* no error *) x.foo = bar; (* "unknown qualification" *) FROM I IMPORT T; (* "T not exported" -- better, but should say T does not exist I was fumbling around with needing a module to say "EXPORTS" or to capitalize the Interface directive in m3makefile, neither of which seemed right *) - Jay > From: hosking at cs.purdue.edu > Date: Fri, 4 Jan 2008 09:43:31 -0500 > To: stsp at elego.de > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] PPC_LINUX breaks > > Has anyone built PPC_LINUX? I've never tried. > > On Jan 4, 2008, at 9:15 AM, Stefan Sperling wrote: > > > On Thu, Jan 03, 2008 at 10:09:22PM +0000, Jay wrote: > >> > >> I can't build PPC_LINUX. > > > > It's been broken at least since the 5.4 release was made. > > > > Back then I failed to build it, and we decided to drop > > it from the 5.4 release. It needs fixing. > > > > -- > > Stefan Sperling Software Developer > > elego Software Solutions GmbH HRB 77719 > > Gustav-Meyer-Allee 25, Gebaeude 12 Tel: +49 30 23 45 86 96 > > 13355 Berlin Fax: +49 30 23 45 86 95 > > http://www.elego.de Geschaeftsfuehrer: Olaf Wagner > Share life as it happens with the new Windows Live. Start sharing! _________________________________________________________________ Share life as it happens with the new Windows Live. http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Fri Jan 4 22:10:59 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 04 Jan 2008 22:10:59 +0100 Subject: [M3devel] M3 concerns In-Reply-To: <477B7629.1E75.00D7.1@scires.com> References: <477B7629.1E75.00D7.1@scires.com> Message-ID: <20080104221059.uwf80xrms0gw8880@mail.elegosoft.com> Quoting Randy Coleburn : > I've seen quite a number of m3commit and m3devel messages lately. > Many of these give the appearance of "thinking out loud" with > various commits followed by apparent reversals. In many cases the > m3commit log messages are terse and don't give the rationale behind > the change. > > For those of us in the M3 community who rely upon the stability of > the libraries and core M3 principles, these types of messages cause > concern. While I appreciate everyone's efforts to move forward, I > don't want to abandon the great care that went into formulating this > language. I agree that some of the recent commit messages seem to give the impression of quick changes. More care should be taken here. I'm not really concerned about the stability of the whole system, as those changes did mostly concern build infrastructure and minor fixes and adaptions. > Question: As various people make contributions and changes, is > there any group of folks who is verifying that the changes don't > break existing code or core principles? Another idea would be to > have a series of test batteries that have to be passed before > changes can be accepted. I know of a number of projects where many > people contribute, but the contributions have to be vetted by > passing some tests. Automated regression tests have been on my agenda for CM3 for a long time. I coulnd't contribute much myself during the last year, as I've been very busy. I've done a little bit in the last two weeks, and others have also worked in this area, so that I hope we will be able to present some working regression test setup within some days. At least we'll have some initial setup that can be extended and improved. More to this topic in another mail. > Without these types of controls, I fear that good forward progress > will inevitably be hampered or compromised by changes made by > someone who hasn't completely thought out and tested the > ramifications of those changes. Yes, this is the usual problem with all systems without periodic automatic regression testing. > For example, I've tried to get cm3 working for me on Windows XP > several times. I still can't seem to get the "current" system to > build correctly on XP. In the past, I have on occasion gotten the > "system" to build, but then some of my programs don't work correctly > when rebuilt using the new cm3. Thus, some changes somewhere have > "broken" my code, yet all of my code uses the "safe" subset of the > language. If I go back to my old reliable cm3 version 4.1 (the last > one put out before Critical Mass, Inc. threw in the towel), my code > compiles and works, even on Windows XP, even using Trestle, > FormsVBT, NetObj, cross-platform pickles (e.g., pickles shared > between Windows & Unix boxes), etc.! Much of my code was originally > developed under Windows NT, so I think it is a tribute to the > original language developers that my code and their compiler work > through various OS version upgrades (NT, 2000, XP) and changes to > the underlying C/C++ compilers used to build the core components. Ah well, Windows is a somewhat special topic. I even haven't a system here for tests, and most of the other contributors don't use it either. I was of the opinion that Jay Krell had fixes or workarounds for most current problems (except for the missing LONGINT support), but I haven't tried his distribution archives yet. It would indeed be very helpful if we could setup regression tests on Windows, too. As for the stability and interoperability, this is a very complex requirement that needs much care and testing. It is difficult to achieve in an open source project, at least in one with so few contributors. I'm sure Critical Mass did an excellent job on this, but it's been a commercial company with other organization and resources. We'll have to become better in this respect step by step. It would also be possible to define a group of reviewers for every change, but I doubt that there would be enough competent volunteers, and I'm afraid that it would rather repress development of CM3. And we really need to have development, as the underlying systems and techniques change and we need to adapt to that. So I'd vote for free commits for everybody, as long as there are not too many contributors, and setup of continually improved regression testing. And we don't need to worry, as all changes can be reverted; we won't lose development history with CVS. > I would appreciate constructive feedback on this topic. I hope this has been constructive enough, Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From hosking at cs.purdue.edu Fri Jan 4 22:17:19 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 4 Jan 2008 16:17:19 -0500 Subject: [M3devel] M3 concerns In-Reply-To: <20080104221059.uwf80xrms0gw8880@mail.elegosoft.com> References: <477B7629.1E75.00D7.1@scires.com> <20080104221059.uwf80xrms0gw8880@mail.elegosoft.com> Message-ID: <063F2D47-D837-4E11-9001-D152527E8694@cs.purdue.edu> My comments embedded: On Jan 4, 2008, at 4:10 PM, Olaf Wagner wrote: > Quoting Randy Coleburn : > >> For example, I've tried to get cm3 working for me on Windows XP >> several times. I still can't seem to get the "current" system to >> build correctly on XP. In the past, I have on occasion gotten >> the "system" to build, but then some of my programs don't work >> correctly when rebuilt using the new cm3. Thus, some changes >> somewhere have "broken" my code, yet all of my code uses the >> "safe" subset of the language. If I go back to my old reliable >> cm3 version 4.1 (the last one put out before Critical Mass, Inc. >> threw in the towel), my code compiles and works, even on Windows >> XP, even using Trestle, FormsVBT, NetObj, cross-platform pickles >> (e.g., pickles shared between Windows & Unix boxes), etc.! Much >> of my code was originally developed under Windows NT, so I think >> it is a tribute to the original language developers that my code >> and their compiler work through various OS version upgrades (NT, >> 2000, XP) and changes to the underlying C/C++ compilers used to >> build the core components. > > Ah well, Windows is a somewhat special topic. I even haven't a system > here for tests, and most of the other contributors don't use it > either. > I was of the opinion that Jay Krell had fixes or workarounds for most > current problems (except for the missing LONGINT support), but I > haven't > tried his distribution archives yet. It would indeed be very helpful > if we could setup regression tests on Windows, too. LONGINT = INTEGER on Windows, which is fine as far as it goes (everything builds appropriately), but not particularly useful. > As for the stability and interoperability, this is a very complex > requirement that needs much care and testing. It is difficult to > achieve > in an open source project, at least in one with so few contributors. > I'm sure Critical Mass did an excellent job on this, but it's been > a commercial company with other organization and resources. We'll > have to become better in this respect step by step. > > It would also be possible to define a group of reviewers for every > change, but I doubt that there would be enough competent volunteers, > and I'm afraid that it would rather repress development of CM3. > And we really need to have development, as the underlying systems and > techniques change and we need to adapt to that. So I'd vote for > free commits for everybody, as long as there are not too many > contributors, and setup of continually improved regression testing. > And we don't need to worry, as all changes can be reverted; we won't > lose development history with CVS. One option is to have moderated commits for non-core developers. After someone has earned the trust of the core developers they can be elected as a member of the core team. This approach is used with the Jikes RVM (www.jikesrvm.org). From jayk123 at hotmail.com Fri Jan 4 22:26:08 2008 From: jayk123 at hotmail.com (Jay) Date: Fri, 4 Jan 2008 21:26:08 +0000 Subject: [M3devel] PPC_LINUX breaks In-Reply-To: References: <20080104141523.GC1459@ted.stsp.lan> <65C183A8-6102-49E9-9C38-8D59C966E42D@cs.purdue.edu> Message-ID: [redundant] ok, I commited fixes for what I have seen so far. There was no delete, though probably changes -- sigset changes from int to 1024 bits for example, or somesuch. I'm sure you all see the commits. Given that PPC_LINUX still uses usermode threads, could have "that" problem, we'll see.. Gotta go for a while now. - Jay From: jayk123 at hotmail.com To: hosking at cs.purdue.edu; stsp at elego.de CC: m3devel at elegosoft.com Subject: RE: [M3devel] PPC_LINUX breaks Date: Fri, 4 Jan 2008 20:45:06 +0000 I'm confused here on what got deleted. I keep seeing it present. I swear I saw the diff though.. :( Browing CVS is such a pain. - Jay From: jayk123 at hotmail.com To: hosking at cs.purdue.edu; stsp at elego.de Date: Fri, 4 Jan 2008 19:58:45 +0000 CC: m3devel at elegosoft.com Subject: Re: [M3devel] PPC_LINUX breaks I figured out a bunch here. a) the diffs I showed. b) "nip" is "next instruction pointer"; that's what you want in the SegV function. And the last parameter should be void_star instead of int. You can use like pt_regs.nip for the old definition or uc_regs.gprregs[PT_NIP] for the new definition. I have diffs here. c) Usignal.i3 had the stuff vtalarm stuff removed, which PPC_LINUX still uses, "POSIX threads" vs. "PThreads" (oh the names..), though perhaps broken by setjmp/longjmp "scrambling". Is it possible to break up an interface into linux-common/foo.i3 linux-ppc/foo.i3 I think not. Shall we just go ahead and translate LINUX_PPC pthread.h into Modula-3? (Btw, doesn't anyone find all this header rewriting sleazy? Or they have to maintain compat anyway so no problem?) The error messages are poor. Let's say I.T does not exist. VAR x : I.T; (* no error *) x.foo = bar; (* "unknown qualification" *) FROM I IMPORT T; (* "T not exported" -- better, but should say T does not exist I was fumbling around with needing a module to say "EXPORTS" or to capitalize the Interface directive in m3makefile, neither of which seemed right *) - Jay > From: hosking at cs.purdue.edu > Date: Fri, 4 Jan 2008 09:43:31 -0500 > To: stsp at elego.de > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] PPC_LINUX breaks > > Has anyone built PPC_LINUX? I've never tried. > > On Jan 4, 2008, at 9:15 AM, Stefan Sperling wrote: > > > On Thu, Jan 03, 2008 at 10:09:22PM +0000, Jay wrote: > >> > >> I can't build PPC_LINUX. > > > > It's been broken at least since the 5.4 release was made. > > > > Back then I failed to build it, and we decided to drop > > it from the 5.4 release. It needs fixing. > > > > -- > > Stefan Sperling Software Developer > > elego Software Solutions GmbH HRB 77719 > > Gustav-Meyer-Allee 25, Gebaeude 12 Tel: +49 30 23 45 86 96 > > 13355 Berlin Fax: +49 30 23 45 86 95 > > http://www.elego.de Geschaeftsfuehrer: Olaf Wagner > Share life as it happens with the new Windows Live. Start sharing! Share life as it happens with the new Windows Live. Start sharing! _________________________________________________________________ Put your friends on the big screen with Windows Vista? + Windows Live?. http://www.microsoft.com/windows/shop/specialoffers.mspx?ocid=TXT_TAGLM_CPC_MediaCtr_bigscreen_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Fri Jan 4 22:32:52 2008 From: jayk123 at hotmail.com (Jay) Date: Fri, 4 Jan 2008 21:32:52 +0000 Subject: [M3devel] Darwin upgrade/fingerprint error In-Reply-To: References: <20080104141523.GC1459@ted.stsp.lan> <65C183A8-6102-49E9-9C38-8D59C966E42D@cs.purdue.edu> Message-ID: Starting with an older release on PPC_DARWIN and running upgrade.sh, I keep getting: === package /dev2/cm3/m3-sys/m3middle === +++ cm3 -build -DROOT='/dev2/cm3' -DCM3_VERSION_TEXT='d5.5.1' -DCM3_VERSION_NUMBER='050501' -DCM3_LAST_CHANGED='2007-12-30' && cm3 -ship -DROOT='/dev2/cm3' -DCM3_VERSION_TEXT='d5.5.1' -DCM3_VERSION_NUMBER='050501' -DCM3_LAST_CHANGED='2007-12-30' +++ --- building in PPC_DARWIN --- ignoring ../src/m3overrides stale imports -> compiling CoffTime.m3 stale imports -> compiling M3Process.i3 stale imports -> compiling M3Process.m3 stale imports -> compiling TFloat.m3 Fatal Error: bad version stamps: TFloat.m3 version stamp mismatch: TargetMap.Float_types <31f4d45a27120488> => TFloat.m3 <663449bb704e9c85> => TargetMap.i3 *** execution of failed *** I assume this will be fixed by: ijayk:/dev2/cm3/scripts jay$ cvs diff upgrade.sh Index: upgrade.sh =================================================================== RCS file: /usr/cvs/cm3/scripts/upgrade.sh,v retrieving revision 1.4 diff -r1.4 upgrade.sh 52a53,55 > echo "$ROOT/scripts/do-pkg.sh" "$@" "realclean ${P}" > "$ROOT/scripts/do-pkg.sh" "$@" "realclean" ${P} || exit 1 > 58a62,64 > echo "$ROOT/scripts/do-cm3-core.sh" "$@" "realclean" > "$ROOT/scripts/do-cm3-core.sh" "$@" "realclean" || exit 1 > Will that really harm/slow anyone's workflow? In fact, notice how the older upgrade, while broken for other reasons, did this dance with upgrading and restoring the pkg store. win\upgrade.cmd still does. Something to consider.. (And I realize that backup/restore of install/pkg is different than realclean of root/*, so maybe that diff is not the fix.) Though it is a problem to manage the versions, in doing the backup/restore. Perhaps this all falls under the heading of -- not worth automating, people know what they are doing, else they can pickup a current binary distribution?? I'll get something working locally no doubt, I don't need any further help. :) (Though past help has helped shed light here, the local/global/ship thing is still just a tad vague to me and I'm just slightly unconvinced it has to be this way, but probably it does, what with necessary circularities between compiler and runtime, building with an older compiler and all that...) - Jay _________________________________________________________________ Share life as it happens with the new Windows Live. http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Fri Jan 4 22:51:48 2008 From: jayk123 at hotmail.com (Jay) Date: Fri, 4 Jan 2008 21:51:48 +0000 Subject: [M3devel] Darwin upgrade/fingerprint error In-Reply-To: References: <20080104141523.GC1459@ted.stsp.lan> <65C183A8-6102-49E9-9C38-8D59C966E42D@cs.purdue.edu> Message-ID: (probably OMIT_GCC=1 on the second clean and build; I assume it has no dependency into the tree and it'd just be building the same thing a second time, slowly) From: jayk123 at hotmail.com To: m3devel at elegosoft.com Date: Fri, 4 Jan 2008 21:32:52 +0000 Subject: [M3devel] Darwin upgrade/fingerprint error Starting with an older release on PPC_DARWIN and running upgrade.sh, I keep getting: === package /dev2/cm3/m3-sys/m3middle === +++ cm3 -build -DROOT='/dev2/cm3' -DCM3_VERSION_TEXT='d5.5.1' -DCM3_VERSION_NUMBER='050501' -DCM3_LAST_CHANGED='2007-12-30' && cm3 -ship -DROOT='/dev2/cm3' -DCM3_VERSION_TEXT='d5.5.1' -DCM3_VERSION_NUMBER='050501' -DCM3_LAST_CHANGED='2007-12-30' +++ --- building in PPC_DARWIN --- ignoring ../src/m3overrides stale imports -> compiling CoffTime.m3 stale imports -> compiling M3Process.i3 stale imports -> compiling M3Process.m3 stale imports -> compiling TFloat.m3 Fatal Error: bad version stamps: TFloat.m3 version stamp mismatch: TargetMap.Float_types <31f4d45a27120488> => TFloat.m3 <663449bb704e9c85> => TargetMap.i3 *** execution of failed *** I assume this will be fixed by: ijayk:/dev2/cm3/scripts jay$ cvs diff upgrade.sh Index: upgrade.sh =================================================================== RCS file: /usr/cvs/cm3/scripts/upgrade.sh,v retrieving revision 1.4 diff -r1.4 upgrade.sh 52a53,55 > echo "$ROOT/scripts/do-pkg.sh" "$@" "realclean ${P}" > "$ROOT/scripts/do-pkg.sh" "$@" "realclean" ${P} || exit 1 > 58a62,64 > echo "$ROOT/scripts/do-cm3-core.sh" "$@" "realclean" > "$ROOT/scripts/do-cm3-core.sh" "$@" "realclean" || exit 1 > Will that really harm/slow anyone's workflow? In fact, notice how the older upgrade, while broken for other reasons, did this dance with upgrading and restoring the pkg store. win\upgrade.cmd still does. Something to consider.. (And I realize that backup/restore of install/pkg is different than realclean of root/*, so maybe that diff is not the fix.) Though it is a problem to manage the versions, in doing the backup/restore. Perhaps this all falls under the heading of -- not worth automating, people know what they are doing, else they can pickup a current binary distribution?? I'll get something working locally no doubt, I don't need any further help. :) (Though past help has helped shed light here, the local/global/ship thing is still just a tad vague to me and I'm just slightly unconvinced it has to be this way, but probably it does, what with necessary circularities between compiler and runtime, building with an older compiler and all that...) - Jay Share life as it happens with the new Windows Live. Start sharing! _________________________________________________________________ Get the power of Windows + Web with the new Windows Live. http://www.windowslive.com?ocid=TXT_TAGHM_Wave2_powerofwindows_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Sat Jan 5 01:13:35 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 05 Jan 2008 01:13:35 +0100 Subject: [M3devel] M3 concerns In-Reply-To: <063F2D47-D837-4E11-9001-D152527E8694@cs.purdue.edu> References: <477B7629.1E75.00D7.1@scires.com> <20080104221059.uwf80xrms0gw8880@mail.elegosoft.com> <063F2D47-D837-4E11-9001-D152527E8694@cs.purdue.edu> Message-ID: <20080105011335.n767h3zbz4gcgk4k@mail.elegosoft.com> Quoting Tony Hosking : > My comments embedded: > > On Jan 4, 2008, at 4:10 PM, Olaf Wagner wrote: >> Ah well, Windows is a somewhat special topic. I even haven't a system >> here for tests, and most of the other contributors don't use it either. >> I was of the opinion that Jay Krell had fixes or workarounds for most >> current problems (except for the missing LONGINT support), but I haven't >> tried his distribution archives yet. It would indeed be very helpful >> if we could setup regression tests on Windows, too. > > LONGINT = INTEGER on Windows, which is fine as far as it goes > (everything builds appropriately), but not particularly useful. I know that it should run this way, but pickles for example wouldn't be exchangeable then, would they? Has anybody tested pickle support for LONGINT yet? >> It would also be possible to define a group of reviewers for every >> change, but I doubt that there would be enough competent volunteers, >> and I'm afraid that it would rather repress development of CM3. >> And we really need to have development, as the underlying systems and >> techniques change and we need to adapt to that. So I'd vote for >> free commits for everybody, as long as there are not too many >> contributors, and setup of continually improved regression testing. >> And we don't need to worry, as all changes can be reverted; we won't >> lose development history with CVS. > > One option is to have moderated commits for non-core developers. After > someone has earned the trust of the core developers they can be elected > as a member of the core team. This approach is used with the Jikes RVM > (www.jikesrvm.org). I wouldn't object to such a policy, though I don't really think that it is currently necessary. But if more active committers do prefer it, we can set up the necessary commit checks. I assume that Randy Coleburn and you are in favour of restricted commits? What about the others? Who would volunteer to review commits from other people? Would this be a responsibility inherited by the unrestricted access? Should we allow commits to branches and only restrict access to the main line? Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jayk123 at hotmail.com Sat Jan 5 02:04:47 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 5 Jan 2008 01:04:47 +0000 Subject: [M3devel] M3 concerns In-Reply-To: <20080105011335.n767h3zbz4gcgk4k@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> Message-ID: I oppose most red tape. However branching can be good, as long as there are frequent merges (between once a week and once a month..well, those timelines are based on other contexts, in this context, I don't know) and automated testing/buildmonkeys/tinderboxes. That is, if I'm in a ghetto branch, I loose both the pressure not to break things, because few/nobody else is in the branch, and the feedback loop of hearing that I've broken someone, so automation would be nice to replace that. I am not experienced with CVS though. I don't know how to setup or merge branches. Even browsing history I find painful, in one branch. Perforce I am quite familiar with. Subversion I learned enough about to know it doesn't suffice, so I'm leary of CVS, which is supposedly in all ways worse. In particular, Subversion doesn't track which changes have been merged from one branch to another. Whereas in Perforce that is a key feature of the system. Amazing that Subversion doesn't do it, but it is near the top of their wishlist. This is a small project. I haven't yet heard of anyone getting one of my possibly "in between" changes and being broken, and even when I checkin frequently, that doesn't mean any one state was broken or wrong. I haven't tested anything with Pickes. One set of tests I found failed all over the place, the m3tests stuff, floating point problems, I think a bunch of never implemented stuff on Windows around calling _fpcontrol or such (platform dependent). The system does build itself, the compiler and "std" packages. I consider that a pretty good start. I realize you can always do more, more and less obvious. There's probably no threading in the compiler, and maybe not even any garbage collection, nor any pickles. I'll look what Olaf commited over the weekend.. Bah humbug and happy new year, :) - Jay > Date: Sat, 5 Jan 2008 01:13:35 +0100> From: wagner at elegosoft.com> To: hosking at cs.purdue.edu; m3devel at elegosoft.com> CC: m3-support at elegosoft.com> Subject: Re: [M3devel] M3 concerns> > Quoting Tony Hosking :> > > My comments embedded:> >> > On Jan 4, 2008, at 4:10 PM, Olaf Wagner wrote:> > >> Ah well, Windows is a somewhat special topic. I even haven't a system> >> here for tests, and most of the other contributors don't use it either.> >> I was of the opinion that Jay Krell had fixes or workarounds for most> >> current problems (except for the missing LONGINT support), but I haven't> >> tried his distribution archives yet. It would indeed be very helpful> >> if we could setup regression tests on Windows, too.> >> > LONGINT = INTEGER on Windows, which is fine as far as it goes> > (everything builds appropriately), but not particularly useful.> > I know that it should run this way, but pickles for example wouldn't> be exchangeable then, would they? Has anybody tested pickle support> for LONGINT yet?> > >> It would also be possible to define a group of reviewers for every> >> change, but I doubt that there would be enough competent volunteers,> >> and I'm afraid that it would rather repress development of CM3.> >> And we really need to have development, as the underlying systems and> >> techniques change and we need to adapt to that. So I'd vote for> >> free commits for everybody, as long as there are not too many> >> contributors, and setup of continually improved regression testing.> >> And we don't need to worry, as all changes can be reverted; we won't> >> lose development history with CVS.> >> > One option is to have moderated commits for non-core developers. After> > someone has earned the trust of the core developers they can be elected> > as a member of the core team. This approach is used with the Jikes RVM> > (www.jikesrvm.org).> > I wouldn't object to such a policy, though I don't really think that> it is currently necessary. But if more active committers do prefer> it, we can set up the necessary commit checks. I assume that Randy Coleburn> and you are in favour of restricted commits? What about the others?> > Who would volunteer to review commits from other people? Would this> be a responsibility inherited by the unrestricted access?> > Should we allow commits to branches and only restrict access to the> main line?> > Olaf> -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194> _________________________________________________________________ Share life as it happens with the new Windows Live. 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 Jan 5 02:22:13 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 5 Jan 2008 01:22:13 +0000 Subject: [M3devel] "crazy cross" In-Reply-To: <20080105011335.n767h3zbz4gcgk4k@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> Message-ID: You've all heard of "Canadian cross"? It is cross-building a cross-compiler.I'm sitting in Windows. I'm going to build a compiler that is going to run on Linux that is going to target Solaris.For one example. You've all seen that Apple has switches like so: gcc -arch i386 ppc ppc64 x86_64 hello.cand poof out comes a binary that runs natively on four architectures I don't like the "inconvenience" of non cross systems and having to have all the machines/OSes just to build the binaries.I realize that you hit the wall if you actually want to test the results. So cross building only gets so much.Of course I also don't want to multiply out build times for tools... Ok, well what is the possibility of: cm3 -target NT386cm3 -target NT386 -target PPC_DARWIN ? In my crazy imagination, you have: \cm3\bin\cm3.cmd %~dp0..\libexec\%processor_architecture%\%TARGET%\cm3.exe %* \cm3\bin\cm3 #!/bin/sh dirname(dirname($0))/libexec/`uname whatever`/$TARGET/cm3 $@ Thus it becomes POSSIBLE to have an n x m matrix, host x target, and be able to build"anything" from one environment. Actually the targets could all be merged into one .exe or be .dll/.sos.Except the code isn't setup for that. Interesting? I guess the hard part is the C code and linking?The Modula-3 stuff is already setup to do most of this? (partly by virtue of all that header rewriting that I labeled sleazy) - Jay _________________________________________________________________ Share life as it happens with the new Windows Live. http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Sat Jan 5 02:28:46 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 5 Jan 2008 01:28:46 +0000 Subject: [M3devel] NT386GNU? In-Reply-To: <20080105011335.n767h3zbz4gcgk4k@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> Message-ID: I assume NT386GNU remains very interesting to folks. Right? Anyone know what's the deal with it? Little work? Lots of work? It'd net LONGINT at least. I realize you'd need sh/awk/sed/gmake/etc., and ld. You'd start by installing mingwin or cygwin. And they (or one) would likely be required for all users, at least for ld and some libs.I assume cygwin/mingwin have long since merged to mainline. I'll try to look into it..... - Jay _________________________________________________________________ Get the power of Windows + Web with the new Windows Live. http://www.windowslive.com?ocid=TXT_TAGHM_Wave2_powerofwindows_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: From hendrik at topoi.pooq.com Sat Jan 5 02:33:07 2008 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Fri, 4 Jan 2008 20:33:07 -0500 Subject: [M3devel] 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> Message-ID: <20080105013307.GB5064@topoi.pooq.com> On Sat, Jan 05, 2008 at 01:04:47AM +0000, Jay wrote: > I oppose most red tape. > > However branching can be good, as long as there are frequent merges > (between once a week and once a month..well, those timelines are based > on other contexts, in this context, I don't know) and automated > testing/buildmonkeys/tinderboxes. That is, if I'm in a ghetto branch, > I loose both the pressure not to break things, because few/nobody else > is in the branch, and the feedback loop of hearing that I've broken > someone, so automation would be nice to replace that. Distributed revision systems have completely implicit, low red-tape branching just by being distributed. > I am not experienced with CVS though. I don't know how to setup or > merge branches. Even browsing history I find painful, in one branch. > Perforce I am quite familiar with. > Subversion I learned enough about to know it doesn't suffice, so I'm > leary of CVS, which is supposedly in all ways worse. gravityboy (http://gravityboy.livejournal.com/39755.html) has a few things to say about people who compare svn with cvs: essentially, he says cvs is so obsolete no one should even be comparing things with it any more. Saying something is better than CVS is like saying that a new model of automatic washing machines work better than rocks by the side of the river. > In particular, Subversion doesn't track which changes have been merged > from one branch to another. Whereas in Perforce that is a key feature > of the system. Amazing that Subversion doesn't do it, but it is near > the top of their wishlist. > > This is a small project. > I haven't yet heard of anyone getting one of my possibly "in between" changes and being broken, and even when I checkin frequently, that doesn't mean any one state was broken or wrong. > > I haven't tested anything with Pickes. One set of tests I found failed all over the place, the m3tests stuff, floating point problems, I think a bunch of never implemented stuff on Windows around calling _fpcontrol or such (platform dependent). > > The system does build itself, the compiler and "std" packages. I consider that a pretty good start. > I realize you can always do more, more and less obvious. There's probably no threading in the compiler, and maybe not even any garbage collection, nor any pickles. > > I'll look what Olaf commited over the weekend.. > > Bah humbug and happy new year, :) > - Jay > > > > > Date: Sat, 5 Jan 2008 01:13:35 +0100> From: wagner at elegosoft.com> To: hosking at cs.purdue.edu; m3devel at elegosoft.com> CC: m3-support at elegosoft.com> Subject: Re: [M3devel] M3 concerns> > Quoting Tony Hosking :> > > My comments embedded:> >> > On Jan 4, 2008, at 4:10 PM, Olaf Wagner wrote:> > >> Ah well, Windows is a somewhat special topic. I even haven't a system> >> here for tests, and most of the other contributors don't use it either.> >> I was of the opinion that Jay Krell had fixes or workarounds for most> >> current problems (except for the missing LONGINT support), but I haven't> >> tried his distribution archives yet. It would indeed be very helpful> >> if we could setup regression tests on Windows, too.> >> > LONGINT = INTEGER on Windows, which is fine as far as it goes> > (everything builds appropriately), but not particularly useful.> > I know that it should run this way, but pickles for example wouldn't> be exchangeable then, would they? Has anybody tested pickle support> for LONGINT yet?> > >> It would also be possible to define a group of reviewers for every> >> change, but I doubt that there would be enough competent volunteers,> >> and I'm afraid that it would rather repress development of CM3.> >> And we really need to have development, as the underlying systems and> >> techniques change and we need to adapt to that. So I'd vote for> >> free commits for everybody, as long as there are not too many> >> contributors, and setup of continually improved regression testing.> >> And we don't need to worry, as all changes can be reverted; we won't> >> lose development history with CVS.> >> > One option is to have moderated commits for non-core developers. After> > someone has earned the trust of the core developers they can be elected> > as a member of the core team. This approach is used with the Jikes RVM> > (www.jikesrvm.org).> > I wouldn't object to such a policy, though I don't really think that> it is currently necessary. But if more active committers do prefer> it, we can set up the necessary commit checks. I assume that Randy Coleburn> and you are in favour of restricted commits? What about the others?> > Who would volunteer to review commits from other people? Would this> be a responsibility inherited by the unrestricted access?> > Should we allow commits to branches and only restrict access to the> main line?> > Olaf> -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194> > _________________________________________________________________ > Share life as it happens with the new Windows Live. > http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_012008 From hendrik at topoi.pooq.com Sat Jan 5 02:17:19 2008 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Fri, 4 Jan 2008 20:17:19 -0500 Subject: [M3devel] M3 concerns In-Reply-To: <20080105011335.n767h3zbz4gcgk4k@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> Message-ID: <20080105011719.GA5064@topoi.pooq.com> On Sat, Jan 05, 2008 at 01:13:35AM +0100, Olaf Wagner wrote: > Quoting Tony Hosking : > > >My comments embedded: > > > >On Jan 4, 2008, at 4:10 PM, Olaf Wagner wrote: > > >>Ah well, Windows is a somewhat special topic. I even haven't a system > >>here for tests, and most of the other contributors don't use it either. > >>I was of the opinion that Jay Krell had fixes or workarounds for most > >>current problems (except for the missing LONGINT support), but I haven't > >>tried his distribution archives yet. It would indeed be very helpful > >>if we could setup regression tests on Windows, too. > > > >LONGINT = INTEGER on Windows, which is fine as far as it goes > >(everything builds appropriately), but not particularly useful. > > I know that it should run this way, but pickles for example wouldn't > be exchangeable then, would they? Has anybody tested pickle support > for LONGINT yet? > > >>It would also be possible to define a group of reviewers for every > >>change, but I doubt that there would be enough competent volunteers, > >>and I'm afraid that it would rather repress development of CM3. > >>And we really need to have development, as the underlying systems and > >>techniques change and we need to adapt to that. So I'd vote for > >>free commits for everybody, as long as there are not too many > >>contributors, and setup of continually improved regression testing. > >>And we don't need to worry, as all changes can be reverted; we won't > >>lose development history with CVS. > > > >One option is to have moderated commits for non-core developers. After > >someone has earned the trust of the core developers they can be elected > >as a member of the core team. This approach is used with the Jikes RVM > >(www.jikesrvm.org). > > I wouldn't object to such a policy, though I don't really think that > it is currently necessary. But if more active committers do prefer > it, we can set up the necessary commit checks. I assume that Randy Coleburn > and you are in favour of restricted commits? What about the others? > > Who would volunteer to review commits from other people? Would this > be a responsibility inherited by the unrestricted access? > > Should we allow commits to branches and only restrict access to the > main line? The philosophy among the monotone developers (who use monotone as their revision control system) is to separate committing from certification. Anyone can commit a revision, which cen then be looked at, discussed, revised a few times, and if found worthy, certified. It gives them an informal kind of flexibility for small changes. Because monotone is a distributed revision conttrol system, they frequently have multiple heads in a branch (I prefer to call them leaves, or buds ready for the growth of new twigs). It's usualy to check out the most recent certified revision when you start a new bit of development. But being stuck with multiple heads, and having their system understand multiple heads, gives them a kind of flexibility that reflects the chaotic structure of real-sorld development. Official branches can also exist. If so, it's usually done by certifying revisions with different branch certificates. Botice that one same revision of one same file can be on several branches with no problems at all. I fact, it's perfectly possible to discover that development that has gone on for a few weeks really belongs on a different branch and so certify it after the fact. Now I'm not telling you to convert your whole development system to monotone, though I might advise it if you were looking for a new revision-control system. Such a changeover could involve substantial disruption. But looking at how it's done there might suggest possibilities after you map it hack to what you are using. The separation of commit from certify seems to be quite useful. -- hendrik From rcoleburn at scires.com Sat Jan 5 03:12:24 2008 From: rcoleburn at scires.com (Randy Coleburn) Date: Fri, 04 Jan 2008 21:12:24 -0500 Subject: [M3devel] 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> Message-ID: <477EA137.1E75.00D7.1@scires.com> Given the current situation, I'm not sure that moderated commits are practical. I think the best route is to get enough tests in place so that all developers can run a regression test suite BEFORE committing changes. Having an automated scoreboard would also help point out where things are broken and need fixing so that folks can volunteer to help. I'll try to find time again this weekend to do a build of cm3 on Windows XP again. If one goes to the website, there seems to be several choices for getting started, so I need some advice on the best way to move forward. 1. Get current sources from head branch and try to build from scratch (after first installing free Microsoft Visual C/C++ tools). 2. Get an older variant (5.2.6, 4.1, etc.) and try to use it to build the new current sources from CVS. 3. Get Jay's d5.5.0 min Win32 and use it to build the current sources from CVS. 4. ?? I know that there are some scripts that have been built to help in building things. One thing that would be helpful I think is to have a text file that lists the correct build sequence order for all packages in the repository. I know that some packages may not build on every platform, but if we keep this text file up-to-date, it would help folks as they work on scripts, etc. Also, I seem to recall that in the past that for some of the core packages, you had to build these twice in the process of getting everything up and running. Again, these facts need to be made very obvious so folks don't go down a wrong path. Once I get started on a path (1..4 above), I also need to know which of the current scripts to use in building on Windows XP to get the best results. I love the language and have been a zealous proponent of it for a long time, but we've got to make it easier for folks to get started with Modula-3. I will carefully document the steps I take in getting the system built on Windows so we can make this available to everyone. As for Jay's comment that he hasn't heard of anyone getting a "broken" version, please understand that I am not directing my comments at any one person, but rather to the system of "checks and balances" that need to be put in place for everyone. The last time I was able to get the sources and build on Windows was v5.26. That version didn't work correctly with some of my programs and I reported the problems to Olaf et al. The last time I checked out the sources and tried to build 5.40, I wound up with compiler errors. I recall some of these were related to LONGINT and some were related to the garbage collector. So yes, there was a situation where I checked out sources that represented a "broken" version in that it would not build. Thus, there are at least two types of "broken": (1) the system sources can't be built correctly, (2) the newly built system causes previously working code to misbehave when recompiled with the new system. Broken #1 should never be allowed to occur for the core system. From what Olaf said, the rule seems to be to keep broken #1 stuff in a branch and only merge it back into the main line when the broken state is resolved. Broken #2 should be avoided using regression test suites. The package status page at http://modula3.elegosoft.com/cm3/package-status.html is headed up by the title CM3 v5.1. Is this page up-to-date? It would be helpful to know where we stand wrt each package on each supported platform relative to the current source tree. Again, I think an automated scoreboard could make this possible. Sorry to ramble on so much in this post. My main interest is in getting the current sources built and running on Windows XP. As soon as I am successful, I will run tests using my code base. I have a number of programs that were built using cm3 v4.1 that are still in use. These use a lot of features, including pickles, netobj, trestle, etc. So, my tests should help uncover Broken #2 problems on Windows. Finally, once I get a working cm3 system on Windows, I'll provide the new cm3-IDE (aka Reactor) package. Regards, Randy >>> Jay 1/4/2008 8:04 PM >>> I oppose most red tape. However branching can be good, as long as there are frequent merges (between once a week and once a month..well, those timelines are based on other contexts, in this context, I don't know) and automated testing/buildmonkeys/tinderboxes. That is, if I'm in a ghetto branch, I loose both the pressure not to break things, because few/nobody else is in the branch, and the feedback loop of hearing that I've broken someone, so automation would be nice to replace that. I am not experienced with CVS though. I don't know how to setup or merge branches. Even browsing history I find painful, in one branch. Perforce I am quite familiar with. Subversion I learned enough about to know it doesn't suffice, so I'm leary of CVS, which is supposedly in all ways worse. In particular, Subversion doesn't track which changes have been merged from one branch to another. Whereas in Perforce that is a key feature of the system. Amazing that Subversion doesn't do it, but it is near the top of their wishlist. This is a small project. I haven't yet heard of anyone getting one of my possibly "in between" changes and being broken, and even when I checkin frequently, that doesn't mean any one state was broken or wrong. I haven't tested anything with Pickes. One set of tests I found failed all over the place, the m3tests stuff, floating point problems, I think a bunch of never implemented stuff on Windows around calling _fpcontrol or such (platform dependent). The system does build itself, the compiler and "std" packages. I consider that a pretty good start. I realize you can always do more, more and less obvious. There's probably no threading in the compiler, and maybe not even any garbage collection, nor any pickles. I'll look what Olaf commited over the weekend.. Bah humbug and happy new year, :) - Jay > Date: Sat, 5 Jan 2008 01:13:35 +0100 > From: wagner at elegosoft.com > To: hosking at cs.purdue.edu; m3devel at elegosoft.com > CC: m3-support at elegosoft.com > Subject: Re: [M3devel] M3 concerns > > Quoting Tony Hosking : > > > My comments embedded: > > > > On Jan 4, 2008, at 4:10 PM, Olaf Wagner wrote: > > >> Ah well, Windows is a somewhat special topic. I even haven't a system > >> here for tests, and most of the other contributors don't use it either. > >> I was of the opinion that Jay Krell had fixes or workarounds for most > >> current problems (except for the missing LONGINT support), but I haven't > >> tried his distribution archives yet. It would indeed be very helpful > >> if we could setup regression tests on Windows, too. > > > > LONGINT = INTEGER on Windows, which is fine as far as it goes > > (everything builds appropriately), but not particularly useful. > > I know that it should run this way, but pickles for example wouldn't > be exchangeable then, would they? Has anybody tested pickle support > for LONGINT yet? > > >> It would also be possible to define a group of reviewers for every > >> change, but I doubt that there would be enough competent volunteers, > >> and I'm afraid that it would rather repress development of CM3. > >> And we really need to have development, as the underlying systems and > >> techniques change and we need to adapt to that. So I'd vote for > >> free commits for everybody, as long as there are not too many > >> contributors, and setup of continually improved regression testing. > >> And we don't need to worry, as all changes can be reverted; we won't > >> lose development history with CVS. > > > > One option is to have moderated commits for non-core developers. After > > someone has earned the trust of the core developers they can be elected > > as a member of the core team. This approach is used with the Jikes RVM > > (www.jikesrvm.org). > > I wouldn't object to such a policy, though I don't really think that > it is currently necessary. But if more active committers do prefer > it, we can set up the necessary commit checks. I assume that Randy Coleburn > and you are in favour of restricted commits? What about the others? > > Who would volunteer to review commits from other people? Would this > be a responsibility inherited by the unrestricted access? > > Should we allow commits to branches and only restrict access to the > main line? > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > Share life as it happens with the new Windows Live. Start sharing! ( 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 Jan 5 05:24:17 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 5 Jan 2008 04:24:17 +0000 Subject: [M3devel] M3 concerns In-Reply-To: <477EA137.1E75.00D7.1@scires.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> <477EA137.1E75.00D7.1@scires.com> Message-ID: Anything that was broken in 5.2.6 is "probably" still broken."Probably" as in that *I* haven't fixed much.Not that *I* am a big deal or anything.Other folks might have fixed stuff. There's been some talk about GUI stuff and not much progress.I'm not much into GUI programming, though I can't standnot having a good GUI (hypocrite I am!) The build stuff, yes and no. There isn't QUITE a canonical build order it turns out.It's circular. I'll explain. I agree work is needed here though.I put forward a very lame candiate for improvement here inscripts\python\pylib.py where at least all the "filters" are in one place.Now any of scripts\python\do*.py can ask for whatever, no need toknow what works on what platform, and the filtering is centralized.The ordering is not. Hey, that's easy.But still, my representation is wrong. It should be a more generic textformat and less actual Python code. Except that there isn't one ordering. I will explain in a sec. For your options 1-4, well, hey, I've endeavored to keep multiple options working.Don't be confused. Just pick one. :) Specifically, you can start with 5.2.6 and run scripts\win\upgrade.It WAS broken recently, related to LONGINT, but it is fixed now.(There isn't yet scripts\python\upgrade, but I promise there will be. :) ) Or you can take my 5.5.0 distribution, and run "anything". I would also recommend you take the exact checked in config file.m3-sys\cminstall\src\config\NT386.It shouldn't require any edits. Feel free to read it, and consider editing it,but it shouldn't require any. I'm assuming current source.There should be no need to "sync backward" or such.I have even endeavored to make one cm3.cfg file work with latest and older source.That is still a developing story on PPC_DARWIN and PPC_LINUX.(And "autoconf-ish" instead of "version checking" checks might be good) You should be able to use just about any Visual C++ toolset.I put in fixes to accomodate various versions.Of course, 8.0 is about the best. 9.0 is a recent release.The releases are all high quality in my experience. Ok, let me explain the ordering thing.There is a necessary circular dependency between the compiler and runtime.You cannot build the runtime unless you have a compiler.You cannot build a compiler unless you have a runtime.An older compiler cannot compile the current runtime, because of LONGINT. Or could be other reasons in the future.However if you already have a runtime (somehow), an older compiler cancompile a current compiler, and then you can use the new compiler tobuild the current runtime, and then rebuild (or at least relink),the compiler against the current runtime. (I'm not sure "compile" and "link"apply per se in Modula-3, I'm not sure it builds in quite the traditionalway.) scripts\win\make-dist and scripts\win\upgrade both take care of this.They can both start with a 5.2.6 compiler/runtime, or a current compiler/runtime.They do waste time if starting with current.Yes, they do build the compiler twice. At some point the first computers must have been built from sticks and rocks and dirt,but once they were working, the second computer could be built with more advanced materials. In particular, the first Modula-3 compiler was probably written in C.The first C compiler was probably written in assembly. Or maybe written in C and hand compiled into assembly.The first assembler was probably hand translated into "machine code". Bootstrapping is a funny thing.Circular dependencies seem wrong, but they are necessary. Bootstrappability from earlier than 5.2 I cannot at this time vouch for.I was thinking of trying with 3.6 which I have and 4.1 if I can find my CD.But it might not be easy and it might be fairly pointless.Bootstrapping does tend to lead to building up and up and up and an inabilityto jump from the initial step to the latest. You do, I expect, restthe starting level from time to time. 3.6 does still build quite easily out of the box on current systems.I built it last week. :)(Only NT386.) Oh, also, the order "only" matters when you don't have a package store already and/or you are changing types. If you are only changing code, and you already have a packge store you can build in any order. When you are changing types, or don't have a package store, I believe you have to build from the bottom of the dependency graph and on up. If you ignore the compiler, the dependency graph that I have in my head is just m3core, then libm3, then everything else. The compiler, well, you get clear errors as to what is missing if you build it out of order. I'll get some ordering into scripts\python, excluding the circularity. I may be mispresenting the circularity. It's probably really m3core, libm3, then the compiler but in the bootstrapping case, you must already have m3core and libm3, from a different build. The circularity exists, but maybe in sort of different terms. You don't need the compiler's .i3 files published to build libm3/m3core, you just need a cm3.exe. - Jay Date: Fri, 4 Jan 2008 21:12:24 -0500From: rcoleburn at scires.comTo: hosking at cs.purdue.edu; m3devel at elegosoft.com; wagner at elegosoft.com; jayk123 at hotmail.comCC: m3-support at elegosoft.comSubject: Re: [M3devel] M3 concerns Given the current situation, I'm not sure that moderated commits are practical. I think the best route is to get enough tests in place so that all developers can run a regression test suite BEFORE committing changes. Having an automated scoreboard would also help point out where things are broken and need fixing so that folks can volunteer to help. I'll try to find time again this weekend to do a build of cm3 on Windows XP again. If one goes to the website, there seems to be several choices for getting started, so I need some advice on the best way to move forward. 1. Get current sources from head branch and try to build from scratch (after first installing free Microsoft Visual C/C++ tools). 2. Get an older variant (5.2.6, 4.1, etc.) and try to use it to build the new current sources from CVS. 3. Get Jay's d5.5.0 min Win32 and use it to build the current sources from CVS. 4. ?? I know that there are some scripts that have been built to help in building things. One thing that would be helpful I think is to have a text file that lists the correct build sequence order for all packages in the repository. I know that some packages may not build on every platform, but if we keep this text file up-to-date, it would help folks as they work on scripts, etc. Also, I seem to recall that in the past that for some of the core packages, you had to build these twice in the process of getting everything up and running. Again, these facts need to be made very obvious so folks don't go down a wrong path. Once I get started on a path (1..4 above), I also need to know which of the current scripts to use in building on Windows XP to get the best results. I love the language and have been a zealous proponent of it for a long time, but we've got to make it easier for folks to get started with Modula-3. I will carefully document the steps I take in getting the system built on Windows so we can make this available to everyone. As for Jay's comment that he hasn't heard of anyone getting a "broken" version, please understand that I am not directing my comments at any one person, but rather to the system of "checks and balances" that need to be put in place for everyone. The last time I was able to get the sources and build on Windows was v5.26. That version didn't work correctly with some of my programs and I reported the problems to Olaf et al. The last time I checked out the sources and tried to build 5.40, I wound up with compiler errors. I recall some of these were related to LONGINT and some were related to the garbage collector. So yes, there was a situation where I checked out sources that represented a "broken" version in that it would not build. Thus, there are at least two types of "broken": (1) the system sources can't be built correctly, (2) the newly built system causes previously working code to misbehave when recompiled with the new system. Broken #1 should never be allowed to occur for the core system. From what Olaf said, the rule seems to be to keep broken #1 stuff in a branch and only merge it back into the main line when the broken state is resolved. Broken #2 should be avoided using regression test suites. The package status page at http://modula3.elegosoft.com/cm3/package-status.html is headed up by the title CM3 v5.1. Is this page up-to-date? It would be helpful to know where we stand wrt each package on each supported platform relative to the current source tree. Again, I think an automated scoreboard could make this possible. Sorry to ramble on so much in this post. My main interest is in getting the current sources built and running on Windows XP. As soon as I am successful, I will run tests using my code base. I have a number of programs that were built using cm3 v4.1 that are still in use. These use a lot of features, including pickles, netobj, trestle, etc. So, my tests should help uncover Broken #2 problems on Windows. Finally, once I get a working cm3 system on Windows, I'll provide the new cm3-IDE (aka Reactor) package. Regards, Randy>>> Jay 1/4/2008 8:04 PM >>>I oppose most red tape. However branching can be good, as long as there are frequent merges (between once a week and once a month..well, those timelines are based on other contexts, in this context, I don't know) and automated testing/buildmonkeys/tinderboxes. That is, if I'm in a ghetto branch, I loose both the pressure not to break things, because few/nobody else is in the branch, and the feedback loop of hearing that I've broken someone, so automation would be nice to replace that. I am not experienced with CVS though. I don't know how to setup or merge branches. Even browsing history I find painful, in one branch.Perforce I am quite familiar with.Subversion I learned enough about to know it doesn't suffice, so I'm leary of CVS, which is supposedly in all ways worse.In particular, Subversion doesn't track which changes have been merged from one branch to another. Whereas in Perforce that is a key feature of the system. Amazing that Subversion doesn't do it, but it is near the top of their wishlist. This is a small project.I haven't yet heard of anyone getting one of my possibly "in between" changes and being broken, and even when I checkin frequently, that doesn't mean any one state was broken or wrong. I haven't tested anything with Pickes. One set of tests I found failed all over the place, the m3tests stuff, floating point problems, I think a bunch of never implemented stuff on Windows around calling _fpcontrol or such (platform dependent). The system does build itself, the compiler and "std" packages. I consider that a pretty good start.I realize you can always do more, more and less obvious. There's probably no threading in the compiler, and maybe not even any garbage collection, nor any pickles. I'll look what Olaf commited over the weekend.. Bah humbug and happy new year, :) - Jay > Date: Sat, 5 Jan 2008 01:13:35 +0100> From: wagner at elegosoft.com> To: hosking at cs.purdue.edu; m3devel at elegosoft.com> CC: m3-support at elegosoft.com> Subject: Re: [M3devel] M3 concerns> > Quoting Tony Hosking :> > > My comments embedded:> >> > On Jan 4, 2008, at 4:10 PM, Olaf Wagner wrote:> > >> Ah well, Windows is a somewhat special topic. I even haven't a system> >> here for tests, and most of the other contributors don't use it either.> >> I was of the opinion that Jay Krell had fixes or workarounds for most> >> current problems (except for the missing LONGINT support), but I haven't> >> tried his distribution archives yet. It would indeed be very helpful> >> if we could setup regression tests on Windows, too.> >> > LONGINT = INTEGER on Windows, which is fine as far as it goes> > (everything builds appropriately), but not particularly useful.> > I know that it should run this way, but pickles for example wouldn't> be exchangeable then, would they? Has anybody tested pickle support> for LONGINT yet?> > >> It would also be possible to define a group of reviewers for every> >> change, but I doubt that there would be enough competent volunteers,> >> and I'm afraid that it would rather repress development of CM3.> >> And we really need to have development, as the underlying systems and> >> techniques change and we need to adapt to that. So I'd vote for> >> free commits for everybody, as long as there are not too many> >> contributors, and setup of continually improved regression testing.> >> And we don't need to worry, as all changes can be reverted; we won't> >> lose development history with CVS.> >> > One option is to have moderated commits for non-core developers. After> > someone has earned the trust of the core developers they can be elected> > as a member of the core team. This approach is used with the Jikes RVM> > (www.jikesrvm.org).> > I wouldn't object to such a policy, though I don't really think that> it is currently necessary. But if more active committers do prefer> it, we can set up the necessary commit checks. I assume that Randy Coleburn> and you are in favour of restricted commits? What about the others?> > Who would volunteer to review commits from other people? Would this> be a responsibility inherited by the unrestricted access?> > Should we allow commits to branches and only restrict access to the> main line?> > Olaf> -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194> Share life as it happens with the new Windows Live. Start sharing! _________________________________________________________________ Share life as it happens with the new Windows Live. http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Sat Jan 5 05:31:03 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 5 Jan 2008 04:31:03 +0000 Subject: [M3devel] 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> <477EA137.1E75.00D7.1@scires.com> Message-ID: Randy if you want to try remote assistance or call me on the phone over the weekend, that's fine. OR, I would agree, that might be cheating. Do it yourself and pound out the good documentation, if you want. Either way. If you cheat, you can always let the next guy tough it out and update the docs. :) There is a checked in document. installation-windows.html or such, though...I'm not the best writer... 1. Get current sources from head branch and try to build from scratch (after first installing free Microsoft Visual C/C++ tools). Not possible -- er, not sufficient. You must start with an existing CM3 distribution as well..the system is written in Modula-3 after all, and CM3 doesn't currently ship the "boot" archives like Digital did, where you just need a C compiler and linker. Heck, it's "binaries" either way. CM3 ships .exes, Digital shipped .obj files. 5.5.0 or 5.2.6 will work. Anything else, I haven't tried (I'm using 5.2.4 on another platform). If you have a particular need/desire/motivation to start with 3.6 or 4.1 or whatever, let me know and I can try. Otherwise, not clear it is interesting. I don't think bootstrapping from *any* version is necessarily interesting, you have to advance sometimes, I think. - Jay From: jayk123 at hotmail.comTo: rcoleburn at scires.com; hosking at cs.purdue.edu; m3devel at elegosoft.com; wagner at elegosoft.comDate: Sat, 5 Jan 2008 04:24:17 +0000CC: m3-support at elegosoft.comSubject: Re: [M3devel] M3 concerns Anything that was broken in 5.2.6 is "probably" still broken."Probably" as in that *I* haven't fixed much.Not that *I* am a big deal or anything.Other folks might have fixed stuff.There's been some talk about GUI stuff and not much progress.I'm not much into GUI programming, though I can't standnot having a good GUI (hypocrite I am!)The build stuff, yes and no.There isn't QUITE a canonical build order it turns out.It's circular. I'll explain.I agree work is needed here though.I put forward a very lame candiate for improvement here inscripts\python\pylib.py where at least all the "filters" are in one place.Now any of scripts\python\do*.py can ask for whatever, no need toknow what works on what platform, and the filtering is centralized.The ordering is not. Hey, that's easy.But still, my representation is wrong. It should be a more generic textformat and less actual Python code.Except that there isn't one ordering. I will explain in a sec.For your options 1-4, well, hey, I've endeavored to keep multiple options working.Don't be confused. Just pick one. :)Specifically, you can start with 5.2.6 and run scripts\win\upgrade.It WAS broken recently, related to LONGINT, but it is fixed now.(There isn't yet scripts\python\upgrade, but I promise there will be. :) )Or you can take my 5.5.0 distribution, and run "anything".I would also recommend you take the exact checked in config file.m3-sys\cminstall\src\config\NT386.It shouldn't require any edits. Feel free to read it, and consider editing it,but it shouldn't require any.I'm assuming current source.There should be no need to "sync backward" or such.I have even endeavored to make one cm3.cfg file work with latest and older source.That is still a developing story on PPC_DARWIN and PPC_LINUX.(And "autoconf-ish" instead of "version checking" checks might be good)You should be able to use just about any Visual C++ toolset.I put in fixes to accomodate various versions.Of course, 8.0 is about the best. 9.0 is a recent release.The releases are all high quality in my experience.Ok, let me explain the ordering thing.There is a necessary circular dependency between the compiler and runtime.You cannot build the runtime unless you have a compiler.You cannot build a compiler unless you have a runtime.An older compiler cannot compile the current runtime, because of LONGINT. Or could be other reasons in the future.However if you already have a runtime (somehow), an older compiler cancompile a current compiler, and then you can use the new compiler tobuild the current runtime, and then rebuild (or at least relink),the compiler against the current runtime. (I'm not sure "compile" and "link"apply per se in Modula-3, I'm not sure it builds in quite the traditionalway.)scripts\win\make-dist and scripts\win\upgrade both take care of this.They can both start with a 5.2.6 compiler/runtime, or a current compiler/runtime.They do waste time if starting with current.Yes, they do build the compiler twice.At some point the first computers must have been built from sticks and rocks and dirt,but once they were working, the second computer could be built with more advanced materials.In particular, the first Modula-3 compiler was probably written in C.The first C compiler was probably written in assembly. Or maybe written in C and hand compiled into assembly.The first assembler was probably hand translated into "machine code".Bootstrapping is a funny thing.Circular dependencies seem wrong, but they are necessary.Bootstrappability from earlier than 5.2 I cannot at this time vouch for.I was thinking of trying with 3.6 which I have and 4.1 if I can find my CD.But it might not be easy and it might be fairly pointless.Bootstrapping does tend to lead to building up and up and up and an inabilityto jump from the initial step to the latest. You do, I expect, restthe starting level from time to time.3.6 does still build quite easily out of the box on current systems.I built it last week. :)(Only NT386.) Oh, also, the order "only" matters when you don't have a package store already and/or you are changing types.If you are only changing code, and you already have a packge store you can build in any order.When you are changing types, or don't have a package store, I believe you have to build from the bottom of the dependency graph and on up. If you ignore the compiler, the dependency graph that I have in my head is just m3core, then libm3, then everything else. The compiler, well, you get clear errors as to what is missing if you build it out of order. I'll get some ordering into scripts\python, excluding the circularity. I may be mispresenting the circularity. It's probably really m3core, libm3, then the compiler but in the bootstrapping case, you must already have m3core and libm3, from a different build. The circularity exists, but maybe in sort of different terms. You don't need the compiler's .i3 files published to build libm3/m3core, you just need a cm3.exe. - Jay Date: Fri, 4 Jan 2008 21:12:24 -0500From: rcoleburn at scires.comTo: hosking at cs.purdue.edu; m3devel at elegosoft.com; wagner at elegosoft.com; jayk123 at hotmail.comCC: m3-support at elegosoft.comSubject: Re: [M3devel] M3 concerns Given the current situation, I'm not sure that moderated commits are practical. I think the best route is to get enough tests in place so that all developers can run a regression test suite BEFORE committing changes. Having an automated scoreboard would also help point out where things are broken and need fixing so that folks can volunteer to help. I'll try to find time again this weekend to do a build of cm3 on Windows XP again. If one goes to the website, there seems to be several choices for getting started, so I need some advice on the best way to move forward. 1. Get current sources from head branch and try to build from scratch (after first installing free Microsoft Visual C/C++ tools). 2. Get an older variant (5.2.6, 4.1, etc.) and try to use it to build the new current sources from CVS. 3. Get Jay's d5.5.0 min Win32 and use it to build the current sources from CVS. 4. ?? I know that there are some scripts that have been built to help in building things. One thing that would be helpful I think is to have a text file that lists the correct build sequence order for all packages in the repository. I know that some packages may not build on every platform, but if we keep this text file up-to-date, it would help folks as they work on scripts, etc. Also, I seem to recall that in the past that for some of the core packages, you had to build these twice in the process of getting everything up and running. Again, these facts need to be made very obvious so folks don't go down a wrong path. Once I get started on a path (1..4 above), I also need to know which of the current scripts to use in building on Windows XP to get the best results. I love the language and have been a zealous proponent of it for a long time, but we've got to make it easier for folks to get started with Modula-3. I will carefully document the steps I take in getting the system built on Windows so we can make this available to everyone. As for Jay's comment that he hasn't heard of anyone getting a "broken" version, please understand that I am not directing my comments at any one person, but rather to the system of "checks and balances" that need to be put in place for everyone. The last time I was able to get the sources and build on Windows was v5.26. That version didn't work correctly with some of my programs and I reported the problems to Olaf et al. The last time I checked out the sources and tried to build 5.40, I wound up with compiler errors. I recall some of these were related to LONGINT and some were related to the garbage collector. So yes, there was a situation where I checked out sources that represented a "broken" version in that it would not build. Thus, there are at least two types of "broken": (1) the system sources can't be built correctly, (2) the newly built system causes previously working code to misbehave when recompiled with the new system. Broken #1 should never be allowed to occur for the core system. From what Olaf said, the rule seems to be to keep broken #1 stuff in a branch and only merge it back into the main line when the broken state is resolved. Broken #2 should be avoided using regression test suites. The package status page at http://modula3.elegosoft.com/cm3/package-status.html is headed up by the title CM3 v5.1. Is this page up-to-date? It would be helpful to know where we stand wrt each package on each supported platform relative to the current source tree. Again, I think an automated scoreboard could make this possible. Sorry to ramble on so much in this post. My main interest is in getting the current sources built and running on Windows XP. As soon as I am successful, I will run tests using my code base. I have a number of programs that were built using cm3 v4.1 that are still in use. These use a lot of features, including pickles, netobj, trestle, etc. So, my tests should help uncover Broken #2 problems on Windows. Finally, once I get a working cm3 system on Windows, I'll provide the new cm3-IDE (aka Reactor) package. Regards, Randy>>> Jay 1/4/2008 8:04 PM >>>I oppose most red tape. However branching can be good, as long as there are frequent merges (between once a week and once a month..well, those timelines are based on other contexts, in this context, I don't know) and automated testing/buildmonkeys/tinderboxes. That is, if I'm in a ghetto branch, I loose both the pressure not to break things, because few/nobody else is in the branch, and the feedback loop of hearing that I've broken someone, so automation would be nice to replace that. I am not experienced with CVS though. I don't know how to setup or merge branches. Even browsing history I find painful, in one branch.Perforce I am quite familiar with.Subversion I learned enough about to know it doesn't suffice, so I'm leary of CVS, which is supposedly in all ways worse.In particular, Subversion doesn't track which changes have been merged from one branch to another. Whereas in Perforce that is a key feature of the system. Amazing that Subversion doesn't do it, but it is near the top of their wishlist. This is a small project.I haven't yet heard of anyone getting one of my possibly "in between" changes and being broken, and even when I checkin frequently, that doesn't mean any one state was broken or wrong. I haven't tested anything with Pickes. One set of tests I found failed all over the place, the m3tests stuff, floating point problems, I think a bunch of never implemented stuff on Windows around calling _fpcontrol or such (platform dependent). The system does build itself, the compiler and "std" packages. I consider that a pretty good start.I realize you can always do more, more and less obvious. There's probably no threading in the compiler, and maybe not even any garbage collection, nor any pickles. I'll look what Olaf commited over the weekend.. Bah humbug and happy new year, :) - Jay > Date: Sat, 5 Jan 2008 01:13:35 +0100> From: wagner at elegosoft.com> To: hosking at cs.purdue.edu; m3devel at elegosoft.com> CC: m3-support at elegosoft.com> Subject: Re: [M3devel] M3 concerns> > Quoting Tony Hosking :> > > My comments embedded:> >> > On Jan 4, 2008, at 4:10 PM, Olaf Wagner wrote:> > >> Ah well, Windows is a somewhat special topic. I even haven't a system> >> here for tests, and most of the other contributors don't use it either.> >> I was of the opinion that Jay Krell had fixes or workarounds for most> >> current problems (except for the missing LONGINT support), but I haven't> >> tried his distribution archives yet. It would indeed be very helpful> >> if we could setup regression tests on Windows, too.> >> > LONGINT = INTEGER on Windows, which is fine as far as it goes> > (everything builds appropriately), but not particularly useful.> > I know that it should run this way, but pickles for example wouldn't> be exchangeable then, would they? Has anybody tested pickle support> for LONGINT yet?> > >> It would also be possible to define a group of reviewers for every> >> change, but I doubt that there would be enough competent volunteers,> >> and I'm afraid that it would rather repress development of CM3.> >> And we really need to have development, as the underlying systems and> >> techniques change and we need to adapt to that. So I'd vote for> >> free commits for everybody, as long as there are not too many> >> contributors, and setup of continually improved regression testing.> >> And we don't need to worry, as all changes can be reverted; we won't> >> lose development history with CVS.> >> > One option is to have moderated commits for non-core developers. After> > someone has earned the trust of the core developers they can be elected> > as a member of the core team. This approach is used with the Jikes RVM> > (www.jikesrvm.org).> > I wouldn't object to such a policy, though I don't really think that> it is currently necessary. But if more active committers do prefer> it, we can set up the necessary commit checks. I assume that Randy Coleburn> and you are in favour of restricted commits? What about the others?> > Who would volunteer to review commits from other people? Would this> be a responsibility inherited by the unrestricted access?> > Should we allow commits to branches and only restrict access to the> main line?> > Olaf> -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194> Share life as it happens with the new Windows Live. Start sharing! Share life as it happens with the new Windows Live. Start sharing! _________________________________________________________________ Put your friends on the big screen with Windows Vista? + Windows Live?. http://www.microsoft.com/windows/shop/specialoffers.mspx?ocid=TXT_TAGLM_CPC_MediaCtr_bigscreen_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Sat Jan 5 05:41:01 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 5 Jan 2008 04:41:01 +0000 Subject: [M3devel] 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> <477EA137.1E75.00D7.1@scires.com> Message-ID: darnit -- one more thing...yeah, I know my email sucks, but you get what you pay for :) Randy asked how to build "everything". "everything" == "standard" == "std". scripts\do-cm3-std.sh scripts\win\do-cm3-std.cmd and def-std-pkgs.sh or such scripts\python\do-cm3-std.py coming soon Yeah, the scripts directory..confused me at first too. So I rewrote it... :) More data driven would be good. If someone can propose the text file format, including specifying the "filters", I can implement the cmd and Python...oh should really move on to using Modula-3 though, stick the knowledge into cm3 itself. cm3 -build libm3 m3core cm3.... Two types of broken, right -- build breaks and run breaks, static breaks and dynamic breaks. - Jay From: jayk123 at hotmail.comTo: rcoleburn at scires.com; hosking at cs.purdue.edu; m3devel at elegosoft.com; wagner at elegosoft.comDate: Sat, 5 Jan 2008 04:31:03 +0000CC: m3-support at elegosoft.comSubject: Re: [M3devel] M3 concerns Randy if you want to try remote assistance or call me on the phone over the weekend, that's fine.OR, I would agree, that might be cheating. Do it yourself and pound out the good documentation, if you want. Either way. If you cheat, you can always let the next guy tough it out and update the docs. :)There is a checked in document. installation-windows.html or such, though...I'm not the best writer... 1. Get current sources from head branch and try to build from scratch (after first installing free Microsoft Visual C/C++ tools). Not possible -- er, not sufficient. You must start with an existing CM3 distribution as well..the system is written in Modula-3 after all, and CM3 doesn't currently ship the "boot" archives like Digital did, where you just need a C compiler and linker. Heck, it's "binaries" either way. CM3 ships .exes, Digital shipped .obj files. 5.5.0 or 5.2.6 will work. Anything else, I haven't tried (I'm using 5.2.4 on another platform). If you have a particular need/desire/motivation to start with 3.6 or 4.1 or whatever, let me know and I can try. Otherwise, not clear it is interesting. I don't think bootstrapping from *any* version is necessarily interesting, you have to advance sometimes, I think. - Jay From: jayk123 at hotmail.comTo: rcoleburn at scires.com; hosking at cs.purdue.edu; m3devel at elegosoft.com; wagner at elegosoft.comDate: Sat, 5 Jan 2008 04:24:17 +0000CC: m3-support at elegosoft.comSubject: Re: [M3devel] M3 concerns Anything that was broken in 5.2.6 is "probably" still broken."Probably" as in that *I* haven't fixed much.Not that *I* am a big deal or anything.Other folks might have fixed stuff.There's been some talk about GUI stuff and not much progress.I'm not much into GUI programming, though I can't standnot having a good GUI (hypocrite I am!)The build stuff, yes and no.There isn't QUITE a canonical build order it turns out.It's circular. I'll explain.I agree work is needed here though.I put forward a very lame candiate for improvement here inscripts\python\pylib.py where at least all the "filters" are in one place.Now any of scripts\python\do*.py can ask for whatever, no need toknow what works on what platform, and the filtering is centralized.The ordering is not. Hey, that's easy.But still, my representation is wrong. It should be a more generic textformat and less actual Python code.Except that there isn't one ordering. I will explain in a sec.For your options 1-4, well, hey, I've endeavored to keep multiple options working.Don't be confused. Just pick one. :)Specifically, you can start with 5.2.6 and run scripts\win\upgrade.It WAS broken recently, related to LONGINT, but it is fixed now.(There isn't yet scripts\python\upgrade, but I promise there will be. :) )Or you can take my 5.5.0 distribution, and run "anything".I would also recommend you take the exact checked in config file.m3-sys\cminstall\src\config\NT386.It shouldn't require any edits. Feel free to read it, and consider editing it,but it shouldn't require any.I'm assuming current source.There should be no need to "sync backward" or such.I have even endeavored to make one cm3.cfg file work with latest and older source.That is still a developing story on PPC_DARWIN and PPC_LINUX.(And "autoconf-ish" instead of "version checking" checks might be good)You should be able to use just about any Visual C++ toolset.I put in fixes to accomodate various versions.Of course, 8.0 is about the best. 9.0 is a recent release.The releases are all high quality in my experience.Ok, let me explain the ordering thing.There is a necessary circular dependency between the compiler and runtime.You cannot build the runtime unless you have a compiler.You cannot build a compiler unless you have a runtime.An older compiler cannot compile the current runtime, because of LONGINT. Or could be other reasons in the future.However if you already have a runtime (somehow), an older compiler cancompile a current compiler, and then you can use the new compiler tobuild the current runtime, and then rebuild (or at least relink),the compiler against the current runtime. (I'm not sure "compile" and "link"apply per se in Modula-3, I'm not sure it builds in quite the traditionalway.)scripts\win\make-dist and scripts\win\upgrade both take care of this.They can both start with a 5.2.6 compiler/runtime, or a current compiler/runtime.They do waste time if starting with current.Yes, they do build the compiler twice.At some point the first computers must have been built from sticks and rocks and dirt,but once they were working, the second computer could be built with more advanced materials.In particular, the first Modula-3 compiler was probably written in C.The first C compiler was probably written in assembly. Or maybe written in C and hand compiled into assembly.The first assembler was probably hand translated into "machine code".Bootstrapping is a funny thing.Circular dependencies seem wrong, but they are necessary.Bootstrappability from earlier than 5.2 I cannot at this time vouch for.I was thinking of trying with 3.6 which I have and 4.1 if I can find my CD.But it might not be easy and it might be fairly pointless.Bootstrapping does tend to lead to building up and up and up and an inabilityto jump from the initial step to the latest. You do, I expect, restthe starting level from time to time.3.6 does still build quite easily out of the box on current systems.I built it last week. :)(Only NT386.) Oh, also, the order "only" matters when you don't have a package store already and/or you are changing types.If you are only changing code, and you already have a packge store you can build in any order.When you are changing types, or don't have a package store, I believe you have to build from the bottom of the dependency graph and on up. If you ignore the compiler, the dependency graph that I have in my head is just m3core, then libm3, then everything else. The compiler, well, you get clear errors as to what is missing if you build it out of order. I'll get some ordering into scripts\python, excluding the circularity. I may be mispresenting the circularity. It's probably really m3core, libm3, then the compiler but in the bootstrapping case, you must already have m3core and libm3, from a different build. The circularity exists, but maybe in sort of different terms. You don't need the compiler's .i3 files published to build libm3/m3core, you just need a cm3.exe. - Jay Date: Fri, 4 Jan 2008 21:12:24 -0500From: rcoleburn at scires.comTo: hosking at cs.purdue.edu; m3devel at elegosoft.com; wagner at elegosoft.com; jayk123 at hotmail.comCC: m3-support at elegosoft.comSubject: Re: [M3devel] M3 concerns Given the current situation, I'm not sure that moderated commits are practical. I think the best route is to get enough tests in place so that all developers can run a regression test suite BEFORE committing changes. Having an automated scoreboard would also help point out where things are broken and need fixing so that folks can volunteer to help. I'll try to find time again this weekend to do a build of cm3 on Windows XP again. If one goes to the website, there seems to be several choices for getting started, so I need some advice on the best way to move forward. 1. Get current sources from head branch and try to build from scratch (after first installing free Microsoft Visual C/C++ tools). 2. Get an older variant (5.2.6, 4.1, etc.) and try to use it to build the new current sources from CVS. 3. Get Jay's d5.5.0 min Win32 and use it to build the current sources from CVS. 4. ?? I know that there are some scripts that have been built to help in building things. One thing that would be helpful I think is to have a text file that lists the correct build sequence order for all packages in the repository. I know that some packages may not build on every platform, but if we keep this text file up-to-date, it would help folks as they work on scripts, etc. Also, I seem to recall that in the past that for some of the core packages, you had to build these twice in the process of getting everything up and running. Again, these facts need to be made very obvious so folks don't go down a wrong path. Once I get started on a path (1..4 above), I also need to know which of the current scripts to use in building on Windows XP to get the best results. I love the language and have been a zealous proponent of it for a long time, but we've got to make it easier for folks to get started with Modula-3. I will carefully document the steps I take in getting the system built on Windows so we can make this available to everyone. As for Jay's comment that he hasn't heard of anyone getting a "broken" version, please understand that I am not directing my comments at any one person, but rather to the system of "checks and balances" that need to be put in place for everyone. The last time I was able to get the sources and build on Windows was v5.26. That version didn't work correctly with some of my programs and I reported the problems to Olaf et al. The last time I checked out the sources and tried to build 5.40, I wound up with compiler errors. I recall some of these were related to LONGINT and some were related to the garbage collector. So yes, there was a situation where I checked out sources that represented a "broken" version in that it would not build. Thus, there are at least two types of "broken": (1) the system sources can't be built correctly, (2) the newly built system causes previously working code to misbehave when recompiled with the new system. Broken #1 should never be allowed to occur for the core system. From what Olaf said, the rule seems to be to keep broken #1 stuff in a branch and only merge it back into the main line when the broken state is resolved. Broken #2 should be avoided using regression test suites. The package status page at http://modula3.elegosoft.com/cm3/package-status.html is headed up by the title CM3 v5.1. Is this page up-to-date? It would be helpful to know where we stand wrt each package on each supported platform relative to the current source tree. Again, I think an automated scoreboard could make this possible. Sorry to ramble on so much in this post. My main interest is in getting the current sources built and running on Windows XP. As soon as I am successful, I will run tests using my code base. I have a number of programs that were built using cm3 v4.1 that are still in use. These use a lot of features, including pickles, netobj, trestle, etc. So, my tests should help uncover Broken #2 problems on Windows. Finally, once I get a working cm3 system on Windows, I'll provide the new cm3-IDE (aka Reactor) package. Regards, Randy>>> Jay 1/4/2008 8:04 PM >>>I oppose most red tape. However branching can be good, as long as there are frequent merges (between once a week and once a month..well, those timelines are based on other contexts, in this context, I don't know) and automated testing/buildmonkeys/tinderboxes. That is, if I'm in a ghetto branch, I loose both the pressure not to break things, because few/nobody else is in the branch, and the feedback loop of hearing that I've broken someone, so automation would be nice to replace that. I am not experienced with CVS though. I don't know how to setup or merge branches. Even browsing history I find painful, in one branch.Perforce I am quite familiar with.Subversion I learned enough about to know it doesn't suffice, so I'm leary of CVS, which is supposedly in all ways worse.In particular, Subversion doesn't track which changes have been merged from one branch to another. Whereas in Perforce that is a key feature of the system. Amazing that Subversion doesn't do it, but it is near the top of their wishlist. This is a small project.I haven't yet heard of anyone getting one of my possibly "in between" changes and being broken, and even when I checkin frequently, that doesn't mean any one state was broken or wrong. I haven't tested anything with Pickes. One set of tests I found failed all over the place, the m3tests stuff, floating point problems, I think a bunch of never implemented stuff on Windows around calling _fpcontrol or such (platform dependent). The system does build itself, the compiler and "std" packages. I consider that a pretty good start.I realize you can always do more, more and less obvious. There's probably no threading in the compiler, and maybe not even any garbage collection, nor any pickles. I'll look what Olaf commited over the weekend.. Bah humbug and happy new year, :) - Jay > Date: Sat, 5 Jan 2008 01:13:35 +0100> From: wagner at elegosoft.com> To: hosking at cs.purdue.edu; m3devel at elegosoft.com> CC: m3-support at elegosoft.com> Subject: Re: [M3devel] M3 concerns> > Quoting Tony Hosking :> > > My comments embedded:> >> > On Jan 4, 2008, at 4:10 PM, Olaf Wagner wrote:> > >> Ah well, Windows is a somewhat special topic. I even haven't a system> >> here for tests, and most of the other contributors don't use it either.> >> I was of the opinion that Jay Krell had fixes or workarounds for most> >> current problems (except for the missing LONGINT support), but I haven't> >> tried his distribution archives yet. It would indeed be very helpful> >> if we could setup regression tests on Windows, too.> >> > LONGINT = INTEGER on Windows, which is fine as far as it goes> > (everything builds appropriately), but not particularly useful.> > I know that it should run this way, but pickles for example wouldn't> be exchangeable then, would they? Has anybody tested pickle support> for LONGINT yet?> > >> It would also be possible to define a group of reviewers for every> >> change, but I doubt that there would be enough competent volunteers,> >> and I'm afraid that it would rather repress development of CM3.> >> And we really need to have development, as the underlying systems and> >> techniques change and we need to adapt to that. So I'd vote for> >> free commits for everybody, as long as there are not too many> >> contributors, and setup of continually improved regression testing.> >> And we don't need to worry, as all changes can be reverted; we won't> >> lose development history with CVS.> >> > One option is to have moderated commits for non-core developers. After> > someone has earned the trust of the core developers they can be elected> > as a member of the core team. This approach is used with the Jikes RVM> > (www.jikesrvm.org).> > I wouldn't object to such a policy, though I don't really think that> it is currently necessary. But if more active committers do prefer> it, we can set up the necessary commit checks. I assume that Randy Coleburn> and you are in favour of restricted commits? What about the others?> > Who would volunteer to review commits from other people? Would this> be a responsibility inherited by the unrestricted access?> > Should we allow commits to branches and only restrict access to the> main line?> > Olaf> -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194> Share life as it happens with the new Windows Live. Start sharing! Share life as it happens with the new Windows Live. Start sharing! Put your friends on the big screen with Windows Vista? + Windows Live?. Start now! _________________________________________________________________ Put your friends on the big screen with Windows Vista? + Windows Live?. http://www.microsoft.com/windows/shop/specialoffers.mspx?ocid=TXT_TAGLM_CPC_MediaCtr_bigscreen_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: From lemming at henning-thielemann.de Sat Jan 5 09:44:40 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Sat, 05 Jan 2008 09:44:40 +0100 (CET) Subject: [M3devel] M3 concerns In-Reply-To: <20080105013307.GB5064@topoi.pooq.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> <20080105013307.GB5064@topoi.pooq.com> Message-ID: On Fri, 4 Jan 2008 hendrik at topoi.pooq.com wrote: > gravityboy (http://gravityboy.livejournal.com/39755.html) has a few > things to say about people who compare svn with cvs: essentially, he > says cvs is so obsolete no one should even be comparing things with it > any more. Saying something is better than CVS is like saying that > a new model of automatic washing machines work better than rocks by the > side of the river. When I was moving from CVS to Darcs, a popular distributed versioning software in the Haskell world, one of my colleagues gave a talk about RCS. I wondered why he still uses and promotes RCS, when even CVS was too restricted for me. However after the talk many of my colleagues seconded his attitude, because CVS was already too complicated for them. To be honest, I still use CVS for small projects, when other machines are invoked, where I can't install Darcs. CVS has the charme, that you have the versioning data in a readable form. You could even repair small damages manually, if it is necessary. From wagner at elegosoft.com Sat Jan 5 13:49:52 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 05 Jan 2008 13:49:52 +0100 Subject: [M3devel] NT386GNU? 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> Message-ID: <20080105134952.6kvyefcy8c0gswkg@mail.elegosoft.com> Quoting Jay : > I assume NT386GNU remains very interesting to folks. Right? > Anyone know what's the deal with it? > Little work? Lots of work? > It'd net LONGINT at least. > I realize you'd need sh/awk/sed/gmake/etc., and ld. > You'd start by installing mingwin or cygwin. > And they (or one) would likely be required for all users, at least > for ld and some libs.I assume cygwin/mingwin have long since > merged to mainline. > I'll try to look into it..... CM3 never had a working NT386GNU target, though PM3 had. It would be great, as this is a POSIX system running on Windows (based on Cygwin32). Some years ago, when I still had a working NT system, I could never get cm3cg backends based on anything above gcc 2.95 to work on Cygwin. They always produced segmentation violations. But I haven't tried for many years now, so things may have changed. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Jan 5 14:32:35 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 05 Jan 2008 14:32:35 +0100 Subject: [M3devel] M3 concerns In-Reply-To: <20080105011719.GA5064@topoi.pooq.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> Message-ID: <20080105143235.ujed2tl3ksogws8k@mail.elegosoft.com> Discussions seem to loose their focus quiet easy on this list :-/ I'd strongly prefer if we could keep the discussion of alternative version control systems out of this. It won't help us, and you can trust this opinion as I really know many version control systems (SCCS, RCS, CVS, Subversion, ClearCase, PVCS Dimensions, Perforce, AccuRev, OpenCM, Vesta,...). I can assure you that CVS is quite adequate for the simple purposes and requirements we have. Changing will make things different, but not better, and cost a lot of efforts we should rather invest into other topics. I'd like to get back to the original topic. How do we need to improve the CM3 development process to ensure and increase the overall quality of the CM3 code base? Could everybody interested in this discussion please just comment on the following items to state his opinion: 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). Technical details should be discussed in a different thread. o Do we need / want to restrict the commit access for the CM3 code repositories? If so, only for certain areas, or for everything? This would be a distinction based on packages. Should we allow or prefer committing new code to branches and merge the resulting change sets based on reviews? (I could also contribute automatic support for creating change sets on branches, as this is part of the DCVS functionality elego developed some time ago). This would be a distinction based on code lines. Yesterday I had the impression that some members of this list would prefer some access restriction, but I'm not really sure. o I'm not sure if and how we should include the Windows target problems here. They were part of the original mail, but seem to belong to another category to me, at least have different causes. Suggestions what exactly to discuss are welcome. o To reach a conclusion on these topics, I suggest that we simply count the majority of opinions of list members that care to participate in this discussion. I'll try to summarize again after everybody has had time for consideration and has spoken up (or remained silent). I'd suggest to continue the discussion for the following week. Please try to keep comments short :-) Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Jan 5 18:06:01 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 05 Jan 2008 18:06:01 +0100 Subject: [M3devel] M3 concerns / Windows problems In-Reply-To: <477EA137.1E75.00D7.1@scires.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> <477EA137.1E75.00D7.1@scires.com> Message-ID: <20080105180601.unyynodmqswo44cs@mail.elegosoft.com> Quoting Randy Coleburn : > I'll try to find time again this weekend to do a build of cm3 on > Windows XP again. That would be great. > 3. Get Jay's d5.5.0 min Win32 and use it to build the current sources > from CVS. I'd choose this one. > I know that there are some scripts that have been built to help in > building things. One thing that would be helpful I think is to have a > text file that lists the correct build sequence order for all > packages in the repository. I know that some packages may not build on > every platform, but if we keep this text file up-to-date, it would help > folks as they work on scripts, etc. The file that lists all packages in order is scripts/def-std-pkgs.sh, though some may be missing from it. It's in Bourne shell format though. A compiler bootstrap may need another more complex order, where some packages are compiled twice at least though. The upgrade process should be automated in scripts/upgrade.sh (for most scenarios). This is due to subtle dependencies between the compiler and the runtime libraries. > Also, I seem to recall that in the past that for some of the core > packages, you had to build these twice in the process of getting > everything up and running. Again, these facts need to be made very > obvious so folks don't go down a wrong path. As explained above... > Once I get started on a path (1..4 above), I also need to know which of > the current scripts to use in building on Windows XP to get the best > results. You should be able to use all, though for the shell scripts you need a POSIX environment (like Cygwin), for the Python scripts you obviously need a Python installation (and they are quiet new, I don't know about their status); easiest will probably be Jay's CMD scripts for Windows. So I think upgrade,cmd would be a good start, followed probably by do-cm3-std.cmd. > I love the language and have been a zealous proponent of it for a long > time, but we've got to make it easier for folks to get started with > Modula-3. I will carefully document the steps I take in getting the > system built on Windows so we can make this available to everyone. I second this. > The last time I was able to get the sources and build on Windows was > v5.26. That version didn't work correctly with some of my programs and > I reported the problems to Olaf et al. The last time I checked out the > sources and tried to build 5.40, I wound up with compiler errors. I > recall some of these were related to LONGINT and some were related to > the garbage collector. So yes, there was a situation where I checked > out sources that represented a "broken" version in that it would not > build. I think that the head of the tree is quiet often broken wrt. a simple compilation of all packages, and sometimes even broken wrt. to the standard compiler upgrade procedure. This is really difficult to foresee for many commits, if they concern the runtime and/or compiler extensions. It's the main reason why I think we need automated regression tests on as many platforms as possible. > The package status page at > http://modula3.elegosoft.com/cm3/package-status.html is headed up by > the title CM3 v5.1. Is this page up-to-date? It would be helpful to > know where we stand wrt each package on each supported platform relative > to the current source tree. Again, I think an automated scoreboard > could make this possible. No, the package status hasn't been updated for a long time. There are lots of things that would need updating. Volunteers are welcome. Once we've got automated tests, this page could be generated, too. > Sorry to ramble on so much in this post. My main interest is in > getting the current sources built and running on Windows XP. As soon as > I am successful, I will run tests using my code base. I have a number > of programs that were built using cm3 v4.1 that are still in use. These > use a lot of features, including pickles, netobj, trestle, etc. So, my > tests should help uncover Broken #2 problems on Windows. IIRC, the main problems we at Elego had with Windows years ago were mostly GUI-related; the base stuff was working well. Unfortunately, there was noone with Windows GUI programming experience at that time :-( > Finally, once I get a working cm3 system on Windows, I'll provide the > new cm3-IDE (aka Reactor) package. This will be great and long-awaited indeed. I hope you succeed, Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From hendrik at topoi.pooq.com Sat Jan 5 19:54:30 2008 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Sat, 5 Jan 2008 13:54:30 -0500 Subject: [M3devel] 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> <20080105013307.GB5064@topoi.pooq.com> Message-ID: <20080105185430.GA6402@topoi.pooq.com> On Sat, Jan 05, 2008 at 09:44:40AM +0100, Henning Thielemann wrote: > > On Fri, 4 Jan 2008 hendrik at topoi.pooq.com wrote: > > > gravityboy (http://gravityboy.livejournal.com/39755.html) has a few > > things to say about people who compare svn with cvs: essentially, he > > says cvs is so obsolete no one should even be comparing things with it > > any more. Saying something is better than CVS is like saying that > > a new model of automatic washing machines work better than rocks by the > > side of the river. > > When I was moving from CVS to Darcs, a popular distributed versioning > software in the Haskell world, one of my colleagues gave a talk about RCS. > I wondered why he still uses and promotes RCS, when even CVS was too > restricted for me. However after the talk many of my colleagues seconded > his attitude, because CVS was already too complicated for them. > To be honest, I still use CVS for small projects, when other machines are > invoked, where I can't install Darcs. CVS has the charme, that you have > the versioning data in a readable form. You could even repair small > damages manually, if it is necessary. What I like about monotone is its absolute paranoia about losing data. When it is syncing different "copies" of the repository, apparently much of the time is spent making sure that the ancient history hasn't been corrupted, and that the data being transferred from one to the other hasn't been corrupted either. And having multiple repositories really does make it hard to lose data. The original CVS, I'm told, was a set of scripts operating on top of RCS. I don't know what it is now. -- hendrik From dabenavidesd at yahoo.es Sat Jan 5 20:06:41 2008 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Sat, 5 Jan 2008 20:06:41 +0100 (CET) Subject: [M3devel] cvsup fix latest cm3 (Scheduler.DisableSwitching, EnableSwitching) Message-ID: <835827.15730.qm@web27109.mail.ukl.yahoo.com> H all: I get some error compiling cvsup (sublib) because of the change on the Scheduler interface of Pthread, It's not hard to fix (importing Scheduler instead of SchedulerPosix). This for your knowledge, with this fixes it compiles and runs well. "../src/Ugzip.m3", line 63: unknown qualification '.' (DisableSwitching) "../src/Ugzip.m3", line 67: unknown qualification '.' (EnableSwitching) "../src/Ugzip.m3", line 74: unknown qualification '.' (DisableSwitching) "../src/Ugzip.m3", line 78: unknown qualification '.' (EnableSwitching) 4 errors encountered new source -> compiling Umd5.i3 new source -> compiling StatusFile.m3 new source -> compiling CVTree.i3 new source -> compiling CVTree.m3 "../src/CVTree.m3", line 315: unknown qualification '.' (DisableSwitching) "../src/CVTree.m3", line 319: unknown qualification '.' (EnableSwitching) "../src/CVTree.m3", line 325: unknown qualification '.' (DisableSwitching) "../src/CVTree.m3", line 329: unknown qualification '.' (EnableSwitching) "../src/CVTree.m3", line 335: unknown qualification '.' (DisableSwitching) "../src/CVTree.m3", line 339: unknown qualification '.' (EnableSwitching) 6 errors encountered --------------------------------- Web Revelaci?n Yahoo! 2007: Premio Favorita del P?blico - ?Vota tu preferida! -------------- next part -------------- An HTML attachment was scrubbed... URL: From hendrik at topoi.pooq.com Sat Jan 5 20:12:43 2008 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Sat, 5 Jan 2008 14:12:43 -0500 Subject: [M3devel] M3 concerns In-Reply-To: <20080105143235.ujed2tl3ksogws8k@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> Message-ID: <20080105191243.GB6402@topoi.pooq.com> On Sat, Jan 05, 2008 at 02:32:35PM +0100, Olaf Wagner wrote: > Discussions seem to loose their focus quiet easy on this list :-/ > > I'd strongly prefer if we could keep the discussion of alternative > version control systems out of this. It won't help us, and you can > trust this opinion as I really know many version control systems > (SCCS, RCS, CVS, Subversion, ClearCase, PVCS Dimensions, Perforce, > AccuRev, OpenCM, Vesta,...). I can assure you that CVS is quite > adequate for the simple purposes and requirements we have. Changing > will make things different, but not better, and cost a lot of efforts > we should rather invest into other topics. I quite agree. But if you have this experience, it would be useful to see a rundown of the advantages and disadvantages of each. I've seen a table of features against version control systems, but it doesn't give any feel for what it's like to use them. Such an essay would be useful for those involved in other projects. It probably won't help Modula 3 itself. Or might you know of such an essay elsewhere? -- hendrik > > I'd like to get back to the original topic. How do we need to improve > the CM3 development process to ensure and increase the overall quality > of the CM3 code base? Could everybody interested in this discussion > please just comment on the following items to state his opinion: > > 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). > > Technical details should be discussed in a different thread. > > o Do we need / want to restrict the commit access for the CM3 > code repositories? At the very least, you should keep spammers out. > > If so, only for certain areas, or for everything? This would > be a distinction based on packages. > > Should we allow or prefer committing new code to branches and > merge the resulting change sets based on reviews? (I could also > contribute automatic support for creating change sets on branches, > as this is part of the DCVS functionality elego developed some time > ago). This would be a distinction based on code lines. What's the 'D' of 'DVCS'? > Yesterday I had the impression that some members of this list > would prefer some access restriction, but I'm not really sure. The real questions are whether corrupt code is checked in often enough to cause trouble to other developers, whether check-in conflicts happen enough to be troublesome, and whether the red tape of lots of branches would be more trouble than it is worth. I don't know the answer to this. For preparing regular stable releases, it is probably worthwhile to freeze development on a release branch, but to keep fixing bugs on both the development and the release branches. As for reviews of changes, that should happen whether there's an access restriction or not. It may be the most important role of those who are knowledgeable with the code base. And they should probably happen before debugging. -- hendrik From wagner at elegosoft.com Sat Jan 5 21:00:05 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 05 Jan 2008 21:00:05 +0100 Subject: [M3devel] more m3tests failures Message-ID: <20080105210005.7iacdx5nkks84osk@mail.elegosoft.com> I've looked into some more failures of m3tests, which I'd like to present to the whole list: (All tests run on FreeBSD 6.3) p035 is a scoping problem which was Ok with /usr/local/cm3/bin/cm3cg-5.4.0 but /usr/local/cm3/bin/cm3cg-d5.5.1 fails, so it must be caused by recent gcc changes. The check that fails is PROCEDURE foo (p: P; same: BOOLEAN) = BEGIN checkB (bar = p, same); checkB (bar # p, NOT same); END foo; PROCEDURE bar (<*UNUSED*> t: Text.T) = BEGIN END bar; BEGIN msg ("group M"); foo (bar, TRUE); msg ("group N"); foo (dummy, FALSE); END; p040 fails due to differences in floating point precision; the numbers on FreeBSD seem to have a higher precision. +++ ../src/p0/p040/stdout.pgm 2003-03-08 11:14:03.000000000 +0100 @@ -964,85 +964,85 @@ ToLongFloat => 0.1 / 3 -0.001234567890123456 +0.0012345678901235 - FromLongFloat [Flo] => 0.001234567890123 - ToLongFloat => 0.001234567890123 / 17 - FromLongFloat [AltFlo] => 0.001234567890123 - ToLongFloat => 0.001234567890123 / 17 - FromLongFloat [Sci] => 1.234567890123456D-3 - ToLongFloat => 0.001234567890123456 / 20 - FromLongFloat [AltSci] => 1.234567890123456D-3 - ToLongFloat => 0.001234567890123456 / 20 - FromLongFloat [Mix] => 0.001234567890123 - ToLongFloat => 0.001234567890123 / 17 + FromLongFloat [Flo] => 0.001234567890124 + ToLongFloat => 0.001234567890124 / 17 + FromLongFloat [AltFlo] => 0.001234567890124 + ToLongFloat => 0.001234567890124 / 17 + FromLongFloat [Sci] => 1.234567890123500D-3 + ToLongFloat => 0.0012345678901235 / 20 + FromLongFloat [AltSci] => 1.2345678901235D-3 + ToLongFloat => 0.0012345678901235 / 18 + FromLongFloat [Mix] => 0.001234567890124 + ToLongFloat => 0.001234567890124 / 17 I'm not sure here what to do, as well as for p070, which tests fingerprints for procedures, and is not implemented in CM3. Do we need that? From RTProcedure.m3: PROCEDURE ToFingerprint (<*UNUSED*> p: Proc): Fingerprint.T = BEGIN <*ASSERT FALSE, "RTProcedure.ToFingerprint is not supported" *> RETURN Fingerprint.Zero; <*NOWARN*> END ToFingerprint; PROCEDURE FromFingerprint (<*UNUSED*> READONLY fp: Fingerprint.T): Proc = BEGIN <*ASSERT FALSE, "RTProcedure.FromFingerprint is not supported" *> RETURN NIL; <*NOWARN*> END FromFingerprint; Or should we deactivate that test? p096 fails with @@ -1,3 +1,2 @@ "../src/Main.m3", line 27: default is not a procedure constant (m) 1 error encountered -Fatal Error: package build failed --- p0/p096/stderr.build 2008-01-05 18:27:24.000000000 +0100 +++ ../src/p0/p096/stderr.build 2003-03-08 11:14:05.000000000 +0100 because of this code: MODULE Main; CONST K = T.m; L = Q; TYPE TProc = PROCEDURE(s: T); CONST A = ARRAY OF TProc{Q}; TYPE T = OBJECT METHODS m() := L; END; ST1 = T OBJECT OVERRIDES m := K END; (*** ILLEGAL *** ST2 = T OBJECT OVERRIDES m := TProc END; ***) ST3 = T OBJECT OVERRIDES m := A[0]; END; PROCEDURE Q(s: T) = BEGIN EVAL s END Q; VAR t: T; st1: ST1; st3: ST3; BEGIN EVAL t; EVAL st1; EVAL st3; END Main. I think I can somehow understand the compiler here. Did this ever work? p116 first fails because FlotMode procedures are not implemented by default: +++ ../src/p1/p116/stderr.pgm 2003-03-08 11:13:53.000000000 +0100 @@ -1,11 +1,3 @@ - - -*** -*** runtime error: -*** <*ASSERT*> failed: FloatMode.SetRounding not implemented -*** file "../src/float/IEEE-default/FloatMode.m3", line 14 -*** - ---------------------------- REAL --- 1.0/0.0 # 1.0/(-0.0) test OK 1.0/0.0 = 1.0/(- (-0.0)) test OK I think this should be tested conditionally depending on platform. But then more checks fail: @@ -25,14 +17,14 @@ Class (MaxFinite*ten) test OK Finite (MaxFinite*ten) test OK IsNaN (MaxFinite*ten) test OK -** Class (zero/zero) test not OK: FALSE should be TRUE + Class (zero/zero) test OK Finite (zero/zero) test OK IsNaN (zero/zero) test OK Sign (zero) test OK Sign (minusZero) test OK - Unordered (zero, NaN) test OK +** Unordered (zero, NaN) test not OK: FALSE should be TRUE Unordered (zero, zero) test OK - Unordered (NaN, NaN) test OK +** Unordered (NaN, NaN) test not OK: FALSE should be TRUE Differs (zero, NaN) test OK which refers to the test lines BCheck("Class (zero/zero)", RealFloat.Class(x) = IEEEClass.QuietNaN, TRUE); BCheck("Unordered (zero, NaN)", RealFloat.Unordered(zero, NaN), TRUE); BCheck("Unordered (NaN, NaN)", RealFloat.Unordered(NaN, NaN), TRUE); Especially the last one suprises me, but I'm no specialist in arithmetics. Is this to be expected? Should we tolerate or can we fix it? So far for now, I need to prepare dinner now, Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From dabenavidesd at yahoo.es Sun Jan 6 02:26:48 2008 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Sun, 6 Jan 2008 02:26:48 +0100 (CET) Subject: [M3devel] Problem with an exmaple of Modula-3 tutorial Message-ID: <316462.45428.qm@web27102.mail.ukl.yahoo.com> Hi all: I was showing an example to a friend of the Modula-3 tutorial, but we ran into an error with the first one: http://modula3.elegosoft.com/cm3/doc/tutorial/m3/m3_2.html#SEC2 MODULE Main ; IMPORT IO; (* So we can print things *) VAR name: TEXT; (* a string variable called "name" *) BEGIN IO.Put("Enter your name: "); IO.GetLine(name); IO.Put("Your name is: " & name & "\n"); END Main. "../src/Main.m3", line 9: incompatible types (rd) Well fortunately we have this great documentation of the interfaces, so a correct (not formally proved) code is: MODULE Main; IMPORT IO; (* So we can print things *) VAR name: TEXT; (* a string variable called "name" *) BEGIN IO.Put("Enter your name: "); name:=IO.GetLine(); IO.Put("Your name is: " & name & "\n"); END Main. I have a cvs account, I cancheck it also for prepare my knowledge and merge some modifications of m3-lectern packages to be able to compile them. Thanks for the great work you have done to keep this wonderful enviroment going on in so many platforms. Happy new years modula-3 developers !! Daniel Benavides --------------------------------- Web Revelaci?n Yahoo! 2007: Premio Favorita del P?blico - ?Vota tu preferida! -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.caltech.edu Sun Jan 6 02:59:23 2008 From: mika at async.caltech.edu (Mika Nystrom) Date: Sat, 05 Jan 2008 17:59:23 -0800 Subject: [M3devel] M3 concerns In-Reply-To: Your message of "Fri, 04 Jan 2008 21:12:24 EST." <477EA137.1E75.00D7.1@scires.com> Message-ID: <200801060159.m061xNjc047849@camembert.async.caltech.edu> "Randy Coleburn" writes: > > >> Date: Sat, 5 Jan 2008 01:13:35 +0100 >> From: wagner at elegosoft.com >> To: hosking at cs.purdue.edu; m3devel at elegosoft.com >> CC: m3-support at elegosoft.com >> Subject: Re: [M3devel] M3 concerns >> >> Quoting Tony Hosking : >> >> > My comments embedded: >> > >> > On Jan 4, 2008, at 4:10 PM, Olaf Wagner wrote: >> >> >> Ah well, Windows is a somewhat special topic. I even haven't a >system >> >> here for tests, and most of the other contributors don't use it >either. >> >> I was of the opinion that Jay Krell had fixes or workarounds for >most >> >> current problems (except for the missing LONGINT support), but I >haven't >> >> tried his distribution archives yet. It would indeed be very >helpful >> >> if we could setup regression tests on Windows, too. >> > >> > LONGINT = INTEGER on Windows, which is fine as far as it goes >> > (everything builds appropriately), but not particularly useful. >> >> I know that it should run this way, but pickles for example wouldn't >> be exchangeable then, would they? Has anybody tested pickle support >> for LONGINT yet? Well, I think this depends on exactly what you (not sure who said this originally) mean by "LONGINT = INTEGER". What you say is true if indeed LONGINT and INTEGER are the same type. If, however, they are different types (as they should be), which just happen to be of the same size (on Windows/i386), there should be no problem. The Pickle library (at least ver. 2) transparently performs endianness reordering and word-size adjustments. (Pickles *should* be exchangeable between 32- and 64-bit architectures, for example, and between big-endian sparcs and little-endian i386s and alphas---this latter property I use to exchange pickles between PPC_DARWIN and FreeBSD4.) Of course, have all the proper hooks been called to enable this? I don't know, I just know it's definitely possible to set things up so that Pickles are exchangeable even under these conditions. Mika From hosking at cs.purdue.edu Sun Jan 6 04:41:33 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 5 Jan 2008 22:41:33 -0500 Subject: [M3devel] M3 concerns In-Reply-To: <200801060159.m061xNjc047849@camembert.async.caltech.edu> References: <200801060159.m061xNjc047849@camembert.async.caltech.edu> Message-ID: <8C8CF668-F1C6-475B-B67A-EA3DCDC7509C@cs.purdue.edu> On Jan 5, 2008, at 8:59 PM, Mika Nystrom wrote: > "Randy Coleburn" writes: >> >> >>>> >>>> LONGINT = INTEGER on Windows, which is fine as far as it goes >>>> (everything builds appropriately), but not particularly useful. >>> >>> I know that it should run this way, but pickles for example wouldn't >>> be exchangeable then, would they? Has anybody tested pickle support >>> for LONGINT yet? > Sorry, yes, I was incorrect in saying LONGINT=INTEGER on WIN32. In fact, they are distinct types that just happen to have the same representation, so the backend can handle them. > Well, I think this depends on exactly what you (not sure who said > this originally) mean by "LONGINT = INTEGER". What you say is true > if indeed LONGINT and INTEGER are the same type. If, however, they > are different types (as they should be), which just happen to be > of the same size (on Windows/i386), there should be no problem. > The Pickle library (at least ver. 2) transparently performs endianness > reordering and word-size adjustments. (Pickles *should* be > exchangeable between 32- and 64-bit architectures, for example, and > between big-endian sparcs and little-endian i386s and alphas---this > latter property I use to exchange pickles between PPC_DARWIN and > FreeBSD4.) Of course, have all the proper hooks been called to > enable this? I don't know, I just know it's definitely possible > to set things up so that Pickles are exchangeable even under these > conditions. > > Mika From wagner at elegosoft.com Sun Jan 6 13:01:46 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Sun, 06 Jan 2008 13:01:46 +0100 Subject: [M3devel] Problem with an exmaple of Modula-3 tutorial In-Reply-To: <316462.45428.qm@web27102.mail.ukl.yahoo.com> References: <316462.45428.qm@web27102.mail.ukl.yahoo.com> Message-ID: <20080106130146.46qwab3808wkogwc@mail.elegosoft.com> Quoting "Daniel Alejandro Benavides D." : > Hi all: > I was showing an example to a friend of the Modula-3 tutorial, but > we ran into an error with the first one: > > http://modula3.elegosoft.com/cm3/doc/tutorial/m3/m3_2.html#SEC2 > > > MODULE Main ; > > IMPORT IO; (* So we can print things *) > > VAR name: TEXT; (* a string variable called "name" *) > > BEGIN > IO.Put("Enter your name: "); > IO.GetLine(name); > IO.Put("Your name is: " & name & "\n"); > END Main. > > "../src/Main.m3", line 9: incompatible types (rd) > > Well fortunately we have this great documentation of the interfaces, > so a correct (not formally proved) code is: > > MODULE Main; > > IMPORT IO; (* So we can print things *) > > VAR name: TEXT; (* a string variable called "name" *) > > BEGIN > IO.Put("Enter your name: "); > name:=IO.GetLine(); > IO.Put("Your name is: " & name & "\n"); > END Main. > > I have a cvs account, I cancheck it also for prepare my knowledge > and merge some modifications of m3-lectern packages to be able to > compile them. Please check in any corrections you'd care to do and let m3-support know about when to ship updates to the web server. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Jan 6 20:39:03 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Sun, 06 Jan 2008 20:39:03 +0100 Subject: [M3devel] M3 concerns / automated regression tests In-Reply-To: <477B7629.1E75.00D7.1@scires.com> References: <477B7629.1E75.00D7.1@scires.com> Message-ID: <20080106203903.tav3gl9c00ow8ggc@mail.elegosoft.com> Quoting Randy Coleburn : > Question: As various people make contributions and changes, is > there any group of folks who is verifying that the changes don't > break existing code or core principles? Another idea would be to > have a series of test batteries that have to be passed before > changes can be accepted. I know of a number of projects where many > people contribute, but the contributions have to be vetted by > passing some tests. > > Without these types of controls, I fear that good forward progress > will inevitably be hampered or compromised by changes made by > someone who hasn't completely thought out and tested the > ramifications of those changes. As announced in other mails, I'd like to get into some details of the regression test standardization I suggest. As you may have noticed, several scripts have been committed to cm3/scripts/regression/. There are some scripts for the integration of tests into the elego tinderbox framework, which are still work in progress. Kaspar Schleiser is working on this; it may take some days before everything works as expected. The main functions for test standardization are contained in the file defs.sh. This is a shell script which can be sourced and used in different contexts. It contains functions for CVS checkout, binary installation, and the actual tests. In my opinion, the most important thing that should be ensured is that the current sources can be compiled with the latest official release of the system. This can get tricky in case of incompatible changes in the compiler runtime, frontend, or configuration (cm3.cfg). So the main part of test_build_core_rel() is an upgrade performed by scripts/upgrade.sh based on the last release. In order to use this, it must of course be installed. This can be done with install_bin_dist(). The test framework uses three installations of CM3, located in INSTBASE, which defaults to ${HOME}/work/cm3-inst. There are rel-${LASTREL}, e.g. rel-5.4.0 current last-ok rel-x.x.x should contain at least a minimal installation of the last official release. It may have to be installed manually, as the installer was interactive until recently. (This has been changed in d5.5.1.) current always contains the CM3 installation which is used for actual shipping during test builds and is usually based on the current sources. last-ok is always updated with the last successfully built version. The workspaces which are used for checkout and compilation contain date stamps in their name, eg. ~/work/cm3-ws-2008-01-04-20-05-06/. They can be set with the variables DS and WS: DS=${DS:-`date -u +'%Y-%m-%d-%H-%M-%S' | tr -d '\\n'`} WS=${WS:-${HOME}/work/cm3-ws-${DS}} Apart from building with the latest release, there are currently the following tests automated: o building the core system with the last-ok version. This will work until anybody checks in an incompatible change for the runtime, frontend, or configuration. It may be used as an indicator that a full upgrade procedure is necessary from this point in time. As this is expected to fail eventually, it should not be considered fatal. This is performed by test_build_core_lastok(). o building the complete set of standard packages with the last-ok / current version. This excludes the compiler itself, and will give an indication if the second step of the bootstrap after initial installation works (installing all standard packages with the minimal system). This is done by test_build_std_lastok(). o building of a minimal binary installation archive. This will ensure that we can actually build a new release for the tested platform. It is done by test_make_bin_dist(). The produced archives can be distributed as current snapshots. o testall() and main() simply combine all tests into one run which might be done nightly. This is currently not compatible with the intended tinderbox integration though. Needed extensions: o The actual compiler regression tests (m3tests) need to be included. I've imported them 2003 from the PM3 distribution, but they are not in a good shape. I've started to work on them, but will need help of others; you will have noticed my messages. o There are many more package-related regression tests, which need to be added, too. I don't know about the status of most though, so this will be a tedious task, too. We could distinguish between tests for core packages work/cm3/m3-libs/binIO/test work/cm3/m3-libs/bitvector/test work/cm3/m3-libs/libm3/tests work/cm3/m3-libs/libm3/tests/rw/autotest work/cm3/m3-libs/m3core/tests work/cm3/m3-libs/patternmatching/tests work/cm3/m3-libs/slisp/tests work/cm3/m3-libs/sortedtableextras/tests and others work/cm3/caltech-parser/drawcontext/test work/cm3/caltech-parser/m3tmplhack/test work/cm3/caltech-parser/parserlib/parserlib/test work/cm3/caltech-parser/parserlib/parserlib/test_stdin work/cm3/m3-comm/events/tests work/cm3/m3-comm/events/tests/test work/cm3/m3-comm/netobj/tests work/cm3/m3-comm/rdwr/test work/cm3/m3-comm/serial/test work/cm3/m3-comm/sharedobj/tests work/cm3/m3-comm/sharedobj/tests/netobjtest work/cm3/m3-comm/sharedobjgen/test work/cm3/m3-comm/udp/test work/cm3/m3-db/db/test work/cm3/m3-db/odbc/test work/cm3/m3-db/pgodbc/test work/cm3/m3-db/postgres95/test work/cm3/m3-db/stable/test work/cm3/m3-libs/dps/test work/cm3/m3-libs/synthesizer/test work/cm3/m3-libs/tcl/test work/cm3/m3-libs/deepcopy/test work/cm3/m3-libs/plplot/test work/cm3/m3-libs/arithmetic/test work/cm3/m3-libs/fftw/test work/cm3/m3-libs/lapack/test work/cm3/m3-libs/unittest work/cm3/m3-libs/unittest-numeric work/cm3/m3-libs/wellfett/test work/cm3/m3-sys/m3modinittest work/cm3/m3-ui/juno-2/juno-app/juno-src/test work/cm3/m3-ui/juno-2/juno-app/juno-src/testRedundant work/cm3/m3-ui/juno-2/juno-compiler/tests work/cm3/m3-ui/ui/test work/cm3/m3-ui/motif/tests work/cm3/m3-ui/ui-tests work/cm3/m3-ui/vbtkit/src/vtext/testing I'll try these after m3tests are working. Of course, contributions of others are welcome for all these. As a start, it may be a good idea if those interested in running regular tests could try the core test framework. What needs to be done is o ( . ./scripts/regression/defs.sh; install_bin_dist ) once, potentially manuallly, or with overwriting the cminstall program to use something current: ( export CMINSTALL=...; . ./scripts/regression/defs.sh; install_bin_dist ) This expects the latest binary installation archive in your home directory. o Now tests should be able to run on a regular basis like this: ( . ./scripts/regression/defs.sh; main ) This will create a new workspace, checkout the current sources, and perform all the tests described above. I've tried this now on a FreeBSD 6.2 and Debian Linux system. It may well be that more adaptions and extensions to the scripts are necessary, but we have to try. If the above works for others, too, we can turn to the tinderbox integration to gather all the results in a database and display them. You may have a look at the results at http://tinderbox.elegosoft.com/ http://tinderbox.elegosoft.com/cm3/status.html Keep in mind that this work is not finished yet. Please let me know of any problems, improvements, or just comments. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From hosking at cs.purdue.edu Sun Jan 6 22:29:58 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 6 Jan 2008 16:29:58 -0500 Subject: [M3devel] more m3tests failures In-Reply-To: <20080105210005.7iacdx5nkks84osk@mail.elegosoft.com> References: <20080105210005.7iacdx5nkks84osk@mail.elegosoft.com> Message-ID: <5BED31CE-54AB-44CB-905A-E19ED6B0435A@cs.purdue.edu> On Jan 5, 2008, at 3:00 PM, Olaf Wagner wrote: > I've looked into some more failures of m3tests, which I'd like to > present to the whole list: (All tests run on FreeBSD 6.3) > > p035 is a scoping problem which was Ok with > > /usr/local/cm3/bin/cm3cg-5.4.0 > > but > > /usr/local/cm3/bin/cm3cg-d5.5.1 > > fails, so it must be caused by recent gcc changes. The check that > fails is > > PROCEDURE foo (p: P; same: BOOLEAN) = > BEGIN > checkB (bar = p, same); checkB (bar # p, NOT same); > END foo; > PROCEDURE bar (<*UNUSED*> t: Text.T) = > BEGIN > END bar; > BEGIN > msg ("group M"); foo (bar, TRUE); > msg ("group N"); foo (dummy, FALSE); > END; Hmm. Something is broken with load_static_link. I will look into it. > > p040 fails due to differences in floating point precision; the numbers > on FreeBSD seem to have a higher precision. > > +++ ../src/p0/p040/stdout.pgm 2003-03-08 11:14:03.000000000 +0100 > @@ -964,85 +964,85 @@ > ToLongFloat => 0.1 / 3 > > > -0.001234567890123456 > +0.0012345678901235 > > - FromLongFloat [Flo] => 0.001234567890123 > - ToLongFloat => 0.001234567890123 / 17 > - FromLongFloat [AltFlo] => 0.001234567890123 > - ToLongFloat => 0.001234567890123 / 17 > - FromLongFloat [Sci] => 1.234567890123456D-3 > - ToLongFloat => 0.001234567890123456 / 20 > - FromLongFloat [AltSci] => 1.234567890123456D-3 > - ToLongFloat => 0.001234567890123456 / 20 > - FromLongFloat [Mix] => 0.001234567890123 > - ToLongFloat => 0.001234567890123 / 17 > + FromLongFloat [Flo] => 0.001234567890124 > + ToLongFloat => 0.001234567890124 / 17 > + FromLongFloat [AltFlo] => 0.001234567890124 > + ToLongFloat => 0.001234567890124 / 17 > + FromLongFloat [Sci] => 1.234567890123500D-3 > + ToLongFloat => 0.0012345678901235 / 20 > + FromLongFloat [AltSci] => 1.2345678901235D-3 > + ToLongFloat => 0.0012345678901235 / 18 > + FromLongFloat [Mix] => 0.001234567890124 > + ToLongFloat => 0.001234567890124 / 17 > > I'm not sure here what to do, as well as for p070, which tests > fingerprints for procedures, and is not implemented in CM3. Do we > need that? From RTProcedure.m3: > > PROCEDURE ToFingerprint (<*UNUSED*> p: Proc): Fingerprint.T = > BEGIN > <*ASSERT FALSE, "RTProcedure.ToFingerprint is not supported" *> > RETURN Fingerprint.Zero; <*NOWARN*> > END ToFingerprint; > > PROCEDURE FromFingerprint (<*UNUSED*> READONLY fp: Fingerprint.T): > Proc = > BEGIN > <*ASSERT FALSE, "RTProcedure.FromFingerprint is not supported" *> > RETURN NIL; <*NOWARN*> > END FromFingerprint; > > Or should we deactivate that test? I suspect we should deactivate both of these for now. > > p096 fails with > > @@ -1,3 +1,2 @@ > "../src/Main.m3", line 27: default is not a procedure constant (m) > 1 error encountered > -Fatal Error: package build failed > --- p0/p096/stderr.build 2008-01-05 18:27:24.000000000 +0100 > +++ ../src/p0/p096/stderr.build 2003-03-08 11:14:05.000000000 +0100 > > because of this code: > > MODULE Main; > > CONST K = T.m; L = Q; > TYPE TProc = PROCEDURE(s: T); > CONST A = ARRAY OF TProc{Q}; > > TYPE T = OBJECT METHODS m() := L; END; > ST1 = T OBJECT OVERRIDES m := K END; > (*** ILLEGAL *** ST2 = T OBJECT OVERRIDES m := TProc END; ***) > ST3 = T OBJECT OVERRIDES m := A[0]; END; > > PROCEDURE Q(s: T) = BEGIN EVAL s END Q; > > VAR t: T; st1: ST1; st3: ST3; > BEGIN > EVAL t; EVAL st1; EVAL st3; > END Main. > > I think I can somehow understand the compiler here. Did this ever > work? Is "CONST K = T.m" not a procedure constant? In which case m := K should work! > > p116 first fails because FlotMode procedures are not implemented by > default: > > +++ ../src/p1/p116/stderr.pgm 2003-03-08 11:13:53.000000000 +0100 > @@ -1,11 +1,3 @@ > - > - > -*** > -*** runtime error: > -*** <*ASSERT*> failed: FloatMode.SetRounding not implemented > -*** file "../src/float/IEEE-default/FloatMode.m3", line 14 > -*** > - > ---------------------------- REAL --- > 1.0/0.0 # 1.0/(-0.0) test OK > 1.0/0.0 = 1.0/(- (-0.0)) test OK > > I think this should be tested conditionally depending on platform. Indeed. > But then more checks fail: > > @@ -25,14 +17,14 @@ > Class (MaxFinite*ten) test OK > Finite (MaxFinite*ten) test OK > IsNaN (MaxFinite*ten) test OK > -** Class (zero/zero) test not OK: FALSE should be TRUE > + Class (zero/zero) test OK > Finite (zero/zero) test OK > IsNaN (zero/zero) test OK > Sign (zero) test OK > Sign (minusZero) test OK > - Unordered (zero, NaN) test OK > +** Unordered (zero, NaN) test not OK: FALSE should be TRUE > Unordered (zero, zero) test OK > - Unordered (NaN, NaN) test OK > +** Unordered (NaN, NaN) test not OK: FALSE should be TRUE > Differs (zero, NaN) test OK > > which refers to the test lines > > BCheck("Class (zero/zero)", RealFloat.Class(x) = > IEEEClass.QuietNaN, TRUE); > BCheck("Unordered (zero, NaN)", RealFloat.Unordered(zero, NaN), > TRUE); > BCheck("Unordered (NaN, NaN)", RealFloat.Unordered(NaN, NaN), > TRUE); > > Especially the last one suprises me, but I'm no specialist in > arithmetics. > Is this to be expected? Should we tolerate or can we fix it? Not sure... > > So far for now, I need to prepare dinner now, > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, > Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 > 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: > Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > DE163214194 > From hosking at cs.purdue.edu Mon Jan 7 15:56:12 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 7 Jan 2008 09:56:12 -0500 Subject: [M3devel] more m3tests failures In-Reply-To: <20080105210005.7iacdx5nkks84osk@mail.elegosoft.com> References: <20080105210005.7iacdx5nkks84osk@mail.elegosoft.com> Message-ID: <145F79EF-1CFF-4393-9C81-7F15CD283674@cs.purdue.edu> On Jan 5, 2008, at 3:00 PM, Olaf Wagner wrote: > I've looked into some more failures of m3tests, which I'd like to > present to the whole list: (All tests run on FreeBSD 6.3) > > p035 is a scoping problem which was Ok with > > /usr/local/cm3/bin/cm3cg-5.4.0 > > but > > /usr/local/cm3/bin/cm3cg-d5.5.1 > > fails, so it must be caused by recent gcc changes. The check that > fails is > > PROCEDURE foo (p: P; same: BOOLEAN) = > BEGIN > checkB (bar = p, same); checkB (bar # p, NOT same); > END foo; > PROCEDURE bar (<*UNUSED*> t: Text.T) = > BEGIN > END bar; > BEGIN > msg ("group M"); foo (bar, TRUE); > msg ("group N"); foo (dummy, FALSE); > END; I think the issue is to do with the fact that we use gcc's automatic nested function support instead of m3cg's load_static_link and pop_static_link. I believe the fix is to make load_static_link load nil instead of an actual static chain value. > > p040 fails due to differences in floating point precision; the numbers > on FreeBSD seem to have a higher precision. > > +++ ../src/p0/p040/stdout.pgm 2003-03-08 11:14:03.000000000 +0100 > @@ -964,85 +964,85 @@ > ToLongFloat => 0.1 / 3 > > > -0.001234567890123456 > +0.0012345678901235 > > - FromLongFloat [Flo] => 0.001234567890123 > - ToLongFloat => 0.001234567890123 / 17 > - FromLongFloat [AltFlo] => 0.001234567890123 > - ToLongFloat => 0.001234567890123 / 17 > - FromLongFloat [Sci] => 1.234567890123456D-3 > - ToLongFloat => 0.001234567890123456 / 20 > - FromLongFloat [AltSci] => 1.234567890123456D-3 > - ToLongFloat => 0.001234567890123456 / 20 > - FromLongFloat [Mix] => 0.001234567890123 > - ToLongFloat => 0.001234567890123 / 17 > + FromLongFloat [Flo] => 0.001234567890124 > + ToLongFloat => 0.001234567890124 / 17 > + FromLongFloat [AltFlo] => 0.001234567890124 > + ToLongFloat => 0.001234567890124 / 17 > + FromLongFloat [Sci] => 1.234567890123500D-3 > + ToLongFloat => 0.0012345678901235 / 20 > + FromLongFloat [AltSci] => 1.2345678901235D-3 > + ToLongFloat => 0.0012345678901235 / 18 > + FromLongFloat [Mix] => 0.001234567890124 > + ToLongFloat => 0.001234567890124 / 17 > > I'm not sure here what to do, as well as for p070, which tests > fingerprints for procedures, and is not implemented in CM3. Do we > need that? From RTProcedure.m3: > > PROCEDURE ToFingerprint (<*UNUSED*> p: Proc): Fingerprint.T = > BEGIN > <*ASSERT FALSE, "RTProcedure.ToFingerprint is not supported" *> > RETURN Fingerprint.Zero; <*NOWARN*> > END ToFingerprint; > > PROCEDURE FromFingerprint (<*UNUSED*> READONLY fp: Fingerprint.T): > Proc = > BEGIN > <*ASSERT FALSE, "RTProcedure.FromFingerprint is not supported" *> > RETURN NIL; <*NOWARN*> > END FromFingerprint; > > Or should we deactivate that test? I suspect we should deactivate both of these for now. > > p096 fails with > > @@ -1,3 +1,2 @@ > "../src/Main.m3", line 27: default is not a procedure constant (m) > 1 error encountered > -Fatal Error: package build failed > --- p0/p096/stderr.build 2008-01-05 18:27:24.000000000 +0100 > +++ ../src/p0/p096/stderr.build 2003-03-08 11:14:05.000000000 +0100 > > because of this code: > > MODULE Main; > > CONST K = T.m; L = Q; > TYPE TProc = PROCEDURE(s: T); > CONST A = ARRAY OF TProc{Q}; > > TYPE T = OBJECT METHODS m() := L; END; > ST1 = T OBJECT OVERRIDES m := K END; > (*** ILLEGAL *** ST2 = T OBJECT OVERRIDES m := TProc END; ***) > ST3 = T OBJECT OVERRIDES m := A[0]; END; > > PROCEDURE Q(s: T) = BEGIN EVAL s END Q; > > VAR t: T; st1: ST1; st3: ST3; > BEGIN > EVAL t; EVAL st1; EVAL st3; > END Main. > > I think I can somehow understand the compiler here. Did this ever > work? Is "CONST K = T.m" not a procedure constant? In which case m := K should work! > > p116 first fails because FlotMode procedures are not implemented by > default: > > +++ ../src/p1/p116/stderr.pgm 2003-03-08 11:13:53.000000000 +0100 > @@ -1,11 +1,3 @@ > - > - > -*** > -*** runtime error: > -*** <*ASSERT*> failed: FloatMode.SetRounding not implemented > -*** file "../src/float/IEEE-default/FloatMode.m3", line 14 > -*** > - > ---------------------------- REAL --- > 1.0/0.0 # 1.0/(-0.0) test OK > 1.0/0.0 = 1.0/(- (-0.0)) test OK > > I think this should be tested conditionally depending on platform. Indeed. > But then more checks fail: > > @@ -25,14 +17,14 @@ > Class (MaxFinite*ten) test OK > Finite (MaxFinite*ten) test OK > IsNaN (MaxFinite*ten) test OK > -** Class (zero/zero) test not OK: FALSE should be TRUE > + Class (zero/zero) test OK > Finite (zero/zero) test OK > IsNaN (zero/zero) test OK > Sign (zero) test OK > Sign (minusZero) test OK > - Unordered (zero, NaN) test OK > +** Unordered (zero, NaN) test not OK: FALSE should be TRUE > Unordered (zero, zero) test OK > - Unordered (NaN, NaN) test OK > +** Unordered (NaN, NaN) test not OK: FALSE should be TRUE > Differs (zero, NaN) test OK > > which refers to the test lines > > BCheck("Class (zero/zero)", RealFloat.Class(x) = > IEEEClass.QuietNaN, TRUE); > BCheck("Unordered (zero, NaN)", RealFloat.Unordered(zero, NaN), > TRUE); > BCheck("Unordered (NaN, NaN)", RealFloat.Unordered(NaN, NaN), > TRUE); > > Especially the last one suprises me, but I'm no specialist in > arithmetics. > Is this to be expected? Should we tolerate or can we fix it? > > So far for now, I need to prepare dinner now, > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, > Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 > 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: > Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > DE163214194 > From darko at darko.org Mon Jan 7 19:12:35 2008 From: darko at darko.org (Darko) Date: Mon, 7 Jan 2008 10:12:35 -0800 Subject: [M3devel] CM3 on Leopard Message-ID: <6CD6F1AC-449E-421D-A26A-C50BA1DFC301@darko.org> Hi Tony, Are you using CM3 on Leopard, aka Mac OS X 10.5? It's stopped working since I upgraded, I get: cc -o parser -fPIC _m3main.o [ ... various libs, modules ... ] - lm3gcdefs -lm -multiply_defined suppress -bind_at_load -shared-libgcc /usr/bin/ld: /usr/lib/gcc/i686-apple-darwin8/4.0.1/../../../libm.dylib unknown flags (type) of section 6 (__TEXT,__dof_plockstat) in load command 0 /usr/bin/ld: can't locate file for: -lgcc_s.10.4 collect2: ld returned 1 exit status when trying to compile. Uname says: Darwin Lucifer.local 9.1.0 Darwin Kernel Version 9.1.0: Wed Oct 31 17:46:22 PDT 2007; root:xnu-1228.0.2~1/RELEASE_I386 i386 It would seem that i just needs to be nudged up to the right version, but I couldn't find anything in the cfg file. Any suggestions? Thanks, Darko. From hosking at cs.purdue.edu Mon Jan 7 20:08:08 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 7 Jan 2008 14:08:08 -0500 Subject: [M3devel] CM3 on Leopard In-Reply-To: <6CD6F1AC-449E-421D-A26A-C50BA1DFC301@darko.org> References: <6CD6F1AC-449E-421D-A26A-C50BA1DFC301@darko.org> Message-ID: On Jan 7, 2008, at 1:12 PM, Darko wrote: > Hi Tony, > > Are you using CM3 on Leopard, aka Mac OS X 10.5? No, I've deliberately *not* upgraded to Leopard until I am able to test CM3 on it. Generally, I avoid bleeding edge OS upgrades for precisely this reason. I don't know when I will have time to play with CM3 on Leopard. Right now, I am tracking down another issue related to the regression framework Olaf is putting together. > It's stopped working since I upgraded, I get: > > cc -o parser -fPIC _m3main.o [ ... various libs, modules ... ] - > lm3gcdefs -lm -multiply_defined suppress -bind_at_load -shared-libgcc At least this suggest your cm3 binary was able to run on Leopard, which is a good start. > > /usr/bin/ld: /usr/lib/gcc/i686-apple-darwin8/4.0.1/../../../ > libm.dylib unknown flags (type) of section 6 > (__TEXT,__dof_plockstat) in load command 0 > /usr/bin/ld: can't locate file for: -lgcc_s.10.4 > collect2: ld returned 1 exit status > > when trying to compile. Uname says: > > Darwin Lucifer.local 9.1.0 Darwin Kernel Version 9.1.0: Wed Oct 31 > 17:46:22 PDT 2007; root:xnu-1228.0.2~1/RELEASE_I386 i386 > > It would seem that i just needs to be nudged up to the right > version, but I couldn't find anything in the cfg file. Any > suggestions? I suspect that you need to rebuild the m3cg backend, but I have no idea how well it will play with Leopard. Also, I have heard there were changes to ucontexts and other thread state which may mean M3 exceptions break, but I have not verified yet. > > Thanks, > Darko. > From hosking at cs.purdue.edu Mon Jan 7 20:27:19 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 7 Jan 2008 14:27:19 -0500 Subject: [M3devel] more m3tests failures In-Reply-To: <20080105210005.7iacdx5nkks84osk@mail.elegosoft.com> References: <20080105210005.7iacdx5nkks84osk@mail.elegosoft.com> Message-ID: I just checked in the fix for p035, with changes to the gcc-based backend (tree-nested.c and parse.c). On Jan 5, 2008, at 3:00 PM, Olaf Wagner wrote: > I've looked into some more failures of m3tests, which I'd like to > present to the whole list: (All tests run on FreeBSD 6.3) > > p035 is a scoping problem which was Ok with > > /usr/local/cm3/bin/cm3cg-5.4.0 > > but > > /usr/local/cm3/bin/cm3cg-d5.5.1 > > fails, so it must be caused by recent gcc changes. The check that > fails is > > PROCEDURE foo (p: P; same: BOOLEAN) = > BEGIN > checkB (bar = p, same); checkB (bar # p, NOT same); > END foo; > PROCEDURE bar (<*UNUSED*> t: Text.T) = > BEGIN > END bar; > BEGIN > msg ("group M"); foo (bar, TRUE); > msg ("group N"); foo (dummy, FALSE); > END; From hosking at cs.purdue.edu Mon Jan 7 21:16:47 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 7 Jan 2008 15:16:47 -0500 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <20080107073815.DBCDD10D45C8@birch.elegosoft.com> References: <20080107073815.DBCDD10D45C8@birch.elegosoft.com> Message-ID: <4F88D761-5F3F-4891-B3BD-7490FC7E7A2A@cs.purdue.edu> Jay, I am very nervous about the pervasive nature of some of your recent commits. NT386GNU is usually configured with OS_TYPE="POSIX". Thus, the m3makefile for cm3, which contains the following: if equal (OS_TYPE, "POSIX") interface ("M3Backend") implementation ("M3BackPosix") implementation ("UtilsPosix") else import ("m3objfile") import ("m3back") interface ("M3Backend") implementation ("M3BackWin32") implementation ("UtilsWin32") end will build a POSIX backend for you on NT386GNU which should do the right thing in invoking the gcc-based backend. Your changes, which hardwire things in cm3 for NT386GNU are thus unnecessary. I suggest you back these changes out and reconsider things. Certainly, NT386GNU should be considered as an independent POSIX target from the NT386 WIN32 target. Thus, one need not make changes to M3BackWin32 for NT386GNU, since it is treated as a POSIX target. As far as threading goes, if user-level threading for NT386 does not work then I can imagine it would be OK to use native WIN32 threads. The switch for that is in m3core/src/thread/m3makefile, which would check for TARGET="NT386GNU" and choose sibdirectory WIN32 instead of using OS_TYPE to pick subdirectory POSIX. On Jan 7, 2008, at 8:38 AM, Jay Krell wrote: > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 08/01/07 08:38:15 > > Modified files: > cm3/m3-libs/m3core/src/unix/cygwin/: Umman.i3 Uresource.i3 > Utypes.m3 > cm3/m3-sys/cm3/src/: Builder.i3 Builder.m3 M3BackPosix.m3 > M3BackWin32.m3 M3Backend.i3 > cm3/m3-sys/cminstall/src/config/: NT386GNU > cm3/m3-sys/m3front/src/misc/: M3Front.m3 > > Log message: > some fixes for NT386GNU (cygwin) > > let win32 cm3 use the gcc backend if target == NT386GNU > might need a better interface here? > switching on target name is probably the wrong thing > need something called "use gcc backend" or somesuch > > loosen the check for file name vs. module name to account for > paths with both types of slashes > might need a better interface/implementation here? > should try to get the paths to line up instead? > > remove -fPIC since it warns that it is redundant (though the > warning is probably wrong > in other details -- not all code is position independent, merely > relocatable..) > > use configured ar, /usr/bin/ar doesn't work, just plain ar does > > update Umman.i3 MAP_ANONYMOUS to new shorter name MAP_ANON > > update Uresource.i3 from struct_rusage_start to VAR struct_rusage > > fix warning about unused import long in Utypes.m3 > > change SYSTEM_CC from cc to gcc because cc is something on my system, > that I have not investigated, and doesn't work; gcc is perfectly > ok here, though > cc lines up nicely with the other two character names -- ar and as > > now need to deal with threads to get m3core to build From darko at darko.org Mon Jan 7 21:23:14 2008 From: darko at darko.org (Darko) Date: Mon, 7 Jan 2008 12:23:14 -0800 Subject: [M3devel] CM3 on Leopard In-Reply-To: References: <6CD6F1AC-449E-421D-A26A-C50BA1DFC301@darko.org> Message-ID: <934FB1C7-75A5-4720-B14E-EFAF6CD52C46@darko.org> It seems that I just forgot to install the latest tools. I fixed it by installing XCode from the Leopard DVD. Exceptions seem to work ok, but I did a very basic test. Maybe I can run the regression test suite on 10.5 when it's finished. I'll report any problems meanwhile. Thanks, Darko. On 07/01/2008, at 11:08 AM, Tony Hosking wrote: > > On Jan 7, 2008, at 1:12 PM, Darko wrote: > >> Hi Tony, >> >> Are you using CM3 on Leopard, aka Mac OS X 10.5? > > No, I've deliberately *not* upgraded to Leopard until I am able to > test CM3 on it. Generally, I avoid bleeding edge OS upgrades for > precisely this reason. I don't know when I will have time to play > with CM3 on Leopard. Right now, I am tracking down another issue > related to the regression framework Olaf is putting together. > >> It's stopped working since I upgraded, I get: >> >> cc -o parser -fPIC _m3main.o [ ... various libs, modules ... ] - >> lm3gcdefs -lm -multiply_defined suppress -bind_at_load -shared-libgcc > > At least this suggest your cm3 binary was able to run on Leopard, > which is a good start. > >> >> /usr/bin/ld: /usr/lib/gcc/i686-apple-darwin8/4.0.1/../../../ >> libm.dylib unknown flags (type) of section 6 >> (__TEXT,__dof_plockstat) in load command 0 >> /usr/bin/ld: can't locate file for: -lgcc_s.10.4 >> collect2: ld returned 1 exit status >> >> when trying to compile. Uname says: >> >> Darwin Lucifer.local 9.1.0 Darwin Kernel Version 9.1.0: Wed Oct 31 >> 17:46:22 PDT 2007; root:xnu-1228.0.2~1/RELEASE_I386 i386 >> >> It would seem that i just needs to be nudged up to the right >> version, but I couldn't find anything in the cfg file. Any >> suggestions? > > I suspect that you need to rebuild the m3cg backend, but I have no > idea how well it will play with Leopard. > > Also, I have heard there were changes to ucontexts and other thread > state which may mean M3 exceptions break, but I have not verified yet. > >> >> Thanks, >> Darko. >> > From hosking at cs.purdue.edu Mon Jan 7 21:27:30 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 7 Jan 2008 15:27:30 -0500 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <4F88D761-5F3F-4891-B3BD-7490FC7E7A2A@cs.purdue.edu> References: <20080107073815.DBCDD10D45C8@birch.elegosoft.com> <4F88D761-5F3F-4891-B3BD-7490FC7E7A2A@cs.purdue.edu> Message-ID: Also, following up on your changes for the backend. I suggest you take a look at the way things are handled in the M3BackLinux.m3 code for PM3. You should be able to switch between the integrated backend and the gcc-based backend similarly, based on the value of the M3_BACKEND_MODE flag. Thus, controlling the backend is a simple matter of changing the cm3.cfg. On Jan 7, 2008, at 3:16 PM, Tony Hosking wrote: > Jay, I am very nervous about the pervasive nature of some of your > recent commits. NT386GNU is usually configured with > OS_TYPE="POSIX". Thus, the m3makefile for cm3, which contains the > following: > > if equal (OS_TYPE, "POSIX") > interface ("M3Backend") > implementation ("M3BackPosix") > implementation ("UtilsPosix") > else > import ("m3objfile") > import ("m3back") > interface ("M3Backend") > implementation ("M3BackWin32") > implementation ("UtilsWin32") > end > > will build a POSIX backend for you on NT386GNU which should do the > right thing in invoking the gcc-based backend. Your changes, which > hardwire things in cm3 for NT386GNU are thus unnecessary. I > suggest you back these changes out and reconsider things. > Certainly, NT386GNU should be considered as an independent POSIX > target from the NT386 WIN32 target. Thus, one need not make > changes to M3BackWin32 for NT386GNU, since it is treated as a POSIX > target. > > As far as threading goes, if user-level threading for NT386 does > not work then I can imagine it would be OK to use native WIN32 > threads. The switch for that is in m3core/src/thread/m3makefile, > which would check for TARGET="NT386GNU" and choose sibdirectory > WIN32 instead of using OS_TYPE to pick subdirectory POSIX. > > On Jan 7, 2008, at 8:38 AM, Jay Krell wrote: > >> CVSROOT: /usr/cvs >> Changes by: jkrell at birch. 08/01/07 08:38:15 >> >> Modified files: >> cm3/m3-libs/m3core/src/unix/cygwin/: Umman.i3 Uresource.i3 >> Utypes.m3 >> cm3/m3-sys/cm3/src/: Builder.i3 Builder.m3 M3BackPosix.m3 >> M3BackWin32.m3 M3Backend.i3 >> cm3/m3-sys/cminstall/src/config/: NT386GNU >> cm3/m3-sys/m3front/src/misc/: M3Front.m3 >> >> Log message: >> some fixes for NT386GNU (cygwin) >> >> let win32 cm3 use the gcc backend if target == NT386GNU >> might need a better interface here? >> switching on target name is probably the wrong thing >> need something called "use gcc backend" or somesuch >> >> loosen the check for file name vs. module name to account for >> paths with both types of slashes >> might need a better interface/implementation here? >> should try to get the paths to line up instead? >> >> remove -fPIC since it warns that it is redundant (though the >> warning is probably wrong >> in other details -- not all code is position independent, merely >> relocatable..) >> >> use configured ar, /usr/bin/ar doesn't work, just plain ar does >> >> update Umman.i3 MAP_ANONYMOUS to new shorter name MAP_ANON >> >> update Uresource.i3 from struct_rusage_start to VAR struct_rusage >> >> fix warning about unused import long in Utypes.m3 >> >> change SYSTEM_CC from cc to gcc because cc is something on my >> system, >> that I have not investigated, and doesn't work; gcc is perfectly >> ok here, though >> cc lines up nicely with the other two character names -- ar and as >> >> now need to deal with threads to get m3core to build > From hosking at cs.purdue.edu Mon Jan 7 21:28:59 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 7 Jan 2008 15:28:59 -0500 Subject: [M3devel] CM3 on Leopard In-Reply-To: <934FB1C7-75A5-4720-B14E-EFAF6CD52C46@darko.org> References: <6CD6F1AC-449E-421D-A26A-C50BA1DFC301@darko.org> <934FB1C7-75A5-4720-B14E-EFAF6CD52C46@darko.org> Message-ID: <2774155B-86E0-4F68-B1D6-AB1FCC9A8AB2@cs.purdue.edu> Very cool! I was thinking it was going to be more painful. Have you bootstrapped a new compiler? On Jan 7, 2008, at 3:23 PM, Darko wrote: > It seems that I just forgot to install the latest tools. I fixed it > by installing XCode from the Leopard DVD. > > Exceptions seem to work ok, but I did a very basic test. Maybe I > can run the regression test suite on 10.5 when it's finished. I'll > report any problems meanwhile. > > Thanks, > Darko. > > > > On 07/01/2008, at 11:08 AM, Tony Hosking wrote: > >> >> On Jan 7, 2008, at 1:12 PM, Darko wrote: >> >>> Hi Tony, >>> >>> Are you using CM3 on Leopard, aka Mac OS X 10.5? >> >> No, I've deliberately *not* upgraded to Leopard until I am able to >> test CM3 on it. Generally, I avoid bleeding edge OS upgrades for >> precisely this reason. I don't know when I will have time to play >> with CM3 on Leopard. Right now, I am tracking down another issue >> related to the regression framework Olaf is putting together. >> >>> It's stopped working since I upgraded, I get: >>> >>> cc -o parser -fPIC _m3main.o [ ... various libs, modules ... ] - >>> lm3gcdefs -lm -multiply_defined suppress -bind_at_load -shared- >>> libgcc >> >> At least this suggest your cm3 binary was able to run on Leopard, >> which is a good start. >> >>> >>> /usr/bin/ld: /usr/lib/gcc/i686-apple-darwin8/4.0.1/../../../ >>> libm.dylib unknown flags (type) of section 6 >>> (__TEXT,__dof_plockstat) in load command 0 >>> /usr/bin/ld: can't locate file for: -lgcc_s.10.4 >>> collect2: ld returned 1 exit status >>> >>> when trying to compile. Uname says: >>> >>> Darwin Lucifer.local 9.1.0 Darwin Kernel Version 9.1.0: Wed Oct >>> 31 17:46:22 PDT 2007; root:xnu-1228.0.2~1/RELEASE_I386 i386 >>> >>> It would seem that i just needs to be nudged up to the right >>> version, but I couldn't find anything in the cfg file. Any >>> suggestions? >> >> I suspect that you need to rebuild the m3cg backend, but I have no >> idea how well it will play with Leopard. >> >> Also, I have heard there were changes to ucontexts and other >> thread state which may mean M3 exceptions break, but I have not >> verified yet. >> >>> >>> Thanks, >>> Darko. >>> >> From darko at darko.org Mon Jan 7 21:41:48 2008 From: darko at darko.org (Darko) Date: Mon, 7 Jan 2008 12:41:48 -0800 Subject: [M3devel] CM3 on Leopard In-Reply-To: <2774155B-86E0-4F68-B1D6-AB1FCC9A8AB2@cs.purdue.edu> References: <6CD6F1AC-449E-421D-A26A-C50BA1DFC301@darko.org> <934FB1C7-75A5-4720-B14E-EFAF6CD52C46@darko.org> <2774155B-86E0-4F68-B1D6-AB1FCC9A8AB2@cs.purdue.edu> Message-ID: No, that's actually my idea of pain - the scripts never seem to work for me. But I'll give it a try because I need to have a go at the (byte) alignment problem evident with the current Intel Darwin compiler at some point. I've actually never really had a problem with Mac OS revisions beyond a cfg file tweak or a rollback of gcc versions. On 07/01/2008, at 12:28 PM, Tony Hosking wrote: > Very cool! I was thinking it was going to be more painful. Have > you bootstrapped a new compiler? > > > On Jan 7, 2008, at 3:23 PM, Darko wrote: > >> It seems that I just forgot to install the latest tools. I fixed it >> by installing XCode from the Leopard DVD. >> >> Exceptions seem to work ok, but I did a very basic test. Maybe I >> can run the regression test suite on 10.5 when it's finished. I'll >> report any problems meanwhile. >> >> Thanks, >> Darko. >> >> >> >> On 07/01/2008, at 11:08 AM, Tony Hosking wrote: >> >>> >>> On Jan 7, 2008, at 1:12 PM, Darko wrote: >>> >>>> Hi Tony, >>>> >>>> Are you using CM3 on Leopard, aka Mac OS X 10.5? >>> >>> No, I've deliberately *not* upgraded to Leopard until I am able to >>> test CM3 on it. Generally, I avoid bleeding edge OS upgrades for >>> precisely this reason. I don't know when I will have time to play >>> with CM3 on Leopard. Right now, I am tracking down another issue >>> related to the regression framework Olaf is putting together. >>> >>>> It's stopped working since I upgraded, I get: >>>> >>>> cc -o parser -fPIC _m3main.o [ ... various libs, modules ... ] - >>>> lm3gcdefs -lm -multiply_defined suppress -bind_at_load -shared- >>>> libgcc >>> >>> At least this suggest your cm3 binary was able to run on Leopard, >>> which is a good start. >>> >>>> >>>> /usr/bin/ld: /usr/lib/gcc/i686-apple-darwin8/4.0.1/../../../ >>>> libm.dylib unknown flags (type) of section 6 >>>> (__TEXT,__dof_plockstat) in load command 0 >>>> /usr/bin/ld: can't locate file for: -lgcc_s.10.4 >>>> collect2: ld returned 1 exit status >>>> >>>> when trying to compile. Uname says: >>>> >>>> Darwin Lucifer.local 9.1.0 Darwin Kernel Version 9.1.0: Wed Oct >>>> 31 17:46:22 PDT 2007; root:xnu-1228.0.2~1/RELEASE_I386 i386 >>>> >>>> It would seem that i just needs to be nudged up to the right >>>> version, but I couldn't find anything in the cfg file. Any >>>> suggestions? >>> >>> I suspect that you need to rebuild the m3cg backend, but I have no >>> idea how well it will play with Leopard. >>> >>> Also, I have heard there were changes to ucontexts and other >>> thread state which may mean M3 exceptions break, but I have not >>> verified yet. >>> >>>> >>>> Thanks, >>>> Darko. >>>> >>> > From jayk123 at hotmail.com Mon Jan 7 22:10:28 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 7 Jan 2008 21:10:28 +0000 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: References: <20080107073815.DBCDD10D45C8@birch.elegosoft.com> <4F88D761-5F3F-4891-B3BD-7490FC7E7A2A@cs.purdue.edu> Message-ID: > Thus, controlling the backend is a simple matter of changing the cm3.cfg Exactly. What I have right now is I build an NT386/Win32 cm3, and then I change the config file, and that one cm3 switches between gcc or not. It is a hybrid. I can already compile all of m3core with this cm3/m3cg, except for threading. I also copy the NT386 directories in pkg to NT386GNU, and possibly foo.lib to libfoo.a -- I have to try again to see if that was the key or not. This gives me an easier sort of "cross", on one machine/OS. I actually swap out the entire cm3.cfg, cm3/m3-sys/cminstall/config/NT386 vs. cm3/m3-sys/cminstall/config/NT386GNU, not just one line. I'll try the "mode" and look at pm3. Thanks. > threading Yeah I thought Win32 would work. I'll try/look again. Later. I think it was set for Posix/setjmp/longjmp and I think I tried pthreads, might not have tried Win32. - Jay > From: hosking at cs.purdue.edu > Date: Mon, 7 Jan 2008 15:27:30 -0500 > To: hosking at cs.purdue.edu > CC: m3devel at elegosoft.com; m3commit at elegosoft.com > Subject: Re: [M3commit] CVS Update: cm3 > > Also, following up on your changes for the backend. I suggest you > take a look at the way things are handled in the M3BackLinux.m3 code > for PM3. You should be able to switch between the integrated backend > and the gcc-based backend similarly, based on the value of the > M3_BACKEND_MODE flag. Thus, controlling the backend is a simple > matter of changing the cm3.cfg. > > > > On Jan 7, 2008, at 3:16 PM, Tony Hosking wrote: > > > Jay, I am very nervous about the pervasive nature of some of your > > recent commits. NT386GNU is usually configured with > > OS_TYPE="POSIX". Thus, the m3makefile for cm3, which contains the > > following: > > > > if equal (OS_TYPE, "POSIX") > > interface ("M3Backend") > > implementation ("M3BackPosix") > > implementation ("UtilsPosix") > > else > > import ("m3objfile") > > import ("m3back") > > interface ("M3Backend") > > implementation ("M3BackWin32") > > implementation ("UtilsWin32") > > end > > > > will build a POSIX backend for you on NT386GNU which should do the > > right thing in invoking the gcc-based backend. Your changes, which > > hardwire things in cm3 for NT386GNU are thus unnecessary. I > > suggest you back these changes out and reconsider things. > > Certainly, NT386GNU should be considered as an independent POSIX > > target from the NT386 WIN32 target. Thus, one need not make > > changes to M3BackWin32 for NT386GNU, since it is treated as a POSIX > > target. > > > > As far as threading goes, if user-level threading for NT386 does > > not work then I can imagine it would be OK to use native WIN32 > > threads. The switch for that is in m3core/src/thread/m3makefile, > > which would check for TARGET="NT386GNU" and choose sibdirectory > > WIN32 instead of using OS_TYPE to pick subdirectory POSIX. > > > > On Jan 7, 2008, at 8:38 AM, Jay Krell wrote: > > > >> CVSROOT: /usr/cvs > >> Changes by: jkrell at birch. 08/01/07 08:38:15 > >> > >> Modified files: > >> cm3/m3-libs/m3core/src/unix/cygwin/: Umman.i3 Uresource.i3 > >> Utypes.m3 > >> cm3/m3-sys/cm3/src/: Builder.i3 Builder.m3 M3BackPosix.m3 > >> M3BackWin32.m3 M3Backend.i3 > >> cm3/m3-sys/cminstall/src/config/: NT386GNU > >> cm3/m3-sys/m3front/src/misc/: M3Front.m3 > >> > >> Log message: > >> some fixes for NT386GNU (cygwin) > >> > >> let win32 cm3 use the gcc backend if target == NT386GNU > >> might need a better interface here? > >> switching on target name is probably the wrong thing > >> need something called "use gcc backend" or somesuch > >> > >> loosen the check for file name vs. module name to account for > >> paths with both types of slashes > >> might need a better interface/implementation here? > >> should try to get the paths to line up instead? > >> > >> remove -fPIC since it warns that it is redundant (though the > >> warning is probably wrong > >> in other details -- not all code is position independent, merely > >> relocatable..) > >> > >> use configured ar, /usr/bin/ar doesn't work, just plain ar does > >> > >> update Umman.i3 MAP_ANONYMOUS to new shorter name MAP_ANON > >> > >> update Uresource.i3 from struct_rusage_start to VAR struct_rusage > >> > >> fix warning about unused import long in Utypes.m3 > >> > >> change SYSTEM_CC from cc to gcc because cc is something on my > >> system, > >> that I have not investigated, and doesn't work; gcc is perfectly > >> ok here, though > >> cc lines up nicely with the other two character names -- ar and as > >> > >> now need to deal with threads to get m3core to build > > > _________________________________________________________________ Watch ?Cause Effect,? a show about real people making a real difference. http://im.live.com/Messenger/IM/MTV/?source=text_watchcause -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon Jan 7 22:21:37 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 7 Jan 2008 16:21:37 -0500 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: References: <20080107073815.DBCDD10D45C8@birch.elegosoft.com> <4F88D761-5F3F-4891-B3BD-7490FC7E7A2A@cs.purdue.edu> Message-ID: I'm about to check in a version that achieves what you want based on M3_BACKEND_MODE in cm3.cfg without the nasty hack of hardwiring cm3. On Jan 7, 2008, at 4:10 PM, Jay wrote: > > >> Thus, controlling the backend is a simple matter of changing the >> cm3.cfg > > > > Exactly. > > > What I have right now is I build an NT386/Win32 cm3, and then I > change the config file, and that one cm3 switches between gcc or not. > It is a hybrid. > I can already compile all of m3core with this cm3/m3cg, except for > threading. > I also copy the NT386 directories in pkg to NT386GNU, and possibly > foo.lib to libfoo.a -- I have to try again to see if that was the > key or not. > This gives me an easier sort of "cross", on one machine/OS. > > I actually swap out the entire cm3.cfg, cm3/m3-sys/cminstall/config/ > NT386 vs. cm3/m3-sys/cminstall/config/NT386GNU, not just one line. > > I'll try the "mode" and look at pm3. Thanks. > > >> threading > > Yeah I thought Win32 would work. I'll try/look again. Later. > I think it was set for Posix/setjmp/longjmp and I think I tried > pthreads, might not have tried Win32. > > - Jay > >> From: hosking at cs.purdue.edu >> Date: Mon, 7 Jan 2008 15:27:30 -0500 >> To: hosking at cs.purdue.edu >> CC: m3devel at elegosoft.com; m3commit at elegosoft.com >> Subject: Re: [M3commit] CVS Update: cm3 >> >> Also, following up on your changes for the backend. I suggest you >> take a look at the way things are handled in the M3BackLinux.m3 code >> for PM3. You should be able to switch between the integrated backend >> and the gcc-based backend similarly, based on the value of the >> M3_BACKEND_MODE flag. Thus, controlling the backend is a simple >> matter of changing the cm3.cfg. >> >> >> >> On Jan 7, 2008, at 3:16 PM, Tony Hosking wrote: >> >>> Jay, I am very nervous about the pervasive nature of some of your >>> recent commits. NT386GNU is usually configured with >>> OS_TYPE="POSIX". Thus, the m3makefile for cm3, which contains the >>> following: >>> >>> if equal (OS_TYPE, "POSIX") >>> interface ("M3Backend") >>> implementation ("M3BackPosix") >>> implementation ("UtilsPosix") >>> else >>> import ("m3objfile") >>> import ("m3back") >>> interface ("M3Backend") >>> implementation ("M3BackWin32") >>> implementation ("UtilsWin32") >>> end >>> >>> will build a POSIX backend for you on NT386GNU which should do the >>> right thing in invoking the gcc-based backend. Your changes, which >>> hardwire things in cm3 for NT386GNU are thus unnecessary. I >>> suggest you back these changes out and reconsider things. >>> Certainly, NT386GNU should be considered as an independent POSIX >>> target from the NT386 WIN32 target. Thus, one need not make >>> changes to M3BackWin32 for NT386GNU, since it is treated as a POSIX >>> target. >>> >>> As far as threading goes, if user-level threading for NT386 does >>> not work then I can imagine it would be OK to use native WIN32 >>> threads. The switch for that is in m3core/src/thread/m3makefile, >>> which would check for TARGET="NT386GNU" and choose sibdirectory >>> WIN32 instead of using OS_TYPE to pick subdirectory POSIX. >>> >>> On Jan 7, 2008, at 8:38 AM, Jay Krell wrote: >>> >>>> CVSROOT: /usr/cvs >>>> Changes by: jkrell at birch. 08/01/07 08:38:15 >>>> >>>> Modified files: >>>> cm3/m3-libs/m3core/src/unix/cygwin/: Umman.i3 Uresource.i3 >>>> Utypes.m3 >>>> cm3/m3-sys/cm3/src/: Builder.i3 Builder.m3 M3BackPosix.m3 >>>> M3BackWin32.m3 M3Backend.i3 >>>> cm3/m3-sys/cminstall/src/config/: NT386GNU >>>> cm3/m3-sys/m3front/src/misc/: M3Front.m3 >>>> >>>> Log message: >>>> some fixes for NT386GNU (cygwin) >>>> >>>> let win32 cm3 use the gcc backend if target == NT386GNU >>>> might need a better interface here? >>>> switching on target name is probably the wrong thing >>>> need something called "use gcc backend" or somesuch >>>> >>>> loosen the check for file name vs. module name to account for >>>> paths with both types of slashes >>>> might need a better interface/implementation here? >>>> should try to get the paths to line up instead? >>>> >>>> remove -fPIC since it warns that it is redundant (though the >>>> warning is probably wrong >>>> in other details -- not all code is position independent, merely >>>> relocatable..) >>>> >>>> use configured ar, /usr/bin/ar doesn't work, just plain ar does >>>> >>>> update Umman.i3 MAP_ANONYMOUS to new shorter name MAP_ANON >>>> >>>> update Uresource.i3 from struct_rusage_start to VAR struct_rusage >>>> >>>> fix warning about unused import long in Utypes.m3 >>>> >>>> change SYSTEM_CC from cc to gcc because cc is something on my >>>> system, >>>> that I have not investigated, and doesn't work; gcc is perfectly >>>> ok here, though >>>> cc lines up nicely with the other two character names -- ar and as >>>> >>>> now need to deal with threads to get m3core to build >>> >> > > _________________________________________________________________ > Watch ?Cause Effect,? a show about real people making a real > difference From kschleiser at elego.de Mon Jan 7 22:32:53 2008 From: kschleiser at elego.de (Kaspar Schleiser) Date: Mon, 07 Jan 2008 22:32:53 +0100 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <20080107192048.3FFBB10D461D@birch.elegosoft.com> References: <20080107192048.3FFBB10D461D@birch.elegosoft.com> Message-ID: <47829A85.4070609@elego.de> Hey, Antony Hosking wrote: > Log message: > Fix bug in procedure value comparison as revealed by p035 of m3tests. Is it possible that this breaks compilation on LINUXLIBC6? I'm getting the following compiler error using the 5.4.0 release compiler, which worked OK this morning: new source -> compiling RTCollector.m3 RTCollector.m3:1878: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. Cheers, Kaspar From hosking at cs.purdue.edu Mon Jan 7 23:28:09 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 7 Jan 2008 17:28:09 -0500 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: References: <20080107073815.DBCDD10D45C8@birch.elegosoft.com> <4F88D761-5F3F-4891-B3BD-7490FC7E7A2A@cs.purdue.edu> Message-ID: I went ahead and cleaned things up to be based on M3_BACKEND_MODE instead of the overly-hardwired approach you were using. On Jan 7, 2008, at 4:10 PM, Jay wrote: > > > Thus, controlling the backend is a simple matter of changing the > cm3.cfg > > Exactly. > > What I have right now is I build an NT386/Win32 cm3, and then I > change the config file, and that one cm3 switches between gcc or not. > It is a hybrid. > I can already compile all of m3core with this cm3/m3cg, except for > threading. > I also copy the NT386 directories in pkg to NT386GNU, and possibly > foo.lib to libfoo.a -- I have to try again to see if that was the > key or not. > This gives me an easier sort of "cross", on one machine/OS. > > I actually swap out the entire cm3.cfg, cm3/m3-sys/cminstall/config/ > NT386 vs. cm3/m3-sys/cminstall/config/NT386GNU, not just one line. > > I'll try the "mode" and look at pm3. Thanks. > > > threading > > Yeah I thought Win32 would work. I'll try/look again. Later. > I think it was set for Posix/setjmp/longjmp and I think I tried > pthreads, might not have tried Win32. > > - Jay > > > From: hosking at cs.purdue.edu > > Date: Mon, 7 Jan 2008 15:27:30 -0500 > > To: hosking at cs.purdue.edu > > CC: m3devel at elegosoft.com; m3commit at elegosoft.com > > Subject: Re: [M3commit] CVS Update: cm3 > > > > Also, following up on your changes for the backend. I suggest you > > take a look at the way things are handled in the M3BackLinux.m3 code > > for PM3. You should be able to switch between the integrated backend > > and the gcc-based backend similarly, based on the value of the > > M3_BACKEND_MODE flag. Thus, controlling the backend is a simple > > matter of changing the cm3.cfg. > > > > > > > > On Jan 7, 2008, at 3:16 PM, Tony Hosking wrote: > > > > > Jay, I am very nervous about the pervasive nature of some of your > > > recent commits. NT386GNU is usually configured with > > > OS_TYPE="POSIX". Thus, the m3makefile for cm3, which contains the > > > following: > > > > > > if equal (OS_TYPE, "POSIX") > > > interface ("M3Backend") > > > implementation ("M3BackPosix") > > > implementation ("UtilsPosix") > > > else > > > import ("m3objfile") > > > import ("m3back") > > > interface ("M3Backend") > > > implementation ("M3BackWin32") > > > implementation ("UtilsWin32") > > > end > > > > > > will build a POSIX backend for you on NT386GNU which should do the > > > right thing in invoking the gcc-based backend. Your changes, which > > > hardwire things in cm3 for NT386GNU are thus unnecessary. I > > > suggest you back these changes out and reconsider things. > > > Certainly, NT386GNU should be considered as an independent POSIX > > > target from the NT386 WIN32 target. Thus, one need not make > > > changes to M3BackWin32 for NT386GNU, since it is treated as a > POSIX > > > target. > > > > > > As far as threading goes, if user-level threading for NT386 does > > > not work then I can imagine it would be OK to use native WIN32 > > > threads. The switch for that is in m3core/src/thread/m3makefile, > > > which would check for TARGET="NT386GNU" and choose sibdirectory > > > WIN32 instead of using OS_TYPE to pick subdirectory POSIX. > > > > > > On Jan 7, 2008, at 8:38 AM, Jay Krell wrote: > > > > > >> CVSROOT: /usr/cvs > > >> Changes by: jkrell at birch. 08/01/07 08:38:15 > > >> > > >> Modified files: > > >> cm3/m3-libs/m3core/src/unix/cygwin/: Umman.i3 Uresource.i3 > > >> Utypes.m3 > > >> cm3/m3-sys/cm3/src/: Builder.i3 Builder.m3 M3BackPosix.m3 > > >> M3BackWin32.m3 M3Backend.i3 > > >> cm3/m3-sys/cminstall/src/config/: NT386GNU > > >> cm3/m3-sys/m3front/src/misc/: M3Front.m3 > > >> > > >> Log message: > > >> some fixes for NT386GNU (cygwin) > > >> > > >> let win32 cm3 use the gcc backend if target == NT386GNU > > >> might need a better interface here? > > >> switching on target name is probably the wrong thing > > >> need something called "use gcc backend" or somesuch > > >> > > >> loosen the check for file name vs. module name to account for > > >> paths with both types of slashes > > >> might need a better interface/implementation here? > > >> should try to get the paths to line up instead? > > >> > > >> remove -fPIC since it warns that it is redundant (though the > > >> warning is probably wrong > > >> in other details -- not all code is position independent, merely > > >> relocatable..) > > >> > > >> use configured ar, /usr/bin/ar doesn't work, just plain ar does > > >> > > >> update Umman.i3 MAP_ANONYMOUS to new shorter name MAP_ANON > > >> > > >> update Uresource.i3 from struct_rusage_start to VAR struct_rusage > > >> > > >> fix warning about unused import long in Utypes.m3 > > >> > > >> change SYSTEM_CC from cc to gcc because cc is something on my > > >> system, > > >> that I have not investigated, and doesn't work; gcc is perfectly > > >> ok here, though > > >> cc lines up nicely with the other two character names -- ar > and as > > >> > > >> now need to deal with threads to get m3core to build > > > > > > > Watch ?Cause Effect,? a show about real people making a real > difference. Learn more From hosking at cs.purdue.edu Mon Jan 7 23:29:04 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 7 Jan 2008 17:29:04 -0500 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: References: <20080107073815.DBCDD10D45C8@birch.elegosoft.com> <4F88D761-5F3F-4891-B3BD-7490FC7E7A2A@cs.purdue.edu> Message-ID: On Jan 7, 2008, at 4:10 PM, Jay wrote: > > >> Thus, controlling the backend is a simple matter of changing the >> cm3.cfg > > > > Exactly. > > > What I have right now is I build an NT386/Win32 cm3, and then I > change the config file, and that one cm3 switches between gcc or not. > It is a hybrid. The hybrid behavior can be controlled from cm3.cfg instead. See my latest checkin. > I can already compile all of m3core with this cm3/m3cg, except for > threading. > I also copy the NT386 directories in pkg to NT386GNU, and possibly > foo.lib to libfoo.a -- I have to try again to see if that was the > key or not. > This gives me an easier sort of "cross", on one machine/OS. > > I actually swap out the entire cm3.cfg, cm3/m3-sys/cminstall/config/ > NT386 vs. cm3/m3-sys/cminstall/config/NT386GNU, not just one line. > > I'll try the "mode" and look at pm3. Thanks. > > >> threading > > Yeah I thought Win32 would work. I'll try/look again. Later. > I think it was set for Posix/setjmp/longjmp and I think I tried > pthreads, might not have tried Win32. > > - Jay > >> From: hosking at cs.purdue.edu >> Date: Mon, 7 Jan 2008 15:27:30 -0500 >> To: hosking at cs.purdue.edu >> CC: m3devel at elegosoft.com; m3commit at elegosoft.com >> Subject: Re: [M3commit] CVS Update: cm3 >> >> Also, following up on your changes for the backend. I suggest you >> take a look at the way things are handled in the M3BackLinux.m3 code >> for PM3. You should be able to switch between the integrated backend >> and the gcc-based backend similarly, based on the value of the >> M3_BACKEND_MODE flag. Thus, controlling the backend is a simple >> matter of changing the cm3.cfg. >> >> >> >> On Jan 7, 2008, at 3:16 PM, Tony Hosking wrote: >> >>> Jay, I am very nervous about the pervasive nature of some of your >>> recent commits. NT386GNU is usually configured with >>> OS_TYPE="POSIX". Thus, the m3makefile for cm3, which contains the >>> following: >>> >>> if equal (OS_TYPE, "POSIX") >>> interface ("M3Backend") >>> implementation ("M3BackPosix") >>> implementation ("UtilsPosix") >>> else >>> import ("m3objfile") >>> import ("m3back") >>> interface ("M3Backend") >>> implementation ("M3BackWin32") >>> implementation ("UtilsWin32") >>> end >>> >>> will build a POSIX backend for you on NT386GNU which should do the >>> right thing in invoking the gcc-based backend. Your changes, which >>> hardwire things in cm3 for NT386GNU are thus unnecessary. I >>> suggest you back these changes out and reconsider things. >>> Certainly, NT386GNU should be considered as an independent POSIX >>> target from the NT386 WIN32 target. Thus, one need not make >>> changes to M3BackWin32 for NT386GNU, since it is treated as a POSIX >>> target. >>> >>> As far as threading goes, if user-level threading for NT386 does >>> not work then I can imagine it would be OK to use native WIN32 >>> threads. The switch for that is in m3core/src/thread/m3makefile, >>> which would check for TARGET="NT386GNU" and choose sibdirectory >>> WIN32 instead of using OS_TYPE to pick subdirectory POSIX. >>> >>> On Jan 7, 2008, at 8:38 AM, Jay Krell wrote: >>> >>>> CVSROOT: /usr/cvs >>>> Changes by: jkrell at birch. 08/01/07 08:38:15 >>>> >>>> Modified files: >>>> cm3/m3-libs/m3core/src/unix/cygwin/: Umman.i3 Uresource.i3 >>>> Utypes.m3 >>>> cm3/m3-sys/cm3/src/: Builder.i3 Builder.m3 M3BackPosix.m3 >>>> M3BackWin32.m3 M3Backend.i3 >>>> cm3/m3-sys/cminstall/src/config/: NT386GNU >>>> cm3/m3-sys/m3front/src/misc/: M3Front.m3 >>>> >>>> Log message: >>>> some fixes for NT386GNU (cygwin) >>>> >>>> let win32 cm3 use the gcc backend if target == NT386GNU >>>> might need a better interface here? >>>> switching on target name is probably the wrong thing >>>> need something called "use gcc backend" or somesuch >>>> >>>> loosen the check for file name vs. module name to account for >>>> paths with both types of slashes >>>> might need a better interface/implementation here? >>>> should try to get the paths to line up instead? >>>> >>>> remove -fPIC since it warns that it is redundant (though the >>>> warning is probably wrong >>>> in other details -- not all code is position independent, merely >>>> relocatable..) >>>> >>>> use configured ar, /usr/bin/ar doesn't work, just plain ar does >>>> >>>> update Umman.i3 MAP_ANONYMOUS to new shorter name MAP_ANON >>>> >>>> update Uresource.i3 from struct_rusage_start to VAR struct_rusage >>>> >>>> fix warning about unused import long in Utypes.m3 >>>> >>>> change SYSTEM_CC from cc to gcc because cc is something on my >>>> system, >>>> that I have not investigated, and doesn't work; gcc is perfectly >>>> ok here, though >>>> cc lines up nicely with the other two character names -- ar and as >>>> >>>> now need to deal with threads to get m3core to build >>> >> > > _________________________________________________________________ > Watch ?Cause Effect,? a show about real people making a real > difference From jayk123 at hotmail.com Tue Jan 8 00:40:49 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 7 Jan 2008 23:40:49 +0000 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: References: <20080107073815.DBCDD10D45C8@birch.elegosoft.com> <4F88D761-5F3F-4891-B3BD-7490FC7E7A2A@cs.purdue.edu> Message-ID: Right, thanks. Looks/sounds about right. Will try it "later". Except: http://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/cm3/src/M3BackWin32.m3.diff?r1=1.2;r2=1.3 Looks suspicious, just by visual inspection, haven't built it -- missing an import and comma vs. period. Style tangent: Have people heard the advise that boolean parameters are bad, because at the callsite esp. they don't give much meaning? What is TRUE? What is FALSE? Enums or named parameters are clearer. Furthermore, heck, the switch on small integers 0,1,2,3... (Not that my switching on targetname was good either.) And, more importantly, given a commit, how do I view it? Easily?Currently I hunt around to each file and view it, but I have to manually navigate to each file in cvs web. I want all the diffs associated with one checkin to be viewable together, no matter which all files were checked at the same time. - Jay > CC: m3devel at elegosoft.com; m3commit at elegosoft.com> From: hosking at cs.purdue.edu> Subject: Re: [M3commit] CVS Update: cm3> Date: Mon, 7 Jan 2008 17:29:04 -0500> To: jayk123 at hotmail.com> > > On Jan 7, 2008, at 4:10 PM, Jay wrote:> > >> >> >> Thus, controlling the backend is a simple matter of changing the > >> cm3.cfg> >> >> >> > Exactly.> >> >> > What I have right now is I build an NT386/Win32 cm3, and then I > > change the config file, and that one cm3 switches between gcc or not.> > It is a hybrid.> > The hybrid behavior can be controlled from cm3.cfg instead. See my > latest checkin.> > > I can already compile all of m3core with this cm3/m3cg, except for > > threading.> > I also copy the NT386 directories in pkg to NT386GNU, and possibly > > foo.lib to libfoo.a -- I have to try again to see if that was the > > key or not.> > This gives me an easier sort of "cross", on one machine/OS.> >> > I actually swap out the entire cm3.cfg, cm3/m3-sys/cminstall/config/ > > NT386 vs. cm3/m3-sys/cminstall/config/NT386GNU, not just one line.> >> > I'll try the "mode" and look at pm3. Thanks.> >> >> >> threading> >> > Yeah I thought Win32 would work. I'll try/look again. Later.> > I think it was set for Posix/setjmp/longjmp and I think I tried > > pthreads, might not have tried Win32.> >> > - Jay> >> >> From: hosking at cs.purdue.edu> >> Date: Mon, 7 Jan 2008 15:27:30 -0500> >> To: hosking at cs.purdue.edu> >> CC: m3devel at elegosoft.com; m3commit at elegosoft.com> >> Subject: Re: [M3commit] CVS Update: cm3> >>> >> Also, following up on your changes for the backend. I suggest you> >> take a look at the way things are handled in the M3BackLinux.m3 code> >> for PM3. You should be able to switch between the integrated backend> >> and the gcc-based backend similarly, based on the value of the> >> M3_BACKEND_MODE flag. Thus, controlling the backend is a simple> >> matter of changing the cm3.cfg.> >>> >>> >>> >> On Jan 7, 2008, at 3:16 PM, Tony Hosking wrote:> >>> >>> Jay, I am very nervous about the pervasive nature of some of your> >>> recent commits. NT386GNU is usually configured with> >>> OS_TYPE="POSIX". Thus, the m3makefile for cm3, which contains the> >>> following:> >>>> >>> if equal (OS_TYPE, "POSIX")> >>> interface ("M3Backend")> >>> implementation ("M3BackPosix")> >>> implementation ("UtilsPosix")> >>> else> >>> import ("m3objfile")> >>> import ("m3back")> >>> interface ("M3Backend")> >>> implementation ("M3BackWin32")> >>> implementation ("UtilsWin32")> >>> end> >>>> >>> will build a POSIX backend for you on NT386GNU which should do the> >>> right thing in invoking the gcc-based backend. Your changes, which> >>> hardwire things in cm3 for NT386GNU are thus unnecessary. I> >>> suggest you back these changes out and reconsider things.> >>> Certainly, NT386GNU should be considered as an independent POSIX> >>> target from the NT386 WIN32 target. Thus, one need not make> >>> changes to M3BackWin32 for NT386GNU, since it is treated as a POSIX> >>> target.> >>>> >>> As far as threading goes, if user-level threading for NT386 does> >>> not work then I can imagine it would be OK to use native WIN32> >>> threads. The switch for that is in m3core/src/thread/m3makefile,> >>> which would check for TARGET="NT386GNU" and choose sibdirectory> >>> WIN32 instead of using OS_TYPE to pick subdirectory POSIX.> >>>> >>> On Jan 7, 2008, at 8:38 AM, Jay Krell wrote:> >>>> >>>> CVSROOT: /usr/cvs> >>>> Changes by: jkrell at birch. 08/01/07 08:38:15> >>>>> >>>> Modified files:> >>>> cm3/m3-libs/m3core/src/unix/cygwin/: Umman.i3 Uresource.i3> >>>> Utypes.m3> >>>> cm3/m3-sys/cm3/src/: Builder.i3 Builder.m3 M3BackPosix.m3> >>>> M3BackWin32.m3 M3Backend.i3> >>>> cm3/m3-sys/cminstall/src/config/: NT386GNU> >>>> cm3/m3-sys/m3front/src/misc/: M3Front.m3> >>>>> >>>> Log message:> >>>> some fixes for NT386GNU (cygwin)> >>>> > >>>> let win32 cm3 use the gcc backend if target == NT386GNU> >>>> might need a better interface here?> >>>> switching on target name is probably the wrong thing> >>>> need something called "use gcc backend" or somesuch> >>>> > >>>> loosen the check for file name vs. module name to account for> >>>> paths with both types of slashes> >>>> might need a better interface/implementation here?> >>>> should try to get the paths to line up instead?> >>>> > >>>> remove -fPIC since it warns that it is redundant (though the> >>>> warning is probably wrong> >>>> in other details -- not all code is position independent, merely> >>>> relocatable..)> >>>> > >>>> use configured ar, /usr/bin/ar doesn't work, just plain ar does> >>>> > >>>> update Umman.i3 MAP_ANONYMOUS to new shorter name MAP_ANON> >>>> > >>>> update Uresource.i3 from struct_rusage_start to VAR struct_rusage> >>>> > >>>> fix warning about unused import long in Utypes.m3> >>>> > >>>> change SYSTEM_CC from cc to gcc because cc is something on my> >>>> system,> >>>> that I have not investigated, and doesn't work; gcc is perfectly> >>>> ok here, though> >>>> cc lines up nicely with the other two character names -- ar and as> >>>> > >>>> now need to deal with threads to get m3core to build> >>>> >>> >> > _________________________________________________________________> > Watch ?Cause Effect,? a show about real people making a real > > difference> _________________________________________________________________ Share life as it happens with the new Windows Live. http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Tue Jan 8 01:16:58 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 08 Jan 2008 01:16:58 +0100 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: References: <20080107073815.DBCDD10D45C8@birch.elegosoft.com> <4F88D761-5F3F-4891-B3BD-7490FC7E7A2A@cs.purdue.edu> Message-ID: <20080108011658.dp4d4zumw4wwkg88@mail.elegosoft.com> Quoting Jay : > Style tangent: Have people heard the advise that boolean parameters > are bad, because at the callsite esp. they don't give much meaning? > What is TRUE? What is FALSE? Enums or named parameters are clearer. I tend to agree, but this might get religious ;-) > And, more importantly, given a commit, how do I view it? > Easily?Currently I hunt around to each file and view it, but I have > to manually navigate to each file in cvs web. > I want all the diffs associated with one checkin to be viewable > together, no matter which all files were checked at the same time. You need two tags or dates to view changeset-like differences with CVS. For example cvs diff -u -r release_CM3_5_4_0 -r HEAD m3-libs will list all the changes in libraries between release 5.4.0 and the current HEAD. cvs diff -u -D yesterday -D now m3-sys Of course you can use other date formats, too, for example "1972-09-24 20:05" or "24 Sep 1972 20:05" or "1 hour ago". Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Jan 8 03:32:14 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 7 Jan 2008 21:32:14 -0500 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <47829A85.4070609@elego.de> References: <20080107192048.3FFBB10D461D@birch.elegosoft.com> <47829A85.4070609@elego.de> Message-ID: On Jan 7, 2008, at 4:32 PM, Kaspar Schleiser wrote: > Hey, > > Antony Hosking wrote: >> Log message: >> Fix bug in procedure value comparison as revealed by p035 of >> m3tests. > Is it possible that this breaks compilation on LINUXLIBC6? > I'm getting the following compiler error using the 5.4.0 release > compiler, which worked OK this morning: > > new source -> compiling RTCollector.m3 > RTCollector.m3:1878: internal compiler error: Segmentation fault > Please submit a full bug report, > with preprocessed source if appropriate. > See for instructions. Yeah, I have the same problem on I386_DARWIN. I will track down the problem tomorrow. Sorry for all the brokenness today -- it pays to compile and test before committing. It did fix the problem with p035 though. :-) > > Cheers, > Kaspar From hosking at cs.purdue.edu Tue Jan 8 04:02:34 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 7 Jan 2008 22:02:34 -0500 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <20080108011658.dp4d4zumw4wwkg88@mail.elegosoft.com> References: <20080107073815.DBCDD10D45C8@birch.elegosoft.com> <4F88D761-5F3F-4891-B3BD-7490FC7E7A2A@cs.purdue.edu> <20080108011658.dp4d4zumw4wwkg88@mail.elegosoft.com> Message-ID: On Jan 7, 2008, at 7:16 PM, Olaf Wagner wrote: > Quoting Jay : > >> Style tangent: Have people heard the advise that boolean >> parameters are bad, because at the callsite esp. they don't give >> much meaning? What is TRUE? What is FALSE? Enums or named >> parameters are clearer. > > I tend to agree, but this might get religious ;-) Indeed. I considered [0..3] but decided against it. :-) But seriously, an alternative would have been a new type in the interface I suppose. Given that it is a private module to the package I didn't feel overly compelled to be more obvious. From hosking at cs.purdue.edu Tue Jan 8 07:23:58 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 8 Jan 2008 01:23:58 -0500 Subject: [M3devel] more m3tests failures In-Reply-To: <20080108013027.jjutp2wnc48gwsk4@mail.elegosoft.com> References: <20080105210005.7iacdx5nkks84osk@mail.elegosoft.com> <20080108013027.jjutp2wnc48gwsk4@mail.elegosoft.com> Message-ID: <4E362486-79CE-4283-AA39-D18066C9E44F@cs.purdue.edu> Seems to be fixed now. Includes fix for p035. On Jan 7, 2008, at 7:30 PM, Olaf Wagner wrote: > Quoting Tony Hosking : > >> I just checked in the fix for p035, with changes to the gcc-based >> backend (tree-nested.c and parse.c). > > As Kaspar has already noticed, this seems to break compilation > of m3core: > > +++ cm3 -build -override -DROOT='/d/home/wagner/work/cm3' - > DCM3_VERSION_TEXT='d5.5.1' -DCM3_VERSION_NUMBER='050501' - > DCM3_LAST_CHANGED='2007-12-30' +++ > --- building in FreeBSD4 --- > > new source -> compiling RTCollector.m3 > RTCollector.m3:1878: internal compiler error: Segmentation fault: 11 > Please submit a full bug report, > with preprocessed source if appropriate. > See for instructions. > compilation failed => not building library "libm3core.a" > Fatal Error: package build failed > *** execution of failed *** > > Olaf >> >> On Jan 5, 2008, at 3:00 PM, Olaf Wagner wrote: >> >>> I've looked into some more failures of m3tests, which I'd like to >>> present to the whole list: (All tests run on FreeBSD 6.3) >>> >>> p035 is a scoping problem which was Ok with >>> >>> /usr/local/cm3/bin/cm3cg-5.4.0 >>> >>> but >>> >>> /usr/local/cm3/bin/cm3cg-d5.5.1 >>> >>> fails, so it must be caused by recent gcc changes. The check that >>> fails is >>> >>> PROCEDURE foo (p: P; same: BOOLEAN) = >>> BEGIN >>> checkB (bar = p, same); checkB (bar # p, NOT same); >>> END foo; >>> PROCEDURE bar (<*UNUSED*> t: Text.T) = >>> BEGIN >>> END bar; >>> BEGIN >>> msg ("group M"); foo (bar, TRUE); >>> msg ("group N"); foo (dummy, FALSE); >>> END; > > > > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, > Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Jan 8 09:13:22 2008 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Tue, 08 Jan 2008 09:13:22 +0100 Subject: [M3devel] Didn't happen for long time now... pthread related error while ./scripts/do-cm3-std.sh build Message-ID: <1199780002.11961.28.camel@faramir.m3w.org> I have Fedora6 on this box, and I've building cm3 for long time on it. Last night ago I've updated my local repo to CVS head, and tried this script.. It breaks on every package linking pthread, looks like. Then I cd to package folder, type "cm3", and it links ok. Example is at end of message. cm3.cfg changes? Here is what I think is relevant in my current. % grep -i pthread /usr/local/cm3/bin/cm3.cfg -A1 -B1 "LIBC" : [ "-lm" ], "PTHREAD" : ["-L/usr/lib", "-lpthread"], %-- not on most Linux platforms -- SYSTEM_LIBORDER = [ "OPENGL", "DECPEX", "MOTIF", "X11", "TCP", "ODBC", "POSTGRES95", "FLEX-BISON", "LEX-YACC", "LIBC", "PTHREAD" ] TIA, dd > === package m3-tools/m3totex === > +++ cm3 -DPTHREAD -build -override -DROOT='/home/dragisha/src/cm3-cvshead-0629/cm3' -DCM3_VERSION_TEXT='d5.5.1' -DCM3_VERSION_NUMBER='050501' -DCM3_LAST_CHANGED='2007-12-30' +++ > --- building in LINUXLIBC6 --- > > /home/dragisha/src/cm3-cvshead-0629/cm3/m3-tools/m3bundle/LINUXLIBC6/m3bundle -name B -F/var/tmp/qk > new source -> compiling B.i3 > new source -> compiling B.m3 > new source -> compiling m3totex.m3 > -> linking m3totex > /home/dragisha/src/cm3-cvshead-0629/cm3/m3-libs/m3core/LINUXLIBC6/libm3core.so: undefined reference to `sem_init' > /home/dragisha/src/cm3-cvshead-0629/cm3/m3-libs/m3core/LINUXLIBC6/libm3core.so: undefined reference to `pthread_key_create' > /home/dragisha/src/cm3-cvshead-0629/cm3/m3-libs/m3core/LINUXLIBC6/libm3core.so: undefined reference to `pthread_attr_setstacksize' > /home/dragisha/src/cm3-cvshead-0629/cm3/m3-libs/m3core/LINUXLIBC6/libm3core.so: undefined reference to `pthread_kill' > /home/dragisha/src/cm3-cvshead-0629/cm3/m3-libs/m3core/LINUXLIBC6/libm3core.so: undefined reference to `pthread_getspecific' > /home/dragisha/src/cm3-cvshead-0629/cm3/m3-libs/m3core/LINUXLIBC6/libm3core.so: undefined reference to `pthread_create' > /home/dragisha/src/cm3-cvshead-0629/cm3/m3-libs/m3core/LINUXLIBC6/libm3core.so: undefined reference to `pthread_attr_getstacksize' > /home/dragisha/src/cm3-cvshead-0629/cm3/m3-libs/m3core/LINUXLIBC6/libm3core.so: undefined reference to `sem_post' > /home/dragisha/src/cm3-cvshead-0629/cm3/m3-libs/m3core/LINUXLIBC6/libm3core.so: undefined reference to `pthread_detach' > /home/dragisha/src/cm3-cvshead-0629/cm3/m3-libs/m3core/LINUXLIBC6/libm3core.so: undefined reference to `sem_getvalue' > /home/dragisha/src/cm3-cvshead-0629/cm3/m3-libs/m3core/LINUXLIBC6/libm3core.so: undefined reference to `pthread_setspecific' > /home/dragisha/src/cm3-cvshead-0629/cm3/m3-libs/m3core/LINUXLIBC6/libm3core.so: undefined reference to `sem_wait' > collect2: ld returned 1 exit status > Fatal Error: package build failed > *** execution of failed *** > faramir:dragisha/pts/7: src/cm3-cvshead-0629/cm3% cd m3-tools/m3totex > faramir:dragisha/pts/7: cm3/m3-tools/m3totex% cm3 > --- building in LINUXLIBC6 --- > > ignoring ../src/m3overrides > > -> linking m3totex > faramir:dragisha/pts/7: cm3/m3-tools/m3totex% which cm3 > /usr/local/cm3/bin/cm3 > faramir:dragisha/pts/7: cm3/m3-tools/m3totex% echo $CM3 > cm3 -DPTHREAD > -- Dragi?a Duri? From lemming at henning-thielemann.de Tue Jan 8 12:29:30 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Tue, 08 Jan 2008 12:29:30 +0100 (CET) Subject: [M3devel] BOOLEAN (Was: CVS Update: cm3) In-Reply-To: <20080108011658.dp4d4zumw4wwkg88@mail.elegosoft.com> References: <20080107073815.DBCDD10D45C8@birch.elegosoft.com> <4F88D761-5F3F-4891-B3BD-7490FC7E7A2A@cs.purdue.edu> <20080108011658.dp4d4zumw4wwkg88@mail.elegosoft.com> Message-ID: On Tue, 8 Jan 2008, Olaf Wagner wrote: > Quoting Jay : > > > Style tangent: Have people heard the advise that boolean parameters > > are bad, because at the callsite esp. they don't give much meaning? > > What is TRUE? What is FALSE? Enums or named parameters are clearer. > > I tend to agree, but this might get religious ;-) In Modula-3 you can explicitly write f (switch := TRUE); Problem is of course, that you only can but you need not. Another advise I like to give about BOOLEANs is, that one should use positive flag names, e.g. not skipIntro := FALSE; but showIntro := TRUE; not disableGUI := TRUE; but enableGUI := FALSE; From jayk123 at hotmail.com Tue Jan 8 14:18:10 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 8 Jan 2008 13:18:10 +0000 Subject: [M3devel] BOOLEAN (Was: CVS Update: cm3) In-Reply-To: References: <20080107073815.DBCDD10D45C8@birch.elegosoft.com> <4F88D761-5F3F-4891-B3BD-7490FC7E7A2A@cs.purdue.edu> <20080108011658.dp4d4zumw4wwkg88@mail.elegosoft.com> Message-ID: Henning, agreed. I said named parameters help, understood that they are up to the caller to use though. Agreed about avoiding negative options, better to have an option that is positive, and leave the users as true and false, or..er..oops, that's what we are also saying not to use. I'm definitely a proponent of this second one. I actually haven't heard/used it for locals, but more for, uh, parameters. (I see I'm being hypocritical again -- don't use booleans...but if you do, use positive ones..), makes sense for locals too. On the other hand, I also like to default things to false/zero, globals, and locals, for easier/more efficient initialization, lately in C I write: void F() { type1 local1 = { 0 } type2 local2 = { 0 } .. } for all my small locals. A good compiler will optimize away at least some of them (as long as they aren't "out parameters") and I've been too burned by uninitialized locals too much, and the code is usually fairly efficient otherwise (again, the initialization can often be removed by the compiler), to desire optimizing them.. So sometimes name things to favor false being the default or more common value. For globals esp. that saves space in the resulting executable. For locals, well, if you initialize all your locals to zero, the compiler can optimize that, into a small loop for zeroing...if it was REALLY smart, it'd move the locals that are zero-initialized to be adjacent, but that could trade off with other factors so I don't assume it happens. - Jay > Date: Tue, 8 Jan 2008 12:29:30 +0100> From: lemming at henning-thielemann.de> Subject: BOOLEAN (Was: CVS Update: cm3)> To: wagner at elegosoft.com> CC: jayk123 at hotmail.com; m3devel at elegosoft.com> > > On Tue, 8 Jan 2008, Olaf Wagner wrote:> > > Quoting Jay :> >> > > Style tangent: Have people heard the advise that boolean parameters> > > are bad, because at the callsite esp. they don't give much meaning?> > > What is TRUE? What is FALSE? Enums or named parameters are clearer.> >> > I tend to agree, but this might get religious ;-)> > In Modula-3 you can explicitly write> f (switch := TRUE);> Problem is of course, that you only can but you need not.> > > Another advise I like to give about BOOLEANs is, that one should use> positive flag names, e.g. not> skipIntro := FALSE;> but> showIntro := TRUE;> > not> disableGUI := TRUE;> but> enableGUI := FALSE;> _________________________________________________________________ Make distant family not so distant with Windows Vista? + Windows Live?. http://www.microsoft.com/windows/digitallife/keepintouch.mspx?ocid=TXT_TAGLM_CPC_VideoChat_distantfamily_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Tue Jan 8 14:24:00 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 8 Jan 2008 13:24:00 +0000 Subject: [M3devel] Didn't happen for long time now... pthread related error while ./scripts/do-cm3-std.sh In-Reply-To: <1199780002.11961.28.camel@faramir.m3w.org> References: <1199780002.11961.28.camel@faramir.m3w.org> Message-ID: Not my area of expertise, but, try this: > "LIBC" : [ "-lm", "-L/usr/lib", "-lpthread" ], > "PTHREAD" : [ ], and look here: http://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/cminstall/src/config/LINUXLIBC6?rev=1.20;content-type=text%2Fplain or here: http://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/cminstall/src/config-no-install/LINUXLIBC6?rev=1.10;content-type=text%2Fplain ..ok, which suggests really, try this: "LIBC" : [ "-Xlinker", "-Bdynamic", "-L/usr/lib", "-lm", "-L/usr/lib", "-lpthread" ], and remove the PTHREAD line. (My suggest was from memory of -lpthread being on the LIBC line.) - Jay > From: dragisha at m3w.org> To: m3devel at elegosoft.com> Date: Tue, 8 Jan 2008 09:13:22 +0100> Subject: [M3devel] Didn't happen for long time now... pthread related error while ./scripts/do-cm3-std.sh build> > I have Fedora6 on this box, and I've building cm3 for long time on it.> Last night ago I've updated my local repo to CVS head, and tried this> script.. It breaks on every package linking pthread, looks like. Then I> cd to package folder, type "cm3", and it links ok. Example is at end of> message.> > cm3.cfg changes? Here is what I think is relevant in my current.> > > % grep -i pthread /usr/local/cm3/bin/cm3.cfg -A1 -B1> "LIBC" : [ "-lm" ],> "PTHREAD" : ["-L/usr/lib", "-lpthread"],> %-- not on most Linux platforms> --> SYSTEM_LIBORDER = [ "OPENGL", "DECPEX", "MOTIF", "X11", "TCP", "ODBC",> "POSTGRES95", "FLEX-BISON", "LEX-YACC", "LIBC",> "PTHREAD" ]> > TIA,> dd> > > > === package m3-tools/m3totex ===> > +++ cm3 -DPTHREAD -build -override -DROOT='/home/dragisha/src/cm3-cvshead-0629/cm3' -DCM3_VERSION_TEXT='d5.5.1' -DCM3_VERSION_NUMBER='050501' -DCM3_LAST_CHANGED='2007-12-30' +++> > --- building in LINUXLIBC6 ---> > > > /home/dragisha/src/cm3-cvshead-0629/cm3/m3-tools/m3bundle/LINUXLIBC6/m3bundle -name B -F/var/tmp/qk> > new source -> compiling B.i3> > new source -> compiling B.m3> > new source -> compiling m3totex.m3> > -> linking m3totex> > /home/dragisha/src/cm3-cvshead-0629/cm3/m3-libs/m3core/LINUXLIBC6/libm3core.so: undefined reference to `sem_init'> > /home/dragisha/src/cm3-cvshead-0629/cm3/m3-libs/m3core/LINUXLIBC6/libm3core.so: undefined reference to `pthread_key_create'> > /home/dragisha/src/cm3-cvshead-0629/cm3/m3-libs/m3core/LINUXLIBC6/libm3core.so: undefined reference to `pthread_attr_setstacksize'> > /home/dragisha/src/cm3-cvshead-0629/cm3/m3-libs/m3core/LINUXLIBC6/libm3core.so: undefined reference to `pthread_kill'> > /home/dragisha/src/cm3-cvshead-0629/cm3/m3-libs/m3core/LINUXLIBC6/libm3core.so: undefined reference to `pthread_getspecific'> > /home/dragisha/src/cm3-cvshead-0629/cm3/m3-libs/m3core/LINUXLIBC6/libm3core.so: undefined reference to `pthread_create'> > /home/dragisha/src/cm3-cvshead-0629/cm3/m3-libs/m3core/LINUXLIBC6/libm3core.so: undefined reference to `pthread_attr_getstacksize'> > /home/dragisha/src/cm3-cvshead-0629/cm3/m3-libs/m3core/LINUXLIBC6/libm3core.so: undefined reference to `sem_post'> > /home/dragisha/src/cm3-cvshead-0629/cm3/m3-libs/m3core/LINUXLIBC6/libm3core.so: undefined reference to `pthread_detach'> > /home/dragisha/src/cm3-cvshead-0629/cm3/m3-libs/m3core/LINUXLIBC6/libm3core.so: undefined reference to `sem_getvalue'> > /home/dragisha/src/cm3-cvshead-0629/cm3/m3-libs/m3core/LINUXLIBC6/libm3core.so: undefined reference to `pthread_setspecific'> > /home/dragisha/src/cm3-cvshead-0629/cm3/m3-libs/m3core/LINUXLIBC6/libm3core.so: undefined reference to `sem_wait'> > collect2: ld returned 1 exit status> > Fatal Error: package build failed> > *** execution of failed ***> > faramir:dragisha/pts/7: src/cm3-cvshead-0629/cm3% cd m3-tools/m3totex> > faramir:dragisha/pts/7: cm3/m3-tools/m3totex% cm3> > --- building in LINUXLIBC6 ---> > > > ignoring ../src/m3overrides> > > > -> linking m3totex> > faramir:dragisha/pts/7: cm3/m3-tools/m3totex% which cm3> > /usr/local/cm3/bin/cm3> > faramir:dragisha/pts/7: cm3/m3-tools/m3totex% echo $CM3> > cm3 -DPTHREAD> > > -- > Dragi?a Duri? > _________________________________________________________________ Watch "Cause Effect," a show about real people making a real difference. http://im.live.com/Messenger/IM/MTV/?source=text_watchcause -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Tue Jan 8 23:57:30 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 08 Jan 2008 23:57:30 +0100 Subject: [M3devel] pthread errors on FreeBSD In-Reply-To: References: <20080105195158.l0sirwku74k84o0s@mail.elegosoft.com> Message-ID: <20080108235730.kkfq44pjkc8s0s0o@mail.elegosoft.com> Quoting Tony Hosking : > On Jan 5, 2008, at 1:51 PM, Olaf Wagner wrote: > >> Hi Tony, >> >> I've today run the tests in m3-sys/m3tests (which were never completely >> adapted to CM3 since my initial import in 2003, I'm afraid), but there >> are two significant differences between UTHREADS and PTHREADS on >> FreeBSD. >> >> The first is the failure of p005: >> >> --- p005 --- a simple thread program >> --- p0/p005/stdout.pgm 2008-01-05 18:24:25.000000000 +0100 >> +++ ../src/p0/p005/stdout.pgm 2003-03-08 11:14:00.000000000 +0100 >> @@ -1,4 +1,4 @@ >> i = 12 >> -Changing i to 15 >> +Changing i to 19 >> Changing i to 22 >> i = 22 >> >> This concerns the order in which new threads are started. > > Whatever order they are started there is no guarantee they will reach > acquire the lock in any particular order. > >> I'm not >> sure if this is really specified, or just random; if so, the test >> should be changed. Programs which make assumptions about the order >> will of course fail then. > > The test needs changing to force a particular order. > >> The second failure shows up in p007, where `a whole bunch of threads' >> is started: >> +++ ../src/p0/p007/stderr.pgm 2003-03-08 11:14:01.000000000 +0100 >> @@ -218,11 +218,1798 @@ >> 218: 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 >> 219: 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 >> 220: 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 >> - 221: >> - >> -*** >> -*** runtime error: >> -*** Thread client error: Release failed with error: 1 >> -*** file "ThreadPThread.m3", line 174 >> -*** >> - >> + 221: 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 >> + 222: 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 >> + 223: 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 >> + 224: 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 >> + 225: 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 >> + 226: 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 >> + 227: 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 >> + 228: 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 >> + 229: 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 >> + 230: 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 >> + 231: 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 >> + 232: 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 >> + 233: 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 >> + 234: 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 >> + 235: 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 >> + 236: 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 >> >> Here a thread crashes when trying to unlock a mutex with EPERM, >> which I do not really understand. man errno says: > > I am unable to reproduce this on my I386_DARWIN machine. EPERM is the > error given if the thread trying to release the mutex does not actually > hold it. However, the ThreadPThread is already checking to make sure > the lock is held by the releasing thread, in this case claiming that > the thread *does* hold the lock. So, I suspect the EPERM error is a > result of some other problem, though I don't know what based on the > output you are showing. I wonder if you have encountered some system > limit. This seems to be caused by using the ThreadF interface to suspend other threads. If a mutex is used, the test passes: PROCEDURE Txt (t: TEXT) = BEGIN (* ThreadF.SuspendOthers (); *) LOCK iolock DO RTIO.PutText (t); END; (* ThreadF.ResumeOthers (); *) END Txt; Apart from the fact that a mutex is the correct thing to use, have you any idea why ThreadF procedures fail? It makes me a bit nervous, as they are used by the garbage collector, aren't they? Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Jan 9 00:16:36 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 8 Jan 2008 18:16:36 -0500 Subject: [M3devel] pthread errors on FreeBSD In-Reply-To: <20080108235730.kkfq44pjkc8s0s0o@mail.elegosoft.com> References: <20080105195158.l0sirwku74k84o0s@mail.elegosoft.com> <20080108235730.kkfq44pjkc8s0s0o@mail.elegosoft.com> Message-ID: Let me look into this one... On Jan 8, 2008, at 5:57 PM, Olaf Wagner wrote: > Quoting Tony Hosking : >> On Jan 5, 2008, at 1:51 PM, Olaf Wagner wrote: >> >>> The second failure shows up in p007, where `a whole bunch of >>> threads' >>> is started: >>> +++ ../src/p0/p007/stderr.pgm 2003-03-08 11:14:01.000000000 +0100 >>> @@ -218,11 +218,1798 @@ >>> 218: 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 >>> 219: 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 >>> 220: 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 >>> - 221: >>> - >>> -*** >>> -*** runtime error: >>> -*** Thread client error: Release failed with error: 1 >>> -*** file "ThreadPThread.m3", line 174 >>> -*** >>> - >>> + 221: 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 >>> + 222: 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 >>> + 223: 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 >>> + 224: 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 >>> + 225: 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 >>> + 226: 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 >>> + 227: 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 >>> + 228: 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 >>> + 229: 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 >>> + 230: 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 >>> + 231: 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 >>> + 232: 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 >>> + 233: 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 >>> + 234: 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 >>> + 235: 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 >>> + 236: 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 >>> >>> Here a thread crashes when trying to unlock a mutex with EPERM, >>> which I do not really understand. man errno says: >> >> I am unable to reproduce this on my I386_DARWIN machine. EPERM is >> the >> error given if the thread trying to release the mutex does not >> actually >> hold it. However, the ThreadPThread is already checking to make sure >> the lock is held by the releasing thread, in this case claiming that >> the thread *does* hold the lock. So, I suspect the EPERM error is a >> result of some other problem, though I don't know what based on the >> output you are showing. I wonder if you have encountered some system >> limit. > > This seems to be caused by using the ThreadF interface to suspend > other threads. If a mutex is used, the test passes: > > PROCEDURE Txt (t: TEXT) = > BEGIN > (* ThreadF.SuspendOthers (); *) > LOCK iolock DO > RTIO.PutText (t); > END; > (* ThreadF.ResumeOthers (); *) > END Txt; > > Apart from the fact that a mutex is the correct thing to use, > have you any idea why ThreadF procedures fail? It makes me a bit > nervous, as they are used by the garbage collector, aren't they? > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, > Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Wed Jan 9 04:48:25 2008 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Wed, 9 Jan 2008 04:48:25 +0100 (CET) Subject: [M3devel] Didn't happen for long time now... pthread related error while ./scripts/do-cm3-std.sh build In-Reply-To: <1199780002.11961.28.camel@faramir.m3w.org> Message-ID: <791321.83057.qm@web27112.mail.ukl.yahoo.com> Hi: Try putting "LIBC" : [ "-lm", "-lpthread" ], in cm3.cfg file I think in this Ubuntu it happened the same, so try and let we know what happens. Daniel Benavides Dragi??a Duri?? wrote: I have Fedora6 on this box, and I've building cm3 for long time on it. Last night ago I've updated my local repo to CVS head, and tried this script.. It breaks on every package linking pthread, looks like. Then I cd to package folder, type "cm3", and it links ok. Example is at end of message. cm3.cfg changes? Here is what I think is relevant in my current. % grep -i pthread /usr/local/cm3/bin/cm3.cfg -A1 -B1 "LIBC" : [ "-lm" ], "PTHREAD" : ["-L/usr/lib", "-lpthread"], %-- not on most Linux platforms -- SYSTEM_LIBORDER = [ "OPENGL", "DECPEX", "MOTIF", "X11", "TCP", "ODBC", "POSTGRES95", "FLEX-BISON", "LEX-YACC", "LIBC", "PTHREAD" ] TIA, dd > === package m3-tools/m3totex === > +++ cm3 -DPTHREAD -build -override -DROOT='/home/dragisha/src/cm3-cvshead-0629/cm3' -DCM3_VERSION_TEXT='d5.5.1' -DCM3_VERSION_NUMBER='050501' -DCM3_LAST_CHANGED='2007-12-30' +++ > --- building in LINUXLIBC6 --- > > /home/dragisha/src/cm3-cvshead-0629/cm3/m3-tools/m3bundle/LINUXLIBC6/m3bundle -name B -F/var/tmp/qk > new source -> compiling B.i3 > new source -> compiling B.m3 > new source -> compiling m3totex.m3 > -> linking m3totex > /home/dragisha/src/cm3-cvshead-0629/cm3/m3-libs/m3core/LINUXLIBC6/libm3core.so: undefined reference to `sem_init' > /home/dragisha/src/cm3-cvshead-0629/cm3/m3-libs/m3core/LINUXLIBC6/libm3core.so: undefined reference to `pthread_key_create' > /home/dragisha/src/cm3-cvshead-0629/cm3/m3-libs/m3core/LINUXLIBC6/libm3core.so: undefined reference to `pthread_attr_setstacksize' > /home/dragisha/src/cm3-cvshead-0629/cm3/m3-libs/m3core/LINUXLIBC6/libm3core.so: undefined reference to `pthread_kill' > /home/dragisha/src/cm3-cvshead-0629/cm3/m3-libs/m3core/LINUXLIBC6/libm3core.so: undefined reference to `pthread_getspecific' > /home/dragisha/src/cm3-cvshead-0629/cm3/m3-libs/m3core/LINUXLIBC6/libm3core.so: undefined reference to `pthread_create' > /home/dragisha/src/cm3-cvshead-0629/cm3/m3-libs/m3core/LINUXLIBC6/libm3core.so: undefined reference to `pthread_attr_getstacksize' > /home/dragisha/src/cm3-cvshead-0629/cm3/m3-libs/m3core/LINUXLIBC6/libm3core.so: undefined reference to `sem_post' > /home/dragisha/src/cm3-cvshead-0629/cm3/m3-libs/m3core/LINUXLIBC6/libm3core.so: undefined reference to `pthread_detach' > /home/dragisha/src/cm3-cvshead-0629/cm3/m3-libs/m3core/LINUXLIBC6/libm3core.so: undefined reference to `sem_getvalue' > /home/dragisha/src/cm3-cvshead-0629/cm3/m3-libs/m3core/LINUXLIBC6/libm3core.so: undefined reference to `pthread_setspecific' > /home/dragisha/src/cm3-cvshead-0629/cm3/m3-libs/m3core/LINUXLIBC6/libm3core.so: undefined reference to `sem_wait' > collect2: ld returned 1 exit status > Fatal Error: package build failed > *** execution of failed *** > faramir:dragisha/pts/7: src/cm3-cvshead-0629/cm3% cd m3-tools/m3totex > faramir:dragisha/pts/7: cm3/m3-tools/m3totex% cm3 > --- building in LINUXLIBC6 --- > > ignoring ../src/m3overrides > > -> linking m3totex > faramir:dragisha/pts/7: cm3/m3-tools/m3totex% which cm3 > /usr/local/cm3/bin/cm3 > faramir:dragisha/pts/7: cm3/m3-tools/m3totex% echo $CM3 > cm3 -DPTHREAD > -- Dragi??a Duri?? --------------------------------- Web Revelaci?n Yahoo! 2007: Premio Favorita del P?blico - ?Vota tu preferida! -------------- next part -------------- An HTML attachment was scrubbed... URL: From dabenavidesd at yahoo.es Wed Jan 9 05:10:17 2008 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Wed, 9 Jan 2008 05:10:17 +0100 (CET) Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: Message-ID: <909140.85424.qm@web27110.mail.ukl.yahoo.com> Hi: You can check what are the differences between a given set of files against a cvs repository with cvs and the diff option: In the below example of the directory of cm3/doc/turorial/m3 (Modula-3 tutorial), the current (in that bash session was revision 1.2), so the comparision is between my version (let's say the wanted to be commited) and the rev. 1.2: daniel at fbd-desktop:~/code/m3-devel$ cvs -d :ext:dbenavid at birch.elegosoft.com:/usr/cvs diff cm3/doc/tutorial/m3 Enter passphrase for key '/home/daniel/.ssh/id_dsa': cvs diff: Diffing cm3/doc/tutorial/m3 Index: cm3/doc/tutorial/m3/m3_2.html =================================================================== RCS file: /usr/cvs/cm3/doc/tutorial/m3/m3_2.html,v retrieving revision 1.2 diff -r1.2 m3_2.html 30c30 < IO.GetLine(name); --- > name:=IO.GetLine(); daniel at fbd-desktop:~/code/m3-devel$ The contents of the my current directory (me-devel) are: daniel at fbd-desktop:~/code/m3-devel$ ls -alh cm3/* cm3/CVS: total 20K drwxr-xr-x 2 daniel daniel 4,0K 2008-01-06 10:28 . drwxr-xr-x 4 daniel daniel 4,0K 2008-01-06 09:40 .. -rw-r--r-- 1 daniel daniel 10 2008-01-06 10:28 Entries -rw-r--r-- 1 daniel daniel 0 2008-01-06 09:40 Entries.Static -rw-r--r-- 1 daniel daniel 4 2008-01-06 09:40 Repository -rw-r--r-- 1 daniel daniel 43 2008-01-06 09:40 Root cm3/doc: total 16K drwxr-xr-x 4 daniel daniel 4,0K 2008-01-06 09:40 . drwxr-xr-x 4 daniel daniel 4,0K 2008-01-06 09:40 .. drwxr-xr-x 2 daniel daniel 4,0K 2008-01-06 10:28 CVS drwxr-xr-x 4 daniel daniel 4,0K 2008-01-06 09:40 tutorial daniel at fbd-desktop:~/code/m3-devel$ This is helpful if you want to compare them in a recursively way. Daniel Benavides Jay wrote: .hmmessage P { margin:0px; padding:0px } body.hmmessage { FONT-SIZE: 10pt; FONT-FAMILY:Tahoma } Right, thanks. Looks/sounds about right. Will try it "later". Except: http://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/cm3/src/M3BackWin32.m3.diff?r1=1.2;r2=1.3 Looks suspicious, just by visual inspection, haven't built it -- missing an import and comma vs. period. Style tangent: Have people heard the advise that boolean parameters are bad, because at the callsite esp. they don't give much meaning? What is TRUE? What is FALSE? Enums or named parameters are clearer. Furthermore, heck, the switch on small integers 0,1,2,3... (Not that my switching on targetname was good either.) And, more importantly, given a commit, how do I view it? Easily? Currently I hunt around to each file and view it, but I have to manually navigate to each file in cvs web. I want all the diffs associated with one checkin to be viewable together, no matter which all files were checked at the same time. - Jay --------------------------------- > CC: m3devel at elegosoft.com; m3commit at elegosoft.com > From: hosking at cs.purdue.edu > Subject: Re: [M3commit] CVS Update: cm3 > Date: Mon, 7 Jan 2008 17:29:04 -0500 > To: jayk123 at hotmail.com > > > On Jan 7, 2008, at 4:10 PM, Jay wrote: > > > > > > >> Thus, controlling the backend is a simple matter of changing the > >> cm3.cfg > > > > > > > > Exactly. > > > > > > What I have right now is I build an NT386/Win32 cm3, and then I > > change the config file, and that one cm3 switches between gcc or not. > > It is a hybrid. > > The hybrid behavior can be controlled from cm3.cfg instead. See my > latest checkin. > > > I can already compile all of m3core with this cm3/m3cg, except for > > threading. > > I also copy the NT386 directories in pkg to NT386GNU, and possibly > > foo.lib to libfoo.a -- I have to try again to see if that was the > > key or not. > > This gives me an easier sort of "cross", on one machine/OS. > > > > I actually swap out the entire cm3.cfg, cm3/m3-sys/cminstall/config/ > > NT386 vs. cm3/m3-sys/cminstall/config/NT386GNU, not just one line. > > > > I'll try the "mode" and look at pm3. Thanks. > > > > > >> threading > > > > Yeah I thought Win32 would work. I'll try/look again. Later. > > I think it was set for Posix/setjmp/longjmp and I think I tried > > pthreads, might not have tried Win32. > > > > - Jay > > > >> From: hosking at cs.purdue.edu > >> Date: Mon, 7 Jan 2008 15:27:30 -0500 > >> To: hosking at cs.purdue.edu > >> CC: m3devel at elegosoft.com; m3commit at elegosoft.com > >> Subject: Re: [M3commit] CVS Update: cm3 > >> > >> Also, following up on your changes for the backend. I suggest you > >> take a look at the way things are handled in the M3BackLinux.m3 code > >> for PM3. You should be able to switch between the integrated backend > >> and the gcc-based backend similarly, based on the value of the > >> M3_BACKEND_MODE flag. Thus, controlling the backend is a simple > >> matter of changing the cm3.cfg. > >> > >> > >> > >> On Jan 7, 2008, at 3:16 PM, Tony Hosking wrote: > >> > >>> Jay, I am very nervous about the pervasive nature of some of your > >>> recent commits. NT386GNU is usually configured with > >>> OS_TYPE="POSIX". Thus, the m3makefile for cm3, which contains the > >>> following: > >>> > >>> if equal (OS_TYPE, "POSIX") > >>> interface ("M3Backend") > >>> implementation ("M3BackPosix") > >>> implementation ("UtilsPosix") > >>> else > >>> import ("m3objfile") > >>> import ("m3back") > >>> interface ("M3Backend") > >>> implementation ("M3BackWin32") > >>> implementation ("UtilsWin32") > >>> end > >>> > >>> will build a POSIX backend for you on NT386GNU which should do the > >>> right thing in invoking the gcc-based backend. Your changes, which > >>> hardwire things in cm3 for NT386GNU are thus unnecessary. I > >>> suggest you back these changes out and reconsider things. > >>> Certainly, NT386GNU should be considered as an independent POSIX > >>> target from the NT386 WIN32 target. Thus, one need not make > >>> changes to M3BackWin32 for NT386GNU, since it is treated as a POSIX > >>> target. > >>> > >>> As far as threading goes, if user-level threading for NT386 does > >>> not work then I can imagine it would be OK to use native WIN32 > >>> threads. The switch for that is in m3core/src/thread/m3makefile, > >>> which would check for TARGET="NT386GNU" and choose sibdirectory > >>> WIN32 instead of using OS_TYPE to pick subdirectory POSIX. > >>> > >>> On Jan 7, 2008, at 8:38 AM, Jay Krell wrote: > >>> > >>>> CVSROOT: /usr/cvs > >>>> Changes by: jkrell at birch. 08/01/07 08:38:15 > >>>> > >>>> Modified files: > >>>> cm3/m3-libs/m3core/src/unix/cygwin/: Umman.i3 Uresource.i3 > >>>> Utypes.m3 > >>>> cm3/m3-sys/cm3/src/: Builder.i3 Builder.m3 M3BackPosix.m3 > >>>> M3BackWin32.m3 M3Backend.i3 > >>>> cm3/m3-sys/cminstall/src/config/: NT386GNU > >>>> cm3/m3-sys/m3front/src/misc/: M3Front.m3 > >>>> > >>>> Log message: > >>>> some fixes for NT386GNU (cygwin) > >>>> > >>>> let win32 cm3 use the gcc backend if target == NT386GNU > >>>> might need a better interface here? > >>>> switching on target name is probably the wrong thing > >>>> need something called "use gcc backend" or somesuch > >>>> > >>>> loosen the check for file name vs. module name to account for > >>>> paths with both types of slashes > >>>> might need a better interface/implementation here? > >>>> should try to get the paths to line up instead? > >>>> > >>>> remove -fPIC since it warns that it is redundant (though the > >>>> warning is probably wrong > >>>> in other details -- not all code is position independent, merely > >>>> relocatable..) > >>>> > >>>> use configured ar, /usr/bin/ar doesn't work, just plain ar does > >>>> > >>>> update Umman.i3 MAP_ANONYMOUS to new shorter name MAP_ANON > >>>> > >>>> update Uresource.i3 from struct_rusage_start to VAR struct_rusage > >>>> > >>>> fix warning about unused import long in Utypes.m3 > >>>> > >>>> change SYSTEM_CC from cc to gcc because cc is something on my > >>>> system, > >>>> that I have not investigated, and doesn't work; gcc is perfectly > >>>> ok here, though > >>>> cc lines up nicely with the other two character names -- ar and as > >>>> > >>>> now need to deal with threads to get m3core to build > >>> > >> > > > > _________________________________________________________________ > > Watch ?Cause Effect,? a show about real people making a real > > difference > --------------------------------- Share life as it happens with the new Windows Live. Start sharing! --------------------------------- Web Revelaci?n Yahoo! 2007: Premio Favorita del P?blico - ?Vota tu preferida! -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Wed Jan 9 11:29:48 2008 From: jayk123 at hotmail.com (Jay) Date: Wed, 9 Jan 2008 10:29:48 +0000 Subject: [M3devel] bunch of win32 archives available Message-ID: I can now readily create these, just via scripts\python\make-dist.Interesting? Note that that they are all now "rooted" in a directory correspondingto their "basename" (cm3-min-WIN32-NT386-d5.5.1, not just cm3, not one level below that)I'm still undecided on this. Rooting them at just "cm3" is much more convenient.Even if I setup a link/junction, cm3 to ...d.5.5.1, annoying then to upgradeit in place to 5.5.2 and still have the old directory name. Also note that "core" and "base" sound the same, and are almost the same. C:\DOCUME~1\Jay\LOCALS~1\Temp\cm3\make-dist\tmp4zutb8>dir /a-d Directory of C:\DOCUME~1\Jay\LOCALS~1\Temp\cm3\make-dist\tmp4zutb8 01/09/2008 12:08 AM 1,666,826 cm3-base-WIN32-NT386-d5.5.1-symbols.tar.bz201/09/2008 12:07 AM 1,939,273 cm3-base-WIN32-NT386-d5.5.1-symbols.zip01/09/2008 12:08 AM 7,388,174 cm3-base-WIN32-NT386-d5.5.1.exe01/09/2008 12:08 AM 5,941,364 cm3-base-WIN32-NT386-d5.5.1.tar.bz201/09/2008 12:08 AM 7,209,998 cm3-base-WIN32-NT386-d5.5.1.zip01/09/2008 12:07 AM 1,590,776 cm3-core-WIN32-NT386-d5.5.1-symbols.tar.bz201/09/2008 12:06 AM 1,943,429 cm3-core-WIN32-NT386-d5.5.1-symbols.zip01/09/2008 12:07 AM 7,388,037 cm3-core-WIN32-NT386-d5.5.1.exe01/09/2008 12:07 AM 5,942,837 cm3-core-WIN32-NT386-d5.5.1.tar.bz201/09/2008 12:07 AM 7,209,861 cm3-core-WIN32-NT386-d5.5.1.zip01/09/2008 12:02 AM 734,369 cm3-min-WIN32-NT386-d5.5.1-symbols.tar.bz201/09/2008 12:02 AM 891,409 cm3-min-WIN32-NT386-d5.5.1-symbols.zip01/09/2008 12:02 AM 3,346,742 cm3-min-WIN32-NT386-d5.5.1.exe01/09/2008 12:02 AM 2,642,419 cm3-min-WIN32-NT386-d5.5.1.tar.bz201/09/2008 12:02 AM 3,168,566 cm3-min-WIN32-NT386-d5.5.1.zip01/09/2008 12:04 AM 5,493,247 cm3-std-WIN32-NT386-d5.5.1-symbols.tar.bz201/09/2008 12:03 AM 6,617,011 cm3-std-WIN32-NT386-d5.5.1-symbols.zip01/09/2008 12:04 AM 19,373,554 cm3-std-WIN32-NT386-d5.5.1.exe01/09/2008 12:06 AM 15,826,615 cm3-std-WIN32-NT386-d5.5.1.tar.bz201/09/2008 12:04 AM 19,195,378 cm3-std-WIN32-NT386-d5.5.1.zip I guess just stick with .zip. Arguably symbols are for "power users/developers" that will have tar/bzip2, arguably not. - Jay _________________________________________________________________ Get the power of Windows + Web with the new Windows Live. http://www.windowslive.com?ocid=TXT_TAGHM_Wave2_powerofwindows_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Wed Jan 9 17:05:57 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 9 Jan 2008 11:05:57 -0500 Subject: [M3devel] Didn't happen for long time now... pthread related error while ./scripts/do-cm3-std.sh In-Reply-To: References: <1199780002.11961.28.camel@faramir.m3w.org> Message-ID: On Jan 8, 2008, at 8:24 AM, Jay wrote: > Not my area of expertise, but, try this: > > > "LIBC" : [ "-lm", "-L/usr/lib", "-lpthread" ], > > "PTHREAD" : [ ], PTHREAD is no longer used, so can safely be discarded. LIBC should indeed contain "-lpthread" where pthreads are not part of libc. > > > and look here: > > http://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/cminstall/ > src/config/LINUXLIBC6?rev=1.20;content-type=text%2Fplain > > or here: > > http://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/cminstall/ > src/config-no-install/LINUXLIBC6?rev=1.10;content-type=text%2Fplain > > ..ok, which suggests really, try this: > > "LIBC" : [ "-Xlinker", "-Bdynamic", "-L/usr/lib", "-lm", "- > L/usr/lib", "-lpthread" ], > > and remove the PTHREAD line. (My suggest was from memory of - > lpthread being on the LIBC line.) > > - Jay > > > > > From: dragisha at m3w.org > > To: m3devel at elegosoft.com > > Date: Tue, 8 Jan 2008 09:13:22 +0100 > > Subject: [M3devel] Didn't happen for long time now... pthread > related error while ./scripts/do-cm3-std.sh build > > > > I have Fedora6 on this box, and I've building cm3 for long time > on it. > > Last night ago I've updated my local repo to CVS head, and tried > this > > script.. It breaks on every package linking pthread, looks like. > Then I > > cd to package folder, type "cm3", and it links ok. Example is at > end of > > message. > > > > cm3.cfg changes? Here is what I think is relevant in my current. > > > > > > % grep -i pthread /usr/local/cm3/bin/cm3.cfg -A1 -B1 > > "LIBC" : [ "-lm" ], > > "PTHREAD" : ["-L/usr/lib", "-lpthread"], > > %-- not on most Linux platforms > > -- > > SYSTEM_LIBORDER = [ "OPENGL", "DECPEX", "MOTIF", "X11", "TCP", > "ODBC", > > "POSTGRES95", "FLEX-BISON", "LEX-YACC", "LI! BC", > > "PTHREAD" ] > > > > TIA, > > dd > > > > > > > === package m3-tools/m3totex === > > > +++ cm3 -DPTHREAD -build -override -DROOT='/home/dragisha/src/ > cm3-cvshead-0629/cm3' -DCM3_VERSION_TEXT='d5.5.1' - > DCM3_VERSION_NUMBER='050501' -DCM3_LAST_CHANGED='2007-12-30' +++ > > > --- building in LINUXLIBC6 --- > > > > > > /home/dragisha/src/cm3-cvshead-0629/cm3/m3-tools/m3bundle/ > LINUXLIBC6/m3bundle -name B -F/var/tmp/qk > > > new source -> compiling B.i3 > > > new source -> compiling B.m3 > > > new source -> compiling m3totex.m3 > > > -> linking m3totex > > > /home/dragisha/src/cm3-cvshead-0629/cm3/m3-libs/m3core/ > LINUXLIBC6/libm3core.so: undefined reference to `sem_init' > > > /home/dragisha/src/cm3-cvshead-0629/cm3/m3-libs/m3core/ > LINUXLIBC6/libm3core.so: undefined reference to `pthread_key_create' > > > /home/dragisha/src/cm3-cvshead-0629/cm3/m3-libs/m3c! ore/ > LINUXLIBC6/libm3core.so: undefined reference to `pthread_attr_sets > tacksize' > > > /home/dragisha/src/cm3-cvshead-0629/cm3/m3-libs/m3core/ > LINUXLIBC6/libm3core.so: undefined reference to `pthread_kill' > > > /home/dragisha/src/cm3-cvshead-0629/cm3/m3-libs/m3core/ > LINUXLIBC6/libm3core.so: undefined reference to `pthread_getspecific' > > > /home/dragisha/src/cm3-cvshead-0629/cm3/m3-libs/m3core/ > LINUXLIBC6/libm3core.so: undefined reference to `pthread_create' > > > /home/dragisha/src/cm3-cvshead-0629/cm3/m3-libs/m3core/ > LINUXLIBC6/libm3core.so: undefined reference to > `pthread_attr_getstacksize' > > > /home/dragisha/src/cm3-cvshead-0629/cm3/m3-libs/m3core/ > LINUXLIBC6/libm3core.so: undefined reference to `sem_post' > > > /home/dragisha/src/cm3-cvshead-0629/cm3/m3-libs/m3core/ > LINUXLIBC6/libm3core.so: undefined reference to `pthread_detach' > > > /home/dragisha/src/cm3-cvshead-0629/cm3/m3-libs/m3core/ > LINUXLIBC6/libm3core.so: undefined reference to `sem_getvalue' > > > /home/dragisha/src/cm3-cvshea! d-0629/cm3/m3-libs/m3core/ > LINUXLIBC6/libm3core.so: undefined reference to `pthread_setspecific' > > > /home/dragisha/src/cm3-cvshead-0629/cm3/m3-libs/m3core/ > LINUXLIBC6/libm3core.so: undefined reference to `sem_wait' > > > collect2: ld returned 1 exit status > > > Fatal Error: package build failed > > > *** execution of failed *** > > > faramir:dragisha/pts/7: src/cm3-cvshead-0629/cm3% cd m3-tools/ > m3totex > > > faramir:dragisha/pts/7: cm3/m3-tools/m3totex% cm3 > > > --- building in LINUXLIBC6 --- > > > > > > ignoring ../src/m3overrides > > > > > > -> linking m3totex > > > faramir:dragisha/pts/7: cm3/m3-tools/m3totex% which cm3 > > > /usr/local/cm3/bin/cm3 > > > faramir:dragisha/pts/7: cm3/m3-tools/m3totex% echo $CM3 > > > cm3 -DPTHREAD > > > > > -- > > Dragi?a Duri? > > > > > Watch "Cause Effect," a show abo! ut real people making a real > difference. Learn more From hosking at cs.purdue.edu Wed Jan 9 18:03:47 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 9 Jan 2008 12:03:47 -0500 Subject: [M3devel] pthread errors on FreeBSD In-Reply-To: <20080108235730.kkfq44pjkc8s0s0o@mail.elegosoft.com> References: <20080105195158.l0sirwku74k84o0s@mail.elegosoft.com> <20080108235730.kkfq44pjkc8s0s0o@mail.elegosoft.com> Message-ID: <0EF146EC-FC60-4467-BEA0-D2B18C608E3C@cs.purdue.edu> On Jan 8, 2008, at 5:57 PM, Olaf Wagner wrote: > Quoting Tony Hosking : >> On Jan 5, 2008, at 1:51 PM, Olaf Wagner wrote: >> >>> >>> The second failure shows up in p007, where `a whole bunch of >>> threads' >>> is started: >>> +++ ../src/p0/p007/stderr.pgm 2003-03-08 11:14:01.000000000 +0100 >>> @@ -218,11 +218,1798 @@ >>> 218: 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 >>> 219: 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 >>> 220: 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 >>> - 221: >>> - >>> -*** >>> -*** runtime error: >>> -*** Thread client error: Release failed with error: 1 >>> -*** file "ThreadPThread.m3", line 174 >>> -*** >>> - >>> + 221: 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 >>> + 222: 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 >>> + 223: 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 >>> + 224: 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 >>> + 225: 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 >>> + 226: 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 >>> + 227: 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 >>> + 228: 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 >>> + 229: 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 >>> + 230: 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 >>> + 231: 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 >>> + 232: 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 >>> + 233: 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 >>> + 234: 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 >>> + 235: 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 >>> + 236: 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 >>> >>> Here a thread crashes when trying to unlock a mutex with EPERM, >>> which I do not really understand. man errno says: >> >> I am unable to reproduce this on my I386_DARWIN machine. EPERM is >> the >> error given if the thread trying to release the mutex does not >> actually >> hold it. However, the ThreadPThread is already checking to make sure >> the lock is held by the releasing thread, in this case claiming that >> the thread *does* hold the lock. So, I suspect the EPERM error is a >> result of some other problem, though I don't know what based on the >> output you are showing. I wonder if you have encountered some system >> limit. > > This seems to be caused by using the ThreadF interface to suspend > other threads. If a mutex is used, the test passes: > > PROCEDURE Txt (t: TEXT) = > BEGIN > (* ThreadF.SuspendOthers (); *) > LOCK iolock DO > RTIO.PutText (t); > END; > (* ThreadF.ResumeOthers (); *) > END Txt; > > Apart from the fact that a mutex is the correct thing to use, > have you any idea why ThreadF procedures fail? It makes me a bit > nervous, as they are used by the garbage collector, aren't they? ThreadF.SuspendOthers/ResumeOthers are particularly dangerous operations that should not be used generally by user-level code, especially where multiple threads may simultaneously invoke SuspendOthers/ResumeOthers, as in this example. I suspect also that any call to SuspendOthers should only be made when RTOS.LockHeap has been called, based on the dependency between LockHeap and SuspendOthers in the ThreadPThread implementation. I could fix this by adding the necessary calls to SuspendOthers (since LockHeap is re- entrant), but would like you to confirm that the following change "works" (even though a lock really is the correct way to go): PROCEDURE Txt (t: TEXT) = BEGIN RTOS.LockHeap(); ThreadF.SuspendOthers (); RTIO.PutText (t); ThreadF.ResumeOthers (); RTOS.UnlockHeap(); END Txt; > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, > Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Jan 10 00:08:57 2008 From: jayk123 at hotmail.com (Jay) Date: Wed, 9 Jan 2008 23:08:57 +0000 Subject: [M3devel] nt386gnu is posix or win32? In-Reply-To: References: <20080107073815.DBCDD10D45C8@birch.elegosoft.com> <4F88D761-5F3F-4891-B3BD-7490FC7E7A2A@cs.purdue.edu> Message-ID: I'm going to be rude and just throw this out there at a time when I probably can't discuss it or yet have enough data/diffs to matter. However, in building NT386GNU -- I can build libm3 and m3core -- the question arises as to if this target is "win32" or "posix'. Currently in the tree it is setup to be "posix", with a fair amount of work already done in that direction -- in particular, the Unix interfaces. However, I think this target is potentially an odd beast. Potentially it is two targets. I guess this mimics cygwin vs. mingwin. Exactly. The "host" is gcc. In order to build this system, one needs "gmake", sh, gcc probably (I'm assuming Visual C++'s compiler/linker cannot build m3cg, but very maybe..). In order to build anything with this system, one needs "as", and most likely ld. (I quote "as" because it is an English word and confusing to read otherwise.) Changing it to output assembly for masm or even Visual C++'s inline __asm is probably actually viable, but not a tiny short term task. (Or maybe writing an as clone that outputs .objs? Maybe using nasm/yasm??? Not sure the point, maybe "as" is perfectly ok.) And then the question arises as to what it takes to run the output. As I've said in other topics, the C runtime dependency of Modula-3 is light -- startup code mainly, but, yeah, also important setjmp/longjmp, and multiplication/division helpers sometimes. This could perhaps all be statically linked. Certainly for Visual C++ it can be. (NOTE: The Cygwin jmp_buf is much larger than Visual C++'s. A THOUGHT is to grow them to the same, for object code compatibility, but probably not useful, and very wasteful, Cygwin's is much larger, the data in the existing code I verified is correct, like 0x40 vs. 0xD0 I think it was, I just did printf("%x", sizeof(jmp_buf)).) To get m3core to build, I switched NT386GNU to use Win32 threads. For THAT to build, I switched OSTYPE to Win32. Overkill perhaps, in order to get the Win32 *.i3 files. Overkill perhaps, but it does build. I fully suspect that old style Posix threads can work easily, and that pthreads can work easily, increasing the dependency on cygwin1.dll. While this is the "other" direction, given the dependency on as, and gcc to build m3cg, probably the horse is out of the barn. This is arguably a simpler answer, less hybrid. I think the analogy to cygwin/mingwin holds, possibly perfectly. Maybe this is two targets. NT386CYGWIN ? NT386MINGWIN ? (Which begs the point -- target naming.... NT386 vs. PPC_LINUX...OS+ARCH vs. ARCH + _ + OS, etc... but ARCH and OS aren't it, there is toolchain and C runtime in the mix..) Obviously SOMETHING is better than NOTHING and I have no useful binary distribution yet to show, so these questions are all very premature. I'm also unsure as to the "seriousness" of using the GNU tools. a) There don't seem to be many users of Modula-3 on Win32. b) Will such users accept/trust a non Microsoft toolchain? (Just what to do folks do with cygwin/mingwin? Build/ship real software?) >From my point of view, the attractive thing about m3cg is I get the int64 stuff arguably out of the way easier. :) Licensing wise..probably a dependency on cygwin1.dll is not desirable. When I'm further along, er, actually, with my existing libm3.dll/m3core.dll, I can see what the dependencies are. If it's just setjmp/lonjmp/memset, maybe try static linking (what is the licensing of that?) or link to msvcr*.dll. Maybe see if I can configure to use mingwin to compile/link except for m3cc. That sounds excellent. You would configure a CYGWIN_ROOT (gcc, ld, make, sh, libs) and a MINGWIN_ROOT (gcc, ld, libs). CYGWIN_ROOT would be required for building m3cc, and either could be used for building anything else. ?? That seems good, though I just thought of it, need more time to think and investigate. Later.. - Jay _________________________________________________________________ Share life as it happens with the new Windows Live. http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Thu Jan 10 01:16:03 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 10 Jan 2008 01:16:03 +0100 Subject: [M3devel] pthread errors on FreeBSD In-Reply-To: <0EF146EC-FC60-4467-BEA0-D2B18C608E3C@cs.purdue.edu> References: <20080105195158.l0sirwku74k84o0s@mail.elegosoft.com> <20080108235730.kkfq44pjkc8s0s0o@mail.elegosoft.com> <0EF146EC-FC60-4467-BEA0-D2B18C608E3C@cs.purdue.edu> Message-ID: <20080110011603.zwkknbh9z44gk40k@mail.elegosoft.com> Quoting Tony Hosking : > On Jan 8, 2008, at 5:57 PM, Olaf Wagner wrote: >> This seems to be caused by using the ThreadF interface to suspend >> other threads. If a mutex is used, the test passes: >> >> PROCEDURE Txt (t: TEXT) = >> BEGIN >> (* ThreadF.SuspendOthers (); *) >> LOCK iolock DO >> RTIO.PutText (t); >> END; >> (* ThreadF.ResumeOthers (); *) >> END Txt; >> >> Apart from the fact that a mutex is the correct thing to use, >> have you any idea why ThreadF procedures fail? It makes me a bit >> nervous, as they are used by the garbage collector, aren't they? > > ThreadF.SuspendOthers/ResumeOthers are particularly dangerous > operations that should not be used generally by user-level code, > especially where multiple threads may simultaneously invoke > SuspendOthers/ResumeOthers, as in this example. I suspect also that > any call to SuspendOthers should only be made when RTOS.LockHeap has > been called, based on the dependency between LockHeap and SuspendOthers > in the ThreadPThread implementation. I could fix this by adding the > necessary calls to SuspendOthers (since LockHeap is re-entrant), but > would like you to confirm that the following change "works" (even > though a lock really is the correct way to go): > > PROCEDURE Txt (t: TEXT) = > BEGIN > RTOS.LockHeap(); > ThreadF.SuspendOthers (); > RTIO.PutText (t); > ThreadF.ResumeOthers (); > RTOS.UnlockHeap(); > END Txt; Though it sounds very convincing, it cannot be completely right: I've run the test three times with mutual exclusion as suggested, and it crashed at three different counts, but never completed :-/ Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Jan 10 02:02:38 2008 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Wed, 9 Jan 2008 20:02:38 -0500 Subject: [M3devel] nt386gnu is posix or win32? In-Reply-To: References: <20080107073815.DBCDD10D45C8@birch.elegosoft.com> <4F88D761-5F3F-4891-B3BD-7490FC7E7A2A@cs.purdue.edu> Message-ID: <20080110010238.GA3891@topoi.pooq.com> On Wed, Jan 09, 2008 at 11:08:57PM +0000, Jay wrote: > I'm going to be rude and just throw this out there at a time when I probably can't discuss it or yet have enough data/diffs to matter. > > However, in building NT386GNU -- I can build libm3 and m3core -- the question arises as to if this target is "win32" or "posix'. > Currently in the tree it is setup to be "posix", with a fair amount of work already done in that direction -- in particular, the Unix interfaces. > > However, I think this target is potentially an odd beast. Potentially it is two targets. > I guess this mimics cygwin vs. mingwin. Exactly. > > The "host" is gcc. In order to build this system, one needs "gmake", sh, gcc probably (I'm assuming Visual C++'s compiler/linker cannot build m3cg, but very maybe..). > > In order to build anything with this system, one needs "as", and most likely ld. > (I quote "as" because it is an English word and confusing to read otherwise.) > Changing it to output assembly for masm or even Visual C++'s inline __asm is probably actually viable, but not a tiny short term task. > (Or maybe writing an as clone that outputs .objs? Maybe using nasm/yasm??? Not sure the point, maybe "as" is perfectly ok.) > > And then the question arises as to what it takes to run the output. > As I've said in other topics, the C runtime dependency of Modula-3 is light -- startup code mainly, but, yeah, also important setjmp/longjmp, and multiplication/division helpers sometimes. This could perhaps all be statically linked. Certainly for Visual C++ it can be. > (NOTE: The Cygwin jmp_buf is much larger than Visual C++'s. A THOUGHT is to grow them to the same, for object code compatibility, but probably not useful, and very wasteful, Cygwin's is much larger, the data in the existing code I verified is correct, like 0x40 vs. 0xD0 I think it was, I just did printf("%x", sizeof(jmp_buf)).) > > To get m3core to build, I switched NT386GNU to use Win32 threads. > For THAT to build, I switched OSTYPE to Win32. Overkill perhaps, in order to get the Win32 *.i3 files. > Overkill perhaps, but it does build. > > I fully suspect that old style Posix threads can work easily, and that pthreads can work easily, increasing the dependency on cygwin1.dll. > While this is the "other" direction, given the dependency on as, and gcc to build m3cg, probably the horse is out of the barn. > This is arguably a simpler answer, less hybrid. > > I think the analogy to cygwin/mingwin holds, possibly perfectly. > > Maybe this is two targets. > NT386CYGWIN ? > NT386MINGWIN ? > > (Which begs the point -- target naming.... NT386 vs. PPC_LINUX...OS+ARCH vs. ARCH + _ + OS, etc... but ARCH and OS aren't it, there is toolchain and C runtime in the mix..) > > Obviously SOMETHING is better than NOTHING and I have no useful binary distribution yet to show, so these questions are all very premature. > > I'm also unsure as to the "seriousness" of using the GNU tools. > a) There don't seem to be many users of Modula-3 on Win32. > b) Will such users accept/trust a non Microsoft toolchain? > (Just what to do folks do with cygwin/mingwin? Build/ship real software?) One of my reasons for using m3 long ago was that I could write programs that would run on both Linux and Windows *without* using the Microsoft tools, which I did not possess. -- hendrik From darko at darko.org Thu Jan 10 02:24:42 2008 From: darko at darko.org (Darko) Date: Wed, 9 Jan 2008 17:24:42 -0800 Subject: [M3devel] nt386gnu is posix or win32? In-Reply-To: References: <20080107073815.DBCDD10D45C8@birch.elegosoft.com> <4F88D761-5F3F-4891-B3BD-7490FC7E7A2A@cs.purdue.edu> Message-ID: <6B5887DD-C4CA-4A5F-9814-C59F9B5DCD87@darko.org> On 09/01/2008, at 3:08 PM, Jay wrote: > a) There don't seem to be many users of Modula-3 on Win32. > b) Will such users accept/trust a non Microsoft toolchain? I think there are as many users as any other CM3 platform. It's an important platform, so it should be supported for that reason I think. Being able to use the GCC back end is very useful. I'm not sure what your exact criteria for 'seriousness' is though. I'd like to see MinGW supported because of better performance and the permissive licence. Implementation issues aside, I don't see the point of loading up all the Cygwin junk onto Windows to make it look like Posix. Darko. From darko at darko.org Thu Jan 10 02:25:31 2008 From: darko at darko.org (Darko) Date: Wed, 9 Jan 2008 17:25:31 -0800 Subject: [M3devel] nt386gnu is posix or win32? In-Reply-To: <20080110010238.GA3891@topoi.pooq.com> References: <20080107073815.DBCDD10D45C8@birch.elegosoft.com> <4F88D761-5F3F-4891-B3BD-7490FC7E7A2A@cs.purdue.edu> <20080110010238.GA3891@topoi.pooq.com> Message-ID: On 09/01/2008, at 5:02 PM, hendrik at topoi.pooq.com wrote: > > One of my reasons for using m3 long ago was that I could write > programs > that would run on both Linux and Windows *without* using the Microsoft > tools, which I did not possess. > > -- hendrik There are free versions of the tools these days, if that makes any difference. Darko. From mika at async.caltech.edu Thu Jan 10 02:31:25 2008 From: mika at async.caltech.edu (Mika Nystrom) Date: Wed, 09 Jan 2008 17:31:25 -0800 Subject: [M3devel] nt386gnu is posix or win32? In-Reply-To: Your message of "Wed, 09 Jan 2008 17:25:31 PST." Message-ID: <200801100131.m0A1VQYS034516@camembert.async.caltech.edu> In this vein, I can tell you I am a frequent user of Modula-3 on Windows. I use PM3/Klagenfurt on a Win 2003 Server system, and occasionally on XP and Win2k. I use it this way because while I develop on Unix, I have users who insist on using Windows for their servers. What matters to me is that I can get an environment that (a) runs decently fast on Windows (b) looks as much as possible like Unix (also from the user point of view) (c) requires minimal code changes The combination of Cygwin and M3 takes care of this, more or less... It's also an easy download/install. Mika Darko writes: > >On 09/01/2008, at 5:02 PM, hendrik at topoi.pooq.com wrote: >> >> One of my reasons for using m3 long ago was that I could write >> programs >> that would run on both Linux and Windows *without* using the Microsoft >> tools, which I did not possess. >> >> -- hendrik > > >There are free versions of the tools these days, if that makes any >difference. > >Darko. From jayk123 at hotmail.com Thu Jan 10 08:11:11 2008 From: jayk123 at hotmail.com (Jay) Date: Thu, 10 Jan 2008 07:11:11 +0000 Subject: [M3devel] bad code on PPC_LINUX? Message-ID: Something is screwy I think. My gdb skills are um not good. On PPC_LINUX. /dev2/cm3/m3-sys/cm3/src/Utils.m3 PROCEDURE WriteFile (file: TEXT; proc: Emitter; append := FALSE) = VAR wr: Wr.T; BEGIN IF (append) THEN wr := AppendWriter (file, fatal := TRUE); ELSE wr := OpenWriter (file, fatal := TRUE); END; TRY (* line 78 *) TRY proc (wr); EXCEPT | Wr.Failure (ec) => Msg.FatalError (ec, "write failed on ", file); | Thread.Alerted => Msg.FatalError (NIL, "interrupted while writing ", file); END; FINALLY CloseWriter (wr, file); END; END WriteFile; I get a SEGV on line 78. I'm willing to believe, sadly, that some of these huge offsets are the price of TRY and saving the register context on anything other than x86 (for registers that aren't even used by the function?), however it crashes just after the call and notice there the huge 32k offset. And really? A 720 byte frame for any function with a TRY on PowerPC? Really? I guess I should look at what PPC_DARWIN does. If someone can give me a quick run down on PowerPC ABI, thanks. I'll search the web. Or maybe check my Mac docs. register 0 is 0 or general purpose? Stack is register ? I know that return address is in the link register. bl is branch and link -- call -- jump and save pc in link register. The code is: (gdb) disassemble Dump of assembler code for function Utils__WriteFile: 0x10024fbc : stwu r1,-720(r1) 0x10024fc0 : mflr r0 0x10024fc4 : mfcr r12 0x10024fc8 : stfd f14,576(r1) 0x10024fcc : stfd f15,584(r1) 0x10024fd0 : stfd f16,592(r1) 0x10024fd4 : stfd f17,600(r1) 0x10024fd8 : stfd f18,608(r1) 0x10024fdc : stfd f19,616(r1) 0x10024fe0 : stfd f20,624(r1) 0x10024fe4 : stfd f21,632(r1) 0x10024fe8 : stfd f22,640(r1) 0x10024fec : stfd f23,648(r1) 0x10024ff0 : stfd f24,656(r1) 0x10024ff4 : stfd f25,664(r1) 0x10024ff8 : stfd f26,672(r1) 0x10024ffc : stfd f27,680(r1) 0x10025000 : stfd f28,688(r1) 0x10025004 : stfd f29,696(r1) 0x10025008 : stfd f30,704(r1) 0x1002500c : stfd f31,712(r1) 0x10025010 : stw r14,504(r1) 0x10025014 : stw r15,508(r1) 0x10025018 : stw r16,512(r1) 0x1002501c : stw r17,516(r1) 0x10025020 : stw r18,520(r1) 0x10025024 : stw r19,524(r1) 0x10025028 : stw r20,528(r1) 0x1002502c : stw r21,532(r1) ---Type to continue, or q to quit--- 0x10025030 : stw r22,536(r1) 0x10025034 : stw r23,540(r1) 0x10025038 : stw r24,544(r1) 0x1002503c : stw r25,548(r1) 0x10025040 : stw r26,552(r1) 0x10025044 : stw r27,556(r1) 0x10025048 : stw r28,560(r1) 0x1002504c : stw r29,564(r1) 0x10025050 : stw r30,568(r1) 0x10025054 : stw r31,572(r1) 0x10025058 : stw r0,724(r1) 0x1002505c : stw r12,500(r1) 0x10025060 : mr r31,r1 0x10025064 : bl 0x10025068 0x10025068 : mflr r30 0x1002506c : lwz r0,-176(r30) 0x10025070 : add r30,r0,r30 0x10025074 : stw r3,8(r31) 0x10025078 : stw r4,12(r31) 0x1002507c : mr r0,r5 0x10025080 : stb r0,16(r31) 0x10025084 : li r0,0 0x10025088 : stw r0,20(r31) 0x1002508c : lbz r0,16(r31) 0x10025090 : clrlwi r0,r0,24 0x10025094 : cmpwi r0,0 0x10025098 : beq- 0x100250b8 0x1002509c : lwz r3,8(r31) 0x100250a0 : li r4,1 0x100250a4 : bl 0x100248a4 ---Type to continue, or q to quit--- 0x100250a8 : stw r3,476(r31) 0x100250ac : lwz r9,476(r31) 0x100250b0 : stw r9,20(r31) 0x100250b4 : b 0x100250d0 0x100250b8 : lwz r3,8(r31) 0x100250bc : li r4,1 0x100250c0 : bl 0x10024658 0x100250c4 : stw r3,476(r31) 0x100250c8 : lwz r9,476(r31) 0x100250cc : stw r9,20(r31) ** here I believe ** 0x100250d0 : lwz r0,-32760(r30) 0x100250d4 : stw r0,32(r31) 0x100250d8 : addi r0,r31,8 0x100250dc : stw r0,36(r31) 0x100250e0 : li r0,3 0x100250e4 : stw r0,28(r31) 0x100250e8 : lwz r9,-32764(r30) 0x100250ec : lwz r0,0(r9) 0x100250f0 : stw r0,24(r31) 0x100250f4 : lwz r9,-32764(r30) 0x100250f8 : addi r0,r31,24 0x100250fc : stw r0,0(r9) 0x10025100 : lwz r9,-32768(r30) 0x10025104 : addi r0,r9,76 0x10025108 : stw r0,64(r31) 0x1002510c : li r0,0 0x10025110 : stw r0,60(r31) 0x10025114 : lwz r9,-32764(r30) 0x10025118 : lwz r0,0(r9) 0x1002511c : stw r0,56(r31) ---Type to continue, or q to quit--- 0x10025120 : lwz r9,-32764(r30) 0x10025124 : addi r0,r31,56 0x10025128 : stw r0,0(r9) 0x1002512c : addi r9,r31,56 0x10025130 : addi r0,r9,48 0x10025134 : mr r3,r0 0x10025138 : bl 0x101bbf28 0x1002513c : mr r0,r3 0x10025140 : cmpwi r0,0 0x10025144 : bne- 0x100251ac 0x10025148 : lwz r9,12(r31) 0x1002514c : stw r9,476(r31) 0x10025150 : lwz r9,476(r31) 0x10025154 : cmpwi r9,0 0x10025158 : beq- 0x10025188 0x1002515c : lwz r9,476(r31) 0x10025160 : lwz r0,0(r9) 0x10025164 : li r9,-1 0x10025168 : cmpw r0,r9 0x1002516c : bne- 0x10025188 0x10025170 : lwz r9,476(r31) 0x10025174 : lwz r9,8(r9) 0x10025178 : stw r9,480(r31) 0x1002517c : lwz r9,476(r31) 0x10025180 : lwz r9,4(r9) 0x10025184 : stw r9,476(r31) 0x10025188 : lwz r11,480(r31) 0x1002518c : lwz r3,20(r31) 0x10025190 : lwz r0,476(r31) 0x10025194 : mtlr r0 ---Type to continue, or q to quit--- 0x10025198 : blrl 0x1002519c : lwz r9,-32764(r30) 0x100251a0 : lwz r0,56(r31) 0x100251a4 : stw r0,0(r9) 0x100251a8 : b 0x10025210 0x100251ac : lwz r9,68(r31) 0x100251b0 : lwz r9,0(r9) 0x100251b4 : lis r0,-15535 0x100251b8 : ori r0,r0,42454 0x100251bc : cmpw r9,r0 0x100251c0 : bne- 0x100251f0 0x100251c4 : lwz r0,72(r31) 0x100251c8 : stw r0,472(r31) 0x100251cc : lwz r9,-32768(r30) 0x100251d0 : addi r0,r9,180 0x100251d4 : lwz r3,472(r31) 0x100251d8 : mr r4,r0 0x100251dc : lwz r5,8(r31) 0x100251e0 : li r6,0 0x100251e4 : li r7,0 0x100251e8 : bl 0x10023b4c 0x100251ec : b 0x10025210 0x100251f0 : lwz r9,-32768(r30) 0x100251f4 : addi r0,r9,212 0x100251f8 : li r3,0 0x100251fc : mr r4,r0 0x10025200 : lwz r5,8(r31) 0x10025204 : li r6,0 0x10025208 : li r7,0 0x1002520c : bl 0x10023b4c ---Type to continue, or q to quit--- 0x10025210 : lwz r9,-32764(r30) 0x10025214 : lwz r0,24(r31) 0x10025218 : stw r0,0(r9) 0x1002521c : addi r11,r31,8 0x10025220 : bl 0x10024f74 0x10025224 : lwz r11,0(r1) 0x10025228 : lwz r0,4(r11) 0x1002522c : lwz r12,-220(r11) 0x10025230 : mtlr r0 0x10025234 : lwz r14,-216(r11) 0x10025238 : lwz r15,-212(r11) 0x1002523c : lwz r16,-208(r11) 0x10025240 : lwz r17,-204(r11) 0x10025244 : lwz r18,-200(r11) 0x10025248 : lwz r19,-196(r11) 0x1002524c : lwz r20,-192(r11) 0x10025250 : lwz r21,-188(r11) 0x10025254 : lwz r22,-184(r11) 0x10025258 : lwz r23,-180(r11) 0x1002525c : lwz r24,-176(r11) 0x10025260 : lwz r25,-172(r11) 0x10025264 : lwz r26,-168(r11) 0x10025268 : lwz r27,-164(r11) 0x1002526c : lwz r28,-160(r11) 0x10025270 : lwz r29,-156(r11) 0x10025274 : lwz r30,-152(r11) 0x10025278 : lwz r31,-148(r11) 0x1002527c : lfd f14,-144(r11) 0x10025280 : lfd f15,-136(r11) 0x10025284 : lfd f16,-128(r11) ---Type to continue, or q to quit--- 0x10025288 : lfd f17,-120(r11) 0x1002528c : lfd f18,-112(r11) 0x10025290 : lfd f19,-104(r11) 0x10025294 : lfd f20,-96(r11) 0x10025298 : lfd f21,-88(r11) 0x1002529c : lfd f22,-80(r11) 0x100252a0 : lfd f23,-72(r11) 0x100252a4 : lfd f24,-64(r11) 0x100252a8 : lfd f25,-56(r11) 0x100252ac : lfd f26,-48(r11) 0x100252b0 : lfd f27,-40(r11) 0x100252b4 : lfd f28,-32(r11) 0x100252b8 : lfd f29,-24(r11) 0x100252bc : lfd f30,-16(r11) 0x100252c0 : lfd f31,-8(r11) 0x100252c4 : mtcrf 56,r12 0x100252c8 : mr r1,r11 0x100252cc : blr 0x100252d0 : .long 0x24ebb0 End of assembler dump. (gdb) bt #0 Utils__WriteFile (M3_Bd56fi_file=0x10277ba0, M3_DmuccK_proc=0x7fb22210, M3_AicXUJ_append=0 '\0') at Utils.m3:78 #1 0x10020a10 in Makefile__Build (M3_Bd56fi_src_dir=0x102720ec) at Makefile.m3:101 #2 0x100292d4 in Main__DoIt () at Main.m3:71 #3 0x10029834 in Main_M3 (M3_AcxOUs_mode=1) at Main.m3:193 #4 0x10188f9c in RTLinker__RunMainBody (M3_DUuepq_m=0x10279b28) at RTLinker.m3:387 #5 0x101880bc in RTLinker__AddUnitI (M3_DUuepq_m=0x10279b28) at RTLinker.m3:100 #6 0x10188198 in RTLinker__AddUnit (M3_DUuepw_b=0x100297f8) at RTLinker.m3:110 #7 0x100002ec in main (argc=1, argv=0x7fb22834, envp=0x7fb2283c) at _m3main.mc:4 I haven't yet figured out how to get gdb to show me the details of the SEGV, like what address was referenced. I swear I think this was working better recently. Oh, I did change something. I will try to change it back. I added -fPIC. Dynamic linking was not working and I thought that might fix it. I'll definitely try without it now. Also, relevant aside -- what, if any, distributions/versions of Linux are people using on PowerPC? Specifically on PowerPC (to limit the religious explosion) I'm currently using Yellow Dog, I think 4.1, but only for Modula-3 purposes, not for anything else. ps: I'd like a SMALL forum of SMART programmers, to discuss GENERAL programming topics. This is it perhaps? - Jay _________________________________________________________________ Watch ?Cause Effect,? a show about real people making a real difference. http://im.live.com/Messenger/IM/MTV/?source=text_watchcause From jayk123 at hotmail.com Thu Jan 10 10:28:31 2008 From: jayk123 at hotmail.com (Jay) Date: Thu, 10 Jan 2008 09:28:31 +0000 Subject: [M3devel] FW: bad code on PPC_LINUX? Message-ID: My emails keep getting truncated for some reason.. :( > From: jayk123 at hotmail.com > To: m3devel at elegosoft.com > Subject: bad code on PPC_LINUX? > Date: Thu, 10 Jan 2008 07:11:11 +0000 > > > Something is screwy I think. > My gdb skills are um not good. > > On PPC_LINUX. > > /dev2/cm3/m3-sys/cm3/src/Utils.m3 > > PROCEDURE WriteFile (file: TEXT; proc: Emitter; append := FALSE) = > VAR wr: Wr.T; > BEGIN > IF (append) > THEN wr := AppendWriter (file, fatal := TRUE); > ELSE wr := OpenWriter (file, fatal := TRUE); > END; > TRY (* line 78 *) > TRY > proc (wr); > EXCEPT > | Wr.Failure (ec) => > Msg.FatalError (ec, "write failed on ", file); > | Thread.Alerted => > Msg.FatalError (NIL, "interrupted while writing ", file); > END; > FINALLY > CloseWriter (wr, file); > END; > END WriteFile; > > I get a SEGV on line 78. > > I'm willing to believe, sadly, that some of these huge offsets > are the price of TRY and saving the register context on anything > other than x86 (for registers that aren't even used by the function?), > however it crashes just after the call and notice there the huge 32k offset. > > And really? A 720 byte frame for any function with a TRY on PowerPC? > Really? > I guess I should look at what PPC_DARWIN does. > > If someone can give me a quick run down on PowerPC ABI, thanks. > I'll search the web. Or maybe check my Mac docs. > register 0 is 0 or general purpose? > Stack is register ? > I know that return address is in the link register. > bl is branch and link -- call -- jump and save pc in link register. > > The code is: > (gdb) disassemble > Dump of assembler code for function Utils__WriteFile: > 0x10024fbc : stwu r1,-720(r1) > 0x10024fc0 : mflr r0 > 0x10024fc4 : mfcr r12 > 0x10024fc8 : stfd f14,576(r1) > 0x10024fcc : stfd f15,584(r1) > 0x10024fd0 : stfd f16,592(r1) > 0x10024fd4 : stfd f17,600(r1) > 0x10024fd8 : stfd f18,608(r1) > 0x10024fdc : stfd f19,616(r1) > 0x10024fe0 : stfd f20,624(r1) > 0x10024fe4 : stfd f21,632(r1) > 0x10024fe8 : stfd f22,640(r1) > 0x10024fec : stfd f23,648(r1) > 0x10024ff0 : stfd f24,656(r1) > 0x10024ff4 : stfd f25,664(r1) > 0x10024ff8 : stfd f26,672(r1) > 0x10024ffc : stfd f27,680(r1) > 0x10025000 : stfd f28,688(r1) > 0x10025004 : stfd f29,696(r1) > 0x10025008 : stfd f30,704(r1) > 0x1002500c : stfd f31,712(r1) > 0x10025010 : stw r14,504(r1) > 0x10025014 : stw r15,508(r1) > 0x10025018 : stw r16,512(r1) > 0x1002501c : stw r17,516(r1) > 0x10025020 : stw r18,520(r1) > 0x10025024 : stw r19,524(r1) > 0x10025028 : stw r20,528(r1) > 0x1002502c : stw r21,532(r1) > ---Type to continue, or q to quit--- > 0x10025030 : stw r22,536(r1) > 0x10025034 : stw r23,540(r1) > 0x10025038 : stw r24,544(r1) > 0x1002503c : stw r25,548(r1) > 0x10025040 : stw r26,552(r1) > 0x10025044 : stw r27,556(r1) > 0x10025048 : stw r28,560(r1) > 0x1002504c : stw r29,564(r1) > 0x10025050 : stw r30,568(r1) > 0x10025054 : stw r31,572(r1) > 0x10025058 : stw r0,724(r1) > 0x1002505c : stw r12,500(r1) > 0x10025060 : mr r31,r1 > 0x10025064 : bl 0x10025068 > 0x10025068 : mflr r30 > 0x1002506c : lwz r0,-176(r30) > 0x10025070 : add r30,r0,r30 > 0x10025074 : stw r3,8(r31) > 0x10025078 : stw r4,12(r31) > 0x1002507c : mr r0,r5 > 0x10025080 : stb r0,16(r31) > 0x10025084 : li r0,0 > 0x10025088 : stw r0,20(r31) > 0x1002508c : lbz r0,16(r31) > 0x10025090 : clrlwi r0,r0,24 > 0x10025094 : cmpwi r0,0 > 0x10025098 : beq- 0x100250b8 > 0x1002509c : lwz r3,8(r31) > 0x100250a0 : li r4,1 > 0x100250a4 : bl 0x100248a4 > ---Type to continue, or q to quit--- > 0x100250a8 : stw r3,476(r31) > 0x100250ac : lwz r9,476(r31) > 0x100250b0 : stw r9,20(r31) > 0x100250b4 : b 0x100250d0 > 0x100250b8 : lwz r3,8(r31) > 0x100250bc : li r4,1 > 0x100250c0 : bl 0x10024658 > 0x100250c4 : stw r3,476(r31) > 0x100250c8 : lwz r9,476(r31) > 0x100250cc : stw r9,20(r31) > > ** here I believe ** > > 0x100250d0 : lwz r0,-32760(r30) > 0x100250d4 : stw r0,32(r31) > 0x100250d8 : addi r0,r31,8 > 0x100250dc : stw r0,36(r31) > 0x100250e0 : li r0,3 > 0x100250e4 : stw r0,28(r31) > 0x100250e8 : lwz r9,-32764(r30) > 0x100250ec : lwz r0,0(r9) > 0x100250f0 : stw r0,24(r31) > 0x100250f4 : lwz r9,-32764(r30) > 0x100250f8 : addi r0,r31,24 > 0x100250fc : stw r0,0(r9) > 0x10025100 : lwz r9,-32768(r30) > 0x10025104 : addi r0,r9,76 > 0x10025108 : stw r0,64(r31) > 0x1002510c : li r0,0 > 0x10025110 : stw r0,60(r31) > 0x10025114 : lwz r9,-32764(r30) > 0x10025118 : lwz r0,0(r9) > 0x1002511c : stw r0,56(r31) > ---Type to continue, or q to quit--- > 0x10025120 : lwz r9,-32764(r30) > 0x10025124 : addi r0,r31,56 > 0x10025128 : stw r0,0(r9) > 0x1002512c : addi r9,r31,56 > 0x10025130 : addi r0,r9,48 > 0x10025134 : mr r3,r0 > 0x10025138 : bl 0x101bbf28 > 0x1002513c : mr r0,r3 > 0x10025140 : cmpwi r0,0 > 0x10025144 : bne- 0x100251ac > 0x10025148 : lwz r9,12(r31) > 0x1002514c : stw r9,476(r31) > 0x10025150 : lwz r9,476(r31) > 0x10025154 : cmpwi r9,0 > 0x10025158 : beq- 0x10025188 > 0x1002515c : lwz r9,476(r31) > 0x10025160 : lwz r0,0(r9) > 0x10025164 : li r9,-1 > 0x10025168 : cmpw r0,r9 > 0x1002516c : bne- 0x10025188 > 0x10025170 : lwz r9,476(r31) > 0x10025174 : lwz r9,8(r9) > 0x10025178 : stw r9,480(r31) > 0x1002517c : lwz r9,476(r31) > 0x10025180 : lwz r9,4(r9) > 0x10025184 : stw r9,476(r31) > 0x10025188 : lwz r11,480(r31) > 0x1002518c : lwz r3,20(r31) > 0x10025190 : lwz r0,476(r31) > 0x10025194 : mtlr r0 > ---Type to continue, or q to quit--- > 0x10025198 : blrl > 0x1002519c : lwz r9,-32764(r30) > 0x100251a0 : lwz r0,56(r31) > 0x100251a4 : stw r0,0(r9) > 0x100251a8 : b 0x10025210 > 0x100251ac : lwz r9,68(r31) > 0x100251b0 : lwz r9,0(r9) > 0x100251b4 : lis r0,-15535 > 0x100251b8 : ori r0,r0,42454 > 0x100251bc : cmpw r9,r0 > 0x100251c0 : bne- 0x100251f0 > 0x100251c4 : lwz r0,72(r31) > 0x100251c8 : stw r0,472(r31) > 0x100251cc : lwz r9,-32768(r30) > 0x100251d0 : addi r0,r9,180 > 0x100251d4 : lwz r3,472(r31) > 0x100251d8 : mr r4,r0 > 0x100251dc : lwz r5,8(r31) > 0x100251e0 : li r6,0 > 0x100251e4 : li r7,0 > 0x100251e8 : bl 0x10023b4c > 0x100251ec : b 0x10025210 > 0x100251f0 : lwz r9,-32768(r30) > 0x100251f4 : addi r0,r9,212 > 0x100251f8 : li r3,0 > 0x100251fc : mr r4,r0 > 0x10025200 : lwz r5,8(r31) > 0x10025204 : li r6,0 > 0x10025208 : li r7,0 > 0x1002520c : bl 0x10023b4c > ---Type to continue, or q to quit--- > 0x10025210 : lwz r9,-32764(r30) > 0x10025214 : lwz r0,24(r31) > 0x10025218 : stw r0,0(r9) > 0x1002521c : addi r11,r31,8 > 0x10025220 : bl 0x10024f74 > 0x10025224 : lwz r11,0(r1) > 0x10025228 : lwz r0,4(r11) > 0x1002522c : lwz r12,-220(r11) > 0x10025230 : mtlr r0 > 0x10025234 : lwz r14,-216(r11) > 0x10025238 : lwz r15,-212(r11) > 0x1002523c : lwz r16,-208(r11) > 0x10025240 : lwz r17,-204(r11) > 0x10025244 : lwz r18,-200(r11) > 0x10025248 : lwz r19,-196(r11) > 0x1002524c : lwz r20,-192(r11) > 0x10025250 : lwz r21,-188(r11) > 0x10025254 : lwz r22,-184(r11) > 0x10025258 : lwz r23,-180(r11) > 0x1002525c : lwz r24,-176(r11) > 0x10025260 : lwz r25,-172(r11) > 0x10025264 : lwz r26,-168(r11) > 0x10025268 : lwz r27,-164(r11) > 0x1002526c : lwz r28,-160(r11) > 0x10025270 : lwz r29,-156(r11) > 0x10025274 : lwz r30,-152(r11) > 0x10025278 : lwz r31,-148(r11) > 0x1002527c : lfd f14,-144(r11) > 0x10025280 : lfd f15,-136(r11) > 0x10025284 : lfd f16,-128(r11) > ---Type to continue, or q to quit--- > 0x10025288 : lfd f17,-120(r11) > 0x1002528c : lfd f18,-112(r11) > 0x10025290 : lfd f19,-104(r11) > 0x10025294 : lfd f20,-96(r11) > 0x10025298 : lfd f21,-88(r11) > 0x1002529c : lfd f22,-80(r11) > 0x100252a0 : lfd f23,-72(r11) > 0x100252a4 : lfd f24,-64(r11) > 0x100252a8 : lfd f25,-56(r11) > 0x100252ac : lfd f26,-48(r11) > 0x100252b0 : lfd f27,-40(r11) > 0x100252b4 : lfd f28,-32(r11) > 0x100252b8 : lfd f29,-24(r11) > 0x100252bc : lfd f30,-16(r11) > 0x100252c0 : lfd f31,-8(r11) > 0x100252c4 : mtcrf 56,r12 > 0x100252c8 : mr r1,r11 > 0x100252cc : blr > 0x100252d0 : .long 0x24ebb0 > End of assembler dump. > > > (gdb) bt > #0 Utils__WriteFile (M3_Bd56fi_file=0x10277ba0, M3_DmuccK_proc=0x7fb22210, > M3_AicXUJ_append=0 '\0') at Utils.m3:78 > #1 0x10020a10 in Makefile__Build (M3_Bd56fi_src_dir=0x102720ec) > at Makefile.m3:101 > #2 0x100292d4 in Main__DoIt () at Main.m3:71 > #3 0x10029834 in Main_M3 (M3_AcxOUs_mode=1) at Main.m3:193 > #4 0x10188f9c in RTLinker__RunMainBody (M3_DUuepq_m=0x10279b28) > at RTLinker.m3:387 > #5 0x101880bc in RTLinker__AddUnitI (M3_DUuepq_m=0x10279b28) at RTLinker.m3:100 > #6 0x10188198 in RTLinker__AddUnit (M3_DUuepw_b=0x100297f8) at RTLinker.m3:110 > #7 0x100002ec in main (argc=1, argv=0x7fb22834, envp=0x7fb2283c) at _m3main.mc:4 > > I haven't yet figured out how to get gdb to show me the details of the SEGV, like what address was referenced. > > I swear I think this was working better recently. > > Oh, I did change something. I will try to change it back. > I added -fPIC. > Dynamic linking was not working and I thought that might fix it. > I'll definitely try without it now. > > Also, relevant aside -- what, if any, distributions/versions of Linux are people using on PowerPC? > Specifically on PowerPC (to limit the religious explosion) > I'm currently using Yellow Dog, I think 4.1, but only for Modula-3 purposes, not for anything else. > > ps: I'd like a SMALL forum of SMART programmers, to discuss GENERAL programming topics. > This is it perhaps? > > - Jay > _________________________________________________________________ > Watch ?Cause Effect,? a show about real people making a real difference. > http://im.live.com/Messenger/IM/MTV/?source=text_watchcause _________________________________________________________________ Make distant family not so distant with Windows Vista? + Windows Live?. http://www.microsoft.com/windows/digitallife/keepintouch.mspx?ocid=TXT_TAGLM_CPC_VideoChat_distantfamily_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Thu Jan 10 12:16:36 2008 From: jayk123 at hotmail.com (Jay) Date: Thu, 10 Jan 2008 11:16:36 +0000 Subject: [M3devel] nt386gnu is posix or win32? In-Reply-To: <200801100131.m0A1VQYS034516@camembert.async.caltech.edu> References: Your message of "Wed, 09 Jan 2008 17:25:31 PST." <200801100131.m0A1VQYS034516@camembert.async.caltech.edu> Message-ID: clarification/additional info Whatever MinGWin I have installed, is via the GPL Qt download. I did not realize MinGWin had the "MSYS" component -- sh, make, etc., enough for autoconf. Enough for gcc? http://www.mingw.org/mingwfaq.shtml#faq-usingwithmsys "How do I use MinGW with Cygwin?For those who would like to use the Cygwin environment for development, yet generatenon-Cygwin-dependant executables, a much easier option to "-mno-cygwin" does exist.Simply install Cygwin and the MinGW distribution in seperate directories (i.e. "C:\CYGWIN"and "C:\MINGW"), and make sure that the "/bin" subdirectory beneath your MinGW installationcomes before Cygwin's "/bin" subdirectory in your PATH environment variable(i.e. "PATH=%PATH%;C:\MINGW\BIN;C:\CYGWIN\BIN"). This will allow you accessto all the UNIX tools you want, while ensuring that the instance of GCC used is the MinGW version." Sounds good.So a possibly good easy answer is just one target -- "NT386GNU" configured probably always as I have it currently -- Win32 threads maybe a cm3 command line define, like -DPTHREAD to use pthreads, will require a tiny bit of work heck, maybe -DUSERTHREAD (and for other systems?) jmpbuf asis -- 0xd0 and will work linked either way. Whether or not mingw works alone, is to be determined.It probably does if not building m3cc, and it may very well even for building m3cc. Among those goals: (a) runs decently fast on Windows (b) looks as much as possible like Unix (also from the user point of view) (c) requires minimal code changes These are related and to some extent help each other, and to some extentare independent. In particular, the theory is, you get #c without requiring #b.Regarding #a, well, it's a question of one or two layers.Modula-3 already provides in many places, but certainly not all, a portability layer.And then another cygwin/posix portability layer? Maybe.These aren't necessarily thick layers and if your code is i/o bound anyway, doesn't matter. (While I'm sure it wasn't intended, "runs fast" can be interpreted as "fast to get it to run",as in ease of development/porting. :) ) Anyway, it seems like both camps (all camps?) can be satisfied. By "serious" I mean, "ship real software using it".Oh and the reference to "toolchains" was dodgy.Already Modula-3 on Windows involves an unusual codegenerator, though still a "normal" linker. - Jay..waiting for m3cc to build again as part of upgrade.sh...(my excuse for wasting time in email..) > To: darko at darko.org> Date: Wed, 9 Jan 2008 17:31:25 -0800> From: mika at async.caltech.edu> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] nt386gnu is posix or win32?> > > In this vein, I can tell you I am a frequent user of Modula-3 on Windows.> I use PM3/Klagenfurt on a Win 2003 Server system, and occasionally on XP and> Win2k.> > I use it this way because while I develop on Unix, I have users who insist on> using Windows for their servers. What matters to me is that I can get an> environment that> > (a) runs decently fast on Windows> (b) looks as much as possible like Unix (also from the user point of view)> (c) requires minimal code changes> > The combination of Cygwin and M3 takes care of this, more or less... It's> also an easy download/install.> > Mika> > > Darko writes:> >> >On 09/01/2008, at 5:02 PM, hendrik at topoi.pooq.com wrote:> >>> >> One of my reasons for using m3 long ago was that I could write > >> programs> >> that would run on both Linux and Windows *without* using the Microsoft> >> tools, which I did not possess.> >>> >> -- hendrik> >> >> >There are free versions of the tools these days, if that makes any > >difference.> >> >Darko. _________________________________________________________________ Put your friends on the big screen with Windows Vista? + Windows Live?. http://www.microsoft.com/windows/shop/specialoffers.mspx?ocid=TXT_TAGLM_CPC_MediaCtr_bigscreen_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Thu Jan 10 12:20:20 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 10 Jan 2008 12:20:20 +0100 Subject: [M3devel] (Offtopic) Some comments on SCM tools, was: Re: M3 concerns In-Reply-To: <20080105191243.GB6402@topoi.pooq.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> <20080105191243.GB6402@topoi.pooq.com> Message-ID: <20080110122020.zm4wc29e8044c0kw@mail.elegosoft.com> Quoting hendrik at topoi.pooq.com: > But if you have this experience, it would be useful to see a rundown > of the advantages and disadvantages of each. I've seen a table of > features against version control systems, but it doesn't give any feel > for what it's like to use them. > > Such an essay would be useful for those involved in other projects. It > probably won't help Modula 3 itself. That would easily become an open-ended task :-) It is not easy to compare different complex tools like SCM systems, which interact in various degrees with process control, workflow management, problem management, project management, general policies... We've tried to provide feature-oriented comparison lists some years ago, but even this needs too much efforts and is too fast out-of-date. There are some aspects that may currently be helpful as criterions though. I'd like to mention some of them o Traditionally, version control tools were centralized server systems. There is one central repository (which can in advanced setups be replicated to several sites for many systems. Replicas may even be partly writable. In case of replication there is one `logical' central repository which is physically distributed.). Systems in this group are CVS, ClearCase, PVCS, AccuRev, Perforce, Subversion, and many others. In recent years, peer-to-peer systems have become popular, because they correspond better to certain aspects of open software projects and are inherently distributed. There is no distinction between workspace and repository, and each workspace holds a partial or complete change history. Such systems are BitKeeper, git, Darcs, and others. As far as I know, these systems are not very popular in the commercial world (yet?). o An orthogonal criterion is the range of functionality that is addressed with the solution. Simple systems like CVS and Perforce do just version control and offer some hooks for further integration. On the other side are process-oriented systems like PVCS Dimensions or a complete ClearCase/ClearQuest setup for RUP. These systems are rather based on change management und workflow than on developer needs. Basic abstractions are baselines, changesets, tasks, projects, activities, functional roles. Of course, some tools are somewhere in between these extremes, like AccuRev, which supports kinds of long-running transactions for everything, called `streams'. (This one's very nice IMO.) o Then there are the costs of the use of the systems. There are always costs, even for open source solutions. You have to consider - server costs (hardware, energy, OS, database, licences, networks) - administration and maintenance (servers and user setup) - user license costs (from 0 to several thousand dollars per year) - use overhead (depending on tool usability and process) - instruction and training Again there are systems that are rather lightweight in this respect (like CVS and Perforce) and some tending to be more heavyweight (like ClearCase and PVCS). o The `end user experience' corresponds very much to the basic concepts needed in everyday use. File based ci/co is very simple, development lines are more or less a must have, change sets and baselines (like in DCVS, AccuRev or RUP) are very nice; diffs and merges seem to be too complex for many users (but are of course needed); conflict avoidance vs. conflict resolution (locking or optimistic approach) is often a religiously discussed topic. The other important issue here is the IDE integration (at least for developers). These are only some randomly picked topics that would need to be addressed in a useful tool comparison. There are very few situations in which you can evaluate and choose the best tool for your purpose; most of the time, you have to adapt and improve existing setups, as everything else would be too expensive and disrupting. Our company has supported several migration projects recently though, so it's not impossible to change ;-) As for CM3, I'm still of the opinion that there is no need to change the existing CVS infrastructure. > Or might you know of such an essay elsewhere? Well, the more interesting field studies and evaluations are not free; there are quite a lot of interesting articles though. I haven't any links here right now; CM crossroads or a Google search on `configuration management' should be a good starting point. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Jan 10 12:24:20 2008 From: jayk123 at hotmail.com (Jay) Date: Thu, 10 Jan 2008 11:24:20 +0000 Subject: [M3devel] win32 path separators -- support forward and backward in libm3? In-Reply-To: <200801100131.m0A1VQYS034516@camembert.async.caltech.edu> References: Your message of "Wed, 09 Jan 2008 17:25:31 PST." <200801100131.m0A1VQYS034516@camembert.async.caltech.edu> Message-ID: To a very large extent, Win32 accepts both / and \ equally as path delimiters. CreateFile, DeleteFile, CreateDirectory, MoveFile, CopyFile, FindFirstFile, GetFileAttributes, the C runtime wrappers fopen, unlink/remove, stat, etc., those all work either way, or with a mix. "Shell" functions like shlwapi.dll, commdlg32.dll, tend not to. In building NT386GNU, I run into places where cm3 is picking apart paths. For whatever reason, it is being given paths with a mix of forward and backward slashes. I find these paths ugly, but they work ok. I've been able to easily progress by changing m3-libs/libm3/src/os/WIN32/PathnameWin32.m3 to treat forward and backslashes the same. I have not yet rebuilt the normal NT386 target with this change. An ok change? Or go and fix NT386GNU a) to be consistent, b) use backward slashes, c) translate at some place. ? C:\dev2\cm3.2\m3-libs\libm3>cvs diffIndex: src/os/WIN32/PathnameWin32.m3===================================================================RCS file: /usr/cvs/cm3/m3-libs/libm3/src/os/WIN32/PathnameWin32.m3,vretrieving revision 1.3diff -r1.3 PathnameWin32.m313c13< DirSepChar = '\\'; DirSepText = "\\";---> DirSepText = "\\";17c17< CONST Legal = SET OF CHAR {'\001' .. '\177'} - SET OF CHAR {DirSepChar, ':'};---> CONST Legal = SET OF CHAR {'\001' .. '\177'} - SET OF CHAR {'\\', '/', ':', '?', '*'};21a22,26> PROCEDURE IsDirSepChar(ch: CHAR): BOOLEAN => BEGIN> RETURN (ch = '\\' OR ch = '/');> END IsDirSepChar;>53,54c58,59< IF Text.GetChar(t, 0) = DirSepChar AND< Text.GetChar(t, nRoot - 1) # DirSepChar THEN---> IF IsDirSepChar(Text.GetChar(t, 0)) AND> NOT IsDirSepChar(Text.GetChar(t, nRoot - 1)) THEN125c130< IF c # DirSepChar AND c # DriveSepChar THEN---> IF NOT IsDirSepChar(c) AND c # DriveSepChar THEN173,174c178,179< IF c = DirSepChar THEN< IF n = 1 OR Text.GetChar(t, 1) # DirSepChar THEN RETURN 1 END;---> IF IsDirSepChar(c) THEN> IF n = 1 OR NOT IsDirSepChar(Text.GetChar(t, 1)) THEN RETURN 1 END;178c183< IF cc = DirSepChar THEN---> IF IsDirSepChar(cc) THEN196c201< IF n > 2 AND Text.GetChar(t, 2) = DirSepChar THEN RETURN 3 END;---> IF n > 2 AND IsDirSepChar(Text.GetChar(t, 2)) THEN RETURN 3 END;218c223< IF c = DirSepChar THEN---> IF IsDirSepChar(c) THEN253c258< IF ch = DirSepChar OR ch = DriveSepChar THEN---> IF IsDirSepChar(ch) OR ch = DriveSepChar THEN - Jay _________________________________________________________________ Put your friends on the big screen with Windows Vista? + Windows Live?. http://www.microsoft.com/windows/shop/specialoffers.mspx?ocid=TXT_TAGLM_CPC_MediaCtr_bigscreen_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.caltech.edu Thu Jan 10 12:34:47 2008 From: mika at async.caltech.edu (Mika Nystrom) Date: Thu, 10 Jan 2008 03:34:47 -0800 Subject: [M3devel] win32 path separators -- support forward and backward in libm3? In-Reply-To: Your message of "Thu, 10 Jan 2008 11:24:20 GMT." Message-ID: <200801101134.m0ABYl2I053123@camembert.async.caltech.edu> With Cygwin, I think it's pretty much inevitable that you're going to get a mixture of / and \.... (and sometimes it's a real pain, yes). For your "edification", I include the file "README.CYGWIN" that I keep at the root of my software repository... I'm sure this doesn't all apply to CM3, but it's what I deal with to get things running with the Klagenfurt compiler... 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. From jayk123 at hotmail.com Thu Jan 10 13:40:22 2008 From: jayk123 at hotmail.com (Jay) Date: Thu, 10 Jan 2008 12:40:22 +0000 Subject: [M3devel] could someone add __stdcall name mangling to m3cc please? In-Reply-To: <200801100131.m0A1VQYS034516@camembert.async.caltech.edu> References: Your message of "Wed, 09 Jan 2008 17:25:31 PST." <200801100131.m0A1VQYS034516@camembert.async.caltech.edu> Message-ID: Could someone out there (Tony?) familiar with the gcc backendhave it not ignore call_conv and if call_conv is 1, appendan at symbol and the number of bytes of parameters to the function name? (Even for zero, e.g. Sleep at 0, GetFileAttributes at 4).This would be I guess at least for "imported" functions. Not clear about calling function pointers, probably needs modification.call_conv 0 is "__cdecl" is push right to left, caller cleans upcall_conv 1 is "__stdcall" is push right to left, callee cleans up There are various synonyms. With no command line switches, __cdecl is the compiler default. __stdcall is deemed more efficient, and is very widely used. Not clear about functions implemented in Modula-3.Probably won't occur? Maybe for callbacks? WindowProcs, thread entry point? This could/should be for NT386GNU only.The hypothetical other NT targets only have one calling convention each. I COULD do something sleazy here and generate little adapter functions, over in m3-win/import-libs esp. I'm still checking out pm3 to see what it does here.(as in cvs checkout, not "looking at") This'll clear up: RTOS.m3:27: undefined reference to `_FatalExit'RTOS.mo: In function `RTOS__GetMemory':RTOS.m3:75: undefined reference to `_VirtualAlloc'RTOS.m3:85: undefined reference to `_VirtualAlloc'RTOS.mo: In function `RTOS__InitMemory':RTOS.m3:96: undefined reference to `_VirtualAlloc'RTOS.m3:100: undefined reference to `_GetSystemInfo'RTOS.mo: In function `RTOS__Write':RTOS.m3:118: undefined reference to `_AllocConsole'RTOS.m3:119: undefined reference to `_GetStdHandle'RTOS.m3:122: undefined reference to `_WriteFile'RTPerfTool.mo: In function `RTPerfTool__Start':RTPerfTool.m3:19: undefined reference to `_ReadFile'RTPerfTool.m3:22: undefined reference to `_CloseHandle'RTPerfTool.mo: In function `RTPerfTool__Close':RTPerfTool.m3:28: undefined reference to `_CloseHandle'RTPerfTool.mo: In function `RTPerfTool__Send':RTPerfTool.m3:34: undefined reference to `_WriteFile'RTPerfTool.mo: In function `RTPerfTool__PrepHandle':RTPerfTool.m3:58: undefined reference to `_GetCurrentProcess'RTPerfTool.m3:59: undefined reference to `_DuplicateHandle'etc. I did think I was past these. I thought I built m3core and libm3 including linking (having even modified cm3.cfg)COULD be I'm using the wrong .libs, but: C:\cygwin\lib\w32api>nm libkernel32.a | findstr CreateFile00000000 I __imp__CreateFileW at 2800000000 T _CreateFileW at 2800000000 I __imp__CreateFileMappingW at 2400000000 T _CreateFileMappingW at 2400000000 I __imp__CreateFileMappingA at 2400000000 T _CreateFileMappingA at 2400000000 I __imp__CreateFileA at 2800000000 T _CreateFileA at 28 C:\cygwin\lib\w32api>cd \MinGW\lib C:\MinGW\lib>nm libkernel32.a | findstr CreateFile00000000 I __imp__CreateFileW at 2800000000 T _CreateFileW at 2800000000 I __imp__CreateFileMappingW at 2400000000 T _CreateFileMappingW at 2400000000 I __imp__CreateFileMappingA at 2400000000 T _CreateFileMappingA at 2400000000 I __imp__CreateFileA at 2800000000 T _CreateFileA at 28 I think at least THREE calling conventions should be supported -- __cdecl, __stdcall, __fastcall --but oh well. We can live without __fastcall.Watcom has another calling convention, "watcall", and they let you describe calling conventions with #pragmas, neat. Thanks, - Jay _________________________________________________________________ Share life as it happens with the new Windows Live. http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Thu Jan 10 13:42:58 2008 From: jayk123 at hotmail.com (Jay) Date: Thu, 10 Jan 2008 12:42:58 +0000 Subject: [M3devel] could someone add __stdcall name mangling to m3cc please? In-Reply-To: References: Your message of "Wed, 09 Jan 2008 17:25:31 PST." <200801100131.m0A1VQYS034516@camembert.async.caltech.edu> Message-ID: PM3 appears to ignore call_conv. Perhaps its NT386GNU uses usermode threads via cygwin1.dll and has no gui support, such as to not import any __stdcall functions??? http://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/m3/pm3/language/modula3/m3compiler/m3cc/gcc/gcc/m3cg/m3.c?rev=1.1;content-type=text%2Fx-cvsweb-markup;cvsroot=PM3 - Jay From: jayk123 at hotmail.comTo: m3devel at elegosoft.comDate: Thu, 10 Jan 2008 12:40:22 +0000Subject: [M3devel] could someone add __stdcall name mangling to m3cc please? Could someone out there (Tony?) familiar with the gcc backendhave it not ignore call_conv and if call_conv is 1, appendan at symbol and the number of bytes of parameters to the function name? (Even for zero, e.g. Sleep at 0, GetFileAttributes at 4).This would be I guess at least for "imported" functions.Not clear about calling function pointers, probably needs modification.call_conv 0 is "__cdecl" is push right to left, caller cleans upcall_conv 1 is "__stdcall" is push right to left, callee cleans up There are various synonyms. With no command line switches, __cdecl is the compiler default. __stdcall is deemed more efficient, and is very widely used.Not clear about functions implemented in Modula-3.Probably won't occur? Maybe for callbacks? WindowProcs, thread entry point?This could/should be for NT386GNU only.The hypothetical other NT targets only have one calling convention each.I COULD do something sleazy here and generate little adapter functions, over in m3-win/import-libs esp.I'm still checking out pm3 to see what it does here.(as in cvs checkout, not "looking at")This'll clear up:RTOS.m3:27: undefined reference to `_FatalExit'RTOS.mo: In function `RTOS__GetMemory':RTOS.m3:75: undefined reference to `_VirtualAlloc'RTOS.m3:85: undefined reference to `_VirtualAlloc'RTOS.mo: In function `RTOS__InitMemory':RTOS.m3:96: undefined reference to `_VirtualAlloc'RTOS.m3:100: undefined reference to `_GetSystemInfo'RTOS.mo: In function `RTOS__Write':RTOS.m3:118: undefined reference to `_AllocConsole'RTOS.m3:119: undefined reference to `_GetStdHandle'RTOS.m3:122: undefined reference to `_WriteFile'RTPerfTool.mo: In function `RTPerfTool__Start':RTPerfTool.m3:19: undefined reference to `_ReadFile'RTPerfTool.m3:22: undefined reference to `_CloseHandle'RTPerfTool.mo: In function `RTPerfTool__Close':RTPerfTool.m3:28: undefined reference to `_CloseHandle'RTPerfTool.mo: In function `RTPerfTool__Send':RTPerfTool.m3:34: undefined reference to `_WriteFile'RTPerfTool.mo: In function `RTPerfTool__PrepHandle':RTPerfTool.m3:58: undefined reference to `_GetCurrentProcess'RTPerfTool.m3:59: undefined reference to `_DuplicateHandle'etc.I did think I was past these. I thought I built m3core and libm3 including linking (having even modified cm3.cfg)COULD be I'm using the wrong .libs, but:C:\cygwin\lib\w32api>nm libkernel32.a | findstr CreateFile00000000 I __imp__CreateFileW at 2800000000 T _CreateFileW at 2800000000 I __imp__CreateFileMappingW at 2400000000 T _CreateFileMappingW at 2400000000 I __imp__CreateFileMappingA at 2400000000 T _CreateFileMappingA at 2400000000 I __imp__CreateFileA at 2800000000 T _CreateFileA at 28C:\cygwin\lib\w32api>cd \MinGW\libC:\MinGW\lib>nm libkernel32.a | findstr CreateFile00000000 I __imp__CreateFileW at 2800000000 T _CreateFileW at 2800000000 I __imp__CreateFileMappingW at 2400000000 T _CreateFileMappingW at 2400000000 I __imp__CreateFileMappingA at 2400000000 T _CreateFileMappingA at 2400000000 I __imp__CreateFileA at 2800000000 T _CreateFileA at 28 I think at least THREE calling conventions should be supported -- __cdecl, __stdcall, __fastcall --but oh well. We can live without __fastcall.Watcom has another calling convention, "watcall", and they let you describe calling conventions with #pragmas, neat.Thanks, - Jay Share life as it happens with the new Windows Live. Start sharing! _________________________________________________________________ Get the power of Windows + Web with the new Windows Live. http://www.windowslive.com?ocid=TXT_TAGHM_Wave2_powerofwindows_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Thu Jan 10 13:58:50 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 10 Jan 2008 13:58:50 +0100 Subject: [M3devel] win32 path separators -- support forward and backward in libm3? In-Reply-To: References: Your message of "Wed, 09 Jan 2008 17:25:31 PST." <200801100131.m0A1VQYS034516@camembert.async.caltech.edu> Message-ID: <20080110135850.g34emuxds0ogwwk4@mail.elegosoft.com> Quoting Jay : > To a very large extent, Win32 accepts both / and \ equally as path > delimiters. > CreateFile, DeleteFile, CreateDirectory, MoveFile, CopyFile, > FindFirstFile, GetFileAttributes, the C runtime wrappers fopen, > unlink/remove, stat, etc., those all work either way, or with a mix. > "Shell" functions like shlwapi.dll, commdlg32.dll, tend not to. > > In building NT386GNU, I run into places where cm3 is picking apart paths. > For whatever reason, it is being given paths with a mix of forward > and backward slashes. > I find these paths ugly, but they work ok. > > I've been able to easily progress by changing > m3-libs/libm3/src/os/WIN32/PathnameWin32.m3 to treat forward and > backslashes the same. > I have not yet rebuilt the normal NT386 target with this change. > > An ok change? > > Or go and fix NT386GNU a) to be consistent, b) use backward slashes, > c) translate at some place. > > ? In my opininion NT386GNU should be a POSIX target and thus use forward slashes as standard as POSIX defines. Offhand I wouldn't object to accept backward slashes as path delimiters, too. But you must heed that \ is used as an escape character almost everywhere (and so should it be in pathname denotations then: a\\b\\c) or you loose much compatibility. I still wonder if the decision to use \ on DOS/Windows was only made to be as incompatible as possible with Unix... Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Jan 10 14:11:33 2008 From: jayk123 at hotmail.com (Jay) Date: Thu, 10 Jan 2008 13:11:33 +0000 Subject: [M3devel] FW: bad code on PPC_LINUX? In-Reply-To: References: Message-ID: Removing -fPIC seems to fix this, though the code still stinks and the frame is still huge (700+ bytes). Even with -O, even without -gstabs (adding/removing -gstabs shouldn't matter but I tried anyway) - Jay ________________________________ > From: jayk123 at hotmail.com > To: m3devel at elegosoft.com > Date: Thu, 10 Jan 2008 09:28:31 +0000 > Subject: [M3devel] FW: bad code on PPC_LINUX? > > My emails keep getting truncated for some reason.. :( > > > ________________________________ >> From: jayk123 at hotmail.com >> To: m3devel at elegosoft.com >> Subject: bad code on PPC_LINUX? >> Date: Thu, 10 Jan 2008 07:11:11 +0000 >> >> >> Something is screwy I think. >> My gdb skills are um not good. >> >> On PPC_LINUX. >> >> /dev2/cm3/m3-sys/cm3/src/Utils.m3 >> >> PROCEDURE WriteFile (file: TEXT; proc: Emitter; append := FALSE) = >> VAR wr: Wr.T; >> BEGIN >> IF (append) >> THEN wr := AppendWriter (file, fatal := TRUE); >> ELSE wr := OpenWriter (file, fatal := TRUE); >> END; >> TRY (* line 78 *) >> TRY >> proc (wr); >> EXCEPT >> | Wr.Failure (ec) => >> Msg.FatalError (ec, "write failed on ", file); >> | Thread.Alerted => >> Msg.FatalError (NIL, "interrupted while writing ", file); >> END; >> FINALLY >> CloseWriter (wr, file); >> END; >> END WriteFile; >> >> I get a SEGV on line 78. >> >> I'm willing to believe, sadly, that some of these huge offsets >> are the price of TRY and saving the register context on anything >> other than x86 (for registers that aren't even used by the function?), >> however it crashes just after the call and notice there the huge 32k offset. >> >> And really? A 720 byte frame for any function with a TRY on PowerPC? >> Really? >> I guess I should look at what PPC_DARWIN does. >> >> If someone can give me a quick run down on PowerPC ABI, thanks. >> I'll search the web. Or maybe check my Mac docs. >> register 0 is 0 or general purpose? >> Stack is register ? >> I know that return address is in the link register. >> bl is branch and link -- call -- jump and save pc in link register. >> >> The code is: >> (gdb) disassemble >> Dump of assembler code for function Utils__WriteFile: >> 0x10024fbc : stwu r1,-720(r1) >> 0x10024fc0 : mflr r0 >> 0x10024fc4 : mfcr r12 >> 0x10024fc8 : stfd f14,576(r1) >> 0x10024fcc : stfd f15,584(r1) >> 0x10024fd0 : stfd f16,592(r1) >> 0x10024fd4 : stfd f17,600(r1) >> 0x10024fd8 : stfd f18,608(r1) >> 0x10024fdc : stfd f19,616(r1) >> 0x10024fe0 : stfd f20,624(r1) >> 0x10024fe4 : stfd f21,632(r1) >> 0x10024fe8 : stfd f22,640(r1) >> 0x10024fec : stfd f23,648(r1) >> 0x10024ff0 : stfd f24,656(r1) >> 0x10024ff4 : stfd f25,664(r1) >> 0x10024ff8 : stfd f26,672(r1) >> 0x10024ffc : stfd f27,680(r1) >> 0x10025000 : stfd f28,688(r1) >> 0x10025004 : stfd f29,696(r1) >> 0x10025008 : stfd f30,704(r1) >> 0x1002500c : stfd f31,712(r1) >> 0x10025010 : stw r14,504(r1) >> 0x10025014 : stw r15,508(r1) >> 0x10025018 : stw r16,512(r1) >> 0x1002501c : stw r17,516(r1) >> 0x10025020 : stw r18,520(r1) >> 0x10025024 : stw r19,524(r1) >> 0x10025028 : stw r20,528(r1) >> 0x1002502c : stw r21,532(r1) >> ---Type to continue, or q to quit--- >> 0x10025030 : stw r22,536(r1) >> 0x10025034 : stw r23,540(r1) >> 0x10025038 : stw r24,544(r1) >> 0x1002503c : stw r25,548(r1) >> 0x10025040 : stw r26,552(r1) >> 0x10025044 : stw r27,556(r1) >> 0x10025048 : stw r28,560(r1) >> 0x1002504c : stw r29,564(r1) >> 0x10025050 : stw r30,568(r1) >> 0x10025054 : stw r31,572(r1) >> 0x10025058 : stw r0,724(r1) >> 0x1002505c : stw r12,500(r1) >> 0x10025060 : mr r31,r1 >> 0x10025064 : bl 0x10025068 >> 0x10025068 : mflr r30 >> 0x1002506c : lwz r0,-176(r30) >> 0x10025070 : add r30,r0,r30 >> 0x10025074 : stw r3,8(r31) >> 0x10025078 : stw r4,12(r31) >> 0x1002507c : mr r0,r5 >> 0x10025080 : stb r0,16(r31) >> 0x10025084 : li r0,0 >> 0x10025088 : stw r0,20(r31) >> 0x1002508c : lbz r0,16(r31) >> 0x10025090 : clrlwi r0,r0,24 >> 0x10025094 : cmpwi r0,0 >> 0x10025098 : beq- 0x100250b8 >> 0x1002509c : lwz r3,8(r31) >> 0x100250a0 : li r4,1 >> 0x100250a4 : bl 0x100248a4 >> ---Type to continue, or q to quit--- >> 0x100250a8 : stw r3,476(r31) >> 0x100250ac : lwz r9,476(r31) >> 0x100250b0 : stw r9,20(r31) >> 0x100250b4 : b 0x100250d0 >> 0x100250b8 : lwz r3,8(r31) >> 0x100250bc : li r4,1 >> 0x100250c0 : bl 0x10024658 >> 0x100250c4 : stw r3,476(r31) >> 0x100250c8 : lwz r9,476(r31) >> 0x100250cc : stw r9,20(r31) >> >> ** here I believe ** >> >> 0x100250d0 : lwz r0,-32760(r30) >> 0x100250d4 : stw r0,32(r31) >> 0x100250d8 : addi r0,r31,8 >> 0x100250dc : stw r0,36(r31) >> 0x100250e0 : li r0,3 >> 0x100250e4 : stw r0,28(r31) >> 0x100250e8 : lwz r9,-32764(r30) >> 0x100250ec : lwz r0,0(r9) >> 0x100250f0 : stw r0,24(r31) >> 0x100250f4 : lwz r9,-32764(r30) >> 0x100250f8 : addi r0,r31,24 >> 0x100250fc : stw r0,0(r9) >> 0x10025100 : lwz r9,-32768(r30) >> 0x10025104 : addi r0,r9,76 >> 0x10025108 : stw r0,64(r31) >> 0x1002510c : li r0,0 >> 0x10025110 : stw r0,60(r31) >> 0x10025114 : lwz r9,-32764(r30) >> 0x10025118 : lwz r0,0(r9) >> 0x1002511c : stw r0,56(r31) >> ---Type to continue, or q to quit--- >> 0x10025120 : lwz r9,-32764(r30) >> 0x10025124 : addi r0,r31,56 >> 0x10025128 : stw r0,0(r9) >> 0x1002512c : addi r9,r31,56 >> 0x10025130 : addi r0,r9,48 >> 0x10025134 : mr r3,r0 >> 0x10025138 : bl 0x101bbf28 >> 0x1002513c : mr r0,r3 >> 0x10025140 : cmpwi r0,0 >> 0x10025144 : bne- 0x100251ac >> 0x10025148 : lwz r9,12(r31) >> 0x1002514c : stw r9,476(r31) >> 0x10025150 : lwz r9,476(r31) >> 0x10025154 : cmpwi r9,0 >> 0x10025158 : beq- 0x10025188 >> 0x1002515c : lwz r9,476(r31) >> 0x10025160 : lwz r0,0(r9) >> 0x10025164 : li r9,-1 >> 0x10025168 : cmpw r0,r9 >> 0x1002516c : bne- 0x10025188 >> 0x10025170 : lwz r9,476(r31) >> 0x10025174 : lwz r9,8(r9) >> 0x10025178 : stw r9,480(r31) >> 0x1002517c : lwz r9,476(r31) >> 0x10025180 : lwz r9,4(r9) >> 0x10025184 : stw r9,476(r31) >> 0x10025188 : lwz r11,480(r31) >> 0x1002518c : lwz r3,20(r31) >> 0x10025190 : lwz r0,476(r31) >> 0x10025194 : mtlr r0 >> ---Type to continue, or q to quit--- >> 0x10025198 : blrl >> 0x1002519c : lwz r9,-32764(r30) >> 0x100251a0 : lwz r0,56(r31) >> 0x100251a4 : stw r0,0(r9) >> 0x100251a8 : b 0x10025210 >> 0x100251ac : lwz r9,68(r31) >> 0x100251b0 : lwz r9,0(r9) >> 0x100251b4 : lis r0,-15535 >> 0x100251b8 : ori r0,r0,42454 >> 0x100251bc : cmpw r9,r0 >> 0x100251c0 : bne- 0x100251f0 >> 0x100251c4 : lwz r0,72(r31) >> 0x100251c8 : stw r0,472(r31) >> 0x100251cc : lwz r9,-32768(r30) >> 0x100251d0 : addi r0,r9,180 >> 0x100251d4 : lwz r3,472(r31) >> 0x100251d8 : mr r4,r0 >> 0x100251dc : lwz r5,8(r31) >> 0x100251e0 : li r6,0 >> 0x100251e4 : li r7,0 >> 0x100251e8 : bl 0x10023b4c >> 0x100251ec : b 0x10025210 >> 0x100251f0 : lwz r9,-32768(r30) >> 0x100251f4 : addi r0,r9,212 >> 0x100251f8 : li r3,0 >> 0x100251fc : mr r4,r0 >> 0x10025200 : lwz r5,8(r31) >> 0x10025204 : li r6,0 >> 0x10025208 : li r7,0 >> 0x1002520c : bl 0x10023b4c >> ---Type to continue, or q to quit--- >> 0x10025210 : lwz r9,-32764(r30) >> 0x10025214 : lwz r0,24(r31) >> 0x10025218 : stw r0,0(r9) >> 0x1002521c : addi r11,r31,8 >> 0x10025220 : bl 0x10024f74 >> 0x10025224 : lwz r11,0(r1) >> 0x10025228 : lwz r0,4(r11) >> 0x1002522c : lwz r12,-220(r11) >> 0x10025230 : mtlr r0 >> 0x10025234 : lwz r14,-216(r11) >> 0x10025238 : lwz r15,-212(r11) >> 0x1002523c : lwz r16,-208(r11) >> 0x10025240 : lwz r17,-204(r11) >> 0x10025244 : lwz r18,-200(r11) >> 0x10025248 : lwz r19,-196(r11) >> 0x1002524c : lwz r20,-192(r11) >> 0x10025250 : lwz r21,-188(r11) >> 0x10025254 : lwz r22,-184(r11) >> 0x10025258 : lwz r23,-180(r11) >> 0x1002525c : lwz r24,-176(r11) >> 0x10025260 : lwz r25,-172(r11) >> 0x10025264 : lwz r26,-168(r11) >> 0x10025268 : lwz r27,-164(r11) >> 0x1002526c : lwz r28,-160(r11) >> 0x10025270 : lwz r29,-156(r11) >> 0x10025274 : lwz r30,-152(r11) >> 0x10025278 : lwz r31,-148(r11) >> 0x1002527c : lfd f14,-144(r11) >> 0x10025280 : lfd f15,-136(r11) >> 0x10025284 : lfd f16,-128(r11) >> ---Type to continue, or q to quit--- >> 0x10025288 : lfd f17,-120(r11) >> 0x1002528c : lfd f18,-112(r11) >> 0x10025290 : lfd f19,-104(r11) >> 0x10025294 : lfd f20,-96(r11) >> 0x10025298 : lfd f21,-88(r11) >> 0x1002529c : lfd f22,-80(r11) >> 0x100252a0 : lfd f23,-72(r11) >> 0x100252a4 : lfd f24,-64(r11) >> 0x100252a8 : lfd f25,-56(r11) >> 0x100252ac : lfd f26,-48(r11) >> 0x100252b0 : lfd f27,-40(r11) >> 0x100252b4 : lfd f28,-32(r11) >> 0x100252b8 : lfd f29,-24(r11) >> 0x100252bc : lfd f30,-16(r11) >> 0x100252c0 : lfd f31,-8(r11) >> 0x100252c4 : mtcrf 56,r12 >> 0x100252c8 : mr r1,r11 >> 0x100252cc : blr >> 0x100252d0 : .long 0x24ebb0 >> End of assembler dump. >> >> >> (gdb) bt >> #0 Utils__WriteFile (M3_Bd56fi_file=0x10277ba0, M3_DmuccK_proc=0x7fb22210, >> M3_AicXUJ_append=0 '\0') at Utils.m3:78 >> #1 0x10020a10 in Makefile__Build (M3_Bd56fi_src_dir=0x102720ec) >> at Makefile.m3:101 >> #2 0x100292d4 in Main__DoIt () at Main.m3:71 >> #3 0x10029834 in Main_M3 (M3_AcxOUs_mode=1) at Main.m3:193 >> #4 0x10188f9c in RTLinker__RunMainBody (M3_DUuepq_m=0x10279b28) >> at RTLinker.m3:387 >> #5 0x101880bc in RTLinker__AddUnitI (M3_DUuepq_m=0x10279b28) at RTLinker.m3:100 >> #6 0x10188198 in RTLinker__AddUnit (M3_DUuepw_b=0x100297f8) at RTLinker.m3:110 >> #7 0x100002ec in main (argc=1, argv=0x7fb22834, envp=0x7fb2283c) at _m3main.mc:4 >> >> I haven't yet figured out how to get gdb to show me the details of the SEGV, like what address was referenced. >> >> I swear I think this was working better recently. >> >> Oh, I did change something. I will try to change it back. >> I added -fPIC. >> Dynamic linking was not working and I thought that might fix it. >> I'll definitely try without it now. >> >> Also, relevant aside -- what, if any, distributions/versions of Linux are people using on PowerPC? >> Specifically on PowerPC (to limit the religious explosion) >> I'm currently using Yellow Dog, I think 4.1, but only for Modula-3 purposes, not for anything else. >> >> ps: I'd like a SMALL forum of SMART programmers, to discuss GENERAL programming topics. >> This is it perhaps? >> >> - Jay >> _________________________________________________________________ >> Watch ?Cause Effect,? a show about real people making a real difference. >> http://im.live.com/Messenger/IM/MTV/?source=text_watchcause > > ________________________________ > Make distant family not so distant with Windows Vista? + Windows Live?. Start now! _________________________________________________________________ Put your friends on the big screen with Windows Vista? + Windows Live?. http://www.microsoft.com/windows/shop/specialoffers.mspx?ocid=TXT_TAGLM_CPC_MediaCtr_bigscreen_012008 From hendrik at topoi.pooq.com Thu Jan 10 15:28:12 2008 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Thu, 10 Jan 2008 09:28:12 -0500 Subject: [M3devel] (Offtopic) Some comments on SCM tools, was: Re: M3 concerns In-Reply-To: <20080110122020.zm4wc29e8044c0kw@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> <20080105191243.GB6402@topoi.pooq.com> <20080110122020.zm4wc29e8044c0kw@mail.elegosoft.com> Message-ID: <20080110142812.GA2503@topoi.pooq.com> On Thu, Jan 10, 2008 at 12:20:20PM +0100, Olaf Wagner wrote: > Quoting hendrik at topoi.pooq.com: > >But if you have this experience, it would be useful to see a rundown > >of the advantages and disadvantages of each. I've seen a table of > >features against version control systems, but it doesn't give any feel > >for what it's like to use them. > > > >Such an essay would be useful for those involved in other projects. It > >probably won't help Modula 3 itself. > > That would easily become an open-ended task :-) I was once asked to compare several programming languages with the intent of advising researchers in an institute which ones to use. A year into the project, I was sorry I ever started it. I learned a lot about CPU-time clocks running backward. I learned a lot about how different languages ended up with differences in floating-point behaviour, even though they were all running on the same hardware with one same set of floating-point instructions. > It is not easy to > compare different complex tools like SCM systems, which interact > in various degrees with process control, workflow management, problem > management, project management, general policies... Which is why a list of features really isn't enough. What's needed is poeple with hands-on experience with several. Which is hard to get. > > We've tried to provide feature-oriented comparison lists some years > ago, but even this needs too much efforts and is too fast out-of-date. > > There are some aspects that may currently be helpful as criterions > though. I'd like to mention some of them > > o Traditionally, version control tools were centralized server systems. > There is one central repository (which can in advanced setups be > replicated to several sites for many systems. Replicas may even be > partly writable. In case of replication there is one `logical' central > repository which is physically distributed.). Systems in this group > are CVS, ClearCase, PVCS, AccuRev, Perforce, Subversion, and many > others. > In recent years, peer-to-peer systems have become popular, because > they correspond better to certain aspects of open software projects > and are inherently distributed. There is no distinction between > workspace and repository, and each workspace holds a partial or > complete change history. > Such systems are BitKeeper, git, Darcs, and others. As far as I know, > these systems are not very popular in the commercial world (yet?). > > o An orthogonal criterion is the range of functionality that is addressed > with the solution. Simple systems like CVS and Perforce do just version > control and offer some hooks for further integration. > On the other side are process-oriented systems like PVCS Dimensions or a > complete ClearCase/ClearQuest setup for RUP. These systems are > rather based on change management und workflow than on developer > needs. Basic abstractions are baselines, changesets, tasks, projects, > activities, functional roles. > Of course, some tools are somewhere in between these extremes, like > AccuRev, which supports kinds of long-running transactions for > everything, called `streams'. (This one's very nice IMO.) > > o Then there are the costs of the use of the systems. There are always > costs, even for open source solutions. You have to consider > > - server costs (hardware, energy, OS, database, licences, networks) > - administration and maintenance (servers and user setup) > - user license costs (from 0 to several thousand dollars per year) > - use overhead (depending on tool usability and process) > - instruction and training > > Again there are systems that are rather lightweight in this respect > (like CVS and Perforce) and some tending to be more heavyweight > (like ClearCase and PVCS). > > o The `end user experience' corresponds very much to the basic > concepts needed in everyday use. File based ci/co is very > simple, development lines are more or less a must have, > change sets and baselines (like in DCVS, AccuRev or RUP) are very > nice; diffs and merges seem to be too complex for many users > (but are of course needed); conflict avoidance vs. conflict > resolution (locking or optimistic approach) is often a religiously > discussed topic. > The other important issue here is the IDE integration (at least > for developers). > > These are only some randomly picked topics that would need to be > addressed in a useful tool comparison. > > There are very few situations in which you can evaluate and choose > the best tool for your purpose; most of the time, you have to adapt > and improve existing setups, as everything else would be too > expensive and disrupting. Our company has supported several migration > projects recently though, so it's not impossible to change ;-) > > As for CM3, I'm still of the opinion that there is no need to > change the existing CVS infrastructure. > > >Or might you know of such an essay elsewhere? > > Well, the more interesting field studies and evaluations are not > free; there are quite a lot of interesting articles though. > I haven't any links here right now; CM crossroads or a Google > search on `configuration management' should be a good starting point. Thank you for this very brief review. I'm really not wanting you to take a year off from more urgent 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 hendrik at topoi.pooq.com Thu Jan 10 15:37:50 2008 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Thu, 10 Jan 2008 09:37:50 -0500 Subject: [M3devel] win32 path separators -- support forward and backward in libm3? In-Reply-To: <20080110135850.g34emuxds0ogwwk4@mail.elegosoft.com> References: <200801100131.m0A1VQYS034516@camembert.async.caltech.edu> <20080110135850.g34emuxds0ogwwk4@mail.elegosoft.com> Message-ID: <20080110143750.GB2503@topoi.pooq.com> On Thu, Jan 10, 2008 at 01:58:50PM +0100, Olaf Wagner wrote: > Quoting Jay : > > >To a very large extent, Win32 accepts both / and \ equally as path > >delimiters. > >CreateFile, DeleteFile, CreateDirectory, MoveFile, CopyFile, > >FindFirstFile, GetFileAttributes, the C runtime wrappers fopen, > >unlink/remove, stat, etc., those all work either way, or with a mix. > >"Shell" functions like shlwapi.dll, commdlg32.dll, tend not to. > > > >In building NT386GNU, I run into places where cm3 is picking apart paths. > >For whatever reason, it is being given paths with a mix of forward > >and backward slashes. > >I find these paths ugly, but they work ok. > > > >I've been able to easily progress by changing > >m3-libs/libm3/src/os/WIN32/PathnameWin32.m3 to treat forward and > >backslashes the same. > >I have not yet rebuilt the normal NT386 target with this change. > > > >An ok change? > > > >Or go and fix NT386GNU a) to be consistent, b) use backward slashes, > > c) translate at some place. > > > >? > > In my opininion NT386GNU should be a POSIX target and thus use forward > slashes as standard as POSIX defines. Offhand I wouldn't object to accept > backward slashes as path delimiters, too. But you must heed that \ > is used as an escape character almost everywhere (and so should it be > in pathname denotations then: a\\b\\c) or you loose much compatibility. > > I still wonder if the decision to use \ on DOS/Windows was only made to > be as incompatible as possible with Unix... In the early days, DOS did not have directories, so there was no need of a slash or anything as a pathname separator. Instead, it got used as a character to attach options to command names. I think is also got used to attach options to filenames sometimes. When someone got the bright idea that directories were a neat idea, it was too late. Incidentally, in those days, Unix wasn't yet the big deal it is now. There were lots of other OS's to be compatible with -- or not. -- hendrik From darko at darko.org Thu Jan 10 17:35:05 2008 From: darko at darko.org (Darko) Date: Thu, 10 Jan 2008 08:35:05 -0800 Subject: [M3devel] nt386gnu is posix or win32? In-Reply-To: References: Your message of "Wed, 09 Jan 2008 17:25:31 PST." <200801100131.m0A1VQYS034516@camembert.async.caltech.edu> Message-ID: <6A267174-E215-48A6-BD0D-CB9AF4C13FE5@darko.org> On 10/01/2008, at 3:16 AM, Jay wrote: > By "serious" I mean, "ship real software using it". Then the question is: what is' real' software. I've shipped commercial software (a smallish application) using the existing native back end, which doesn't produce very good code, but the performance was adequate. For many other applications this won't be the case. You should look at this issue the other way around: If it allows people to build 'serious' software, they will use it. If you have an interest in Windows and M3, this would be one of the most useful things you could do, IMHO. Darko. From hosking at cs.purdue.edu Thu Jan 10 18:41:55 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 10 Jan 2008 12:41:55 -0500 Subject: [M3devel] bad code on PPC_LINUX? In-Reply-To: References: Message-ID: <9E64639D-CF64-4E6E-A157-FB67D1AC0C9B@cs.purdue.edu> Is this an alignment problem? Or a mismatch between the compiler and runtime? I have no idea if the alignment specs and definitions for the jmp_buf used in exceptions are matched between the compiler and run-time properly. See Target.m3 in the compiler and RTMachine.i3 in the runtime. On Jan 10, 2008, at 2:11 AM, Jay wrote: > > Something is screwy I think. > My gdb skills are um not good. > > On PPC_LINUX. > > /dev2/cm3/m3-sys/cm3/src/Utils.m3 > > PROCEDURE WriteFile (file: TEXT; proc: Emitter; append := FALSE) = > VAR wr: Wr.T; > BEGIN > IF (append) > THEN wr := AppendWriter (file, fatal := TRUE); > ELSE wr := OpenWriter (file, fatal := TRUE); > END; > TRY (* line 78 *) > TRY > proc (wr); > EXCEPT > | Wr.Failure (ec) => > Msg.FatalError (ec, "write failed on ", file); > | Thread.Alerted => > Msg.FatalError (NIL, "interrupted while writing ", file); > END; > FINALLY > CloseWriter (wr, file); > END; > END WriteFile; > > I get a SEGV on line 78. > > I'm willing to believe, sadly, that some of these huge offsets > are the price of TRY and saving the register context on anything > other than x86 (for registers that aren't even used by the function?), > however it crashes just after the call and notice there the huge > 32k offset From hosking at cs.purdue.edu Thu Jan 10 18:52:35 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 10 Jan 2008 12:52:35 -0500 Subject: [M3devel] could someone add __stdcall name mangling to m3cc please? In-Reply-To: References: Your message of "Wed, 09 Jan 2008 17:25:31 PST." <200801100131.m0A1VQYS034516@camembert.async.caltech.edu> Message-ID: <6D677FCA-D704-4E84-BD58-893C71D97B59@cs.purdue.edu> On Jan 10, 2008, at 7:42 AM, Jay wrote: > PM3 appears to ignore call_conv. > Perhaps its NT386GNU uses usermode threads via cygwin1.dll and has > no gui support, such as to not import any __stdcall functions??? Probably, yes. CM3 were the ones who added gui support. Anyway, I think it is simply a matter of adding the appropriate attribute to the function decls in the gcc backend. I believe that it supports cdecl and stdcall. Are these all we need to specify? > http://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/m3/pm3/language/ > modula3/m3compiler/m3cc/gcc/gcc/m3cg/m3.c?rev=1.1;content-type=text% > 2Fx-cvsweb-markup;cvsroot=PM3 > > - Jay > > From: jayk123 at hotmail.com > To: m3devel at elegosoft.com > Date: Thu, 10 Jan 2008 12:40:22 +0000 > Subject: [M3devel] could someone add __stdcall name mangling to > m3cc please? > > Could someone out there (Tony?) familiar with the gcc backend > have it not ignore call_conv and if call_conv is 1, append > an at symbol and the number of bytes of parameters to the function > name? > (Even for zero, e.g. Sleep at 0, GetFileAttributes at 4). > This would be I guess at least for "imported" functions. > > Not clear about calling function pointers, probably needs > modification. > call_conv 0 is "__cdecl" is push right to left, caller cleans up > call_conv 1 is "__stdcall" is push right to left, callee cleans up > There are various synonyms. > With no command line switches, __cdecl is the compiler default. > __stdcall is deemed more efficient, and is very widely used. > > Not clear about functions implemented in Modula-3. > Probably won't occur? Maybe for callbacks? WindowProcs, thread > entry point? > > This could/should be for NT386GNU only. > The hypothetical other NT targets only have one calling convention > each. > > I COULD do something sleazy here and generate little adapter > functions, over in m3-win/import-libs esp. > > I'm still checking out pm3 to see what it does here. > (as in cvs checkout, not "looking at") > > This'll clear up: > > RTOS.m3:27: undefined reference to `_FatalExit' > RTOS.mo: In function `RTOS__GetMemory': > RTOS.m3:75: undefined reference to `_VirtualAlloc' > RTOS.m3:85: undefined reference to `_VirtualAlloc' > RTOS.mo: In function `RTOS__InitMemory': > RTOS.m3:96: undefined reference to `_VirtualAlloc' > RTOS.m3:100: undefined reference to `_GetSystemInfo' > RTOS.mo: In function `RTOS__Write': > RTOS.m3:118: undefined reference to `_AllocConsole' > RTOS.m3:119: undefined reference to `_GetStdHandle' > RTOS.m3:122: undefined reference to `_WriteFile' > RTPerfTool.mo: In function `RTPerfTool__Start': > RTPerfTool.m3:19: undefined reference to `_ReadFile' > RTPerfTool.m3:22: undefined reference to `_CloseHandle' > RTPerfTool.mo: In function `RTPerfTool__Close': > RTPerfTool.m3:28: undefined reference to `_CloseHandle' > RTPerfTool.mo: In function `RTPerfTool__Send': > RTPerfTool.m3:34: undefined reference to `_WriteFile' > RTPerfTool.mo: In function `RTPerfTool__PrepHandle': > RTPerfTool.m3:58: undefined reference to `_GetCurrentProcess' > RTPerfTool.m3:59: undefined reference to `_DuplicateHandle' > etc. > > I did think I was past these. I thought I built m3core and libm3 > including linking (having even modified cm3.cfg) > COULD be I'm using the wrong .libs, but: > > C:\cygwin\lib\w32api>nm libkernel32.a | findstr CreateFile > 00000000 I __imp__CreateFileW at 28 > 00000000 T _CreateFileW at 28 > 00000000 I __imp__CreateFileMappingW at 24 > 00000000 T _CreateFileMappingW at 24 > 00000000 I __imp__CreateFileMappingA at 24 > 00000000 T _CreateFileMappingA at 24 > 00000000 I __imp__CreateFileA at 28 > 00000000 T _CreateFileA at 28 > > C:\cygwin\lib\w32api>cd \MinGW\lib > > C:\MinGW\lib>nm libkernel32.a | findstr CreateFile > 00000000 I __imp__CreateFileW at 28 > 00000000 T _CreateFileW at 28 > 00000000 I __imp__CreateFileMappingW at 24 > 00000000 T _CreateFileMappingW at 24 > 00000000 I __imp__CreateFileMappingA at 24 > 00000000 T _CreateFileMappingA at 24 > 00000000 I __imp__CreateFileA at 28 > 00000000 T _CreateFileA at 28 > > I think at least THREE calling conventions should be supported -- > __cdecl, __stdcall, __fastcall -- > but oh well. We can live without __fastcall. > Watcom has another calling convention, "watcall", and they let you > describe calling conventions with #pragmas, neat. > > Thanks, > - Jay > > Share life as it happens with the new Windows Live. Start sharing! > Get the power of Windows + Web with the new Windows Live. Get it now! From hosking at cs.purdue.edu Thu Jan 10 18:57:47 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 10 Jan 2008 12:57:47 -0500 Subject: [M3devel] could someone add __stdcall name mangling to m3cc please? In-Reply-To: References: Your message of "Wed, 09 Jan 2008 17:25:31 PST." <200801100131.m0A1VQYS034516@camembert.async.caltech.edu> Message-ID: <70EC0898-EE63-4C19-8C28-EC72E2B73B31@cs.purdue.edu> Do we have a version of the gcc-based backend that *ever* supported the calling conventions? On Jan 10, 2008, at 7:40 AM, Jay wrote: > Could someone out there (Tony?) familiar with the gcc backend > have it not ignore call_conv and if call_conv is 1, append > an at symbol and the number of bytes of parameters to the function > name? > (Even for zero, e.g. Sleep at 0, GetFileAttributes at 4). > This would be I guess at least for "imported" functions. > > Not clear about calling function pointers, probably needs > modification. > call_conv 0 is "__cdecl" is push right to left, caller cleans up > call_conv 1 is "__stdcall" is push right to left, callee cleans up > There are various synonyms. > With no command line switches, __cdecl is the compiler default. > __stdcall is deemed more efficient, and is very widely used. > > Not clear about functions implemented in Modula-3. > Probably won't occur? Maybe for callbacks? WindowProcs, thread > entry point? > > This could/should be for NT386GNU only. > The hypothetical other NT targets only have one calling convention > each. > > I COULD do something sleazy here and generate little adapter > functions, over in m3-win/import-libs esp. > > I'm still checking out pm3 to see what it does here. > (as in cvs checkout, not "looking at") > > This'll clear up: > > RTOS.m3:27: undefined reference to `_FatalExit' > RTOS.mo: In function `RTOS__GetMemory': > RTOS.m3:75: undefined reference to `_VirtualAlloc' > RTOS.m3:85: undefined reference to `_VirtualAlloc' > RTOS.mo: In function `RTOS__InitMemory': > RTOS.m3:96: undefined reference to `_VirtualAlloc' > RTOS.m3:100: undefined reference to `_GetSystemInfo' > RTOS.mo: In function `RTOS__Write': > RTOS.m3:118: undefined reference to `_AllocConsole' > RTOS.m3:119: undefined reference to `_GetStdHandle' > RTOS.m3:122: undefined reference to `_WriteFile' > RTPerfTool.mo: In function `RTPerfTool__Start': > RTPerfTool.m3:19: undefined reference to `_ReadFile' > RTPerfTool.m3:22: undefined reference to `_CloseHandle' > RTPerfTool.mo: In function `RTPerfTool__Close': > RTPerfTool.m3:28: undefined reference to `_CloseHandle' > RTPerfTool.mo: In function `RTPerfTool__Send': > RTPerfTool.m3:34: undefined reference to `_WriteFile' > RTPerfTool.mo: In function `RTPerfTool__PrepHandle': > RTPerfTool.m3:58: undefined reference to `_GetCurrentProcess' > RTPerfTool.m3:59: undefined reference to `_DuplicateHandle' > etc. > > I did think I was past these. I thought I built m3core and libm3 > including linking (having even modified cm3.cfg) > COULD be I'm using the wrong .libs, but: > > C:\cygwin\lib\w32api>nm libkernel32.a | findstr CreateFile > 00000000 I __imp__CreateFileW at 28 > 00000000 T _CreateFileW at 28 > 00000000 I __imp__CreateFileMappingW at 24 > 00000000 T _CreateFileMappingW at 24 > 00000000 I __imp__CreateFileMappingA at 24 > 00000000 T _CreateFileMappingA at 24 > 00000000 I __imp__CreateFileA at 28 > 00000000 T _CreateFileA at 28 > > C:\cygwin\lib\w32api>cd \MinGW\lib > > C:\MinGW\lib>nm libkernel32.a | findstr CreateFile > 00000000 I __imp__CreateFileW at 28 > 00000000 T _CreateFileW at 28 > 00000000 I __imp__CreateFileMappingW at 24 > 00000000 T _CreateFileMappingW at 24 > 00000000 I __imp__CreateFileMappingA at 24 > 00000000 T _CreateFileMappingA at 24 > 00000000 I __imp__CreateFileA at 28 > 00000000 T _CreateFileA at 28 > > I think at least THREE calling conventions should be supported -- > __cdecl, __stdcall, __fastcall -- > but oh well. We can live without __fastcall. > Watcom has another calling convention, "watcall", and they let you > describe calling conventions with #pragmas, neat. > > Thanks, > - Jay > > Share life as it happens with the new Windows Live. Start sharing! From hosking at cs.purdue.edu Thu Jan 10 19:16:40 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 10 Jan 2008 13:16:40 -0500 Subject: [M3devel] FW: bad code on PPC_LINUX? In-Reply-To: References: Message-ID: <9D5186FA-9A91-4696-B6C6-CABC12DAE188@cs.purdue.edu> On Jan 10, 2008, at 4:28 AM, Jay wrote: > My emails keep getting truncated for some reason.. :( > > > > From: jayk123 at hotmail.com > > To: m3devel at elegosoft.com > > Subject: bad code on PPC_LINUX? > > Date: Thu, 10 Jan 2008 07:11:11 +0000 > > > > > > Something is screwy I think. > > My gdb skills are um not good. > > > > On PPC_LINUX. > > > > /dev2/cm3/m3-sys/cm3/src/Utils.m3 > > > > PROCEDURE WriteFile (file: TEXT; proc: Emitter; append := FALSE) = > > VAR wr: Wr.T; > > BEGIN > > IF (append) > > THEN wr := AppendWriter (file, fatal := TRUE); > > ELSE wr := OpenWriter (file, fatal := TRUE); > > END; > > TRY (* line 78 *) > > TRY > > proc (wr); > > EXCEPT > > | Wr.Failure (ec) => > > Msg.FatalError (ec, "write failed on ", file); > > | Thread.Alerted => > > Msg.FatalError (NIL, "interrupted while writing ", file); > > END; > > FINALLY > > CloseWriter (wr, file); > > END; > > END WriteFile; > > > > I get a SEGV on line 78. > > > > I'm willing to believe, sadly, that some of these huge offsets > > are the price of TRY and saving the register context on anything > > other than x86 (for registers that aren't even used by the > function?), > > however it crashes just after the call and notice there the huge > 32k offset. > > > > And really? A 720 byte frame for any function with a TRY on PowerPC? > > Really? Sounds odd, but maybe some struct in the frame is huge. What is the size of the jmp_buf? > > > I guess I should look at what PPC_DARWIN does. Sure. > > > > > If someone can give me a quick run down on PowerPC ABI, thanks. > > I'll search the web. Or maybe check my Mac docs. Mac docs do a reasonable job. It is similar for PPC Linux. http://developer.apple.com/documentation/DeveloperTools/ CompilersDebuggers-date.html > > > register 0 is 0 or general purpose? > > Stack is register ? > > I know that return address is in the link register. > > bl is branch and link -- call -- jump and save pc in link register. > > > > The code is: > > (gdb) disassemble > > Dump of assembler code for function Utils__WriteFile: > > 0x10024fbc : stwu r1,-720(r1) > > 0x10024fc0 : mflr r0 > > 0x10024fc4 : mfcr r12 > > 0x10024fc8 : stfd f14,576(r1) > > 0x10024fcc : stfd f15,584(r1) > > 0x10024fd0 : stfd f16,592(r1) > > 0x10024fd4 : stfd f17,600(r1) > > 0x10024fd8 : stfd f18,608(r1) > > 0x10024fdc : stfd f19,616(r1) > > 0x10024fe0 : stfd f20,624(r1) > > 0x10024fe4 : stfd f21,632(r1) > > 0x10024fe8 : stfd f22,640(r1) > > 0x10024fec : stfd f23,648(r1) > > 0x10024ff0 : stfd f24,656(r1) > > 0x10024ff4 : stfd f25,664(r1) > > 0x10024ff8 : stfd f26,672(r1) > > 0x10024ffc : stfd f27,680(r1) > > 0x10025000 : stfd f28,688(r1) > > 0x10025004 : stfd f29,696(r1) > > 0x10025008 : stfd f30,704(r1) > > 0x1002500c : stfd f31,712(r1) > > 0x10025010 : stw r14,504(r1) > > 0x10025014 : stw r15,508(r1) > > 0x10025018 : stw r16,512(r1) > > 0x1002501c : stw r17,516(r1) > > 0x10025020 : stw r18,520(r1) > > 0x10025024 : stw r19,524(r1) > > 0x10025028 : stw r20,528(r1) > > 0x1002502c : stw r21,532(r1) > > ---Type to continue, or q to quit--- > > 0x10025030 : stw r22,536(r1) > > 0x10025034 : stw r23,540(r1) > > 0x10025038 : stw r24,544(r1) > > 0x1002503c : stw r25,548(r1) > > 0x10025040 : stw r26,552(r1) > > 0x10025044 : stw r27,556(r1) > > 0x10025048 : stw r28,560(r1) > > 0x1002504c : stw r29,564(r1) > > 0x10025050 : stw r30,568(r1) > > 0x10025054 : stw r31,572(r1) > > 0x10025058 : stw r0,724(r1) > > 0x1002505c : stw r12,500(r1) > > 0x10025060 : mr r31,r1 > > 0x10025064 : bl 0x10025068 > > 0x10025068 : mflr r30 > > 0x1002506c : lwz r0,-176(r30) > > 0x10025070 : add r30,r0,r30 > > 0x10025074 : stw r3,8(r31) > > 0x10025078 : stw r4,12(r31) > > 0x1002507c : mr r0,r5 > > 0x10025080 : stb r0,16(r31) > > 0x10025084 : li r0,0 > > 0x10025088 : stw r0,20(r31) > > 0x1002508c : lbz r0,16(r31) > > 0x10025090 : clrlwi r0,r0,24 > > 0x10025094 : cmpwi r0,0 > > 0x10025098 : beq- 0x100250b8 > > 0x1002509c : lwz r3,8(r31) > > 0x100250a0 : li r4,1 > > 0x100250a4 : bl 0x100248a4 > > ---Type to continue, or q to quit--- > > 0x100250a8 : stw r3,476(r31) > > 0x100250ac : lwz r9,476(r31) > > 0x100250b0 : stw r9,20(r31) > > 0x100250b4 : b 0x100250d0 > > 0x100250b8 : lwz r3,8(r31) > > 0x100250bc : li r4,1 > > 0x100250c0 : bl 0x10024658 > > 0x100250c4 : stw r3,476(r31) > > 0x100250c8 : lwz r9,476(r31) > > 0x100250cc : stw r9,20(r31) > > > > ** here I believe ** > > > > 0x100250d0 : lwz r0,-32760(r30) > > 0x100250d4 : stw r0,32(r31) > > 0x100250d8 : addi r0,r31,8 > > 0x100250dc : stw r0,36(r31) > > 0x100250e0 : li r0,3 > > 0x100250e4 : stw r0,28(r31) > > 0x100250e8 : lwz r9,-32764(r30) > > 0x100250ec : lwz r0,0(r9) > > 0x100250f0 : stw r0,24(r31) > > 0x100250f4 : lwz r9,-32764(r30) > > 0x100250f8 : addi r0,r31,24 > > 0x100250fc : stw r0,0(r9) > > 0x10025100 : lwz r9,-32768(r30) > > 0x10025104 : addi r0,r9,76 > > 0x10025108 : stw r0,64(r31) > > 0x1002510c : li r0,0 > > 0x10025110 : stw r0,60(r31) > > 0x10025114 : lwz r9,-32764(r30) > > 0x10025118 : lwz r0,0(r9) > > 0x1002511c : stw r0,56(r31) > > ---Type to continue, or q to quit--- > > 0x10025120 : lwz r9,-32764(r30) > > 0x10025124 : addi r0,r31,56 > > 0x10025128 : stw r0,0(r9) > > 0x1002512c : addi r9,r31,56 > > 0x10025130 : addi r0,r9,48 > > 0x10025134 : mr r3,r0 > > 0x10025138 : bl 0x101bbf28 > > 0x1002513c : mr r0,r3 > > 0x10025140 : cmpwi r0,0 > > 0x10025144 : bne- 0x100251ac > > 0x10025148 : lwz r9,12(r31) > > 0x1002514c : stw r9,476(r31) > > 0x10025150 : lwz r9,476(r31) > > 0x10025154 : cmpwi r9,0 > > 0x10025158 : beq- 0x10025188 > > 0x1002515c : lwz r9,476(r31) > > 0x10025160 : lwz r0,0(r9) > > 0x10025164 : li r9,-1 > > 0x10025168 : cmpw r0,r9 > > 0x1002516c : bne- 0x10025188 > > 0x10025170 : lwz r9,476(r31) > > 0x10025174 : lwz r9,8(r9) > > 0x10025178 : stw r9,480(r31) > > 0x1002517c : lwz r9,476(r31) > > 0x10025180 : lwz r9,4(r9) > > 0x10025184 : stw r9,476(r31) > > 0x10025188 : lwz r11,480(r31) > > 0x1002518c : lwz r3,20(r31) > > 0x10025190 : lwz r0,476(r31) > > 0x10025194 : mtlr r0 > > ---Type to continue, or q to quit--- > > 0x10025198 : blrl > > 0x1002519c : lwz r9,-32764(r30) > > 0x100251a0 : lwz r0,56(r31) > > 0x100251a4 : stw r0,0(r9) > > 0x100251a8 : b 0x10025210 > > 0x100251ac : lwz r9,68(r31) > > 0x100251b0 : lwz r9,0(r9) > > 0x100251b4 : lis r0,-15535 > > 0x100251b8 : ori r0,r0,42454 > > 0x100251bc : cmpw r9,r0 > > 0x100251c0 : bne- 0x100251f0 > > 0x100251c4 : lwz r0,72(r31) > > 0x100251c8 : stw r0,472(r31) > > 0x100251cc : lwz r9,-32768(r30) > > 0x100251d0 : addi r0,r9,180 > > 0x100251d4 : lwz r3,472(r31) > > 0x100251d8 : mr r4,r0 > > 0x100251dc : lwz r5,8(r31) > > 0x100251e0 : li r6,0 > > 0x100251e4 : li r7,0 > > 0x100251e8 : bl 0x10023b4c > > 0x100251ec : b 0x10025210 > > 0x100251f0 : lwz r9,-32768(r30) > > 0x100251f4 : addi r0,r9,212 > > 0x100251f8 : li r3,0 > > 0x100251fc : mr r4,r0 > > 0x10025200 : lwz r5,8(r31) > > 0x10025204 : li r6,0 > > 0x10025208 : li r7,0 > > 0x1002520c : bl 0x10023b4c > > ---Type to continue, or q to quit--- > > 0x10025210 : lwz r9,-32764(r30) > > 0x10025214 : lwz r0,24(r31) > > 0x10025218 : stw r0,0(r9) > > 0x1002521c : addi r11,r31,8 > > 0x10025220 : bl 0x10024f74 > > 0x10025224 : lwz r11,0(r1) > > 0x10025228 : lwz r0,4(r11) > > 0x1002522c : lwz r12,-220(r11) > > 0x10025230 : mtlr r0 > > 0x10025234 : lwz r14,-216(r11) > > 0x10025238 : lwz r15,-212(r11) > > 0x1002523c : lwz r16,-208(r11) > > 0x10025240 : lwz r17,-204(r11) > > 0x10025244 : lwz r18,-200(r11) > > 0x10025248 : lwz r19,-196(r11) > > 0x1002524c : lwz r20,-192(r11) > > 0x10025250 : lwz r21,-188(r11) > > 0x10025254 : lwz r22,-184(r11) > > 0x10025258 : lwz r23,-180(r11) > > 0x1002525c : lwz r24,-176(r11) > > 0x10025260 : lwz r25,-172(r11) > > 0x10025264 : lwz r26,-168(r11) > > 0x10025268 : lwz r27,-164(r11) > > 0x1002526c : lwz r28,-160(r11) > > 0x10025270 : lwz r29,-156(r11) > > 0x10025274 : lwz r30,-152(r11) > > 0x10025278 : lwz r31,-148(r11) > > 0x1002527c : lfd f14,-144(r11) > > 0x10025280 : lfd f15,-136(r11) > > 0x10025284 : lfd f16,-128(r11) > > ---Type to continue, or q to quit--- > > 0x10025288 : lfd f17,-120(r11) > > 0x1002528c : lfd f18,-112(r11) > > 0x10025290 : lfd f19,-104(r11) > > 0x10025294 : lfd f20,-96(r11) > > 0x10025298 : lfd f21,-88(r11) > > 0x1002529c : lfd f22,-80(r11) > > 0x100252a0 : lfd f23,-72(r11) > > 0x100252a4 : lfd f24,-64(r11) > > 0x100252a8 : lfd f25,-56(r11) > > 0x100252ac : lfd f26,-48(r11) > > 0x100252b0 : lfd f27,-40(r11) > > 0x100252b4 : lfd f28,-32(r11) > > 0x100252b8 : lfd f29,-24(r11) > > 0x100252bc : lfd f30,-16(r11) > > 0x100252c0 : lfd f31,-8(r11) > > 0x100252c4 : mtcrf 56,r12 > > 0x100252c8 : mr r1,r11 > > 0x100252cc : blr > > 0x100252d0 : .long 0x24ebb0 > > End of assembler dump. > > > > > > (gdb) bt > > #0 Utils__WriteFile (M3_Bd56fi_file=0x10277ba0, > M3_DmuccK_proc=0x7fb22210, > > M3_AicXUJ_append=0 '\0') at Utils.m3:78 > > #1 0x10020a10 in Makefile__Build (M3_Bd56fi_src_dir=0x102720ec) > > at Makefile.m3:101 > > #2 0x100292d4 in Main__DoIt () at Main.m3:71 > > #3 0x10029834 in Main_M3 (M3_AcxOUs_mode=1) at Main.m3:193 > > #4 0x10188f9c in RTLinker__RunMainBody (M3_DUuepq_m=0x10279b28) > > at RTLinker.m3:387 > > #5 0x101880bc in RTLinker__AddUnitI (M3_DUuepq_m=0x10279b28) at > RTLinker.m3:100 > > #6 0x10188198 in RTLinker__AddUnit (M3_DUuepw_b=0x100297f8) at > RTLinker.m3:110 > > #7 0x100002ec in main (argc=1, argv=0x7fb22834, envp=0x7fb2283c) > at _m3main.mc:4 > > > > I haven't yet figured out how to get gdb to show me the details > of the SEGV, like what address was referenced. > > > > I swear I think this was working better recently. > > > > Oh, I did change something. I will try to change it back. > > I added -fPIC. > > Dynamic linking was not working and I thought that might fix it. > > I'll definitely try without it now. > > > > Also, relevant aside -- what, if any, distributions/versions of > Linux are people using on PowerPC? > > Specifically on PowerPC (to limit the religious explosion) > > I'm currently using Yellow Dog, I think 4.1, but only for > Modula-3 purposes, not for anything else. > > > > ps: I'd like a SMALL forum of SMART programmers, to discuss > GENERAL programming topics. > > This is it perhaps? > > > > - Jay > > _________________________________________________________________ > > Watch ?Cause Effect,? a show about real people making a real > difference. > > http://im.live.com/Messenger/IM/MTV/?source=text_watchcause > > Make distant family not so distant with Windows Vista? + Windows > Live?. Start now! From hosking at cs.purdue.edu Thu Jan 10 19:30:55 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 10 Jan 2008 13:30:55 -0500 Subject: [M3devel] nt386gnu is posix or win32? In-Reply-To: References: <20080107073815.DBCDD10D45C8@birch.elegosoft.com> <4F88D761-5F3F-4891-B3BD-7490FC7E7A2A@cs.purdue.edu> Message-ID: On Jan 9, 2008, at 6:08 PM, Jay wrote: > I'm going to be rude and just throw this out there at a time when I > probably can't discuss it or yet have enough data/diffs to matter. > > However, in building NT386GNU -- I can build libm3 and m3core -- > the question arises as to if this target is "win32" or "posix'. > Currently in the tree it is setup to be "posix", with a fair amount > of work already done in that direction -- in particular, the Unix > interfaces. > > However, I think this target is potentially an odd beast. > Potentially it is two targets. > I guess this mimics cygwin vs. mingwin. Exactly. > > The "host" is gcc. In order to build this system, one needs > "gmake", sh, gcc probably (I'm assuming Visual C++'s compiler/ > linker cannot build m3cg, but very maybe..). > > In order to build anything with this system, one needs "as", and > most likely ld. > (I quote "as" because it is an English word and confusing to read > otherwise.) > Changing it to output assembly for masm or even Visual C++'s inline > __asm is probably actually viable, but not a tiny short term task. > (Or maybe writing an as clone that outputs .objs? Maybe using nasm/ > yasm??? Not sure the point, maybe "as" is perfectly ok.) > > And then the question arises as to what it takes to run the output. > As I've said in other topics, the C runtime dependency of Modula-3 > is light -- startup code mainly, but, yeah, also important setjmp/ > longjmp, and multiplication/division helpers sometimes. This could > perhaps all be statically linked. Certainly for Visual C++ it can be. > (NOTE: The Cygwin jmp_buf is much larger than Visual C++'s. A > THOUGHT is to grow them to the same, for object code compatibility, > but probably not useful, and very wasteful, Cygwin's is much > larger, the data in the existing code I verified is correct, like > 0x40 vs. 0xD0 I think it was, I just did printf("%x", sizeof > (jmp_buf)).) > > To get m3core to build, I switched NT386GNU to use Win32 threads. > For THAT to build, I switched OSTYPE to Win32. Overkill perhaps, in > order to get the Win32 *.i3 files. > Overkill perhaps, but it does build. > > I fully suspect that old style Posix threads can work easily, and > that pthreads can work easily, increasing the dependency on > cygwin1.dll. User-level (ThreadPosix) threads might work (using setjmp/longjmp for thread switching -- I guess that is what PM3 used to do). Or did it use ThreadWin32? I doubt ThreadPThread will work since I don't think there is a pthreads binding for Win32 threads on NT, or is there? > While this is the "other" direction, given the dependency on as, > and gcc to build m3cg, probably the horse is out of the barn. > This is arguably a simpler answer, less hybrid. My strong preference is to tread NT386GNU (i.e., Cygwin based) as a POSIX target, which might happen to use ThreadWin32. That way, the usual POSIX/Cygwin flavor of things is preserved. > > > I think the analogy to cygwin/mingwin holds, possibly perfectly. > > Maybe this is two targets. > NT386CYGWIN ? > NT386MINGWIN ? > > (Which begs the point -- target naming.... NT386 vs. PPC_LINUX...OS > +ARCH vs. ARCH + _ + OS, etc... but ARCH and OS aren't it, there is > toolchain and C runtime in the mix..) > > Obviously SOMETHING is better than NOTHING and I have no useful > binary distribution yet to show, so these questions are all very > premature. > > I'm also unsure as to the "seriousness" of using the GNU tools. > a) There don't seem to be many users of Modula-3 on Win32. > b) Will such users accept/trust a non Microsoft toolchain? > (Just what to do folks do with cygwin/mingwin? Build/ship real > software?) > > From my point of view, the attractive thing about m3cg is I get the > int64 stuff arguably out of the way easier. :) > > Licensing wise..probably a dependency on cygwin1.dll is not desirable. > > When I'm further along, er, actually, with my existing libm3.dll/ > m3core.dll, I can see what the dependencies are. > If it's just setjmp/lonjmp/memset, maybe try static linking (what > is the licensing of that?) or link to msvcr*.dll. > > Maybe see if I can configure to use mingwin to compile/link except > for m3cc. That sounds excellent. > You would configure a CYGWIN_ROOT (gcc, ld, make, sh, libs) and a > MINGWIN_ROOT (gcc, ld, libs). CYGWIN_ROOT would be required for > building m3cc, and either could be used for building anything > else. ?? That seems good, though I just thought of it, need more > time to think and investigate. > > Later.. > - Jay > > > Share life as it happens with the new Windows Live. Start sharing! From hosking at cs.purdue.edu Thu Jan 10 19:32:04 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 10 Jan 2008 13:32:04 -0500 Subject: [M3devel] nt386gnu is posix or win32? In-Reply-To: <20080110010238.GA3891@topoi.pooq.com> References: <20080107073815.DBCDD10D45C8@birch.elegosoft.com> <4F88D761-5F3F-4891-B3BD-7490FC7E7A2A@cs.purdue.edu> <20080110010238.GA3891@topoi.pooq.com> Message-ID: This echoes my desire that NT386GNU/Cygwin rely mostly on the POSIX personality of Cygwin, though threading might use win32.dll. On Jan 9, 2008, at 8:02 PM, hendrik at topoi.pooq.com wrote: > On Wed, Jan 09, 2008 at 11:08:57PM +0000, Jay wrote: >> I'm going to be rude and just throw this out there at a time when >> I probably can't discuss it or yet have enough data/diffs to matter. >> >> However, in building NT386GNU -- I can build libm3 and m3core -- >> the question arises as to if this target is "win32" or "posix'. >> Currently in the tree it is setup to be "posix", with a fair >> amount of work already done in that direction -- in particular, >> the Unix interfaces. >> >> However, I think this target is potentially an odd beast. >> Potentially it is two targets. >> I guess this mimics cygwin vs. mingwin. Exactly. >> >> The "host" is gcc. In order to build this system, one needs >> "gmake", sh, gcc probably (I'm assuming Visual C++'s compiler/ >> linker cannot build m3cg, but very maybe..). >> >> In order to build anything with this system, one needs "as", and >> most likely ld. >> (I quote "as" because it is an English word and confusing to >> read otherwise.) >> Changing it to output assembly for masm or even Visual C++'s >> inline __asm is probably actually viable, but not a tiny short >> term task. >> (Or maybe writing an as clone that outputs .objs? Maybe using nasm/ >> yasm??? Not sure the point, maybe "as" is perfectly ok.) >> >> And then the question arises as to what it takes to run the output. >> As I've said in other topics, the C runtime dependency of Modula-3 >> is light -- startup code mainly, but, yeah, also important setjmp/ >> longjmp, and multiplication/division helpers sometimes. This could >> perhaps all be statically linked. Certainly for Visual C++ it can be. >> (NOTE: The Cygwin jmp_buf is much larger than Visual C++'s. A >> THOUGHT is to grow them to the same, for object code >> compatibility, but probably not useful, and very wasteful, >> Cygwin's is much larger, the data in the existing code I verified >> is correct, like 0x40 vs. 0xD0 I think it was, I just did printf("% >> x", sizeof(jmp_buf)).) >> >> To get m3core to build, I switched NT386GNU to use Win32 threads. >> For THAT to build, I switched OSTYPE to Win32. Overkill perhaps, >> in order to get the Win32 *.i3 files. >> Overkill perhaps, but it does build. >> >> I fully suspect that old style Posix threads can work easily, and >> that pthreads can work easily, increasing the dependency on >> cygwin1.dll. >> While this is the "other" direction, given the dependency on as, >> and gcc to build m3cg, probably the horse is out of the barn. >> This is arguably a simpler answer, less hybrid. >> >> I think the analogy to cygwin/mingwin holds, possibly perfectly. >> >> Maybe this is two targets. >> NT386CYGWIN ? >> NT386MINGWIN ? >> >> (Which begs the point -- target naming.... NT386 vs. PPC_LINUX...OS >> +ARCH vs. ARCH + _ + OS, etc... but ARCH and OS aren't it, there >> is toolchain and C runtime in the mix..) >> >> Obviously SOMETHING is better than NOTHING and I have no useful >> binary distribution yet to show, so these questions are all very >> premature. >> >> I'm also unsure as to the "seriousness" of using the GNU tools. >> a) There don't seem to be many users of Modula-3 on Win32. >> b) Will such users accept/trust a non Microsoft toolchain? >> (Just what to do folks do with cygwin/mingwin? Build/ship real >> software?) > > One of my reasons for using m3 long ago was that I could write > programs > that would run on both Linux and Windows *without* using the Microsoft > tools, which I did not possess. > > -- hendrik From jayk123 at hotmail.com Thu Jan 10 20:48:15 2008 From: jayk123 at hotmail.com (Jay) Date: Thu, 10 Jan 2008 19:48:15 +0000 Subject: [M3devel] could someone add __stdcall name mangling to m3cc please? In-Reply-To: <70EC0898-EE63-4C19-8C28-EC72E2B73B31@cs.purdue.edu> References: Your message of "Wed, 09 Jan 2008 17:25:31 PST." <200801100131.m0A1VQYS034516@camembert.async.caltech.edu> <70EC0898-EE63-4C19-8C28-EC72E2B73B31@cs.purdue.edu> Message-ID: > CC: m3devel at elegosoft.com > From: hosking at cs.purdue.edu > > Do we have a version of the gcc-based backend that *ever* supported > the calling conventions? I don't know, but I theorize no. - Jay _________________________________________________________________ Share life as it happens with the new Windows Live. http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Thu Jan 10 20:55:15 2008 From: jayk123 at hotmail.com (Jay) Date: Thu, 10 Jan 2008 19:55:15 +0000 Subject: [M3devel] could someone add __stdcall name mangling to m3cc please? In-Reply-To: <6D677FCA-D704-4E84-BD58-893C71D97B59@cs.purdue.edu> References: Your message of "Wed, 09 Jan 2008 17:25:31 PST." <200801100131.m0A1VQYS034516@camembert.async.caltech.edu> <6D677FCA-D704-4E84-BD58-893C71D97B59@cs.purdue.edu> Message-ID: > CC: m3devel at elegosoft.com > From: hosking at cs.purdue.edu > > On Jan 10, 2008, at 7:42 AM, Jay wrote: > > > PM3 appears to ignore call_conv. > > Perhaps its NT386GNU uses usermode threads via cygwin1.dll and has > > no gui support, such as to not import any __stdcall functions??? > > Probably, yes. CM3 were the ones who added gui support. Anyway, I > think it is simply a matter of adding the appropriate attribute to > the function decls in the gcc backend. I believe that it supports > cdecl and stdcall. Are these all we need to specify? Digital added GUI support, but that doesn't necessary matter. PM3 might have dropped or broken it -- well, at least the NT386GNU target, not NT386. Good point, attributes, not name. __cdecl and __stdcall will suffice, yes. There is __fastcall but the M3 front end doesn't support it. The M3 front end only supports __cdecl and __stdcall, and various synonyms thereof, but it just resolves to 0 and 1, I think 0 is __cdecl. Look for "NTCall" in the source, or "stdcall" on the front end. It's pretty clear. If I knew how to easily "build things properly" "but get a preprocessed file", that is, add -E to the proper place, I would have preprocessed parse.c to get an idea how to...well...add the stuff to the name, which isn't the right fix anyway. As two where the char* or char[] is is buried in macros.. (e.g. CodeWarrior implements this well, right click a file and say "preprocess" or "disassemble") - Jay _________________________________________________________________ Put your friends on the big screen with Windows Vista? + Windows Live?. http://www.microsoft.com/windows/shop/specialoffers.mspx?ocid=TXT_TAGLM_CPC_MediaCtr_bigscreen_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney.bates at wichita.edu Thu Jan 10 22:39:57 2008 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Thu, 10 Jan 2008 15:39:57 -0600 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <20080108011658.dp4d4zumw4wwkg88@mail.elegosoft.com> References: <20080107073815.DBCDD10D45C8@birch.elegosoft.com> <4F88D761-5F3F-4891-B3BD-7490FC7E7A2A@cs.purdue.edu> <20080108011658.dp4d4zumw4wwkg88@mail.elegosoft.com> Message-ID: <478690AD.5000104@wichita.edu> My practice is to let the actual expression do the explaining to the reader, if it can do that, otherwise, give the formal name in a keyword binding. For example, if the actual is a (boolean-typed) variable named "IsEmpty", that alone probably suggests what the meaning of the parameter is. OTOH, if the actual is "TRUE", then I would code "IsEmpty := TRUE". > Quoting Jay : > >> Style tangent: Have people heard the advise that boolean parameters >> are bad, because at the callsite esp. they don't give much meaning? >> What is TRUE? What is FALSE? Enums or named parameters are clearer. > > -- ------------------------------------------------------------- Rodney 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 Thu Jan 10 22:31:16 2008 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Thu, 10 Jan 2008 15:31:16 -0600 Subject: [M3devel] M3 concerns In-Reply-To: <20080105011335.n767h3zbz4gcgk4k@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> Message-ID: <47868EA4.6090407@wichita.edu> I have been inside pickles a few times, so I might be the logical person to do this. All the infrastructure is there to convert integer sizes, but I expect detection of the fingerprint for LONGINT and determining its size will need a bit of work. Olaf Wagner wrote: > I know that it should run this way, but pickles for example wouldn't > be exchangeable then, would they? Has anybody tested pickle support > for LONGINT yet? > -- ------------------------------------------------------------- Rodney 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 Thu Jan 10 22:58:36 2008 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Thu, 10 Jan 2008 15:58:36 -0600 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <20080107192048.3FFBB10D461D@birch.elegosoft.com> References: <20080107192048.3FFBB10D461D@birch.elegosoft.com> Message-ID: <4786950C.6020502@wichita.edu> Antony, I can' tell from your posts whether this is what you did or not, but: m3gdb really needs for there to be a static link allocated space and stored, for _every_ nested procedure, even if there is nothing in the compiled code that uses it. m3gdb accesses/passes static links in several situations, e.g., a user-typed call on a nested procedure constant, user-typed assignment of a nested procedure value to a procedure variable, user-typed call on a procedure variable (whose value might be nested or top-level), and just access to a variable that is nonlocal to the current frame. All of this has been implemented for some time, although it is distressingly fragile. I have a number of times gone back in and fixed some case I thought I had working earlier. I recently started seeing "invalid static link" messages again from m3gdb, after a hiatus. The variable access function is particularly important to me, as I often use nested procedures, especially a recursive nested procedure inside a parent that holds variables that are local to the whole recursive (dynamic) nest but not fully global. Especially when the recursion is umpteen levels deep, it is a real pain to have to figure out how many levels to go "up" in the dynamic chain just to get to the immediate static parent to print one of its variables. And if you want to type a expression that mixes a local and a nonlocal variable, the feature is almost essential. So, I propose static links be there always, with the possible exception of at very high optimization levels. Antony Hosking wrote: > CVSROOT: /usr/cvs > Changes by: hosking at birch. 08/01/07 20:20:48 > > Modified files: > cm3/m3-sys/m3cc/gcc/gcc/: tree-nested.c > cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c > > Log message: > Fix bug in procedure value comparison as revealed by p035 of m3tests. > The problem was that convert_all_function_calls was marking nested function > decls as *not* needing a static chain (DECL_NO_STATIC_CHAIN) when their bodies > and other nested procedures within them did not refer to any of their > variables. In Modula-3 we still need the static chain (ie, procedure > environment) for procedure values so that they can be compared (tested > for equality) properly. See the M3 language specification for details of > procedure types, which define a procedure as a triple, including its > environment. The fix makes use of DECL_NONLOCAL on function decls to mark > them as needing the static chain to be preserved whenever a STATIC_CHAIN_EXPR > is created for the decl. > > -- ------------------------------------------------------------- Rodney 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 Jan 11 02:39:33 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 10 Jan 2008 20:39:33 -0500 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <4786950C.6020502@wichita.edu> References: <20080107192048.3FFBB10D461D@birch.elegosoft.com> <4786950C.6020502@wichita.edu> Message-ID: <79F0BFF3-15DB-48BF-A7D4-B5C6CEA3FF7A@cs.purdue.edu> This is easy enough to fix. I'll get to it tomorrow. On Jan 10, 2008, at 4:58 PM, Rodney M. Bates wrote: > Antony, I can' tell from your posts whether this is what you did or > not, but: > > m3gdb really needs for there to be a static link allocated space > and stored, for > _every_ nested procedure, even if there is nothing in the compiled > code that uses > it. m3gdb accesses/passes static links in several situations, > e.g., a user-typed > call on a nested procedure constant, user-typed assignment of a > nested procedure > value to a procedure variable, user-typed call on a procedure > variable (whose > value might be nested or top-level), and just access to a variable > that is nonlocal > to the current frame. > > All of this has been implemented for some time, although it is > distressingly > fragile. I have a number of times gone back in and fixed some case > I thought > I had working earlier. I recently started seeing "invalid static > link" messages > again from m3gdb, after a hiatus. > > The variable access function is particularly important to me, as I > often use nested > procedures, especially a recursive nested procedure inside a parent > that holds variables > that are local to the whole recursive (dynamic) nest but not fully > global. Especially when > the recursion is umpteen levels deep, it is a real pain to have to > figure out how > many levels to go "up" in the dynamic chain just to get to the > immediate static parent > to print one of its variables. And if you want to type a expression > that mixes a local > and a nonlocal variable, the feature is almost essential. > > So, I propose static links be there always, with the possible > exception of at very > high optimization levels. > > > > Antony Hosking wrote: >> CVSROOT: /usr/cvs >> Changes by: hosking at birch. 08/01/07 20:20:48 >> Modified files: >> cm3/m3-sys/m3cc/gcc/gcc/: tree-nested.c cm3/m3-sys/m3cc/gcc/gcc/ >> m3cg/: parse.c Log message: >> Fix bug in procedure value comparison as revealed by p035 of >> m3tests. >> The problem was that convert_all_function_calls was marking >> nested function >> decls as *not* needing a static chain (DECL_NO_STATIC_CHAIN) when >> their bodies >> and other nested procedures within them did not refer to any of >> their >> variables. In Modula-3 we still need the static chain (ie, >> procedure >> environment) for procedure values so that they can be compared >> (tested >> for equality) properly. See the M3 language specification for >> details of >> procedure types, which define a procedure as a triple, including its >> environment. The fix makes use of DECL_NONLOCAL on function >> decls to mark >> them as needing the static chain to be preserved whenever a >> STATIC_CHAIN_EXPR >> is created for the decl. > > -- > ------------------------------------------------------------- > Rodney 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 Jan 11 08:36:20 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 11 Jan 2008 08:36:20 +0100 Subject: [M3devel] CVS repo changed, was: Re: scripts/pkgs In-Reply-To: References: Message-ID: <20080111083620.zxhq9ylw08ogw0oc@mail.elegosoft.com> Quoting Jay : > Please do "something" about this directory I created. > Like very much delete/obliterate it. If the history can be renamed > to another directory, say, pkginfo maybe, ok. > The files are all deleted but might be worth bringing back at some > point, maybe. > > On a case insensitive file system, this directory conflicts with the > PKGS file. > This was totally my fault and stupid. I was thinking "PKGS" was > named "PKGSDB", but that's just the variable name, and I should have > checked. I've moved cm3/scripts/pkgs to cm3/scripts/pkgs-obsolete on birch. This will break existing workspaces which contain it; you'll have to remove and update it, or edit CVS/Entries. If you use -P for checkout and update, empty directories will be removed on-the-fly. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Fri Jan 11 09:18:23 2008 From: mika at async.caltech.edu (Mika Nystrom) Date: Fri, 11 Jan 2008 00:18:23 -0800 Subject: [M3devel] nt386gnu is posix or win32? In-Reply-To: Your message of "Thu, 10 Jan 2008 08:35:05 PST." <6A267174-E215-48A6-BD0D-CB9AF4C13FE5@darko.org> Message-ID: <200801110818.m0B8IN44005691@camembert.async.caltech.edu> That program I talked about that I build under PM3/Klagenfurt, NT386GNU, is a multi-threaded real-time financial application that, at times, trades over a million dollars an hour's worth of stocks. It doesn't run on Windows for any technical reason. If it were completely up to me, it wouldn't. But I am still glad that Modula-3 works on Windows. Mika Darko writes: > >On 10/01/2008, at 3:16 AM, Jay wrote: >> By "serious" I mean, "ship real software using it". > >Then the question is: what is' real' software. I've shipped commercial >software (a smallish application) using the existing native back end, >which doesn't produce very good code, but the performance was >adequate. For many other applications this won't be the case. > >You should look at this issue the other way around: If it allows >people to build 'serious' software, they will use it. If you have an >interest in Windows and M3, this would be one of the most useful >things you could do, IMHO. > >Darko. From mika at async.caltech.edu Fri Jan 11 09:23:42 2008 From: mika at async.caltech.edu (Mika Nystrom) Date: Fri, 11 Jan 2008 00:23:42 -0800 Subject: [M3devel] could someone add __stdcall name mangling to m3cc please? In-Reply-To: Your message of "Thu, 10 Jan 2008 12:52:35 EST." <6D677FCA-D704-4E84-BD58-893C71D97B59@cs.purdue.edu> Message-ID: <200801110823.m0B8NgIn005977@camembert.async.caltech.edu> Hmm my Klagenfurt distribution of PM3 has a bunch of Trestle things in it. mentor even works sometimes. But I am not sure exactly when it came out or what kinds of tricks they were doing in the backend. One can track it down by following the link in an email I sent yesterday or the day before, but it's a binary distribution. Mika Tony Hosking writes: > >On Jan 10, 2008, at 7:42 AM, Jay wrote: > >> PM3 appears to ignore call_conv. >> Perhaps its NT386GNU uses usermode threads via cygwin1.dll and has >> no gui support, such as to not import any __stdcall functions??? > >Probably, yes. CM3 were the ones who added gui support. Anyway, I >think it is simply a matter of adding the appropriate attribute to >the function decls in the gcc backend. I believe that it supports >cdecl and stdcall. Are these all we need to specify? > >> http://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/m3/pm3/language/ >> modula3/m3compiler/m3cc/gcc/gcc/m3cg/m3.c?rev=1.1;content-type=text% >> 2Fx-cvsweb-markup;cvsroot=PM3 >> >> - Jay >> >> From: jayk123 at hotmail.com >> To: m3devel at elegosoft.com >> Date: Thu, 10 Jan 2008 12:40:22 +0000 >> Subject: [M3devel] could someone add __stdcall name mangling to >> m3cc please? >> >> Could someone out there (Tony?) familiar with the gcc backend >> have it not ignore call_conv and if call_conv is 1, append >> an at symbol and the number of bytes of parameters to the function >> name? >> (Even for zero, e.g. Sleep at 0, GetFileAttributes at 4). >> This would be I guess at least for "imported" functions. >> >> Not clear about calling function pointers, probably needs >> modification. >> call_conv 0 is "__cdecl" is push right to left, caller cleans up >> call_conv 1 is "__stdcall" is push right to left, callee cleans up >> There are various synonyms. >> With no command line switches, __cdecl is the compiler default. >> __stdcall is deemed more efficient, and is very widely used. >> >> Not clear about functions implemented in Modula-3. >> Probably won't occur? Maybe for callbacks? WindowProcs, thread >> entry point? >> >> This could/should be for NT386GNU only. >> The hypothetical other NT targets only have one calling convention >> each. >> >> I COULD do something sleazy here and generate little adapter >> functions, over in m3-win/import-libs esp. >> >> I'm still checking out pm3 to see what it does here. >> (as in cvs checkout, not "looking at") >> >> This'll clear up: >> >> RTOS.m3:27: undefined reference to `_FatalExit' >> RTOS.mo: In function `RTOS__GetMemory': >> RTOS.m3:75: undefined reference to `_VirtualAlloc' >> RTOS.m3:85: undefined reference to `_VirtualAlloc' >> RTOS.mo: In function `RTOS__InitMemory': >> RTOS.m3:96: undefined reference to `_VirtualAlloc' >> RTOS.m3:100: undefined reference to `_GetSystemInfo' >> RTOS.mo: In function `RTOS__Write': >> RTOS.m3:118: undefined reference to `_AllocConsole' >> RTOS.m3:119: undefined reference to `_GetStdHandle' >> RTOS.m3:122: undefined reference to `_WriteFile' >> RTPerfTool.mo: In function `RTPerfTool__Start': >> RTPerfTool.m3:19: undefined reference to `_ReadFile' >> RTPerfTool.m3:22: undefined reference to `_CloseHandle' >> RTPerfTool.mo: In function `RTPerfTool__Close': >> RTPerfTool.m3:28: undefined reference to `_CloseHandle' >> RTPerfTool.mo: In function `RTPerfTool__Send': >> RTPerfTool.m3:34: undefined reference to `_WriteFile' >> RTPerfTool.mo: In function `RTPerfTool__PrepHandle': >> RTPerfTool.m3:58: undefined reference to `_GetCurrentProcess' >> RTPerfTool.m3:59: undefined reference to `_DuplicateHandle' >> etc. >> >> I did think I was past these. I thought I built m3core and libm3 >> including linking (having even modified cm3.cfg) >> COULD be I'm using the wrong .libs, but: >> >> C:\cygwin\lib\w32api>nm libkernel32.a | findstr CreateFile >> 00000000 I __imp__CreateFileW at 28 >> 00000000 T _CreateFileW at 28 >> 00000000 I __imp__CreateFileMappingW at 24 >> 00000000 T _CreateFileMappingW at 24 >> 00000000 I __imp__CreateFileMappingA at 24 >> 00000000 T _CreateFileMappingA at 24 >> 00000000 I __imp__CreateFileA at 28 >> 00000000 T _CreateFileA at 28 >> >> C:\cygwin\lib\w32api>cd \MinGW\lib >> >> C:\MinGW\lib>nm libkernel32.a | findstr CreateFile >> 00000000 I __imp__CreateFileW at 28 >> 00000000 T _CreateFileW at 28 >> 00000000 I __imp__CreateFileMappingW at 24 >> 00000000 T _CreateFileMappingW at 24 >> 00000000 I __imp__CreateFileMappingA at 24 >> 00000000 T _CreateFileMappingA at 24 >> 00000000 I __imp__CreateFileA at 28 >> 00000000 T _CreateFileA at 28 >> >> I think at least THREE calling conventions should be supported -- >> __cdecl, __stdcall, __fastcall -- >> but oh well. We can live without __fastcall. >> Watcom has another calling convention, "watcall", and they let you >> describe calling conventions with #pragmas, neat. >> >> Thanks, >> - Jay >> >> Share life as it happens with the new Windows Live. Start sharing! >> Get the power of Windows + Web with the new Windows Live. Get it now! From mika at async.caltech.edu Fri Jan 11 09:25:22 2008 From: mika at async.caltech.edu (Mika Nystrom) Date: Fri, 11 Jan 2008 00:25:22 -0800 Subject: [M3devel] nt386gnu is posix or win32? In-Reply-To: Your message of "Thu, 10 Jan 2008 13:30:55 EST." Message-ID: <200801110825.m0B8PMSW006110@camembert.async.caltech.edu> ThreadWin32, I think. That's supposed to be one of the benefits of using Modula-3 under Windows :-) Tony Hosking writes: > >On Jan 9, 2008, at 6:08 PM, Jay wrote: ... >> that pthreads can work easily, increasing the dependency on >> cygwin1.dll. > >User-level (ThreadPosix) threads might work (using setjmp/longjmp for >thread switching -- I guess that is what PM3 used to do). Or did it >use ThreadWin32? I doubt ThreadPThread will work since I don't >think there is a pthreads binding for Win32 threads on NT, or is there? > >> While this is the "other" direction, given the dependency on as, >> and gcc to build m3cg, probably the horse is out of the barn. >> This is arguably a simpler answer, less hybrid. > >My strong preference is to tread NT386GNU (i.e., Cygwin based) as a >POSIX target, which might happen to use ThreadWin32. That way, the >usual POSIX/Cygwin flavor of things is preserved. > >> >> >> I think the analogy to cygwin/mingwin holds, possibly perfectly. >> >> Maybe this is two targets. >> NT386CYGWIN ? >> NT386MINGWIN ? >> >> (Which begs the point -- target naming.... NT386 vs. PPC_LINUX...OS >> +ARCH vs. ARCH + _ + OS, etc... but ARCH and OS aren't it, there is >> toolchain and C runtime in the mix..) >> >> Obviously SOMETHING is better than NOTHING and I have no useful >> binary distribution yet to show, so these questions are all very >> premature. >> >> I'm also unsure as to the "seriousness" of using the GNU tools. >> a) There don't seem to be many users of Modula-3 on Win32. >> b) Will such users accept/trust a non Microsoft toolchain? >> (Just what to do folks do with cygwin/mingwin? Build/ship real >> software?) >> >> From my point of view, the attractive thing about m3cg is I get the >> int64 stuff arguably out of the way easier. :) >> >> Licensing wise..probably a dependency on cygwin1.dll is not desirable. >> >> When I'm further along, er, actually, with my existing libm3.dll/ >> m3core.dll, I can see what the dependencies are. >> If it's just setjmp/lonjmp/memset, maybe try static linking (what >> is the licensing of that?) or link to msvcr*.dll. >> >> Maybe see if I can configure to use mingwin to compile/link except >> for m3cc. That sounds excellent. >> You would configure a CYGWIN_ROOT (gcc, ld, make, sh, libs) and a >> MINGWIN_ROOT (gcc, ld, libs). CYGWIN_ROOT would be required for >> building m3cc, and either could be used for building anything >> else. ?? That seems good, though I just thought of it, need more >> time to think and investigate. >> >> Later.. >> - Jay >> >> >> Share life as it happens with the new Windows Live. Start sharing! From mika at async.caltech.edu Fri Jan 11 09:32:56 2008 From: mika at async.caltech.edu (Mika Nystrom) Date: Fri, 11 Jan 2008 00:32:56 -0800 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: Your message of "Thu, 10 Jan 2008 15:58:36 CST." <4786950C.6020502@wichita.edu> Message-ID: <200801110832.m0B8Wuwg006472@camembert.async.caltech.edu> This reminds me, there used to be a bug in PM3... has it been fixed? This code was unreliable: PROCEDURE P() = VAR a : T; PROCEDURE Q(b : U) = BEGIN a := saveSomethingAbout(b) END Q; BEGIN CallVisitor(Q) END P; (Note that the M3 report says that while inner procedures may not be assigned to variables, they may be passed as procedure parameters. The workaround for the compiler bug is to use something called "object-oriented programming".) "Rodney M. Bates" writes: >Antony, I can' tell from your posts whether this is what you did or not, but: > >m3gdb really needs for there to be a static link allocated space and stored, for >_every_ nested procedure, even if there is nothing in the compiled code that uses >it. m3gdb accesses/passes static links in several situations, e.g., a user-typed >call on a nested procedure constant, user-typed assignment of a nested procedure >value to a procedure variable, user-typed call on a procedure variable (whose >value might be nested or top-level), and just access to a variable that is nonlocal >to the current frame. > >All of this has been implemented for some time, although it is distressingly >fragile. I have a number of times gone back in and fixed some case I thought >I had working earlier. I recently started seeing "invalid static link" messages >again from m3gdb, after a hiatus. > >The variable access function is particularly important to me, as I often use nested >procedures, especially a recursive nested procedure inside a parent that holds variables >that are local to the whole recursive (dynamic) nest but not fully global. Especially when >the recursion is umpteen levels deep, it is a real pain to have to figure out how >many levels to go "up" in the dynamic chain just to get to the immediate static parent >to print one of its variables. And if you want to type a expression that mixes a local >and a nonlocal variable, the feature is almost essential. > >So, I propose static links be there always, with the possible exception of at very >high optimization levels. > > > >Antony Hosking wrote: >> CVSROOT: /usr/cvs >> Changes by: hosking at birch. 08/01/07 20:20:48 >> >> Modified files: >> cm3/m3-sys/m3cc/gcc/gcc/: tree-nested.c >> cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c >> >> Log message: >> Fix bug in procedure value comparison as revealed by p035 of m3tests. >> The problem was that convert_all_function_calls was marking nested function >> decls as *not* needing a static chain (DECL_NO_STATIC_CHAIN) when their bodies >> and other nested procedures within them did not refer to any of their >> variables. In Modula-3 we still need the static chain (ie, procedure >> environment) for procedure values so that they can be compared (tested >> for equality) properly. See the M3 language specification for details of >> procedure types, which define a procedure as a triple, including its >> environment. The fix makes use of DECL_NONLOCAL on function decls to mark >> them as needing the static chain to be preserved whenever a STATIC_CHAIN_EXPR >> is created for the decl. >> >> > >-- >------------------------------------------------------------- >Rodney 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 Jan 11 12:36:14 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 11 Jan 2008 12:36:14 +0100 Subject: [M3devel] M3 project references, was: Re: nt386gnu is posix or win32? In-Reply-To: <200801110818.m0B8IN44005691@camembert.async.caltech.edu> References: <200801110818.m0B8IN44005691@camembert.async.caltech.edu> Message-ID: <20080111123614.txul50nyqs80oowg@mail.elegosoft.com> Quoting Mika Nystrom : > That program I talked about that I build under PM3/Klagenfurt, > NT386GNU, is a multi-threaded real-time financial application that, > at times, trades over a million dollars an hour's worth of stocks. > It doesn't run on Windows for any technical reason. If it were > completely up to me, it wouldn't. But I am still glad that Modula-3 > works on Windows. Cool. I didn't know that M3 was really used in such commercial projects. It would be great if we had a list of such projects on our web site as references. Would that be possible with your program/customer? Are there other commercial projects we could mention? Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Fri Jan 11 13:32:24 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 11 Jan 2008 13:32:24 +0100 Subject: [M3devel] Darwin upgrade/fingerprint error In-Reply-To: References: <20080104141523.GC1459@ted.stsp.lan> <65C183A8-6102-49E9-9C38-8D59C966E42D@cs.purdue.edu> Message-ID: <20080111133224.kpsd1ehwso4go048@mail.elegosoft.com> Quoting Jay : > (probably OMIT_GCC=1 on the second clean and build; I assume it has > no dependency into the tree and it'd just be building the same thing > a second time, slowly) Late answer, but I can hardly catch up with all the mail I get. Even CM3 is so active these days (which is a good thing :). You are right, m3cc does not depend on any other CM3 package and needs to be built just once. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From hosking at cs.purdue.edu Fri Jan 11 16:17:00 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 11 Jan 2008 10:17:00 -0500 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <200801110832.m0B8Wuwg006472@camembert.async.caltech.edu> References: <200801110832.m0B8Wuwg006472@camembert.async.caltech.edu> Message-ID: <85B79C0A-B69E-4E12-B938-6A374398568D@cs.purdue.edu> Certainly fixed in CM3. On Jan 11, 2008, at 3:32 AM, Mika Nystrom wrote: > This reminds me, there used to be a bug in PM3... has it been > fixed? This code > was unreliable: > > PROCEDURE P() = > > VAR a : T; > > PROCEDURE Q(b : U) = > BEGIN a := saveSomethingAbout(b) END Q; > > BEGIN CallVisitor(Q) END P; > > (Note that the M3 report says that while inner procedures may not > be assigned to variables, they may be passed as procedure parameters. > The workaround for the compiler bug is to use something called > "object-oriented programming".) > > "Rodney M. Bates" writes: >> Antony, I can' tell from your posts whether this is what you did >> or not, but: >> >> m3gdb really needs for there to be a static link allocated space >> and stored, for >> _every_ nested procedure, even if there is nothing in the compiled >> code that uses >> it. m3gdb accesses/passes static links in several situations, >> e.g., a user-typed >> call on a nested procedure constant, user-typed assignment of a >> nested procedure >> value to a procedure variable, user-typed call on a procedure >> variable (whose >> value might be nested or top-level), and just access to a variable >> that is nonlocal >> to the current frame. >> >> All of this has been implemented for some time, although it is >> distressingly >> fragile. I have a number of times gone back in and fixed some >> case I thought >> I had working earlier. I recently started seeing "invalid static >> link" messages >> again from m3gdb, after a hiatus. >> >> The variable access function is particularly important to me, as I >> often use nested >> procedures, especially a recursive nested procedure inside a >> parent that holds variables >> that are local to the whole recursive (dynamic) nest but not fully >> global. Especially when >> the recursion is umpteen levels deep, it is a real pain to have to >> figure out how >> many levels to go "up" in the dynamic chain just to get to the >> immediate static parent >> to print one of its variables. And if you want to type a >> expression that mixes a local >> and a nonlocal variable, the feature is almost essential. >> >> So, I propose static links be there always, with the possible >> exception of at very >> high optimization levels. >> >> >> >> Antony Hosking wrote: >>> CVSROOT: /usr/cvs >>> Changes by: hosking at birch. 08/01/07 20:20:48 >>> >>> Modified files: >>> cm3/m3-sys/m3cc/gcc/gcc/: tree-nested.c >>> cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c >>> >>> Log message: >>> Fix bug in procedure value comparison as revealed by p035 of >>> m3tests. >>> The problem was that convert_all_function_calls was marking >>> nested function >>> decls as *not* needing a static chain (DECL_NO_STATIC_CHAIN) >>> when their bodies >>> and other nested procedures within them did not refer to any of >>> their >>> variables. In Modula-3 we still need the static chain (ie, >>> procedure >>> environment) for procedure values so that they can be compared >>> (tested >>> for equality) properly. See the M3 language specification for >>> details of >>> procedure types, which define a procedure as a triple, including >>> its >>> environment. The fix makes use of DECL_NONLOCAL on function >>> decls to mark >>> them as needing the static chain to be preserved whenever a >>> STATIC_CHAIN_EXPR >>> is created for the decl. >>> >>> >> >> -- >> ------------------------------------------------------------- >> Rodney 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 Jan 11 18:10:36 2008 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Fri, 11 Jan 2008 11:10:36 -0600 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <200801110832.m0B8Wuwg006472@camembert.async.caltech.edu> References: <200801110832.m0B8Wuwg006472@camembert.async.caltech.edu> Message-ID: <4787A30C.3060709@wichita.edu> I use what I think is the pattern you refer to regularly. A callback "visit" procedure (which is nested) is passed as a parameter and it accesses nonlocal variables. I just reran a test driver main program that does massive tests of a particular module and uses this pattern extensively. No problems showed up, using PM3 integrated backend, PM3 with gcc backend, and a recent CM3. I still run a lot of stuff PM3-compiled, but my PM3 has somehow diverged significantly from the official distribution, and every time I start to resolve this, it quickly gets a lot deeper than I want to take time for. Mika Nystrom wrote: > This reminds me, there used to be a bug in PM3... has it been fixed? This code > was unreliable: > > PROCEDURE P() = > > VAR a : T; > > PROCEDURE Q(b : U) = > BEGIN a := saveSomethingAbout(b) END Q; > > BEGIN CallVisitor(Q) END P; > > (Note that the M3 report says that while inner procedures may not > be assigned to variables, they may be passed as procedure parameters. > The workaround for the compiler bug is to use something called > "object-oriented programming".) > -- ------------------------------------------------------------- Rodney 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 Jan 11 19:16:44 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 11 Jan 2008 13:16:44 -0500 Subject: [M3devel] could someone add __stdcall name mangling to m3cc please? In-Reply-To: References: Your message of "Wed, 09 Jan 2008 17:25:31 PST." <200801100131.m0A1VQYS034516@camembert.async.caltech.edu> Message-ID: <6D467648-44A7-48DC-AB8D-27B3AC19EBB0@cs.purdue.edu> I just added support for this. Let me know if it seems to work (or not! :-) ). On Jan 10, 2008, at 7:40 AM, Jay wrote: > Could someone out there (Tony?) familiar with the gcc backend > have it not ignore call_conv and if call_conv is 1, append > an at symbol and the number of bytes of parameters to the function > name? > (Even for zero, e.g. Sleep at 0, GetFileAttributes at 4). > This would be I guess at least for "imported" functions. > > Not clear about calling function pointers, probably needs > modification. > call_conv 0 is "__cdecl" is push right to left, caller cleans up > call_conv 1 is "__stdcall" is push right to left, callee cleans up > There are various synonyms. > With no command line switches, __cdecl is the compiler default. > __stdcall is deemed more efficient, and is very widely used. > > Not clear about functions implemented in Modula-3. > Probably won't occur? Maybe for callbacks? WindowProcs, thread > entry point? > > This could/should be for NT386GNU only. > The hypothetical other NT targets only have one calling convention > each. > > I COULD do something sleazy here and generate little adapter > functions, over in m3-win/import-libs esp. > > I'm still checking out pm3 to see what it does here. > (as in cvs checkout, not "looking at") > > This'll clear up: > > RTOS.m3:27: undefined reference to `_FatalExit' > RTOS.mo: In function `RTOS__GetMemory': > RTOS.m3:75: undefined reference to `_VirtualAlloc' > RTOS.m3:85: undefined reference to `_VirtualAlloc' > RTOS.mo: In function `RTOS__InitMemory': > RTOS.m3:96: undefined reference to `_VirtualAlloc' > RTOS.m3:100: undefined reference to `_GetSystemInfo' > RTOS.mo: In function `RTOS__Write': > RTOS.m3:118: undefined reference to `_AllocConsole' > RTOS.m3:119: undefined reference to `_GetStdHandle' > RTOS.m3:122: undefined reference to `_WriteFile' > RTPerfTool.mo: In function `RTPerfTool__Start': > RTPerfTool.m3:19: undefined reference to `_ReadFile' > RTPerfTool.m3:22: undefined reference to `_CloseHandle' > RTPerfTool.mo: In function `RTPerfTool__Close': > RTPerfTool.m3:28: undefined reference to `_CloseHandle' > RTPerfTool.mo: In function `RTPerfTool__Send': > RTPerfTool.m3:34: undefined reference to `_WriteFile' > RTPerfTool.mo: In function `RTPerfTool__PrepHandle': > RTPerfTool.m3:58: undefined reference to `_GetCurrentProcess' > RTPerfTool.m3:59: undefined reference to `_DuplicateHandle' > etc. > > I did think I was past these. I thought I built m3core and libm3 > including linking (having even modified cm3.cfg) > COULD be I'm using the wrong .libs, but: > > C:\cygwin\lib\w32api>nm libkernel32.a | findstr CreateFile > 00000000 I __imp__CreateFileW at 28 > 00000000 T _CreateFileW at 28 > 00000000 I __imp__CreateFileMappingW at 24 > 00000000 T _CreateFileMappingW at 24 > 00000000 I __imp__CreateFileMappingA at 24 > 00000000 T _CreateFileMappingA at 24 > 00000000 I __imp__CreateFileA at 28 > 00000000 T _CreateFileA at 28 > > C:\cygwin\lib\w32api>cd \MinGW\lib > > C:\MinGW\lib>nm libkernel32.a | findstr CreateFile > 00000000 I __imp__CreateFileW at 28 > 00000000 T _CreateFileW at 28 > 00000000 I __imp__CreateFileMappingW at 24 > 00000000 T _CreateFileMappingW at 24 > 00000000 I __imp__CreateFileMappingA at 24 > 00000000 T _CreateFileMappingA at 24 > 00000000 I __imp__CreateFileA at 28 > 00000000 T _CreateFileA at 28 > > I think at least THREE calling conventions should be supported -- > __cdecl, __stdcall, __fastcall -- > but oh well. We can live without __fastcall. > Watcom has another calling convention, "watcall", and they let you > describe calling conventions with #pragmas, neat. > > Thanks, > - Jay > > Share life as it happens with the new Windows Live. Start sharing! From hosking at cs.purdue.edu Fri Jan 11 19:24:49 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 11 Jan 2008 13:24:49 -0500 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <4786950C.6020502@wichita.edu> References: <20080107192048.3FFBB10D461D@birch.elegosoft.com> <4786950C.6020502@wichita.edu> Message-ID: Rodney, Can you confirm that the static chains are now there for your purposes with the latest m3cc? As far as I know, *any* nested procedure that might be called *will* now have a static chain generated for it. I don't think I need to make any other changes to support this. The reasoning is as follows: load_static_link is generated by the M3 front-end compiler whenever a nested function is called, and whenever a procedure value is created from a nested function -- ie, when passing a nested procedure as an actual -- since the value includes the static link as its environment. This is what fixed p035 of m3tests. -- Tony On Jan 10, 2008, at 4:58 PM, Rodney M. Bates wrote: > Antony, I can' tell from your posts whether this is what you did or > not, but: > > m3gdb really needs for there to be a static link allocated space > and stored, for > _every_ nested procedure, even if there is nothing in the compiled > code that uses > it. m3gdb accesses/passes static links in several situations, > e.g., a user-typed > call on a nested procedure constant, user-typed assignment of a > nested procedure > value to a procedure variable, user-typed call on a procedure > variable (whose > value might be nested or top-level), and just access to a variable > that is nonlocal > to the current frame. > > All of this has been implemented for some time, although it is > distressingly > fragile. I have a number of times gone back in and fixed some case > I thought > I had working earlier. I recently started seeing "invalid static > link" messages > again from m3gdb, after a hiatus. > > The variable access function is particularly important to me, as I > often use nested > procedures, especially a recursive nested procedure inside a parent > that holds variables > that are local to the whole recursive (dynamic) nest but not fully > global. Especially when > the recursion is umpteen levels deep, it is a real pain to have to > figure out how > many levels to go "up" in the dynamic chain just to get to the > immediate static parent > to print one of its variables. And if you want to type a expression > that mixes a local > and a nonlocal variable, the feature is almost essential. > > So, I propose static links be there always, with the possible > exception of at very > high optimization levels. > > > > Antony Hosking wrote: >> CVSROOT: /usr/cvs >> Changes by: hosking at birch. 08/01/07 20:20:48 >> Modified files: >> cm3/m3-sys/m3cc/gcc/gcc/: tree-nested.c cm3/m3-sys/m3cc/gcc/gcc/ >> m3cg/: parse.c Log message: >> Fix bug in procedure value comparison as revealed by p035 of >> m3tests. >> The problem was that convert_all_function_calls was marking >> nested function >> decls as *not* needing a static chain (DECL_NO_STATIC_CHAIN) when >> their bodies >> and other nested procedures within them did not refer to any of >> their >> variables. In Modula-3 we still need the static chain (ie, >> procedure >> environment) for procedure values so that they can be compared >> (tested >> for equality) properly. See the M3 language specification for >> details of >> procedure types, which define a procedure as a triple, including its >> environment. The fix makes use of DECL_NONLOCAL on function >> decls to mark >> them as needing the static chain to be preserved whenever a >> STATIC_CHAIN_EXPR >> is created for the decl. > > -- > ------------------------------------------------------------- > Rodney 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 Jan 12 01:20:04 2008 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Fri, 11 Jan 2008 18:20:04 -0600 Subject: [M3devel] I need CVS help again Message-ID: <478807B4.2080100@wichita.edu> I have gotten myself into this jam before, as a result of trying to develop/test on more than one local machine with more than one M3 installation. I have more questions on how to figure out what happened and how to fix it. I did a cvs update when, I guess, I had local uncommitted edits. I got messages saying that changes were being merged and there were conflicts. For example, I now have local files named: .#m3-eval.c.1.12 m3-eval.c and in CVS/Entries, the line: /m3-eval.c/1.14/Result of merge... Have I correctly surmised that this all means 1) prior to the update, CVS/Entries would have said: /m3-eval/c/1.12... meaning 1.12 was the last version cvs knew I had, 2) But my local m3-eval.c had local changes relative to 1.12, 3) And .#m3-eval.c.1.12 is a copy of that locally changed m3-eval.c, as it was prior to the cvs update, 4) The latest version cvs has in its repository is 1.14, and 5) My current local m3-eval.c was generated by merging version 1.14 from the repository with what is now in .#m3-eval.c.1.12? Is there a simple way to get cvs to diff between its stored version 1.12 and my .#m3-eval.1.12? -- ------------------------------------------------------------- Rodney 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 Sat Jan 12 01:22:16 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 12 Jan 2008 01:22:16 +0100 Subject: [M3devel] I need CVS help again In-Reply-To: <478807B4.2080100@wichita.edu> References: <478807B4.2080100@wichita.edu> Message-ID: <20080112012216.k4d438pquc0sw8os@mail.elegosoft.com> Quoting "Rodney M. Bates" : > I have gotten myself into this jam before, as a result of trying to > develop/test on more than one local machine with more than one M3 > installation. I have more questions on how to figure out what happened > and how to fix it. > > I did a cvs update when, I guess, I had local uncommitted edits. > I got messages saying that changes were being merged and there were > conflicts. For example, I now have local files named: > > .#m3-eval.c.1.12 > m3-eval.c > > and in CVS/Entries, the line: > > /m3-eval.c/1.14/Result of merge... > > Have I correctly surmised that this all means > > 1) prior to the update, CVS/Entries would have said: > > /m3-eval/c/1.12... > > meaning 1.12 was the last version cvs knew I had, > > 2) But my local m3-eval.c had local changes relative to 1.12, > > 3) And .#m3-eval.c.1.12 is a copy of that locally changed > m3-eval.c, as it was prior to the cvs update, Yes, this should be your original file. > 4) The latest version cvs has in its repository is 1.14, and Yes. > 5) My current local m3-eval.c was generated by merging version > 1.14 from the repository with what is now in .#m3-eval.c.1.12? Yes. You should simply find the comflicts in m3-eval.c by looking for lines with <<<< and ===== and >>>>. Often they are easy to edit manually. > Is there a simple way to get cvs to diff between its stored > version 1.12 and my .#m3-eval.1.12? You can checkout any version into your workspace and compare locally: cvs up -p -r 1.12 m3-eval.c > m3-eval.c.1.12 cvs up -p -r 1.14 m3-eval.c > m3-eval.c.1.14 diff -u .m3-eval.c.1.12 \#m3-eval.1.12 ... HTH, Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Jan 12 14:27:23 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 12 Jan 2008 13:27:23 +0000 Subject: [M3devel] could someone add __stdcall name mangling to m3cc please? In-Reply-To: <6D467648-44A7-48DC-AB8D-27B3AC19EBB0@cs.purdue.edu> References: Your message of "Wed, 09 Jan 2008 17:25:31 PST." <200801100131.m0A1VQYS034516@camembert.async.caltech.edu> <6D467648-44A7-48DC-AB8D-27B3AC19EBB0@cs.purdue.edu> Message-ID: Thanks, but not quite. The number of parameters times four needs to be appended to the name, in decimal. But I'm just getting 0. That is, gcc is handling the underlying detail, but you aren't giving it enough infomrmation. I'll see if I can bang out those temporary wrappers automatically.. (a Quake programming challenge, that I've already invented the hard part of I think -- Quake can't do math..) - Jay > CC: m3devel at elegosoft.com> From: hosking at cs.purdue.edu> Subject: Re: [M3devel] could someone add __stdcall name mangling to m3cc please?> Date: Fri, 11 Jan 2008 13:16:44 -0500> To: jayk123 at hotmail.com> > I just added support for this. Let me know if it seems to work (or > not! :-) ).> > > On Jan 10, 2008, at 7:40 AM, Jay wrote:> > > Could someone out there (Tony?) familiar with the gcc backend> > have it not ignore call_conv and if call_conv is 1, append> > an at symbol and the number of bytes of parameters to the function > > name?> > (Even for zero, e.g. Sleep at 0, GetFileAttributes at 4).> > This would be I guess at least for "imported" functions.> >> > Not clear about calling function pointers, probably needs > > modification.> > call_conv 0 is "__cdecl" is push right to left, caller cleans up> > call_conv 1 is "__stdcall" is push right to left, callee cleans up> > There are various synonyms.> > With no command line switches, __cdecl is the compiler default.> > __stdcall is deemed more efficient, and is very widely used.> >> > Not clear about functions implemented in Modula-3.> > Probably won't occur? Maybe for callbacks? WindowProcs, thread > > entry point?> >> > This could/should be for NT386GNU only.> > The hypothetical other NT targets only have one calling convention > > each.> >> > I COULD do something sleazy here and generate little adapter > > functions, over in m3-win/import-libs esp.> >> > I'm still checking out pm3 to see what it does here.> > (as in cvs checkout, not "looking at")> >> > This'll clear up:> >> > RTOS.m3:27: undefined reference to `_FatalExit'> > RTOS.mo: In function `RTOS__GetMemory':> > RTOS.m3:75: undefined reference to `_VirtualAlloc'> > RTOS.m3:85: undefined reference to `_VirtualAlloc'> > RTOS.mo: In function `RTOS__InitMemory':> > RTOS.m3:96: undefined reference to `_VirtualAlloc'> > RTOS.m3:100: undefined reference to `_GetSystemInfo'> > RTOS.mo: In function `RTOS__Write':> > RTOS.m3:118: undefined reference to `_AllocConsole'> > RTOS.m3:119: undefined reference to `_GetStdHandle'> > RTOS.m3:122: undefined reference to `_WriteFile'> > RTPerfTool.mo: In function `RTPerfTool__Start':> > RTPerfTool.m3:19: undefined reference to `_ReadFile'> > RTPerfTool.m3:22: undefined reference to `_CloseHandle'> > RTPerfTool.mo: In function `RTPerfTool__Close':> > RTPerfTool.m3:28: undefined reference to `_CloseHandle'> > RTPerfTool.mo: In function `RTPerfTool__Send':> > RTPerfTool.m3:34: undefined reference to `_WriteFile'> > RTPerfTool.mo: In function `RTPerfTool__PrepHandle':> > RTPerfTool.m3:58: undefined reference to `_GetCurrentProcess'> > RTPerfTool.m3:59: undefined reference to `_DuplicateHandle'> > etc.> >> > I did think I was past these. I thought I built m3core and libm3 > > including linking (having even modified cm3.cfg)> > COULD be I'm using the wrong .libs, but:> >> > C:\cygwin\lib\w32api>nm libkernel32.a | findstr CreateFile> > 00000000 I __imp__CreateFileW at 28> > 00000000 T _CreateFileW at 28> > 00000000 I __imp__CreateFileMappingW at 24> > 00000000 T _CreateFileMappingW at 24> > 00000000 I __imp__CreateFileMappingA at 24> > 00000000 T _CreateFileMappingA at 24> > 00000000 I __imp__CreateFileA at 28> > 00000000 T _CreateFileA at 28> >> > C:\cygwin\lib\w32api>cd \MinGW\lib> >> > C:\MinGW\lib>nm libkernel32.a | findstr CreateFile> > 00000000 I __imp__CreateFileW at 28> > 00000000 T _CreateFileW at 28> > 00000000 I __imp__CreateFileMappingW at 24> > 00000000 T _CreateFileMappingW at 24> > 00000000 I __imp__CreateFileMappingA at 24> > 00000000 T _CreateFileMappingA at 24> > 00000000 I __imp__CreateFileA at 28> > 00000000 T _CreateFileA at 28> >> > I think at least THREE calling conventions should be supported -- > > __cdecl, __stdcall, __fastcall --> > but oh well. We can live without __fastcall.> > Watcom has another calling convention, "watcall", and they let you > > describe calling conventions with #pragmas, neat.> >> > Thanks,> > - Jay> >> > Share life as it happens with the new Windows Live. Start sharing!> _________________________________________________________________ Make distant family not so distant with Windows Vista? + Windows Live?. http://www.microsoft.com/windows/digitallife/keepintouch.mspx?ocid=TXT_TAGLM_CPC_VideoChat_distantfamily_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sat Jan 12 16:41:26 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 12 Jan 2008 10:41:26 -0500 Subject: [M3devel] could someone add __stdcall name mangling to m3cc please? In-Reply-To: References: Your message of "Wed, 09 Jan 2008 17:25:31 PST." <200801100131.m0A1VQYS034516@camembert.async.caltech.edu> <6D467648-44A7-48DC-AB8D-27B3AC19EBB0@cs.purdue.edu> Message-ID: I'm not sure what you were trying to do with parse.c by adding a parameter (nargs*4) to the stdcall attribute, but that probably doesn't do anything interesting. The problem appears to be because on external function decls the parameter decls are currently being ignored by cm3cg. If I fix parse.c to add the params for those then it should work properly with the stdcall attribute. On Jan 12, 2008, at 8:27 AM, Jay wrote: > Thanks, but not quite. The number of parameters times four needs to > be appended to the name, in decimal. > But I'm just getting 0. > That is, gcc is handling the underlying detail, but you aren't > giving it enough infomrmation. > I'll see if I can bang out those temporary wrappers automatically.. > (a Quake programming challenge, that I've already invented the hard > part of I think -- Quake can't do math..) > > - Jay > > > > CC: m3devel at elegosoft.com > > From: hosking at cs.purdue.edu > > Subject: Re: [M3devel] could someone add __stdcall name mangling > to m3cc please? > > Date: Fri, 11 Jan 2008 13:16:44 -0500 > > To: jayk123 at hotmail.com > > > > I just added support for this. Let me know if it seems to work (or > > not! :-) ). > > > > > > On Jan 10, 2008, at 7:40 AM, Jay wrote: > > > > > Could someone out there (Tony?) familiar with the gcc backend > > > have it not ignore call_conv and if call_conv is 1, append > > > an at symbol and the number of bytes of parameters to the function > > > name? > > > (Even for zero, e.g. Sleep at 0, GetFileAttributes at 4). > > > This would be I guess at least for "imported" functions. > > > > > > Not clear about calling function pointers, probably needs > > > modification. > > > call_conv 0 is "__cdecl" is push right to left, caller cleans up > > > call_conv 1 is "__stdcall" is push right to left, callee cleans up > > > There are various synonyms. > > > With no command line switches, __cdecl is the compiler default. > > > __stdcall is deemed more efficient, and is very widely used. > > > > > > Not clear about functions implemented in Modula-3. > > > Probably won't occur? Maybe for callbacks? WindowProcs, thread > > > entry point? > > > > > > This could/should be for NT386GNU only. > > > The hypothetical other NT targets only have one calling convention > > > each. > > > > > > I COULD do something sleazy here and generate little adapter > > > functions, over in m3-win/import-libs esp. > > > > > > I'm still checking out pm3 to see what it does here. > > > (as in cvs checkout, not "looking at") > > > > > > This'll clear up: > > > > > > RTOS.m3:27: undefined reference to `_FatalExit' > > > RTOS.mo: In function `RTOS__GetMemory': > > > RTOS.m3:75: undefined reference to `_VirtualAlloc' > > > RTOS.m3:85: undefined reference to `_VirtualAlloc' > > > RTOS.mo: In function `RTOS__InitMemory': > > > RTOS.m3:96: undefined reference to `_VirtualAlloc' > > > RTOS.m3:100: undefined reference to `_GetSystemInfo' > > > RTOS.mo: In function `RTOS__Write': > > > RTOS.m3:118: undefined reference to `_AllocConsole' > > > RTOS.m3:119: undefined reference to `_GetStdHandle' > > > RTOS.m3:122: undefined reference to `_WriteFile' > > > RTPerfTool.mo: In function `RTPerfTool__Start': > > > RTPerfTool.m3:19: undefined reference to `_ReadFile' > > > RTPerfTool.m3:22: undefined reference to `_CloseHandle' > > > RTPerfTool.mo: In function `RTPerfTool__Close': > > > RTPerfTool.m3:28: undefined reference to `_CloseHandle' > > > RTPerfTool.mo: In function `RTPerfTool__Send': > > > RTPerfTool.m3:34: undefined reference to `_WriteFile' > > > RTPerfTool.mo: In function `RTPerfTool__PrepHandle': > > > RTPerfTool.m3:58: undefined reference to `_GetCurrentProcess' > > > RTPerfTool.m3:59: undefined reference to `_DuplicateHandle' > > > etc. > > > > > > I did think I was past these. I thought I built m3core and libm3 > > > including linking (having even modified cm3.cfg) > > > COULD be I'm using the wrong .libs, but: > > > > > > C:\cygwin\lib\w32api>nm libkernel32.a | findstr CreateFile > > > 00000000 I __imp__CreateFileW at 28 > > > 00000000 T _CreateFileW at 28 > > > 00000000 I __imp__CreateFileMappingW at 24 > > > 00000000 T _CreateFileMappingW at 24 > > > 00000000 I __imp__CreateFileMappingA at 24 > > > 00000000 T _CreateFileMappingA at 24 > > > 00000000 I __imp__CreateFileA at 28 > > > 00000000 T _CreateFileA at 28 > > > > > > C:\cygwin\lib\w32api>cd \MinGW\lib > > > > > > C:\MinGW\lib>nm libkernel32.a | findstr CreateFile > > > 00000000 I __imp__CreateFileW at 28 > > > 00000000 T _CreateFileW at 28 > > > 00000000 I __imp__CreateFileMappingW at 24 > > > 00000000 T _CreateFileMappingW at 24 > > > 00000000 I __imp__CreateFileMappingA at 24 > > > 00000000 T _CreateFileMappingA at 24 > > > 00000000 I __imp__CreateFileA at 28 > > > 00000000 T _CreateFileA at 28 > > > > > > I think at least THREE calling conventions should be supported -- > > > __cdecl, __stdcall, __fastcall -- > > > but oh well. We can live without __fastcall. > > > Watcom has another calling convention, "watcall", and they let you > > > describe calling conventions with #pragmas, neat. > > > > > > Thanks, > > > - Jay > > > > > > Share life as it happens with the new Windows Live. Start sharing! > > > > > Make distant family not so distant with Windows Vista? + Windows > Live?. Start now! From jayk123 at hotmail.com Sat Jan 12 19:13:27 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 12 Jan 2008 18:13:27 +0000 Subject: [M3devel] could someone add __stdcall name mangling to m3cc please? In-Reply-To: References: Your message of "Wed, 09 Jan 2008 17:25:31 PST." <200801100131.m0A1VQYS034516@camembert.async.caltech.edu> <6D467648-44A7-48DC-AB8D-27B3AC19EBB0@cs.purdue.edu> Message-ID: Tony, Sorry, I didn't mean to check those in. Those were wild guesses that I hadn't tested yet.I put it back. Thanks for catching that. - Jay > CC: m3devel at elegosoft.com> From: hosking at cs.purdue.edu> Subject: Re: [M3devel] could someone add __stdcall name mangling to m3cc please?> Date: Sat, 12 Jan 2008 10:41:26 -0500> To: jayk123 at hotmail.com> > I'm not sure what you were trying to do with parse.c by adding a > parameter (nargs*4) to the stdcall attribute, but that probably > doesn't do anything interesting. The problem appears to be because > on external function decls the parameter decls are currently being > ignored by cm3cg. If I fix parse.c to add the params for those then > it should work properly with the stdcall attribute.> > On Jan 12, 2008, at 8:27 AM, Jay wrote:> > > Thanks, but not quite. The number of parameters times four needs to > > be appended to the name, in decimal.> > But I'm just getting 0.> > That is, gcc is handling the underlying detail, but you aren't > > giving it enough infomrmation.> > I'll see if I can bang out those temporary wrappers automatically.. > > (a Quake programming challenge, that I've already invented the hard > > part of I think -- Quake can't do math..)> >> > - Jay> >> >> > > CC: m3devel at elegosoft.com> > > From: hosking at cs.purdue.edu> > > Subject: Re: [M3devel] could someone add __stdcall name mangling > > to m3cc please?> > > Date: Fri, 11 Jan 2008 13:16:44 -0500> > > To: jayk123 at hotmail.com> > >> > > I just added support for this. Let me know if it seems to work (or> > > not! :-) ).> > >> > >> > > On Jan 10, 2008, at 7:40 AM, Jay wrote:> > >> > > > Could someone out there (Tony?) familiar with the gcc backend> > > > have it not ignore call_conv and if call_conv is 1, append> > > > an at symbol and the number of bytes of parameters to the function> > > > name?> > > > (Even for zero, e.g. Sleep at 0, GetFileAttributes at 4).> > > > This would be I guess at least for "imported" functions.> > > >> > > > Not clear about calling function pointers, probably needs> > > > modification.> > > > call_conv 0 is "__cdecl" is push right to left, caller cleans up> > > > call_conv 1 is "__stdcall" is push right to left, callee cleans up> > > > There are various synonyms.> > > > With no command line switches, __cdecl is the compiler default.> > > > __stdcall is deemed more efficient, and is very widely used.> > > >> > > > Not clear about functions implemented in Modula-3.> > > > Probably won't occur? Maybe for callbacks? WindowProcs, thread> > > > entry point?> > > >> > > > This could/should be for NT386GNU only.> > > > The hypothetical other NT targets only have one calling convention> > > > each.> > > >> > > > I COULD do something sleazy here and generate little adapter> > > > functions, over in m3-win/import-libs esp.> > > >> > > > I'm still checking out pm3 to see what it does here.> > > > (as in cvs checkout, not "looking at")> > > >> > > > This'll clear up:> > > >> > > > RTOS.m3:27: undefined reference to `_FatalExit'> > > > RTOS.mo: In function `RTOS__GetMemory':> > > > RTOS.m3:75: undefined reference to `_VirtualAlloc'> > > > RTOS.m3:85: undefined reference to `_VirtualAlloc'> > > > RTOS.mo: In function `RTOS__InitMemory':> > > > RTOS.m3:96: undefined reference to `_VirtualAlloc'> > > > RTOS.m3:100: undefined reference to `_GetSystemInfo'> > > > RTOS.mo: In function `RTOS__Write':> > > > RTOS.m3:118: undefined reference to `_AllocConsole'> > > > RTOS.m3:119: undefined reference to `_GetStdHandle'> > > > RTOS.m3:122: undefined reference to `_WriteFile'> > > > RTPerfTool.mo: In function `RTPerfTool__Start':> > > > RTPerfTool.m3:19: undefined reference to `_ReadFile'> > > > RTPerfTool.m3:22: undefined reference to `_CloseHandle'> > > > RTPerfTool.mo: In function `RTPerfTool__Close':> > > > RTPerfTool.m3:28: undefined reference to `_CloseHandle'> > > > RTPerfTool.mo: In function `RTPerfTool__Send':> > > > RTPerfTool.m3:34: undefined reference to `_WriteFile'> > > > RTPerfTool.mo: In function `RTPerfTool__PrepHandle':> > > > RTPerfTool.m3:58: undefined reference to `_GetCurrentProcess'> > > > RTPerfTool.m3:59: undefined reference to `_DuplicateHandle'> > > > etc.> > > >> > > > I did think I was past these. I thought I built m3core and libm3> > > > including linking (having even modified cm3.cfg)> > > > COULD be I'm using the wrong .libs, but:> > > >> > > > C:\cygwin\lib\w32api>nm libkernel32.a | findstr CreateFile> > > > 00000000 I __imp__CreateFileW at 28> > > > 00000000 T _CreateFileW at 28> > > > 00000000 I __imp__CreateFileMappingW at 24> > > > 00000000 T _CreateFileMappingW at 24> > > > 00000000 I __imp__CreateFileMappingA at 24> > > > 00000000 T _CreateFileMappingA at 24> > > > 00000000 I __imp__CreateFileA at 28> > > > 00000000 T _CreateFileA at 28> > > >> > > > C:\cygwin\lib\w32api>cd \MinGW\lib> > > >> > > > C:\MinGW\lib>nm libkernel32.a | findstr CreateFile> > > > 00000000 I __imp__CreateFileW at 28> > > > 00000000 T _CreateFileW at 28> > > > 00000000 I __imp__CreateFileMappingW at 24> > > > 00000000 T _CreateFileMappingW at 24> > > > 00000000 I __imp__CreateFileMappingA at 24> > > > 00000000 T _CreateFileMappingA at 24> > > > 00000000 I __imp__CreateFileA at 28> > > > 00000000 T _CreateFileA at 28> > > >> > > > I think at least THREE calling conventions should be supported --> > > > __cdecl, __stdcall, __fastcall --> > > > but oh well. We can live without __fastcall.> > > > Watcom has another calling convention, "watcall", and they let you> > > > describe calling conventions with #pragmas, neat.> > > >> > > > Thanks,> > > > - Jay> > > >> > > > Share life as it happens with the new Windows Live. Start sharing!> > >> >> >> > Make distant family not so distant with Windows Vista? + Windows > > Live?. Start now!> _________________________________________________________________ Watch ?Cause Effect,? a show about real people making a real difference. http://im.live.com/Messenger/IM/MTV/?source=text_watchcause -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Sat Jan 12 20:57:49 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 12 Jan 2008 19:57:49 +0000 Subject: [M3devel] could someone add __stdcall name mangling to m3cc please? In-Reply-To: References: Your message of "Wed, 09 Jan 2008 17:25:31 PST." <200801100131.m0A1VQYS034516@camembert.async.caltech.edu> <6D467648-44A7-48DC-AB8D-27B3AC19EBB0@cs.purdue.edu> Message-ID: Something like this????? ===================================================================RCS file: /usr/cvs/cm3/m3-sys/m3cc/gcc/gcc/m3cg/parse.c,vretrieving revision 1.41diff -r1.41 parse.c3066a3070> tree atypes = NULL_TREE);3091c3095,3102< TREE_TYPE (p) = build_function_type (return_type, NULL_TREE);---> /* for NT386 __stdcall, we just need to declare the right number> of parameters> */> if (--n_params== 0) {> atypes = tree_cons (NULL_TREE, t_word, atypes);> }>> TREE_TYPE (p) = build_function_type (return_type, atypes); haven't even compiled it yet.. - Jay > From: jayk123 at hotmail.com> To: hosking at cs.purdue.edu> Date: Sat, 12 Jan 2008 18:13:27 +0000> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] could someone add __stdcall name mangling to m3cc please?> > Tony, Sorry, I didn't mean to check those in. Those were wild guesses that I hadn't tested yet.I put it back. Thanks for catching that.> > - Jay> > > > > CC: m3devel at elegosoft.com> From: hosking at cs.purdue.edu> Subject: Re: [M3devel] could someone add __stdcall name mangling to m3cc please?> Date: Sat, 12 Jan 2008 10:41:26 -0500> To: jayk123 at hotmail.com> > I'm not sure what you were trying to do with parse.c by adding a > parameter (nargs*4) to the stdcall attribute, but that probably > doesn't do anything interesting. The problem appears to be because > on external function decls the parameter decls are currently being > ignored by cm3cg. If I fix parse.c to add the params for those then > it should work properly with the stdcall attribute.> > On Jan 12, 2008, at 8:27 AM, Jay wrote:> > > Thanks, but not quite. The number of parameters times four needs to > > be appended to the name, in decimal.> > But I'm just getting 0.> > That is, gcc is handling the underlying detail, but you aren't > > giving it enough infomrmation.> > I'll see if I can bang out those temporary wrappers automatically.. > > (a Quake programming challenge, that I've already invented the hard > > part of I think -- Quake can't do math..)> >> > - Jay> >> >> > > CC: m3devel at elegosoft.com> > > From: hosking at cs.purdue.edu> > > Subject: Re: [M3devel] could someone add __stdcall name mangling > > to m3cc please?> > > Date: Fri, 11 Jan 2008 13:16:44 -0500> > > To: jayk123 at hotmail.com> > >> > > I just added support for this. Let me know if it seems to work (or> > > not! :-) ).> > >> > >> > > On Jan 10, 2008, at 7:40 AM, Jay wrote:> > >> > > > Could someone out there (Tony?) familiar with the gcc backend> > > > have it not ignore call_conv and if call_conv is 1, append> > > > an at symbol and the number of bytes of parameters to the function> > > > name?> > > > (Even for zero, e.g. Sleep at 0, GetFileAttributes at 4).> > > > This would be I guess at least for "imported" functions.> > > >> > > > Not clear about calling function pointers, probably needs> > > > modification.> > > > call_conv 0 is "__cdecl" is push right to left, caller cleans up> > > > call_conv 1 is "__stdcall" is push right to left, callee cleans up> > > > There are various synonyms.> > > > With no command line switches, __cdecl is the compiler default.> > > > __stdcall is deemed more efficient, and is very widely used.> > > >> > > > Not clear about functions implemented in Modula-3.> > > > Probably won't occur? Maybe for callbacks? WindowProcs, thread> > > > entry point?> > > >> > > > This could/should be for NT386GNU only.> > > > The hypothetical other NT targets only have one calling convention> > > > each.> > > >> > > > I COULD do something sleazy here and generate little adapter> > > > functions, over in m3-win/import-libs esp.> > > >> > > > I'm still checking out pm3 to see what it does here.> > > > (as in cvs checkout, not "looking at")> > > >> > > > This'll clear up:> > > >> > > > RTOS.m3:27: undefined reference to `_FatalExit'> > > > RTOS.mo: In function `RTOS__GetMemory':> > > > RTOS.m3:75: undefined reference to `_VirtualAlloc'> > > > RTOS.m3:85: undefined reference to `_VirtualAlloc'> > > > RTOS.mo: In function `RTOS__InitMemory':> > > > RTOS.m3:96: undefined reference to `_VirtualAlloc'> > > > RTOS.m3:100: undefined reference to `_GetSystemInfo'> > > > RTOS.mo: In function `RTOS__Write':> > > > RTOS.m3:118: undefined reference to `_AllocConsole'> > > > RTOS.m3:119: undefined reference to `_GetStdHandle'> > > > RTOS.m3:122: undefined reference to `_WriteFile'> > > > RTPerfTool.mo: In function `RTPerfTool__Start':> > > > RTPerfTool.m3:19: undefined reference to `_ReadFile'> > > > RTPerfTool.m3:22: undefined reference to `_CloseHandle'> > > > RTPerfTool.mo: In function `RTPerfTool__Close':> > > > RTPerfTool.m3:28: undefined reference to `_CloseHandle'> > > > RTPerfTool.mo: In function `RTPerfTool__Send':> > > > RTPerfTool.m3:34: undefined reference to `_WriteFile'> > > > RTPerfTool.mo: In function `RTPerfTool__PrepHandle':> > > > RTPerfTool.m3:58: undefined reference to `_GetCurrentProcess'> > > > RTPerfTool.m3:59: undefined reference to `_DuplicateHandle'> > > > etc.> > > >> > > > I did think I was past these. I thought I built m3core and libm3> > > > including linking (having even modified cm3.cfg)> > > > COULD be I'm using the wrong .libs, but:> > > >> > > > C:\cygwin\lib\w32api>nm libkernel32.a | findstr CreateFile> > > > 00000000 I __imp__CreateFileW at 28> > > > 00000000 T _CreateFileW at 28> > > > 00000000 I __imp__CreateFileMappingW at 24> > > > 00000000 T _CreateFileMappingW at 24> > > > 00000000 I __imp__CreateFileMappingA at 24> > > > 00000000 T _CreateFileMappingA at 24> > > > 00000000 I __imp__CreateFileA at 28> > > > 00000000 T _CreateFileA at 28> > > >> > > > C:\cygwin\lib\w32api>cd \MinGW\lib> > > >> > > > C:\MinGW\lib>nm libkernel32.a | findstr CreateFile> > > > 00000000 I __imp__CreateFileW at 28> > > > 00000000 T _CreateFileW at 28> > > > 00000000 I __imp__CreateFileMappingW at 24> > > > 00000000 T _CreateFileMappingW at 24> > > > 00000000 I __imp__CreateFileMappingA at 24> > > > 00000000 T _CreateFileMappingA at 24> > > > 00000000 I __imp__CreateFileA at 28> > > > 00000000 T _CreateFileA at 28> > > >> > > > I think at least THREE calling conventions should be supported --> > > > __cdecl, __stdcall, __fastcall --> > > > but oh well. We can live without __fastcall.> > > > Watcom has another calling convention, "watcall", and they let you> > > > describe calling conventions with #pragmas, neat.> > > >> > > > Thanks,> > > > - Jay> > > >> > > > Share life as it happens with the new Windows Live. Start sharing!> > >> >> >> > Make distant family not so distant with Windows Vista? + Windows > > Live?. Start now!> > _________________________________________________________________> Watch ?Cause Effect,? a show about real people making a real difference _________________________________________________________________ Get the power of Windows + Web with the new Windows Live. http://www.windowslive.com?ocid=TXT_TAGHM_Wave2_powerofwindows_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sun Jan 13 01:04:12 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 12 Jan 2008 19:04:12 -0500 Subject: [M3devel] could someone add __stdcall name mangling to m3cc please? In-Reply-To: References: Your message of "Wed, 09 Jan 2008 17:25:31 PST." <200801100131.m0A1VQYS034516@camembert.async.caltech.edu> <6D467648-44A7-48DC-AB8D-27B3AC19EBB0@cs.purdue.edu> Message-ID: I will be able to get m3cc to spit out the appropriate stdcall function names. Needs a little work, but nothing too drastic. On Jan 12, 2008, at 1:13 PM, Jay wrote: > Tony, Sorry, I didn't mean to check those in. Those were wild > guesses that I hadn't tested yet. > I put it back. Thanks for catching that. > > - Jay > > > > > CC: m3devel at elegosoft.com > > From: hosking at cs.purdue.edu > > Subject: Re: [M3devel] could someone add __stdcall name mangling > to m3cc please? > > Date: Sat, 12 Jan 2008 10:41:26 -0500 > > To: jayk123 at hotmail.com > > > > I'm not sure what you were trying to do with parse.c by adding a > > parameter (nargs*4) to the stdcall attribute, but that probably > > doesn't do anything interesting. The problem appears to be because > > on external function decls the parameter decls are currently being > > ignored by cm3cg. If I fix parse.c to add the params for those then > > it should work properly with the stdcall attribute. > > > > On Jan 12, 2008, at 8:27 AM, Jay wrote: > > > > > Thanks, but not quite. The number of parameters times four > needs to > > > be appended to the name, in decimal. > > > But I'm just getting 0. > > > That is, gcc is handling the underlying detail, but you aren't > > > giving it enough infomrmation. > > > I'll see if I can bang out those temporary wrappers > automatically.. > > > (a Quake programming challenge, that I've already invented the > hard > > > part of I think -- Quake can't do math..) > > > > > > - Jay > > > > > > > > > > CC: m3devel at elegosoft.com > > > > From: hosking at cs.purdue.edu > > > > Subject: Re: [M3devel] could someone add __stdcall name mangling > > > to m3cc please? > > > > Date: Fri, 11 Jan 2008 13:16:44 -0500 > > > > To: jayk123 at hotmail.com > > > > > > > > I just added support for this. Let me know if it seems to > work (or > > > > not! :-) ). > > > > > > > > > > > > On Jan 10, 2008, at 7:40 AM, Jay wrote: > > > > > > > > > Could someone out there (Tony?) familiar with the gcc backend > > > > > have it not ignore call_conv and if call_conv is 1, append > > > > > an at symbol and the number of bytes of parameters to the > function > > > > > name? > > > > > (Even for zero, e.g. Sleep at 0, GetFileAttributes at 4). > > > > > This would be I guess at least for "imported" functions. > > > > > > > > > > Not clear about calling function pointers, probably needs > > > > > modification. > > > > > call_conv 0 is "__cdecl" is push right to left, caller > cleans up > > > > > call_conv 1 is "__stdcall" is push right to left, callee > cleans up > > > > > There are various synonyms. > > > > > With no command line switches, __cdecl is the compiler > default. > > > > > __stdcall is deemed more efficient, and is very widely used. > > > > > > > > > > Not clear about functions implemented in Modula-3. > > > > > Probably won't occur? Maybe for callbacks? WindowProcs, thread > > > > > entry point? > > > > > > > > > > This could/should be for NT386GNU only. > > > > > The hypothetical other NT targets only have one calling > convention > > > > > each. > > > > > > > > > > I COULD do something sleazy here and generate little adapter > > > > > functions, over in m3-win/import-libs esp. > > > > > > > > > > I'm still checking out pm3 to see what it does here. > > > > > (as in cvs checkout, not "looking at") > > > > > > > > > > This'll clear up: > > > > > > > > > > RTOS.m3:27: undefined reference to `_FatalExit' > > > > > RTOS.mo: In function `RTOS__GetMemory': > > > > > RTOS.m3:75: undefined reference to `_VirtualAlloc' > > > > > RTOS.m3:85: undefined reference to `_VirtualAlloc' > > > > > RTOS.mo: In function `RTOS__InitMemory': > > > > > RTOS.m3:96: undefined reference to `_VirtualAlloc' > > > > > RTOS.m3:100: undefined reference to `_GetSystemInfo' > > > > > RTOS.mo: In function `RTOS__Write': > > > > > RTOS.m3:118: undefined reference to `_AllocConsole' > > > > > RTOS.m3:119: undefined reference to `_GetStdHandle' > > > > > RTOS.m3:122: undefined reference to `_WriteFile' > > > > > RTPerfTool.mo: In function `RTPerfTool__Start': > > > > > RTPerfTool.m3:19: undefined reference to `_ReadFile' > > > > > RTPerfTool.m3:22: undefined reference to `_CloseHandle' > > > > > RTPerfTool.mo: In function `RTPerfTool__Close': > > > > > RTPerfTool.m3:28: undefined reference to `_CloseHandle' > > > > > RTPerfTool.mo: In function `RTPerfTool__Send': > > > > > RTPerfTool.m3:34: undefined reference to `_WriteFile' > > > > > RTPerfTool.mo: In function `RTPerfTool__PrepHandle': > > > > > RTPerfTool.m3:58: undefined reference to `_GetCurrentProcess' > > > > > RTPerfTool.m3:59: undefined reference to `_DuplicateHandle' > > > > > etc. > > > > > > > > > > I did think I was past these. I thought I built m3core and > libm3 > > > > > including linking (having even modified cm3.cfg) > > > > > COULD be I'm using the wrong .libs, but: > > > > > > > > > > C:\cygwin\lib\w32api>nm libkernel32.a | findstr CreateFile > > > > > 00000000 I __imp__CreateFileW at 28 > > > > > 00000000 T _CreateFileW at 28 > > > > > 00000000 I __imp__CreateFileMappingW at 24 > > > > > 00000000 T _CreateFileMappingW at 24 > > > > > 00000000 I __imp__CreateFileMappingA at 24 > > > > > 00000000 T _CreateFileMappingA at 24 > > > > > 00000000 I __imp__CreateFileA at 28 > > > > > 00000000 T _CreateFileA at 28 > > > > > > > > > > C:\cygwin\lib\w32api>cd \MinGW\lib > > > > > > > > > > C:\MinGW\lib>nm libkernel32.a | findstr CreateFile > > > > > 00000000 I __imp__CreateFileW at 28 > > > > > 00000000 T _CreateFileW at 28 > > > > > 00000000 I __imp__CreateFileMappingW at 24 > > > > > 00000000 T _CreateFileMappingW at 24 > > > > > 00000000 I __imp__CreateFileMappingA at 24 > > > > > 00000000 T _CreateFileMappingA at 24 > > > > > 00000000 I __imp__CreateFileA at 28 > > > > > 00000000 T _CreateFileA at 28 > > > > > > > > > > I think at least THREE calling conventions should be > supported -- > > > > > __cdecl, __stdcall, __fastcall -- > > > > > but oh well. We can live without __fastcall. > > > > > Watcom has another calling convention, "watcall", and they > let you > > > > > describe calling conventions with #pragmas, neat. > > > > > > > > > > Thanks, > > > > > - Jay > > > > > > > > > > Share life as it happens with the new Windows Live. Start > sharing! > > > > > > > > > > > > > Make distant family not so distant with Windows Vista? + Windows > > > Live?. Start now! > > > > > Watch ?Cause Effect,? a show about real people making a real > difference. Learn more From hosking at cs.purdue.edu Sun Jan 13 01:06:35 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 12 Jan 2008 19:06:35 -0500 Subject: [M3devel] could someone add __stdcall name mangling to m3cc please? In-Reply-To: References: Your message of "Wed, 09 Jan 2008 17:25:31 PST." <200801100131.m0A1VQYS034516@camembert.async.caltech.edu> <6D467648-44A7-48DC-AB8D-27B3AC19EBB0@cs.purdue.edu> Message-ID: <80BC3E7C-2DA6-4765-9053-A52950700404@cs.purdue.edu> It will need to be a little cleaner than that -- I'd rather gather the parameters as declared and enter them into the function type. It means not ignoring the parameter decls: see m3cg_declare_param check for current_param_count==0. To do this it needs to be a little bit smarter about managing current_function_decl -- probably a stack. On Jan 12, 2008, at 2:57 PM, Jay wrote: > Something like this????? > > =================================================================== > RCS file: /usr/cvs/cm3/m3-sys/m3cc/gcc/gcc/m3cg/parse.c,v > retrieving revision 1.41 > diff -r1.41 parse.c > 3066a3070 > > tree atypes = NULL_TREE); > 3091c3095,3102 > < TREE_TYPE (p) = build_function_type (return_type, NULL_TREE); > --- > > /* for NT386 __stdcall, we just need to declare the right number > > of parameters > > */ > > if (--n_params== 0) { > > atypes = tree_cons (NULL_TREE, t_word, atypes); > > } > > > > TREE_TYPE (p) = build_function_type (return_type, atypes); > > haven't even compiled it yet.. > > - Jay > > > > > > > > From: jayk123 at hotmail.com > > To: hosking at cs.purdue.edu > > Date: Sat, 12 Jan 2008 18:13:27 +0000 > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] could someone add __stdcall name mangling > to m3cc please? > > > > Tony, Sorry, I didn't mean to check those in. Those were wild > guesses that I hadn't tested yet.I put it back. Thanks for catching > that. > > > > - Jay > > > > > > > > > CC: m3devel at elegosoft.com> From: hosking at cs.purdue.edu> > Subject: Re: [M3devel] could someone add __stdcall name mangling to > m3cc please?> Date: Sat, 12 Jan 2008 10:41:26 -0500> To: > jayk123 at hotmail.com> > I'm not sure what you were trying to do with > parse.c by adding a > parameter (nargs*4) to the stdcall attribute, > but that probably > doesn't do anything interesting. The problem > appears to be because > on external function decls the parameter > decls are currently being > ignored by cm3cg. If I fix parse.c to > add the params for those then > it should work properly with the > stdcall attribute.> > On Jan 12, 2008, at 8:27 AM, Jay wrote:> > > > Thanks, but not quite. The number of parameters times four needs to > > > be appended to the name, in decimal.> > But I'm just getting > 0.> > That is, gcc is handling the underlying detail, but you > aren't > > giving it enough infomrmation.> > I'll see if I can bang > out those temporary wrappers automatically.. > > (a Quake > programming challenge, that I've already invented the hard > > part > of I think -- Quake can't do math..)> >> > - Jay> >> >> > > CC: > m3devel at elegosoft.com> > > From: hosking at cs.purdue.edu> > > > Subject: Re: [M3devel] could someone add __stdcall name mangling > > > to m3cc please?> > > Date: Fri, 11 Jan 2008 13:16:44 -0500> > > > To: jayk123 at hotmail.com> > >> > > I just added support for this. > Let me know if it seems to work (or> > > not! :-) ).> > >> > >> > > > On Jan 10, 2008, at 7:40 AM, Jay wrote:> > >> > > > Could someone > out there (Tony?) familiar with the gcc backend> > > > have it not > ignore call_conv and if call_conv is 1, append> > > > an at symbol > and the number of bytes of parameters to the function> > > > name?> > > > > (Even for zero, e.g. Sleep at 0, GetFileAttributes at 4).> > > > > This would be I guess at least for "imported" functions.> > > >> > > > > Not clear about calling function pointers, probably needs> > > > > modification.> > > > call_conv 0 is "__cdecl" is push right to > left, caller cleans up> > > > call_conv 1 is "__stdcall" is push > right to left, callee cleans up> > > > There are various synonyms.> > > > > With no command line switches, __cdecl is the compiler > default.> > > > __stdcall is deemed more efficient, and is very > widely used.> > > >> > > > Not clear about functions implemented in > Modula-3.> > > > Probably won't occur? Maybe for callbacks? > WindowProcs, thread> > > > entry point?> > > >> > > > This could/ > should be for NT386GNU only.> > > > The hypothetical other NT > targets only have one calling convention> > > > each.> > > >> > > > > I COULD do something sleazy here and generate little adapter> > > > > functions, over in m3-win/import-libs esp.> > > >> > > > I'm still > checking out pm3 to see what it does here.> > > > (as in cvs > checkout, not "looking at")> > > >> > > > This'll clear up:> > > >> > > > > RTOS.m3:27: undefined reference to `_FatalExit'> > > > > RTOS.mo: In function `RTOS__GetMemory':> > > > RTOS.m3:75: > undefined reference to `_VirtualAlloc'> > > > RTOS.m3:85: undefined > reference to `_VirtualAlloc'> > > > RTOS.mo: In function > `RTOS__InitMemory':> > > > RTOS.m3:96: undefined reference to > `_VirtualAlloc'> > > > RTOS.m3:100: undefined reference to > `_GetSystemInfo'> > > > RTOS.mo: In function `RTOS__Write':> > > > > RTOS.m3:118: undefined reference to `_AllocConsole'> > > > > RTOS.m3:119: undefined reference to `_GetStdHandle'> > > > > RTOS.m3:122: undefined reference to `_WriteFile'> > > > > RTPerfTool.mo: In function `RTPerfTool__Start':> > > > > RTPerfTool.m3:19: undefined reference to `_ReadFile'> > > > > RTPerfTool.m3:22: undefined reference to `_CloseHandle'> > > > > RTPerfTool.mo: In function `RTPerfTool__Close':> > > > > RTPerfTool.m3:28: undefined reference to `_CloseHandle'> > > > > RTPerfTool.mo: In function `RTPerfTool__Send':> > > > > RTPerfTool.m3:34: undefined reference to `_WriteFile'> > > > > RTPerfTool.mo: In function `RTPerfTool__PrepHandle':> > > > > RTPerfTool.m3:58: undefined reference to `_GetCurrentProcess'> > > > > RTPerfTool.m3:59: undefined reference to `_DuplicateHandle'> > > > > etc.> > > >> > > > I did think I was past these. I thought I > built m3core and libm3> > > > including linking (having even > modified cm3.cfg)> > > > COULD be I'm using the wrong .libs, but:> > > > >> > > > C:\cygwin\lib\w32api>nm libkernel32.a | findstr > CreateFile> > > > 00000000 I __imp__CreateFileW at 28> > > > 00000000 > T _CreateFileW at 28> > > > 00000000 I __imp__CreateFileMappingW at 24> > > > > 00000000 T _CreateFileMappingW at 24> > > > 00000000 I > __imp__CreateFileMappingA at 24> > > > 00000000 T > _CreateFileMappingA at 24> > > > 00000000 I __imp__CreateFileA at 28> > > > > 00000000 T _CreateFileA at 28> > > >> > > > C:\cygwin\lib\w32api>cd > \MinGW\lib> > > >> > > > C:\MinGW\lib>nm libkernel32.a | findstr > CreateFile> > > > 00000000 I __imp__CreateFileW at 28> > > > 00000000 > T _CreateFileW at 28> > > > 00000000 I __imp__CreateFileMappingW at 24> > > > > 00000000 T _CreateFileMappingW at 24> > > > 00000000 I > __imp__CreateFileMappingA at 24> > > > 00000000 T > _CreateFileMappingA at 24> > > > 00000000 I __imp__CreateFileA at 28> > > > > 00000000 T _CreateFileA at 28> > > >> > > > I think at least THREE > calling conventions should be supported --> > > > __cdecl, > __stdcall, __fastcall --> > > > but oh well. We can live without > __fastcall.> > > > Watcom has another calling convention, > "watcall", and they let you> > > > describe calling conventions > with #pragmas, neat.> > > >> > > > Thanks,> > > > - Jay> > > >> > > > > Share life as it happens with the new Windows Live. Start sharing! > > > >> >> >> > Make distant family not so distant with Windows > Vista? + Windows > > Live?. Start now!> > > _________________________________________________________________ > > Watch ?Cause Effect,? a show about real people making a real > difference > > > Get the power of Windows + Web with the new Windows Live. Get it now! From jayk123 at hotmail.com Sun Jan 13 01:49:10 2008 From: jayk123 at hotmail.com (Jay) Date: Sun, 13 Jan 2008 00:49:10 +0000 Subject: [M3devel] could someone add __stdcall name mangling to m3cc please? In-Reply-To: <80BC3E7C-2DA6-4765-9053-A52950700404@cs.purdue.edu> References: Your message of "Wed, 09 Jan 2008 17:25:31 PST." <200801100131.m0A1VQYS034516@camembert.async.caltech.edu> <6D467648-44A7-48DC-AB8D-27B3AC19EBB0@cs.purdue.edu> <80BC3E7C-2DA6-4765-9053-A52950700404@cs.purdue.edu> Message-ID: I commited something LIKE this, that lets m3core.dll link. (The below had several errors. Failing to loop, failing to terminate the list correctly, only getting function pointers or functions instead of both, for some reason the Windows *.i3 files use a mix.) libm3.dll has a boring pathname format problem, ld doesn't like c:\foo\../bar.lib and I got sidetracked.. It MIGHT not work for SOME functions, a link error -- if taking __int64 or small structs by value, in a __stdcall function. I'll see if that comes up as I progress through the system slowly. - Jay > CC: m3devel at elegosoft.com> From: hosking at cs.purdue.edu> Subject: Re: [M3devel] could someone add __stdcall name mangling to m3cc please?> Date: Sat, 12 Jan 2008 19:06:35 -0500> To: jayk123 at hotmail.com> > It will need to be a little cleaner than that -- I'd rather gather > the parameters as declared and enter them into the function type. It > means not ignoring the parameter decls: see m3cg_declare_param check > for current_param_count==0. To do this it needs to be a little bit > smarter about managing current_function_decl -- probably a stack.> > On Jan 12, 2008, at 2:57 PM, Jay wrote:> > > Something like this?????> >> > ===================================================================> > RCS file: /usr/cvs/cm3/m3-sys/m3cc/gcc/gcc/m3cg/parse.c,v> > retrieving revision 1.41> > diff -r1.41 parse.c> > 3066a3070> > > tree atypes = NULL_TREE);> > 3091c3095,3102> > < TREE_TYPE (p) = build_function_type (return_type, NULL_TREE);> > ---> > > /* for NT386 __stdcall, we just need to declare the right number> > > of parameters> > > */> > > if (--n_params== 0) {> > > atypes = tree_cons (NULL_TREE, t_word, atypes);> > > }> > >> > > TREE_TYPE (p) = build_function_type (return_type, atypes);> >> > haven't even compiled it yet..> >> > - Jay> >> >> >> >> >> >> > > From: jayk123 at hotmail.com> > > To: hosking at cs.purdue.edu> > > Date: Sat, 12 Jan 2008 18:13:27 +0000> > > CC: m3devel at elegosoft.com> > > Subject: Re: [M3devel] could someone add __stdcall name mangling > > to m3cc please?> > >> > > Tony, Sorry, I didn't mean to check those in. Those were wild > > guesses that I hadn't tested yet.I put it back. Thanks for catching > > that.> > >> > > - Jay> > >> > >> > >> > > > CC: m3devel at elegosoft.com> From: hosking at cs.purdue.edu> > > Subject: Re: [M3devel] could someone add __stdcall name mangling to > > m3cc please?> Date: Sat, 12 Jan 2008 10:41:26 -0500> To: > > jayk123 at hotmail.com> > I'm not sure what you were trying to do with > > parse.c by adding a > parameter (nargs*4) to the stdcall attribute, > > but that probably > doesn't do anything interesting. The problem > > appears to be because > on external function decls the parameter > > decls are currently being > ignored by cm3cg. If I fix parse.c to > > add the params for those then > it should work properly with the > > stdcall attribute.> > On Jan 12, 2008, at 8:27 AM, Jay wrote:> > > > > Thanks, but not quite. The number of parameters times four needs to > > > > be appended to the name, in decimal.> > But I'm just getting > > 0.> > That is, gcc is handling the underlying detail, but you > > aren't > > giving it enough infomrmation.> > I'll see if I can bang > > out those temporary wrappers automatically.. > > (a Quake > > programming challenge, that I've already invented the hard > > part > > of I think -- Quake can't do math..)> >> > - Jay> >> >> > > CC: > > m3devel at elegosoft.com> > > From: hosking at cs.purdue.edu> > > > > Subject: Re: [M3devel] could someone add __stdcall name mangling > > > > to m3cc please?> > > Date: Fri, 11 Jan 2008 13:16:44 -0500> > > > > To: jayk123 at hotmail.com> > >> > > I just added support for this. > > Let me know if it seems to work (or> > > not! :-) ).> > >> > >> > > > > On Jan 10, 2008, at 7:40 AM, Jay wrote:> > >> > > > Could someone > > out there (Tony?) familiar with the gcc backend> > > > have it not > > ignore call_conv and if call_conv is 1, append> > > > an at symbol > > and the number of bytes of parameters to the function> > > > name?> > > > > > (Even for zero, e.g. Sleep at 0, GetFileAttributes at 4).> > > > > > This would be I guess at least for "imported" functions.> > > >> > > > > > Not clear about calling function pointers, probably needs> > > > > > modification.> > > > call_conv 0 is "__cdecl" is push right to > > left, caller cleans up> > > > call_conv 1 is "__stdcall" is push > > right to left, callee cleans up> > > > There are various synonyms.> > > > > > With no command line switches, __cdecl is the compiler > > default.> > > > __stdcall is deemed more efficient, and is very > > widely used.> > > >> > > > Not clear about functions implemented in > > Modula-3.> > > > Probably won't occur? Maybe for callbacks? > > WindowProcs, thread> > > > entry point?> > > >> > > > This could/ > > should be for NT386GNU only.> > > > The hypothetical other NT > > targets only have one calling convention> > > > each.> > > >> > > > > > I COULD do something sleazy here and generate little adapter> > > > > > functions, over in m3-win/import-libs esp.> > > >> > > > I'm still > > checking out pm3 to see what it does here.> > > > (as in cvs > > checkout, not "looking at")> > > >> > > > This'll clear up:> > > >> > > > > > RTOS.m3:27: undefined reference to `_FatalExit'> > > > > > RTOS.mo: In function `RTOS__GetMemory':> > > > RTOS.m3:75: > > undefined reference to `_VirtualAlloc'> > > > RTOS.m3:85: undefined > > reference to `_VirtualAlloc'> > > > RTOS.mo: In function > > `RTOS__InitMemory':> > > > RTOS.m3:96: undefined reference to > > `_VirtualAlloc'> > > > RTOS.m3:100: undefined reference to > > `_GetSystemInfo'> > > > RTOS.mo: In function `RTOS__Write':> > > > > > RTOS.m3:118: undefined reference to `_AllocConsole'> > > > > > RTOS.m3:119: undefined reference to `_GetStdHandle'> > > > > > RTOS.m3:122: undefined reference to `_WriteFile'> > > > > > RTPerfTool.mo: In function `RTPerfTool__Start':> > > > > > RTPerfTool.m3:19: undefined reference to `_ReadFile'> > > > > > RTPerfTool.m3:22: undefined reference to `_CloseHandle'> > > > > > RTPerfTool.mo: In function `RTPerfTool__Close':> > > > > > RTPerfTool.m3:28: undefined reference to `_CloseHandle'> > > > > > RTPerfTool.mo: In function `RTPerfTool__Send':> > > > > > RTPerfTool.m3:34: undefined reference to `_WriteFile'> > > > > > RTPerfTool.mo: In function `RTPerfTool__PrepHandle':> > > > > > RTPerfTool.m3:58: undefined reference to `_GetCurrentProcess'> > > > > > RTPerfTool.m3:59: undefined reference to `_DuplicateHandle'> > > > > > etc.> > > >> > > > I did think I was past these. I thought I > > built m3core and libm3> > > > including linking (having even > > modified cm3.cfg)> > > > COULD be I'm using the wrong .libs, but:> > > > > >> > > > C:\cygwin\lib\w32api>nm libkernel32.a | findstr > > CreateFile> > > > 00000000 I __imp__CreateFileW at 28> > > > 00000000 > > T _CreateFileW at 28> > > > 00000000 I __imp__CreateFileMappingW at 24> > > > > > 00000000 T _CreateFileMappingW at 24> > > > 00000000 I > > __imp__CreateFileMappingA at 24> > > > 00000000 T > > _CreateFileMappingA at 24> > > > 00000000 I __imp__CreateFileA at 28> > > > > > 00000000 T _CreateFileA at 28> > > >> > > > C:\cygwin\lib\w32api>cd > > \MinGW\lib> > > >> > > > C:\MinGW\lib>nm libkernel32.a | findstr > > CreateFile> > > > 00000000 I __imp__CreateFileW at 28> > > > 00000000 > > T _CreateFileW at 28> > > > 00000000 I __imp__CreateFileMappingW at 24> > > > > > 00000000 T _CreateFileMappingW at 24> > > > 00000000 I > > __imp__CreateFileMappingA at 24> > > > 00000000 T > > _CreateFileMappingA at 24> > > > 00000000 I __imp__CreateFileA at 28> > > > > > 00000000 T _CreateFileA at 28> > > >> > > > I think at least THREE > > calling conventions should be supported --> > > > __cdecl, > > __stdcall, __fastcall --> > > > but oh well. We can live without > > __fastcall.> > > > Watcom has another calling convention, > > "watcall", and they let you> > > > describe calling conventions > > with #pragmas, neat.> > > >> > > > Thanks,> > > > - Jay> > > >> > > > > > Share life as it happens with the new Windows Live. Start sharing! > > > > >> >> >> > Make distant family not so distant with Windows > > Vista? + Windows > > Live?. Start now!>> > > _________________________________________________________________> > > Watch ?Cause Effect,? a show about real people making a real > > difference> >> >> > Get the power of Windows + Web with the new Windows Live. Get it now!> _________________________________________________________________ Watch ?Cause Effect,? a show about real people making a real difference. http://im.live.com/Messenger/IM/MTV/?source=text_watchcause -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Jan 13 01:51:15 2008 From: jay.krell at cornell.edu (Jay) Date: Sun, 13 Jan 2008 00:51:15 +0000 Subject: [M3devel] could someone add __stdcall name mangling to m3cc please? In-Reply-To: <80BC3E7C-2DA6-4765-9053-A52950700404@cs.purdue.edu> References: Your message of "Wed, 09 Jan 2008 17:25:31 PST." <200801100131.m0A1VQYS034516@camembert.async.caltech.edu> <6D467648-44A7-48DC-AB8D-27B3AC19EBB0@cs.purdue.edu> <80BC3E7C-2DA6-4765-9053-A52950700404@cs.purdue.edu> Message-ID: > current_param_count Must this code use globals? - Jay From: jayk123 at hotmail.comTo: hosking at cs.purdue.eduCC: m3devel at elegosoft.comSubject: RE: [M3devel] could someone add __stdcall name mangling to m3cc please?Date: Sun, 13 Jan 2008 00:49:10 +0000 I commited something LIKE this, that lets m3core.dll link. (The below had several errors. Failing to loop, failing to terminate the list correctly, only getting function pointers or functions instead of both, for some reason the Windows *.i3 files use a mix.) libm3.dll has a boring pathname format problem, ld doesn't like c:\foo\../bar.lib and I got sidetracked.. It MIGHT not work for SOME functions, a link error -- if taking __int64 or small structs by value, in a __stdcall function.I'll see if that comes up as I progress through the system slowly. - Jay > CC: m3devel at elegosoft.com> From: hosking at cs.purdue.edu> Subject: Re: [M3devel] could someone add __stdcall name mangling to m3cc please?> Date: Sat, 12 Jan 2008 19:06:35 -0500> To: jayk123 at hotmail.com> > It will need to be a little cleaner than that -- I'd rather gather > the parameters as declared and enter them into the function type. It > means not ignoring the parameter decls: see m3cg_declare_param check > for current_param_count==0. To do this it needs to be a little bit > smarter about managing current_function_decl -- probably a stack.> > On Jan 12, 2008, at 2:57 PM, Jay wrote:> > > Something like this?????> >> > ===================================================================> > RCS file: /usr/cvs/cm3/m3-sys/m3cc/gcc/gcc/m3cg/parse.c,v> > retrieving revision 1.41> > diff -r1.41 parse.c> > 3066a3070> > > tree atypes = NULL_TREE);> > 3091c3095,3102> > < TREE_TYPE (p) = build_function_type (return_type, NULL_TREE);> > ---> > > /* for NT386 __stdcall, we just need to declare the right number> > > of parameters> > > */> > > if (--n_params== 0) {> > > atypes = tree_cons (NULL_TREE, t_word, atypes);> > > }> > >> > > TREE_TYPE (p) = build_function_type (return_type, atypes);> >> > haven't even compiled it yet..> >> > - Jay> >> >> >> >> >> >> > > From: jayk123 at hotmail.com> > > To: hosking at cs.purdue.edu> > > Date: Sat, 12 Jan 2008 18:13:27 +0000> > > CC: m3devel at elegosoft.com> > > Subject: Re: [M3devel] could someone add __stdcall name mangling > > to m3cc please?> > >> > > Tony, Sorry, I didn't mean to check those in. Those were wild > > guesses that I hadn't tested yet.I put it back. Thanks for catching > > that.> > >> > > - Jay> > >> > >> > >> > > > CC: m3devel at elegosoft.com> From: hosking at cs.purdue.edu> > > Subject: Re: [M3devel] could someone add __stdcall name mangling to > > m3cc please?> Date: Sat, 12 Jan 2008 10:41:26 -0500> To: > > jayk123 at hotmail.com> > I'm not sure what you were trying to do with > > parse.c by adding a > parameter (nargs*4) to the stdcall attribute, > > but that probably > doesn't do anything interesting. The problem > > appears to be because > on external function decls the parameter > > decls are currently being > ignored by cm3cg. If I fix parse.c to > > add the params for those then > it should work properly with the > > stdcall attribute.> > On Jan 12, 2008, at 8:27 AM, Jay wrote:> > > > > Thanks, but not quite. The number of parameters times four needs to > > > > be appended to the name, in decimal.> > But I'm just getting > > 0.> > That is, gcc is handling the underlying detail, but you > > aren't > > giving it enough infomrmation.> > I'll see if I can bang > > out those temporary wrappers automatically.. > > (a Quake > > programming challenge, that I've already invented the hard > > part > > of I think -- Quake can't do math..)> >> > - Jay> >> >> > > CC: > > m3devel at elegosoft.com> > > From: hosking at cs.purdue.edu> > > > > Subject: Re: [M3devel] could someone add __stdcall name mangling > > > > to m3cc please?> > > Date: Fri, 11 Jan 2008 13:16:44 -0500> > > > > To: jayk123 at hotmail.com> > >> > > I just added support for this. > > Let me know if it seems to work (or> > > not! :-) ).> > >> > >> > > > > On Jan 10, 2008, at 7:40 AM, Jay wrote:> > >> > > > Could someone > > out there (Tony?) familiar with the gcc backend> > > > have it not > > ignore call_conv and if call_conv is 1, append> > > > an at symbol > > and the number of bytes of parameters to the function> > > > name?> > > > > > (Even for zero, e.g. Sleep at 0, GetFileAttributes at 4).> > > > > > This would be I guess at least for "imported" functions.> > > >> > > > > > Not clear about calling function pointers, probably needs> > > > > > modification.> > > > call_conv 0 is "__cdecl" is push right to > > left, caller cleans up> > > > call_conv 1 is "__stdcall" is push > > right to left, callee cleans up> > > > There are various synonyms.> > > > > > With no command line switches, __cdecl is the compiler > > default.> > > > __stdcall is deemed more efficient, and is very > > widely used.> > > >> > > > Not clear about functions implemented in > > Modula-3.> > > > Probably won't occur? Maybe for callbacks? > > WindowProcs, thread> > > > entry point?> > > >> > > > This could/ > > should be for NT386GNU only.> > > > The hypothetical other NT > > targets only have one calling convention> > > > each.> > > >> > > > > > I COULD do something sleazy here and generate little adapter> > > > > > functions, over in m3-win/import-libs esp.> > > >> > > > I'm still > > checking out pm3 to see what it does here.> > > > (as in cvs > > checkout, not "looking at")> > > >> > > > This'll clear up:> > > >> > > > > > RTOS.m3:27: undefined reference to `_FatalExit'> > > > > > RTOS.mo: In function `RTOS__GetMemory':> > > > RTOS.m3:75: > > undefined reference to `_VirtualAlloc'> > > > RTOS.m3:85: undefined > > reference to `_VirtualAlloc'> > > > RTOS.mo: In function > > `RTOS__InitMemory':> > > > RTOS.m3:96: undefined reference to > > `_VirtualAlloc'> > > > RTOS.m3:100: undefined reference to > > `_GetSystemInfo'> > > > RTOS.mo: In function `RTOS__Write':> > > > > > RTOS.m3:118: undefined reference to `_AllocConsole'> > > > > > RTOS.m3:119: undefined reference to `_GetStdHandle'> > > > > > RTOS.m3:122: undefined reference to `_WriteFile'> > > > > > RTPerfTool.mo: In function `RTPerfTool__Start':> > > > > > RTPerfTool.m3:19: undefined reference to `_ReadFile'> > > > > > RTPerfTool.m3:22: undefined reference to `_CloseHandle'> > > > > > RTPerfTool.mo: In function `RTPerfTool__Close':> > > > > > RTPerfTool.m3:28: undefined reference to `_CloseHandle'> > > > > > RTPerfTool.mo: In function `RTPerfTool__Send':> > > > > > RTPerfTool.m3:34: undefined reference to `_WriteFile'> > > > > > RTPerfTool.mo: In function `RTPerfTool__PrepHandle':> > > > > > RTPerfTool.m3:58: undefined reference to `_GetCurrentProcess'> > > > > > RTPerfTool.m3:59: undefined reference to `_DuplicateHandle'> > > > > > etc.> > > >> > > > I did think I was past these. I thought I > > built m3core and libm3> > > > including linking (having even > > modified cm3.cfg)> > > > COULD be I'm using the wrong .libs, but:> > > > > >> > > > C:\cygwin\lib\w32api>nm libkernel32.a | findstr > > CreateFile> > > > 00000000 I __imp__CreateFileW at 28> > > > 00000000 > > T _CreateFileW at 28> > > > 00000000 I __imp__CreateFileMappingW at 24> > > > > > 00000000 T _CreateFileMappingW at 24> > > > 00000000 I > > __imp__CreateFileMappingA at 24> > > > 00000000 T > > _CreateFileMappingA at 24> > > > 00000000 I __imp__CreateFileA at 28> > > > > > 00000000 T _CreateFileA at 28> > > >> > > > C:\cygwin\lib\w32api>cd > > \MinGW\lib> > > >> > > > C:\MinGW\lib>nm libkernel32.a | findstr > > CreateFile> > > > 00000000 I __imp__CreateFileW at 28> > > > 00000000 > > T _CreateFileW at 28> > > > 00000000 I __imp__CreateFileMappingW at 24> > > > > > 00000000 T _CreateFileMappingW at 24> > > > 00000000 I > > __imp__CreateFileMappingA at 24> > > > 00000000 T > > _CreateFileMappingA at 24> > > > 00000000 I __imp__CreateFileA at 28> > > > > > 00000000 T _CreateFileA at 28> > > >> > > > I think at least THREE > > calling conventions should be supported --> > > > __cdecl, > > __stdcall, __fastcall --> > > > but oh well. We can live without > > __fastcall.> > > > Watcom has another calling convention, > > "watcall", and they let you> > > > describe calling conventions > > with #pragmas, neat.> > > >> > > > Thanks,> > > > - Jay> > > >> > > > > > Share life as it happens with the new Windows Live. Start sharing! > > > > >> >> >> > Make distant family not so distant with Windows > > Vista? + Windows > > Live?. Start now!>> > > _________________________________________________________________> > > Watch ?Cause Effect,? a show about real people making a real > > difference> >> >> > Get the power of Windows + Web with the new Windows Live. Get it now!> Watch ?Cause Effect,? a show about real people making a real difference. Learn more _________________________________________________________________ Watch ?Cause Effect,? a show about real people making a real difference. http://im.live.com/Messenger/IM/MTV/?source=text_watchcause -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Sun Jan 13 16:05:23 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Sun, 13 Jan 2008 16:05:23 +0100 Subject: [M3devel] M3 concerns In-Reply-To: <20080105143235.ujed2tl3ksogws8k@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> Message-ID: <20080113160523.7ih7rpkusogsook8@mail.elegosoft.com> Quoting myself: > Discussions seem to loose their focus quiet easy on this list :-/ It might seem that I've scared everybody away from further discussing, or indeed nobody else is interested in this topic. As I'd promised to write a resume, here are some comments / suggestions: > How do we need to improve > the CM3 development process to ensure and increase the overall quality > of the CM3 code base? Could everybody interested in this discussion > please just comment on the following items to state his opinion: > > 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). > > Technical details should be discussed in a different thread. There has been some progress on CM3 regression test automation. The tinderbox setup by Kaspar is working and quite usable, though some things still need to be improved or fixed. Have a look at http://tinderbox.elegosoft.com/tinderbox/cm3/status.html to view the current build results (from FreeBSD and Linux systems; two test runs every day for every platform). We're now at the stage that others could contribute their daily build results, so that the platform coverage gets better. Some details (mostly security related) still have to be resolved (with out administrators); I'll follow up on this in a separate mail. I've also invested a considerable amount of time to review all the failures and problems in the m3-sys/m3tests regression test package, which is now run as part of the daily tests. The short result is that there still _are_ several problems with the current compiler and/or runtime which may need attention. I'll post another summary for this; volunteers for closer inspection are welcome. > o Do we need / want to restrict the commit access for the CM3 > code repositories? > > If so, only for certain areas, or for everything? This would > be a distinction based on packages. > > Should we allow or prefer committing new code to branches and > merge the resulting change sets based on reviews? (I could also > contribute automatic support for creating change sets on branches, > as this is part of the DCVS functionality elego developed some time > ago). This would be a distinction based on code lines. > > Yesterday I had the impression that some members of this list > would prefer some access restriction, but I'm not really sure. As there have been no more comments / opninions I'd suggest that we leave things as they currently are, unless there are good objections to this. > o I'm not sure if and how we should include the Windows target > problems here. They were part of the original mail, but seem > to belong to another category to me, at least have different > causes. Suggestions what exactly to discuss are welcome. I don't know if Randy was successful in getting the current CM3 system to run on Windows; some problems and solutions have been posted to m3devel since last week. There also seems to be progress in resurrecting the NT386GNU target, but this is obviously work in progress. So far for this (intermediate?) summary of CM3 QA :-) Please let me know what you think about the recent additions and changes, Olaf PS: I won't be able to continue to spare as much time on CM3 as I've done during the last three weeks, so I'd like to encourage everybody who'd like to help, improve or take responsibility for (some of) the started tasks. -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Jan 14 00:36:40 2008 From: jayk123 at hotmail.com (Jay) Date: Sun, 13 Jan 2008 23:36:40 +0000 Subject: [M3devel] religion, philosophy, Posix vs. Win32 In-Reply-To: <280102.76351.qm@web27105.mail.ukl.yahoo.com> References: <280102.76351.qm@web27105.mail.ukl.yahoo.com> Message-ID: The conclusion here is: Just try to convince me otherwise. :) The gist of the question is: Just what characteristics of "Posix" and "Win32" should "NT386GNU" have? Just what characteristics of "Posix" do people notice and like? You can't say "the whole thing". :) Restated: What is Posix? I don't mean, where is the standard document web site. I mean what is it TO YOU? Is it open/read/write/close? Is it fork? Is it sbrk? On these previous ones, they are interesting to many programmers, but Modula-3 already layers over all this, so these are unlikely defining characteristics here. Is it sh? Probably somewhat. But if have you sat in Cygwin sh much vs. cmd? It is annoying. Command line history is flaky. Paths are munged to say /cygdrive. You lose the critical F8 command line completion against history feature. You lose a lot of editing capability, but do gain some alternate possibly "portable" similar. Is it Perl? No. Is it X Windows. I doubt it. Is it pthreads? Probably not. Or at least vtalarm? Maybe? Or setjmp/longjmp? Ok. Longjmp to the same buffer multiple times? Not likely. Longjmp to a place that has already returned? Not likely. All full paths starting with a forward slash? Maybe. Backward slash being a valid non-seperator path character? Maybe. Think about that last one. It is valid and occurs in Win32 code to treat forward slash and backward slash the same. Some code does, some code does not. What if you just did that unconditionally, like even in Posix? What is the role of backward slash in Posix paths? It either just doesn't occur, or is an escape character, or is a regular character. Something at a low level could replace the backward slashes with forward slashes. I would like to change the code in m3-sys/cm3/m3path.m3 to treat backward slashes and forward slashes the same. Backward slashes just won't occur on Posix, right? So far I have managed without this change, but not having it has bitten me a few times. I do have the analogous change to the Win32 path code in m3core. It is the redundant filenames libfoo.a instead of foo.lib and libfoo.so instead of foo.so? Perhaps. This seems dumb, redundant to me. Why have prefixes and suffixes? Don't suffixes suffice? That all said, I remain convinced that a useful intermediate or probably endpoint is a toolset that targets Windows using cm3cg, ld, as, but otherwise looks like NT386 as much as possible. MAYBE alter the library names to libfoo.*. sh and make are needed for building cm3cg. I did use Cygwin for that. MinGWin sounds promising here too but I haven't tried. - Jay _________________________________________________________________ Get the power of Windows + Web with the new Windows Live. http://www.windowslive.com?ocid=TXT_TAGHM_Wave2_powerofwindows_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Mon Jan 14 00:43:41 2008 From: jayk123 at hotmail.com (Jay) Date: Sun, 13 Jan 2008 23:43:41 +0000 Subject: [M3devel] dynamic linking, stanalone()? In-Reply-To: <280102.76351.qm@web27105.mail.ukl.yahoo.com> References: <280102.76351.qm@web27105.mail.ukl.yahoo.com> Message-ID: Dynamic linking vs. "standalone". How does that work? On Posix, with ld, etc.? I understand fully how it works on NT386 and will explain, as a jumping off point for explanation and analogies. Windows has "import .libs" and regular old "static .libs". In reality it has import .objs and regular .objs, and a .lib is a collection of .objs, and can contain a mix, but this is not well known. Usually a .lib only has all one type or all the other type. Actually older import .libs are just kind of wierd and drive the linker in odd roundabout ways that end up doing the right thing, I guess without the linker knowing much. Current Cygwin/Mingwin ld/dlltool import libs I think are still odd. And large. And besides, they seem buggy but tht's a tangent. Look at msvcrt.lib. It contains static startup code and imports. There is no seperate crt0.o file on Windows. USUALLY people only build one .lib type or another. However the Modula-3 system has a clever innovation. It always builds both. This retains flexibility in how the clients are built. cm3.exe links to m3core/libm3 statically, most other folks dynamically. It is ROUGHLY like so: lib /out:foo.lib.sa objects... sa for standalone link /out:foo.dll objects... as a by-product of the link, foo.lib an import .lib is produced When you go to link, you give the linker, well, let's say, full paths. To foo.lib or foo.lib.sa, or whatever mix. (or leaf only paths and the LIB environment variable is searched, kind of like $PATH) In "Posix" I know there is foo.a and foo.so. But an .so is a .dll. An .a is? Either? And the third one is? To some extent, no matter. I THINK it goes like this for Cygwin/MinGWin: ar foo.lib.sa objects ld -o foo.dll --out-imlib foo.lib but it's not quite working for me currently. I'm backtracking to get to an earlier version of my config file that was. I should probably break down and use dlltool. And I can read the docs, of course. I do so. And search the web. I have avoided using anything that isn't already a configuration variable. That is, I use gcc instead of ld for example. This is dumb of me I realize. ld gave me fits also on MacOSX but on Windows it should be more viable, fewer arcane details as to what to link in. e.g. I believe on "Posix", the entry point of a file is whatever .o is linked first. Chose carefully. On Windows it is seperately specified and the order of the link command doesn't affect it (though still has other subtle affects). And it is usually buried in a .lib, fewer files to chose between. - Jay _________________________________________________________________ Share life as it happens with the new Windows Live. http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Mon Jan 14 00:53:58 2008 From: jayk123 at hotmail.com (Jay) Date: Sun, 13 Jan 2008 23:53:58 +0000 Subject: [M3devel] dynamic linking, stanalone()? In-Reply-To: References: <280102.76351.qm@web27105.mail.ukl.yahoo.com> Message-ID: Nevermind, I'll figure it out. I am going to try dlltool. Currently it SEEMS like references are to _Foo but defintions are Foo. Of course, leading underscores always confuse. Sometimes they are added, sometimes they are removed, sometimes they must match. It stinks a little bit. At least on x86 Windows. Usually it is well hidden. COULD be a disagreement between Cygwin cm3cg and mingwin as/ld..though given that things were working..I don't know. I should try the mingwin sh/make/sed... - Jay From: jayk123 at hotmail.com To: m3devel at elegosoft.com Date: Sun, 13 Jan 2008 23:43:41 +0000 Subject: [M3devel] dynamic linking, stanalone()? Dynamic linking vs. "standalone". How does that work? On Posix, with ld, etc.? I understand fully how it works on NT386 and will explain, as a jumping off point for explanation and analogies. Windows has "import .libs" and regular old "static .libs". In reality it has import .objs and regular .objs, and a .lib is a collection of .objs, and can contain a mix, but this is not well known. Usually a .lib only has all one type or all the other type. Actually older import .libs are just kind of wierd and drive the linker in odd roundabout ways that end up doing the right thing, I guess without the linker knowing much. Current Cygwin/Mingwin ld/dlltool import libs I think are still odd. And large. And besides, they seem buggy but tht's a tangent. Look at msvcrt.lib. It contains static startup code and imports. There is no seperate crt0.o file on Windows. USUALLY people only build one .lib type or another. However the Modula-3 system has a clever innovation. It always builds both. This retains flexibility in how the clients are built. cm3.exe links to m3core/libm3 statically, most other folks dynamically. It is ROUGHLY like so: lib /out:foo.lib.sa objects... sa for standalone link /out:foo.dll objects... as a by-product of the link, foo.lib an import .lib is produced When you go to link, you give the linker, well, let's say, full paths. To foo.lib or foo.lib.sa, or whatever mix. (or leaf only paths and the LIB environment variable is searched, kind of like $PATH) In "Posix" I know there is foo.a and foo.so. But an .so is a .dll. An .a is? Either? And the third one is? To some extent, no matter. I THINK it goes like this for Cygwin/MinGWin: ar foo.lib.sa objects ld -o foo.dll --out-imlib foo.lib but it's not quite working for me currently. I'm backtracking to get to an earlier version of my config file that was. I should probably break down and use dlltool. And I can read the docs, of course. I do so. And search the web. I have avoided using anything that isn't already a configuration variable. That is, I use gcc instead of ld for example. This is dumb of me I realize. ld gave me fits also on MacOSX but on Windows it should be more viable, fewer arcane details as to what to link in. e.g. I believe on "Posix", the entry point of a file is whatever .o is linked first. Chose carefully. On Windows it is seperately specified and the order of the link command doesn't affect it (though still has other subtle affects). And it is usually buried in a .lib, fewer files to chose between. - Jay Share life as it happens with the new Windows Live. Start sharing! _________________________________________________________________ Put your friends on the big screen with Windows Vista? + Windows Live?. http://www.microsoft.com/windows/shop/specialoffers.mspx?ocid=TXT_TAGLM_CPC_MediaCtr_bigscreen_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon Jan 14 01:13:17 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 13 Jan 2008 19:13:17 -0500 Subject: [M3devel] religion, philosophy, Posix vs. Win32 In-Reply-To: References: <280102.76351.qm@web27105.mail.ukl.yahoo.com> Message-ID: I really don't know enough about Windows to answer these questions properly. My take on it is: since Cygwin is intended to give a Linux-like environment on Windows, then it should behave more like a Linux system than a Windows system. That is, CM3 will look like it is running on some (strange) flavor of Linux. That said, the threading sub-system might be implemented as ThreadWin32 instead of ThreadPosix just to get system-level thread scheduling (ie, good for multi-core), similarly to the way ThreadPThread is used on some POSIX targets. The rest of things with Cygwin should behave like any other POSIX target. Perhaps someone else out there with better Windows knowledge can respond more intelligently than I have. On Jan 13, 2008, at 6:36 PM, Jay wrote: > The conclusion here is: > Just try to convince me otherwise. :) > > The gist of the question is: > Just what characteristics of "Posix" and "Win32" should > "NT386GNU" have? > > Just what characteristics of "Posix" do people notice and like? > You can't say "the whole thing". :) > > Restated: > > What is Posix? I don't mean, where is the standard document web site. > I mean what is it TO YOU? > > Is it open/read/write/close? > Is it fork? > Is it sbrk? > On these previous ones, they are interesting to many programmers, > but Modula-3 already layers over all this, so these are unlikely > defining > characteristics here. > > Is it sh? Probably somewhat. But if have you sat in Cygwin sh much > vs. cmd? > It is annoying. Command line history is flaky. Paths are munged to > say /cygdrive. > You lose the critical F8 command line completion against history > feature. > You lose a lot of editing capability, but do gain some alternate > possibly "portable" > similar. > > Is it Perl? No. > Is it X Windows. I doubt it. > Is it pthreads? Probably not. > Or at least vtalarm? Maybe? > Or setjmp/longjmp? Ok. > Longjmp to the same buffer multiple times? Not likely. > Longjmp to a place that has already returned? Not likely. > All full paths starting with a forward slash? Maybe. > Backward slash being a valid non-seperator path character? Maybe. > > Think about that last one. > It is valid and occurs in Win32 code to treat forward slash and > backward slash the same. > Some code does, some code does not. > What if you just did that unconditionally, like even in Posix? > What is the role of backward slash in Posix paths? It either just > doesn't occur, > or is an escape character, or is a regular character. Something at > a low level > could replace the backward slashes with forward slashes. > > I would like to change the code in m3-sys/cm3/m3path.m3 to treat > backward slashes > and forward slashes the same. Backward slashes just won't occur on > Posix, right? > So far I have managed without this change, but not having it has > bitten me a few times. > I do have the analogous change to the Win32 path code in m3core. > > It is the redundant filenames libfoo.a instead of foo.lib and > libfoo.so instead of foo.so? > Perhaps. This seems dumb, redundant to me. Why have prefixes and > suffixes? > Don't suffixes suffice? > > That all said, I remain convinced that a useful intermediate or > probably endpoint > is a toolset that targets Windows using cm3cg, ld, as, but > otherwise looks like > NT386 as much as possible. MAYBE alter the library names to libfoo.*. > > sh and make are needed for building cm3cg. > I did use Cygwin for that. MinGWin sounds promising here too but I > haven't tried. > > - Jay > > > Get the power of Windows + Web with the new Windows Live. Get it now! From mika at async.caltech.edu Mon Jan 14 01:40:17 2008 From: mika at async.caltech.edu (Mika Nystrom) Date: Sun, 13 Jan 2008 16:40:17 -0800 Subject: [M3devel] religion, philosophy, Posix vs. Win32 In-Reply-To: Your message of "Sun, 13 Jan 2008 23:36:40 GMT." Message-ID: <200801140040.m0E0eHs7046272@camembert.async.caltech.edu> Jay, I don't know if this is completely responsive to your question, and take it with a grain of salt because I have never programmed on a "pure" Windows system (and God willing, I never shall). I expect the NT386GNU target, Cygwin, Windows-POSIX, whatever you call it, to look as much as Unix "as possible." (Obviously not, but as "reasonable".) The main things are (1) yes, /bin/sh, and (2) Unix (POSIX?) libc---Modula-3 does a good job of covering up the basic stuff so you don't need to worry about it for the most part, but sometimes, just sometimes, you need to get, say, some system information that doesn't have an existing M3 interface (say the amount of free diskspace or something like that). Then you should be able to call C code that is portable between Unix and Windows. One thing that is bizarre about the old NT386GNU PM3 that doesn't conform to the above description: it uses Windows Time.T. It's all the more bizarre because Cygwin uses Unix time_t. (Time.Now and time(3) are off by a couple of hundred years on NT386GNU, whereas they are the same on all Unixes.) I am sure there are other things. Oh yes, the open-file (default) locking semantics are different too. Those two are actually the only differences that I noticed in the programming environments. Mika Jay writes: >--_d0659847-2f20-454a-9665-5df3b5ce2832_ >Content-Type: text/plain; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > >The conclusion here is: > Just try to convince me otherwise. :) > >The gist of the question is: > Just what characteristics of "Posix" and "Win32" should "NT386GNU" have? > > Just what characteristics of "Posix" do people notice and like? >You can't say "the whole thing". :) > >Restated: > >What is Posix? I don't mean, where is the standard document web site. >I mean what is it TO YOU? > >Is it open/read/write/close? >Is it fork? >Is it sbrk? > On these previous ones, they are interesting to many programmers, > but Modula-3 already layers over all this, so these are unlikely defining >characteristics here. > >Is it sh? Probably somewhat. But if have you sat in Cygwin sh much vs. cmd? > It is annoying. Command line history is flaky. Paths are munged to say /cy= >gdrive. > You lose the critical F8 command line completion against history feature. > You lose a lot of editing capability, but do gain some alternate possibly= > "portable" > similar. > >Is it Perl? No. >Is it X Windows. I doubt it. >Is it pthreads? Probably not. > Or at least vtalarm? Maybe? > Or setjmp/longjmp? Ok. > Longjmp to the same buffer multiple times? Not likely. > Longjmp to a place that has already returned? Not likely. >All full paths starting with a forward slash? Maybe. > Backward slash being a valid non-seperator path character? Maybe. > >Think about that last one. >It is valid and occurs in Win32 code to treat forward slash and backward sl= >ash the same. >Some code does, some code does not. >What if you just did that unconditionally, like even in Posix? >What is the role of backward slash in Posix paths? It either just doesn't o= >ccur, >or is an escape character, or is a regular character. Something at a low le= >vel >could replace the backward slashes with forward slashes. > >I would like to change the code in m3-sys/cm3/m3path.m3 to treat backward s= >lashes >and forward slashes the same. Backward slashes just won't occur on Posix, r= >ight? >So far I have managed without this change, but not having it has bitten me = >a few times. >I do have the analogous change to the Win32 path code in m3core. > >It is the redundant filenames libfoo.a instead of foo.lib and libfoo.so ins= >tead of foo.so? >Perhaps. This seems dumb, redundant to me. Why have prefixes and suffixes? >Don't suffixes suffice? > >That all said, I remain convinced that a useful intermediate or probably en= >dpoint >is a toolset that targets Windows using cm3cg, ld, as, but otherwise looks = >like >NT386 as much as possible. MAYBE alter the library names to libfoo.*. > >sh and make are needed for building cm3cg. >I did use Cygwin for that. MinGWin sounds promising here too but I haven't = >tried. > > - Jay > > >_________________________________________________________________ >Get the power of Windows + Web with the new Windows Live. >http://www.windowslive.com?ocid=3DTXT_TAGHM_Wave2_powerofwindows_012008= > >--_d0659847-2f20-454a-9665-5df3b5ce2832_ >Content-Type: text/html; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > > > > >The conclusion here is:
 Just try to conv= >ince me otherwise. :)

The gist of the question is:
  Just wh= >at characteristics of "Posix" and "Win32" should "NT386GNU" have?

&n= >bsp;Just what characteristics of "Posix" do people notice and like?
You = >can't say "the whole thing". :)

Restated:

What is Posix? I do= >n't mean, where is the standard document web site.
I mean what is it TO = >YOU?

Is it open/read/write/close?
Is it fork?
Is it sbrk?
&= >nbsp; On these previous ones, they are interesting to many programmers,
= > but Modula-3 already layers over all this, so these are unlikely defi= >ning
characteristics here.

Is it sh? Probably somewhat. But if ha= >ve you sat in Cygwin sh much vs. cmd?
 It is annoying. Command line= > history is flaky. Paths are munged to say /cygdrive.
 You lose the= > critical F8 command line completion against history feature.
  You= > lose a lot of editing capability, but do gain some alternate possibly "por= >table"
  similar.

Is it Perl? No.
Is it X Windows. I doub= >t it.
Is it pthreads? Probably not.
  Or at least vtalarm? Maybe= >?
  Or setjmp/longjmp? Ok.
    Longjmp to the sam= >e buffer multiple times? Not likely.
    Longjmp to a pla= >ce that has already returned? Not likely.
All full paths starting with a= > forward slash? Maybe.
  Backward slash being a valid non-seperator= > path character? Maybe.

Think about that last one.
It is valid an= >d occurs in Win32 code to treat forward slash and backward slash the same.<= >br>Some code does, some code does not.
What if you just did that uncondi= >tionally, like even in Posix?
What is the role of backward slash in Posi= >x paths? It either just doesn't occur,
or is an escape character, or is = >a regular character. Something at a low level
could replace the backward= > slashes with forward slashes.

I would like to change the code in m3= >-sys/cm3/m3path.m3 to treat backward slashes
and forward slashes the sam= >e. Backward slashes just won't occur on Posix, right?
So far I have mana= >ged without this change, but not having it has bitten me a few times.
I = >do have the analogous change to the Win32 path code in m3core.

It is= > the redundant filenames libfoo.a instead of foo.lib and libfoo.so instead = >of foo.so?
Perhaps. This seems dumb, redundant to me. Why have prefixes = >and suffixes?
Don't suffixes suffice?

That all said, I remain con= >vinced that a useful intermediate or probably endpoint
is a toolset that= > targets Windows using cm3cg, ld, as, but otherwise looks like
NT386 as = >much as possible. MAYBE alter the library names to libfoo.*.

sh and = >make are needed for building cm3cg.
I did use Cygwin for that. MinGWin s= >ounds promising here too but I haven't tried.

 - Jay

/>
Get the power of Windows + Web with the new Windows Live. =3D'http://www.windowslive.com?ocid=3DTXT_TAGHM_Wave2_powerofwindows_012008= >' target=3D'_new'>Get it now! >= > >--_d0659847-2f20-454a-9665-5df3b5ce2832_-- From jayk123 at hotmail.com Mon Jan 14 02:20:25 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 14 Jan 2008 01:20:25 +0000 Subject: [M3devel] "shared" vs. "standalone" Message-ID: I was experimenting with gcc/ld flags and I realized: There are two bits for shared/dynamic/standalone, sort of. It looks like cm3 only exposes one. They are: I am "shared", I am a .dll, I am an .so, code can link to me and "share" me. There is, I am "standalone", I have limited dependencies, I link to static .libs where possible, even if I am "shared". The same might not be true of my clients. AKA, same as previous, perhaps I am "dynamic" -- I link dynamically to stuff at runtime. IF I am dynamic, then my clients are. But if I am not, they might not be, and, actually, given CM3's provision for .sa files (on Windows at least), I can have it both ways. I can build a "dynamic" file and my clients can chose to use that or not. It looks like CM3 equates these.That is, you cannot build "standalone" .dlls/.sos..dlls/.sos are implicitly not standalone by virtue of being shared. - Jay _________________________________________________________________ Get the power of Windows + Web with the new Windows Live. http://www.windowslive.com?ocid=TXT_TAGHM_Wave2_powerofwindows_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Mon Jan 14 02:30:58 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 14 Jan 2008 01:30:58 +0000 Subject: [M3devel] religion, philosophy, Posix vs. Win32 In-Reply-To: <200801140040.m0E0eHs7046272@camembert.async.caltech.edu> References: Your message of "Sun, 13 Jan 2008 23:36:40 GMT." <200801140040.m0E0eHs7046272@camembert.async.caltech.edu> Message-ID: ok..well...some provision I guess eventually should be made for those who agree with you and Tony. What will come first is something else. :) A system that is Win32 as much as possible, EXCEPT that it uses the gcc-based backend, and as, and ld, and maybe throws around some forward slashes here and there. I weakly propose: NT386GNU be deleted and NT386MINGWIN (NT386MING? I386_MINGWIN? X86_MINGWIN?) and NT386CYGWIN (NT386CYG? I386_CYGWIN? X86_CYGWIN?) takes its place. but not right now. However, it still might be one target, and you edit the config file. It depends on what people define as a "target" and what it means for two "different" things to be the same "target". The same target can link with same target. To a huge extent, NT386 can link with NT386GNU. Different targets get installed to different pkg directories. SOLgnu and SOLsun might provide a similar set of questions/answers, not that I know anything about it. :) Anyway, I'm in a practical mode now, so I'll stop rambling in email. :) There's also the matter of X Windows or not... - Jay > To: jayk123 at hotmail.com> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] religion, philosophy, Posix vs. Win32 > Date: Sun, 13 Jan 2008 16:40:17 -0800> From: mika at async.caltech.edu> > Jay,> > I don't know if this is completely responsive to your question, and> take it with a grain of salt because I have never programmed on a> "pure" Windows system (and God willing, I never shall).> > I expect the NT386GNU target, Cygwin, Windows-POSIX, whatever you> call it, to look as much as Unix "as possible." (Obviously not,> but as "reasonable".) The main things are (1) yes, /bin/sh, and> (2) Unix (POSIX?) libc---Modula-3 does a good job of covering up> the basic stuff so you don't need to worry about it for the most> part, but sometimes, just sometimes, you need to get, say, some> system information that doesn't have an existing M3 interface (say> the amount of free diskspace or something like that). Then you> should be able to call C code that is portable between Unix and> Windows.> > One thing that is bizarre about the old NT386GNU PM3 that doesn't> conform to the above description: it uses Windows Time.T. It's all> the more bizarre because Cygwin uses Unix time_t. (Time.Now and> time(3) are off by a couple of hundred years on NT386GNU, whereas> they are the same on all Unixes.) I am sure there are other things.> Oh yes, the open-file (default) locking semantics are different> too. Those two are actually the only differences that I noticed> in the programming environments.> > Mika> > Jay writes:> >--_d0659847-2f20-454a-9665-5df3b5ce2832_> >Content-Type: text/plain; charset="iso-8859-1"> >Content-Transfer-Encoding: quoted-printable> >> >The conclusion here is:> > Just try to convince me otherwise. :)> >> >The gist of the question is:> > Just what characteristics of "Posix" and "Win32" should "NT386GNU" have?> >> > Just what characteristics of "Posix" do people notice and like?> >You can't say "the whole thing". :)> >> >Restated:> >> >What is Posix? I don't mean, where is the standard document web site.> >I mean what is it TO YOU?> >> >Is it open/read/write/close?> >Is it fork?> >Is it sbrk?> > On these previous ones, they are interesting to many programmers,> > but Modula-3 already layers over all this, so these are unlikely defining> >characteristics here.> >> >Is it sh? Probably somewhat. But if have you sat in Cygwin sh much vs. cmd?> > It is annoying. Command line history is flaky. Paths are munged to say /cy=> >gdrive.> > You lose the critical F8 command line completion against history feature.> > You lose a lot of editing capability, but do gain some alternate possibly=> > "portable"> > similar.> >> >Is it Perl? No.> >Is it X Windows. I doubt it.> >Is it pthreads? Probably not.> > Or at least vtalarm? Maybe?> > Or setjmp/longjmp? Ok.> > Longjmp to the same buffer multiple times? Not likely.> > Longjmp to a place that has already returned? Not likely.> >All full paths starting with a forward slash? Maybe.> > Backward slash being a valid non-seperator path character? Maybe.> >> >Think about that last one.> >It is valid and occurs in Win32 code to treat forward slash and backward sl=> >ash the same.> >Some code does, some code does not.> >What if you just did that unconditionally, like even in Posix?> >What is the role of backward slash in Posix paths? It either just doesn't o=> >ccur,> >or is an escape character, or is a regular character. Something at a low le=> >vel> >could replace the backward slashes with forward slashes.> >> >I would like to change the code in m3-sys/cm3/m3path.m3 to treat backward s=> >lashes> >and forward slashes the same. Backward slashes just won't occur on Posix, r=> >ight?> >So far I have managed without this change, but not having it has bitten me => >a few times.> >I do have the analogous change to the Win32 path code in m3core.> >> >It is the redundant filenames libfoo.a instead of foo.lib and libfoo.so ins=> >tead of foo.so?> >Perhaps. This seems dumb, redundant to me. Why have prefixes and suffixes?> >Don't suffixes suffice?> >> >That all said, I remain convinced that a useful intermediate or probably en=> >dpoint> >is a toolset that targets Windows using cm3cg, ld, as, but otherwise looks => >like> >NT386 as much as possible. MAYBE alter the library names to libfoo.*.> >> >sh and make are needed for building cm3cg.> >I did use Cygwin for that. MinGWin sounds promising here too but I haven't => >tried.> >> > - Jay> >> >> >_________________________________________________________________> >Get the power of Windows + Web with the new Windows Live.> >http://www.windowslive.com?ocid=3DTXT_TAGHM_Wave2_powerofwindows_012008=> >> >--_d0659847-2f20-454a-9665-5df3b5ce2832_> >Content-Type: text/html; charset="iso-8859-1"> >Content-Transfer-Encoding: quoted-printable> >> >> >> >> >> >The conclusion here is:
 Just try to conv=> >ince me otherwise. :)

The gist of the question is:
  Just wh=> >at characteristics of "Posix" and "Win32" should "NT386GNU" have?

&n=> >bsp;Just what characteristics of "Posix" do people notice and like?
You => >can't say "the whole thing". :)

Restated:

What is Posix? I do=> >n't mean, where is the standard document web site.
I mean what is it TO => >YOU?

Is it open/read/write/close?
Is it fork?
Is it sbrk?
&=> >nbsp; On these previous ones, they are interesting to many programmers,
=> > but Modula-3 already layers over all this, so these are unlikely defi=> >ning
characteristics here.

Is it sh? Probably somewhat. But if ha=> >ve you sat in Cygwin sh much vs. cmd?
 It is annoying. Command line=> > history is flaky. Paths are munged to say /cygdrive.
 You lose the=> > critical F8 command line completion against history feature.
  You=> > lose a lot of editing capability, but do gain some alternate possibly "por=> >table"
  similar.

Is it Perl? No.
Is it X Windows. I doub=> >t it.
Is it pthreads? Probably not.
  Or at least vtalarm? Maybe=> >?
  Or setjmp/longjmp? Ok.
    Longjmp to the sam=> >e buffer multiple times? Not likely.
    Longjmp to a pla=> >ce that has already returned? Not likely.
All full paths starting with a=> > forward slash? Maybe.
  Backward slash being a valid non-seperator=> > path character? Maybe.

Think about that last one.
It is valid an=> >d occurs in Win32 code to treat forward slash and backward slash the same.<=> >br>Some code does, some code does not.
What if you just did that uncondi=> >tionally, like even in Posix?
What is the role of backward slash in Posi=> >x paths? It either just doesn't occur,
or is an escape character, or is => >a regular character. Something at a low level
could replace the backward=> > slashes with forward slashes.

I would like to change the code in m3=> >-sys/cm3/m3path.m3 to treat backward slashes
and forward slashes the sam=> >e. Backward slashes just won't occur on Posix, right?
So far I have mana=> >ged without this change, but not having it has bitten me a few times.
I => >do have the analogous change to the Win32 path code in m3core.

It is=> > the redundant filenames libfoo.a instead of foo.lib and libfoo.so instead => >of foo.so?
Perhaps. This seems dumb, redundant to me. Why have prefixes => >and suffixes?
Don't suffixes suffice?

That all said, I remain con=> >vinced that a useful intermediate or probably endpoint
is a toolset that=> > targets Windows using cm3cg, ld, as, but otherwise looks like
NT386 as => >much as possible. MAYBE alter the library names to libfoo.*.

sh and => >make are needed for building cm3cg.
I did use Cygwin for that. MinGWin s=> >ounds promising here too but I haven't tried.

 - Jay

> />
Get the power of Windows + Web with the new Windows Live. >=3D'http://www.windowslive.com?ocid=3DTXT_TAGHM_Wave2_powerofwindows_012008=> >' target=3D'_new'>Get it now!> >=> >> >--_d0659847-2f20-454a-9665-5df3b5ce2832_-- _________________________________________________________________ Put your friends on the big screen with Windows Vista? + Windows Live?. http://www.microsoft.com/windows/shop/specialoffers.mspx?ocid=TXT_TAGLM_CPC_MediaCtr_bigscreen_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.caltech.edu Mon Jan 14 02:55:21 2008 From: mika at async.caltech.edu (Mika Nystrom) Date: Sun, 13 Jan 2008 17:55:21 -0800 Subject: [M3devel] religion, philosophy, Posix vs. Win32 In-Reply-To: Your message of "Mon, 14 Jan 2008 01:30:58 GMT." Message-ID: <200801140155.m0E1tLxU048776@camembert.async.caltech.edu> Well Unix compatibility is what Cygwin "is for"... it's a little odd to have Cygwin pretend to be Windows---if you want Windows, you don't need Cygwin! The old PM3 doesn't use X for its Trestle. It uses native Windows things. Note there is no contradiction between using Windows UI for Trestle and what I said before. Under Cygwin, you want to be able to use X, just like on Unix. But if M3 doesn't use it, well no matter. Although if you want to extend wish lists, sure, it might be nice to be able to build Trestle under X on Cygwin, too. (I mean, why not? It ought to be "trivial", right?) Mika Jay writes: >--_5cf007a7-8622-47c5-8550-283b4142bb52_ >Content-Type: text/plain; charset="Windows-1252" >Content-Transfer-Encoding: quoted-printable > >ok..well...some provision I guess eventually should be made for those who a= >gree with you and Tony. >What will come first is something else. :) > A system that is Win32 as much as possible, EXCEPT that it uses the gcc-ba= >sed backend, and as, and ld, and maybe throws around some forward slashes h= >ere and there. >=20 >I weakly propose: > NT386GNU be deleted > and NT386MINGWIN (NT386MING? I386_MINGWIN? X86_MINGWIN?) > and NT386CYGWIN (NT386CYG? I386_CYGWIN? X86_CYGWIN?) > takes its place. >=20 >but not right now. >=20 >However, it still might be one target, and you edit the config file. >It depends on what people define as a "target" and what it means for two "d= >ifferent" things to be the same "target". >The same target can link with same target. To a huge extent, NT386 can link= > with NT386GNU. >Different targets get installed to different pkg directories. >=20 >SOLgnu and SOLsun might provide a similar set of questions/answers, not tha= >t I know anything about it. :) >=20 >Anyway, I'm in a practical mode now, so I'll stop rambling in email. :) >=20 >There's also the matter of X Windows or not... >=20 > - Jay > >> To: jayk123 at hotmail.com> CC: m3devel at elegosoft.com> Subject: Re: [M3devel= >] religion, philosophy, Posix vs. Win32 > Date: Sun, 13 Jan 2008 16:40:17 -= >0800> From: mika at async.caltech.edu> > Jay,> > I don't know if this is compl= >etely responsive to your question, and> take it with a grain of salt becaus= >e I have never programmed on a> "pure" Windows system (and God willing, I n= >ever shall).> > I expect the NT386GNU target, Cygwin, Windows-POSIX, whatev= >er you> call it, to look as much as Unix "as possible." (Obviously not,> bu= >t as "reasonable".) The main things are (1) yes, /bin/sh, and> (2) Unix (PO= >SIX?) libc---Modula-3 does a good job of covering up> the basic stuff so yo= >u don't need to worry about it for the most> part, but sometimes, just some= >times, you need to get, say, some> system information that doesn't have an = >existing M3 interface (say> the amount of free diskspace or something like = >that). Then you> should be able to call C code that is portable between Uni= >x and> Windows.> > One thing that is bizarre about the old NT386GNU PM3 tha= >t doesn't> conform to the above description: it uses Windows Time.T. It's a= >ll> the more bizarre because Cygwin uses Unix time_t. (Time.Now and> time(3= >) are off by a couple of hundred years on NT386GNU, whereas> they are the s= >ame on all Unixes.) I am sure there are other things.> Oh yes, the open-fil= >e (default) locking semantics are different> too. Those two are actually th= >e only differences that I noticed> in the programming environments.> > Mika= >> > Jay writes:> >--_d0659847-2f20-454a-9665-5df3b5ce2832_> >Content-Type: = >text/plain; charset=3D"iso-8859-1"> >Content-Transfer-Encoding: quoted-prin= >table> >> >The conclusion here is:> > Just try to convince me otherwise. :)= >> >> >The gist of the question is:> > Just what characteristics of "Posix" = >and "Win32" should "NT386GNU" have?> >> > Just what characteristics of "Pos= >ix" do people notice and like?> >You can't say "the whole thing". :)> >> >R= >estated:> >> >What is Posix? I don't mean, where is the standard document w= >eb site.> >I mean what is it TO YOU?> >> >Is it open/read/write/close?> >Is= > it fork?> >Is it sbrk?> > On these previous ones, they are interesting to = >many programmers,> > but Modula-3 already layers over all this, so these ar= >e unlikely defining> >characteristics here.> >> >Is it sh? Probably somewha= >t. But if have you sat in Cygwin sh much vs. cmd?> > It is annoying. Comman= >d line history is flaky. Paths are munged to say /cy=3D> >gdrive.> > You lo= >se the critical F8 command line completion against history feature.> > You = >lose a lot of editing capability, but do gain some alternate possibly=3D> >= > "portable"> > similar.> >> >Is it Perl? No.> >Is it X Windows. I doubt it.= >> >Is it pthreads? Probably not.> > Or at least vtalarm? Maybe?> > Or setjm= >p/longjmp? Ok.> > Longjmp to the same buffer multiple times? Not likely.> >= > Longjmp to a place that has already returned? Not likely.> >All full paths= > starting with a forward slash? Maybe.> > Backward slash being a valid non-= >seperator path character? Maybe.> >> >Think about that last one.> >It is va= >lid and occurs in Win32 code to treat forward slash and backward sl=3D> >as= >h the same.> >Some code does, some code does not.> >What if you just did th= >at unconditionally, like even in Posix?> >What is the role of backward slas= >h in Posix paths? It either just doesn't o=3D> >ccur,> >or is an escape cha= >racter, or is a regular character. Something at a low le=3D> >vel> >could r= >eplace the backward slashes with forward slashes.> >> >I would like to chan= >ge the code in m3-sys/cm3/m3path.m3 to treat backward s=3D> >lashes> >and f= >orward slashes the same. Backward slashes just won't occur on Posix, r=3D> = >>ight?> >So far I have managed without this change, but not having it has b= >itten me =3D> >a few times.> >I do have the analogous change to the Win32 p= >ath code in m3core.> >> >It is the redundant filenames libfoo.a instead of = >foo.lib and libfoo.so ins=3D> >tead of foo.so?> >Perhaps. This seems dumb, = >redundant to me. Why have prefixes and suffixes?> >Don't suffixes suffice?>= > >> >That all said, I remain convinced that a useful intermediate or probab= >ly en=3D> >dpoint> >is a toolset that targets Windows using cm3cg, ld, as, = >but otherwise looks =3D> >like> >NT386 as much as possible. MAYBE alter the= > library names to libfoo.*.> >> >sh and make are needed for building cm3cg.= >> >I did use Cygwin for that. MinGWin sounds promising here too but I haven= >'t =3D> >tried.> >> > - Jay> >> >> >_______________________________________= >__________________________> >Get the power of Windows + Web with the new Wi= >ndows Live.> >http://www.windowslive.com?ocid=3D3DTXT_TAGHM_Wave2_powerofwi= >ndows_012008=3D> >> >--_d0659847-2f20-454a-9665-5df3b5ce2832_> >Content-Typ= >e: text/html; charset=3D"iso-8859-1"> >Content-Transfer-Encoding: quoted-pr= >intable> >> >> >> >> >> >The conclusion here= > is:
 Just try to conv=3D> >ince me otherwise. :)

The gist o= >f the question is:
  Just wh=3D> >at characteristics of "Posix" and= > "Win32" should "NT386GNU" have?

&n=3D> >bsp;Just what characteristi= >cs of "Posix" do people notice and like?
You =3D> >can't say "the whole = >thing". :)

Restated:

What is Posix? I do=3D> >n't mean, where= > is the standard document web site.
I mean what is it TO =3D> >YOU?
<= >br>Is it open/read/write/close?
Is it fork?
Is it sbrk?
&=3D> >nbs= >p; On these previous ones, they are interesting to many programmers,
=3D= >> > but Modula-3 already layers over all this, so these are unlikely d= >efi=3D> >ning
characteristics here.

Is it sh? Probably somewhat. = >But if ha=3D> >ve you sat in Cygwin sh much vs. cmd?
 It is annoyin= >g. Command line=3D> > history is flaky. Paths are munged to say /cygdrive.<= >br> You lose the=3D> > critical F8 command line completion against his= >tory feature.
  You=3D> > lose a lot of editing capability, but do = >gain some alternate possibly "por=3D> >table"
  similar.

Is = >it Perl? No.
Is it X Windows. I doub=3D> >t it.
Is it pthreads? Proba= >bly not.
  Or at least vtalarm? Maybe=3D> >?
  Or setjmp/lo= >ngjmp? Ok.
    Longjmp to the sam=3D> >e buffer multiple = >times? Not likely.
    Longjmp to a pla=3D> >ce that has = >already returned? Not likely.
All full paths starting with a=3D> > forwa= >rd slash? Maybe.
  Backward slash being a valid non-seperator=3D> >= > path character? Maybe.

Think about that last one.
It is valid an= >=3D> >d occurs in Win32 code to treat forward slash and backward slash the = >same.<=3D> >br>Some code does, some code does not.
What if you just did = >that uncondi=3D> >tionally, like even in Posix?
What is the role of back= >ward slash in Posi=3D> >x paths? It either just doesn't occur,
or is an = >escape character, or is =3D> >a regular character. Something at a low level= >
could replace the backward=3D> > slashes with forward slashes.

I= > would like to change the code in m3=3D> >-sys/cm3/m3path.m3 to treat backw= >ard slashes
and forward slashes the sam=3D> >e. Backward slashes just wo= >n't occur on Posix, right?
So far I have mana=3D> >ged without this chan= >ge, but not having it has bitten me a few times.
I =3D> >do have the ana= >logous change to the Win32 path code in m3core.

It is=3D> > the redu= >ndant filenames libfoo.a instead of foo.lib and libfoo.so instead =3D> >of = >foo.so?
Perhaps. This seems dumb, redundant to me. Why have prefixes =3D= >> >and suffixes?
Don't suffixes suffice?

That all said, I remain = >con=3D> >vinced that a useful intermediate or probably endpoint
is a too= >lset that=3D> > targets Windows using cm3cg, ld, as, but otherwise looks li= >ke
NT386 as =3D> >much as possible. MAYBE alter the library names to lib= >foo.*.

sh and =3D> >make are needed for building cm3cg.
I did use= > Cygwin for that. MinGWin s=3D> >ounds promising here too but I haven't tri= >ed.

 - Jay

> />
Get the power of Windows + = >Web with the new Windows Live. >=3D3D'http://www.windowslive.co= >m?ocid=3D3DTXT_TAGHM_Wave2_powerofwindows_012008=3D> >' target=3D3D'_new'>G= >et it now!> >=3D> >> >--_d0659847-2f20-454a-9665-5df3b5ce= >2832_-- >_________________________________________________________________ >Put your friends on the big screen with Windows Vista=AE + Windows Live=99. >http://www.microsoft.com/windows/shop/specialoffers.mspx?ocid=3DTXT_TAGLM_C= >PC_MediaCtr_bigscreen_012008= > >--_5cf007a7-8622-47c5-8550-283b4142bb52_ >Content-Type: text/html; charset="Windows-1252" >Content-Transfer-Encoding: quoted-printable > > > > > >ok..well...some provision I guess eventually shou= >ld be made for those who agree with you and Tony.
>What will come first is something else. :)
> A system that is Win32 as much as possible, EXCEPT that it uses the g= >cc-based backend, and as, and ld, and maybe throws around some forward slas= >hes here and there.
> 
>I weakly propose:
>  NT386GNU be deleted
>  and NT386MINGWIN (NT386MING? I386_MINGWIN? X86_MINGWIN?)
>  and NT386CYGWIN (NT386CYG? I386_CYGWIN? X86_CYGWIN?)
> takes its place.
> 
>but not right now.
> 
>However, it still might be one target, and you edit the config file.
>It depends on what people define as a "target" and what it means for two "d= >ifferent" things to be the same "target".
>The same target can link with same target. To a huge extent, NT386 can link= > with NT386GNU.
>Different targets get installed to different pkg directories.
> 
>SOLgnu and SOLsun might provide a similar set of questions/answers, not tha= >t I know anything about it. :)
> 
>Anyway, I'm in a practical mode now, so I'll stop rambling in email. :)
> 
>There's also the matter of X Windows or not...
> 
> - Jay

>
>> To: jayk123 at hotmail.com
> CC: m3devel at elegosoft.com
> Subj= >ect: Re: [M3devel] religion, philosophy, Posix vs. Win32
> Date: Sun= >, 13 Jan 2008 16:40:17 -0800
> From: mika at async.caltech.edu
> <= >BR>> Jay,
>
> I don't know if this is completely responsive= > to your question, and
> take it with a grain of salt because I have = >never programmed on a
> "pure" Windows system (and God willing, I nev= >er shall).
>
> I expect the NT386GNU target, Cygwin, Windows-P= >OSIX, whatever you
> call it, to look as much as Unix "as possible." = >(Obviously not,
> but as "reasonable".) The main things are (1) yes, = >/bin/sh, and
> (2) Unix (POSIX?) libc---Modula-3 does a good job of c= >overing up
> the basic stuff so you don't need to worry about it for = >the most
> part, but sometimes, just sometimes, you need to get, say,= > some
> system information that doesn't have an existing M3 interface= > (say
> the amount of free diskspace or something like that). Then yo= >u
> should be able to call C code that is portable between Unix andR>> Windows.
>
> One thing that is bizarre about the old NT= >386GNU PM3 that doesn't
> conform to the above description: it uses W= >indows Time.T. It's all
> the more bizarre because Cygwin uses Unix t= >ime_t. (Time.Now and
> time(3) are off by a couple of hundred years o= >n NT386GNU, whereas
> they are the same on all Unixes.) I am sure the= >re are other things.
> Oh yes, the open-file (default) locking semant= >ics are different
> too. Those two are actually the only differences = >that I noticed
> in the programming environments.
>
> Mi= >ka
>
> Jay writes:
> >--_d0659847-2f20-454a-9665-5df3= >b5ce2832_
> >Content-Type: text/plain; charset=3D"iso-8859-1"
&= >gt; >Content-Transfer-Encoding: quoted-printable
> >
> &g= >t;The conclusion here is:
> > Just try to convince me otherwise. := >)
> >
> >The gist of the question is:
> > Just w= >hat characteristics of "Posix" and "Win32" should "NT386GNU" have?
> = >>
> > Just what characteristics of "Posix" do people notice and= > like?
> >You can't say "the whole thing". :)
> >
>= > >Restated:
> >
> >What is Posix? I don't mean, where = >is the standard document web site.
> >I mean what is it TO YOU?>> >
> >Is it open/read/write/close?
> >Is it fork?= >
> >Is it sbrk?
> > On these previous ones, they are inte= >resting to many programmers,
> > but Modula-3 already layers over = >all this, so these are unlikely defining
> >characteristics here.<= >BR>> >
> >Is it sh? Probably somewhat. But if have you sat i= >n Cygwin sh much vs. cmd?
> > It is annoying. Command line history= > is flaky. Paths are munged to say /cy=3D
> >gdrive.
> > = >You lose the critical F8 command line completion against history feature.R>> > You lose a lot of editing capability, but do gain some alternat= >e possibly=3D
> > "portable"
> > similar.
> >>> >Is it Perl? No.
> >Is it X Windows. I doubt it.
> = >>Is it pthreads? Probably not.
> > Or at least vtalarm? Maybe?<= >BR>> > Or setjmp/longjmp? Ok.
> > Longjmp to the same buffer= > multiple times? Not likely.
> > Longjmp to a place that has alrea= >dy returned? Not likely.
> >All full paths starting with a forward= > slash? Maybe.
> > Backward slash being a valid non-seperator path= > character? Maybe.
> >
> >Think about that last one.
&= >gt; >It is valid and occurs in Win32 code to treat forward slash and bac= >kward sl=3D
> >ash the same.
> >Some code does, some code= > does not.
> >What if you just did that unconditionally, like even= > in Posix?
> >What is the role of backward slash in Posix paths? I= >t either just doesn't o=3D
> >ccur,
> >or is an escape ch= >aracter, or is a regular character. Something at a low le=3D
> >ve= >l
> >could replace the backward slashes with forward slashes.
&= >gt; >
> >I would like to change the code in m3-sys/cm3/m3path.m= >3 to treat backward s=3D
> >lashes
> >and forward slashes= > the same. Backward slashes just won't occur on Posix, r=3D
> >igh= >t?
> >So far I have managed without this change, but not having it= > has bitten me =3D
> >a few times.
> >I do have the analo= >gous change to the Win32 path code in m3core.
> >
> >It i= >s the redundant filenames libfoo.a instead of foo.lib and libfoo.so ins=3D<= >BR>> >tead of foo.so?
> >Perhaps. This seems dumb, redundant= > to me. Why have prefixes and suffixes?
> >Don't suffixes suffice?= >
> >
> >That all said, I remain convinced that a useful i= >ntermediate or probably en=3D
> >dpoint
> >is a toolset t= >hat targets Windows using cm3cg, ld, as, but otherwise looks =3D
> &g= >t;like
> >NT386 as much as possible. MAYBE alter the library names= > to libfoo.*.
> >
> >sh and make are needed for building = >cm3cg.
> >I did use Cygwin for that. MinGWin sounds promising here= > too but I haven't =3D
> >tried.
> >
> > - JayR>> >
> >
> >______________________________________= >___________________________
> >Get the power of Windows + Web with= > the new Windows Live.
> >http://www.windowslive.com?ocid=3D3DTXT_= >TAGHM_Wave2_powerofwindows_012008=3D
> >
> >--_d0659847-2= >f20-454a-9665-5df3b5ce2832_
> >Content-Type: text/html; charset=3D= >"iso-8859-1"
> >Content-Transfer-Encoding: quoted-printable
>= >; >
> ><html>
> ><head>
> ><st= >yle>
> >.hmmessage P
> >{
> >margin:0px;
&= >gt; >padding:0px
> >}
> >body.hmmessage
> >{<= >BR>> >FONT-SIZE: 10pt;
> >FONT-FAMILY:Tahoma
> >}R>> ></style>
> ></head>
> ><body cl= >ass=3D3D'hmmessage'>The conclusion here is:<br>&nbsp;Just try = >to conv=3D
> >ince me otherwise. :)<br><br>The gist of= > the question is:<br>&nbsp; Just wh=3D
> >at characteris= >tics of "Posix" and "Win32" should "NT386GNU" have?<br><br>&= >;n=3D
> >bsp;Just what characteristics of "Posix" do people notice= > and like?<br>You =3D
> >can't say "the whole thing". :)<= >br><br>Restated:<br><br>What is Posix? I do=3D
>= > >n't mean, where is the standard document web site.<br>I mean wha= >t is it TO =3D
> >YOU?<br><br>Is it open/read/write/cl= >ose?<br>Is it fork?<br>Is it sbrk?<br>&=3D
> &g= >t;nbsp; On these previous ones, they are interesting to many programmers,&l= >t;br>=3D
> >&nbsp;but Modula-3 already layers over all this= >, so these are unlikely defi=3D
> >ning<br>characteristics h= >ere.<br><br>Is it sh? Probably somewhat. But if ha=3D
> &= >gt;ve you sat in Cygwin sh much vs. cmd?<br>&nbsp;It is annoying.= > Command line=3D
> > history is flaky. Paths are munged to say /cy= >gdrive.<br>&nbsp;You lose the=3D
> > critical F8 command= > line completion against history feature.<br>&nbsp; You=3D
>= >; > lose a lot of editing capability, but do gain some alternate possibl= >y "por=3D
> >table"<br>&nbsp; similar.<br><br&g= >t;Is it Perl? No.<br>Is it X Windows. I doub=3D
> >t it.<= >br>Is it pthreads? Probably not.<br>&nbsp; Or at least vtalarm= >? Maybe=3D
> >?<br>&nbsp; Or setjmp/longjmp? Ok.<br&g= >t;&nbsp;&nbsp;&nbsp; Longjmp to the sam=3D
> >e buffer= > multiple times? Not likely.<br>&nbsp;&nbsp;&nbsp; Longjm= >p to a pla=3D
> >ce that has already returned? Not likely.<br&g= >t;All full paths starting with a=3D
> > forward slash? Maybe.<b= >r>&nbsp; Backward slash being a valid non-seperator=3D
> > = >path character? Maybe.<br><br>Think about that last one.<br&= >gt;It is valid an=3D
> >d occurs in Win32 code to treat forward sl= >ash and backward slash the same.<=3D
> >br>Some code does, s= >ome code does not.<br>What if you just did that uncondi=3D
> &g= >t;tionally, like even in Posix?<br>What is the role of backward slash= > in Posi=3D
> >x paths? It either just doesn't occur,<br>or = >is an escape character, or is =3D
> >a regular character. Somethin= >g at a low level<br>could replace the backward=3D
> > slashe= >s with forward slashes.<br><br>I would like to change the code = >in m3=3D
> >-sys/cm3/m3path.m3 to treat backward slashes<br>= >and forward slashes the sam=3D
> >e. Backward slashes just won't o= >ccur on Posix, right?<br>So far I have mana=3D
> >ged withou= >t this change, but not having it has bitten me a few times.<br>I =3D<= >BR>> >do have the analogous change to the Win32 path code in m3core.&= >lt;br><br>It is=3D
> > the redundant filenames libfoo.a i= >nstead of foo.lib and libfoo.so instead =3D
> >of foo.so?<br>= >;Perhaps. This seems dumb, redundant to me. Why have prefixes =3D
> &= >gt;and suffixes?<br>Don't suffixes suffice?<br><br>That a= >ll said, I remain con=3D
> >vinced that a useful intermediate or p= >robably endpoint<br>is a toolset that=3D
> > targets Windows= > using cm3cg, ld, as, but otherwise looks like<br>NT386 as =3D
>= >; >much as possible. MAYBE alter the library names to libfoo.*.<br>= >;<br>sh and =3D
> >make are needed for building cm3cg.<br= >>I did use Cygwin for that. MinGWin s=3D
> >ounds promising her= >e too but I haven't tried.<br><br>&nbsp;- Jay<br><= >br><br=3D
> > /><hr />Get the power of Windows + We= >b with the new Windows Live. <a href=3D
> >=3D3D'http://www.win= >dowslive.com?ocid=3D3DTXT_TAGHM_Wave2_powerofwindows_012008=3D
> >= >' target=3D3D'_new'>Get it now!</a></body>
> ></= >html>=3D
> >
> >--_d0659847-2f20-454a-9665-5df3b5ce283= >2_--


Put your friends on the big screen with Windows Vis= >ta=AE + Windows Live=99. pecialoffers.mspx?ocid=3DTXT_TAGLM_CPC_MediaCtr_bigscreen_012008' target=3D= >'_new'>Start now! >= > >--_5cf007a7-8622-47c5-8550-283b4142bb52_-- From dabenavidesd at yahoo.es Mon Jan 14 03:32:37 2008 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Mon, 14 Jan 2008 03:32:37 +0100 (CET) Subject: [M3devel] religion, philosophy, Posix vs. Win32 In-Reply-To: <200801140040.m0E0eHs7046272@camembert.async.caltech.edu> Message-ID: <17920.29413.qm@web27103.mail.ukl.yahoo.com> Hi all, Yes, I also noticed the Time.T issue in pm3 1.1.15 because I was trying to get compiled m3browser and I finally arranged to do that, but the program just broke, and I didn't know about cygwin differences against a real UNIX platform. Also in that pm3 NT386GNU, the winvbt implementation was the one of dec-src not like current cm3 winvbt (that use WIDECHAR as I remember) I tried to have the same interfaces to be able to use from m3browser. Now fortunately you can compile m3browser with NT386 cm3 platform. I just liked very much the way one can make a bootstrap from pm3 from one platform to another and make a minimal compiler for NT386GNU: http://tkb.mpl.com/~tkb/software/misc/pm3-NT386GNU.patch I couldn't repeat the above link instructions in a Debian Sarge machine, with all the pm3 Debian packages installed (available in the Debian Woody http://archive.debian.org/pool/main/p/pm3/ ) I think the reason was I was unable to do all the bootstrap process http://archive.debian.org/pool/main/p/pm3-i386 I would like to have that kind of posix to cygwin capability of port at least a minimal compiler/runtime system. Also, talking about the topic of port NT386 to NT386GNU (more than a year ago) I got some answer from Bert Laverman, Daniel Benavides wrote: > What if we use the cygwin platform to run cm3, an use its runtime > of linker and c Compiler? "Normally this involves a speed penalty, because cygwin will emulate a UNIX environment, and has to translate this to Windows calls. The advantage is of course that you can ignore most differences between Windows and UNIX. If you don't want the speed penalty, and can take care of the platform differences, then you can use the -mno-cygwin flag. However, make sure you use only "real" Windows API calls." Bert Laverman Thanks Mika Nystrom escribi?: Jay, I don't know if this is completely responsive to your question, and take it with a grain of salt because I have never programmed on a "pure" Windows system (and God willing, I never shall). I expect the NT386GNU target, Cygwin, Windows-POSIX, whatever you call it, to look as much as Unix "as possible." (Obviously not, but as "reasonable".) The main things are (1) yes, /bin/sh, and (2) Unix (POSIX?) libc---Modula-3 does a good job of covering up the basic stuff so you don't need to worry about it for the most part, but sometimes, just sometimes, you need to get, say, some system information that doesn't have an existing M3 interface (say the amount of free diskspace or something like that). Then you should be able to call C code that is portable between Unix and Windows. One thing that is bizarre about the old NT386GNU PM3 that doesn't conform to the above description: it uses Windows Time.T. It's all the more bizarre because Cygwin uses Unix time_t. (Time.Now and time(3) are off by a couple of hundred years on NT386GNU, whereas they are the same on all Unixes.) I am sure there are other things. Oh yes, the open-file (default) locking semantics are different too. Those two are actually the only differences that I noticed in the programming environments. Mika Jay writes: >--_d0659847-2f20-454a-9665-5df3b5ce2832_ >Content-Type: text/plain; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > >The conclusion here is: > Just try to convince me otherwise. :) > >The gist of the question is: > Just what characteristics of "Posix" and "Win32" should "NT386GNU" have? > > Just what characteristics of "Posix" do people notice and like? >You can't say "the whole thing". :) > >Restated: > >What is Posix? I don't mean, where is the standard document web site. >I mean what is it TO YOU? > >Is it open/read/write/close? >Is it fork? >Is it sbrk? > On these previous ones, they are interesting to many programmers, > but Modula-3 already layers over all this, so these are unlikely defining >characteristics here. > >Is it sh? Probably somewhat. But if have you sat in Cygwin sh much vs. cmd? > It is annoying. Command line history is flaky. Paths are munged to say /cy= >gdrive. > You lose the critical F8 command line completion against history feature. > You lose a lot of editing capability, but do gain some alternate possibly= > "portable" > similar. > >Is it Perl? No. >Is it X Windows. I doubt it. >Is it pthreads? Probably not. > Or at least vtalarm? Maybe? > Or setjmp/longjmp? Ok. > Longjmp to the same buffer multiple times? Not likely. > Longjmp to a place that has already returned? Not likely. >All full paths starting with a forward slash? Maybe. > Backward slash being a valid non-seperator path character? Maybe. > >Think about that last one. >It is valid and occurs in Win32 code to treat forward slash and backward sl= >ash the same. >Some code does, some code does not. >What if you just did that unconditionally, like even in Posix? >What is the role of backward slash in Posix paths? It either just doesn't o= >ccur, >or is an escape character, or is a regular character. Something at a low le= >vel >could replace the backward slashes with forward slashes. > >I would like to change the code in m3-sys/cm3/m3path.m3 to treat backward s= >lashes >and forward slashes the same. Backward slashes just won't occur on Posix, r= >ight? >So far I have managed without this change, but not having it has bitten me = >a few times. >I do have the analogous change to the Win32 path code in m3core. > >It is the redundant filenames libfoo.a instead of foo.lib and libfoo.so ins= >tead of foo.so? >Perhaps. This seems dumb, redundant to me. Why have prefixes and suffixes? >Don't suffixes suffice? > >That all said, I remain convinced that a useful intermediate or probably en= >dpoint >is a toolset that targets Windows using cm3cg, ld, as, but otherwise looks = >like >NT386 as much as possible. MAYBE alter the library names to libfoo.*. > >sh and make are needed for building cm3cg. >I did use Cygwin for that. MinGWin sounds promising here too but I haven't = >tried. > > - Jay > > >_________________________________________________________________ >Get the power of Windows + Web with the new Windows Live. >http://www.windowslive.com?ocid=3DTXT_TAGHM_Wave2_powerofwindows_012008= > >--_d0659847-2f20-454a-9665-5df3b5ce2832_ >Content-Type: text/html; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > > > >.hmmessage P >{ >margin:0px; >padding:0px >} >body.hmmessage >{ >FONT-SIZE: 10pt; >FONT-FAMILY:Tahoma >} > > >The conclusion here is: Just try to conv= >ince me otherwise. :) The gist of the question is: Just wh= >at characteristics of "Posix" and "Win32" should "NT386GNU" have? &n= >bsp;Just what characteristics of "Posix" do people notice and like? You = >can't say "the whole thing". :) Restated: What is Posix? I do= >n't mean, where is the standard document web site. I mean what is it TO = >YOU? Is it open/read/write/close? Is it fork? Is it sbrk? &= >nbsp; On these previous ones, they are interesting to many programmers, = > but Modula-3 already layers over all this, so these are unlikely defi= >ning characteristics here. Is it sh? Probably somewhat. But if ha= >ve you sat in Cygwin sh much vs. cmd? It is annoying. Command line= > history is flaky. Paths are munged to say /cygdrive. You lose the= > critical F8 command line completion against history feature. You= > lose a lot of editing capability, but do gain some alternate possibly "por= >table" similar. Is it Perl? No. Is it X Windows. I doub= >t it. Is it pthreads? Probably not. Or at least vtalarm? Maybe= >? Or setjmp/longjmp? Ok. Longjmp to the sam= >e buffer multiple times? Not likely. Longjmp to a pla= >ce that has already returned? Not likely. All full paths starting with a= > forward slash? Maybe. Backward slash being a valid non-seperator= > path character? Maybe. Think about that last one. It is valid an= >d occurs in Win32 code to treat forward slash and backward slash the same.<= >br>Some code does, some code does not. What if you just did that uncondi= >tionally, like even in Posix? What is the role of backward slash in Posi= >x paths? It either just doesn't occur, or is an escape character, or is = >a regular character. Something at a low level could replace the backward= > slashes with forward slashes. I would like to change the code in m3= >-sys/cm3/m3path.m3 to treat backward slashes and forward slashes the sam= >e. Backward slashes just won't occur on Posix, right? So far I have mana= >ged without this change, but not having it has bitten me a few times. I = >do have the analogous change to the Win32 path code in m3core. It is= > the redundant filenames libfoo.a instead of foo.lib and libfoo.so instead = >of foo.so? Perhaps. This seems dumb, redundant to me. Why have prefixes = >and suffixes? Don't suffixes suffice? That all said, I remain con= >vinced that a useful intermediate or probably endpoint is a toolset that= > targets Windows using cm3cg, ld, as, but otherwise looks like NT386 as = >much as possible. MAYBE alter the library names to libfoo.*. sh and = >make are needed for building cm3cg. I did use Cygwin for that. MinGWin s= >ounds promising here too but I haven't tried. - Jay > /> --------------------------------- Get the power of Windows + Web with the new Windows Live. >=3D'http://www.windowslive.com?ocid=3DTXT_TAGHM_Wave2_powerofwindows_012008= >' target=3D'_new'>Get it now! >= > >--_d0659847-2f20-454a-9665-5df3b5ce2832_-- --------------------------------- Web Revelaci?n Yahoo! 2007: Premio Favorita del P?blico - ?Vota tu preferida! -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Mon Jan 14 05:39:19 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 14 Jan 2008 04:39:19 +0000 Subject: [M3devel] religion, philosophy, Posix vs. Win32 In-Reply-To: <17920.29413.qm@web27103.mail.ukl.yahoo.com> References: <200801140040.m0E0eHs7046272@camembert.async.caltech.edu> <17920.29413.qm@web27103.mail.ukl.yahoo.com> Message-ID: I agree cross-buildability is nice. That is something NT-non-GNU will never have to the extent that NT-GNU would have, other than cross building from Windows x86 <=> Windows AMD64, etc., or NT => CE, or NT <=> 9x, which is all a fairly large set of cross combinations that do work.. You can have portability at one or more layers..and all that. How many/much do you want? At the Modula-3 level and at the C level and at the command line human interface/"scripting" level (for scripting, just use Quake or Perl or Python, really). For now my priority is using the gcc backend and the associated as and ld and possibly dlltool. And buildability of the gcc backend which requires much more, but is easy enough, I cross that bridge days ago. For some reason the gcc produced mklib.exe crashes at startup, I believe here:C:\dev2\cm3.2\m3-libs\m3core\src\runtime\common\RTLinker.m3(81): IF (imp.import = NIL) THEN imp.import := imp.binder (0); END;or here: C:\dev2\cm3.2\m3-libs\m3core\src\runtime\common\RTLinker.m3(182): IF (imp.import = NIL) THEN imp.import := imp.binder (0); END; imp.binder is NULL. I'm sure there was a check for NULL followed by a jump to NULL and recall the callstack was to around here. You can actually debug it with gdb. :) That was kind of nice. I'm not sure about looking at globals -- info globals just said I had void pointers, but at least I could see the stack. Not that I must use mklib, but I was considering it, and it should work.... 32 bit time_t is a nightmare waiting to happen. Have folks upgraded to 64 bit time_t? Win32, depending on the layer, supports 32 bit time_t seconds since 1970, 64 bit time_t I assume with the same start, and 64 bit time since 1601 something like 100's of nanoseconds, low enough precision to have a plenty large range (i.e. it isn't measuring 4 billionths of seconds and therefore would have already run out. :) ) Having time start at 1970 can be a bit inconenient. It is fine for the timestamps on files, but, e.g. for birthdays? Admittedly 1601 isn't adequate either for historical purposes, and eventually, if you are dealing with history, the Gregorian calendar runs out back in time and things get even much more complicated. :) - Jay Date: Mon, 14 Jan 2008 03:32:37 +0100From: dabenavidesd at yahoo.esSubject: Re: [M3devel] religion, philosophy, Posix vs. Win32To: mika at async.caltech.edu; jayk123 at hotmail.comCC: m3devel at elegosoft.comHi all,Yes, I also noticed the Time.T issue in pm3 1.1.15 because I was trying to get compiled m3browser and I finally arranged to do that, but the program just broke, and I didn't know about cygwin differences against a real UNIX platform.Also in that pm3 NT386GNU, the winvbt implementation was the one of dec-src not like current cm3 winvbt (that use WIDECHAR as I remember)I tried to have the same interfaces to be able to use from m3browser.Now fortunately you can compile m3browser with NT386 cm3 platform.I just liked very much the way one can make a bootstrap from pm3 from one platform to another and make a minimal compiler for NT386GNU:http://tkb.mpl.com/~tkb/software/misc/pm3-NT386GNU.patchI couldn't repeat the above link instructions in a Debian Sarge machine, with all the pm3 Debian packages installed (available in the Debian Woody http://archive.debian.org/pool/main/p/pm3/ ) I think the reason was I was unable to do all the bootstrap process http://archive.debian.org/pool/main/p/pm3-i386I would like to have that kind of posix to cygwin capability of port at least a minimal compiler/runtime system.Also, talking about the topic of port NT386 to NT386GNU (more than a year ago) I got some answer from Bert Laverman, Daniel Benavides wrote: > What if we use the cygwin platform to run cm3, an use its runtime > of linker and c Compiler? "Normally this involves a speed penalty, because cygwin will emulate a UNIX environment, and has to translate this to Windows calls. The advantage is of course that you can ignore most differences between Windows and UNIX. If you don't want the speed penalty, and can take care of the platform differences, then you can use the -mno-cygwin flag. However, make sure you use only "real" Windows API calls." Bert LavermanThanksMika Nystrom escribi?: Jay,I don't know if this is completely responsive to your question, andtake it with a grain of salt because I have never programmed on a"pure" Windows system (and God willing, I never shall).I expect the NT386GNU target, Cygwin, Windows-POSIX, whatever youcall it, to look as much as Unix "as possible." (Obviously not,but as "reasonable".) The main things are (1) yes, /bin/sh, and(2) Unix (POSIX?) libc---Modula-3 does a good job of covering upthe basic stuff so you don't need to worry about it for the mostpart, but sometimes, just sometimes, you need to get, say, somesystem information that doesn't have an existing M3 interface (saythe amount of free diskspace or something like that). Then youshould be able to call C code that is portable between Unix andWindows.One thing that is bizarre about the old NT386GNU PM3 that doesn'tconform to the above description: it uses Windows Time.T. It's allthe more bizarre because Cygwin uses Unix time_t. (Time.Now andtime(3) are off by a couple of hundred years on NT386GNU, whereasthey are the same on all Unixes.) I am sure there are other things.Oh yes, the open-file (default) locking semantics are differenttoo. Those two are actually the only differences that I noticedin the programming environments.MikaJay writes:>--_d0659847-2f20-454a-9665-5df3b5ce2832_>Content-Type: text/plain; charset="iso-8859-1">Content-Transfer-Encoding: quoted-printable>>The conclusion here is:> Just try to convince me otherwise. :)>>The gist of the question is:> Just what characteristics of "Posix" and "Win32" should "NT386GNU" have?>> Just what characteristics of "Posix" do people notice and like?>You can't say "the whole thing". :)>>Restated:>>What is Posix? I don't mean, where is the standard document web site.>I mean what is it TO YOU?>>Is it open/read/write/close?>Is it fork?>Is it sbrk?> On these previous ones, they are interesting to many programmers,> but Modula-3 already layers over all this, so these are unlikely defining>characteristics here.>>Is it sh? Probably somewhat. But if have you sat in Cygwin sh much vs. cmd?> It is annoying. Command line history is flaky. Paths are munged to say /cy=>gdrive.> You lose the critical F8 command line completion against history feature.> You lose a lot of editing capability, but do gain some alternate possibly=> "portable"> similar.>>Is it Perl? No.>Is it X Windows. I doubt it.>Is it pthreads? Probably not.> Or at least vtalarm? Maybe?> Or setjmp/longjmp? Ok.> Longjmp to the same buffer multiple times? Not likely.> Longjmp to a place that has already returned? Not likely.>All full paths starting with a forward slash? Maybe.> Backward slash being a valid non-seperator path character? Maybe.>>Think about that last one.>It is valid and occurs in Win32 code to treat forward slash and backward sl=>ash the same.>Some code does, some code does not.>What if you just did that unconditionally, like even in Posix?>What is the role of backward slash in Posix paths? It either just doesn't o=>ccur,>or is an escape character, or is a regular character. Something at a low le=>vel>could replace the backward slashes with forward slashes.>>I would like to change the code in m3-sys/cm3/m3path.m3 to treat backward s=>lashes>and forward slashes the same. Backward slashes just won't occur on Posix, r=>ight?>So far I have managed without this change, but not having it has bitten me =>a few times.>I do have the analogous change to the Win32 path code in m3core.>>It is the redundant filenames libfoo.a instead of foo.lib and libfoo.so ins=>tead of foo.so?>Perhaps. This seems dumb, redundant to me. Why have prefixes and suffixes?>Don't suffixes suffice?>>That all said, I remain convinced that a useful intermediate or probably en=>dpoint>is a toolset that targets Windows using cm3cg, ld, as, but otherwise looks =>like>NT386 as much as possible. MAYBE alter the library names to libfoo.*.>>sh and make are needed for building cm3cg.>I did use Cygwin for that. MinGWin sounds promising here too but I haven't =>tried.>> - Jay>>>_________________________________________________________________>Get the power of Windows + Web with the new Windows Live.>http://www.windowslive.com?ocid=3DTXT_TAGHM_Wave2_powerofwindows_012008=>>--_d0659847-2f20-454a-9665-5df3b5ce2832_>Content-Type: text/html; charset="iso-8859-1">Content-Transfer-Encoding: quoted-printable>>>> >>The conclusion here is: Just try to conv=>ince me otherwise. :)The gist of the question is: Just wh=>at characteristics of "Posix" and "Win32" should "NT386GNU" have?&n=>bsp;Just what characteristics of "Posix" do people notice and like?You =>can't say "the whole thing". :)Restated:What is Posix? I do=>n't mean, where is the standard document web site.I mean what is it TO =>YOU?Is it open/read/write/close?Is it fork?Is it sbrk?&=>nbsp; On these previous ones, they are interesting to many programmers,=> but Modula-3 already layers over all this, so these are unlikely defi=>ningcharacteristics here.Is it sh? Probably somewhat. But if ha=>ve you sat in Cygwin sh much vs. cmd? It is annoying. Command line=> history is flaky. Paths are munged to say /cygdrive. You lose the=> critical F8 command line completion against history feature. You=> lose a lot of editing capability, but do gain some alternate possibly "por=>table" similar.Is it Perl? No.Is it X Windows. I doub=>t it.Is it pthreads? Probably not. Or at least vtalarm? Maybe=>? Or setjmp/longjmp? Ok. Longjmp to the sam=>e buffer multiple times? Not likely. Longjmp to a pla=>ce that has already returned? Not likely.All full paths starting with a=> forward slash? Maybe. Backward slash being a valid non-seperator=> path character? Maybe.Think about that last one.It is valid an=>d occurs in Win32 code to treat forward slash and backward slash the same.<=>br>Some code does, some code does not.What if you just did that uncondi=>tionally, like even in Posix?What is the role of backward slash in Posi=>x paths? It either just doesn't occur,or is an escape character, or is =>a regular character. Something at a low levelcould replace the backward=> slashes with forward slashes.I would like to change the code in m3=>-sys/cm3/m3path.m3 to treat backward slashesand forward slashes the sam=>e. Backward slashes just won't occur on Posix, right?So far I have mana=>ged without this change, but not having it has bitten me a few times.I =>do have the analogous change to the Win32 path code in m3core.It is=> the redundant filenames libfoo.a instead of foo.lib and libfoo.so instead =>of foo.so?Perhaps. This seems dumb, redundant to me. Why have prefixes =>and suffixes?Don't suffixes suffice?That all said, I remain con=>vinced that a useful intermediate or probably endpointis a toolset that=> targets Windows using cm3cg, ld, as, but otherwise looks likeNT386 as =>much as possible. MAYBE alter the library names to libfoo.*.sh and =>make are needed for building cm3cg.I did use Cygwin for that. MinGWin s=>ounds promising here too but I haven't tried. - Jay> /> Get the power of Windows + Web with the new Windows Live. >=3D'http://www.windowslive.com?ocid=3DTXT_TAGHM_Wave2_powerofwindows_012008=>' target=3D'_new'>Get it now!>=>>--_d0659847-2f20-454a-9665-5df3b5ce2832_-- Web Revelaci?n Yahoo! 2007:Premio Favorita del P?blico - ?Vota tu preferida! _________________________________________________________________ Watch ?Cause Effect,? a show about real people making a real difference. http://im.live.com/Messenger/IM/MTV/?source=text_watchcause -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon Jan 14 16:47:28 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 14 Jan 2008 10:47:28 -0500 Subject: [M3devel] Static chains Message-ID: Rodney, I just realised that the static chains variables are *not* always being set up for nested function internal use. i.e., callers will pass them, but nested functions that don't explicitly use them will not have a static chain. Is this something essential for you? Why would you need a static chain from within a nested function that doesn't use any outer scope variables? Since it doesn't use any outer scope variables they cannot affect its execution, so debugging the value of those variables seems unnecessary. This is the default behavior of gcc for static chains. -- Tony From hendrik at topoi.pooq.com Mon Jan 14 18:19:50 2008 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Mon, 14 Jan 2008 12:19:50 -0500 Subject: [M3devel] Static chains In-Reply-To: References: Message-ID: <20080114171950.GB20313@topoi.pooq.com> On Mon, Jan 14, 2008 at 10:47:28AM -0500, Tony Hosking wrote: > Rodney, > > I just realised that the static chains variables are *not* always > being set up for nested function internal use. i.e., callers will > pass them, but nested functions that don't explicitly use them will > not have a static chain. Is this something essential for you? Why > would you need a static chain from within a nested function that > doesn't use any outer scope variables? Since it doesn't use any > outer scope variables they cannot affect its execution, so debugging > the value of those variables seems unnecessary. This is the default > behavior of gcc for static chains. And having them could break languages where it's possible to export procedures to places where their nonlocal procedures are still in existence but the intermediate lexical levels which they don't use are not. (Algol 68 is a case in point) -- hendrik > > -- Tony > From hosking at cs.purdue.edu Mon Jan 14 19:36:31 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 14 Jan 2008 13:36:31 -0500 Subject: [M3devel] Static chains In-Reply-To: <20080114171950.GB20313@topoi.pooq.com> References: <20080114171950.GB20313@topoi.pooq.com> Message-ID: <4C674DDA-00B2-4AFF-B78F-597C7ACC0E73@cs.purdue.edu> I believe Modula-3's downward-only (ie, only to callee's) exposure rules for procedure values will avoid this issue. On Jan 14, 2008, at 12:19 PM, hendrik at topoi.pooq.com wrote: > On Mon, Jan 14, 2008 at 10:47:28AM -0500, Tony Hosking wrote: >> Rodney, >> >> I just realised that the static chains variables are *not* always >> being set up for nested function internal use. i.e., callers will >> pass them, but nested functions that don't explicitly use them will >> not have a static chain. Is this something essential for you? Why >> would you need a static chain from within a nested function that >> doesn't use any outer scope variables? Since it doesn't use any >> outer scope variables they cannot affect its execution, so debugging >> the value of those variables seems unnecessary. This is the default >> behavior of gcc for static chains. > > And having them could break languages where it's possible to export > procedures to places where their nonlocal procedures are still in > existence but the intermediate lexical levels which they don't use are > not. (Algol 68 is a case in point) > > -- hendrik > >> >> -- Tony >> From darko at darko.org Mon Jan 14 21:35:45 2008 From: darko at darko.org (Darko) Date: Mon, 14 Jan 2008 12:35:45 -0800 Subject: [M3devel] GC question Message-ID: <9BB575E4-75B0-432D-BDEF-49F8F8644D80@darko.org> Tony, I imagine you're intimately familiar with the garbage collector implementation. If I wanted to implement a 'reallocate' function that preserved references to an object although the object was reallocated, ie change all existing references from the old object to the new object, would this be straight forward using the code of the current GC implementation? Is there any existing function that might do something like this already? Thanks, Darko. From mika at async.caltech.edu Mon Jan 14 21:53:18 2008 From: mika at async.caltech.edu (Mika Nystrom) Date: Mon, 14 Jan 2008 12:53:18 -0800 Subject: [M3devel] GC question In-Reply-To: Your message of "Mon, 14 Jan 2008 12:35:45 PST." <9BB575E4-75B0-432D-BDEF-49F8F8644D80@darko.org> Message-ID: <200801142053.m0EKrIMi087093@camembert.async.caltech.edu> It would have to be able to return an error, no? If there's an ambiguous root pointing to the object... Darko writes: >Tony, > >I imagine you're intimately familiar with the garbage collector >implementation. If I wanted to implement a 'reallocate' function that >preserved references to an object although the object was reallocated, >ie change all existing references from the old object to the new >object, would this be straight forward using the code of the current >GC implementation? Is there any existing function that might do >something like this already? > >Thanks, >Darko. From ndantam at purdue.edu Mon Jan 14 22:05:34 2008 From: ndantam at purdue.edu (Neil T. Dantam) Date: Mon, 14 Jan 2008 16:05:34 -0500 Subject: [M3devel] GC question In-Reply-To: <9BB575E4-75B0-432D-BDEF-49F8F8644D80@darko.org> References: <9BB575E4-75B0-432D-BDEF-49F8F8644D80@darko.org> Message-ID: <478BCE9E.70504@purdue.edu> Darko wrote: > If I wanted to implement a 'reallocate' function that preserved > references to an object although the object was reallocated, ie > change all existing references from the old object to the new > object, would this be straight forward using the code of the > current GC implementation? Probably not. Because precise pointer locations are not known for the stacks, they are treated conservatively, and any objects potentially referenced from the stacks are pinned in place by the GC. It would be impossible to update references to your reallocated object if those references live in the stack because we do not have precise information for stack pointer locations. -- Neil T. Dantam From ndantam at purdue.edu Mon Jan 14 22:09:30 2008 From: ndantam at purdue.edu (Neil T. Dantam) Date: Mon, 14 Jan 2008 16:09:30 -0500 Subject: [M3devel] GC question In-Reply-To: <200801142053.m0EKrIMi087093@camembert.async.caltech.edu> References: <200801142053.m0EKrIMi087093@camembert.async.caltech.edu> Message-ID: <478BCF8A.7090409@purdue.edu> Mika Nystrom wrote: > It would have to be able to return an error, no? If there's > an ambiguous root pointing to the object... If you have a reference to the object that you are reallocating which you must pass to this procedure, then you have a reference on the stack creating an ambiguous root. Also, the GC doesn't just pin objects, it pins entire pages because there may be a derived pointer referring to some object in that page. So if your object to reallocate is on the same page as anything referenced from the stack, you couldn't automatically update pointers. Now if you only want to update pointers in heap, maybe there's a way to make that work. -- Neil T. Dantam From hosking at cs.purdue.edu Mon Jan 14 22:17:11 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 14 Jan 2008 16:17:11 -0500 Subject: [M3devel] GC question In-Reply-To: <200801142053.m0EKrIMi087093@camembert.async.caltech.edu> References: <200801142053.m0EKrIMi087093@camembert.async.caltech.edu> Message-ID: <425DF106-9200-4E49-86FE-DCF377FEC631@cs.purdue.edu> I'm not sure what your purpose here might be. You shouldn't assume anything about an object's precise location since the collector is free to move it around. What are you trying to do? If you are trying to *replace* one object with another and have all references to the old object refer to the new object, then, yes, you really need to get intimately involved with the GC, since it will need to go through the whole heap and redirect those references. It is doable, but messy, and probably requires that all threads in the system be stopped while you pull off the switch. To do it without stopping all the threads requires that you do something much smarter (see papers on replicating GC...). On Jan 14, 2008, at 3:53 PM, Mika Nystrom wrote: > It would have to be able to return an error, no? If there's > an ambiguous root pointing to the object... > > > Darko writes: >> Tony, >> >> I imagine you're intimately familiar with the garbage collector >> implementation. If I wanted to implement a 'reallocate' function that >> preserved references to an object although the object was >> reallocated, >> ie change all existing references from the old object to the new >> object, would this be straight forward using the code of the current >> GC implementation? Is there any existing function that might do >> something like this already? >> >> Thanks, >> Darko. From hosking at cs.purdue.edu Mon Jan 14 22:17:46 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 14 Jan 2008 16:17:46 -0500 Subject: [M3devel] GC question In-Reply-To: <200801142053.m0EKrIMi087093@camembert.async.caltech.edu> References: <200801142053.m0EKrIMi087093@camembert.async.caltech.edu> Message-ID: PS Yes, if there is an ambiguous root pointing at the object then you are stuck. On Jan 14, 2008, at 3:53 PM, Mika Nystrom wrote: > It would have to be able to return an error, no? If there's > an ambiguous root pointing to the object... > > > Darko writes: >> Tony, >> >> I imagine you're intimately familiar with the garbage collector >> implementation. If I wanted to implement a 'reallocate' function that >> preserved references to an object although the object was >> reallocated, >> ie change all existing references from the old object to the new >> object, would this be straight forward using the code of the current >> GC implementation? Is there any existing function that might do >> something like this already? >> >> Thanks, >> Darko. From darko at darko.org Mon Jan 14 22:28:18 2008 From: darko at darko.org (Darko) Date: Mon, 14 Jan 2008 13:28:18 -0800 Subject: [M3devel] GC question In-Reply-To: <425DF106-9200-4E49-86FE-DCF377FEC631@cs.purdue.edu> References: <200801142053.m0EKrIMi087093@camembert.async.caltech.edu> <425DF106-9200-4E49-86FE-DCF377FEC631@cs.purdue.edu> Message-ID: <1AD34A8D-A9A6-464A-B8A1-792B74355528@darko.org> Yep, I want to replace one object with another. One application is to expand open arrays without searching large data structures for references to replace. Maybe a simpler question is can you increase the size of an allocated object without getting messy? On 14/01/2008, at 1:17 PM, Tony Hosking wrote: > I'm not sure what your purpose here might be. You shouldn't assume > anything about an object's precise location since the collector is > free to move it around. What are you trying to do? If you are > trying to *replace* one object with another and have all references > to the old object refer to the new object, then, yes, you really > need to get intimately involved with the GC, since it will need to > go through the whole heap and redirect those references. It is > doable, but messy, and probably requires that all threads in the > system be stopped while you pull off the switch. To do it without > stopping all the threads requires that you do something much smarter > (see papers on replicating GC...). > > On Jan 14, 2008, at 3:53 PM, Mika Nystrom wrote: > >> It would have to be able to return an error, no? If there's >> an ambiguous root pointing to the object... >> >> >> Darko writes: >>> Tony, >>> >>> I imagine you're intimately familiar with the garbage collector >>> implementation. If I wanted to implement a 'reallocate' function >>> that >>> preserved references to an object although the object was >>> reallocated, >>> ie change all existing references from the old object to the new >>> object, would this be straight forward using the code of the current >>> GC implementation? Is there any existing function that might do >>> something like this already? >>> >>> Thanks, >>> Darko. > From rodney.bates at wichita.edu Tue Jan 15 00:24:35 2008 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Mon, 14 Jan 2008 17:24:35 -0600 Subject: [M3devel] Static chains In-Reply-To: References: Message-ID: <478BEF33.2050203@wichita.edu> Think of the debugger as an interpreter for a substantial subset of the language. When the program is stopped at some point, m3gdb can, in effect, inject code to evaluate an arbitrary expression, typed by the debugger user, or execute an arbitrary assignment or call statement. Although there are a number of gaps yet in the implementation, m3gdb is approaching fitting this description. The user-typed code can both create and use static link values that do not occur in the original code that the compiler saws. The simplest example is, when stopped in a nested procedure, the user types 'print NonLocalVariable'. This works fine right now, unless the compiler has not stored the SL in the current proc's activation record, which a compiler might well do if the nested proc, as coded, has no references to any nonlocal variables. (Or keeps the SL only in a register, etc.) You could say this is only a convenience, as the user could work around it by just typing 'up' the exact number of times to get to the static parent's frame (which is, of course, also a dynamic ancestor). But that can slow down debugging a great deal, and I often find it a very important convenience. Anyway, you could say that to a degree about much of what a debugger does. A more complex example might be 'print Nested1(Nested2,NonlocalVar)', where Nested1 and Nested2 are nested procedures. Here, the debugger has create and pass the appropriate SL value in order to call Nested1, which, unless Nested1 is one scope deeper than the current stop point, also entails m3gdb's fetching the SL that was given to some procedure on the current dynamic call chain. The same things are required of m3gdb to construct the closure for Nested2, which it must pass to Nested1. And if NonlocalVar is in an outer scope where Nested1 and/or Nested2 aren't visible, there would be no workaround possible at all. Tony, I haven't been able to try out your latest change anyway, as I seem to have once again regressed to not being able to get CM3 to link to a working version of libpthread on Mandriva. Also, I am about to travel for a week, so may be out of this discussion for a while. Tony Hosking wrote: > Rodney, > > I just realised that the static chains variables are *not* always being > set up for nested function internal use. i.e., callers will pass them, > but nested functions that don't explicitly use them will not have a > static chain. Is this something essential for you? Why would you need > a static chain from within a nested function that doesn't use any outer > scope variables? Since it doesn't use any outer scope variables they > cannot affect its execution, so debugging the value of those variables > seems unnecessary. This is the default behavior of gcc for static chains. > > -- Tony > > -- ------------------------------------------------------------- Rodney 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 Jan 15 00:09:08 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 14 Jan 2008 18:09:08 -0500 Subject: [M3devel] GC question In-Reply-To: <1AD34A8D-A9A6-464A-B8A1-792B74355528@darko.org> References: <200801142053.m0EKrIMi087093@camembert.async.caltech.edu> <425DF106-9200-4E49-86FE-DCF377FEC631@cs.purdue.edu> <1AD34A8D-A9A6-464A-B8A1-792B74355528@darko.org> Message-ID: <5D72E480-17E4-4394-B617-83A7A8AF2F66@cs.purdue.edu> On Jan 14, 2008, at 4:28 PM, Darko wrote: > Yep, I want to replace one object with another. One application is > to expand open arrays without searching large data structures for > references to replace. Maybe a simpler question is can you increase > the size of an allocated object without getting messy? Not easily. Old-time Smalltalk systems had an "Object become:" method that you could use to reallocate in this way, but a level of indirection was used to avoid having to scan the heap. How about using an explicit level of indirection of your own? The WeakRef interface may be useful to you here too, so that you can discard indirection state when there are no other references to the object. > > > On 14/01/2008, at 1:17 PM, Tony Hosking wrote: > >> I'm not sure what your purpose here might be. You shouldn't >> assume anything about an object's precise location since the >> collector is free to move it around. What are you trying to do? >> If you are trying to *replace* one object with another and have >> all references to the old object refer to the new object, then, >> yes, you really need to get intimately involved with the GC, since >> it will need to go through the whole heap and redirect those >> references. It is doable, but messy, and probably requires that >> all threads in the system be stopped while you pull off the >> switch. To do it without stopping all the threads requires that >> you do something much smarter (see papers on replicating GC...). >> >> On Jan 14, 2008, at 3:53 PM, Mika Nystrom wrote: >> >>> It would have to be able to return an error, no? If there's >>> an ambiguous root pointing to the object... >>> >>> >>> Darko writes: >>>> Tony, >>>> >>>> I imagine you're intimately familiar with the garbage collector >>>> implementation. If I wanted to implement a 'reallocate' function >>>> that >>>> preserved references to an object although the object was >>>> reallocated, >>>> ie change all existing references from the old object to the new >>>> object, would this be straight forward using the code of the >>>> current >>>> GC implementation? Is there any existing function that might do >>>> something like this already? >>>> >>>> Thanks, >>>> Darko. >> From hendrik at topoi.pooq.com Tue Jan 15 00:30:47 2008 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Mon, 14 Jan 2008 18:30:47 -0500 Subject: [M3devel] Static chains In-Reply-To: <4C674DDA-00B2-4AFF-B78F-597C7ACC0E73@cs.purdue.edu> References: <20080114171950.GB20313@topoi.pooq.com> <4C674DDA-00B2-4AFF-B78F-597C7ACC0E73@cs.purdue.edu> Message-ID: <20080114233047.GC20313@topoi.pooq.com> On Mon, Jan 14, 2008 at 01:36:31PM -0500, Tony Hosking wrote: > I believe Modula-3's downward-only (ie, only to callee's) exposure > rules for procedure values will avoid this issue. Yes, that's true. But you mentioned static links i the context o gcc: > >>the value of those variables seems unnecessary. This is the default > >>behavior of gcc for static chains. so perhaps there was still some relevance. -- hendrik From darko at darko.org Tue Jan 15 01:39:23 2008 From: darko at darko.org (Darko) Date: Mon, 14 Jan 2008 16:39:23 -0800 Subject: [M3devel] GC question In-Reply-To: <5D72E480-17E4-4394-B617-83A7A8AF2F66@cs.purdue.edu> References: <200801142053.m0EKrIMi087093@camembert.async.caltech.edu> <425DF106-9200-4E49-86FE-DCF377FEC631@cs.purdue.edu> <1AD34A8D-A9A6-464A-B8A1-792B74355528@darko.org> <5D72E480-17E4-4394-B617-83A7A8AF2F66@cs.purdue.edu> Message-ID: <44DE2F53-50D6-4A32-AD7E-F8716E425D7B@darko.org> Yes, I was considering that and other options, I was just hoping to move the complexity to the compiler, where I thought it might already be implemented. I have to try keep my code very clean and simple. On 14/01/2008, at 3:09 PM, Tony Hosking wrote: > > On Jan 14, 2008, at 4:28 PM, Darko wrote: > >> Yep, I want to replace one object with another. One application is >> to expand open arrays without searching large data structures for >> references to replace. Maybe a simpler question is can you increase >> the size of an allocated object without getting messy? > > Not easily. > > Old-time Smalltalk systems had an "Object become:" method that you > could use to reallocate in this way, but a level of indirection was > used to avoid having to scan the heap. How about using an explicit > level of indirection of your own? The WeakRef interface may be > useful to you here too, so that you can discard indirection state > when there are no other references to the object. > >> >> >> On 14/01/2008, at 1:17 PM, Tony Hosking wrote: >> >>> I'm not sure what your purpose here might be. You shouldn't >>> assume anything about an object's precise location since the >>> collector is free to move it around. What are you trying to do? >>> If you are trying to *replace* one object with another and have >>> all references to the old object refer to the new object, then, >>> yes, you really need to get intimately involved with the GC, since >>> it will need to go through the whole heap and redirect those >>> references. It is doable, but messy, and probably requires that >>> all threads in the system be stopped while you pull off the >>> switch. To do it without stopping all the threads requires that >>> you do something much smarter (see papers on replicating GC...). >>> >>> On Jan 14, 2008, at 3:53 PM, Mika Nystrom wrote: >>> >>>> It would have to be able to return an error, no? If there's >>>> an ambiguous root pointing to the object... >>>> >>>> >>>> Darko writes: >>>>> Tony, >>>>> >>>>> I imagine you're intimately familiar with the garbage collector >>>>> implementation. If I wanted to implement a 'reallocate' function >>>>> that >>>>> preserved references to an object although the object was >>>>> reallocated, >>>>> ie change all existing references from the old object to the new >>>>> object, would this be straight forward using the code of the >>>>> current >>>>> GC implementation? Is there any existing function that might do >>>>> something like this already? >>>>> >>>>> Thanks, >>>>> Darko. >>> > From rodney.bates at wichita.edu Tue Jan 15 02:56:05 2008 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Mon, 14 Jan 2008 19:56:05 -0600 Subject: [M3devel] Static chains In-Reply-To: <20080114171950.GB20313@topoi.pooq.com> References: <20080114171950.GB20313@topoi.pooq.com> Message-ID: <478C12B5.4050908@wichita.edu> Modula-3 prevents the dangling environment problem with a rule that, while a nested procedure can indeed be passed as a parameter, it can not be assigned to a variable. Only a top-level procedure value can be assigned to a variable. In general, this has to be checked at runtime, at the time of an assignment. The compilers all do this by making the RT representation of a procedure value explicitly denote whether it is nested or top-level. hendrik at topoi.pooq.com wrote: > On Mon, Jan 14, 2008 at 10:47:28AM -0500, Tony Hosking wrote: > >>Rodney, >> >>I just realised that the static chains variables are *not* always >>being set up for nested function internal use. i.e., callers will >>pass them, but nested functions that don't explicitly use them will >>not have a static chain. Is this something essential for you? Why >>would you need a static chain from within a nested function that >>doesn't use any outer scope variables? Since it doesn't use any >>outer scope variables they cannot affect its execution, so debugging >>the value of those variables seems unnecessary. This is the default >>behavior of gcc for static chains. > > > And having them could break languages where it's possible to export > procedures to places where their nonlocal procedures are still in > existence but the intermediate lexical levels which they don't use are > not. (Algol 68 is a case in point) > > -- hendrik > > >>-- Tony >> > > -- ------------------------------------------------------------- Rodney 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 Jan 15 03:13:39 2008 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Mon, 14 Jan 2008 20:13:39 -0600 Subject: [M3devel] Static chains In-Reply-To: <478BEF33.2050203@wichita.edu> References: <478BEF33.2050203@wichita.edu> Message-ID: <478C16D3.6040405@wichita.edu> See embedded corrections I (Rodney M. Bates) wrote: > Think of the debugger as an interpreter for a substantial subset of the > language. When the program is stopped at some point, m3gdb can, in effect, > inject code to evaluate an arbitrary expression, typed by the debugger > user, or execute an arbitrary assignment or call statement. Although > there are a number of gaps yet in the implementation, m3gdb is approaching > fitting this description. > > The user-typed code can both create and use static link values that do > not occur in the original code that the compiler saws. The simplest ^saw > example is, when stopped in a nested procedure, the user types > 'print NonLocalVariable'. This works fine right now, unless the compiler > has not stored the SL in the current proc's activation record, which a > compiler might well do if the nested proc, as coded, has no references > to any nonlocal variables. (Or keeps the SL only in a register, etc.) > > You could say this is only a convenience, as the user could work around > it by just typing 'up' the exact number of times to get to the static > parent's frame (which is, of course, also a dynamic ancestor). But that > can slow down debugging a great deal, and I often find it a very important > convenience. Anyway, you could say that to a degree about much of what a > debugger does. > > A more complex example might be 'print Nested1(Nested2,NonlocalVar)', > where Nested1 and Nested2 are nested procedures. Here, the debugger > has create and pass the appropriate SL value in order to call Nested1, > which, unless Nested1 is one scope deeper than the current stop point, > also entails m3gdb's fetching the SL that was given to some procedure > on the current dynamic call chain. The same things are required of ^static chain. Although it is true that the proc is also on the dynamic chain, that is not what I meant and is confusing at best. > m3gdb to construct the closure for Nested2, which it must pass to Nested1. > And if NonlocalVar is in an outer scope where Nested1 and/or Nested2 > aren't visible, there would be no workaround possible at all. > > Tony, I haven't been able to try out your latest change anyway, as > I seem to have once again regressed to not being able to get CM3 to > link to a working version of libpthread on Mandriva. Also, I am about > to travel for a week, so may be out of this discussion for a while. > > > Tony Hosking wrote: > >> Rodney, >> >> I just realised that the static chains variables are *not* always >> being set up for nested function internal use. i.e., callers will >> pass them, but nested functions that don't explicitly use them will >> not have a static chain. Is this something essential for you? Why >> would you need a static chain from within a nested function that >> doesn't use any outer scope variables? Since it doesn't use any >> outer scope variables they cannot affect its execution, so debugging >> the value of those variables seems unnecessary. This is the default >> behavior of gcc for static chains. >> >> -- Tony >> >> > -- ------------------------------------------------------------- Rodney 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 Jan 15 06:54:05 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 15 Jan 2008 05:54:05 +0000 Subject: [M3devel] Static chains In-Reply-To: <478BEF33.2050203@wichita.edu> References: <478BEF33.2050203@wichita.edu> Message-ID: I really don't think an optimizing compiler should be passing around unused static links just for the debugger to use. The debugger should look up the stack itself. Optimizing compilers remove locals, remove parameters, remove functions, create custom calling conventions, etc. An non-optimizing compiler, sure, I guess. Though it seems some level of optimization should be always on. It pains me to think that every little function call I write might be made, and not inlined. Microsoft compilers now do inlining across static lib boundaries. Or that constant arithmetic like:#define A 1 #define B 2 int c = (A + B) might be computed at runtime. Or that while(1) .. .. if ... break; might generate a runtime check if 1 is not zero (along with the code bloat). Microsoft has "__forceinline", and it is a warning or error if the compiler is unable to inline such a function. - Jay> Date: Mon, 14 Jan 2008 17:24:35 -0600> From: rodney.bates at wichita.edu> To: hosking at cs.purdue.edu> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] Static chains> > Think of the debugger as an interpreter for a substantial subset of the> language. When the program is stopped at some point, m3gdb can, in effect,> inject code to evaluate an arbitrary expression, typed by the debugger> user, or execute an arbitrary assignment or call statement. Although> there are a number of gaps yet in the implementation, m3gdb is approaching> fitting this description.> > The user-typed code can both create and use static link values that do> not occur in the original code that the compiler saws. The simplest> example is, when stopped in a nested procedure, the user types> 'print NonLocalVariable'. This works fine right now, unless the compiler> has not stored the SL in the current proc's activation record, which a> compiler might well do if the nested proc, as coded, has no references> to any nonlocal variables. (Or keeps the SL only in a register, etc.)> > You could say this is only a convenience, as the user could work around> it by just typing 'up' the exact number of times to get to the static> parent's frame (which is, of course, also a dynamic ancestor). But that> can slow down debugging a great deal, and I often find it a very important> convenience. Anyway, you could say that to a degree about much of what a> debugger does.> > A more complex example might be 'print Nested1(Nested2,NonlocalVar)',> where Nested1 and Nested2 are nested procedures. Here, the debugger> has create and pass the appropriate SL value in order to call Nested1,> which, unless Nested1 is one scope deeper than the current stop point,> also entails m3gdb's fetching the SL that was given to some procedure> on the current dynamic call chain. The same things are required of> m3gdb to construct the closure for Nested2, which it must pass to Nested1.> And if NonlocalVar is in an outer scope where Nested1 and/or Nested2> aren't visible, there would be no workaround possible at all.> > Tony, I haven't been able to try out your latest change anyway, as> I seem to have once again regressed to not being able to get CM3 to> link to a working version of libpthread on Mandriva. Also, I am about> to travel for a week, so may be out of this discussion for a while.> > > Tony Hosking wrote:> > Rodney,> > > > I just realised that the static chains variables are *not* always being > > set up for nested function internal use. i.e., callers will pass them, > > but nested functions that don't explicitly use them will not have a > > static chain. Is this something essential for you? Why would you need > > a static chain from within a nested function that doesn't use any outer > > scope variables? Since it doesn't use any outer scope variables they > > cannot affect its execution, so debugging the value of those variables > > seems unnecessary. This is the default behavior of gcc for static chains.> > > > -- Tony> > > > > > -- > -------------------------------------------------------------> Rodney M. Bates, retired assistant professor> Dept. of Computer Science, Wichita State University> Wichita, KS 67260-0083> 316-978-3922> rodney.bates at wichita.edu _________________________________________________________________ Put your friends on the big screen with Windows Vista? + Windows Live?. http://www.microsoft.com/windows/shop/specialoffers.mspx?ocid=TXT_TAGLM_CPC_MediaCtr_bigscreen_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Tue Jan 15 07:00:48 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 15 Jan 2008 06:00:48 +0000 Subject: [M3devel] Static chains In-Reply-To: <478BEF33.2050203@wichita.edu> References: <478BEF33.2050203@wichita.edu> Message-ID: ps: I "like" nested functions, and even the ability for them to capture their outer context, like in Scheme: (define make-adder (lambda x) (lambda y) (x + y)) (define add5 (make-adder 5)) (add 5 4) => 9 but I've lived without this long enough. Capturing just the right amount of context manually is also easy. Otherwise the compiler/runtime either has to a) heap allocate and garbage collect all stack frames b) do the analysis to decide what to heap allocate. I believe Java and C# do b. They don't necessarily have nested "functions", but nested classes with functions, same thing. Java might make you declare captured state as "final" (aka const aka readonly). That said, heap allocated stack frames are a powerful measure in preventing stack exhaustion, which is an otherwise seemingly difficult and ignored problem. The stack is not infinite yet most programmers rarely think about its size. - Jay From: jayk123 at hotmail.comTo: rodney.bates at wichita.edu; hosking at cs.purdue.eduCC: m3devel at elegosoft.comSubject: RE: [M3devel] Static chainsDate: Tue, 15 Jan 2008 05:54:05 +0000 I really don't think an optimizing compiler should be passing around unused static links just for the debugger to use. The debugger should look up the stack itself. Optimizing compilers remove locals, remove parameters, remove functions, create custom calling conventions, etc. An non-optimizing compiler, sure, I guess. Though it seems some level of optimization should be always on.It pains me to think that every little function call I write might be made, and not inlined.Microsoft compilers now do inlining across static lib boundaries.Or that constant arithmetic like:#define A 1#define B 2int c = (A + B) might be computed at runtime. Or that while(1) .. .. if ... break; might generate a runtime check if 1 is not zero (along with the code bloat). Microsoft has "__forceinline", and it is a warning or error if the compiler is unable to inline such a function. - Jay> Date: Mon, 14 Jan 2008 17:24:35 -0600> From: rodney.bates at wichita.edu> To: hosking at cs.purdue.edu> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] Static chains> > Think of the debugger as an interpreter for a substantial subset of the> language. When the program is stopped at some point, m3gdb can, in effect,> inject code to evaluate an arbitrary expression, typed by the debugger> user, or execute an arbitrary assignment or call statement. Although> there are a number of gaps yet in the implementation, m3gdb is approaching> fitting this description.> > The user-typed code can both create and use static link values that do> not occur in the original code that the compiler saws. The simplest> example is, when stopped in a nested procedure, the user types> 'print NonLocalVariable'. This works fine right now, unless the compiler> has not stored the SL in the current proc's activation record, which a> compiler might well do if the nested proc, as coded, has no references> to any nonlocal variables. (Or keeps the SL only in a register, etc.)> > You could say this is only a convenience, as the user could work around> it by just typing 'up' the exact number of times to get to the static> parent's frame (which is, of course, also a dynamic ancestor). But that> can slow down debugging a great deal, and I often find it a very important> convenience. Anyway, you could say that to a degree about much of what a> debugger does.> > A more complex example might be 'print Nested1(Nested2,NonlocalVar)',> where Nested1 and Nested2 are nested procedures. Here, the debugger> has create and pass the appropriate SL value in order to call Nested1,> which, unless Nested1 is one scope deeper than the current stop point,> also entails m3gdb's fetching the SL that was given to some procedure> on the current dynamic call chain. The same things are required of> m3gdb to construct the closure for Nested2, which it must pass to Nested1.> And if NonlocalVar is in an outer scope where Nested1 and/or Nested2> aren't visible, there would be no workaround possible at all.> > Tony, I haven't been able to try out your latest change anyway, as> I seem to have once again regressed to not being able to get CM3 to> link to a working version of libpthread on Mandriva. Also, I am about> to travel for a week, so may be out of this discussion for a while.> > > Tony Hosking wrote:> > Rodney,> > > > I just realised that the static chains variables are *not* always being > > set up for nested function internal use. i.e., callers will pass them, > > but nested functions that don't explicitly use them will not have a > > static chain. Is this something essential for you? Why would you need > > a static chain from within a nested function that doesn't use any outer > > scope variables? Since it doesn't use any outer scope variables they > > cannot affect its execution, so debugging the value of those variables > > seems unnecessary. This is the default behavior of gcc for static chains.> > > > -- Tony> > > > > > -- > -------------------------------------------------------------> Rodney M. Bates, retired assistant professor> Dept. of Computer Science, Wichita State University> Wichita, KS 67260-0083> 316-978-3922> rodney.bates at wichita.edu Put your friends on the big screen with Windows Vista? + Windows Live?. Start now! _________________________________________________________________ Share life as it happens with the new Windows Live. http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Tue Jan 15 08:00:13 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 15 Jan 2008 07:00:13 +0000 Subject: [M3devel] "crazy cross" In-Reply-To: <20080105011335.n767h3zbz4gcgk4k@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> Message-ID: It looks like at least cm3 is "always" target-independent. Whatever target is defined to in cm3.cfg, if it is one of the built in known ones, cm3 will generate code for. Except maybe NT386, though it need not be -- cm3 could have both the .obj and "gcc tree" writing backends both linked into it and dynamically chose between them. Maybe it already does. cm3 operates at a fairly high level when using gcc, and the target specific stuff is just some data about the name of setjmp, the sizeof jmp_buf, etc..The "only" "problem" is then m3cg/as/ld/link.m3cg could be moved to $CM3_INSTALL/pkg/x/HOST/TARGET. cm3, along with everything else, could be $CM3_INSTALL/pkg/x/HOST leaving $CM3_INSTALL/bin/cm3 that is sh and $CM3_INSTALL/bin/cm3.py or cm3.cmd that calls out to cm3. "Fixing" as/ld, well, I don't suppose they tend to be target neutral do they? You'd have to import them like gcc and build them n times. Gaining a much slower build, much larger tree. I suppose anyone could do this themselves, and change cm3.cfg appropriately. Doing things "officially" this way for one "big" distribution, probably folks would not go for. - Jay From: jayk123 at hotmail.comTo: m3devel at elegosoft.comSubject: "crazy cross"Date: Sat, 5 Jan 2008 01:22:13 +0000 You've all heard of "Canadian cross"?It is cross-building a cross-compiler.I'm sitting in Windows. I'm going to build a compiler that is going to run on Linux that is going to target Solaris.For one example.You've all seen that Apple has switches like so:gcc -arch i386 ppc ppc64 x86_64 hello.cand poof out comes a binary that runs natively on four architecturesI don't like the "inconvenience" of non cross systems and having to have all the machines/OSes just to build the binaries.I realize that you hit the wall if you actually want to test the results. So cross building only gets so much.Of course I also don't want to multiply out build times for tools...Ok, well what is the possibility of:cm3 -target NT386cm3 -target NT386 -target PPC_DARWIN? In my crazy imagination, you have: \cm3\bin\cm3.cmd %~dp0..\libexec\%processor_architecture%\%TARGET%\cm3.exe %* \cm3\bin\cm3 #!/bin/sh dirname(dirname($0))/libexec/`uname whatever`/$TARGET/cm3 $@Thus it becomes POSSIBLE to have an n x m matrix, host x target, and be able to build"anything" from one environment.Actually the targets could all be merged into one .exe or be .dll/.sos.Except the code isn't setup for that.Interesting?I guess the hard part is the C code and linking?The Modula-3 stuff is already setup to do most of this? (partly by virtue of all that header rewriting that I labeled sleazy) - Jay Share life as it happens with the new Windows Live. Start sharing! _________________________________________________________________ Share life as it happens with the new Windows Live. http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Tue Jan 15 14:34:25 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 15 Jan 2008 13:34:25 +0000 Subject: [M3devel] NT386GNU status Message-ID: I can build a lot of std, at least up to m3ui. However..nothing works. Everything crashes. In order to build std, I copied back the NT386 cm3 and mklib, though the config sets TARGET=NT386GNU and runs cm3cg. (i.e. I'm not just using the NT386 backend!) The crash is what I mentioned the other day: D:\>\cygwin\bin\gdb \dev2\cm3.2\m3-sys\cm3\NT386GNU\cm3.exeGNU gdb 6.5.50.20060706-cvs (cygwin-special)Copyright (C) 2006 Free Software Foundation, Inc.GDB is free software, covered by the GNU General Public License, and you arewelcome to change it and/or distribute copies of it under certain conditions.Type "show copying" to see the conditions.There is absolutely no warranty for GDB. Type "show warranty" for details.This GDB was configured as "i686-pc-cygwin"...(gdb) runStarting program: D:/dev2/cm3.2/m3-sys/cm3/NT386GNU/cm3.exeLoaded symbols for /cygdrive/d/WINDOWS/system32/ntdll.dllLoaded symbols for /cygdrive/d/WINDOWS/system32/kernel32.dllLoaded symbols for /cygdrive/d/WINDOWS/system32/advapi32.dllLoaded symbols for /cygdrive/d/WINDOWS/system32/rpcrt4.dllLoaded symbols for /cygdrive/d/WINDOWS/system32/gdi32.dllLoaded symbols for /cygdrive/d/WINDOWS/system32/user32.dllLoaded symbols for /cygdrive/d/WINDOWS/system32/msvcrt.dllLoaded symbols for /cygdrive/d/WINDOWS/system32/wsock32.dllLoaded symbols for /cygdrive/d/WINDOWS/system32/ws2_32.dllLoaded symbols for /cygdrive/d/WINDOWS/system32/ws2help.dll Program received signal SIGSEGV, Segmentation fault.0x00000000 in ?? ()(gdb) bt#0 0x00000000 in ?? ()#1 0x005de831 in RTLinker__FindModules (M3_DjPxE3_m=0x682340) at RTLinker.m3:182#2 0x005de5fb in RTLinker__AddUnitI (M3_DjPxE3_m=0x682340) at RTLinker.m3:111#3 0x005de6b0 in RTLinker__AddUnit (M3_DjPxE5_b=0x603fd0) at RTLinker.m3:122#4 0x005de34d in RTLinker__InitRuntime (M3_AcxOUs_p_argc=0, M3_AJWxb1_p_argv=0x3f2bf0, M3_AJWxb1_p_envp=0x3f24c0, M3_AJWxb1_p_instance=0x1) at RTLinker.m3:42#5 0x00401315 in main (argc=1, argv=0x3f24c0, envp=0x3f2bf0) at _m3main.mc:3(gdb) qThe program is running. Exit anyway? (y or n) y D:\> Oh, m3ui and related are broken due to: D:\dev2\cm3.2\m3-tools\m3bundle\NT386GNU\m3bundle -name formseditBundle -FD:\DOCUME~1\Jay\LOCALS~1\Temp\qknew source -> compiling FormsEditVBT.i3new source -> compiling formseditBundle.i3new source -> compiling FormsEditVBT.m3new source -> compiling FormsEdit.m3new source -> compiling formseditBundle.m3 -> linking formsedit.exeD:\dev2\cm3.2/m3-ui\ui\NT386GNU\m3ui.lib.sa(WinTrestle.mo): In function `WinTrestle__ButtonEvent':WinTrestle.m3:1843: undefined reference to `WindowFromPoint at 4'collect2: ld returned 1 exit status"D:\\dev2\\cm3.2\m3-sys\cminstall\src\config\NT386GNU", line 583: quake runtimeerror: link failed, see D:\dev2\cm3.2\m3-ui\formsedit\NT386GNU\formsedit.lst for more information \mingw\bin\nm \MinGW\lib\libuser32.a | findstr WindowFromPoint00000000 T _WindowFromPoint at 800000000 I __imp__WindowFromPoint at 8 Maybe Tony will fix my __stdcall work. :)Or maybe the problem is the declaration.Or maybe I can confirm it is passing a small struct by pointer instead of by referenceand just write a little translation thunk. But also see why NT386 works.Not a big deal. Trestle can wait. If anyone wants to try this stuff out, debug, I can either share diffs or commit them.They are actually pretty small.I just have to look into the definitions of the runtime linker/binder stuff and/orthe assembly, see if there's some disconnect somewhere. Other gdb above, this is all with mingwin + msys. They are enough to build cm3cg. mingwin should suffice for the rest. The ld that comes with the mingwin that free Qt gives you is too old, from around 2004. It doesn't support "response files", which are needed for building some packages due to command line length. The change was made circa 2005. Current "released" Mingwin works (I didn't use "technology preview") Probably I'll take a break for now. - Jay _________________________________________________________________ Share life as it happens with the new Windows Live. http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Tue Jan 15 14:41:49 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 15 Jan 2008 08:41:49 -0500 Subject: [M3devel] Static chains In-Reply-To: References: <478BEF33.2050203@wichita.edu> Message-ID: <8E6886FC-DAD4-452A-9771-F40640045A74@cs.purdue.edu> Yes, I am leery myself of much the same. Gcc is very careful about when a nested procedure is allocated a static link. On Jan 15, 2008, at 12:54 AM, Jay wrote: > I really don't think an optimizing compiler should be passing > around unused static links just for the debugger to use. The > debugger should look up the stack itself. > > Optimizing compilers remove locals, remove parameters, remove > functions, create custom calling conventions, etc. > > An non-optimizing compiler, sure, I guess. > > Though it seems some level of optimization should be always on. > It pains me to think that every little function call I write might > be made, and not inlined. > Microsoft compilers now do inlining across static lib boundaries. > Or that constant arithmetic like: > #define A 1 > #define B 2 > int c = (A + B) > > might be computed at runtime. > > Or that > while(1) > .. > .. if ... break; > > might generate a runtime check if 1 is not zero (along with the > code bloat). > > Microsoft has "__forceinline", and it is a warning or error if the > compiler is unable to inline such a function. > > - Jay > > > > Date: Mon, 14 Jan 2008 17:24:35 -0600 > > From: rodney.bates at wichita.edu > > To: hosking at cs.purdue.edu > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] Static chains > > > > Think of the debugger as an interpreter for a substantial subset > of the > > language. When the program is stopped at some point, m3gdb can, > in effect, > > inject code to evaluate an arbitrary expression, typed by the > debugger > > user, or execute an arbitrary assignment or call statement. Although > > there are a number of gaps yet in the implementation, m3gdb is > approaching > > fitting this description. > > > > The user-typed code can both create and use static link values > that do > > not occur in the original code that the compiler saws. The simplest > > example is, when stopped in a nested procedure, the user types > > 'print NonLocalVariable'. This works fine right now, unless the > compiler > > has not stored the SL in the current proc's activation record, > which a > > compiler might well do if the nested proc, as coded, has no > references > > to any nonlocal variables. (Or keeps the SL only in a register, > etc.) > > > > You could say this is only a convenience, as the user could work > around > > it by just typing 'up' the exact number of times to get to the > static > > parent's frame (which is, of course, also a dynamic ancestor). > But that > > can slow down debugging a great deal, and I often find it a very > important > > convenience. Anyway, you could say that to a degree about much of > what a > > debugger does. > > > > A more complex example might be 'print Nested1 > (Nested2,NonlocalVar)', > > where Nested1 and Nested2 are nested procedures. Here, the debugger > > has create and pass the appropriate SL value in order to call > Nested1, > > which, unless Nested1 is one scope deeper than the current stop > point, > > also entails m3gdb's fetching the SL that was given to some > procedure > > on the current dynamic call chain. The same things are required of > > m3gdb to construct the closure for Nested2, which it must pass to > Nested1. > > And if NonlocalVar is in an outer scope where Nested1 and/or Nested2 > > aren't visible, there would be no workaround possible at all. > > > > Tony, I haven't been able to try out your latest change anyway, as > > I seem to have once again regressed to not being able to get CM3 to > > link to a working version of libpthread on Mandriva. Also, I am > about > > to travel for a week, so may be out of this discussion for a while. > > > > > > Tony Hosking wrote: > > > Rodney, > > > > > > I just realised that the static chains variables are *not* > always being > > > set up for nested function internal use. i.e., callers will > pass them, > > > but nested functions that don't explicitly use them will not > have a > > > static chain. Is this something essential for you? Why would > you need > > > a static chain from within a nested function that doesn't use > any outer > > > scope variables? Since it doesn't use any outer scope variables > they > > > cannot affect its execution, so debugging the value of those > variables > > > seems unnecessary. This is the default behavior of gcc for > static chains. > > > > > > -- Tony > > > > > > > > > > -- > > ------------------------------------------------------------- > > Rodney M. Bates, retired assistant professor > > Dept. of Computer Science, Wichita State University > > Wichita, KS 67260-0083 > > 316-978-3922 > > rodney.bates at wichita.edu > > > Put your friends on the big screen with Windows Vista? + Windows > Live?. Start now! From hosking at cs.purdue.edu Tue Jan 15 14:47:13 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 15 Jan 2008 08:47:13 -0500 Subject: [M3devel] "crazy cross" 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> Message-ID: On Jan 15, 2008, at 2:00 AM, Jay wrote: > It looks like at least cm3 is "always" target-independent. > Whatever target is defined to in cm3.cfg, if it is one of the built > in known ones, cm3 will generate code for. Except maybe NT386, > though it need not be -- cm3 could have both the .obj and "gcc > tree" writing backends both linked into it and dynamically chose > between them. Yes, the cm3 front-end will generate .mo/.io files for any target on any other host. The gcc-based backend runs as a separate process (there are license issues with linking the gcc-based backend directly with the front-end). > Maybe it already does. > cm3 operates at a fairly high level when using gcc, and the target > specific stuff is just some data about the name of setjmp, the > sizeof jmp_buf, etc.. > > The "only" "problem" is then m3cg/as/ld/link. > m3cg could be moved to $CM3_INSTALL/pkg/x/HOST/TARGET. True! > cm3, along with everything else, could be $CM3_INSTALL/pkg/x/HOST > leaving $CM3_INSTALL/bin/cm3 that is sh and $CM3_INSTALL/bin/cm3.py > or cm3.cmd that calls out to cm3. Possibly. > "Fixing" as/ld, well, I don't suppose they tend to be target > neutral do they? You'd have to import them like gcc and build them > n times. Gaining a much slower build, much larger tree. Indeed. > I suppose anyone could do this themselves, and change cm3.cfg > appropriately. Doing things "officially" this way for one "big" > distribution, probably folks would not go for. This is how bootstraps to other targets typically go: cm3 *.m3- >*.mo. Copy .mo files to target. Build cm3cg for target. cm3cg *.mo->*.ms as *.ms->*.o ld *.o->libs/execs. > > > - Jay > > > > From: jayk123 at hotmail.com > To: m3devel at elegosoft.com > Subject: "crazy cross" > Date: Sat, 5 Jan 2008 01:22:13 +0000 > > You've all heard of "Canadian cross"? > > It is cross-building a cross-compiler. > I'm sitting in Windows. I'm going to build a compiler that is going > to run on Linux that is going to target Solaris. > For one example. > > You've all seen that Apple has switches like so: > > gcc -arch i386 ppc ppc64 x86_64 hello.c > and poof out comes a binary that runs natively on four architectures > > I don't like the "inconvenience" of non cross systems and having to > have all the machines/OSes just to build the binaries. > I realize that you hit the wall if you actually want to test the > results. So cross building only gets so much. > Of course I also don't want to multiply out build times for tools... > > Ok, well what is the possibility of: > > cm3 -target NT386 > cm3 -target NT386 -target PPC_DARWIN > > ? In my crazy imagination, you have: > > \cm3\bin\cm3.cmd > %~dp0..\libexec\%processor_architecture%\%TARGET%\cm3.exe %* > > \cm3\bin\cm3 > #!/bin/sh > dirname(dirname($0))/libexec/`uname whatever`/$TARGET/cm3 $@ > > Thus it becomes POSSIBLE to have an n x m matrix, host x target, > and be able to build > "anything" from one environment. > > Actually the targets could all be merged into one .exe or > be .dll/.sos. > Except the code isn't setup for that. > > Interesting? > > I guess the hard part is the C code and linking? > The Modula-3 stuff is already setup to do most of this? > (partly by virtue of all that header rewriting that I labeled > sleazy) > > - Jay > > > > Share life as it happens with the new Windows Live. Start sharing! > > Share life as it happens with the new Windows Live. Start sharing! From hosking at cs.purdue.edu Tue Jan 15 14:54:50 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 15 Jan 2008 08:54:50 -0500 Subject: [M3devel] NT386GNU status In-Reply-To: References: Message-ID: <6D01FCB8-D43D-4927-BA3C-23C566E818E6@cs.purdue.edu> On Jan 15, 2008, at 8:34 AM, Jay wrote: > I can build a lot of std, at least up to m3ui. > > However..nothing works. > > Everything crashes. > > In order to build std, I copied back the NT386 cm3 and mklib, > though the config sets TARGET=NT386GNU and runs cm3cg. > (i.e. I'm not just using the NT386 backend!) > > The crash is what I mentioned the other day: > > D:\>\cygwin\bin\gdb \dev2\cm3.2\m3-sys\cm3\NT386GNU\cm3.exe > GNU gdb 6.5.50.20060706-cvs (cygwin-special) > Copyright (C) 2006 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, > and you are > welcome to change it and/or distribute copies of it under certain > conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for > details. > This GDB was configured as "i686-pc-cygwin"... > (gdb) run > Starting program: D:/dev2/cm3.2/m3-sys/cm3/NT386GNU/cm3.exe > Loaded symbols for /cygdrive/d/WINDOWS/system32/ntdll.dll > Loaded symbols for /cygdrive/d/WINDOWS/system32/kernel32.dll > Loaded symbols for /cygdrive/d/WINDOWS/system32/advapi32.dll > Loaded symbols for /cygdrive/d/WINDOWS/system32/rpcrt4.dll > Loaded symbols for /cygdrive/d/WINDOWS/system32/gdi32.dll > Loaded symbols for /cygdrive/d/WINDOWS/system32/user32.dll > Loaded symbols for /cygdrive/d/WINDOWS/system32/msvcrt.dll > Loaded symbols for /cygdrive/d/WINDOWS/system32/wsock32.dll > Loaded symbols for /cygdrive/d/WINDOWS/system32/ws2_32.dll > Loaded symbols for /cygdrive/d/WINDOWS/system32/ws2help.dll > > Program received signal SIGSEGV, Segmentation fault. > 0x00000000 in ?? () > (gdb) bt > #0 0x00000000 in ?? () > #1 0x005de831 in RTLinker__FindModules (M3_DjPxE3_m=0x682340) > at RTLinker.m3:182 > #2 0x005de5fb in RTLinker__AddUnitI (M3_DjPxE3_m=0x682340) at > RTLinker.m3:111 > #3 0x005de6b0 in RTLinker__AddUnit (M3_DjPxE5_b=0x603fd0) at > RTLinker.m3:122 > #4 0x005de34d in RTLinker__InitRuntime (M3_AcxOUs_p_argc=0, > M3_AJWxb1_p_argv=0x3f2bf0, M3_AJWxb1_p_envp=0x3f24c0, > M3_AJWxb1_p_instance=0x1) at RTLinker.m3:42 > #5 0x00401315 in main (argc=1, argv=0x3f24c0, envp=0x3f2bf0) at > _m3main.mc:3 > (gdb) q > The program is running. Exit anyway? (y or n) y > D:\> Looks like a problem with the run-time linker. Something must be broken in the compiler-generated link info. Not sure why... > Oh, m3ui and related are broken due to: > > D:\dev2\cm3.2\m3-tools\m3bundle\NT386GNU\m3bundle -name > formseditBundle -FD:\DOC > UME~1\Jay\LOCALS~1\Temp\qk > new source -> compiling FormsEditVBT.i3 > new source -> compiling formseditBundle.i3 > new source -> compiling FormsEditVBT.m3 > new source -> compiling FormsEdit.m3 > new source -> compiling formseditBundle.m3 > -> linking formsedit.exe > D:\dev2\cm3.2/m3-ui\ui\NT386GNU\m3ui.lib.sa(WinTrestle.mo): In > function `WinTres > tle__ButtonEvent': > WinTrestle.m3:1843: undefined reference to `WindowFromPoint at 4' > collect2: ld returned 1 exit status > "D:\\dev2\\cm3.2\m3-sys\cminstall\src\config\NT386GNU", line 583: > quake runtime > error: link failed, see D:\dev2\cm3.2\m3-ui\formsedit\NT386GNU > \formsedit.lst for > more information > > \mingw\bin\nm \MinGW\lib\libuser32.a | findstr WindowFromPoint > 00000000 T _WindowFromPoint at 8 > 00000000 I __imp__WindowFromPoint at 8 > > Maybe Tony will fix my __stdcall work. :) Yes, I know what needs doing to m3cc(cm3cg). Just need to do it. > Or maybe the problem is the declaration. > Or maybe I can confirm it is passing a small struct by pointer > instead of by reference > and just write a little translation thunk. But also see why NT386 > works. > Not a big deal. Trestle can wait. > > If anyone wants to try this stuff out, debug, I can either share > diffs or commit them. > They are actually pretty small. > I just have to look into the definitions of the runtime linker/ > binder stuff and/or > the assembly, see if there's some disconnect somewhere. > > Other gdb above, this is all with mingwin + msys. > They are enough to build cm3cg. > mingwin should suffice for the rest. > > The ld that comes with the mingwin that free Qt gives you is too > old, from around 2004. > It doesn't support "response files", which are needed for building > some packages due to command line length. > The change was made circa 2005. Current "released" Mingwin works (I > didn't use "technology preview") > > Probably I'll take a break for now. > > - Jay > > Share life as it happens with the new Windows Live. Start sharing! From jayk123 at hotmail.com Wed Jan 16 00:24:50 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 15 Jan 2008 23:24:50 +0000 Subject: [M3devel] "crazy cross" 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> Message-ID: I forgot some vaguely related things. Do people worry about optimizing away creating new processes? Could m3cg be built as an .so/.dll? Probably. And ok license-wise? Could m3cg be run once per package instead of once per source? gcc and cl both can be: cl -c foo.c bar.c gcc -c foo.c bar.c Currently in NT386GNU I depend on -o, gcc -c foo.c -o foo.obj Would need to handle that, not a big deal. Also, in the scheme below, either cm3.sh/cm3.cmd would have a switch to merely print the "real" cm3's path, or, just as well, sysinfo.sh et. al. would know how to find it, save that process. Furthermore -- multithreaded build? I believe, maybe absent bootstrapping, that cm3 could read "all" the m3makefiles, work out the dependency graph trivially, and build things in parallel. Bootstrappinging works too. It builds only what you say, in the right order. The Python scripts can implement this easily enough. - Jay ---------------------------------------- > CC: m3devel at elegosoft.com > From: hosking at cs.purdue.edu > Subject: Re: [M3devel] "crazy cross" > Date: Tue, 15 Jan 2008 08:47:13 -0500 > To: jayk123 at hotmail.com > > > On Jan 15, 2008, at 2:00 AM, Jay wrote: > >> It looks like at least cm3 is "always" target-independent. >> Whatever target is defined to in cm3.cfg, if it is one of the built >> in known ones, cm3 will generate code for. Except maybe NT386, >> though it need not be -- cm3 could have both the .obj and "gcc >> tree" writing backends both linked into it and dynamically chose >> between them. > > Yes, the cm3 front-end will generate .mo/.io files for any target on > any other host. The gcc-based backend runs as a separate process > (there are license issues with linking the gcc-based backend directly > with the front-end). > >> Maybe it already does. >> cm3 operates at a fairly high level when using gcc, and the target >> specific stuff is just some data about the name of setjmp, the >> sizeof jmp_buf, etc.. >> >> The "only" "problem" is then m3cg/as/ld/link. >> m3cg could be moved to $CM3_INSTALL/pkg/x/HOST/TARGET. > > True! > >> cm3, along with everything else, could be $CM3_INSTALL/pkg/x/HOST >> leaving $CM3_INSTALL/bin/cm3 that is sh and $CM3_INSTALL/bin/cm3.py >> or cm3.cmd that calls out to cm3. > > Possibly. > >> "Fixing" as/ld, well, I don't suppose they tend to be target >> neutral do they? You'd have to import them like gcc and build them >> n times. Gaining a much slower build, much larger tree. > > Indeed. > >> I suppose anyone could do this themselves, and change cm3.cfg >> appropriately. Doing things "officially" this way for one "big" >> distribution, probably folks would not go for. > > This is how bootstraps to other targets typically go: cm3 *.m3- > >*.mo. Copy .mo files to target. Build cm3cg for target. cm3cg > *.mo->*.ms as *.ms->*.o ld *.o->libs/execs. > > >> >> >> - Jay >> >> >> >> From: jayk123 at hotmail.com >> To: m3devel at elegosoft.com >> Subject: "crazy cross" >> Date: Sat, 5 Jan 2008 01:22:13 +0000 >> >> You've all heard of "Canadian cross"? >> >> It is cross-building a cross-compiler. >> I'm sitting in Windows. I'm going to build a compiler that is going >> to run on Linux that is going to target Solaris. >> For one example. >> >> You've all seen that Apple has switches like so: >> >> gcc -arch i386 ppc ppc64 x86_64 hello.c >> and poof out comes a binary that runs natively on four architectures >> >> I don't like the "inconvenience" of non cross systems and having to >> have all the machines/OSes just to build the binaries. >> I realize that you hit the wall if you actually want to test the >> results. So cross building only gets so much. >> Of course I also don't want to multiply out build times for tools... >> >> Ok, well what is the possibility of: >> >> cm3 -target NT386 >> cm3 -target NT386 -target PPC_DARWIN >> >> ? In my crazy imagination, you have: >> >> \cm3\bin\cm3.cmd >> %~dp0..\libexec\%processor_architecture%\%TARGET%\cm3.exe %* >> >> \cm3\bin\cm3 >> #!/bin/sh >> dirname(dirname($0))/libexec/`uname whatever`/$TARGET/cm3 $@ >> >> Thus it becomes POSSIBLE to have an n x m matrix, host x target, >> and be able to build >> "anything" from one environment. >> >> Actually the targets could all be merged into one .exe or >> be .dll/.sos. >> Except the code isn't setup for that. >> >> Interesting? >> >> I guess the hard part is the C code and linking? >> The Modula-3 stuff is already setup to do most of this? >> (partly by virtue of all that header rewriting that I labeled >> sleazy) >> >> - Jay >> >> >> >> Share life as it happens with the new Windows Live. Start sharing! >> >> Share life as it happens with the new Windows Live. Start sharing! > _________________________________________________________________ Watch ?Cause Effect,? a show about real people making a real difference. http://im.live.com/Messenger/IM/MTV/?source=text_watchcause From hosking at cs.purdue.edu Wed Jan 16 00:51:44 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 15 Jan 2008 18:51:44 -0500 Subject: [M3devel] "crazy cross" 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> Message-ID: <1DDFAB54-77B6-4593-B309-2C767D4F1FAC@cs.purdue.edu> On Jan 15, 2008, at 6:24 PM, Jay wrote: > > I forgot some vaguely related things. > > Do people worry about optimizing away creating new processes? Perhaps. > Could m3cg be built as an .so/.dll? Probably. Tricky given gcc's nature. But, m3middle could be glued to gcc to build gcc's trees directly...though I strongly prefer the current arrangement. > And ok license-wise? Um, no. FSF have been generally opposed to the way the Modula-3 backend is a thin front-end veneer over gcc, since we get to use their compiler without infecting M3 with the GPL/LGPL. Of course, it would probably be preferable to have CM3 under the GPL/LGPL > Could m3cg be run once per package instead of once per source? Possibly, though right now m3cg does not use the gcc front-end driver. To be honest, I prefer the separation of concerns between m3middle and the gcc-based backend. It is much easier for debugging and development. > gcc and cl both can be: > cl -c foo.c bar.c > gcc -c foo.c bar.c > Currently in NT386GNU I depend on -o, > gcc -c foo.c -o foo.obj > Would need to handle that, not a big deal. > > Also, in the scheme below, either cm3.sh/cm3.cmd would have a > switch to merely print the "real" cm3's path, or, just as well, > sysinfo.sh et. al. would know how to find it, save that process. > > Furthermore -- multithreaded build? > > I believe, maybe absent bootstrapping, that cm3 could read "all" > the m3makefiles, work out the dependency graph trivially, and build > things in parallel. Bootstrappinging works too. It builds only what > you say, in the right order. The Python scripts can implement this > easily enough. I would strongly prefer to see functionality remain decomposed as it currently is. Tangled balls of string are tough to understand, maintain, and develop. > > - Jay > > ---------------------------------------- >> CC: m3devel at elegosoft.com >> From: hosking at cs.purdue.edu >> Subject: Re: [M3devel] "crazy cross" >> Date: Tue, 15 Jan 2008 08:47:13 -0500 >> To: jayk123 at hotmail.com >> >> >> On Jan 15, 2008, at 2:00 AM, Jay wrote: >> >>> It looks like at least cm3 is "always" target-independent. >>> Whatever target is defined to in cm3.cfg, if it is one of the built >>> in known ones, cm3 will generate code for. Except maybe NT386, >>> though it need not be -- cm3 could have both the .obj and "gcc >>> tree" writing backends both linked into it and dynamically chose >>> between them. >> >> Yes, the cm3 front-end will generate .mo/.io files for any target on >> any other host. The gcc-based backend runs as a separate process >> (there are license issues with linking the gcc-based backend directly >> with the front-end). >> >>> Maybe it already does. >>> cm3 operates at a fairly high level when using gcc, and the target >>> specific stuff is just some data about the name of setjmp, the >>> sizeof jmp_buf, etc.. >>> >>> The "only" "problem" is then m3cg/as/ld/link. >>> m3cg could be moved to $CM3_INSTALL/pkg/x/HOST/TARGET. >> >> True! >> >>> cm3, along with everything else, could be $CM3_INSTALL/pkg/x/HOST >>> leaving $CM3_INSTALL/bin/cm3 that is sh and $CM3_INSTALL/bin/cm3.py >>> or cm3.cmd that calls out to cm3. >> >> Possibly. >> >>> "Fixing" as/ld, well, I don't suppose they tend to be target >>> neutral do they? You'd have to import them like gcc and build them >>> n times. Gaining a much slower build, much larger tree. >> >> Indeed. >> >>> I suppose anyone could do this themselves, and change cm3.cfg >>> appropriately. Doing things "officially" this way for one "big" >>> distribution, probably folks would not go for. >> >> This is how bootstraps to other targets typically go: cm3 *.m3- >>> *.mo. Copy .mo files to target. Build cm3cg for target. cm3cg >> *.mo->*.ms as *.ms->*.o ld *.o->libs/execs. >> >> >>> >>> >>> - Jay >>> >>> >>> >>> From: jayk123 at hotmail.com >>> To: m3devel at elegosoft.com >>> Subject: "crazy cross" >>> Date: Sat, 5 Jan 2008 01:22:13 +0000 >>> >>> You've all heard of "Canadian cross"? >>> >>> It is cross-building a cross-compiler. >>> I'm sitting in Windows. I'm going to build a compiler that is going >>> to run on Linux that is going to target Solaris. >>> For one example. >>> >>> You've all seen that Apple has switches like so: >>> >>> gcc -arch i386 ppc ppc64 x86_64 hello.c >>> and poof out comes a binary that runs natively on four architectures >>> >>> I don't like the "inconvenience" of non cross systems and having to >>> have all the machines/OSes just to build the binaries. >>> I realize that you hit the wall if you actually want to test the >>> results. So cross building only gets so much. >>> Of course I also don't want to multiply out build times for tools... >>> >>> Ok, well what is the possibility of: >>> >>> cm3 -target NT386 >>> cm3 -target NT386 -target PPC_DARWIN >>> >>> ? In my crazy imagination, you have: >>> >>> \cm3\bin\cm3.cmd >>> %~dp0..\libexec\%processor_architecture%\%TARGET%\cm3.exe %* >>> >>> \cm3\bin\cm3 >>> #!/bin/sh >>> dirname(dirname($0))/libexec/`uname whatever`/$TARGET/cm3 $@ >>> >>> Thus it becomes POSSIBLE to have an n x m matrix, host x target, >>> and be able to build >>> "anything" from one environment. >>> >>> Actually the targets could all be merged into one .exe or >>> be .dll/.sos. >>> Except the code isn't setup for that. >>> >>> Interesting? >>> >>> I guess the hard part is the C code and linking? >>> The Modula-3 stuff is already setup to do most of this? >>> (partly by virtue of all that header rewriting that I labeled >>> sleazy) >>> >>> - Jay >>> >>> >>> >>> Share life as it happens with the new Windows Live. Start sharing! >>> >>> Share life as it happens with the new Windows Live. Start sharing! >> > > _________________________________________________________________ > Watch ?Cause Effect,? a show about real people making a real > difference. > http://im.live.com/Messenger/IM/MTV/?source=text_watchcause From jayk123 at hotmail.com Wed Jan 16 04:57:13 2008 From: jayk123 at hotmail.com (Jay) Date: Wed, 16 Jan 2008 03:57:13 +0000 Subject: [M3devel] NT386GNU status In-Reply-To: <6D01FCB8-D43D-4927-BA3C-23C566E818E6@cs.purdue.edu> References: <6D01FCB8-D43D-4927-BA3C-23C566E818E6@cs.purdue.edu> Message-ID: I believe you are perfectly capable of finding this, but fyi: http://msdn2.microsoft.com/en-us/library/ms633558.aspx HWND WindowFromPoint(POINT Point); http://msdn2.microsoft.com/en-us/library/ms536119(VS.85).aspx typedef struct tagPOINT { LONG x; LONG y; } POINT, *PPOINT; http://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/m3core/src/win32/WinUser.i3?rev=1.2;content-type=text%2Fplain <*EXTERNAL WindowFromPoint:WINAPI*>PROCEDURE WindowFromPoint (Point: POINT): HWND; http://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/m3core/src/win32/WinDef.i3 POINT = RECORD x: LONG; y: LONG; END; so 8 byte structs are passed by value.Other small sizes might be an issue as well. Oh.. //#pragma pack(1) made no difference #define X(n) typedef struct { char a[n]; } A ## n; void __stdcall F ## n( A##n a) { } X(1) X(2) X(3) X(4) X(5) X(6) X(7) X(8)X(9) X(10) X(11) X(12) X(13) X(14) X(15)X(16) X(17) X(18) X(19) X(20) X(30) X(90)X(900) X(901) X(902) Y:\>link /dump /symbols t.obj Dump of file t.obj COFF SYMBOL TABLE008 00000000 SECT3 notype () External | _F1 at 4009 00000010 SECT3 notype () External | _F2 at 400A 00000020 SECT3 notype () External | _F3 at 400B 00000030 SECT3 notype () External | _F4 at 400C 00000040 SECT3 notype () External | _F5 at 800D 00000050 SECT3 notype () External | _F6 at 800E 00000060 SECT3 notype () External | _F7 at 800F 00000070 SECT3 notype () External | _F8 at 8010 00000080 SECT3 notype () External | _F9 at 12011 00000090 SECT3 notype () External | _F10 at 12012 000000A0 SECT3 notype () External | _F11 at 12013 000000B0 SECT3 notype () External | _F12 at 12014 000000C0 SECT3 notype () External | _F13 at 16015 000000D0 SECT3 notype () External | _F14 at 16016 000000E0 SECT3 notype () External | _F15 at 16017 000000F0 SECT3 notype () External | _F16 at 16018 00000100 SECT3 notype () External | _F17 at 20019 00000110 SECT3 notype () External | _F18 at 2001A 00000120 SECT3 notype () External | _F19 at 2001B 00000130 SECT3 notype () External | _F20 at 2001C 00000140 SECT3 notype () External | _F30 at 3201D 00000150 SECT3 notype () External | _F90 at 9201E 00000160 SECT3 notype () External | _F900 at 90001F 00000170 SECT3 notype () External | _F901 at 904020 00000180 SECT3 notype () External | _F902 at 904 so, really, pass by value is pass by value, no matter the size.Round struct sizes up to a multiple of 4 (or word size, but this naming stuff and multiple calling conventions is only x86). I thought beyond some small number they'd be passed by pointer and the callee would copy to its local stack..which /might/ still be the case, but it's not how the function naming works at least. I'll check what the code should and does look like. - Jay > From: hosking at cs.purdue.edu> > > Oh, m3ui and related are broken due to:> >> > -> linking formsedit.exe> > WinTrestle.m3:1843: undefined reference to `WindowFromPoint at 4'> >> > \mingw\bin\nm \MinGW\lib\libuser32.a | findstr WindowFromPoint> > 00000000 T _WindowFromPoint at 8> > 00000000 I __imp__WindowFromPoint at 8> >> > Maybe Tony will fix my __stdcall work. :)> > Yes, I know what needs doing to m3cc(cm3cg). Just need to do it. _________________________________________________________________ Make distant family not so distant with Windows Vista? + Windows Live?. http://www.microsoft.com/windows/digitallife/keepintouch.mspx?ocid=TXT_TAGLM_CPC_VideoChat_distantfamily_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcoleburn at scires.com Wed Jan 16 04:52:59 2008 From: rcoleburn at scires.com (Randy Coleburn) Date: Tue, 15 Jan 2008 22:52:59 -0500 Subject: [M3devel] my status on win32 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> <477EA137.1E75.00D7.1@scires.com> Message-ID: <478D394B.1E75.00D7.1@scires.com> Jay et al: I've listed below the steps I've undertaken to try and build the current sources on Windows XP. I've also attached a text file showing the output I got when trying to build everything using Jay's upgrade.cmd script. Unfortunately, I'm getting a build error (see below). Please advise on how to resolve. STEPS I TOOK: ========= 1. Download Microsoft Visual Studio 2008 Express Edition All-in-One .ISO file and burn to DVD. http://www.microsoft.com/express/download/ 2. Install Microsoft Visual C++ 2008 Express Edition from DVD. 3. Use "Microsoft Update" service to check for updates / service packs. 4. Download cygwin setup program from http://cygwin.com/ 5. Ran cygwin setup.exe program to install cygwin for all users. Under "Devel" category, make certain to select "cvs" for installation. 6. Launch cygwin from desktop icon. 7. In cygwin command shell window, execute following two commands, making sure to give email as password when prompted for login: cvs -d :pserver:anonymous at modula3.elegosoft.com:/usr/cvs login cvs -d :pserver:anonymous at modula3.elegosoft.com:/usr/cvs checkout cm3 8. Moved resulting C:\cygwin\home\rcoleburn\cm3 to C:\CM3_CVS_SourceTree Note that you should replace "rcoleburn" above with your Windows login username. 9. Download cm3-min-WIN32-NT386-d5.5.0.zip and cm3-min-WIN32-NT386-d5.5.0-symbols.zip from http://modula3.elegosoft.com/cm3/download.html 10. Unzipped cm3-min-WIN32-NT386-d5.5.0.zip and stored resulting cm3 folder at C:\cm3 11. Unzipped cm3-min-WIN32-NT386-d5.5.0-symbols.zip and stored resulting symbols folder at C:\cm3\symbols 12. Launch Windows Command Prompt shell. The following steps represent commands executed within this shell. 13. path %path%;c:\cm3\bin 14. "C:\Program Files\Microsoft Visual Studio 9.0\VC\vcvarsall.bat" 15. cd C:\CM3_CVS_SourceTree\scripts\win 16. upgrade.cmd ERROR I'M GETTING: ============= === package C:\CM3_CVS_SourceTree\m3-sys\cm3 === +++ "cm3 -build -DROOT=C:\\CM3_CVS_SourceTree -DCM3_VERSION_TEXT=d5.5.1 -DCM3_V ERSION_NUMBER=050501 -DCM3_LAST_CHANGED=2007-12-30 && cm3 -ship -DROOT=C:\\CM3_C VS_SourceTree -DCM3_VERSION_TEXT=d5.5.1 -DCM3_VERSION_NUMBER=050501 -DCM3_LAST_C HANGED=2007-12-30" +++ --- building in NT386 --- ignoring ..\src\m3overrides "C:\CM3_CVS_SourceTree\m3-sys\cm3\src\version.quake", line 136: quake runtime er ror: unable to open "C:\CM3_CVS_SourceTree\m3-sys\cm3\src\../NT386.datenow" for reading --procedure-- -line- -file--- include -- version_impl 136 C:\CM3_CVS_SourceTree\m3-sys\cm3\src\version.quake include_dir 20 C:\CM3_CVS_SourceTree\m3-sys\cm3\src\m3makefile 8 C:\CM3_CVS_SourceTree\m3-sys\cm3\NT386\m3make.args Fatal Error: package build failed ERROR: "cm3 -build -DROOT=C:\\CM3_CVS_SourceTree -DCM3_VERSION_TEXT=d5.5.1 -DCM 3_VERSION_NUMBER=050501 -DCM3_LAST_CHANGED=2007-12-30 && cm3 -ship -DROOT=C:\\CM 3_CVS_SourceTree -DCM3_VERSION_TEXT=d5.5.1 -DCM3_VERSION_NUMBER=050501 -DCM3_LAS T_CHANGED=2007-12-30" ERROR: cd C:\CM3_CVS_SourceTree\m3-sys\cm3 ERROR: set INSTALLROOT=c:\cm3 Regards, Randy -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: cm3setup.txt URL: From jayk123 at hotmail.com Wed Jan 16 05:03:24 2008 From: jayk123 at hotmail.com (Jay) Date: Wed, 16 Jan 2008 04:03:24 +0000 Subject: [M3devel] my status on win32 In-Reply-To: <478D394B.1E75.00D7.1@scires.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> <477EA137.1E75.00D7.1@scires.com> <478D394B.1E75.00D7.1@scires.com> Message-ID: That's not too bad really. 1) I'd recommend putting cm3 at the start of the path instead of the end. 2) Just comment out the offending code to make progress. It's not critical. >> C:\CM3_CVS_SourceTree\m3-sys\cm3\src\../NT386.datenow The code is: C:\CM3_CVS_SourceTree\m3-sys\cm3\src\version.quake or such, included by cm3\src\m3makefile. Does the file exist? Does version.quake use "/" or "SL"? If it uses "/", try replacing with SL (and ampersand for string concat). Could be that a newer binary distributions works better with forward slashes. > 4. > 5. > 6. Launch cygwin from desktop icon. Cygwin is only needed for cvs, I think you realize. Could you send me offline the result of just running "set" after running vcvarsall? I'd like to adapt pylib.py to it maybe. (I can start from 5.1.6 and will try 4.1 at some point.) - Jay Date: Tue, 15 Jan 2008 22:52:59 -0500From: rcoleburn at scires.comTo: m3devel at elegosoft.com; jayk123 at hotmail.comSubject: my status on win32 Jay et al: I've listed below the steps I've undertaken to try and build the current sources on Windows XP. I've also attached a text file showing the output I got when trying to build everything using Jay's upgrade.cmd script. Unfortunately, I'm getting a build error (see below). Please advise on how to resolve. STEPS I TOOK: ========= 1. Download Microsoft Visual Studio 2008 Express Edition All-in-One .ISO file and burn to DVD. http://www.microsoft.com/express/download/ 2. Install Microsoft Visual C++ 2008 Express Edition from DVD. 3. Use "Microsoft Update" service to check for updates / service packs. 4. Download cygwin setup program from http://cygwin.com/ 5. Ran cygwin setup.exe program to install cygwin for all users. Under "Devel" category, make certain to select "cvs" for installation. 6. Launch cygwin from desktop icon. 7. In cygwin command shell window, execute following two commands, making sure to give email as password when prompted for login: cvs -d :pserver:anonymous at modula3.elegosoft.com:/usr/cvs login cvs -d :pserver:anonymous at modula3.elegosoft.com:/usr/cvs checkout cm3 8. Moved resulting C:\cygwin\home\rcoleburn\cm3 to C:\CM3_CVS_SourceTree Note that you should replace "rcoleburn" above with your Windows login username. 9. Download cm3-min-WIN32-NT386-d5.5.0.zip and cm3-min-WIN32-NT386-d5.5.0-symbols.zip from http://modula3.elegosoft.com/cm3/download.html 10. Unzipped cm3-min-WIN32-NT386-d5.5.0.zip and stored resulting cm3 folder at C:\cm3 11. Unzipped cm3-min-WIN32-NT386-d5.5.0-symbols.zip and stored resulting symbols folder at C:\cm3\symbols 12. Launch Windows Command Prompt shell. The following steps represent commands executed within this shell. 13. path %path%;c:\cm3\bin 14. "C:\Program Files\Microsoft Visual Studio 9.0\VC\vcvarsall.bat" 15. cd C:\CM3_CVS_SourceTree\scripts\win 16. upgrade.cmd ERROR I'M GETTING: ============= === package C:\CM3_CVS_SourceTree\m3-sys\cm3 ===+++ "cm3 -build -DROOT=C:\\CM3_CVS_SourceTree -DCM3_VERSION_TEXT=d5.5.1 -DCM3_VERSION_NUMBER=050501 -DCM3_LAST_CHANGED=2007-12-30 && cm3 -ship -DROOT=C:\\CM3_CVS_SourceTree -DCM3_VERSION_TEXT=d5.5.1 -DCM3_VERSION_NUMBER=050501 -DCM3_LAST_CHANGED=2007-12-30" +++--- building in NT386 --- ignoring ..\src\m3overrides "C:\CM3_CVS_SourceTree\m3-sys\cm3\src\version.quake", line 136: quake runtime error: unable to open "C:\CM3_CVS_SourceTree\m3-sys\cm3\src\../NT386.datenow" forreading --procedure-- -line- -file---include -- version_impl 136 C:\CM3_CVS_SourceTree\m3-sys\cm3\src\version.quakeinclude_dir 20 C:\CM3_CVS_SourceTree\m3-sys\cm3\src\m3makefile 8 C:\CM3_CVS_SourceTree\m3-sys\cm3\NT386\m3make.args Fatal Error: package build failedERROR: "cm3 -build -DROOT=C:\\CM3_CVS_SourceTree -DCM3_VERSION_TEXT=d5.5.1 -DCM3_VERSION_NUMBER=050501 -DCM3_LAST_CHANGED=2007-12-30 && cm3 -ship -DROOT=C:\\CM3_CVS_SourceTree -DCM3_VERSION_TEXT=d5.5.1 -DCM3_VERSION_NUMBER=050501 -DCM3_LAST_CHANGED=2007-12-30"ERROR: cd C:\CM3_CVS_SourceTree\m3-sys\cm3ERROR: set INSTALLROOT=c:\cm3 Regards, Randy _________________________________________________________________ Share life as it happens with the new Windows Live. http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcoleburn at scires.com Wed Jan 16 05:30:01 2008 From: rcoleburn at scires.com (Randy Coleburn) Date: Tue, 15 Jan 2008 23:30:01 -0500 Subject: [M3devel] my status on win32 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> <477EA137.1E75.00D7.1@scires.com> <478D394B.1E75.00D7.1@scires.com> Message-ID: <478D41F9.1E75.00D7.1@scires.com> Jay: The file version.quake does exist in m3-sys\cm3\src I'm not much of a quake programmer, so not sure exactly how to alter this file. I did a search for "SL" but did not find it. Regards, Randy >>> Jay 1/15/2008 11:03 PM >>> That's not too bad really. 1) I'd recommend putting cm3 at the start of the path instead of the end. 2) Just comment out the offending code to make progress. It's not critical. >> C:\CM3_CVS_SourceTree\m3-sys\cm3\src\../NT386.datenow The code is: C:\CM3_CVS_SourceTree\m3-sys\cm3\src\version.quake or such, included by cm3\src\m3makefile. Does the file exist? Does version.quake use "/" or "SL"? If it uses "/", try replacing with SL (and ampersand for string concat). Could be that a newer binary distributions works better with forward slashes. > 4. > 5. > 6. Launch cygwin from desktop icon. Cygwin is only needed for cvs, I think you realize. Could you send me offline the result of just running "set" after running vcvarsall? I'd like to adapt pylib.py to it maybe. (I can start from 5.1.6 and will try 4.1 at some point.) - Jay Date: Tue, 15 Jan 2008 22:52:59 -0500 From: rcoleburn at scires.com To: m3devel at elegosoft.com; jayk123 at hotmail.com Subject: my status on win32 Jay et al: I've listed below the steps I've undertaken to try and build the current sources on Windows XP. I've also attached a text file showing the output I got when trying to build everything using Jay's upgrade.cmd script. Unfortunately, I'm getting a build error (see below). Please advise on how to resolve. STEPS I TOOK: ========= 1. Download Microsoft Visual Studio 2008 Express Edition All-in-One .ISO file and burn to DVD. http://www.microsoft.com/express/download/ 2. Install Microsoft Visual C++ 2008 Express Edition from DVD. 3. Use "Microsoft Update" service to check for updates / service packs. 4. Download cygwin setup program from http://cygwin.com/ 5. Ran cygwin setup.exe program to install cygwin for all users. Under "Devel" category, make certain to select "cvs" for installation. 6. Launch cygwin from desktop icon. 7. In cygwin command shell window, execute following two commands, making sure to give email as password when prompted for login: cvs -d :pserver:anonymous at modula3.elegosoft.com:/usr/cvs login cvs -d :pserver:anonymous at modula3.elegosoft.com:/usr/cvs checkout cm3 8. Moved resulting C:\cygwin\home\rcoleburn\cm3 to C:\CM3_CVS_SourceTree Note that you should replace "rcoleburn" above with your Windows login username. 9. Download cm3-min-WIN32-NT386-d5.5.0.zip and cm3-min-WIN32-NT386-d5.5.0-symbols.zip from http://modula3.elegosoft.com/cm3/download.html 10. Unzipped cm3-min-WIN32-NT386-d5.5.0.zip and stored resulting cm3 folder at C:\cm3 11. Unzipped cm3-min-WIN32-NT386-d5.5.0-symbols.zip and stored resulting symbols folder at C:\cm3\symbols 12. Launch Windows Command Prompt shell. The following steps represent commands executed within this shell. 13. path %path%;c:\cm3\bin 14. "C:\Program Files\Microsoft Visual Studio 9.0\VC\vcvarsall.bat" 15. cd C:\CM3_CVS_SourceTree\scripts\win 16. upgrade.cmd ERROR I'M GETTING: ============= === package C:\CM3_CVS_SourceTree\m3-sys\cm3 === +++ "cm3 -build -DROOT=C:\\CM3_CVS_SourceTree -DCM3_VERSION_TEXT=d5.5.1 -DCM3_V ERSION_NUMBER=050501 -DCM3_LAST_CHANGED=2007-12-30 && cm3 -ship -DROOT=C:\\CM3_C VS_SourceTree -DCM3_VERSION_TEXT=d5.5.1 -DCM3_VERSION_NUMBER=050501 -DCM3_LAST_C HANGED=2007-12-30" +++ --- building in NT386 --- ignoring ..\src\m3overrides "C:\CM3_CVS_SourceTree\m3-sys\cm3\src\version.quake", line 136: quake runtime er ror: unable to open "C:\CM3_CVS_SourceTree\m3-sys\cm3\src\../NT386.datenow" for reading --procedure-- -line- -file--- include -- version_impl 136 C:\CM3_CVS_SourceTree\m3-sys\cm3\src\version.quake include_dir 20 C:\CM3_CVS_SourceTree\m3-sys\cm3\src\m3makefile 8 C:\CM3_CVS_SourceTree\m3-sys\cm3\NT386\m3make.args Fatal Error: package build failed ERROR: "cm3 -build -DROOT=C:\\CM3_CVS_SourceTree -DCM3_VERSION_TEXT=d5.5.1 -DCM 3_VERSION_NUMBER=050501 -DCM3_LAST_CHANGED=2007-12-30 && cm3 -ship -DROOT=C:\\CM 3_CVS_SourceTree -DCM3_VERSION_TEXT=d5.5.1 -DCM3_VERSION_NUMBER=050501 -DCM3_LAS T_CHANGED=2007-12-30" ERROR: cd C:\CM3_CVS_SourceTree\m3-sys\cm3 ERROR: set INSTALLROOT=c:\cm3 Regards, Randy Share life as it happens with the new Windows Live. Start sharing! ( 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 Wed Jan 16 05:55:39 2008 From: rcoleburn at scires.com (Randy Coleburn) Date: Tue, 15 Jan 2008 23:55:39 -0500 Subject: [M3devel] my status on win32 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> <477EA137.1E75.00D7.1@scires.com> <478D394B.1E75.00D7.1@scires.com> Message-ID: <478D47FB.1E75.00D7.1@scires.com> Jay: In the file version.quake, I made the following edit: changed line: local datefn = "../" & TARGET & ".datenow" to: local datefn = ".." & SL & TARGET & ".datenow" This change has the effect of putting a backward slash in the pathname instead of a forward slash, so we get C:\CM3_CVS_SourceTree\m3-sys\cm3\src\..\NT386.datenow So from that perspective, the change seems good. Unfortunately, I still get the error that this file can't be opened. A quick check of C:\CM3_CVS_SourceTree\m3-sys\cm3\NT386 shows that the file .datenow does not exist. Regards, Randy >>> Jay 1/15/2008 11:03 PM >>> That's not too bad really. 1) I'd recommend putting cm3 at the start of the path instead of the end. 2) Just comment out the offending code to make progress. It's not critical. >> C:\CM3_CVS_SourceTree\m3-sys\cm3\src\../NT386.datenow The code is: C:\CM3_CVS_SourceTree\m3-sys\cm3\src\version.quake or such, included by cm3\src\m3makefile. Does the file exist? Does version.quake use "/" or "SL"? If it uses "/", try replacing with SL (and ampersand for string concat). Could be that a newer binary distributions works better with forward slashes. > 4. > 5. > 6. Launch cygwin from desktop icon. Cygwin is only needed for cvs, I think you realize. Could you send me offline the result of just running "set" after running vcvarsall? I'd like to adapt pylib.py to it maybe. (I can start from 5.1.6 and will try 4.1 at some point.) - Jay Date: Tue, 15 Jan 2008 22:52:59 -0500 From: rcoleburn at scires.com To: m3devel at elegosoft.com; jayk123 at hotmail.com Subject: my status on win32 Jay et al: I've listed below the steps I've undertaken to try and build the current sources on Windows XP. I've also attached a text file showing the output I got when trying to build everything using Jay's upgrade.cmd script. Unfortunately, I'm getting a build error (see below). Please advise on how to resolve. STEPS I TOOK: ========= 1. Download Microsoft Visual Studio 2008 Express Edition All-in-One .ISO file and burn to DVD. http://www.microsoft.com/express/download/ 2. Install Microsoft Visual C++ 2008 Express Edition from DVD. 3. Use "Microsoft Update" service to check for updates / service packs. 4. Download cygwin setup program from http://cygwin.com/ 5. Ran cygwin setup.exe program to install cygwin for all users. Under "Devel" category, make certain to select "cvs" for installation. 6. Launch cygwin from desktop icon. 7. In cygwin command shell window, execute following two commands, making sure to give email as password when prompted for login: cvs -d :pserver:anonymous at modula3.elegosoft.com:/usr/cvs login cvs -d :pserver:anonymous at modula3.elegosoft.com:/usr/cvs checkout cm3 8. Moved resulting C:\cygwin\home\rcoleburn\cm3 to C:\CM3_CVS_SourceTree Note that you should replace "rcoleburn" above with your Windows login username. 9. Download cm3-min-WIN32-NT386-d5.5.0.zip and cm3-min-WIN32-NT386-d5.5.0-symbols.zip from http://modula3.elegosoft.com/cm3/download.html 10. Unzipped cm3-min-WIN32-NT386-d5.5.0.zip and stored resulting cm3 folder at C:\cm3 11. Unzipped cm3-min-WIN32-NT386-d5.5.0-symbols.zip and stored resulting symbols folder at C:\cm3\symbols 12. Launch Windows Command Prompt shell. The following steps represent commands executed within this shell. 13. path %path%;c:\cm3\bin 14. "C:\Program Files\Microsoft Visual Studio 9.0\VC\vcvarsall.bat" 15. cd C:\CM3_CVS_SourceTree\scripts\win 16. upgrade.cmd ERROR I'M GETTING: ============= === package C:\CM3_CVS_SourceTree\m3-sys\cm3 === +++ "cm3 -build -DROOT=C:\\CM3_CVS_SourceTree -DCM3_VERSION_TEXT=d5.5.1 -DCM3_V ERSION_NUMBER=050501 -DCM3_LAST_CHANGED=2007-12-30 && cm3 -ship -DROOT=C:\\CM3_C VS_SourceTree -DCM3_VERSION_TEXT=d5.5.1 -DCM3_VERSION_NUMBER=050501 -DCM3_LAST_C HANGED=2007-12-30" +++ --- building in NT386 --- ignoring ..\src\m3overrides "C:\CM3_CVS_SourceTree\m3-sys\cm3\src\version.quake", line 136: quake runtime er ror: unable to open "C:\CM3_CVS_SourceTree\m3-sys\cm3\src\../NT386.datenow" for reading --procedure-- -line- -file--- include -- version_impl 136 C:\CM3_CVS_SourceTree\m3-sys\cm3\src\version.quake include_dir 20 C:\CM3_CVS_SourceTree\m3-sys\cm3\src\m3makefile 8 C:\CM3_CVS_SourceTree\m3-sys\cm3\NT386\m3make.args Fatal Error: package build failed ERROR: "cm3 -build -DROOT=C:\\CM3_CVS_SourceTree -DCM3_VERSION_TEXT=d5.5.1 -DCM 3_VERSION_NUMBER=050501 -DCM3_LAST_CHANGED=2007-12-30 && cm3 -ship -DROOT=C:\\CM 3_CVS_SourceTree -DCM3_VERSION_TEXT=d5.5.1 -DCM3_VERSION_NUMBER=050501 -DCM3_LAS T_CHANGED=2007-12-30" ERROR: cd C:\CM3_CVS_SourceTree\m3-sys\cm3 ERROR: set INSTALLROOT=c:\cm3 Regards, Randy Share life as it happens with the new Windows Live. Start sharing! ( 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 Jan 16 07:01:42 2008 From: jayk123 at hotmail.com (Jay) Date: Wed, 16 Jan 2008 06:01:42 +0000 Subject: [M3devel] my status on win32 In-Reply-To: <478D47FB.1E75.00D7.1@scires.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> <477EA137.1E75.00D7.1@scires.com> <478D394B.1E75.00D7.1@scires.com> <478D47FB.1E75.00D7.1@scires.com> Message-ID: I think I see the problem. in cm3\src\m3makefile, make this change > if not defined("NOW") include(datefn) > end datefn is only created if certain other variables aren't defined, and do-pkg defines them. I don't know why I don't see this. Later. Could be that the Python scripts have a typo and don't define them.I've been using them more than cmd. If the host is NT, "NOW" is either gotten from an updated cm3.exe, or left to "not available". So the initial cm3 built from older cm3 can't report when it was built, but cm3 built from current cm3 can. I need to change that: 1) to be a function for niceness 2) to make it that way for Posix, for any host but I haven't been using Posix as much lately so not testing it. - Jay Date: Tue, 15 Jan 2008 23:55:39 -0500From: rcoleburn at scires.comTo: m3devel at elegosoft.com; jayk123 at hotmail.comSubject: RE: my status on win32 Jay: In the file version.quake, I made the following edit: changed line: local datefn = "../" & TARGET & ".datenow" to: local datefn = ".." & SL & TARGET & ".datenow" This change has the effect of putting a backward slash in the pathname instead of a forward slash, so we getC:\CM3_CVS_SourceTree\m3-sys\cm3\src\..\NT386.datenow So from that perspective, the change seems good. Unfortunately, I still get the error that this file can't be opened. A quick check of C:\CM3_CVS_SourceTree\m3-sys\cm3\NT386 shows that the file .datenow does not exist. Regards, Randy>>> Jay 1/15/2008 11:03 PM >>>That's not too bad really. 1) I'd recommend putting cm3 at the start of the path instead of the end. 2) Just comment out the offending code to make progress. It's not critical. >> C:\CM3_CVS_SourceTree\m3-sys\cm3\src\../NT386.datenow The code is: C:\CM3_CVS_SourceTree\m3-sys\cm3\src\version.quake or such, included by cm3\src\m3makefile. Does the file exist?Does version.quake use "/" or "SL"? If it uses "/", try replacing with SL (and ampersand for string concat). Could be that a newer binary distributions works better with forward slashes. > 4. > 5. > 6. Launch cygwin from desktop icon. Cygwin is only needed for cvs, I think you realize. Could you send me offline the result of just running "set" after running vcvarsall? I'd like to adapt pylib.py to it maybe. (I can start from 5.1.6 and will try 4.1 at some point.) - Jay Date: Tue, 15 Jan 2008 22:52:59 -0500From: rcoleburn at scires.comTo: m3devel at elegosoft.com; jayk123 at hotmail.comSubject: my status on win32 Jay et al: I've listed below the steps I've undertaken to try and build the current sources on Windows XP. I've also attached a text file showing the output I got when trying to build everything using Jay's upgrade.cmd script. Unfortunately, I'm getting a build error (see below). Please advise on how to resolve. STEPS I TOOK: ========= 1. Download Microsoft Visual Studio 2008 Express Edition All-in-One .ISO file and burn to DVD. http://www.microsoft.com/express/download/ 2. Install Microsoft Visual C++ 2008 Express Edition from DVD. 3. Use "Microsoft Update" service to check for updates / service packs. 4. Download cygwin setup program from http://cygwin.com/ 5. Ran cygwin setup.exe program to install cygwin for all users. Under "Devel" category, make certain to select "cvs" for installation. 6. Launch cygwin from desktop icon. 7. In cygwin command shell window, execute following two commands, making sure to give email as password when prompted for login: cvs -d :pserver:anonymous at modula3.elegosoft.com:/usr/cvs login cvs -d :pserver:anonymous at modula3.elegosoft.com:/usr/cvs checkout cm3 8. Moved resulting C:\cygwin\home\rcoleburn\cm3 to C:\CM3_CVS_SourceTree Note that you should replace "rcoleburn" above with your Windows login username. 9. Download cm3-min-WIN32-NT386-d5.5.0.zip and cm3-min-WIN32-NT386-d5.5.0-symbols.zip from http://modula3.elegosoft.com/cm3/download.html 10. Unzipped cm3-min-WIN32-NT386-d5.5.0.zip and stored resulting cm3 folder at C:\cm3 11. Unzipped cm3-min-WIN32-NT386-d5.5.0-symbols.zip and stored resulting symbols folder at C:\cm3\symbols 12. Launch Windows Command Prompt shell. The following steps represent commands executed within this shell. 13. path %path%;c:\cm3\bin 14. "C:\Program Files\Microsoft Visual Studio 9.0\VC\vcvarsall.bat" 15. cd C:\CM3_CVS_SourceTree\scripts\win 16. upgrade.cmd ERROR I'M GETTING: ============= === package C:\CM3_CVS_SourceTree\m3-sys\cm3 ===+++ "cm3 -build -DROOT=C:\\CM3_CVS_SourceTree -DCM3_VERSION_TEXT=d5.5.1 -DCM3_VERSION_NUMBER=050501 -DCM3_LAST_CHANGED=2007-12-30 && cm3 -ship -DROOT=C:\\CM3_CVS_SourceTree -DCM3_VERSION_TEXT=d5.5.1 -DCM3_VERSION_NUMBER=050501 -DCM3_LAST_CHANGED=2007-12-30" +++--- building in NT386 --- ignoring ..\src\m3overrides "C:\CM3_CVS_SourceTree\m3-sys\cm3\src\version.quake", line 136: quake runtime error: unable to open "C:\CM3_CVS_SourceTree\m3-sys\cm3\src\../NT386.datenow" forreading --procedure-- -line- -file---include -- version_impl 136 C:\CM3_CVS_SourceTree\m3-sys\cm3\src\version.quakeinclude_dir 20 C:\CM3_CVS_SourceTree\m3-sys\cm3\src\m3makefile 8 C:\CM3_CVS_SourceTree\m3-sys\cm3\NT386\m3make.args Fatal Error: package build failedERROR: "cm3 -build -DROOT=C:\\CM3_CVS_SourceTree -DCM3_VERSION_TEXT=d5.5.1 -DCM3_VERSION_NUMBER=050501 -DCM3_LAST_CHANGED=2007-12-30 && cm3 -ship -DROOT=C:\\CM3_CVS_SourceTree -DCM3_VERSION_TEXT=d5.5.1 -DCM3_VERSION_NUMBER=050501 -DCM3_LAST_CHANGED=2007-12-30"ERROR: cd C:\CM3_CVS_SourceTree\m3-sys\cm3ERROR: set INSTALLROOT=c:\cm3 Regards, Randy Share life as it happens with the new Windows Live. Start sharing! _________________________________________________________________ Put your friends on the big screen with Windows Vista? + Windows Live?. http://www.microsoft.com/windows/shop/specialoffers.mspx?ocid=TXT_TAGLM_CPC_MediaCtr_bigscreen_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Wed Jan 16 07:04:48 2008 From: jayk123 at hotmail.com (Jay) Date: Wed, 16 Jan 2008 06:04:48 +0000 Subject: [M3devel] my status on win32 In-Reply-To: <478D47FB.1E75.00D7.1@scires.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> <477EA137.1E75.00D7.1@scires.com> <478D394B.1E75.00D7.1@scires.com> <478D47FB.1E75.00D7.1@scires.com> Message-ID: Note that the file is called "NT386.datenow" in the cm3 directory. I will be changing that too. Outputs don't belong outside of the target directory, unless there is some deliberate need to shield from the frequency of "clean" / "realclean", like if only some other "really really clean" event should cause them to be regenerated. I believe Olaf oked this privately but like I said, I want to change a bit more here, and need to test on Posix. Also there's another file with a dot in front of it, and I generally oppose all "hiding" of files -- Unix dot, or Windows attrib -h. - Jay Date: Tue, 15 Jan 2008 23:55:39 -0500From: rcoleburn at scires.comTo: m3devel at elegosoft.com; jayk123 at hotmail.comSubject: RE: my status on win32 Jay: In the file version.quake, I made the following edit: changed line: local datefn = "../" & TARGET & ".datenow" to: local datefn = ".." & SL & TARGET & ".datenow" This change has the effect of putting a backward slash in the pathname instead of a forward slash, so we getC:\CM3_CVS_SourceTree\m3-sys\cm3\src\..\NT386.datenow So from that perspective, the change seems good. Unfortunately, I still get the error that this file can't be opened. A quick check of C:\CM3_CVS_SourceTree\m3-sys\cm3\NT386 shows that the file .datenow does not exist. Regards, Randy>>> Jay 1/15/2008 11:03 PM >>>That's not too bad really. 1) I'd recommend putting cm3 at the start of the path instead of the end. 2) Just comment out the offending code to make progress. It's not critical. >> C:\CM3_CVS_SourceTree\m3-sys\cm3\src\../NT386.datenow The code is: C:\CM3_CVS_SourceTree\m3-sys\cm3\src\version.quake or such, included by cm3\src\m3makefile. Does the file exist?Does version.quake use "/" or "SL"? If it uses "/", try replacing with SL (and ampersand for string concat). Could be that a newer binary distributions works better with forward slashes. > 4. > 5. > 6. Launch cygwin from desktop icon. Cygwin is only needed for cvs, I think you realize. Could you send me offline the result of just running "set" after running vcvarsall? I'd like to adapt pylib.py to it maybe. (I can start from 5.1.6 and will try 4.1 at some point.) - Jay Date: Tue, 15 Jan 2008 22:52:59 -0500From: rcoleburn at scires.comTo: m3devel at elegosoft.com; jayk123 at hotmail.comSubject: my status on win32 Jay et al: I've listed below the steps I've undertaken to try and build the current sources on Windows XP. I've also attached a text file showing the output I got when trying to build everything using Jay's upgrade.cmd script. Unfortunately, I'm getting a build error (see below). Please advise on how to resolve. STEPS I TOOK: ========= 1. Download Microsoft Visual Studio 2008 Express Edition All-in-One .ISO file and burn to DVD. http://www.microsoft.com/express/download/ 2. Install Microsoft Visual C++ 2008 Express Edition from DVD. 3. Use "Microsoft Update" service to check for updates / service packs. 4. Download cygwin setup program from http://cygwin.com/ 5. Ran cygwin setup.exe program to install cygwin for all users. Under "Devel" category, make certain to select "cvs" for installation. 6. Launch cygwin from desktop icon. 7. In cygwin command shell window, execute following two commands, making sure to give email as password when prompted for login: cvs -d :pserver:anonymous at modula3.elegosoft.com:/usr/cvs login cvs -d :pserver:anonymous at modula3.elegosoft.com:/usr/cvs checkout cm3 8. Moved resulting C:\cygwin\home\rcoleburn\cm3 to C:\CM3_CVS_SourceTree Note that you should replace "rcoleburn" above with your Windows login username. 9. Download cm3-min-WIN32-NT386-d5.5.0.zip and cm3-min-WIN32-NT386-d5.5.0-symbols.zip from http://modula3.elegosoft.com/cm3/download.html 10. Unzipped cm3-min-WIN32-NT386-d5.5.0.zip and stored resulting cm3 folder at C:\cm3 11. Unzipped cm3-min-WIN32-NT386-d5.5.0-symbols.zip and stored resulting symbols folder at C:\cm3\symbols 12. Launch Windows Command Prompt shell. The following steps represent commands executed within this shell. 13. path %path%;c:\cm3\bin 14. "C:\Program Files\Microsoft Visual Studio 9.0\VC\vcvarsall.bat" 15. cd C:\CM3_CVS_SourceTree\scripts\win 16. upgrade.cmd ERROR I'M GETTING: ============= === package C:\CM3_CVS_SourceTree\m3-sys\cm3 ===+++ "cm3 -build -DROOT=C:\\CM3_CVS_SourceTree -DCM3_VERSION_TEXT=d5.5.1 -DCM3_VERSION_NUMBER=050501 -DCM3_LAST_CHANGED=2007-12-30 && cm3 -ship -DROOT=C:\\CM3_CVS_SourceTree -DCM3_VERSION_TEXT=d5.5.1 -DCM3_VERSION_NUMBER=050501 -DCM3_LAST_CHANGED=2007-12-30" +++--- building in NT386 --- ignoring ..\src\m3overrides "C:\CM3_CVS_SourceTree\m3-sys\cm3\src\version.quake", line 136: quake runtime error: unable to open "C:\CM3_CVS_SourceTree\m3-sys\cm3\src\../NT386.datenow" forreading --procedure-- -line- -file---include -- version_impl 136 C:\CM3_CVS_SourceTree\m3-sys\cm3\src\version.quakeinclude_dir 20 C:\CM3_CVS_SourceTree\m3-sys\cm3\src\m3makefile 8 C:\CM3_CVS_SourceTree\m3-sys\cm3\NT386\m3make.args Fatal Error: package build failedERROR: "cm3 -build -DROOT=C:\\CM3_CVS_SourceTree -DCM3_VERSION_TEXT=d5.5.1 -DCM3_VERSION_NUMBER=050501 -DCM3_LAST_CHANGED=2007-12-30 && cm3 -ship -DROOT=C:\\CM3_CVS_SourceTree -DCM3_VERSION_TEXT=d5.5.1 -DCM3_VERSION_NUMBER=050501 -DCM3_LAST_CHANGED=2007-12-30"ERROR: cd C:\CM3_CVS_SourceTree\m3-sys\cm3ERROR: set INSTALLROOT=c:\cm3 Regards, Randy Share life as it happens with the new Windows Live. Start sharing! _________________________________________________________________ Get the power of Windows + Web with the new Windows Live. http://www.windowslive.com?ocid=TXT_TAGHM_Wave2_powerofwindows_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.caltech.edu Wed Jan 16 09:45:47 2008 From: mika at async.caltech.edu (Mika Nystrom) Date: Wed, 16 Jan 2008 00:45:47 -0800 Subject: [M3devel] m3tests, pickles Message-ID: <200801160845.m0G8jlKE064314@camembert.async.caltech.edu> Can I add something tricky to a wish list on regression testing? Tricky because I don't know the best way to go about it. I have spent quite some time with various versions of Modula-3 tracking down issues with Pickles. Usually the problem is that Pickles aren't transferrable between systems, and it turns out that I have included some type, somewhere, that doesn't translate. MUTEX is a good example. First of all it would be very nice if such system dependencies were kept out (for instance, don't know if it's possible, but something like this...) TYPE RealMutex = OBJECT END; TYPE WinMutex = RealMutex OBJECT (* windows fields *) END; TYPE PosixMutex = RealMutex OBJECT (* POSIX fields *) END; TYPE MUTEX = RealMutex; and of course all that a client sees is MUTEX which is the same across systems. However I realize that what I say above may not be possible or practical in all cases. This brings me to the fact that Pickles are sensitive to certain types of bugs (I think), and it would be very nice to check that all OS/processor builds of M3 make compatible Pickles, with the possible exception of things like MUTEX. Of course this can't be done within a single build... Mika From wagner at elegosoft.com Wed Jan 16 10:11:31 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 16 Jan 2008 10:11:31 +0100 Subject: [M3devel] m3tests, pickles In-Reply-To: <200801160845.m0G8jlKE064314@camembert.async.caltech.edu> References: <200801160845.m0G8jlKE064314@camembert.async.caltech.edu> Message-ID: <20080116101131.reooi2rou8swg84k@mail.elegosoft.com> Quoting Mika Nystrom : > > Can I add something tricky to a wish list on regression testing? > Tricky because I don't know the best way to go about it. > > I have spent quite some time with various versions of Modula-3 > tracking down issues with Pickles. Usually the problem is that > Pickles aren't transferrable between systems, and it turns out that > I have included some type, somewhere, that doesn't translate. > MUTEX is a good example. First of all it would be very nice if > such system dependencies were kept out (for instance, don't know > if it's possible, but something like this...) > > TYPE RealMutex = OBJECT END; > > TYPE WinMutex = RealMutex OBJECT (* windows fields *) END; > TYPE PosixMutex = RealMutex OBJECT (* POSIX fields *) END; > > TYPE MUTEX = RealMutex; > > and of course all that a client sees is MUTEX which is the same > across systems. > > However I realize that what I say above may not be possible or > practical in all cases. > > This brings me to the fact that Pickles are sensitive to certain > types of bugs (I think), and it would be very nice to check that > all OS/processor builds of M3 make compatible Pickles, with the > possible exception of things like MUTEX. Of course this can't be > done within a single build... Sure this can and should be done. We just need reference data for all pickles and check them in for comparison somewhere below m3tests. Would you care to add such a test to the m3tests package? The Modula-3 part should could either just output pickles of various structures and leave the comparison to the existing quake code (simple solution) or run the comparison itself and return proper error messages and return codes (preferred solution). Or have I missed something important that makes this approach fail? Of course it will take some time until we've covered all target platforms with out tinderbox setup. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Jan 16 13:59:03 2008 From: rcoleburn at scires.com (Randy Coleburn) Date: Wed, 16 Jan 2008 07:59:03 -0500 Subject: [M3devel] m3tests, pickles In-Reply-To: <200801160845.m0G8jlKE064314@camembert.async.caltech.edu> References: <200801160845.m0G8jlKE064314@camembert.async.caltech.edu> Message-ID: <478DB947.1E75.00D7.1@scires.com> Mika: I've used pickles between various platforms in the past. I use the Pickle2 variant. In my code, I've registered special picklers to deal with mutexes. Since it doesn't make sense to transfer the state of a mutex between computers, I simply recreate/reinitialize the mutex on the receiving computer. Here is an example of an interface and a module that defines a type ServerConfig.T that I transfer between computers using Pickle2 and network objects. I've omitted some of the detail just to show the important stuff about the special pickling definitions and procedures: INTERFACE ServerConfig; CONST Brand = "ServerConfig"; (* prefix for all branded references *) TYPE T <: Public; Public = ConfigSettings.T OBJECT METHODS init (): T; (* initialize to default settings *) ... END; (* Public *) END ServerConfig. MODULE ServerConfig EXPORTS ServerConfig; IMPORT Pickle2 AS Pickle; TYPE PrivateMutex = MUTEX BRANDED Brand & ".PrivateMutex" OBJECT END; REVEAL T = Public BRANDED Brand & ".T" OBJECT mutex: PrivateMutex := NIL; ... METHODS OVERRIDES init := Init; ... END; (* T *) (*-------------------*) (* Pickle Procedures *) (*-------------------*) TYPE Special = Pickle.Special OBJECT OVERRIDES write := WriteSpecial; read := ReadSpecial; END; (* Special *) PROCEDURE WriteSpecial (self: Special; <*UNUSED*>ref: REFANY; <*UNUSED*>writer: Pickle.Writer ) RAISES {Pickle.Error, <*NOWARN*>Wr.Failure, Thread.Alerted} = (* Special pickle writer for ServerConfig.PrivateMutex objects. *) BEGIN (* WriteSpecial *) IF self.sc = TYPECODE(PrivateMutex) THEN (* omit writing the mutex field *) ELSE RAISE Pickle.Error("ServerConfig.WriteSpecial asked to process unrecognized typecode."); (* should never happen *) END; (* if *) END WriteSpecial; PROCEDURE ReadSpecial (self: Special; reader: Pickle.Reader; id: Pickle.RefID ): REFANY RAISES {Pickle.Error, <*NOWARN*>Rd.EndOfFile, Rd.Failure, Thread.Alerted} = (* Special pickle reader for ServerConfig.PrivateMutex objects. *) BEGIN (* ReadSpecial *) IF self.sc = TYPECODE(PrivateMutex) THEN WITH m = NEW(PrivateMutex) DO reader.noteRef(m, id); RETURN m; END; (* with *) ELSE RAISE Pickle.Error("ServerConfig.ReadSpecial asked to process unrecognized typecode."); (* should never happen *) END; (* if *) END ReadSpecial; BEGIN (* ServerConfig module initialization *) Pickle.RegisterSpecial(NEW(Special, sc := TYPECODE(PrivateMutex))); END ServerConfig. Regards, Randy >>> Mika Nystrom 1/16/2008 3:45 AM >>> Can I add something tricky to a wish list on regression testing? Tricky because I don't know the best way to go about it. I have spent quite some time with various versions of Modula-3 tracking down issues with Pickles. Usually the problem is that Pickles aren't transferrable between systems, and it turns out that I have included some type, somewhere, that doesn't translate. MUTEX is a good example. First of all it would be very nice if such system dependencies were kept out (for instance, don't know if it's possible, but something like this...) TYPE RealMutex = OBJECT END; TYPE WinMutex = RealMutex OBJECT (* windows fields *) END; TYPE PosixMutex = RealMutex OBJECT (* POSIX fields *) END; TYPE MUTEX = RealMutex; and of course all that a client sees is MUTEX which is the same across systems. However I realize that what I say above may not be possible or practical in all cases. This brings me to the fact that Pickles are sensitive to certain types of bugs (I think), and it would be very nice to check that all OS/processor builds of M3 make compatible Pickles, with the possible exception of things like MUTEX. Of course this can't be done within a single build... Mika -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcoleburn at scires.com Wed Jan 16 14:25:49 2008 From: rcoleburn at scires.com (Randy Coleburn) Date: Wed, 16 Jan 2008 08:25:49 -0500 Subject: [M3devel] my status on win32 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> <477EA137.1E75.00D7.1@scires.com> <478D394B.1E75.00D7.1@scires.com> <478D47FB.1E75.00D7.1@scires.com> Message-ID: <478DBF8D.1E75.00D7.1@scires.com> Jay: There is no line in the m3makefile dealing with datefn, so I added the whole statement just before the line include("version.quake") Now, I get an error saying that the variable datefn is not defined. If you change to put quotes around datefn in the include statement, you get an error saying it can't open the file. You made a reference in one of your earlier posts about trying 5.1.6 or 4.1, but note that I started with your cm3-min-WIN32-NT386-d5.5.0.zip , not the 5.1.6 or 4.1 versions. Thus, using d5.5.0 as a base, I am trying to run your "upgrade.cmd" to rebuild the sources I checked out from CVS. Since this doesn't work "out-of-the-box", again I say this fits into the "Broken #1" category. If I can get this to work, I don't mind putting together a Windows installer program that will install the whole thing. That way, folks won't have to install cygwin just to get CVS so that they can install a working cm3. Folks will need to install the free Microsoft Visual C as a prerequisite, but then that's not too bad. Having an installer program would make cm3 more friendly to Windows folks. The current 16-step method is too laborious and error-prone for the person just getting started and they will not give cm3 a second try. As the cm3 system evolves and new releases are made, we will need to keep the installer program up-to-date and I don't mind doing that. After someone gets familiar with cm3 they might want to delve into some of the scripts for rebuilding the system, but until then, I think the installer program is the way to go. Regards, Randy >>> Jay 1/16/2008 1:01 AM >>> I think I see the problem. in cm3\src\m3makefile, make this change > if not defined("NOW") include(datefn) > end datefn is only created if certain other variables aren't defined, and do-pkg defines them. I don't know why I don't see this. Later. Could be that the Python scripts have a typo and don't define them. I've been using them more than cmd. If the host is NT, "NOW" is either gotten from an updated cm3.exe, or left to "not available". So the initial cm3 built from older cm3 can't report when it was built, but cm3 built from current cm3 can. I need to change that: 1) to be a function for niceness 2) to make it that way for Posix, for any host but I haven't been using Posix as much lately so not testing it. - Jay Date: Tue, 15 Jan 2008 23:55:39 -0500 From: rcoleburn at scires.com To: m3devel at elegosoft.com; jayk123 at hotmail.com Subject: RE: my status on win32 Jay: In the file version.quake, I made the following edit: changed line: local datefn = "../" & TARGET & ".datenow" to: local datefn = ".." & SL & TARGET & ".datenow" This change has the effect of putting a backward slash in the pathname instead of a forward slash, so we get C:\CM3_CVS_SourceTree\m3-sys\cm3\src\..\NT386.datenow So from that perspective, the change seems good. Unfortunately, I still get the error that this file can't be opened. A quick check of C:\CM3_CVS_SourceTree\m3-sys\cm3\NT386 shows that the file .datenow does not exist. Regards, Randy >>> Jay 1/15/2008 11:03 PM >>> That's not too bad really. 1) I'd recommend putting cm3 at the start of the path instead of the end. 2) Just comment out the offending code to make progress. It's not critical. >> C:\CM3_CVS_SourceTree\m3-sys\cm3\src\../NT386.datenow The code is: C:\CM3_CVS_SourceTree\m3-sys\cm3\src\version.quake or such, included by cm3\src\m3makefile. Does the file exist? Does version.quake use "/" or "SL"? If it uses "/", try replacing with SL (and ampersand for string concat). Could be that a newer binary distributions works better with forward slashes. > 4. > 5. > 6. Launch cygwin from desktop icon. Cygwin is only needed for cvs, I think you realize. Could you send me offline the result of just running "set" after running vcvarsall? I'd like to adapt pylib.py to it maybe. (I can start from 5.1.6 and will try 4.1 at some point.) - Jay Date: Tue, 15 Jan 2008 22:52:59 -0500 From: rcoleburn at scires.com To: m3devel at elegosoft.com; jayk123 at hotmail.com Subject: my status on win32 Jay et al: I've listed below the steps I've undertaken to try and build the current sources on Windows XP. I've also attached a text file showing the output I got when trying to build everything using Jay's upgrade.cmd script. Unfortunately, I'm getting a build error (see below). Please advise on how to resolve. STEPS I TOOK: ========= 1. Download Microsoft Visual Studio 2008 Express Edition All-in-One .ISO file and burn to DVD. http://www.microsoft.com/express/download/ 2. Install Microsoft Visual C++ 2008 Express Edition from DVD. 3. Use "Microsoft Update" service to check for updates / service packs. 4. Download cygwin setup program from http://cygwin.com/ 5. Ran cygwin setup.exe program to install cygwin for all users. Under "Devel" category, make certain to select "cvs" for installation. 6. Launch cygwin from desktop icon. 7. In cygwin command shell window, execute following two commands, making sure to give email as password when prompted for login: cvs -d :pserver:anonymous at modula3.elegosoft.com:/usr/cvs login cvs -d :pserver:anonymous at modula3.elegosoft.com:/usr/cvs checkout cm3 8. Moved resulting C:\cygwin\home\rcoleburn\cm3 to C:\CM3_CVS_SourceTree Note that you should replace "rcoleburn" above with your Windows login username. 9. Download cm3-min-WIN32-NT386-d5.5.0.zip and cm3-min-WIN32-NT386-d5.5.0-symbols.zip from http://modula3.elegosoft.com/cm3/download.html 10. Unzipped cm3-min-WIN32-NT386-d5.5.0.zip and stored resulting cm3 folder at C:\cm3 11. Unzipped cm3-min-WIN32-NT386-d5.5.0-symbols.zip and stored resulting symbols folder at C:\cm3\symbols 12. Launch Windows Command Prompt shell. The following steps represent commands executed within this shell. 13. path %path%;c:\cm3\bin 14. "C:\Program Files\Microsoft Visual Studio 9.0\VC\vcvarsall.bat" 15. cd C:\CM3_CVS_SourceTree\scripts\win 16. upgrade.cmd ERROR I'M GETTING: ============= === package C:\CM3_CVS_SourceTree\m3-sys\cm3 === +++ "cm3 -build -DROOT=C:\\CM3_CVS_SourceTree -DCM3_VERSION_TEXT=d5.5.1 -DCM3_V ERSION_NUMBER=050501 -DCM3_LAST_CHANGED=2007-12-30 && cm3 -ship -DROOT=C:\\CM3_C VS_SourceTree -DCM3_VERSION_TEXT=d5.5.1 -DCM3_VERSION_NUMBER=050501 -DCM3_LAST_C HANGED=2007-12-30" +++ --- building in NT386 --- ignoring ..\src\m3overrides "C:\CM3_CVS_SourceTree\m3-sys\cm3\src\version.quake", line 136: quake runtime er ror: unable to open "C:\CM3_CVS_SourceTree\m3-sys\cm3\src\../NT386.datenow" for reading --procedure-- -line- -file--- include -- version_impl 136 C:\CM3_CVS_SourceTree\m3-sys\cm3\src\version.quake include_dir 20 C:\CM3_CVS_SourceTree\m3-sys\cm3\src\m3makefile 8 C:\CM3_CVS_SourceTree\m3-sys\cm3\NT386\m3make.args Fatal Error: package build failed ERROR: "cm3 -build -DROOT=C:\\CM3_CVS_SourceTree -DCM3_VERSION_TEXT=d5.5.1 -DCM 3_VERSION_NUMBER=050501 -DCM3_LAST_CHANGED=2007-12-30 && cm3 -ship -DROOT=C:\\CM 3_CVS_SourceTree -DCM3_VERSION_TEXT=d5.5.1 -DCM3_VERSION_NUMBER=050501 -DCM3_LAS T_CHANGED=2007-12-30" ERROR: cd C:\CM3_CVS_SourceTree\m3-sys\cm3 ERROR: set INSTALLROOT=c:\cm3 Regards, Randy Share life as it happens with the new Windows Live. Start sharing! ( http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_012008 ) Put your friends on the big screen with Windows Vista* + Windows Live*. Start now! ( http://www.microsoft.com/windows/shop/specialoffers.mspx?ocid=TXT_TAGLM_CPC_MediaCtr_bigscreen_012008 ) -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Wed Jan 16 15:17:16 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 16 Jan 2008 09:17:16 -0500 Subject: [M3devel] m3tests, pickles In-Reply-To: <478DB947.1E75.00D7.1@scires.com> References: <200801160845.m0G8jlKE064314@camembert.async.caltech.edu> <478DB947.1E75.00D7.1@scires.com> Message-ID: <9C071234-4343-4AEB-B4BF-463FEEDFE831@cs.purdue.edu> Perhaps we just need some builtin specials for types like MUTEX that need different handling. Of course, what does it mean to transfer a MUTEX or a thread anyway?! On Jan 16, 2008, at 7:59 AM, Randy Coleburn wrote: > Mika: > > I've used pickles between various platforms in the past. I use the > Pickle2 variant. > > In my code, I've registered special picklers to deal with mutexes. > Since it doesn't make sense to transfer the state of a mutex > between computers, I simply recreate/reinitialize the mutex on the > receiving computer. Here is an example of an interface and a > module that defines a type ServerConfig.T that I transfer between > computers using Pickle2 and network objects. I've omitted some of > the detail just to show the important stuff about the special > pickling definitions and procedures: > > > INTERFACE ServerConfig; > > CONST > Brand = "ServerConfig"; (* prefix for all branded references *) > TYPE > T <: Public; > > Public = ConfigSettings.T OBJECT > METHODS > init (): T; > (* initialize to default settings *) > ... > END; (* Public *) > END ServerConfig. > > > > MODULE ServerConfig EXPORTS ServerConfig; > > IMPORT > Pickle2 AS Pickle; > TYPE > PrivateMutex = MUTEX BRANDED Brand & ".PrivateMutex" OBJECT END; > REVEAL > T = Public BRANDED Brand & ".T" OBJECT > mutex: PrivateMutex := NIL; > ... > METHODS > OVERRIDES > init := Init; > ... > END; (* T *) > > (*-------------------*) > (* Pickle Procedures *) > (*-------------------*) > > TYPE > Special = Pickle.Special OBJECT > OVERRIDES > write := WriteSpecial; > read := ReadSpecial; > END; (* Special *) > > PROCEDURE WriteSpecial (self: Special; > <*UNUSED*>ref: REFANY; > <*UNUSED*>writer: Pickle.Writer > ) > RAISES {Pickle.Error, > <*NOWARN*>Wr.Failure, Thread.Alerted} = > (* Special pickle writer for ServerConfig.PrivateMutex objects. *) > BEGIN (* WriteSpecial *) > IF self.sc = TYPECODE(PrivateMutex) > THEN > (* omit writing the mutex field *) > ELSE > RAISE Pickle.Error("ServerConfig.WriteSpecial asked to > process unrecognized typecode."); (* should never happen *) > END; (* if *) > END WriteSpecial; > > > > PROCEDURE ReadSpecial (self: Special; > reader: Pickle.Reader; > id: Pickle.RefID > ): REFANY > RAISES {Pickle.Error, > <*NOWARN*>Rd.EndOfFile, Rd.Failure, Thread.Alerted} = > (* Special pickle reader for ServerConfig.PrivateMutex objects. *) > BEGIN (* ReadSpecial *) > IF self.sc = TYPECODE(PrivateMutex) > THEN > WITH m = NEW(PrivateMutex) > DO > reader.noteRef(m, id); > RETURN m; > END; (* with *) > ELSE > RAISE Pickle.Error("ServerConfig.ReadSpecial asked to process > unrecognized typecode."); (* should never happen *) > END; (* if *) > END ReadSpecial; > > > > BEGIN (* ServerConfig module initialization *) > Pickle.RegisterSpecial(NEW(Special, sc := TYPECODE(PrivateMutex))); > END ServerConfig. > > Regards, > Randy > > >>> Mika Nystrom 1/16/2008 3:45 AM >>> > > Can I add something tricky to a wish list on regression testing? > Tricky because I don't know the best way to go about it. > > I have spent quite some time with various versions of Modula-3 > tracking down issues with Pickles. Usually the problem is that > Pickles aren't transferrable between systems, and it turns out that > I have included some type, somewhere, that doesn't translate. > MUTEX is a good example. First of all it would be very nice if > such system dependencies were kept out (for instance, don't know > if it's possible, but something like this...) > > TYPE RealMutex = OBJECT END; > > TYPE WinMutex = RealMutex OBJECT (* windows fields *) END; > TYPE PosixMutex = RealMutex OBJECT (* POSIX fields *) END; > > TYPE MUTEX = RealMutex; > > and of course all that a client sees is MUTEX which is the same > across systems. > > However I realize that what I say above may not be possible or > practical in all cases. > > This brings me to the fact that Pickles are sensitive to certain > types of bugs (I think), and it would be very nice to check that > all OS/processor builds of M3 make compatible Pickles, with the > possible exception of things like MUTEX. Of course this can't be > done within a single build... > > Mika > From jayk123 at hotmail.com Wed Jan 16 16:28:52 2008 From: jayk123 at hotmail.com (Jay) Date: Wed, 16 Jan 2008 15:28:52 +0000 Subject: [M3devel] my status on win32 In-Reply-To: <478DBF8D.1E75.00D7.1@scires.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> <477EA137.1E75.00D7.1@scires.com> <478D394B.1E75.00D7.1@scires.com> <478D47FB.1E75.00D7.1@scires.com> <478DBF8D.1E75.00D7.1@scires.com> Message-ID: Randy, yes and no and clarifications. I mention starting with 5.1.6 as a "worst" or "worse" case. The earlier you start, the harder things are -- for me, to ensure it will work. If you merely start with my 5.5.0, well, what are you rebuilding from source for? Heck, you can use any binary distribution, 4.1, 5.1.6, and just use it. They should work. The n steps you/I give are really actually geared for people who WANT to build from source, it is not what people HAVE to do. As well there have been can be source distributions, to cut out CVS. I'll look into the datefn stuff shortly. As to the installer, well, again, yes and no. The need for the installer is very small. All you have to do today is unzip the .zip somewhere and set the path, and possibly the vcvars thing. That's it. I should..now that you are "pressuring" me for ease of use, teach cm3 about the various %devenvdir%, %vcinstalldir% variables, etc. That way as long as the user installed the tools, even if they elected not to change path/lib/include, cm3 can find the compiler and linker. I know everyone wants to preserve the flexibility of quake/cm3.cfg but...besides, cm3 can be pretty darn smart here. IF cm3.cfg defines SYSTEM_CC, leave things along (NT386 cm3.cfg does not today do that). However if there is now SYSTEM_CC and there is no cl.exe/link.exe in %PATH%, it could go on a quick hunt for them. On the lib and include part, well, the dependency on %include% might only be for errno..maybe not worth it. It has been whatever it is forever, like int* _errno(void); #define errno (*_errno)()). Modula-3 engages in rampant header cloning and CErrnoC was only introduced where that was deemed more fragile than usual, and for Windows it probably wasn't actually fragile -- the fragility, if I may be so rudely judgemental, is because so many other systems are so Johnny-come-lately to arriving at the obviously correct threading model that Windows has had all along (since Win95/NT, can't say anything good about Win3.1; I think OS/2 might have had it correct all along too.). Funny, everyone has FINALLY arrived at the correct threading model, only to have start changing again, since the number of cores and machines is set to be much greater than anticipated, the obvious threading model has been deemed too difficult for anyone to use (Win32, Modula-3, Java, .NET, Python, all the same supposedly too difficult model btw), and so some new one is needed, and well, truthfully, the difficulty is not just for dummies on relatively small multiproc boxes not having simple race conditions, the problem is scaling way way up. Sorry that was my usual tangential. Even the unzip and set path would benefit slightly from a GUI installer. I believe there is some easy thing you can do where you write your GUI installer and you put it in the .zip and then you prepend the GUI self extracting .zip/.exe stub, and you can tell it to run a particular command after the extraction. I guess you might use a fancier thing though? That is, are you going to, say, write a gui installer from scratch in Modula-3? It might be a fun exercise. :) And then you could build the self extracting prefix from source etc. This is the hard way I guess, but more interesing. If you can build an msi or use InstallShield or Wix or something, go ahead. If you use widely availabe free as in beer tools, that can be rolled into whatever automation there is to produce distributions, keeping it up to date shouldn't be a problem. I do have to bring up some annoying questions: 1) Does anyone besides me have the capacity to produce distributions? i.e.: Any Win32 machines left at Elego? 2) I know I ramble. So one of my many tangents/questions went unanswered. Say, in the absence of a gui installer, should .zips/.tar.bz files look like cm3-min-/bin/cm3 or bin/cm3 or cm3/bin/cm3 The last one is more directly usable. The first one is very common. This reminds me though Randy, the distribution I made available was "min", so yeah, like if you are doing any gui programming, using any "standard" library besides m3core or libm3, you'd need to build more from source. I can readily provide you a "std" distribution though. It's "always" been a "problem" to make my files available -- no web site hosting for me -- but recently that wasn't a problem, someone picked the files out of ~jkrell on birch and put them on the web site. Good. One more thing -- Olaf, please confirm repeat yourself, 'cause I admit I wasn't sure it was the right thing, but if you insist, ok. "std" should be "all"? I should not continue to imagine there is a new larger group called "all"? And wherever things are missing from std but do build ok, add them? m3cc should be in std? (I admit some big indecisiveness around m3cc. It is far and away the longest thing to build and so the one you really want to skip the most and leave out of whatever package group. I also wonder if on Windows, there should be some check where if sh is not in the $PATH, just silently skip m3cc? You only need MingWin to build what I have on my system for NT386GNU, except you also need msys just for m3cc. msys is actually quite small, like only 20 files..) Oh, sorry, yet another question. The non-gcc backend is excluded from the build on systems that use the gcc backend. For minimization, that is appropriate. For maximizing cross build capability, it is wrong. The packages build fine. I suspect they work. I am not a user of cross build capability yet, so I don't really care. (What I do for NT386/NT386GNU /might/ be considered sort of a cross build, but it is different/easier). They are small packages. - Jay Date: Wed, 16 Jan 2008 08:25:49 -0500From: rcoleburn at scires.comTo: m3devel at elegosoft.com; jayk123 at hotmail.comSubject: Re: [M3devel] my status on win32 Jay: There is no line in the m3makefile dealing with datefn, so I added the whole statement just before the line include("version.quake") Now, I get an error saying that the variable datefn is not defined. If you change to put quotes around datefn in the include statement, you get an error saying it can't open the file. You made a reference in one of your earlier posts about trying 5.1.6 or 4.1, but note that I started with your cm3-min-WIN32-NT386-d5.5.0.zip , not the 5.1.6 or 4.1 versions. Thus, using d5.5.0 as a base, I am trying to run your "upgrade.cmd" to rebuild the sources I checked out from CVS. Since this doesn't work "out-of-the-box", again I say this fits into the "Broken #1" category. If I can get this to work, I don't mind putting together a Windows installer program that will install the whole thing. That way, folks won't have to install cygwin just to get CVS so that they can install a working cm3. Folks will need to install the free Microsoft Visual C as a prerequisite, but then that's not too bad. Having an installer program would make cm3 more friendly to Windows folks. The current 16-step method is too laborious and error-prone for the person just getting started and they will not give cm3 a second try. As the cm3 system evolves and new releases are made, we will need to keep the installer program up-to-date and I don't mind doing that. After someone gets familiar with cm3 they might want to delve into some of the scripts for rebuilding the system, but until then, I think the installer program is the way to go. Regards, Randy>>> Jay 1/16/2008 1:01 AM >>>I think I see the problem. in cm3\src\m3makefile, make this change > if not defined("NOW") include(datefn) > end datefn is only created if certain other variables aren't defined, and do-pkg defines them.I don't know why I don't see this. Later.Could be that the Python scripts have a typo and don't define them.I've been using them more than cmd. If the host is NT, "NOW" is either gotten from an updated cm3.exe, or left to "not available". So the initial cm3 built from older cm3 can't report when it was built, but cm3 built from current cm3 can. I need to change that: 1) to be a function for niceness 2) to make it that way for Posix, for any host but I haven't been using Posix as much lately so not testing it. - Jay Date: Tue, 15 Jan 2008 23:55:39 -0500From: rcoleburn at scires.comTo: m3devel at elegosoft.com; jayk123 at hotmail.comSubject: RE: my status on win32 Jay: In the file version.quake, I made the following edit: changed line: local datefn = "../" & TARGET & ".datenow" to: local datefn = ".." & SL & TARGET & ".datenow" This change has the effect of putting a backward slash in the pathname instead of a forward slash, so we getC:\CM3_CVS_SourceTree\m3-sys\cm3\src\..\NT386.datenow So from that perspective, the change seems good. Unfortunately, I still get the error that this file can't be opened. A quick check of C:\CM3_CVS_SourceTree\m3-sys\cm3\NT386 shows that the file .datenow does not exist. Regards, Randy>>> Jay 1/15/2008 11:03 PM >>>That's not too bad really. 1) I'd recommend putting cm3 at the start of the path instead of the end. 2) Just comment out the offending code to make progress. It's not critical. >> C:\CM3_CVS_SourceTree\m3-sys\cm3\src\../NT386.datenow The code is: C:\CM3_CVS_SourceTree\m3-sys\cm3\src\version.quake or such, included by cm3\src\m3makefile. Does the file exist?Does version.quake use "/" or "SL"? If it uses "/", try replacing with SL (and ampersand for string concat). Could be that a newer binary distributions works better with forward slashes. > 4. > 5. > 6. Launch cygwin from desktop icon. Cygwin is only needed for cvs, I think you realize. Could you send me offline the result of just running "set" after running vcvarsall? I'd like to adapt pylib.py to it maybe. (I can start from 5.1.6 and will try 4.1 at some point.) - Jay Date: Tue, 15 Jan 2008 22:52:59 -0500From: rcoleburn at scires.comTo: m3devel at elegosoft.com; jayk123 at hotmail.comSubject: my status on win32 Jay et al: I've listed below the steps I've undertaken to try and build the current sources on Windows XP. I've also attached a text file showing the output I got when trying to build everything using Jay's upgrade.cmd script. Unfortunately, I'm getting a build error (see below). Please advise on how to resolve. STEPS I TOOK: ========= 1. Download Microsoft Visual Studio 2008 Express Edition All-in-One .ISO file and burn to DVD. http://www.microsoft.com/express/download/ 2. Install Microsoft Visual C++ 2008 Express Edition from DVD. 3. Use "Microsoft Update" service to check for updates / service packs. 4. Download cygwin setup program from http://cygwin.com/ 5. Ran cygwin setup.exe program to install cygwin for all users. Under "Devel" category, make certain to select "cvs" for installation. 6. Launch cygwin from desktop icon. 7. In cygwin command shell window, execute following two commands, making sure to give email as password when prompted for login: cvs -d :pserver:anonymous at modula3.elegosoft.com:/usr/cvs login cvs -d :pserver:anonymous at modula3.elegosoft.com:/usr/cvs checkout cm3 8. Moved resulting C:\cygwin\home\rcoleburn\cm3 to C:\CM3_CVS_SourceTree Note that you should replace "rcoleburn" above with your Windows login username. 9. Download cm3-min-WIN32-NT386-d5.5.0.zip and cm3-min-WIN32-NT386-d5.5.0-symbols.zip from http://modula3.elegosoft.com/cm3/download.html 10. Unzipped cm3-min-WIN32-NT386-d5.5.0.zip and stored resulting cm3 folder at C:\cm3 11. Unzipped cm3-min-WIN32-NT386-d5.5.0-symbols.zip and stored resulting symbols folder at C:\cm3\symbols 12. Launch Windows Command Prompt shell. The following steps represent commands executed within this shell. 13. path %path%;c:\cm3\bin 14. "C:\Program Files\Microsoft Visual Studio 9.0\VC\vcvarsall.bat" 15. cd C:\CM3_CVS_SourceTree\scripts\win 16. upgrade.cmd ERROR I'M GETTING: ============= === package C:\CM3_CVS_SourceTree\m3-sys\cm3 ===+++ "cm3 -build -DROOT=C:\\CM3_CVS_SourceTree -DCM3_VERSION_TEXT=d5.5.1 -DCM3_VERSION_NUMBER=050501 -DCM3_LAST_CHANGED=2007-12-30 && cm3 -ship -DROOT=C:\\CM3_CVS_SourceTree -DCM3_VERSION_TEXT=d5.5.1 -DCM3_VERSION_NUMBER=050501 -DCM3_LAST_CHANGED=2007-12-30" +++--- building in NT386 --- ignoring ..\src\m3overrides "C:\CM3_CVS_SourceTree\m3-sys\cm3\src\version.quake", line 136: quake runtime error: unable to open "C:\CM3_CVS_SourceTree\m3-sys\cm3\src\../NT386.datenow" forreading --procedure-- -line- -file---include -- version_impl 136 C:\CM3_CVS_SourceTree\m3-sys\cm3\src\version.quakeinclude_dir 20 C:\CM3_CVS_SourceTree\m3-sys\cm3\src\m3makefile 8 C:\CM3_CVS_SourceTree\m3-sys\cm3\NT386\m3make.args Fatal Error: package build failedERROR: "cm3 -build -DROOT=C:\\CM3_CVS_SourceTree -DCM3_VERSION_TEXT=d5.5.1 -DCM3_VERSION_NUMBER=050501 -DCM3_LAST_CHANGED=2007-12-30 && cm3 -ship -DROOT=C:\\CM3_CVS_SourceTree -DCM3_VERSION_TEXT=d5.5.1 -DCM3_VERSION_NUMBER=050501 -DCM3_LAST_CHANGED=2007-12-30"ERROR: cd C:\CM3_CVS_SourceTree\m3-sys\cm3ERROR: set INSTALLROOT=c:\cm3 Regards, Randy Share life as it happens with the new Windows Live. Start sharing! Put your friends on the big screen with Windows Vista? + Windows LiveT. Start now! _________________________________________________________________ Get the power of Windows + Web with the new Windows Live. http://www.windowslive.com?ocid=TXT_TAGHM_Wave2_powerofwindows_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Wed Jan 16 16:29:32 2008 From: jayk123 at hotmail.com (Jay) Date: Wed, 16 Jan 2008 15:29:32 +0000 Subject: [M3devel] my status on win32 In-Reply-To: <478DBF8D.1E75.00D7.1@scires.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> <477EA137.1E75.00D7.1@scires.com> <478D394B.1E75.00D7.1@scires.com> <478D47FB.1E75.00D7.1@scires.com> <478DBF8D.1E75.00D7.1@scires.com> Message-ID: Yes I agree it is "broken #1" and shouldn't be this way, but I assure you, really, your results are 99% there. What isn't working is minor and easy to fix and much is working. - Jay Date: Wed, 16 Jan 2008 08:25:49 -0500From: rcoleburn at scires.comTo: m3devel at elegosoft.com; jayk123 at hotmail.comSubject: Re: [M3devel] my status on win32 Jay: There is no line in the m3makefile dealing with datefn, so I added the whole statement just before the line include("version.quake") Now, I get an error saying that the variable datefn is not defined. If you change to put quotes around datefn in the include statement, you get an error saying it can't open the file. You made a reference in one of your earlier posts about trying 5.1.6 or 4.1, but note that I started with your cm3-min-WIN32-NT386-d5.5.0.zip , not the 5.1.6 or 4.1 versions. Thus, using d5.5.0 as a base, I am trying to run your "upgrade.cmd" to rebuild the sources I checked out from CVS. Since this doesn't work "out-of-the-box", again I say this fits into the "Broken #1" category. If I can get this to work, I don't mind putting together a Windows installer program that will install the whole thing. That way, folks won't have to install cygwin just to get CVS so that they can install a working cm3. Folks will need to install the free Microsoft Visual C as a prerequisite, but then that's not too bad. Having an installer program would make cm3 more friendly to Windows folks. The current 16-step method is too laborious and error-prone for the person just getting started and they will not give cm3 a second try. As the cm3 system evolves and new releases are made, we will need to keep the installer program up-to-date and I don't mind doing that. After someone gets familiar with cm3 they might want to delve into some of the scripts for rebuilding the system, but until then, I think the installer program is the way to go. Regards, Randy>>> Jay 1/16/2008 1:01 AM >>>I think I see the problem. in cm3\src\m3makefile, make this change > if not defined("NOW") include(datefn) > end datefn is only created if certain other variables aren't defined, and do-pkg defines them.I don't know why I don't see this. Later.Could be that the Python scripts have a typo and don't define them.I've been using them more than cmd. If the host is NT, "NOW" is either gotten from an updated cm3.exe, or left to "not available". So the initial cm3 built from older cm3 can't report when it was built, but cm3 built from current cm3 can. I need to change that: 1) to be a function for niceness 2) to make it that way for Posix, for any host but I haven't been using Posix as much lately so not testing it. - Jay Date: Tue, 15 Jan 2008 23:55:39 -0500From: rcoleburn at scires.comTo: m3devel at elegosoft.com; jayk123 at hotmail.comSubject: RE: my status on win32 Jay: In the file version.quake, I made the following edit: changed line: local datefn = "../" & TARGET & ".datenow" to: local datefn = ".." & SL & TARGET & ".datenow" This change has the effect of putting a backward slash in the pathname instead of a forward slash, so we getC:\CM3_CVS_SourceTree\m3-sys\cm3\src\..\NT386.datenow So from that perspective, the change seems good. Unfortunately, I still get the error that this file can't be opened. A quick check of C:\CM3_CVS_SourceTree\m3-sys\cm3\NT386 shows that the file .datenow does not exist. Regards, Randy>>> Jay 1/15/2008 11:03 PM >>>That's not too bad really. 1) I'd recommend putting cm3 at the start of the path instead of the end. 2) Just comment out the offending code to make progress. It's not critical. >> C:\CM3_CVS_SourceTree\m3-sys\cm3\src\../NT386.datenow The code is: C:\CM3_CVS_SourceTree\m3-sys\cm3\src\version.quake or such, included by cm3\src\m3makefile. Does the file exist?Does version.quake use "/" or "SL"? If it uses "/", try replacing with SL (and ampersand for string concat). Could be that a newer binary distributions works better with forward slashes. > 4. > 5. > 6. Launch cygwin from desktop icon. Cygwin is only needed for cvs, I think you realize. Could you send me offline the result of just running "set" after running vcvarsall? I'd like to adapt pylib.py to it maybe. (I can start from 5.1.6 and will try 4.1 at some point.) - Jay Date: Tue, 15 Jan 2008 22:52:59 -0500From: rcoleburn at scires.comTo: m3devel at elegosoft.com; jayk123 at hotmail.comSubject: my status on win32 Jay et al: I've listed below the steps I've undertaken to try and build the current sources on Windows XP. I've also attached a text file showing the output I got when trying to build everything using Jay's upgrade.cmd script. Unfortunately, I'm getting a build error (see below). Please advise on how to resolve. STEPS I TOOK: ========= 1. Download Microsoft Visual Studio 2008 Express Edition All-in-One .ISO file and burn to DVD. http://www.microsoft.com/express/download/ 2. Install Microsoft Visual C++ 2008 Express Edition from DVD. 3. Use "Microsoft Update" service to check for updates / service packs. 4. Download cygwin setup program from http://cygwin.com/ 5. Ran cygwin setup.exe program to install cygwin for all users. Under "Devel" category, make certain to select "cvs" for installation. 6. Launch cygwin from desktop icon. 7. In cygwin command shell window, execute following two commands, making sure to give email as password when prompted for login: cvs -d :pserver:anonymous at modula3.elegosoft.com:/usr/cvs login cvs -d :pserver:anonymous at modula3.elegosoft.com:/usr/cvs checkout cm3 8. Moved resulting C:\cygwin\home\rcoleburn\cm3 to C:\CM3_CVS_SourceTree Note that you should replace "rcoleburn" above with your Windows login username. 9. Download cm3-min-WIN32-NT386-d5.5.0.zip and cm3-min-WIN32-NT386-d5.5.0-symbols.zip from http://modula3.elegosoft.com/cm3/download.html 10. Unzipped cm3-min-WIN32-NT386-d5.5.0.zip and stored resulting cm3 folder at C:\cm3 11. Unzipped cm3-min-WIN32-NT386-d5.5.0-symbols.zip and stored resulting symbols folder at C:\cm3\symbols 12. Launch Windows Command Prompt shell. The following steps represent commands executed within this shell. 13. path %path%;c:\cm3\bin 14. "C:\Program Files\Microsoft Visual Studio 9.0\VC\vcvarsall.bat" 15. cd C:\CM3_CVS_SourceTree\scripts\win 16. upgrade.cmd ERROR I'M GETTING: ============= === package C:\CM3_CVS_SourceTree\m3-sys\cm3 ===+++ "cm3 -build -DROOT=C:\\CM3_CVS_SourceTree -DCM3_VERSION_TEXT=d5.5.1 -DCM3_VERSION_NUMBER=050501 -DCM3_LAST_CHANGED=2007-12-30 && cm3 -ship -DROOT=C:\\CM3_CVS_SourceTree -DCM3_VERSION_TEXT=d5.5.1 -DCM3_VERSION_NUMBER=050501 -DCM3_LAST_CHANGED=2007-12-30" +++--- building in NT386 --- ignoring ..\src\m3overrides "C:\CM3_CVS_SourceTree\m3-sys\cm3\src\version.quake", line 136: quake runtime error: unable to open "C:\CM3_CVS_SourceTree\m3-sys\cm3\src\../NT386.datenow" forreading --procedure-- -line- -file---include -- version_impl 136 C:\CM3_CVS_SourceTree\m3-sys\cm3\src\version.quakeinclude_dir 20 C:\CM3_CVS_SourceTree\m3-sys\cm3\src\m3makefile 8 C:\CM3_CVS_SourceTree\m3-sys\cm3\NT386\m3make.args Fatal Error: package build failedERROR: "cm3 -build -DROOT=C:\\CM3_CVS_SourceTree -DCM3_VERSION_TEXT=d5.5.1 -DCM3_VERSION_NUMBER=050501 -DCM3_LAST_CHANGED=2007-12-30 && cm3 -ship -DROOT=C:\\CM3_CVS_SourceTree -DCM3_VERSION_TEXT=d5.5.1 -DCM3_VERSION_NUMBER=050501 -DCM3_LAST_CHANGED=2007-12-30"ERROR: cd C:\CM3_CVS_SourceTree\m3-sys\cm3ERROR: set INSTALLROOT=c:\cm3 Regards, Randy Share life as it happens with the new Windows Live. Start sharing! Put your friends on the big screen with Windows Vista? + Windows LiveT. Start now! _________________________________________________________________ Watch ?Cause Effect,? a show about real people making a real difference. http://im.live.com/Messenger/IM/MTV/?source=text_watchcause -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcoleburn at scires.com Wed Jan 16 17:24:34 2008 From: rcoleburn at scires.com (Randy Coleburn) Date: Wed, 16 Jan 2008 11:24:34 -0500 Subject: [M3devel] my status on win32 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> <477EA137.1E75.00D7.1@scires.com> <478D394B.1E75.00D7.1@scires.com> <478D47FB.1E75.00D7.1@scires.com> <478DBF8D.1E75.00D7.1@scires.com> Message-ID: <478DE973.1E75.00D7.1@scires.com> Jay: Not sure I've clued in to all of your dialog. Sorry. I have in the past used a free tool to build an installer package and I was thinking of using it again. Since the tool is free, we could put all the work I do into the CVS repository so that others could also maintain it. What I am looking to achieve is to have a way where a "normal" Windows user could download a program, run it, and have all of the cm3 packages installed without having to use the MIN distribution to build it up or any other tools to get the sources (like cvs). You could achieve the same thing by having a big ZIP file also I suppose, but having the installer would also let us easily put something in the start menu to launch a command line with all the environment variables set properly via automatic call to vcvars et al. When I get "Reactor" working, it too could be put into the start menu. That just makes it fit in better with the Windows user culture I think. The reason I wanted to rebuild everything is two-fold: 1) ensure it can be done (i.e., test for "Broken #1"), and 2) get all of the rest of the packages built so I could then use cm3 to build "reactor" and my own programs and test them to see if there are any "Broken #2" issues. The MIN distribution is really insufficient to do much of anything except to build the rest of the packages you need. My understanding is that I needed to use CVS to get the current sources, because if I went back to the source archive, it was old and known to be Broken #1 on Windows. I'm glad that you believe the current "Broken #1" situation is easy to fix. Let me know what to do and I'll give it another try. My experience in the past has been that there are 3 conditions to getting cm3 to work properly on windows after it has been installed: 1) make sure your environment variables are set up by vcvars to point to the compiler/linker/libraries (of course if you used a non-Microsoft C compiler/linker you would need to use something other than vcvars); 2) make sure cm3.cfg has the right paths in place to find all the libraries and tools using DOS style short names (no embedded spaces); and 3) make sure C:\cm3\bin is in your path. Of these, #2 & #3 are essentially one-time events, and #1 can be set up by a invoking a batch/command file via a shortcut, so no big deal for me. You could even make #1 a one-time event by modifying the system-level (vice user-level) environment variables. The old cm3install program seemed to do a decent job of #2 for me. Also, I've noted some of your past dialog about accepting either '/' or '\' as a path separator. I'm sure you are aware that on Windows '/' is used often for switches (arguments). Plus Windows also allows spaces to be embedded in the command line, so whatever solution you propose needs to take into account that a valid command line might look like this: C:\My Program Folder\My Program.exe /myArg1 /myArg2 In some situations, this command line would have to be quoted and rendered as: "C:\My Program Folder\My Program.exe" /myArg1 /myArg2 and in places where the backslash is an escape character, I've seen "C:\\My Program Folder\\My Program.exe" /myArg1 /myArg2 Alas, I seem to have rambled a bit also. Sorry. The immediate need for me now is to solve the Broken #1 condition, so please let me know how to fix it and proceed. Regards, Randy >>> Jay 1/16/2008 10:28 AM >>> Randy, yes and no and clarifications. I mention starting with 5.1.6 as a "worst" or "worse" case. The earlier you start, the harder things are -- for me, to ensure it will work. If you merely start with my 5.5.0, well, what are you rebuilding from source for? Heck, you can use any binary distribution, 4.1, 5.1.6, and just use it. They should work. The n steps you/I give are really actually geared for people who WANT to build from source, it is not what people HAVE to do. As well there have been can be source distributions, to cut out CVS. I'll look into the datefn stuff shortly. As to the installer, well, again, yes and no. The need for the installer is very small. All you have to do today is unzip the .zip somewhere and set the path, and possibly the vcvars thing. That's it. I should..now that you are "pressuring" me for ease of use, teach cm3 about the various %devenvdir%, %vcinstalldir% variables, etc. That way as long as the user installed the tools, even if they elected not to change path/lib/include, cm3 can find the compiler and linker. I know everyone wants to preserve the flexibility of quake/cm3.cfg but...besides, cm3 can be pretty darn smart here. IF cm3.cfg defines SYSTEM_CC, leave things along (NT386 cm3.cfg does not today do that). However if there is now SYSTEM_CC and there is no cl.exe/link.exe in %PATH%, it could go on a quick hunt for them. On the lib and include part, well, the dependency on %include% might only be for errno..maybe not worth it. It has been whatever it is forever, like int* _errno(void); #define errno (*_errno)()). Modula-3 engages in rampant header cloning and CErrnoC was only introduced where that was deemed more fragile than usual, and for Windows it probably wasn't actually fragile -- the fragility, if I may be so rudely judgemental, is because so many other systems are so Johnny-come-lately to arriving at the obviously correct threading model that Windows has had all along (since Win95/NT, can't say anything good about Win3.1; I think OS/2 might have had it correct all along too.). Funny, everyone has FINALLY arrived at the correct threading model, only to have start changing again, since the number of cores and machines is set to be much greater than anticipated, the obvious threading model has been deemed too difficult for anyone to use (Win32, Modula-3, Java, .NET, Python, all the same supposedly too difficult model btw), and so some new one is needed, and well, truthfully, the difficulty is not just for dummies on relatively small multiproc boxes not having simple race conditions, the problem is scaling way way up. Sorry that was my usual tangential. Even the unzip and set path would benefit slightly from a GUI installer. I believe there is some easy thing you can do where you write your GUI installer and you put it in the .zip and then you prepend the GUI self extracting .zip/.exe stub, and you can tell it to run a particular command after the extraction. I guess you might use a fancier thing though? That is, are you going to, say, write a gui installer from scratch in Modula-3? It might be a fun exercise. :) And then you could build the self extracting prefix from source etc. This is the hard way I guess, but more interesing. If you can build an msi or use InstallShield or Wix or something, go ahead. If you use widely availabe free as in beer tools, that can be rolled into whatever automation there is to produce distributions, keeping it up to date shouldn't be a problem. I do have to bring up some annoying questions: 1) Does anyone besides me have the capacity to produce distributions? i.e.: Any Win32 machines left at Elego? 2) I know I ramble. So one of my many tangents/questions went unanswered. Say, in the absence of a gui installer, should .zips/.tar.bz files look like cm3-min-/bin/cm3 or bin/cm3 or cm3/bin/cm3 The last one is more directly usable. The first one is very common. This reminds me though Randy, the distribution I made available was "min", so yeah, like if you are doing any gui programming, using any "standard" library besides m3core or libm3, you'd need to build more from source. I can readily provide you a "std" distribution though. It's "always" been a "problem" to make my files available -- no web site hosting for me -- but recently that wasn't a problem, someone picked the files out of ~jkrell on birch and put them on the web site. Good. One more thing -- Olaf, please confirm repeat yourself, 'cause I admit I wasn't sure it was the right thing, but if you insist, ok. "std" should be "all"? I should not continue to imagine there is a new larger group called "all"? And wherever things are missing from std but do build ok, add them? m3cc should be in std? (I admit some big indecisiveness around m3cc. It is far and away the longest thing to build and so the one you really want to skip the most and leave out of whatever package group. I also wonder if on Windows, there should be some check where if sh is not in the $PATH, just silently skip m3cc? You only need MingWin to build what I have on my system for NT386GNU, except you also need msys just for m3cc. msys is actually quite small, like only 20 files..) Oh, sorry, yet another question. The non-gcc backend is excluded from the build on systems that use the gcc backend. For minimization, that is appropriate. For maximizing cross build capability, it is wrong. The packages build fine. I suspect they work. I am not a user of cross build capability yet, so I don't really care. (What I do for NT386/NT386GNU /might/ be considered sort of a cross build, but it is different/easier). They are small packages. - Jay Date: Wed, 16 Jan 2008 08:25:49 -0500 From: rcoleburn at scires.com To: m3devel at elegosoft.com; jayk123 at hotmail.com Subject: Re: [M3devel] my status on win32 Jay: There is no line in the m3makefile dealing with datefn, so I added the whole statement just before the line include("version.quake") Now, I get an error saying that the variable datefn is not defined. If you change to put quotes around datefn in the include statement, you get an error saying it can't open the file. You made a reference in one of your earlier posts about trying 5.1.6 or 4.1, but note that I started with your cm3-min-WIN32-NT386-d5.5.0.zip , not the 5.1.6 or 4.1 versions. Thus, using d5.5.0 as a base, I am trying to run your "upgrade.cmd" to rebuild the sources I checked out from CVS. Since this doesn't work "out-of-the-box", again I say this fits into the "Broken #1" category. If I can get this to work, I don't mind putting together a Windows installer program that will install the whole thing. That way, folks won't have to install cygwin just to get CVS so that they can install a working cm3. Folks will need to install the free Microsoft Visual C as a prerequisite, but then that's not too bad. Having an installer program would make cm3 more friendly to Windows folks. The current 16-step method is too laborious and error-prone for the person just getting started and they will not give cm3 a second try. As the cm3 system evolves and new releases are made, we will need to keep the installer program up-to-date and I don't mind doing that. After someone gets familiar with cm3 they might want to delve into some of the scripts for rebuilding the system, but until then, I think the installer program is the way to go. Regards, Randy >>> Jay 1/16/2008 1:01 AM >>> I think I see the problem. in cm3\src\m3makefile, make this change > if not defined("NOW") include(datefn) > end datefn is only created if certain other variables aren't defined, and do-pkg defines them. I don't know why I don't see this. Later. Could be that the Python scripts have a typo and don't define them. I've been using them more than cmd. If the host is NT, "NOW" is either gotten from an updated cm3.exe, or left to "not available". So the initial cm3 built from older cm3 can't report when it was built, but cm3 built from current cm3 can. I need to change that: 1) to be a function for niceness 2) to make it that way for Posix, for any host but I haven't been using Posix as much lately so not testing it. - Jay Date: Tue, 15 Jan 2008 23:55:39 -0500 From: rcoleburn at scires.com To: m3devel at elegosoft.com; jayk123 at hotmail.com Subject: RE: my status on win32 Jay: In the file version.quake, I made the following edit: changed line: local datefn = "../" & TARGET & ".datenow" to: local datefn = ".." & SL & TARGET & ".datenow" This change has the effect of putting a backward slash in the pathname instead of a forward slash, so we get C:\CM3_CVS_SourceTree\m3-sys\cm3\src\..\NT386.datenow So from that perspective, the change seems good. Unfortunately, I still get the error that this file can't be opened. A quick check of C:\CM3_CVS_SourceTree\m3-sys\cm3\NT386 shows that the file .datenow does not exist. Regards, Randy >>> Jay 1/15/2008 11:03 PM >>> That's not too bad really. 1) I'd recommend putting cm3 at the start of the path instead of the end. 2) Just comment out the offending code to make progress. It's not critical. >> C:\CM3_CVS_SourceTree\m3-sys\cm3\src\../NT386.datenow The code is: C:\CM3_CVS_SourceTree\m3-sys\cm3\src\version.quake or such, included by cm3\src\m3makefile. Does the file exist? Does version.quake use "/" or "SL"? If it uses "/", try replacing with SL (and ampersand for string concat). Could be that a newer binary distributions works better with forward slashes. > 4. > 5. > 6. Launch cygwin from desktop icon. Cygwin is only needed for cvs, I think you realize. Could you send me offline the result of just running "set" after running vcvarsall? I'd like to adapt pylib.py to it maybe. (I can start from 5.1.6 and will try 4.1 at some point.) - Jay Date: Tue, 15 Jan 2008 22:52:59 -0500 From: rcoleburn at scires.com To: m3devel at elegosoft.com; jayk123 at hotmail.com Subject: my status on win32 Jay et al: I've listed below the steps I've undertaken to try and build the current sources on Windows XP. I've also attached a text file showing the output I got when trying to build everything using Jay's upgrade.cmd script. Unfortunately, I'm getting a build error (see below). Please advise on how to resolve. STEPS I TOOK: ========= 1. Download Microsoft Visual Studio 2008 Express Edition All-in-One .ISO file and burn to DVD. http://www.microsoft.com/express/download/ 2. Install Microsoft Visual C++ 2008 Express Edition from DVD. 3. Use "Microsoft Update" service to check for updates / service packs. 4. Download cygwin setup program from http://cygwin.com/ 5. Ran cygwin setup.exe program to install cygwin for all users. Under "Devel" category, make certain to select "cvs" for installation. 6. Launch cygwin from desktop icon. 7. In cygwin command shell window, execute following two commands, making sure to give email as password when prompted for login: cvs -d :pserver:anonymous at modula3.elegosoft.com:/usr/cvs login cvs -d :pserver:anonymous at modula3.elegosoft.com:/usr/cvs checkout cm3 8. Moved resulting C:\cygwin\home\rcoleburn\cm3 to C:\CM3_CVS_SourceTree Note that you should replace "rcoleburn" above with your Windows login username. 9. Download cm3-min-WIN32-NT386-d5.5.0.zip and cm3-min-WIN32-NT386-d5.5.0-symbols.zip from http://modula3.elegosoft.com/cm3/download.html 10. Unzipped cm3-min-WIN32-NT386-d5.5.0.zip and stored resulting cm3 folder at C:\cm3 11. Unzipped cm3-min-WIN32-NT386-d5.5.0-symbols.zip and stored resulting symbols folder at C:\cm3\symbols 12. Launch Windows Command Prompt shell. The following steps represent commands executed within this shell. 13. path %path%;c:\cm3\bin 14. "C:\Program Files\Microsoft Visual Studio 9.0\VC\vcvarsall.bat" 15. cd C:\CM3_CVS_SourceTree\scripts\win 16. upgrade.cmd ERROR I'M GETTING: ============= === package C:\CM3_CVS_SourceTree\m3-sys\cm3 === +++ "cm3 -build -DROOT=C:\\CM3_CVS_SourceTree -DCM3_VERSION_TEXT=d5.5.1 -DCM3_V ERSION_NUMBER=050501 -DCM3_LAST_CHANGED=2007-12-30 && cm3 -ship -DROOT=C:\\CM3_C VS_SourceTree -DCM3_VERSION_TEXT=d5.5.1 -DCM3_VERSION_NUMBER=050501 -DCM3_LAST_C HANGED=2007-12-30" +++ --- building in NT386 --- ignoring ..\src\m3overrides "C:\CM3_CVS_SourceTree\m3-sys\cm3\src\version.quake", line 136: quake runtime er ror: unable to open "C:\CM3_CVS_SourceTree\m3-sys\cm3\src\../NT386.datenow" for reading --procedure-- -line- -file--- include -- version_impl 136 C:\CM3_CVS_SourceTree\m3-sys\cm3\src\version.quake include_dir 20 C:\CM3_CVS_SourceTree\m3-sys\cm3\src\m3makefile 8 C:\CM3_CVS_SourceTree\m3-sys\cm3\NT386\m3make.args Fatal Error: package build failed ERROR: "cm3 -build -DROOT=C:\\CM3_CVS_SourceTree -DCM3_VERSION_TEXT=d5.5.1 -DCM 3_VERSION_NUMBER=050501 -DCM3_LAST_CHANGED=2007-12-30 && cm3 -ship -DROOT=C:\\CM 3_CVS_SourceTree -DCM3_VERSION_TEXT=d5.5.1 -DCM3_VERSION_NUMBER=050501 -DCM3_LAS T_CHANGED=2007-12-30" ERROR: cd C:\CM3_CVS_SourceTree\m3-sys\cm3 ERROR: set INSTALLROOT=c:\cm3 Regards, Randy Share life as it happens with the new Windows Live. Start sharing! ( http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_012008 ) Put your friends on the big screen with Windows Vista* + Windows LiveT. Start now! ( http://www.microsoft.com/windows/shop/specialoffers.mspx?ocid=TXT_TAGLM_CPC_MediaCtr_bigscreen_012008 ) Get the power of Windows + Web with the new Windows Live. Get it now! ( http://www.windowslive.com/?ocid=TXT_TAGHM_Wave2_powerofwindows_012008 ) -------------- next part -------------- An HTML attachment was scrubbed... URL: From darko at darko.org Wed Jan 16 19:28:48 2008 From: darko at darko.org (Darko) Date: Wed, 16 Jan 2008 10:28:48 -0800 Subject: [M3devel] GC question version 2 Message-ID: Ok, a slightly different approach: Can the GC give me a list of all the objects that contain a reference to an object? Would it be thorough (ie not miss any objects)? False positives might be ok. Then I could check the type of each object and update the references myself. It would be reasonable to assume that the references in question were not being changed by any thread during the checking process. Thanks, Darko. From jayk123 at hotmail.com Wed Jan 16 20:13:21 2008 From: jayk123 at hotmail.com (Jay) Date: Wed, 16 Jan 2008 19:13:21 +0000 Subject: [M3devel] my status on win32 In-Reply-To: <478DE973.1E75.00D7.1@scires.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> <477EA137.1E75.00D7.1@scires.com> <478D394B.1E75.00D7.1@scires.com> <478D47FB.1E75.00D7.1@scires.com> <478DBF8D.1E75.00D7.1@scires.com> <478DE973.1E75.00D7.1@scires.com> Message-ID: Hi Randy. I mostly agree and understand. Go ahead with your installer work. :) #2 is no longer needed. The cm3.cfg I use, that is checked in, that is in the newer distributions, just runs plain "cl" and links to plain "kernel32.dll", and doesn't pass any /I switches to cl => therefore it depends on %PATH%, %LIB%, and %INCLUDE%. As I was saying/rambling, we/I can probably teach cm3 a bit so as to not need vcvars. As I recall, but I need to check, when you install VC, there are some variables it sets unconditionally, and some it asks the user if they should be set. The ones it asks about are PATH, LIB, INCLUDE. The ones it sets unconditionally are the "root" of the install. PATH / LIB / INCLUDE are more invasive, more impactful, have more potential to break things. They are also easily derived from the "root". Similarly, the CM3 installer could ask the user if it is ok to modify their %PATH%, and do it in the registry and set the WM_INI_CHANGED or such message so that Explorer picks it up. Need to check MSDN on this. Forward slashes are fine for options. I take a dim view of these space, quoting, escaping issues. I have very mixed experience here. In SOME situations, your command lines pass through various layers of code, with various attempts to handle or ignore the various issues. The result is in my opinion an unpredictable mess. The problem is that people have confused "an array of strings" with "one flat string". At this point the confusion is widespread and deeply ingrained. On Unix I believe people just ignore the issue by not using spaces (or quotes?) on the command line, though escaping issues still remain for other characters. You just have to read the documenation on CreateProcess to realize how messed up this is. c:\program files\foo I believe is interpreted multiple ways until something works. It can be running c:\program with the parameter files\foo, or it can be running c:\program files\foo. Reliable interprocess communication should not be via command lines but via something more strongly typed such as RPC or shared memory or reading/writing a Pickle. I use the command line a lot, and I frequently copy paths from the command line and paste them into the file open dialog, which does not accept forward slashes nor nested double slashes. It should but oh well. Therefore I have goal before much longer to ensure that every path generated and probably reported by cm3 is in the "normal" form. If the user types in a forward slash, perhaps that should be reported back though. And forward slashes should be ok to enter and then get used internally. The need to configure short file names are gone, along with the need to quote them, by virtue of the dependency on environment variables. Paths with spaces can still come in other ways, but not via SYSTEM_CC in a "normal" cm3, for my newfangled revisionist version of "normal". :) Short names really stink, in so many ways. First, they aren't necessary even shorter, they are just of a limited character set. They can be up to twice as long as "long". Try this: mkdir \1.1.1. dir /x 1* Also, wildcard matching "always" (in FindFirstFile/FindNextFile) operates against both long and short, and since short are unpredcitable, wildcard matching therefore is. An example, probably, is: echo > foo.bar echo > food.barf dir *.bar Will probably, but not necessarily, match both files, though you would only expect one match. As well, I don't believe short file names have always been backed up and restored -- for anyone that uses any backup softwre (not me!). So you determine your short name, you backup and restore, and it changes. Or more clearly, recreating files, might get a different name. It's a mess. I would discourage you from persisting short names ever. Names with spaces I discourage but not as strong. For example, in some contexts, there is just one name and there is no ambiguity. Actually in %PATH% there is no ambiguity because the sepArator is the semicolon.I think Win9x different though, sigh. I agree from my "min" distribution, you need to build the rest. I have to admit, I thought the "culture" on this list was to want to and actually build the system from source. I will put a "std" distribution up on birch this week hopefully and hopefully someone will put it on the web page. Maintaining the installer should not be a problem. As long as the licensing and cost and all is right. I have not fixed the build yet, sorry. - Jay Date: Wed, 16 Jan 2008 11:24:34 -0500From: rcoleburn at scires.comTo: m3devel at elegosoft.com; jayk123 at hotmail.comSubject: Re: [M3devel] my status on win32 Jay: Not sure I've clued in to all of your dialog. Sorry. I have in the past used a free tool to build an installer package and I was thinking of using it again. Since the tool is free, we could put all the work I do into the CVS repository so that others could also maintain it. What I am looking to achieve is to have a way where a "normal" Windows user could download a program, run it, and have all of the cm3 packages installed without having to use the MIN distribution to build it up or any other tools to get the sources (like cvs). You could achieve the same thing by having a big ZIP file also I suppose, but having the installer would also let us easily put something in the start menu to launch a command line with all the environment variables set properly via automatic call to vcvars et al. When I get "Reactor" working, it too could be put into the start menu. That just makes it fit in better with the Windows user culture I think. The reason I wanted to rebuild everything is two-fold: 1) ensure it can be done (i.e., test for "Broken #1"), and 2) get all of the rest of the packages built so I could then use cm3 to build "reactor" and my own programs and test them to see if there are any "Broken #2" issues. The MIN distribution is really insufficient to do much of anything except to build the rest of the packages you need. My understanding is that I needed to use CVS to get the current sources, because if I went back to the source archive, it was old and known to be Broken #1 on Windows. I'm glad that you believe the current "Broken #1" situation is easy to fix. Let me know what to do and I'll give it another try. My experience in the past has been that there are 3 conditions to getting cm3 to work properly on windows after it has been installed: 1) make sure your environment variables are set up by vcvars to point to the compiler/linker/libraries (of course if you used a non-Microsoft C compiler/linker you would need to use something other than vcvars); 2) make sure cm3.cfg has the right paths in place to find all the libraries and tools using DOS style short names (no embedded spaces); and 3) make sure C:\cm3\bin is in your path. Of these, #2 & #3 are essentially one-time events, and #1 can be set up by a invoking a batch/command file via a shortcut, so no big deal for me. You could even make #1 a one-time event by modifying the system-level (vice user-level) environment variables. The old cm3install program seemed to do a decent job of #2 for me. Also, I've noted some of your past dialog about accepting either '/' or '\' as a path separator. I'm sure you are aware that on Windows '/' is used often for switches (arguments). Plus Windows also allows spaces to be embedded in the command line, so whatever solution you propose needs to take into account that a valid command line might look like this: C:\My Program Folder\My Program.exe /myArg1 /myArg2 In some situations, this command line would have to be quoted and rendered as: "C:\My Program Folder\My Program.exe" /myArg1 /myArg2 and in places where the backslash is an escape character, I've seen "C:\\My Program Folder\\My Program.exe" /myArg1 /myArg2 Alas, I seem to have rambled a bit also. Sorry. The immediate need for me now is to solve the Broken #1 condition, so please let me know how to fix it and proceed. Regards, Randy>>> Jay 1/16/2008 10:28 AM >>>Randy, yes and no and clarifications. I mention starting with 5.1.6 as a "worst" or "worse" case.The earlier you start, the harder things are -- for me, to ensure it will work. If you merely start with my 5.5.0, well, what are you rebuilding from source for?Heck, you can use any binary distribution, 4.1, 5.1.6, and just use it. They should work. The n steps you/I give are really actually geared for people who WANT to build from source, it is not what people HAVE to do.As well there have been can be source distributions, to cut out CVS. I'll look into the datefn stuff shortly. As to the installer, well, again, yes and no.The need for the installer is very small. All you have to do today is unzip the .zip somewhere and set the path, and possibly the vcvars thing. That's it. I should..now that you are "pressuring" me for ease of use, teach cm3 about the various ?venvdir%, %vcinstalldir% variables, etc. That way as long as the user installed the tools, even if they elected not to change path/lib/include, cm3 can find the compiler and linker. I know everyone wants to preserve the flexibility of quake/cm3.cfg but...besides, cm3 can be pretty darn smart here. IF cm3.cfg defines SYSTEM_CC, leave things along (NT386 cm3.cfg does not today do that). However if there is now SYSTEM_CC and there is no cl.exe/link.exe in %PATH%, it could go on a quick hunt for them. On the lib and include part, well, the dependency on %include% might only be for errno..maybe not worth it. It has been whatever it is forever, like int* _errno(void); #define errno (*_errno)()). Modula-3 engages in rampant header cloning and CErrnoC was only introduced where that was deemed more fragile than usual, and for Windows it probably wasn't actually fragile -- the fragility, if I may be so rudely judgemental, is because so many other systems are so Johnny-come-lately to arriving at the obviously correct threading model that Windows has had all along (since Win95/NT, can't say anything good about Win3.1; I think OS/2 might have had it correct all along too.). Funny, everyone has FINALLY arrived at the correct threading model, only to have start changing again, since the number of cores and machines is set to be much greater than anticipated, the obvious threading model has been deemed too difficult for anyone to use (Win32, Modula-3, Java, .NET, Python, all the same supposedly too difficult model btw), and so some new one is needed, and well, truthfully, the difficulty is not just for dummies on relatively small multiproc boxes not having simple race conditions, the problem is scaling way way up. Sorry that was my usual tangential. Even the unzip and set path would benefit slightly from a GUI installer.I believe there is some easy thing you can do where you write your GUI installer and you put it in the .zip and then you prepend the GUI self extracting .zip/.exe stub, and you can tell it to run a particular command after the extraction. I guess you might use a fancier thing though?That is, are you going to, say, write a gui installer from scratch in Modula-3? It might be a fun exercise. :)And then you could build the self extracting prefix from source etc.This is the hard way I guess, but more interesing.If you can build an msi or use InstallShield or Wix or something, go ahead.If you use widely availabe free as in beer tools, that can be rolled into whatever automation there is to produce distributions, keeping it up to date shouldn't be a problem. I do have to bring up some annoying questions: 1) Does anyone besides me have the capacity to produce distributions? i.e.: Any Win32 machines left at Elego? 2) I know I ramble. So one of my many tangents/questions went unanswered.Say, in the absence of a gui installer, should .zips/.tar.bz files look like cm3-min-/bin/cm3orbin/cm3orcm3/bin/cm3 The last one is more directly usable. The first one is very common. This reminds me though Randy, the distribution I made available was "min", so yeah, like if you are doing any gui programming, using any "standard" library besides m3core or libm3, you'd need to build more from source. I can readily provide you a "std" distribution though.It's "always" been a "problem" to make my files available -- no web site hosting for me -- but recently that wasn't a problem, someone picked the files out of ~jkrell on birch and put them on the web site. Good. One more thing -- Olaf, please confirm repeat yourself, 'cause I admit I wasn't sure it was the right thing, but if you insist, ok. "std" should be "all"? I should not continue to imagine there is a new larger group called "all"? And wherever things are missing from std but do build ok, add them?m3cc should be in std?(I admit some big indecisiveness around m3cc. It is far and away the longest thing to build and so the one you really want to skip the most and leave out of whatever package group. I also wonder if on Windows, there should be some check where if sh is not in the $PATH, just silently skip m3cc? You only need MingWin to build what I have on my system for NT386GNU, except you also need msys just for m3cc. msys is actually quite small, like only 20 files..) Oh, sorry, yet another question.The non-gcc backend is excluded from the build on systems that use the gcc backend.For minimization, that is appropriate.For maximizing cross build capability, it is wrong.The packages build fine. I suspect they work.I am not a user of cross build capability yet, so I don't really care. (What I do for NT386/NT386GNU /might/ be considered sort of a cross build, but it is different/easier).They are small packages. - Jay Date: Wed, 16 Jan 2008 08:25:49 -0500From: rcoleburn at scires.comTo: m3devel at elegosoft.com; jayk123 at hotmail.comSubject: Re: [M3devel] my status on win32 Jay: There is no line in the m3makefile dealing with datefn, so I added the whole statement just before the line include("version.quake") Now, I get an error saying that the variable datefn is not defined. If you change to put quotes around datefn in the include statement, you get an error saying it can't open the file. You made a reference in one of your earlier posts about trying 5.1.6 or 4.1, but note that I started with your cm3-min-WIN32-NT386-d5.5.0.zip , not the 5.1.6 or 4.1 versions. Thus, using d5.5.0 as a base, I am trying to run your "upgrade.cmd" to rebuild the sources I checked out from CVS. Since this doesn't work "out-of-the-box", again I say this fits into the "Broken #1" category. If I can get this to work, I don't mind putting together a Windows installer program that will install the whole thing. That way, folks won't have to install cygwin just to get CVS so that they can install a working cm3. Folks will need to install the free Microsoft Visual C as a prerequisite, but then that's not too bad. Having an installer program would make cm3 more friendly to Windows folks. The current 16-step method is too laborious and error-prone for the person just getting started and they will not give cm3 a second try. As the cm3 system evolves and new releases are made, we will need to keep the installer program up-to-date and I don't mind doing that. After someone gets familiar with cm3 they might want to delve into some of the scripts for rebuilding the system, but until then, I think the installer program is the way to go. Regards, Randy>>> Jay 1/16/2008 1:01 AM >>>I think I see the problem. in cm3\src\m3makefile, make this change > if not defined("NOW") include(datefn) > end datefn is only created if certain other variables aren't defined, and do-pkg defines them.I don't know why I don't see this. Later.Could be that the Python scripts have a typo and don't define them.I've been using them more than cmd. If the host is NT, "NOW" is either gotten from an updated cm3.exe, or left to "not available". So the initial cm3 built from older cm3 can't report when it was built, but cm3 built from current cm3 can. I need to change that: 1) to be a function for niceness 2) to make it that way for Posix, for any host but I haven't been using Posix as much lately so not testing it. - Jay Date: Tue, 15 Jan 2008 23:55:39 -0500From: rcoleburn at scires.comTo: m3devel at elegosoft.com; jayk123 at hotmail.comSubject: RE: my status on win32 Jay: In the file version.quake, I made the following edit: changed line: local datefn = "../" & TARGET & ".datenow" to: local datefn = ".." & SL & TARGET & ".datenow" This change has the effect of putting a backward slash in the pathname instead of a forward slash, so we getC:\CM3_CVS_SourceTree\m3-sys\cm3\src\..\NT386.datenow So from that perspective, the change seems good. Unfortunately, I still get the error that this file can't be opened. A quick check of C:\CM3_CVS_SourceTree\m3-sys\cm3\NT386 shows that the file .datenow does not exist. Regards, Randy>>> Jay 1/15/2008 11:03 PM >>>That's not too bad really. 1) I'd recommend putting cm3 at the start of the path instead of the end. 2) Just comment out the offending code to make progress. It's not critical. >> C:\CM3_CVS_SourceTree\m3-sys\cm3\src\../NT386.datenow The code is: C:\CM3_CVS_SourceTree\m3-sys\cm3\src\version.quake or such, included by cm3\src\m3makefile. Does the file exist?Does version.quake use "/" or "SL"? If it uses "/", try replacing with SL (and ampersand for string concat). Could be that a newer binary distributions works better with forward slashes. > 4. > 5. > 6. Launch cygwin from desktop icon. Cygwin is only needed for cvs, I think you realize. Could you send me offline the result of just running "set" after running vcvarsall? I'd like to adapt pylib.py to it maybe. (I can start from 5.1.6 and will try 4.1 at some point.) - Jay Date: Tue, 15 Jan 2008 22:52:59 -0500From: rcoleburn at scires.comTo: m3devel at elegosoft.com; jayk123 at hotmail.comSubject: my status on win32 Jay et al: I've listed below the steps I've undertaken to try and build the current sources on Windows XP. I've also attached a text file showing the output I got when trying to build everything using Jay's upgrade.cmd script. Unfortunately, I'm getting a build error (see below). Please advise on how to resolve. STEPS I TOOK: ========= 1. Download Microsoft Visual Studio 2008 Express Edition All-in-One .ISO file and burn to DVD. http://www.microsoft.com/express/download/ 2. Install Microsoft Visual C++ 2008 Express Edition from DVD. 3. Use "Microsoft Update" service to check for updates / service packs. 4. Download cygwin setup program from http://cygwin.com/ 5. Ran cygwin setup.exe program to install cygwin for all users. Under "Devel" category, make certain to select "cvs" for installation. 6. Launch cygwin from desktop icon. 7. In cygwin command shell window, execute following two commands, making sure to give email as password when prompted for login: cvs -d :pserver:anonymous at modula3.elegosoft.com:/usr/cvs login cvs -d :pserver:anonymous at modula3.elegosoft.com:/usr/cvs checkout cm3 8. Moved resulting C:\cygwin\home\rcoleburn\cm3 to C:\CM3_CVS_SourceTree Note that you should replace "rcoleburn" above with your Windows login username. 9. Download cm3-min-WIN32-NT386-d5.5.0.zip and cm3-min-WIN32-NT386-d5.5.0-symbols.zip from http://modula3.elegosoft.com/cm3/download.html 10. Unzipped cm3-min-WIN32-NT386-d5.5.0.zip and stored resulting cm3 folder at C:\cm3 11. Unzipped cm3-min-WIN32-NT386-d5.5.0-symbols.zip and stored resulting symbols folder at C:\cm3\symbols 12. Launch Windows Command Prompt shell. The following steps represent commands executed within this shell. 13. path %path%;c:\cm3\bin 14. "C:\Program Files\Microsoft Visual Studio 9.0\VC\vcvarsall.bat" 15. cd C:\CM3_CVS_SourceTree\scripts\win 16. upgrade.cmd ERROR I'M GETTING: ============= === package C:\CM3_CVS_SourceTree\m3-sys\cm3 ===+++ "cm3 -build -DROOT=C:\\CM3_CVS_SourceTree -DCM3_VERSION_TEXT=d5.5.1 -DCM3_VERSION_NUMBER=050501 -DCM3_LAST_CHANGED=2007-12-30 && cm3 -ship -DROOT=C:\\CM3_CVS_SourceTree -DCM3_VERSION_TEXT=d5.5.1 -DCM3_VERSION_NUMBER=050501 -DCM3_LAST_CHANGED=2007-12-30" +++--- building in NT386 --- ignoring ..\src\m3overrides "C:\CM3_CVS_SourceTree\m3-sys\cm3\src\version.quake", line 136: quake runtime error: unable to open "C:\CM3_CVS_SourceTree\m3-sys\cm3\src\../NT386.datenow" forreading --procedure-- -line- -file---include -- version_impl 136 C:\CM3_CVS_SourceTree\m3-sys\cm3\src\version.quakeinclude_dir 20 C:\CM3_CVS_SourceTree\m3-sys\cm3\src\m3makefile 8 C:\CM3_CVS_SourceTree\m3-sys\cm3\NT386\m3make.args Fatal Error: package build failedERROR: "cm3 -build -DROOT=C:\\CM3_CVS_SourceTree -DCM3_VERSION_TEXT=d5.5.1 -DCM3_VERSION_NUMBER=050501 -DCM3_LAST_CHANGED=2007-12-30 && cm3 -ship -DROOT=C:\\CM3_CVS_SourceTree -DCM3_VERSION_TEXT=d5.5.1 -DCM3_VERSION_NUMBER=050501 -DCM3_LAST_CHANGED=2007-12-30"ERROR: cd C:\CM3_CVS_SourceTree\m3-sys\cm3ERROR: set INSTALLROOT=c:\cm3 Regards, Randy Share life as it happens with the new Windows Live. Start sharing! Put your friends on the big screen with Windows Vista? + Windows LiveT. Start now! Get the power of Windows + Web with the new Windows Live. Get it now! _________________________________________________________________ Make distant family not so distant with Windows Vista? + Windows Live?. http://www.microsoft.com/windows/digitallife/keepintouch.mspx?ocid=TXT_TAGLM_CPC_VideoChat_distantfamily_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Wed Jan 16 21:27:40 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 16 Jan 2008 15:27:40 -0500 Subject: [M3devel] GC question version 2 In-Reply-To: References: Message-ID: This might be possible, but probably would force completion of the current GC to get all the references. Again, not a particularly nice thing to be doing. Once again, why not use indirection and weak references. Probably cheaper, more flexible and portable. On Jan 16, 2008, at 1:28 PM, Darko wrote: > Ok, a slightly different approach: Can the GC give me a list of all > the objects that contain a reference to an object? Would it be > thorough (ie not miss any objects)? False positives might be ok. > Then I could check the type of each object and update the > references myself. It would be reasonable to assume that the > references in question were not being changed by any thread during > the checking process. > > Thanks, > Darko. From darko at darko.org Wed Jan 16 21:52:31 2008 From: darko at darko.org (Darko) Date: Wed, 16 Jan 2008 12:52:31 -0800 Subject: [M3devel] GC question version 2 In-Reply-To: References: Message-ID: <96E7F2FE-D050-4B3C-8918-258FE5CE690F@darko.org> Thanks, I probably will have to use some combination of encapsulation and indirection, but that solution isn't cheaper in terms of memory, which might be a problem in what is an all-allocated data structure (ie, every field value is allocated). I'm basically investigating all possible approaches and not against the solution you've suggested. On 16/01/2008, at 12:27 PM, Tony Hosking wrote: > This might be possible, but probably would force completion of the > current GC to get all the references. Again, not a particularly > nice thing to be doing. Once again, why not use indirection and > weak references. Probably cheaper, more flexible and portable. > > On Jan 16, 2008, at 1:28 PM, Darko wrote: > >> Ok, a slightly different approach: Can the GC give me a list of all >> the objects that contain a reference to an object? Would it be >> thorough (ie not miss any objects)? False positives might be ok. >> Then I could check the type of each object and update the >> references myself. It would be reasonable to assume that the >> references in question were not being changed by any thread during >> the checking process. >> >> Thanks, >> Darko. > From wagner at elegosoft.com Wed Jan 16 21:53:32 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 16 Jan 2008 21:53:32 +0100 Subject: [M3devel] my status on win32 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> <477EA137.1E75.00D7.1@scires.com> <478D394B.1E75.00D7.1@scires.com> <478D47FB.1E75.00D7.1@scires.com> <478DBF8D.1E75.00D7.1@scires.com> Message-ID: <20080116215332.ds4sfixao84g4wk4@mail.elegosoft.com> Quoting Jay : > Yes I agree it is "broken #1" and shouldn't be this way, but I > assure you, really, your results are 99% there. What isn't working > is minor and easy to fix and much is working. Jay, could you please just fix the cm3 package so that it compiles without problems in NT386(GNU), too? It should not be too difficult; there are no problems on the POSIX platforms. As for other installers or installation packages, I'm not against them, it is just that somebody must take responsibility and maintain them and keep them up-to-date. I for sure cannot contribute the efforts needed to maintain different installation variants for different targets. It has been much work to get everything working as it is. I'd be very careful with any changes that might have impacts on the system and installation structures. Everything will have to be tested on every platform afterwards, and my experience says that at least half will break regardless how careful you tried to be. For the integrity of the system itself, the regression test suite we've now setup will be a great help in my opinion. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Jan 16 21:55:51 2008 From: rcoleburn at scires.com (Randy Coleburn) Date: Wed, 16 Jan 2008 15:55:51 -0500 Subject: [M3devel] my status on win32 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> <477EA137.1E75.00D7.1@scires.com> <478D394B.1E75.00D7.1@scires.com> <478D47FB.1E75.00D7.1@scires.com> <478DBF8D.1E75.00D7.1@scires.com> <478DE973.1E75.00D7.1@scires.com> Message-ID: <478E2908.1E75.00D7.1@scires.com> Jay: Thanks for your reply. I think most of your goals seem reasonable and I concur that there are nasty problems introduced by spaces and short names. It's a messy situation that neither you nor I created. I was just relaying some of my prior experience in getting things to work. Indeed, for me, I try to avoid spaces always. That's one reason I root my cm3 at "C:\cm3" instead of in "C:\Program Files\cm3" or "C:\Documents and Settings\userhome\cm3". I've noted that with the various Visual Studio and Visual C tools going back for some time now that after you install it, your environment vars for TEMP and TMP get changed to use short names without spaces, so I guess even Microsoft has trouble with spaces. I also recall in the past with cm3 having trouble if my TEMP and TMP vars included spaces, so having Microsoft switch them to use short names without spaces seemed to solve that cm3 problem at least. As for the VC installation, I too recall that on some prior versions it asked you whether you wanted to set the environment vars permanently or to use vcvars. This time, when I installed Visual Studio 2008, it did not ask this question, so I guess it is version dependant. I'm not at the machine right now where I did the install, but later tonight I'll check to see if the VS2008 install set any permanent environment vars. Again, for me, I would like to be able to build everything as the first step in my series of tests. As soon as you can give me a fix to make things build, I can move on to make more progress. Thanks for your help. Regards, Randy >>> Jay 1/16/2008 2:13 PM >>> Hi Randy. I mostly agree and understand. Go ahead with your installer work. :) #2 is no longer needed. The cm3.cfg I use, that is checked in, that is in the newer distributions, just runs plain "cl" and links to plain "kernel32.dll", and doesn't pass any /I switches to cl => therefore it depends on %PATH%, %LIB%, and %INCLUDE%. As I was saying/rambling, we/I can probably teach cm3 a bit so as to not need vcvars. As I recall, but I need to check, when you install VC, there are some variables it sets unconditionally, and some it asks the user if they should be set. The ones it asks about are PATH, LIB, INCLUDE. The ones it sets unconditionally are the "root" of the install. PATH / LIB / INCLUDE are more invasive, more impactful, have more potential to break things. They are also easily derived from the "root". Similarly, the CM3 installer could ask the user if it is ok to modify their %PATH%, and do it in the registry and set the WM_INI_CHANGED or such message so that Explorer picks it up. Need to check MSDN on this. Forward slashes are fine for options. I take a dim view of these space, quoting, escaping issues. I have very mixed experience here. In SOME situations, your command lines pass through various layers of code, with various attempts to handle or ignore the various issues. The result is in my opinion an unpredictable mess. The problem is that people have confused "an array of strings" with "one flat string". At this point the confusion is widespread and deeply ingrained. On Unix I believe people just ignore the issue by not using spaces (or quotes?) on the command line, though escaping issues still remain for other characters. You just have to read the documenation on CreateProcess to realize how messed up this is. c:\program files\foo I believe is interpreted multiple ways until something works. It can be running c:\program with the parameter files\foo, or it can be running c:\program files\foo. Reliable interprocess communication should not be via command lines but via something more strongly typed such as RPC or shared memory or reading/writing a Pickle. I use the command line a lot, and I frequently copy paths from the command line and paste them into the file open dialog, which does not accept forward slashes nor nested double slashes. It should but oh well. Therefore I have goal before much longer to ensure that every path generated and probably reported by cm3 is in the "normal" form. If the user types in a forward slash, perhaps that should be reported back though. And forward slashes should be ok to enter and then get used internally. The need to configure short file names are gone, along with the need to quote them, by virtue of the dependency on environment variables. Paths with spaces can still come in other ways, but not via SYSTEM_CC in a "normal" cm3, for my newfangled revisionist version of "normal". :) Short names really stink, in so many ways. First, they aren't necessary even shorter, they are just of a limited character set. They can be up to twice as long as "long". Try this: mkdir \1.1.1. dir /x 1* Also, wildcard matching "always" (in FindFirstFile/FindNextFile) operates against both long and short, and since short are unpredcitable, wildcard matching therefore is. An example, probably, is: echo > foo.bar echo > food.barf dir *.bar Will probably, but not necessarily, match both files, though you would only expect one match. As well, I don't believe short file names have always been backed up and restored -- for anyone that uses any backup softwre (not me!). So you determine your short name, you backup and restore, and it changes. Or more clearly, recreating files, might get a different name. It's a mess. I would discourage you from persisting short names ever. Names with spaces I discourage but not as strong. For example, in some contexts, there is just one name and there is no ambiguity. Actually in %PATH% there is no ambiguity because the sepArator is the semicolon. I think Win9x different though, sigh. I agree from my "min" distribution, you need to build the rest. I have to admit, I thought the "culture" on this list was to want to and actually build the system from source. I will put a "std" distribution up on birch this week hopefully and hopefully someone will put it on the web page. Maintaining the installer should not be a problem. As long as the licensing and cost and all is right. I have not fixed the build yet, sorry. - Jay Date: Wed, 16 Jan 2008 11:24:34 -0500 From: rcoleburn at scires.com To: m3devel at elegosoft.com; jayk123 at hotmail.com Subject: Re: [M3devel] my status on win32 Jay: Not sure I've clued in to all of your dialog. Sorry. I have in the past used a free tool to build an installer package and I was thinking of using it again. Since the tool is free, we could put all the work I do into the CVS repository so that others could also maintain it. What I am looking to achieve is to have a way where a "normal" Windows user could download a program, run it, and have all of the cm3 packages installed without having to use the MIN distribution to build it up or any other tools to get the sources (like cvs). You could achieve the same thing by having a big ZIP file also I suppose, but having the installer would also let us easily put something in the start menu to launch a command line with all the environment variables set properly via automatic call to vcvars et al. When I get "Reactor" working, it too could be put into the start menu. That just makes it fit in better with the Windows user culture I think. The reason I wanted to rebuild everything is two-fold: 1) ensure it can be done (i.e., test for "Broken #1"), and 2) get all of the rest of the packages built so I could then use cm3 to build "reactor" and my own programs and test them to see if there are any "Broken #2" issues. The MIN distribution is really insufficient to do much of anything except to build the rest of the packages you need. My understanding is that I needed to use CVS to get the current sources, because if I went back to the source archive, it was old and known to be Broken #1 on Windows. I'm glad that you believe the current "Broken #1" situation is easy to fix. Let me know what to do and I'll give it another try. My experience in the past has been that there are 3 conditions to getting cm3 to work properly on windows after it has been installed: 1) make sure your environment variables are set up by vcvars to point to the compiler/linker/libraries (of course if you used a non-Microsoft C compiler/linker you would need to use something other than vcvars); 2) make sure cm3.cfg has the right paths in place to find all the libraries and tools using DOS style short names (no embedded spaces); and 3) make sure C:\cm3\bin is in your path. Of these, #2 & #3 are essentially one-time events, and #1 can be set up by a invoking a batch/command file via a shortcut, so no big deal for me. You could even make #1 a one-time event by modifying the system-level (vice user-level) environment variables. The old cm3install program seemed to do a decent job of #2 for me. Also, I've noted some of your past dialog about accepting either '/' or '\' as a path separator. I'm sure you are aware that on Windows '/' is used often for switches (arguments). Plus Windows also allows spaces to be embedded in the command line, so whatever solution you propose needs to take into account that a valid command line might look like this: C:\My Program Folder\My Program.exe /myArg1 /myArg2 In some situations, this command line would have to be quoted and rendered as: "C:\My Program Folder\My Program.exe" /myArg1 /myArg2 and in places where the backslash is an escape character, I've seen "C:\\My Program Folder\\My Program.exe" /myArg1 /myArg2 Alas, I seem to have rambled a bit also. Sorry. The immediate need for me now is to solve the Broken #1 condition, so please let me know how to fix it and proceed. Regards, Randy >>> Jay 1/16/2008 10:28 AM >>> Randy, yes and no and clarifications. I mention starting with 5.1.6 as a "worst" or "worse" case. The earlier you start, the harder things are -- for me, to ensure it will work. If you merely start with my 5.5.0, well, what are you rebuilding from source for? Heck, you can use any binary distribution, 4.1, 5.1.6, and just use it. They should work. The n steps you/I give are really actually geared for people who WANT to build from source, it is not what people HAVE to do. As well there have been can be source distributions, to cut out CVS. I'll look into the datefn stuff shortly. As to the installer, well, again, yes and no. The need for the installer is very small. All you have to do today is unzip the .zip somewhere and set the path, and possibly the vcvars thing. That's it. I should..now that you are "pressuring" me for ease of use, teach cm3 about the various ?venvdir%, %vcinstalldir% variables, etc. That way as long as the user installed the tools, even if they elected not to change path/lib/include, cm3 can find the compiler and linker. I know everyone wants to preserve the flexibility of quake/cm3.cfg but...besides, cm3 can be pretty darn smart here. IF cm3.cfg defines SYSTEM_CC, leave things along (NT386 cm3.cfg does not today do that). However if there is now SYSTEM_CC and there is no cl.exe/link.exe in %PATH%, it could go on a quick hunt for them. On the lib and include part, well, the dependency on %include% might only be for errno..maybe not worth it. It has been whatever it is forever, like int* _errno(void); #define errno (*_errno)()). Modula-3 engages in rampant header cloning and CErrnoC was only introduced where that was deemed more fragile than usual, and for Windows it probably wasn't actually fragile -- the fragility, if I may be so rudely judgemental, is because so many other systems are so Johnny-come-lately to arriving at the obviously correct threading model that Windows has had all along (since Win95/NT, can't say anything good about Win3.1; I think OS/2 might have had it correct all along too.). Funny, everyone has FINALLY arrived at the correct threading model, only to have start changing again, since the number of cores and machines is set to be much greater than anticipated, the obvious threading model has been deemed too difficult for anyone to use (Win32, Modula-3, Java, .NET, Python, all the same supposedly too difficult model btw), and so some new one is needed, and well, truthfully, the difficulty is not just for dummies on relatively small multiproc boxes not having simple race conditions, the problem is scaling way way up. Sorry that was my usual tangential. Even the unzip and set path would benefit slightly from a GUI installer. I believe there is some easy thing you can do where you write your GUI installer and you put it in the .zip and then you prepend the GUI self extracting .zip/.exe stub, and you can tell it to run a particular command after the extraction. I guess you might use a fancier thing though? That is, are you going to, say, write a gui installer from scratch in Modula-3? It might be a fun exercise. :) And then you could build the self extracting prefix from source etc. This is the hard way I guess, but more interesing. If you can build an msi or use InstallShield or Wix or something, go ahead. If you use widely availabe free as in beer tools, that can be rolled into whatever automation there is to produce distributions, keeping it up to date shouldn't be a problem. I do have to bring up some annoying questions: 1) Does anyone besides me have the capacity to produce distributions? i.e.: Any Win32 machines left at Elego? 2) I know I ramble. So one of my many tangents/questions went unanswered. Say, in the absence of a gui installer, should .zips/.tar.bz files look like cm3-min-/bin/cm3 or bin/cm3 or cm3/bin/cm3 The last one is more directly usable. The first one is very common. This reminds me though Randy, the distribution I made available was "min", so yeah, like if you are doing any gui programming, using any "standard" library besides m3core or libm3, you'd need to build more from source. I can readily provide you a "std" distribution though. It's "always" been a "problem" to make my files available -- no web site hosting for me -- but recently that wasn't a problem, someone picked the files out of ~jkrell on birch and put them on the web site. Good. One more thing -- Olaf, please confirm repeat yourself, 'cause I admit I wasn't sure it was the right thing, but if you insist, ok. "std" should be "all"? I should not continue to imagine there is a new larger group called "all"? And wherever things are missing from std but do build ok, add them? m3cc should be in std? (I admit some big indecisiveness around m3cc. It is far and away the longest thing to build and so the one you really want to skip the most and leave out of whatever package group. I also wonder if on Windows, there should be some check where if sh is not in the $PATH, just silently skip m3cc? You only need MingWin to build what I have on my system for NT386GNU, except you also need msys just for m3cc. msys is actually quite small, like only 20 files..) Oh, sorry, yet another question. The non-gcc backend is excluded from the build on systems that use the gcc backend. For minimization, that is appropriate. For maximizing cross build capability, it is wrong. The packages build fine. I suspect they work. I am not a user of cross build capability yet, so I don't really care. (What I do for NT386/NT386GNU /might/ be considered sort of a cross build, but it is different/easier). They are small packages. - Jay Date: Wed, 16 Jan 2008 08:25:49 -0500 From: rcoleburn at scires.com To: m3devel at elegosoft.com; jayk123 at hotmail.com Subject: Re: [M3devel] my status on win32 Jay: There is no line in the m3makefile dealing with datefn, so I added the whole statement just before the line include("version.quake") Now, I get an error saying that the variable datefn is not defined. If you change to put quotes around datefn in the include statement, you get an error saying it can't open the file. You made a reference in one of your earlier posts about trying 5.1.6 or 4.1, but note that I started with your cm3-min-WIN32-NT386-d5.5.0.zip , not the 5.1.6 or 4.1 versions. Thus, using d5.5.0 as a base, I am trying to run your "upgrade.cmd" to rebuild the sources I checked out from CVS. Since this doesn't work "out-of-the-box", again I say this fits into the "Broken #1" category. If I can get this to work, I don't mind putting together a Windows installer program that will install the whole thing. That way, folks won't have to install cygwin just to get CVS so that they can install a working cm3. Folks will need to install the free Microsoft Visual C as a prerequisite, but then that's not too bad. Having an installer program would make cm3 more friendly to Windows folks. The current 16-step method is too laborious and error-prone for the person just getting started and they will not give cm3 a second try. As the cm3 system evolves and new releases are made, we will need to keep the installer program up-to-date and I don't mind doing that. After someone gets familiar with cm3 they might want to delve into some of the scripts for rebuilding the system, but until then, I think the installer program is the way to go. Regards, Randy >>> Jay 1/16/2008 1:01 AM >>> I think I see the problem. in cm3\src\m3makefile, make this change > if not defined("NOW") include(datefn) > end datefn is only created if certain other variables aren't defined, and do-pkg defines them. I don't know why I don't see this. Later. Could be that the Python scripts have a typo and don't define them. I've been using them more than cmd. If the host is NT, "NOW" is either gotten from an updated cm3.exe, or left to "not available". So the initial cm3 built from older cm3 can't report when it was built, but cm3 built from current cm3 can. I need to change that: 1) to be a function for niceness 2) to make it that way for Posix, for any host but I haven't been using Posix as much lately so not testing it. - Jay Date: Tue, 15 Jan 2008 23:55:39 -0500 From: rcoleburn at scires.com To: m3devel at elegosoft.com; jayk123 at hotmail.com Subject: RE: my status on win32 Jay: In the file version.quake, I made the following edit: changed line: local datefn = "../" & TARGET & ".datenow" to: local datefn = ".." & SL & TARGET & ".datenow" This change has the effect of putting a backward slash in the pathname instead of a forward slash, so we get C:\CM3_CVS_SourceTree\m3-sys\cm3\src\..\NT386.datenow So from that perspective, the change seems good. Unfortunately, I still get the error that this file can't be opened. A quick check of C:\CM3_CVS_SourceTree\m3-sys\cm3\NT386 shows that the file .datenow does not exist. Regards, Randy >>> Jay 1/15/2008 11:03 PM >>> That's not too bad really. 1) I'd recommend putting cm3 at the start of the path instead of the end. 2) Just comment out the offending code to make progress. It's not critical. >> C:\CM3_CVS_SourceTree\m3-sys\cm3\src\../NT386.datenow The code is: C:\CM3_CVS_SourceTree\m3-sys\cm3\src\version.quake or such, included by cm3\src\m3makefile. Does the file exist? Does version.quake use "/" or "SL"? If it uses "/", try replacing with SL (and ampersand for string concat). Could be that a newer binary distributions works better with forward slashes. > 4. > 5. > 6. Launch cygwin from desktop icon. Cygwin is only needed for cvs, I think you realize. Could you send me offline the result of just running "set" after running vcvarsall? I'd like to adapt pylib.py to it maybe. (I can start from 5.1.6 and will try 4.1 at some point.) - Jay Date: Tue, 15 Jan 2008 22:52:59 -0500 From: rcoleburn at scires.com To: m3devel at elegosoft.com; jayk123 at hotmail.com Subject: my status on win32 Jay et al: I've listed below the steps I've undertaken to try and build the current sources on Windows XP. I've also attached a text file showing the output I got when trying to build everything using Jay's upgrade.cmd script. Unfortunately, I'm getting a build error (see below). Please advise on how to resolve. STEPS I TOOK: ========= 1. Download Microsoft Visual Studio 2008 Express Edition All-in-One .ISO file and burn to DVD. http://www.microsoft.com/express/download/ 2. Install Microsoft Visual C++ 2008 Express Edition from DVD. 3. Use "Microsoft Update" service to check for updates / service packs. 4. Download cygwin setup program from http://cygwin.com/ 5. Ran cygwin setup.exe program to install cygwin for all users. Under "Devel" category, make certain to select "cvs" for installation. 6. Launch cygwin from desktop icon. 7. In cygwin command shell window, execute following two commands, making sure to give email as password when prompted for login: cvs -d :pserver:anonymous at modula3.elegosoft.com:/usr/cvs login cvs -d :pserver:anonymous at modula3.elegosoft.com:/usr/cvs checkout cm3 8. Moved resulting C:\cygwin\home\rcoleburn\cm3 to C:\CM3_CVS_SourceTree Note that you should replace "rcoleburn" above with your Windows login username. 9. Download cm3-min-WIN32-NT386-d5.5.0.zip and cm3-min-WIN32-NT386-d5.5.0-symbols.zip from http://modula3.elegosoft.com/cm3/download.html 10. Unzipped cm3-min-WIN32-NT386-d5.5.0.zip and stored resulting cm3 folder at C:\cm3 11. Unzipped cm3-min-WIN32-NT386-d5.5.0-symbols.zip and stored resulting symbols folder at C:\cm3\symbols 12. Launch Windows Command Prompt shell. The following steps represent commands executed within this shell. 13. path %path%;c:\cm3\bin 14. "C:\Program Files\Microsoft Visual Studio 9.0\VC\vcvarsall.bat" 15. cd C:\CM3_CVS_SourceTree\scripts\win 16. upgrade.cmd ERROR I'M GETTING: ============= === package C:\CM3_CVS_SourceTree\m3-sys\cm3 === +++ "cm3 -build -DROOT=C:\\CM3_CVS_SourceTree -DCM3_VERSION_TEXT=d5.5.1 -DCM3_V ERSION_NUMBER=050501 -DCM3_LAST_CHANGED=2007-12-30 && cm3 -ship -DROOT=C:\\CM3_C VS_SourceTree -DCM3_VERSION_TEXT=d5.5.1 -DCM3_VERSION_NUMBER=050501 -DCM3_LAST_C HANGED=2007-12-30" +++ --- building in NT386 --- ignoring ..\src\m3overrides "C:\CM3_CVS_SourceTree\m3-sys\cm3\src\version.quake", line 136: quake runtime er ror: unable to open "C:\CM3_CVS_SourceTree\m3-sys\cm3\src\../NT386.datenow" for reading --procedure-- -line- -file--- include -- version_impl 136 C:\CM3_CVS_SourceTree\m3-sys\cm3\src\version.quake include_dir 20 C:\CM3_CVS_SourceTree\m3-sys\cm3\src\m3makefile 8 C:\CM3_CVS_SourceTree\m3-sys\cm3\NT386\m3make.args Fatal Error: package build failed ERROR: "cm3 -build -DROOT=C:\\CM3_CVS_SourceTree -DCM3_VERSION_TEXT=d5.5.1 -DCM 3_VERSION_NUMBER=050501 -DCM3_LAST_CHANGED=2007-12-30 && cm3 -ship -DROOT=C:\\CM 3_CVS_SourceTree -DCM3_VERSION_TEXT=d5.5.1 -DCM3_VERSION_NUMBER=050501 -DCM3_LAS T_CHANGED=2007-12-30" ERROR: cd C:\CM3_CVS_SourceTree\m3-sys\cm3 ERROR: set INSTALLROOT=c:\cm3 Regards, Randy Share life as it happens with the new Windows Live. Start sharing! ( http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_012008 ) Put your friends on the big screen with Windows Vista* + Windows LiveT. Start now! ( http://www.microsoft.com/windows/shop/specialoffers.mspx?ocid=TXT_TAGLM_CPC_MediaCtr_bigscreen_012008 ) Get the power of Windows + Web with the new Windows Live. Get it now! ( http://www.windowslive.com/?ocid=TXT_TAGHM_Wave2_powerofwindows_012008 ) Make distant family not so distant with Windows Vista* + Windows Live*. Start now! ( http://www.microsoft.com/windows/digitallife/keepintouch.mspx?ocid=TXT_TAGLM_CPC_VideoChat_distantfamily_012008 ) -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Wed Jan 16 22:42:04 2008 From: jayk123 at hotmail.com (Jay) Date: Wed, 16 Jan 2008 21:42:04 +0000 Subject: [M3devel] my status on win32 In-Reply-To: <478E2908.1E75.00D7.1@scires.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> <477EA137.1E75.00D7.1@scires.com> <478D394B.1E75.00D7.1@scires.com> <478D47FB.1E75.00D7.1@scires.com> <478DBF8D.1E75.00D7.1@scires.com> <478DE973.1E75.00D7.1@scires.com> <478E2908.1E75.00D7.1@scires.com> Message-ID: Regarding temp, I find that cm3 doesn't delete the response files qk, qk_1, etc. so I have modified cm3.cfg/NT386/NT386GNU to write the response files into the output directory, so they will be reliably cleaned up at some point. That /might/ divorce cm3 from all interactions with TEMP/TMP. It was tricky, because mklib demands newlines in the response file, spaces aren't adequate, and arglist doesn't always write a response file, such as for short command lines, and the command lines are nested lists, which don't seem to flatten like the docs say, I could find no way to flatten them. When I get back home I think I'll send all my diffs and hope for one big approval and then submit them. Maybe I'll figure out the NT386GNU runtime crash before that. - Jay Date: Wed, 16 Jan 2008 15:55:51 -0500From: rcoleburn at scires.comTo: m3devel at elegosoft.com; jayk123 at hotmail.comSubject: RE: [M3devel] my status on win32 Jay: Thanks for your reply. I think most of your goals seem reasonable and I concur that there are nasty problems introduced by spaces and short names. It's a messy situation that neither you nor I created. I was just relaying some of my prior experience in getting things to work. Indeed, for me, I try to avoid spaces always. That's one reason I root my cm3 at "C:\cm3" instead of in "C:\Program Files\cm3" or "C:\Documents and Settings\userhome\cm3". I've noted that with the various Visual Studio and Visual C tools going back for some time now that after you install it, your environment vars for TEMP and TMP get changed to use short names without spaces, so I guess even Microsoft has trouble with spaces. I also recall in the past with cm3 having trouble if my TEMP and TMP vars included spaces, so having Microsoft switch them to use short names without spaces seemed to solve that cm3 problem at least. As for the VC installation, I too recall that on some prior versions it asked you whether you wanted to set the environment vars permanently or to use vcvars. This time, when I installed Visual Studio 2008, it did not ask this question, so I guess it is version dependant. I'm not at the machine right now where I did the install, but later tonight I'll check to see if the VS2008 install set any permanent environment vars. Again, for me, I would like to be able to build everything as the first step in my series of tests. As soon as you can give me a fix to make things build, I can move on to make more progress. Thanks for your help. Regards, Randy>>> Jay 1/16/2008 2:13 PM >>>Hi Randy. I mostly agree and understand.Go ahead with your installer work. :) #2 is no longer needed. The cm3.cfg I use, that is checked in, that is in the newer distributions, just runs plain "cl" and links to plain "kernel32.dll", and doesn't pass any /I switches to cl => therefore it depends on %PATH%, %LIB%, and %INCLUDE%. As I was saying/rambling, we/I can probably teach cm3 a bit so as to not need vcvars.As I recall, but I need to check, when you install VC, there are some variables it sets unconditionally, and some it asks the user if they should be set. The ones it asks about are PATH, LIB, INCLUDE. The ones it sets unconditionally are the "root" of the install. PATH / LIB / INCLUDE are more invasive, more impactful, have more potential to break things. They are also easily derived from the "root". Similarly, the CM3 installer could ask the user if it is ok to modify their %PATH%, and do it in the registry and set the WM_INI_CHANGED or such message so that Explorer picks it up. Need to check MSDN on this. Forward slashes are fine for options. I take a dim view of these space, quoting, escaping issues.I have very mixed experience here. In SOME situations, your command lines pass through various layers of code, with various attempts to handle or ignore the various issues. The result is in my opinion an unpredictable mess.The problem is that people have confused "an array of strings" with "one flat string". At this point the confusion is widespread and deeply ingrained. On Unix I believe people just ignore the issue by not using spaces (or quotes?) on the command line, though escaping issues still remain for other characters. You just have to read the documenation on CreateProcess to realize how messed up this is.c:\program files\foo I believe is interpreted multiple ways until something works.It can be running c:\program with the parameter files\foo, or it can be running c:\program files\foo. Reliable interprocess communication should not be via command lines but via something more strongly typed such as RPC or shared memory or reading/writing a Pickle. I use the command line a lot, and I frequently copy paths from the command line and paste them into the file open dialog, which does not accept forward slashes nor nested double slashes. It should but oh well. Therefore I have goal before much longer to ensure that every path generated and probably reported by cm3 is in the "normal" form. If the user types in a forward slash, perhaps that should be reported back though. And forward slashes should be ok to enter and then get used internally. The need to configure short file names are gone, along with the need to quote them, by virtue of the dependency on environment variables. Paths with spaces can still come in other ways, but not via SYSTEM_CC in a "normal" cm3, for my newfangled revisionist version of "normal". :) Short names really stink, in so many ways.First, they aren't necessary even shorter, they are just of a limited character set.They can be up to twice as long as "long".Try this: mkdir \1.1.1. dir /x 1* Also, wildcard matching "always" (in FindFirstFile/FindNextFile) operates against both long and short, and since short are unpredcitable, wildcard matching therefore is. An example, probably, is: echo > foo.barecho > food.barfdir *.bar Will probably, but not necessarily, match both files, though you would only expect one match. As well, I don't believe short file names have always been backed up and restored -- for anyone that uses any backup softwre (not me!). So you determine your short name, you backup and restore, and it changes. Or more clearly, recreating files, might get a different name.It's a mess. I would discourage you from persisting short names ever.Names with spaces I discourage but not as strong.For example, in some contexts, there is just one name and there is no ambiguity.Actually in %PATH% there is no ambiguity because the sepArator is the semicolon.I think Win9x different though, sigh. I agree from my "min" distribution, you need to build the rest.I have to admit, I thought the "culture" on this list was to want to and actually build the system from source.I will put a "std" distribution up on birch this week hopefully and hopefully someone will put it on the web page. Maintaining the installer should not be a problem.As long as the licensing and cost and all is right. I have not fixed the build yet, sorry. - Jay Date: Wed, 16 Jan 2008 11:24:34 -0500From: rcoleburn at scires.comTo: m3devel at elegosoft.com; jayk123 at hotmail.comSubject: Re: [M3devel] my status on win32 Jay: Not sure I've clued in to all of your dialog. Sorry. I have in the past used a free tool to build an installer package and I was thinking of using it again. Since the tool is free, we could put all the work I do into the CVS repository so that others could also maintain it. What I am looking to achieve is to have a way where a "normal" Windows user could download a program, run it, and have all of the cm3 packages installed without having to use the MIN distribution to build it up or any other tools to get the sources (like cvs). You could achieve the same thing by having a big ZIP file also I suppose, but having the installer would also let us easily put something in the start menu to launch a command line with all the environment variables set properly via automatic call to vcvars et al. When I get "Reactor" working, it too could be put into the start menu. That just makes it fit in better with the Windows user culture I think. The reason I wanted to rebuild everything is two-fold: 1) ensure it can be done (i.e., test for "Broken #1"), and 2) get all of the rest of the packages built so I could then use cm3 to build "reactor" and my own programs and test them to see if there are any "Broken #2" issues. The MIN distribution is really insufficient to do much of anything except to build the rest of the packages you need. My understanding is that I needed to use CVS to get the current sources, because if I went back to the source archive, it was old and known to be Broken #1 on Windows. I'm glad that you believe the current "Broken #1" situation is easy to fix. Let me know what to do and I'll give it another try. My experience in the past has been that there are 3 conditions to getting cm3 to work properly on windows after it has been installed: 1) make sure your environment variables are set up by vcvars to point to the compiler/linker/libraries (of course if you used a non-Microsoft C compiler/linker you would need to use something other than vcvars); 2) make sure cm3.cfg has the right paths in place to find all the libraries and tools using DOS style short names (no embedded spaces); and 3) make sure C:\cm3\bin is in your path. Of these, #2 & #3 are essentially one-time events, and #1 can be set up by a invoking a batch/command file via a shortcut, so no big deal for me. You could even make #1 a one-time event by modifying the system-level (vice user-level) environment variables. The old cm3install program seemed to do a decent job of #2 for me. Also, I've noted some of your past dialog about accepting either '/' or '\' as a path separator. I'm sure you are aware that on Windows '/' is used often for switches (arguments). Plus Windows also allows spaces to be embedded in the command line, so whatever solution you propose needs to take into account that a valid command line might look like this: C:\My Program Folder\My Program.exe /myArg1 /myArg2 In some situations, this command line would have to be quoted and rendered as: "C:\My Program Folder\My Program.exe" /myArg1 /myArg2 and in places where the backslash is an escape character, I've seen "C:\\My Program Folder\\My Program.exe" /myArg1 /myArg2 Alas, I seem to have rambled a bit also. Sorry. The immediate need for me now is to solve the Broken #1 condition, so please let me know how to fix it and proceed. Regards, Randy>>> Jay 1/16/2008 10:28 AM >>>Randy, yes and no and clarifications. I mention starting with 5.1.6 as a "worst" or "worse" case.The earlier you start, the harder things are -- for me, to ensure it will work. If you merely start with my 5.5.0, well, what are you rebuilding from source for?Heck, you can use any binary distribution, 4.1, 5.1.6, and just use it. They should work. The n steps you/I give are really actually geared for people who WANT to build from source, it is not what people HAVE to do.As well there have been can be source distributions, to cut out CVS. I'll look into the datefn stuff shortly. As to the installer, well, again, yes and no.The need for the installer is very small. All you have to do today is unzip the .zip somewhere and set the path, and possibly the vcvars thing. That's it. I should..now that you are "pressuring" me for ease of use, teach cm3 about the various ?venvdir%, %vcinstalldir% variables, etc. That way as long as the user installed the tools, even if they elected not to change path/lib/include, cm3 can find the compiler and linker. I know everyone wants to preserve the flexibility of quake/cm3.cfg but...besides, cm3 can be pretty darn smart here. IF cm3.cfg defines SYSTEM_CC, leave things along (NT386 cm3.cfg does not today do that). However if there is now SYSTEM_CC and there is no cl.exe/link.exe in %PATH%, it could go on a quick hunt for them. On the lib and include part, well, the dependency on %include% might only be for errno..maybe not worth it. It has been whatever it is forever, like int* _errno(void); #define errno (*_errno)()). Modula-3 engages in rampant header cloning and CErrnoC was only introduced where that was deemed more fragile than usual, and for Windows it probably wasn't actually fragile -- the fragility, if I may be so rudely judgemental, is because so many other systems are so Johnny-come-lately to arriving at the obviously correct threading model that Windows has had all along (since Win95/NT, can't say anything good about Win3.1; I think OS/2 might have had it correct all along too.). Funny, everyone has FINALLY arrived at the correct threading model, only to have start changing again, since the number of cores and machines is set to be much greater than anticipated, the obvious threading model has been deemed too difficult for anyone to use (Win32, Modula-3, Java, .NET, Python, all the same supposedly too difficult model btw), and so some new one is needed, and well, truthfully, the difficulty is not just for dummies on relatively small multiproc boxes not having simple race conditions, the problem is scaling way way up. Sorry that was my usual tangential. Even the unzip and set path would benefit slightly from a GUI installer.I believe there is some easy thing you can do where you write your GUI installer and you put it in the .zip and then you prepend the GUI self extracting .zip/.exe stub, and you can tell it to run a particular command after the extraction. I guess you might use a fancier thing though?That is, are you going to, say, write a gui installer from scratch in Modula-3? It might be a fun exercise. :)And then you could build the self extracting prefix from source etc.This is the hard way I guess, but more interesing.If you can build an msi or use InstallShield or Wix or something, go ahead.If you use widely availabe free as in beer tools, that can be rolled into whatever automation there is to produce distributions, keeping it up to date shouldn't be a problem. I do have to bring up some annoying questions: 1) Does anyone besides me have the capacity to produce distributions? i.e.: Any Win32 machines left at Elego? 2) I know I ramble. So one of my many tangents/questions went unanswered.Say, in the absence of a gui installer, should .zips/.tar.bz files look like cm3-min-/bin/cm3orbin/cm3orcm3/bin/cm3 The last one is more directly usable. The first one is very common. This reminds me though Randy, the distribution I made available was "min", so yeah, like if you are doing any gui programming, using any "standard" library besides m3core or libm3, you'd need to build more from source. I can readily provide you a "std" distribution though.It's "always" been a "problem" to make my files available -- no web site hosting for me -- but recently that wasn't a problem, someone picked the files out of ~jkrell on birch and put them on the web site. Good. One more thing -- Olaf, please confirm repeat yourself, 'cause I admit I wasn't sure it was the right thing, but if you insist, ok. "std" should be "all"? I should not continue to imagine there is a new larger group called "all"? And wherever things are missing from std but do build ok, add them?m3cc should be in std?(I admit some big indecisiveness around m3cc. It is far and away the longest thing to build and so the one you really want to skip the most and leave out of whatever package group. I also wonder if on Windows, there should be some check where if sh is not in the $PATH, just silently skip m3cc? You only need MingWin to build what I have on my system for NT386GNU, except you also need msys just for m3cc. msys is actually quite small, like only 20 files..) Oh, sorry, yet another question.The non-gcc backend is excluded from the build on systems that use the gcc backend.For minimization, that is appropriate.For maximizing cross build capability, it is wrong.The packages build fine. I suspect they work.I am not a user of cross build capability yet, so I don't really care. (What I do for NT386/NT386GNU /might/ be considered sort of a cross build, but it is different/easier).They are small packages. - Jay Date: Wed, 16 Jan 2008 08:25:49 -0500From: rcoleburn at scires.comTo: m3devel at elegosoft.com; jayk123 at hotmail.comSubject: Re: [M3devel] my status on win32 Jay: There is no line in the m3makefile dealing with datefn, so I added the whole statement just before the line include("version.quake") Now, I get an error saying that the variable datefn is not defined. If you change to put quotes around datefn in the include statement, you get an error saying it can't open the file. You made a reference in one of your earlier posts about trying 5.1.6 or 4.1, but note that I started with your cm3-min-WIN32-NT386-d5.5.0.zip , not the 5.1.6 or 4.1 versions. Thus, using d5.5.0 as a base, I am trying to run your "upgrade.cmd" to rebuild the sources I checked out from CVS. Since this doesn't work "out-of-the-box", again I say this fits into the "Broken #1" category. If I can get this to work, I don't mind putting together a Windows installer program that will install the whole thing. That way, folks won't have to install cygwin just to get CVS so that they can install a working cm3. Folks will need to install the free Microsoft Visual C as a prerequisite, but then that's not too bad. Having an installer program would make cm3 more friendly to Windows folks. The current 16-step method is too laborious and error-prone for the person just getting started and they will not give cm3 a second try. As the cm3 system evolves and new releases are made, we will need to keep the installer program up-to-date and I don't mind doing that. After someone gets familiar with cm3 they might want to delve into some of the scripts for rebuilding the system, but until then, I think the installer program is the way to go. Regards, Randy>>> Jay 1/16/2008 1:01 AM >>>I think I see the problem. in cm3\src\m3makefile, make this change > if not defined("NOW") include(datefn) > end datefn is only created if certain other variables aren't defined, and do-pkg defines them.I don't know why I don't see this. Later.Could be that the Python scripts have a typo and don't define them.I've been using them more than cmd. If the host is NT, "NOW" is either gotten from an updated cm3.exe, or left to "not available". So the initial cm3 built from older cm3 can't report when it was built, but cm3 built from current cm3 can. I need to change that: 1) to be a function for niceness 2) to make it that way for Posix, for any host but I haven't been using Posix as much lately so not testing it. - Jay Date: Tue, 15 Jan 2008 23:55:39 -0500From: rcoleburn at scires.comTo: m3devel at elegosoft.com; jayk123 at hotmail.comSubject: RE: my status on win32 Jay: In the file version.quake, I made the following edit: changed line: local datefn = "../" & TARGET & ".datenow" to: local datefn = ".." & SL & TARGET & ".datenow" This change has the effect of putting a backward slash in the pathname instead of a forward slash, so we getC:\CM3_CVS_SourceTree\m3-sys\cm3\src\..\NT386.datenow So from that perspective, the change seems good. Unfortunately, I still get the error that this file can't be opened. A quick check of C:\CM3_CVS_SourceTree\m3-sys\cm3\NT386 shows that the file .datenow does not exist. Regards, Randy>>> Jay 1/15/2008 11:03 PM >>>That's not too bad really. 1) I'd recommend putting cm3 at the start of the path instead of the end. 2) Just comment out the offending code to make progress. It's not critical. >> C:\CM3_CVS_SourceTree\m3-sys\cm3\src\../NT386.datenow The code is: C:\CM3_CVS_SourceTree\m3-sys\cm3\src\version.quake or such, included by cm3\src\m3makefile. Does the file exist?Does version.quake use "/" or "SL"? If it uses "/", try replacing with SL (and ampersand for string concat). Could be that a newer binary distributions works better with forward slashes. > 4. > 5. > 6. Launch cygwin from desktop icon. Cygwin is only needed for cvs, I think you realize. Could you send me offline the result of just running "set" after running vcvarsall? I'd like to adapt pylib.py to it maybe. (I can start from 5.1.6 and will try 4.1 at some point.) - Jay Date: Tue, 15 Jan 2008 22:52:59 -0500From: rcoleburn at scires.comTo: m3devel at elegosoft.com; jayk123 at hotmail.comSubject: my status on win32 Jay et al: I've listed below the steps I've undertaken to try and build the current sources on Windows XP. I've also attached a text file showing the output I got when trying to build everything using Jay's upgrade.cmd script. Unfortunately, I'm getting a build error (see below). Please advise on how to resolve. STEPS I TOOK: ========= 1. Download Microsoft Visual Studio 2008 Express Edition All-in-One .ISO file and burn to DVD. http://www.microsoft.com/express/download/ 2. Install Microsoft Visual C++ 2008 Express Edition from DVD. 3. Use "Microsoft Update" service to check for updates / service packs. 4. Download cygwin setup program from http://cygwin.com/ 5. Ran cygwin setup.exe program to install cygwin for all users. Under "Devel" category, make certain to select "cvs" for installation. 6. Launch cygwin from desktop icon. 7. In cygwin command shell window, execute following two commands, making sure to give email as password when prompted for login: cvs -d :pserver:anonymous at modula3.elegosoft.com:/usr/cvs login cvs -d :pserver:anonymous at modula3.elegosoft.com:/usr/cvs checkout cm3 8. Moved resulting C:\cygwin\home\rcoleburn\cm3 to C:\CM3_CVS_SourceTree Note that you should replace "rcoleburn" above with your Windows login username. 9. Download cm3-min-WIN32-NT386-d5.5.0.zip and cm3-min-WIN32-NT386-d5.5.0-symbols.zip from http://modula3.elegosoft.com/cm3/download.html 10. Unzipped cm3-min-WIN32-NT386-d5.5.0.zip and stored resulting cm3 folder at C:\cm3 11. Unzipped cm3-min-WIN32-NT386-d5.5.0-symbols.zip and stored resulting symbols folder at C:\cm3\symbols 12. Launch Windows Command Prompt shell. The following steps represent commands executed within this shell. 13. path %path%;c:\cm3\bin 14. "C:\Program Files\Microsoft Visual Studio 9.0\VC\vcvarsall.bat" 15. cd C:\CM3_CVS_SourceTree\scripts\win 16. upgrade.cmd ERROR I'M GETTING: ============= === package C:\CM3_CVS_SourceTree\m3-sys\cm3 ===+++ "cm3 -build -DROOT=C:\\CM3_CVS_SourceTree -DCM3_VERSION_TEXT=d5.5.1 -DCM3_VERSION_NUMBER=050501 -DCM3_LAST_CHANGED=2007-12-30 && cm3 -ship -DROOT=C:\\CM3_CVS_SourceTree -DCM3_VERSION_TEXT=d5.5.1 -DCM3_VERSION_NUMBER=050501 -DCM3_LAST_CHANGED=2007-12-30" +++--- building in NT386 --- ignoring ..\src\m3overrides "C:\CM3_CVS_SourceTree\m3-sys\cm3\src\version.quake", line 136: quake runtime error: unable to open "C:\CM3_CVS_SourceTree\m3-sys\cm3\src\../NT386.datenow" forreading --procedure-- -line- -file---include -- version_impl 136 C:\CM3_CVS_SourceTree\m3-sys\cm3\src\version.quakeinclude_dir 20 C:\CM3_CVS_SourceTree\m3-sys\cm3\src\m3makefile 8 C:\CM3_CVS_SourceTree\m3-sys\cm3\NT386\m3make.args Fatal Error: package build failedERROR: "cm3 -build -DROOT=C:\\CM3_CVS_SourceTree -DCM3_VERSION_TEXT=d5.5.1 -DCM3_VERSION_NUMBER=050501 -DCM3_LAST_CHANGED=2007-12-30 && cm3 -ship -DROOT=C:\\CM3_CVS_SourceTree -DCM3_VERSION_TEXT=d5.5.1 -DCM3_VERSION_NUMBER=050501 -DCM3_LAST_CHANGED=2007-12-30"ERROR: cd C:\CM3_CVS_SourceTree\m3-sys\cm3ERROR: set INSTALLROOT=c:\cm3 Regards, Randy Share life as it happens with the new Windows Live. Start sharing! Put your friends on the big screen with Windows Vista? + Windows LiveT. Start now! Get the power of Windows + Web with the new Windows Live. Get it now! Make distant family not so distant with Windows Vista? + Windows LiveT. Start now! _________________________________________________________________ Put your friends on the big screen with Windows Vista? + Windows Live?. http://www.microsoft.com/windows/shop/specialoffers.mspx?ocid=TXT_TAGLM_CPC_MediaCtr_bigscreen_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Wed Jan 16 22:44:02 2008 From: jayk123 at hotmail.com (Jay) Date: Wed, 16 Jan 2008 21:44:02 +0000 Subject: [M3devel] my status on win32 In-Reply-To: <20080116215332.ds4sfixao84g4wk4@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> <477EA137.1E75.00D7.1@scires.com> <478D394B.1E75.00D7.1@scires.com> <478D47FB.1E75.00D7.1@scires.com> <478DBF8D.1E75.00D7.1@scires.com> <20080116215332.ds4sfixao84g4wk4@mail.elegosoft.com> Message-ID: When I get home I don't fall right to sleep... It's been building fine for me... Which reminds me. Randy, just cd over to m3-sys\cm3 and run either: cm3 or cm3 -DROOT= That might work. More likely the second. The problem is possibly related to "scripts". - Jay > Date: Wed, 16 Jan 2008 21:53:32 +0100> From: wagner at elegosoft.com> To: jayk123 at hotmail.com> CC: rcoleburn at scires.com; m3devel at elegosoft.com; m3-support at elego.de> Subject: Re: [M3devel] my status on win32> > Quoting Jay :> > > Yes I agree it is "broken #1" and shouldn't be this way, but I > > assure you, really, your results are 99% there. What isn't working > > is minor and easy to fix and much is working.> > Jay, could you please just fix the cm3 package so that it compiles> without problems in NT386(GNU), too? It should not be too difficult;> there are no problems on the POSIX platforms.> > As for other installers or installation packages, I'm not against them,> it is just that somebody must take responsibility and maintain them> and keep them up-to-date. I for sure cannot contribute the efforts> needed to maintain different installation variants for different> targets. It has been much work to get everything working as it is.> I'd be very careful with any changes that might have impacts on the> system and installation structures. Everything will have to be tested> on every platform afterwards, and my experience says that at least> half will break regardless how careful you tried to be.> > For the integrity of the system itself, the regression test suite> we've now setup will be a great help in my opinion.> > Olaf> -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194> _________________________________________________________________ Get the power of Windows + Web with the new Windows Live. http://www.windowslive.com?ocid=TXT_TAGHM_Wave2_powerofwindows_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Thu Jan 17 12:35:00 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 17 Jan 2008 12:35:00 +0100 Subject: [M3devel] About permissions on sources in the case of sources with permissions for owner only In-Reply-To: References: <998919.97099.qm@web27103.mail.ukl.yahoo.com> Message-ID: <20080117123500.hdmex004is48wook@mail.elegosoft.com> Late follow-up: Quoting Henning Thielemann : > On Wed, 17 Oct 2007, Daniel Alejandro Benavides D. wrote: > >> I got a commentary about files produced by the compiler and the >> files exported to the repository (ship) >> When compiling a package (bilist present on directory list of >> http://users.informatik.uni-halle.de/~thielema/Research/datastruct.tar.bz2 >> ) that has read and write permissions only for the owner >> I got files in LINUXLIBC6 that are readable for the group and other users. >> But when shipped on the 'src' directory they 're just readable for >> the owner (root). > > This is a general problem, not bound to BiList. > > As a work-around I wrote a script which corrects permissions after the > installation. > > $ more cm3ship > cm3 -ship > (chmod -R a+r /usr/local/cm3/pkg ; chmod a+x `find > /usr/local/cm3/pkg -type d`) & > > However, I do not want to call it 'solution'. This has bothered me several times, too. If the user's umask is set wrong, other's won't be able to change his installations. It can both be seen as a bug or a feature though. Today we leave all the permission settings to the OS. At least on POSIX the builder could set the group bit or just apply its own umask (defined in cm3.cfg). I don't know what to do on Windows, though; and on POSIX systems ACLs are used more and more. What do other's think: do we want to add some support for permissions wrt. team working? Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From lemming at henning-thielemann.de Thu Jan 17 12:38:15 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Thu, 17 Jan 2008 12:38:15 +0100 (MET) Subject: [M3devel] About permissions on sources in the case of sources with permissions for owner only In-Reply-To: <20080117123500.hdmex004is48wook@mail.elegosoft.com> References: <998919.97099.qm@web27103.mail.ukl.yahoo.com> <20080117123500.hdmex004is48wook@mail.elegosoft.com> Message-ID: On Thu, 17 Jan 2008, Olaf Wagner wrote: > Late follow-up: > > Quoting Henning Thielemann : > > On Wed, 17 Oct 2007, Daniel Alejandro Benavides D. wrote: > > > >> I got a commentary about files produced by the compiler and the > >> files exported to the repository (ship) > >> When compiling a package (bilist present on directory list of > >> http://users.informatik.uni-halle.de/~thielema/Research/datastruct.tar.bz2 > >> ) that has read and write permissions only for the owner > >> I got files in LINUXLIBC6 that are readable for the group and other users Is this a problem specific to my datastruct package? From wagner at elegosoft.com Thu Jan 17 13:34:46 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 17 Jan 2008 13:34:46 +0100 Subject: [M3devel] About permissions on sources in the case of sources with permissions for owner only In-Reply-To: References: <998919.97099.qm@web27103.mail.ukl.yahoo.com> <20080117123500.hdmex004is48wook@mail.elegosoft.com> Message-ID: <20080117133446.c0klnluuqs08wc48@mail.elegosoft.com> Quoting Henning Thielemann : > On Thu, 17 Jan 2008, Olaf Wagner wrote: > >> Late follow-up: >> >> Quoting Henning Thielemann : >> > On Wed, 17 Oct 2007, Daniel Alejandro Benavides D. wrote: >> > >> >> I got a commentary about files produced by the compiler and the >> >> files exported to the repository (ship) >> >> When compiling a package (bilist present on directory list of >> >> >> http://users.informatik.uni-halle.de/~thielema/Research/datastruct.tar.bz2 >> >> ) that has read and write permissions only for the owner >> >> I got files in LINUXLIBC6 that are readable for the group and other users > > Is this a problem specific to my datastruct package? No, it's a general problem; I was just following up to an old mail. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Jan 18 16:32:21 2008 From: jayk123 at hotmail.com (Jay) Date: Fri, 18 Jan 2008 15:32:21 +0000 Subject: [M3devel] my status on win32 In-Reply-To: <478DE973.1E75.00D7.1@scires.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> <477EA137.1E75.00D7.1@scires.com> <478D394B.1E75.00D7.1@scires.com> <478D47FB.1E75.00D7.1@scires.com> <478DBF8D.1E75.00D7.1@scires.com> <478DE973.1E75.00D7.1@scires.com> Message-ID: Randy, please try with an updated m3-sys/cm3/src/version.quake and report back, thanks. I understand why I wasn't seeing this. - Jay Date: Wed, 16 Jan 2008 11:24:34 -0500From: rcoleburn at scires.comTo: m3devel at elegosoft.com; jayk123 at hotmail.comSubject: Re: [M3devel] my status on win32 Jay: Not sure I've clued in to all of your dialog. Sorry. I have in the past used a free tool to build an installer package and I was thinking of using it again. Since the tool is free, we could put all the work I do into the CVS repository so that others could also maintain it. What I am looking to achieve is to have a way where a "normal" Windows user could download a program, run it, and have all of the cm3 packages installed without having to use the MIN distribution to build it up or any other tools to get the sources (like cvs). You could achieve the same thing by having a big ZIP file also I suppose, but having the installer would also let us easily put something in the start menu to launch a command line with all the environment variables set properly via automatic call to vcvars et al. When I get "Reactor" working, it too could be put into the start menu. That just makes it fit in better with the Windows user culture I think. The reason I wanted to rebuild everything is two-fold: 1) ensure it can be done (i.e., test for "Broken #1"), and 2) get all of the rest of the packages built so I could then use cm3 to build "reactor" and my own programs and test them to see if there are any "Broken #2" issues. The MIN distribution is really insufficient to do much of anything except to build the rest of the packages you need. My understanding is that I needed to use CVS to get the current sources, because if I went back to the source archive, it was old and known to be Broken #1 on Windows. I'm glad that you believe the current "Broken #1" situation is easy to fix. Let me know what to do and I'll give it another try. My experience in the past has been that there are 3 conditions to getting cm3 to work properly on windows after it has been installed: 1) make sure your environment variables are set up by vcvars to point to the compiler/linker/libraries (of course if you used a non-Microsoft C compiler/linker you would need to use something other than vcvars); 2) make sure cm3.cfg has the right paths in place to find all the libraries and tools using DOS style short names (no embedded spaces); and 3) make sure C:\cm3\bin is in your path. Of these, #2 & #3 are essentially one-time events, and #1 can be set up by a invoking a batch/command file via a shortcut, so no big deal for me. You could even make #1 a one-time event by modifying the system-level (vice user-level) environment variables. The old cm3install program seemed to do a decent job of #2 for me. Also, I've noted some of your past dialog about accepting either '/' or '\' as a path separator. I'm sure you are aware that on Windows '/' is used often for switches (arguments). Plus Windows also allows spaces to be embedded in the command line, so whatever solution you propose needs to take into account that a valid command line might look like this: C:\My Program Folder\My Program.exe /myArg1 /myArg2 In some situations, this command line would have to be quoted and rendered as: "C:\My Program Folder\My Program.exe" /myArg1 /myArg2 and in places where the backslash is an escape character, I've seen "C:\\My Program Folder\\My Program.exe" /myArg1 /myArg2 Alas, I seem to have rambled a bit also. Sorry. The immediate need for me now is to solve the Broken #1 condition, so please let me know how to fix it and proceed. Regards, Randy>>> Jay 1/16/2008 10:28 AM >>>Randy, yes and no and clarifications. I mention starting with 5.1.6 as a "worst" or "worse" case.The earlier you start, the harder things are -- for me, to ensure it will work. If you merely start with my 5.5.0, well, what are you rebuilding from source for?Heck, you can use any binary distribution, 4.1, 5.1.6, and just use it. They should work. The n steps you/I give are really actually geared for people who WANT to build from source, it is not what people HAVE to do.As well there have been can be source distributions, to cut out CVS. I'll look into the datefn stuff shortly. As to the installer, well, again, yes and no.The need for the installer is very small. All you have to do today is unzip the .zip somewhere and set the path, and possibly the vcvars thing. That's it. I should..now that you are "pressuring" me for ease of use, teach cm3 about the various ?venvdir%, %vcinstalldir% variables, etc. That way as long as the user installed the tools, even if they elected not to change path/lib/include, cm3 can find the compiler and linker. I know everyone wants to preserve the flexibility of quake/cm3.cfg but...besides, cm3 can be pretty darn smart here. IF cm3.cfg defines SYSTEM_CC, leave things along (NT386 cm3.cfg does not today do that). However if there is now SYSTEM_CC and there is no cl.exe/link.exe in %PATH%, it could go on a quick hunt for them. On the lib and include part, well, the dependency on %include% might only be for errno..maybe not worth it. It has been whatever it is forever, like int* _errno(void); #define errno (*_errno)()). Modula-3 engages in rampant header cloning and CErrnoC was only introduced where that was deemed more fragile than usual, and for Windows it probably wasn't actually fragile -- the fragility, if I may be so rudely judgemental, is because so many other systems are so Johnny-come-lately to arriving at the obviously correct threading model that Windows has had all along (since Win95/NT, can't say anything good about Win3.1; I think OS/2 might have had it correct all along too.). Funny, everyone has FINALLY arrived at the correct threading model, only to have start changing again, since the number of cores and machines is set to be much greater than anticipated, the obvious threading model has been deemed too difficult for anyone to use (Win32, Modula-3, Java, .NET, Python, all the same supposedly too difficult model btw), and so some new one is needed, and well, truthfully, the difficulty is not just for dummies on relatively small multiproc boxes not having simple race conditions, the problem is scaling way way up. Sorry that was my usual tangential. Even the unzip and set path would benefit slightly from a GUI installer.I believe there is some easy thing you can do where you write your GUI installer and you put it in the .zip and then you prepend the GUI self extracting .zip/.exe stub, and you can tell it to run a particular command after the extraction. I guess you might use a fancier thing though?That is, are you going to, say, write a gui installer from scratch in Modula-3? It might be a fun exercise. :)And then you could build the self extracting prefix from source etc.This is the hard way I guess, but more interesing.If you can build an msi or use InstallShield or Wix or something, go ahead.If you use widely availabe free as in beer tools, that can be rolled into whatever automation there is to produce distributions, keeping it up to date shouldn't be a problem. I do have to bring up some annoying questions: 1) Does anyone besides me have the capacity to produce distributions? i.e.: Any Win32 machines left at Elego? 2) I know I ramble. So one of my many tangents/questions went unanswered.Say, in the absence of a gui installer, should .zips/.tar.bz files look like cm3-min-/bin/cm3orbin/cm3orcm3/bin/cm3 The last one is more directly usable. The first one is very common. This reminds me though Randy, the distribution I made available was "min", so yeah, like if you are doing any gui programming, using any "standard" library besides m3core or libm3, you'd need to build more from source. I can readily provide you a "std" distribution though.It's "always" been a "problem" to make my files available -- no web site hosting for me -- but recently that wasn't a problem, someone picked the files out of ~jkrell on birch and put them on the web site. Good. One more thing -- Olaf, please confirm repeat yourself, 'cause I admit I wasn't sure it was the right thing, but if you insist, ok. "std" should be "all"? I should not continue to imagine there is a new larger group called "all"? And wherever things are missing from std but do build ok, add them?m3cc should be in std?(I admit some big indecisiveness around m3cc. It is far and away the longest thing to build and so the one you really want to skip the most and leave out of whatever package group. I also wonder if on Windows, there should be some check where if sh is not in the $PATH, just silently skip m3cc? You only need MingWin to build what I have on my system for NT386GNU, except you also need msys just for m3cc. msys is actually quite small, like only 20 files..) Oh, sorry, yet another question.The non-gcc backend is excluded from the build on systems that use the gcc backend.For minimization, that is appropriate.For maximizing cross build capability, it is wrong.The packages build fine. I suspect they work.I am not a user of cross build capability yet, so I don't really care. (What I do for NT386/NT386GNU /might/ be considered sort of a cross build, but it is different/easier).They are small packages. - Jay Date: Wed, 16 Jan 2008 08:25:49 -0500From: rcoleburn at scires.comTo: m3devel at elegosoft.com; jayk123 at hotmail.comSubject: Re: [M3devel] my status on win32 Jay: There is no line in the m3makefile dealing with datefn, so I added the whole statement just before the line include("version.quake") Now, I get an error saying that the variable datefn is not defined. If you change to put quotes around datefn in the include statement, you get an error saying it can't open the file. You made a reference in one of your earlier posts about trying 5.1.6 or 4.1, but note that I started with your cm3-min-WIN32-NT386-d5.5.0.zip , not the 5.1.6 or 4.1 versions. Thus, using d5.5.0 as a base, I am trying to run your "upgrade.cmd" to rebuild the sources I checked out from CVS. Since this doesn't work "out-of-the-box", again I say this fits into the "Broken #1" category. If I can get this to work, I don't mind putting together a Windows installer program that will install the whole thing. That way, folks won't have to install cygwin just to get CVS so that they can install a working cm3. Folks will need to install the free Microsoft Visual C as a prerequisite, but then that's not too bad. Having an installer program would make cm3 more friendly to Windows folks. The current 16-step method is too laborious and error-prone for the person just getting started and they will not give cm3 a second try. As the cm3 system evolves and new releases are made, we will need to keep the installer program up-to-date and I don't mind doing that. After someone gets familiar with cm3 they might want to delve into some of the scripts for rebuilding the system, but until then, I think the installer program is the way to go. Regards, Randy>>> Jay 1/16/2008 1:01 AM >>>I think I see the problem. in cm3\src\m3makefile, make this change > if not defined("NOW") include(datefn) > end datefn is only created if certain other variables aren't defined, and do-pkg defines them.I don't know why I don't see this. Later.Could be that the Python scripts have a typo and don't define them.I've been using them more than cmd. If the host is NT, "NOW" is either gotten from an updated cm3.exe, or left to "not available". So the initial cm3 built from older cm3 can't report when it was built, but cm3 built from current cm3 can. I need to change that: 1) to be a function for niceness 2) to make it that way for Posix, for any host but I haven't been using Posix as much lately so not testing it. - Jay Date: Tue, 15 Jan 2008 23:55:39 -0500From: rcoleburn at scires.comTo: m3devel at elegosoft.com; jayk123 at hotmail.comSubject: RE: my status on win32 Jay: In the file version.quake, I made the following edit: changed line: local datefn = "../" & TARGET & ".datenow" to: local datefn = ".." & SL & TARGET & ".datenow" This change has the effect of putting a backward slash in the pathname instead of a forward slash, so we getC:\CM3_CVS_SourceTree\m3-sys\cm3\src\..\NT386.datenow So from that perspective, the change seems good. Unfortunately, I still get the error that this file can't be opened. A quick check of C:\CM3_CVS_SourceTree\m3-sys\cm3\NT386 shows that the file .datenow does not exist. Regards, Randy>>> Jay 1/15/2008 11:03 PM >>>That's not too bad really. 1) I'd recommend putting cm3 at the start of the path instead of the end. 2) Just comment out the offending code to make progress. It's not critical. >> C:\CM3_CVS_SourceTree\m3-sys\cm3\src\../NT386.datenow The code is: C:\CM3_CVS_SourceTree\m3-sys\cm3\src\version.quake or such, included by cm3\src\m3makefile. Does the file exist?Does version.quake use "/" or "SL"? If it uses "/", try replacing with SL (and ampersand for string concat). Could be that a newer binary distributions works better with forward slashes. > 4. > 5. > 6. Launch cygwin from desktop icon. Cygwin is only needed for cvs, I think you realize. Could you send me offline the result of just running "set" after running vcvarsall? I'd like to adapt pylib.py to it maybe. (I can start from 5.1.6 and will try 4.1 at some point.) - Jay Date: Tue, 15 Jan 2008 22:52:59 -0500From: rcoleburn at scires.comTo: m3devel at elegosoft.com; jayk123 at hotmail.comSubject: my status on win32 Jay et al: I've listed below the steps I've undertaken to try and build the current sources on Windows XP. I've also attached a text file showing the output I got when trying to build everything using Jay's upgrade.cmd script. Unfortunately, I'm getting a build error (see below). Please advise on how to resolve. STEPS I TOOK: ========= 1. Download Microsoft Visual Studio 2008 Express Edition All-in-One .ISO file and burn to DVD. http://www.microsoft.com/express/download/ 2. Install Microsoft Visual C++ 2008 Express Edition from DVD. 3. Use "Microsoft Update" service to check for updates / service packs. 4. Download cygwin setup program from http://cygwin.com/ 5. Ran cygwin setup.exe program to install cygwin for all users. Under "Devel" category, make certain to select "cvs" for installation. 6. Launch cygwin from desktop icon. 7. In cygwin command shell window, execute following two commands, making sure to give email as password when prompted for login: cvs -d :pserver:anonymous at modula3.elegosoft.com:/usr/cvs login cvs -d :pserver:anonymous at modula3.elegosoft.com:/usr/cvs checkout cm3 8. Moved resulting C:\cygwin\home\rcoleburn\cm3 to C:\CM3_CVS_SourceTree Note that you should replace "rcoleburn" above with your Windows login username. 9. Download cm3-min-WIN32-NT386-d5.5.0.zip and cm3-min-WIN32-NT386-d5.5.0-symbols.zip from http://modula3.elegosoft.com/cm3/download.html 10. Unzipped cm3-min-WIN32-NT386-d5.5.0.zip and stored resulting cm3 folder at C:\cm3 11. Unzipped cm3-min-WIN32-NT386-d5.5.0-symbols.zip and stored resulting symbols folder at C:\cm3\symbols 12. Launch Windows Command Prompt shell. The following steps represent commands executed within this shell. 13. path %path%;c:\cm3\bin 14. "C:\Program Files\Microsoft Visual Studio 9.0\VC\vcvarsall.bat" 15. cd C:\CM3_CVS_SourceTree\scripts\win 16. upgrade.cmd ERROR I'M GETTING: ============= === package C:\CM3_CVS_SourceTree\m3-sys\cm3 ===+++ "cm3 -build -DROOT=C:\\CM3_CVS_SourceTree -DCM3_VERSION_TEXT=d5.5.1 -DCM3_VERSION_NUMBER=050501 -DCM3_LAST_CHANGED=2007-12-30 && cm3 -ship -DROOT=C:\\CM3_CVS_SourceTree -DCM3_VERSION_TEXT=d5.5.1 -DCM3_VERSION_NUMBER=050501 -DCM3_LAST_CHANGED=2007-12-30" +++--- building in NT386 --- ignoring ..\src\m3overrides "C:\CM3_CVS_SourceTree\m3-sys\cm3\src\version.quake", line 136: quake runtime error: unable to open "C:\CM3_CVS_SourceTree\m3-sys\cm3\src\../NT386.datenow" forreading --procedure-- -line- -file---include -- version_impl 136 C:\CM3_CVS_SourceTree\m3-sys\cm3\src\version.quakeinclude_dir 20 C:\CM3_CVS_SourceTree\m3-sys\cm3\src\m3makefile 8 C:\CM3_CVS_SourceTree\m3-sys\cm3\NT386\m3make.args Fatal Error: package build failedERROR: "cm3 -build -DROOT=C:\\CM3_CVS_SourceTree -DCM3_VERSION_TEXT=d5.5.1 -DCM3_VERSION_NUMBER=050501 -DCM3_LAST_CHANGED=2007-12-30 && cm3 -ship -DROOT=C:\\CM3_CVS_SourceTree -DCM3_VERSION_TEXT=d5.5.1 -DCM3_VERSION_NUMBER=050501 -DCM3_LAST_CHANGED=2007-12-30"ERROR: cd C:\CM3_CVS_SourceTree\m3-sys\cm3ERROR: set INSTALLROOT=c:\cm3 Regards, Randy Share life as it happens with the new Windows Live. Start sharing! Put your friends on the big screen with Windows Vista? + Windows LiveT. Start now! Get the power of Windows + Web with the new 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 rcoleburn at scires.com Fri Jan 18 16:58:36 2008 From: rcoleburn at scires.com (Randy Coleburn) Date: Fri, 18 Jan 2008 10:58:36 -0500 Subject: [M3devel] my status on win32 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> <477EA137.1E75.00D7.1@scires.com> <478D394B.1E75.00D7.1@scires.com> <478D47FB.1E75.00D7.1@scires.com> <478DBF8D.1E75.00D7.1@scires.com> <478DE973.1E75.00D7.1@scires.com> Message-ID: <47908659.1E75.00D7.1@scires.com> Jay: Ok. It will be later tonight before I can try again. Thanks! BTW, can you point me to a document/file somewhere that describes the various options for your windows command file scripts? I did experiment further with using the do-cm3-std.cmd and was finally able to get most everything to build, but of course this doesn't rebuild the compiler and core. Had problems with mentor and m3zume not wanting to build/run, so I commented these out in the cmd file to get it to work. Then I had trouble because everything was built with overrides by default, so I had to mess around with changing parameters and rebuilding clean. I've tried building some of my programs and, of course, have run into a few problems due to changes in the system. I've overcome most of these, but I am seeing some strange behavior: 1. pixmaps aren't rendered properly on the screen. They look really bad. I recall having this problem a while back with one of the early 5.x releases, so I guess it was never solved. I've got some old test programs I try to dig out and see if I can find out what is going on. I seem to recall that building standalone in the past seemed to fix the problem, so this is a real mystery. 2. I'm having trouble with bundles not returning all of the data. In the "reactor" program, bundles are used to provide input to the web browser for the page source. I'm seeing cases where not all of the HTML source is making it to the browser. Not sure if this is an I/O problem (maybe buffers not flushed) or if it is something else. It may be that this problem has some impact on #1 above because pixmaps are sometimes stored in the bundles. For the above #1 and #2, these things worked properly on cm3 v4.1. I have the sources to 4.1, so maybe I can use them to figure out what is wrong. On a side note, I found and fixed a major bug in the "reactor" program, so that is good. Now, for another topic that we should probably move to a new email thread: Back in the early days, my company paid Critical Mass, Inc., to customize the Trestle/FormsVBT look and feel to more closely resemble Windows. I have the sources for this work, but of course it is based on v4.1 and the repository code has moved on since then. I am curious if anyone would be interested in me trying to integrate these customizations back into the current source tree, perhaps on a different branch? If we go this route, I may need a little refresher tutorial on the use of branches in CVS. We would want to make it so that the main branch and the customized branch could evolve in sync. That is, if a bug was found in either branch, the fix should be incorporated into both. Regards, Randy >>> Jay 1/18/2008 10:32 AM >>> Randy, please try with an updated m3-sys/cm3/src/version.quake and report back, thanks. I understand why I wasn't seeing this. - Jay Date: Wed, 16 Jan 2008 11:24:34 -0500 From: rcoleburn at scires.com To: m3devel at elegosoft.com; jayk123 at hotmail.com Subject: Re: [M3devel] my status on win32 Jay: Not sure I've clued in to all of your dialog. Sorry. I have in the past used a free tool to build an installer package and I was thinking of using it again. Since the tool is free, we could put all the work I do into the CVS repository so that others could also maintain it. What I am looking to achieve is to have a way where a "normal" Windows user could download a program, run it, and have all of the cm3 packages installed without having to use the MIN distribution to build it up or any other tools to get the sources (like cvs). You could achieve the same thing by having a big ZIP file also I suppose, but having the installer would also let us easily put something in the start menu to launch a command line with all the environment variables set properly via automatic call to vcvars et al. When I get "Reactor" working, it too could be put into the start menu. That just makes it fit in better with the Windows user culture I think. The reason I wanted to rebuild everything is two-fold: 1) ensure it can be done (i.e., test for "Broken #1"), and 2) get all of the rest of the packages built so I could then use cm3 to build "reactor" and my own programs and test them to see if there are any "Broken #2" issues. The MIN distribution is really insufficient to do much of anything except to build the rest of the packages you need. My understanding is that I needed to use CVS to get the current sources, because if I went back to the source archive, it was old and known to be Broken #1 on Windows. I'm glad that you believe the current "Broken #1" situation is easy to fix. Let me know what to do and I'll give it another try. My experience in the past has been that there are 3 conditions to getting cm3 to work properly on windows after it has been installed: 1) make sure your environment variables are set up by vcvars to point to the compiler/linker/libraries (of course if you used a non-Microsoft C compiler/linker you would need to use something other than vcvars); 2) make sure cm3.cfg has the right paths in place to find all the libraries and tools using DOS style short names (no embedded spaces); and 3) make sure C:\cm3\bin is in your path. Of these, #2 & #3 are essentially one-time events, and #1 can be set up by a invoking a batch/command file via a shortcut, so no big deal for me. You could even make #1 a one-time event by modifying the system-level (vice user-level) environment variables. The old cm3install program seemed to do a decent job of #2 for me. Also, I've noted some of your past dialog about accepting either '/' or '\' as a path separator. I'm sure you are aware that on Windows '/' is used often for switches (arguments). Plus Windows also allows spaces to be embedded in the command line, so whatever solution you propose needs to take into account that a valid command line might look like this: C:\My Program Folder\My Program.exe /myArg1 /myArg2 In some situations, this command line would have to be quoted and rendered as: "C:\My Program Folder\My Program.exe" /myArg1 /myArg2 and in places where the backslash is an escape character, I've seen "C:\\My Program Folder\\My Program.exe" /myArg1 /myArg2 Alas, I seem to have rambled a bit also. Sorry. The immediate need for me now is to solve the Broken #1 condition, so please let me know how to fix it and proceed. Regards, Randy >>> Jay 1/16/2008 10:28 AM >>> Randy, yes and no and clarifications. I mention starting with 5.1.6 as a "worst" or "worse" case. The earlier you start, the harder things are -- for me, to ensure it will work. If you merely start with my 5.5.0, well, what are you rebuilding from source for? Heck, you can use any binary distribution, 4.1, 5.1.6, and just use it. They should work. The n steps you/I give are really actually geared for people who WANT to build from source, it is not what people HAVE to do. As well there have been can be source distributions, to cut out CVS. I'll look into the datefn stuff shortly. As to the installer, well, again, yes and no. The need for the installer is very small. All you have to do today is unzip the .zip somewhere and set the path, and possibly the vcvars thing. That's it. I should..now that you are "pressuring" me for ease of use, teach cm3 about the various ?venvdir%, %vcinstalldir% variables, etc. That way as long as the user installed the tools, even if they elected not to change path/lib/include, cm3 can find the compiler and linker. I know everyone wants to preserve the flexibility of quake/cm3.cfg but...besides, cm3 can be pretty darn smart here. IF cm3.cfg defines SYSTEM_CC, leave things along (NT386 cm3.cfg does not today do that). However if there is now SYSTEM_CC and there is no cl.exe/link.exe in %PATH%, it could go on a quick hunt for them. On the lib and include part, well, the dependency on %include% might only be for errno..maybe not worth it. It has been whatever it is forever, like int* _errno(void); #define errno (*_errno)()). Modula-3 engages in rampant header cloning and CErrnoC was only introduced where that was deemed more fragile than usual, and for Windows it probably wasn't actually fragile -- the fragility, if I may be so rudely judgemental, is because so many other systems are so Johnny-come-lately to arriving at the obviously correct threading model that Windows has had all along (since Win95/NT, can't say anything good about Win3.1; I think OS/2 might have had it correct all along too.). Funny, everyone has FINALLY arrived at the correct threading model, only to have start changing again, since the number of cores and machines is set to be much greater than anticipated, the obvious threading model has been deemed too difficult for anyone to use (Win32, Modula-3, Java, .NET, Python, all the same supposedly too difficult model btw), and so some new one is needed, and well, truthfully, the difficulty is not just for dummies on relatively small multiproc boxes not having simple race conditions, the problem is scaling way way up. Sorry that was my usual tangential. Even the unzip and set path would benefit slightly from a GUI installer. I believe there is some easy thing you can do where you write your GUI installer and you put it in the .zip and then you prepend the GUI self extracting .zip/.exe stub, and you can tell it to run a particular command after the extraction. I guess you might use a fancier thing though? That is, are you going to, say, write a gui installer from scratch in Modula-3? It might be a fun exercise. :) And then you could build the self extracting prefix from source etc. This is the hard way I guess, but more interesing. If you can build an msi or use InstallShield or Wix or something, go ahead. If you use widely availabe free as in beer tools, that can be rolled into whatever automation there is to produce distributions, keeping it up to date shouldn't be a problem. I do have to bring up some annoying questions: 1) Does anyone besides me have the capacity to produce distributions? i.e.: Any Win32 machines left at Elego? 2) I know I ramble. So one of my many tangents/questions went unanswered. Say, in the absence of a gui installer, should .zips/.tar.bz files look like cm3-min-/bin/cm3 or bin/cm3 or cm3/bin/cm3 The last one is more directly usable. The first one is very common. This reminds me though Randy, the distribution I made available was "min", so yeah, like if you are doing any gui programming, using any "standard" library besides m3core or libm3, you'd need to build more from source. I can readily provide you a "std" distribution though. It's "always" been a "problem" to make my files available -- no web site hosting for me -- but recently that wasn't a problem, someone picked the files out of ~jkrell on birch and put them on the web site. Good. One more thing -- Olaf, please confirm repeat yourself, 'cause I admit I wasn't sure it was the right thing, but if you insist, ok. "std" should be "all"? I should not continue to imagine there is a new larger group called "all"? And wherever things are missing from std but do build ok, add them? m3cc should be in std? (I admit some big indecisiveness around m3cc. It is far and away the longest thing to build and so the one you really want to skip the most and leave out of whatever package group. I also wonder if on Windows, there should be some check where if sh is not in the $PATH, just silently skip m3cc? You only need MingWin to build what I have on my system for NT386GNU, except you also need msys just for m3cc. msys is actually quite small, like only 20 files..) Oh, sorry, yet another question. The non-gcc backend is excluded from the build on systems that use the gcc backend. For minimization, that is appropriate. For maximizing cross build capability, it is wrong. The packages build fine. I suspect they work. I am not a user of cross build capability yet, so I don't really care. (What I do for NT386/NT386GNU /might/ be considered sort of a cross build, but it is different/easier). They are small packages. - Jay Date: Wed, 16 Jan 2008 08:25:49 -0500 From: rcoleburn at scires.com To: m3devel at elegosoft.com; jayk123 at hotmail.com Subject: Re: [M3devel] my status on win32 Jay: There is no line in the m3makefile dealing with datefn, so I added the whole statement just before the line include("version.quake") Now, I get an error saying that the variable datefn is not defined. If you change to put quotes around datefn in the include statement, you get an error saying it can't open the file. You made a reference in one of your earlier posts about trying 5.1.6 or 4.1, but note that I started with your cm3-min-WIN32-NT386-d5.5.0.zip , not the 5.1.6 or 4.1 versions. Thus, using d5.5.0 as a base, I am trying to run your "upgrade.cmd" to rebuild the sources I checked out from CVS. Since this doesn't work "out-of-the-box", again I say this fits into the "Broken #1" category. If I can get this to work, I don't mind putting together a Windows installer program that will install the whole thing. That way, folks won't have to install cygwin just to get CVS so that they can install a working cm3. Folks will need to install the free Microsoft Visual C as a prerequisite, but then that's not too bad. Having an installer program would make cm3 more friendly to Windows folks. The current 16-step method is too laborious and error-prone for the person just getting started and they will not give cm3 a second try. As the cm3 system evolves and new releases are made, we will need to keep the installer program up-to-date and I don't mind doing that. After someone gets familiar with cm3 they might want to delve into some of the scripts for rebuilding the system, but until then, I think the installer program is the way to go. Regards, Randy >>> Jay 1/16/2008 1:01 AM >>> I think I see the problem. in cm3\src\m3makefile, make this change > if not defined("NOW") include(datefn) > end datefn is only created if certain other variables aren't defined, and do-pkg defines them. I don't know why I don't see this. Later. Could be that the Python scripts have a typo and don't define them. I've been using them more than cmd. If the host is NT, "NOW" is either gotten from an updated cm3.exe, or left to "not available". So the initial cm3 built from older cm3 can't report when it was built, but cm3 built from current cm3 can. I need to change that: 1) to be a function for niceness 2) to make it that way for Posix, for any host but I haven't been using Posix as much lately so not testing it. - Jay Date: Tue, 15 Jan 2008 23:55:39 -0500 From: rcoleburn at scires.com To: m3devel at elegosoft.com; jayk123 at hotmail.com Subject: RE: my status on win32 Jay: In the file version.quake, I made the following edit: changed line: local datefn = "../" & TARGET & ".datenow" to: local datefn = ".." & SL & TARGET & ".datenow" This change has the effect of putting a backward slash in the pathname instead of a forward slash, so we get C:\CM3_CVS_SourceTree\m3-sys\cm3\src\..\NT386.datenow So from that perspective, the change seems good. Unfortunately, I still get the error that this file can't be opened. A quick check of C:\CM3_CVS_SourceTree\m3-sys\cm3\NT386 shows that the file .datenow does not exist. Regards, Randy >>> Jay 1/15/2008 11:03 PM >>> That's not too bad really. 1) I'd recommend putting cm3 at the start of the path instead of the end. 2) Just comment out the offending code to make progress. It's not critical. >> C:\CM3_CVS_SourceTree\m3-sys\cm3\src\../NT386.datenow The code is: C:\CM3_CVS_SourceTree\m3-sys\cm3\src\version.quake or such, included by cm3\src\m3makefile. Does the file exist? Does version.quake use "/" or "SL"? If it uses "/", try replacing with SL (and ampersand for string concat). Could be that a newer binary distributions works better with forward slashes. > 4. > 5. > 6. Launch cygwin from desktop icon. Cygwin is only needed for cvs, I think you realize. Could you send me offline the result of just running "set" after running vcvarsall? I'd like to adapt pylib.py to it maybe. (I can start from 5.1.6 and will try 4.1 at some point.) - Jay Date: Tue, 15 Jan 2008 22:52:59 -0500 From: rcoleburn at scires.com To: m3devel at elegosoft.com; jayk123 at hotmail.com Subject: my status on win32 Jay et al: I've listed below the steps I've undertaken to try and build the current sources on Windows XP. I've also attached a text file showing the output I got when trying to build everything using Jay's upgrade.cmd script. Unfortunately, I'm getting a build error (see below). Please advise on how to resolve. STEPS I TOOK: ========= 1. Download Microsoft Visual Studio 2008 Express Edition All-in-One .ISO file and burn to DVD. http://www.microsoft.com/express/download/ 2. Install Microsoft Visual C++ 2008 Express Edition from DVD. 3. Use "Microsoft Update" service to check for updates / service packs. 4. Download cygwin setup program from http://cygwin.com/ 5. Ran cygwin setup.exe program to install cygwin for all users. Under "Devel" category, make certain to select "cvs" for installation. 6. Launch cygwin from desktop icon. 7. In cygwin command shell window, execute following two commands, making sure to give email as password when prompted for login: cvs -d :pserver:anonymous at modula3.elegosoft.com:/usr/cvs login cvs -d :pserver:anonymous at modula3.elegosoft.com:/usr/cvs checkout cm3 8. Moved resulting C:\cygwin\home\rcoleburn\cm3 to C:\CM3_CVS_SourceTree Note that you should replace "rcoleburn" above with your Windows login username. 9. Download cm3-min-WIN32-NT386-d5.5.0.zip and cm3-min-WIN32-NT386-d5.5.0-symbols.zip from http://modula3.elegosoft.com/cm3/download.html 10. Unzipped cm3-min-WIN32-NT386-d5.5.0.zip and stored resulting cm3 folder at C:\cm3 11. Unzipped cm3-min-WIN32-NT386-d5.5.0-symbols.zip and stored resulting symbols folder at C:\cm3\symbols 12. Launch Windows Command Prompt shell. The following steps represent commands executed within this shell. 13. path %path%;c:\cm3\bin 14. "C:\Program Files\Microsoft Visual Studio 9.0\VC\vcvarsall.bat" 15. cd C:\CM3_CVS_SourceTree\scripts\win 16. upgrade.cmd ERROR I'M GETTING: ============= === package C:\CM3_CVS_SourceTree\m3-sys\cm3 === +++ "cm3 -build -DROOT=C:\\CM3_CVS_SourceTree -DCM3_VERSION_TEXT=d5.5.1 -DCM3_V ERSION_NUMBER=050501 -DCM3_LAST_CHANGED=2007-12-30 && cm3 -ship -DROOT=C:\\CM3_C VS_SourceTree -DCM3_VERSION_TEXT=d5.5.1 -DCM3_VERSION_NUMBER=050501 -DCM3_LAST_C HANGED=2007-12-30" +++ --- building in NT386 --- ignoring ..\src\m3overrides "C:\CM3_CVS_SourceTree\m3-sys\cm3\src\version.quake", line 136: quake runtime er ror: unable to open "C:\CM3_CVS_SourceTree\m3-sys\cm3\src\../NT386.datenow" for reading --procedure-- -line- -file--- include -- version_impl 136 C:\CM3_CVS_SourceTree\m3-sys\cm3\src\version.quake include_dir 20 C:\CM3_CVS_SourceTree\m3-sys\cm3\src\m3makefile 8 C:\CM3_CVS_SourceTree\m3-sys\cm3\NT386\m3make.args Fatal Error: package build failed ERROR: "cm3 -build -DROOT=C:\\CM3_CVS_SourceTree -DCM3_VERSION_TEXT=d5.5.1 -DCM 3_VERSION_NUMBER=050501 -DCM3_LAST_CHANGED=2007-12-30 && cm3 -ship -DROOT=C:\\CM 3_CVS_SourceTree -DCM3_VERSION_TEXT=d5.5.1 -DCM3_VERSION_NUMBER=050501 -DCM3_LAS T_CHANGED=2007-12-30" ERROR: cd C:\CM3_CVS_SourceTree\m3-sys\cm3 ERROR: set INSTALLROOT=c:\cm3 Regards, Randy Share life as it happens with the new Windows Live. Start sharing! ( http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_012008 ) Put your friends on the big screen with Windows Vista* + Windows LiveT. Start now! ( http://www.microsoft.com/windows/shop/specialoffers.mspx?ocid=TXT_TAGLM_CPC_MediaCtr_bigscreen_012008 ) Get the power of Windows + Web with the new Windows Live. Get it now! ( http://www.windowslive.com/?ocid=TXT_TAGHM_Wave2_powerofwindows_012008 ) 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 ) -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcoleburn at scires.com Fri Jan 18 17:10:38 2008 From: rcoleburn at scires.com (Randy Coleburn) Date: Fri, 18 Jan 2008 11:10:38 -0500 Subject: [M3devel] new name for "reactor" Message-ID: <4790892B.1E75.00D7.1@scires.com> I thought I should ask for input from the community before finalizing the new name for "reactor." One of the conditions imposed on making the "reactor" source available is that I have to rename the product and remove all trademarked references. Originally, I chose the name "CM3-IDE" for CM3 Integrated Development Environment, but this name isn't very catchy. I thought about possibly using the name "Catalyst" since a catalyst is something used to accelerate a process and "reactor" certainly fits this definition. A brief search on the web turned up a some other uses of the name, but we may not have a problem if we don't try to trademark the name, or perhaps we could differentiate by calling it "CM3-Catalyst" or "M3-Catalyst". For those that don't know, "reactor" uses a web browser to present its interface. It allows you to quickly browse through all of your source code, create new packages, build and run programs, invoke your favorite editor, run tutorials, browse documentation, etc., etc. With the advent of tabbed browsing, it really makes it nice to understand what is going on when examining your code and when writing code it makes it easy to look up interface definitions etc. If anyone has suggestions on the name to use, please let me know. I'd like to finalize the name within the next few days so I can finalize the code for submission to the repository. Regards, Randy Coleburn -------------- next part -------------- An HTML attachment was scrubbed... URL: From lemming at henning-thielemann.de Fri Jan 18 17:50:42 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Fri, 18 Jan 2008 17:50:42 +0100 (MET) Subject: [M3devel] new name for "reactor" In-Reply-To: <4790892B.1E75.00D7.1@scires.com> References: <4790892B.1E75.00D7.1@scires.com> Message-ID: On Fri, 18 Jan 2008, Randy Coleburn wrote: > I thought about possibly using the name "Catalyst" since a catalyst is > something used to accelerate a process and "reactor" certainly fits this > definition. A brief search on the web turned up a some other uses of > the name, but we may not have a problem if we don't try to trademark the > name, or perhaps we could differentiate by calling it "CM3-Catalyst" or > "M3-Catalyst". I like the name. From jayk123 at hotmail.com Fri Jan 18 22:50:23 2008 From: jayk123 at hotmail.com (Jay) Date: Fri, 18 Jan 2008 21:50:23 +0000 Subject: [M3devel] my status on win32 In-Reply-To: <47908659.1E75.00D7.1@scires.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> <477EA137.1E75.00D7.1@scires.com> <478D394B.1E75.00D7.1@scires.com> <478D47FB.1E75.00D7.1@scires.com> <478DBF8D.1E75.00D7.1@scires.com> <478DE973.1E75.00D7.1@scires.com> <47908659.1E75.00D7.1@scires.com> Message-ID: I'll see about adding usage statements. Basically all the do* scripts accept a "command" and a list of packages. The commands are: realclean clean -- pretty useless imho buildlocal -- the default ship buildship -- build and shpi buildglobal The .sh and .py have a usage explaining this but .cmd is missing it, probably because I didn't fully understand at the time the functionality of the code I was blindy porting. do-* except for do-pkg have an implied list of packages. Maybe you can add to it, would have to check the source. do-pkg requires a list. Most of the rest are not meant to be user-callable -- sysinfo, pkginfo, pkgcmds. make-dist its its own thing. Oh, right -- environment variables. Many things are overridable with them, and need documentation the same. What do folks think of deleting all of scripts\win and having only scripts\python? I guess you have to try them out first, at least.Scripts\python achieves parity pretty much, except for the more logging to files, less logging to the console, that win\make-dist has. Furthermore, out on a limb, what do folks think of deleting most of scripts\*.sh and having just Python? I doubt this will fly and I will try resist mentioning it often. :) In the interest of consensus here, though I doubt it will help, I'd be open to rewriting python in Perl, or possiby even Tcl. I am also willing/interested in discussing the merits of these languages, or an as yet undeveloped one "ideal language" (Modula-3 I don't think is it, sorry), but probably most people will find it a waste of time. Where is the geek-out-really-badly mailing list? :) - Jay Date: Fri, 18 Jan 2008 10:58:36 -0500From: rcoleburn at scires.comTo: m3devel at elegosoft.com; jayk123 at hotmail.comSubject: Re: [M3devel] my status on win32 Jay: Ok. It will be later tonight before I can try again. Thanks! BTW, can you point me to a document/file somewhere that describes the various options for your windows command file scripts? I did experiment further with using the do-cm3-std.cmd and was finally able to get most everything to build, but of course this doesn't rebuild the compiler and core. Had problems with mentor and m3zume not wanting to build/run, so I commented these out in the cmd file to get it to work. Then I had trouble because everything was built with overrides by default, so I had to mess around with changing parameters and rebuilding clean. I've tried building some of my programs and, of course, have run into a few problems due to changes in the system. I've overcome most of these, but I am seeing some strange behavior: 1. pixmaps aren't rendered properly on the screen. They look really bad. I recall having this problem a while back with one of the early 5.x releases, so I guess it was never solved. I've got some old test programs I try to dig out and see if I can find out what is going on. I seem to recall that building standalone in the past seemed to fix the problem, so this is a real mystery. 2. I'm having trouble with bundles not returning all of the data. In the "reactor" program, bundles are used to provide input to the web browser for the page source. I'm seeing cases where not all of the HTML source is making it to the browser. Not sure if this is an I/O problem (maybe buffers not flushed) or if it is something else. It may be that this problem has some impact on #1 above because pixmaps are sometimes stored in the bundles. For the above #1 and #2, these things worked properly on cm3 v4.1. I have the sources to 4.1, so maybe I can use them to figure out what is wrong. On a side note, I found and fixed a major bug in the "reactor" program, so that is good. Now, for another topic that we should probably move to a new email thread: Back in the early days, my company paid Critical Mass, Inc., to customize the Trestle/FormsVBT look and feel to more closely resemble Windows. I have the sources for this work, but of course it is based on v4.1 and the repository code has moved on since then. I am curious if anyone would be interested in me trying to integrate these customizations back into the current source tree, perhaps on a different branch? If we go this route, I may need a little refresher tutorial on the use of branches in CVS. We would want to make it so that the main branch and the customized branch could evolve in sync. That is, if a bug was found in either branch, the fix should be incorporated into both. Regards, Randy>>> Jay 1/18/2008 10:32 AM >>>Randy, please try with an updated m3-sys/cm3/src/version.quake and report back, thanks.I understand why I wasn't seeing this. - Jay Date: Wed, 16 Jan 2008 11:24:34 -0500From: rcoleburn at scires.comTo: m3devel at elegosoft.com; jayk123 at hotmail.comSubject: Re: [M3devel] my status on win32 Jay: Not sure I've clued in to all of your dialog. Sorry. I have in the past used a free tool to build an installer package and I was thinking of using it again. Since the tool is free, we could put all the work I do into the CVS repository so that others could also maintain it. What I am looking to achieve is to have a way where a "normal" Windows user could download a program, run it, and have all of the cm3 packages installed without having to use the MIN distribution to build it up or any other tools to get the sources (like cvs). You could achieve the same thing by having a big ZIP file also I suppose, but having the installer would also let us easily put something in the start menu to launch a command line with all the environment variables set properly via automatic call to vcvars et al. When I get "Reactor" working, it too could be put into the start menu. That just makes it fit in better with the Windows user culture I think. The reason I wanted to rebuild everything is two-fold: 1) ensure it can be done (i.e., test for "Broken #1"), and 2) get all of the rest of the packages built so I could then use cm3 to build "reactor" and my own programs and test them to see if there are any "Broken #2" issues. The MIN distribution is really insufficient to do much of anything except to build the rest of the packages you need. My understanding is that I needed to use CVS to get the current sources, because if I went back to the source archive, it was old and known to be Broken #1 on Windows. I'm glad that you believe the current "Broken #1" situation is easy to fix. Let me know what to do and I'll give it another try. My experience in the past has been that there are 3 conditions to getting cm3 to work properly on windows after it has been installed: 1) make sure your environment variables are set up by vcvars to point to the compiler/linker/libraries (of course if you used a non-Microsoft C compiler/linker you would need to use something other than vcvars); 2) make sure cm3.cfg has the right paths in place to find all the libraries and tools using DOS style short names (no embedded spaces); and 3) make sure C:\cm3\bin is in your path. Of these, #2 & #3 are essentially one-time events, and #1 can be set up by a invoking a batch/command file via a shortcut, so no big deal for me. You could even make #1 a one-time event by modifying the system-level (vice user-level) environment variables. The old cm3install program seemed to do a decent job of #2 for me. Also, I've noted some of your past dialog about accepting either '/' or '\' as a path separator. I'm sure you are aware that on Windows '/' is used often for switches (arguments). Plus Windows also allows spaces to be embedded in the command line, so whatever solution you propose needs to take into account that a valid command line might look like this: C:\My Program Folder\My Program.exe /myArg1 /myArg2 In some situations, this command line would have to be quoted and rendered as: "C:\My Program Folder\My Program.exe" /myArg1 /myArg2 and in places where the backslash is an escape character, I've seen "C:\\My Program Folder\\My Program.exe" /myArg1 /myArg2 Alas, I seem to have rambled a bit also. Sorry. The immediate need for me now is to solve the Broken #1 condition, so please let me know how to fix it and proceed. Regards, Randy>>> Jay 1/16/2008 10:28 AM >>>Randy, yes and no and clarifications. I mention starting with 5.1.6 as a "worst" or "worse" case.The earlier you start, the harder things are -- for me, to ensure it will work. If you merely start with my 5.5.0, well, what are you rebuilding from source for?Heck, you can use any binary distribution, 4.1, 5.1.6, and just use it. They should work. The n steps you/I give are really actually geared for people who WANT to build from source, it is not what people HAVE to do.As well there have been can be source distributions, to cut out CVS. I'll look into the datefn stuff shortly. As to the installer, well, again, yes and no.The need for the installer is very small. All you have to do today is unzip the .zip somewhere and set the path, and possibly the vcvars thing. That's it. I should..now that you are "pressuring" me for ease of use, teach cm3 about the various ?venvdir%, %vcinstalldir% variables, etc. That way as long as the user installed the tools, even if they elected not to change path/lib/include, cm3 can find the compiler and linker. I know everyone wants to preserve the flexibility of quake/cm3.cfg but...besides, cm3 can be pretty darn smart here. IF cm3.cfg defines SYSTEM_CC, leave things along (NT386 cm3.cfg does not today do that). However if there is now SYSTEM_CC and there is no cl.exe/link.exe in %PATH%, it could go on a quick hunt for them. On the lib and include part, well, the dependency on %include% might only be for errno..maybe not worth it. It has been whatever it is forever, like int* _errno(void); #define errno (*_errno)()). Modula-3 engages in rampant header cloning and CErrnoC was only introduced where that was deemed more fragile than usual, and for Windows it probably wasn't actually fragile -- the fragility, if I may be so rudely judgemental, is because so many other systems are so Johnny-come-lately to arriving at the obviously correct threading model that Windows has had all along (since Win95/NT, can't say anything good about Win3.1; I think OS/2 might have had it correct all along too.). Funny, everyone has FINALLY arrived at the correct threading model, only to have start changing again, since the number of cores and machines is set to be much greater than anticipated, the obvious threading model has been deemed too difficult for anyone to use (Win32, Modula-3, Java, .NET, Python, all the same supposedly too difficult model btw), and so some new one is needed, and well, truthfully, the difficulty is not just for dummies on relatively small multiproc boxes not having simple race conditions, the problem is scaling way way up. Sorry that was my usual tangential. Even the unzip and set path would benefit slightly from a GUI installer.I believe there is some easy thing you can do where you write your GUI installer and you put it in the .zip and then you prepend the GUI self extracting .zip/.exe stub, and you can tell it to run a particular command after the extraction. I guess you might use a fancier thing though?That is, are you going to, say, write a gui installer from scratch in Modula-3? It might be a fun exercise. :)And then you could build the self extracting prefix from source etc.This is the hard way I guess, but more interesing.If you can build an msi or use InstallShield or Wix or something, go ahead.If you use widely availabe free as in beer tools, that can be rolled into whatever automation there is to produce distributions, keeping it up to date shouldn't be a problem. I do have to bring up some annoying questions: 1) Does anyone besides me have the capacity to produce distributions? i.e.: Any Win32 machines left at Elego? 2) I know I ramble. So one of my many tangents/questions went unanswered.Say, in the absence of a gui installer, should .zips/.tar.bz files look like cm3-min-/bin/cm3orbin/cm3orcm3/bin/cm3 The last one is more directly usable. The first one is very common. This reminds me though Randy, the distribution I made available was "min", so yeah, like if you are doing any gui programming, using any "standard" library besides m3core or libm3, you'd need to build more from source. I can readily provide you a "std" distribution though.It's "always" been a "problem" to make my files available -- no web site hosting for me -- but recently that wasn't a problem, someone picked the files out of ~jkrell on birch and put them on the web site. Good. One more thing -- Olaf, please confirm repeat yourself, 'cause I admit I wasn't sure it was the right thing, but if you insist, ok. "std" should be "all"? I should not continue to imagine there is a new larger group called "all"? And wherever things are missing from std but do build ok, add them?m3cc should be in std?(I admit some big indecisiveness around m3cc. It is far and away the longest thing to build and so the one you really want to skip the most and leave out of whatever package group. I also wonder if on Windows, there should be some check where if sh is not in the $PATH, just silently skip m3cc? You only need MingWin to build what I have on my system for NT386GNU, except you also need msys just for m3cc. msys is actually quite small, like only 20 files..) Oh, sorry, yet another question.The non-gcc backend is excluded from the build on systems that use the gcc backend.For minimization, that is appropriate.For maximizing cross build capability, it is wrong.The packages build fine. I suspect they work.I am not a user of cross build capability yet, so I don't really care. (What I do for NT386/NT386GNU /might/ be considered sort of a cross build, but it is different/easier).They are small packages. - Jay Date: Wed, 16 Jan 2008 08:25:49 -0500From: rcoleburn at scires.comTo: m3devel at elegosoft.com; jayk123 at hotmail.comSubject: Re: [M3devel] my status on win32 Jay: There is no line in the m3makefile dealing with datefn, so I added the whole statement just before the line include("version.quake") Now, I get an error saying that the variable datefn is not defined. If you change to put quotes around datefn in the include statement, you get an error saying it can't open the file. You made a reference in one of your earlier posts about trying 5.1.6 or 4.1, but note that I started with your cm3-min-WIN32-NT386-d5.5.0.zip , not the 5.1.6 or 4.1 versions. Thus, using d5.5.0 as a base, I am trying to run your "upgrade.cmd" to rebuild the sources I checked out from CVS. Since this doesn't work "out-of-the-box", again I say this fits into the "Broken #1" category. If I can get this to work, I don't mind putting together a Windows installer program that will install the whole thing. That way, folks won't have to install cygwin just to get CVS so that they can install a working cm3. Folks will need to install the free Microsoft Visual C as a prerequisite, but then that's not too bad. Having an installer program would make cm3 more friendly to Windows folks. The current 16-step method is too laborious and error-prone for the person just getting started and they will not give cm3 a second try. As the cm3 system evolves and new releases are made, we will need to keep the installer program up-to-date and I don't mind doing that. After someone gets familiar with cm3 they might want to delve into some of the scripts for rebuilding the system, but until then, I think the installer program is the way to go. Regards, Randy>>> Jay 1/16/2008 1:01 AM >>>I think I see the problem. in cm3\src\m3makefile, make this change > if not defined("NOW") include(datefn) > end datefn is only created if certain other variables aren't defined, and do-pkg defines them.I don't know why I don't see this. Later.Could be that the Python scripts have a typo and don't define them.I've been using them more than cmd. If the host is NT, "NOW" is either gotten from an updated cm3.exe, or left to "not available". So the initial cm3 built from older cm3 can't report when it was built, but cm3 built from current cm3 can. I need to change that: 1) to be a function for niceness 2) to make it that way for Posix, for any host but I haven't been using Posix as much lately so not testing it. - Jay Date: Tue, 15 Jan 2008 23:55:39 -0500From: rcoleburn at scires.comTo: m3devel at elegosoft.com; jayk123 at hotmail.comSubject: RE: my status on win32 Jay: In the file version.quake, I made the following edit: changed line: local datefn = "../" & TARGET & ".datenow" to: local datefn = ".." & SL & TARGET & ".datenow" This change has the effect of putting a backward slash in the pathname instead of a forward slash, so we getC:\CM3_CVS_SourceTree\m3-sys\cm3\src\..\NT386.datenow So from that perspective, the change seems good. Unfortunately, I still get the error that this file can't be opened. A quick check of C:\CM3_CVS_SourceTree\m3-sys\cm3\NT386 shows that the file .datenow does not exist. Regards, Randy>>> Jay 1/15/2008 11:03 PM >>>That's not too bad really. 1) I'd recommend putting cm3 at the start of the path instead of the end. 2) Just comment out the offending code to make progress. It's not critical. >> C:\CM3_CVS_SourceTree\m3-sys\cm3\src\../NT386.datenow The code is: C:\CM3_CVS_SourceTree\m3-sys\cm3\src\version.quake or such, included by cm3\src\m3makefile. Does the file exist?Does version.quake use "/" or "SL"? If it uses "/", try replacing with SL (and ampersand for string concat). Could be that a newer binary distributions works better with forward slashes. > 4. > 5. > 6. Launch cygwin from desktop icon. Cygwin is only needed for cvs, I think you realize. Could you send me offline the result of just running "set" after running vcvarsall? I'd like to adapt pylib.py to it maybe. (I can start from 5.1.6 and will try 4.1 at some point.) - Jay Date: Tue, 15 Jan 2008 22:52:59 -0500From: rcoleburn at scires.comTo: m3devel at elegosoft.com; jayk123 at hotmail.comSubject: my status on win32 Jay et al: I've listed below the steps I've undertaken to try and build the current sources on Windows XP. I've also attached a text file showing the output I got when trying to build everything using Jay's upgrade.cmd script. Unfortunately, I'm getting a build error (see below). Please advise on how to resolve. STEPS I TOOK: ========= 1. Download Microsoft Visual Studio 2008 Express Edition All-in-One .ISO file and burn to DVD. http://www.microsoft.com/express/download/ 2. Install Microsoft Visual C++ 2008 Express Edition from DVD. 3. Use "Microsoft Update" service to check for updates / service packs. 4. Download cygwin setup program from http://cygwin.com/ 5. Ran cygwin setup.exe program to install cygwin for all users. Under "Devel" category, make certain to select "cvs" for installation. 6. Launch cygwin from desktop icon. 7. In cygwin command shell window, execute following two commands, making sure to give email as password when prompted for login: cvs -d :pserver:anonymous at modula3.elegosoft.com:/usr/cvs login cvs -d :pserver:anonymous at modula3.elegosoft.com:/usr/cvs checkout cm3 8. Moved resulting C:\cygwin\home\rcoleburn\cm3 to C:\CM3_CVS_SourceTree Note that you should replace "rcoleburn" above with your Windows login username. 9. Download cm3-min-WIN32-NT386-d5.5.0.zip and cm3-min-WIN32-NT386-d5.5.0-symbols.zip from http://modula3.elegosoft.com/cm3/download.html 10. Unzipped cm3-min-WIN32-NT386-d5.5.0.zip and stored resulting cm3 folder at C:\cm3 11. Unzipped cm3-min-WIN32-NT386-d5.5.0-symbols.zip and stored resulting symbols folder at C:\cm3\symbols 12. Launch Windows Command Prompt shell. The following steps represent commands executed within this shell. 13. path %path%;c:\cm3\bin 14. "C:\Program Files\Microsoft Visual Studio 9.0\VC\vcvarsall.bat" 15. cd C:\CM3_CVS_SourceTree\scripts\win 16. upgrade.cmd ERROR I'M GETTING: ============= === package C:\CM3_CVS_SourceTree\m3-sys\cm3 ===+++ "cm3 -build -DROOT=C:\\CM3_CVS_SourceTree -DCM3_VERSION_TEXT=d5.5.1 -DCM3_VERSION_NUMBER=050501 -DCM3_LAST_CHANGED=2007-12-30 && cm3 -ship -DROOT=C:\\CM3_CVS_SourceTree -DCM3_VERSION_TEXT=d5.5.1 -DCM3_VERSION_NUMBER=050501 -DCM3_LAST_CHANGED=2007-12-30" +++--- building in NT386 --- ignoring ..\src\m3overrides "C:\CM3_CVS_SourceTree\m3-sys\cm3\src\version.quake", line 136: quake runtime error: unable to open "C:\CM3_CVS_SourceTree\m3-sys\cm3\src\../NT386.datenow" forreading --procedure-- -line- -file---include -- version_impl 136 C:\CM3_CVS_SourceTree\m3-sys\cm3\src\version.quakeinclude_dir 20 C:\CM3_CVS_SourceTree\m3-sys\cm3\src\m3makefile 8 C:\CM3_CVS_SourceTree\m3-sys\cm3\NT386\m3make.args Fatal Error: package build failedERROR: "cm3 -build -DROOT=C:\\CM3_CVS_SourceTree -DCM3_VERSION_TEXT=d5.5.1 -DCM3_VERSION_NUMBER=050501 -DCM3_LAST_CHANGED=2007-12-30 && cm3 -ship -DROOT=C:\\CM3_CVS_SourceTree -DCM3_VERSION_TEXT=d5.5.1 -DCM3_VERSION_NUMBER=050501 -DCM3_LAST_CHANGED=2007-12-30"ERROR: cd C:\CM3_CVS_SourceTree\m3-sys\cm3ERROR: set INSTALLROOT=c:\cm3 Regards, Randy Share life as it happens with the new Windows Live. Start sharing! Put your friends on the big screen with Windows Vista? + Windows LiveT. Start now! Get the power of Windows + Web with the new Windows Live. Get it now! 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 jayk123 at hotmail.com Fri Jan 18 23:28:14 2008 From: jayk123 at hotmail.com (Jay) Date: Fri, 18 Jan 2008 22:28:14 +0000 Subject: [M3devel] incremental build always rebuilds cm3, never produces the same thing -- what time is "now"? In-Reply-To: <47908659.1E75.00D7.1@scires.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> <477EA137.1E75.00D7.1@scires.com> <478D394B.1E75.00D7.1@scires.com> <478D47FB.1E75.00D7.1@scires.com> <478DBF8D.1E75.00D7.1@scires.com> <478DE973.1E75.00D7.1@scires.com> <47908659.1E75.00D7.1@scires.com> Message-ID: In m3-sys\cm3, incremental build always rebuilds cm3, never produces the same thing. I know exactly why. My modification to Olaf's timestamping (which I think he approved, but perhaps didn't realize this outcome). Because we generate a source file with the current time, and it always changes. Is this ok with people?I know it has downsides, but it might be ok. You know: 1) incremental build should really never do anything, never writing anything, fast which is important -- never write, or be fast? both? 2) You might want to compare two full builds and determine they are identical; the less of this sort of thing the better If not, what do people suggest for a way to determine when to update the time? The logic before I think was essentially never, unless you went and deleted a specific file. Perhaps that is right, once it is discovered and publicized. Perhaps another output directory is needed -- say / -- that upgrade and make-dist, perhaps, know to delete, and maybe realclean...of cm3? deletes? Hey, maybe just declare an output, with "..", in the m3makefile, so merely clean and realclean update the time, but incremental builds do not? This seems obviously the way to go right now, but still slightly debatable. Like, maybe an accurate timestamp is needed. Maybe if any other source or .lib changes, the timestamp should change -- so, like, m3_back/m3_link could regenerate the file, except that might be too late. Should "now" be less granular than a second? That mitigates the problem but i think is not satisfactory.Should "now" be overridable on the command line or with an environment variable? - 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 Fri Jan 18 23:42:26 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 18 Jan 2008 23:42:26 +0100 Subject: [M3devel] my status on win32 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> <477EA137.1E75.00D7.1@scires.com> <478D394B.1E75.00D7.1@scires.com> <478D47FB.1E75.00D7.1@scires.com> <478DBF8D.1E75.00D7.1@scires.com> <478DE973.1E75.00D7.1@scires.com> <47908659.1E75.00D7.1@scires.com> Message-ID: <20080118234226.8g4fi0mkgwgscwww@mail.elegosoft.com> Quoting Jay : > I'll see about adding usage statements. > Basically all the do* scripts accept a "command" and a list of packages. > The commands are: > realclean > clean -- pretty useless imho > buildlocal -- the default > ship > buildship -- build and shpi > buildglobal Actually, the more useful commands are build -- build with overrides to ROOT buildship (same as buildglobal) -- build with global package pool realclean -- completely delete derived target files > do-pkg requires a list. If you're doing you're own project, this may be what is most useful -- if you use the scripts at all. > What do folks think of deleting all of scripts\win and having only > scripts\python? > I guess you have to try them out first, at least.Scripts\python > achieves parity pretty much, except for the more logging to files, > less logging to the console, that win\make-dist has. > > Furthermore, out on a limb, what do folks think of deleting most of > scripts\*.sh and having just Python? I'd object to this. Shell is POSIX standard, and most of the infrastructure is built on it; Python is nice to have, but should not be a prerequisite to CM3. > I doubt this will fly and I will try resist mentioning it often. :) > In the interest of consensus here, though I doubt it will help, I'd > be open to rewriting python in Perl, or possiby even Tcl. Why? > I am also willing/interested in discussing the merits of these > languages, or an as yet undeveloped one "ideal language" (Modula-3 I > don't think is it, sorry), but probably most people will find it a > waste of time. Where is the geek-out-really-badly mailing list? :) I don't see the point in rewriting the scripts in yet other languages. The purpose of the scripts is to support the installation, administration and maintenance of the CM3 distribution. They were not intended as a general purpose build or automation environment, though they can be used for this purpose to a certain extent. But the main point is that they are useful for the people maintaining the distribution. We could think about rewriting everything in M3 to further reduce the system dependencies, but this would not be as flexible as a general scripting language. Quake would need to be substantially extended, and Python is nice, but a huge software distribution in itself, that should be independent of CM3. POSIX shell is the one common interpreter I have found to be available on almost all systems. (Even when we were programming point-of-sale solutions on DOS in the early 90s we had ksh and other POSIX tools there to emulate the Sun development environment we used on the servers.) OK, on Windows you have to install it (e.g. in form of Cygwin) like Python, but it's still the best choice wrt. availability and portability I've found. For general discussions of the advantages and disadvantage of programming languages, some of the comp.lang.* newsgroups may be the better choice, though I haven't read them for years now and don't know if they're still alive. As for the ideal language -- I don't think that there is any language that could claim this. The advantages and disadvantages depend heavily on the usage context, environment, and skills and understanding of the programmers. (M3 is pretty good 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 rcoleburn at scires.com Fri Jan 18 23:53:45 2008 From: rcoleburn at scires.com (Randy Coleburn) Date: Fri, 18 Jan 2008 17:53:45 -0500 Subject: [M3devel] my status on win32 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> <477EA137.1E75.00D7.1@scires.com> <478D394B.1E75.00D7.1@scires.com> <478D47FB.1E75.00D7.1@scires.com> <478DBF8D.1E75.00D7.1@scires.com> <478DE973.1E75.00D7.1@scires.com> <47908659.1E75.00D7.1@scires.com> Message-ID: <4790E7A7.1E75.00D7.1@scires.com> Jay: What does "buildglobal" mean? How is it different from "buildship"? As far as "scripts" go, I'm an old guy that started out with computers that had real core memory. When the IBM PC revolution hit, I was already a professional and had mastered large computers with network operating systems and even micro-computers with CP/M. I learned DOS and became a good "BAT" batch file programmer (we didn't call them scripting languages back then). I'm still pretty good with Windows CMD files, but have not tackled python. My vote for cm3 on Windows is to avoid making the end user (customer) have to learn or acquire things that aren't native to his environment. Thus, I would argue for use of CMD files on Windows instead of some other scripting language. This same reasoning is why I was pushing for the all-in-one installation program for cm3 on Windows. If all a "Windows person" has to do to get cm3 modula-3 up and running on his box is to run an install program and possibly tweak a few CMD scripts to his/her liking, then it is "easy". Forcing acquisition and installation of other tools/environments just to get started makes things complicated and increases the barrier to startup and acceptance. Just my 2 cents worth. A few years ago, I contributed some BAT/CMD files that could be used to build the entire system on Windows. The only issue is that as the system evolves, you have to keep the package build order up to date. I don't mind trying to help out further in this area. You seem to be very technically capable, so perhaps what I can offer pales in comparison. Thanks for all you are doing. Let me know if/how I can help. Regards, Randy >>> Jay 1/18/2008 4:50 PM >>> I'll see about adding usage statements. Basically all the do* scripts accept a "command" and a list of packages. The commands are: realclean clean -- pretty useless imho buildlocal -- the default ship buildship -- build and shpi buildglobal The .sh and .py have a usage explaining this but .cmd is missing it, probably because I didn't fully understand at the time the functionality of the code I was blindy porting. do-* except for do-pkg have an implied list of packages. Maybe you can add to it, would have to check the source. do-pkg requires a list. Most of the rest are not meant to be user-callable -- sysinfo, pkginfo, pkgcmds. make-dist its its own thing. Oh, right -- environment variables. Many things are overridable with them, and need documentation the same. What do folks think of deleting all of scripts\win and having only scripts\python? I guess you have to try them out first, at least. Scripts\python achieves parity pretty much, except for the more logging to files, less logging to the console, that win\make-dist has. Furthermore, out on a limb, what do folks think of deleting most of scripts\*.sh and having just Python? I doubt this will fly and I will try resist mentioning it often. :) In the interest of consensus here, though I doubt it will help, I'd be open to rewriting python in Perl, or possiby even Tcl. I am also willing/interested in discussing the merits of these languages, or an as yet undeveloped one "ideal language" (Modula-3 I don't think is it, sorry), but probably most people will find it a waste of time. Where is the geek-out-really-badly mailing list? :) - Jay Date: Fri, 18 Jan 2008 10:58:36 -0500 From: rcoleburn at scires.com To: m3devel at elegosoft.com; jayk123 at hotmail.com Subject: Re: [M3devel] my status on win32 Jay: Ok. It will be later tonight before I can try again. Thanks! BTW, can you point me to a document/file somewhere that describes the various options for your windows command file scripts? I did experiment further with using the do-cm3-std.cmd and was finally able to get most everything to build, but of course this doesn't rebuild the compiler and core. Had problems with mentor and m3zume not wanting to build/run, so I commented these out in the cmd file to get it to work. Then I had trouble because everything was built with overrides by default, so I had to mess around with changing parameters and rebuilding clean. I've tried building some of my programs and, of course, have run into a few problems due to changes in the system. I've overcome most of these, but I am seeing some strange behavior: 1. pixmaps aren't rendered properly on the screen. They look really bad. I recall having this problem a while back with one of the early 5.x releases, so I guess it was never solved. I've got some old test programs I try to dig out and see if I can find out what is going on. I seem to recall that building standalone in the past seemed to fix the problem, so this is a real mystery. 2. I'm having trouble with bundles not returning all of the data. In the "reactor" program, bundles are used to provide input to the web browser for the page source. I'm seeing cases where not all of the HTML source is making it to the browser. Not sure if this is an I/O problem (maybe buffers not flushed) or if it is something else. It may be that this problem has some impact on #1 above because pixmaps are sometimes stored in the bundles. For the above #1 and #2, these things worked properly on cm3 v4.1. I have the sources to 4.1, so maybe I can use them to figure out what is wrong. On a side note, I found and fixed a major bug in the "reactor" program, so that is good. Now, for another topic that we should probably move to a new email thread: Back in the early days, my company paid Critical Mass, Inc., to customize the Trestle/FormsVBT look and feel to more closely resemble Windows. I have the sources for this work, but of course it is based on v4.1 and the repository code has moved on since then. I am curious if anyone would be interested in me trying to integrate these customizations back into the current source tree, perhaps on a different branch? If we go this route, I may need a little refresher tutorial on the use of branches in CVS. We would want to make it so that the main branch and the customized branch could evolve in sync. That is, if a bug was found in either branch, the fix should be incorporated into both. Regards, Randy >>> Jay 1/18/2008 10:32 AM >>> Randy, please try with an updated m3-sys/cm3/src/version.quake and report back, thanks. I understand why I wasn't seeing this. - Jay Date: Wed, 16 Jan 2008 11:24:34 -0500 From: rcoleburn at scires.com To: m3devel at elegosoft.com; jayk123 at hotmail.com Subject: Re: [M3devel] my status on win32 Jay: Not sure I've clued in to all of your dialog. Sorry. I have in the past used a free tool to build an installer package and I was thinking of using it again. Since the tool is free, we could put all the work I do into the CVS repository so that others could also maintain it. What I am looking to achieve is to have a way where a "normal" Windows user could download a program, run it, and have all of the cm3 packages installed without having to use the MIN distribution to build it up or any other tools to get the sources (like cvs). You could achieve the same thing by having a big ZIP file also I suppose, but having the installer would also let us easily put something in the start menu to launch a command line with all the environment variables set properly via automatic call to vcvars et al. When I get "Reactor" working, it too could be put into the start menu. That just makes it fit in better with the Windows user culture I think. The reason I wanted to rebuild everything is two-fold: 1) ensure it can be done (i.e., test for "Broken #1"), and 2) get all of the rest of the packages built so I could then use cm3 to build "reactor" and my own programs and test them to see if there are any "Broken #2" issues. The MIN distribution is really insufficient to do much of anything except to build the rest of the packages you need. My understanding is that I needed to use CVS to get the current sources, because if I went back to the source archive, it was old and known to be Broken #1 on Windows. I'm glad that you believe the current "Broken #1" situation is easy to fix. Let me know what to do and I'll give it another try. My experience in the past has been that there are 3 conditions to getting cm3 to work properly on windows after it has been installed: 1) make sure your environment variables are set up by vcvars to point to the compiler/linker/libraries (of course if you used a non-Microsoft C compiler/linker you would need to use something other than vcvars); 2) make sure cm3.cfg has the right paths in place to find all the libraries and tools using DOS style short names (no embedded spaces); and 3) make sure C:\cm3\bin is in your path. Of these, #2 & #3 are essentially one-time events, and #1 can be set up by a invoking a batch/command file via a shortcut, so no big deal for me. You could even make #1 a one-time event by modifying the system-level (vice user-level) environment variables. The old cm3install program seemed to do a decent job of #2 for me. Also, I've noted some of your past dialog about accepting either '/' or '\' as a path separator. I'm sure you are aware that on Windows '/' is used often for switches (arguments). Plus Windows also allows spaces to be embedded in the command line, so whatever solution you propose needs to take into account that a valid command line might look like this: C:\My Program Folder\My Program.exe /myArg1 /myArg2 In some situations, this command line would have to be quoted and rendered as: "C:\My Program Folder\My Program.exe" /myArg1 /myArg2 and in places where the backslash is an escape character, I've seen "C:\\My Program Folder\\My Program.exe" /myArg1 /myArg2 Alas, I seem to have rambled a bit also. Sorry. The immediate need for me now is to solve the Broken #1 condition, so please let me know how to fix it and proceed. Regards, Randy >>> Jay 1/16/2008 10:28 AM >>> Randy, yes and no and clarifications. I mention starting with 5.1.6 as a "worst" or "worse" case. The earlier you start, the harder things are -- for me, to ensure it will work. If you merely start with my 5.5.0, well, what are you rebuilding from source for? Heck, you can use any binary distribution, 4.1, 5.1.6, and just use it. They should work. The n steps you/I give are really actually geared for people who WANT to build from source, it is not what people HAVE to do. As well there have been can be source distributions, to cut out CVS. I'll look into the datefn stuff shortly. As to the installer, well, again, yes and no. The need for the installer is very small. All you have to do today is unzip the .zip somewhere and set the path, and possibly the vcvars thing. That's it. I should..now that you are "pressuring" me for ease of use, teach cm3 about the various ?venvdir%, %vcinstalldir% variables, etc. That way as long as the user installed the tools, even if they elected not to change path/lib/include, cm3 can find the compiler and linker. I know everyone wants to preserve the flexibility of quake/cm3.cfg but...besides, cm3 can be pretty darn smart here. IF cm3.cfg defines SYSTEM_CC, leave things along (NT386 cm3.cfg does not today do that). However if there is now SYSTEM_CC and there is no cl.exe/link.exe in %PATH%, it could go on a quick hunt for them. On the lib and include part, well, the dependency on %include% might only be for errno..maybe not worth it. It has been whatever it is forever, like int* _errno(void); #define errno (*_errno)()). Modula-3 engages in rampant header cloning and CErrnoC was only introduced where that was deemed more fragile than usual, and for Windows it probably wasn't actually fragile -- the fragility, if I may be so rudely judgemental, is because so many other systems are so Johnny-come-lately to arriving at the obviously correct threading model that Windows has had all along (since Win95/NT, can't say anything good about Win3.1; I think OS/2 might have had it correct all along too.). Funny, everyone has FINALLY arrived at the correct threading model, only to have start changing again, since the number of cores and machines is set to be much greater than anticipated, the obvious threading model has been deemed too difficult for anyone to use (Win32, Modula-3, Java, .NET, Python, all the same supposedly too difficult model btw), and so some new one is needed, and well, truthfully, the difficulty is not just for dummies on relatively small multiproc boxes not having simple race conditions, the problem is scaling way way up. Sorry that was my usual tangential. Even the unzip and set path would benefit slightly from a GUI installer. I believe there is some easy thing you can do where you write your GUI installer and you put it in the .zip and then you prepend the GUI self extracting .zip/.exe stub, and you can tell it to run a particular command after the extraction. I guess you might use a fancier thing though? That is, are you going to, say, write a gui installer from scratch in Modula-3? It might be a fun exercise. :) And then you could build the self extracting prefix from source etc. This is the hard way I guess, but more interesing. If you can build an msi or use InstallShield or Wix or something, go ahead. If you use widely availabe free as in beer tools, that can be rolled into whatever automation there is to produce distributions, keeping it up to date shouldn't be a problem. I do have to bring up some annoying questions: 1) Does anyone besides me have the capacity to produce distributions? i.e.: Any Win32 machines left at Elego? 2) I know I ramble. So one of my many tangents/questions went unanswered. Say, in the absence of a gui installer, should .zips/.tar.bz files look like cm3-min-/bin/cm3 or bin/cm3 or cm3/bin/cm3 The last one is more directly usable. The first one is very common. This reminds me though Randy, the distribution I made available was "min", so yeah, like if you are doing any gui programming, using any "standard" library besides m3core or libm3, you'd need to build more from source. I can readily provide you a "std" distribution though. It's "always" been a "problem" to make my files available -- no web site hosting for me -- but recently that wasn't a problem, someone picked the files out of ~jkrell on birch and put them on the web site. Good. One more thing -- Olaf, please confirm repeat yourself, 'cause I admit I wasn't sure it was the right thing, but if you insist, ok. "std" should be "all"? I should not continue to imagine there is a new larger group called "all"? And wherever things are missing from std but do build ok, add them? m3cc should be in std? (I admit some big indecisiveness around m3cc. It is far and away the longest thing to build and so the one you really want to skip the most and leave out of whatever package group. I also wonder if on Windows, there should be some check where if sh is not in the $PATH, just silently skip m3cc? You only need MingWin to build what I have on my system for NT386GNU, except you also need msys just for m3cc. msys is actually quite small, like only 20 files..) Oh, sorry, yet another question. The non-gcc backend is excluded from the build on systems that use the gcc backend. For minimization, that is appropriate. For maximizing cross build capability, it is wrong. The packages build fine. I suspect they work. I am not a user of cross build capability yet, so I don't really care. (What I do for NT386/NT386GNU /might/ be considered sort of a cross build, but it is different/easier). They are small packages. - Jay Date: Wed, 16 Jan 2008 08:25:49 -0500 From: rcoleburn at scires.com To: m3devel at elegosoft.com; jayk123 at hotmail.com Subject: Re: [M3devel] my status on win32 Jay: There is no line in the m3makefile dealing with datefn, so I added the whole statement just before the line include("version.quake") Now, I get an error saying that the variable datefn is not defined. If you change to put quotes around datefn in the include statement, you get an error saying it can't open the file. You made a reference in one of your earlier posts about trying 5.1.6 or 4.1, but note that I started with your cm3-min-WIN32-NT386-d5.5.0.zip , not the 5.1.6 or 4.1 versions. Thus, using d5.5.0 as a base, I am trying to run your "upgrade.cmd" to rebuild the sources I checked out from CVS. Since this doesn't work "out-of-the-box", again I say this fits into the "Broken #1" category. If I can get this to work, I don't mind putting together a Windows installer program that will install the whole thing. That way, folks won't have to install cygwin just to get CVS so that they can install a working cm3. Folks will need to install the free Microsoft Visual C as a prerequisite, but then that's not too bad. Having an installer program would make cm3 more friendly to Windows folks. The current 16-step method is too laborious and error-prone for the person just getting started and they will not give cm3 a second try. As the cm3 system evolves and new releases are made, we will need to keep the installer program up-to-date and I don't mind doing that. After someone gets familiar with cm3 they might want to delve into some of the scripts for rebuilding the system, but until then, I think the installer program is the way to go. Regards, Randy >>> Jay 1/16/2008 1:01 AM >>> I think I see the problem. in cm3\src\m3makefile, make this change > if not defined("NOW") include(datefn) > end datefn is only created if certain other variables aren't defined, and do-pkg defines them. I don't know why I don't see this. Later. Could be that the Python scripts have a typo and don't define them. I've been using them more than cmd. If the host is NT, "NOW" is either gotten from an updated cm3.exe, or left to "not available". So the initial cm3 built from older cm3 can't report when it was built, but cm3 built from current cm3 can. I need to change that: 1) to be a function for niceness 2) to make it that way for Posix, for any host but I haven't been using Posix as much lately so not testing it. - Jay Date: Tue, 15 Jan 2008 23:55:39 -0500 From: rcoleburn at scires.com To: m3devel at elegosoft.com; jayk123 at hotmail.com Subject: RE: my status on win32 Jay: In the file version.quake, I made the following edit: changed line: local datefn = "../" & TARGET & ".datenow" to: local datefn = ".." & SL & TARGET & ".datenow" This change has the effect of putting a backward slash in the pathname instead of a forward slash, so we get C:\CM3_CVS_SourceTree\m3-sys\cm3\src\..\NT386.datenow So from that perspective, the change seems good. Unfortunately, I still get the error that this file can't be opened. A quick check of C:\CM3_CVS_SourceTree\m3-sys\cm3\NT386 shows that the file .datenow does not exist. Regards, Randy >>> Jay 1/15/2008 11:03 PM >>> That's not too bad really. 1) I'd recommend putting cm3 at the start of the path instead of the end. 2) Just comment out the offending code to make progress. It's not critical. >> C:\CM3_CVS_SourceTree\m3-sys\cm3\src\../NT386.datenow The code is: C:\CM3_CVS_SourceTree\m3-sys\cm3\src\version.quake or such, included by cm3\src\m3makefile. Does the file exist? Does version.quake use "/" or "SL"? If it uses "/", try replacing with SL (and ampersand for string concat). Could be that a newer binary distributions works better with forward slashes. > 4. > 5. > 6. Launch cygwin from desktop icon. Cygwin is only needed for cvs, I think you realize. Could you send me offline the result of just running "set" after running vcvarsall? I'd like to adapt pylib.py to it maybe. (I can start from 5.1.6 and will try 4.1 at some point.) - Jay Date: Tue, 15 Jan 2008 22:52:59 -0500 From: rcoleburn at scires.com To: m3devel at elegosoft.com; jayk123 at hotmail.com Subject: my status on win32 Jay et al: I've listed below the steps I've undertaken to try and build the current sources on Windows XP. I've also attached a text file showing the output I got when trying to build everything using Jay's upgrade.cmd script. Unfortunately, I'm getting a build error (see below). Please advise on how to resolve. STEPS I TOOK: ========= 1. Download Microsoft Visual Studio 2008 Express Edition All-in-One .ISO file and burn to DVD. http://www.microsoft.com/express/download/ 2. Install Microsoft Visual C++ 2008 Express Edition from DVD. 3. Use "Microsoft Update" service to check for updates / service packs. 4. Download cygwin setup program from http://cygwin.com/ 5. Ran cygwin setup.exe program to install cygwin for all users. Under "Devel" category, make certain to select "cvs" for installation. 6. Launch cygwin from desktop icon. 7. In cygwin command shell window, execute following two commands, making sure to give email as password when prompted for login: cvs -d :pserver:anonymous at modula3.elegosoft.com:/usr/cvs login cvs -d :pserver:anonymous at modula3.elegosoft.com:/usr/cvs checkout cm3 8. Moved resulting C:\cygwin\home\rcoleburn\cm3 to C:\CM3_CVS_SourceTree Note that you should replace "rcoleburn" above with your Windows login username. 9. Download cm3-min-WIN32-NT386-d5.5.0.zip and cm3-min-WIN32-NT386-d5.5.0-symbols.zip from http://modula3.elegosoft.com/cm3/download.html 10. Unzipped cm3-min-WIN32-NT386-d5.5.0.zip and stored resulting cm3 folder at C:\cm3 11. Unzipped cm3-min-WIN32-NT386-d5.5.0-symbols.zip and stored resulting symbols folder at C:\cm3\symbols 12. Launch Windows Command Prompt shell. The following steps represent commands executed within this shell. 13. path %path%;c:\cm3\bin 14. "C:\Program Files\Microsoft Visual Studio 9.0\VC\vcvarsall.bat" 15. cd C:\CM3_CVS_SourceTree\scripts\win 16. upgrade.cmd ERROR I'M GETTING: ============= === package C:\CM3_CVS_SourceTree\m3-sys\cm3 === +++ "cm3 -build -DROOT=C:\\CM3_CVS_SourceTree -DCM3_VERSION_TEXT=d5.5.1 -DCM3_V ERSION_NUMBER=050501 -DCM3_LAST_CHANGED=2007-12-30 && cm3 -ship -DROOT=C:\\CM3_C VS_SourceTree -DCM3_VERSION_TEXT=d5.5.1 -DCM3_VERSION_NUMBER=050501 -DCM3_LAST_C HANGED=2007-12-30" +++ --- building in NT386 --- ignoring ..\src\m3overrides "C:\CM3_CVS_SourceTree\m3-sys\cm3\src\version.quake", line 136: quake runtime er ror: unable to open "C:\CM3_CVS_SourceTree\m3-sys\cm3\src\../NT386.datenow" for reading --procedure-- -line- -file--- include -- version_impl 136 C:\CM3_CVS_SourceTree\m3-sys\cm3\src\version.quake include_dir 20 C:\CM3_CVS_SourceTree\m3-sys\cm3\src\m3makefile 8 C:\CM3_CVS_SourceTree\m3-sys\cm3\NT386\m3make.args Fatal Error: package build failed ERROR: "cm3 -build -DROOT=C:\\CM3_CVS_SourceTree -DCM3_VERSION_TEXT=d5.5.1 -DCM 3_VERSION_NUMBER=050501 -DCM3_LAST_CHANGED=2007-12-30 && cm3 -ship -DROOT=C:\\CM 3_CVS_SourceTree -DCM3_VERSION_TEXT=d5.5.1 -DCM3_VERSION_NUMBER=050501 -DCM3_LAS T_CHANGED=2007-12-30" ERROR: cd C:\CM3_CVS_SourceTree\m3-sys\cm3 ERROR: set INSTALLROOT=c:\cm3 Regards, Randy Share life as it happens with the new Windows Live. Start sharing! ( http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_012008 ) Put your friends on the big screen with Windows Vista* + Windows LiveT. Start now! ( http://www.microsoft.com/windows/shop/specialoffers.mspx?ocid=TXT_TAGLM_CPC_MediaCtr_bigscreen_012008 ) Get the power of Windows + Web with the new Windows Live. Get it now! ( http://www.windowslive.com/?ocid=TXT_TAGHM_Wave2_powerofwindows_012008 ) 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 ) Helping your favorite cause is as easy as instant messaging. You IM, we give. Learn more. ( http://im.live.com/Messenger/IM/Home/?source=text_hotmail_join ) -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Fri Jan 18 23:57:31 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 18 Jan 2008 23:57:31 +0100 Subject: [M3devel] incremental build always rebuilds cm3, never produces the same thing -- what time is "now"? 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> <477EA137.1E75.00D7.1@scires.com> <478D394B.1E75.00D7.1@scires.com> <478D47FB.1E75.00D7.1@scires.com> <478DBF8D.1E75.00D7.1@scires.com> <478DE973.1E75.00D7.1@scires.com> <47908659.1E75.00D7.1@scires.com> Message-ID: <20080118235731.i77fhwy4ys8k0og4@mail.elegosoft.com> Quoting Jay : > In m3-sys\cm3, incremental build always rebuilds cm3, never produces > the same thing. > > I know exactly why. My modification to Olaf's timestamping (which I > think he approved, > but perhaps didn't realize this outcome). I know of this problem and don't think it's of much importance. > Because we generate a source file with the current time, and it > always changes. It's not only that: we could fix the time and it would still rebuild, because the Version module is always generated, regardless if it's needed or not. Of course this could be fixed, too. > Is this ok with people?I know it has downsides, but it might be ok. > You know: > 1) incremental build should really never do anything, never > writing anything, fast > which is important -- never write, or be fast? both? > 2) You might want to compare two full builds and determine they > are identical; the less of this sort of thing the better > If not, what do people suggest for a way to determine when to update > the time? > The logic before I think was essentially never, unless you went and > deleted a specific file. > Perhaps that is right, once it is discovered and publicized. > Perhaps another output directory is needed -- say / > -- that upgrade and make-dist, perhaps, know to delete, and maybe > realclean...of cm3? deletes? Hey, maybe just declare an output, with > "..", in the m3makefile, so merely clean and realclean update the > time, but incremental builds do not? This seems obviously the way to > go right now, but still slightly debatable. Like, maybe an accurate > timestamp is needed. Maybe if any other source or .lib changes, the > timestamp should change -- so, like, m3_back/m3_link could > regenerate the file, except that might be too late. > > Should "now" be less granular than a second? That mitigates the > problem but i think is not satisfactory.Should "now" be overridable > on the command line or with an environment variable? Again I think it's not worth bothering about. The cm3 package will only be rebuilt by its developers and maintainers, and they can easily disable the mechanism if they want to. Or by end users performing an upgrade, but they should do it based on a script. The correct time to use would indeed be the last modification time of all the sources files compiled and linked into cm3. I've thought about this for half a day, but it would be a hell of an effort to program based on CVS. (If anybody finds an easy solution to do this, I'd be very interested.) The time stamp is just to imprint in releases and snapshots when the compiler was actually built and helps to relate problem reports to system releases. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Jan 19 00:03:18 2008 From: jayk123 at hotmail.com (Jay) Date: Fri, 18 Jan 2008 23:03:18 +0000 Subject: [M3devel] my status on win32 In-Reply-To: <20080118234226.8g4fi0mkgwgscwww@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> <477EA137.1E75.00D7.1@scires.com> <478D394B.1E75.00D7.1@scires.com> <478D47FB.1E75.00D7.1@scires.com> <478DBF8D.1E75.00D7.1@scires.com> <478DE973.1E75.00D7.1@scires.com> <47908659.1E75.00D7.1@scires.com> <20080118234226.8g4fi0mkgwgscwww@mail.elegosoft.com> Message-ID: Ok, that shuts me up well. I will continue to party in the *.py files and mostly avoid the *.sh files. And then, still, *.cmd vs. *.py? I suspect the answer is "The Windows folks, Jay being the most vocal/active at the moment, can do what they want" (which is partly why I am here -- to be in the "partially independent minority". :) ) I stopped reading usenet years ago but from time to time wonder if it might be "useful". I have at least two problems with using Modula-3 here but I might be somewhat or wrong or very wrong. 1) I have been unable to aquire a taste for it. 2) What about bootstrapping? This is a more general and relevant question that I have . >>>> From what version are you expected to be able to boot what version? Is it ok for merely version n to only be bootrappable, or upgradable, from version n (for upgrade) or n - 1 (bootstrap)? Or downgrade from anything > n? "Version n" isn't even well defined..or is that because I don't know about pkgtags? Any increased dependency on Quake worries me here, until I understand this. Yet, unless you can be clever and a) make all new things optional b) write all new things in both M3 and Quake, or M3 and SH, or M3 and whatever, forward progress is entirely blocked in Quake, and that probably can't be the right answer. Arguably either way -- required changes must be possible at any point in the stack at any time. Nothing is unchangable. Don't go crazy. Don't change things for no reason. But if a change is needed, it can be done. OR, alternatively, some things really cannot be changed, as they would require rewriting all or at least a whole heck of a lot of code. The world is round, and that cannot change, until such time as the world is gone, and all of us with it, for example. Modula-3 files have the extensions .m3 and .i3. I could be wrong, but there will never ever be a reason to change that, for example. I can bootstrap on Windows from 5.1.3. I have 4.1 and 3.6 but haven't tried yet. I believe 3.6 won't work since I /think/ cm3 uses WIDECHAR or such. 3.6 definitely still "works" on its own, nice. I am not sure there is any point to those exercises. Having them working independently may be useful for comparison and history, but that is different than booting. - Jay > Date: Fri, 18 Jan 2008 23:42:26 +0100> From: wagner at elegosoft.com> To: jayk123 at hotmail.com> CC: rcoleburn at scires.com; m3devel at elegosoft.com> Subject: Re: [M3devel] my status on win32> > Quoting Jay :> > > I'll see about adding usage statements.> > Basically all the do* scripts accept a "command" and a list of packages.> > The commands are:> > realclean> > clean -- pretty useless imho> > buildlocal -- the default> > ship> > buildship -- build and shpi> > buildglobal> > Actually, the more useful commands are> > build -- build with overrides to ROOT> buildship (same as buildglobal) -- build with global package pool> realclean -- completely delete derived target files> > > do-pkg requires a list.> > If you're doing you're own project, this may be what is most useful> -- if you use the scripts at all.> > > What do folks think of deleting all of scripts\win and having only > > scripts\python?> > I guess you have to try them out first, at least.Scripts\python > > achieves parity pretty much, except for the more logging to files, > > less logging to the console, that win\make-dist has.> >> > Furthermore, out on a limb, what do folks think of deleting most of > > scripts\*.sh and having just Python?> > I'd object to this. Shell is POSIX standard, and most of the> infrastructure is built on it; Python is nice to have, but should> not be a prerequisite to CM3.> > > I doubt this will fly and I will try resist mentioning it often. :)> > In the interest of consensus here, though I doubt it will help, I'd > > be open to rewriting python in Perl, or possiby even Tcl.> > Why?> > > I am also willing/interested in discussing the merits of these > > languages, or an as yet undeveloped one "ideal language" (Modula-3 I > > don't think is it, sorry), but probably most people will find it a > > waste of time. Where is the geek-out-really-badly mailing list? :)> > I don't see the point in rewriting the scripts in yet other languages.> The purpose of the scripts is to support the installation, administration> and maintenance of the CM3 distribution. They were not intended as> a general purpose build or automation environment, though they can> be used for this purpose to a certain extent. But the main point is> that they are useful for the people maintaining the distribution.> > We could think about rewriting everything in M3 to further reduce> the system dependencies, but this would not be as flexible as a> general scripting language. Quake would need to be substantially> extended, and Python is nice, but a huge software distribution in> itself, that should be independent of CM3.> > POSIX shell is the one common interpreter I have found to be available> on almost all systems. (Even when we were programming point-of-sale> solutions on DOS in the early 90s we had ksh and other POSIX tools there> to emulate the Sun development environment we used on the servers.)> OK, on Windows you have to install it (e.g. in form of Cygwin) like> Python, but it's still the best choice wrt. availability and portability> I've found.> > For general discussions of the advantages and disadvantage of> programming languages, some of the comp.lang.* newsgroups may> be the better choice, though I haven't read them for years now> and don't know if they're still alive.> > As for the ideal language -- I don't think that there is any language> that could claim this. The advantages and disadvantages depend heavily> on the usage context, environment, and skills and understanding of the> programmers.> > (M3 is pretty good 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> _________________________________________________________________ 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 Jan 19 00:25:33 2008 From: jayk123 at hotmail.com (Jay) Date: Fri, 18 Jan 2008 23:25:33 +0000 Subject: [M3devel] my status on win32 In-Reply-To: <4790E7A7.1E75.00D7.1@scires.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> <477EA137.1E75.00D7.1@scires.com> <478D394B.1E75.00D7.1@scires.com> <478D47FB.1E75.00D7.1@scires.com> <478DBF8D.1E75.00D7.1@scires.com> <478DE973.1E75.00D7.1@scires.com> <47908659.1E75.00D7.1@scires.com> <4790E7A7.1E75.00D7.1@scires.com> Message-ID: I'm an old guy that started with 143k floppies. :) I don't like calling them "scripts" either. They are "programs", in varying languages, needing "compilation" or not. cmd is an awful language and deserves some derisive label, but Perl and Python seem to strive to be pretty complete and large maintainable well *engineered* systems have been built with them. If I may stretch the point, they are "systems" programming languages, for "system" meaning "large well engineered modular maintainable long lived reliable blah blah system", not "operating system" or in particular "kernel". Perl has some problems. Python has some problems. They both have some "magic" "developer productivity" improvements, and that can be a bad thing, it can lead to programming faster with less design/engineering. Olaf I didn't answer your question "why?" And it is moot. For whatever temporary or permanent condition, I don't like "sh". I have tried to learn it several times and always get lost in a haze of special things to keep in mind, portability concerns, inability to build data structures perhaps. Not that "special things to keep in mind" prevented *.cmd from being created, maybe I put more persistance there, or a younger self. I have run MS-DOS relatively recently and been amazed at how limited command.com is. I don't think portability to .bat is feasible while accomplishing much approaching the *.sh. (Dare I mention a DJGPP port? No such thing exists, but, hey, gcc, consider making garbage collection and threading optional pending further research.., the djgpp posix-ish runtime....seems feasible, not sure what people do with this environment though....and besides, Python exists built with djgpp so whil djgpp might be a viable interesting port, command.com remains irrelevant..) Randy I kind of agree with your sentiment about the "native environment", and reducing dependencies, it is a common one, HOWEVER I believe it is a gray one, and the pay off to compromising it can be substantial. There will be a NT386GNU target, and unless we import ld, as, (and I'm not going to do so) and more, it will likely always require getting cm*.tar.gz and at least one other file onto your system to build m3cc. There was work on a linker written in Modula-3, so in fact, using the system might be possible without gcc/ld/as, or even without Visual C++. However m3core has some C code, so building it, for the forseeable future, will continue to require a C compiler. (I think this C code is cutable, that I have seen -- hand/dtoa, and at least Win32 Errno). It is possible that the cm3 gui installer will prompt "Do you want to be able to build the ENTIRE system, including the compiler from source", and if so, for NT386GNU look for the local installs, else get and install them, or for NT386 plop you in IE's at microsoft.com (EULAs and all that..)." Try installing the free/open Qt for example. It will get MingW for you. In this model, what is extra? Where does one download/dependency end and the next begin? In terms of the user experience, not clear. I am aware of your programs and while they appear well designed/documented/developed, I like to do things myself. I have been tempted to ask "Mind if I delete yours and move mine up into that directory" but thought it maybe too rude. Thanks for the compliment, and you should keep at it (the contributions, not the compliments, or both. :) ) If you want an explanation of something I did, ask. Buildship, buildlocal, buildglobal..uh oh, you did ask.and I doubt I can explain this well, not sure I understand it well. Will try later maybe, or see what anyone else says first. - Jay Date: Fri, 18 Jan 2008 17:53:45 -0500From: rcoleburn at scires.comTo: m3devel at elegosoft.com; jayk123 at hotmail.comSubject: RE: [M3devel] my status on win32 Jay: What does "buildglobal" mean? How is it different from "buildship"? As far as "scripts" go, I'm an old guy that started out with computers that had real core memory. When the IBM PC revolution hit, I was already a professional and had mastered large computers with network operating systems and even micro-computers with CP/M. I learned DOS and became a good "BAT" batch file programmer (we didn't call them scripting languages back then). I'm still pretty good with Windows CMD files, but have not tackled python. My vote for cm3 on Windows is to avoid making the end user (customer) have to learn or acquire things that aren't native to his environment. Thus, I would argue for use of CMD files on Windows instead of some other scripting language. This same reasoning is why I was pushing for the all-in-one installation program for cm3 on Windows. If all a "Windows person" has to do to get cm3 modula-3 up and running on his box is to run an install program and possibly tweak a few CMD scripts to his/her liking, then it is "easy". Forcing acquisition and installation of other tools/environments just to get started makes things complicated and increases the barrier to startup and acceptance. Just my 2 cents worth. A few years ago, I contributed some BAT/CMD files that could be used to build the entire system on Windows. The only issue is that as the system evolves, you have to keep the package build order up to date. I don't mind trying to help out further in this area. You seem to be very technically capable, so perhaps what I can offer pales in comparison. Thanks for all you are doing. Let me know if/how I can help. Regards, Randy>>> Jay 1/18/2008 4:50 PM >>>I'll see about adding usage statements.Basically all the do* scripts accept a "command" and a list of packages.The commands are: realclean clean -- pretty useless imho buildlocal -- the default ship buildship -- build and shpi buildglobal The .sh and .py have a usage explaining this but .cmd is missing it, probably because I didn't fully understand at the time the functionality of the code I was blindy porting. do-* except for do-pkg have an implied list of packages. Maybe you can add to it, would have to check the source. do-pkg requires a list. Most of the rest are not meant to be user-callable -- sysinfo, pkginfo, pkgcmds. make-dist its its own thing. Oh, right -- environment variables. Many things are overridable with them, and need documentation the same. What do folks think of deleting all of scripts\win and having only scripts\python?I guess you have to try them out first, at least.Scripts\python achieves parity pretty much, except for the more logging to files, less logging to the console, that win\make-dist has. Furthermore, out on a limb, what do folks think of deleting most of scripts\*.sh and having just Python?I doubt this will fly and I will try resist mentioning it often. :)In the interest of consensus here, though I doubt it will help, I'd be open to rewriting python in Perl, or possiby even Tcl. I am also willing/interested in discussing the merits of these languages, or an as yet undeveloped one "ideal language" (Modula-3 I don't think is it, sorry), but probably most people will find it a waste of time. Where is the geek-out-really-badly mailing list? :) - Jay Date: Fri, 18 Jan 2008 10:58:36 -0500From: rcoleburn at scires.comTo: m3devel at elegosoft.com; jayk123 at hotmail.comSubject: Re: [M3devel] my status on win32 Jay: Ok. It will be later tonight before I can try again. Thanks! BTW, can you point me to a document/file somewhere that describes the various options for your windows command file scripts? I did experiment further with using the do-cm3-std.cmd and was finally able to get most everything to build, but of course this doesn't rebuild the compiler and core. Had problems with mentor and m3zume not wanting to build/run, so I commented these out in the cmd file to get it to work. Then I had trouble because everything was built with overrides by default, so I had to mess around with changing parameters and rebuilding clean. I've tried building some of my programs and, of course, have run into a few problems due to changes in the system. I've overcome most of these, but I am seeing some strange behavior: 1. pixmaps aren't rendered properly on the screen. They look really bad. I recall having this problem a while back with one of the early 5.x releases, so I guess it was never solved. I've got some old test programs I try to dig out and see if I can find out what is going on. I seem to recall that building standalone in the past seemed to fix the problem, so this is a real mystery. 2. I'm having trouble with bundles not returning all of the data. In the "reactor" program, bundles are used to provide input to the web browser for the page source. I'm seeing cases where not all of the HTML source is making it to the browser. Not sure if this is an I/O problem (maybe buffers not flushed) or if it is something else. It may be that this problem has some impact on #1 above because pixmaps are sometimes stored in the bundles. For the above #1 and #2, these things worked properly on cm3 v4.1. I have the sources to 4.1, so maybe I can use them to figure out what is wrong. On a side note, I found and fixed a major bug in the "reactor" program, so that is good. Now, for another topic that we should probably move to a new email thread: Back in the early days, my company paid Critical Mass, Inc., to customize the Trestle/FormsVBT look and feel to more closely resemble Windows. I have the sources for this work, but of course it is based on v4.1 and the repository code has moved on since then. I am curious if anyone would be interested in me trying to integrate these customizations back into the current source tree, perhaps on a different branch? If we go this route, I may need a little refresher tutorial on the use of branches in CVS. We would want to make it so that the main branch and the customized branch could evolve in sync. That is, if a bug was found in either branch, the fix should be incorporated into both. Regards, Randy>>> Jay 1/18/2008 10:32 AM >>>Randy, please try with an updated m3-sys/cm3/src/version.quake and report back, thanks.I understand why I wasn't seeing this. - Jay Date: Wed, 16 Jan 2008 11:24:34 -0500From: rcoleburn at scires.comTo: m3devel at elegosoft.com; jayk123 at hotmail.comSubject: Re: [M3devel] my status on win32 Jay: Not sure I've clued in to all of your dialog. Sorry. I have in the past used a free tool to build an installer package and I was thinking of using it again. Since the tool is free, we could put all the work I do into the CVS repository so that others could also maintain it. What I am looking to achieve is to have a way where a "normal" Windows user could download a program, run it, and have all of the cm3 packages installed without having to use the MIN distribution to build it up or any other tools to get the sources (like cvs). You could achieve the same thing by having a big ZIP file also I suppose, but having the installer would also let us easily put something in the start menu to launch a command line with all the environment variables set properly via automatic call to vcvars et al. When I get "Reactor" working, it too could be put into the start menu. That just makes it fit in better with the Windows user culture I think. The reason I wanted to rebuild everything is two-fold: 1) ensure it can be done (i.e., test for "Broken #1"), and 2) get all of the rest of the packages built so I could then use cm3 to build "reactor" and my own programs and test them to see if there are any "Broken #2" issues. The MIN distribution is really insufficient to do much of anything except to build the rest of the packages you need. My understanding is that I needed to use CVS to get the current sources, because if I went back to the source archive, it was old and known to be Broken #1 on Windows. I'm glad that you believe the current "Broken #1" situation is easy to fix. Let me know what to do and I'll give it another try. My experience in the past has been that there are 3 conditions to getting cm3 to work properly on windows after it has been installed: 1) make sure your environment variables are set up by vcvars to point to the compiler/linker/libraries (of course if you used a non-Microsoft C compiler/linker you would need to use something other than vcvars); 2) make sure cm3.cfg has the right paths in place to find all the libraries and tools using DOS style short names (no embedded spaces); and 3) make sure C:\cm3\bin is in your path. Of these, #2 & #3 are essentially one-time events, and #1 can be set up by a invoking a batch/command file via a shortcut, so no big deal for me. You could even make #1 a one-time event by modifying the system-level (vice user-level) environment variables. The old cm3install program seemed to do a decent job of #2 for me. Also, I've noted some of your past dialog about accepting either '/' or '\' as a path separator. I'm sure you are aware that on Windows '/' is used often for switches (arguments). Plus Windows also allows spaces to be embedded in the command line, so whatever solution you propose needs to take into account that a valid command line might look like this: C:\My Program Folder\My Program.exe /myArg1 /myArg2 In some situations, this command line would have to be quoted and rendered as: "C:\My Program Folder\My Program.exe" /myArg1 /myArg2 and in places where the backslash is an escape character, I've seen "C:\\My Program Folder\\My Program.exe" /myArg1 /myArg2 Alas, I seem to have rambled a bit also. Sorry. The immediate need for me now is to solve the Broken #1 condition, so please let me know how to fix it and proceed. Regards, Randy>>> Jay 1/16/2008 10:28 AM >>>Randy, yes and no and clarifications. I mention starting with 5.1.6 as a "worst" or "worse" case.The earlier you start, the harder things are -- for me, to ensure it will work. If you merely start with my 5.5.0, well, what are you rebuilding from source for?Heck, you can use any binary distribution, 4.1, 5.1.6, and just use it. They should work. The n steps you/I give are really actually geared for people who WANT to build from source, it is not what people HAVE to do.As well there have been can be source distributions, to cut out CVS. I'll look into the datefn stuff shortly. As to the installer, well, again, yes and no.The need for the installer is very small. All you have to do today is unzip the .zip somewhere and set the path, and possibly the vcvars thing. That's it. I should..now that you are "pressuring" me for ease of use, teach cm3 about the various ?venvdir%, %vcinstalldir% variables, etc. That way as long as the user installed the tools, even if they elected not to change path/lib/include, cm3 can find the compiler and linker. I know everyone wants to preserve the flexibility of quake/cm3.cfg but...besides, cm3 can be pretty darn smart here. IF cm3.cfg defines SYSTEM_CC, leave things along (NT386 cm3.cfg does not today do that). However if there is now SYSTEM_CC and there is no cl.exe/link.exe in %PATH%, it could go on a quick hunt for them. On the lib and include part, well, the dependency on %include% might only be for errno..maybe not worth it. It has been whatever it is forever, like int* _errno(void); #define errno (*_errno)()). Modula-3 engages in rampant header cloning and CErrnoC was only introduced where that was deemed more fragile than usual, and for Windows it probably wasn't actually fragile -- the fragility, if I may be so rudely judgemental, is because so many other systems are so Johnny-come-lately to arriving at the obviously correct threading model that Windows has had all along (since Win95/NT, can't say anything good about Win3.1; I think OS/2 might have had it correct all along too.). Funny, everyone has FINALLY arrived at the correct threading model, only to have start changing again, since the number of cores and machines is set to be much greater than anticipated, the obvious threading model has been deemed too difficult for anyone to use (Win32, Modula-3, Java, .NET, Python, all the same supposedly too difficult model btw), and so some new one is needed, and well, truthfully, the difficulty is not just for dummies on relatively small multiproc boxes not having simple race conditions, the problem is scaling way way up. Sorry that was my usual tangential. Even the unzip and set path would benefit slightly from a GUI installer.I believe there is some easy thing you can do where you write your GUI installer and you put it in the .zip and then you prepend the GUI self extracting .zip/.exe stub, and you can tell it to run a particular command after the extraction. I guess you might use a fancier thing though?That is, are you going to, say, write a gui installer from scratch in Modula-3? It might be a fun exercise. :)And then you could build the self extracting prefix from source etc.This is the hard way I guess, but more interesing.If you can build an msi or use InstallShield or Wix or something, go ahead.If you use widely availabe free as in beer tools, that can be rolled into whatever automation there is to produce distributions, keeping it up to date shouldn't be a problem. I do have to bring up some annoying questions: 1) Does anyone besides me have the capacity to produce distributions? i.e.: Any Win32 machines left at Elego? 2) I know I ramble. So one of my many tangents/questions went unanswered.Say, in the absence of a gui installer, should .zips/.tar.bz files look like cm3-min-/bin/cm3orbin/cm3orcm3/bin/cm3 The last one is more directly usable. The first one is very common. This reminds me though Randy, the distribution I made available was "min", so yeah, like if you are doing any gui programming, using any "standard" library besides m3core or libm3, you'd need to build more from source. I can readily provide you a "std" distribution though.It's "always" been a "problem" to make my files available -- no web site hosting for me -- but recently that wasn't a problem, someone picked the files out of ~jkrell on birch and put them on the web site. Good. One more thing -- Olaf, please confirm repeat yourself, 'cause I admit I wasn't sure it was the right thing, but if you insist, ok. "std" should be "all"? I should not continue to imagine there is a new larger group called "all"? And wherever things are missing from std but do build ok, add them?m3cc should be in std?(I admit some big indecisiveness around m3cc. It is far and away the longest thing to build and so the one you really want to skip the most and leave out of whatever package group. I also wonder if on Windows, there should be some check where if sh is not in the $PATH, just silently skip m3cc? You only need MingWin to build what I have on my system for NT386GNU, except you also need msys just for m3cc. msys is actually quite small, like only 20 files..) Oh, sorry, yet another question.The non-gcc backend is excluded from the build on systems that use the gcc backend.For minimization, that is appropriate.For maximizing cross build capability, it is wrong.The packages build fine. I suspect they work.I am not a user of cross build capability yet, so I don't really care. (What I do for NT386/NT386GNU /might/ be considered sort of a cross build, but it is different/easier).They are small packages. - Jay Date: Wed, 16 Jan 2008 08:25:49 -0500From: rcoleburn at scires.comTo: m3devel at elegosoft.com; jayk123 at hotmail.comSubject: Re: [M3devel] my status on win32 Jay: There is no line in the m3makefile dealing with datefn, so I added the whole statement just before the line include("version.quake") Now, I get an error saying that the variable datefn is not defined. If you change to put quotes around datefn in the include statement, you get an error saying it can't open the file. You made a reference in one of your earlier posts about trying 5.1.6 or 4.1, but note that I started with your cm3-min-WIN32-NT386-d5.5.0.zip , not the 5.1.6 or 4.1 versions. Thus, using d5.5.0 as a base, I am trying to run your "upgrade.cmd" to rebuild the sources I checked out from CVS. Since this doesn't work "out-of-the-box", again I say this fits into the "Broken #1" category. If I can get this to work, I don't mind putting together a Windows installer program that will install the whole thing. That way, folks won't have to install cygwin just to get CVS so that they can install a working cm3. Folks will need to install the free Microsoft Visual C as a prerequisite, but then that's not too bad. Having an installer program would make cm3 more friendly to Windows folks. The current 16-step method is too laborious and error-prone for the person just getting started and they will not give cm3 a second try. As the cm3 system evolves and new releases are made, we will need to keep the installer program up-to-date and I don't mind doing that. After someone gets familiar with cm3 they might want to delve into some of the scripts for rebuilding the system, but until then, I think the installer program is the way to go. Regards, Randy>>> Jay 1/16/2008 1:01 AM >>>I think I see the problem. in cm3\src\m3makefile, make this change > if not defined("NOW") include(datefn) > end datefn is only created if certain other variables aren't defined, and do-pkg defines them.I don't know why I don't see this. Later.Could be that the Python scripts have a typo and don't define them.I've been using them more than cmd. If the host is NT, "NOW" is either gotten from an updated cm3.exe, or left to "not available". So the initial cm3 built from older cm3 can't report when it was built, but cm3 built from current cm3 can. I need to change that: 1) to be a function for niceness 2) to make it that way for Posix, for any host but I haven't been using Posix as much lately so not testing it. - Jay Date: Tue, 15 Jan 2008 23:55:39 -0500From: rcoleburn at scires.comTo: m3devel at elegosoft.com; jayk123 at hotmail.comSubject: RE: my status on win32 Jay: In the file version.quake, I made the following edit: changed line: local datefn = "../" & TARGET & ".datenow" to: local datefn = ".." & SL & TARGET & ".datenow" This change has the effect of putting a backward slash in the pathname instead of a forward slash, so we getC:\CM3_CVS_SourceTree\m3-sys\cm3\src\..\NT386.datenow So from that perspective, the change seems good. Unfortunately, I still get the error that this file can't be opened. A quick check of C:\CM3_CVS_SourceTree\m3-sys\cm3\NT386 shows that the file .datenow does not exist. Regards, Randy>>> Jay 1/15/2008 11:03 PM >>>That's not too bad really. 1) I'd recommend putting cm3 at the start of the path instead of the end. 2) Just comment out the offending code to make progress. It's not critical. >> C:\CM3_CVS_SourceTree\m3-sys\cm3\src\../NT386.datenow The code is: C:\CM3_CVS_SourceTree\m3-sys\cm3\src\version.quake or such, included by cm3\src\m3makefile. Does the file exist?Does version.quake use "/" or "SL"? If it uses "/", try replacing with SL (and ampersand for string concat). Could be that a newer binary distributions works better with forward slashes. > 4. > 5. > 6. Launch cygwin from desktop icon. Cygwin is only needed for cvs, I think you realize. Could you send me offline the result of just running "set" after running vcvarsall? I'd like to adapt pylib.py to it maybe. (I can start from 5.1.6 and will try 4.1 at some point.) - Jay Date: Tue, 15 Jan 2008 22:52:59 -0500From: rcoleburn at scires.comTo: m3devel at elegosoft.com; jayk123 at hotmail.comSubject: my status on win32 Jay et al: I've listed below the steps I've undertaken to try and build the current sources on Windows XP. I've also attached a text file showing the output I got when trying to build everything using Jay's upgrade.cmd script. Unfortunately, I'm getting a build error (see below). Please advise on how to resolve. STEPS I TOOK: ========= 1. Download Microsoft Visual Studio 2008 Express Edition All-in-One .ISO file and burn to DVD. http://www.microsoft.com/express/download/ 2. Install Microsoft Visual C++ 2008 Express Edition from DVD. 3. Use "Microsoft Update" service to check for updates / service packs. 4. Download cygwin setup program from http://cygwin.com/ 5. Ran cygwin setup.exe program to install cygwin for all users. Under "Devel" category, make certain to select "cvs" for installation. 6. Launch cygwin from desktop icon. 7. In cygwin command shell window, execute following two commands, making sure to give email as password when prompted for login: cvs -d :pserver:anonymous at modula3.elegosoft.com:/usr/cvs login cvs -d :pserver:anonymous at modula3.elegosoft.com:/usr/cvs checkout cm3 8. Moved resulting C:\cygwin\home\rcoleburn\cm3 to C:\CM3_CVS_SourceTree Note that you should replace "rcoleburn" above with your Windows login username. 9. Download cm3-min-WIN32-NT386-d5.5.0.zip and cm3-min-WIN32-NT386-d5.5.0-symbols.zip from http://modula3.elegosoft.com/cm3/download.html 10. Unzipped cm3-min-WIN32-NT386-d5.5.0.zip and stored resulting cm3 folder at C:\cm3 11. Unzipped cm3-min-WIN32-NT386-d5.5.0-symbols.zip and stored resulting symbols folder at C:\cm3\symbols 12. Launch Windows Command Prompt shell. The following steps represent commands executed within this shell. 13. path %path%;c:\cm3\bin 14. "C:\Program Files\Microsoft Visual Studio 9.0\VC\vcvarsall.bat" 15. cd C:\CM3_CVS_SourceTree\scripts\win 16. upgrade.cmd ERROR I'M GETTING: ============= === package C:\CM3_CVS_SourceTree\m3-sys\cm3 ===+++ "cm3 -build -DROOT=C:\\CM3_CVS_SourceTree -DCM3_VERSION_TEXT=d5.5.1 -DCM3_VERSION_NUMBER=050501 -DCM3_LAST_CHANGED=2007-12-30 && cm3 -ship -DROOT=C:\\CM3_CVS_SourceTree -DCM3_VERSION_TEXT=d5.5.1 -DCM3_VERSION_NUMBER=050501 -DCM3_LAST_CHANGED=2007-12-30" +++--- building in NT386 --- ignoring ..\src\m3overrides "C:\CM3_CVS_SourceTree\m3-sys\cm3\src\version.quake", line 136: quake runtime error: unable to open "C:\CM3_CVS_SourceTree\m3-sys\cm3\src\../NT386.datenow" forreading --procedure-- -line- -file---include -- version_impl 136 C:\CM3_CVS_SourceTree\m3-sys\cm3\src\version.quakeinclude_dir 20 C:\CM3_CVS_SourceTree\m3-sys\cm3\src\m3makefile 8 C:\CM3_CVS_SourceTree\m3-sys\cm3\NT386\m3make.args Fatal Error: package build failedERROR: "cm3 -build -DROOT=C:\\CM3_CVS_SourceTree -DCM3_VERSION_TEXT=d5.5.1 -DCM3_VERSION_NUMBER=050501 -DCM3_LAST_CHANGED=2007-12-30 && cm3 -ship -DROOT=C:\\CM3_CVS_SourceTree -DCM3_VERSION_TEXT=d5.5.1 -DCM3_VERSION_NUMBER=050501 -DCM3_LAST_CHANGED=2007-12-30"ERROR: cd C:\CM3_CVS_SourceTree\m3-sys\cm3ERROR: set INSTALLROOT=c:\cm3 Regards, Randy Share life as it happens with the new Windows Live. Start sharing! Put your friends on the big screen with Windows Vista? + Windows LiveT. Start now! Get the power of Windows + Web with the new Windows Live. Get it now! 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. _________________________________________________________________ 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 Sat Jan 19 00:38:45 2008 From: jayk123 at hotmail.com (Jay) Date: Fri, 18 Jan 2008 23:38:45 +0000 Subject: [M3devel] NT386GNU diffs In-Reply-To: <4790E7A7.1E75.00D7.1@scires.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> <477EA137.1E75.00D7.1@scires.com> <478D394B.1E75.00D7.1@scires.com> <478D47FB.1E75.00D7.1@scires.com> <478DBF8D.1E75.00D7.1@scires.com> <478DE973.1E75.00D7.1@scires.com> <47908659.1E75.00D7.1@scires.com> <4790E7A7.1E75.00D7.1@scires.com> Message-ID: I think attached is all the diffs I have for NT386GNU. They are: "rewrite" NT386GNU config fileThe diff and result are present.It almost exactly matches NT386.In fact, the targets can perhaps be merged into one configurable target,and NT386GNU be "reclaimed" for the more Posix port people want.But not right now. setjmp to _setjmpThis "works" with Cygwin and MinGW, whereas setjmp doesn't."Works" as in links. I should double check this. Maybe not needed. Just one line.. Changes NT386GNU from Posix to Win32. Any objects to commiting? The result is you can build a lot of NT386GNU, but it won't run.I would say it won't "quite" run, but I can't claim to know all that is wrong. Yes, I understand, getting it to run is very important. This may be progress,but isn't useful yet. - 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 Sat Jan 19 00:42:56 2008 From: jayk123 at hotmail.com (Jay) Date: Fri, 18 Jan 2008 23:42:56 +0000 Subject: [M3devel] m3cc/fopen("rb") In-Reply-To: <4790E7A7.1E75.00D7.1@scires.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> <477EA137.1E75.00D7.1@scires.com> <478D394B.1E75.00D7.1@scires.com> <478D47FB.1E75.00D7.1@scires.com> <478DBF8D.1E75.00D7.1@scires.com> <478DE973.1E75.00D7.1@scires.com> <47908659.1E75.00D7.1@scires.com> <4790E7A7.1E75.00D7.1@scires.com> Message-ID: I changed m3cc to use fopen("rb") instead of fopen("r"), needed for NT386GNU. Yet I just found this: C:\cm3-4.1\binutils-2.7\gas\config\go32.cfg /* Some operating systems, for example DOS, require the use of "wb" mode when opening a binary file for writing. If only "w" is used, the file will not be correct. However, some other systems reject such a mode. This indicates which ../include/fopen-*.h header file we want to include, so that we can get macros that'll do the right thing for this system. */#define WANT_FOPEN_BIN 1 Does it matter? - 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 Jan 19 00:43:51 2008 From: jayk123 at hotmail.com (Jay) Date: Fri, 18 Jan 2008 23:43:51 +0000 Subject: [M3devel] NT386GNU diffs 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> <477EA137.1E75.00D7.1@scires.com> <478D394B.1E75.00D7.1@scires.com> <478D47FB.1E75.00D7.1@scires.com> <478DBF8D.1E75.00D7.1@scires.com> <478DE973.1E75.00D7.1@scires.com> <47908659.1E75.00D7.1@scires.com> <4790E7A7.1E75.00D7.1@scires.com> Message-ID: attached this time.. From: jayk123 at hotmail.comTo: m3devel at elegosoft.comDate: Fri, 18 Jan 2008 23:38:45 +0000Subject: [M3devel] NT386GNU diffs I think attached is all the diffs I have for NT386GNU.They are:"rewrite" NT386GNU config fileThe diff and result are present.It almost exactly matches NT386.In fact, the targets can perhaps be merged into one configurable target,and NT386GNU be "reclaimed" for the more Posix port people want.But not right now.setjmp to _setjmpThis "works" with Cygwin and MinGW, whereas setjmp doesn't."Works" as in links. I should double check this. Maybe not needed.Just one line..Changes NT386GNU from Posix to Win32.Any objects to commiting?The result is you can build a lot of NT386GNU, but it won't run.I would say it won't "quite" run, but I can't claim to know all that is wrong.Yes, I understand, getting it to run is very important. This may be progress,but isn't useful yet. - 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: diff.zip Type: application/x-zip-compressed Size: 11639 bytes Desc: not available URL: From rcoleburn at scires.com Sat Jan 19 01:05:38 2008 From: rcoleburn at scires.com (Randy Coleburn) Date: Fri, 18 Jan 2008 19:05:38 -0500 Subject: [M3devel] my status on win32 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> <477EA137.1E75.00D7.1@scires.com> <478D394B.1E75.00D7.1@scires.com> <478D47FB.1E75.00D7.1@scires.com> <478DBF8D.1E75.00D7.1@scires.com> <478DE973.1E75.00D7.1@scires.com> <47908659.1E75.00D7.1@scires.com> <4790E7A7.1E75.00D7.1@scires.com> Message-ID: <4790F880.1E75.00D7.1@scires.com> >>> Jay 1/18/2008 6:25 PM >>> >>> I'm an old guy that started with 143k floppies. :) Floppies, what a luxury! I had to deal with paper tape, punched cards, and hard-wired plug boards to program old IBM tabulating machines. I've found no better finger muscle exercise than "typing" for hours on an old ITT canary-yellow roll paper teletype machine with a paper tape punch. And no, I don't long for the "good 'ol days" because in many ways they weren't so good... Regards, Randy -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Sat Jan 19 01:29:19 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 19 Jan 2008 00:29:19 +0000 Subject: [M3devel] FW: my status on win32 In-Reply-To: <20080118234226.8g4fi0mkgwgscwww@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> <477EA137.1E75.00D7.1@scires.com> <478D394B.1E75.00D7.1@scires.com> <478D47FB.1E75.00D7.1@scires.com> <478DBF8D.1E75.00D7.1@scires.com> <478DE973.1E75.00D7.1@scires.com> <47908659.1E75.00D7.1@scires.com> <20080118234226.8g4fi0mkgwgscwww@mail.elegosoft.com> Message-ID: darnit something keeps truncating my email. From: jayk123 at hotmail.comTo: wagner at elegosoft.comCC: rcoleburn at scires.com; m3devel at elegosoft.comSubject: RE: [M3devel] my status on win32Date: Fri, 18 Jan 2008 23:03:18 +0000 Ok, that shuts me up well. I will continue to party in the *.py files and mostly avoid the *.sh files. And then, still, *.cmd vs. *.py? I suspect the answer is "The Windows folks, Jay being the most vocal/active at the moment, can do what they want" (which is partly why I am here -- to be in the "partially independent minority". :) )I stopped reading usenet years ago but from time to time wonder if it might be "useful". I have at least two problems with using Modula-3 here but I might be somewhat or wrong or very wrong. 1) I have been unable to aquire a taste for it. 2) What about bootstrapping? This is a more general and relevant question that I have. >>>> From what version are you expected to be able to boot what version? Is it ok for merely version n to only be bootrappable, or upgradable, from version n (for upgrade) or n - 1 (bootstrap)?Or downgrade from anything > n?"Version n" isn't even well defined..or is that because I don't know about pkgtags? Any increased dependency on Quake worries me here, until I understand this. Yet, unless you can be clever and a) make all new things optional b) write all new things in both M3 and Quake, or M3 and SH, or M3 and whatever, forward progress is entirely blocked in Quake, and that probably can't be the right answer. Arguably either way -- required changes must be possible at any point in the stack at any time. Nothing is unchangable. Don't go crazy. Don't change things for no reason. But if a change is needed, it can be done. OR, alternatively, some things really cannot be changed, as they would require rewriting all or at least a whole heck of a lot of code. The world is round, and that cannot change, until such time as the world is gone, and all of us with it, for example. Modula-3 files have the extensions .m3 and .i3. I could be wrong, but there will never ever be a reason to change that, for example. I can bootstrap on Windows from 5.1.3.I have 4.1 and 3.6 but haven't tried yet.I believe 3.6 won't work since I /think/ cm3 uses WIDECHAR or such.3.6 definitely still "works" on its own, nice.I am not sure there is any point to those exercises.Having them working independently may be useful for comparison and history, but that is different than booting. - Jay [snip, deliberate] _________________________________________________________________ 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 Jan 19 01:47:11 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 19 Jan 2008 00:47:11 +0000 Subject: [M3devel] buildlocal vs. buildglobal vs. buildship explanation Message-ID: I'm not sure I can explain this well or if I fully understand it. "Ship" means "Install" Let's say your install is at c:\cm3 and your source is at c:\dev2\cm3 (I would use dev, but Unix took it.) Depending on the state of things, you probably two of many things: c:\cm3\pkg\libm3\nt386\libm3.libc:\cm3\pkg\libm3\nt386\libm3.dllc:\dev2\cm3\m3-libs\libm3\nt386\libm3.libc:\dev2\cm3\m3-libs\libm3\nt386\libm3.dll You will have more in \dev2\cm3\m3-libs\libm3\nt386. When you build stuff, you can use the installed dependencies or the just built dependencies. buildlocal uses the just built dependencies. buildglobal uses the installed dependencies buildship build and ships (installs) each directoryIt does it in one pass: buildship pkg1 pkg1 => build pkg1 ship pkg1 build pkg2 ship pkg2 and NOT build pkg1 build pkg2 ship pkg1 ship pkg2 You may only ship/install outputs that are builtglobal.Outputs are presumed to only be valid if "amidst" dependencies thatmatch the declarations and such they were built against -- i.e. the headers, in C. If you are starting with a minimal install, with just m3core and libm3, then you mustbuildship and you must do it in dependency order. (I just derived this rule, might be wrong.) It only matters for certain types of changes, and then it can really matter. You might change the format of some compiler-produced runtime-consumed data. You might have a bunch of .sos/.dlls. They can only work with each other if they match in certain ways. Again, ways which don't change that often, but sometimes do -- like changing public types. This is why you can get "fingerprint mismatches" -- when code has different notions as to a type definition. I guess that is when the "ship checking" is either inadequate or circumvented. It makes me wonder. What if there was a compilation mode in which all types were opaque. If all record field access to records defined in other packages were implemented by non-inlined dynamically linked getter/setter functions. It would be slow. It would be much more amenable to type changes -- removal/renaming/retyping of existing fields being the remaining "problems". Actually adding would be a problem too, clients of the new could not run against the old. - 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 Sat Jan 19 01:50:35 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 19 Jan 2008 00:50:35 +0000 Subject: [M3devel] FW: buildlocal vs. buildglobal vs. buildship explanation Message-ID: Besides getting truncated, newlines often get stripped from my emails. I wish for working email.. From: jayk123 at hotmail.comTo: m3devel at elegosoft.comSubject: buildlocal vs. buildglobal vs. buildship explanationDate: Sat, 19 Jan 2008 00:47:11 +0000 I'm not sure I can explain this well or if I fully understand it. "Ship" means "Install" Let's say your install is atc:\cm3 and your source is at c:\dev2\cm3 (I would use dev, but Unix took it.) Depending on the state of things, you probably two of many things: c:\cm3\pkg\libm3\nt386\libm3.libc:\cm3\pkg\libm3\nt386\libm3.dllc:\dev2\cm3\m3-libs\libm3\nt386\libm3.libc:\dev2\cm3\m3-libs\libm3\nt386\libm3.dll You will have more in \dev2\cm3\m3-libs\libm3\nt386. When you build stuff, you can use the installed dependencies or the just built dependencies. buildlocal uses the just built dependencies. buildglobal uses the installed dependencies buildship build and ships (installs) each directoryIt does it in one pass: buildship pkg1 pkg1 => build pkg1 ship pkg1 build pkg2 ship pkg2 and NOT build pkg1 build pkg2 ship pkg1 ship pkg2 You may only ship/install outputs that are builtglobal.Outputs are presumed to only be valid if "amidst" dependencies thatmatch the declarations and such they were built against -- i.e. the headers, in C. If you are starting with a minimal install, with just m3core and libm3, then you mustbuildship and you must do it in dependency order. (I just derived this rule, might be wrong.) It only matters for certain types of changes, and then it can really matter. You might change the format of some compiler-produced runtime-consumed data. You might have a bunch of .sos/.dlls. They can only work with each other if they match in certain ways. Again, ways which don't change that often, but sometimes do -- like changing public types. This is why you can get "fingerprint mismatches" -- when code has different notions as to a type definition.I guess that is when the "ship checking" is either inadequate or circumvented. It makes me wonder.What if there was a compilation mode in which all types were opaque.If all record field access to records defined in other packages were implementedby non-inlined dynamically linked getter/setter functions.It would be slow. It would be much more amenable to type changes -- removal/renaming/retyping ofexisting fields being the remaining "problems".Actually adding would be a problem too, clients of the new could not run against the old. - 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 Jan 19 01:56:57 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 19 Jan 2008 00:56:57 +0000 Subject: [M3devel] FW: buildlocal vs. buildglobal vs. buildship explanation Message-ID: one more try darnit.... From: jayk123 at hotmail.comTo: jayk123 at hotmail.comSubject: buildlocal vs.Date: Sat, 19 Jan 2008 00:55:31 +0000 "Ship" means "Install" Let's say your install is at c:\cm3 and your source is at c:\dev2\cm3 (I would use dev, but Unix took it.) Depending on the state of things, you probably two of many things: c:\cm3\pkg\libm3\nt386\libm3.lib c:\cm3\pkg\libm3\nt386\libm3.dll c:\dev2\cm3\m3-libs\libm3\nt386\libm3.lib c:\dev2\cm3\m3-libs\libm3\nt386\libm3.dll You will have much more in \dev2\cm3\m3-libs\libm3\nt386. When you build stuff, you can use the installed dependencies or the just built dependencies. buildlocal uses the just built dependencies. buildglobal uses the installed dependencies buildship build and ships (installs) each directory It does it one pass: buildship pkg1 pkg1 => build pkg1 ship pkg1 build pkg2 ship pkg2 and NOT build pkg1 build pkg2 ship pkg1 ship pkg2 You may only ship/install outputs that are builtglobal. Outputs are presumed to only be valid if "amidst" dependencies that match the declarations and such they were built against -- i.e. the headers, in C. If you are starting with a minimal install, with just m3core and libm3, then you must buildship and you must do it in dependncy order. It only matters for certain types of changes, and then it can really matter. You might change the format of some compiler-produced runtime-consumed data. You might have a bunch of .sos/.dlls. They can only work with each other if they match in certain ways. Again, ways which don't change that often, but sometimes do -- like changing public types. - 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 rcoleburn at scires.com Sat Jan 19 02:35:55 2008 From: rcoleburn at scires.com (Randy Coleburn) Date: Fri, 18 Jan 2008 20:35:55 -0500 Subject: [M3devel] FW: buildlocal vs. buildglobal vs. buildship explanation In-Reply-To: References: Message-ID: <47910DA8.1E75.00D7.1@scires.com> Jay: I understand the cm3 package and build system. I just didn't know what "buildglobal" meant. >From your explanation, I take it that buildglobal = (cm3 -build) + (cm3 -ship) together on a per package basis. If this is true, then buildglobal == buildship; i.e., there is no difference. You stated that the default of the script is buildlocal and I gather buildlocal = (cm3 -build -override). If so, I now see why I was confused. The default for the compiler is not to include the overrides file (at least that is my recollection from the 4.1 days--maybe its different now). So in my way of thinking, buildlocal = (cm3 -build) without doing any shipping. Perhaps a more self-explanatory option name for (cm3 -build -override) would be "buildoverrides". The system won't let you ship a package built with overrides, so that is why I ran into trouble trying to get everything installed using do-cm3-std without passing the buildship or buildglobal option. I've always liked the cm3 way of having a private source package tree where folks work on the code and then having a separate public package tree where folks "ship" their finished product. Yes, I know you wind up having the code in two places, but then you can "clean" up the derived files in your private tree to save space if needed. The old "reactor" documentation did a fairly good job of explaining the cm3 package concept and the idea of public and private repositories. I'm attempting to convert this document into something we can put back in the cvs repository. I have to take out all the trademarks and replace the graphics etc so it is a painful process without the original electronic source. I've resorted to scanning it in via a scanner and making edits. Regards, Randy >>> Jay 1/18/2008 7:56 PM >>> one more try darnit.... From: jayk123 at hotmail.com To: jayk123 at hotmail.com Subject: buildlocal vs. Date: Sat, 19 Jan 2008 00:55:31 +0000 "Ship" means "Install" Let's say your install is at c:\cm3 and your source is at c:\dev2\cm3 (I would use dev, but Unix took it.) Depending on the state of things, you probably two of many things: c:\cm3\pkg\libm3\nt386\libm3.lib c:\cm3\pkg\libm3\nt386\libm3.dll c:\dev2\cm3\m3-libs\libm3\nt386\libm3.lib c:\dev2\cm3\m3-libs\libm3\nt386\libm3.dll You will have much more in \dev2\cm3\m3-libs\libm3\nt386. When you build stuff, you can use the installed dependencies or the just built dependencies. buildlocal uses the just built dependencies. buildglobal uses the installed dependencies buildship build and ships (installs) each directory It does it one pass: buildship pkg1 pkg1 => build pkg1 ship pkg1 build pkg2 ship pkg2 and NOT build pkg1 build pkg2 ship pkg1 ship pkg2 You may only ship/install outputs that are builtglobal. Outputs are presumed to only be valid if "amidst" dependencies that match the declarations and such they were built against -- i.e. the headers, in C. If you are starting with a minimal install, with just m3core and libm3, then you must buildship and you must do it in dependncy order. It only matters for certain types of changes, and then it can really matter. You might change the format of some compiler-produced runtime-consumed data. You might have a bunch of .sos/.dlls. They can only work with each other if they match in certain ways. Again, ways which don't change that often, but sometimes do -- like changing public types. - Jay 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 jayk123 at hotmail.com Sat Jan 19 03:03:00 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 19 Jan 2008 02:03:00 +0000 Subject: [M3devel] FW: buildlocal vs. buildglobal vs. buildship explanation In-Reply-To: <47910DA8.1E75.00D7.1@scires.com> References: <47910DA8.1E75.00D7.1@scires.com> Message-ID: No electronic source? Wow that stinks. cm3 = cm3 -build = "buildglobal" buildglobal != buildship buildglobal means to build against global, but not to ship It is the normal thing to do, I think, when you aren't changing "too much". If you are building something for which all dependencies have already shipped and aren't changing, a typical little utility. Or if you aren't changing the fingerprints of any public types, I think. Certainly if you are only changing code. Not sure about changing the revelations of partially opaque types. But maybe that's a gross simplification of what kind of development occurs. The doubling is mostly good. It fixes a problem well. However, I have some criticism, perhaps rooted in an inadequate understanding, I admit. 1) the ban on shipping having used overrides seems overly strict -- what if the fingerprints match? 2) perhaps some global fingerprint (hash) can be inserted after TARGET, enabling multiple versions to coexist in the same install root? But maybe that's just what you create a seperate install root for, since, I guess bin has to match pkg, so the whole tree is "ruined" anyway. x/* vs. */x in terms of directory layout. And maybe such a fingerprint would need too many bits to be reliable and then be annoyingly long. 3) This is the one I have the most confident understanding of -- as long as you are shipping "everything" all at once, I think shipping with overrides is just fine. There is a question as to what "everything" is. - Jay Date: Fri, 18 Jan 2008 20:35:55 -0500From: rcoleburn at scires.comTo: m3devel at elegosoft.com; jayk123 at hotmail.comSubject: Re: [M3devel] FW: buildlocal vs. buildglobal vs. buildship explanation Jay: I understand the cm3 package and build system. I just didn't know what "buildglobal" meant. >From your explanation, I take it that buildglobal = (cm3 -build) + (cm3 -ship) together on a per package basis. If this is true, then buildglobal == buildship; i.e., there is no difference. You stated that the default of the script is buildlocal and I gather buildlocal = (cm3 -build -override). If so, I now see why I was confused. The default for the compiler is not to include the overrides file (at least that is my recollection from the 4.1 days--maybe its different now). So in my way of thinking, buildlocal = (cm3 -build) without doing any shipping. Perhaps a more self-explanatory option name for (cm3 -build -override) would be "buildoverrides". The system won't let you ship a package built with overrides, so that is why I ran into trouble trying to get everything installed using do-cm3-std without passing the buildship or buildglobal option. I've always liked the cm3 way of having a private source package tree where folks work on the code and then having a separate public package tree where folks "ship" their finished product. Yes, I know you wind up having the code in two places, but then you can "clean" up the derived files in your private tree to save space if needed. The old "reactor" documentation did a fairly good job of explaining the cm3 package concept and the idea of public and private repositories. I'm attempting to convert this document into something we can put back in the cvs repository. I have to take out all the trademarks and replace the graphics etc so it is a painful process without the original electronic source. I've resorted to scanning it in via a scanner and making edits. Regards, Randy>>> Jay 1/18/2008 7:56 PM >>>one more try darnit.... From: jayk123 at hotmail.comTo: jayk123 at hotmail.comSubject: buildlocal vs.Date: Sat, 19 Jan 2008 00:55:31 +0000 "Ship" means "Install" Let's say your install is at c:\cm3 and your source is at c:\dev2\cm3 (I would use dev, but Unix took it.) Depending on the state of things, you probably two of many things: c:\cm3\pkg\libm3\nt386\libm3.lib c:\cm3\pkg\libm3\nt386\libm3.dll c:\dev2\cm3\m3-libs\libm3\nt386\libm3.lib c:\dev2\cm3\m3-libs\libm3\nt386\libm3.dll You will have much more in \dev2\cm3\m3-libs\libm3\nt386. When you build stuff, you can use the installed dependencies or the just built dependencies. buildlocal uses the just built dependencies. buildglobal uses the installed dependencies buildship build and ships (installs) each directory It does it one pass: buildship pkg1 pkg1 => build pkg1 ship pkg1 build pkg2 ship pkg2 and NOT build pkg1 build pkg2 ship pkg1 ship pkg2 You may only ship/install outputs that are builtglobal. Outputs are presumed to only be valid if "amidst" dependencies that match the declarations and such they were built against -- i.e. the headers, in C. If you are starting with a minimal install, with just m3core and libm3, then you must buildship and you must do it in dependncy order. It only matters for certain types of changes, and then it can really matter. You might change the format of some compiler-produced runtime-consumed data. You might have a bunch of .sos/.dlls. They can only work with each other if they match in certain ways. Again, ways which don't change that often, but sometimes do -- like changing public types. - Jay 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 jayk123 at hotmail.com Sat Jan 19 04:18:16 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 19 Jan 2008 03:18:16 +0000 Subject: [M3devel] NT386GNU diffs In-Reply-To: <4790E7A7.1E75.00D7.1@scires.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> <477EA137.1E75.00D7.1@scires.com> <478D394B.1E75.00D7.1@scires.com> <478D47FB.1E75.00D7.1@scires.com> <478DBF8D.1E75.00D7.1@scires.com> <478DE973.1E75.00D7.1@scires.com> <47908659.1E75.00D7.1@scires.com> <4790E7A7.1E75.00D7.1@scires.com> Message-ID: eh, the diffs are small enough - I commited them. The commit includes a stab at documenting how to build this stuff, but importantly, again, the results don't work.. - Jay From: jayk123 at hotmail.comTo: m3devel at elegosoft.comSubject: NT386GNU diffsDate: Fri, 18 Jan 2008 23:38:45 +0000 I think attached is all the diffs I have for NT386GNU.They are:"rewrite" NT386GNU config fileThe diff and result are present.It almost exactly matches NT386.In fact, the targets can perhaps be merged into one configurable target,and NT386GNU be "reclaimed" for the more Posix port people want.But not right now.setjmp to _setjmpThis "works" with Cygwin and MinGW, whereas setjmp doesn't."Works" as in links. I should double check this. Maybe not needed.Just one line..Changes NT386GNU from Posix to Win32.Any objects to commiting?The result is you can build a lot of NT386GNU, but it won't run.I would say it won't "quite" run, but I can't claim to know all that is wrong.Yes, I understand, getting it to run is very important. This may be progress,but isn't useful yet. - Jay 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 Sat Jan 19 04:29:11 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 19 Jan 2008 03:29:11 +0000 Subject: [M3devel] environment variable names? In-Reply-To: <4790E7A7.1E75.00D7.1@scires.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> <477EA137.1E75.00D7.1@scires.com> <478D394B.1E75.00D7.1@scires.com> <478D47FB.1E75.00D7.1@scires.com> <478DBF8D.1E75.00D7.1@scires.com> <478DE973.1E75.00D7.1@scires.com> <47908659.1E75.00D7.1@scires.com> <4790E7A7.1E75.00D7.1@scires.com> Message-ID: Approximately one of these I introduced an therefore might not be in the *.sh.Otherwise I believe these are all NOT my invention, and supported same/similarfor *.sh and *.py. *.cmd lags behind maybe. CM3_ROOT or ROOT is the root of the sourcescripts figures this out basedDOes anyone mind that it doesn't say "SOURCE", e.g. CM3_SOURCE_ROOT? I just introduced this recently: OPTIONALLY there is one generic cm3.cfg, m3-sys\cminstall\src\config\cm3.cfg, that delegates back to the live configuration files in that same directory. That file cannot determine this itself. If you cd around and run cm3, without using do-pkg etc., and you use this new cm3.cfg, you need to set CM3_ROOT or ROOT. CM3_INSTALL or INSTALLROOT are the root of the installed CM3. DOes any mind that the first one doesn't say "ROOT"? e.g. CM3_INSTALL_ROOT? CM3_TARGET or TARGET The target, duh. cm3.cfg sniffs this if $OS == NT386, otherwise not. Does any else mind that such generic global environment variables are queried? ROOT, INSTALLROOT, TARGET? It SEEMS TO ME, the ideal choices would be: CM3_INSTALL_ROOT CM3_SOURCE_ROOT or maybe just CM3_ROOT asis, hey, source is king, source is implied CM3_TARGET and no others. The Quake/.sh/.py code can use whatever it wants internally. It should probably just be left alone but I have to express my perfectionist opinion. :) I am tempted to drop the shorter names from the *.py though, which does make *.py and *.sh a bit less compatible. The scripts could/should also copy one to other for compat (esp. with older builds), reducing any affect here, but that saves people from polluting their global environment at least. ?? - 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 rcoleburn at scires.com Sat Jan 19 06:31:21 2008 From: rcoleburn at scires.com (Randy Coleburn) Date: Sat, 19 Jan 2008 00:31:21 -0500 Subject: [M3devel] pixmap problem Message-ID: <479144D6.1E75.00D7.1@scires.com> I've attached a small zip file containing a simple test program. On Windows XP using the current cm3 from the repository I get the following behavior: a) when the buildstandalone() line is commented out in the m3makefile, the pixmap is rendered poorly on the screen. It has gray streaked lines through it. b) when the buildstandalone() directive is used in the m3makefile, the pixmap is rendered properly on the screen. This program uses pixmaps and bundles. I'm also seeing some problems with bundles, so the two problems may be related, but I'm not sure. Would some of the other developers mind running this simple test program on their platforms and reporting the results. I'd like to know if the problem is limited to Windows NT386 platform, or if it occurs on others. Thanks, Randy Coleburn -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: TestPixmap.zip Type: application/x-zip-compressed Size: 4870 bytes Desc: not available URL: From jayk123 at hotmail.com Sat Jan 19 06:46:37 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 19 Jan 2008 05:46:37 +0000 Subject: [M3devel] strange code? Message-ID: I'm comparing the output of the two backends, since I haven't figured out many gdb commands yet. Well darn the code looks semantically the same around the crash so I'll have to dig differently. Still, why does it bump the stack extra like this: subl $8, %esp <== pushl %eax pushl %edx call _RTLinker__TraceModule addl $16, %esp <== the other backend uses 8 here subl $12, %esp <== pushl $0 call *%eax addl $16, %esp <== the other uses 4 Is it trying to keep the stack 16-aligned? - 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 hosking at cs.purdue.edu Sat Jan 19 09:09:47 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 19 Jan 2008 03:09:47 -0500 Subject: [M3devel] pixmap problem In-Reply-To: <479144D6.1E75.00D7.1@scires.com> References: <479144D6.1E75.00D7.1@scires.com> Message-ID: <0CF197B5-1ADA-4955-904A-7B4ABACE7652@cs.purdue.edu> Looks fine to me on I386_DARWIN. On Jan 19, 2008, at 12:31 AM, Randy Coleburn wrote: > From hosking at cs.purdue.edu Sat Jan 19 09:12:12 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 19 Jan 2008 03:12:12 -0500 Subject: [M3devel] strange code? In-Reply-To: References: Message-ID: Yes, indeed. I believe gcc will try to keep the stack 16-byte aligned. I seem to recall that there are alignment configuration values in the compiler that might cause a crash if set wrong. On Jan 19, 2008, at 12:46 AM, Jay wrote: > I'm comparing the output of the two backends, since I haven't > figured out many gdb commands yet. > Well darn the code looks semantically the same around the crash so > I'll have to dig differently. > > Still, why does it bump the stack extra like this: > > subl $8, %esp <== > pushl %eax > pushl %edx > call _RTLinker__TraceModule > addl $16, %esp <== the other backend uses 8 here > > > subl $12, %esp <== > pushl $0 > call *%eax > addl $16, %esp <== the other uses 4 > > Is it trying to keep the stack 16-aligned? > > - 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 Sat Jan 19 09:52:08 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 19 Jan 2008 08:52:08 +0000 Subject: [M3devel] pixmap problem In-Reply-To: <0CF197B5-1ADA-4955-904A-7B4ABACE7652@cs.purdue.edu> References: <479144D6.1E75.00D7.1@scires.com> <0CF197B5-1ADA-4955-904A-7B4ABACE7652@cs.purdue.edu> Message-ID: I can repro the two different behaviors on XP. I was going to try on PPC_DARWIN but I guess Tony's info suffices. I tried rolling hand.c back to before I changed (months/year ago), since it is involved in bit twiddling, no change, phew. Debugging here is a big humungous pain. NT386 has good stacks and line numbers, but no locals or type info, I'd really sometime like to get Codeview info into those .objs...I think it is documented well enough, but still not necessarily easy, or maybe have a C generating backend partly for this reason (and to bring up more targets, using native tools), and function calls in disassembly I think don't resolve; NT386GNU can't yet build this, though it will soon, but I'm not familiar with gdb and there appears to be no type info. I'm building m3gdb right now, I don't know if it will work, I hope it has type info, and I'm not familiar with the relevant code. In gdb I struggle just to view bytes in memory, add numbers to addresses and see those, etc. I think for MY problem, I'm going to link in C code to dump the structs. There is tracing code and I enabled it, but even it crashes in Text_Length. At least MY problem crashes, hopefully near the problem, whereas your problem goes all the way through to completion with no stopping to hint where the problem is. Darn it. :) on the mock rudeness and :( on the lack of a crash. You write the bundle out and it matches, so that doesn't rule out bundles as being the problem? (darn) And bundles look pretty simple, a bundle is just a generated source file with a constant in it. Maybe newline problems? That wouldn't make sense. I just downloaded some program that might let me separately view the ppm, maybe it'll reveal something. The bad behavior has like regularly spaced solid color veritical bars a few pixels side across the whole picture, and regularly spaced vertical stripes from the correct picture alternating with that. Perhaps someone with ppm/bitmap/graphics experience has seen this behavior and it results from some common pixmap mismanagement we could look for? I have to say this is very surprising. I always wondered, and now I pretty much assume -- Modula-3 never imports/exports data in its dynamic linking, right? It alway imports/exports functions, right? On Windows, functions have an optional optimization, but data must be handled differently at compile time if it is going to be dynamically imported. For functions, if you don't apply the optimization at compile time, the linker will just generate a single instruction thunk instead. That is, given a symbol Foo, there is a symbol __imp__Foo that is a pointer to the actual foo in another .dll/.so. The loader only patches pointers, one per import if you build your .dll correctly, it doesn't patch instructions or code strewn throughout a .dll, just one contiguous array of pointers. MAYBE they don't have to be contiguous for each .dl you import from. That is, if call msvcrt!fopen, msvcrt!fclose, kernel32!Sleep, my .dll/.exe typically has an array: pointer to msvcrt!fopen pointer to msvcrt!fclose null pointer to kernel32!Sleep But perhaps kernel32.dll's pointers and msvcrt.dll's pointers need not be adjacent. So, going back, my point/question is that, if the compiler knows the function is imported, it can call through __imp__Foo instead of calling Foo. But if it calls Foo and you import Foo, the linker will create the function Foo that just jmps through __imp__Foo. That doesn't work for data though. There's no ability to intervenve like that. So for imported data, the compiler must generated a read and dereference of the pointer __imp__Foo for accesses to Foo, if Foo is to be imported. Data imports may be faster when appropriate, but for this reason, I'd say they aren't worth it. And for this reason, I HOPE Modula-3 never imports/exports data. Oh, you could, for data, always reference the pointer __imp_Foo, and if non materializes, create one. However that would suck perf in order to make an uncommon case work. I hope Modula-3 doesn't do that either. :) Though I guess since this global data in question...maybe it is rare??? Later, - Jay > From: hosking at cs.purdue.edu> Date: Sat, 19 Jan 2008 03:09:47 -0500> To: rcoleburn at scires.com> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] pixmap problem> > Looks fine to me on I386_DARWIN.> > On Jan 19, 2008, at 12:31 AM, Randy Coleburn wrote:> > > > _________________________________________________________________ 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 Jan 19 09:55:12 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 19 Jan 2008 08:55:12 +0000 Subject: [M3devel] pixmap problem In-Reply-To: References: <479144D6.1E75.00D7.1@scires.com> <0CF197B5-1ADA-4955-904A-7B4ABACE7652@cs.purdue.edu> Message-ID: and then wouldn't you know...the end of gdb building looks like: Info: resolving _LINES by linking to __imp__LINES (auto-import)Info: resolving _COLS by linking to __imp__COLS (auto-import)Info: resolving _stdscr by linking to __imp__stdscr (auto-import)Info: resolving _curscr by linking to __imp__curscr (auto-import)make[3]: Entering directory `/cygdrive/c/dev2/cm3.2/m3-sys/m3gdb/NT386GNU/gdb'make[4]: Entering directory `/cygdrive/c/dev2/cm3.2/m3-sys/m3gdb/NT386GNU/gdb/doc'make[4]: Nothing to be done for `all'.make[4]: Leaving directory `/cygdrive/c/dev2/cm3.2/m3-sys/m3gdb/NT386GNU/gdb/doc'make[3]: Leaving directory `/cygdrive/c/dev2/cm3.2/m3-sys/m3gdb/NT386GNU/gdb'make[2]: Leaving directory `/cygdrive/c/dev2/cm3.2/m3-sys/m3gdb/NT386GNU/gdb'make[1]: Leaving directory `/cygdrive/c/dev2/cm3.2/m3-sys/m3gdb/NT386GNU'make[1]: Entering directory `/cygdrive/c/dev2/cm3.2/m3-sys/m3gdb/NT386GNU'make[1]: Nothing to be done for `all-target'.make[1]: Leaving directory `/cygdrive/c/dev2/cm3.2/m3-sys/m3gdb/NT386GNU' Fatal Error: unable to copy "gdb/gdb" to "m3gdb": ErrorCode=2: The system cannot find the file specified. ###################### LINK_FILE: ################## But I don't see any errros before that...I think I'm just forgetting to append .exe. - Jay From: jayk123 at hotmail.comSo for imported data, the compiler must generated a read and dereference of the pointer __imp__Foo for accesses to Foo, if Foo is to be imported.Data imports may be faster when appropriate, but for this reason, I'd say they aren't worth it.And for this reason, I HOPE Modula-3 never imports/exports data. Oh, you could, for data, always reference the pointer __imp_Foo, and if non materializes, create one.However that would suck perf in order to make an uncommon case work.I hope Modula-3 doesn't do that either. :)Though I guess since this global data in question...maybe it is rare??? Later, - 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 Sat Jan 19 12:02:59 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 19 Jan 2008 11:02:59 +0000 Subject: [M3devel] more assembly symbols please? Message-ID: Any chance the m3cg output could have, um, some symbols for the global data? It's kind of a pain to decode.. The module/import info is ok a lot, lots of runtime links ok. I think the bad one might be RTHeapInfo but I have to decode the very bare of symbols assembly.. or comments? Like for record fields? Still thinking of sticking a call out to C code...Even OutputDebugString since RTIO isn't working... I looked through the m3cg --help, didn't find anything. Tony? _MM_RTHeapInfo:0 .long _L_1+224 4 .long _MM_RTHeapInfo+528 .long _MM_RTHeapInfo+30812,16 .space 820 .long _L_1+15224 .space 428 .long _L_1+22032 .long _L_1+22036 .long _MM_RTHeapInfo+16040 .space 4 .long _RTHeapInfo_M3 I get to count out to 160 bytes from here..: _L_1:0 .byte 481 .byte 492 .byte 503 .byte 514 .byte 525 .byte 536 .byte 547 .byte 558 .byte 569 .byte 57a .byte 97b .byte 98c .byte 99d .byte 100e .byte 101f .byte 10210 .long _RTHooks__TextLitInfo14 .long _RTHooks__TextLitGetChar18 .long _RTHooks__TextLitGetWideChar1c .long _RTHooks__TextLitGetChars20 .long _RTHooks__TextLitGetWideChars24 .long 228 .long _L_1+162c .long 730 .ascii "shownew"37 .space 138 .long 23c .long _L_1+1640 .long 644 .ascii "update"4a .space 24c .ascii "RTHeapInfo_M3"50 .space 1 .ascii "Init" .space 1 I'll try the C code.. - 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 Sat Jan 19 12:08:19 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 19 Jan 2008 11:08:19 +0000 Subject: [M3devel] more assembly symbols please? In-Reply-To: References: Message-ID: oh I've got two better ideas 1) move RTIO ahead of RTHeapInfo, or earlier, in the unit list 2) paste the RTIO code into RTLinker so calling it doesn't depend on linking!And now I see the command line check for tracing comes after some linking, for good reason. I had set the global to true in the source, and that is probably bad. I'm not sure though within a module if the linking is needed, or if it is only for cross-module references.. - Jay From: jayk123 at hotmail.comTo: m3devel at elegosoft.comDate: Sat, 19 Jan 2008 11:02:59 +0000Subject: [M3devel] more assembly symbols please? Any chance the m3cg output could have, um, some symbols for the global data?It's kind of a pain to decode.. The module/import info is ok a lot, lots of runtime links ok.I think the bad one might be RTHeapInfo but I have to decode the very bare of symbols assembly..or comments? Like for record fields?Still thinking of sticking a call out to C code...Even OutputDebugString since RTIO isn't working... I looked through the m3cg --help, didn't find anything. Tony? _MM_RTHeapInfo:0 .long _L_1+224 4 .long _MM_RTHeapInfo+528 .long _MM_RTHeapInfo+30812,16 .space 820 .long _L_1+15224 .space 428 .long _L_1+22032 .long _L_1+22036 .long _MM_RTHeapInfo+16040 .space 4 .long _RTHeapInfo_M3I get to count out to 160 bytes from here..: _L_1:0 .byte 481 .byte 492 .byte 503 .byte 514 .byte 525 .byte 536 .byte 547 .byte 558 .byte 569 .byte 57a .byte 97b .byte 98c .byte 99d .byte 100e .byte 101f .byte 10210 .long _RTHooks__TextLitInfo14 .long _RTHooks__TextLitGetChar18 .long _RTHooks__TextLitGetWideChar1c .long _RTHooks__TextLitGetChars20 .long _RTHooks__TextLitGetWideChars24 .long 228 .long _L_1+162c .long 730 .ascii "shownew"37 .space 138 .long 23c .long _L_1+1640 .long 644 .ascii "update"4a .space 24c .ascii "RTHeapInfo_M3"50 .space 1 .ascii "Init" .space 1I'll try the C code.. - Jay Connect and share in new ways with Windows Live. Get it 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 jayk123 at hotmail.com Sat Jan 19 12:32:21 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 19 Jan 2008 11:32:21 +0000 Subject: [M3devel] more assembly symbols please? In-Reply-To: References: Message-ID: duh, finally, got it. parameters being passed in the wrong order -- left to right instead of right to left. should have read the assembly of some multi parameter function calls... PROCEDURE RTLinker_PutInt (i: INTEGER; width := 0) = VAR num : ARRAY [0..30] OF CHAR; len := FromInt (ADR (num[0]), i, 10); BEGIN FOR i := 1 TO width - len DO PutChar (' ') END; PutChars (ADR (num[0]), len); END RTLinker_PutInt;Dump of assembler code for function RTLinker__RTLinker_PutInt:0x005de25f : push %ebp0x005de260 : mov %esp,%ebp0x005de262 : sub $0x38,%esp0x005de265 : mov 0x8(%ebp),%edx0x005de268 : sub $0x4,%esp0x005de26b : lea 0xffffffd9(%ebp),%eax0x005de26e : push %eax0x005de26f : push %edx0x005de270 : push $0xa0x005de272 : call 0x5de345 and I AVed writing to the address 0xA.. - 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 Sat Jan 19 15:33:08 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 19 Jan 2008 14:33:08 +0000 Subject: [M3devel] link info still bad. In-Reply-To: References: Message-ID: clarification -- RTLinker still crashes. I put in C code to dump, since it crashes before its own printing would work.A bunch works and then: Module 00682020 ..\src\runtime\common\RTHeapInfo.m3 Imports 006820C0{Import 00000000, Binder 00000000, Next 00603FD0} and then the dumper AV's because the next pointer is bad. 0:000> dc 00603FD000603fd0 8be58955 c0b80845 c900682a 909090c3 U...E...*h......00603fe0 8be58955 80b80845 c900682b e58955c3 U...E...+h...U..00603ff0 ec835657 08458b20 8904c083 2be8a1c2 WV.. .E........+00604000 f4050068 8b000000 dc7d8d00 b8fcc689 h.........}.....00604010 00000007 a5f3c189 758dd789 07b8fcdc ...........u....00604020 89000000 83a5f3c1 5f5e20c4 9090c3c9 ......... ^_....00604030 8be58955 60b80845 c900682c 909090c3 U...E..`,h......00604040 8be58955 00b80845 c900682d 909090c3 U...E...-h...... anything over 0x80000000, or depending on configuration, 0xc0000000, is an invalid user mode pointer on 32bit NT. The address space is usually split 2gig/2gig, the upper 2gig is the kernel memory, the same mappings system side. There is an option to make it 3gig/1gig. If anyone has any hints, please tell me, thanks. If anyone else can build this stuff...? I can commit the printing to be only on this platform... The assembly code output by cm3cg is much harder to read than it should be, even for assembly language.. :( Attached. - Jay From: jayk123 at hotmail.comTo: m3devel at elegosoft.comSubject: RE: [M3devel] more assembly symbols please?Date: Sat, 19 Jan 2008 11:32:21 +0000 duh, finally, got it. parameters being passed in the wrong order -- left to right instead of right to left.should have read the assembly of some multi parameter function calls... PROCEDURE RTLinker_PutInt (i: INTEGER; width := 0) = VAR num : ARRAY [0..30] OF CHAR; len := FromInt (ADR (num[0]), i, 10); BEGIN FOR i := 1 TO width - len DO PutChar (' ') END; PutChars (ADR (num[0]), len); END RTLinker_PutInt;Dump of assembler code for function RTLinker__RTLinker_PutInt:0x005de25f : push %ebp0x005de260 : mov %esp,%ebp0x005de262 : sub $0x38,%esp0x005de265 : mov 0x8(%ebp),%edx0x005de268 : sub $0x4,%esp0x005de26b : lea 0xffffffd9(%ebp),%eax0x005de26e : push %eax0x005de26f : push %edx0x005de270 : push $0xa0x005de272 : call 0x5de345 and I AVed writing to the address 0xA.. - 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: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: RTHeapIn.ms URL: From dabenavidesd at yahoo.es Sat Jan 19 17:54:00 2008 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Sat, 19 Jan 2008 17:54:00 +0100 (CET) Subject: [M3devel] pixmap problem In-Reply-To: Message-ID: <235688.77597.qm@web27110.mail.ukl.yahoo.com> Hi: The TestPixmap does show a nice battery on LINUXLIBC6, Ubuntu Gutsy 2.6.22-14-386, 32 bits machine. Thanks Jay wrote: .hmmessage P { margin:0px; padding:0px } body.hmmessage { FONT-SIZE: 10pt; FONT-FAMILY:Tahoma } I can repro the two different behaviors on XP. I was going to try on PPC_DARWIN but I guess Tony's info suffices. I tried rolling hand.c back to before I changed (months/year ago), since it is involved in bit twiddling, no change, phew. Debugging here is a big humungous pain. NT386 has good stacks and line numbers, but no locals or type info, I'd really sometime like to get Codeview info into those .objs...I think it is documented well enough, but still not necessarily easy, or maybe have a C generating backend partly for this reason (and to bring up more targets, using native tools), and function calls in disassembly I think don't resolve; NT386GNU can't yet build this, though it will soon, but I'm not familiar with gdb and there appears to be no type info. I'm building m3gdb right now, I don't know if it will work, I hope it has type info, and I'm not familiar with the relevant code. In gdb I struggle just to view bytes in memory, add numbers to addresses and see those, etc. I think for MY problem, I'm going to link in C code to dump the structs. There is tracing code and I enabled it, but even it crashes in Text_Length. At least MY problem crashes, hopefully near the problem, whereas your problem goes all the way through to completion with no stopping to hint where the problem is. Darn it. :) on the mock rudeness and :( on the lack of a crash. You write the bundle out and it matches, so that doesn't rule out bundles as being the problem? (darn) And bundles look pretty simple, a bundle is just a generated source file with a constant in it. Maybe newline problems? That wouldn't make sense. I just downloaded some program that might let me separately view the ppm, maybe it'll reveal something. The bad behavior has like regularly spaced solid color veritical bars a few pixels side across the whole picture, and regularly spaced vertical stripes from the correct picture alternating with that. Perhaps someone with ppm/bitmap/graphics experience has seen this behavior and it results from some common pixmap mismanagement we could look for? I have to say this is very surprising. I always wondered, and now I pretty much assume -- Modula-3 never imports/exports data in its dynamic linking, right? It alway imports/exports functions, right? On Windows, functions have an optional optimization, but data must be handled differently at compile time if it is going to be dynamically imported. For functions, if you don't apply the optimization at compile time, the linker will just generate a single instruction thunk instead. That is, given a symbol Foo, there is a symbol __imp__Foo that is a pointer to the actual foo in another .dll/.so. The loader only patches pointers, one per import if you build your .dll correctly, it doesn't patch instructions or code strewn throughout a .dll, just one contiguous array of pointers. MAYBE they don't have to be contiguous for each .dl you import from. That is, if call msvcrt!fopen, msvcrt!fclose, kernel32!Sleep, my .dll/.exe typically has an array: pointer to msvcrt!fopen pointer to msvcrt!fclose null pointer to kernel32!Sleep But perhaps kernel32.dll's pointers and msvcrt.dll's pointers need not be adjacent. So, going back, my point/question is that, if the compiler knows the function is imported, it can call through __imp__Foo instead of calling Foo. But if it calls Foo and you import Foo, the linker will create the function Foo that just jmps through __imp__Foo. That doesn't work for data though. There's no ability to intervenve like that. So for imported data, the compiler must generated a read and dereference of the pointer __imp__Foo for accesses to Foo, if Foo is to be imported. Data imports may be faster when appropriate, but for this reason, I'd say they aren't worth it. And for this reason, I HOPE Modula-3 never imports/exports data. Oh, you could, for data, always reference the pointer __imp_Foo, and if non materializes, create one. However that would suck perf in order to make an uncommon case work. I hope Modula-3 doesn't do that either. :) Though I guess since this global data in question...maybe it is rare??? Later, - Jay --------------------------------- > From: hosking at cs.purdue.edu > Date: Sat, 19 Jan 2008 03:09:47 -0500 > To: rcoleburn at scires.com > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] pixmap problem > > Looks fine to me on I386_DARWIN. > > On Jan 19, 2008, at 12:31 AM, Randy Coleburn wrote: > > > > --------------------------------- Need to know the score, the latest news, or you need your Hotmail?-get your "fix" Check it out. --------------------------------- Web Revelaci?n Yahoo! 2007: Premio Favorita del P?blico - ?Vota tu preferida! -------------- next part -------------- An HTML attachment was scrubbed... URL: From hendrik at topoi.pooq.com Sat Jan 19 18:30:02 2008 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Sat, 19 Jan 2008 12:30:02 -0500 Subject: [M3devel] new name for "reactor" In-Reply-To: <4790892B.1E75.00D7.1@scires.com> References: <4790892B.1E75.00D7.1@scires.com> Message-ID: <20080119173002.GB32561@topoi.pooq.com> On Fri, Jan 18, 2008 at 11:10:38AM -0500, Randy Coleburn wrote: > > Originally, I chose the name "CM3-IDE" for CM3 Integrated Development Environment, but this name isn't very catchy. Actually, CM3-IDE (or perhaps better cm3-ide) isn't bad -- it makes it completely clear what the package is. cm3-catalyst makes people wonder what it does, whether they need it, and whether they should spend disk space to install it. -- hendrik From hosking at cs.purdue.edu Sat Jan 19 18:33:08 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 19 Jan 2008 12:33:08 -0500 Subject: [M3devel] more assembly symbols please? In-Reply-To: References: Message-ID: <2717B275-2548-41BC-BD1E-8742BCE6FA51@cs.purdue.edu> Take a look at the .mc intermediate code output if you want to see that section of the data. There are at least comments. Use m3cgcat - binary < x.mc > x.mo to view it (You can run m3cgcat on any other CM3 install). On Jan 19, 2008, at 6:02 AM, Jay wrote: > Any chance the m3cg output could have, um, some symbols for the > global data? > It's kind of a pain to decode.. > > The module/import info is ok a lot, lots of runtime links ok. > I think the bad one might be RTHeapInfo but I have to decode the > very bare of symbols assembly.. > or comments? Like for record fields? > Still thinking of sticking a call out to C code...Even > OutputDebugString since RTIO isn't working... > > I looked through the m3cg --help, didn't find anything. > > Tony? > > _MM_RTHeapInfo: > 0 .long _L_1+224 > 4 .long _MM_RTHeapInfo+52 > 8 .long _MM_RTHeapInfo+308 > 12,16 .space 8 > 20 .long _L_1+152 > 24 .space 4 > 28 .long _L_1+220 > 32 .long _L_1+220 > 36 .long _MM_RTHeapInfo+160 > 40 .space 4 > .long _RTHeapInfo_M3 > > I get to count out to 160 bytes from here..: > > _L_1: > 0 .byte 48 > 1 .byte 49 > 2 .byte 50 > 3 .byte 51 > 4 .byte 52 > 5 .byte 53 > 6 .byte 54 > 7 .byte 55 > 8 .byte 56 > 9 .byte 57 > a .byte 97 > b .byte 98 > c .byte 99 > d .byte 100 > e .byte 101 > f .byte 102 > 10 .long _RTHooks__TextLitInfo > 14 .long _RTHooks__TextLitGetChar > 18 .long _RTHooks__TextLitGetWideChar > 1c .long _RTHooks__TextLitGetChars > 20 .long _RTHooks__TextLitGetWideChars > 24 .long 2 > 28 .long _L_1+16 > 2c .long 7 > 30 .ascii "shownew" > 37 .space 1 > 38 .long 2 > 3c .long _L_1+16 > 40 .long 6 > 44 .ascii "update" > 4a .space 2 > 4c .ascii "RTHeapInfo_M3" > 50 .space 1 > .ascii "Init" > .space 1 > > I'll try the C code.. > > - Jay > > > > > > Connect and share in new ways with Windows Live. Get it now! From hosking at cs.purdue.edu Sat Jan 19 18:43:16 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 19 Jan 2008 12:43:16 -0500 Subject: [M3devel] new name for "reactor" In-Reply-To: <20080119173002.GB32561@topoi.pooq.com> References: <4790892B.1E75.00D7.1@scires.com> <20080119173002.GB32561@topoi.pooq.com> Message-ID: <8BE9BB1C-5120-4D4E-AEC1-FE1BBF729AA4@cs.purdue.edu> I second this opinion: On Jan 19, 2008, at 12:30 PM, hendrik at topoi.pooq.com wrote: >> Actually, CM3-IDE (or perhaps better cm3-ide) isn't bad -- it >> makes it > completely clear what the package is. cm3-catalyst makes people > wonder > what it does, whether they need it, and whether they should spend disk > space to install it. > > -- hendrik From hosking at cs.purdue.edu Sat Jan 19 18:48:06 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 19 Jan 2008 12:48:06 -0500 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <20080119031134.4B6A510D4625@birch.elegosoft.com> References: <20080119031134.4B6A510D4625@birch.elegosoft.com> Message-ID: So, I am very confused now. Does NT386GNU no longer mean use of the full set of GNU tools m3cc/ld/as, as would be available under Cygwin? I thought the point of this was to be able to run in as much of a GNU environment as possible. GNU to me means the whole toolsuite not just m3cc. To me, a GNU-based environment on Windows holds great attraction, since it consists of tools that I generally always install on Windows, that I know, and are similar to the other platforms I use. On Jan 19, 2008, at 4:11 AM, Jay Krell wrote: > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 08/01/19 04:11:34 > > Modified files: > cm3/m3-libs/m3core/src/runtime/: m3makefile > cm3/m3-sys/cminstall/src/config/: NT386GNU > cm3/m3-sys/m3front/src/builtinInfo/: InfoModule.m3 > cm3/m3-sys/m3middle/src/: Target.m3 > > Log message: > m3-sys/m3middle/src/Target.m3 > m3-libs/m3core/src/runtime/m3makefile > m3-sys\m3front\src\builtinInfo\InfoModule.m3 > > switch NT386GNU to be Win32 instead of POSIX > switch NT386GNU to _setjmp instead of setjmp > jmp_buf size still big like Cygwin > rewrite NT386GNU config file -- almost identical to NT386 > mingwin required for building Modula-3 programs > mingwin AND msys required for building m3cc > > To boot: > > install Python (www.activestate.com) > > have a working NT386 system > get current source > Mine is at c:\dev2\cm3.2 (cm3 is has other paused work, dev was > taken by Unix) > > get and install binary distribution (5.1.3 works, anything newer > should work) > I install to c:\cm3 > copy %CVSROOT%\m3-sys\cminstall\src\config\cm3.cfg to \cm3\bin > \cm3.cfg > > Have a Visual C++ toolset (cl and link) > and run the vcvars link on the start menu (this can/will be made > easier) > Almost any version should work. > if you are using Visual C++ 8.0 (RTM?), rename away its mt.exe > and get a newer from such as from the Platform SDK. Otherwise it > crashes. > This is not specific to NT386GNU, just that I recently removed the > Platform SDK > from my %PATH%. > > cd %CVSROOT%\scripts\python > .\upgrade > > install msys and mingwin from http://www.mingw.org (links to > SourceForge) > for mingwin, you only need the "base" > msys tells you to avoid mingwin make, in favor of msys make, and I > did that > > I install to the defaults > c:\msys\1.0 > c:\mingw > > if you don't install to the defaults, add > \bin and to the start, but which order between the two?) > > if you do install to the defaults, scripts\python will fix path > for you, > if there is no gcc/as/sh on our $PATH > > cd %CVSROOT%\scripts\python > upgrade && bootntgnu > > NOTE THE RESULTING BINARIES DO NOT YET WORK, but this is still > progress. > > These instructions inevitably to be further tested and refined and > placed elsewhere! From jayk123 at hotmail.com Sat Jan 19 19:32:35 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 19 Jan 2008 18:32:35 +0000 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: References: <20080119031134.4B6A510D4625@birch.elegosoft.com> Message-ID: It DOES use m3cc/ld/as, and mklib for building static .libs, though that could probably be gcc/ar/dlltools if I figured it out. "Everything" except m3cc/m3gdb can be built with just MinGWin. Building m3cc requires MSys as well. Building m3gdb requires Cygwin. m3cg is not dependent on cygwin1.dll, nor are any other Modula-3 outputs. m3gdb is dependent on cygwin1.dll. Using Cygwin probably would work..and I could try it to see if it resolves the RTLinker problem. As well, we could have something like, in cm3.cfg you could set MINGWIN_ROOT, MSYS_ROOT, and/or CYGWIN_ROOT, to guide what tools are used, OR we can have some variable: GNU_MODE = 0 % Do not use GNU tools at all -- today's NT386 GNU_MODE = 1 % Use GNU tools minimally -- today's NT386GNU GNU_MODE = 2 % Use GNU tools maximally -- not existant but probably easy Eh..I know, not great.. what do "minimally" and "maximally" mean. I think we have the problem of a) many viable choices b) want to make several of them available c) just don't know what to call things and what the interface should be. As well as an interop question, since jmpbuf does vary in size between cygwin1.dl and everything else. Further down the line, there are other linkers, other compilers, other runtimes. The design here and now might take them into consideration. Gasp..I just realized, there is also another good backend option. parse.c's approach could probably be adapted to Open Watcom AND they might even take the changes (not that I have asked, I just thought of this). And that would net you progress toward a) 32 bit MS-DOS target b) OS/2 target, c) Netware target d) gcc-free Linux target, since the support all of them. Other target possibilities include Digital Mars compiler/linker, CodeWarrior (I know, dead and all), etc. Open Watcom is probably the most interesting since it is open source... - Jay > From: hosking at cs.purdue.edu> Date: Sat, 19 Jan 2008 12:48:06 -0500> To: jkrell at elego.de> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] [M3commit] CVS Update: cm3> > So, I am very confused now. Does NT386GNU no longer mean use of the > full set of GNU tools m3cc/ld/as, as would be available under > Cygwin? I thought the point of this was to be able to run in as much > of a GNU environment as possible. GNU to me means the whole > toolsuite not just m3cc. To me, a GNU-based environment on Windows > holds great attraction, since it consists of tools that I generally > always install on Windows, that I know, and are similar to the other > platforms I use.> > On Jan 19, 2008, at 4:11 AM, Jay Krell wrote:> > > CVSROOT: /usr/cvs> > Changes by: jkrell at birch. 08/01/19 04:11:34> >> > Modified files:> > cm3/m3-libs/m3core/src/runtime/: m3makefile> > cm3/m3-sys/cminstall/src/config/: NT386GNU> > cm3/m3-sys/m3front/src/builtinInfo/: InfoModule.m3> > cm3/m3-sys/m3middle/src/: Target.m3> >> > Log message:> > m3-sys/m3middle/src/Target.m3> > m3-libs/m3core/src/runtime/m3makefile> > m3-sys\m3front\src\builtinInfo\InfoModule.m3> > > > switch NT386GNU to be Win32 instead of POSIX> > switch NT386GNU to _setjmp instead of setjmp> > jmp_buf size still big like Cygwin> > rewrite NT386GNU config file -- almost identical to NT386> > mingwin required for building Modula-3 programs> > mingwin AND msys required for building m3cc> > > > To boot:> > > > install Python (www.activestate.com)> > > > have a working NT386 system> > get current source> > Mine is at c:\dev2\cm3.2 (cm3 is has other paused work, dev was > > taken by Unix)> > > > get and install binary distribution (5.1.3 works, anything newer > > should work)> > I install to c:\cm3> > copy %CVSROOT%\m3-sys\cminstall\src\config\cm3.cfg to \cm3\bin > > \cm3.cfg> > > > Have a Visual C++ toolset (cl and link)> > and run the vcvars link on the start menu (this can/will be made > > easier)> > Almost any version should work.> > if you are using Visual C++ 8.0 (RTM?), rename away its mt.exe> > and get a newer from such as from the Platform SDK. Otherwise it > > crashes.> > This is not specific to NT386GNU, just that I recently removed the > > Platform SDK> > from my %PATH%.> > > > cd %CVSROOT%\scripts\python> > .\upgrade> > > > install msys and mingwin from http://www.mingw.org (links to > > SourceForge)> > for mingwin, you only need the "base"> > msys tells you to avoid mingwin make, in favor of msys make, and I > > did that> > > > I install to the defaults> > c:\msys\1.0> > c:\mingw> > > > if you don't install to the defaults, add> > \bin and > to the start, but which order between the two?)> > > > if you do install to the defaults, scripts\python will fix path > > for you,> > if there is no gcc/as/sh on our $PATH> > > > cd %CVSROOT%\scripts\python> > upgrade && bootntgnu> > > > NOTE THE RESULTING BINARIES DO NOT YET WORK, but this is still > > progress.> > > > These instructions inevitably to be further tested and refined and > > placed elsewhere!> _________________________________________________________________ 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 Jan 19 19:35:09 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 19 Jan 2008 18:35:09 +0000 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: References: <20080119031134.4B6A510D4625@birch.elegosoft.com> Message-ID: ps -- look at m3-sys/cminstall/src/config/NT386GNU. While it is very very similar to NT386, and even outputs foo.lib and foo.lib.sa like NT386, it uses gcc for C compilation, linking, and m3cg for the backend. It is very "GNU" in tools, but not runtime. - Jay From: jayk123 at hotmail.comTo: hosking at cs.purdue.edu; jkrell at elego.deCC: m3devel at elegosoft.comSubject: RE: [M3devel] [M3commit] CVS Update: cm3Date: Sat, 19 Jan 2008 18:32:35 +0000 It DOES use m3cc/ld/as, and mklib for building static .libs, though that could probably be gcc/ar/dlltools if I figured it out."Everything" except m3cc/m3gdb can be built with just MinGWin.Building m3cc requires MSys as well.Building m3gdb requires Cygwin.m3cg is not dependent on cygwin1.dll, nor are any other Modula-3 outputs. m3gdb is dependent on cygwin1.dll. Using Cygwin probably would work..and I could try it to see if it resolves the RTLinker problem. As well, we could have something like, in cm3.cfg you could set MINGWIN_ROOT, MSYS_ROOT, and/or CYGWIN_ROOT, to guide what tools are used, OR we can have some variable: GNU_MODE = 0 % Do not use GNU tools at all -- today's NT386GNU_MODE = 1 % Use GNU tools minimally -- today's NT386GNUGNU_MODE = 2 % Use GNU tools maximally -- not existant but probably easy Eh..I know, not great.. what do "minimally" and "maximally" mean. I think we have the problem of a) many viable choices b) want to make several of them available c) just don't know what to call things and what the interface should be. As well as an interop question, since jmpbuf does vary in size between cygwin1.dl and everything else. Further down the line, there are other linkers, other compilers, other runtimes. The design here and now might take them into consideration.Gasp..I just realized, there is also another good backend option. parse.c's approach could probably be adapted to Open Watcom AND they might even take the changes (not that I have asked, I just thought of this). And that would net you progress toward a) 32 bit MS-DOS target b) OS/2 target, c) Netware target d) gcc-free Linux target, since the support all of them.Other target possibilities include Digital Mars compiler/linker, CodeWarrior (I know, dead and all), etc. Open Watcom is probably the most interesting since it is open source... - Jay > From: hosking at cs.purdue.edu> Date: Sat, 19 Jan 2008 12:48:06 -0500> To: jkrell at elego.de> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] [M3commit] CVS Update: cm3> > So, I am very confused now. Does NT386GNU no longer mean use of the > full set of GNU tools m3cc/ld/as, as would be available under > Cygwin? I thought the point of this was to be able to run in as much > of a GNU environment as possible. GNU to me means the whole > toolsuite not just m3cc. To me, a GNU-based environment on Windows > holds great attraction, since it consists of tools that I generally > always install on Windows, that I know, and are similar to the other > platforms I use.> > On Jan 19, 2008, at 4:11 AM, Jay Krell wrote:> > > CVSROOT: /usr/cvs> > Changes by: jkrell at birch. 08/01/19 04:11:34> >> > Modified files:> > cm3/m3-libs/m3core/src/runtime/: m3makefile> > cm3/m3-sys/cminstall/src/config/: NT386GNU> > cm3/m3-sys/m3front/src/builtinInfo/: InfoModule.m3> > cm3/m3-sys/m3middle/src/: Target.m3> >> > Log message:> > m3-sys/m3middle/src/Target.m3> > m3-libs/m3core/src/runtime/m3makefile> > m3-sys\m3front\src\builtinInfo\InfoModule.m3> > > > switch NT386GNU to be Win32 instead of POSIX> > switch NT386GNU to _setjmp instead of setjmp> > jmp_buf size still big like Cygwin> > rewrite NT386GNU config file -- almost identical to NT386> > mingwin required for building Modula-3 programs> > mingwin AND msys required for building m3cc> > > > To boot:> > > > install Python (www.activestate.com)> > > > have a working NT386 system> > get current source> > Mine is at c:\dev2\cm3.2 (cm3 is has other paused work, dev was > > taken by Unix)> > > > get and install binary distribution (5.1.3 works, anything newer > > should work)> > I install to c:\cm3> > copy %CVSROOT%\m3-sys\cminstall\src\config\cm3.cfg to \cm3\bin > > \cm3.cfg> > > > Have a Visual C++ toolset (cl and link)> > and run the vcvars link on the start menu (this can/will be made > > easier)> > Almost any version should work.> > if you are using Visual C++ 8.0 (RTM?), rename away its mt.exe> > and get a newer from such as from the Platform SDK. Otherwise it > > crashes.> > This is not specific to NT386GNU, just that I recently removed the > > Platform SDK> > from my %PATH%.> > > > cd %CVSROOT%\scripts\python> > .\upgrade> > > > install msys and mingwin from http://www.mingw.org (links to > > SourceForge)> > for mingwin, you only need the "base"> > msys tells you to avoid mingwin make, in favor of msys make, and I > > did that> > > > I install to the defaults> > c:\msys\1.0> > c:\mingw> > > > if you don't install to the defaults, add> > \bin and > to the start, but which order between the two?)> > > > if you do install to the defaults, scripts\python will fix path > > for you,> > if there is no gcc/as/sh on our $PATH> > > > cd %CVSROOT%\scripts\python> > upgrade && bootntgnu> > > > NOTE THE RESULTING BINARIES DO NOT YET WORK, but this is still > > progress.> > > > These instructions inevitably to be further tested and refined and > > placed elsewhere!> 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 Jan 19 19:45:27 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 19 Jan 2008 18:45:27 +0000 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: References: <20080119031134.4B6A510D4625@birch.elegosoft.com> Message-ID: ps -- the need or Visual C++ referenced in the checkin coment is to "boot" -- to build a current cm3 to build the NT386GNU stuff. Just like you need cm3 to do cross builds, except in this case both Modula-3 targets can be fully built on the same machine. Once you build the first time, IF it was working, no Visual C++/SDK requirement. Once a working binary distribution is available, ditto. - Jay From: jayk123 at hotmail.comTo: hosking at cs.purdue.edu; jkrell at elego.deCC: m3devel at elegosoft.comSubject: RE: [M3devel] [M3commit] CVS Update: cm3Date: Sat, 19 Jan 2008 18:35:09 +0000 ps -- look at m3-sys/cminstall/src/config/NT386GNU.While it is very very similar to NT386, and even outputs foo.lib and foo.lib.sa like NT386, it uses gcc for C compilation, linking, and m3cg for the backend.It is very "GNU" in tools, but not runtime. - Jay From: jayk123 at hotmail.comTo: hosking at cs.purdue.edu; jkrell at elego.deCC: m3devel at elegosoft.comSubject: RE: [M3devel] [M3commit] CVS Update: cm3Date: Sat, 19 Jan 2008 18:32:35 +0000 It DOES use m3cc/ld/as, and mklib for building static .libs, though that could probably be gcc/ar/dlltools if I figured it out."Everything" except m3cc/m3gdb can be built with just MinGWin.Building m3cc requires MSys as well.Building m3gdb requires Cygwin.m3cg is not dependent on cygwin1.dll, nor are any other Modula-3 outputs. m3gdb is dependent on cygwin1.dll. Using Cygwin probably would work..and I could try it to see if it resolves the RTLinker problem. As well, we could have something like, in cm3.cfg you could set MINGWIN_ROOT, MSYS_ROOT, and/or CYGWIN_ROOT, to guide what tools are used, OR we can have some variable: GNU_MODE = 0 % Do not use GNU tools at all -- today's NT386GNU_MODE = 1 % Use GNU tools minimally -- today's NT386GNUGNU_MODE = 2 % Use GNU tools maximally -- not existant but probably easy Eh..I know, not great.. what do "minimally" and "maximally" mean. I think we have the problem of a) many viable choices b) want to make several of them available c) just don't know what to call things and what the interface should be. As well as an interop question, since jmpbuf does vary in size between cygwin1.dl and everything else. Further down the line, there are other linkers, other compilers, other runtimes. The design here and now might take them into consideration.Gasp..I just realized, there is also another good backend option. parse.c's approach could probably be adapted to Open Watcom AND they might even take the changes (not that I have asked, I just thought of this). And that would net you progress toward a) 32 bit MS-DOS target b) OS/2 target, c) Netware target d) gcc-free Linux target, since the support all of them.Other target possibilities include Digital Mars compiler/linker, CodeWarrior (I know, dead and all), etc. Open Watcom is probably the most interesting since it is open source... - Jay > From: hosking at cs.purdue.edu> Date: Sat, 19 Jan 2008 12:48:06 -0500> To: jkrell at elego.de> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] [M3commit] CVS Update: cm3> > So, I am very confused now. Does NT386GNU no longer mean use of the > full set of GNU tools m3cc/ld/as, as would be available under > Cygwin? I thought the point of this was to be able to run in as much > of a GNU environment as possible. GNU to me means the whole > toolsuite not just m3cc. To me, a GNU-based environment on Windows > holds great attraction, since it consists of tools that I generally > always install on Windows, that I know, and are similar to the other > platforms I use.> > On Jan 19, 2008, at 4:11 AM, Jay Krell wrote:> > > CVSROOT: /usr/cvs> > Changes by: jkrell at birch. 08/01/19 04:11:34> >> > Modified files:> > cm3/m3-libs/m3core/src/runtime/: m3makefile> > cm3/m3-sys/cminstall/src/config/: NT386GNU> > cm3/m3-sys/m3front/src/builtinInfo/: InfoModule.m3> > cm3/m3-sys/m3middle/src/: Target.m3> >> > Log message:> > m3-sys/m3middle/src/Target.m3> > m3-libs/m3core/src/runtime/m3makefile> > m3-sys\m3front\src\builtinInfo\InfoModule.m3> > > > switch NT386GNU to be Win32 instead of POSIX> > switch NT386GNU to _setjmp instead of setjmp> > jmp_buf size still big like Cygwin> > rewrite NT386GNU config file -- almost identical to NT386> > mingwin required for building Modula-3 programs> > mingwin AND msys required for building m3cc> > > > To boot:> > > > install Python (www.activestate.com)> > > > have a working NT386 system> > get current source> > Mine is at c:\dev2\cm3.2 (cm3 is has other paused work, dev was > > taken by Unix)> > > > get and install binary distribution (5.1.3 works, anything newer > > should work)> > I install to c:\cm3> > copy %CVSROOT%\m3-sys\cminstall\src\config\cm3.cfg to \cm3\bin > > \cm3.cfg> > > > Have a Visual C++ toolset (cl and link)> > and run the vcvars link on the start menu (this can/will be made > > easier)> > Almost any version should work.> > if you are using Visual C++ 8.0 (RTM?), rename away its mt.exe> > and get a newer from such as from the Platform SDK. Otherwise it > > crashes.> > This is not specific to NT386GNU, just that I recently removed the > > Platform SDK> > from my %PATH%.> > > > cd %CVSROOT%\scripts\python> > .\upgrade> > > > install msys and mingwin from http://www.mingw.org (links to > > SourceForge)> > for mingwin, you only need the "base"> > msys tells you to avoid mingwin make, in favor of msys make, and I > > did that> > > > I install to the defaults> > c:\msys\1.0> > c:\mingw> > > > if you don't install to the defaults, add> > \bin and > to the start, but which order between the two?)> > > > if you do install to the defaults, scripts\python will fix path > > for you,> > if there is no gcc/as/sh on our $PATH> > > > cd %CVSROOT%\scripts\python> > upgrade && bootntgnu> > > > NOTE THE RESULTING BINARIES DO NOT YET WORK, but this is still > > progress.> > > > These instructions inevitably to be further tested and refined and > > placed elsewhere!> 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! _________________________________________________________________ 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 Sat Jan 19 19:49:32 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 19 Jan 2008 18:49:32 +0000 Subject: [M3devel] more assembly symbols please? In-Reply-To: <2717B275-2548-41BC-BD1E-8742BCE6FA51@cs.purdue.edu> References: <2717B275-2548-41BC-BD1E-8742BCE6FA51@cs.purdue.edu> Message-ID: Thanks. m3cg -y for full tracing also dumps relevant stuff at the end. I'll try m3cgcat too. I should just be able to build/run an NT386 version. My C tracing does "prove" the problem is RTHeapInfo, but I still haven't figured out why. I've started skimming the code that builds that data...still a ways off from solving this I think. I have some suspicion the linker is moving things around that were otherwise correct, but I am far from proving that or fixing it. I'd like to first verify that the "m3front" / m3cg output is correct. The lack of labels in the as actually is a counter point to the movement theory, hard for linker to get a handle on anything to move around, it's just one blob. - Jay > CC: m3devel at elegosoft.com> From: hosking at cs.purdue.edu> Subject: Re: [M3devel] more assembly symbols please?> Date: Sat, 19 Jan 2008 12:33:08 -0500> To: jayk123 at hotmail.com> > Take a look at the .mc intermediate code output if you want to see > that section of the data. There are at least comments. Use m3cgcat - > binary < x.mc > x.mo to view it (You can run m3cgcat on any other CM3 > install).> > On Jan 19, 2008, at 6:02 AM, Jay wrote:> > > Any chance the m3cg output could have, um, some symbols for the > > global data?> > It's kind of a pain to decode..> >> > The module/import info is ok a lot, lots of runtime links ok.> > I think the bad one might be RTHeapInfo but I have to decode the > > very bare of symbols assembly..> > or comments? Like for record fields?> > Still thinking of sticking a call out to C code...Even > > OutputDebugString since RTIO isn't working...> >> > I looked through the m3cg --help, didn't find anything.> >> > Tony?> >> > _MM_RTHeapInfo:> > 0 .long _L_1+224> > 4 .long _MM_RTHeapInfo+52> > 8 .long _MM_RTHeapInfo+308> > 12,16 .space 8> > 20 .long _L_1+152> > 24 .space 4> > 28 .long _L_1+220> > 32 .long _L_1+220> > 36 .long _MM_RTHeapInfo+160> > 40 .space 4> > .long _RTHeapInfo_M3> >> > I get to count out to 160 bytes from here..:> >> > _L_1:> > 0 .byte 48> > 1 .byte 49> > 2 .byte 50> > 3 .byte 51> > 4 .byte 52> > 5 .byte 53> > 6 .byte 54> > 7 .byte 55> > 8 .byte 56> > 9 .byte 57> > a .byte 97> > b .byte 98> > c .byte 99> > d .byte 100> > e .byte 101> > f .byte 102> > 10 .long _RTHooks__TextLitInfo> > 14 .long _RTHooks__TextLitGetChar> > 18 .long _RTHooks__TextLitGetWideChar> > 1c .long _RTHooks__TextLitGetChars> > 20 .long _RTHooks__TextLitGetWideChars> > 24 .long 2> > 28 .long _L_1+16> > 2c .long 7> > 30 .ascii "shownew"> > 37 .space 1> > 38 .long 2> > 3c .long _L_1+16> > 40 .long 6> > 44 .ascii "update"> > 4a .space 2> > 4c .ascii "RTHeapInfo_M3"> > 50 .space 1> > .ascii "Init"> > .space 1> >> > I'll try the C code..> >> > - Jay> >> >> >> >> >> > 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 wagner at elegosoft.com Sat Jan 19 20:48:10 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 19 Jan 2008 20:48:10 +0100 Subject: [M3devel] my status on win32 In-Reply-To: <47908659.1E75.00D7.1@scires.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> <477EA137.1E75.00D7.1@scires.com> <478D394B.1E75.00D7.1@scires.com> <478D47FB.1E75.00D7.1@scires.com> <478DBF8D.1E75.00D7.1@scires.com> <478DE973.1E75.00D7.1@scires.com> <47908659.1E75.00D7.1@scires.com> Message-ID: <20080119204810.3wmumqgms88sccw4@mail.elegosoft.com> Quoting Randy Coleburn : > 1. pixmaps aren't rendered properly on the screen. They look really > bad. I recall having this problem a while back with one of the early > 5.x releases, so I guess it was never solved. I've got some old test > programs I try to dig out and see if I can find out what is going on. I > seem to recall that building standalone in the past seemed to fix the > problem, so this is a real mystery. Hi Randy, I'm afraid I wasn't able to solve it directly some years ago and then forgot about it due to more urgent tasks. I think we should try to narrow down the location of the problem (i.e. is it in the runtime, code generation, linker, or windows libraries). As you still have the 4.1 code of the Windows libraries, could you first try to build them with the new compiler and see if it makes a difference if you link against them? It may also be worthwhile to compare the commands actually used for linking (use -commands). That is, before we turn to the actual generated code... I still haven't got Windows access here, so I can just suggest what to do... Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From rcoleburn at scires.com Sat Jan 19 22:22:06 2008 From: rcoleburn at scires.com (Randy Coleburn) Date: Sat, 19 Jan 2008 16:22:06 -0500 Subject: [M3devel] reactor: catalyst vs cm3-ide Message-ID: <479223AC.1E75.00D7.1@scires.com> Ok, I've gotten some feedback on the new name for reactor. I've attached a PDF that has two pages: one depicts use of Catalyst, the other CM3-IDE. Please let me know which you prefer. BTW, if anyone else can draw up something better, go for it. I'm not a graphic artist. Regards, Randy -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: newReactor.pdf Type: application/pdf Size: 84104 bytes Desc: not available URL: From rcoleburn at scires.com Sat Jan 19 22:27:09 2008 From: rcoleburn at scires.com (Randy Coleburn) Date: Sat, 19 Jan 2008 16:27:09 -0500 Subject: [M3devel] success with upgrade on NT386 Message-ID: <479224DB.1E75.00D7.1@scires.com> Jay: Thanks for all your help. I checked out your updates last night and was able to do a complete rebuild of the compiler and all packages using the upgrade and do-cmd-std scripts on Windows XP. Regards, Randy -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sun Jan 20 00:46:59 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 19 Jan 2008 18:46:59 -0500 Subject: [M3devel] more assembly symbols please? In-Reply-To: References: <2717B275-2548-41BC-BD1E-8742BCE6FA51@cs.purdue.edu> Message-ID: <1A973B4E-23DD-4B85-B42F-9070E93429BB@cs.purdue.edu> Which linker are you using? Could that be a factor? On Jan 19, 2008, at 1:49 PM, Jay wrote: > Thanks. m3cg -y for full tracing also dumps relevant stuff at the end. > I'll try m3cgcat too. I should just be able to build/run an NT386 > version. > My C tracing does "prove" the problem is RTHeapInfo, but I still > haven't figured out why. > I've started skimming the code that builds that data...still a ways > off from solving this I think. > I have some suspicion the linker is moving things around that were > otherwise correct, but I am far from proving that or fixing it. > I'd like to first verify that the "m3front" / m3cg output is correct. > The lack of labels in the as actually is a counter point to the > movement theory, hard for linker to get a handle on anything to > move around, it's just one blob. > > - Jay > > > > > CC: m3devel at elegosoft.com > > From: hosking at cs.purdue.edu > > Subject: Re: [M3devel] more assembly symbols please? > > Date: Sat, 19 Jan 2008 12:33:08 -0500 > > To: jayk123 at hotmail.com > > > > Take a look at the .mc intermediate code output if you want to see > > that section of the data. There are at least comments. Use m3cgcat - > > binary < x.mc > x.mo to view it (You can run m3cgcat on any other > CM3 > > install). > > > > On Jan 19, 2008, at 6:02 AM, Jay wrote: > > > > > Any chance the m3cg output could have, um, some symbols for the > > > global data? > > > It's kind of a pain to decode.. > > > > > > The module/import info is ok a lot, lots of runtime links ok. > > > I think the bad one might be RTHeapInfo but I have to decode the > > > very bare of symbols assembly.. > > > or comments? Like for record fields? > > > Still thinking of sticking a call out to C code...Even > > > OutputDebugString since RTIO isn't working... > > > > > > I looked through the m3cg --help, didn't find anything. > > > > > > Tony? > > > > > > _MM_RTHeapInfo: > > > 0 .long _L_1+224 > > > 4 .long _MM_RTHeapInfo+52 > > > 8 .long _MM_RTHeapInfo+308 > > > 12,16 .space 8 > > > 20 .long _L_1+152 > > > 24 .space 4 > > > 28 .long _L_1+220 > > > 32 .long _L_1+220 > > > 36 .long _MM_RTHeapInfo+160 > > > 40 .space 4 > > > .long _RTHeapInfo_M3 > > > > > > I get to count out to 160 bytes from here..: > > > > > > _L_1: > > > 0 .byte 48 > > > 1 .byte 49 > > > 2 .byte 50 > > > 3 .byte 51 > > > 4 .byte 52 > > > 5 .byte 53 > > > 6 .byte 54 > > > 7 .byte 55 > > > 8 .byte 56 > > > 9 .byte 57 > > > a .byte 97 > > > b .byte 98 > > > c .byte 99 > > > d .byte 100 > > > e .byte 101 > > > f .byte 102 > > > 10 .long _RTHooks__TextLitInfo > > > 14 .long _RTHooks__TextLitGetChar > > > 18 .long _RTHooks__TextLitGetWideChar > > > 1c .long _RTHooks__TextLitGetChars > > > 20 .long _RTHooks__TextLitGetWideChars > > > 24 .long 2 > > > 28 .long _L_1+16 > > > 2c .long 7 > > > 30 .ascii "shownew" > > > 37 .space 1 > > > 38 .long 2 > > > 3c .long _L_1+16 > > > 40 .long 6 > > > 44 .ascii "update" > > > 4a .space 2 > > > 4c .ascii "RTHeapInfo_M3" > > > 50 .space 1 > > > .ascii "Init" > > > .space 1 > > > > > > I'll try the C code.. > > > > > > - Jay > > > > > > > > > > > > > > > > > > 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 hosking at cs.purdue.edu Sun Jan 20 00:47:41 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 19 Jan 2008 18:47:41 -0500 Subject: [M3devel] my status on win32 In-Reply-To: <20080119204810.3wmumqgms88sccw4@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> <477EA137.1E75.00D7.1@scires.com> <478D394B.1E75.00D7.1@scires.com> <478D47FB.1E75.00D7.1@scires.com> <478DBF8D.1E75.00D7.1@scires.com> <478DE973.1E75.00D7.1@scires.com> <47908659.1E75.00D7.1@scires.com> <20080119204810.3wmumqgms88sccw4@mail.elegosoft.com> Message-ID: I would perhaps suspect a bad library mapping. On Jan 19, 2008, at 2:48 PM, Olaf Wagner wrote: > Quoting Randy Coleburn : >> 1. pixmaps aren't rendered properly on the screen. They look really >> bad. I recall having this problem a while back with one of the early >> 5.x releases, so I guess it was never solved. I've got some old test >> programs I try to dig out and see if I can find out what is going >> on. I >> seem to recall that building standalone in the past seemed to fix the >> problem, so this is a real mystery. > > Hi Randy, > > I'm afraid I wasn't able to solve it directly some years ago and > then forgot about it due to more urgent tasks. > > I think we should try to narrow down the location of the problem > (i.e. is it in the runtime, code generation, linker, or windows > libraries). > > As you still have the 4.1 code of the Windows libraries, could you > first try to build them with the new compiler and see if it makes > a difference if you link against them? > > It may also be worthwhile to compare the commands actually used > for linking (use -commands). That is, before we turn to the actual > generated code... > > I still haven't got Windows access here, so I can just suggest what > to do... > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, > Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Jan 20 00:51:41 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 19 Jan 2008 18:51:41 -0500 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: References: <20080119031134.4B6A510D4625@birch.elegosoft.com> Message-ID: <5BFBD626-F492-4058-9A7A-6CB295753585@cs.purdue.edu> On Jan 19, 2008, at 1:32 PM, Jay wrote: > Gasp..I just realized, there is also another good backend option. > parse.c's approach could probably be adapted to Open Watcom AND > they might even take the changes (not that I have asked, I just > thought of this). And that would net you progress toward a) 32 bit > MS-DOS target b) OS/2 target, c) Netware target d) gcc-free Linux > target, since the support all of them. I would plump for llvm. Apple is using it heavily these days and may be pushing it into their Mac compiler toolchain. > > Other target possibilities include Digital Mars compiler/linker, > CodeWarrior (I know, dead and all), etc. Open Watcom is probably > the most interesting since it is open source... > > - Jay > > > > > From: hosking at cs.purdue.edu > > Date: Sat, 19 Jan 2008 12:48:06 -0500 > > To: jkrell at elego.de > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > > > So, I am very confused now. Does NT386GNU no longer mean use of the > > full set of GNU tools m3cc/ld/as, as would be available under > > Cygwin? I thought the point of this was to be able to run in as much > > of a GNU environment as possible. GNU to me means the whole > > toolsuite not just m3cc. To me, a GNU-based environment on Windows > > holds great attraction, since it consists of tools that I generally > > always install on Windows, that I know, and are similar to the other > > platforms I use. > > > > On Jan 19, 2008, at 4:11 AM, Jay Krell wrote: > > > > > CVSROOT: /usr/cvs > > > Changes by: jkrell at birch. 08/01/19 04:11:34 > > > > > > Modified files: > > > cm3/m3-libs/m3core/src/runtime/: m3makefile > > > cm3/m3-sys/cminstall/src/config/: NT386GNU > > > cm3/m3-sys/m3front/src/builtinInfo/: InfoModule.m3 > > > cm3/m3-sys/m3middle/src/: Target.m3 > > > > > > Log message: > > > m3-sys/m3middle/src/Target.m3 > > > m3-libs/m3core/src/runtime/m3makefile > > > m3-sys\m3front\src\builtinInfo\InfoModule.m3 > > > > > > switch NT386GNU to be Win32 instead of POSIX > > > switch NT386GNU to _setjmp instead of setjmp > > > jmp_buf size still big like Cygwin > > > rewrite NT386GNU config file -- almost identical to NT386 > > > mingwin required for building Modula-3 programs > > > mingwin AND msys required for building m3cc > > > > > > To boot: > > > > > > install Python (www.activestate.com) > > > > > > have a working NT386 system > > > get current source > > > Mine is at c:\dev2\cm3.2 (cm3 is has other paused work, dev was > > > taken by Unix) > > > > > > get and install binary distribution (5.1.3 works, anything newer > > > should work) > > > I install to c:\cm3 > > > copy %CVSROOT%\m3-sys\cminstall\src\config\cm3.cfg to \cm3\bin > > > \cm3.cfg > > > > > > Have a Visual C++ toolset (cl and link) > > > and run the vcvars link on the start menu (this can/will be made > > > easier) > > > Almost any version should work. > > > if you are using Visual C++ 8.0 (RTM?), rename away its mt.exe > > > and get a newer from such as from the Platform SDK. Otherwise it > > > crashes. > > > This is not specific to NT386GNU, just that I recently removed the > > > Platform SDK > > > from my %PATH%. > > > > > > cd %CVSROOT%\scripts\python > > > .\upgrade > > > > > > install msys and mingwin from http://www.mingw.org (links to > > > SourceForge) > > > for mingwin, you only need the "base" > > > msys tells you to avoid mingwin make, in favor of msys make, and I > > > did that > > > > > > I install to the defaults > > > c:\msys\1.0 > > > c:\mingw > > > > > > if you don't install to the defaults, add > > > \bin and > > to the start, but which order between the two?) > > > > > > if you do install to the defaults, scripts\python will fix path > > > for you, > > > if there is no gcc/as/sh on our $PATH > > > > > > cd %CVSROOT%\scripts\python > > > upgrade && bootntgnu > > > > > > NOTE THE RESULTING BINARIES DO NOT YET WORK, but this is still > > > progress. > > > > > > These instructions inevitably to be further tested and refined and > > > placed elsewhere! > > > > > 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 Sun Jan 20 00:52:12 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 19 Jan 2008 18:52:12 -0500 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: References: <20080119031134.4B6A510D4625@birch.elegosoft.com> Message-ID: OK, that's what I had hoped. Sounds good! On Jan 19, 2008, at 1:35 PM, Jay wrote: > ps -- look at m3-sys/cminstall/src/config/NT386GNU. > While it is very very similar to NT386, and even outputs foo.lib > and foo.lib.sa like NT386, it uses gcc for C compilation, linking, > and m3cg for the backend. > It is very "GNU" in tools, but not runtime. > > - Jay > > From: jayk123 at hotmail.com > To: hosking at cs.purdue.edu; jkrell at elego.de > CC: m3devel at elegosoft.com > Subject: RE: [M3devel] [M3commit] CVS Update: cm3 > Date: Sat, 19 Jan 2008 18:32:35 +0000 > > It DOES use m3cc/ld/as, and mklib for building static .libs, though > that could probably be gcc/ar/dlltools if I figured it out. > "Everything" except m3cc/m3gdb can be built with just MinGWin. > Building m3cc requires MSys as well. > Building m3gdb requires Cygwin. > m3cg is not dependent on cygwin1.dll, nor are any other Modula-3 > outputs. m3gdb is dependent on cygwin1.dll. > > Using Cygwin probably would work..and I could try it to see if it > resolves the RTLinker problem. > > As well, we could have something like, in cm3.cfg you could set > MINGWIN_ROOT, MSYS_ROOT, and/or CYGWIN_ROOT, to guide what tools > are used, OR we can have some variable: > > GNU_MODE = 0 % Do not use GNU tools at all -- today's NT386 > GNU_MODE = 1 % Use GNU tools minimally -- today's NT386GNU > GNU_MODE = 2 % Use GNU tools maximally -- not existant but probably > easy > > Eh..I know, not great.. what do "minimally" and "maximally" mean. > > I think we have the problem of a) many viable choices b) want to > make several of them available c) just don't know what to call > things and what the interface should be. As well as an interop > question, since jmpbuf does vary in size between cygwin1.dl and > everything else. > > Further down the line, there are other linkers, other compilers, > other runtimes. The design here and now might take them into > consideration. > Gasp..I just realized, there is also another good backend option. > parse.c's approach could probably be adapted to Open Watcom AND > they might even take the changes (not that I have asked, I just > thought of this). And that would net you progress toward a) 32 bit > MS-DOS target b) OS/2 target, c) Netware target d) gcc-free Linux > target, since the support all of them. > Other target possibilities include Digital Mars compiler/linker, > CodeWarrior (I know, dead and all), etc. Open Watcom is probably > the most interesting since it is open source... > > - Jay > > > > > From: hosking at cs.purdue.edu > > Date: Sat, 19 Jan 2008 12:48:06 -0500 > > To: jkrell at elego.de > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > > > So, I am very confused now. Does NT386GNU no longer mean use of the > > full set of GNU tools m3cc/ld/as, as would be available under > > Cygwin? I thought the point of this was to be able to run in as much > > of a GNU environment as possible. GNU to me means the whole > > toolsuite not just m3cc. To me, a GNU-based environment on Windows > > holds great attraction, since it consists of tools that I generally > > always install on Windows, that I know, and are similar to the other > > platforms I use. > > > > On Jan 19, 2008, at 4:11 AM, Jay Krell wrote: > > > > > CVSROOT: /usr/cvs > > > Changes by: jkrell at birch. 08/01/19 04:11:34 > > > > > > Modified files: > > > cm3/m3-libs/m3core/src/runtime/: m3makefile > > > cm3/m3-sys/cminstall/src/config/: NT386GNU > > > cm3/m3-sys/m3front/src/builtinInfo/: InfoModule.m3 > > > cm3/m3-sys/m3middle/src/: Target.m3 > > > > > > Log message: > > > m3-sys/m3middle/src/Target.m3 > > > m3-libs/m3core/src/runtime/m3makefile > > > m3-sys\m3front\src\builtinInfo\InfoModule.m3 > > > > > > switch NT386GNU to be Win32 instead of POSIX > > > switch NT386GNU to _setjmp instead of setjmp > > > jmp_buf size still big like Cygwin > > > rewrite NT386GNU config file -- almost identical to NT386 > > > mingwin required for building Modula-3 programs > > > mingwin AND msys required for building m3cc > > > > > > To boot: > > > > > > install Python (www.activestate.com) > > > > > > have a working NT386 system > > > get current source > > > Mine is at c:\dev2\cm3.2 (cm3 is has other paused work, dev was > > > taken by Unix) > > > > > > get and install binary distribution (5.1.3 works, anything newer > > > should work) > > > I install to c:\cm3 > > > copy %CVSROOT%\m3-sys\cminstall\src\config\cm3.cfg to \cm3\bin > > > \cm3.cfg > > > > > > Have a Visual C++ toolset (cl and link) > > > and run the vcvars link on the start menu (this can/will be made > > > easier) > > > Almost any version should work. > > > if you are using Visual C++ 8.0 (RTM?), rename away its mt.exe > > > and get a newer from such as from the Platform SDK. Otherwise it > > > crashes. > > > This is not specific to NT386GNU, just that I recently removed the > > > Platform SDK > > > from my %PATH%. > > > > > > cd %CVSROOT%\scripts\python > > > .\upgrade > > > > > > install msys and mingwin from http://www.mingw.org (links to > > > SourceForge) > > > for mingwin, you only need the "base" > > > msys tells you to avoid mingwin make, in favor of msys make, and I > > > did that > > > > > > I install to the defaults > > > c:\msys\1.0 > > > c:\mingw > > > > > > if you don't install to the defaults, add > > > \bin and > > to the start, but which order between the two?) > > > > > > if you do install to the defaults, scripts\python will fix path > > > for you, > > > if there is no gcc/as/sh on our $PATH > > > > > > cd %CVSROOT%\scripts\python > > > upgrade && bootntgnu > > > > > > NOTE THE RESULTING BINARIES DO NOT YET WORK, but this is still > > > progress. > > > > > > These instructions inevitably to be further tested and refined and > > > placed elsewhere! > > > > > 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! From rcoleburn at scires.com Sun Jan 20 03:12:37 2008 From: rcoleburn at scires.com (Randy Coleburn) Date: Sat, 19 Jan 2008 21:12:37 -0500 Subject: [M3devel] my status on win32 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> <477EA137.1E75.00D7.1@scires.com> <478D394B.1E75.00D7.1@scires.com> <478D47FB.1E75.00D7.1@scires.com> <478DBF8D.1E75.00D7.1@scires.com> <478DE973.1E75.00D7.1@scires.com> <47908659.1E75.00D7.1@scires.com> <20080119204810.3wmumqgms88sccw4@mail.elegosoft.com> Message-ID: <479267C2.1E75.00D7.1@scires.com> Hi Tony: Are you suggesting that when the program is built standalone it maps libraries differently? I know there is a difference between dynamic vs. static libraries, but are you suggesting that a different library is being mapped than the vendor's equivalent of the dynamic library? How would I check for this situation? Your suggestion seems plausible since the source is not recompiled; instead, the linker is used to change the way the EXE is put together and that seems to cause the difference in operation as far as pixmaps are concerned. Regards, Randy >>> Tony Hosking 1/19/2008 6:47 PM >>> I would perhaps suspect a bad library mapping. On Jan 19, 2008, at 2:48 PM, Olaf Wagner wrote: > Quoting Randy Coleburn : >> 1. pixmaps aren't rendered properly on the screen. They look really >> bad. I recall having this problem a while back with one of the early >> 5.x releases, so I guess it was never solved. I've got some old test >> programs I try to dig out and see if I can find out what is going >> on. I >> seem to recall that building standalone in the past seemed to fix the >> problem, so this is a real mystery. > > Hi Randy, > > I'm afraid I wasn't able to solve it directly some years ago and > then forgot about it due to more urgent tasks. > > I think we should try to narrow down the location of the problem > (i.e. is it in the runtime, code generation, linker, or windows > libraries). > > As you still have the 4.1 code of the Windows libraries, could you > first try to build them with the new compiler and see if it makes > a difference if you link against them? > > It may also be worthwhile to compare the commands actually used > for linking (use -commands). That is, before we turn to the actual > generated code... > > I still haven't got Windows access here, so I can just suggest what > to do... > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, > Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 > 45 86 95 > http://www.elegosoft.com ( http://www.elegosoft.com/ ) | Gesch?ftsf?hrer: Olaf Wagner | Sitz: > Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > DE163214194 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Sun Jan 20 05:27:43 2008 From: jayk123 at hotmail.com (Jay) Date: Sun, 20 Jan 2008 04:27:43 +0000 Subject: [M3devel] my status on win32 In-Reply-To: <479267C2.1E75.00D7.1@scires.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> <477EA137.1E75.00D7.1@scires.com> <478D394B.1E75.00D7.1@scires.com> <478D47FB.1E75.00D7.1@scires.com> <478DBF8D.1E75.00D7.1@scires.com> <478DE973.1E75.00D7.1@scires.com> <47908659.1E75.00D7.1@scires.com> <20080119204810.3wmumqgms88sccw4@mail.elegosoft.com> <479267C2.1E75.00D7.1@scires.com> Message-ID: What does "mapped" mean here? The way it works, on Modula-3 NT386, and I haven't seen this done quite this way ever on Win32, not so systematically/mechanically/automatically, and I don't know how Posixish systems work here, but the way it works is that for every .dll, CM3 NT386 builds foo.lib and foo.lib.sa. foo.lib is an "import lib", just containing essentially function names and a file name. foo.lib.sa is a regular old static .lib, sa for standalone. You can also just build a static .lib -- for stuff that is never a .dll, for stuff that is only used once, but is broken up into multiple directories. For example m3quake, m3middle, m3objfile, m3back, etc. They are only used by cm3 so are just static .libs, just foo.lib, are built. (If we fix cm3.exe to be copy over itself, and I have some new clever ideas here, it might be profitable, for "developer productivity", to turn these into .dlls -- just so I can cd around and rebuild/reship less.) When you ask to build a standalone executable, we have a list of .libs, foo.lib, bar.lib. They are full paths. For each one, we see if foo.lib.sa exists, and if so, we use that instead of foo.lib. It is all rather simple and clever, but at least to me, it was surprising and new, so I explain it here. Perhaps Posixish systems work very similarly and this is old hat? I know cm3 doesn't implement this for Posix, but ar/ld/gcc could be handling things this way underneath for it. For example, I know on Mac OS X, if you link to a full path to a file, that's what you get. But if you say -Ldirectory -lfoo, ld probes for directory/foo.dylib and then directory/foo.a. So modulo the extensions and unknown to me how you build the things in the first place, same thing. You have to be sure to use the setting to split lib paths like that, otherwise you break dynamic linking. CM3 makes foo.sa.lib with its own mklib. This is also unusual. Normally one would use lib.exe or link.exe /lib for this, or ar/ld/gcc/dlltools. But the CM3 folks were obviously, openly en route to cutting dependencies through reimplementation. I had some initial trouble on NT385GNU building static .libs with ar/ld/gcc/dlltool, so, heck, I just do what NT386 does, and it seems to be working (modulo that SOMETHING is not working :) ). I don't want to stop anyone else from debugging this but if nobody else figures it out I will try. I can repro it easily, thanks for the good repro Randy! (though I wish it would crash instead of mis-display :) ) There is no "vendor's equivalent library" here, it is all just Modula-3 foo.lib or foo.lib.sa. Look at NT386/*.txt, by the .exe. Build one way. Rename away NT386. Build the other way. Compare the directories. You will see what I am talking about. - Jay Date: Sat, 19 Jan 2008 21:12:37 -0500 From: rcoleburn at scires.com To: hosking at cs.purdue.edu; wagner at elegosoft.com CC: m3devel at elegosoft.com Subject: Re: [M3devel] my status on win32 Hi Tony: Are you suggesting that when the program is built standalone it maps libraries differently? I know there is a difference between dynamic vs. static libraries, but are you suggesting that a different library is being mapped than the vendor's equivalent of the dynamic library? How would I check for this situation? Your suggestion seems plausible since the source is not recompiled; instead, the linker is used to change the way the EXE is put together and that seems to cause the difference in operation as far as pixmaps are concerned. Regards, Randy >>> Tony Hosking 1/19/2008 6:47 PM >>> I would perhaps suspect a bad library mapping. On Jan 19, 2008, at 2:48 PM, Olaf Wagner wrote: > Quoting Randy Coleburn : >> 1. pixmaps aren't rendered properly on the screen. They look really >> bad. I recall having this problem a while back with one of the early >> 5.x releases, so I guess it was never solved. I've got some old test >> programs I try to dig out and see if I can find out what is going >> on. I >> seem to recall that building standalone in the past seemed to fix the >> problem, so this is a real mystery. > > Hi Randy, > > I'm afraid I wasn't able to solve it directly some years ago and > then forgot about it due to more urgent tasks. > > I think we should try to narrow down the location of the problem > (i.e. is it in the runtime, code generation, linker, or windows > libraries). > > As you still have the 4.1 code of the Windows libraries, could you > first try to build them with the new compiler and see if it makes > a difference if you link against them? > > It may also be worthwhile to compare the commands actually used > for linking (use -commands). That is, before we turn to the actual > generated code... > > I still haven't got Windows access here, so I can just suggest what > to do... > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, > Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 Jan 20 04:46:03 2008 From: mika at async.caltech.edu (Mika Nystrom) Date: Sat, 19 Jan 2008 19:46:03 -0800 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: Your message of "Sat, 19 Jan 2008 12:48:06 EST." Message-ID: <200801200346.m0K3k3Em023728@camembert.async.caltech.edu> Can I add a perhaps obvious observation? NT386GNU must, of all things, mean that the code will compile and link cleanly, with a minimum of fuss, against Cygwin's headers and libraries. I have never used MS's C tools so I don't know if this is the case with them. It is of course the case when you use GNU ld, etc. When building large software in Modula-3 it's almost inevitable that, since the language is used by so few people, you will have a need to call out to C code (or Fortran code, or some other compiled code, with C interfaces). If you develop on Unix and use Cygwin to port to Windows, it makes no sense to distinguish between NT386 and NT386GNU unless the latter has pretty much the same environment as the Unix system. Mika Tony Hosking writes: >So, I am very confused now. Does NT386GNU no longer mean use of the >full set of GNU tools m3cc/ld/as, as would be available under >Cygwin? I thought the point of this was to be able to run in as much >of a GNU environment as possible. GNU to me means the whole >toolsuite not just m3cc. To me, a GNU-based environment on Windows >holds great attraction, since it consists of tools that I generally >always install on Windows, that I know, and are similar to the other >platforms I use. > >On Jan 19, 2008, at 4:11 AM, Jay Krell wrote: > >> CVSROOT: /usr/cvs >> Changes by: jkrell at birch. 08/01/19 04:11:34 >> >> Modified files: >> cm3/m3-libs/m3core/src/runtime/: m3makefile >> cm3/m3-sys/cminstall/src/config/: NT386GNU >> cm3/m3-sys/m3front/src/builtinInfo/: InfoModule.m3 >> cm3/m3-sys/m3middle/src/: Target.m3 >> >> Log message: >> m3-sys/m3middle/src/Target.m3 >> m3-libs/m3core/src/runtime/m3makefile >> m3-sys\m3front\src\builtinInfo\InfoModule.m3 >> >> switch NT386GNU to be Win32 instead of POSIX >> switch NT386GNU to _setjmp instead of setjmp >> jmp_buf size still big like Cygwin >> rewrite NT386GNU config file -- almost identical to NT386 >> mingwin required for building Modula-3 programs >> mingwin AND msys required for building m3cc >> >> To boot: >> >> install Python (www.activestate.com) >> >> have a working NT386 system >> get current source >> Mine is at c:\dev2\cm3.2 (cm3 is has other paused work, dev was >> taken by Unix) >> >> get and install binary distribution (5.1.3 works, anything newer >> should work) >> I install to c:\cm3 >> copy %CVSROOT%\m3-sys\cminstall\src\config\cm3.cfg to \cm3\bin >> \cm3.cfg >> >> Have a Visual C++ toolset (cl and link) >> and run the vcvars link on the start menu (this can/will be made >> easier) >> Almost any version should work. >> if you are using Visual C++ 8.0 (RTM?), rename away its mt.exe >> and get a newer from such as from the Platform SDK. Otherwise it >> crashes. >> This is not specific to NT386GNU, just that I recently removed the >> Platform SDK >> from my %PATH%. >> >> cd %CVSROOT%\scripts\python >> .\upgrade >> >> install msys and mingwin from http://www.mingw.org (links to >> SourceForge) >> for mingwin, you only need the "base" >> msys tells you to avoid mingwin make, in favor of msys make, and I >> did that >> >> I install to the defaults >> c:\msys\1.0 >> c:\mingw >> >> if you don't install to the defaults, add >> \bin and > to the start, but which order between the two?) >> >> if you do install to the defaults, scripts\python will fix path >> for you, >> if there is no gcc/as/sh on our $PATH >> >> cd %CVSROOT%\scripts\python >> upgrade && bootntgnu >> >> NOTE THE RESULTING BINARIES DO NOT YET WORK, but this is still >> progress. >> >> These instructions inevitably to be further tested and refined and >> placed elsewhere! From jayk123 at hotmail.com Sun Jan 20 05:52:55 2008 From: jayk123 at hotmail.com (Jay) Date: Sun, 20 Jan 2008 04:52:55 +0000 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: References: <20080119031134.4B6A510D4625@birch.elegosoft.com> Message-ID: Good, a happy customer. :) > GNU_MODE = 0 % Do not use GNU tools at all -- today's NT386 > GNU_MODE = 1 % Use GNU tools minimally -- today's NT386GNU > GNU_MODE = 2 % Use GNU tools maximally -- not existant but probably > easy > > Eh..I know, not great.. what do "minimally" and "maximally" mean. I'm still fishing for anyone to provide answers to these less important decisions that I have trouble with. Otherwise maybe no NT Cygwin system. TARGETs = { NT386, NT386GNU, NT386CYGWIN }? TARGETs = { NT386, NT386MINGWIN, NT386CYGWIN }? TARGETs = { NT386 + GNU_MODE }? The one reason I don't favor NT386 + GNU_MODE is that Cygwin has a much larger jmpbuf than the others. I think same TARGET implies code can be linked together, and I think varying jmpbuf implies otherwise. So NT386 and NT386MINGWIN should rarely cross paths with NT386CYGWIN. I also do NOT like this ad-hoc naming style. PPC_DARWIN, I386_DARWIN are much more to my style. The names should be somehow hierarchical, except, I realize, there isn't necessarily one "path" of stuff which to name platforms, though the GNU folks have settled on a way or two. They have triples or quadruples -- processor-hardware-os or such, however this doesn't clearly suffice. Something that accomodates: NT386 + LLVM NT386 + Watcom, linker and/or backend and/or runtime NT386 + Digital Mars linker and/or backend and/or runtime A C generating backend, and then linker/runtime and similar IA64, AMD64 variants would be good. To a large extent, these can be few platforms, subject to configuration, like if all the linkers consume a common file format (not clear), and if all the jmpbufs are the same size (known to be partly true, partly false). Oh and another thing, the runtime dependency is very likely cuttable, however PRESUMABLY real world applications (if there are any) link in a substantial amount of C or C++, in which case, it isn't necessarily cuttable. As well, if I can figure out a good way to do it, switching NT386 from awful slow frequent TlsGetValue/TlsSetValue to manipulating the linked list in fs:0, that would be nice, and might incur a C runtime dependency, but well worth it. The way Modula-3 works here is terrible. Another compromise option is probably __declspec(thread), though there is trickiness there in terms of being in a .dll that isn't used by the .exe. - Jay > CC: jkrell at elego.de; m3devel at elegosoft.com > From: hosking at cs.purdue.edu > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > Date: Sat, 19 Jan 2008 18:52:12 -0500 > To: jayk123 at hotmail.com > > OK, that's what I had hoped. > > Sounds good! > > On Jan 19, 2008, at 1:35 PM, Jay wrote: > > > ps -- look at m3-sys/cminstall/src/config/NT386GNU. > > While it is very very similar to NT386, and even outputs foo.lib > > and foo.lib.sa like NT386, it uses gcc for C compilation, linking, > > and m3cg for the backend. > > It is very "GNU" in tools, but not runtime. > > > > - Jay > > > > From: jayk123 at hotmail.com > > To: hosking at cs.purdue.edu; jkrell at elego.de > > CC: m3devel at elegosoft.com > > Subject: RE: [M3devel] [M3commit] CVS Update: cm3 > > Date: Sat, 19 Jan 2008 18:32:35 +0000 > > > > It DOES use m3cc/ld/as, and mklib for building static .libs, though > > that could probably be gcc/ar/dlltools if I figured it out. > > "Everything" except m3cc/m3gdb can be built with just MinGWin. > > Building m3cc requires MSys as well. > > Building m3gdb requires Cygwin. > > m3cg is not dependent on cygwin1.dll, nor are any other Modula-3 > > outputs. m3gdb is dependent on cygwin1.dll. > > > > Using Cygwin probably would work..and I could try it to see if it > > resolves the RTLinker problem. > > > > As well, we could have something like, in cm3.cfg you could set > > MINGWIN_ROOT, MSYS_ROOT, and/or CYGWIN_ROOT, to guide what tools > > are used, OR we can have some variable: > > > > GNU_MODE = 0 % Do not use GNU tools at all -- today's NT386 > > GNU_MODE = 1 % Use GNU tools minimally -- today's NT386GNU > > GNU_MODE = 2 % Use GNU tools maximally -- not existant but probably > > easy > > > > Eh..I know, not great.. what do "minimally" and "maximally" mean. > > > > I think we have the problem of a) many viable choices b) want to > > make several of them available c) just don't know what to call > > things and what the interface should be. As well as an interop > > question, since jmpbuf does vary in size between cygwin1.dl and > > everything else. > > > > Further down the line, there are other linkers, other compilers, > > other runtimes. The design here and now might take them into > > consideration. > > Gasp..I just realized, there is also another good backend option. > > parse.c's approach could probably be adapted to Open Watcom AND > > they might even take the changes (not that I have asked, I just > > thought of this). And that would net you progress toward a) 32 bit > > MS-DOS target b) OS/2 target, c) Netware target d) gcc-free Linux > > target, since the support all of them. > > Other target possibilities include Digital Mars compiler/linker, > > CodeWarrior (I know, dead and all), etc. Open Watcom is probably > > the most interesting since it is open source... > > > > - Jay > > > > > > > > > From: hosking at cs.purdue.edu > > > Date: Sat, 19 Jan 2008 12:48:06 -0500 > > > To: jkrell at elego.de > > > CC: m3devel at elegosoft.com > > > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > > > > > So, I am very confused now. Does NT386GNU no longer mean use of the > > > full set of GNU tools m3cc/ld/as, as would be available under > > > Cygwin? I thought the point of this was to be able to run in as much > > > of a GNU environment as possible. GNU to me means the whole > > > toolsuite not just m3cc. To me, a GNU-based environment on Windows > > > holds great attraction, since it consists of tools that I generally > > > always install on Windows, that I know, and are similar to the other > > > platforms I use. > > > > > > On Jan 19, 2008, at 4:11 AM, Jay Krell wrote: > > > > > > > CVSROOT: /usr/cvs > > > > Changes by: jkrell at birch. 08/01/19 04:11:34 > > > > > > > > Modified files: > > > > cm3/m3-libs/m3core/src/runtime/: m3makefile > > > > cm3/m3-sys/cminstall/src/config/: NT386GNU > > > > cm3/m3-sys/m3front/src/builtinInfo/: InfoModule.m3 > > > > cm3/m3-sys/m3middle/src/: Target.m3 > > > > > > > > Log message: > > > > m3-sys/m3middle/src/Target.m3 > > > > m3-libs/m3core/src/runtime/m3makefile > > > > m3-sys\m3front\src\builtinInfo\InfoModule.m3 > > > > > > > > switch NT386GNU to be Win32 instead of POSIX > > > > switch NT386GNU to _setjmp instead of setjmp > > > > jmp_buf size still big like Cygwin > > > > rewrite NT386GNU config file -- almost identical to NT386 > > > > mingwin required for building Modula-3 programs > > > > mingwin AND msys required for building m3cc > > > > > > > > To boot: > > > > > > > > install Python (www.activestate.com) > > > > > > > > have a working NT386 system > > > > get current source > > > > Mine is at c:\dev2\cm3.2 (cm3 is has other paused work, dev was > > > > taken by Unix) > > > > > > > > get and install binary distribution (5.1.3 works, anything newer > > > > should work) > > > > I install to c:\cm3 > > > > copy %CVSROOT%\m3-sys\cminstall\src\config\cm3.cfg to \cm3\bin > > > > \cm3.cfg > > > > > > > > Have a Visual C++ toolset (cl and link) > > > > and run the vcvars link on the start menu (this can/will be made > > > > easier) > > > > Almost any version should work. > > > > if you are using Visual C++ 8.0 (RTM?), rename away its mt.exe > > > > and get a newer from such as from the Platform SDK. Otherwise it > > > > crashes. > > > > This is not specific to NT386GNU, just that I recently removed the > > > > Platform SDK > > > > from my %PATH%. > > > > > > > > cd %CVSROOT%\scripts\python > > > > .\upgrade > > > > > > > > install msys and mingwin from http://www.mingw.org (links to > > > > SourceForge) > > > > for mingwin, you only need the "base" > > > > msys tells you to avoid mingwin make, in favor of msys make, and I > > > > did that > > > > > > > > I install to the defaults > > > > c:\msys\1.0 > > > > c:\mingw > > > > > > > > if you don't install to the defaults, add > > > > \bin and > > > to the start, but which order between the two?) > > > > > > > > if you do install to the defaults, scripts\python will fix path > > > > for you, > > > > if there is no gcc/as/sh on our $PATH > > > > > > > > cd %CVSROOT%\scripts\python > > > > upgrade && bootntgnu > > > > > > > > NOTE THE RESULTING BINARIES DO NOT YET WORK, but this is still > > > > progress. > > > > > > > > These instructions inevitably to be further tested and refined and > > > > placed elsewhere! > > > > > > > > > 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 jayk123 at hotmail.com Sun Jan 20 05:56:00 2008 From: jayk123 at hotmail.com (Jay) Date: Sun, 20 Jan 2008 04:56:00 +0000 Subject: [M3devel] more assembly symbols please? In-Reply-To: <1A973B4E-23DD-4B85-B42F-9070E93429BB@cs.purdue.edu> References: <2717B275-2548-41BC-BD1E-8742BCE6FA51@cs.purdue.edu> <1A973B4E-23DD-4B85-B42F-9070E93429BB@cs.purdue.edu> Message-ID: MinGWin (GNU ld) I might try putting together a totally Cygwin system to see if that works, to try to understand where the problem is. This really shouldn't be so hard from the information I have though.. :( Fishing with Cygwin should not be needed.. I can dump the ModuleInfo from C and I can see where the bad one is, I just need to trace through its creation to find where it goes bad... I assume it is NOT related to the fact that assembly/object file names get truncated to 8 characters, RTHeapInfo.m3 => RTHeapIn.m3 but so far that's all I see to "what is special about RTHeapInfo?". - Jay > CC: m3devel at elegosoft.com > From: hosking at cs.purdue.edu > Subject: Re: [M3devel] more assembly symbols please? > Date: Sat, 19 Jan 2008 18:46:59 -0500 > To: jayk123 at hotmail.com > > Which linker are you using? Could that be a factor? > > On Jan 19, 2008, at 1:49 PM, Jay wrote: > > > Thanks. m3cg -y for full tracing also dumps relevant stuff at the end. > > I'll try m3cgcat too. I should just be able to build/run an NT386 > > version. > > My C tracing does "prove" the problem is RTHeapInfo, but I still > > haven't figured out why. > > I've started skimming the code that builds that data...still a ways > > off from solving this I think. > > I have some suspicion the linker is moving things around that were > > otherwise correct, but I am far from proving that or fixing it. > > I'd like to first verify that the "m3front" / m3cg output is correct. > > The lack of labels in the as actually is a counter point to the > > movement theory, hard for linker to get a handle on anything to > > move around, it's just one blob. > > > > - Jay > > > > > > > > > CC: m3devel at elegosoft.com > > > From: hosking at cs.purdue.edu > > > Subject: Re: [M3devel] more assembly symbols please? > > > Date: Sat, 19 Jan 2008 12:33:08 -0500 > > > To: jayk123 at hotmail.com > > > > > > Take a look at the .mc intermediate code output if you want to see > > > that section of the data. There are at least comments. Use m3cgcat - > > > binary < x.mc > x.mo to view it (You can run m3cgcat on any other > > CM3 > > > install). > > > > > > On Jan 19, 2008, at 6:02 AM, Jay wrote: > > > > > > > Any chance the m3cg output could have, um, some symbols for the > > > > global data? > > > > It's kind of a pain to decode.. > > > > > > > > The module/import info is ok a lot, lots of runtime links ok. > > > > I think the bad one might be RTHeapInfo but I have to decode the > > > > very bare of symbols assembly.. > > > > or comments? Like for record fields? > > > > Still thinking of sticking a call out to C code...Even > > > > OutputDebugString since RTIO isn't working... > > > > > > > > I looked through the m3cg --help, didn't find anything. > > > > > > > > Tony? > > > > > > > > _MM_RTHeapInfo: > > > > 0 .long _L_1+224 > > > > 4 .long _MM_RTHeapInfo+52 > > > > 8 .long _MM_RTHeapInfo+308 > > > > 12,16 .space 8 > > > > 20 .long _L_1+152 > > > > 24 .space 4 > > > > 28 .long _L_1+220 > > > > 32 .long _L_1+220 > > > > 36 .long _MM_RTHeapInfo+160 > > > > 40 .space 4 > > > > .long _RTHeapInfo_M3 > > > > > > > > I get to count out to 160 bytes from here..: > > > > > > > > _L_1: > > > > 0 .byte 48 > > > > 1 .byte 49 > > > > 2 .byte 50 > > > > 3 .byte 51 > > > > 4 .byte 52 > > > > 5 .byte 53 > > > > 6 .byte 54 > > > > 7 .byte 55 > > > > 8 .byte 56 > > > > 9 .byte 57 > > > > a .byte 97 > > > > b .byte 98 > > > > c .byte 99 > > > > d .byte 100 > > > > e .byte 101 > > > > f .byte 102 > > > > 10 .long _RTHooks__TextLitInfo > > > > 14 .long _RTHooks__TextLitGetChar > > > > 18 .long _RTHooks__TextLitGetWideChar > > > > 1c .long _RTHooks__TextLitGetChars > > > > 20 .long _RTHooks__TextLitGetWideChars > > > > 24 .long 2 > > > > 28 .long _L_1+16 > > > > 2c .long 7 > > > > 30 .ascii "shownew" > > > > 37 .space 1 > > > > 38 .long 2 > > > > 3c .long _L_1+16 > > > > 40 .long 6 > > > > 44 .ascii "update" > > > > 4a .space 2 > > > > 4c .ascii "RTHeapInfo_M3" > > > > 50 .space 1 > > > > .ascii "Init" > > > > .space 1 > > > > > > > > I'll try the C code.. > > > > > > > > - Jay > > > > > > > > > > > > > > > > > > > > > > > > Connect and share in new ways with Windows Live. Get it now! > > > > > > > > > Shed those extra pounds with MSN and The Biggest Loser! Learn more. > _________________________________________________________________ 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 Jan 20 05:57:49 2008 From: jayk123 at hotmail.com (Jay) Date: Sun, 20 Jan 2008 04:57:49 +0000 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <5BFBD626-F492-4058-9A7A-6CB295753585@cs.purdue.edu> References: <20080119031134.4B6A510D4625@birch.elegosoft.com> <5BFBD626-F492-4058-9A7A-6CB295753585@cs.purdue.edu> Message-ID: Right, agreed, thanks for the reminder. - Jay > CC: jkrell at elego.de; m3devel at elegosoft.com > From: hosking at cs.purdue.edu > > On Jan 19, 2008, at 1:32 PM, Jay wrote: > > > Gasp..I just realized, there is also another good backend option. > > parse.c's approach could probably be adapted to Open Watcom AND > > they might even take the changes (not that I have asked, I just > > thought of this). And that would net you progress toward a) 32 bit > > MS-DOS target b) OS/2 target, c) Netware target d) gcc-free Linux > > target, since the support all of them. > > I would plump for llvm. Apple is using it heavily these days and may > be pushing it into their Mac compiler toolchain. _________________________________________________________________ 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 Jan 20 07:34:14 2008 From: jayk123 at hotmail.com (Jay) Date: Sun, 20 Jan 2008 06:34:14 +0000 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <200801200346.m0K3k3Em023728@camembert.async.caltech.edu> References: Your message of "Sat, 19 Jan 2008 12:48:06 EST." <200801200346.m0K3k3Em023728@camembert.async.caltech.edu> Message-ID: Mika, while I agree such a target might be interesting, and might just about work now, there is another target that is also definitely interesting, and more interesting to some folks, and perhaps more efficient, smaller, faster. There needs to be a way to ask for one or the other. People want one. People want the other. I think I've seen about two people ask for each. Wow a small number. There are tools and there is runtime, and you can pick and chose. But too many choices and people get confused, so there's a need to prepackage some combinations under small names. At the moment, NT386GNU means use GNU tools, but otherwise be like NT386. There are really several variables in all this. There are three threading models available, and they probably all work or could be easily made to. There are two underlying GUI libraries, ditto. There is PERHAPS Win9x compatibility to consider. Cygwin is dropping that in newer versions. What is a "target"? vs. what is a "configuration"? Odds are fairly good that if you merely alter $PATH one way or the other, and undo my small changes below to what m3makefile includes what, and what cm3 assumes OSTYPE is, Cygwin will work, at least as well as I have NT386GNU otherwise working. That is, all three of these targets are so darn similar that is almost just a matter of "configuration" and could perhaps be made so. I am reluctant to blow up the size of jmpbuf to enable arbitrary mixing however. The tricky part is not so much making it work, but what to call it, how to expose it to users, as well as perhaps streamlining the setup. I am better at "making it work" however and am open to suggestions all around. There is yet another direction and it is obviously the direction things were going -- neither GNU nor MS tools. There is already the x86 backend written in Modula-3. It is noticably very much faster than the gcc backend. There is very little C code in the system and it could probably all be rewritten in Modula-3..the beauty of its "optional safety"...though your point is very valid as to outside the system. There is already a start of a runtime linker that loads .objs. The C runtime dependency is very very minimal already. Finish those last two points and you have a "self contained" system , from a certain point of view, a common point of view, though there is still the dependency on kernel32.dll, user32.dll, gdi32.dll, the "OS" as people like to label it, though it is really just another bunch of code in most respects and not something as "special" as people think, and you can be more or less dependent on it as well -- remember that Modula-3 when using the vtalarm threads does its own scheduling (I think), a task people normally think of as provided by an "OS". (I believe Mary Fernandez already wrote a relatively easily retargetable linker and debugger in Modula-3, but I could be wrong.) I just realized another target -- NT386-Interix or such, these days known as "Services for Unix" and I think a free download. This is YET ANOTHER very Posixish environment. As well, there is the question from earlier of "What is Posix?" It's not like Microsoft doesn't provide open/read/write/close. They do. What all is in the Cygwin headers that people want? The availability of sh should have little impact on your Modula-3 code, right? You aren't running command lines in it, right? It's not like portable standard C and C++ can't be compiled just as well, if not better and faster, by the Microsoft compiler. It can be. I realize there are details, levels of ANSI conformity, and there are language extensions on both sides. Now, since I have been debugging stuff lately, I realize there could be a big question as to debuggers. More importantly, debug information format. My experience lately is that this is an either/or choice, and you can't have it both ways. If you are very used to gdb/m3gdb, you must use the GNU tools. But you don't need Cygwin (except to build m3gdb or acquire gdb). If you are very used to windbg/ntsd/cdb/Visual Studio, well you must use the non-gcc backend, the Microsoft C compiler for the little bit of C/C++ if you want to debug it, the Microsoft linker I assume, however you aren't going to be likely happy. The non-gcc backend only outputs line number information, no types, no locals. It's not a pleasant experience, but at least you can see the stack. You can also to some extent use both. You can build your code for either platform and flit around between the two. Or you can flit around between debuggers and deal with a lack of symbols in one, and just poke around in memory, using information gleaned from the other. But again, this doesn't have much to do with Cygwin or not Cygwin. I've only been going at this a short time, so maybe gdb does better with the Cygwin output. I don't know. Sorry for the tone. We are actually in agreement, essentially. I have been largely on the fence and just asking what to call things, and everyone else is clearly on one side or the other. I personally will not use Cygwin if I can help it, but I do use it for cvs and ssh at least. I actually hardlink swaths of it into my Windows directory, the useful command line utilities, that which likely one non-configurable version would suffice -- ie: not gcc/ld/ar/as. If there was one true gcc/ld/ar/as, I would hardlink it in too. Likewise with cl/link. e.g. I have windiff in there, but not cl/link. I don't want that cygwin1.dll dependency and then have to understand the licensing... So the non-Cygwin target came first. It is easier. It is faster. It is what I prefer. Maybe there will be a Cygwin target. Maybe someone else will provide it? It should be clear btw that the real work here was all done for us in gcc/ld, and cm3. The rest is easier. Besides..who is going to do the work here, and who is going to use it? Are Windows users asking for a more Posixish system or are Posix users saying what Windows should be like? Will they move to it? Bah humbug. - Jay > To: hosking at cs.purdue.edu> To: m3devel at elegosoft.com> Date: Sat, 19 Jan 2008 19:46:03 -0800> From: mika at async.caltech.edu> Subject: Re: [M3devel] [M3commit] CVS Update: cm3> > Can I add a perhaps obvious observation?> > NT386GNU must, of all things, mean that the code will compile and> link cleanly, with a minimum of fuss, against Cygwin's headers> and libraries. I have never used MS's C tools so I don't know> if this is the case with them. It is of course the case when> you use GNU ld, etc.> > When building large software in Modula-3 it's almost inevitable> that, since the language is used by so few people, you will have a> need to call out to C code (or Fortran code, or some other compiled> code, with C interfaces). If you develop on Unix and use Cygwin> to port to Windows, it makes no sense to distinguish between NT386> and NT386GNU unless the latter has pretty much the same environment> as the Unix system.> > Mika> > Tony Hosking writes:> >So, I am very confused now. Does NT386GNU no longer mean use of the > >full set of GNU tools m3cc/ld/as, as would be available under > >Cygwin? I thought the point of this was to be able to run in as much > >of a GNU environment as possible. GNU to me means the whole > >toolsuite not just m3cc. To me, a GNU-based environment on Windows > >holds great attraction, since it consists of tools that I generally > >always install on Windows, that I know, and are similar to the other > >platforms I use.> >> >On Jan 19, 2008, at 4:11 AM, Jay Krell wrote:> >> >> CVSROOT: /usr/cvs> >> Changes by: jkrell at birch. 08/01/19 04:11:34> >>> >> Modified files:> >> cm3/m3-libs/m3core/src/runtime/: m3makefile> >> cm3/m3-sys/cminstall/src/config/: NT386GNU> >> cm3/m3-sys/m3front/src/builtinInfo/: InfoModule.m3> >> cm3/m3-sys/m3middle/src/: Target.m3> >>> >> Log message:> >> m3-sys/m3middle/src/Target.m3> >> m3-libs/m3core/src/runtime/m3makefile> >> m3-sys\m3front\src\builtinInfo\InfoModule.m3> >> > >> switch NT386GNU to be Win32 instead of POSIX> >> switch NT386GNU to _setjmp instead of setjmp> >> jmp_buf size still big like Cygwin> >> rewrite NT386GNU config file -- almost identical to NT386> >> mingwin required for building Modula-3 programs> >> mingwin AND msys required for building m3cc> >> > >> To boot:> >> > >> install Python (www.activestate.com)> >> > >> have a working NT386 system> >> get current source> >> Mine is at c:\dev2\cm3.2 (cm3 is has other paused work, dev was > >> taken by Unix)> >> > >> get and install binary distribution (5.1.3 works, anything newer > >> should work)> >> I install to c:\cm3> >> copy %CVSROOT%\m3-sys\cminstall\src\config\cm3.cfg to \cm3\bin > >> \cm3.cfg> >> > >> Have a Visual C++ toolset (cl and link)> >> and run the vcvars link on the start menu (this can/will be made > >> easier)> >> Almost any version should work.> >> if you are using Visual C++ 8.0 (RTM?), rename away its mt.exe> >> and get a newer from such as from the Platform SDK. Otherwise it > >> crashes.> >> This is not specific to NT386GNU, just that I recently removed the > >> Platform SDK> >> from my %PATH%.> >> > >> cd %CVSROOT%\scripts\python> >> .\upgrade> >> > >> install msys and mingwin from http://www.mingw.org (links to > >> SourceForge)> >> for mingwin, you only need the "base"> >> msys tells you to avoid mingwin make, in favor of msys make, and I > >> did that> >> > >> I install to the defaults> >> c:\msys\1.0> >> c:\mingw> >> > >> if you don't install to the defaults, add> >> \bin and >> to the start, but which order between the two?)> >> > >> if you do install to the defaults, scripts\python will fix path > >> for you,> >> if there is no gcc/as/sh on our $PATH> >> > >> cd %CVSROOT%\scripts\python> >> upgrade && bootntgnu> >> > >> NOTE THE RESULTING BINARIES DO NOT YET WORK, but this is still > >> progress.> >> > >> These instructions inevitably to be further tested and refined and > >> placed elsewhere! _________________________________________________________________ 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 Jan 20 13:08:20 2008 From: jayk123 at hotmail.com (Jay) Date: Sun, 20 Jan 2008 12:08:20 +0000 Subject: [M3devel] more assembly symbols please? In-Reply-To: <1A973B4E-23DD-4B85-B42F-9070E93429BB@cs.purdue.edu> References: <2717B275-2548-41BC-BD1E-8742BCE6FA51@cs.purdue.edu> <1A973B4E-23DD-4B85-B42F-9070E93429BB@cs.purdue.edu> Message-ID: Exact same result with MS link. Quite the succesful interop. :) I copied in all the relevant *o and *obj files (avoiding mklib/*.lib as a factor) to C:\dev2\cm3.2\m3-sys\cm3\NT386GNU and selectively from \mingw\lib (like just in the end libcgcc.a for arithmetic helpers) and then link -out:cm3.exe *.io *.mo *.obj comctl32.lib gdi32.lib user32.lib wsock32.lib netapi32.lib libgcc.a kernel32.lib advapi32.lib msvcrt.lib prints the same thing, crashes due to the same data. Which is to say, in the great toolset debate, you can use the gcc back end (and as) for Modula-3, but then either ld or link and probably cl or gcc. :) Except..it still doesn't quite work.. I guess "collect2" is a synonym for ld? - Jay From: jayk123 at hotmail.comTo: hosking at cs.purdue.eduCC: m3devel at elegosoft.comSubject: RE: [M3devel] more assembly symbols please?Date: Sun, 20 Jan 2008 04:56:00 +0000 MinGWin (GNU ld)I might try putting together a totally Cygwin system to see if that works, to try to understand where the problem is.This really shouldn't be so hard from the information I have though.. :(Fishing with Cygwin should not be needed..I can dump the ModuleInfo from C and I can see where the bad one is, I just need to trace through its creation to find where it goes bad...I assume it is NOT related to the fact that assembly/object file names get truncated to 8 characters, RTHeapInfo.m3 => RTHeapIn.m3 but so far that's all I see to "what is special about RTHeapInfo?". - Jay > CC: m3devel at elegosoft.com> From: hosking at cs.purdue.edu> Subject: Re: [M3devel] more assembly symbols please?> Date: Sat, 19 Jan 2008 18:46:59 -0500> To: jayk123 at hotmail.com> > Which linker are you using? Could that be a factor?> > On Jan 19, 2008, at 1:49 PM, Jay wrote:> > > Thanks. m3cg -y for full tracing also dumps relevant stuff at the end.> > I'll try m3cgcat too. I should just be able to build/run an NT386 > > version.> > My C tracing does "prove" the problem is RTHeapInfo, but I still > > haven't figured out why.> > I've started skimming the code that builds that data...still a ways > > off from solving this I think.> > I have some suspicion the linker is moving things around that were > > otherwise correct, but I am far from proving that or fixing it.> > I'd like to first verify that the "m3front" / m3cg output is correct.> > The lack of labels in the as actually is a counter point to the > > movement theory, hard for linker to get a handle on anything to > > move around, it's just one blob.> >> > - Jay> >> >> >> > > CC: m3devel at elegosoft.com> > > From: hosking at cs.purdue.edu> > > Subject: Re: [M3devel] more assembly symbols please?> > > Date: Sat, 19 Jan 2008 12:33:08 -0500> > > To: jayk123 at hotmail.com> > >> > > Take a look at the .mc intermediate code output if you want to see> > > that section of the data. There are at least comments. Use m3cgcat -> > > binary < x.mc > x.mo to view it (You can run m3cgcat on any other > > CM3> > > install).> > >> > > On Jan 19, 2008, at 6:02 AM, Jay wrote:> > >> > > > Any chance the m3cg output could have, um, some symbols for the> > > > global data?> > > > It's kind of a pain to decode..> > > >> > > > The module/import info is ok a lot, lots of runtime links ok.> > > > I think the bad one might be RTHeapInfo but I have to decode the> > > > very bare of symbols assembly..> > > > or comments? Like for record fields?> > > > Still thinking of sticking a call out to C code...Even> > > > OutputDebugString since RTIO isn't working...> > > >> > > > I looked through the m3cg --help, didn't find anything.> > > >> > > > Tony?> > > >> > > > _MM_RTHeapInfo:> > > > 0 .long _L_1+224> > > > 4 .long _MM_RTHeapInfo+52> > > > 8 .long _MM_RTHeapInfo+308> > > > 12,16 .space 8> > > > 20 .long _L_1+152> > > > 24 .space 4> > > > 28 .long _L_1+220> > > > 32 .long _L_1+220> > > > 36 .long _MM_RTHeapInfo+160> > > > 40 .space 4> > > > .long _RTHeapInfo_M3> > > >> > > > I get to count out to 160 bytes from here..:> > > >> > > > _L_1:> > > > 0 .byte 48> > > > 1 .byte 49> > > > 2 .byte 50> > > > 3 .byte 51> > > > 4 .byte 52> > > > 5 .byte 53> > > > 6 .byte 54> > > > 7 .byte 55> > > > 8 .byte 56> > > > 9 .byte 57> > > > a .byte 97> > > > b .byte 98> > > > c .byte 99> > > > d .byte 100> > > > e .byte 101> > > > f .byte 102> > > > 10 .long _RTHooks__TextLitInfo> > > > 14 .long _RTHooks__TextLitGetChar> > > > 18 .long _RTHooks__TextLitGetWideChar> > > > 1c .long _RTHooks__TextLitGetChars> > > > 20 .long _RTHooks__TextLitGetWideChars> > > > 24 .long 2> > > > 28 .long _L_1+16> > > > 2c .long 7> > > > 30 .ascii "shownew"> > > > 37 .space 1> > > > 38 .long 2> > > > 3c .long _L_1+16> > > > 40 .long 6> > > > 44 .ascii "update"> > > > 4a .space 2> > > > 4c .ascii "RTHeapInfo_M3"> > > > 50 .space 1> > > > .ascii "Init"> > > > .space 1> > > >> > > > I'll try the C code..> > > >> > > > - Jay> > > >> > > >> > > >> > > >> > > >> > > > Connect and share in new ways with Windows Live. Get it now!> > >> >> >> > Shed those extra pounds with MSN and The Biggest Loser! Learn more.> 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 wagner at elegosoft.com Sun Jan 20 15:56:49 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Sun, 20 Jan 2008 15:56:49 +0100 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: References: <20080119031134.4B6A510D4625@birch.elegosoft.com> Message-ID: <20080120155649.tl5ghxhnl8o0g4cs@mail.elegosoft.com> Quoting Jay : > Good, a happy customer. :) > >> GNU_MODE = 0 % Do not use GNU tools at all -- today's NT386 >> GNU_MODE = 1 % Use GNU tools minimally -- today's NT386GNU >> GNU_MODE = 2 % Use GNU tools maximally -- not existant but probably >> easy >> >> Eh..I know, not great.. what do "minimally" and "maximally" mean. > > I'm still fishing for anyone to provide answers to these > less important decisions that I have trouble with. > Otherwise maybe no NT Cygwin system. > > TARGETs = { NT386, NT386GNU, NT386CYGWIN }? > TARGETs = { NT386, NT386MINGWIN, NT386CYGWIN }? > TARGETs = { NT386 + GNU_MODE }? > > The one reason I don't favor NT386 + GNU_MODE is that Cygwin has a > much larger jmpbuf than the others. > I think same TARGET implies code can be linked together, and I think > varying jmpbuf implies otherwise. > So NT386 and NT386MINGWIN should rarely cross paths with NT386CYGWIN. I think a new target is called for if I have understood everything right. We need one pure native target (NT386), one pure-Cygwin-based target (NT386_CYGWIN?) and one mix of runtime, gnu tools and mingwin (NT386_MINGWIN?). As NT386GNU already exists, we must decide if we want to use it as we traditionally did (all Cygwin) or the mixed implementation (Mingwin and much Windows RT). > I also do NOT like this ad-hoc naming style. > PPC_DARWIN, I386_DARWIN are much more to my style. > The names should be somehow hierarchical, except, I realize, there > isn't necessarily one "path" of > stuff which to name platforms, though the GNU folks have settled on > a way or two. > They have triples or quadruples -- processor-hardware-os or such, > however this doesn't > clearly suffice. Well, yes, something more systematic would have been better, but to break with the history will cause much trouble for all users and the infrastructure. So I'd rather vote that only new targets get more systematic names. > Something that accomodates: > NT386 + LLVM > NT386 + Watcom, linker and/or backend and/or runtime > NT386 + Digital Mars linker and/or backend and/or runtime > A C generating backend, and then linker/runtime > and similar IA64, AMD64 variants would be good. I'm not sure that a C generating backend would really help matters. This was done in the first implementation of DEC, and they soon abandoned it as C had proven to be a bad choice as intermediate language. I agree it would be great for cross-compilation etc. As far as C and RT dependencies of native Windows compilers go, I don't see why this couldn't be just a question of another cm3.cfg setup. > To a large extent, these can be few platforms, subject to > configuration, like if all > the linkers consume a common file format (not clear), and if all the > jmpbufs are the same > size (known to be partly true, partly false). Yes, jmpbuf is always a problem for user threads and exceptions. On Unix systems the jmpbuf and other important low-level structures are always defined by the system headers and independent of compilers AFAIK, so I'm a bit surprised that it should be different on Windows. But maybe I'm just wrong and haven't just seen the right counter examples... > Oh and another thing, the runtime dependency is very likely cuttable, however > PRESUMABLY real world applications (if there are any) link in a > substantial amount of > C or C++, in which case, it isn't necessarily cuttable. Yes. Real world applications tend to link other libraries (C, C++, Fortran, ...) and even often call other applications like sh etc. > As well, if I can figure out a good way to do it, switching NT386 > from awful slow > frequent TlsGetValue/TlsSetValue to manipulating the linked list in > fs:0, that would be nice, > and might incur a C runtime dependency, but well worth it. The way > Modula-3 works here > is terrible. Another compromise option is probably > __declspec(thread), though there is trickiness there > in terms of being in a .dll that isn't used by the .exe. Such optimizations should be done depending on the target. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Jan 20 17:26:28 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 20 Jan 2008 11:26:28 -0500 Subject: [M3devel] my status on win32 In-Reply-To: <479267C2.1E75.00D7.1@scires.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> <477EA137.1E75.00D7.1@scires.com> <478D394B.1E75.00D7.1@scires.com> <478D47FB.1E75.00D7.1@scires.com> <478DBF8D.1E75.00D7.1@scires.com> <478DE973.1E75.00D7.1@scires.com> <47908659.1E75.00D7.1@scires.com> <20080119204810.3wmumqgms88sccw4@mail.elegosoft.com> <479267C2.1E75.00D7.1@scires.com> Message-ID: I'm not sure what I mean since I am a Windows ignoramus. Jay? On Jan 19, 2008, at 9:12 PM, Randy Coleburn wrote: > Hi Tony: > > Are you suggesting that when the program is built standalone it > maps libraries differently? I know there is a difference between > dynamic vs. static libraries, but are you suggesting that a > different library is being mapped than the vendor's equivalent of > the dynamic library? How would I check for this situation? > > Your suggestion seems plausible since the source is not recompiled; > instead, the linker is used to change the way the EXE is put > together and that seems to cause the difference in operation as far > as pixmaps are concerned. > > Regards, > Randy > > >>> Tony Hosking 1/19/2008 6:47 PM >>> > I would perhaps suspect a bad library mapping. > > On Jan 19, 2008, at 2:48 PM, Olaf Wagner wrote: > > > Quoting Randy Coleburn : > >> 1. pixmaps aren't rendered properly on the screen. They look > really > >> bad. I recall having this problem a while back with one of the > early > >> 5.x releases, so I guess it was never solved. I've got some old > test > >> programs I try to dig out and see if I can find out what is going > >> on. I > >> seem to recall that building standalone in the past seemed to > fix the > >> problem, so this is a real mystery. > > > > Hi Randy, > > > > I'm afraid I wasn't able to solve it directly some years ago and > > then forgot about it due to more urgent tasks. > > > > I think we should try to narrow down the location of the problem > > (i.e. is it in the runtime, code generation, linker, or windows > > libraries). > > > > As you still have the 4.1 code of the Windows libraries, could you > > first try to build them with the new compiler and see if it makes > > a difference if you link against them? > > > > It may also be worthwhile to compare the commands actually used > > for linking (use -commands). That is, before we turn to the actual > > generated code... > > > > I still haven't got Windows access here, so I can just suggest what > > to do... > > > > Olaf > > -- > > Olaf Wagner -- elego Software Solutions GmbH > > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, > > Germany > > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Jan 20 17:48:26 2008 From: jayk123 at hotmail.com (Jay) Date: Sun, 20 Jan 2008 16:48:26 +0000 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <20080120155649.tl5ghxhnl8o0g4cs@mail.elegosoft.com> References: <20080119031134.4B6A510D4625@birch.elegosoft.com> <20080120155649.tl5ghxhnl8o0g4cs@mail.elegosoft.com> Message-ID: > the infrastructure. So I'd rather vote that only new targets get> more systematic names. Of course, though the existing names suggest new names, and not clear the value of the existing NT386GNU. Ie. is there a benefit to keep it in use with some meaning or not? Cygwin does have a larger jmpbuf than msvcr*.dll/mingwin. I think it holds sigaction state besides register state. "NT" and "Win" seem redundant. I386_MINGWIN? I386_CYGWIN? NT386_GNU? NT386_MINGNU? Ok, I admit that NT386_CYGWIN NT386_MINGWIN despite the redundancy, clearly point to existing projects that probably have name recognition. And building from NT386 is reasonable -- as was I saying about existing names influencing new names. A C generating backend gets you perhaps easier retargeting as well. I do see there is "MINGWIN64" out there, for AMD64. Not sure what the state of IA64 is though... (See -- you should avoid saying "32" or "64" in stuff, Win32 => Win, Win64 => Win.) I also would agree that creating one target instead of two is probably a good idea -- seems easier. I am not sure if current state is relevant. I mean, is NT386GNU really working and in use anywhere? Is PM3 in use? If so, then matching their meaning would be good. Or even going beyond that -- to Trestle on X Windows. :) (Though CygwinX doesn't exactly appear active.) And thus the precedent for no underscore. NT386MINGWIN ? NT386MINGNU ? I don't know if "MSYS" needs a place in this name. It is needed for building m3cc. I wonder if a hybrid/adaptive approach will be desired -- if Cygwin is available, the MinGWin target could use it to build m3gdb, since it can't otherwise. Hint for anyone trying out Cygwin and getting an odd mix of paths: mkdir \cygdrive get junction.exe from the former www.sysinternals.com junction \cygdrive\c c:\ now when some Cygwin code passes /cygdrive/c to Win32 code, it will just work, no translation needed. If you have multiple drives, I guess just fully populate each one c:\cygdrive\c => c:\ c:\cygdrive\d => d:\ d:\cygdrive\c => c:\ d:\cygdrive\d => d:\ etc. but I haven't tried that. Or, to reduce the multiplication, set them all up on c: and have d:\cygdrive => c:\cygdrive, e:\cygdrive => c:\cygdrive, etc. - Jay > Date: Sun, 20 Jan 2008 15:56:49 +0100> From: wagner at elegosoft.com> To: m3devel at elegosoft.com> Subject: Re: [M3devel] [M3commit] CVS Update: cm3> > Quoting Jay :> > > Good, a happy customer. :)> >> >> GNU_MODE = 0 % Do not use GNU tools at all -- today's NT386> >> GNU_MODE = 1 % Use GNU tools minimally -- today's NT386GNU> >> GNU_MODE = 2 % Use GNU tools maximally -- not existant but probably> >> easy> >>> >> Eh..I know, not great.. what do "minimally" and "maximally" mean.> >> > I'm still fishing for anyone to provide answers to these> > less important decisions that I have trouble with.> > Otherwise maybe no NT Cygwin system.> >> > TARGETs = { NT386, NT386GNU, NT386CYGWIN }?> > TARGETs = { NT386, NT386MINGWIN, NT386CYGWIN }?> > TARGETs = { NT386 + GNU_MODE }?> >> > The one reason I don't favor NT386 + GNU_MODE is that Cygwin has a > > much larger jmpbuf than the others.> > I think same TARGET implies code can be linked together, and I think > > varying jmpbuf implies otherwise.> > So NT386 and NT386MINGWIN should rarely cross paths with NT386CYGWIN.> > I think a new target is called for if I have understood everything right.> We need one pure native target (NT386), one pure-Cygwin-based target> (NT386_CYGWIN?) and one mix of runtime, gnu tools and mingwin> (NT386_MINGWIN?).> > As NT386GNU already exists, we must decide if we want to use it as> we traditionally did (all Cygwin) or the mixed implementation> (Mingwin and much Windows RT).> > > I also do NOT like this ad-hoc naming style.> > PPC_DARWIN, I386_DARWIN are much more to my style.> > The names should be somehow hierarchical, except, I realize, there > > isn't necessarily one "path" of> > stuff which to name platforms, though the GNU folks have settled on > > a way or two.> > They have triples or quadruples -- processor-hardware-os or such, > > however this doesn't> > clearly suffice.> > Well, yes, something more systematic would have been better, but> to break with the history will cause much trouble for all users and> the infrastructure. So I'd rather vote that only new targets get> more systematic names.> > > Something that accomodates:> > NT386 + LLVM> > NT386 + Watcom, linker and/or backend and/or runtime> > NT386 + Digital Mars linker and/or backend and/or runtime> > A C generating backend, and then linker/runtime> > and similar IA64, AMD64 variants would be good.> > I'm not sure that a C generating backend would really help matters.> This was done in the first implementation of DEC, and they soon> abandoned it as C had proven to be a bad choice as intermediate language.> I agree it would be great for cross-compilation etc.> > As far as C and RT dependencies of native Windows compilers go, I don't> see why this couldn't be just a question of another cm3.cfg setup.> > > To a large extent, these can be few platforms, subject to > > configuration, like if all> > the linkers consume a common file format (not clear), and if all the > > jmpbufs are the same> > size (known to be partly true, partly false).> > Yes, jmpbuf is always a problem for user threads and exceptions.> On Unix systems the jmpbuf and other important low-level structures> are always defined by the system headers and independent of compilers> AFAIK, so I'm a bit surprised that it should be different on Windows.> But maybe I'm just wrong and haven't just seen the right counter> examples...> > > Oh and another thing, the runtime dependency is very likely cuttable, however> > PRESUMABLY real world applications (if there are any) link in a > > substantial amount of> > C or C++, in which case, it isn't necessarily cuttable.> > Yes. Real world applications tend to link other libraries (C, C++,> Fortran, ...) and even often call other applications like sh etc.> > > As well, if I can figure out a good way to do it, switching NT386 > > from awful slow> > frequent TlsGetValue/TlsSetValue to manipulating the linked list in > > fs:0, that would be nice,> > and might incur a C runtime dependency, but well worth it. The way > > Modula-3 works here> > is terrible. Another compromise option is probably > > __declspec(thread), though there is trickiness there> > in terms of being in a .dll that isn't used by the .exe.> > Such optimizations should be done depending on the target.> > Olaf> -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 hosking at cs.purdue.edu Sun Jan 20 18:02:32 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 20 Jan 2008 12:02:32 -0500 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <20080120110109.92CCC10D4628@birch.elegosoft.com> References: <20080120110109.92CCC10D4628@birch.elegosoft.com> Message-ID: Jay, I am particularly disturbed by these changes you just committed because of the nasty reliance they impose on C in this part of the run-time library. Part of the beauty of M3 is that its compiler and libraries are almost entirely programmed in Modula-3. Your change here has been made to satisfy a need to debug a severely broken run- time system. Better in such situations to use a standard debugger rather than pollute the Modula-3 code with nasty reliance on C. If you need to use such hacks in your debugging please do so in your privately checked out working directories rather than imposing them on the rest of us by checking into the main tree. If you need a debugging source tree in which to play then there is ample provision using CVS to fork a development branch that is off the main trunk. Shall I undo these hacks or will you? It is important in a collaborative effort such as this to make sure that we all play nicely in the shared CVS space. In this case I think you have regressed the code base by adding these C-based hacks. Best, -- Tony On Jan 20, 2008, at 12:01 PM, Jay Krell wrote: > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 08/01/20 12:01:09 > > Modified files: > cm3/m3-libs/m3core/src/runtime/common/: RTLinker.i3 RTLinker.m3 > m3makefile > Added files: > cm3/m3-libs/m3core/src/runtime/common/: RTLinkerC.c > > Log message: > allow RTLinker's tracing to work when things are more broken > the default behavior is unchanged, and the behavior with > @M3tracelinker > is preserved > a change in behavior requires modifying RTLinkerC.c and rebuilding > this also enables more verbose tracing From hosking at cs.purdue.edu Sun Jan 20 18:06:03 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 20 Jan 2008 12:06:03 -0500 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: References: <20080119031134.4B6A510D4625@birch.elegosoft.com> <20080120155649.tl5ghxhnl8o0g4cs@mail.elegosoft.com> Message-ID: On Jan 20, 2008, at 11:48 AM, Jay wrote: > > the infrastructure. So I'd rather vote that only new targets get > > more systematic names. > > Of course, though the existing names suggest new names, and > not clear the value of the existing NT386GNU. Ie. is there a benefit > to keep it in use with some meaning or not? Since others have made historic associations for the names we should probably keep their original meaning. I agree with Olaf here. From jayk123 at hotmail.com Sun Jan 20 18:13:52 2008 From: jayk123 at hotmail.com (Jay) Date: Sun, 20 Jan 2008 17:13:52 +0000 Subject: [M3devel] my status on win32 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> <477EA137.1E75.00D7.1@scires.com> <478D394B.1E75.00D7.1@scires.com> <478D47FB.1E75.00D7.1@scires.com> <478DBF8D.1E75.00D7.1@scires.com> <478DE973.1E75.00D7.1@scires.com> <47908659.1E75.00D7.1@scires.com> <20080119204810.3wmumqgms88sccw4@mail.elegosoft.com> <479267C2.1E75.00D7.1@scires.com> Message-ID: I'm not sure what you mean either Tony. :) But you got me thinking. Standalone vs. non standalone are mostly a transparent size optimization. But there is the state sharing vs. not. If there is some: static int i; int GetGlobal(void) { return i; } void SetGlobal(int j) { return i = j; } in a dll then there is just one i process wide. With a static .lib, each client .dll/.so/.exe would get its own i. However Modula-3 doesn't offer standalone .dlls so some of that is moot. The repro is so easy, I'm sure we'll get it before much longer, but I'd like to fix the GNU ModuleInfo first. - Jay > From: hosking at cs.purdue.edu> Date: Sun, 20 Jan 2008 11:26:28 -0500> To: rcoleburn at scires.com> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] my status on win32> > I'm not sure what I mean since I am a Windows ignoramus. Jay?> > On Jan 19, 2008, at 9:12 PM, Randy Coleburn wrote:> > > Hi Tony:> >> > Are you suggesting that when the program is built standalone it > > maps libraries differently? I know there is a difference between > > dynamic vs. static libraries, but are you suggesting that a > > different library is being mapped than the vendor's equivalent of > > the dynamic library? How would I check for this situation?> >> > Your suggestion seems plausible since the source is not recompiled; > > instead, the linker is used to change the way the EXE is put > > together and that seems to cause the difference in operation as far > > as pixmaps are concerned.> >> > Regards,> > Randy> >> > >>> Tony Hosking 1/19/2008 6:47 PM >>>> > I would perhaps suspect a bad library mapping.> >> > On Jan 19, 2008, at 2:48 PM, Olaf Wagner wrote:> >> > > Quoting Randy Coleburn :> > >> 1. pixmaps aren't rendered properly on the screen. They look > > really> > >> bad. I recall having this problem a while back with one of the > > early> > >> 5.x releases, so I guess it was never solved. I've got some old > > test> > >> programs I try to dig out and see if I can find out what is going> > >> on. I> > >> seem to recall that building standalone in the past seemed to > > fix the> > >> problem, so this is a real mystery.> > >> > > Hi Randy,> > >> > > I'm afraid I wasn't able to solve it directly some years ago and> > > then forgot about it due to more urgent tasks.> > >> > > I think we should try to narrow down the location of the problem> > > (i.e. is it in the runtime, code generation, linker, or windows> > > libraries).> > >> > > As you still have the 4.1 code of the Windows libraries, could you> > > first try to build them with the new compiler and see if it makes> > > a difference if you link against them?> > >> > > It may also be worthwhile to compare the commands actually used> > > for linking (use -commands). That is, before we turn to the actual> > > generated code...> > >> > > I still haven't got Windows access here, so I can just suggest what> > > to do...> > >> > > Olaf> > > --> > > Olaf Wagner -- elego Software Solutions GmbH> > > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin,> > > Germany> > > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 Sun Jan 20 18:24:10 2008 From: jayk123 at hotmail.com (Jay) Date: Sun, 20 Jan 2008 17:24:10 +0000 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: References: <20080120110109.92CCC10D4628@birch.elegosoft.com> Message-ID: You guys REALLY don't like C, eh? It's not a hack, any more so than the tracing that was there, and the existing tracing could be not turned on until "much" later in startup, and the debuggers have no type information, even gdb and I think m3gdb just seem to have void* everywhere, true, I could just dump the memory. Either way. I have a contrary view, in that if something is particularly gnarly such that someone had to write printing code, someone might need it in the future, maybe better to leave it available. However, on the other hand..I write this sort of printing all the time and leaving it all in would really blow up the size of the code base, even while most stuff usually works. In this case, printing code has been left there all along, an entire module dedicated to reduce-depending printing. Making it work much better, drastically cutting the dependency, seems reasonable. Actually RTIO should probably be rewritten in C instead of lumping the logging into RTLinker. It is a hack in that respect. I found it kind of disturbing how much RTIO reinvents, integer formating, buffering... (and yes I realize I have both such features under my code in stdio) Anyway, I'm not wedded to it. I wish it were easier to interface C with Modula-3. The type declarations I had to clone should be output by the Modula-3 compiler, and the names I chose should be either the default or easier to get, since they are the names used for Modula-3 code... (I'm not going to jump for a fork. My CVS skills stink. I'll just leave the files uncommited.) - Jay > From: hosking at cs.purdue.edu> Date: Sun, 20 Jan 2008 12:02:32 -0500> To: jkrell at elego.de> CC: m3devel at elegosoft.com; m3commit at elegosoft.com> Subject: Re: [M3devel] [M3commit] CVS Update: cm3> > Jay,> > I am particularly disturbed by these changes you just committed > because of the nasty reliance they impose on C in this part of the > run-time library. Part of the beauty of M3 is that its compiler and > libraries are almost entirely programmed in Modula-3. Your change > here has been made to satisfy a need to debug a severely broken run- > time system. Better in such situations to use a standard debugger > rather than pollute the Modula-3 code with nasty reliance on C. If > you need to use such hacks in your debugging please do so in your > privately checked out working directories rather than imposing them > on the rest of us by checking into the main tree. If you need a > debugging source tree in which to play then there is ample provision > using CVS to fork a development branch that is off the main trunk. > Shall I undo these hacks or will you?> > It is important in a collaborative effort such as this to make sure > that we all play nicely in the shared CVS space. In this case I > think you have regressed the code base by adding these C-based hacks.> > Best,> > -- Tony> > On Jan 20, 2008, at 12:01 PM, Jay Krell wrote:> > > CVSROOT: /usr/cvs> > Changes by: jkrell at birch. 08/01/20 12:01:09> >> > Modified files:> > cm3/m3-libs/m3core/src/runtime/common/: RTLinker.i3 RTLinker.m3> > m3makefile> > Added files:> > cm3/m3-libs/m3core/src/runtime/common/: RTLinkerC.c> >> > Log message:> > allow RTLinker's tracing to work when things are more broken> > the default behavior is unchanged, and the behavior with > > @M3tracelinker> > is preserved> > a change in behavior requires modifying RTLinkerC.c and rebuilding> > this also enables more verbose tracing> _________________________________________________________________ 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 Sun Jan 20 18:52:38 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 20 Jan 2008 12:52:38 -0500 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: References: <20080120110109.92CCC10D4628@birch.elegosoft.com> Message-ID: On Jan 20, 2008, at 12:24 PM, Jay wrote: > You guys REALLY don't like C, eh? > It's not a hack, any more so than the tracing that was there, and > the existing tracing could be not turned on until "much" later in > startup, and the debuggers have no type information, even gdb and I > think m3gdb just seem to have void* everywhere, true, I could just > dump the memory. The debuggers do have most type information on POSIX platforms. It's not that I don't like C, just that your use of it here was a little gratuitous. For this sort of low-level debugging memory dumps are your friend -- if you want to read something a little more symbolic put in a temporary hack in your private space. Just don't make the rest of us swallow it. Jay, I'm not trying to be hypercritical, just trying to preserve some cleanliness in the core library code. Please keep up your great work! Best regards, Tony > > > Either way. > > I have a contrary view, in that if something is particularly gnarly > such that someone had to write printing code, someone might need it > in the future, maybe better to leave it available. However, on the > other hand..I write this sort of printing all the time and leaving > it all in would really blow up the size of the code base, even > while most stuff usually works. > In this case, printing code has been left there all along, an > entire module dedicated to reduce-depending printing. Making it > work much better, drastically cutting the dependency, seems > reasonable. Actually RTIO should probably be rewritten in C instead > of lumping the logging into RTLinker. It is a hack in that respect. > I found it kind of disturbing how much RTIO reinvents, integer > formating, buffering... (and yes I realize I have both such > features under my code in stdio) > > Anyway, I'm not wedded to it. > I wish it were easier to interface C with Modula-3. The type > declarations I had to clone should be output by the Modula-3 > compiler, and the names I chose should be either the default or > easier to get, since they are the names used for Modula-3 code... > > (I'm not going to jump for a fork. My CVS skills stink. I'll just > leave the files uncommited.) > > - Jay > > > > > > From: hosking at cs.purdue.edu > > Date: Sun, 20 Jan 2008 12:02:32 -0500 > > To: jkrell at elego.de > > CC: m3devel at elegosoft.com; m3commit at elegosoft.com > > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > > > Jay, > > > > I am particularly disturbed by these changes you just committed > > because of the nasty reliance they impose on C in this part of the > > run-time library. Part of the beauty of M3 is that its compiler and > > libraries are almost entirely programmed in Modula-3. Your change > > here has been made to satisfy a need to debug a severely broken run- > > time system. Better in such situations to use a standard debugger > > rather than pollute the Modula-3 code with nasty reliance on C. If > > you need to use such hacks in your debugging please do so in your > > privately checked out working directories rather than imposing them > > on the rest of us by checking into the main tree. If you need a > > debugging source tree in which to play then there is ample provision > > using CVS to fork a development branch that is off the main trunk. > > Shall I undo these hacks or will you? > > > > It is important in a collaborative effort such as this to make sure > > that we all play nicely in the shared CVS space. In this case I > > think you have regressed the code base by adding these C-based > hacks. > > > > Best, > > > > -- Tony > > > > On Jan 20, 2008, at 12:01 PM, Jay Krell wrote: > > > > > CVSROOT: /usr/cvs > > > Changes by: jkrell at birch. 08/01/20 12:01:09 > > > > > > Modified files: > > > cm3/m3-libs/m3core/src/runtime/common/: RTLinker.i3 RTLinker.m3 > > > m3makefile > > > Added files: > > > cm3/m3-libs/m3core/src/runtime/common/: RTLinkerC.c > > > > > > Log message: > > > allow RTLinker's tracing to work when things are more broken > > > the default behavior is unchanged, and the behavior with > > > @M3tracelinker > > > is preserved > > > a change in behavior requires modifying RTLinkerC.c and rebuilding > > > this also enables more verbose tracing > > > > > Need to know the score, the latest news, or you need your Hotmail?- > get your "fix". Check it out. From jayk123 at hotmail.com Sun Jan 20 19:13:08 2008 From: jayk123 at hotmail.com (Jay) Date: Sun, 20 Jan 2008 18:13:08 +0000 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: References: <20080120110109.92CCC10D4628@birch.elegosoft.com> Message-ID: Hey I almost have this figured out. I compared RTHeapInfo.ms's MM_RTHeapInfo PPC_DARWIN vs. NT386GNU. They are almost the same. Ok, anyway, I decided, duh, let's disassembly the garbage data and see if it is code. It is. That roughly matches the PPC_DARWIN vs. NT386GNU diff where some numbers were off by 4. Therefore: The module info is this: 0:000> dc 0068113800681138 00681138 00000000 00603de0 00681144 when it should be: 0:000> dc 0068113800681138 xxxxx 00603de0 00681144 Two problems. One clear, one less clear. TYPE (* one of these is generated for each imported interface reference *) ImportInfo = RECORD import : ModulePtr; binder : Binder; (* returns "import" pointer *) next : ImportPtr; END; 4 bytes of padding are between import and binder. Making binder be used for next. Making a pointer to code vs. a pointer to data mixed up. That's a big problem. I understand. What I don't understand is the value of import. I walked the whole list of imports and in every case, the back pointer to the module was actually to the import itself. Huh? Perhaps I went wrong earlier and am off in the weeds..but I don't think so. I mean, the pointers are to self in any case and that's seldom correct data, unless they are empty circular singly linked lists.. I'll dig a bit more.. - Jay full debugging session...email is going to remove the newlines and make it unreadable probably.. Module 0x681020 ..\src\runtime\common\RTHeapInfo.m3 Imports 0x6810c0{Import 0x0, Binder 0x0, Next 0x603d60} (f88.aec): Access violation - code c0000005 (first chance) First chance exceptions are reported before any exception handling. This exception may be expected and handled. eax=8be58955 ebx=00000001 ecx=611030e8 edx=00008889 esi=611021a0 edi=006147e0 eip=006006a0 esp=0022cb70 ebp=0022cba8 iopl=0 nv up ei ng nz na pe nc cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00010286 *** ERROR: Module load completed but symbols could not be loaded for image00400000 image00400000+0x2006a0: 006006a0 8b00 mov eax,dword ptr [eax] ds:0023:8be58955=???????? 0:000> dc 0x681020 00681020 00680fe0 00681054 00681154 00000000 ..h.T.h.T.h..... 00681030 00000000 00680f98 00000000 00680fdc ......h.......h. 00681040 00680fdc 006810c0 00000000 0060053f ..h...h.....?.`. 00681050 00000003 00000000 6c810e28 72d376bc ........(..l.v.r 00681060 1e527894 01000201 00000000 00000000 .xR............. 00681070 00000000 00681004 00000000 00000000 ......h......... 00681080 0068100c 00000000 e545939d 00000000 ..h.......E..... 00681090 00000000 00000000 00000000 00681008 ..............h. 0:000> dc 006810c0 006810c0 00000000 00000000 00603d60 006810cc ........`=`...h. 006810d0 00000000 005fb070 006810d8 00000000 ....p._...h..... 006810e0 005fb4a0 006810e4 00000000 005f1c00 .._...h......._. 006810f0 006810f0 00000000 005f58d0 006810fc ..h......X_...h. 00681100 00000000 00606500 00681108 00000000 .....e`...h..... 00681110 006064f0 00681114 00000000 005f8790 .d`...h......._. 00681120 00681120 00000000 00605350 0068112c .h.....PS`.,.h. 00681130 00000000 00606520 00681138 00000000 .... e`.8.h..... oops, code not data, let's try the next one 0:000> dc 00603d60 00603d60 8be58955 d0b80845 c900681a 909090c3 U...E....h...... 00603d70 8be58955 90b80845 c900681b e58955c3 U...E....h...U.. 00603d80 ec835657 08458b20 8904c083 1bf8a1c2 WV.. .E......... 00603d90 f4050068 8b000000 dc7d8d00 b8fcc689 h.........}..... 00603da0 00000007 a5f3c189 758dd789 07b8fcdc ...........u.... 00603db0 89000000 83a5f3c1 5f5e20c4 9090c3c9 ......... ^_.... 00603dc0 8be58955 70b80845 c900681c 909090c3 U...E..p.h...... 00603dd0 8be58955 10b80845 c900681d 909090c3 U...E....h...... 0:000> dc 006810cc 006810cc 006810cc 00000000 005fb070 006810d8 ..h.....p._...h. 006810dc 00000000 005fb4a0 006810e4 00000000 ......_...h..... 006810ec 005f1c00 006810f0 00000000 005f58d0 .._...h......X_. 006810fc 006810fc 00000000 00606500 00681108 ..h......e`...h. 0068110c 00000000 006064f0 00681114 00000000 .....d`...h..... 0068111c 005f8790 00681120 00000000 00605350 .._. .h.....PS`. 0068112c 0068112c 00000000 00606520 00681138 ,.h..... e`.8.h. 0068113c 00000000 00603de0 00681144 00000000 .....=`.D.h..... 0:000> dc 006810d8 006810d8 006810d8 00000000 005fb4a0 006810e4 ..h......._...h. 006810e8 00000000 005f1c00 006810f0 00000000 ......_...h..... 006810f8 005f58d0 006810fc 00000000 00606500 .X_...h......e`. 00681108 00681108 00000000 006064f0 00681114 ..h......d`...h. 00681118 00000000 005f8790 00681120 00000000 ......_. .h..... 00681128 00605350 0068112c 00000000 00606520 PS`.,.h..... e`. 00681138 00681138 00000000 00603de0 00681144 8.h......=`.D.h. 00681148 00000000 005dfc00 00000000 00680f00 ......].......h. oops, this is code not data 0:000> dc 005fb4a0 005fb4a0 8be58955 80b80845 c90067af 909090c3 U...E....g......005fb4b0 8be58955 40b80845 c90067b1 909090c3 U...E.. at .g......005fb4c0 83e58955 45c738ec 000000dc 08458b00 U....8.E......E.005fb4d0 8b04c083 d8458900 83d8458b 1d7f0ff8 ......E..E......005fb4e0 8308458b e8500cec 00011e94 8910c483 .E....P.........005fb4f0 458be045 cc4589e0 0000f9e9 d8458b00 E..E..E.......E.005fb500 500cec83 0000f2e8 10c48300 8be04589 ...P.........E..005fb510 4589e045 d8458bdc 8e0fc085 000000d0 E..E..E......... let's try the next one 0:000> dc 006810e4 006810e4 006810e4 00000000 005f1c00 006810f0 ..h......._...h.006810f4 00000000 005f58d0 006810fc 00000000 .....X_...h.....00681104 00606500 00681108 00000000 006064f0 .e`...h......d`.00681114 00681114 00000000 005f8790 00681120 ..h......._. .h.00681124 00000000 00605350 0068112c 00000000 ....PS`.,.h.....00681134 00606520 00681138 00000000 00603de0 e`.8.h......=`.00681144 00681144 00000000 005dfc00 00000000 D.h.......].....00681154 00680f00 00000000 6c810e28 00000002 ..h.....(..l.... 0:000> dc 006810e4 006810e4 006810e4 00000000 005f1c00 006810f0 ..h......._...h.006810f4 00000000 005f58d0 006810fc 00000000 .....X_...h.....00681104 00606500 00681108 00000000 006064f0 .e`...h......d`.00681114 00681114 00000000 005f8790 00681120 ..h......._. .h.00681124 00000000 00605350 0068112c 00000000 ....PS`.,.h.....00681134 00606520 00681138 00000000 00603de0 e`.8.h......=`.00681144 00681144 00000000 005dfc00 00000000 D.h.......].....00681154 00680f00 00000000 6c810e28 00000002 ..h.....(..l.... show it to be code btw (I did this earlier, not sure what happened in the log;I cannot represent byte patterns as x86 code by sight, but the disassembly is spot on) 0:000> u 005f1c00 image00400000+0x1f1c00:005f1c00 55 push ebp005f1c01 89e5 mov ebp,esp005f1c03 8b4508 mov eax,dword ptr [ebp+8]005f1c06 b8a0906700 mov eax,offset image00400000+0x2790a0 (006790a0)005f1c0b c9 leave005f1c0c c3 ret005f1c0d 90 nop005f1c0e 90 nop ok, so again let's try the next 0:000> dc 006810f0 006810f0 006810f0 00000000 005f58d0 006810fc ..h......X_...h.00681100 00000000 00606500 00681108 00000000 .....e`...h.....00681110 006064f0 00681114 00000000 005f8790 .d`...h......._.00681120 00681120 00000000 00605350 0068112c .h.....PS`.,.h.00681130 00000000 00606520 00681138 00000000 .... e`.8.h.....00681140 00603de0 00681144 00000000 005dfc00 .=`.D.h.......].00681150 00000000 00680f00 00000000 6c810e28 ......h.....(..l00681160 00000002 00000000 00000000 00000000 ................ 0:000> dc 006810fc 006810fc 006810fc 00000000 00606500 00681108 ..h......e`...h.0068110c 00000000 006064f0 00681114 00000000 .....d`...h.....0068111c 005f8790 00681120 00000000 00605350 .._. .h.....PS`.0068112c 0068112c 00000000 00606520 00681138 ,.h..... e`.8.h.0068113c 00000000 00603de0 00681144 00000000 .....=`.D.h.....0068114c 005dfc00 00000000 00680f00 00000000 ..].......h.....0068115c 6c810e28 00000002 00000000 00000000 (..l............0068116c 00000000 79545452 52536570 33495f43 ....RTTypeSRC_I3 0:000> dc 00681108 00681108 00681108 00000000 006064f0 00681114 ..h......d`...h.00681118 00000000 005f8790 00681120 00000000 ......_. .h.....00681128 00605350 0068112c 00000000 00606520 PS`.,.h..... e`.00681138 00681138 00000000 00603de0 00681144 8.h......=`.D.h.00681148 00000000 005dfc00 00000000 00680f00 ......].......h.00681158 00000000 6c810e28 00000002 00000000 ....(..l........00681168 00000000 00000000 79545452 52536570 ........RTTypeSR00681178 33495f43 00000000 00600750 00681170 C_I3....P.`.p.h. it just keeps going, a pretty good linked listEXCEPT for the padding and the first pointer always looks wrong 0:000> dc 00681114 00681114 00681114 00000000 005f8790 00681120 ..h......._. .h.00681124 00000000 00605350 0068112c 00000000 ....PS`.,.h.....00681134 00606520 00681138 00000000 00603de0 e`.8.h......=`.00681144 00681144 00000000 005dfc00 00000000 D.h.......].....00681154 00680f00 00000000 6c810e28 00000002 ..h.....(..l....00681164 00000000 00000000 00000000 79545452 ............RTTy00681174 52536570 33495f43 00000000 00600750 peSRC_I3....P.`.00681184 00681170 00000000 735c2e2e 725c6372 p.h.......\src\r 0:000> dc 00681120 00681120 00681120 00000000 00605350 0068112c .h.....PS`.,.h.00681130 00000000 00606520 00681138 00000000 .... e`.8.h.....00681140 00603de0 00681144 00000000 005dfc00 .=`.D.h.......].00681150 00000000 00680f00 00000000 6c810e28 ......h.....(..l00681160 00000002 00000000 00000000 00000000 ................00681170 79545452 52536570 33495f43 00000000 RTTypeSRC_I3....00681180 00600750 00681170 00000000 735c2e2e P.`.p.h.......\s00681190 725c6372 69746e75 635c656d 6f6d6d6f rc\runtime\commo 0:000> dc 0068112c 0068112c 0068112c 00000000 00606520 00681138 ,.h..... e`.8.h.0068113c 00000000 00603de0 00681144 00000000 .....=`.D.h.....0068114c 005dfc00 00000000 00680f00 00000000 ..].......h.....0068115c 6c810e28 00000002 00000000 00000000 (..l............0068116c 00000000 79545452 52536570 33495f43 ....RTTypeSRC_I30068117c 00000000 00600750 00681170 00000000 ....P.`.p.h.....0068118c 735c2e2e 725c6372 69746e75 635c656d ..\src\runtime\c0068119c 6f6d6d6f 54525c6e 65707954 2e435253 ommon\RTTypeSRC. 0:000> dc 00681138 00681138 00681138 00000000 00603de0 00681144 8.h......=`.D.h.00681148 00000000 005dfc00 00000000 00680f00 ......].......h.00681158 00000000 6c810e28 00000002 00000000 ....(..l........00681168 00000000 00000000 79545452 52536570 ........RTTypeSR00681178 33495f43 00000000 00600750 00681170 C_I3....P.`.p.h.00681188 00000000 735c2e2e 725c6372 69746e75 ......\src\runti00681198 635c656d 6f6d6d6f 54525c6e 65707954 me\common\RTType006811a8 2e435253 00003369 0068118c 00000000 SRC.i3....h..... 0:000> dc 00681144 00681144 00681144 00000000 005dfc00 00000000 D.h.......]..... 00681154 00680f00 00000000 6c810e28 00000002 ..h.....(..l.... 00681164 00000000 00000000 00000000 79545452 ............RTTy 00681174 52536570 33495f43 00000000 00600750 peSRC_I3....P.`. 00681184 00681170 00000000 735c2e2e 725c6372 p.h.......\src\r 00681194 69746e75 635c656d 6f6d6d6f 54525c6e untime\common\RT 006811a4 65707954 2e435253 00003369 0068118c TypeSRC.i3....h. 006811b4 00000000 00000000 00000000 00000000 ................ another confirmation of a code pointer 0:000> u 005dfc00 image00400000+0x1dfc00: 005dfc00 55 push ebp 005dfc01 89e5 mov ebp,esp 005dfc03 8b4508 mov eax,dword ptr [ebp+8] 005dfc06 b800516700 mov eax,offset image00400000+0x275100 (00675100) 005dfc0b c9 leave 005dfc0c c3 ret 005dfc0d 90 nop 005dfc0e 90 nop 0:000> This is the nice thing about command line debuggers, a textual log. _________________________________________________________________ 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 rcoleburn at scires.com Sun Jan 20 20:10:46 2008 From: rcoleburn at scires.com (Randy Coleburn) Date: Sun, 20 Jan 2008 14:10:46 -0500 Subject: [M3devel] pixmap problem In-Reply-To: <200801200341.m0K3feKM023564@camembert.async.caltech.edu> References: Your message of "Sat, 19 Jan 2008 17:54:00 +0100." <235688.77597.qm@web27110.mail.ukl.yahoo.com> <200801200341.m0K3feKM023564@camembert.async.caltech.edu> Message-ID: <47935664.1E75.00D7.1@scires.com> Mika / Daniel: Thanks for the test info! Well, based on what ya'll are reporting, I think the problem has to do with the NT386 platform. I also don't think it has to do necessarily with the source code. So, there must be something fishy going on in the NT386 world in the linkage step to cause this type of situation when switching between regular and buildstandalone(). Unfortunately, I'm probably not the right person to figure out what is wrong and fix it either. Hey, but at least I produced a short test program that reproduces the problem. Maybe Jay or someone can offer another suggestion on how to fix it. I do know for sure that the TestPixmap program does build and run correctly on cm3 v4.1 for both buildstandalone() and regular. So, there must be something that has changed since then to cause this behavior. Maybe there is some different argument set that needs to get passed to the linker. I don't know. Regards, Randy >>> Mika Nystrom 1/19/2008 10:41 PM >>> It works great on NT386GNU, PM3/Klagenfurt, as well, without the build_standalone. Mika "Daniel Alejandro Benavides D." writes: >--0-1095273535-1200761640=:77597 >Content-Type: text/plain; charset=iso-8859-1 >Content-Transfer-Encoding: 8bit > >Hi: >The TestPixmap does show a nice battery on LINUXLIBC6, Ubuntu Gutsy 2.6.22-14-386, 32 bits machine. > >Thanks > > >Jay wrote: .hmmessage P { margin:0px; padding:0px } body.hmmessage { FONT-SIZE: 10pt; FONT-FAMILY:Tahoma } I can repro > the two different behaviors on XP. > I was going to try on PPC_DARWIN but I guess Tony's info suffices. > > I tried rolling hand.c back to before I changed (months/year ago), since it is involved in bit twiddling, no change, phew. > > Debugging here is a big humungous pain. > NT386 has good stacks and line numbers, but no locals or type info, I'd really sometime like to get Codeview info into those .objs...I think it > is documented well enough, but still not necessarily easy, or maybe have a C generating backend partly for this reason (and to bring up more ta >rgets, using native tools), and function calls in disassembly I think don't resolve; NT386GNU can't yet build this, though it will soon, but I'm > not familiar with gdb and there appears to be no type info. I'm building m3gdb right now, I don't know if it will work, I hope it has type info >, and I'm not familiar with the relevant code. In gdb I struggle just to view bytes in memory, add numbers to addresses and see those, etc. I th >ink for MY problem, I'm going to link in C code to dump the structs. There is tracing code and I enabled it, but even it crashes in Text_Length. > At least MY problem crashes, hopefully near the problem, whereas your problem goes all the way through to completion with > no stopping to hint where the problem is. Darn it. :) on the mock rudeness and :( on the lack of a crash. > > You write the bundle out and it matches, so that doesn't rule out bundles as being the problem? (darn) > And bundles look pretty simple, a bundle is just a generated source file with a constant in it. > Maybe newline problems? That wouldn't make sense. I just downloaded some program that might let me separately view the ppm, maybe it'll reveal >something. > > The bad behavior has like regularly spaced solid color veritical bars a few pixels side across the whole picture, and regularly spaced vertical > stripes from the correct picture alternating with that. Perhaps someone with ppm/bitmap/graphics experience has seen this behavior and it resul >ts from some common pixmap mismanagement we could look for? > > I have to say this is very surprising. > > I always wondered, and now I pretty much assume -- Modula-3 never imports/exports data in its dynamic linking, right? It alway imports/exports >functions, right? > On Windows, functions have an optional optimization, but data must be handled differently at compile time if it is going to be dynamically impo >rted. > For functions, if you don't apply the optimization at compile time, the linker will just generate a single instruction thunk instead. > > That is, given a symbol Foo, there is a symbol __imp__Foo that is a pointer to the actual foo in another .dll/.so. > The loader only patches pointers, one per import if you build your .dll correctly, it doesn't patch instructions or code strewn throughout a .d >ll, just one contiguous array of pointers. MAYBE they don't have to be contiguous for each .dl you import from. > > That is, if call msvcrt!fopen, msvcrt!fclose, kernel32!Sleep, my .dll/.exe typically has an array: > > pointer to msvcrt!fopen > pointer to msvcrt!fclose > null > pointer to kernel32!Sleep > > But perhaps kernel32.dll's pointers and msvcrt.dll's pointers need not be adjacent. > > So, going back, my point/question is that, if the compiler knows the function is imported, it can call through __imp__Foo instead of calling Fo >o. > But if it calls Foo and you import Foo, the linker will create the function Foo that just jmps through __imp__Foo. > That doesn't work for data though. There's no ability to intervenve like that. > So for imported data, the compiler must generated a read and dereference of the pointer __imp__Foo for accesses to Foo, if Foo is to be importe >d. > Data imports may be faster when appropriate, but for this reason, I'd say they aren't worth it. > And for this reason, I HOPE Modula-3 never imports/exports data. > > Oh, you could, for data, always reference the pointer __imp_Foo, and if non materializes, create one. > However that would suck perf in order to make an uncommon case work. > I hope Modula-3 doesn't do that either. :) > Though I guess since this global data in question...maybe it is rare??? > > Later, > - Jay > > > >--------------------------------- > > > From: hosking at cs.purdue.edu >> Date: Sat, 19 Jan 2008 03:09:47 -0500 >> To: rcoleburn at scires.com >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] pixmap problem >> >> Looks fine to me on I386_DARWIN. >> >> On Jan 19, 2008, at 12:31 AM, Randy Coleburn wrote: >> >> > >> > > > >--------------------------------- >Need to know the score, the latest news, or you need your Hotmail*-get your "fix" Check it out. > > >--------------------------------- > >Web Revelaci*n Yahoo! 2007: > Premio Favorita del P*blico - ?Vota tu preferida! >--0-1095273535-1200761640=:77597 >Content-Type: text/html; charset=iso-8859-1 >Content-Transfer-Encoding: 8bit > >Hi:
The TestPixmap does show a nice battery on LINUXLIBC6, Ubuntu Gutsy 2.6.22-14-386, 32 bits machine.

Thanks


Jay &l >t;jayk123 at hotmail.com> wrote:
I can repro the two > different behaviors on XP.
I was going to try on PPC_DARWIN but I guess Tony's info suffices.
 
I tried rolling hand.c back to > before I changed (months/year ago), since it is involved in bit twiddling, no change, phew.
 
Debugging here is a big humungous&nb >sp;pain.
NT386 has good stacks and line numbers, but no locals or type info, I'd really sometime like to get Codeview info into those .objs. >..I think it is documented well enough, but still not necessarily easy, or maybe have a C generating backend partly for this > reason (and to bring up more targets, using native tools), and function calls in disassembly I think don't resolve; NT386GNU can't yet bui >ld this, though it will soon, but I'm not familiar with gdb and there appears to be no type info. I'm building m3gdb right now, I don't know if >it will work, I hope it has type info, and I'm not familiar with the relevant code. In gdb I struggle just to view bytes in memory, add numbers >to addresses and see those, etc. I think for MY problem, I'm going to link in C code to dump the structs. There is tracing code and I enabled it >, but even it crashes in Text_Length. At least MY problem crashes, hopefully near the problem, whereas your problem goes all the way through to >completion with no stopping to hint where the problem is. Darn it. :) on the mock rudeness and :( on the lack of a crash.
 
You wri >te the bundle out and it matches, so that doesn't rule out bundles as being the problem? (darn)
And bundles look pretty > simple, a bundle is just a generated source file with a constant in it.
Maybe newline problems? That wouldn't make sense. I just downl >oaded some program that might let me separately view the ppm, maybe it'll reveal something.
 
The bad behavior has like regularly s >paced solid color veritical bars a few pixels side across the whole picture, and regularly spaced vertical stripes from the correct picture alte >rnating with that. Perhaps someone with ppm/bitmap/graphics experience has seen this behavior and it results from some common pixmap mismanageme >nt we could look for?
 
I have to say this is very surprising.
 
I always wondered, and now I pretty much assume -- Mo >dula-3 never imports/exports data in its dynamic linking, right? It alway imports/exports functions, right?
On Windows, functions have an op >tional optimization, but data must be handled differently at compile time if it is going to be dynamically imported.
For > functions, if you don't apply the optimization at compile time, the linker will just generate a single instruction thunk instead.
 
> That is, given a symbol Foo, there is a symbol __imp__Foo that is a pointer to the actual foo in another .dll/.so.
Th >e loader only patches pointers, one per import if you build your .dll correctly, it doesn't patch instructions or code strewn throughout a >.dll, just one contiguous array of pointers. MAYBE they don't have to be contiguous for each .dl you import from.
 
That is, if cal >l msvcrt!fopen, msvcrt!fclose, kernel32!Sleep, my .dll/.exe typically has an array:
 
pointer to msvcrt!fopen
pointer to msvcrt >!fclose
null
pointer to kernel32!Sleep
 
But perhaps kernel32.dll's pointers and msvcrt.dll's pointers need not be adjacent >.
 
So, going back, my point/question is that, if the compiler knows the function is imported, it can call > through __imp__Foo instead of calling Foo.
But if it calls Foo and you import Foo, the linker will create the function Foo that just jmps t >hrough __imp__Foo.
That doesn't work for data though. There's no ability to intervenve like that.
So for imported data, the compiler mus >t generated a read and dereference of the pointer __imp__Foo for accesses to Foo, if Foo is to be imported.
Data import >s may be faster when appropriate, but for this reason, I'd say they aren't worth it.
And for this reason, I HOPE Modula-3 never imports/expo >rts data.
 
Oh, you could, for data, always reference the pointer __imp_Foo, and if non materializes, create one.
However that >would suck perf in order to make an uncommon case work.
I hope Modula-3 doesn't do that either. :)
Though I guess since this global data > in question...maybe it is rare???
 
Later,
 - Jay



> From: > hosking at cs.purdue.edu
> Date: Sat, 19 Jan 2008 03:09:47 -0500
> To: rcoleburn at scires.com
> CC: m3devel at elegosoft.com
> >Subject: Re: [M3devel] pixmap problem
>
> Looks fine to me on I386_DARWIN.
>
> On Jan 19, 2008, at 12:31 AM, Randy Col >eburn wrote:
>
> > <TestPixmap.zip>
>


Need to know the score, the latest news, or you need your Hotm >ail*-get your "fix" Check it out.

> > >


Web Revelaci*n Yahoo! 2007:
Premio Favorita del P*blico - ?Vota tu preferida! >--0-1095273535-1200761640=:77597-- -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcoleburn at scires.com Sun Jan 20 20:12:45 2008 From: rcoleburn at scires.com (Randy Coleburn) Date: Sun, 20 Jan 2008 14:12:45 -0500 Subject: [M3devel] my status on win32 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> <477EA137.1E75.00D7.1@scires.com> <478D394B.1E75.00D7.1@scires.com> <478D47FB.1E75.00D7.1@scires.com> <478DBF8D.1E75.00D7.1@scires.com> <478DE973.1E75.00D7.1@scires.com> <47908659.1E75.00D7.1@scires.com> <20080119204810.3wmumqgms88sccw4@mail.elegosoft.com> <479267C2.1E75.00D7.1@scires.com><479267C2.1E75.00D7.1@scires.com> Message-ID: <479356DB.1E75.00D7.1@scires.com> "mapped" is probably a poor choice of words here. Sorry. --Randy >>> Jay 1/19/2008 11:27 PM >>> What does "mapped" mean here? The way it works, on Modula-3 NT386, and I haven't seen this done quite this way ever on Win32, not so systematically/mechanically/automatically, and I don't know how Posixish systems work here, but the way it works is that for every .dll, CM3 NT386 builds foo.lib and foo.lib.sa. foo.lib is an "import lib", just containing essentially function names and a file name. foo.lib.sa is a regular old static .lib, sa for standalone. You can also just build a static .lib -- for stuff that is never a .dll, for stuff that is only used once, but is broken up into multiple directories. For example m3quake, m3middle, m3objfile, m3back, etc. They are only used by cm3 so are just static .libs, just foo.lib, are built. (If we fix cm3.exe to be copy over itself, and I have some new clever ideas here, it might be profitable, for "developer productivity", to turn these into .dlls -- just so I can cd around and rebuild/reship less.) When you ask to build a standalone executable, we have a list of .libs, foo.lib, bar.lib. They are full paths. For each one, we see if foo.lib.sa exists, and if so, we use that instead of foo.lib. It is all rather simple and clever, but at least to me, it was surprising and new, so I explain it here. Perhaps Posixish systems work very similarly and this is old hat? I know cm3 doesn't implement this for Posix, but ar/ld/gcc could be handling things this way underneath for it. For example, I know on Mac OS X, if you link to a full path to a file, that's what you get. But if you say -Ldirectory -lfoo, ld probes for directory/foo.dylib and then directory/foo.a. So modulo the extensions and unknown to me how you build the things in the first place, same thing. You have to be sure to use the setting to split lib paths like that, otherwise you break dynamic linking. CM3 makes foo.sa.lib with its own mklib. This is also unusual. Normally one would use lib.exe or link.exe /lib for this, or ar/ld/gcc/dlltools. But the CM3 folks were obviously, openly en route to cutting dependencies through reimplementation. I had some initial trouble on NT385GNU building static .libs with ar/ld/gcc/dlltool, so, heck, I just do what NT386 does, and it seems to be working (modulo that SOMETHING is not working :) ). I don't want to stop anyone else from debugging this but if nobody else figures it out I will try. I can repro it easily, thanks for the good repro Randy! (though I wish it would crash instead of mis-display :) ) There is no "vendor's equivalent library" here, it is all just Modula-3 foo.lib or foo.lib.sa. Look at NT386/*.txt, by the .exe. Build one way. Rename away NT386. Build the other way. Compare the directories. You will see what I am talking about. - Jay Date: Sat, 19 Jan 2008 21:12:37 -0500 From: rcoleburn at scires.com To: hosking at cs.purdue.edu; wagner at elegosoft.com CC: m3devel at elegosoft.com Subject: Re: [M3devel] my status on win32 Hi Tony: Are you suggesting that when the program is built standalone it maps libraries differently? I know there is a difference between dynamic vs. static libraries, but are you suggesting that a different library is being mapped than the vendor's equivalent of the dynamic library? How would I check for this situation? Your suggestion seems plausible since the source is not recompiled; instead, the linker is used to change the way the EXE is put together and that seems to cause the difference in operation as far as pixmaps are concerned. Regards, Randy >>> Tony Hosking 1/19/2008 6:47 PM >>> I would perhaps suspect a bad library mapping. On Jan 19, 2008, at 2:48 PM, Olaf Wagner wrote: > Quoting Randy Coleburn : >> 1. pixmaps aren't rendered properly on the screen. They look really >> bad. I recall having this problem a while back with one of the early >> 5.x releases, so I guess it was never solved. I've got some old test >> programs I try to dig out and see if I can find out what is going >> on. I >> seem to recall that building standalone in the past seemed to fix the >> problem, so this is a real mystery. > > Hi Randy, > > I'm afraid I wasn't able to solve it directly some years ago and > then forgot about it due to more urgent tasks. > > I think we should try to narrow down the location of the problem > (i.e. is it in the runtime, code generation, linker, or windows > libraries). > > As you still have the 4.1 code of the Windows libraries, could you > first try to build them with the new compiler and see if it makes > a difference if you link against them? > > It may also be worthwhile to compare the commands actually used > for linking (use -commands). That is, before we turn to the actual > generated code... > > I still haven't got Windows access here, so I can just suggest what > to do... > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, > Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 > 45 86 95 > http://www.elegosoft.com ( http://www.elegosoft.com/ ) | Gesch?ftsf?hrer: Olaf Wagner | Sitz: > Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > DE163214194 > Helping your favorite cause is as easy as instant messaging. You IM, we give. Learn more. ( http://im.live.com/Messenger/IM/Home/?source=text_hotmail_join ) -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Sun Jan 20 20:48:31 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Sun, 20 Jan 2008 20:48:31 +0100 Subject: [M3devel] pixmap problem In-Reply-To: <47935664.1E75.00D7.1@scires.com> References: Your message of "Sat, 19 Jan 2008 17:54:00 +0100." <235688.77597.qm@web27110.mail.ukl.yahoo.com> <200801200341.m0K3feKM023564@camembert.async.caltech.edu> <47935664.1E75.00D7.1@scires.com> Message-ID: <20080120204831.81poj3gg0084o0g0@mail.elegosoft.com> Quoting Randy Coleburn : > Mika / Daniel: Thanks for the test info! > > Well, based on what ya'll are reporting, I think the problem has to do > with the NT386 platform. I also don't think it has to do necessarily > with the source code. So, there must be something fishy going on in the > NT386 world in the linkage step to cause this type of situation when > switching between regular and buildstandalone(). I must have missed that, browsing the lots of mails on this list recently ;-) > Unfortunately, I'm probably not the right person to figure out what is > wrong and fix it either. Hey, but at least I produced a short test > program that reproduces the problem. This is often the more difficult part. > Maybe Jay or someone can offer another suggestion on how to fix it. I think Jay is the well capable of finding out what's going wrong there. Let's wait for him. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Sun Jan 20 21:41:23 2008 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Sun, 20 Jan 2008 21:41:23 +0100 (CET) Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: Message-ID: <862972.55026.qm@web27105.mail.ukl.yahoo.com> Hi: I think for all the users that maybe NT386GNU is more thought like NT386cygwin, but if we see that GNU tools are used in projects like Mingw, that is a fork of cygwin and with the aim of programs running without the dependency on cygwin dll, that maybe guide us to say that the "old target" NT386GNU should be run with a cygwin enviroment. The NT386_MINGW seems to be a nice name/description for the platform which no depends on cygwin.dll but a MinGW/MSYS enviroment. Certainly I think the gnu toolchain is highly used by both the projects, and as I remember, when installing gcc on cygwin it also offers the mingw tool set to the cygwin enviroment to be installed. So let's say that projects are very related and cooperative, but are not the same. So Jay, m3cc could be built on a cygwin enviroment and m3gdb? If so, we can think in those two separeted platforms? although cooperative for m3 developers. I would like to see m3-lectern packages running on NT386GNU using the filesystem /dev, which is something that I wouldn't expect to be on the proposed NT386_MINGW platform. Thanks Jay wrote: .hmmessage P { margin:0px; padding:0px } body.hmmessage { FONT-SIZE: 10pt; FONT-FAMILY:Tahoma } > the infrastructure. So I'd rather vote that only new targets get > more systematic names. Of course, though the existing names suggest new names, and not clear the value of the existing NT386GNU. Ie. is there a benefit to keep it in use with some meaning or not? Cygwin does have a larger jmpbuf than msvcr*.dll/mingwin. I think it holds sigaction state besides register state. "NT" and "Win" seem redundant. I386_MINGWIN? I386_CYGWIN? NT386_GNU? NT386_MINGNU? Ok, I admit that NT386_CYGWIN NT386_MINGWIN despite the redundancy, clearly point to existing projects that probably have name recognition. And building from NT386 is reasonable -- as was I saying about existing names influencing new names. A C generating backend gets you perhaps easier retargeting as well. I do see there is "MINGWIN64" out there, for AMD64. Not sure what the state of IA64 is though... (See -- you should avoid saying "32" or "64" in stuff, Win32 => Win, Win64 => Win.) I also would agree that creating one target instead of two is probably a good idea -- seems easier. I am not sure if current state is relevant. I mean, is NT386GNU really working and in use anywhere? Is PM3 in use? If so, then matching their meaning would be good. Or even going beyond that -- to Trestle on X Windows. :) (Though CygwinX doesn't exactly appear active.) And thus the precedent for no underscore. NT386MINGWIN ? NT386MINGNU ? I don't know if "MSYS" needs a place in this name. It is needed for building m3cc. I wonder if a hybrid/adaptive approach will be desired -- if Cygwin is available, the MinGWin target could use it to build m3gdb, since it can't otherwise. Hint for anyone trying out Cygwin and getting an odd mix of paths: mkdir \cygdrive get junction.exe from the former www.sysinternals.com junction \cygdrive\c c:\ now when some Cygwin code passes /cygdrive/c to Win32 code, it will just work, no translation needed. If you have multiple drives, I guess just fully populate each one c:\cygdrive\c => c:\ c:\cygdrive\d => d:\ d:\cygdrive\c => c:\ d:\cygdrive\d => d:\ etc. but I haven't tried that. Or, to reduce the multiplication, set them all up on c: and have d:\cygdrive => c:\cygdrive, e:\cygdrive => c:\cygdrive, etc. - Jay --------------------------------- > Date: Sun, 20 Jan 2008 15:56:49 +0100 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > Quoting Jay : > > > Good, a happy customer. :) > > > >> GNU_MODE = 0 % Do not use GNU tools at all -- today's NT386 > >> GNU_MODE = 1 % Use GNU tools minimally -- today's NT386GNU > >> GNU_MODE = 2 % Use GNU tools maximally -- not existant but probably > >> easy > >> > >> Eh..I know, not great.. what do "minimally" and "maximally" mean. > > > > I'm still fishing for anyone to provide answers to these > > less important decisions that I have trouble with. > > Otherwise maybe no NT Cygwin system. > > > > TARGETs = { NT386, NT386GNU, NT386CYGWIN }? > > TARGETs = { NT386, NT386MINGWIN, NT386CYGWIN }? > > TARGETs = { NT386 + GNU_MODE }? > > > > The one reason I don't favor NT386 + GNU_MODE is that Cygwin has a > > much larger jmpbuf than the others. > > I think same TARGET implies code can be linked together, and I think > > varying jmpbuf implies otherwise. > > So NT386 and NT386MINGWIN should rarely cross paths with NT386CYGWIN. > > I think a new target is called for if I have understood everything right. > We need one pure native target (NT386), one pure-Cygwin-based target > (NT386_CYGWIN?) and one mix of runtime, gnu tools and mingwin > (NT386_MINGWIN?). > > As NT386GNU already exists, we must decide if we want to use it as > we traditionally did (all Cygwin) or the mixed implementation > (Mingwin and much Windows RT). > > > I also do NOT like this ad-hoc naming style. > > PPC_DARWIN, I386_DARWIN are much more to my style. > > The names should be somehow hierarchical, except, I realize, there > > isn't necessarily one "path" of > > stuff which to name platforms, though the GNU folks have settled on > > a way or two. > > They have triples or quadruples -- processor-hardware-os or such, > > however this doesn't > > clearly suffice. > > Well, yes, something more systematic would have been better, but > to break with the history will cause much trouble for all users and > the infrastructure. So I'd rather vote that only new targets get > more systematic names. > > > Something that accomodates: > > NT386 + LLVM > > NT386 + Watcom, linker and/or backend and/or runtime > > NT386 + Digital Mars linker and/or backend and/or runtime > > A C generating backend, and then linker/runtime > > and similar IA64, AMD64 variants would be good. > > I'm not sure that a C generating backend would really help matters. > This was done in the first implementation of DEC, and they soon > abandoned it as C had proven to be a bad choice as intermediate language. > I agree it would be great for cross-compilation etc. > > As far as C and RT dependencies of native Windows compilers go, I don't > see why this couldn't be just a question of another cm3.cfg setup. > > > To a large extent, these can be few platforms, subject to > > configuration, like if all > > the linkers consume a common file format (not clear), and if all the > > jmpbufs are the same > > size (known to be partly true, partly false). > > Yes, jmpbuf is always a problem for user threads and exceptions. > On Unix systems the jmpbuf and other important low-level structures > are always defined by the system headers and independent of compilers > AFAIK, so I'm a bit surprised that it should be different on Windows. > But maybe I'm just wrong and haven't just seen the right counter > examples... > > > Oh and another thing, the runtime dependency is very likely cuttable, however > > PRESUMABLY real world applications (if there are any) link in a > > substantial amount of > > C or C++, in which case, it isn't necessarily cuttable. > > Yes. Real world applications tend to link other libraries (C, C++, > Fortran, ...) and even often call other applications like sh etc. > > > As well, if I can figure out a good way to do it, switching NT386 > > from awful slow > > frequent TlsGetValue/TlsSetValue to manipulating the linked list in > > fs:0, that would be nice, > > and might incur a C runtime dependency, but well worth it. The way > > Modula-3 works here > > is terrible. Another compromise option is probably > > __declspec(thread), though there is trickiness there > > in terms of being in a .dll that isn't used by the .exe. > > Such optimizations should be done depending on the target. > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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! --------------------------------- Web Revelaci?n Yahoo! 2007: Premio Favorita del P?blico - ?Vota tu preferida! -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Sun Jan 20 22:03:12 2008 From: jayk123 at hotmail.com (Jay) Date: Sun, 20 Jan 2008 21:03:12 +0000 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <862972.55026.qm@web27105.mail.ukl.yahoo.com> References: <862972.55026.qm@web27105.mail.ukl.yahoo.com> Message-ID: Daniel, yes it's true cygwin has like -mno-cygwin or something. I will have to try that.Currently msys is required to build m3cc and cygwin is required to build m3gdb. m3gdb didn't have any type information anyway, so if you install cygwin, you can just use its gdb. (Note that cygwin is highly modular/package-based, so you can pick and chose what you install, there are many many many choices, so you don't automatically get gdb, you don't automatically even get gcc or ld/binutils.) Otherwise just MinGWin is required. Cygwin might just work. I'll try it before much longer. Is someone going to go ahead and create a new target? I guess I'm about able to. I think I finally fixed the major crash so can..take a break and then continue. Wow that was tedious. Once I can get a MinGWin distribution, I want to look at the pixmap bug, before looking into this new target.. Maybe someone will beat me to it though? /dev does not appear in Cygwin, at least not with cd and ls on my system. I expect /dev/null will work. I do have a very limited installed of Cygwin now, as I was trying to understand roughly what is needed. I don't know what to expect from /dev in Cygwin. You might be asking for too much. $ ls /dev/null/dev/null Jay at jay-win1 /$ ls /proc1312 cpuinfo meminfo registry stat version3936 loadavg partitions self uptime Jay at jay-win1 /$ ls /devls: cannot access /dev: No such file or directory $ ls /dev/tty/dev/tty $ ls /dev/conls: cannot access /dev/con: No such file or directory Jay at jay-win1 /$ ls /dev/fd0/dev/fd0 Jay at jay-win1 /$ ls /dev/fd*ls: cannot access /dev/fd*: No such file or directory Jay at jay-win1 /$ ls /dev/hd0ls: cannot access /dev/hd0: No such file or directory Jay at jay-win1 /$ ls /dev/sc*ls: cannot access /dev/sc*: No such file or directory I'm not sure what all to guess here. fd0 appears but I don't have a floppy disk. $ cat /proc/uptime41101.28 32423.71 Jay at jay-win1 /$ cat /proc/versionCYGWIN_NT-5.1 1.5.25(0.156/4/2) 2007-12-14 19:21 I'm inclined not to make any cygwin binary distributions until further reading of the license... There's still the X Windows vs. Win32 question... - Jay Date: Sun, 20 Jan 2008 21:41:23 +0100From: dabenavidesd at yahoo.esSubject: Re: [M3devel] [M3commit] CVS Update: cm3To: jayk123 at hotmail.com; wagner at elegosoft.com; m3devel at elegosoft.comHi:I think for all the users that maybe NT386GNU is more thought like NT386cygwin, but if we see that GNU tools are used in projects like Mingw, that is a fork of cygwin and with the aim of programs running without the dependency on cygwin dll, that maybe guide us to say that the "old target" NT386GNU should be run with a cygwin enviroment.The NT386_MINGW seems to be a nice name/description for the platform which no depends on cygwin.dll but a MinGW/MSYS enviroment.Certainly I think the gnu toolchain is highly used by both the projects, and as I remember, when installing gcc on cygwin it also offers the mingw tool set to the cygwin enviroment to be installed. So let's say that projects are very related and cooperative, but are not the same.So Jay, m3cc could be built on a cygwin enviroment and m3gdb?If so, we can think in those two separeted platforms? although cooperative for m3 developers.I would like to see m3-lectern packages running on NT386GNU using the filesystem /dev, which is something that I wouldn't expect to be on the proposed NT386_MINGW platform.ThanksJay wrote: > the infrastructure. So I'd rather vote that only new targets get> more systematic names.Of course, though the existing names suggest new names, andnot clear the value of the existing NT386GNU. Ie. is there a benefitto keep it in use with some meaning or not? Cygwin does have a larger jmpbuf than msvcr*.dll/mingwin.I think it holds sigaction state besides register state. "NT" and "Win" seem redundant. I386_MINGWIN? I386_CYGWIN? NT386_GNU? NT386_MINGNU? Ok, I admit that NT386_CYGWIN NT386_MINGWIN despite the redundancy, clearly point to existing projects that probably have name recognition.And building from NT386 is reasonable -- as was I saying about existing names influencing new names. A C generating backend gets you perhaps easier retargeting as well.I do see there is "MINGWIN64" out there, for AMD64.Not sure what the state of IA64 is though...(See -- you should avoid saying "32" or "64" in stuff, Win32 => Win, Win64 => Win.) I also would agree that creating one target instead of two is probably a good idea -- seems easier. I am not sure if current state is relevant. I mean, is NT386GNU really working and in use anywhere? Is PM3 in use?If so, then matching their meaning would be good. Or even going beyond that -- to Trestle on X Windows. :) (Though CygwinX doesn't exactly appear active.) And thus the precedent for no underscore.NT386MINGWIN ?NT386MINGNU ? I don't know if "MSYS" needs a place in this name.It is needed for building m3cc. I wonder if a hybrid/adaptive approach will be desired -- if Cygwin is available, the MinGWin target could use it to build m3gdb, since it can't otherwise. Hint for anyone trying out Cygwin and getting an odd mix of paths:mkdir \cygdriveget junction.exe from the former www.sysinternals.comjunction \cygdrive\c c:\now when some Cygwin code passes /cygdrive/c to Win32 code, it will just work, no translation needed.If you have multiple drives, I guess just fully populate each onec:\cygdrive\c => c:\c:\cygdrive\d => d:\d:\cygdrive\c => c:\d:\cygdrive\d => d:\ etc. but I haven't tried that.Or, to reduce the multiplication, set them all up on c: and have d:\cygdrive => c:\cygdrive, e:\cygdrive => c:\cygdrive, etc. - Jay > Date: Sun, 20 Jan 2008 15:56:49 +0100> From: wagner at elegosoft.com> To: m3devel at elegosoft.com> Subject: Re: [M3devel] [M3commit] CVS Update: cm3> > Quoting Jay :> > > Good, a happy customer. :)> >> >> GNU_MODE = 0 % Do not use GNU tools at all -- today's NT386> >> GNU_MODE = 1 % Use GNU tools minimally -- today's NT386GNU> >> GNU_MODE = 2 % Use GNU tools maximally -- not existant but probably> >> easy> >>> >> Eh..I know, not great.. what do "minimally" and "maximally" mean.> >> > I'm still fishing for anyone to provide answers to these> > less important decisions that I have trouble with.> > Otherwise maybe no NT Cygwin system.> >> > TARGETs = { NT386, NT386GNU, NT386CYGWIN }?> > TARGETs = { NT386, NT386MINGWIN, NT386CYGWIN }?> > TARGETs = { NT386 + GNU_MODE }?> >> > The one reason I don't favor NT386 + GNU_MODE is that Cygwin has a > > much larger jmpbuf than the others.> > I think same TARGET implies code can be linked together, and I think > > varying jmpbuf implies otherwise.> > So NT386 and NT386MINGWIN should rarely cross paths with NT386CYGWIN.> > I think a new target is called for if I have understood everything right.> We need one pure native target (NT386), one pure-Cygwin-based target> (NT386_CYGWIN?) and one mix of runtime, gnu tools and mingwin> (NT386_MINGWIN?).> > As NT386GNU already exists, we must decide if we want to use it as> we traditionally did (all Cygwin) or the mixed implementation> (Mingwin and much Windows RT).> > > I also do NOT like this ad-hoc naming style.> > PPC_DARWIN, I386_DARWIN are much more to my style.> > The names should be somehow hierarchical, except, I realize, there > > isn't necessarily one "path" of> > stuff which to name platforms, though the GNU folks have settled on > > a way or two.> > They have triples or quadruples -- processor-hardware-os or such, > > however this doesn't> > clearly suffice.> > Well, yes, something more systematic would have been better, but> to break with the history will cause much trouble for all users and> the infrastructure. So I'd rather vote that only new targets get> more systematic names.> > > Something that accomodates:> > NT386 + LLVM> > NT386 + Watcom, linker and/or backend and/or runtime> > NT386 + Digital Mars linker and/or backend and/or runtime> > A C generating backend, and then linker/runtime> > and similar IA64, AMD64 variants would be good.> > I'm not sure that a C generating backend would really help matters.> This was done in the first implementation of DEC, and they soon> abandoned it as C had proven to be a bad choice as intermediate language.> I agree it would be great for cross-compilation etc.> > As far as C and RT dependencies of native Windows compilers go, I don't> see why this couldn't be just a question of another cm3.cfg setup.> > > To a large extent, these can be few platforms, subject to > > configuration, like if all> > the linkers consume a common file format (not clear), and if all the > > jmpbufs are the same> > size (known to be partly true, partly false).> > Yes, jmpbuf is always a problem for user threads and exceptions.> On Unix systems the jmpbuf and other important low-level structures> are always defined by the system headers and independent of compilers> AFAIK, so I'm a bit surprised that it should be different on Windows.> But maybe I'm just wrong and haven't just seen the right counter> examples...> > > Oh and another thing, the runtime dependency is very likely cuttable, however> > PRESUMABLY real world applications (if there are any) link in a > > substantial amount of> > C or C++, in which case, it isn't necessarily cuttable.> > Yes. Real world applications tend to link other libraries (C, C++,> Fortran, ...) and even often call other applications like sh etc.> > > As well, if I can figure out a good way to do it, switching NT386 > > from awful slow> > frequent TlsGetValue/TlsSetValue to manipulating the linked list in > > fs:0, that would be nice,> > and might incur a C runtime dependency, but well worth it. The way > > Modula-3 works here> > is terrible. Another compromise option is probably > > __declspec(thread), though there is trickiness there> > in terms of being in a .dll that isn't used by the .exe.> > Such optimizations should be done depending on the target.> > Olaf> -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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! Web Revelaci?n Yahoo! 2007:Premio Favorita del P?blico - ?Vota tu preferida! _________________________________________________________________ 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 Jan 20 22:09:42 2008 From: jayk123 at hotmail.com (Jay) Date: Sun, 20 Jan 2008 21:09:42 +0000 Subject: [M3devel] cygwin users? In-Reply-To: <862972.55026.qm@web27105.mail.ukl.yahoo.com> References: <862972.55026.qm@web27105.mail.ukl.yahoo.com> Message-ID: Does anyone who is asking for Cygwin support actually use it? Or you are all just Unix users? (And MinGW users either?) I mean, are we hearing what people want and will use, or just what ought to exist in some ideal world? - 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 wagner at elegosoft.com Sun Jan 20 22:18:32 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Sun, 20 Jan 2008 22:18:32 +0100 Subject: [M3devel] Open CM3 regression tests Message-ID: <20080120211832.GA26993@elegosoft.com> Hi again everybody, I got a little bit side-tracked during recent days while trying to set up a sensible interface for test status reporting by the poor state of the CM3 WWW presentation. So I tried to improve the presentation and structure of the site. It's still all simple hand-crafted HTML and nothing very fancy, though I think it looks better now than before. Let me know what you think. And I know, the colours will be the most interesting discussion topic ;-) But back to more important issues. There are still a number of problems in the CM3 compiler regression tests that I'd like to discuss and close: either adapt the test, fix the compiler, or document the issue as intended or erroneous behaviour of CM3. Though I've thrown in some names here and there, nobody should hesitate to voice his opinion. Here's the extract of the test run log: CM3_TARGET=FreeBSD4 BINDISTMIN=/home/wagner/cm3-min-POSIX-FreeBSD4-5.4.0.tgz === 2008-01-19 23:43:24 run cm3 compiler and runtime regression test suite in /home/wagner/work/cm3-ws/luthien-2008-01-19-02-30-01 with lastok version Critical Mass Modula-3 version d5.5.1 last updated: 2007-12-30 compiled: 2008-01-19 17:27:13 configuration: /home/wagner/work/cm3-inst/luthien/current/bin/cm3.cfg --- building in FreeBSD4 --- > no errors for p1 to p115 --- p116b --- default IEEE floating point tests from Xerox PARC --- p1/p116b/stderr.pgm 2008-01-20 00:47:20.000000000 +0100 +++ ../src/p1/p116b/stderr.pgm 2008-01-13 00:55:55.000000000 +0100 @@ -17,7 +17,7 @@ Class (MaxFinite*ten) test OK Finite (MaxFinite*ten) test OK IsNaN (MaxFinite*ten) test OK -** Class (zero/zero) test not OK: FALSE should be TRUE + Class (zero/zero) test OK Finite (zero/zero) test OK IsNaN (zero/zero) test OK Sign (zero) test OK @@ -58,7 +58,7 @@ Class MaxFinite*ten test OK Finite MaxFinite*ten test OK IsNaN MaxFinite*ten test OK -** Class zero/zero test not OK: FALSE should be TRUE + Class zero/zero test OK Finite zero/zero test OK IsNaN zero/zero test OK Sign (zero) test OK > Some arithmetic problems. Perhaps Henning Thielemann could have > a look at this? --- p117 --- SUBARRAY (LOOPHOLE) OK again --- p155 --- operations on small sets --- p1/p155/stderr.pgm 2008-01-20 00:48:16.000000000 +0100 +++ ../src/p1/p155/stderr.pgm 2008-01-13 00:55:56.000000000 +0100 @@ -2,7 +2,6 @@ check set q = {} check set r = {a, b} check set x = {a, b, e} -************************ ERROR: check (NOT (p >= x)) failed > This concerns the >= operation on sets. The language definition > says: > > infix <=, >= (x,y: Ordinal) : BOOLEAN > (x,y: Float) : BOOLEAN > (x,y: ADDRESS) : BOOLEAN > (x,y: Set) : BOOLEAN > > In the first three cases, <= returns TRUE if x is at most as large as > y. In the last case, <= returns TRUE if every element of x is an > element of y. In all cases, it is a static error if the type of x is > not assignable to the type of y, or vice versa. The expression x >= y > is equivalent to y <= x. > > So the implementation seems to be plainly wrong. I think the test > for the previous operation <= only succeeds accidentally. --- p156 --- operations on medium-sized sets > OK > until --- p172 --- REAL vs. C's float --- p1/p172/stdout.pgm 2008-01-20 00:49:10.000000000 +0100 +++ ../src/p1/p172/stdout.pgm 2003-03-08 23:36:48.000000000 +0100 @@ -0,0 +1 @@ +23 23 --- p1/p172/stderr.pgm 2008-01-20 00:49:10.000000000 +0100 +++ ../src/p1/p172/stderr.pgm 2003-03-08 23:36:48.000000000 +0100 @@ -1,5 +1,3 @@ -23.4 23 -************************ ERROR: 23.4 instead of 23 > result too exact? > Perhaps Henning again? And Tony? --- p173 --- LONGREAL vs. C's double > OK again until --- p185 --- REAL vs. C float --- p1/p185/stderr.pgm 2008-01-20 00:49:32.000000000 +0100 +++ ../src/p1/p185/stderr.pgm 2003-03-08 23:36:50.000000000 +0100 @@ -1,4 +1,3 @@ -************************ ERROR: 53 instead of 24 > This is another effect of the precision problem. Expression evaluation > seems always to be done with 53 bits of precision (double), and never > with pure reals (23 bits). I assume it will be the same for C on > all PC hardware at least. Should we consider this to be an error or > just document the behaviour? > > I assume it cannot easily be changed, can it? --- p186 --- case statement with large labels > Just some output differences; I seem to have switched core dumps > off in one environment... > > So we can probably ignore these ones. --- r0/r001/stdout.build 2008-01-20 00:50:07.000000000 +0100 +++ ../src/r0/r001/stdout.build 2008-01-13 00:55:57.000000000 +0100 @@ -1,3 +1,3 @@ "../src/Main.m3", line 13: warning: potentially unhandled exception: Main.a 1 warning encountered -Abort trap (core dumped) +Abort trap --- r002 --- stack overflow in the main thread --- r0/r002/stdout.build 2008-01-20 00:50:09.000000000 +0100 +++ ../src/r0/r002/stdout.build 2008-01-13 00:55:57.000000000 +0100 @@ -1 +1 @@ -Bus error (core dumped) +Bus error --- r003 --- b3tests/b002 - improper size for an open array parameter --- r0/r003/stdout.build 2008-01-20 00:50:11.000000000 +0100 +++ ../src/r0/r003/stdout.build 2008-01-13 00:55:57.000000000 +0100 @@ -1,4 +1,4 @@ "../src/Main.m3", line 11: warning: open array passed by value (x) "../src/Main.m3", line 13: warning: large parameter passed by value (40 bytes) (x) 2 warnings encountered -Abort trap (core dumped) +Abort trap --- r004 --- negative size for an open array --- r0/r004/stdout.build 2008-01-20 00:50:13.000000000 +0100 +++ ../src/r0/r004/stdout.build 2008-01-13 00:55:57.000000000 +0100 @@ -1 +1 @@ -Abort trap (core dumped) +Abort trap > That were all the functional tests. Following is only error detection > and handling: > > There seems to be a problem recognizing some recursive declarations: --- e0/e020/stdout.build 2008-01-20 00:50:32.000000000 +0100 +++ ../src/e0/e020/stdout.build 2008-01-09 02:15:42.000000000 +0100 @@ -1 +1 @@ -Bus error (core dumped) +Fatal Error: package build failed --- e021 --- illegal recursive declaration > OK until --- e026 --- two types with the same brand --- e0/e026/stdout.build 2008-01-20 00:50:38.000000000 +0100 +++ ../src/e0/e026/stdout.build 2003-03-08 23:36:13.000000000 +0100 @@ -0,0 +1,3 @@ +"../src/Main.m3", line 8: string: duplicate brand +"../src/Main.m3", line 7: string: duplicate brand +2 errors encountered > This seems to be just different/missing error output. > > Another more obvious example of this is here: --- e029 --- use type instead of value as an initializer --- e0/e029/stdout.build 2008-01-20 00:50:41.000000000 +0100 +++ ../src/e0/e029/stdout.build 2008-01-09 02:15:44.000000000 +0100 @@ -1,11 +1,4 @@ "../src/Main.m3", line 24: warning: variable has type NULL (r) -"../src/Main.m3", line 24: ** INTERNAL CG ERROR *** stack not empty, depth (1) -"../src/Main.m3", line 25: ** INTERNAL CG ERROR *** stack not empty, depth (1) -"../src/Main.m3", line 26: ** INTERNAL CG ERROR *** unaligned load_indirect type=11 s/a=0/8 -"../src/Main.m3", line 26: ** INTERNAL CG ERROR *** unaligned store_indirect type=11 s/a=0/8 -"../src/Main.m3", line 26: ** INTERNAL CG ERROR *** stack not empty, depth (1) -"../src/Main.m3", line 26: ** INTERNAL CG ERROR *** stack not empty, depth (1) -"../src/Main.m3", line 22: ** INTERNAL CG ERROR *** stack not empty, depth (1) -"../src/Main.m3", line 22: 2 code generation errors -8 errors and 1 warning encountered +"../src/Main.m3", line 24: types are not assignable +1 error and 1 warning encountered Fatal Error: package build failed > Just ignore it? > > For reference, here's the extract of the programs' stderr output: >>> test_m3tests error extract: FreeBSD4/p1/p116b/stderr.pgm:** Class (zero/zero) test not OK: FALSE should be TRUE FreeBSD4/p1/p116b/stderr.pgm:** Class zero/zero test not OK: FALSE should be TRUE FreeBSD4/p1/p155/stderr.pgm:************************ ERROR: check (NOT (p >= x)) failed FreeBSD4/p1/p155/stderr.pgm:1 error(s) and 0 warning(s) detected FreeBSD4/p1/p172/stderr.pgm:************************ ERROR: 23.4 instead of 23 FreeBSD4/p1/p172/stderr.pgm:1 error(s) and 0 warning(s) detected FreeBSD4/p1/p185/stderr.pgm:************************ ERROR: 53 instead of 24 FreeBSD4/p1/p185/stderr.pgm:1 error(s) and 0 warning(s) detected FreeBSD4/r0/r001/stderr.pgm:*** FreeBSD4/r0/r001/stderr.pgm:*** runtime error: FreeBSD4/r0/r001/stderr.pgm:*** Unhandled exception: Main.a FreeBSD4/r0/r001/stderr.pgm:*** file "../src/Main.m3", line 13 FreeBSD4/r0/r001/stderr.pgm:*** FreeBSD4/r0/r003/stderr.pgm:*** FreeBSD4/r0/r003/stderr.pgm:*** runtime error: FreeBSD4/r0/r003/stderr.pgm:*** An open array had the wrong shape. FreeBSD4/r0/r003/stderr.pgm:*** file "../src/Main.m3", line 19 FreeBSD4/r0/r003/stderr.pgm:*** FreeBSD4/r0/r004/stderr.pgm:*** FreeBSD4/r0/r004/stderr.pgm:*** runtime error: FreeBSD4/r0/r004/stderr.pgm:*** An enumeration or subrange value was out of range. FreeBSD4/r0/r004/stderr.pgm:*** file "../src/runtime/common/RTAllocator.m3", line 309 FreeBSD4/r0/r004/stderr.pgm:*** >>> 7 in test_m3tests 2008-01-19-02-30-01 /home/wagner/work/cm3-ws/luthien-2008-01-19-02-30-01 === 2008-01-19 23:50:47 cm3 m3tests run done Thanks in advance for your comments, Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From hosking at cs.purdue.edu Sun Jan 20 22:30:11 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 20 Jan 2008 16:30:11 -0500 Subject: [M3devel] cygwin users? In-Reply-To: References: <862972.55026.qm@web27105.mail.ukl.yahoo.com> Message-ID: <8FB801EB-62E4-4DC6-905A-320E4366E011@cs.purdue.edu> On Jan 20, 2008, at 4:09 PM, Jay wrote: > Does anyone who is asking for Cygwin support actually use it? Or > you are all just Unix users? > (And MinGW users either?) I am principally a Unix user, but I am comfortable with Windows when using Cygwin. Thus, I would probably be more comfortable with running CM3 under Cygwin than running under some other Windows configuration. i.e., installing via .sh under Cygwin (same as I do on Unix targets) makes for a more uniform experience for me. > I mean, are we hearing what people want and will use, or just what > ought to exist in some ideal world? > > - Jay > > Climb to the top of the charts! Play the word scramble challenge > with star power. Play now! From hosking at cs.purdue.edu Sun Jan 20 22:38:16 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 20 Jan 2008 16:38:16 -0500 Subject: [M3devel] Open CM3 regression tests In-Reply-To: <20080120211832.GA26993@elegosoft.com> References: <20080120211832.GA26993@elegosoft.com> Message-ID: <9C00EA97-9B43-43BE-9CDF-EEAC9C1321D5@cs.purdue.edu> The set operations are all coded as external C functions -- should be easy enough to fix those. Or are there type issues too? On Jan 20, 2008, at 4:18 PM, Olaf Wagner wrote: > Hi again everybody, > > I got a little bit side-tracked during recent days while trying > to set up a sensible interface for test status reporting > by the poor state of the CM3 WWW presentation. So I tried to improve > the presentation and structure of the site. It's still all simple > hand-crafted HTML and nothing very fancy, though I think it looks > better now than before. Let me know what you think. And I know, > the colours will be the most interesting discussion topic ;-) > > But back to more important issues. There are still a number of > problems in the CM3 compiler regression tests that I'd like to > discuss and close: either adapt the test, fix the compiler, or > document the issue as intended or erroneous behaviour of CM3. > Though I've thrown in some names here and there, nobody should > hesitate to voice his opinion. Here's the extract of the test run > log: > > CM3_TARGET=FreeBSD4 > BINDISTMIN=/home/wagner/cm3-min-POSIX-FreeBSD4-5.4.0.tgz > === 2008-01-19 23:43:24 run cm3 compiler and runtime regression > test suite in /home/wagner/work/cm3-ws/luthien-2008-01-19-02-30-01 > with lastok version > Critical Mass Modula-3 version d5.5.1 > last updated: 2007-12-30 > compiled: 2008-01-19 17:27:13 > configuration: /home/wagner/work/cm3-inst/luthien/current/bin/ > cm3.cfg > > --- building in FreeBSD4 --- > >> no errors for p1 to p115 > > --- p116b --- default IEEE floating point tests from Xerox PARC > --- p1/p116b/stderr.pgm 2008-01-20 00:47:20.000000000 +0100 > +++ ../src/p1/p116b/stderr.pgm 2008-01-13 00:55:55.000000000 +0100 > @@ -17,7 +17,7 @@ > Class (MaxFinite*ten) test OK > Finite (MaxFinite*ten) test OK > IsNaN (MaxFinite*ten) test OK > -** Class (zero/zero) test not OK: FALSE should be TRUE > + Class (zero/zero) test OK > Finite (zero/zero) test OK > IsNaN (zero/zero) test OK > Sign (zero) test OK > @@ -58,7 +58,7 @@ > Class MaxFinite*ten test OK > Finite MaxFinite*ten test OK > IsNaN MaxFinite*ten test OK > -** Class zero/zero test not OK: FALSE should be TRUE > + Class zero/zero test OK > Finite zero/zero test OK > IsNaN zero/zero test OK > Sign (zero) test OK > >> Some arithmetic problems. Perhaps Henning Thielemann could have >> a look at this? > > --- p117 --- SUBARRAY (LOOPHOLE) > OK again > --- p155 --- operations on small sets > --- p1/p155/stderr.pgm 2008-01-20 00:48:16.000000000 +0100 > +++ ../src/p1/p155/stderr.pgm 2008-01-13 00:55:56.000000000 +0100 > @@ -2,7 +2,6 @@ > check set q = {} > check set r = {a, b} > check set x = {a, b, e} > -************************ ERROR: check (NOT (p >= x)) failed > >> This concerns the >= operation on sets. The language definition >> says: >> >> infix <=, >= (x,y: Ordinal) : BOOLEAN >> (x,y: Float) : BOOLEAN >> (x,y: ADDRESS) : BOOLEAN >> (x,y: Set) : BOOLEAN >> >> In the first three cases, <= returns TRUE if x is at most as large as >> y. In the last case, <= returns TRUE if every element of x is an >> element of y. In all cases, it is a static error if the type of x is >> not assignable to the type of y, or vice versa. The expression x >= y >> is equivalent to y <= x. >> >> So the implementation seems to be plainly wrong. I think the test >> for the previous operation <= only succeeds accidentally. > > > --- p156 --- operations on medium-sized sets >> OK >> until > > --- p172 --- REAL vs. C's float > --- p1/p172/stdout.pgm 2008-01-20 00:49:10.000000000 +0100 > +++ ../src/p1/p172/stdout.pgm 2003-03-08 23:36:48.000000000 +0100 > @@ -0,0 +1 @@ > +23 23 > --- p1/p172/stderr.pgm 2008-01-20 00:49:10.000000000 +0100 > +++ ../src/p1/p172/stderr.pgm 2003-03-08 23:36:48.000000000 +0100 > @@ -1,5 +1,3 @@ > -23.4 23 > -************************ ERROR: 23.4 instead of 23 >> result too exact? >> Perhaps Henning again? And Tony? > > --- p173 --- LONGREAL vs. C's double >> OK again until > > --- p185 --- REAL vs. C float > --- p1/p185/stderr.pgm 2008-01-20 00:49:32.000000000 +0100 > +++ ../src/p1/p185/stderr.pgm 2003-03-08 23:36:50.000000000 +0100 > @@ -1,4 +1,3 @@ > -************************ ERROR: 53 instead of 24 > >> This is another effect of the precision problem. Expression >> evaluation >> seems always to be done with 53 bits of precision (double), and never >> with pure reals (23 bits). I assume it will be the same for C on >> all PC hardware at least. Should we consider this to be an error or >> just document the behaviour? >> >> I assume it cannot easily be changed, can it? > > --- p186 --- case statement with large labels >> Just some output differences; I seem to have switched core dumps >> off in one environment... >> >> So we can probably ignore these ones. > > --- r0/r001/stdout.build 2008-01-20 00:50:07.000000000 +0100 > +++ ../src/r0/r001/stdout.build 2008-01-13 00:55:57.000000000 +0100 > @@ -1,3 +1,3 @@ > "../src/Main.m3", line 13: warning: potentially unhandled > exception: Main.a > 1 warning encountered > -Abort trap (core dumped) > +Abort trap > --- r002 --- stack overflow in the main thread > --- r0/r002/stdout.build 2008-01-20 00:50:09.000000000 +0100 > +++ ../src/r0/r002/stdout.build 2008-01-13 00:55:57.000000000 +0100 > @@ -1 +1 @@ > -Bus error (core dumped) > +Bus error > --- r003 --- b3tests/b002 - improper size for an open array parameter > --- r0/r003/stdout.build 2008-01-20 00:50:11.000000000 +0100 > +++ ../src/r0/r003/stdout.build 2008-01-13 00:55:57.000000000 +0100 > @@ -1,4 +1,4 @@ > "../src/Main.m3", line 11: warning: open array passed by value (x) > "../src/Main.m3", line 13: warning: large parameter passed by > value (40 bytes) (x) > 2 warnings encountered > -Abort trap (core dumped) > +Abort trap > --- r004 --- negative size for an open array > --- r0/r004/stdout.build 2008-01-20 00:50:13.000000000 +0100 > +++ ../src/r0/r004/stdout.build 2008-01-13 00:55:57.000000000 +0100 > @@ -1 +1 @@ > -Abort trap (core dumped) > +Abort trap > >> That were all the functional tests. Following is only error detection >> and handling: >> >> There seems to be a problem recognizing some recursive declarations: > > --- e0/e020/stdout.build 2008-01-20 00:50:32.000000000 +0100 > +++ ../src/e0/e020/stdout.build 2008-01-09 02:15:42.000000000 +0100 > @@ -1 +1 @@ > -Bus error (core dumped) > +Fatal Error: package build failed > > --- e021 --- illegal recursive declaration >> OK until > > --- e026 --- two types with the same brand > --- e0/e026/stdout.build 2008-01-20 00:50:38.000000000 +0100 > +++ ../src/e0/e026/stdout.build 2003-03-08 23:36:13.000000000 +0100 > @@ -0,0 +1,3 @@ > +"../src/Main.m3", line 8: string: duplicate brand > +"../src/Main.m3", line 7: string: duplicate brand > +2 errors encountered > >> This seems to be just different/missing error output. >> >> Another more obvious example of this is here: > > --- e029 --- use type instead of value as an initializer > --- e0/e029/stdout.build 2008-01-20 00:50:41.000000000 +0100 > +++ ../src/e0/e029/stdout.build 2008-01-09 02:15:44.000000000 +0100 > @@ -1,11 +1,4 @@ > "../src/Main.m3", line 24: warning: variable has type NULL (r) > -"../src/Main.m3", line 24: ** INTERNAL CG ERROR *** stack not > empty, depth (1) > -"../src/Main.m3", line 25: ** INTERNAL CG ERROR *** stack not > empty, depth (1) > -"../src/Main.m3", line 26: ** INTERNAL CG ERROR *** unaligned > load_indirect type=11 s/a=0/8 > -"../src/Main.m3", line 26: ** INTERNAL CG ERROR *** unaligned > store_indirect type=11 s/a=0/8 > -"../src/Main.m3", line 26: ** INTERNAL CG ERROR *** stack not > empty, depth (1) > -"../src/Main.m3", line 26: ** INTERNAL CG ERROR *** stack not > empty, depth (1) > -"../src/Main.m3", line 22: ** INTERNAL CG ERROR *** stack not > empty, depth (1) > -"../src/Main.m3", line 22: 2 code generation errors > -8 errors and 1 warning encountered > +"../src/Main.m3", line 24: types are not assignable > +1 error and 1 warning encountered > Fatal Error: package build failed > >> Just ignore it? >> >> For reference, here's the extract of the programs' stderr output: > >>>> test_m3tests error extract: > FreeBSD4/p1/p116b/stderr.pgm:** Class (zero/zero) test not OK: > FALSE should be TRUE > FreeBSD4/p1/p116b/stderr.pgm:** Class zero/zero test not OK: FALSE > should be TRUE > FreeBSD4/p1/p155/stderr.pgm:************************ ERROR: check > (NOT (p >= x)) failed > FreeBSD4/p1/p155/stderr.pgm:1 error(s) and 0 warning(s) detected > FreeBSD4/p1/p172/stderr.pgm:************************ ERROR: 23.4 > instead of 23 > FreeBSD4/p1/p172/stderr.pgm:1 error(s) and 0 warning(s) detected > FreeBSD4/p1/p185/stderr.pgm:************************ ERROR: 53 > instead of 24 > FreeBSD4/p1/p185/stderr.pgm:1 error(s) and 0 warning(s) detected > FreeBSD4/r0/r001/stderr.pgm:*** > FreeBSD4/r0/r001/stderr.pgm:*** runtime error: > FreeBSD4/r0/r001/stderr.pgm:*** Unhandled exception: Main.a > FreeBSD4/r0/r001/stderr.pgm:*** file "../src/Main.m3", line 13 > FreeBSD4/r0/r001/stderr.pgm:*** > FreeBSD4/r0/r003/stderr.pgm:*** > FreeBSD4/r0/r003/stderr.pgm:*** runtime error: > FreeBSD4/r0/r003/stderr.pgm:*** An open array had the wrong shape. > FreeBSD4/r0/r003/stderr.pgm:*** file "../src/Main.m3", line 19 > FreeBSD4/r0/r003/stderr.pgm:*** > FreeBSD4/r0/r004/stderr.pgm:*** > FreeBSD4/r0/r004/stderr.pgm:*** runtime error: > FreeBSD4/r0/r004/stderr.pgm:*** An enumeration or subrange value > was out of range. > FreeBSD4/r0/r004/stderr.pgm:*** file "../src/runtime/common/ > RTAllocator.m3", line 309 > FreeBSD4/r0/r004/stderr.pgm:*** >>>> 7 in test_m3tests 2008-01-19-02-30-01 /home/wagner/work/cm3-ws/ >>>> luthien-2008-01-19-02-30-01 > === 2008-01-19 23:50:47 cm3 m3tests run done > > Thanks in advance for your comments, > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, > Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 > 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: > Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > DE163214194 From dabenavidesd at yahoo.es Sun Jan 20 23:30:59 2008 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Sun, 20 Jan 2008 23:30:59 +0100 (CET) Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: Message-ID: <651689.4797.qm@web27107.mail.ukl.yahoo.com> Hi: Yes, there is some kind of support for /dev file system, though I have not used it, I think this documentation is reliable: http://www.cygwin.com/cygwin-ug-net/using-specialnames.html Well after all the things you are right because the license issues maybe affect the decision of some users of making use of cygwin (NT386GNU): Let's suppose that there is some user(s) interested more in WIN32 platform so we can expose a better support for that on NT386_MINGW or in current NT386. The NT386GNU user(s) would be more appropriate for those interested in using more tools of a POSIX enviroment, let's say grep, gaw, POSIX functions of time, x server/client enviroment and all the stuff you can get to work on cygwin. So the second user has to pay (if he needs) attention on the licensing issues of all of the used tools. Thanks for the comments. Daniel Benavides Jay wrote: .hmmessage P { margin:0px; padding:0px } body.hmmessage { FONT-SIZE: 10pt; FONT-FAMILY:Tahoma } Daniel, yes it's true cygwin has like -mno-cygwin or something. I will have to try that. Currently msys is required to build m3cc and cygwin is required to build m3gdb. m3gdb didn't have any type information anyway, so if you install cygwin, you can just use its gdb. (Note that cygwin is highly modular/package-based, so you can pick and chose what you install, there are many many many choices, so you don't automatically get gdb, you don't automatically even get gcc or ld/binutils.) Otherwise just MinGWin is required. Cygwin might just work. I'll try it before much longer. Is someone going to go ahead and create a new target? I guess I'm about able to. I think I finally fixed the major crash so can..take a break and then continue. Wow that was tedious. Once I can get a MinGWin distribution, I want to look at the pixmap bug, before looking into this new target.. Maybe someone will beat me to it though? /dev does not appear in Cygwin, at least not with cd and ls on my system. I expect /dev/null will work. I do have a very limited installed of Cygwin now, as I was trying to understand roughly what is needed. I don't know what to expect from /dev in Cygwin. You might be asking for too much. $ ls /dev/null /dev/null Jay at jay-win1 / $ ls /proc 1312 cpuinfo meminfo registry stat version 3936 loadavg partitions self uptime Jay at jay-win1 / $ ls /dev ls: cannot access /dev: No such file or directory $ ls /dev/tty /dev/tty $ ls /dev/con ls: cannot access /dev/con: No such file or directory Jay at jay-win1 / $ ls /dev/fd0 /dev/fd0 Jay at jay-win1 / $ ls /dev/fd* ls: cannot access /dev/fd*: No such file or directory Jay at jay-win1 / $ ls /dev/hd0 ls: cannot access /dev/hd0: No such file or directory Jay at jay-win1 / $ ls /dev/sc* ls: cannot access /dev/sc*: No such file or directory I'm not sure what all to guess here. fd0 appears but I don't have a floppy disk. $ cat /proc/uptime 41101.28 32423.71 Jay at jay-win1 / $ cat /proc/version CYGWIN_NT-5.1 1.5.25(0.156/4/2) 2007-12-14 19:21 I'm inclined not to make any cygwin binary distributions until further reading of the license... There's still the X Windows vs. Win32 question... - Jay --------------------------------- Date: Sun, 20 Jan 2008 21:41:23 +0100 From: dabenavidesd at yahoo.es Subject: Re: [M3devel] [M3commit] CVS Update: cm3 To: jayk123 at hotmail.com; wagner at elegosoft.com; m3devel at elegosoft.com Hi: I think for all the users that maybe NT386GNU is more thought like NT386cygwin, but if we see that GNU tools are used in projects like Mingw, that is a fork of cygwin and with the aim of programs running without the dependency on cygwin dll, that maybe guide us to say that the "old target" NT386GNU should be run with a cygwin enviroment. The NT386_MINGW seems to be a nice name/description for the platform which no depends on cygwin.dll but a MinGW/MSYS enviroment. Certainly I think the gnu toolchain is highly used by both the projects, and as I remember, when installing gcc on cygwin it also offers the mingw tool set to the cygwin enviroment to be installed. So let's say that projects are very related and cooperative, but are not the same. So Jay, m3cc could be built on a cygwin enviroment and m3gdb? If so, we can think in those two separeted platforms? although cooperative for m3 developers. I would like to see m3-lectern packages running on NT386GNU using the filesystem /dev, which is something that I wouldn't expect to be on the proposed NT386_MINGW platform. Thanks Jay wrote: .ExternalClass .EC_hmmessage P {padding:0px;} .ExternalClass EC_body.hmmessage {font-size:10pt;font-family:Tahoma;} > the infrastructure. So I'd rather vote that only new targets get > more systematic names. Of course, though the existing names suggest new names, and not clear the value of the existing NT386GNU. Ie. is there a benefit to keep it in use with some meaning or not? Cygwin does have a larger jmpbuf than msvcr*.dll/mingwin. I think it holds sigaction state besides register state. "NT" and "Win" seem redundant. I386_MINGWIN? I386_CYGWIN? NT386_GNU? NT386_MINGNU? Ok, I admit that NT386_CYGWIN NT386_MINGWIN despite the redundancy, clearly point to existing projects that probably have name recognition. And building from NT386 is reasonable -- as was I saying about existing names influencing new names. A C generating backend gets you perhaps easier retargeting as well. I do see there is "MINGWIN64" out there, for AMD64. Not sure what the state of IA64 is though... (See -- you should avoid saying "32" or "64" in stuff, Win32 => Win, Win64 => Win.) I also would agree that creating one target instead of two is probably a good idea -- seems easier. I am not sure if current state is relevant. I mean, is NT386GNU really working and in use anywhere? Is PM3 in use? If so, then matching their meaning would be good. Or even going beyond that -- to Trestle on X Windows. :) (Though CygwinX doesn't exactly appear active.) And thus the precedent for no underscore. NT386MINGWIN ? NT386MINGNU ? I don't know if "MSYS" needs a place in this name. It is needed for building m3cc. I wonder if a hybrid/adaptive approach will be desired -- if Cygwin is available, the MinGWin target could use it to build m3gdb, since it can't otherwise. Hint for anyone trying out Cygwin and getting an odd mix of paths: mkdir \cygdrive get junction.exe from the former www.sysinternals.com junction \cygdrive\c c:\ now when some Cygwin code passes /cygdrive/c to Win32 code, it will just work, no translation needed. If you have multiple drives, I guess just fully populate each one c:\cygdrive\c => c:\ c:\cygdrive\d => d:\ d:\cygdrive\c => c:\ d:\cygdrive\d => d:\ etc. but I haven't tried that. Or, to reduce the multiplication, set them all up on c: and have d:\cygdrive => c:\cygdrive, e:\cygdrive => c:\cygdrive, etc. - Jay --------------------------------- > Date: Sun, 20 Jan 2008 15:56:49 +0100 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > Quoting Jay : > > > Good, a happy customer. :) > > > >> GNU_MODE = 0 % Do not use GNU tools at all -- today's NT386 > >> GNU_MODE = 1 % Use GNU tools minimally -- today's NT386GNU > >> GNU_MODE = 2 % Use GNU tools maximally -- not existant but probably > >> easy > >> > >> Eh..I know, not great.. what do "minimally" and "maximally" mean. > > > > I'm still fishing for anyone to provide answers to these > > less important decisions that I have trouble with. > > Otherwise maybe no NT Cygwin system. > > > > TARGETs = { NT386, NT386GNU, NT386CYGWIN }? > > TARGETs = { NT386, NT386MINGWIN, NT386CYGWIN }? > > TARGETs = { NT386 + GNU_MODE }? > > > > The one reason I don't favor NT386 + GNU_MODE is that Cygwin has a > > much larger jmpbuf than the others. > > I think same TARGET implies code can be linked together, and I think > > varying jmpbuf implies otherwise. > > So NT386 and NT386MINGWIN should rarely cross paths with NT386CYGWIN. > > I think a new target is called for if I have understood everything right. > We need one pure native target (NT386), one pure-Cygwin-based target > (NT386_CYGWIN?) and one mix of runtime, gnu tools and mingwin > (NT386_MINGWIN?). > > As NT386GNU already exists, we must decide if we want to use it as > we traditionally did (all Cygwin) or the mixed implementation > (Mingwin and much Windows RT). > > > I also do NOT like this ad-hoc naming style. > > PPC_DARWIN, I386_DARWIN are much more to my style. > > The names should be somehow hierarchical, except, I realize, there > > isn't necessarily one "path" of > > stuff which to name platforms, though the GNU folks have settled on > > a way or two. > > They have triples or quadruples -- processor-hardware-os or such, > > however this doesn't > > clearly suffice. > > Well, yes, something more systematic would have been better, but > to break with the history will cause much trouble for all users and > the infrastructure. So I'd rather vote that only new targets get > more systematic names. > > > Something that accomodates: > > NT386 + LLVM > > NT386 + Watcom, linker and/or backend and/or runtime > > NT386 + Digital Mars linker and/or backend and/or runtime > > A C generating backend, and then linker/runtime > > and similar IA64, AMD64 variants would be good. > > I'm not sure that a C generating backend would really help matters. > This was done in the first implementation of DEC, and they soon > abandoned it as C had proven to be a bad choice as intermediate language. > I agree it would be great for cross-compilation etc. > > As far as C and RT dependencies of native Windows compilers go, I don't > see why this couldn't be just a question of another cm3.cfg setup. > > > To a large extent, these can be few platforms, subject to > > configuration, like if all > > the linkers consume a common file format (not clear), and if all the > > jmpbufs are the same > > size (known to be partly true, partly false). > > Yes, jmpbuf is always a problem for user threads and exceptions. > On Unix systems the jmpbuf and other important low-level structures > are always defined by the system headers and independent of compilers > AFAIK, so I'm a bit surprised that it should be different on Windows. > But maybe I'm just wrong and haven't just seen the right counter > examples... > > > Oh and another thing, the runtime dependency is very likely cuttable, however > > PRESUMABLY real world applications (if there are any) link in a > > substantial amount of > > C or C++, in which case, it isn't necessarily cuttable. > > Yes. Real world applications tend to link other libraries (C, C++, > Fortran, ...) and even often call other applications like sh etc. > > > As well, if I can figure out a good way to do it, switching NT386 > > from awful slow > > frequent TlsGetValue/TlsSetValue to manipulating the linked list in > > fs:0, that would be nice, > > and might incur a C runtime dependency, but well worth it. The way > > Modula-3 works here > > is terrible. Another compromise option is probably > > __declspec(thread), though there is trickiness there > > in terms of being in a .dll that isn't used by the .exe. > > Such optimizations should be done depending on the target. > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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! --------------------------------- Web Revelaci?n Yahoo! 2007: Premio Favorita del P?blico - ?Vota tu preferida! --------------------------------- Shed those extra pounds with MSN and The Biggest Loser! Learn more. --------------------------------- Web Revelaci?n Yahoo! 2007: Premio Favorita del P?blico - ?Vota tu preferida! -------------- next part -------------- An HTML attachment was scrubbed... URL: From dabenavidesd at yahoo.es Sun Jan 20 23:35:02 2008 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Sun, 20 Jan 2008 23:35:02 +0100 (CET) Subject: [M3devel] cygwin users? In-Reply-To: Message-ID: <786049.83427.qm@web27111.mail.ukl.yahoo.com> I guess my discussion is more about of an ideal world for programmers :) that has a lot of discussion, but also for all the users that want to port more easily applications from a (~)Unix platforms to Windows like I would like to do it with m3-lectern packages. Thanks again, Daniel Benavides Jay escribi?: .hmmessage P { margin:0px; padding:0px } body.hmmessage { FONT-SIZE: 10pt; FONT-FAMILY:Tahoma } Does anyone who is asking for Cygwin support actually use it? Or you are all just Unix users? (And MinGW users either?) I mean, are we hearing what people want and will use, or just what ought to exist in some ideal world? - Jay --------------------------------- Climb to the top of the charts! Play the word scramble challenge with star power. Play now! --------------------------------- Web Revelaci?n Yahoo! 2007: Premio Favorita del P?blico - ?Vota tu preferida! -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Sun Jan 20 23:45:32 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Sun, 20 Jan 2008 23:45:32 +0100 Subject: [M3devel] cygwin users? In-Reply-To: References: <862972.55026.qm@web27105.mail.ukl.yahoo.com> Message-ID: <20080120234532.1dstrrusisoscc0s@mail.elegosoft.com> Quoting Jay : > Does anyone who is asking for Cygwin support actually use it? Or you > are all just Unix users? > (And MinGW users either?) > I mean, are we hearing what people want and will use, or just what > ought to exist in some ideal world? I haven been using Cygwin several years ago, and would do so again. Whenever I have to use a Windows system, one of the first things I do is install Cygwin to have a comfortable command line environment I am familiar with. I'd be especially interested in M3-XWindows programs running on Cygwin, as the native Trestle implementation was never complete, IIRC. And X-Servers are really common and easy to install nowadays even on 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 darko at darko.org Mon Jan 21 01:18:59 2008 From: darko at darko.org (Darko) Date: Sun, 20 Jan 2008 16:18:59 -0800 Subject: [M3devel] cygwin users? In-Reply-To: References: <862972.55026.qm@web27105.mail.ukl.yahoo.com> Message-ID: <7EEE72F7-B0D1-42FB-B5D7-4C2E3533F16E@darko.org> I don't use Cygwin, but I use a Unix command line under Windows (I found the basic bash tools compiled to be used standalone under Windows, they might be MinGW based, but I'm not sure). I generally use GUI tools, CodeWarrior on my Mac generally, but also the MS IDE for its debugging tool. I'm interested in the NT/GNU platform mostly for the optimised code generation. I guess I represent the other side to the Unix geeks - it's just another platform to me and I'd like to keep it distinct from Windows, mainly for performance, compatibility and simplicity. I think there are many potential users like me out there, who don't particularly care about Unix. M3's Unix heritage has hindered M3 a little I think. One of the reasons M3 isn't more popular is because there are no simple installers for common "user" platforms. One of the things I'd like to do is create a installer for Windows and Mac OS X with full native API interfaces, a full set of relevant compiled libraries, and a little bit of documentation. That way people can give it a try with the minimum of time invested. People will discover M3 is a great language to program in if people actually get a chance to use it. Thanks for doing all the work you've been doing on the NT platform, Jay, it is much appreciated and has the potential to bring may more users to M3. Darko. On 20/01/2008, at 1:09 PM, Jay wrote: > Does anyone who is asking for Cygwin support actually use it? Or you > are all just Unix users? > (And MinGW users either?) > I mean, are we hearing what people want and will use, or just what > ought to exist in some ideal world? > > - Jay > > Climb to the top of the charts! Play the word scramble challenge > with star power. Play now! From jayk123 at hotmail.com Mon Jan 21 05:45:43 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 21 Jan 2008 04:45:43 +0000 Subject: [M3devel] "one more time before I give in" :) Message-ID: Should the mingwin/msys method just be a configuration of NT386? A command line option to cm3 and/or an environment variable? The targets are nearly the same. The difference just needs to be exposed somehow, so the config file can switch betwen two implementations of a few functions -- compile_c, m3_link, make_lib. If Windows cminstall/src/config/NT386 and cminstall/src/config/NT386GNU, you see very very similar. Maybe they vary just in BUILD_DIR? Or does that break things?Profiling changes BUILD_DIR so I figure it might be ok. I tried making BUILD_DIR not readonly and setting it with cm3 -D, doesn't work. It can probably be set conditionally in the config file based on another variable though, I'd have to check. Besides, it might be nice for a notion of a set of build_dirs that are probed. In particular, you might have some C or C++ code that uses GCC (or Microsoft) extensions. That could also be handled by a different variable, like compile_with_gcc() and compile_with_msvc() in the m3makefile and then cm3 would switch between compile_gcc and compile_msvc instead of the usual compile_c functoin. There is a high degree of interoperabilty between these two or even all three platforms. Perhaps this is a can of worms though. Much potential utility but too complicated to think about? Perhaps I too desperate to have fewer platforms? I do need multiple build_dirs, like three, that is certain. - 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 Mon Jan 21 06:05:03 2008 From: darko at darko.org (Darko) Date: Sun, 20 Jan 2008 21:05:03 -0800 Subject: [M3devel] "one more time before I give in" :) In-Reply-To: References: Message-ID: <1E4B5D9E-F0B1-4E2F-90E6-34385C5CDFB6@darko.org> Can we just have them as separate config files and anyone who wants to switch between them can do so in a script or other method on their own platform? Most people would just choose one and stick to it. We should try to keep it simple and move the complexity to people who want a more complex setup. On 20/01/2008, at 8:45 PM, Jay wrote: > Should the mingwin/msys method just be a configuration of NT386? > A command line option to cm3 and/or an environment variable? > > The targets are nearly the same. > The difference just needs to be exposed somehow, so the config file > can switch betwen two implementations of a few functions -- > compile_c, m3_link, make_lib. > If Windows cminstall/src/config/NT386 and cminstall/src/config/ > NT386GNU, you see very very similar. > > Maybe they vary just in BUILD_DIR? Or does that break things? > Profiling changes BUILD_DIR so I figure it might be ok. > I tried making BUILD_DIR not readonly and setting it with cm3 -D, > doesn't work. > It can probably be set conditionally in the config file based on > another variable though, I'd have to check. > > Besides, it might be nice for a notion of a set of build_dirs that > are probed. > In particular, you might have some C or C++ code that uses GCC (or > Microsoft) extensions. > That could also be handled by a different variable, like > compile_with_gcc() and compile_with_msvc() in the m3makefile and > then cm3 would switch between compile_gcc and compile_msvc instead > of the usual compile_c functoin. > > There is a high degree of interoperabilty between these two or even > all three platforms. > > Perhaps this is a can of worms though. Much potential utility but > too complicated to think about? > > Perhaps I too desperate to have fewer platforms? > I do need multiple build_dirs, like three, that is certain. > > - Jay > > Helping your favorite cause is as easy as instant messaging. You IM, > we give. Learn more. From jayk123 at hotmail.com Mon Jan 21 06:47:28 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 21 Jan 2008 05:47:28 +0000 Subject: [M3devel] next problem (NT386GNU) Message-ID: M3File.m3 PROCEDURE IsReadable (path: TEXT): BOOLEAN = (* We don't really check for readablitiy, just for existence *) BEGIN TRY EVAL FS.Status (path); line 82 RETURN TRUE; EXCEPT OSError.E => RETURN FALSE; END; END IsReadable; -----LINE 82 ----- start_call_direct p.25 0 Struct load_address v.25 0 pop_param Addr load v.26 0 Addr Addr pop_param Addr call_direct p.25 Struct pop StructI'm guessing you only see an import for the first call on purpose, but I will compare with PPC_DARWIN: -----LINE 46 ----- import_procedure FS__Status 2 Struct 0 p.25 declare_indirect 2078421550 -2078421551 declare_param _return 4 4 Addr 2078421550 F F 50 v.62 declare_param p 4 4 Addr 1358456180 F F 50 v.63 start_call_direct p.25 0 Struct load_address v.13 0 pop_param Addr load v.14 0 Addr Addr pop_param Addr call_direct p.25 Struct pop Struct .globl _M3File__IsReadable .def _M3File__IsReadable; .scl 2; .type 32; .endef_M3File__IsReadable: .stabn 68,0,178,LM93-_M3File__IsReadableLM93: pushl %ebp movl %esp, %ebp pushl %edi pushl %esi pushl %ebx subl $300, %espLBB15: .stabn 68,0,181,LM94-_M3File__IsReadableLM94:L157: movl -280(%ebp), %eax andl $0, %eax orl $_L_1, %eax movl %eax, -280(%ebp) movl -284(%ebp), %eax andl $0, %eax movl %eax, -284(%ebp) subl $12, %esp leal -288(%ebp), %eax pushl %eax call _RTHooks__PushEFrame addl $16, %esp leal -288(%ebp), %eax addl $48, %eax subl $12, %esp pushl %eax call __setjmp addl $16, %esp testb %al, %al jne L158 .stabn 68,0,183,LM95-_M3File__IsReadableLM95: movl -288(%ebp), %eax subl $12, %esp pushl %eax call _RTHooks__PopEFrame addl $16, %esp movl $1, -304(%ebp) jmp L159L158: .stabn 68,0,185,LM96-_M3File__IsReadableLM96: movl $0, -304(%ebp)L159:LBE15: movl -304(%ebp), %eax leal -12(%ebp), %esp popl %ebx popl %esi popl %edi leave ret M3File.IsReadable's call to FS.Status is omitted, all files are readable, even if they are not openable, therefore it "finds" cm3.cfg in the current directory and then fails to open it.. later.. ..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 wagner at elegosoft.com Mon Jan 21 08:20:53 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 21 Jan 2008 08:20:53 +0100 Subject: [M3devel] "one more time before I give in" :) In-Reply-To: References: Message-ID: <20080121082053.2ph7hxo5esw0wk0g@mail.elegosoft.com> Quoting Jay : > Should the mingwin/msys method just be a configuration of NT386? > A command line option to cm3 and/or an environment variable? > > The targets are nearly the same. > The difference just needs to be exposed somehow, so the config file > can switch betwen two implementations of a few functions -- > compile_c, m3_link, make_lib. > If Windows cminstall/src/config/NT386 and > cminstall/src/config/NT386GNU, you see very very similar. As long as the M3 and C code is all the same, I'm not against having just different cm3.cfg files. > Maybe they vary just in BUILD_DIR? Or does that break > things?Profiling changes BUILD_DIR so I figure it might be ok. > I tried making BUILD_DIR not readonly and setting it with cm3 -D, > doesn't work. > It can probably be set conditionally in the config file based on > another variable though, I'd have to check. > > Besides, it might be nice for a notion of a set of build_dirs that > are probed. > In particular, you might have some C or C++ code that uses GCC (or > Microsoft) extensions. > That could also be handled by a different variable, like > compile_with_gcc() and compile_with_msvc() in the m3makefile and > then cm3 would switch between compile_gcc and compile_msvc instead > of the usual compile_c functoin. > > There is a high degree of interoperabilty between these two or even > all three platforms. > > Perhaps this is a can of worms though. Much potential utility but > too complicated to think about? > > Perhaps I too desperate to have fewer platforms? > I do need multiple build_dirs, like three, that is certain. Using other build_dirs for derived target files from cm3.cfg should work, too; but we should not diverge too much from the staandard; perhaps just add a _MINGWIN or _CYGWIN suffix? Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Jan 21 08:43:53 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 21 Jan 2008 07:43:53 +0000 Subject: [M3devel] next problem (NT386GNU) Message-ID: I haven't tested a fix but I see the problem. This function returns a struct. There are two struct returning calling conventions. In one, the backend handles it. Which includes the backend knowing there is a return value and its type (or at least its size?). In the other, the front end handles it. In this case, the front end generates passing an extra pointer parameter to the function, and the function's return type is void. The NT calling conventions, all of them, are marked as front end handling it. I assume that is correct, could check. Everything else is marked as back end handling. Now then, somewhere along the line, gcc figures out that the return value isn't used here. The point of the function call is to see if it generates an exception.Gcc removes the function because its return value isn't used, and, well, somehow it doesn't know about the exceptions here. I'll have to see how "raise" is implemented. I think it's by a call to a function that gets the jmpbuf from a thread local and calls longjmp. (Did I mention it is very inefficient?) There are few possible fixes, but nothing completely satisfactory yet in mind. One is have parse.c mark all function calls as having side affects. This is easy, but overly pessimistic. Another is for the front end to mark struct returning functions as having side affects. Better, but still overly pessimistic. Another is for the front end to mark any function that can raise as having side affects. Getting better still. I don't know how to do that but I'll look. This is still a bit overly pessimistic, since what you really want to know is, not the function's side affects, but whether or not it raised. If the function is inlined, the side affects could be optimized away, or if there are enough callers who don't care about the side affects to warrant an optimization, and depending on the cost of computing the side affects, another instance of the function could be made that only raises or not, but no side affects otherwise. This is "advanced" optimization the sort of which tends never to be implemented. I think the best option is anything that can raise is marked as having side affects. I'll see if I can figure that out. You can figure this out by looking at m3cgcat -binary < M3File.mc > 1.txt on PPC_DARWIN and NT386GNU and comparing. Maybe marking all or nearly functions as having side effects isn't so bad. Or at least anything returning a struct. That gets parity with other platforms, even if it is a bit pessimistic. I think I'll do that, and ignore figuring out if raise is called and using that as a filter. The parity angle is good. The good news for all you Unix lovers :) is this bug is relatively portable to Cygwin. True, it is specific to NT386GNU having multiple "calling conventions", which no other platform has. Which again, jokingly, strikes at the question -- What is Posix? What do you want from Cygwin? One thing Cygwin does NOT give you is just one calling convention, alas, this calling convention business stinks. It's not even an NT thing, only an NT386 thing. All the other NT platforms had/have only one calling convention. You can't get far on NT386 without needing to support two calling conventions. The "OS" uses mostly __stdcall -- callee pops -- smaller, faster. But anything that is varargs, such as printf -- pretty much must use caller pops -- __cdecl. As well, __cdecl is the default, so prevalent, and used in most C runtime functions. There is also __fastcall that uses like up to two registers for parameters. I have seen a platform in which printf did the pop, and it depended on the number/size of parameters matching the format string. On most platforms, printf("", 1, 2, 3, 4) just does nothing, but on that platform, it'd unbalance the stack and crash. - Jay From: jayk123 at hotmail.comTo: hosking at cs.purdue.eduCC: m3devel at elegosoft.comSubject: next problem (NT386GNU)Date: Mon, 21 Jan 2008 05:47:28 +0000 M3File.m3 PROCEDURE IsReadable (path: TEXT): BOOLEAN = (* We don't really check for readablitiy, just for existence *) BEGIN TRY EVAL FS.Status (path); line 82 RETURN TRUE; EXCEPT OSError.E => RETURN FALSE; END; END IsReadable; -----LINE 82 ----- start_call_direct p.25 0 Struct load_address v.25 0 pop_param Addr load v.26 0 Addr Addr pop_param Addr call_direct p.25 Struct pop StructI'm guessing you only see an import for the first call on purpose, but I will compare with PPC_DARWIN: -----LINE 46 ----- import_procedure FS__Status 2 Struct 0 p.25 declare_indirect 2078421550 -2078421551 declare_param _return 4 4 Addr 2078421550 F F 50 v.62 declare_param p 4 4 Addr 1358456180 F F 50 v.63 start_call_direct p.25 0 Struct load_address v.13 0 pop_param Addr load v.14 0 Addr Addr pop_param Addr call_direct p.25 Struct pop Struct .globl _M3File__IsReadable .def _M3File__IsReadable; .scl 2; .type 32; .endef_M3File__IsReadable: .stabn 68,0,178,LM93-_M3File__IsReadableLM93: pushl %ebp movl %esp, %ebp pushl %edi pushl %esi pushl %ebx subl $300, %espLBB15: .stabn 68,0,181,LM94-_M3File__IsReadableLM94:L157: movl -280(%ebp), %eax andl $0, %eax orl $_L_1, %eax movl %eax, -280(%ebp) movl -284(%ebp), %eax andl $0, %eax movl %eax, -284(%ebp) subl $12, %esp leal -288(%ebp), %eax pushl %eax call _RTHooks__PushEFrame addl $16, %esp leal -288(%ebp), %eax addl $48, %eax subl $12, %esp pushl %eax call __setjmp addl $16, %esp testb %al, %al jne L158 .stabn 68,0,183,LM95-_M3File__IsReadableLM95: movl -288(%ebp), %eax subl $12, %esp pushl %eax call _RTHooks__PopEFrame addl $16, %esp movl $1, -304(%ebp) jmp L159L158: .stabn 68,0,185,LM96-_M3File__IsReadableLM96: movl $0, -304(%ebp)L159:LBE15: movl -304(%ebp), %eax leal -12(%ebp), %esp popl %ebx popl %esi popl %edi leave ret M3File.IsReadable's call to FS.Status is omitted, all files are readable, even if they are not openable, therefore it "finds" cm3.cfg in the current directory and then fails to open it.. later.. ..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 Mon Jan 21 09:03:44 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 21 Jan 2008 08:03:44 +0000 Subject: [M3devel] FW: next problem (NT386GNU) Message-ID: and again my mail got truncated..Clearly the best option, despite the pessimism, is to mark all struct returning functions has having side affects, as that achieves parity with all the other gcc-based platforms. Optimizing this can be left for later target-independent work that'll probably never happen. Changing the calling convention is almost an option, as there are so few functions in the world foolhardy enough to return structs. If they are all written in Modula-3, then there'd be enough consistency. Sleazy though.I'll see what PM3 does first. - Jay Which again, jokingly, strikes at the question -- What is Posix? What do you want from Cygwin?One thing Cygwin does NOT give you is just one calling convention, alas, this calling convention business stinks. It's not even an NT thing, only an NT386 thing. All the other NT platforms had/have only one calling convention. You can't get far on NT386 without needing to support two calling conventions.The "OS" uses mostly __stdcall -- callee pops -- smaller, faster.But anything that is varargs, such as printf -- pretty much must use caller pops -- __cdecl.As well, __cdecl is the default, so prevalent, and used in most C runtime functions.There is also __fastcall that uses like up to two registers for parameters. I have seen a platform in which printf did the pop, and it depended on the number/size of parameters matching the format string. On most platforms, printf("", 1, 2, 3, 4) just does nothing, but on that platform, it'd unbalance the stack and crash. - Jay From: jayk123 at hotmail.comTo: hosking at cs.purdue.eduCC: m3devel at elegosoft.comSubject: next problem (NT386GNU)Date: Mon, 21 Jan 2008 05:47:28 +0000 M3File.m3 PROCEDURE IsReadable (path: TEXT): BOOLEAN = (* We don't really check for readablitiy, just for existence *) BEGIN TRY EVAL FS.Status (path); line 82 RETURN TRUE; EXCEPT OSError.E => RETURN FALSE; END; END IsReadable; -----LINE 82 ----- start_call_direct p.25 0 Struct load_address v.25 0 pop_param Addr load v.26 0 Addr Addr pop_param Addr call_direct p.25 Struct pop StructI'm guessing you only see an import for the first call on purpose, but I will compare with PPC_DARWIN: -----LINE 46 ----- import_procedure FS__Status 2 Struct 0 p.25 declare_indirect 2078421550 -2078421551 declare_param _return 4 4 Addr 2078421550 F F 50 v.62 declare_param p 4 4 Addr 1358456180 F F 50 v.63 start_call_direct p.25 0 Struct load_address v.13 0 pop_param Addr load v.14 0 Addr Addr pop_param Addr call_direct p.25 Struct pop Struct .globl _M3File__IsReadable .def _M3File__IsReadable; .scl 2; .type 32; .endef_M3File__IsReadable: .stabn 68,0,178,LM93-_M3File__IsReadableLM93: pushl %ebp movl %esp, %ebp pushl %edi pushl %esi pushl %ebx subl $300, %espLBB15: .stabn 68,0,181,LM94-_M3File__IsReadableLM94:L157: movl -280(%ebp), %eax andl $0, %eax orl $_L_1, %eax movl %eax, -280(%ebp) movl -284(%ebp), %eax andl $0, %eax movl %eax, -284(%ebp) subl $12, %esp leal -288(%ebp), %eax pushl %eax call _RTHooks__PushEFrame addl $16, %esp leal -288(%ebp), %eax addl $48, %eax subl $12, %esp pushl %eax call __setjmp addl $16, %esp testb %al, %al jne L158 .stabn 68,0,183,LM95-_M3File__IsReadableLM95: movl -288(%ebp), %eax subl $12, %esp pushl %eax call _RTHooks__PopEFrame addl $16, %esp movl $1, -304(%ebp) jmp L159L158: .stabn 68,0,185,LM96-_M3File__IsReadableLM96: movl $0, -304(%ebp)L159:LBE15: movl -304(%ebp), %eax leal -12(%ebp), %esp popl %ebx popl %esi popl %edi leave ret M3File.IsReadable's call to FS.Status is omitted, all files are readable, even if they are not openable, therefore it "finds" cm3.cfg in the current directory and then fails to open it.. later.. ..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! 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 Jan 21 09:05:32 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 21 Jan 2008 08:05:32 +0000 Subject: [M3devel] next problem (NT386GNU) Message-ID: pm3: IF gnuWin32 THEN CCs[x].args_left_to_right := TRUE; CCs[x].results_on_left := TRUE; CCs[x].standard_structs := TRUE; END;Duh, maybe the backend handles it correctly. I'll try.. - Jay From: jayk123 at hotmail.comTo: m3devel at elegosoft.comSubject: FW: next problem (NT386GNU)Date: Mon, 21 Jan 2008 08:03:44 +0000 and again my mail got truncated..Clearly the best option, despite the pessimism, is to mark all struct returning functions has having side affects, as that achieves parity with all the other gcc-based platforms. Optimizing this can be left for later target-independent work that'll probably never happen. Changing the calling convention is almost an option, as there are so few functions in the world foolhardy enough to return structs. If they are all written in Modula-3, then there'd be enough consistency. Sleazy though.I'll see what PM3 does first. - Jay Which again, jokingly, strikes at the question -- What is Posix? What do you want from Cygwin?One thing Cygwin does NOT give you is just one calling convention, alas, this calling convention business stinks. It's not even an NT thing, only an NT386 thing. All the other NT platforms had/have only one calling convention. You can't get far on NT386 without needing to support two calling conventions.The "OS" uses mostly __stdcall -- callee pops -- smaller, faster.But anything that is varargs, such as printf -- pretty much must use caller pops -- __cdecl.As well, __cdecl is the default, so prevalent, and used in most C runtime functions.There is also __fastcall that uses like up to two registers for parameters. I have seen a platform in which printf did the pop, and it depended on the number/size of parameters matching the format string. On most platforms, printf("", 1, 2, 3, 4) just does nothing, but on that platform, it'd unbalance the stack and crash. - Jay From: jayk123 at hotmail.comTo: hosking at cs.purdue.eduCC: m3devel at elegosoft.comSubject: next problem (NT386GNU)Date: Mon, 21 Jan 2008 05:47:28 +0000 M3File.m3 PROCEDURE IsReadable (path: TEXT): BOOLEAN = (* We don't really check for readablitiy, just for existence *) BEGIN TRY EVAL FS.Status (path); line 82 RETURN TRUE; EXCEPT OSError.E => RETURN FALSE; END; END IsReadable; -----LINE 82 ----- start_call_direct p.25 0 Struct load_address v.25 0 pop_param Addr load v.26 0 Addr Addr pop_param Addr call_direct p.25 Struct pop StructI'm guessing you only see an import for the first call on purpose, but I will compare with PPC_DARWIN: -----LINE 46 ----- import_procedure FS__Status 2 Struct 0 p.25 declare_indirect 2078421550 -2078421551 declare_param _return 4 4 Addr 2078421550 F F 50 v.62 declare_param p 4 4 Addr 1358456180 F F 50 v.63 start_call_direct p.25 0 Struct load_address v.13 0 pop_param Addr load v.14 0 Addr Addr pop_param Addr call_direct p.25 Struct pop Struct .globl _M3File__IsReadable .def _M3File__IsReadable; .scl 2; .type 32; .endef_M3File__IsReadable: .stabn 68,0,178,LM93-_M3File__IsReadableLM93: pushl %ebp movl %esp, %ebp pushl %edi pushl %esi pushl %ebx subl $300, %espLBB15: .stabn 68,0,181,LM94-_M3File__IsReadableLM94:L157: movl -280(%ebp), %eax andl $0, %eax orl $_L_1, %eax movl %eax, -280(%ebp) movl -284(%ebp), %eax andl $0, %eax movl %eax, -284(%ebp) subl $12, %esp leal -288(%ebp), %eax pushl %eax call _RTHooks__PushEFrame addl $16, %esp leal -288(%ebp), %eax addl $48, %eax subl $12, %esp pushl %eax call __setjmp addl $16, %esp testb %al, %al jne L158 .stabn 68,0,183,LM95-_M3File__IsReadableLM95: movl -288(%ebp), %eax subl $12, %esp pushl %eax call _RTHooks__PopEFrame addl $16, %esp movl $1, -304(%ebp) jmp L159L158: .stabn 68,0,185,LM96-_M3File__IsReadableLM96: movl $0, -304(%ebp)L159:LBE15: movl -304(%ebp), %eax leal -12(%ebp), %esp popl %ebx popl %esi popl %edi leave ret M3File.IsReadable's call to FS.Status is omitted, all files are readable, even if they are not openable, therefore it "finds" cm3.cfg in the current directory and then fails to open it.. later.. ..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! Learn more. 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 jayk123 at hotmail.com Mon Jan 21 11:50:28 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 21 Jan 2008 10:50:28 +0000 Subject: [M3devel] gcc/eh/setjmp Message-ID: Folks, try adding -Wunreachable-code to your m3back options and tell me if you don't get loads of warnings. for stuff like: TRY return Foo(); ELSE return FALSE; I get them on NT386GNU and PPC_DARWIN. Functions with TRY need, in gcc parlance: calls_setjmp and the exception/finally blocks need: has_nonlocal_label and functions with RAISE might need: has_nonlocal_goto Luckily, gcc doesn't seem to act on what it figure out. - 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 mika at async.caltech.edu Mon Jan 21 11:54:26 2008 From: mika at async.caltech.edu (Mika Nystrom) Date: Mon, 21 Jan 2008 02:54:26 -0800 Subject: [M3devel] cygwin users? In-Reply-To: Your message of "Sun, 20 Jan 2008 21:09:42 GMT." Message-ID: <200801211054.m0LAsQbx067355@camembert.async.caltech.edu> I develop on FreeBSD but my production system runs under Cygwin. It links with libpq.a, plus various C and Fortran code I wrote myself under Unix. It also builds with make, uses readline, calls /bin/sh, etc., etc., etc. I'm using PM3/Klagenfurt for this, and I'm just DYING to shift it to CM3 one day, because since I need Pickles to work across all architectures I'm using I'm currently in the situation that I can't use Linux in our clustered system (no PM3), nor can I use MacOS (also no PM3). One of my business partners uses Ubuntu, so his computer can't talk to mine, and I have a Mac laptop, so my laptop can't talk to my main systems. Etc. Cygwin is the only of five or six environments that I have to use that can't run CM3. Yes it is probably possible for me to port my code to native Windows (anything is possible), but the beauty of Cygwin is that I can be fairly confident that any code that works on FreeBSD, no matter how weird and Unix-specific, will also work on Cygwin. (Once you know about the pitfalls in Time.T and file semantics.) I am a bona fide "Windows hater". To me, Windows is an especially bloated program loader that for some bizarre reason people have chosen to load the most useful web browsers and music players. I haven't found anything else useful that it does. I have seen people use something called "Visual Studio" on it. Oh yes, I even used it myself once, but I couldn't figure out how to transport the program I wrote to the computer of someone who didn't have "Visual Studio" to run (even after asking some of my former students, who are now programmers at Microsoft), so I gave up on it. I think it is for people like me that Cygwin was invented. Mika Jay writes: >--_674d79e8-e259-4230-8419-f52e99d90089_ >Content-Type: text/plain; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > >Does anyone who is asking for Cygwin support actually use it? Or you are al= >l just Unix users? >(And MinGW users either?) >I mean, are we hearing what people want and will use, or just what ought to= > exist in some ideal world? >=20 > - Jay >_________________________________________________________________ >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= > >--_674d79e8-e259-4230-8419-f52e99d90089_ >Content-Type: text/html; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > > > > >Does anyone who is asking for Cygwin support actu= >ally use it? Or you are all just Unix users?
>(And MinGW users either?)
>I mean, are we hearing what people want and will use, or just what ought to= > exist in some ideal world?
> 
> - Jay

Climb to the top of the charts!=A0Play the word = >scramble challenge with star power. uffle.aspx?icid=3Dstarshuffle_wlmailtextlink_jan' target=3D'_new'>Play now!= > >= > >--_674d79e8-e259-4230-8419-f52e99d90089_-- From lemming at henning-thielemann.de Mon Jan 21 12:51:48 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Mon, 21 Jan 2008 12:51:48 +0100 (MET) Subject: [M3devel] Open CM3 regression tests In-Reply-To: <20080120211832.GA26993@elegosoft.com> References: <20080120211832.GA26993@elegosoft.com> Message-ID: On Sun, 20 Jan 2008, Olaf Wagner wrote: > > no errors for p1 to p115 > > --- p116b --- default IEEE floating point tests from Xerox PARC > --- p1/p116b/stderr.pgm 2008-01-20 00:47:20.000000000 +0100 > +++ ../src/p1/p116b/stderr.pgm 2008-01-13 00:55:55.000000000 +0100 My compiler complains about LONGINT type in src/Test.i3 . I assume that this is the 64 bit support. Seems that I have to upgrade my compiler. In general floating point is a strange issue. You cannot rely on that your machine supports IEEE format, although most machines do. The precision of the same float type can be different on different machines. However, the Float modules shall reflect that. Computation with NaN and Infinity is broken, it should be avoided and in most cases continueing the computation with NaN or Infinity only hides the precise error location. It would be better to abort with an error for a division by zero, overflow and so on. I think one can enable this with FloatModes. From jayk123 at hotmail.com Mon Jan 21 14:19:41 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 21 Jan 2008 13:19:41 +0000 Subject: [M3devel] gcc/eh/setjmp Message-ID: I've been trying sprinkling these bits around, to no avail. I realize another larger step is to communicate much try/except/finally information down, in order to use the native support (which still stinks on Windows). I stupidly plumbed the depths of "CG" to communicate the bits down before seeing what was needed.. - Jay From: jayk123 at hotmail.comTo: m3devel at elegosoft.comSubject: gcc/eh/setjmpDate: Mon, 21 Jan 2008 10:50:28 +0000 Folks, try adding -Wunreachable-code to your m3back options and tell me if you don't get loads of warnings.for stuff like: TRY return Foo();ELSE return FALSE; I get them on NT386GNU and PPC_DARWIN. Functions with TRY need, in gcc parlance: calls_setjmp and the exception/finally blocks need: has_nonlocal_label and functions with RAISE might need: has_nonlocal_goto Luckily, gcc doesn't seem to act on what it figure out. - Jay Helping your favorite cause is as easy as instant messaging. You IM, we give. Learn more. _________________________________________________________________ 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 Jan 21 15:50:06 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 21 Jan 2008 14:50:06 +0000 Subject: [M3devel] code quality.. Message-ID: Unoptimized code quality is really bad, even compared to unoptimized C, even compared to gcc, and optimized code quality isn't great. I have this made up C code. I was verifyingthe struct return calling convention. typedef struct { unsigned a; unsigned b; unsigned c;} d; d F2(unsigned a, unsigned b, unsigned c){ d e; e.a = a * b * c; e.b = 123; e.c = a - b - c; return e;} and then the equivalent Modula-3: INTERFACE T; TYPE T1 = RECORD a,b,c : INTEGEREND; PROCEDURE F2(a,b,c : INTEGER) : T1; END T. MODULE T; PROCEDURE F2(a,b,c : INTEGER) : T1 =VAR e : T1;BEGIN e.a := (a * b * c); e.b := 123; e.c := (a - b - c); RETURN e;END F2; BEGINEND T. Unoptimized Visual C++ 8.0: _F2: 00000000: 55 push ebp 00000001: 8B EC mov ebp,esp 00000003: 83 EC 0C sub esp,0Ch 00000006: 8B 45 0C mov eax,dword ptr [ebp+0Ch] 00000009: 0F AF 45 10 imul eax,dword ptr [ebp+10h] 0000000D: 0F AF 45 14 imul eax,dword ptr [ebp+14h] 00000011: 89 45 F4 mov dword ptr [ebp-0Ch],eax 00000014: C7 45 F8 7B 00 00 mov dword ptr [ebp-8],7Bh 00 0000001B: 8B 4D 0C mov ecx,dword ptr [ebp+0Ch] 0000001E: 2B 4D 10 sub ecx,dword ptr [ebp+10h] 00000021: 2B 4D 14 sub ecx,dword ptr [ebp+14h] 00000024: 89 4D FC mov dword ptr [ebp-4],ecx 00000027: 8B 55 08 mov edx,dword ptr [ebp+8] 0000002A: 8B 45 F4 mov eax,dword ptr [ebp-0Ch] 0000002D: 89 02 mov dword ptr [edx],eax 0000002F: 8B 4D F8 mov ecx,dword ptr [ebp-8] 00000032: 89 4A 04 mov dword ptr [edx+4],ecx 00000035: 8B 45 FC mov eax,dword ptr [ebp-4] 00000038: 89 42 08 mov dword ptr [edx+8],eax 0000003B: 8B 45 08 mov eax,dword ptr [ebp+8] 0000003E: 8B E5 mov esp,ebp 00000040: 5D pop ebp 00000041: C3 ret Visual C++ 8.0 with /O1 It writes the results right into the output. _F2: 00000000: 55 push ebp 00000001: 8B EC mov ebp,esp 00000003: 8B 4D 0C mov ecx,dword ptr [ebp+0Ch] 00000006: 8B 45 08 mov eax,dword ptr [ebp+8] 00000009: 8B D1 mov edx,ecx 0000000B: 0F AF 55 10 imul edx,dword ptr [ebp+10h] 0000000F: 0F AF 55 14 imul edx,dword ptr [ebp+14h] 00000013: 2B 4D 10 sub ecx,dword ptr [ebp+10h] 00000016: 89 10 mov dword ptr [eax],edx 00000018: 2B 4D 14 sub ecx,dword ptr [ebp+14h] 0000001B: C7 40 04 7B 00 00 mov dword ptr [eax+4],7Bh 00 00000022: 89 48 08 mov dword ptr [eax+8],ecx 00000025: 5D pop ebp 00000026: C3 ret with /O2 _F2: 00000000: 8B 4C 24 08 mov ecx,dword ptr [esp+8] 00000004: 8B 54 24 0C mov edx,dword ptr [esp+0Ch] 00000008: 8B 44 24 04 mov eax,dword ptr [esp+4] 0000000C: 56 push esi 0000000D: 8B 74 24 14 mov esi,dword ptr [esp+14h] 00000011: 57 push edi 00000012: 8B F9 mov edi,ecx 00000014: 0F AF FA imul edi,edx 00000017: 0F AF FE imul edi,esi 0000001A: 2B CA sub ecx,edx 0000001C: 89 38 mov dword ptr [eax],edi 0000001E: 2B CE sub ecx,esi 00000020: 5F pop edi 00000021: C7 40 04 7B 00 00 mov dword ptr [eax+4],7Bh 00 00000028: 89 48 08 mov dword ptr [eax+8],ecx 0000002B: 5E pop esi 0000002C: C3 ret gcc 3.4.5 unoptimized _F2: 00000000: 55 push ebp 00000001: 89 E5 mov ebp,esp 00000003: 83 EC 18 sub esp,18h 00000006: 8B 4D 08 mov ecx,dword ptr [ebp+8] 00000009: 8B 45 0C mov eax,dword ptr [ebp+0Ch] 0000000C: 0F AF 45 10 imul eax,dword ptr [ebp+10h] 00000010: 0F AF 45 14 imul eax,dword ptr [ebp+14h] 00000014: 89 45 E8 mov dword ptr [ebp-18h],eax 00000017: C7 45 EC 7B 00 00 mov dword ptr [ebp-14h],7Bh 00 0000001E: 8B 55 10 mov edx,dword ptr [ebp+10h] 00000021: 8B 45 0C mov eax,dword ptr [ebp+0Ch] 00000024: 29 D0 sub eax,edx 00000026: 2B 45 14 sub eax,dword ptr [ebp+14h] 00000029: 89 45 F0 mov dword ptr [ebp-10h],eax 0000002C: 8B 45 E8 mov eax,dword ptr [ebp-18h] 0000002F: 89 01 mov dword ptr [ecx],eax 00000031: 8B 45 EC mov eax,dword ptr [ebp-14h] 00000034: 89 41 04 mov dword ptr [ecx+4],eax 00000037: 8B 45 F0 mov eax,dword ptr [ebp-10h] 0000003A: 89 41 08 mov dword ptr [ecx+8],eax 0000003D: 89 C8 mov eax,ecx 0000003F: C9 leave 00000040: C2 04 00 ret 4 00000043: 90 nop 00000044: 90 nop ...more nops for padding... gcc -O1 _F2: 00000000: 55 push ebp 00000001: 89 E5 mov ebp,esp 00000003: 83 EC 18 sub esp,18h 00000006: 89 5D F8 mov dword ptr [ebp-8],ebx 00000009: 89 75 FC mov dword ptr [ebp-4],esi 0000000C: 8B 45 08 mov eax,dword ptr [ebp+8] 0000000F: 8B 4D 0C mov ecx,dword ptr [ebp+0Ch] 00000012: 8B 5D 10 mov ebx,dword ptr [ebp+10h] 00000015: 8B 75 14 mov esi,dword ptr [ebp+14h] 00000018: 89 CA mov edx,ecx 0000001A: 0F AF D3 imul edx,ebx 0000001D: 0F AF D6 imul edx,esi 00000020: 29 D9 sub ecx,ebx 00000022: 29 F1 sub ecx,esi 00000024: 89 10 mov dword ptr [eax],edx 00000026: C7 40 04 7B 00 00 mov dword ptr [eax+4],7Bh 00 0000002D: 89 48 08 mov dword ptr [eax+8],ecx 00000030: 8B 5D F8 mov ebx,dword ptr [ebp-8] 00000033: 8B 75 FC mov esi,dword ptr [ebp-4] 00000036: 89 EC mov esp,ebp 00000038: 5D pop ebp 00000039: C2 04 00 ret 4 0000003C: 90 nop 0000003D: 90 nop 0000003E: 90 nop 0000003F: 90 nop I didn't investigate all the switches much and simple -O vs. -O1 vs. -O2 vs. -o3all do the same. -O1 -fomit-frame-pointer netted: _F2: 00000000: 83 EC 1C sub esp,1Ch 00000003: 89 5C 24 14 mov dword ptr [esp+14h],ebx 00000007: 89 74 24 18 mov dword ptr [esp+18h],esi 0000000B: 8B 44 24 20 mov eax,dword ptr [esp+20h] 0000000F: 8B 4C 24 24 mov ecx,dword ptr [esp+24h] 00000013: 8B 5C 24 28 mov ebx,dword ptr [esp+28h] 00000017: 8B 74 24 2C mov esi,dword ptr [esp+2Ch] 0000001B: 89 CA mov edx,ecx 0000001D: 0F AF D3 imul edx,ebx 00000020: 0F AF D6 imul edx,esi 00000023: 29 D9 sub ecx,ebx 00000025: 29 F1 sub ecx,esi 00000027: 89 10 mov dword ptr [eax],edx 00000029: C7 40 04 7B 00 00 mov dword ptr [eax+4],7Bh 00 00000030: 89 48 08 mov dword ptr [eax+8],ecx 00000033: 8B 5C 24 14 mov ebx,dword ptr [esp+14h] 00000037: 8B 74 24 18 mov esi,dword ptr [esp+18h] 0000003B: 83 C4 1C add esp,1Ch 0000003E: C2 04 00 ret 4 00000041: 90 nop .. more nops .. Ok, ready, here goes the unoptimized Modula-3.Notice the duplicate copying of the return value and the *doubling* in code size. _T__F2: 00000000: 55 push ebp 00000001: 89 E5 mov ebp,esp 00000003: 57 push edi 00000004: 56 push esi 00000005: 83 EC 30 sub esp,30h 00000008: 8B 55 0C mov edx,dword ptr [ebp+0Ch] 0000000B: 8B 45 10 mov eax,dword ptr [ebp+10h] 0000000E: 0F AF D0 imul edx,eax 00000011: 8B 45 14 mov eax,dword ptr [ebp+14h] 00000014: 0F AF D0 imul edx,eax 00000017: 8B 45 D4 mov eax,dword ptr [ebp-2Ch] 0000001A: 83 E0 00 and eax,0 0000001D: 09 D0 or eax,edx 0000001F: 89 45 D4 mov dword ptr [ebp-2Ch],eax 00000022: 8B 45 D8 mov eax,dword ptr [ebp-28h] 00000025: 83 E0 00 and eax,0 00000028: 83 C8 7B or eax,7Bh 0000002B: 89 45 D8 mov dword ptr [ebp-28h],eax 0000002E: 8B 55 0C mov edx,dword ptr [ebp+0Ch] 00000031: 8B 45 10 mov eax,dword ptr [ebp+10h] 00000034: 29 C2 sub edx,eax 00000036: 8B 45 14 mov eax,dword ptr [ebp+14h] 00000039: 29 C2 sub edx,eax 0000003B: 8B 45 DC mov eax,dword ptr [ebp-24h] 0000003E: 83 E0 00 and eax,0 00000041: 09 D0 or eax,edx 00000043: 89 45 DC mov dword ptr [ebp-24h],eax 00000046: 8B 45 08 mov eax,dword ptr [ebp+8] 00000049: 89 C2 mov edx,eax 0000004B: 8D 45 D4 lea eax,[ebp-2Ch] 0000004E: 8D 7D EC lea edi,[ebp-14h] 00000051: 89 C6 mov esi,eax 00000053: FC cld 00000054: A5 movs dword ptr es:[edi],dword ptr [esi] 00000055: A5 movs dword ptr es:[edi],dword ptr [esi] 00000056: A5 movs dword ptr es:[edi],dword ptr [esi] 00000057: 89 D7 mov edi,edx 00000059: 8D 75 EC lea esi,[ebp-14h] 0000005C: FC cld 0000005D: A5 movs dword ptr es:[edi],dword ptr [esi] 0000005E: A5 movs dword ptr es:[edi],dword ptr [esi] 0000005F: A5 movs dword ptr es:[edi],dword ptr [esi] 00000060: 83 C4 30 add esp,30h 00000063: 5E pop esi 00000064: 5F pop edi 00000065: C9 leave 00000066: C3 ret optimized Modula-3 is better, saves the extra copy, but still not great: _T__F2: 00000000: 55 push ebp 00000001: 89 E5 mov ebp,esp 00000003: 57 push edi 00000004: 56 push esi 00000005: 53 push ebx 00000006: 83 EC 10 sub esp,10h 00000009: 8B 55 0C mov edx,dword ptr [ebp+0Ch] 0000000C: 8B 4D 10 mov ecx,dword ptr [ebp+10h] 0000000F: 8B 5D 14 mov ebx,dword ptr [ebp+14h] 00000012: 89 D0 mov eax,edx 00000014: 0F AF C1 imul eax,ecx 00000017: 0F AF C3 imul eax,ebx 0000001A: 8B 75 E8 mov esi,dword ptr [ebp-18h] 0000001D: 89 45 E8 mov dword ptr [ebp-18h],eax 00000020: 8B 45 EC mov eax,dword ptr [ebp-14h] 00000023: C7 45 EC 7B 00 00 mov dword ptr [ebp-14h],7Bh 00 0000002A: 29 CA sub edx,ecx 0000002C: 29 DA sub edx,ebx Huh what does this next instruction achieve? 0000002E: 8B 45 F0 mov eax,dword ptr [ebp-10h] 00000031: 89 55 F0 mov dword ptr [ebp-10h],edx 00000034: 8B 7D 08 mov edi,dword ptr [ebp+8] 00000037: 8D 75 E8 lea esi,[ebp-18h] 0000003A: FC cld 0000003B: A5 movs dword ptr es:[edi],dword ptr [esi] 0000003C: A5 movs dword ptr es:[edi],dword ptr [esi] 0000003D: A5 movs dword ptr es:[edi],dword ptr [esi] 0000003E: 83 C4 10 add esp,10h 00000041: 5B pop ebx 00000042: 5E pop esi 00000043: 5F pop edi 00000044: C9 leave 00000045: C3 ret and lastly the integrated backend, which runs much faster, and I believe has just one mode,somewhat optimized (but still lacks int64 support): _T__F2: 00000000: 55 push ebp 00000001: 8B EC mov ebp,esp 00000003: 81 EC 18 00 00 00 sub esp,18h 00000009: 53 push ebx 0000000A: 56 push esi 0000000B: 57 push edi 0000000C: 8B 5D 10 mov ebx,dword ptr [ebp+10h] 0000000F: 0F AF 5D 0C imul ebx,dword ptr [ebp+0Ch] 00000013: 0F AF 5D 14 imul ebx,dword ptr [ebp+14h] 00000017: 89 5D F4 mov dword ptr [ebp-0Ch],ebx 0000001A: C7 45 F8 7B 00 00 mov dword ptr [ebp-8],7Bh 00 00000021: 8B 55 0C mov edx,dword ptr [ebp+0Ch] 00000024: 2B 55 10 sub edx,dword ptr [ebp+10h] 00000027: 2B 55 14 sub edx,dword ptr [ebp+14h] 0000002A: 89 55 FC mov dword ptr [ebp-4],edx 0000002D: 8D 75 F4 lea esi,[ebp-0Ch] 00000030: 8B 7D 08 mov edi,dword ptr [ebp+8] 00000033: 8B 4E 00 mov ecx,dword ptr [esi] 00000036: 89 4F 00 mov dword ptr [edi],ecx 00000039: 8B 4E 04 mov ecx,dword ptr [esi+4] 0000003C: 89 4F 04 mov dword ptr [edi+4],ecx 0000003F: 8B 4E 08 mov ecx,dword ptr [esi+8] 00000042: 89 4F 08 mov dword ptr [edi+8],ecx 00000045: 8B C7 mov eax,edi 00000047: 5F pop edi 00000048: 5E pop esi 00000049: 5B pop ebx 0000004A: C9 leave 0000004B: C3 ret I haven't looked at all this in depth, but the doubling in size, the extra copy, that the integrated backend's code is fairly small... - 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 Jan 21 16:22:32 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 21 Jan 2008 15:22:32 +0000 Subject: [M3devel] safety vs. capacity vs. reinvention? Message-ID: I'm constantly noticing fixed sized buffers in the Modula-3 code and reinvention of basic data types and algorithms, such as growable arrays. Something seems off, eh? Here's the latest: -> linking cm3.exec:\\docume~1\\jay\\locals~1\\temp\\cm3\\make-dist\\tmpukymas\\cm3-core-WIN32-NT386GNU-d5.5.1\\pkg\\m3back\\NT386GNU\\m3back.lib c:\\docume~1\\jay\\locals~1\\temp\\cm3\\make-dist\\tmpukymas\\cm3-core-WIN32-NT386GNU-d5.5.1\\pkg\\m3objfile\\NT386GNU\\m3objfile.lib c:\\docume~1\\jay\\locals~1\\temp\\cm3\\make-dist\\tmpukymas\\cm3-core-WIN32-NT386GNU-d5.5.1\\pkg\\m3quake\\NT386GNU\\m3quake.lib c:\\docume~1\\jay\\locals~1\\temp\\cm3\\make-dist\\tmpukymas\\cm3-core-WIN32-NT386GNU-d5.5.1\\pkg\\m3front\\NT386GNU\\m3front.lib c:\\docume~1\\jay\\locals~1\\temp\\cm3\\make-dist\\tmpukymas\\cm3-core-WIN32-NT386GNU-d5.5.1\\pkg\\m3linker\\NT386GNU\\m3link.lib c:\\docume~1\\jay\\locals~1\\temp\\cm3\\make-dist\\tmpukymas\\cm3-core-WIN32-NT386GNU-d5.5.1\\pkg\\m3middle\\NT386GNU\\m3middle.lib c:\\docume~1\\jay\\locals~1\\temp\\cm3\\make-dist\\tmpukymas\\cm3-core-WIN32-NT386GNU-d5.5.1\\pkg\\libm3\\NT386GNU\\m3.lib.sa c:\\docume~1\\jay\\locals~1\\temp\\cm3\\make-dist\\tmpukymas\\cm3-core-WIN32-NT386GNU-d5.5.1\\pkg\\m3core\\NT386GNU\\m3core.lib.sa -lcomctl32 -lwsock32 -lnetapi32 -lgdi32 -luser32 ****** runtime error:*** <*ASSERT*> failed.*** file "..\src\M3ID.m3", line 58*** Stack trace: FP PC Procedure--------- --------- ------------------------------- 0x22f198 0x59e9c3 Add + 0x53 in ..\src\M3ID.m3 0x22f1c8 0x4209cb Txt2ID + 0x14 in ..\src\M3Build.m3 0x22f208 0x478f9f PushText + 0x97 in ..\src\QMachine.m3 0x22f418 0x47c38f DoEscape + 0x341 in ..\src\QMachine.m3 0x22f478 0x476a37 DoCall + 0x568 in ..\src\QMachine.m3 0x22f558 0x475a49 Eval + 0x1845(!) in ..\src\QMachine.m3 0x22f578 0x4764ca CallProc + 0x2b in ..\src\QMachine.m3 0x22f6e8 0x413717 CallProc + 0x156 in ..\src\Builder.m3 0x22f758 0x40e96a BuildProgram + 0x66a in ..\src\Builder.m3 0x22f788 0x402282 BuildPgm + 0x62 in ..\src\Builder.m3......... ......... ... more frames ... PROCEDURE Add (x: TEXT; class: [0..255]): T = VAR t : T; len := Text.Length (x); buf : ARRAY [0..1024] OF CHAR; BEGIN IF len > NUMBER(buf) THEN IO.Put(x); END; <*ASSERT len <= NUMBER (buf) *> Text.SetChars (buf, x); t := FromStr (buf, len); IF (class # 0) THEN classes [t] := class; END; IF (ids[t].text = NIL) THEN ids[t].text := x; END; RETURN t; END Add;The code is escaping imported .libs in order to write them into a response file, since gcc needs the doubled slashes.. I'm using a response file BECAUSE I have a long string.. - 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 Jan 21 16:54:10 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 21 Jan 2008 10:54:10 -0500 Subject: [M3devel] next problem (NT386GNU) In-Reply-To: References: Message-ID: <6E1E4409-F3D9-4982-B179-2D4C9648FDD0@cs.purdue.edu> Surely, when using the gcc-based backend then we should make the backend handle it. The front end handling it is only need for the integrated x86 backend. On Jan 21, 2008, at 2:43 AM, Jay wrote: > I haven't tested a fix but I see the problem. > > This function returns a struct. > There are two struct returning calling conventions. > In one, the backend handles it. Which includes the backend knowing > there is a return value and its type (or at least its size?). > In the other, the front end handles it. In this case, the front end > generates passing an extra pointer parameter to the function, and > the function's return type is void. > > The NT calling conventions, all of them, are marked as front end > handling it. I assume that is correct, could check. > Everything else is marked as back end handling. > > Now then, somewhere along the line, gcc figures out that the return > value isn't used here. > The point of the function call is to see if it generates an exception. > > Gcc removes the function because its return value isn't used, and, > well, somehow it doesn't know about the exceptions here. I'll have > to see how "raise" is implemented. I think it's by a call to a > function that gets the jmpbuf from a thread local and calls > longjmp. (Did I mention it is very inefficient?) > > There are few possible fixes, but nothing completely satisfactory > yet in mind. > > One is have parse.c mark all function calls as having side affects. > This is easy, but overly pessimistic. > Another is for the front end to mark struct returning functions as > having side affects. Better, but still overly pessimistic. > Another is for the front end to mark any function that can raise as > having side affects. Getting better still. I don't know how to do > that but I'll look. This is still a bit overly pessimistic, since > what you really want to know is, not the function's side affects, > but whether or not it raised. If the function is inlined, the side > affects could be optimized away, or if there are enough callers who > don't care about the side affects to warrant an optimization, and > depending on the cost of computing the side affects, another > instance of the function could be made that only raises or not, but > no side affects otherwise. This is "advanced" optimization the sort > of which tends never to be implemented. > > I think the best option is anything that can raise is marked as > having side affects. > I'll see if I can figure that out. > > You can figure this out by looking at m3cgcat -binary < M3File.mc > > 1.txt on PPC_DARWIN and NT386GNU and comparing. > > Maybe marking all or nearly functions as having side effects isn't > so bad. > Or at least anything returning a struct. That gets parity with > other platforms, even if it is a bit pessimistic. > I think I'll do that, and ignore figuring out if raise is called > and using that as a filter. > The parity angle is good. > > The good news for all you Unix lovers :) is this bug is relatively > portable to Cygwin. > True, it is specific to NT386GNU having multiple "calling > conventions", which no other platform has. > Which again, jokingly, strikes at the question -- What is Posix? > What do you want from Cygwin? > One thing Cygwin does NOT give you is just one calling convention, > alas, this calling convention business stinks. It's not even an NT > thing, only an NT386 thing. All the other NT platforms had/have > only one calling convention. > > You can't get far on NT386 without needing to support two calling > conventions. > The "OS" uses mostly __stdcall -- callee pops -- smaller, faster. > But anything that is varargs, such as printf -- pretty much must > use caller pops -- __cdecl. > As well, __cdecl is the default, so prevalent, and used in most C > runtime functions. > There is also __fastcall that uses like up to two registers for > parameters. > > I have seen a platform in which printf did the pop, and it depended > on the number/size of parameters matching the format string. On > most platforms, printf("", 1, 2, 3, 4) just does nothing, but on > that platform, it'd unbalance the stack and crash. > > - Jay > > From: jayk123 at hotmail.com > To: hosking at cs.purdue.edu > CC: m3devel at elegosoft.com > Subject: next problem (NT386GNU) > Date: Mon, 21 Jan 2008 05:47:28 +0000 > > M3File.m3 > > PROCEDURE IsReadable (path: TEXT): BOOLEAN = > (* We don't really check for readablitiy, just for existence *) > BEGIN > TRY > EVAL FS.Status (path); line 82 > RETURN TRUE; > EXCEPT OSError.E => > RETURN FALSE; > END; > END IsReadable; > > -----LINE 82 ----- > start_call_direct p.25 0 Struct > load_address v.25 0 > pop_param Addr > load v.26 0 Addr Addr > pop_param Addr > call_direct p.25 Struct > pop Struct > > > > I'm guessing you only see an import for the first call on purpose, > but I will compare with PPC_DARWIN: > > -----LINE 46 ----- > import_procedure FS__Status 2 Struct 0 p.25 > declare_indirect 2078421550 -2078421551 > declare_param _return 4 4 Addr 2078421550 F F 50 v.62 > declare_param p 4 4 Addr 1358456180 F F 50 v.63 > start_call_direct p.25 0 Struct > load_address v.13 0 > pop_param Addr > load v.14 0 Addr Addr > pop_param Addr > call_direct p.25 Struct > pop Struct > > > .globl _M3File__IsReadable > .def _M3File__IsReadable; .scl 2; .type 32; .endef > _M3File__IsReadable: > .stabn 68,0,178,LM93-_M3File__IsReadable > LM93: > pushl %ebp > movl %esp, %ebp > pushl %edi > pushl %esi > pushl %ebx > subl $300, %esp > LBB15: > .stabn 68,0,181,LM94-_M3File__IsReadable > LM94: > L157: > movl -280(%ebp), %eax > andl $0, %eax > orl $_L_1, %eax > movl %eax, -280(%ebp) > movl -284(%ebp), %eax > andl $0, %eax > movl %eax, -284(%ebp) > subl $12, %esp > leal -288(%ebp), %eax > pushl %eax > call _RTHooks__PushEFrame > addl $16, %esp > leal -288(%ebp), %eax > addl $48, %eax > subl $12, %esp > pushl %eax > call __setjmp > addl $16, %esp > testb %al, %al > jne L158 > .stabn 68,0,183,LM95-_M3File__IsReadable > LM95: > movl -288(%ebp), %eax > subl $12, %esp > pushl %eax > call _RTHooks__PopEFrame > addl $16, %esp > movl $1, -304(%ebp) > jmp L159 > L158: > .stabn 68,0,185,LM96-_M3File__IsReadable > LM96: > movl $0, -304(%ebp) > L159: > LBE15: > movl -304(%ebp), %eax > leal -12(%ebp), %esp > popl %ebx > popl %esi > popl %edi > leave > ret > > > M3File.IsReadable's call to FS.Status is omitted, all files are > readable, even if they are not openable, therefore it "finds" > cm3.cfg in the current directory and then fails to open it.. > > later.. > ..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! Learn more. From hosking at cs.purdue.edu Mon Jan 21 17:01:52 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 21 Jan 2008 11:01:52 -0500 Subject: [M3devel] code quality.. In-Reply-To: References: Message-ID: <241EF32F-F814-4EB0-88A8-B3E413D1F4BE@cs.purdue.edu> Is this having the front-end handle return of structs or the backend? On Jan 21, 2008, at 9:50 AM, Jay wrote: > Unoptimized code quality is really bad, > even compared to unoptimized C, even compared > to gcc, and optimized code quality isn't great. > > I have this made up C code. I was verifying > the struct return calling convention. > > typedef struct { > unsigned a; > unsigned b; > unsigned c; > } d; > > d F2(unsigned a, unsigned b, unsigned c) > { > d e; > e.a = a * b * c; > e.b = 123; > e.c = a - b - c; > return e; > } > > and then the equivalent Modula-3: > > INTERFACE T; > > TYPE T1 = RECORD > a,b,c : INTEGER > END; > > PROCEDURE F2(a,b,c : INTEGER) : T1; > > END T. > > MODULE T; > > PROCEDURE F2(a,b,c : INTEGER) : T1 = > VAR > e : T1; > BEGIN > e.a := (a * b * c); > e.b := 123; > e.c := (a - b - c); > RETURN e; > END F2; > > BEGIN > END T. > > Unoptimized Visual C++ 8.0: > > _F2: > 00000000: 55 push ebp > 00000001: 8B EC mov ebp,esp > 00000003: 83 EC 0C sub esp,0Ch > 00000006: 8B 45 0C mov eax,dword ptr [ebp+0Ch] > 00000009: 0F AF 45 10 imul eax,dword ptr [ebp+10h] > 0000000D: 0F AF 45 14 imul eax,dword ptr [ebp+14h] > 00000011: 89 45 F4 mov dword ptr [ebp-0Ch],eax > 00000014: C7 45 F8 7B 00 00 mov dword ptr [ebp-8],7Bh > 00 > 0000001B: 8B 4D 0C mov ecx,dword ptr [ebp+0Ch] > 0000001E: 2B 4D 10 sub ecx,dword ptr [ebp+10h] > 00000021: 2B 4D 14 sub ecx,dword ptr [ebp+14h] > 00000024: 89 4D FC mov dword ptr [ebp-4],ecx > 00000027: 8B 55 08 mov edx,dword ptr [ebp+8] > 0000002A: 8B 45 F4 mov eax,dword ptr [ebp-0Ch] > 0000002D: 89 02 mov dword ptr [edx],eax > 0000002F: 8B 4D F8 mov ecx,dword ptr [ebp-8] > 00000032: 89 4A 04 mov dword ptr [edx+4],ecx > 00000035: 8B 45 FC mov eax,dword ptr [ebp-4] > 00000038: 89 42 08 mov dword ptr [edx+8],eax > 0000003B: 8B 45 08 mov eax,dword ptr [ebp+8] > 0000003E: 8B E5 mov esp,ebp > 00000040: 5D pop ebp > 00000041: C3 ret > > Visual C++ 8.0 with /O1 > > It writes the results right into the output. > _F2: > 00000000: 55 push ebp > 00000001: 8B EC mov ebp,esp > 00000003: 8B 4D 0C mov ecx,dword ptr [ebp+0Ch] > 00000006: 8B 45 08 mov eax,dword ptr [ebp+8] > 00000009: 8B D1 mov edx,ecx > 0000000B: 0F AF 55 10 imul edx,dword ptr [ebp+10h] > 0000000F: 0F AF 55 14 imul edx,dword ptr [ebp+14h] > 00000013: 2B 4D 10 sub ecx,dword ptr [ebp+10h] > 00000016: 89 10 mov dword ptr [eax],edx > 00000018: 2B 4D 14 sub ecx,dword ptr [ebp+14h] > 0000001B: C7 40 04 7B 00 00 mov dword ptr [eax+4],7Bh > 00 > 00000022: 89 48 08 mov dword ptr [eax+8],ecx > 00000025: 5D pop ebp > 00000026: C3 ret > > with /O2 > > _F2: > 00000000: 8B 4C 24 08 mov ecx,dword ptr [esp+8] > 00000004: 8B 54 24 0C mov edx,dword ptr [esp+0Ch] > 00000008: 8B 44 24 04 mov eax,dword ptr [esp+4] > 0000000C: 56 push esi > 0000000D: 8B 74 24 14 mov esi,dword ptr [esp+14h] > 00000011: 57 push edi > 00000012: 8B F9 mov edi,ecx > 00000014: 0F AF FA imul edi,edx > 00000017: 0F AF FE imul edi,esi > 0000001A: 2B CA sub ecx,edx > 0000001C: 89 38 mov dword ptr [eax],edi > 0000001E: 2B CE sub ecx,esi > 00000020: 5F pop edi > 00000021: C7 40 04 7B 00 00 mov dword ptr [eax+4],7Bh > 00 > 00000028: 89 48 08 mov dword ptr [eax+8],ecx > 0000002B: 5E pop esi > 0000002C: C3 ret > > gcc 3.4.5 unoptimized > > _F2: > 00000000: 55 push ebp > 00000001: 89 E5 mov ebp,esp > 00000003: 83 EC 18 sub esp,18h > 00000006: 8B 4D 08 mov ecx,dword ptr [ebp+8] > 00000009: 8B 45 0C mov eax,dword ptr [ebp+0Ch] > 0000000C: 0F AF 45 10 imul eax,dword ptr [ebp+10h] > 00000010: 0F AF 45 14 imul eax,dword ptr [ebp+14h] > 00000014: 89 45 E8 mov dword ptr [ebp-18h],eax > 00000017: C7 45 EC 7B 00 00 mov dword ptr [ebp-14h],7Bh > 00 > 0000001E: 8B 55 10 mov edx,dword ptr [ebp+10h] > 00000021: 8B 45 0C mov eax,dword ptr [ebp+0Ch] > 00000024: 29 D0 sub eax,edx > 00000026: 2B 45 14 sub eax,dword ptr [ebp+14h] > 00000029: 89 45 F0 mov dword ptr [ebp-10h],eax > 0000002C: 8B 45 E8 mov eax,dword ptr [ebp-18h] > 0000002F: 89 01 mov dword ptr [ecx],eax > 00000031: 8B 45 EC mov eax,dword ptr [ebp-14h] > 00000034: 89 41 04 mov dword ptr [ecx+4],eax > 00000037: 8B 45 F0 mov eax,dword ptr [ebp-10h] > 0000003A: 89 41 08 mov dword ptr [ecx+8],eax > 0000003D: 89 C8 mov eax,ecx > 0000003F: C9 leave > 00000040: C2 04 00 ret 4 > 00000043: 90 nop > 00000044: 90 nop > ...more nops for padding... > > gcc -O1 > > _F2: > 00000000: 55 push ebp > 00000001: 89 E5 mov ebp,esp > 00000003: 83 EC 18 sub esp,18h > 00000006: 89 5D F8 mov dword ptr [ebp-8],ebx > 00000009: 89 75 FC mov dword ptr [ebp-4],esi > 0000000C: 8B 45 08 mov eax,dword ptr [ebp+8] > 0000000F: 8B 4D 0C mov ecx,dword ptr [ebp+0Ch] > 00000012: 8B 5D 10 mov ebx,dword ptr [ebp+10h] > 00000015: 8B 75 14 mov esi,dword ptr [ebp+14h] > 00000018: 89 CA mov edx,ecx > 0000001A: 0F AF D3 imul edx,ebx > 0000001D: 0F AF D6 imul edx,esi > 00000020: 29 D9 sub ecx,ebx > 00000022: 29 F1 sub ecx,esi > 00000024: 89 10 mov dword ptr [eax],edx > 00000026: C7 40 04 7B 00 00 mov dword ptr [eax+4],7Bh > 00 > 0000002D: 89 48 08 mov dword ptr [eax+8],ecx > 00000030: 8B 5D F8 mov ebx,dword ptr [ebp-8] > 00000033: 8B 75 FC mov esi,dword ptr [ebp-4] > 00000036: 89 EC mov esp,ebp > 00000038: 5D pop ebp > 00000039: C2 04 00 ret 4 > 0000003C: 90 nop > 0000003D: 90 nop > 0000003E: 90 nop > 0000003F: 90 nop > > I didn't investigate all the switches much and simple -O vs. -O1 > vs. -O2 vs. -o3 > all do the same. > > -O1 -fomit-frame-pointer netted: > > _F2: > 00000000: 83 EC 1C sub esp,1Ch > 00000003: 89 5C 24 14 mov dword ptr [esp+14h],ebx > 00000007: 89 74 24 18 mov dword ptr [esp+18h],esi > 0000000B: 8B 44 24 20 mov eax,dword ptr [esp+20h] > 0000000F: 8B 4C 24 24 mov ecx,dword ptr [esp+24h] > 00000013: 8B 5C 24 28 mov ebx,dword ptr [esp+28h] > 00000017: 8B 74 24 2C mov esi,dword ptr [esp+2Ch] > 0000001B: 89 CA mov edx,ecx > 0000001D: 0F AF D3 imul edx,ebx > 00000020: 0F AF D6 imul edx,esi > 00000023: 29 D9 sub ecx,ebx > 00000025: 29 F1 sub ecx,esi > 00000027: 89 10 mov dword ptr [eax],edx > 00000029: C7 40 04 7B 00 00 mov dword ptr [eax+4],7Bh > 00 > 00000030: 89 48 08 mov dword ptr [eax+8],ecx > 00000033: 8B 5C 24 14 mov ebx,dword ptr [esp+14h] > 00000037: 8B 74 24 18 mov esi,dword ptr [esp+18h] > 0000003B: 83 C4 1C add esp,1Ch > 0000003E: C2 04 00 ret 4 > 00000041: 90 nop > .. more nops .. > > Ok, ready, here goes the unoptimized Modula-3. > Notice the duplicate copying of the return value and the *doubling* > in code size. > > _T__F2: > 00000000: 55 push ebp > 00000001: 89 E5 mov ebp,esp > 00000003: 57 push edi > 00000004: 56 push esi > 00000005: 83 EC 30 sub esp,30h > 00000008: 8B 55 0C mov edx,dword ptr [ebp+0Ch] > 0000000B: 8B 45 10 mov eax,dword ptr [ebp+10h] > 0000000E: 0F AF D0 imul edx,eax > 00000011: 8B 45 14 mov eax,dword ptr [ebp+14h] > 00000014: 0F AF D0 imul edx,eax > 00000017: 8B 45 D4 mov eax,dword ptr [ebp-2Ch] > 0000001A: 83 E0 00 and eax,0 > 0000001D: 09 D0 or eax,edx > 0000001F: 89 45 D4 mov dword ptr [ebp-2Ch],eax > 00000022: 8B 45 D8 mov eax,dword ptr [ebp-28h] > 00000025: 83 E0 00 and eax,0 > 00000028: 83 C8 7B or eax,7Bh > 0000002B: 89 45 D8 mov dword ptr [ebp-28h],eax > 0000002E: 8B 55 0C mov edx,dword ptr [ebp+0Ch] > 00000031: 8B 45 10 mov eax,dword ptr [ebp+10h] > 00000034: 29 C2 sub edx,eax > 00000036: 8B 45 14 mov eax,dword ptr [ebp+14h] > 00000039: 29 C2 sub edx,eax > 0000003B: 8B 45 DC mov eax,dword ptr [ebp-24h] > 0000003E: 83 E0 00 and eax,0 > 00000041: 09 D0 or eax,edx > 00000043: 89 45 DC mov dword ptr [ebp-24h],eax > 00000046: 8B 45 08 mov eax,dword ptr [ebp+8] > 00000049: 89 C2 mov edx,eax > 0000004B: 8D 45 D4 lea eax,[ebp-2Ch] > 0000004E: 8D 7D EC lea edi,[ebp-14h] > 00000051: 89 C6 mov esi,eax > 00000053: FC cld > 00000054: A5 movs dword ptr es:[edi],dword > ptr [esi] > 00000055: A5 movs dword ptr es:[edi],dword > ptr [esi] > 00000056: A5 movs dword ptr es:[edi],dword > ptr [esi] > 00000057: 89 D7 mov edi,edx > 00000059: 8D 75 EC lea esi,[ebp-14h] > 0000005C: FC cld > 0000005D: A5 movs dword ptr es:[edi],dword > ptr [esi] > 0000005E: A5 movs dword ptr es:[edi],dword > ptr [esi] > 0000005F: A5 movs dword ptr es:[edi],dword > ptr [esi] > 00000060: 83 C4 30 add esp,30h > 00000063: 5E pop esi > 00000064: 5F pop edi > 00000065: C9 leave > 00000066: C3 ret > > optimized Modula-3 is better, saves the extra copy, but still not > great: > > _T__F2: > 00000000: 55 push ebp > 00000001: 89 E5 mov ebp,esp > 00000003: 57 push edi > 00000004: 56 push esi > 00000005: 53 push ebx > 00000006: 83 EC 10 sub esp,10h > 00000009: 8B 55 0C mov edx,dword ptr [ebp+0Ch] > 0000000C: 8B 4D 10 mov ecx,dword ptr [ebp+10h] > 0000000F: 8B 5D 14 mov ebx,dword ptr [ebp+14h] > 00000012: 89 D0 mov eax,edx > 00000014: 0F AF C1 imul eax,ecx > 00000017: 0F AF C3 imul eax,ebx > 0000001A: 8B 75 E8 mov esi,dword ptr [ebp-18h] > 0000001D: 89 45 E8 mov dword ptr [ebp-18h],eax > 00000020: 8B 45 EC mov eax,dword ptr [ebp-14h] > 00000023: C7 45 EC 7B 00 00 mov dword ptr [ebp-14h],7Bh > 00 > 0000002A: 29 CA sub edx,ecx > 0000002C: 29 DA sub edx,ebx > > Huh what does this next instruction achieve? > 0000002E: 8B 45 F0 mov eax,dword ptr [ebp-10h] > 00000031: 89 55 F0 mov dword ptr [ebp-10h],edx > 00000034: 8B 7D 08 mov edi,dword ptr [ebp+8] > 00000037: 8D 75 E8 lea esi,[ebp-18h] > 0000003A: FC cld > 0000003B: A5 movs dword ptr es:[edi],dword > ptr [esi] > 0000003C: A5 movs dword ptr es:[edi],dword > ptr [esi] > 0000003D: A5 movs dword ptr es:[edi],dword > ptr [esi] > 0000003E: 83 C4 10 add esp,10h > 00000041: 5B pop ebx > 00000042: 5E pop esi > 00000043: 5F pop edi > 00000044: C9 leave > 00000045: C3 ret > > and lastly the integrated backend, which runs much faster, and I > believe has just one mode, > somewhat optimized (but still lacks int64 support): > > _T__F2: > 00000000: 55 push ebp > 00000001: 8B EC mov ebp,esp > 00000003: 81 EC 18 00 00 00 sub esp,18h > 00000009: 53 push ebx > 0000000A: 56 push esi > 0000000B: 57 push edi > 0000000C: 8B 5D 10 mov ebx,dword ptr [ebp+10h] > 0000000F: 0F AF 5D 0C imul ebx,dword ptr [ebp+0Ch] > 00000013: 0F AF 5D 14 imul ebx,dword ptr [ebp+14h] > 00000017: 89 5D F4 mov dword ptr [ebp-0Ch],ebx > 0000001A: C7 45 F8 7B 00 00 mov dword ptr [ebp-8],7Bh > 00 > 00000021: 8B 55 0C mov edx,dword ptr [ebp+0Ch] > 00000024: 2B 55 10 sub edx,dword ptr [ebp+10h] > 00000027: 2B 55 14 sub edx,dword ptr [ebp+14h] > 0000002A: 89 55 FC mov dword ptr [ebp-4],edx > 0000002D: 8D 75 F4 lea esi,[ebp-0Ch] > 00000030: 8B 7D 08 mov edi,dword ptr [ebp+8] > 00000033: 8B 4E 00 mov ecx,dword ptr [esi] > 00000036: 89 4F 00 mov dword ptr [edi],ecx > 00000039: 8B 4E 04 mov ecx,dword ptr [esi+4] > 0000003C: 89 4F 04 mov dword ptr [edi+4],ecx > 0000003F: 8B 4E 08 mov ecx,dword ptr [esi+8] > 00000042: 89 4F 08 mov dword ptr [edi+8],ecx > 00000045: 8B C7 mov eax,edi > 00000047: 5F pop edi > 00000048: 5E pop esi > 00000049: 5B pop ebx > 0000004A: C9 leave > 0000004B: C3 ret > > I haven't looked at all this in depth, but the doubling in size, > the extra copy, > that the integrated backend's code is fairly small... > > - Jay > > Shed those extra pounds with MSN and The Biggest Loser! Learn more. From hosking at cs.purdue.edu Mon Jan 21 16:59:35 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 21 Jan 2008 10:59:35 -0500 Subject: [M3devel] gcc/eh/setjmp In-Reply-To: References: Message-ID: I think gcc was forced not to act on it by use of LABEL_PRESERVE_P and FORCED_LABEL as well as making the function containing the TRY non-inlinable, plus lots of other goop to let the flow analyser know that funky stuff was going on at labels for TRY scopes. Take a look at the lines of parse.c that deal with "set_label" when "barrier=TRUE". On Jan 21, 2008, at 5:50 AM, Jay wrote: > Folks, try adding -Wunreachable-code to your m3back options and > tell me if you don't get loads of warnings. > for stuff like: > > TRY > return Foo(); > ELSE > return FALSE; > > I get them on NT386GNU and PPC_DARWIN. > > Functions with TRY need, in gcc parlance: > calls_setjmp > > and the exception/finally blocks need: > has_nonlocal_label > > and functions with RAISE might need: > has_nonlocal_goto > > Luckily, gcc doesn't seem to act on what it figure out. > > - Jay > > > > > > Helping your favorite cause is as easy as instant messaging. You > IM, we give. Learn more. From jayk123 at hotmail.com Mon Jan 21 17:06:37 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 21 Jan 2008 16:06:37 +0000 Subject: [M3devel] gcc/eh/setjmp In-Reply-To: References: Message-ID: Any chance of giving gcc enough or the right information so that -Wunreachable-code can be used without hitting a bunch of false positives? It's not being dumb, not that sort of false positive. It reports every except block and anything after a try { return } except { } as unreachable. - Jay > CC: m3devel at elegosoft.com> From: hosking at cs.purdue.edu> Subject: Re: [M3devel] gcc/eh/setjmp> Date: Mon, 21 Jan 2008 10:59:35 -0500> To: jayk123 at hotmail.com> > I think gcc was forced not to act on it by use of LABEL_PRESERVE_P > and FORCED_LABEL as well as making the function containing the TRY > non-inlinable, plus lots of other goop to let the flow analyser know > that funky stuff was going on at labels for TRY scopes. Take a look > at the lines of parse.c that deal with "set_label" when "barrier=TRUE".> > On Jan 21, 2008, at 5:50 AM, Jay wrote:> > > Folks, try adding -Wunreachable-code to your m3back options and > > tell me if you don't get loads of warnings.> > for stuff like:> >> > TRY> > return Foo();> > ELSE> > return FALSE;> >> > I get them on NT386GNU and PPC_DARWIN.> >> > Functions with TRY need, in gcc parlance:> > calls_setjmp> >> > and the exception/finally blocks need:> > has_nonlocal_label> >> > and functions with RAISE might need:> > has_nonlocal_goto> >> > Luckily, gcc doesn't seem to act on what it figure out.> >> > - Jay> >> >> >> >> >> > Helping your favorite cause is as easy as instant messaging. You > > IM, we give. 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 jayk123 at hotmail.com Mon Jan 21 17:04:45 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 21 Jan 2008 16:04:45 +0000 Subject: [M3devel] code quality.. In-Reply-To: <241EF32F-F814-4EB0-88A8-B3E413D1F4BE@cs.purdue.edu> References: <241EF32F-F814-4EB0-88A8-B3E413D1F4BE@cs.purdue.edu> Message-ID: backend. I think it is correct, if inefficient. - Jay > CC: m3devel at elegosoft.com> From: hosking at cs.purdue.edu> Subject: Re: [M3devel] code quality..> Date: Mon, 21 Jan 2008 11:01:52 -0500> To: jayk123 at hotmail.com> > Is this having the front-end handle return of structs or the backend?> > On Jan 21, 2008, at 9:50 AM, Jay wrote:> > > Unoptimized code quality is really bad,> > even compared to unoptimized C, even compared> > to gcc, and optimized code quality isn't great.> >> > I have this made up C code. I was verifying> > the struct return calling convention.> >> > typedef struct {> > unsigned a;> > unsigned b;> > unsigned c;> > } d;> >> > d F2(unsigned a, unsigned b, unsigned c)> > {> > d e;> > e.a = a * b * c;> > e.b = 123;> > e.c = a - b - c;> > return e;> > }> >> > and then the equivalent Modula-3:> >> > INTERFACE T;> >> > TYPE T1 = RECORD> > a,b,c : INTEGER> > END;> >> > PROCEDURE F2(a,b,c : INTEGER) : T1;> >> > END T.> >> > MODULE T;> >> > PROCEDURE F2(a,b,c : INTEGER) : T1 => > VAR> > e : T1;> > BEGIN> > e.a := (a * b * c);> > e.b := 123;> > e.c := (a - b - c);> > RETURN e;> > END F2;> >> > BEGIN> > END T.> >> > Unoptimized Visual C++ 8.0:> >> > _F2:> > 00000000: 55 push ebp> > 00000001: 8B EC mov ebp,esp> > 00000003: 83 EC 0C sub esp,0Ch> > 00000006: 8B 45 0C mov eax,dword ptr [ebp+0Ch]> > 00000009: 0F AF 45 10 imul eax,dword ptr [ebp+10h]> > 0000000D: 0F AF 45 14 imul eax,dword ptr [ebp+14h]> > 00000011: 89 45 F4 mov dword ptr [ebp-0Ch],eax> > 00000014: C7 45 F8 7B 00 00 mov dword ptr [ebp-8],7Bh> > 00> > 0000001B: 8B 4D 0C mov ecx,dword ptr [ebp+0Ch]> > 0000001E: 2B 4D 10 sub ecx,dword ptr [ebp+10h]> > 00000021: 2B 4D 14 sub ecx,dword ptr [ebp+14h]> > 00000024: 89 4D FC mov dword ptr [ebp-4],ecx> > 00000027: 8B 55 08 mov edx,dword ptr [ebp+8]> > 0000002A: 8B 45 F4 mov eax,dword ptr [ebp-0Ch]> > 0000002D: 89 02 mov dword ptr [edx],eax> > 0000002F: 8B 4D F8 mov ecx,dword ptr [ebp-8]> > 00000032: 89 4A 04 mov dword ptr [edx+4],ecx> > 00000035: 8B 45 FC mov eax,dword ptr [ebp-4]> > 00000038: 89 42 08 mov dword ptr [edx+8],eax> > 0000003B: 8B 45 08 mov eax,dword ptr [ebp+8]> > 0000003E: 8B E5 mov esp,ebp> > 00000040: 5D pop ebp> > 00000041: C3 ret> >> > Visual C++ 8.0 with /O1> >> > It writes the results right into the output.> > _F2:> > 00000000: 55 push ebp> > 00000001: 8B EC mov ebp,esp> > 00000003: 8B 4D 0C mov ecx,dword ptr [ebp+0Ch]> > 00000006: 8B 45 08 mov eax,dword ptr [ebp+8]> > 00000009: 8B D1 mov edx,ecx> > 0000000B: 0F AF 55 10 imul edx,dword ptr [ebp+10h]> > 0000000F: 0F AF 55 14 imul edx,dword ptr [ebp+14h]> > 00000013: 2B 4D 10 sub ecx,dword ptr [ebp+10h]> > 00000016: 89 10 mov dword ptr [eax],edx> > 00000018: 2B 4D 14 sub ecx,dword ptr [ebp+14h]> > 0000001B: C7 40 04 7B 00 00 mov dword ptr [eax+4],7Bh> > 00> > 00000022: 89 48 08 mov dword ptr [eax+8],ecx> > 00000025: 5D pop ebp> > 00000026: C3 ret> >> > with /O2> >> > _F2:> > 00000000: 8B 4C 24 08 mov ecx,dword ptr [esp+8]> > 00000004: 8B 54 24 0C mov edx,dword ptr [esp+0Ch]> > 00000008: 8B 44 24 04 mov eax,dword ptr [esp+4]> > 0000000C: 56 push esi> > 0000000D: 8B 74 24 14 mov esi,dword ptr [esp+14h]> > 00000011: 57 push edi> > 00000012: 8B F9 mov edi,ecx> > 00000014: 0F AF FA imul edi,edx> > 00000017: 0F AF FE imul edi,esi> > 0000001A: 2B CA sub ecx,edx> > 0000001C: 89 38 mov dword ptr [eax],edi> > 0000001E: 2B CE sub ecx,esi> > 00000020: 5F pop edi> > 00000021: C7 40 04 7B 00 00 mov dword ptr [eax+4],7Bh> > 00> > 00000028: 89 48 08 mov dword ptr [eax+8],ecx> > 0000002B: 5E pop esi> > 0000002C: C3 ret> >> > gcc 3.4.5 unoptimized> >> > _F2:> > 00000000: 55 push ebp> > 00000001: 89 E5 mov ebp,esp> > 00000003: 83 EC 18 sub esp,18h> > 00000006: 8B 4D 08 mov ecx,dword ptr [ebp+8]> > 00000009: 8B 45 0C mov eax,dword ptr [ebp+0Ch]> > 0000000C: 0F AF 45 10 imul eax,dword ptr [ebp+10h]> > 00000010: 0F AF 45 14 imul eax,dword ptr [ebp+14h]> > 00000014: 89 45 E8 mov dword ptr [ebp-18h],eax> > 00000017: C7 45 EC 7B 00 00 mov dword ptr [ebp-14h],7Bh> > 00> > 0000001E: 8B 55 10 mov edx,dword ptr [ebp+10h]> > 00000021: 8B 45 0C mov eax,dword ptr [ebp+0Ch]> > 00000024: 29 D0 sub eax,edx> > 00000026: 2B 45 14 sub eax,dword ptr [ebp+14h]> > 00000029: 89 45 F0 mov dword ptr [ebp-10h],eax> > 0000002C: 8B 45 E8 mov eax,dword ptr [ebp-18h]> > 0000002F: 89 01 mov dword ptr [ecx],eax> > 00000031: 8B 45 EC mov eax,dword ptr [ebp-14h]> > 00000034: 89 41 04 mov dword ptr [ecx+4],eax> > 00000037: 8B 45 F0 mov eax,dword ptr [ebp-10h]> > 0000003A: 89 41 08 mov dword ptr [ecx+8],eax> > 0000003D: 89 C8 mov eax,ecx> > 0000003F: C9 leave> > 00000040: C2 04 00 ret 4> > 00000043: 90 nop> > 00000044: 90 nop> > ...more nops for padding...> >> > gcc -O1> >> > _F2:> > 00000000: 55 push ebp> > 00000001: 89 E5 mov ebp,esp> > 00000003: 83 EC 18 sub esp,18h> > 00000006: 89 5D F8 mov dword ptr [ebp-8],ebx> > 00000009: 89 75 FC mov dword ptr [ebp-4],esi> > 0000000C: 8B 45 08 mov eax,dword ptr [ebp+8]> > 0000000F: 8B 4D 0C mov ecx,dword ptr [ebp+0Ch]> > 00000012: 8B 5D 10 mov ebx,dword ptr [ebp+10h]> > 00000015: 8B 75 14 mov esi,dword ptr [ebp+14h]> > 00000018: 89 CA mov edx,ecx> > 0000001A: 0F AF D3 imul edx,ebx> > 0000001D: 0F AF D6 imul edx,esi> > 00000020: 29 D9 sub ecx,ebx> > 00000022: 29 F1 sub ecx,esi> > 00000024: 89 10 mov dword ptr [eax],edx> > 00000026: C7 40 04 7B 00 00 mov dword ptr [eax+4],7Bh> > 00> > 0000002D: 89 48 08 mov dword ptr [eax+8],ecx> > 00000030: 8B 5D F8 mov ebx,dword ptr [ebp-8]> > 00000033: 8B 75 FC mov esi,dword ptr [ebp-4]> > 00000036: 89 EC mov esp,ebp> > 00000038: 5D pop ebp> > 00000039: C2 04 00 ret 4> > 0000003C: 90 nop> > 0000003D: 90 nop> > 0000003E: 90 nop> > 0000003F: 90 nop> >> > I didn't investigate all the switches much and simple -O vs. -O1 > > vs. -O2 vs. -o3> > all do the same.> >> > -O1 -fomit-frame-pointer netted:> >> > _F2:> > 00000000: 83 EC 1C sub esp,1Ch> > 00000003: 89 5C 24 14 mov dword ptr [esp+14h],ebx> > 00000007: 89 74 24 18 mov dword ptr [esp+18h],esi> > 0000000B: 8B 44 24 20 mov eax,dword ptr [esp+20h]> > 0000000F: 8B 4C 24 24 mov ecx,dword ptr [esp+24h]> > 00000013: 8B 5C 24 28 mov ebx,dword ptr [esp+28h]> > 00000017: 8B 74 24 2C mov esi,dword ptr [esp+2Ch]> > 0000001B: 89 CA mov edx,ecx> > 0000001D: 0F AF D3 imul edx,ebx> > 00000020: 0F AF D6 imul edx,esi> > 00000023: 29 D9 sub ecx,ebx> > 00000025: 29 F1 sub ecx,esi> > 00000027: 89 10 mov dword ptr [eax],edx> > 00000029: C7 40 04 7B 00 00 mov dword ptr [eax+4],7Bh> > 00> > 00000030: 89 48 08 mov dword ptr [eax+8],ecx> > 00000033: 8B 5C 24 14 mov ebx,dword ptr [esp+14h]> > 00000037: 8B 74 24 18 mov esi,dword ptr [esp+18h]> > 0000003B: 83 C4 1C add esp,1Ch> > 0000003E: C2 04 00 ret 4> > 00000041: 90 nop> > .. more nops ..> >> > Ok, ready, here goes the unoptimized Modula-3.> > Notice the duplicate copying of the return value and the *doubling* > > in code size.> >> > _T__F2:> > 00000000: 55 push ebp> > 00000001: 89 E5 mov ebp,esp> > 00000003: 57 push edi> > 00000004: 56 push esi> > 00000005: 83 EC 30 sub esp,30h> > 00000008: 8B 55 0C mov edx,dword ptr [ebp+0Ch]> > 0000000B: 8B 45 10 mov eax,dword ptr [ebp+10h]> > 0000000E: 0F AF D0 imul edx,eax> > 00000011: 8B 45 14 mov eax,dword ptr [ebp+14h]> > 00000014: 0F AF D0 imul edx,eax> > 00000017: 8B 45 D4 mov eax,dword ptr [ebp-2Ch]> > 0000001A: 83 E0 00 and eax,0> > 0000001D: 09 D0 or eax,edx> > 0000001F: 89 45 D4 mov dword ptr [ebp-2Ch],eax> > 00000022: 8B 45 D8 mov eax,dword ptr [ebp-28h]> > 00000025: 83 E0 00 and eax,0> > 00000028: 83 C8 7B or eax,7Bh> > 0000002B: 89 45 D8 mov dword ptr [ebp-28h],eax> > 0000002E: 8B 55 0C mov edx,dword ptr [ebp+0Ch]> > 00000031: 8B 45 10 mov eax,dword ptr [ebp+10h]> > 00000034: 29 C2 sub edx,eax> > 00000036: 8B 45 14 mov eax,dword ptr [ebp+14h]> > 00000039: 29 C2 sub edx,eax> > 0000003B: 8B 45 DC mov eax,dword ptr [ebp-24h]> > 0000003E: 83 E0 00 and eax,0> > 00000041: 09 D0 or eax,edx> > 00000043: 89 45 DC mov dword ptr [ebp-24h],eax> > 00000046: 8B 45 08 mov eax,dword ptr [ebp+8]> > 00000049: 89 C2 mov edx,eax> > 0000004B: 8D 45 D4 lea eax,[ebp-2Ch]> > 0000004E: 8D 7D EC lea edi,[ebp-14h]> > 00000051: 89 C6 mov esi,eax> > 00000053: FC cld> > 00000054: A5 movs dword ptr es:[edi],dword > > ptr [esi]> > 00000055: A5 movs dword ptr es:[edi],dword > > ptr [esi]> > 00000056: A5 movs dword ptr es:[edi],dword > > ptr [esi]> > 00000057: 89 D7 mov edi,edx> > 00000059: 8D 75 EC lea esi,[ebp-14h]> > 0000005C: FC cld> > 0000005D: A5 movs dword ptr es:[edi],dword > > ptr [esi]> > 0000005E: A5 movs dword ptr es:[edi],dword > > ptr [esi]> > 0000005F: A5 movs dword ptr es:[edi],dword > > ptr [esi]> > 00000060: 83 C4 30 add esp,30h> > 00000063: 5E pop esi> > 00000064: 5F pop edi> > 00000065: C9 leave> > 00000066: C3 ret> >> > optimized Modula-3 is better, saves the extra copy, but still not > > great:> >> > _T__F2:> > 00000000: 55 push ebp> > 00000001: 89 E5 mov ebp,esp> > 00000003: 57 push edi> > 00000004: 56 push esi> > 00000005: 53 push ebx> > 00000006: 83 EC 10 sub esp,10h> > 00000009: 8B 55 0C mov edx,dword ptr [ebp+0Ch]> > 0000000C: 8B 4D 10 mov ecx,dword ptr [ebp+10h]> > 0000000F: 8B 5D 14 mov ebx,dword ptr [ebp+14h]> > 00000012: 89 D0 mov eax,edx> > 00000014: 0F AF C1 imul eax,ecx> > 00000017: 0F AF C3 imul eax,ebx> > 0000001A: 8B 75 E8 mov esi,dword ptr [ebp-18h]> > 0000001D: 89 45 E8 mov dword ptr [ebp-18h],eax> > 00000020: 8B 45 EC mov eax,dword ptr [ebp-14h]> > 00000023: C7 45 EC 7B 00 00 mov dword ptr [ebp-14h],7Bh> > 00> > 0000002A: 29 CA sub edx,ecx> > 0000002C: 29 DA sub edx,ebx> >> > Huh what does this next instruction achieve?> > 0000002E: 8B 45 F0 mov eax,dword ptr [ebp-10h]> > 00000031: 89 55 F0 mov dword ptr [ebp-10h],edx> > 00000034: 8B 7D 08 mov edi,dword ptr [ebp+8]> > 00000037: 8D 75 E8 lea esi,[ebp-18h]> > 0000003A: FC cld> > 0000003B: A5 movs dword ptr es:[edi],dword > > ptr [esi]> > 0000003C: A5 movs dword ptr es:[edi],dword > > ptr [esi]> > 0000003D: A5 movs dword ptr es:[edi],dword > > ptr [esi]> > 0000003E: 83 C4 10 add esp,10h> > 00000041: 5B pop ebx> > 00000042: 5E pop esi> > 00000043: 5F pop edi> > 00000044: C9 leave> > 00000045: C3 ret> >> > and lastly the integrated backend, which runs much faster, and I > > believe has just one mode,> > somewhat optimized (but still lacks int64 support):> >> > _T__F2:> > 00000000: 55 push ebp> > 00000001: 8B EC mov ebp,esp> > 00000003: 81 EC 18 00 00 00 sub esp,18h> > 00000009: 53 push ebx> > 0000000A: 56 push esi> > 0000000B: 57 push edi> > 0000000C: 8B 5D 10 mov ebx,dword ptr [ebp+10h]> > 0000000F: 0F AF 5D 0C imul ebx,dword ptr [ebp+0Ch]> > 00000013: 0F AF 5D 14 imul ebx,dword ptr [ebp+14h]> > 00000017: 89 5D F4 mov dword ptr [ebp-0Ch],ebx> > 0000001A: C7 45 F8 7B 00 00 mov dword ptr [ebp-8],7Bh> > 00> > 00000021: 8B 55 0C mov edx,dword ptr [ebp+0Ch]> > 00000024: 2B 55 10 sub edx,dword ptr [ebp+10h]> > 00000027: 2B 55 14 sub edx,dword ptr [ebp+14h]> > 0000002A: 89 55 FC mov dword ptr [ebp-4],edx> > 0000002D: 8D 75 F4 lea esi,[ebp-0Ch]> > 00000030: 8B 7D 08 mov edi,dword ptr [ebp+8]> > 00000033: 8B 4E 00 mov ecx,dword ptr [esi]> > 00000036: 89 4F 00 mov dword ptr [edi],ecx> > 00000039: 8B 4E 04 mov ecx,dword ptr [esi+4]> > 0000003C: 89 4F 04 mov dword ptr [edi+4],ecx> > 0000003F: 8B 4E 08 mov ecx,dword ptr [esi+8]> > 00000042: 89 4F 08 mov dword ptr [edi+8],ecx> > 00000045: 8B C7 mov eax,edi> > 00000047: 5F pop edi> > 00000048: 5E pop esi> > 00000049: 5B pop ebx> > 0000004A: C9 leave> > 0000004B: C3 ret> >> > I haven't looked at all this in depth, but the doubling in size, > > the extra copy,> > that the integrated backend's code is fairly small...> >> > - Jay> >> > 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 Mon Jan 21 17:10:19 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 21 Jan 2008 16:10:19 +0000 Subject: [M3devel] next problem (NT386GNU) In-Reply-To: <6E1E4409-F3D9-4982-B179-2D4C9648FDD0@cs.purdue.edu> References: <6E1E4409-F3D9-4982-B179-2D4C9648FDD0@cs.purdue.edu> Message-ID: agreed once I thought about it I guess that explains left to right as well. Parameters are always left to right from a higher level point of view, and if that is wrong, the compiler will reorder. "everything" works now - Jay > CC: m3devel at elegosoft.com> From: hosking at cs.purdue.edu> Subject: Re: next problem (NT386GNU)> Date: Mon, 21 Jan 2008 10:54:10 -0500> To: jayk123 at hotmail.com> > Surely, when using the gcc-based backend then we should make the > backend handle it. The front end handling it is only need for the > integrated x86 backend.> > On Jan 21, 2008, at 2:43 AM, Jay wrote:> > > I haven't tested a fix but I see the problem.> >> > This function returns a struct.> > There are two struct returning calling conventions.> > In one, the backend handles it. Which includes the backend knowing > > there is a return value and its type (or at least its size?).> > In the other, the front end handles it. In this case, the front end > > generates passing an extra pointer parameter to the function, and > > the function's return type is void.> >> > The NT calling conventions, all of them, are marked as front end > > handling it. I assume that is correct, could check.> > Everything else is marked as back end handling.> >> > Now then, somewhere along the line, gcc figures out that the return > > value isn't used here.> > The point of the function call is to see if it generates an exception.> >> > Gcc removes the function because its return value isn't used, and, > > well, somehow it doesn't know about the exceptions here. I'll have > > to see how "raise" is implemented. I think it's by a call to a > > function that gets the jmpbuf from a thread local and calls > > longjmp. (Did I mention it is very inefficient?)> >> > There are few possible fixes, but nothing completely satisfactory > > yet in mind.> >> > One is have parse.c mark all function calls as having side affects. > > This is easy, but overly pessimistic.> > Another is for the front end to mark struct returning functions as > > having side affects. Better, but still overly pessimistic.> > Another is for the front end to mark any function that can raise as > > having side affects. Getting better still. I don't know how to do > > that but I'll look. This is still a bit overly pessimistic, since > > what you really want to know is, not the function's side affects, > > but whether or not it raised. If the function is inlined, the side > > affects could be optimized away, or if there are enough callers who > > don't care about the side affects to warrant an optimization, and > > depending on the cost of computing the side affects, another > > instance of the function could be made that only raises or not, but > > no side affects otherwise. This is "advanced" optimization the sort > > of which tends never to be implemented.> >> > I think the best option is anything that can raise is marked as > > having side affects.> > I'll see if I can figure that out.> >> > You can figure this out by looking at m3cgcat -binary < M3File.mc > > > 1.txt on PPC_DARWIN and NT386GNU and comparing.> >> > Maybe marking all or nearly functions as having side effects isn't > > so bad.> > Or at least anything returning a struct. That gets parity with > > other platforms, even if it is a bit pessimistic.> > I think I'll do that, and ignore figuring out if raise is called > > and using that as a filter.> > The parity angle is good.> >> > The good news for all you Unix lovers :) is this bug is relatively > > portable to Cygwin.> > True, it is specific to NT386GNU having multiple "calling > > conventions", which no other platform has.> > Which again, jokingly, strikes at the question -- What is Posix? > > What do you want from Cygwin?> > One thing Cygwin does NOT give you is just one calling convention, > > alas, this calling convention business stinks. It's not even an NT > > thing, only an NT386 thing. All the other NT platforms had/have > > only one calling convention.> >> > You can't get far on NT386 without needing to support two calling > > conventions.> > The "OS" uses mostly __stdcall -- callee pops -- smaller, faster.> > But anything that is varargs, such as printf -- pretty much must > > use caller pops -- __cdecl.> > As well, __cdecl is the default, so prevalent, and used in most C > > runtime functions.> > There is also __fastcall that uses like up to two registers for > > parameters.> >> > I have seen a platform in which printf did the pop, and it depended > > on the number/size of parameters matching the format string. On > > most platforms, printf("", 1, 2, 3, 4) just does nothing, but on > > that platform, it'd unbalance the stack and crash.> >> > - Jay> >> > From: jayk123 at hotmail.com> > To: hosking at cs.purdue.edu> > CC: m3devel at elegosoft.com> > Subject: next problem (NT386GNU)> > Date: Mon, 21 Jan 2008 05:47:28 +0000> >> > M3File.m3> >> > PROCEDURE IsReadable (path: TEXT): BOOLEAN => > (* We don't really check for readablitiy, just for existence *)> > BEGIN> > TRY> > EVAL FS.Status (path); line 82> > RETURN TRUE;> > EXCEPT OSError.E =>> > RETURN FALSE;> > END;> > END IsReadable;> >> > -----LINE 82 -----> > start_call_direct p.25 0 Struct> > load_address v.25 0> > pop_param Addr> > load v.26 0 Addr Addr> > pop_param Addr> > call_direct p.25 Struct> > pop Struct> >> >> >> > I'm guessing you only see an import for the first call on purpose, > > but I will compare with PPC_DARWIN:> >> > -----LINE 46 -----> > import_procedure FS__Status 2 Struct 0 p.25> > declare_indirect 2078421550 -2078421551> > declare_param _return 4 4 Addr 2078421550 F F 50 v.62> > declare_param p 4 4 Addr 1358456180 F F 50 v.63> > start_call_direct p.25 0 Struct> > load_address v.13 0> > pop_param Addr> > load v.14 0 Addr Addr> > pop_param Addr> > call_direct p.25 Struct> > pop Struct> >> >> > .globl _M3File__IsReadable> > .def _M3File__IsReadable; .scl 2; .type 32; .endef> > _M3File__IsReadable:> > .stabn 68,0,178,LM93-_M3File__IsReadable> > LM93:> > pushl %ebp> > movl %esp, %ebp> > pushl %edi> > pushl %esi> > pushl %ebx> > subl $300, %esp> > LBB15:> > .stabn 68,0,181,LM94-_M3File__IsReadable> > LM94:> > L157:> > movl -280(%ebp), %eax> > andl $0, %eax> > orl $_L_1, %eax> > movl %eax, -280(%ebp)> > movl -284(%ebp), %eax> > andl $0, %eax> > movl %eax, -284(%ebp)> > subl $12, %esp> > leal -288(%ebp), %eax> > pushl %eax> > call _RTHooks__PushEFrame> > addl $16, %esp> > leal -288(%ebp), %eax> > addl $48, %eax> > subl $12, %esp> > pushl %eax> > call __setjmp> > addl $16, %esp> > testb %al, %al> > jne L158> > .stabn 68,0,183,LM95-_M3File__IsReadable> > LM95:> > movl -288(%ebp), %eax> > subl $12, %esp> > pushl %eax> > call _RTHooks__PopEFrame> > addl $16, %esp> > movl $1, -304(%ebp)> > jmp L159> > L158:> > .stabn 68,0,185,LM96-_M3File__IsReadable> > LM96:> > movl $0, -304(%ebp)> > L159:> > LBE15:> > movl -304(%ebp), %eax> > leal -12(%ebp), %esp> > popl %ebx> > popl %esi> > popl %edi> > leave> > ret> >> >> > M3File.IsReadable's call to FS.Status is omitted, all files are > > readable, even if they are not openable, therefore it "finds" > > cm3.cfg in the current directory and then fails to open it..> >> > later..> > ..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! 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 jayk123 at hotmail.com Mon Jan 21 17:36:47 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 21 Jan 2008 16:36:47 +0000 Subject: [M3devel] broken record... Message-ID: Looking at the file names I'm about to announce are available... User could set OS_TYPE in config file or environment variable CM3_OSTYPE, to Posix or Win32, and everything else could go along.. POSIX-NT386GNU => paths all start with forward slash, Trestle is on X Windows, threads might be pthreads; WIN32-NT386GNU => paths tend toward backslashes, Trestle on Win32, threads are native, tools are GNU. Oh, and I guess people like libfoo.a, even though "lib" and ".a" seem redundant? Or don't care? - 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 Mon Jan 21 17:41:48 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 21 Jan 2008 16:41:48 +0000 Subject: [M3devel] NT386GNU distribution available Message-ID: Here, in my user directory on birch, is the first CM3 NT386GNU release.It is MinGWin based FOR NOW.This needs to be changed SOON. Install MinGWin. (Search the web for it.)set PATH=c:\MinGW\bin;%PATH% (The default install location is c:\MinGW, not MinGWin.) The MinGWin that Qt gives you is too old, from around 2004.It doesn't support "response files" (aka long command lines). If you want to rebuild m3cg: Install MSys. It is at the same place as MinGWin. set PATH=c:\msys\1.0\bin;%PATH% else consider set OMIT_GCC=yes depending on if you run the various scripts. If you install to these exact paths, scripts\python\pylib.py will use them automatically. Optionally install Python. I recommend it. Extract one or more of the archives. They will extract to like: cm3-min-WIN32-NT386GNU-d5.5.1\bin\cm3.exe You can rename it cm3, or for purposes of backup/restore, xcopy /fivery \cm3-min-WIN32-NT386GNU-d5.5.1 \cm3 (For extra good testing, first rmdir /q/s \cm3.) set PATH=c:\cm3\bin;%PATH% This is important, since various code will tend to assume NT386 unless overridden. set CM3_TARGET=NT386GNU Someone please weigh in on zip vs. tar.bz2 on the other Win32 platforms.For reference, MinGWin doesn't include tar/bzip2, MSys does, Cygwinhas tons of optional stuff, they are in there, probably the base. And then go to scripts\python and run whatever: upgrade or make-dist or do-cm3-core or do-cm3-base but not currently do-cm3-std scripts\win\upgrade works too. Do remember to set CM3_TARGET=NT386GNU. You will probably at some point be prompted to set CM3_ROOT to the root of the sourcetree as well. If you run "scripts", it will be set for you.If you cd around and run cm3, it won't. \cm3\bin\cm3.cfg delegates out to the source tree.Except the one in the distributions do not.But if you run upgrade, you'll have such a thing. If you want to rebuild cm3cg from source: cd m3-sys\m3cc\gcc\gcc\m3cg cvs update -j 1.46 -j 1.45 parse.c or thereabouts to get back enough of a __stdcall fix to build a lot. If you want to bootstrap without a previous NT386GNU distribution but with a previous NT386 build, try like this: Get a working NT386 system. Get current source (except parse.c). If your system is not current, scripts\python\upgrade This will work as far back as cm3-min-WIN32-NT386-5.1.3. scripts\python\bootntgnu which is really just roughly: do-pkg realclean m3core libm3 m3cc do-pkg buildship m3core libm3 m3cc set CM3_TARGET=NT386GNU Now you have the equivalent of the minimum distribution and can build whatever. do-pkg .... If you want to rollback a bit but not completely, scripts\win\pkggnu_clean.cmd is very simple and just deletes all the NT386GNU directories under $INSTALLROOT\pkg. There are "min", "core", and "base" distributions.Kind of subtle names, eh?"min" is sufficient.The binaries are all not "strippped". Last minute errata: There is bin\cm3.cfg and bin\NT386GNU. They are identical. The intent was only to have cm3.cfg there. The system builds itself, so that's pretty good. I forgot to include m3gdb, but it should probably be in a separate "GNU" archive? Someone move the files to a web download place? (and you can move, not copy, I can easily recreate the files) - Jay _________________________________________________________________ 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 Mon Jan 21 17:57:29 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 21 Jan 2008 11:57:29 -0500 Subject: [M3devel] gcc/eh/setjmp In-Reply-To: References: Message-ID: <0ECB2F81-C843-409C-AB24-A837EA93F083@cs.purdue.edu> Yeah, we should be able to do that. I wonder if setting DECL_NONLOCAL on barrier labels will do the trick? On Jan 21, 2008, at 11:06 AM, Jay wrote: > Any chance of giving gcc enough or the right information so that - > Wunreachable-code can be used without hitting a bunch of false > positives? It's not being dumb, not that sort of false positive. It > reports every except block and anything after a try { return } > except { } as unreachable. > > - Jay > > > > > CC: m3devel at elegosoft.com > > From: hosking at cs.purdue.edu > > Subject: Re: [M3devel] gcc/eh/setjmp > > Date: Mon, 21 Jan 2008 10:59:35 -0500 > > To: jayk123 at hotmail.com > > > > I think gcc was forced not to act on it by use of LABEL_PRESERVE_P > > and FORCED_LABEL as well as making the function containing the TRY > > non-inlinable, plus lots of other goop to let the flow analyser know > > that funky stuff was going on at labels for TRY scopes. Take a look > > at the lines of parse.c that deal with "set_label" when > "barrier=TRUE". > > > > On Jan 21, 2008, at 5:50 AM, Jay wrote: > > > > > Folks, try adding -Wunreachable-code to your m3back options and > > > tell me if you don't get loads of warnings. > > > for stuff like: > > > > > > TRY > > > return Foo(); > > > ELSE > > > return FALSE; > > > > > > I get them on NT386GNU and PPC_DARWIN. > > > > > > Functions with TRY need, in gcc parlance: > > > calls_setjmp > > > > > > and the exception/finally blocks need: > > > has_nonlocal_label > > > > > > and functions with RAISE might need: > > > has_nonlocal_goto > > > > > > Luckily, gcc doesn't seem to act on what it figure out. > > > > > > - Jay > > > > > > > > > > > > > > > > > > Helping your favorite cause is as easy as instant messaging. You > > > IM, we give. Learn more. > > > > > Shed those extra pounds with MSN and The Biggest Loser! Learn more. From hosking at cs.purdue.edu Mon Jan 21 18:01:28 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 21 Jan 2008 12:01:28 -0500 Subject: [M3devel] next problem (NT386GNU) In-Reply-To: References: <6E1E4409-F3D9-4982-B179-2D4C9648FDD0@cs.purdue.edu> Message-ID: I just need to fix m3cc/cm3cg to emit the stdcall parameter information for imported procedures. It is simply a matter of not ignoring declare_param for import_procedure chunks. This means maintaining a current_function_decl (and possibly a current_param_count) stack (since import_procedure can occur inside a declare_procedure chunk). I know what needs doing, but have not much free time right now... On Jan 21, 2008, at 11:10 AM, Jay wrote: > agreed once I thought about it > I guess that explains left to right as well. > Parameters are always left to right from a higher level point of > view, and if that is wrong, the compiler will reorder. > > "everything" works now > > - Jay > > > > > CC: m3devel at elegosoft.com > > From: hosking at cs.purdue.edu > > Subject: Re: next problem (NT386GNU) > > Date: Mon, 21 Jan 2008 10:54:10 -0500 > > To: jayk123 at hotmail.com > > > > Surely, when using the gcc-based backend then we should make the > > backend handle it. The front end handling it is only need for the > > integrated x86 backend. > > > > On Jan 21, 2008, at 2:43 AM, Jay wrote: > > > > > I haven't tested a fix but I see the problem. > > > > > > This function returns a struct. > > > There are two struct returning calling conventions. > > > In one, the backend handles it. Which includes the backend knowing > > > there is a return value and its type (or at least its size?). > > > In the other, the front end handles it. In this case, the front > end > > > generates passing an extra pointer parameter to the function, and > > > the function's return type is void. > > > > > > The NT calling conventions, all of them, are marked as front end > > > handling it. I assume that is correct, could check. > > > Everything else is marked as back end handling. > > > > > > Now then, somewhere along the line, gcc figures out that the > return > > > value isn't used here. > > > The point of the function call is to see if it generates an > exception. > > > > > > Gcc removes the function because its return value isn't used, and, > > > well, somehow it doesn't know about the exceptions here. I'll have > > > to see how "raise" is implemented. I think it's by a call to a > > > function that gets the jmpbuf from a thread local and calls > > > longjmp. (Did I mention it is very inefficient?) > > > > > > There are few possible fixes, but nothing completely satisfactory > > > yet in mind. > > > > > > One is have parse.c mark all function calls as having side > affects. > > > This is easy, but overly pessimistic. > > > Another is for the front end to mark struct returning functions as > > > having side affects. Better, but still overly pessimistic. > > > Another is for the front end to mark any function that can > raise as > > > having side affects. Getting better still. I don't know how to do > > > that but I'll look. This is still a bit overly pessimistic, since > > > what you really want to know is, not the function's side affects, > > > but whether or not it raised. If the function is inlined, the side > > > affects could be optimized away, or if there are enough callers > who > > > don't care about the side affects to warrant an optimization, and > > > depending on the cost of computing the side affects, another > > > instance of the function could be made that only raises or not, > but > > > no side affects otherwise. This is "advanced" optimization the > sort > > > of which tends never to be implemented. > > > > > > I think the best option is anything that can raise is marked as > > > having side affects. > > > I'll see if I can figure that out. > > > > > > You can figure this out by looking at m3cgcat -binary < > M3File.mc > > > > 1.txt on PPC_DARWIN and NT386GNU and comparing. > > > > > > Maybe marking all or nearly functions as having side effects isn't > > > so bad. > > > Or at least anything returning a struct. That gets parity with > > > other platforms, even if it is a bit pessimistic. > > > I think I'll do that, and ignore figuring out if raise is called > > > and using that as a filter. > > > The parity angle is good. > > > > > > The good news for all you Unix lovers :) is this bug is relatively > > > portable to Cygwin. > > > True, it is specific to NT386GNU having multiple "calling > > > conventions", which no other platform has. > > > Which again, jokingly, strikes at the question -- What is Posix? > > > What do you want from Cygwin? > > > One thing Cygwin does NOT give you is just one calling convention, > > > alas, this calling convention business stinks. It's not even an NT > > > thing, only an NT386 thing. All the other NT platforms had/have > > > only one calling convention. > > > > > > You can't get far on NT386 without needing to support two calling > > > conventions. > > > The "OS" uses mostly __stdcall -- callee pops -- smaller, faster. > > > But anything that is varargs, such as printf -- pretty much must > > > use caller pops -- __cdecl. > > > As well, __cdecl is the default, so prevalent, and used in most C > > > runtime functions. > > > There is also __fastcall that uses like up to two registers for > > > parameters. > > > > > > I have seen a platform in which printf did the pop, and it > depended > > > on the number/size of parameters matching the format string. On > > > most platforms, printf("", 1, 2, 3, 4) just does nothing, but on > > > that platform, it'd unbalance the stack and crash. > > > > > > - Jay > > > > > > From: jayk123 at hotmail.com > > > To: hosking at cs.purdue.edu > > > CC: m3devel at elegosoft.com > > > Subject: next problem (NT386GNU) > > > Date: Mon, 21 Jan 2008 05:47:28 +0000 > > > > > > M3File.m3 > > > > > > PROCEDURE IsReadable (path: TEXT): BOOLEAN = > > > (* We don't really check for readablitiy, just for existence *) > > > BEGIN > > > TRY > > > EVAL FS.Status (path); line 82 > > > RETURN TRUE; > > > EXCEPT OSError.E => > > > RETURN FALSE; > > > END; > > > END IsReadable; > > > > > > -----LINE 82 ----- > > > start_call_direct p.25 0 Struct > > > load_address v.25 0 > > > pop_param Addr > > > load v.26 0 Addr Addr > > > pop_param Addr > > > call_direct p.25 Struct > > > pop Struct > > > > > > > > > > > > I'm guessing you only see an import for the first call on purpose, > > > but I will compare with PPC_DARWIN: > > > > > > -----LINE 46 ----- > > > import_procedure FS__Status 2 Struct 0 p.25 > > > declare_indirect 2078421550 -2078421551 > > > declare_param _return 4 4 Addr 2078421550 F F 50 v.62 > > > declare_param p 4 4 Addr 1358456180 F F 50 v.63 > > > start_call_direct p.25 0 Struct > > > load_address v.13 0 > > > pop_param Addr > > > load v.14 0 Addr Addr > > > pop_param Addr > > > call_direct p.25 Struct > > > pop Struct > > > > > > > > > .globl _M3File__IsReadable > > > .def _M3File__IsReadable; .scl 2; .type 32; .endef > > > _M3File__IsReadable: > > > .stabn 68,0,178,LM93-_M3File__IsReadable > > > LM93: > > > pushl %ebp > > > movl %esp, %ebp > > > pushl %edi > > > pushl %esi > > > pushl %ebx > > > subl $300, %esp > > > LBB15: > > > .stabn 68,0,181,LM94-_M3File__IsReadable > > > LM94: > > > L157: > > > movl -280(%ebp), %eax > > > andl $0, %eax > > > orl $_L_1, %eax > > > movl %eax, -280(%ebp) > > > movl -284(%ebp), %eax > > > andl $0, %eax > > > movl %eax, -284(%ebp) > > > subl $12, %esp > > > leal -288(%ebp), %eax > > > pushl %eax > > > call _RTHooks__PushEFrame > > > addl $16, %esp > > > leal -288(%ebp), %eax > > > addl $48, %eax > > > subl $12, %esp > > > pushl %eax > > > call __setjmp > > > addl $16, %esp > > > testb %al, %al > > > jne L158 > > > .stabn 68,0,183,LM95-_M3File__IsReadable > > > LM95: > > > movl -288(%ebp), %eax > > > subl $12, %esp > > > pushl %eax > > > call _RTHooks__PopEFrame > > > addl $16, %esp > > > movl $1, -304(%ebp) > > > jmp L159 > > > L158: > > > .stabn 68,0,185,LM96-_M3File__IsReadable > > > LM96: > > > movl $0, -304(%ebp) > > > L159: > > > LBE15: > > > movl -304(%ebp), %eax > > > leal -12(%ebp), %esp > > > popl %ebx > > > popl %esi > > > popl %edi > > > leave > > > ret > > > > > > > > > M3File.IsReadable's call to FS.Status is omitted, all files are > > > readable, even if they are not openable, therefore it "finds" > > > cm3.cfg in the current directory and then fails to open it.. > > > > > > later.. > > > ..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! Learn > more. > > > > > Shed those extra pounds with MSN and The Biggest Loser! Learn more. From hosking at cs.purdue.edu Mon Jan 21 18:02:12 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 21 Jan 2008 12:02:12 -0500 Subject: [M3devel] broken record... In-Reply-To: References: Message-ID: <659E4F4F-3A52-4269-9F4F-790613E14530@cs.purdue.edu> On Jan 21, 2008, at 11:36 AM, Jay wrote: > Looking at the file names I'm about to announce are available... > > User could set OS_TYPE in config file or environment variable > CM3_OSTYPE, to Posix or Win32, and everything else could go along.. > POSIX-NT386GNU => paths all start with forward slash, Trestle is on > X Windows, threads might be pthreads; WIN32-NT386GNU => paths tend > toward backslashes, Trestle on Win32, threads are native, tools are > GNU. > > Oh, and I guess people like libfoo.a, even though "lib" and ".a" > seem redundant? Don't care really. Standard on Unix is lib*.a. > > Or don't care? > > - Jay > > > > > > Climb to the top of the charts! Play the word scramble challenge > with star power. Play now! From jayk123 at hotmail.com Mon Jan 21 23:16:54 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 21 Jan 2008 22:16:54 +0000 Subject: [M3devel] next problem (NT386GNU) In-Reply-To: References: <6E1E4409-F3D9-4982-B179-2D4C9648FDD0@cs.purdue.edu> Message-ID: Understood. Put back my parse.c in the meantime? Also, the front end could do this, right? And probably without a stack? It could compute "effective parameter size" and pass that down. Backend could then divide by 4 and claim that is the signature, that number of parameters. Would have to see how passing a struct works out anyway -- one parameter or one per field. - Jay > CC: m3devel at elegosoft.com > From: hosking at cs.purdue.edu > Subject: Re: next problem (NT386GNU) > Date: Mon, 21 Jan 2008 12:01:28 -0500 > To: jayk123 at hotmail.com > > I just need to fix m3cc/cm3cg to emit the stdcall parameter > information for imported procedures. It is simply a matter of not > ignoring declare_param for import_procedure chunks. This means > maintaining a current_function_decl (and possibly a > current_param_count) stack (since import_procedure can occur inside a > declare_procedure chunk). I know what needs doing, but have not much > free time right now... > > On Jan 21, 2008, at 11:10 AM, Jay wrote: > > > agreed once I thought about it > > I guess that explains left to right as well. > > Parameters are always left to right from a higher level point of > > view, and if that is wrong, the compiler will reorder. > > > > "everything" works now > > > > - Jay > > > > > > > > > CC: m3devel at elegosoft.com > > > From: hosking at cs.purdue.edu > > > Subject: Re: next problem (NT386GNU) > > > Date: Mon, 21 Jan 2008 10:54:10 -0500 > > > To: jayk123 at hotmail.com > > > > > > Surely, when using the gcc-based backend then we should make the > > > backend handle it. The front end handling it is only need for the > > > integrated x86 backend. > > > > > > On Jan 21, 2008, at 2:43 AM, Jay wrote: > > > > > > > I haven't tested a fix but I see the problem. > > > > > > > > This function returns a struct. > > > > There are two struct returning calling conventions. > > > > In one, the backend handles it. Which includes the backend knowing > > > > there is a return value and its type (or at least its size?). > > > > In the other, the front end handles it. In this case, the front > > end > > > > generates passing an extra pointer parameter to the function, and > > > > the function's return type is void. > > > > > > > > The NT calling conventions, all of them, are marked as front end > > > > handling it. I assume that is correct, could check. > > > > Everything else is marked as back end handling. > > > > > > > > Now then, somewhere along the line, gcc figures out that the > > return > > > > value isn't used here. > > > > The point of the function call is to see if it generates an > > exception. > > > > > > > > Gcc removes the function because its return value isn't used, and, > > > > well, somehow it doesn't know about the exceptions here. I'll have > > > > to see how "raise" is implemented. I think it's by a call to a > > > > function that gets the jmpbuf from a thread local and calls > > > > longjmp. (Did I mention it is very inefficient?) > > > > > > > > There are few possible fixes, but nothing completely satisfactory > > > > yet in mind. > > > > > > > > One is have parse.c mark all function calls as having side > > affects. > > > > This is easy, but overly pessimistic. > > > > Another is for the front end to mark struct returning functions as > > > > having side affects. Better, but still overly pessimistic. > > > > Another is for the front end to mark any function that can > > raise as > > > > having side affects. Getting better still. I don't know how to do > > > > that but I'll look. This is still a bit overly pessimistic, since > > > > what you really want to know is, not the function's side affects, > > > > but whether or not it raised. If the function is inlined, the side > > > > affects could be optimized away, or if there are enough callers > > who > > > > don't care about the side affects to warrant an optimization, and > > > > depending on the cost of computing the side affects, another > > > > instance of the function could be made that only raises or not, > > but > > > > no side affects otherwise. This is "advanced" optimization the > > sort > > > > of which tends never to be implemented. > > > > > > > > I think the best option is anything that can raise is marked as > > > > having side affects. > > > > I'll see if I can figure that out. > > > > > > > > You can figure this out by looking at m3cgcat -binary < > > M3File.mc > > > > > 1.txt on PPC_DARWIN and NT386GNU and comparing. > > > > > > > > Maybe marking all or nearly functions as having side effects isn't > > > > so bad. > > > > Or at least anything returning a struct. That gets parity with > > > > other platforms, even if it is a bit pessimistic. > > > > I think I'll do that, and ignore figuring out if raise is called > > > > and using that as a filter. > > > > The parity angle is good. > > > > > > > > The good news for all you Unix lovers :) is this bug is relatively > > > > portable to Cygwin. > > > > True, it is specific to NT386GNU having multiple "calling > > > > conventions", which no other platform has. > > > > Which again, jokingly, strikes at the question -- What is Posix? > > > > What do you want from Cygwin? > > > > One thing Cygwin does NOT give you is just one calling convention, > > > > alas, this calling convention business stinks. It's not even an NT > > > > thing, only an NT386 thing. All the other NT platforms had/have > > > > only one calling convention. > > > > > > > > You can't get far on NT386 without needing to support two calling > > > > conventions. > > > > The "OS" uses mostly __stdcall -- callee pops -- smaller, faster. > > > > But anything that is varargs, such as printf -- pretty much must > > > > use caller pops -- __cdecl. > > > > As well, __cdecl is the default, so prevalent, and used in most C > > > > runtime functions. > > > > There is also __fastcall that uses like up to two registers for > > > > parameters. > > > > > > > > I have seen a platform in which printf did the pop, and it > > depended > > > > on the number/size of parameters matching the format string. On > > > > most platforms, printf("", 1, 2, 3, 4) just does nothing, but on > > > > that platform, it'd unbalance the stack and crash. > > > > > > > > - Jay > > > > > > > > From: jayk123 at hotmail.com > > > > To: hosking at cs.purdue.edu > > > > CC: m3devel at elegosoft.com > > > > Subject: next problem (NT386GNU) > > > > Date: Mon, 21 Jan 2008 05:47:28 +0000 > > > > > > > > M3File.m3 > > > > > > > > PROCEDURE IsReadable (path: TEXT): BOOLEAN = > > > > (* We don't really check for readablitiy, just for existence *) > > > > BEGIN > > > > TRY > > > > EVAL FS.Status (path); line 82 > > > > RETURN TRUE; > > > > EXCEPT OSError.E => > > > > RETURN FALSE; > > > > END; > > > > END IsReadable; > > > > > > > > -----LINE 82 ----- > > > > start_call_direct p.25 0 Struct > > > > load_address v.25 0 > > > > pop_param Addr > > > > load v.26 0 Addr Addr > > > > pop_param Addr > > > > call_direct p.25 Struct > > > > pop Struct > > > > > > > > > > > > > > > > I'm guessing you only see an import for the first call on purpose, > > > > but I will compare with PPC_DARWIN: > > > > > > > > -----LINE 46 ----- > > > > import_procedure FS__Status 2 Struct 0 p.25 > > > > declare_indirect 2078421550 -2078421551 > > > > declare_param _return 4 4 Addr 2078421550 F F 50 v.62 > > > > declare_param p 4 4 Addr 1358456180 F F 50 v.63 > > > > start_call_direct p.25 0 Struct > > > > load_address v.13 0 > > > > pop_param Addr > > > > load v.14 0 Addr Addr > > > > pop_param Addr > > > > call_direct p.25 Struct > > > > pop Struct > > > > > > > > > > > > .globl _M3File__IsReadable > > > > .def _M3File__IsReadable; .scl 2; .type 32; .endef > > > > _M3File__IsReadable: > > > > .stabn 68,0,178,LM93-_M3File__IsReadable > > > > LM93: > > > > pushl %ebp > > > > movl %esp, %ebp > > > > pushl %edi > > > > pushl %esi > > > > pushl %ebx > > > > subl $300, %esp > > > > LBB15: > > > > .stabn 68,0,181,LM94-_M3File__IsReadable > > > > LM94: > > > > L157: > > > > movl -280(%ebp), %eax > > > > andl $0, %eax > > > > orl $_L_1, %eax > > > > movl %eax, -280(%ebp) > > > > movl -284(%ebp), %eax > > > > andl $0, %eax > > > > movl %eax, -284(%ebp) > > > > subl $12, %esp > > > > leal -288(%ebp), %eax > > > > pushl %eax > > > > call _RTHooks__PushEFrame > > > > addl $16, %esp > > > > leal -288(%ebp), %eax > > > > addl $48, %eax > > > > subl $12, %esp > > > > pushl %eax > > > > call __setjmp > > > > addl $16, %esp > > > > testb %al, %al > > > > jne L158 > > > > .stabn 68,0,183,LM95-_M3File__IsReadable > > > > LM95: > > > > movl -288(%ebp), %eax > > > > subl $12, %esp > > > > pushl %eax > > > > call _RTHooks__PopEFrame > > > > addl $16, %esp > > > > movl $1, -304(%ebp) > > > > jmp L159 > > > > L158: > > > > .stabn 68,0,185,LM96-_M3File__IsReadable > > > > LM96: > > > > movl $0, -304(%ebp) > > > > L159: > > > > LBE15: > > > > movl -304(%ebp), %eax > > > > leal -12(%ebp), %esp > > > > popl %ebx > > > > popl %esi > > > > popl %edi > > > > leave > > > > ret > > > > > > > > > > > > M3File.IsReadable's call to FS.Status is omitted, all files are > > > > readable, even if they are not openable, therefore it "finds" > > > > cm3.cfg in the current directory and then fails to open it.. > > > > > > > > later.. > > > > ..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! Learn > > more. > > > > > > > > > Shed those extra pounds with MSN and The Biggest Loser! Learn more. > _________________________________________________________________ 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 Jan 21 23:32:32 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 21 Jan 2008 17:32:32 -0500 Subject: [M3devel] next problem (NT386GNU) In-Reply-To: References: <6E1E4409-F3D9-4982-B179-2D4C9648FDD0@cs.purdue.edu> Message-ID: <1A6EC7D6-32B2-44AD-933F-6976040A7D7F@cs.purdue.edu> I'd prefer to have the backend do it properly based on properly declared types. I'd prefer to keep this code out of the current mainline of parse.c -- you could fork a temporary branch if necessary. On Jan 21, 2008, at 5:16 PM, Jay wrote: > Understood. Put back my parse.c in the meantime? > > Also, the front end could do this, right? And probably without a > stack? > It could compute "effective parameter size" and pass that down. > Backend could then divide by 4 and claim that is the signature, > that number of parameters. > > Would have to see how passing a struct works out anyway -- one > parameter > or one per field. > > - Jay > > > > CC: m3devel at elegosoft.com > > From: hosking at cs.purdue.edu > > Subject: Re: next problem (NT386GNU) > > Date: Mon, 21 Jan 2008 12:01:28 -0500 > > To: jayk123 at hotmail.com > > > > I just need to fix m3cc/cm3cg to emit the stdcall parameter > > information for imported procedures. It is simply a matter of not > > ignoring declare_param for import_procedure chunks. This means > > maintaining a current_function_decl (and possibly a > > current_param_count) stack (since import_procedure can occur > inside a > > declare_procedure chunk). I know what needs doing, but have not much > > free time right now... > > > > On Jan 21, 2008, at 11:10 AM, Jay wrote: > > > > > agreed once I thought about it > > > I guess that explains left to right as well. > > > Parameters are always left to right from a higher level point of > > > view, and if that is wrong, the compiler will reorder. > > > > > > "everything" works now > > > > > > - Jay > > > > > > > > > > > > > CC: m3devel at elegosoft.com > > > > From: hosking at cs.purdue.edu > > > > Subject: Re: next problem (NT386GNU) > > > > Date: Mon, 21 Jan 2008 10:54:10 -0500 > > > > To: jayk123 at hotmail.com > > > > > > > > Surely, when using the gcc-based backend then we should make the > > > > backend handle it. The front end handling it is only need for > the > > > > integrated x86 backend. > > > > > > > > On Jan 21, 2008, at 2:43 AM, Jay wrote: > > > > > > > > > I haven't tested a fix but I see the problem. > > > > > > > > > > This function returns a struct. > > > > > There are two struct returning calling conventions. > > > > > In one, the backend handles it. Which includes the backend > knowing > > > > > there is a return value and its type (or at least its size?). > > > > > In the other, the front end handles it. In this case, the > front > > > end > > > > > generates passing an extra pointer parameter to the > function, and > > > > > the function's return type is void. > > > > > > > > > > The NT calling conventions, all of them, are marked as > front end > > > > > handling it. I assume that is correct, could check. > > > > > Everything else is marked as back end handling. > > > > > > > > > > Now then, somewhere along the line, gcc figures out that the > > > return > > > > > value isn't used here. > > > > > The point of the function call is to see if it generates an > > > exception. > > > > > > > > > > Gcc removes the function because its return value isn't > used, and, > > > > > well, somehow it doesn't know about the exceptions here. > I'll have > > > > > to see how "raise" is implemented. I think it's by a call to a > > > > > function that gets the jmpbuf from a thread local and calls > > > > > longjmp. (Did I mention it is very inefficient?) > > > > > > > > > > There are few possible fixes, but nothing completely > satisfactory > > > > > yet in mind. > > > > > > > > > > One is have parse.c mark all function calls as having side > > > affects. > > > > > This is easy, but overly pessimistic. > > > > > Another is for the front end to mark struct returning > functions as > > > > > having side affects. Better, but still overly pessimistic. > > > > > Another is for the front end to mark any function that can > > > raise as > > > > > having side affects. Getting better still. I don't know how > to do > > > > > that but I'll look. This is still a bit overly pessimistic, > since > > > > > what you really want to know is, not the function's side > affects, > > > > > but whether or not it raised. If the function is inlined, > the side > > > > > affects could be optimized away, or if there are enough > callers > > > who > > > > > don't care about the side affects to warrant an > optimization, and > > > > > depending on the cost of computing the side affects, another > > > > > instance of the function could be made that only raises or > not, > > > but > > > > > no side affects otherwise. This is "advanced" optimization the > > > sort > > > > > of which tends never to be implemented. > > > > > > > > > > I think the best option is anything that can raise is > marked as > > > > > having side affects. > > > > > I'll see if I can figure that out. > > > > > > > > > > You can figure this out by looking at m3cgcat -binary < > > > M3File.mc > > > > > > 1.txt on PPC_DARWIN and NT386GNU and comparing. > > > > > > > > > > Maybe marking all or nearly functions as having side > effects isn't > > > > > so bad. > > > > > Or at least anything returning a struct. That gets parity with > > > > > other platforms, even if it is a bit pessimistic. > > > > > I think I'll do that, and ignore figuring out if raise is > called > > > > > and using that as a filter. > > > > > The parity angle is good. > > > > > > > > > > The good news for all you Unix lovers :) is this bug is > relatively > > > > > portable to Cygwin. > > > > > True, it is specific to NT386GNU having multiple "calling > > > > > conventions", which no other platform has. > > > > > Which again, jokingly, strikes at the question -- What is > Posix? > > > > > What do you want from Cygwin? > > > > > One thing Cygwin does NOT give you is just one calling > convention, > > > > > alas, this calling convention business stinks. It's not > even an NT > > > > > thing, only an NT386 thing. All the other NT platforms had/ > have > > > > > only one calling convention. > > > > > > > > > > You can't get far on NT386 without needing to support two > calling > > > > > conventions. > > > > > The "OS" uses mostly __stdcall -- callee pops -- smaller, > faster. > > > > > But anything that is varargs, such as printf -- pretty much > must > > > > > use caller pops -- __cdecl. > > > > > As well, __cdecl is the default, so prevalent, and used in > most C > > > > > runtime functions. > > > > > There is also __fastcall that uses like up to two registers > for > > > > > parameters. > > > > > > > > > > I have seen a platform in which printf did the pop, and it > > > depended > > > > > on the number/size of parameters matching the format > string. On > > > > > most platforms, printf("", 1, 2, 3, 4) just does nothing, > but on > > > > > that platform, it'd unbalance the stack and crash. > > > > > > > > > > - Jay > > > > > > > > > > From: jayk123 at hotmail.com > > > > > To: hosking at cs.purdue.edu > > > > > CC: m3devel at elegosoft.com > > > > > Subject: next problem (NT386GNU) > > > > > Date: Mon, 21 Jan 2008 05:47:28 +0000 > > > > > > > > > > M3File.m3 > > > > > > > > > > PROCEDURE IsReadable (path: TEXT): BOOLEAN = > > > > > (* We don't really check for readablitiy, just for > existence *) > > > > > BEGIN > > > > > TRY > > > > > EVAL FS.Status (path); line 82 > > > > > RETURN TRUE; > > > > > EXCEPT OSError.E => > > > > > RETURN FALSE; > > > > > END; > > > > > END IsReadable; > > > > > > > > > > -----LINE 82 ----- > > > > > start_call_direct p.25 0 Struct > > > > > load_address v.25 0 > > > > > pop_param Addr > > > > > load v.26 0 Addr Addr > > > > > pop_param Addr > > > > > call_direct p.25 Struct > > > > > pop Struct > > > > > > > > > > > > > > > > > > > > I'm guessing you only see an import for the first call on > purpose, > > > > > but I will compare with PPC_DARWIN: > > > > > > > > > > -----LINE 46 ----- > > > > > import_procedure FS__Status 2 Struct 0 p.25 > > > > > declare_indirect 2078421550 -2078421551 > > > > > declare_param _return 4 4 Addr 2078421550 F F 50 v.62 > > > > > declare_param p 4 4 Addr 1358456180 F F 50 v.63 > > > > > start_call_direct p.25 0 Struct > > > > > load_address v.13 0 > > > > > pop_param Addr > > > > > load v.14 0 Addr Addr > > > > > pop_param Addr > > > > > call_direct p.25 Struct > > > > > pop Struct > > > > > > > > > > > > > > > .globl _M3File__IsReadable > > > > > .def _M3File__IsReadable; .scl 2; .type 32; .endef > > > > > _M3File__IsReadable: > > > > > .stabn 68,0,178,LM93-_M3File__IsReadable > > > > > LM93: > > > > > pushl %ebp > > > > > movl %esp, %ebp > > > > > pushl %edi > > > > > pushl %esi > > > > > pushl %ebx > > > > > subl $300, %esp > > > > > LBB15: > > > > > .stabn 68,0,181,LM94-_M3File__IsReadable > > > > > LM94: > > > > > L157: > > > > > movl -280(%ebp), %eax > > > > > andl $0, %eax > > > > > orl $_L_1, %eax > > > > > movl %eax, -280(%ebp) > > > > > movl -284(%ebp), %eax > > > > > andl $0, %eax > > > > > movl %eax, -284(%ebp) > > > > > subl $12, %esp > > > > > leal -288(%ebp), %eax > > > > > pushl %eax > > > > > call _RTHooks__PushEFrame > > > > > addl $16, %esp > > > > > leal -288(%ebp), %eax > > > > > addl $48, %eax > > > > > subl $12, %esp > > > > > pushl %eax > > > > > call __setjmp > > > > > addl $16, %esp > > > > > testb %al, %al > > > > > jne L158 > > > > > .stabn 68,0,183,LM95-_M3File__IsReadable > > > > > LM95: > > > > > movl -288(%ebp), %eax > > > > > subl $12, %esp > > > > > pushl %eax > > > > > call _RTHooks__PopEFrame > > > > > addl $16, %esp > > > > > movl $1, -304(%ebp) > > > > > jmp L159 > > > > > L158: > > > > > .stabn 68,0,185,LM96-_M3File__IsReadable > > > > > LM96: > > > > > movl $0, -304(%ebp) > > > > > L159: > > > > > LBE15: > > > > > movl -304(%ebp), %eax > > > > > leal -12(%ebp), %esp > > > > > popl %ebx > > > > > popl %esi > > > > > popl %edi > > > > > leave > > > > > ret > > > > > > > > > > > > > > > M3File.IsReadable's call to FS.Status is omitted, all files > are > > > > > readable, even if they are not openable, therefore it "finds" > > > > > cm3.cfg in the current directory and then fails to open it.. > > > > > > > > > > later.. > > > > > ..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! Learn > > > more. > > > > > > > > > > > > > Shed those extra pounds with MSN and The Biggest Loser! Learn > more. > > > > Climb to the top of the charts! Play the word scramble challenge > with star power. Play now! From jayk123 at hotmail.com Tue Jan 22 00:01:44 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 21 Jan 2008 23:01:44 +0000 Subject: [M3devel] platform/build_dir is a big tuple? Message-ID: I just realized... As I said, there are several variables. "platform" is a big tuple architecture -- x86, ppc, sparc OS -- NT, Linux, Darwin, Solaris ostype -- win32, posix This probably not -- embodied instead by C runtime and threading model C compiler -- Visual C++, gcc, Sun, Watcom, DigitalMars, Metrowerks and version thereof Linker -- Visual C++, gcc/ld, C runtime -- msvc*, linuxlibc6, cygwin (newline) executable format -- aout, elf, pe (witness the three Linux x86 targets; yes, I know aout is dead and the elf target probably also) oh..maybe object file format -- coff, elf, mach-o Threading model -- vtalarm, pthreads, Win32 backend -- integrated, gcc, C generating Windows library -- X Windows, Windows naming convention -- Unix/Posix, Windows, grumpy Unix Many combinations make sense and work -- two threading models on most systems. Many combinations do not -- Win32 threads on most. Maybe call this "native" threads. Many combinations interoperate -- gcc and Visual C++ output the same .obj file format But you don't want to mix jmpbuf size with the wrong C runtime Naming conventions are sometimes arbitrary, sometimes not, depending on if the linker is given precise paths or like on Mac it probes (is that how a bunch work?). Each variable could contribute a little bit to BUILD_DIR OS -- n, l, d, s This would probably come first and be spelled out. NT, Linux, Solaris architecture -- x, p, s, mi (mips), a (alpha), m6 (m68k or just 6), a (amd64) This might be longer too -- x86, PPC, SPARC C compiler -- ms6, ms7,ms71, ms8, g2, g3, g4, mw6, mw7, mw8, w Linker -- g, m C runtime -- m, g (glibc), c Executable format -- a, e, p (or w for Windows), m (mach-o), pef obj format -- c, e, m threading model -- v, p, w; or v and n (native) backend -- i, g, c Windowing library -- x, w naming convention -- u or p, m (Microsoft) or w (windows), g Ok, I know, crazy, unwieldy, crazy long directory names, but somehow seems true. Imagine there was an "integrated linker". It could consume at least three different obj formats and output at least three different executable formats (elf, pe/coff, mach-o). A smaller version of this however is to let the user set OSTYPE and NAMING_CONVENTION, and perhaps a few other variables (Windowing library is one obviously missing), in the config, honor them, and possibly build up BUILD_DIR in this way. Several variables can be omited..well mainly obj format. That seems to vary the least or vary along with compiler/linker. - 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 Jan 22 00:06:41 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 21 Jan 2008 23:06:41 +0000 Subject: [M3devel] next problem (NT386GNU) In-Reply-To: <1A6EC7D6-32B2-44AD-933F-6976040A7D7F@cs.purdue.edu> References: <6E1E4409-F3D9-4982-B179-2D4C9648FDD0@cs.purdue.edu> <1A6EC7D6-32B2-44AD-933F-6976040A7D7F@cs.purdue.edu> Message-ID: I don't want to deal with learning about CVS branches, please. I can try the __cdecl thunk hack I had nearly working, over in m3-win\import-libs. It's lame compared to my parse.c though. Given void __stdcall Foo(int a, struct {int a, b}), or rather Foo 12, it would generate one source file/.obj void __stdcall F(int a, int b, int c); void __stdcall Fstdcall(int a, int b, int c) { return Fstdcall(a b c); } another source file/.obj void __stdcall Fstdcall(int a, int b, int c); void __cdecl F(int a, int b, int c) { return Fstdcall(a b c); } If I could put parse.c back, I could limit this to functions that take structs. Or at least one function in particular that I know is a current problem. Limiting this hack would be good. - Jay > CC: m3devel at elegosoft.com > From: hosking at cs.purdue.edu > Subject: Re: next problem (NT386GNU) > Date: Mon, 21 Jan 2008 17:32:32 -0500 > To: jayk123 at hotmail.com > > I'd prefer to have the backend do it properly based on properly > declared types. I'd prefer to keep this code out of the current > mainline of parse.c -- you could fork a temporary branch if necessary. > > On Jan 21, 2008, at 5:16 PM, Jay wrote: > > > Understood. Put back my parse.c in the meantime? > > > > Also, the front end could do this, right? And probably without a > > stack? > > It could compute "effective parameter size" and pass that down. > > Backend could then divide by 4 and claim that is the signature, > > that number of parameters. > > > > Would have to see how passing a struct works out anyway -- one > > parameter > > or one per field. > > > > - Jay > > > > > > > CC: m3devel at elegosoft.com > > > From: hosking at cs.purdue.edu > > > Subject: Re: next problem (NT386GNU) > > > Date: Mon, 21 Jan 2008 12:01:28 -0500 > > > To: jayk123 at hotmail.com > > > > > > I just need to fix m3cc/cm3cg to emit the stdcall parameter > > > information for imported procedures. It is simply a matter of not > > > ignoring declare_param for import_procedure chunks. This means > > > maintaining a current_function_decl (and possibly a > > > current_param_count) stack (since import_procedure can occur > > inside a > > > declare_procedure chunk). I know what needs doing, but have not much > > > free time right now... > > > > > > On Jan 21, 2008, at 11:10 AM, Jay wrote: > > > > > > > agreed once I thought about it > > > > I guess that explains left to right as well. > > > > Parameters are always left to right from a higher level point of > > > > view, and if that is wrong, the compiler will reorder. > > > > > > > > "everything" works now > > > > > > > > - Jay > > > > > > > > > > > > > > > > > CC: m3devel at elegosoft.com > > > > > From: hosking at cs.purdue.edu > > > > > Subject: Re: next problem (NT386GNU) > > > > > Date: Mon, 21 Jan 2008 10:54:10 -0500 > > > > > To: jayk123 at hotmail.com > > > > > > > > > > Surely, when using the gcc-based backend then we should make the > > > > > backend handle it. The front end handling it is only need for > > the > > > > > integrated x86 backend. > > > > > > > > > > On Jan 21, 2008, at 2:43 AM, Jay wrote: > > > > > > > > > > > I haven't tested a fix but I see the problem. > > > > > > > > > > > > This function returns a struct. > > > > > > There are two struct returning calling conventions. > > > > > > In one, the backend handles it. Which includes the backend > > knowing > > > > > > there is a return value and its type (or at least its size?). > > > > > > In the other, the front end handles it. In this case, the > > front > > > > end > > > > > > generates passing an extra pointer parameter to the > > function, and > > > > > > the function's return type is void. > > > > > > > > > > > > The NT calling conventions, all of them, are marked as > > front end > > > > > > handling it. I assume that is correct, could check. > > > > > > Everything else is marked as back end handling. > > > > > > > > > > > > Now then, somewhere along the line, gcc figures out that the > > > > return > > > > > > value isn't used here. > > > > > > The point of the function call is to see if it generates an > > > > exception. > > > > > > > > > > > > Gcc removes the function because its return value isn't > > used, and, > > > > > > well, somehow it doesn't know about the exceptions here. > > I'll have > > > > > > to see how "raise" is implemented. I think it's by a call to a > > > > > > function that gets the jmpbuf from a thread local and calls > > > > > > longjmp. (Did I mention it is very inefficient?) > > > > > > > > > > > > There are few possible fixes, but nothing completely > > satisfactory > > > > > > yet in mind. > > > > > > > > > > > > One is have parse.c mark all function calls as having side > > > > affects. > > > > > > This is easy, but overly pessimistic. > > > > > > Another is for the front end to mark struct returning > > functions as > > > > > > having side affects. Better, but still overly pessimistic. > > > > > > Another is for the front end to mark any function that can > > > > raise as > > > > > > having side affects. Getting better still. I don't know how > > to do > > > > > > that but I'll look. This is still a bit overly pessimistic, > > since > > > > > > what you really want to know is, not the function's side > > affects, > > > > > > but whether or not it raised. If the function is inlined, > > the side > > > > > > affects could be optimized away, or if there are enough > > callers > > > > who > > > > > > don't care about the side affects to warrant an > > optimization, and > > > > > > depending on the cost of computing the side affects, another > > > > > > instance of the function could be made that only raises or > > not, > > > > but > > > > > > no side affects otherwise. This is "advanced" optimization the > > > > sort > > > > > > of which tends never to be implemented. > > > > > > > > > > > > I think the best option is anything that can raise is > > marked as > > > > > > having side affects. > > > > > > I'll see if I can figure that out. > > > > > > > > > > > > You can figure this out by looking at m3cgcat -binary < > > > > M3File.mc > > > > > > > 1.txt on PPC_DARWIN and NT386GNU and comparing. > > > > > > > > > > > > Maybe marking all or nearly functions as having side > > effects isn't > > > > > > so bad. > > > > > > Or at least anything returning a struct. That gets parity with > > > > > > other platforms, even if it is a bit pessimistic. > > > > > > I think I'll do that, and ignore figuring out if raise is > > called > > > > > > and using that as a filter. > > > > > > The parity angle is good. > > > > > > > > > > > > The good news for all you Unix lovers :) is this bug is > > relatively > > > > > > portable to Cygwin. > > > > > > True, it is specific to NT386GNU having multiple "calling > > > > > > conventions", which no other platform has. > > > > > > Which again, jokingly, strikes at the question -- What is > > Posix? > > > > > > What do you want from Cygwin? > > > > > > One thing Cygwin does NOT give you is just one calling > > convention, > > > > > > alas, this calling convention business stinks. It's not > > even an NT > > > > > > thing, only an NT386 thing. All the other NT platforms had/ > > have > > > > > > only one calling convention. > > > > > > > > > > > > You can't get far on NT386 without needing to support two > > calling > > > > > > conventions. > > > > > > The "OS" uses mostly __stdcall -- callee pops -- smaller, > > faster. > > > > > > But anything that is varargs, such as printf -- pretty much > > must > > > > > > use caller pops -- __cdecl. > > > > > > As well, __cdecl is the default, so prevalent, and used in > > most C > > > > > > runtime functions. > > > > > > There is also __fastcall that uses like up to two registers > > for > > > > > > parameters. > > > > > > > > > > > > I have seen a platform in which printf did the pop, and it > > > > depended > > > > > > on the number/size of parameters matching the format > > string. On > > > > > > most platforms, printf("", 1, 2, 3, 4) just does nothing, > > but on > > > > > > that platform, it'd unbalance the stack and crash. > > > > > > > > > > > > - Jay > > > > > > > > > > > > From: jayk123 at hotmail.com > > > > > > To: hosking at cs.purdue.edu > > > > > > CC: m3devel at elegosoft.com > > > > > > Subject: next problem (NT386GNU) > > > > > > Date: Mon, 21 Jan 2008 05:47:28 +0000 > > > > > > > > > > > > M3File.m3 > > > > > > > > > > > > PROCEDURE IsReadable (path: TEXT): BOOLEAN = > > > > > > (* We don't really check for readablitiy, just for > > existence *) > > > > > > BEGIN > > > > > > TRY > > > > > > EVAL FS.Status (path); line 82 > > > > > > RETURN TRUE; > > > > > > EXCEPT OSError.E => > > > > > > RETURN FALSE; > > > > > > END; > > > > > > END IsReadable; > > > > > > > > > > > > -----LINE 82 ----- > > > > > > start_call_direct p.25 0 Struct > > > > > > load_address v.25 0 > > > > > > pop_param Addr > > > > > > load v.26 0 Addr Addr > > > > > > pop_param Addr > > > > > > call_direct p.25 Struct > > > > > > pop Struct > > > > > > > > > > > > > > > > > > > > > > > > I'm guessing you only see an import for the first call on > > purpose, > > > > > > but I will compare with PPC_DARWIN: > > > > > > > > > > > > -----LINE 46 ----- > > > > > > import_procedure FS__Status 2 Struct 0 p.25 > > > > > > declare_indirect 2078421550 -2078421551 > > > > > > declare_param _return 4 4 Addr 2078421550 F F 50 v.62 > > > > > > declare_param p 4 4 Addr 1358456180 F F 50 v.63 > > > > > > start_call_direct p.25 0 Struct > > > > > > load_address v.13 0 > > > > > > pop_param Addr > > > > > > load v.14 0 Addr Addr > > > > > > pop_param Addr > > > > > > call_direct p.25 Struct > > > > > > pop Struct > > > > > > > > > > > > > > > > > > .globl _M3File__IsReadable > > > > > > .def _M3File__IsReadable; .scl 2; .type 32; .endef > > > > > > _M3File__IsReadable: > > > > > > .stabn 68,0,178,LM93-_M3File__IsReadable > > > > > > LM93: > > > > > > pushl %ebp > > > > > > movl %esp, %ebp > > > > > > pushl %edi > > > > > > pushl %esi > > > > > > pushl %ebx > > > > > > subl $300, %esp > > > > > > LBB15: > > > > > > .stabn 68,0,181,LM94-_M3File__IsReadable > > > > > > LM94: > > > > > > L157: > > > > > > movl -280(%ebp), %eax > > > > > > andl $0, %eax > > > > > > orl $_L_1, %eax > > > > > > movl %eax, -280(%ebp) > > > > > > movl -284(%ebp), %eax > > > > > > andl $0, %eax > > > > > > movl %eax, -284(%ebp) > > > > > > subl $12, %esp > > > > > > leal -288(%ebp), %eax > > > > > > pushl %eax > > > > > > call _RTHooks__PushEFrame > > > > > > addl $16, %esp > > > > > > leal -288(%ebp), %eax > > > > > > addl $48, %eax > > > > > > subl $12, %esp > > > > > > pushl %eax > > > > > > call __setjmp > > > > > > addl $16, %esp > > > > > > testb %al, %al > > > > > > jne L158 > > > > > > .stabn 68,0,183,LM95-_M3File__IsReadable > > > > > > LM95: > > > > > > movl -288(%ebp), %eax > > > > > > subl $12, %esp > > > > > > pushl %eax > > > > > > call _RTHooks__PopEFrame > > > > > > addl $16, %esp > > > > > > movl $1, -304(%ebp) > > > > > > jmp L159 > > > > > > L158: > > > > > > .stabn 68,0,185,LM96-_M3File__IsReadable > > > > > > LM96: > > > > > > movl $0, -304(%ebp) > > > > > > L159: > > > > > > LBE15: > > > > > > movl -304(%ebp), %eax > > > > > > leal -12(%ebp), %esp > > > > > > popl %ebx > > > > > > popl %esi > > > > > > popl %edi > > > > > > leave > > > > > > ret > > > > > > > > > > > > > > > > > > M3File.IsReadable's call to FS.Status is omitted, all files > > are > > > > > > readable, even if they are not openable, therefore it "finds" > > > > > > cm3.cfg in the current directory and then fails to open it.. > > > > > > > > > > > > later.. > > > > > > ..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! Learn > > > > more. > > > > > > > > > > > > > > > > > Shed those extra pounds with MSN and The Biggest Loser! Learn > > more. > > > > > > > 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 jayk123 at hotmail.com Tue Jan 22 00:17:32 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 21 Jan 2008 23:17:32 +0000 Subject: [M3devel] branching a file? In-Reply-To: <1A6EC7D6-32B2-44AD-933F-6976040A7D7F@cs.purdue.edu> References: <6E1E4409-F3D9-4982-B179-2D4C9648FDD0@cs.purdue.edu> <1A6EC7D6-32B2-44AD-933F-6976040A7D7F@cs.purdue.edu> Message-ID: In Perforce, if you want to make a file that starts out as a copy of another, but then diverges, NOT in a different branch, but one that will coexist in a different file name or path, you can use "integrate" to create the file initially. Does CVS have that? Or just copy and be done? e.g.: p4 integrate NT386GNU NT386_MINGWIN or p4 integrate NT386 NT386_MINGWIN (The first is more accurate, these files are almost identical, and really I'd like to have less duplication here somehow, like by copying all of the config files to bin\config and having them include bits and pieces -- reasonable? It used to look something like that, right?) (Integrate is also the command for merging branches. I little strange naming there all around.) - 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 Jan 22 00:56:27 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 21 Jan 2008 18:56:27 -0500 Subject: [M3devel] next problem (NT386GNU) In-Reply-To: References: <6E1E4409-F3D9-4982-B179-2D4C9648FDD0@cs.purdue.edu> <1A6EC7D6-32B2-44AD-933F-6976040A7D7F@cs.purdue.edu> Message-ID: I should be able to get cm3cg doing the right thing by the end of the week. On Jan 21, 2008, at 6:06 PM, Jay wrote: > I don't want to deal with learning about CVS branches, please. > > I can try the __cdecl thunk hack I had nearly working, over in m3- > win\import-libs. > It's lame compared to my parse.c though. > > Given void __stdcall Foo(int a, struct {int a, b}), or rather Foo 12, > > it would generate > > one source file/.obj > void __stdcall F(int a, int b, int c); > void __stdcall Fstdcall(int a, int b, int c) { return Fstdcall > (a b c); } > > another source file/.obj > void __stdcall Fstdcall(int a, int b, int c); > void __cdecl F(int a, int b, int c) { return Fstdcall(a b c); } > > If I could put parse.c back, I could limit this to functions that > take structs. > Or at least one function in particular that I know is a current > problem. > Limiting this hack would be good. > > - Jay > > > > CC: m3devel at elegosoft.com > > From: hosking at cs.purdue.edu > > Subject: Re: next problem (NT386GNU) > > Date: Mon, 21 Jan 2008 17:32:32 -0500 > > To: jayk123 at hotmail.com > > > > I'd prefer to have the backend do it properly based on properly > > declared types. I'd prefer to keep this code out of the current > > mainline of parse.c -- you could fork a temporary branch if > necessary. > > > > On Jan 21, 2008, at 5:16 PM, Jay wrote: > > > > > Understood. Put back my parse.c in the meantime? > > > > > > Also, the front end could do this, right? And probably without a > > > stack? > > > It could compute "effective parameter size" and pass that down. > > > Backend could then divide by 4 and claim that is the signature, > > > that number of parameters. > > > > > > Would have to see how passing a struct works out anyway -- one > > > parameter > > > or one per field. > > > > > > - Jay > > > > > > > > > > CC: m3devel at elegosoft.com > > > > From: hosking at cs.purdue.edu > > > > Subject: Re: next problem (NT386GNU) > > > > Date: Mon, 21 Jan 2008 12:01:28 -0500 > > > > To: jayk123 at hotmail.com > > > > > > > > I just need to fix m3cc/cm3cg to emit the stdcall parameter > > > > information for imported procedures. It is simply a matter of > not > > > > ignoring declare_param for import_procedure chunks. This means > > > > maintaining a current_function_decl (and possibly a > > > > current_param_count) stack (since import_procedure can occur > > > inside a > > > > declare_procedure chunk). I know what needs doing, but have > not much > > > > free time right now... > > > > > > > > On Jan 21, 2008, at 11:10 AM, Jay wrote: > > > > > > > > > agreed once I thought about it > > > > > I guess that explains left to right as well. > > > > > Parameters are always left to right from a higher level > point of > > > > > view, and if that is wrong, the compiler will reorder. > > > > > > > > > > "everything" works now > > > > > > > > > > - Jay > > > > > > > > > > > > > > > > > > > > > CC: m3devel at elegosoft.com > > > > > > From: hosking at cs.purdue.edu > > > > > > Subject: Re: next problem (NT386GNU) > > > > > > Date: Mon, 21 Jan 2008 10:54:10 -0500 > > > > > > To: jayk123 at hotmail.com > > > > > > > > > > > > Surely, when using the gcc-based backend then we should > make the > > > > > > backend handle it. The front end handling it is only need > for > > > the > > > > > > integrated x86 backend. > > > > > > > > > > > > On Jan 21, 2008, at 2:43 AM, Jay wrote: > > > > > > > > > > > > > I haven't tested a fix but I see the problem. > > > > > > > > > > > > > > This function returns a struct. > > > > > > > There are two struct returning calling conventions. > > > > > > > In one, the backend handles it. Which includes the backend > > > knowing > > > > > > > there is a return value and its type (or at least its > size?). > > > > > > > In the other, the front end handles it. In this case, the > > > front > > > > > end > > > > > > > generates passing an extra pointer parameter to the > > > function, and > > > > > > > the function's return type is void. > > > > > > > > > > > > > > The NT calling conventions, all of them, are marked as > > > front end > > > > > > > handling it. I assume that is correct, could check. > > > > > > > Everything else is marked as back end handling. > > > > > > > > > > > > > > Now then, somewhere along the line, gcc figures out > that the > > > > > return > > > > > > > value isn't used here. > > > > > > > The point of the function call is to see if it > generates an > > > > > exception. > > > > > > > > > > > > > > Gcc removes the function because its return value isn't > > > used, and, > > > > > > > well, somehow it doesn't know about the exceptions here. > > > I'll have > > > > > > > to see how "raise" is implemented. I think it's by a > call to a > > > > > > > function that gets the jmpbuf from a thread local and > calls > > > > > > > longjmp. (Did I mention it is very inefficient?) > > > > > > > > > > > > > > There are few possible fixes, but nothing completely > > > satisfactory > > > > > > > yet in mind. > > > > > > > > > > > > > > One is have parse.c mark all function calls as having side > > > > > affects. > > > > > > > This is easy, but overly pessimistic. > > > > > > > Another is for the front end to mark struct returning > > > functions as > > > > > > > having side affects. Better, but still overly pessimistic. > > > > > > > Another is for the front end to mark any function that can > > > > > raise as > > > > > > > having side affects. Getting better still. I don't know > how > > > to do > > > > > > > that but I'll look. This is still a bit overly > pessimistic, > > > since > > > > > > > what you really want to know is, not the function's side > > > affects, > > > > > > > but whether or not it raised. If the function is inlined, > > > the side > > > > > > > affects could be optimized away, or if there are enough > > > callers > > > > > who > > > > > > > don't care about the side affects to warrant an > > > optimization, and > > > > > > > depending on the cost of computing the side affects, > another > > > > > > > instance of the function could be made that only raises or > > > not, > > > > > but > > > > > > > no side affects otherwise. This is "advanced" > optimization the > > > > > sort > > > > > > > of which tends never to be implemented. > > > > > > > > > > > > > > I think the best option is anything that can raise is > > > marked as > > > > > > > having side affects. > > > > > > > I'll see if I can figure that out. > > > > > > > > > > > > > > You can figure this out by looking at m3cgcat -binary < > > > > > M3File.mc > > > > > > > > 1.txt on PPC_DARWIN and NT386GNU and comparing. > > > > > > > > > > > > > > Maybe marking all or nearly functions as having side > > > effects isn't > > > > > > > so bad. > > > > > > > Or at least anything returning a struct. That gets > parity with > > > > > > > other platforms, even if it is a bit pessimistic. > > > > > > > I think I'll do that, and ignore figuring out if raise is > > > called > > > > > > > and using that as a filter. > > > > > > > The parity angle is good. > > > > > > > > > > > > > > The good news for all you Unix lovers :) is this bug is > > > relatively > > > > > > > portable to Cygwin. > > > > > > > True, it is specific to NT386GNU having multiple "calling > > > > > > > conventions", which no other platform has. > > > > > > > Which again, jokingly, strikes at the question -- What is > > > Posix? > > > > > > > What do you want from Cygwin? > > > > > > > One thing Cygwin does NOT give you is just one calling > > > convention, > > > > > > > alas, this calling convention business stinks. It's not > > > even an NT > > > > > > > thing, only an NT386 thing. All the other NT platforms > had/ > > > have > > > > > > > only one calling convention. > > > > > > > > > > > > > > You can't get far on NT386 without needing to support two > > > calling > > > > > > > conventions. > > > > > > > The "OS" uses mostly __stdcall -- callee pops -- smaller, > > > faster. > > > > > > > But anything that is varargs, such as printf -- pretty > much > > > must > > > > > > > use caller pops -- __cdecl. > > > > > > > As well, __cdecl is the default, so prevalent, and used in > > > most C > > > > > > > runtime functions. > > > > > > > There is also __fastcall that uses like up to two > registers > > > for > > > > > > > parameters. > > > > > > > > > > > > > > I have seen a platform in which printf did the pop, and it > > > > > depended > > > > > > > on the number/size of parameters matching the format > > > string. On > > > > > > > most platforms, printf("", 1, 2, 3, 4) just does nothing, > > > but on > > > > > > > that platform, it'd unbalance the stack and crash. > > > > > > > > > > > > > > - Jay > > > > > > > > > > > > > > From: jayk123 at hotmail.com > > > > > > > To: hosking at cs.purdue.edu > > > > > > > CC: m3devel at elegosoft.com > > > > > > > Subject: next problem (NT386GNU) > > > > > > > Date: Mon, 21 Jan 2008 05:47:28 +0000 > > > > > > > > > > > > > > M3File.m3 > > > > > > > > > > > > > > PROCEDURE IsReadable (path: TEXT): BOOLEAN = > > > > > > > (* We don't really check for readablitiy, just for > > > existence *) > > > > > > > BEGIN > > > > > > > TRY > > > > > > > EVAL FS.Status (path); line 82 > > > > > > > RETURN TRUE; > > > > > > > EXCEPT OSError.E => > > > > > > > RETURN FALSE; > > > > > > > END; > > > > > > > END IsReadable; > > > > > > > > > > > > > > -----LINE 82 ----- > > > > > > > start_call_direct p.25 0 Struct > > > > > > > load_address v.25 0 > > > > > > > pop_param Addr > > > > > > > load v.26 0 Addr Addr > > > > > > > pop_param Addr > > > > > > > call_direct p.25 Struct > > > > > > > pop Struct > > > > > > > > > > > > > > > > > > > > > > > > > > > > I'm guessing you only see an import for the first call on > > > purpose, > > > > > > > but I will compare with PPC_DARWIN: > > > > > > > > > > > > > > -----LINE 46 ----- > > > > > > > import_procedure FS__Status 2 Struct 0 p.25 > > > > > > > declare_indirect 2078421550 -2078421551 > > > > > > > declare_param _return 4 4 Addr 2078421550 F F 50 v.62 > > > > > > > declare_param p 4 4 Addr 1358456180 F F 50 v.63 > > > > > > > start_call_direct p.25 0 Struct > > > > > > > load_address v.13 0 > > > > > > > pop_param Addr > > > > > > > load v.14 0 Addr Addr > > > > > > > pop_param Addr > > > > > > > call_direct p.25 Struct > > > > > > > pop Struct > > > > > > > > > > > > > > > > > > > > > .globl _M3File__IsReadable > > > > > > > .def _M3File__IsReadable; .scl 2; .type 32; .endef > > > > > > > _M3File__IsReadable: > > > > > > > .stabn 68,0,178,LM93-_M3File__IsReadable > > > > > > > LM93: > > > > > > > pushl %ebp > > > > > > > movl %esp, %ebp > > > > > > > pushl %edi > > > > > > > pushl %esi > > > > > > > pushl %ebx > > > > > > > subl $300, %esp > > > > > > > LBB15: > > > > > > > .stabn 68,0,181,LM94-_M3File__IsReadable > > > > > > > LM94: > > > > > > > L157: > > > > > > > movl -280(%ebp), %eax > > > > > > > andl $0, %eax > > > > > > > orl $_L_1, %eax > > > > > > > movl %eax, -280(%ebp) > > > > > > > movl -284(%ebp), %eax > > > > > > > andl $0, %eax > > > > > > > movl %eax, -284(%ebp) > > > > > > > subl $12, %esp > > > > > > > leal -288(%ebp), %eax > > > > > > > pushl %eax > > > > > > > call _RTHooks__PushEFrame > > > > > > > addl $16, %esp > > > > > > > leal -288(%ebp), %eax > > > > > > > addl $48, %eax > > > > > > > subl $12, %esp > > > > > > > pushl %eax > > > > > > > call __setjmp > > > > > > > addl $16, %esp > > > > > > > testb %al, %al > > > > > > > jne L158 > > > > > > > .stabn 68,0,183,LM95-_M3File__IsReadable > > > > > > > LM95: > > > > > > > movl -288(%ebp), %eax > > > > > > > subl $12, %esp > > > > > > > pushl %eax > > > > > > > call _RTHooks__PopEFrame > > > > > > > addl $16, %esp > > > > > > > movl $1, -304(%ebp) > > > > > > > jmp L159 > > > > > > > L158: > > > > > > > .stabn 68,0,185,LM96-_M3File__IsReadable > > > > > > > LM96: > > > > > > > movl $0, -304(%ebp) > > > > > > > L159: > > > > > > > LBE15: > > > > > > > movl -304(%ebp), %eax > > > > > > > leal -12(%ebp), %esp > > > > > > > popl %ebx > > > > > > > popl %esi > > > > > > > popl %edi > > > > > > > leave > > > > > > > ret > > > > > > > > > > > > > > > > > > > > > M3File.IsReadable's call to FS.Status is omitted, all > files > > > are > > > > > > > readable, even if they are not openable, therefore it > "finds" > > > > > > > cm3.cfg in the current directory and then fails to open > it.. > > > > > > > > > > > > > > later.. > > > > > > > ..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! > Learn > > > > > more. > > > > > > > > > > > > > > > > > > > > > Shed those extra pounds with MSN and The Biggest Loser! Learn > > > more. > > > > > > > > > > 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". Check it out. From darko at darko.org Tue Jan 22 06:37:40 2008 From: darko at darko.org (Darko) Date: Mon, 21 Jan 2008 21:37:40 -0800 Subject: [M3devel] NT386GNU distribution available In-Reply-To: References: Message-ID: <54D13F89-4394-4508-AA47-531956BC43F3@darko.org> Do you have a link for the distribution, or did I miss something? - Darko On 21/01/2008, at 8:41 AM, Jay wrote: > Here, in my user directory on birch, is the first CM3 NT386GNU > release. > It is MinGWin based FOR NOW. > This needs to be changed SOON. > > Install MinGWin. (Search the web for it.) > set PATH=c:\MinGW\bin;%PATH% > > (The default install location is c:\MinGW, not MinGWin.) > > The MinGWin that Qt gives you is too old, from around 2004. > It doesn't support "response files" (aka long command lines). > > If you want to rebuild m3cg: > > Install MSys. It is at the same place as MinGWin. > set PATH=c:\msys\1.0\bin;%PATH% > > else consider > > set OMIT_GCC=yes > > depending on if you run the various scripts. > > If you install to these exact paths, scripts\python\pylib.py > will use them automatically. > > Optionally install Python. I recommend it. > > Extract one or more of the archives. > They will extract to like: > > cm3-min-WIN32-NT386GNU-d5.5.1\bin\cm3.exe > > You can rename it cm3, or for purposes of backup/restore, > xcopy /fivery \cm3-min-WIN32-NT386GNU-d5.5.1 \cm3 > > (For extra good testing, first rmdir /q/s \cm3.) > > set PATH=c:\cm3\bin;%PATH% > > This is important, since various code will tend to assume NT386 > unless overridden. > > set CM3_TARGET=NT386GNU > > Someone please weigh in on zip vs. tar.bz2 on the other Win32 > platforms. > For reference, MinGWin doesn't include tar/bzip2, MSys does, Cygwin > has tons of optional stuff, they are in there, probably the base. > > And then go to scripts\python and run whatever: > upgrade > or make-dist > or do-cm3-core > or do-cm3-base > but not currently do-cm3-std > > scripts\win\upgrade works too. > > Do remember to set CM3_TARGET=NT386GNU. > > You will probably at some point be prompted to set CM3_ROOT to the > root of the source > tree as well. If you run "scripts", it will be set for you. > If you cd around and run cm3, it won't. > > \cm3\bin\cm3.cfg delegates out to the source tree. > Except the one in the distributions do not. > But if you run upgrade, you'll have such a thing. > > If you want to rebuild cm3cg from source: > cd m3-sys\m3cc\gcc\gcc\m3cg > cvs update -j 1.46 -j 1.45 parse.c > > or thereabouts to get back enough of a __stdcall fix to build a lot. > > If you want to bootstrap without a previous NT386GNU distribution > but with > a previous NT386 build, try like this: > > Get a working NT386 system. > Get current source (except parse.c). > If your system is not current, > scripts\python\upgrade > This will work as far back as cm3-min-WIN32-NT386-5.1.3. > scripts\python\bootntgnu > which is really just roughly: > do-pkg realclean m3core libm3 m3cc > do-pkg buildship m3core libm3 m3cc > set CM3_TARGET=NT386GNU > Now you have the equivalent of the minimum distribution and > can build whatever. > do-pkg .... > > If you want to rollback a bit but not completely, scripts\win > \pkggnu_clean.cmd is > very simple and just deletes all the NT386GNU directories under > $INSTALLROOT\pkg. > > There are "min", "core", and "base" distributions. > Kind of subtle names, eh? > "min" is sufficient. > The binaries are all not "strippped". > > Last minute errata: > There is bin\cm3.cfg and bin\NT386GNU. They are identical. > The intent was only to have cm3.cfg there. > > The system builds itself, so that's pretty good. > > I forgot to include m3gdb, but it should probably be in a separate > "GNU" archive? > > Someone move the files to a web download place? > (and you can move, not copy, I can easily recreate the files) > > - Jay > > Shed those extra pounds with MSN and The Biggest Loser! Learn more. From wagner at elegosoft.com Tue Jan 22 08:10:49 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 22 Jan 2008 08:10:49 +0100 Subject: [M3devel] next problem (NT386GNU) In-Reply-To: References: <6E1E4409-F3D9-4982-B179-2D4C9648FDD0@cs.purdue.edu> <1A6EC7D6-32B2-44AD-933F-6976040A7D7F@cs.purdue.edu> Message-ID: <20080122081049.74tzfvozwo4wwwow@mail.elegosoft.com> Quoting Jay : > I don't want to deal with learning about CVS branches, please. I don't understand the problems some people seem to have with CVS. Creating a branch is really simple: o create a branch tag, for example: cvs tag -b devel_nt386gnu_gcc_opt files(s) o update to that branch: cvs up -r devel_nt386gnu_gcc_opt files(s) That's it. The tag is now `sticky' on the files, i.e. remembered in the CVS/Entries files in your workspace. From now on you're using the branch for the mentioned files. To restore them to the latest main trunk version, use cvs up -A files(s) And Jay, as a Windows user you probably don't like to use the cvs commandline in Cygwin; just install CVS-NT and tortoise (Randy did, too). It may be more convenient for you. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Jan 22 08:26:25 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 22 Jan 2008 07:26:25 +0000 Subject: [M3devel] NT386GNU distribution available In-Reply-To: <54D13F89-4394-4508-AA47-531956BC43F3@darko.org> References: <54D13F89-4394-4508-AA47-531956BC43F3@darko.org> Message-ID: Sorry I do not. All I can do is scp the files to my home directory on birch and have "someone else" make them available otherwise. I made them world readable. If you have access to birch, look in ~jkrell. I'm not an ssh/scp expert, but this might work: scp yourname at m3.elegosoft.com:~jkrell/*.bz2 . I don't now if ~ works here. I should have listed the file names, sorry. Later. I think I deleted all the native Win32 files so that will net you three files all relevant. Or if you can ls in the directory...the "min" one imho is the most interesting, you can build the others easily from it. Maybe try bootstrapping as kind of detailed below? :) (That should be tested as well.) Maybe Trestle tonight, we'll see.. - Jay > CC: m3devel at elegosoft.com> From: darko at darko.org> To: jayk123 at hotmail.com> Subject: Re: [M3devel] NT386GNU distribution available> Date: Mon, 21 Jan 2008 21:37:40 -0800> > Do you have a link for the distribution, or did I miss something?> > - Darko> > On 21/01/2008, at 8:41 AM, Jay wrote:> > > Here, in my user directory on birch, is the first CM3 NT386GNU > > release.> > It is MinGWin based FOR NOW.> > This needs to be changed SOON.> >> > Install MinGWin. (Search the web for it.)> > set PATH=c:\MinGW\bin;%PATH%> >> > (The default install location is c:\MinGW, not MinGWin.)> >> > The MinGWin that Qt gives you is too old, from around 2004.> > It doesn't support "response files" (aka long command lines).> >> > If you want to rebuild m3cg:> >> > Install MSys. It is at the same place as MinGWin.> > set PATH=c:\msys\1.0\bin;%PATH%> >> > else consider> >> > set OMIT_GCC=yes> >> > depending on if you run the various scripts.> >> > If you install to these exact paths, scripts\python\pylib.py> > will use them automatically.> >> > Optionally install Python. I recommend it.> >> > Extract one or more of the archives.> > They will extract to like:> >> > cm3-min-WIN32-NT386GNU-d5.5.1\bin\cm3.exe> >> > You can rename it cm3, or for purposes of backup/restore,> > xcopy /fivery \cm3-min-WIN32-NT386GNU-d5.5.1 \cm3> >> > (For extra good testing, first rmdir /q/s \cm3.)> >> > set PATH=c:\cm3\bin;%PATH%> >> > This is important, since various code will tend to assume NT386 > > unless overridden.> >> > set CM3_TARGET=NT386GNU> >> > Someone please weigh in on zip vs. tar.bz2 on the other Win32 > > platforms.> > For reference, MinGWin doesn't include tar/bzip2, MSys does, Cygwin> > has tons of optional stuff, they are in there, probably the base.> >> > And then go to scripts\python and run whatever:> > upgrade> > or make-dist> > or do-cm3-core> > or do-cm3-base> > but not currently do-cm3-std> >> > scripts\win\upgrade works too.> >> > Do remember to set CM3_TARGET=NT386GNU.> >> > You will probably at some point be prompted to set CM3_ROOT to the > > root of the source> > tree as well. If you run "scripts", it will be set for you.> > If you cd around and run cm3, it won't.> >> > \cm3\bin\cm3.cfg delegates out to the source tree.> > Except the one in the distributions do not.> > But if you run upgrade, you'll have such a thing.> >> > If you want to rebuild cm3cg from source:> > cd m3-sys\m3cc\gcc\gcc\m3cg> > cvs update -j 1.46 -j 1.45 parse.c> >> > or thereabouts to get back enough of a __stdcall fix to build a lot.> >> > If you want to bootstrap without a previous NT386GNU distribution > > but with> > a previous NT386 build, try like this:> >> > Get a working NT386 system.> > Get current source (except parse.c).> > If your system is not current,> > scripts\python\upgrade> > This will work as far back as cm3-min-WIN32-NT386-5.1.3.> > scripts\python\bootntgnu> > which is really just roughly:> > do-pkg realclean m3core libm3 m3cc> > do-pkg buildship m3core libm3 m3cc> > set CM3_TARGET=NT386GNU> > Now you have the equivalent of the minimum distribution and > > can build whatever.> > do-pkg ....> >> > If you want to rollback a bit but not completely, scripts\win > > \pkggnu_clean.cmd is> > very simple and just deletes all the NT386GNU directories under > > $INSTALLROOT\pkg.> >> > There are "min", "core", and "base" distributions.> > Kind of subtle names, eh?> > "min" is sufficient.> > The binaries are all not "strippped".> >> > Last minute errata:> > There is bin\cm3.cfg and bin\NT386GNU. They are identical.> > The intent was only to have cm3.cfg there.> >> > The system builds itself, so that's pretty good.> >> > I forgot to include m3gdb, but it should probably be in a separate > > "GNU" archive?> >> > Someone move the files to a web download place?> > (and you can move, not copy, I can easily recreate the files)> >> > - Jay> >> > 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 jayk123 at hotmail.com Tue Jan 22 08:34:35 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 22 Jan 2008 07:34:35 +0000 Subject: [M3devel] next problem (NT386GNU) In-Reply-To: <20080122081049.74tzfvozwo4wwwow@mail.elegosoft.com> References: <6E1E4409-F3D9-4982-B179-2D4C9648FDD0@cs.purdue.edu> <1A6EC7D6-32B2-44AD-933F-6976040A7D7F@cs.purdue.edu> <20080122081049.74tzfvozwo4wwwow@mail.elegosoft.com> Message-ID: Olaf, yes and no. How do I then bring the files into mainline? Which Tinderbox is testing them? This is impossible question probably, because Tinderbox for private changes probably doesn't scale well. But it would be nice. And other than private branches, submitting diffs would be nice. Or, as well, these can be crutches for bad changes, and people can abuse the Tinderbox. It's tough though, because a multi machine Tinderbox can always easily do much more diligence than one developer and his local machines. (What's the Win32 Tinderbox story, I wonder? I guess first I can see if Mozilla has one, and if not, it probably doesn't exist, if so, it does :) ) I don't mind the command line, but I'm a bit slow learning new tools. I find new source control systems daunting. I'm quite expert with Perforce though including branching, integrating, resolving, etc.. You don't have to be in Cygwin (sh) to use cvs, but it's true, one very annoying thing about all these forward-slash-requiring tools is I lose the usefulness of command line completion in cmd. Cmd is quite good at editing command lines, keeping output and command line history (set the scrollback to 9999), copy/paste, and is very fast, nothing else that I have tried competes. Most are even merely slower on their video output except maybe the actual text ones. The F8 feature, command line completion against history, which I can't explain well, is really great. MSys comes up with awful colors that I couldn't figure out how to change. Cygwin makes all your paths be /cygdrive/c/... which is just ugly and long. MSys/MinGWin are much nicer with merely /c... I installed TortoiseCVS but it didn't work..I need to look into how to get it to use ssh. But as well, if my work doesn't suck too much, it should be fine for mainline. Look at diffs is really also slow. I've done best by always saving away an .orig file and then windiff. Otherwise 1) is very slow 2) textual diffs...I use the command line all the time, but for viewing diffs...it's really insufficient. - Jay > Date: Tue, 22 Jan 2008 08:10:49 +0100> From: wagner at elegosoft.com> To: m3devel at elegosoft.com> Subject: Re: [M3devel] next problem (NT386GNU)> > Quoting Jay :> > > I don't want to deal with learning about CVS branches, please.> > I don't understand the problems some people seem to have with CVS.> Creating a branch is really simple:> > o create a branch tag, for example:> > cvs tag -b devel_nt386gnu_gcc_opt files(s)> > o update to that branch:> > cvs up -r devel_nt386gnu_gcc_opt files(s)> > That's it. The tag is now `sticky' on the files, i.e. remembered> in the CVS/Entries files in your workspace. From now on you're> using the branch for the mentioned files. To restore them to the> latest main trunk version, use> > cvs up -A files(s)> > And Jay, as a Windows user you probably don't like to use the cvs> commandline in Cygwin; just install CVS-NT and tortoise (Randy did,> too). It may be more convenient for you.> > Olaf> -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 Tue Jan 22 08:53:03 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 22 Jan 2008 08:53:03 +0100 Subject: [M3devel] NT386GNU distribution available In-Reply-To: References: <54D13F89-4394-4508-AA47-531956BC43F3@darko.org> Message-ID: <20080122085303.zxbo59ixickk4gos@mail.elegosoft.com> Quoting Jay : > Sorry I do not. All I can do is scp the files to my home directory > on birch and have "someone else" make them available otherwise. > I made them world readable. You could at least make the appropriate entries to the www/download.html page in the same format as the others are. Perhaps we should just add a directory with an automatic index generation for this kind of new archives like for the generated snapshots. I've now added the links. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Jan 22 09:20:52 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 22 Jan 2008 09:20:52 +0100 Subject: [M3devel] next problem (NT386GNU) In-Reply-To: References: <6E1E4409-F3D9-4982-B179-2D4C9648FDD0@cs.purdue.edu> <1A6EC7D6-32B2-44AD-933F-6976040A7D7F@cs.purdue.edu> <20080122081049.74tzfvozwo4wwwow@mail.elegosoft.com> Message-ID: <20080122092052.4osfqyffkkggcs48@mail.elegosoft.com> Quoting Jay : > Olaf, yes and no. > > How do I then bring the files into mainline? A merge is done by using -j (join) insted of -r during update: cvs up -j tag1 [-j tag2] file(s) > Which Tinderbox is testing them? Currently no platforms except for FreeBSD 6 and Debian Linux are tested and displayed in the tinderbox. Unless you or Randy set up a build host running the regression test scripts, it may take a little bit longer for daily test results on Windows to be available. But I'm still waiting for the result shipping implementation and procedure description anyway. Should be available soon, I've heard ;-) Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Jan 22 09:32:52 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 22 Jan 2008 08:32:52 +0000 Subject: [M3devel] NT386GNU distribution available In-Reply-To: <20080122085303.zxbo59ixickk4gos@mail.elegosoft.com> References: <54D13F89-4394-4508-AA47-531956BC43F3@darko.org> <20080122085303.zxbo59ixickk4gos@mail.elegosoft.com> Message-ID: I add entries in download.html and they say ~jkrell/foo or /usr/home/jkrell/foo and the machine updates download.html every so often and done? I didn't/don't know if I could do anything from my end, or what it would be. Thanks! - Jay > Date: Tue, 22 Jan 2008 08:53:03 +0100> From: wagner at elegosoft.com> To: m3devel at elegosoft.com> Subject: Re: [M3devel] NT386GNU distribution available> > Quoting Jay :> > > Sorry I do not. All I can do is scp the files to my home directory > > on birch and have "someone else" make them available otherwise.> > I made them world readable.> > You could at least make the appropriate entries to the www/download.html> page in the same format as the others are.> > Perhaps we should just add a directory with an automatic index generation> for this kind of new archives like for the generated snapshots.> > I've now added the links.> > Olaf> -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 Jan 22 09:43:20 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 22 Jan 2008 08:43:20 +0000 Subject: [M3devel] next problem (NT386GNU) In-Reply-To: <20080122092052.4osfqyffkkggcs48@mail.elegosoft.com> References: <6E1E4409-F3D9-4982-B179-2D4C9648FDD0@cs.purdue.edu> <1A6EC7D6-32B2-44AD-933F-6976040A7D7F@cs.purdue.edu> <20080122081049.74tzfvozwo4wwwow@mail.elegosoft.com> <20080122092052.4osfqyffkkggcs48@mail.elegosoft.com> Message-ID: Any idea how? Oh I see...sounds easier than expected..I was thinking of doing cross builds on your machines or finding some Win32 hosting/colocation, but.. http://en.wikipedia.org/wiki/Tinderbox_%28software%29 >> Mozilla's tinderbox is written in Perl >> Tinderbox is composed of a server with clients running builds and reporting status via mail. probably easy enough to just run it on a machine of mine.. http://www.mozilla.org/projects/tinderbox/index.html -- version 2 http://www.johnkeiser.com/mozilla/tbox3.html -- version 3 - Jay > Date: Tue, 22 Jan 2008 09:20:52 +0100> From: wagner at elegosoft.com> To: jayk123 at hotmail.com> CC: m3devel at elegosoft.com> Subject: RE: [M3devel] next problem (NT386GNU)> > Quoting Jay :> > > Olaf, yes and no.> >> > How do I then bring the files into mainline?> > A merge is done by using -j (join) insted of -r during update:> > cvs up -j tag1 [-j tag2] file(s)> > > Which Tinderbox is testing them?> > Currently no platforms except for FreeBSD 6 and Debian Linux are> tested and displayed in the tinderbox.> > Unless you or Randy set up a build host running the regression test> scripts, it may take a little bit longer for daily test results on> Windows to be available.> > But I'm still waiting for the result shipping implementation and> procedure description anyway. Should be available soon, I've heard ;-)> > Olaf> -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 Tue Jan 22 11:48:56 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 22 Jan 2008 10:48:56 +0000 Subject: [M3devel] platform/build_dir is a big tuple? In-Reply-To: References: Message-ID: Final answer? I played around with this but just can't accept platforms/build_dirs like: ntx86msmsmscm3msn ntx86gccgcccm3cgmsn ntx86gccgcccm3cgxn ntx86-gggggmn ntx86-ggixn ntx86_mmmimm Ok, I have one more name here, and then a bit of a change, or a stronger statement of something I had already said. NT386MINGNU Ok, I think we (me!) are confusing host and target, MOSTLY. And cm3 might not have them quite divided appropriately. What is a "host"? What is a "target"? MinGWin and Visual C++ output similar results, targetingthe same runtime (usually), threading library, windowing library.There is a chance for exception handling to diverge however.Well, speaking of Visual C++ the C/C++ compiler and MinGWinthe gcc environment, yes, very different, not interoperable.MinGWin uses what gcc calls "sjlj" -- setjmp/longjmp exceptions.Very inefficient. But heck, gcc doesn't support __try/__except/__finally,only C++ exceptions, and interop of C++ is often not great,what with name mangling and all. NT386GNU's OUTPUT uses a different runtime, unless you trim dependencies, possibly a different threading library, possibly a different windowing library. All this probably configurable. Again exception handling is a sore point in that it is the primary C runtime dependency of Modula-3. If you use Cygwin but say -mno-cygwin, that means you are targeting NT386. (and don't use pthreads or X Windows; behavior of exceptions/setjmp/longjmp TBD -- really, need to not use the -mno-cygwin headers in that case; I'll check). Perhaps m3core.dll should export m3_setjmp/m3_longjmp.. Either one can do a cross build to the other.Two cm3.exes, two sets of outputs, that either can produce. NT386 can use gcc or the integrated backend. And the gcc it uses can be MinGWin or Cygwin. (theoretically and probably soon reality) NT386GNU can use either as well! (also currently theory, but a real possibility) It isn't GNU tools, it is GNU runtime. One small area with cm3 might fall down just slightly is that of cross builds where host and target have different naming conventions. -lfoo vs. foo.lib, foo.o vs. foo.obj are an aspect of the host and I vaguely recall that cm3 ties naming convention to ostype. The appending of .exe is a target characteristics, but the others are not really. Naming convention is really a host thing and not a target thing. The config files are a mix of host and target information, mostly actually host, except for the one line that says TARGET. Most of the target variation is in cm3, which always can do any, and cm3cg (which might be nice to be similar, but that's another matter and not likely to ever change, except when AMD64 is the last architecture standing. :) ) If Windows had "rpath", then SL would be split between HOST_SL and TARGET_SL.As it stands, SL is HOST_SL. Consider as well the various versions of Visual C++.They output mostly the same, very interoperable. Consider optimization switches. Host or target?Consider version of gcc or Visual C++? Host or target?Well, inevitably, the host has an affect on the target. If not the for the host, the target would not even exist. Bugs in the host produce bugs in the target. etc. (And realize that Cygwin runs on top of an OS built witha Microsoft compiler, so really there is interop, but sometimes through a layer.) So there's a risk of saying there is six+ combinations. (host cygwin, host mingwin, host native) x (target nt386, target nt386gnu) But generally the host is assumed not a factor. I guess "LIBC" could be seperated into several options... You could actually have code that needs one runtime or another, and they could link together, depending on what they do.. This is something I don't know if cm3 handles, or anything I have seen. I should be able to build a static .lib, that includes some C code, that imbues its clients with build time dependencies. Well, I guess #pragma comment(linker) is this. So the next tasks are roughly: Merge my NT386 and NT386GNU files. Switching on a variable such as backend mode. Introduce a "new" (old) NT386GNU file, perhaps more like what was already there. Change NT386GNU back to Posix. Build NT386GNU. oh, one more point...while these are two targets from cm3's point of view, they are PROBABLY the same target to cm3cg and so only one is needed. I have to check if configure differentiates between i686-pc-cygwin and i686-pc-mingwin... but I guess it should... It might actually be profitable to have two bloated cm3cg.exe's. And they should ship to \cm3\pkg\m3cc\target\host or host\target and cm3 should know which to run. Blech..four of them when one would suffice? The detail being mainly what the paths to .libs look like, unfortunate. Possibly cm3 can bridge this gap using that "broken" feature that symlinks libs into the target directory, using NTFS hard links, if installroot and root are on the same volume... (or symlinks on Vista). Or maybe convert the paths as appropriate, hacky, but saves an extra cm3cg.exe which is good to avoid. (all the more reason to lump all targets into one file, so that the host x target matrix collapses to just one axis, host; and then you can write stuff in Perl/Python/Java/C# to collapse that to just one, except for the underlying runtime/interpreter...) Oh, cm3cg isn't the issue. It is always sitting in the correct directory and reads one file and writes one file, no slashes. The issue is gcc as the linker. Again, this is a host issue..and cm3 or the config file definitely should do the translation. - Jay From: jayk123 at hotmail.comTo: m3devel at elegosoft.comDate: Mon, 21 Jan 2008 23:01:44 +0000Subject: [M3devel] platform/build_dir is a big tuple? _________________________________________________________________ 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 Tue Jan 22 14:00:12 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 22 Jan 2008 13:00:12 +0000 Subject: [M3devel] platform/build_dir is a big tuple? In-Reply-To: References: Message-ID: I'm still torn over that any NT386 target could have a choice of three threading models (win32, pthread, vtalarm), two windowing libraries (ms, x), two (three) compilers (ms, mingwin, cygwin), two (three) linkers (ms, mingwn, cygwin), various runtimes (msvc various versions, cygwin, mingwin (discouraged)) etc. Appending a short string of unreadable bits to BUILD_DIR is very temptingin order to easily generate and test the combinatorial possibilities. backend: 0 integrated, 1 gcc already a setting (with four values) ccompiler/linker: 0 ms, 1 gcc (these could be split, and could allocate more bits...) maybe 00 ms, 01 cygwin, 10 ming maybe define enum up front that allows for watcom, metrowerks, digitalmars, llvm etc. maybe use a decimal digit for all these, and 0 is reserved, maybe. threading: 0 win32, 1 pthreads drop vtalarm, or use two bits? windowing: 0 ms, 1 x cruntime: 0 ms, 1 cyg There is also a ming runtime, discouraged There also really N ms runtimes, ming offers several: msvcrt.dll, msvcr70.dll, msvcr71.dll, msvcr80.dll, msvcr90.dll... but jmpbuf presumbly doesn't change again could allocate multiple bits.. cruntime I guess determines oSTYPE Win32 or Posix, thoughit loses its meaning mostly, and X vs. not-X is usually decide the same... The three most common combinations: 00000 -- NT386 11111 -- NT386GNU 11000 -- NT386MINGNU but several others would work 11101 -- cygwin with native windowing 11011 -- cygwin with native threads 11001 -- cygwin with native threads and native windowing BUILD_DIR would be NT386-$(config)as a special case perhaps, the three commoncases could be translated to the above strings. But the underlying implementation would be a few bools/enums,and iterating through them would be easy, while special casingand skipping deemed invalid combinations, like ms runtime and pthreads,and possibly ms runtime and x windows. Really, it might surprise folks, but really, basically every single combination works. Compilers are very independent of headers and libs and headers and libs are very independent of compilers, aside from a few language extensions like __stdcall. You can generally mix runtimes in the same process, just as you can mix them on the same machine, you just need to be careful about what you pass to what. If you call fopen, be sure pass the result back to the matching fclose, malloc/free, etc. Startup code, to the extent that it matters, might be a problem, but really, just avoid C++ globals with constructors/destructors anyway, they are always a problem. Modula-3 has its own startup code, and if you were to write "main" in C and link in Modula-3 static .libs, that probably doesn't work...might actually be better to play into whatever the platform's C++ constructor story is, as problematic as they (probably always?) are -- i.e. unpredictable/hard-to-control ordering. (bad editing...and maybe use hex for compression..) Bringing back cminstall is almost interesting, to promptthe user, or probe their system, though Quake/cm3 can probe at runtime.if os == windows_nt system_cc | findstr version | findstr gcc else system_cc | findstr visual c++else system_cc | grep version | grep gcc else system_cc | grep visual c++end inefficient. anyway, I'll merge current NT386GNU into NT386 and make it chosehow to compile/link which are the main variables today. and then decide about cygwin, but probably do like the above, sinceit'll totally share code with NT386 except the naming conventionsand the removal of the -mno-cygwin switch.. I know this seems overly complicated, but it should be exposableeasily enough to users by hiding the choices, presenting three basic ones,and still allow all the obvious and perhaps useful knobs, and iterating throughthe combinations, without creating a combinatorial explosion of source filesor Modula-3 or Quake code. ...Jay From: jayk123 at hotmail.comTo: m3devel at elegosoft.comDate: Tue, 22 Jan 2008 10:48:56 +0000Subject: Re: [M3devel] platform/build_dir is a big tuple? Final answer? I played around with this but just can't accept platforms/build_dirs like: ntx86msmsmscm3msn ntx86gccgcccm3cgmsn ntx86gccgcccm3cgxn ntx86-gggggmn ntx86-ggixn ntx86_mmmimmOk, I have one more name here, and then a bit of a change, or a stronger statement of something I had already said.NT386MINGNUOk, I think we (me!) are confusing host and target, MOSTLY.And cm3 might not have them quite divided appropriately.What is a "host"? What is a "target"?MinGWin and Visual C++ output similar results, targetingthe same runtime (usually), threading library, windowing library.There is a chance for exception handling to diverge however.Well, speaking of Visual C++ the C/C++ compiler and MinGWinthe gcc environment, yes, very different, not interoperable.MinGWin uses what gcc calls "sjlj" -- setjmp/longjmp exceptions.Very inefficient. But heck, gcc doesn't support __try/__except/__finally,only C++ exceptions, and interop of C++ is often not great,what with name mangling and all.NT386GNU's OUTPUT uses a different runtime, unless you trim dependencies, possibly a different threading library, possibly a different windowing library. All this probably configurable. Again exception handling is a sore point in that it is the primary C runtime dependency of Modula-3. If you use Cygwin but say -mno-cygwin, that means you are targeting NT386. (and don't use pthreads or X Windows; behavior of exceptions/setjmp/longjmp TBD -- really, need to not use the -mno-cygwin headers in that case; I'll check).Perhaps m3core.dll should export m3_setjmp/m3_longjmp..Either one can do a cross build to the other.Two cm3.exes, two sets of outputs, that either can produce.NT386 can use gcc or the integrated backend. And the gcc it uses can be MinGWin or Cygwin. (theoretically and probably soon reality) NT386GNU can use either as well! (also currently theory, but a real possibility) It isn't GNU tools, it is GNU runtime.One small area with cm3 might fall down just slightly is that of cross builds where host and target have different naming conventions. -lfoo vs. foo.lib, foo.o vs. foo.obj are an aspect of the host and I vaguely recall that cm3 ties naming convention to ostype. The appending of .exe is a target characteristics, but the others are not really. Naming convention is really a host thing and not a target thing.The config files are a mix of host and target information, mostly actually host, except for the one line that says TARGET. Most of the target variation is in cm3, which always can do any, and cm3cg (which might be nice to be similar, but that's another matter and not likely to ever change, except when AMD64 is the last architecture standing. :) )If Windows had "rpath", then SL would be split between HOST_SL and TARGET_SL.As it stands, SL is HOST_SL.Consider as well the various versions of Visual C++.They output mostly the same, very interoperable.Consider optimization switches. Host or target?Consider version of gcc or Visual C++? Host or target?Well, inevitably, the host has an affect on the target. If not the for the host, the target would not even exist. Bugs in the host produce bugs in the target. etc.(And realize that Cygwin runs on top of an OS built witha Microsoft compiler, so really there is interop, but sometimes through a layer.) So there's a risk of saying there is six+ combinations.(host cygwin, host mingwin, host native) x (target nt386, target nt386gnu) But generally the host is assumed not a factor. I guess "LIBC" could be seperated into several options...You could actually have code that needs one runtime or another, and they couldlink together, depending on what they do.. This is something I don't know if cm3 handles, or anything I have seen. I should be able to build a static .lib, that includes some C code, that imbues its clients with build time dependencies. Well, I guess #pragma comment(linker) is this.So the next tasks are roughly: Merge my NT386 and NT386GNU files. Switching on a variable such as backend mode. Introduce a "new" (old) NT386GNU file, perhaps more like what was already there. Change NT386GNU back to Posix. Build NT386GNU. oh, one more point...while these are two targets from cm3's point of view, they are PROBABLY the same target to cm3cgand so only one is needed. I have to check if configure differentiates between i686-pc-cygwin and i686-pc-mingwin...but I guess it should...It might actually be profitable to have two bloated cm3cg.exe's.And they should ship to \cm3\pkg\m3cc\target\host or host\target and cm3 should know which to run.Blech..four of them when one would suffice?The detail being mainly what the paths to .libs look like, unfortunate.Possibly cm3 can bridge this gap using that "broken" feature that symlinks libs into the target directory,using NTFS hard links, if installroot and root are on the same volume... (or symlinks on Vista).Or maybe convert the paths as appropriate, hacky, but saves an extra cm3cg.exe which is good to avoid. (all the more reason to lump all targets into one file, so that the host x target matrix collapses to just one axis, host; andthen you can write stuff in Perl/Python/Java/C# to collapse that to just one, except for the underlying runtime/interpreter...) Oh, cm3cg isn't the issue. It is always sitting in the correct directory and reads one file and writes one file, no slashes.The issue is gcc as the linker. Again, this is a host issue..and cm3 or the config file definitely should do the translation. - Jay From: jayk123 at hotmail.comTo: m3devel at elegosoft.comDate: Mon, 21 Jan 2008 23:01:44 +0000Subject: [M3devel] platform/build_dir is a big tuple? 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 wagner at elegosoft.com Tue Jan 22 14:29:22 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 22 Jan 2008 14:29:22 +0100 Subject: [M3devel] platform/build_dir is a big tuple? In-Reply-To: References: Message-ID: <20080122142922.k73w5es5j4gckso4@mail.elegosoft.com> All this may be useful during development, but it is not really useful for a software distribution to our users, I think. Nobody will understand it :-( We need to keep things more simple. We don't need to support everything out of the box. Instead, we should offer some sensible default combinations of everyhing you describe. First of all: we don't distribute cross compilers (at least until now). This is a special topic reserved for adding new platforms. Runtime and compilers used do not necessarily need to be distinguished by target or build dir, in many cases different cm3.cfg may suffice. Until now, threading models are also no choice that needs to be visible at this level. There's one default model for every target, and the user can change it by recompiling. And if we should really agree that changing the target naming scheme is a good idea, we should o use a systematic one with not more than 4 elements (better still, 3 (e.g. --)) o don't use cryptic abbreviations that will confuse most people Just my 2 cents, Olaf Quoting Jay : > I'm still torn over that any NT386 target could have a choice of > three threading models (win32, pthread, vtalarm), two windowing > libraries (ms, x), two (three) compilers (ms, mingwin, cygwin), two > (three) linkers (ms, mingwn, cygwin), various runtimes (msvc various > versions, cygwin, mingwin (discouraged)) etc. > > Appending a short string of unreadable bits to BUILD_DIR is very > temptingin order to easily generate and test the combinatorial > possibilities. > > backend: 0 integrated, 1 gcc already a setting (with four values) > > ccompiler/linker: 0 ms, 1 gcc (these could be split, and could > allocate more bits...) maybe 00 ms, 01 cygwin, 10 ming maybe define > enum up front that allows for watcom, metrowerks, digitalmars, llvm > etc. > maybe use a decimal digit for all these, and 0 is reserved, maybe. > > threading: 0 win32, 1 pthreads drop vtalarm, or use two bits? > > windowing: 0 ms, 1 x > > cruntime: 0 ms, 1 cyg There is also a ming runtime, discouraged > There also really N ms runtimes, ming offers several: msvcrt.dll, > msvcr70.dll, msvcr71.dll, msvcr80.dll, msvcr90.dll... but jmpbuf > presumbly doesn't change again could allocate multiple bits.. > > cruntime I guess determines oSTYPE Win32 or Posix, thoughit loses > its meaning mostly, and X vs. not-X is usually decide the same... > > The three most common combinations: 00000 -- NT386 11111 -- > NT386GNU 11000 -- NT386MINGNU > > but several others would work 11101 -- cygwin with native windowing > 11011 -- cygwin with native threads 11001 -- cygwin with native > threads and native windowing > BUILD_DIR would be NT386-$(config)as a special case perhaps, the > three commoncases could be translated to the above strings. > > But the underlying implementation would be a few bools/enums,and > iterating through them would be easy, while special casingand > skipping deemed invalid combinations, like ms runtime and > pthreads,and possibly ms runtime and x windows. > Really, it might surprise folks, but really, basically every single > combination works. > Compilers are very independent of headers and libs and headers and > libs are very independent of compilers, aside from a few language > extensions like __stdcall. You can generally mix runtimes in the > same process, just as you can mix them on the same machine, you just > need to be careful about what you pass to what. If you call fopen, > be sure pass the result back to the matching fclose, malloc/free, > etc. Startup code, to the extent that it matters, might be a > problem, but really, just avoid C++ globals with > constructors/destructors anyway, they are always a problem. Modula-3 > has its own startup code, and if you were to write "main" in C and > link in Modula-3 static .libs, that probably doesn't work...might > actually be better to play into whatever the platform's C++ > constructor story is, as problematic as they (probably always?) are > -- i.e. unpredictable/hard-to-control ordering. > > (bad editing...and maybe use hex for compression..) > > Bringing back cminstall is almost interesting, to promptthe user, or > probe their system, though Quake/cm3 can probe at runtime.if os == > windows_nt system_cc | findstr version | findstr gcc else > system_cc | findstr visual c++else system_cc | grep version | grep > gcc else system_cc | grep visual c++end > > inefficient. > > anyway, I'll merge current NT386GNU into NT386 and make it chosehow > to compile/link which are the main variables today. > and then decide about cygwin, but probably do like the above, > sinceit'll totally share code with NT386 except the naming > conventionsand the removal of the -mno-cygwin switch.. > > I know this seems overly complicated, but it should be > exposableeasily enough to users by hiding the choices, presenting > three basic ones,and still allow all the obvious and perhaps useful > knobs, and iterating throughthe combinations, without creating a > combinatorial explosion of source filesor Modula-3 or Quake code. > ...Jay > > > From: jayk123 at hotmail.comTo: m3devel at elegosoft.comDate: Tue, 22 Jan > 2008 10:48:56 +0000Subject: Re: [M3devel] platform/build_dir is a > big tuple? > > > Final answer? I played around with this but just can't accept > platforms/build_dirs like: ntx86msmsmscm3msn ntx86gccgcccm3cgmsn > ntx86gccgcccm3cgxn ntx86-gggggmn ntx86-ggixn ntx86_mmmimmOk, I > have one more name here, and then a bit of a change, or a stronger > statement of something I had already said.NT386MINGNUOk, I think we > (me!) are confusing host and target, MOSTLY.And cm3 might not have > them quite divided appropriately.What is a "host"? What is a > "target"?MinGWin and Visual C++ output similar results, targetingthe > same runtime (usually), threading library, windowing library.There > is a chance for exception handling to diverge however.Well, speaking > of Visual C++ the C/C++ compiler and MinGWinthe gcc environment, > yes, very different, not interoperable.MinGWin uses what gcc calls > "sjlj" -- setjmp/longjmp exceptions.Very inefficient. But heck, gcc > doesn't support __try/__except/__finally,only C++ exceptions, and > interop of C++ is often not great,what with name mangling and > all.NT386GNU's OUTPUT uses a different runtime, unless you trim > dependencies, possibly a different threading library, possibly a > different windowing library. All this probably configurable. Again > exception handling is a sore point in that it is the primary C > runtime dependency of Modula-3. If you use Cygwin but say > -mno-cygwin, that means you are targeting NT386. (and don't use > pthreads or X Windows; behavior of exceptions/setjmp/longjmp TBD -- > really, need to not use the -mno-cygwin headers in that case; I'll > check).Perhaps m3core.dll should export > m3_setjmp/m3_longjmp..Either one can do a cross build to the > other.Two cm3.exes, two sets of outputs, that either can > produce.NT386 can use gcc or the integrated backend. And the gcc > it uses can be MinGWin or Cygwin. (theoretically and probably soon > reality) NT386GNU can use either as well! (also currently theory, > but a real possibility) It isn't GNU tools, it is GNU runtime.One > small area with cm3 might fall down just slightly is that of > cross builds where host and target have different naming > conventions. -lfoo vs. foo.lib, foo.o vs. foo.obj are an aspect > of the host and I vaguely recall that cm3 ties naming convention > to ostype. The appending of .exe is a target characteristics, but > the others are not really. Naming convention is really a host > thing and not a target thing.The config files are a mix of host and > target information, mostly actually host, except for the one line > that says TARGET. Most of the target variation is in cm3, which > always can do any, and cm3cg (which might be nice to be similar, > but that's another matter and not likely to ever change, except > when AMD64 is the last architecture standing. :) )If Windows had > "rpath", then SL would be split between HOST_SL and TARGET_SL.As it > stands, SL is HOST_SL.Consider as well the various versions of > Visual C++.They output mostly the same, very interoperable.Consider > optimization switches. Host or target?Consider version of gcc or > Visual C++? Host or target?Well, inevitably, the host has an affect > on the target. If not the for the host, the target would not even > exist. Bugs in the host produce bugs in the target. etc.(And > realize that Cygwin runs on top of an OS built witha Microsoft > compiler, so really there is interop, but sometimes through a > layer.) So there's a risk of saying there is six+ > combinations.(host cygwin, host mingwin, host native) x (target > nt386, target nt386gnu) But generally the host is assumed not a > factor. I guess "LIBC" could be seperated into several options...You > could actually have code that needs one runtime or another, and > they couldlink together, depending on what they do.. This is > something I don't know if cm3 handles, or anything I have seen. I > should be able to build a static .lib, that includes some C code, > that imbues its clients with build time dependencies. Well, I > guess #pragma comment(linker) is this.So the next tasks are > roughly: Merge my NT386 and NT386GNU files. Switching on a > variable such as backend mode. Introduce a "new" (old) NT386GNU > file, perhaps more like what was already there. Change NT386GNU > back to Posix. Build NT386GNU. oh, one more point...while these > are two targets from cm3's point of view, they are PROBABLY the > same target to cm3cgand so only one is needed. I have to check if > configure differentiates between i686-pc-cygwin and > i686-pc-mingwin...but I guess it should...It might actually be > profitable to have two bloated cm3cg.exe's.And they should ship to > \cm3\pkg\m3cc\target\host or host\target and cm3 should know which > to run.Blech..four of them when one would suffice?The detail being > mainly what the paths to .libs look like, unfortunate.Possibly cm3 > can bridge this gap using that "broken" feature that symlinks libs > into the target directory,using NTFS hard links, if installroot and > root are on the same volume... (or symlinks on Vista).Or maybe > convert the paths as appropriate, hacky, but saves an extra > cm3cg.exe which is good to avoid. (all the more reason to lump all > targets into one file, so that the host x target matrix collapses > to just one axis, host; andthen you can write stuff in > Perl/Python/Java/C# to collapse that to just one, except for the > underlying runtime/interpreter...) Oh, cm3cg isn't the issue. It is > always sitting in the correct directory and reads one file and > writes one file, no slashes.The issue is gcc as the linker. Again, > this is a host issue..and cm3 or the config file definitely should > do the translation. - Jay > > > From: jayk123 at hotmail.comTo: m3devel at elegosoft.comDate: Mon, 21 Jan > 2008 23:01:44 +0000Subject: [M3devel] platform/build_dir is a big > tuple? > > 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 -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Jan 22 15:29:04 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 22 Jan 2008 14:29:04 +0000 Subject: [M3devel] platform/build_dir is a big tuple? In-Reply-To: <20080122142922.k73w5es5j4gckso4@mail.elegosoft.com> References: <20080122142922.k73w5es5j4gckso4@mail.elegosoft.com> Message-ID: I know, I've heard it many times from smart people, but sorry I can't resist. I will strive for a balance. In particular I'm thinking NT386 sets a few globals as described include NT386.commonNT386GNU sets a few globals as described include NT386.commonNT386MINGNU sets a few globals as described include NT386.common NT386.common will not be the simplest. CM3 might know about a few more of these globals than it already does. Under the covers, there is already lots and lots and lots of complexity and always will be (look at the stuff I debugged, which I admit was half stupid since PM3 had half the diffs -- I didn't find their config file to see about the double alignment though, so I was stuck debugging that afaik). - Jay > Date: Tue, 22 Jan 2008 14:29:22 +0100> From: wagner at elegosoft.com> To: m3devel at elegosoft.com> Subject: Re: [M3devel] platform/build_dir is a big tuple?> > All this may be useful during development, but it is not really> useful for a software distribution to our users, I think.> > Nobody will understand it :-( We need to keep things more simple.> > We don't need to support everything out of the box. Instead, we should> offer some sensible default combinations of everyhing you describe.> > First of all: we don't distribute cross compilers (at least until now).> This is a special topic reserved for adding new platforms.> > Runtime and compilers used do not necessarily need to be distinguished> by target or build dir, in many cases different cm3.cfg may suffice.> > Until now, threading models are also no choice that needs to be> visible at this level. There's one default model for every target,> and the user can change it by recompiling.> > And if we should really agree that changing the target naming scheme> is a good idea, we should> > o use a systematic one with not more than 4 elements (better still,> 3 (e.g. --))> o don't use cryptic abbreviations that will confuse most people> > Just my 2 cents,> > Olaf> > Quoting Jay :> > I'm still torn over that any NT386 target could have a choice of > > three threading models (win32, pthread, vtalarm), two windowing > > libraries (ms, x), two (three) compilers (ms, mingwin, cygwin), two > > (three) linkers (ms, mingwn, cygwin), various runtimes (msvc various > > versions, cygwin, mingwin (discouraged)) etc.> >> > Appending a short string of unreadable bits to BUILD_DIR is very > > temptingin order to easily generate and test the combinatorial > > possibilities.> >> > backend: 0 integrated, 1 gcc already a setting (with four values)> >> > ccompiler/linker: 0 ms, 1 gcc (these could be split, and could > > allocate more bits...) maybe 00 ms, 01 cygwin, 10 ming maybe define > > enum up front that allows for watcom, metrowerks, digitalmars, llvm > > etc.> > maybe use a decimal digit for all these, and 0 is reserved, maybe.> >> > threading: 0 win32, 1 pthreads drop vtalarm, or use two bits?> >> > windowing: 0 ms, 1 x> >> > cruntime: 0 ms, 1 cyg There is also a ming runtime, discouraged > > There also really N ms runtimes, ming offers several: msvcrt.dll, > > msvcr70.dll, msvcr71.dll, msvcr80.dll, msvcr90.dll... but jmpbuf > > presumbly doesn't change again could allocate multiple bits..> >> > cruntime I guess determines oSTYPE Win32 or Posix, thoughit loses > > its meaning mostly, and X vs. not-X is usually decide the same...> >> > The three most common combinations: 00000 -- NT386 11111 -- > > NT386GNU 11000 -- NT386MINGNU> >> > but several others would work 11101 -- cygwin with native windowing > > 11011 -- cygwin with native threads 11001 -- cygwin with native > > threads and native windowing> > BUILD_DIR would be NT386-$(config)as a special case perhaps, the > > three commoncases could be translated to the above strings.> >> > But the underlying implementation would be a few bools/enums,and > > iterating through them would be easy, while special casingand > > skipping deemed invalid combinations, like ms runtime and > > pthreads,and possibly ms runtime and x windows.> > Really, it might surprise folks, but really, basically every single > > combination works.> > Compilers are very independent of headers and libs and headers and > > libs are very independent of compilers, aside from a few language > > extensions like __stdcall. You can generally mix runtimes in the > > same process, just as you can mix them on the same machine, you just > > need to be careful about what you pass to what. If you call fopen, > > be sure pass the result back to the matching fclose, malloc/free, > > etc. Startup code, to the extent that it matters, might be a > > problem, but really, just avoid C++ globals with > > constructors/destructors anyway, they are always a problem. Modula-3 > > has its own startup code, and if you were to write "main" in C and > > link in Modula-3 static .libs, that probably doesn't work...might > > actually be better to play into whatever the platform's C++ > > constructor story is, as problematic as they (probably always?) are > > -- i.e. unpredictable/hard-to-control ordering.> >> > (bad editing...and maybe use hex for compression..)> >> > Bringing back cminstall is almost interesting, to promptthe user, or > > probe their system, though Quake/cm3 can probe at runtime.if os == > > windows_nt system_cc | findstr version | findstr gcc else > > system_cc | findstr visual c++else system_cc | grep version | grep > > gcc else system_cc | grep visual c++end> >> > inefficient.> >> > anyway, I'll merge current NT386GNU into NT386 and make it chosehow > > to compile/link which are the main variables today.> > and then decide about cygwin, but probably do like the above, > > sinceit'll totally share code with NT386 except the naming > > conventionsand the removal of the -mno-cygwin switch..> >> > I know this seems overly complicated, but it should be > > exposableeasily enough to users by hiding the choices, presenting > > three basic ones,and still allow all the obvious and perhaps useful > > knobs, and iterating throughthe combinations, without creating a > > combinatorial explosion of source filesor Modula-3 or Quake code.> > ...Jay> >> >> > From: jayk123 at hotmail.comTo: m3devel at elegosoft.comDate: Tue, 22 Jan > > 2008 10:48:56 +0000Subject: Re: [M3devel] platform/build_dir is a > > big tuple?> >> >> > Final answer? I played around with this but just can't accept > > platforms/build_dirs like: ntx86msmsmscm3msn ntx86gccgcccm3cgmsn > > ntx86gccgcccm3cgxn ntx86-gggggmn ntx86-ggixn ntx86_mmmimmOk, I > > have one more name here, and then a bit of a change, or a stronger > > statement of something I had already said.NT386MINGNUOk, I think we > > (me!) are confusing host and target, MOSTLY.And cm3 might not have > > them quite divided appropriately.What is a "host"? What is a > > "target"?MinGWin and Visual C++ output similar results, targetingthe > > same runtime (usually), threading library, windowing library.There > > is a chance for exception handling to diverge however.Well, speaking > > of Visual C++ the C/C++ compiler and MinGWinthe gcc environment, > > yes, very different, not interoperable.MinGWin uses what gcc calls > > "sjlj" -- setjmp/longjmp exceptions.Very inefficient. But heck, gcc > > doesn't support __try/__except/__finally,only C++ exceptions, and > > interop of C++ is often not great,what with name mangling and > > all.NT386GNU's OUTPUT uses a different runtime, unless you trim > > dependencies, possibly a different threading library, possibly a > > different windowing library. All this probably configurable. Again > > exception handling is a sore point in that it is the primary C > > runtime dependency of Modula-3. If you use Cygwin but say > > -mno-cygwin, that means you are targeting NT386. (and don't use > > pthreads or X Windows; behavior of exceptions/setjmp/longjmp TBD -- > > really, need to not use the -mno-cygwin headers in that case; I'll > > check).Perhaps m3core.dll should export > > m3_setjmp/m3_longjmp..Either one can do a cross build to the > > other.Two cm3.exes, two sets of outputs, that either can > > produce.NT386 can use gcc or the integrated backend. And the gcc > > it uses can be MinGWin or Cygwin. (theoretically and probably soon > > reality) NT386GNU can use either as well! (also currently theory, > > but a real possibility) It isn't GNU tools, it is GNU runtime.One > > small area with cm3 might fall down just slightly is that of > > cross builds where host and target have different naming > > conventions. -lfoo vs. foo.lib, foo.o vs. foo.obj are an aspect > > of the host and I vaguely recall that cm3 ties naming convention > > to ostype. The appending of .exe is a target characteristics, but > > the others are not really. Naming convention is really a host > > thing and not a target thing.The config files are a mix of host and > > target information, mostly actually host, except for the one line > > that says TARGET. Most of the target variation is in cm3, which > > always can do any, and cm3cg (which might be nice to be similar, > > but that's another matter and not likely to ever change, except > > when AMD64 is the last architecture standing. :) )If Windows had > > "rpath", then SL would be split between HOST_SL and TARGET_SL.As it > > stands, SL is HOST_SL.Consider as well the various versions of > > Visual C++.They output mostly the same, very interoperable.Consider > > optimization switches. Host or target?Consider version of gcc or > > Visual C++? Host or target?Well, inevitably, the host has an affect > > on the target. If not the for the host, the target would not even > > exist. Bugs in the host produce bugs in the target. etc.(And > > realize that Cygwin runs on top of an OS built witha Microsoft > > compiler, so really there is interop, but sometimes through a > > layer.) So there's a risk of saying there is six+ > > combinations.(host cygwin, host mingwin, host native) x (target > > nt386, target nt386gnu) But generally the host is assumed not a > > factor. I guess "LIBC" could be seperated into several options...You > > could actually have code that needs one runtime or another, and > > they couldlink together, depending on what they do.. This is > > something I don't know if cm3 handles, or anything I have seen. I > > should be able to build a static .lib, that includes some C code, > > that imbues its clients with build time dependencies. Well, I > > guess #pragma comment(linker) is this.So the next tasks are > > roughly: Merge my NT386 and NT386GNU files. Switching on a > > variable such as backend mode. Introduce a "new" (old) NT386GNU > > file, perhaps more like what was already there. Change NT386GNU > > back to Posix. Build NT386GNU. oh, one more point...while these > > are two targets from cm3's point of view, they are PROBABLY the > > same target to cm3cgand so only one is needed. I have to check if > > configure differentiates between i686-pc-cygwin and > > i686-pc-mingwin...but I guess it should...It might actually be > > profitable to have two bloated cm3cg.exe's.And they should ship to > > \cm3\pkg\m3cc\target\host or host\target and cm3 should know which > > to run.Blech..four of them when one would suffice?The detail being > > mainly what the paths to .libs look like, unfortunate.Possibly cm3 > > can bridge this gap using that "broken" feature that symlinks libs > > into the target directory,using NTFS hard links, if installroot and > > root are on the same volume... (or symlinks on Vista).Or maybe > > convert the paths as appropriate, hacky, but saves an extra > > cm3cg.exe which is good to avoid. (all the more reason to lump all > > targets into one file, so that the host x target matrix collapses > > to just one axis, host; andthen you can write stuff in > > Perl/Python/Java/C# to collapse that to just one, except for the > > underlying runtime/interpreter...) Oh, cm3cg isn't the issue. It is > > always sitting in the correct directory and reads one file and > > writes one file, no slashes.The issue is gcc as the linker. Again, > > this is a host issue..and cm3 or the config file definitely should > > do the translation. - Jay> >> >> > From: jayk123 at hotmail.comTo: m3devel at elegosoft.comDate: Mon, 21 Jan > > 2008 23:01:44 +0000Subject: [M3devel] platform/build_dir is a big > > tuple?> >> > 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> > > > -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 Jan 22 17:54:37 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 22 Jan 2008 16:54:37 +0000 Subject: [M3devel] platform/build_dir is a big tuple? In-Reply-To: References: <20080122142922.k73w5es5j4gckso4@mail.elegosoft.com> Message-ID: This is essentially in now. I understand all those points, but there are pluses and minuses either way. Including: > 3 (e.g. --)) "variant", that's space for arbitrary variation, it's not one variable. This scheme acknowledges two common variables and leaves slush to try to cope with what else there is. Of course, it would be a big advance over what is there. And yes I realize you lose somehow one way or another. Anyway, if what I have is acceptable, or shows an acceptable direction that is *almost* complete (it is definitely not quite complete, since Cygwin isn't active yet), I can start winding down this topic. :) The scheme I have..I kind of already said this..TARGET will always be NT386, and it is configurable. Three of the configurations are recognized and given made up short readable build_dir.To me, from the user perspective, build_dir is a critical aspect of target, so you can kind of give the appearance of targets without adding full scale new targets, which I realize would be "ok". The rest, if you try them, get mechnical build_dir. What I haven't worked out yet is, like..before there was the TARGET/CM3_TARGET environment variables. Those should probably remain and get translated..which actually pretty much already works -- the environment variable will map not to a target, but to a config file name, and it will handle everything. I haven't tried this. I left the old targets for temporary compat. Later... arch-os-variant is fine I'd like to check what the four element gnu configurations. arch-os-variant won't apply for the two "new" targets I'm working on presumably, since they derive from the existing NT386. I assume given NT386, and essentially NT386GNU, nobody would argue for introducing I386_NT_MINGWIN or I386_NT_CYGWIN, but maybe. And yes I know, sorry, I'm being a bit of a jerk, asking for something, getting it, and then not taking it. If people do want I386_NT_MINGIN or X86_NT_MINGNU, ok with me. - Jay From: jayk123 at hotmail.comTo: wagner at elegosoft.com; m3devel at elegosoft.comDate: Tue, 22 Jan 2008 14:29:04 +0000Subject: Re: [M3devel] platform/build_dir is a big tuple? I know, I've heard it many times from smart people, but sorry I can't resist. I will strive for a balance. In particular I'm thinking NT386 sets a few globals as described include NT386.commonNT386GNU sets a few globals as described include NT386.commonNT386MINGNU sets a few globals as described include NT386.commonNT386.common will not be the simplest. CM3 might know about a few more of these globals than it already does. Under the covers, there is already lots and lots and lots of complexity and always will be (look at the stuff I debugged, which I admit was half stupid since PM3 had half the diffs -- I didn't find their config file to see about the double alignment though, so I was stuck debugging that afaik). - Jay > Date: Tue, 22 Jan 2008 14:29:22 +0100> From: wagner at elegosoft.com> To: m3devel at elegosoft.com> Subject: Re: [M3devel] platform/build_dir is a big tuple?> > All this may be useful during development, but it is not really> useful for a software distribution to our users, I think.> > Nobody will understand it :-( We need to keep things more simple.> > We don't need to support everything out of the box. Instead, we should> offer some sensible default combinations of everyhing you describe.> > First of all: we don't distribute cross compilers (at least until now).> This is a special topic reserved for adding new platforms.> > Runtime and compilers used do not necessarily need to be distinguished> by target or build dir, in many cases different cm3.cfg may suffice.> > Until now, threading models are also no choice that needs to be> visible at this level. There's one default model for every target,> and the user can change it by recompiling.> > And if we should really agree that changing the target naming scheme> is a good idea, we should> > o use a systematic one with not more than 4 elements (better still,> 3 (e.g. --))> o don't use cryptic abbreviations that will confuse most people> > Just my 2 cents,> > Olaf> > Quoting Jay :> > I'm still torn over that any NT386 target could have a choice of > > three threading models (win32, pthread, vtalarm), two windowing > > libraries (ms, x), two (three) compilers (ms, mingwin, cygwin), two > > (three) linkers (ms, mingwn, cygwin), various runtimes (msvc various > > versions, cygwin, mingwin (discouraged)) etc.> >> > Appending a short string of unreadable bits to BUILD_DIR is very > > temptingin order to easily generate and test the combinatorial > > possibilities.> >> > backend: 0 integrated, 1 gcc already a setting (with four values)> >> > ccompiler/linker: 0 ms, 1 gcc (these could be split, and could > > allocate more bits...) maybe 00 ms, 01 cygwin, 10 ming maybe define > > enum up front that allows for watcom, metrowerks, digitalmars, llvm > > etc.> > maybe use a decimal digit for all these, and 0 is reserved, maybe.> >> > threading: 0 win32, 1 pthreads drop vtalarm, or use two bits?> >> > windowing: 0 ms, 1 x> >> > cruntime: 0 ms, 1 cyg There is also a ming runtime, discouraged > > There also really N ms runtimes, ming offers several: msvcrt.dll, > > msvcr70.dll, msvcr71.dll, msvcr80.dll, msvcr90.dll... but jmpbuf > > presumbly doesn't change again could allocate multiple bits..> >> > cruntime I guess determines oSTYPE Win32 or Posix, thoughit loses > > its meaning mostly, and X vs. not-X is usually decide the same...> >> > The three most common combinations: 00000 -- NT386 11111 -- > > NT386GNU 11000 -- NT386MINGNU> >> > but several others would work 11101 -- cygwin with native windowing > > 11011 -- cygwin with native threads 11001 -- cygwin with native > > threads and native windowing> > BUILD_DIR would be NT386-$(config)as a special case perhaps, the > > three commoncases could be translated to the above strings.> >> > But the underlying implementation would be a few bools/enums,and > > iterating through them would be easy, while special casingand > > skipping deemed invalid combinations, like ms runtime and > > pthreads,and possibly ms runtime and x windows.> > Really, it might surprise folks, but really, basically every single > > combination works.> > Compilers are very independent of headers and libs and headers and > > libs are very independent of compilers, aside from a few language > > extensions like __stdcall. You can generally mix runtimes in the > > same process, just as you can mix them on the same machine, you just > > need to be careful about what you pass to what. If you call fopen, > > be sure pass the result back to the matching fclose, malloc/free, > > etc. Startup code, to the extent that it matters, might be a > > problem, but really, just avoid C++ globals with > > constructors/destructors anyway, they are always a problem. Modula-3 > > has its own startup code, and if you were to write "main" in C and > > link in Modula-3 static .libs, that probably doesn't work...might > > actually be better to play into whatever the platform's C++ > > constructor story is, as problematic as they (probably always?) are > > -- i.e. unpredictable/hard-to-control ordering.> >> > (bad editing...and maybe use hex for compression..)> >> > Bringing back cminstall is almost interesting, to promptthe user, or > > probe their system, though Quake/cm3 can probe at runtime.if os == > > windows_nt system_cc | findstr version | findstr gcc else > > system_cc | findstr visual c++else system_cc | grep version | grep > > gcc else system_cc | grep visual c++end> >> > inefficient.> >> > anyway, I'll merge current NT386GNU into NT386 and make it chosehow > > to compile/link which are the main variables today.> > and then decide about cygwin, but probably do like the above, > > sinceit'll totally share code with NT386 except the naming > > conventionsand the removal of the -mno-cygwin switch..> >> > I know this seems overly complicated, but it should be > > exposableeasily enough to users by hiding the choices, presenting > > three basic ones,and still allow all the obvious and perhaps useful > > knobs, and iterating throughthe combinations, without creating a > > combinatorial explosion of source filesor Modula-3 or Quake code.> > ...Jay> >> >> > From: jayk123 at hotmail.comTo: m3devel at elegosoft.comDate: Tue, 22 Jan > > 2008 10:48:56 +0000Subject: Re: [M3devel] platform/build_dir is a > > big tuple?> >> >> > Final answer? I played around with this but just can't accept > > platforms/build_dirs like: ntx86msmsmscm3msn ntx86gccgcccm3cgmsn > > ntx86gccgcccm3cgxn ntx86-gggggmn ntx86-ggixn ntx86_mmmimmOk, I > > have one more name here, and then a bit of a change, or a stronger > > statement of something I had already said.NT386MINGNUOk, I think we > > (me!) are confusing host and target, MOSTLY.And cm3 might not have > > them quite divided appropriately.What is a "host"? What is a > > "target"?MinGWin and Visual C++ output similar results, targetingthe > > same runtime (usually), threading library, windowing library.There > > is a chance for exception handling to diverge however.Well, speaking > > of Visual C++ the C/C++ compiler and MinGWinthe gcc environment, > > yes, very different, not interoperable.MinGWin uses what gcc calls > > "sjlj" -- setjmp/longjmp exceptions.Very inefficient. But heck, gcc > > doesn't support __try/__except/__finally,only C++ exceptions, and > > interop of C++ is often not great,what with name mangling and > > all.NT386GNU's OUTPUT uses a different runtime, unless you trim > > dependencies, possibly a different threading library, possibly a > > different windowing library. All this probably configurable. Again > > exception handling is a sore point in that it is the primary C > > runtime dependency of Modula-3. If you use Cygwin but say > > -mno-cygwin, that means you are targeting NT386. (and don't use > > pthreads or X Windows; behavior of exceptions/setjmp/longjmp TBD -- > > really, need to not use the -mno-cygwin headers in that case; I'll > > check).Perhaps m3core.dll should export > > m3_setjmp/m3_longjmp..Either one can do a cross build to the > > other.Two cm3.exes, two sets of outputs, that either can > > produce.NT386 can use gcc or the integrated backend. And the gcc > > it uses can be MinGWin or Cygwin. (theoretically and probably soon > > reality) NT386GNU can use either as well! (also currently theory, > > but a real possibility) It isn't GNU tools, it is GNU runtime.One > > small area with cm3 might fall down just slightly is that of > > cross builds where host and target have different naming > > conventions. -lfoo vs. foo.lib, foo.o vs. foo.obj are an aspect > > of the host and I vaguely recall that cm3 ties naming convention > > to ostype. The appending of .exe is a target characteristics, but > > the others are not really. Naming convention is really a host > > thing and not a target thing.The config files are a mix of host and > > target information, mostly actually host, except for the one line > > that says TARGET. Most of the target variation is in cm3, which > > always can do any, and cm3cg (which might be nice to be similar, > > but that's another matter and not likely to ever change, except > > when AMD64 is the last architecture standing. :) )If Windows had > > "rpath", then SL would be split between HOST_SL and TARGET_SL.As it > > stands, SL is HOST_SL.Consider as well the various versions of > > Visual C++.They output mostly the same, very interoperable.Consider > > optimization switches. Host or target?Consider version of gcc or > > Visual C++? Host or target?Well, inevitably, the host has an affect > > on the target. If not the for the host, the target would not even > > exist. Bugs in the host produce bugs in the target. etc.(And > > realize that Cygwin runs on top of an OS built witha Microsoft > > compiler, so really there is interop, but sometimes through a > > layer.) So there's a risk of saying there is six+ > > combinations.(host cygwin, host mingwin, host native) x (target > > nt386, target nt386gnu) But generally the host is assumed not a > > factor. I guess "LIBC" could be seperated into several options...You > > could actually have code that needs one runtime or another, and > > they couldlink together, depending on what they do.. This is > > something I don't know if cm3 handles, or anything I have seen. I > > should be able to build a static .lib, that includes some C code, > > that imbues its clients with build time dependencies. Well, I > > guess #pragma comment(linker) is this.So the next tasks are > > roughly: Merge my NT386 and NT386GNU files. Switching on a > > variable such as backend mode. Introduce a "new" (old) NT386GNU > > file, perhaps more like what was already there. Change NT386GNU > > back to Posix. Build NT386GNU. oh, one more point...while these > > are two targets from cm3's point of view, they are PROBABLY the > > same target to cm3cgand so only one is needed. I have to check if > > configure differentiates between i686-pc-cygwin and > > i686-pc-mingwin...but I guess it should...It might actually be > > profitable to have two bloated cm3cg.exe's.And they should ship to > > \cm3\pkg\m3cc\target\host or host\target and cm3 should know which > > to run.Blech..four of them when one would suffice?The detail being > > mainly what the paths to .libs look like, unfortunate.Possibly cm3 > > can bridge this gap using that "broken" feature that symlinks libs > > into the target directory,using NTFS hard links, if installroot and > > root are on the same volume... (or symlinks on Vista).Or maybe > > convert the paths as appropriate, hacky, but saves an extra > > cm3cg.exe which is good to avoid. (all the more reason to lump all > > targets into one file, so that the host x target matrix collapses > > to just one axis, host; andthen you can write stuff in > > Perl/Python/Java/C# to collapse that to just one, except for the > > underlying runtime/interpreter...) Oh, cm3cg isn't the issue. It is > > always sitting in the correct directory and reads one file and > > writes one file, no slashes.The issue is gcc as the linker. Again, > > this is a host issue..and cm3 or the config file definitely should > > do the translation. - Jay> >> >> > From: jayk123 at hotmail.comTo: m3devel at elegosoft.comDate: Mon, 21 Jan > > 2008 23:01:44 +0000Subject: [M3devel] platform/build_dir is a big > > tuple?> >> > 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> > > > -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 hosking at cs.purdue.edu Tue Jan 22 18:50:44 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 22 Jan 2008 12:50:44 -0500 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <20080122163601.6245410D4608@birch.elegosoft.com> References: <20080122163601.6245410D4608@birch.elegosoft.com> Message-ID: <9C3615E5-FEDB-4AAB-BFC7-AFE867C94241@cs.purdue.edu> Do we really want to build all the Windows interfaces even on non- Windows hosts? Yuck. On Jan 22, 2008, at 5:36 PM, Jay Krell wrote: > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 08/01/22 17:36:01 > > Modified files: > cm3/m3-sys/cm3/src/: M3Backend.m3 m3makefile > cm3/scripts/: backup-pkgs.sh boot-cm3-build-on-target.sh > boot-cm3-core.sh boot-cm3-with-m3.sh > copy-bootarchives.sh do-cm3-core.sh > make-bin-dist-min.sh pack-crossbuild.sh pkginfo.sh > Removed files: > cm3/m3-sys/cm3/src/: M3BackPosix.m3 M3BackWin32.m3 > > Log message: > put integrated backend into all hosts, so that cross builds work > a bit more; built on PPC_DARWIN (ie: built on Posix, where it's > an actual diff; what this will enable for me is a "semi-cros" > from a NT386GNU cm3.exe to NT386/NT386MINGNU. And it's fairly cheap, > the integrated backend is nothing compared to cm3cg. > did not run all the .sh files, just upgrade.sh > Note that m3staloneback is relatively unused, probably for > debugging, left alone. > mklib should come in as well for cross purposes but left that > alone too. > There are warnings in WinDef.m3 about <*WINAPI*> on function pointer > types. Perhaps they can be deferred and only trigger if the types > are used? If the types are called? ie: make the pragma understood, > but > don't support calling using calling conventions not supported by > target From hosking at cs.purdue.edu Tue Jan 22 18:54:04 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 22 Jan 2008 12:54:04 -0500 Subject: [M3devel] platform/build_dir is a big tuple? In-Reply-To: <20080122142922.k73w5es5j4gckso4@mail.elegosoft.com> References: <20080122142922.k73w5es5j4gckso4@mail.elegosoft.com> Message-ID: <2AB0D273-C3B8-4D46-BCC1-4D032692DCB0@cs.purdue.edu> On Jan 22, 2008, at 8:29 AM, Olaf Wagner wrote: > All this may be useful during development, but it is not really > useful for a software distribution to our users, I think. > > Nobody will understand it :-( We need to keep things more simple. > > We don't need to support everything out of the box. Instead, we should > offer some sensible default combinations of everyhing you describe. > > First of all: we don't distribute cross compilers (at least until > now). > This is a special topic reserved for adding new platforms. Precisely why I don't like many of the recent changes. I don't want to build Windows interfaces and gorp for a non-Windows platform. Jay, can you *please* back these changes out? > > Runtime and compilers used do not necessarily need to be distinguished > by target or build dir, in many cases different cm3.cfg may suffice. > > Until now, threading models are also no choice that needs to be > visible at this level. There's one default model for every target, > and the user can change it by recompiling. > > And if we should really agree that changing the target naming scheme > is a good idea, we should > > o use a systematic one with not more than 4 elements (better still, > 3 (e.g. --)) > o don't use cryptic abbreviations that will confuse most people > > Just my 2 cents, > > Olaf > > Quoting Jay : >> I'm still torn over that any NT386 target could have a choice of >> three threading models (win32, pthread, vtalarm), two windowing >> libraries (ms, x), two (three) compilers (ms, mingwin, cygwin), >> two (three) linkers (ms, mingwn, cygwin), various runtimes (msvc >> various versions, cygwin, mingwin (discouraged)) etc. >> >> Appending a short string of unreadable bits to BUILD_DIR is very >> temptingin order to easily generate and test the combinatorial >> possibilities. >> >> backend: 0 integrated, 1 gcc already a setting (with four values) >> >> ccompiler/linker: 0 ms, 1 gcc (these could be split, and could >> allocate more bits...) maybe 00 ms, 01 cygwin, 10 ming maybe >> define enum up front that allows for watcom, metrowerks, >> digitalmars, llvm etc. >> maybe use a decimal digit for all these, and 0 is reserved, maybe. >> >> threading: 0 win32, 1 pthreads drop vtalarm, or use two bits? >> >> windowing: 0 ms, 1 x >> >> cruntime: 0 ms, 1 cyg There is also a ming runtime, discouraged >> There also really N ms runtimes, ming offers several: >> msvcrt.dll, msvcr70.dll, msvcr71.dll, msvcr80.dll, >> msvcr90.dll... but jmpbuf presumbly doesn't change again could >> allocate multiple bits.. >> >> cruntime I guess determines oSTYPE Win32 or Posix, thoughit loses >> its meaning mostly, and X vs. not-X is usually decide the same... >> >> The three most common combinations: 00000 -- NT386 11111 -- >> NT386GNU 11000 -- NT386MINGNU >> >> but several others would work 11101 -- cygwin with native >> windowing 11011 -- cygwin with native threads 11001 -- cygwin >> with native threads and native windowing >> BUILD_DIR would be NT386-$(config)as a special case perhaps, the >> three commoncases could be translated to the above strings. >> >> But the underlying implementation would be a few bools/enums,and >> iterating through them would be easy, while special casingand >> skipping deemed invalid combinations, like ms runtime and >> pthreads,and possibly ms runtime and x windows. >> Really, it might surprise folks, but really, basically every >> single combination works. >> Compilers are very independent of headers and libs and headers >> and libs are very independent of compilers, aside from a few >> language extensions like __stdcall. You can generally mix >> runtimes in the same process, just as you can mix them on the >> same machine, you just need to be careful about what you pass to >> what. If you call fopen, be sure pass the result back to the >> matching fclose, malloc/free, etc. Startup code, to the extent >> that it matters, might be a problem, but really, just avoid C++ >> globals with constructors/destructors anyway, they are always a >> problem. Modula-3 has its own startup code, and if you were to >> write "main" in C and link in Modula-3 static .libs, that >> probably doesn't work...might actually be better to play into >> whatever the platform's C++ constructor story is, as problematic >> as they (probably always?) are -- i.e. unpredictable/hard-to- >> control ordering. >> >> (bad editing...and maybe use hex for compression..) >> >> Bringing back cminstall is almost interesting, to promptthe user, >> or probe their system, though Quake/cm3 can probe at runtime.if >> os == windows_nt system_cc | findstr version | findstr gcc >> else system_cc | findstr visual c++else system_cc | grep >> version | grep gcc else system_cc | grep visual c++end >> >> inefficient. >> >> anyway, I'll merge current NT386GNU into NT386 and make it >> chosehow to compile/link which are the main variables today. >> and then decide about cygwin, but probably do like the above, >> sinceit'll totally share code with NT386 except the naming >> conventionsand the removal of the -mno-cygwin switch.. >> >> I know this seems overly complicated, but it should be >> exposableeasily enough to users by hiding the choices, presenting >> three basic ones,and still allow all the obvious and perhaps >> useful knobs, and iterating throughthe combinations, without >> creating a combinatorial explosion of source filesor Modula-3 or >> Quake code. >> ...Jay >> >> >> From: jayk123 at hotmail.comTo: m3devel at elegosoft.comDate: Tue, 22 >> Jan 2008 10:48:56 +0000Subject: Re: [M3devel] platform/build_dir >> is a big tuple? >> >> >> Final answer? I played around with this but just can't accept >> platforms/build_dirs like: ntx86msmsmscm3msn >> ntx86gccgcccm3cgmsn ntx86gccgcccm3cgxn ntx86-gggggmn ntx86- >> ggixn ntx86_mmmimmOk, I have one more name here, and then a bit >> of a change, or a stronger statement of something I had already >> said.NT386MINGNUOk, I think we (me!) are confusing host and >> target, MOSTLY.And cm3 might not have them quite divided >> appropriately.What is a "host"? What is a "target"?MinGWin and >> Visual C++ output similar results, targetingthe same runtime >> (usually), threading library, windowing library.There is a chance >> for exception handling to diverge however.Well, speaking of >> Visual C++ the C/C++ compiler and MinGWinthe gcc environment, >> yes, very different, not interoperable.MinGWin uses what gcc >> calls "sjlj" -- setjmp/longjmp exceptions.Very inefficient. But >> heck, gcc doesn't support __try/__except/__finally,only C++ >> exceptions, and interop of C++ is often not great,what with name >> mangling and all.NT386GNU's OUTPUT uses a different runtime, >> unless you trim dependencies, possibly a different threading >> library, possibly a different windowing library. All this >> probably configurable. Again exception handling is a sore point >> in that it is the primary C runtime dependency of Modula-3. If >> you use Cygwin but say -mno-cygwin, that means you are targeting >> NT386. (and don't use pthreads or X Windows; behavior of >> exceptions/setjmp/longjmp TBD -- really, need to not use the - >> mno-cygwin headers in that case; I'll check).Perhaps m3core.dll >> should export m3_setjmp/m3_longjmp..Either one can do a cross >> build to the other.Two cm3.exes, two sets of outputs, that either >> can produce.NT386 can use gcc or the integrated backend. And the >> gcc it uses can be MinGWin or Cygwin. (theoretically and probably >> soon reality) NT386GNU can use either as well! (also currently >> theory, but a real possibility) It isn't GNU tools, it is GNU >> runtime.One small area with cm3 might fall down just slightly is >> that of cross builds where host and target have different >> naming conventions. -lfoo vs. foo.lib, foo.o vs. foo.obj are an >> aspect of the host and I vaguely recall that cm3 ties naming >> convention to ostype. The appending of .exe is a target >> characteristics, but the others are not really. Naming >> convention is really a host thing and not a target thing.The >> config files are a mix of host and target information, mostly >> actually host, except for the one line that says TARGET. Most of >> the target variation is in cm3, which always can do any, and >> cm3cg (which might be nice to be similar, but that's another >> matter and not likely to ever change, except when AMD64 is the >> last architecture standing. :) )If Windows had "rpath", then SL >> would be split between HOST_SL and TARGET_SL.As it stands, SL is >> HOST_SL.Consider as well the various versions of Visual C++.They >> output mostly the same, very interoperable.Consider optimization >> switches. Host or target?Consider version of gcc or Visual C++? >> Host or target?Well, inevitably, the host has an affect on the >> target. If not the for the host, the target would not even >> exist. Bugs in the host produce bugs in the target. etc.(And >> realize that Cygwin runs on top of an OS built witha Microsoft >> compiler, so really there is interop, but sometimes through a >> layer.) So there's a risk of saying there is six+ combinations. >> (host cygwin, host mingwin, host native) x (target nt386, target >> nt386gnu) But generally the host is assumed not a factor. I >> guess "LIBC" could be seperated into several options...You could >> actually have code that needs one runtime or another, and they >> couldlink together, depending on what they do.. This is something >> I don't know if cm3 handles, or anything I have seen. I should be >> able to build a static .lib, that includes some C code, that >> imbues its clients with build time dependencies. Well, I guess >> #pragma comment(linker) is this.So the next tasks are roughly: >> Merge my NT386 and NT386GNU files. Switching on a variable such >> as backend mode. Introduce a "new" (old) NT386GNU file, >> perhaps more like what was already there. Change NT386GNU back >> to Posix. Build NT386GNU. oh, one more point...while these are >> two targets from cm3's point of view, they are PROBABLY the same >> target to cm3cgand so only one is needed. I have to check if >> configure differentiates between i686-pc-cygwin and i686-pc- >> mingwin...but I guess it should...It might actually be profitable >> to have two bloated cm3cg.exe's.And they should ship to \cm3\pkg >> \m3cc\target\host or host\target and cm3 should know which to >> run.Blech..four of them when one would suffice?The detail being >> mainly what the paths to .libs look like, unfortunate.Possibly >> cm3 can bridge this gap using that "broken" feature that symlinks >> libs into the target directory,using NTFS hard links, if >> installroot and root are on the same volume... (or symlinks on >> Vista).Or maybe convert the paths as appropriate, hacky, but >> saves an extra cm3cg.exe which is good to avoid. (all the more >> reason to lump all targets into one file, so that the host x >> target matrix collapses to just one axis, host; andthen you can >> write stuff in Perl/Python/Java/C# to collapse that to just one, >> except for the underlying runtime/interpreter...) Oh, cm3cg isn't >> the issue. It is always sitting in the correct directory and >> reads one file and writes one file, no slashes.The issue is gcc >> as the linker. Again, this is a host issue..and cm3 or the config >> file definitely should do the translation. - Jay >> >> >> From: jayk123 at hotmail.comTo: m3devel at elegosoft.comDate: Mon, 21 >> Jan 2008 23:01:44 +0000Subject: [M3devel] platform/build_dir is a >> big tuple? >> >> 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 > > > > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, > Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 > 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: > Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > DE163214194 > From rcoleburn at scires.com Tue Jan 22 20:48:38 2008 From: rcoleburn at scires.com (Randy Coleburn) Date: Tue, 22 Jan 2008 14:48:38 -0500 Subject: [M3devel] next problem (NT386GNU) In-Reply-To: References: <6E1E4409-F3D9-4982-B179-2D4C9648FDD0@cs.purdue.edu> <1A6EC7D6-32B2-44AD-933F-6976040A7D7F@cs.purdue.edu> <20080122081049.74tzfvozwo4wwwow@mail.elegosoft.com> Message-ID: <47960244.1E75.00D7.1@scires.com> Jay / Olaf: I installed CVSNT and TortoiseCVS. I am having some trouble with "update" however. When I try to update the whole tree, it begins working, but after a little while I start seeing messages that checksums didn't match on certain files and that it will refetch. Then, after just a little longer, it stops responding. I've left it running for hours, but no new lines scroll by saying it is doing anything. Finally, I just hit cancel and it promptly stops and informs me it aborted the operation, as if it been waiting all along for me to tell it to give up. Now, if I update individual files or selected files, it seems to work no problem. And, I've been able to check out the whole repository, and yes it does take some time to pull everything down. I can also do diffs on selected files. I've also used it to commit a few files to the repository. So, it is working fine, except for update. Either something is amiss, or I'm not doing something just right. I am about to consider going back to cygwin and running its version of cvs on my tree to see if it will do the update, but I seem to recall reading somewhere that is not good to mix between cvs and cvsnt on the same tree. Jay, I too have used WinDiff for a long time. But, with the CVSNT and Tortoise installs, I also installed WinMerge. ( http://winmerge.org/ ) I'm still learning more about it, but so far, I have enjoyed it better than WinDiff because in addition to letting you see the diffs, it also lets you selectively merge diffs between the files using a GUI. It also integrates nicely with TortoiseCVS. Jay, you can get command line completion in Windows, but you have to make a registry tweak. There are actually two tweaks: one for filename completion and one for pathname completion. They are quite simple. See instructions below: Enable automatic completion for the computer as follows: a. Click Start, click Run, type regedit, and then click OK. b. Locate and click the HKEY_LOCAL_MACHINE\Software\Microsoft\Command Processor key c. Double-click the CompletionChar value and type 9 as the value; Windows converts it to hexadecimal. d. Double-click the PathCompletionChar value and type 9 as the value; Windows converts it to hexadecimal. e. Quit Registry Editor. Note that this modification allows you to press the TAB key while in a command prompt window in order to perform automatic filename and pathname completion. (You may have to restart or log in again before this modification will take affect.) Regards, Randy >>> Jay 1/22/2008 2:34 AM >>> Olaf, yes and no. How do I then bring the files into mainline? Which Tinderbox is testing them? This is impossible question probably, because Tinderbox for private changes probably doesn't scale well. But it would be nice. And other than private branches, submitting diffs would be nice. Or, as well, these can be crutches for bad changes, and people can abuse the Tinderbox. It's tough though, because a multi machine Tinderbox can always easily do much more diligence than one developer and his local machines. (What's the Win32 Tinderbox story, I wonder? I guess first I can see if Mozilla has one, and if not, it probably doesn't exist, if so, it does :) ) I don't mind the command line, but I'm a bit slow learning new tools. I find new source control systems daunting. I'm quite expert with Perforce though including branching, integrating, resolving, etc.. You don't have to be in Cygwin (sh) to use cvs, but it's true, one very annoying thing about all these forward-slash-requiring tools is I lose the usefulness of command line completion in cmd. Cmd is quite good at editing command lines, keeping output and command line history (set the scrollback to 9999), copy/paste, and is very fast, nothing else that I have tried competes. Most are even merely slower on their video output except maybe the actual text ones. The F8 feature, command line completion against history, which I can't explain well, is really great. MSys comes up with awful colors that I couldn't figure out how to change. Cygwin makes all your paths be /cygdrive/c/... which is just ugly and long. MSys/MinGWin are much nicer with merely /c... I installed TortoiseCVS but it didn't work..I need to look into how to get it to use ssh. But as well, if my work doesn't suck too much, it should be fine for mainline. Look at diffs is really also slow. I've done best by always saving away an .orig file and then windiff. Otherwise 1) is very slow 2) textual diffs...I use the command line all the time, but for viewing diffs...it's really insufficient. - Jay > Date: Tue, 22 Jan 2008 08:10:49 +0100 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] next problem (NT386GNU) > > Quoting Jay : > > > I don't want to deal with learning about CVS branches, please. > > I don't understand the problems some people seem to have with CVS. > Creating a branch is really simple: > > o create a branch tag, for example: > > cvs tag -b devel_nt386gnu_gcc_opt files(s) > > o update to that branch: > > cvs up -r devel_nt386gnu_gcc_opt files(s) > > That's it. The tag is now `sticky' on the files, i.e. remembered > in the CVS/Entries files in your workspace. From now on you're > using the branch for the mentioned files. To restore them to the > latest main trunk version, use > > cvs up -A files(s) > > And Jay, as a Windows user you probably don't like to use the cvs > commandline in Cygwin; just install CVS-NT and tortoise (Randy did, > too). It may be more convenient for you. > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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". Check it out. ( http://www.msnmobilefix.com/Default.aspx ) -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcoleburn at scires.com Tue Jan 22 21:03:45 2008 From: rcoleburn at scires.com (Randy Coleburn) Date: Tue, 22 Jan 2008 15:03:45 -0500 Subject: [M3devel] platform/build_dir is a big tuple? In-Reply-To: References: Message-ID: <479605CF.1E75.00D7.1@scires.com> Jay: For my part on Windows, I am happy to stay with the underlying OS, the native windows threading, the integrated backend, and use the free Microsoft Visual Studio tools. I don't really want to have to install/use cygwin or any of the other variants. When I see target = NT386, this list is what I am expecting. For the cm3 newbie coming from a Microsoft Windows environment, I think this list would be the most appealing and pose the least barrier to getting starting. Yes, I still will work on the installer program once I'm satisfied that I have a good working cm3 on Windows. Of course, I am just one voice. If you can and want to provide for all of the other variants on windows, that is ok with me. Just don't do away with what I have now. Regards, Randy >>> Jay 1/22/2008 8:00 AM >>> I'm still torn over that any NT386 target could have a choice of three threading models (win32, pthread, vtalarm), two windowing libraries (ms, x), two (three) compilers (ms, mingwin, cygwin), two (three) linkers (ms, mingwn, cygwin), various runtimes (msvc various versions, cygwin, mingwin (discouraged)) etc. Appending a short string of unreadable bits to BUILD_DIR is very tempting in order to easily generate and test the combinatorial possibilities. backend: 0 integrated, 1 gcc already a setting (with four values) ccompiler/linker: 0 ms, 1 gcc (these could be split, and could allocate more bits...) maybe 00 ms, 01 cygwin, 10 ming maybe define enum up front that allows for watcom, metrowerks, digitalmars, llvm etc. maybe use a decimal digit for all these, and 0 is reserved, maybe. threading: 0 win32, 1 pthreads drop vtalarm, or use two bits? windowing: 0 ms, 1 x cruntime: 0 ms, 1 cyg There is also a ming runtime, discouraged There also really N ms runtimes, ming offers several: msvcrt.dll, msvcr70.dll, msvcr71.dll, msvcr80.dll, msvcr90.dll... but jmpbuf presumbly doesn't change again could allocate multiple bits.. cruntime I guess determines oSTYPE Win32 or Posix, though it loses its meaning mostly, and X vs. not-X is usually decide the same... The three most common combinations: 00000 -- NT386 11111 -- NT386GNU 11000 -- NT386MINGNU but several others would work 11101 -- cygwin with native windowing 11011 -- cygwin with native threads 11001 -- cygwin with native threads and native windowing BUILD_DIR would be NT386-$(config) as a special case perhaps, the three common cases could be translated to the above strings. But the underlying implementation would be a few bools/enums, and iterating through them would be easy, while special casing and skipping deemed invalid combinations, like ms runtime and pthreads, and possibly ms runtime and x windows. Really, it might surprise folks, but really, basically every single combination works. Compilers are very independent of headers and libs and headers and libs are very independent of compilers, aside from a few language extensions like __stdcall. You can generally mix runtimes in the same process, just as you can mix them on the same machine, you just need to be careful about what you pass to what. If you call fopen, be sure pass the result back to the matching fclose, malloc/free, etc. Startup code, to the extent that it matters, might be a problem, but really, just avoid C++ globals with constructors/destructors anyway, they are always a problem. Modula-3 has its own startup code, and if you were to write "main" in C and link in Modula-3 static .libs, that probably doesn't work...might actually be better to play into whatever the platform's C++ constructor story is, as problematic as they (probably always?) are -- i.e. unpredictable/hard-to-control ordering. (bad editing...and maybe use hex for compression..) Bringing back cminstall is almost interesting, to prompt the user, or probe their system, though Quake/cm3 can probe at runtime. if os == windows_nt system_cc | findstr version | findstr gcc else system_cc | findstr visual c++ else system_cc | grep version | grep gcc else system_cc | grep visual c++ end inefficient. anyway, I'll merge current NT386GNU into NT386 and make it chose how to compile/link which are the main variables today. and then decide about cygwin, but probably do like the above, since it'll totally share code with NT386 except the naming conventions and the removal of the -mno-cygwin switch.. I know this seems overly complicated, but it should be exposable easily enough to users by hiding the choices, presenting three basic ones, and still allow all the obvious and perhaps useful knobs, and iterating through the combinations, without creating a combinatorial explosion of source files or Modula-3 or Quake code. ...Jay From: jayk123 at hotmail.com To: m3devel at elegosoft.com Date: Tue, 22 Jan 2008 10:48:56 +0000 Subject: Re: [M3devel] platform/build_dir is a big tuple? Final answer? I played around with this but just can't accept platforms/build_dirs like: ntx86msmsmscm3msn ntx86gccgcccm3cgmsn ntx86gccgcccm3cgxn ntx86-gggggmn ntx86-ggixn ntx86_mmmimm Ok, I have one more name here, and then a bit of a change, or a stronger statement of something I had already said. NT386MINGNU Ok, I think we (me!) are confusing host and target, MOSTLY. And cm3 might not have them quite divided appropriately. What is a "host"? What is a "target"? MinGWin and Visual C++ output similar results, targeting the same runtime (usually), threading library, windowing library. There is a chance for exception handling to diverge however. Well, speaking of Visual C++ the C/C++ compiler and MinGWin the gcc environment, yes, very different, not interoperable. MinGWin uses what gcc calls "sjlj" -- setjmp/longjmp exceptions. Very inefficient. But heck, gcc doesn't support __try/__except/__finally, only C++ exceptions, and interop of C++ is often not great, what with name mangling and all. NT386GNU's OUTPUT uses a different runtime, unless you trim dependencies, possibly a different threading library, possibly a different windowing library. All this probably configurable. Again exception handling is a sore point in that it is the primary C runtime dependency of Modula-3. If you use Cygwin but say -mno-cygwin, that means you are targeting NT386. (and don't use pthreads or X Windows; behavior of exceptions/setjmp/longjmp TBD -- really, need to not use the -mno-cygwin headers in that case; I'll check). Perhaps m3core.dll should export m3_setjmp/m3_longjmp.. Either one can do a cross build to the other. Two cm3.exes, two sets of outputs, that either can produce. NT386 can use gcc or the integrated backend. And the gcc it uses can be MinGWin or Cygwin. (theoretically and probably soon reality) NT386GNU can use either as well! (also currently theory, but a real possibility) It isn't GNU tools, it is GNU runtime. One small area with cm3 might fall down just slightly is that of cross builds where host and target have different naming conventions. -lfoo vs. foo.lib, foo.o vs. foo.obj are an aspect of the host and I vaguely recall that cm3 ties naming convention to ostype. The appending of .exe is a target characteristics, but the others are not really. Naming convention is really a host thing and not a target thing. The config files are a mix of host and target information, mostly actually host, except for the one line that says TARGET. Most of the target variation is in cm3, which always can do any, and cm3cg (which might be nice to be similar, but that's another matter and not likely to ever change, except when AMD64 is the last architecture standing. :) ) If Windows had "rpath", then SL would be split between HOST_SL and TARGET_SL. As it stands, SL is HOST_SL. Consider as well the various versions of Visual C++. They output mostly the same, very interoperable. Consider optimization switches. Host or target? Consider version of gcc or Visual C++? Host or target? Well, inevitably, the host has an affect on the target. If not the for the host, the target would not even exist. Bugs in the host produce bugs in the target. etc. (And realize that Cygwin runs on top of an OS built with a Microsoft compiler, so really there is interop, but sometimes through a layer.) So there's a risk of saying there is six+ combinations. (host cygwin, host mingwin, host native) x (target nt386, target nt386gnu) But generally the host is assumed not a factor. I guess "LIBC" could be seperated into several options... You could actually have code that needs one runtime or another, and they could link together, depending on what they do.. This is something I don't know if cm3 handles, or anything I have seen. I should be able to build a static .lib, that includes some C code, that imbues its clients with build time dependencies. Well, I guess #pragma comment(linker) is this. So the next tasks are roughly: Merge my NT386 and NT386GNU files. Switching on a variable such as backend mode. Introduce a "new" (old) NT386GNU file, perhaps more like what was already there. Change NT386GNU back to Posix. Build NT386GNU. oh, one more point...while these are two targets from cm3's point of view, they are PROBABLY the same target to cm3cg and so only one is needed. I have to check if configure differentiates between i686-pc-cygwin and i686-pc-mingwin... but I guess it should... It might actually be profitable to have two bloated cm3cg.exe's. And they should ship to \cm3\pkg\m3cc\target\host or host\target and cm3 should know which to run. Blech..four of them when one would suffice? The detail being mainly what the paths to .libs look like, unfortunate. Possibly cm3 can bridge this gap using that "broken" feature that symlinks libs into the target directory, using NTFS hard links, if installroot and root are on the same volume... (or symlinks on Vista). Or maybe convert the paths as appropriate, hacky, but saves an extra cm3cg.exe which is good to avoid. (all the more reason to lump all targets into one file, so that the host x target matrix collapses to just one axis, host; and then you can write stuff in Perl/Python/Java/C# to collapse that to just one, except for the underlying runtime/interpreter...) Oh, cm3cg isn't the issue. It is always sitting in the correct directory and reads one file and writes one file, no slashes. The issue is gcc as the linker. Again, this is a host issue..and cm3 or the config file definitely should do the translation. - Jay From: jayk123 at hotmail.com To: m3devel at elegosoft.com Date: Mon, 21 Jan 2008 23:01:44 +0000 Subject: [M3devel] platform/build_dir is a big tuple? 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 wagner at elegosoft.com Tue Jan 22 23:48:06 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 22 Jan 2008 23:48:06 +0100 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <9C3615E5-FEDB-4AAB-BFC7-AFE867C94241@cs.purdue.edu> References: <20080122163601.6245410D4608@birch.elegosoft.com> <9C3615E5-FEDB-4AAB-BFC7-AFE867C94241@cs.purdue.edu> Message-ID: <20080122234806.me1n09816o08gc80@mail.elegosoft.com> Quoting Tony Hosking : > Do we really want to build all the Windows interfaces even on > non-Windows hosts? Yuck. I'd suggest to build that conditional, Jay. Olaf > On Jan 22, 2008, at 5:36 PM, Jay Krell wrote: > >> CVSROOT: /usr/cvs >> Changes by: jkrell at birch. 08/01/22 17:36:01 >> >> Modified files: >> cm3/m3-sys/cm3/src/: M3Backend.m3 m3makefile >> cm3/scripts/: backup-pkgs.sh boot-cm3-build-on-target.sh >> boot-cm3-core.sh boot-cm3-with-m3.sh >> copy-bootarchives.sh do-cm3-core.sh >> make-bin-dist-min.sh pack-crossbuild.sh pkginfo.sh >> Removed files: >> cm3/m3-sys/cm3/src/: M3BackPosix.m3 M3BackWin32.m3 >> >> Log message: >> put integrated backend into all hosts, so that cross builds work >> a bit more; built on PPC_DARWIN (ie: built on Posix, where it's >> an actual diff; what this will enable for me is a "semi-cros" >> from a NT386GNU cm3.exe to NT386/NT386MINGNU. And it's fairly cheap, >> the integrated backend is nothing compared to cm3cg. >> did not run all the .sh files, just upgrade.sh >> Note that m3staloneback is relatively unused, probably for >> debugging, left alone. >> mklib should come in as well for cross purposes but left that alone too. >> There are warnings in WinDef.m3 about <*WINAPI*> on function pointer >> types. Perhaps they can be deferred and only trigger if the types >> are used? If the types are called? ie: make the pragma understood, but >> don't support calling using calling conventions not supported by target -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Jan 23 00:04:35 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 23 Jan 2008 00:04:35 +0100 Subject: [M3devel] next problem (NT386GNU) In-Reply-To: <47960244.1E75.00D7.1@scires.com> References: <6E1E4409-F3D9-4982-B179-2D4C9648FDD0@cs.purdue.edu> <1A6EC7D6-32B2-44AD-933F-6976040A7D7F@cs.purdue.edu> <20080122081049.74tzfvozwo4wwwow@mail.elegosoft.com> <47960244.1E75.00D7.1@scires.com> Message-ID: <20080123000435.kjtci5bewwcss448@mail.elegosoft.com> Quoting Randy Coleburn : > Jay / Olaf: > > I installed CVSNT and TortoiseCVS. I am having some trouble with > "update" however. When I try to update the whole tree, it begins > working, but after a little while I start seeing messages that checksums > didn't match on certain files and that it will refetch. Then, after > just a little longer, it stops responding. I've left it running for > hours, but no new lines scroll by saying it is doing anything. Finally, > I just hit cancel and it promptly stops and informs me it aborted the > operation, as if it been waiting all along for me to tell it to give > up. > > Now, if I update individual files or selected files, it seems to work > no problem. And, I've been able to check out the whole repository, and > yes it does take some time to pull everything down. I can also do diffs > on selected files. I've also used it to commit a few files to the > repository. > > So, it is working fine, except for update. Either something is amiss, > or I'm not doing something just right. I am about to consider going > back to cygwin and running its version of cvs on my tree to see if it > will do the update, but I seem to recall reading somewhere that is not > good to mix between cvs and cvsnt on the same tree. This is strange. I've never seen that myself before. A complete update or checkout should take several minutes via encrypted TCP/IP, but not longer (depending on the line bandwidth and latency, of course). Just today I've heard of a customer who suffers from random connection problems with Subversion and Windows 2000 workstations; the theory there being that some TCP/IP parameters are set very strange and the whole protocol stack is not up to the task in its default configuration. This does not happen on XT or Vista, though, who seem to have incorporated significant improvements. (It's all rather strange to me, since I'm a Unix person myself and used to stable networking.) So depending on your OS you might want to tweak the TCP parameters a little bit to see if it improves. Hard-core debugging of this problem will need careful use of tcpdump and produce megabytes of logs; but perhaps just using the cvs trace option (cvs -t up ...) will give some indication if there's another problem than the underlying connection. There's also nothing against checking out a different workspace with the Cygwin cvs to see if that works better. We've made good experiences with CVSNT though. If the problem persists, we could also try to do some tcpdumping on the server side (Ronny Forberger would be the one to do it), but this will take some preparation time. @Ronny, perhaps you've got another idea? 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 ronny.forberger at elegosoft.com Wed Jan 23 00:53:02 2008 From: ronny.forberger at elegosoft.com (Ronny Forberger) Date: Wed, 23 Jan 2008 00:53:02 +0100 Subject: [M3devel] next problem (NT386GNU) In-Reply-To: <20080123000435.kjtci5bewwcss448@mail.elegosoft.com> References: <6E1E4409-F3D9-4982-B179-2D4C9648FDD0@cs.purdue.edu> <1A6EC7D6-32B2-44AD-933F-6976040A7D7F@cs.purdue.edu> <20080122081049.74tzfvozwo4wwwow@mail.elegosoft.com> <47960244.1E75.00D7.1@scires.com> <20080123000435.kjtci5bewwcss448@mail.elegosoft.com> Message-ID: <479681DE.8020104@elegosoft.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Olaf Wagner schrieb: > Quoting Randy Coleburn : > >> Jay / Olaf: >> >> I installed CVSNT and TortoiseCVS. I am having some trouble with >> "update" however. When I try to update the whole tree, it begins >> working, but after a little while I start seeing messages that >> checksums >> didn't match on certain files and that it will refetch. Then, after >> just a little longer, it stops responding. I've left it running for >> hours, but no new lines scroll by saying it is doing anything. >> Finally, >> I just hit cancel and it promptly stops and informs me it aborted the >> operation, as if it been waiting all along for me to tell it to give >> up. >> >> Now, if I update individual files or selected files, it seems to work >> no problem. And, I've been able to check out the whole repository, >> and >> yes it does take some time to pull everything down. I can also do >> diffs >> on selected files. I've also used it to commit a few files to the >> repository. >> >> So, it is working fine, except for update. Either something is amiss, >> or I'm not doing something just right. I am about to consider going >> back to cygwin and running its version of cvs on my tree to see if it >> will do the update, but I seem to recall reading somewhere that is not >> good to mix between cvs and cvsnt on the same tree. > > This is strange. I've never seen that myself before. A complete > update or checkout should take several minutes via encrypted > TCP/IP, but not longer (depending on the line bandwidth and latency, > of course). > > Just today I've heard of a customer who suffers from random connection > problems with Subversion and Windows 2000 workstations; the theory > there > being that some TCP/IP parameters are set very strange and the whole > protocol stack is not up to the task in its default configuration. > This does not happen on XT or Vista, though, who seem to have > incorporated > significant improvements. (It's all rather strange to me, since I'm a > Unix person myself and used to stable networking.) > > So depending on your OS you might want to tweak the TCP parameters a > little bit to see if it improves. Hard-core debugging of this problem > will need careful use of tcpdump and produce megabytes of logs; > but perhaps just using the cvs trace option (cvs -t up ...) will > give some indication if there's another problem than the underlying > connection. > > There's also nothing against checking out a different workspace > with the Cygwin cvs to see if that works better. We've made good > experiences with CVSNT though. > > If the problem persists, we could also try to do some tcpdumping on > the server side (Ronny Forberger would be the one to do it), but this > will take some preparation time. > > @Ronny, perhaps you've got another idea? Maybe try to enable debug mode on the cvs core programme (cvsnt). Not sure if dumping network traffic might help. You can also watch the cvs command running by logging on to modula3.elegosoft.com via ssh. You should really first check quality of your network connection to modula3.elegosoft.com and possibly try if update works with other implentations of cvs. Cheers, 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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHloHdXa9RCz+1wnMRAi7uAKCLvz8DqU/SeiHr/2FGum0BWOLHNACgl6R8 mk+bxc060/81T2l4IUwpEQU= =Xe1T -----END PGP SIGNATURE----- From jayk123 at hotmail.com Wed Jan 23 03:49:26 2008 From: jayk123 at hotmail.com (Jay) Date: Wed, 23 Jan 2008 02:49:26 +0000 Subject: [M3devel] enum for backend mode? In-Reply-To: <2AB0D273-C3B8-4D46-BCC1-4D032692DCB0@cs.purdue.edu> References: <20080122142922.k73w5es5j4gckso4@mail.elegosoft.com> <2AB0D273-C3B8-4D46-BCC1-4D032692DCB0@cs.purdue.edu> Message-ID: I'll be passing around backend mode a little more. Should we make it an enum? Good names are hard to come up with here. Here's my lame strawman: BackendMode = { IntegratedProducesObject, IntegratedProducedAssembly, QuakeProducesObject, QuakeProducesAssembly }; I have these changes almost done but am going to remove them pending discussion. I don't really like these names. They are long and still not all clear. Long would be ok if they were perfectly clear, imho. These names do correlate well with the nearby comments, which get roughly repeated for every use of the magic numbers. "quake" is usually called "m3back" or such, the name of the Quake function. I find both descriptions a bit short and therefore unclear. I don't think IntegratedProducingAssembly and QuakeProducingObject "really" exist. There is m3staloneback -- QuakeProducingObject or Assembly, and the code is available for IntegratedProducingAssembly, I guess esp. for debugging, but you can just as well link /dump /disasm -- but I don't think these are really in use. Therefore, perhaps merely Object and Assembly, though Integrated vs. not is a significant aspect not represented.. - 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 Wed Jan 23 04:33:24 2008 From: jayk123 at hotmail.com (Jay) Date: Wed, 23 Jan 2008 03:33:24 +0000 Subject: [M3devel] platform/build_dir is a big tuple? In-Reply-To: <2AB0D273-C3B8-4D46-BCC1-4D032692DCB0@cs.purdue.edu> References: <20080122142922.k73w5es5j4gckso4@mail.elegosoft.com> <2AB0D273-C3B8-4D46-BCC1-4D032692DCB0@cs.purdue.edu> Message-ID: Ok now? It's just types and the warnings should be gone. ps: I think all compilers should be cross-capable in one executable if that is easy. CM3 is, except for the missing integrated backend and mklib. Others like Java are. Not easy with gcc/cm3cg darn which makes some of CM3's functionality moot. And the missing linker... - Jay > From: hosking at cs.purdue.edu> > Precisely why I don't like many of the recent changes. I don't want > to build Windows interfaces and gorp for a non-Windows platform. > Jay, can you *please* back these changes 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 jayk123 at hotmail.com Wed Jan 23 04:45:44 2008 From: jayk123 at hotmail.com (Jay) Date: Wed, 23 Jan 2008 03:45:44 +0000 Subject: [M3devel] pixmap problem In-Reply-To: <20080120204831.81poj3gg0084o0g0@mail.elegosoft.com> References: Your message of "Sat, 19 Jan 2008 17:54:00 +0100." <235688.77597.qm@web27110.mail.ukl.yahoo.com> <200801200341.m0K3feKM023564@camembert.async.caltech.edu> <47935664.1E75.00D7.1@scires.com> <20080120204831.81poj3gg0084o0g0@mail.elegosoft.com> Message-ID: Please give me a few days on the NT386/GNU stuff first, thanks. - Jay > Date: Sun, 20 Jan 2008 20:48:31 +0100> From: wagner at elegosoft.com> To: m3devel at elegosoft.com> Subject: Re: [M3devel] pixmap problem> > Quoting Randy Coleburn :> > > Mika / Daniel: Thanks for the test info!> >> > Well, based on what ya'll are reporting, I think the problem has to do> > with the NT386 platform. I also don't think it has to do necessarily> > with the source code. So, there must be something fishy going on in the> > NT386 world in the linkage step to cause this type of situation when> > switching between regular and buildstandalone().> > I must have missed that, browsing the lots of mails on this list> recently ;-)> > > Unfortunately, I'm probably not the right person to figure out what is> > wrong and fix it either. Hey, but at least I produced a short test> > program that reproduces the problem.> > This is often the more difficult part.> > > Maybe Jay or someone can offer another suggestion on how to fix it.> > I think Jay is the well capable of finding out what's going wrong there.> Let's wait for him.> > Olaf> -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 hosking at cs.purdue.edu Wed Jan 23 05:51:48 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 22 Jan 2008 23:51:48 -0500 Subject: [M3devel] platform/build_dir is a big tuple? In-Reply-To: References: <20080122142922.k73w5es5j4gckso4@mail.elegosoft.com> <2AB0D273-C3B8-4D46-BCC1-4D032692DCB0@cs.purdue.edu> Message-ID: <4BF6B109-55C1-4B71-830D-3B61219CF66F@cs.purdue.edu> Hmm, perhaps I overreacted. :-) On Jan 22, 2008, at 10:33 PM, Jay wrote: > Ok now? It's just types and the warnings should be gone. > > ps: I think all compilers should be cross-capable in one executable > if that is easy. CM3 is, except > for the missing integrated backend and mklib. > Others like Java are. Not easy with gcc/cm3cg darn which makes some > of CM3's functionality moot. > And the missing linker... > > - Jay > > From: hosking at cs.purdue.edu > > > > Precisely why I don't like many of the recent changes. I don't want > > to build Windows interfaces and gorp for a non-Windows platform. > > Jay, can you *please* back these changes out? > > Need to know the score, the latest news, or you need your Hotmail?- > get your "fix". Check it out. From jayk123 at hotmail.com Wed Jan 23 06:26:06 2008 From: jayk123 at hotmail.com (Jay) Date: Wed, 23 Jan 2008 05:26:06 +0000 Subject: [M3devel] next problem (NT386GNU) In-Reply-To: <479681DE.8020104@elegosoft.com> References: <6E1E4409-F3D9-4982-B179-2D4C9648FDD0@cs.purdue.edu> <1A6EC7D6-32B2-44AD-933F-6976040A7D7F@cs.purdue.edu> <20080122081049.74tzfvozwo4wwwow@mail.elegosoft.com> <47960244.1E75.00D7.1@scires.com> <20080123000435.kjtci5bewwcss448@mail.elegosoft.com> <479681DE.8020104@elegosoft.com> Message-ID: Here's a little Windows hack?trick?technique from memory for dividing down long running commands that might help. in_each_dir.cmd for /f %%a in ('dir /b /ad') do cd %%a && %* cd %CVSROOT% in_each_dir cvs update -dAP If the problem is one that you merely want to parallelize with a possible loss in logging, because it is actually a reliable but slow and parallelizable operation, you can do like: in_each_dir start cvs update -dAP or in_each_dir start /min cvs update -dAP That doesn't seem the case here so just use it serially. I'm quite proud of this one line of cmd. :) (while at the time..cmd stinks...) Could it be newlines vs. carriagereturn-newlines? I find checkouts takes a while, but heck, I'm using wireless and often forget -z3. My CVS knowledge continues to be lame..something like cvs -z3 checkout cm3/scripts as a way to limit the initial checkout and then cd %CM3_ROOT% for %a in (m3-sys m3-libs m3-ui etc.) do cvs update -dAP %a to do it piecemeal. See, what I'd like is to get either all the toplevel directories but empty, or all the directories but no files, so I can use in_each_dir to enumerate. A more complete solution that logs each command to its own file and combines the exit codes is left as an exercise. :) I've never debugged networking stuff and hope never to. I recently installed the Windows network tracing free download thingy for the first time, I forget why, didn't use it much, and have since reinstalled the OS and don't plan on reinstalling the tracer. It did appear quite nice, flexible, great gui for forming filters and such, etc... TortoiseSVN has worked fine for me, on a small tree. I will try TortoiseCVS again some time. I think I didn't tell it about ssh. - Jay > Date: Wed, 23 Jan 2008 00:53:02 +0100> From: ronny.forberger at elegosoft.com> To: rcoleburn at scires.com> CC: m3devel at elegosoft.com; jayk123 at hotmail.com> Subject: Re: [M3devel] next problem (NT386GNU)> > -----BEGIN PGP SIGNED MESSAGE-----> Hash: SHA1> > Olaf Wagner schrieb:> > Quoting Randy Coleburn :> >> >> Jay / Olaf:> >>> >> I installed CVSNT and TortoiseCVS. I am having some trouble with> >> "update" however. When I try to update the whole tree, it begins> >> working, but after a little while I start seeing messages that> >> checksums> >> didn't match on certain files and that it will refetch. Then, after> >> just a little longer, it stops responding. I've left it running for> >> hours, but no new lines scroll by saying it is doing anything.> >> Finally,> >> I just hit cancel and it promptly stops and informs me it aborted the> >> operation, as if it been waiting all along for me to tell it to give> >> up.> >>> >> Now, if I update individual files or selected files, it seems to work> >> no problem. And, I've been able to check out the whole repository,> >> and> >> yes it does take some time to pull everything down. I can also do> >> diffs> >> on selected files. I've also used it to commit a few files to the> >> repository.> >>> >> So, it is working fine, except for update. Either something is amiss,> >> or I'm not doing something just right. I am about to consider going> >> back to cygwin and running its version of cvs on my tree to see if it> >> will do the update, but I seem to recall reading somewhere that is not> >> good to mix between cvs and cvsnt on the same tree.> >> > This is strange. I've never seen that myself before. A complete> > update or checkout should take several minutes via encrypted> > TCP/IP, but not longer (depending on the line bandwidth and latency,> > of course).> >> > Just today I've heard of a customer who suffers from random connection> > problems with Subversion and Windows 2000 workstations; the theory> > there> > being that some TCP/IP parameters are set very strange and the whole> > protocol stack is not up to the task in its default configuration.> > This does not happen on XT or Vista, though, who seem to have> > incorporated> > significant improvements. (It's all rather strange to me, since I'm a> > Unix person myself and used to stable networking.)> >> > So depending on your OS you might want to tweak the TCP parameters a> > little bit to see if it improves. Hard-core debugging of this problem> > will need careful use of tcpdump and produce megabytes of logs;> > but perhaps just using the cvs trace option (cvs -t up ...) will> > give some indication if there's another problem than the underlying> > connection.> >> > There's also nothing against checking out a different workspace> > with the Cygwin cvs to see if that works better. We've made good> > experiences with CVSNT though.> >> > If the problem persists, we could also try to do some tcpdumping on> > the server side (Ronny Forberger would be the one to do it), but this> > will take some preparation time.> >> > @Ronny, perhaps you've got another idea?> Maybe try to enable debug mode on the cvs core programme (cvsnt). Not> sure if dumping network traffic might help. You can also watch the cvs> command running by logging on to modula3.elegosoft.com via ssh.> > You should really first check quality of your network connection to> modula3.elegosoft.com and possibly try if update works with other> implentations of cvs.> > Cheers,> > 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> -----BEGIN PGP SIGNATURE-----> Version: GnuPG v1.4.6 (GNU/Linux)> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org> > iD8DBQFHloHdXa9RCz+1wnMRAi7uAKCLvz8DqU/SeiHr/2FGum0BWOLHNACgl6R8> mk+bxc060/81T2l4IUwpEQU=> =Xe1T> -----END PGP SIGNATURE-----> _________________________________________________________________ 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 Jan 23 06:58:55 2008 From: mika at async.caltech.edu (Mika Nystrom) Date: Tue, 22 Jan 2008 21:58:55 -0800 Subject: [M3devel] next problem (NT386GNU) In-Reply-To: Your message of "Wed, 23 Jan 2008 00:04:35 +0100." <20080123000435.kjtci5bewwcss448@mail.elegosoft.com> Message-ID: <200801230558.m0N5wtQ4034198@camembert.async.caltech.edu> I think Windows 2000 is well known for having some exceptionally nasty bugs in its TCP implementation. In fact my Modula-3 code has special workarounds for win2k: it doesn't download more than a few kilobytes at a time---if you try more, the network card sometimes goes catatonic. There are some notes on it here and there on the Internet. Not sure what the cause is. Mika Olaf Wagner writes: >Quoting Randy Coleburn : > >> Jay / Olaf: >> >> I installed CVSNT and TortoiseCVS. I am having some trouble with >> "update" however. When I try to update the whole tree, it begins >> working, but after a little while I start seeing messages that checksums >> didn't match on certain files and that it will refetch. Then, after >> just a little longer, it stops responding. I've left it running for >> hours, but no new lines scroll by saying it is doing anything. Finally, >> I just hit cancel and it promptly stops and informs me it aborted the >> operation, as if it been waiting all along for me to tell it to give >> up. >> >> Now, if I update individual files or selected files, it seems to work >> no problem. And, I've been able to check out the whole repository, and >> yes it does take some time to pull everything down. I can also do diffs >> on selected files. I've also used it to commit a few files to the >> repository. >> >> So, it is working fine, except for update. Either something is amiss, >> or I'm not doing something just right. I am about to consider going >> back to cygwin and running its version of cvs on my tree to see if it >> will do the update, but I seem to recall reading somewhere that is not >> good to mix between cvs and cvsnt on the same tree. > >This is strange. I've never seen that myself before. A complete >update or checkout should take several minutes via encrypted >TCP/IP, but not longer (depending on the line bandwidth and latency, >of course). > >Just today I've heard of a customer who suffers from random connection >problems with Subversion and Windows 2000 workstations; the theory there >being that some TCP/IP parameters are set very strange and the whole >protocol stack is not up to the task in its default configuration. >This does not happen on XT or Vista, though, who seem to have incorporated >significant improvements. (It's all rather strange to me, since I'm a >Unix person myself and used to stable networking.) > >So depending on your OS you might want to tweak the TCP parameters a >little bit to see if it improves. Hard-core debugging of this problem >will need careful use of tcpdump and produce megabytes of logs; >but perhaps just using the cvs trace option (cvs -t up ...) will >give some indication if there's another problem than the underlying >connection. > >There's also nothing against checking out a different workspace >with the Cygwin cvs to see if that works better. We've made good >experiences with CVSNT though. > >If the problem persists, we could also try to do some tcpdumping on >the server side (Ronny Forberger would be the one to do it), but this >will take some preparation time. > >@Ronny, perhaps you've got another idea? > >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 jayk123 at hotmail.com Wed Jan 23 07:28:01 2008 From: jayk123 at hotmail.com (Jay) Date: Wed, 23 Jan 2008 06:28:01 +0000 Subject: [M3devel] next problem (NT386GNU) In-Reply-To: <200801230558.m0N5wtQ4034198@camembert.async.caltech.edu> References: Your message of "Wed, 23 Jan 2008 00:04:35 +0100." <20080123000435.kjtci5bewwcss448@mail.elegosoft.com> <200801230558.m0N5wtQ4034198@camembert.async.caltech.edu> Message-ID: (I never used Windows 2000 much, but NT 4 worked solidly for a long time (didn't use CVS on it), hard to imagine Windows 2000 regressed much. XP and 2003 are solid, Vista I think is holding up in /this area/. There is the whole IPv4 vs. IPv6 transition still ongoing around the world. I really think Windows is better than its given credit for. Not Win9x, but NT. The Apple BS about being on a solid Unix foundation and all that..it's not like NT doesn't have same model, the same user/kernel isolation.....) Besides..if Cygwin CVS works fine (for me and I think for Randy), either a) it's not the network, or 2) Cygwin has workarounds and TortoiseCVS/CVSNT do not. I doubt #2, but almost anything is possible. Granted, I don't have TortoiseCVS/CVSNT working yet, didn't configure ssh for it. At some hypothetical point I install Win95/98/NT3.x/NT4/Win2000 in virtual machines and see how Modula-3 fairs.. I know the current binaries won't work on Win95/NT3.x due to Interlocked stuff, and some dependency on new processors, same thing (ie: you could inline or statically link such functions, and work on older OS but not on a 386). People should speak up if they expect pre-XP or 386/486/regular old Pentium support. And even then, the processors continue to progress at a surprising-to-me rate, MMX, SSE, SSE2, etc. (Not to mention AMD64..I have an unfortunate hardware situation at home there, might need to get another machine soon...or swap machines in a way I'd rather not..but this is getting ahead of things) - Jay > To: wagner at elegosoft.com> Date: Tue, 22 Jan 2008 21:58:55 -0800> From: mika at async.caltech.edu> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] next problem (NT386GNU)> > > I think Windows 2000 is well known for having some exceptionally> nasty bugs in its TCP implementation. In fact my Modula-3 code has> special workarounds for win2k: it doesn't download more than a few> kilobytes at a time---if you try more, the network card sometimes> goes catatonic. There are some notes on it here and there on the> Internet. Not sure what the cause is.> > Mika > > Olaf Wagner writes:> >Quoting Randy Coleburn :> >> >> Jay / Olaf:> >>> >> I installed CVSNT and TortoiseCVS. I am having some trouble with> >> "update" however. When I try to update the whole tree, it begins> >> working, but after a little while I start seeing messages that checksums> >> didn't match on certain files and that it will refetch. Then, after> >> just a little longer, it stops responding. I've left it running for> >> hours, but no new lines scroll by saying it is doing anything. Finally,> >> I just hit cancel and it promptly stops and informs me it aborted the> >> operation, as if it been waiting all along for me to tell it to give> >> up.> >>> >> Now, if I update individual files or selected files, it seems to work> >> no problem. And, I've been able to check out the whole repository, and> >> yes it does take some time to pull everything down. I can also do diffs> >> on selected files. I've also used it to commit a few files to the> >> repository.> >>> >> So, it is working fine, except for update. Either something is amiss,> >> or I'm not doing something just right. I am about to consider going> >> back to cygwin and running its version of cvs on my tree to see if it> >> will do the update, but I seem to recall reading somewhere that is not> >> good to mix between cvs and cvsnt on the same tree.> >> >This is strange. I've never seen that myself before. A complete> >update or checkout should take several minutes via encrypted> >TCP/IP, but not longer (depending on the line bandwidth and latency,> >of course).> >> >Just today I've heard of a customer who suffers from random connection> >problems with Subversion and Windows 2000 workstations; the theory there> >being that some TCP/IP parameters are set very strange and the whole> >protocol stack is not up to the task in its default configuration.> >This does not happen on XT or Vista, though, who seem to have incorporated> >significant improvements. (It's all rather strange to me, since I'm a> >Unix person myself and used to stable networking.)> >> >So depending on your OS you might want to tweak the TCP parameters a> >little bit to see if it improves. Hard-core debugging of this problem> >will need careful use of tcpdump and produce megabytes of logs;> >but perhaps just using the cvs trace option (cvs -t up ...) will> >give some indication if there's another problem than the underlying> >connection.> >> >There's also nothing against checking out a different workspace> >with the Cygwin cvs to see if that works better. We've made good> >experiences with CVSNT though.> >> >If the problem persists, we could also try to do some tcpdumping on> >the server side (Ronny Forberger would be the one to do it), but this> >will take some preparation time.> >> >@Ronny, perhaps you've got another idea?> >> >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 _________________________________________________________________ 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 Wed Jan 23 08:06:20 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Wed, 23 Jan 2008 08:06:20 +0100 (MET) Subject: [M3devel] platform/build_dir is a big tuple? In-Reply-To: <479605CF.1E75.00D7.1@scires.com> References: <479605CF.1E75.00D7.1@scires.com> Message-ID: On Tue, 22 Jan 2008, Randy Coleburn wrote: > Jay: > > For my part on Windows, I am happy to stay with the underlying OS, the > native windows threading, the integrated backend, and use the free > Microsoft Visual Studio tools. I don't really want to have to > install/use cygwin or any of the other variants. When I see target = > NT386, this list is what I am expecting. For the cm3 newbie coming from > a Microsoft Windows environment, I think this list would be the most > appealing and pose the least barrier to getting starting. Yes, I still > will work on the installer program once I'm satisfied that I have a good > working cm3 on Windows. One year ago I was in the situation to port one of my Modula-3 programs from Linux to Windows in order to hand it over to a Windows user. As I never use Windows, I have only a plain Windows installation on my machine with almost no tools other than cm3. I was glad to be able to run cm3 immediately and to find all libraries that I needed in binary form without Cygwin dependencies - otherwise not only I had to install that on my machine but I also would have to persuade the other Windows guy to install it as well. Summarized I strongly vote for NT386 being Windows with least dependencies on other packages. From jayk123 at hotmail.com Wed Jan 23 08:37:28 2008 From: jayk123 at hotmail.com (Jay) Date: Wed, 23 Jan 2008 07:37:28 +0000 Subject: [M3devel] platform/build_dir is a big tuple? In-Reply-To: References: <479605CF.1E75.00D7.1@scires.com> Message-ID: Let me cut to the chase, again: Everyone will probably be satisfied. For a very small "everyone". :) The underlying implementation shall be "heavily" parameterized. There shall be three visible pre packaged configurations. Power users, and clever and crazy people can experiment beyond those three. The EXACT three configurations is SLIGHTLY up in the air, but is likely to be: NT386 same as today, integrated backend, Win32 GUI, msvc*.dll, native win32 kernel threads, native backslashy paths (and perhaps increased compat with forward slashes, some of that is already in, m3core, but not yet cm3), Visual C++ compiler and linker. NT386MINGNU same as today's (recent) NT386GNU, but with Trestle-on-Win32 also working external backend, gcc compiler and linker, but otherwise same as NT386 One small wrinkle here is there is no m3gdb, but you can use the m3gdb from the next one, or Cygwin's gdb. NT386GNU As GNU as possible. pthreads (uncertain), X Windows (CygwinX), Cygwin C library, stupid looking paths that start /cygdrive, wierdo symlinks that don't interoperate well with the rest of the system (attempting to run cc.exe crashes ntvdm.exe, for example), "link" makes file system links (or at least strange files) instead of linking programs, a slow and perhaps fragile copy-immediately implementation of fork, problems running one type of program from another because you don't know which command line parameters and which environment variables represent paths or lists of paths and therefore how to translate them, etc. The underlying parameters, which are largely independent and which you can change individually, but which you will actually just ignore usually, shall be: modula-3 backend integrated 0 cm3cg 1 This might be replaced by the existing 0-3 variable. C compiler Visual C++ cl 0 gcc 1 In future this could be redefined as decimal digit or a character to accomodate other choices. linker Visual C++ link 0 gcc 1 In future this could be redefined as decimal digit or a character to accomodate other choices. Threading library Native Win32 kernel threads 0 Cygwin pthreads which are probably layered on native Win32 kernel threads 1 This is the one area where people have suggested using native Win32 functionality instead of Cygwin vtalaram user threads probably not available fiber user threads probably not available This would have been better than vtalaram, but not Win9x compatible If anyone wanted user vtlaram or fiber, this could be extended. It probably always should have been fibers instead of setjmp/longjmp where fibers are available... Window library Native Win32 gui 0 (hopefully with bugs to be worked out) X Windows via CygwinX 1 (hopefully the binaries are X server agnostic, and even work against a remote Unix machine?) C library native msvcr* through Visual C++ or MinGWin 0 Cygwin and its path oddities 1 The current notion of "OSTYPE" becomes much less useful here, as it previously embodied multiple factors. It wasn't all that useful anyway, imho, but as a way to reduce the matrix of targets down to two, the same two in multiple places. Now, in a few places, you check a more specific variable. Theoretically, I don't have to change cm3 here, just the config file and some m3makefiles. Because, tricky tricky, the main thing cm3 cares about is the backend "mode", and that does match up above with the 0/1. There are actually 4 modes and I should maybe hoist that up to be the variable, very maybe. A few m3makefiles will have to change, in small ways. Therefore, NT386 is all 0s, NT386GNU shall be all 1s, except maybe threading, and NT386MINGNU shall be a mix -- backend, C compiler, linker 1, the rest 0. Besides that, what I haven't in my head yet, is that individual m3makefiles should be able to ask for one compiler or the other. The base system won't do that, but user systems could, if they have some code that depends on one compiler or the other and they are going to link it together. For this purpose, for exposing these features to users, possibly values other than "0" and "1" are needed. If the configuration is one of these three combinations, build_dir is translated as shown. Otherwise, it is "NT386-" plus the unreadable string of 0s and 1s. This is essentially already commited. NT386 works this way. NT386MINGNU works this, but is for now called NT386GNU, and doesn't have any Trestle yet. The new/old Cygwin NT386GNU isn't active yet, but easily should be. There are three config files, NT386, NT386MINGNU, NT386GNU, they are all just a few lines and then include NT386.common. Oh, one more thing I haven't worked out is how the user asks for one target or another. It is probably via the environment variable CM3_TARGET, though in reality, "TARGET" for all of these shall be NT386. Any questions? Don't ask me when Cygwin NT386GNU will be active or when the names will flip. I will try it soon. This is essentiallyalready in the tree, with a little bit of "temporary, for compat" sprinkled in to avoid renaming NT386GNU/MINGNU just yet, and the Cygwinish stuff not active, no X Windows on NT386 yet..groundwork is laid, I think I've stopped thinking through the indecisiveness, I just keep hearing the two extreme sides, the Windows users who want Windows (do you even care about the gcc backend? It's slow. It generates inefficient code. It supports Longint) and a few Unix users who might reluctantly use Windows a little more if their backend slowed down and their libraries changed... Personally my main goal here is to not feel guilty about not finishing the LONGINT support yet in the integrated backend. I'd still like to finish that, but it was taking embarassingly long. I'd also like an uber-cross build environment, where I can build anything from anything. Getting cm3cg working was part of that. I'm not sure I have the patience to build gcc and ld/binutils that many times though. - Jay > Date: Wed, 23 Jan 2008 08:06:20 +0100> From: lemming at henning-thielemann.de> Subject: Re: [M3devel] platform/build_dir is a big tuple?> To: rcoleburn at scires.com> CC: m3devel at elegosoft.com; jayk123 at hotmail.com> > > On Tue, 22 Jan 2008, Randy Coleburn wrote:> > > Jay:> >> > For my part on Windows, I am happy to stay with the underlying OS, the> > native windows threading, the integrated backend, and use the free> > Microsoft Visual Studio tools. I don't really want to have to> > install/use cygwin or any of the other variants. When I see target => > NT386, this list is what I am expecting. For the cm3 newbie coming from> > a Microsoft Windows environment, I think this list would be the most> > appealing and pose the least barrier to getting starting. Yes, I still> > will work on the installer program once I'm satisfied that I have a good> > working cm3 on Windows.> > One year ago I was in the situation to port one of my Modula-3 programs> from Linux to Windows in order to hand it over to a Windows user. As I> never use Windows, I have only a plain Windows installation on my machine> with almost no tools other than cm3. I was glad to be able to run cm3> immediately and to find all libraries that I needed in binary form without> Cygwin dependencies - otherwise not only I had to install that on my> machine but I also would have to persuade the other Windows guy to install> it as well. Summarized I strongly vote for NT386 being Windows with least> dependencies on other packages. _________________________________________________________________ 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 Jan 23 08:22:54 2008 From: mika at async.caltech.edu (Mika Nystrom) Date: Tue, 22 Jan 2008 23:22:54 -0800 Subject: [M3devel] platform/build_dir is a big tuple? In-Reply-To: Your message of "Wed, 23 Jan 2008 08:06:20 +0100." Message-ID: <200801230722.m0N7Msbc036278@camembert.async.caltech.edu> Henning Thielemann writes: > >On Tue, 22 Jan 2008, Randy Coleburn wrote: > >> Jay: >> >> For my part on Windows, I am happy to stay with the underlying OS, the >> native windows threading, the integrated backend, and use the free >> Microsoft Visual Studio tools. I don't really want to have to >> install/use cygwin or any of the other variants. When I see target = >> NT386, this list is what I am expecting. For the cm3 newbie coming from >> a Microsoft Windows environment, I think this list would be the most >> appealing and pose the least barrier to getting starting. Yes, I still >> will work on the installer program once I'm satisfied that I have a good >> working cm3 on Windows. > >One year ago I was in the situation to port one of my Modula-3 programs >from Linux to Windows in order to hand it over to a Windows user. As I >never use Windows, I have only a plain Windows installation on my machine >with almost no tools other than cm3. I was glad to be able to run cm3 >immediately and to find all libraries that I needed in binary form without >Cygwin dependencies - otherwise not only I had to install that on my >machine but I also would have to persuade the other Windows guy to install >it as well. Summarized I strongly vote for NT386 being Windows with least >dependencies on other packages. My experience was almost the opposite. I had a complicated system running on Unix, using Modula-3 for most of its implementation but all sorts of other dirty glue to run properly, and various calls to libc routines. A couple of Windows people told me "please run this stuff on our machine [we don't care how you do it]". I promptly installed Cygwin and got the whole thing running with a fairly small amount of fuss. Accordingly, I vote for NT386GNU being a Cygwin thing that looks as much like Unix as possible! I can certainly see the other point of view, but is there a great need for something between these two extremes? If I were the one putting together Modula-3 compilers for Windows, I'd do those two (not sure which one first) and not worry about all the other permutations of threading libraries, compilers, etc. Mika From jayk123 at hotmail.com Wed Jan 23 08:49:28 2008 From: jayk123 at hotmail.com (Jay) Date: Wed, 23 Jan 2008 07:49:28 +0000 Subject: [M3devel] platform/build_dir is a big tuple? In-Reply-To: References: <479605CF.1E75.00D7.1@scires.com> Message-ID: > If anyone wanted user vtlaram or fiber, this could be extended. > It probably always should have been fibers instead of setjmp/longjmp where fibers are available... Oh, sorry, Modula-3 has never to my knowledge used user/vtalarm threads. If anyone does want to take over their own scheduling and have an N:M model, fibers are perhaps the way to go, unless you need Win9x. Fibers take care of creating a stack and swapping register context, whereas setjmp/longjmp only swap register context and I suspect Modula-3 uses them in a non-conformant but generally-compatible way. I haven't looked into this yet. For exceptions, ok. For thread switching, probably not. But I'd have to look at how it's implemented.. user mode threads, fibers..are problematic. For example Win32 critical sections can be taken recursively, on the same thread. Fibers can move around between threads and therefore cannot take them recursively. All in all, as said below, I'm inclined to omit support for user mode threads on Windows. I ASSUME the Cygwin pthreads are a thin wrapper over Windows, except...except there is the condition variables...not sure they can be layered over thinly... As I said, this is one bit I am uncertan of. Maybe just always use native Win32 threads. It would be a perhaps interesting curiosity to see if cygwin binaries tend to only depend on cygwin .dlls and not win32 .dlls, as a "proof" of the "completeness" of the layer/wrapping. (though as to the quality, see below.) Of course, cygwin code can still use win32..your m3makefile might actually check target==nt386 to know "the truth". But I doubt anyone would use this flexibility. - Jay From: jayk123 at hotmail.comTo: lemming at henning-thielemann.de; rcoleburn at scires.comCC: m3devel at elegosoft.comSubject: RE: [M3devel] platform/build_dir is a big tuple?Date: Wed, 23 Jan 2008 07:37:28 +0000 Let me cut to the chase, again: Everyone will probably be satisfied. For a very small "everyone". :) The underlying implementation shall be "heavily" parameterized.There shall be three visible pre packaged configurations.Power users, and clever and crazy people can experiment beyond those three.The EXACT three configurations is SLIGHTLY up in the air, but is likely to be: NT386 same as today, integrated backend, Win32 GUI, msvc*.dll, native win32 kernel threads, native backslashy paths (and perhaps increased compat with forward slashes, some of that is already in, m3core, but not yet cm3), Visual C++ compiler and linker. NT386MINGNU same as today's (recent) NT386GNU, but with Trestle-on-Win32 also working external backend, gcc compiler and linker, but otherwise same as NT386 One small wrinkle here is there is no m3gdb, but you can use the m3gdb from the next one, or Cygwin's gdb. NT386GNU As GNU as possible. pthreads (uncertain), X Windows (CygwinX), Cygwin C library, stupid looking paths that start /cygdrive, wierdo symlinks that don't interoperate well with the rest of the system (attempting to run cc.exe crashes ntvdm.exe, for example), "link" makes file system links (or at least strange files) instead of linking programs, a slow and perhaps fragile copy-immediately implementation of fork, problems running one type of program from another because you don't know which command line parameters and which environment variables represent paths or lists of paths and therefore how to translate them, etc. The underlying parameters, which are largely independent and which you can change individually, but which you will actually just ignore usually, shall be: modula-3 backend integrated 0 cm3cg 1 This might be replaced by the existing 0-3 variable. C compiler Visual C++ cl 0 gcc 1 In future this could be redefined as decimal digit or a character to accomodate other choices. linker Visual C++ link 0 gcc 1 In future this could be redefined as decimal digit or a character to accomodate other choices. Threading library Native Win32 kernel threads 0 Cygwin pthreads which are probably layered on native Win32 kernel threads 1 This is the one area where people have suggested using native Win32 functionality instead of Cygwin vtalaram user threads probably not available fiber user threads probably not available This would have been better than vtalaram, but not Win9x compatible If anyone wanted user vtlaram or fiber, this could be extended. It probably always should have been fibers instead of setjmp/longjmp where fibers are available... Window library Native Win32 gui 0 (hopefully with bugs to be worked out) X Windows via CygwinX 1 (hopefully the binaries are X server agnostic, and even work against a remote Unix machine?) C library native msvcr* through Visual C++ or MinGWin 0 Cygwin and its path oddities 1 The current notion of "OSTYPE" becomes much less useful here, as it previously embodied multiple factors. It wasn't all that useful anyway, imho, but as a way to reduce the matrix of targets down to two, the same two in multiple places. Now, in a few places, you check a more specific variable. Theoretically, I don't have to change cm3 here, just the config file and some m3makefiles. Because, tricky tricky, the main thing cm3 cares about is the backend "mode", and that does match up above with the 0/1. There are actually 4 modes and I should maybe hoist that up to be the variable, very maybe. A few m3makefiles will have to change, in small ways. Therefore, NT386 is all 0s, NT386GNU shall be all 1s, except maybe threading, and NT386MINGNU shall be a mix -- backend, C compiler, linker 1, the rest 0. Besides that, what I haven't in my head yet, is that individual m3makefiles should be able to ask for one compiler or the other. The base system won't do that, but user systems could, if they have some code that depends on one compiler or the other and they are going to link it together. For this purpose, for exposing these features to users, possibly values other than "0" and "1" are needed. If the configuration is one of these three combinations, build_dir is translated as shown.Otherwise, it is "NT386-" plus the unreadable string of 0s and 1s. This is essentially already commited. NT386 works this way. NT386MINGNU works this, but is for now called NT386GNU, and doesn't have any Trestle yet. The new/old Cygwin NT386GNU isn't active yet, but easily should be. There are three config files, NT386, NT386MINGNU, NT386GNU, they are all just a few lines and then include NT386.common. Oh, one more thing I haven't worked out is how the user asks for one target or another.It is probably via the environment variable CM3_TARGET, though in reality, "TARGET" for all of these shall be NT386. Any questions?Don't ask me when Cygwin NT386GNU will be active or when the names will flip. I will try it soon. This is essentiallyalready in the tree, with a little bit of "temporary, for compat" sprinkled in to avoid renaming NT386GNU/MINGNU just yet, and the Cygwinish stuff not active, no X Windows on NT386 yet..groundwork is laid, I think I've stopped thinking through the indecisiveness, I just keep hearing the two extreme sides, the Windows users who want Windows (do you even care about the gcc backend? It's slow. It generates inefficient code. It supports Longint) and a few Unix users who might reluctantly use Windows a little more if their backend slowed down and their libraries changed... Personally my main goal here is to not feel guilty about not finishing the LONGINT support yet in the integrated backend.I'd still like to finish that, but it was taking embarassingly long. I'd also like an uber-cross build environment, where I can build anything from anything. Getting cm3cg working was part of that. I'm not sure I have the patience to build gcc and ld/binutils that many times though. - Jay > Date: Wed, 23 Jan 2008 08:06:20 +0100> From: lemming at henning-thielemann.de> Subject: Re: [M3devel] platform/build_dir is a big tuple?> To: rcoleburn at scires.com> CC: m3devel at elegosoft.com; jayk123 at hotmail.com> > > On Tue, 22 Jan 2008, Randy Coleburn wrote:> > > Jay:> >> > For my part on Windows, I am happy to stay with the underlying OS, the> > native windows threading, the integrated backend, and use the free> > Microsoft Visual Studio tools. I don't really want to have to> > install/use cygwin or any of the other variants. When I see target => > NT386, this list is what I am expecting. For the cm3 newbie coming from> > a Microsoft Windows environment, I think this list would be the most> > appealing and pose the least barrier to getting starting. Yes, I still> > will work on the installer program once I'm satisfied that I have a good> > working cm3 on Windows.> > One year ago I was in the situation to port one of my Modula-3 programs> from Linux to Windows in order to hand it over to a Windows user. As I> never use Windows, I have only a plain Windows installation on my machine> with almost no tools other than cm3. I was glad to be able to run cm3> immediately and to find all libraries that I needed in binary form without> Cygwin dependencies - otherwise not only I had to install that on my> machine but I also would have to persuade the other Windows guy to install> it as well. Summarized I strongly vote for NT386 being Windows with least> dependencies on other packages. 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 mika at async.caltech.edu Wed Jan 23 08:50:49 2008 From: mika at async.caltech.edu (Mika Nystrom) Date: Tue, 22 Jan 2008 23:50:49 -0800 Subject: [M3devel] platform/build_dir is a big tuple? In-Reply-To: Your message of "Wed, 23 Jan 2008 07:37:28 GMT." Message-ID: <200801230750.m0N7onlw036945@camembert.async.caltech.edu> This sounds wonderful!! Mika P.S. Personally I don't care about pthreads, user threads, or any other kind of threads. I think Modula-3 threads are beautiful (one of the real strengths of the language, in fact), and good as never see a need to delve any lower than that. Win32 threads work fine on the old NT386GNU. There were no pthreads back then, and probably Win32 threads are better than user threads anyhow... (in the sense of requiring fewest "anti-blocking" hacks). Of course there might be someone out there who doesn't agree, and needs Modula-3 threads to be built on pthreads for some reason... Jay writes: >--_6a1e3166-9b30-4149-b10d-8b7fe22a1ec0_ >Content-Type: text/plain; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > >Let me cut to the chase, again: >=20 > Everyone will probably be satisfied.=20 > For a very small "everyone". :)=20 >=20 >The underlying implementation shall be "heavily" parameterized. >There shall be three visible pre packaged configurations. >Power users, and clever and crazy people can experiment beyond those three. >The EXACT three configurations is SLIGHTLY up in the air, but is likely to = >be: >=20 >NT386 > same as today, integrated backend, Win32 GUI, msvc*.dll, native win32 ker= >nel threads, native backslashy paths (and perhaps increased compat with for= >ward slashes, some of that is already in, m3core, but not yet cm3), Visual = >C++ compiler and linker. >=20 >NT386MINGNU > same as today's (recent) NT386GNU, but with Trestle-on-Win32 also working= >=20 > external backend, gcc compiler and linker, but otherwise same as NT386 > One small wrinkle here is there is no m3gdb, but you can use the m3gdb fr= >om the next one, or Cygwin's gdb. >=20 >NT386GNU > As GNU as possible. pthreads (uncertain), X Windows (CygwinX), Cygwin C l= >ibrary, stupid looking paths that start /cygdrive, wierdo symlinks that don= >'t interoperate well with the rest of the system (attempting to run cc.exe = >crashes ntvdm.exe, for example), "link" makes file system links (or at leas= >t strange files) instead of linking programs, a slow and perhaps fragile co= >py-immediately implementation of fork, problems running one type of program= > from another because you don't know which command line parameters and whic= >h environment variables represent paths or lists of paths and therefore how= > to translate them, etc.=20 >The underlying parameters, which are largely independent and which you can = >change individually, but which you will actually just ignore usually, shall= > be: >=20 > modula-3 backend > integrated 0 > cm3cg 1 > This might be replaced by the existing 0-3 variable. >=20 > C compiler =20 > Visual C++ cl 0 > gcc 1 > In future this could be redefined as decimal digit or a character to ac= >comodate other choices. >=20 > linker > Visual C++ link 0 > gcc 1 > In future this could be redefined as decimal digit or a character to ac= >comodate other choices. >=20 > Threading library > Native Win32 kernel threads 0 > Cygwin pthreads which are probably layered on native Win32 kernel thre= >ads 1 > This is the one area where people have suggested using native Win32 fu= >nctionality instead of Cygwin > vtalaram user threads probably not available > fiber user threads probably not available > This would have been better than vtalaram, but not Win9x compatib= >le > If anyone wanted user vtlaram or fiber, this could be extended. It pro= >bably always should have been fibers instead of setjmp/longjmp where fibers= > are available... >=20 > Window library > Native Win32 gui 0 (hopefully with bugs to be worked out)=20 > X Windows via CygwinX 1 (hopefully the binaries are X server agnostic= >, and even work against a remote Unix machine?) >=20 > C library > native msvcr* through Visual C++ or MinGWin 0 > Cygwin and its path oddities 1=20 >=20 >The current notion of "OSTYPE" becomes much less useful here, as it previou= >sly embodied multiple factors. > It wasn't all that useful anyway, imho, but as a way to reduce the matrix = >of targets down to two, the same two in multiple places. Now, in a few plac= >es, you check a more specific variable. Theoretically, I don't have to chan= >ge cm3 here, just the config file and some m3makefiles. Because, tricky tri= >cky, the main thing cm3 cares about is the backend "mode", and that does ma= >tch up above with the 0/1. There are actually 4 modes and I should maybe ho= >ist that up to be the variable, very maybe. A few m3makefiles will have to = >change, in small ways. >=20 > Therefore, NT386 is all 0s, NT386GNU shall be all 1s, except maybe thread= >ing, and NT386MINGNU shall be a mix -- backend, C compiler, linker 1, the r= >est 0. Besides that, what I haven't in my head yet, is that individual m3ma= >kefiles should be able to ask for one compiler or the other. The base syste= >m won't do that, but user systems could, if they have some code that depend= >s on one compiler or the other and they are going to link it together. For = >this purpose, for exposing these features to users, possibly values other t= >han "0" and "1" are needed. >=20 >If the configuration is one of these three combinations, build_dir is trans= >lated as shown. >Otherwise, it is "NT386-" plus the unreadable string of 0s and 1s. >=20 >This is essentially already commited. NT386 works this way. NT386MINGNU wor= >ks this, but is for now called NT386GNU, and doesn't have any Trestle yet. = >The new/old Cygwin NT386GNU isn't active yet, but easily should be. >=20 >There are three config files, NT386, NT386MINGNU, NT386GNU, they are all ju= >st a few lines and then include NT386.common. >=20 >Oh, one more thing I haven't worked out is how the user asks for one target= > or another. >It is probably via the environment variable CM3_TARGET, though in reality, = >"TARGET" for all of these shall be NT386. >=20 >Any questions? >Don't ask me when Cygwin NT386GNU will be active or when the names will fli= >p. I will try it soon. >=20 >This is essentiallyalready in the tree, with a little bit of "temporary, fo= >r compat" sprinkled in to avoid renaming NT386GNU/MINGNU just yet, and the = >Cygwinish stuff not active, no X Windows on NT386 yet..groundwork is laid, = >I think I've stopped thinking through the indecisiveness, I just keep heari= >ng the two extreme sides, the Windows users who want Windows (do you even c= >are about the gcc backend? It's slow. It generates inefficient code. It sup= >ports Longint) and a few Unix users who might reluctantly use Windows a lit= >tle more if their backend slowed down and their libraries changed... >=20 >Personally my main goal here is to not feel guilty about not finishing the = >LONGINT support yet in the integrated backend. >I'd still like to finish that, but it was taking embarassingly long. >=20 >I'd also like an uber-cross build environment, where I can build anything f= >rom anything. Getting cm3cg working was part of that. I'm not sure I have t= >he patience to build gcc and ld/binutils that many times though. >=20 > - Jay > > > >> Date: Wed, 23 Jan 2008 08:06:20 +0100> From: lemming at henning-thielemann.d= >e> Subject: Re: [M3devel] platform/build_dir is a big tuple?> To: rcoleburn= >@scires.com> CC: m3devel at elegosoft.com; jayk123 at hotmail.com> > > On Tue, 22= > Jan 2008, Randy Coleburn wrote:> > > Jay:> >> > For my part on Windows, I = >am happy to stay with the underlying OS, the> > native windows threading, t= >he integrated backend, and use the free> > Microsoft Visual Studio tools. I= > don't really want to have to> > install/use cygwin or any of the other var= >iants. When I see target =3D> > NT386, this list is what I am expecting. Fo= >r the cm3 newbie coming from> > a Microsoft Windows environment, I think th= >is list would be the most> > appealing and pose the least barrier to gettin= >g starting. Yes, I still> > will work on the installer program once I'm sat= >isfied that I have a good> > working cm3 on Windows.> > One year ago I was = >in the situation to port one of my Modula-3 programs> from Linux to Windows= > in order to hand it over to a Windows user. As I> never use Windows, I hav= >e only a plain Windows installation on my machine> with almost no tools oth= >er than cm3. I was glad to be able to run cm3> immediately and to find all = >libraries that I needed in binary form without> Cygwin dependencies - other= >wise not only I had to install that on my> machine but I also would have to= > persuade the other Windows guy to install> it as well. Summarized I strong= >ly vote for NT386 being Windows with least> dependencies on other packages. >_________________________________________________________________ >Connect and share in new ways with Windows Live. >http://www.windowslive.com/share.html?ocid=3DTXT_TAGHM_Wave2_sharelife_0120= >08= > >--_6a1e3166-9b30-4149-b10d-8b7fe22a1ec0_ >Content-Type: text/html; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > > > > >Let me cut to the chase, again:
> 
> Everyone will probably be satisfied.
> For a very small "everyone". :)
> 
>The underlying implementation shall be "heavily" parameterized.
>There shall be three visible pre packaged configurations.
>Power users, and clever and crazy people can experiment beyond those three.= >
>The EXACT three configurations is SLIGHTLY up in the air, but is likely to = >be:
> 
>NT386
>  same as today, integrated backend, Win32 GUI, msvc*.dll, native win3= >2 kernel threads, native backslashy paths (and perhaps increased compat wit= >h forward slashes, some of that is already in, m3core, but not yet cm3), Vi= >sual C++ compiler and linker.
> 
>NT386MINGNU
>  same as today's (recent) NT386GNU, but with Trestle-on-Win32 al= >so working
>   external backend, gcc compiler and linker, but otherwise same = >as NT386
>  One small wrinkle here is there is no m3gdb, but you can use the m3g= >db from the next one, or Cygwin's gdb.
> 
>NT386GNU
>  As GNU as possible. pthreads (uncertain), X Windows (CygwinX), Cygwi= >n C library, stupid looking paths that start /cygdrive, wierdo symlinks tha= >t don't interoperate well with the rest of the system (attempting to run cc= >.exe crashes ntvdm.exe, for example), "link" makes file system links (or at= > least strange files) instead of linking programs, a slow and perhaps = >fragile copy-immediately implementation of fork, problems running one type = >of program from another because you don't know which command line parameter= >s and which environment variables represent paths or lists of paths and the= >refore how to translate them, etc.

>The underlying parameters, which are largely independent and which you can = >change individually, but which you will actually just ignore usually, = >shall be:
> 
>  modula-3 backend
>     integrated 0
>     cm3cg 1
>   This might be replaced by the existing 0-3 variable.
> 
>  C compiler 
>    Visual C++ cl 0
>    gcc 1
>    In future this could be redefined as decimal digit or a = >character to accomodate other choices.
> 
>  linker
>     Visual C++ link 0
>     gcc 1
>    In future this could be redefined as decimal digit or a = >character to accomodate other choices.
> 
>   Threading library
>     Native Win32 kernel threads 0
>     Cygwin pthreads which are probably layered on nati= >ve Win32 kernel threads 1
>     This is the one area where people have suggested u= >sing native Win32 functionality instead of Cygwin
>     vtalaram user threads probably not available
>     fiber user threads probably not available
>          This would have been= > better than vtalaram, but not Win9x compatible
>     If anyone wanted user vtlaram or fiber, this could= > be extended. It probably always should have been fibers instead of setjmp/= >longjmp where fibers are available...
> 
>   Window library
>      Native Win32 gui 0 (hopefully with bugs to b= >e worked out)
>      X Windows via CygwinX 1 (hopefully the binar= >ies are X server agnostic, and even work against a remote Unix machine?)> > 
>    C library
>      native msvcr* through Visual C++ or MinGWin = >0
>      Cygwin and its path oddities 1
> 
>The current notion of "OSTYPE" becomes much less useful here, as it previou= >sly embodied multiple factors.
> It wasn't all that useful anyway, imho, but as a way to reduce the ma= >trix of targets down to two, the same two in multiple places. Now, in a few= > places, you check a more specific variable. Theoretically, I don't have to= > change cm3 here, just the config file and some m3makefiles. Because, trick= >y tricky, the main thing cm3 cares about is the backend "mode", and that do= >es match up above with the 0/1. There are actually 4 modes and I should may= >be hoist that up to be the variable, very maybe. A few m3makefiles will hav= >e to change, in small ways.
> 
>  Therefore, NT386 is all 0s, NT386GNU shall be all 1s, exce= >pt maybe threading, and NT386MINGNU shall be a mix -- backend, C = >compiler, linker 1, the rest 0. Besides that, what I haven't in my head yet= >, is that individual m3makefiles should be able to ask for one compiler or = >the other. The base system won't do that, but user systems could, if they h= >ave some code that depends on one compiler or the other and they are going = >to link it together. For this purpose, for exposing these features to users= >, possibly values other than "0" and "1" are needed.
> 
>If the configuration is one of these three combinations, build_dir is trans= >lated as shown.
>Otherwise, it is "NT386-" plus the unreadable string of 0s and 1s.
> 
>This is essentially already commited. NT386 works this way. NT386MINGNU wor= >ks this, but is for now called NT386GNU, and doesn't have any Trestle yet. = >The new/old Cygwin NT386GNU isn't active yet, but easily should be.
> 
>There are three config files, NT386, NT386MINGNU, NT386GNU, they are all ju= >st a few lines and then include NT386.common.
> 
>Oh, one more thing I haven't worked out is how the user asks for one target= > or another.
>It is probably via the environment variable CM3_TARGET, though in reality, = >"TARGET" for all of these shall be NT386.
> 
>Any questions?
>Don't ask me when Cygwin NT386GNU will be active or when the names will fli= >p. I will try it soon.
> 
>This is essentiallyalready in the tree, with a little bit of "temp= >orary, for compat" sprinkled in to avoid renaming NT386GNU/MINGNU just yet,= > and the Cygwinish stuff not active, no X Windows on NT386 yet..groundwork = >is laid, I think I've stopped thinking through the indecisiveness, I just k= >eep hearing the two extreme sides, the Windows users who want Windows (do y= >ou even care about the gcc backend? It's slow. It generates inefficient cod= >e. It supports Longint) and a few Unix users who might reluctantly use Wind= >ows a little more if their backend slowed down and their libraries changed.= >..
> 
>Personally my main goal here is to not feel guilty about not finishing the = >LONGINT support yet in the integrated backend.
>I'd still like to finish that, but it was taking embarassingly long.
> 
>I'd also like an uber-cross build environment, where I can build anything f= >rom anything. Getting cm3cg working was part of that. I'm not sure I have t= >he patience to build gcc and ld/binutils that many times though.
> 
>   - Jay


> >
>
>> Date: Wed, 23 Jan 2008 08:06:20 +0100
> From: lemming at henning-th= >ielemann.de
> Subject: Re: [M3devel] platform/build_dir is a big tupl= >e?
> To: rcoleburn at scires.com
> CC: m3devel at elegosoft.com; jayk= >123 at hotmail.com
>
>
> On Tue, 22 Jan 2008, Randy Colebu= >rn wrote:
>
> > Jay:
> >
> > For my part = >on Windows, I am happy to stay with the underlying OS, the
> > nat= >ive windows threading, the integrated backend, and use the free
> >= >; Microsoft Visual Studio tools. I don't really want to have to
> >= >; install/use cygwin or any of the other variants. When I see target =3D>> > NT386, this list is what I am expecting. For the cm3 newbie comi= >ng from
> > a Microsoft Windows environment, I think this list wou= >ld be the most
> > appealing and pose the least barrier to getting= > starting. Yes, I still
> > will work on the installer program onc= >e I'm satisfied that I have a good
> > working cm3 on Windows.
= >>
> One year ago I was in the situation to port one of my Modula-= >3 programs
> from Linux to Windows in order to hand it over to a Wind= >ows user. As I
> never use Windows, I have only a plain Windows insta= llation on my machine
> with almost no tools other than cm3. I was gl= >ad to be able to run cm3
> immediately and to find all libraries that= > I needed in binary form without
> Cygwin dependencies - otherwise no= >t only I had to install that on my
> machine but I also would have to= > persuade the other Windows guy to install
> it as well. Summarized I= > strongly vote for NT386 being Windows with least
> dependencies on o= >ther packages.


Connect and share in new ways with Window= >s Live. ave2_sharelife_012008' target=3D'_new'>Get it now! >= > >--_6a1e3166-9b30-4149-b10d-8b7fe22a1ec0_-- From jayk123 at hotmail.com Wed Jan 23 09:11:21 2008 From: jayk123 at hotmail.com (Jay) Date: Wed, 23 Jan 2008 08:11:21 +0000 Subject: [M3devel] ABIs and combinatorial configuration explosion in another project Message-ID: Our main concern here is jmpbuf size. And possibly exception interop. C++ throw should run Modula-3 finally en route to the C++ catch, and vice versa. Bonus points if each language can catch each other's exceptions, by type. Oh and interop with other Modula-3 compilers. :) Btw, you can see how profiling munges build_dir, same thing. http://www.boost.org/more/separate_compilation.html#static_or_dynamic Preventing Compiler ABI Clashes There are some compilers (mostly Microsoft Windows compilers again!), which feature a range of compiler switches that alter the ABI of C++ classes and functions. By way of example, consider Borland's compiler which has the following options:-b (on or off - effects enum sizes). -Vx (on or off - empty members). -Ve (on or off - empty base classes). -aX (alignment - 5 options). -pX (Calling convention - 4 options). -VmX (member pointer size and layout - 5 options). -VC (on or off, changes name mangling). -Vl (on or off, changes struct layout). These options are provided in addition to those affecting which runtime library is used (more on which later); the total number of combinations of options can be obtained by multiplying together the individual options above, so that gives 2*2*2*5*4*5*2*2 = 3200 combinations! The problem is that users often expect to be able to build the Boost libraries and then just link to them and have everything just plain work, no matter what their project settings are. Irrespective of whether this is a reasonable expectation or not, without some means of managing this issue, the user may well find that their program will experience strange and hard to track down crashes at runtime unless the library they link to was built with the same options as their project (changes to the default alignment setting are a prime culprit). One way to manage this is with "prefix and suffix" headers: these headers invoke compiler specific #pragma directives to instruct the compiler that whatever code follows was built (or is to be built) with a specific set of compiler ABI settings. .... For example the regex libraries get named as follows when built with Visual Studio .NET 2003:boost_regex-vc71-mt-1_31.lib boost_regex-vc71-mt-gd-1_31.lib libboost_regex-vc71-mt-1_31.lib libboost_regex-vc71-mt-gd-1_31.lib libboost_regex-vc71-mt-s-1_31.lib libboost_regex-vc71-mt-sgd-1_31.lib libboost_regex-vc71-s-1_31.lib libboost_regex-vc71-sgd-1_31.lib The difficulty now is selecting which of these the user should link his or her code to. _________________________________________________________________ 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 Wed Jan 23 09:27:55 2008 From: jayk123 at hotmail.com (Jay) Date: Wed, 23 Jan 2008 08:27:55 +0000 Subject: [M3devel] platform/build_dir is a big tuple? In-Reply-To: <200801230722.m0N7Msbc036278@camembert.async.caltech.edu> References: Your message of "Wed, 23 Jan 2008 08:06:20 +0100." <200801230722.m0N7Msbc036278@camembert.async.caltech.edu> Message-ID: > but is there a great need for something between these two extremes? Unclear I agree. It was useful as a stepping stone to the other extreme. The problems with it were "portable", though PM3 already solved one of them. It's the closest thing *today* to NT386 that supports LONGINT and mitigates my guilt about that. :) IN FACT, oh crap I thought I was done thinking about this. In fact the NT386 distribution could include cm3cg/as and whenever source uses LONGINT, compile it with it. Hacky. Hopefully to be avoided by really fixing the integrated backend. There do exist MinGWin and MSys, so I'm not the one who thought of this in-between.There is even "GCW" but it seems stillborn. Anyway, I'm pretty sure this discusion can wind down now. :) (I didn't say end, I said wind down. :) ) Unless anyone really dislikes how I've structured the config files and my upcoming cm3 changes that I think will be very very very small. I'm thinking..TARGET will remain NT386, NT386GNU will all but go away, as a target, it will live on as a "configuration", of which cm3 knows nothing, OS_TYPE will vary, and it will determine jmpbuf size..is that sleazy? Integrated backend vs. non integrated backend will determine the calling convention issues. Backend mode is correct asis. Alternatives to keying off of OS_TYPE in cm3: 1) Key off a new variable called currently "CLibrary", usually ignored. But on NT386 has the values 0 and 1. 2) Have the config file set jmpbuf size itself, and have cm3 know about that new variable. Hard to argue with that. The config file already has the power to subtley destroy things through script, witness double alignment. 3) look into why cygwin has a larger jmpbuf, if msvc*dll setjmp can be used instead, or m3core.dll can have its own m3_setjmp and export it. Might be better to call it something more abstract, like m3_try_for_except and m3_try_for_finally. 4) Blow up the jmpbuf size unconditionally on NT386. Bigger than necessary should work fine, but is wasteful. #3 Looking into the cygwin jmpbuf is pretty much an absolute. Heck, maybe it's just padding for the future, or maybe only used depending on something... 5) Abandon 386 and move on to AMD64. :) - Jay _________________________________________________________________ Shed those extra pounds with MSN and The Biggest Loser! http://biggestloser.msn.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcoleburn at scires.com Wed Jan 23 09:50:10 2008 From: rcoleburn at scires.com (Randy Coleburn) Date: Wed, 23 Jan 2008 03:50:10 -0500 Subject: [M3devel] new problem on NT386 Message-ID: <4796B970.1E75.00D7.1@scires.com> As you know, I am working to finalize the new Reactor. I've run into a new problem that did not exist on cm3 v5.2.6 or on cm3 v4.1, so I am hoping someone, perhaps Jay, can shed some light. Reactor uses quake function calls to invoke operations like build, clean, ship, etc. I have determined that the change directory (cd) call is not working properly. Here is an example quake function used by Reactor to build a package: proc build_package (pkg, options) is exec ("cd", pkg, "| cm3", options) end If I had a package "Hello" located in C:\MyPkgs\Hello, here is what the exec call looks like: exec ("cd C:\MyPkgs\Hello | cm3") What is happening is that the "cd" is ignored and "cm3" is being called in the current directory (whichever that happens to be). Thus, the cm3.exe can't find the sources for the package. I've gone back to the old v5.2.6, and this wrong behavior does not occur. Instead, everything works as it should. So something has changed since that point in time that is causing a problem. Any ideas? Regards, Randy -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Wed Jan 23 10:11:15 2008 From: jayk123 at hotmail.com (Jay) Date: Wed, 23 Jan 2008 09:11:15 +0000 Subject: [M3devel] new problem on NT386 In-Reply-To: <4796B970.1E75.00D7.1@scires.com> References: <4796B970.1E75.00D7.1@scires.com> Message-ID: Surprising, but I'm sure it is trivial. For now try this: exec ("cmd", "/c \"", pkg, "| cm3", options, "\"") and if that doesn't work > "foo.cmd" in write(pkg, "| cm3", options) end exec("foo.cmd") or in the very unlikely change THAT doesn't work, exec("cmd /c foo.cmd") or exec("cmd", "/c", "foo.cmd") See version.quake for examples. cd %cvsroot% dir /s/b version.quake I'm embarrased about my proficiency with cmd and Quake. :) Actually for an even better related example maybe, look at m3cc\m3makefile and m3gdb\m3makefile. dir /s/b %cvsroot%\m3makefile | findstr /i m3cc have quick edit turned on in your cmd double click the output, right click once maybe (it's hard to remember verbally the muscle memory here) and then file.open, paste the Windows command line is nice! until you to start "programming it" with cmd (and then it can be nice, but not for long).... You will be sitting in the target directory likely so you don't need a unique file name. I have been prepending "private" temporary files with "_m3", like "_m3responsefile.txt", "_m3something.cmd". CM3 uses ".M3" but I don't like hidden files as that achieves on Unix, they just hide stuff that inevitably should be visible. (I keep going back and forth about the "@" characters in config files. For now, I have revealed the once per directory mklib and link/gcc, and the occasional C compilation, but kept hidden the repeated runs of m3cg and as; don't worry, this only applies to NT386 and my config-no-install directory.) What, Reactor is implemented in Quake instead of Modula-3? :) Later, - Jay Date: Wed, 23 Jan 2008 03:50:10 -0500From: rcoleburn at scires.comTo: m3devel at elegosoft.comSubject: [M3devel] new problem on NT386 As you know, I am working to finalize the new Reactor. I've run into a new problem that did not exist on cm3 v5.2.6 or on cm3 v4.1, so I am hoping someone, perhaps Jay, can shed some light. Reactor uses quake function calls to invoke operations like build, clean, ship, etc. I have determined that the change directory (cd) call is not working properly. Here is an example quake function used by Reactor to build a package: proc build_package (pkg, options) is exec ("cd", pkg, "| cm3", options)end If I had a package "Hello" located in C:\MyPkgs\Hello, here is what the exec call looks like: exec ("cd C:\MyPkgs\Hello | cm3") What is happening is that the "cd" is ignored and "cm3" is being called in the current directory (whichever that happens to be). Thus, the cm3.exe can't find the sources for the package. I've gone back to the old v5.2.6, and this wrong behavior does not occur. Instead, everything works as it should. So something has changed since that point in time that is causing a problem. Any ideas? Regards, Randy _________________________________________________________________ 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 rcoleburn at scires.com Wed Jan 23 11:29:31 2008 From: rcoleburn at scires.com (Randy Coleburn) Date: Wed, 23 Jan 2008 05:29:31 -0500 Subject: [M3devel] new problem on NT386 In-Reply-To: <4796B970.1E75.00D7.1@scires.com> References: <4796B970.1E75.00D7.1@scires.com> Message-ID: <4796D0BA.1E75.00D7.1@scires.com> OK, scratch what I said in my prior message about the "cd" not working. I ran some more tests and I'm not sure anymore. Jay, what has changed in the way quake, cm3, and cm3.cfg interact since v5.2.6? What I am seeing is that when Reactor is built using the current cm3, the output that should be going to the web browser is instead going to the console log. This is strange. The same exact code compiled under 5.2.6 works correctly (output goes to browser). Also, there are some strange differences in the output and the results are different. Not only are the results different, they are wrong under the new system, while they are correct under 5.2.6. Indeed, the build operation on the new system does not even find the correct package. Reactor is written in Modula-3, but it does use some quake helper functions. Here are the quake sources that Reactor is using for the clean and build procedures: proc clean_package (pkg) is exec ("cd", pkg, "| cm3 -verbose -clean") end proc build_package (pkg, options) is exec ("cd", pkg, "| cm3 -verbose", options) end As you can see, I've turned on the -verbose cm3 option to make the differences clear. Now, what I present next is the verbose output of 4 different operations, in the following order: 1. clean_package on 5.2.6 2. build_package on 5.2.6 3. clean_package on current cm3 4. build_package on current cm3 #1 and #2 work fine, while #3 and #4 do not. The source code for the Reactor package is the exact same in all 4 runs, the difference is that in 1 & 2 the source is built on v5.2.6, while in #3 & #4 it is built on the current cm3 checked out from the repository a few days ago. ==================================================================================== #1: Here is the result of running a clean operation followed by a build operation on the 5.2.6 cm3 system. (This version is correct!) cd C:\DOCUME~1\rcolebur\MYDOCU~1\CM3_ID~1\hello | cm3 -verbose -clean EVAL ("m3make.args") rm .M3SHIP rm .M3OVERRIDES rm Hello.mc rm Hello.ms rm Hello.mo rm Hello_m.o rm .M3EXPORTS rm hello.exe rm hello.mx rm .M3WEB rm hello.map rm hello.lst rm _m3main.c rm _m3main.o rm _m3main.obj rm .M3WEB seconds #times operation 0.02 16 removing temporary files 0.03 other --------------------------------------------------- 0.05 TOTAL rm m3make.args cd .. ================================================================================= #2: Now, the build operation on 5.2.6 (again, this is correct): cd C:\DOCUME~1\rcolebur\MYDOCU~1\CM3_ID~1\hello | cm3 -verbose EVAL ("m3make.args") rm .M3SHIP rm .M3OVERRIDES inhale hello.mx inhale c:\cm3\pkg\m3core\NT386\m3core.lib reading "c:\cm3\pkg\m3core\NT386\m3core.m3x": 0 seconds no source to match imported link unit M3_BUILTIN.i3 inhale c:\cm3\pkg\libm3\NT386\m3.lib reading "c:\cm3\pkg\libm3\NT386\m3.m3x": 0 seconds checking Hello.m3 checking IO.i3 in library c:\cm3\pkg\libm3\NT386\m3.lib checking Wr.i3 in library c:\cm3\pkg\libm3\NT386\m3.lib checking Thread.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking RTHooks.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking TextCat.m3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking TextLiteral.m3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking RTThread.m3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking RTType.m3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking RTDebug.m3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking RTAllocator.m3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking RTHooks.m3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking ThreadWin32.m3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking OSConfig.i3 in library c:\cm3\pkg\libm3\NT386\m3.lib checking OSConfigWin32.m3 in library c:\cm3\pkg\libm3\NT386\m3.lib checking AtomList.i3 in library c:\cm3\pkg\libm3\NT386\m3.lib checking Atom.i3 in library c:\cm3\pkg\libm3\NT386\m3.lib checking Atom.m3 in library c:\cm3\pkg\libm3\NT386\m3.lib checking AtomList.m3 in library c:\cm3\pkg\libm3\NT386\m3.lib checking Wr.m3 in library c:\cm3\pkg\libm3\NT386\m3.lib checking Rd.i3 in library c:\cm3\pkg\libm3\NT386\m3.lib checking Rd.m3 in library c:\cm3\pkg\libm3\NT386\m3.lib checking IO.m3 in library c:\cm3\pkg\libm3\NT386\m3.lib checking Main.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking FloatMode.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking FloatMode.m3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking Lex.i3 in library c:\cm3\pkg\libm3\NT386\m3.lib checking Word.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking Word.m3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking Lex.m3 in library c:\cm3\pkg\libm3\NT386\m3.lib checking OSError.i3 in library c:\cm3\pkg\libm3\NT386\m3.lib checking OSErrorWin32.m3 in library c:\cm3\pkg\libm3\NT386\m3.lib checking Fmt.i3 in library c:\cm3\pkg\libm3\NT386\m3.lib checking Extended.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking Extended.m3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking LongReal.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking LongReal.m3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking Real.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking Real.m3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking Fmt.m3 in library c:\cm3\pkg\libm3\NT386\m3.lib checking FileWr.i3 in library c:\cm3\pkg\libm3\NT386\m3.lib checking Pathname.i3 in library c:\cm3\pkg\libm3\NT386\m3.lib checking TextSeq.i3 in library c:\cm3\pkg\libm3\NT386\m3.lib checking Text.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking TextClass.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking M3_BUILTIN.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking TextClass.m3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking TextSub.m3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking Text.m3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking TextSeq.m3 in library c:\cm3\pkg\libm3\NT386\m3.lib checking PathnameWin32.m3 in library c:\cm3\pkg\libm3\NT386\m3.lib checking File.i3 in library c:\cm3\pkg\libm3\NT386\m3.lib checking Time.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking TimeWin32.m3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking FileWr.m3 in library c:\cm3\pkg\libm3\NT386\m3.lib checking FileRd.i3 in library c:\cm3\pkg\libm3\NT386\m3.lib checking FileRd.m3 in library c:\cm3\pkg\libm3\NT386\m3.lib checking Stdio.i3 in library c:\cm3\pkg\libm3\NT386\m3.lib checking Stdio.m3 in library c:\cm3\pkg\libm3\NT386\m3.lib checking WrClass.i3 in library c:\cm3\pkg\libm3\NT386\m3.lib checking Process.i3 in library c:\cm3\pkg\libm3\NT386\m3.lib checking ProcessWin32.m3 in library c:\cm3\pkg\libm3\NT386\m3.lib checking WinBase.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking Ctypes.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking BasicCtypes.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking WinDef.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking WinBaseTypes.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking WinDef.m3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking WinNT.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking WinNT.m3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking RTProcess.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking RTProcess.m3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking OSErrorWin32.i3 in library c:\cm3\pkg\libm3\NT386\m3.lib checking M3toC.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking M3toC.m3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking LazyConsole.i3 in library c:\cm3\pkg\libm3\NT386\m3.lib checking FileWin32.i3 in library c:\cm3\pkg\libm3\NT386\m3.lib checking Pipe.i3 in library c:\cm3\pkg\libm3\NT386\m3.lib checking PipeWin32.m3 in library c:\cm3\pkg\libm3\NT386\m3.lib checking Pipe.m3 in library c:\cm3\pkg\libm3\NT386\m3.lib checking FileWin32.m3 in library c:\cm3\pkg\libm3\NT386\m3.lib checking LazyConsole.m3 in library c:\cm3\pkg\libm3\NT386\m3.lib checking WinCon.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking Terminal.i3 in library c:\cm3\pkg\libm3\NT386\m3.lib checking Terminal.m3 in library c:\cm3\pkg\libm3\NT386\m3.lib checking TimeWin32.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking WinError.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking RegularFile.i3 in library c:\cm3\pkg\libm3\NT386\m3.lib checking RegularFile.m3 in library c:\cm3\pkg\libm3\NT386\m3.lib checking Text8CString.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking Text8CString.m3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking Text8.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking Text8.m3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking Cstring.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking Cstdlib.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking Cstddef.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking Text8Short.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking Text8Short.m3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking RTOS.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking RTOS.m3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking RTIO.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking RTIO.m3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking RTException.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking RT0.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking RT0.m3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking RTExFrame.m3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking RTException.m3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking RTHeapRep.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking RTHeapDep.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking RTMachine.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking Csetjmp.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking RTHeapDep.m3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking RTCollector.m3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking RTHeapRep.m3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking RTType.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking TextLiteral.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking RuntimeError.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking RuntimeError.m3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking ThreadF.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking RTPerfTool.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking RTPerfTool.m3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking RTParams.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking RTParams.m3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking RTMisc.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking RTMisc.m3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking RTVM.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking RTHeapMap.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking RTHeapMap.m3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking RTHeapEvent.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking RTWeakRef.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking RTCollectorSRC.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking RTCollector.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking RTMapOp.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking RTTypeMap.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking RTTypeMap.m3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking RTMapOp.m3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking RTModule.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking RTLinker.m3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking RTLinkerX.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking RTHeapInfo.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking RTHeapInfo.m3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking RTThreadInit.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking RTSignal.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking RTSignal.m3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking RTTypeSRC.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking RTLinker.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking ThreadContext.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking RTError.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking RTError.m3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking RTMachInfo.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking RTMachInfo.m3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking RTProcedureSRC.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking RTProcedure.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking Fingerprint.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking Fingerprint.m3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking RTProcedure.m3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking Poly.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking Poly.m3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking PolyBasis.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking PolyBasis.m3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking RTAllocCnts.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking RTArgs.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking RTArgs.m3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking Compiler.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking Compiler.m3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking RTThread.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking RTExFrame.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking RdClass.i3 in library c:\cm3\pkg\libm3\NT386\m3.lib checking FS.i3 in library c:\cm3\pkg\libm3\NT386\m3.lib checking FSWin32.m3 in library c:\cm3\pkg\libm3\NT386\m3.lib checking FS.m3 in library c:\cm3\pkg\libm3\NT386\m3.lib checking OSWin32.i3 in library c:\cm3\pkg\libm3\NT386\m3.lib checking OSWin32.m3 in library c:\cm3\pkg\libm3\NT386\m3.lib checking TextSeqRep.i3 in library c:\cm3\pkg\libm3\NT386\m3.lib checking String16.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking String16.m3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking String8.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking String8.m3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking Text16.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking Text16.m3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking Text16Short.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking Text16Short.m3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking TextCat.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking TextSub.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking ExtendedFloat.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking ExtendedFloat.m3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking LongFloat.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking LongFloat.m3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking RealFloat.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking RealFloat.m3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking FmtBufF.i3 in library c:\cm3\pkg\libm3\NT386\m3.lib checking FmtBuf.i3 in library c:\cm3\pkg\libm3\NT386\m3.lib checking FmtBuf.m3 in library c:\cm3\pkg\libm3\NT386\m3.lib checking Convert.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking Convert.m3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking CConvert.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking CConvert.m3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking FmtBufTest.i3 in library c:\cm3\pkg\libm3\NT386\m3.lib checking FPU.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking FPU.m3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking DragonT.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking DragonT.m3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking RealRep.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking DragonInt.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking DragonInt.m3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking LongRealRep.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking IEEESpecial.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking IEEESpecial.m3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking UnsafeRd.i3 in library c:\cm3\pkg\libm3\NT386\m3.lib checking UnsafeWr.i3 in library c:\cm3\pkg\libm3\NT386\m3.lib checking AtomAtomTbl.i3 in library c:\cm3\pkg\libm3\NT386\m3.lib checking AtomAtomTbl.m3 in library c:\cm3\pkg\libm3\NT386\m3.lib checking WinSock.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking WinSock.m3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking Env.i3 in library c:\cm3\pkg\libm3\NT386\m3.lib checking Env.m3 in library c:\cm3\pkg\libm3\NT386\m3.lib checking MutexRep.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking WinGDI.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking WinGDI.m3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking Scheduler.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking RTHeap.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking RTHeap.m3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking RTAllocator.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib checking RTDebug.i3 in library c:\cm3\pkg\m3core\NT386\m3core.lib Compiling Hello.m3 (new source) m3front ..\src\Hello.m3 -unfold_nested_procs -check_procs -w1 exhale hello.mx linking hello.exe generate _m3main.obj C:\PROGRA~1\MID05A~1\VC\bin\LINK @C:\DOCUME~1\rcolebur\LOCALS~1\Temp\qk > hello.lst m3_link => 0 seconds #times operation 0.02 3 inhaling library link info 0.03 224 merging new link info 0.02 1 generating _m3main.c 0.11 1 linking 0.02 3 garbage collection --------------------------------------------------- 0.19 TOTAL rm m3make.args cd .. ================================================================================= #3: Here is the clean operation on the current cm3 system (this is different, and wrong): calling clean_package("C:\DOCUME~1\cm3\MYDOCU~1\CM3_ID~1\hello") EVAL ("cm3.cfg") mkdir NT386 --- cleaning NT386 --- cd NT386 Looking in .. ignoring ..\anim3D.dll (not a directory) ignoring ..\anim3D.pdb (not a directory) ignoring ..\binIO.dll (not a directory) ignoring ..\binIO.pdb (not a directory) ignoring ..\BitVector.dll (not a directory) ignoring ..\BitVector.pdb (not a directory) ignoring ..\Calculator.exe (not a directory) ignoring ..\Calculator.pdb (not a directory) ignoring ..\CheckForNetObjD.exe (not a directory) ignoring ..\CheckForNetObjD.pdb (not a directory) ignoring ..\cm3-d5.5.0.exe (not a directory) ignoring ..\cm3-d5.5.0.pdb (not a directory) ignoring ..\cm3-d5.5.1.exe (not a directory) ignoring ..\cm3-d5.5.1.pdb (not a directory) ignoring ..\cm3.cfg (not a directory) ignoring ..\cm3.exe (not a directory) ignoring ..\cm3.pdb (not a directory) ignoring ..\cm3ide.exe (not a directory) ignoring ..\cm3ide.pdb (not a directory) ignoring ..\cm3Proj.CMD (not a directory) ignoring ..\cm3SetupCmdEnv.CMD (not a directory) ignoring ..\cm3StartIDE.CMD (not a directory) ignoring ..\cm3v41.cfg (not a directory) ignoring ..\cmpdir.exe (not a directory) ignoring ..\cmpdir.pdb (not a directory) ignoring ..\cmpfp.pdb (not a directory) ignoring ..\cmvbt.dll (not a directory) ignoring ..\cmvbt.pdb (not a directory) ignoring ..\Cube.exe (not a directory) ignoring ..\Cube.pdb (not a directory) ignoring ..\CV_Banner.exe (not a directory) ignoring ..\CV_Banner.pdb (not a directory) ignoring ..\CV_Client.exe (not a directory) ignoring ..\CV_Client.pdb (not a directory) ignoring ..\CV_ListConfigDefns.exe (not a directory) ignoring ..\CV_ListConfigDefns.pdb (not a directory) ignoring ..\CV_MessageTool.exe (not a directory) ignoring ..\CV_MessageTool.pdb (not a directory) ignoring ..\CV_Server.exe (not a directory) ignoring ..\CV_Server.pdb (not a directory) ignoring ..\CV_Shutdown.exe (not a directory) ignoring ..\CV_Shutdown.pdb (not a directory) ignoring ..\cygwin1.dll (not a directory) ignoring ..\db.dll (not a directory) ignoring ..\db.pdb (not a directory) ignoring ..\debug.dll (not a directory) ignoring ..\debug.pdb (not a directory) ignoring ..\deepcopy.dll (not a directory) ignoring ..\deepcopy.pdb (not a directory) ignoring ..\DiGraph.dll (not a directory) ignoring ..\DiGraph.pdb (not a directory) ignoring ..\dirfp.exe (not a directory) ignoring ..\dirfp.pdb (not a directory) ignoring ..\Documentation_cm3Proj.htm (not a directory) ignoring ..\Documentation_cm3Proj.pdf (not a directory) ignoring ..\Documentation_CM3SetupCmdEnv.htm (not a directory) ignoring ..\Documentation_CM3SetupCmdEnv.pdf (not a directory) ignoring ..\Documentation_CM3StartIDE.htm (not a directory) ignoring ..\Documentation_CM3StartIDE.pdf (not a directory) ignoring ..\DummyNavServer.exe (not a directory) ignoring ..\DummyNavServer.pdb (not a directory) ignoring ..\embutils.dll (not a directory) ignoring ..\embutils.pdb (not a directory) ignoring ..\events.dll (not a directory) ignoring ..\events.pdb (not a directory) ignoring ..\fisheye.exe (not a directory) ignoring ..\fisheye.pdb (not a directory) ignoring ..\fix_nl.exe (not a directory) ignoring ..\fix_nl.pdb (not a directory) ignoring ..\foo2.pdb (not a directory) ignoring ..\formsedit.exe (not a directory) ignoring ..\formsedit.pdb (not a directory) ignoring ..\formsview.pdb (not a directory) ignoring ..\Geometry.dll (not a directory) ignoring ..\Geometry.pdb (not a directory) ignoring ..\gzip.exe (not a directory) ignoring ..\http.dll (not a directory) ignoring ..\http.pdb (not a directory) ignoring ..\juno-compiler.dll (not a directory) ignoring ..\juno-compiler.pdb (not a directory) ignoring ..\juno-machine.dll (not a directory) ignoring ..\juno-machine.pdb (not a directory) ignoring ..\Juno.exe (not a directory) ignoring ..\Juno.pdb (not a directory) ignoring ..\jvideo.dll (not a directory) ignoring ..\jvideo.pdb (not a directory) ignoring ..\libbuf.dll (not a directory) ignoring ..\libbuf.pdb (not a directory) ignoring ..\libCV.dll (not a directory) ignoring ..\libCV.pdb (not a directory) ignoring ..\libdump.pdb (not a directory) ignoring ..\libGUI.dll (not a directory) ignoring ..\libGUI.pdb (not a directory) ignoring ..\libSciRes3.dll (not a directory) ignoring ..\libSciRes3.pdb (not a directory) ignoring ..\libsio.dll (not a directory) ignoring ..\libsio.pdb (not a directory) ignoring ..\listfuncs.dll (not a directory) ignoring ..\listfuncs.pdb (not a directory) ignoring ..\m3.dll (not a directory) ignoring ..\m3.pdb (not a directory) ignoring ..\m3back.pdb (not a directory) ignoring ..\m3browser.exe (not a directory) ignoring ..\m3browser.pdb (not a directory) ignoring ..\m3bundle.exe (not a directory) ignoring ..\m3bundle.pdb (not a directory) ignoring ..\m3cgcat.pdb (not a directory) ignoring ..\m3cggen.pdb (not a directory) ignoring ..\m3codeview.dll (not a directory) ignoring ..\m3codeview.pdb (not a directory) ignoring ..\m3core.dll (not a directory) ignoring ..\m3core.pdb (not a directory) ignoring ..\m3formsvbt.dll (not a directory) ignoring ..\m3formsvbt.pdb (not a directory) ignoring ..\m3formsvbtpixmaps.dll (not a directory) ignoring ..\m3formsvbtpixmaps.pdb (not a directory) ignoring ..\m3markup.dll (not a directory) ignoring ..\m3markup.pdb (not a directory) ignoring ..\m3mg.dll (not a directory) ignoring ..\m3mg.pdb (not a directory) ignoring ..\m3mgkit.dll (not a directory) ignoring ..\m3mgkit.pdb (not a directory) ignoring ..\m3netobj.dll (not a directory) ignoring ..\m3netobj.pdb (not a directory) ignoring ..\m3parseparams.dll (not a directory) ignoring ..\m3parseparams.pdb (not a directory) ignoring ..\m3scan.dll (not a directory) ignoring ..\m3scan.pdb (not a directory) ignoring ..\m3slisp.dll (not a directory) ignoring ..\m3slisp.pdb (not a directory) ignoring ..\m3smalldb.dll (not a directory) ignoring ..\m3smalldb.pdb (not a directory) ignoring ..\m3tcl.dll (not a directory) ignoring ..\m3tcl.pdb (not a directory) ignoring ..\m3tcp.dll (not a directory) ignoring ..\m3tcp.pdb (not a directory) ignoring ..\m3tk-misc.dll (not a directory) ignoring ..\m3tk-misc.pdb (not a directory) ignoring ..\m3tk.dll (not a directory) ignoring ..\m3tk.pdb (not a directory) ignoring ..\m3tohtml.exe (not a directory) ignoring ..\m3tohtml.pdb (not a directory) ignoring ..\m3totex.exe (not a directory) ignoring ..\m3totex.pdb (not a directory) ignoring ..\m3ui.dll (not a directory) ignoring ..\m3ui.pdb (not a directory) ignoring ..\m3vbtkit.dll (not a directory) ignoring ..\m3vbtkit.pdb (not a directory) ignoring ..\m3zeus.dll (not a directory) ignoring ..\m3zeus.pdb (not a directory) ignoring ..\m3zume.exe (not a directory) ignoring ..\m3zume.pdb (not a directory) ignoring ..\MakeShortPath.cmd (not a directory) ignoring ..\mentor.exe (not a directory) ignoring ..\mentor.pdb (not a directory) ignoring ..\metasyn.dll (not a directory) ignoring ..\metasyn.pdb (not a directory) ignoring ..\mklib.exe (not a directory) ignoring ..\mklib.pdb (not a directory) ignoring ..\netobjd.exe (not a directory) ignoring ..\netobjd.pdb (not a directory) ignoring ..\NT386 (derived object directory) ignoring ..\obliq (not a directory) ignoring ..\obliq-anim.exe (not a directory) ignoring ..\obliq-anim.pdb (not a directory) ignoring ..\obliq-min.exe (not a directory) ignoring ..\obliq-min.pdb (not a directory) ignoring ..\obliq-std.exe (not a directory) ignoring ..\obliq-std.pdb (not a directory) ignoring ..\obliq-ui.exe (not a directory) ignoring ..\obliq-ui.pdb (not a directory) ignoring ..\obliq.dll (not a directory) ignoring ..\obliq.pdb (not a directory) ignoring ..\obliqlibanim.dll (not a directory) ignoring ..\obliqlibanim.pdb (not a directory) ignoring ..\obliqlibemb.dll (not a directory) ignoring ..\obliqlibemb.pdb (not a directory) ignoring ..\obliqlibm3.dll (not a directory) ignoring ..\obliqlibm3.pdb (not a directory) ignoring ..\obliqlibui.dll (not a directory) ignoring ..\obliqlibui.pdb (not a directory) ignoring ..\obliqparse.dll (not a directory) ignoring ..\obliqparse.pdb (not a directory) ignoring ..\obliqprint.dll (not a directory) ignoring ..\obliqprint.pdb (not a directory) ignoring ..\obliqrt.dll (not a directory) ignoring ..\obliqrt.pdb (not a directory) ignoring ..\obliqsrv (not a directory) ignoring ..\obliqsrv-std.exe (not a directory) ignoring ..\obliqsrv-std.pdb (not a directory) ignoring ..\obliqsrv-ui.exe (not a directory) ignoring ..\obliqsrv-ui.pdb (not a directory) ignoring ..\odbc.dll (not a directory) ignoring ..\odbc.pdb (not a directory) ignoring ..\opengl.dll (not a directory) ignoring ..\opengl.pdb (not a directory) ignoring ..\patternmatching.dll (not a directory) ignoring ..\patternmatching.pdb (not a directory) ignoring ..\PklFonts.pdb (not a directory) ignoring ..\rdwr.dll (not a directory) ignoring ..\rdwr.pdb (not a directory) ignoring ..\recordheap (not a directory) ignoring ..\RehearseCode.exe (not a directory) ignoring ..\RehearseCode.pdb (not a directory) ignoring ..\replayheap.exe (not a directory) ignoring ..\replayheap.pdb (not a directory) ignoring ..\serial2.dll (not a directory) ignoring ..\serial2.pdb (not a directory) ignoring ..\serialio.dll (not a directory) ignoring ..\serialio.pdb (not a directory) ignoring ..\set.dll (not a directory) ignoring ..\set.pdb (not a directory) ignoring ..\sgml.dll (not a directory) ignoring ..\sgml.pdb (not a directory) ignoring ..\sharedobj.dll (not a directory) ignoring ..\sharedobj.pdb (not a directory) ignoring ..\shobjcodegen.exe (not a directory) ignoring ..\shobjcodegen.pdb (not a directory) ignoring ..\showheap.exe (not a directory) ignoring ..\showheap.pdb (not a directory) ignoring ..\shownew.exe (not a directory) ignoring ..\shownew.pdb (not a directory) ignoring ..\showthread.exe (not a directory) ignoring ..\showthread.pdb (not a directory) ignoring ..\SortedTableExtras.dll (not a directory) ignoring ..\SortedTableExtras.pdb (not a directory) ignoring ..\stable.dll (not a directory) ignoring ..\stable.pdb (not a directory) ignoring ..\stablegen.exe (not a directory) ignoring ..\stablegen.pdb (not a directory) ignoring ..\stubgen.exe (not a directory) ignoring ..\stubgen.pdb (not a directory) ignoring ..\synex.dll (not a directory) ignoring ..\synex.pdb (not a directory) ignoring ..\synwr.dll (not a directory) ignoring ..\synwr.pdb (not a directory) ignoring ..\table-list.dll (not a directory) ignoring ..\table-list.pdb (not a directory) ignoring ..\tar.exe (not a directory) ignoring ..\TempFiles.dll (not a directory) ignoring ..\TempFiles.pdb (not a directory) ignoring ..\TestPixmap.pdb (not a directory) ignoring ..\UDP.dll (not a directory) ignoring ..\UDP.pdb (not a directory) ignoring ..\uniq.pdb (not a directory) ignoring ..\videovbt.dll (not a directory) ignoring ..\videovbt.pdb (not a directory) ignoring ..\visobliq.exe (not a directory) ignoring ..\visobliq.pdb (not a directory) ignoring ..\vocgi.exe (not a directory) ignoring ..\vocgi.pdb (not a directory) ignoring ..\voquery.exe (not a directory) ignoring ..\voquery.pdb (not a directory) ignoring ..\vorun.exe (not a directory) ignoring ..\vorun.pdb (not a directory) ignoring ..\vostart (not a directory) ignoring ..\vostart.cmd (not a directory) ignoring ..\web.dll (not a directory) ignoring ..\web.pdb (not a directory) ignoring ..\webvbt.dll (not a directory) ignoring ..\webvbt.pdb (not a directory) ignoring ..\windowsResources.dll (not a directory) ignoring ..\windowsResources.pdb (not a directory) ignoring ..\zapNT386.cmd (not a directory) EVAL ("m3make.args") rm .M3SHIP rm .M3OVERRIDES rm .M3EXPORTS rm prog.exe rm prog.mx rm .M3WEB rm prog.map rm prog.lst rm _m3main.c rm _m3main.o rm _m3main.obj rm .M3WEB seconds #times operation 0.01 3 garbage collection 0.04 other --------------------------------------------------- 0.05 TOTAL rm m3make.args cd .. is_empty (NT386) => rmdir NT386 ================================================================================= #4: Here is the build operation on the current cm3 (this is different from v5.2.6 and wrong--it does not find the package to build!): calling build_package("C:\DOCUME~1\cm3\MYDOCU~1\CM3_ID~1\hello", "") EVAL ("cm3.cfg") mkdir NT386 --- building in NT386 --- cd NT386 Looking in .. ignoring ..\anim3D.dll (not a directory) ignoring ..\anim3D.pdb (not a directory) ignoring ..\binIO.dll (not a directory) ignoring ..\binIO.pdb (not a directory) ignoring ..\BitVector.dll (not a directory) ignoring ..\BitVector.pdb (not a directory) ignoring ..\Calculator.exe (not a directory) ignoring ..\Calculator.pdb (not a directory) ignoring ..\CheckForNetObjD.exe (not a directory) ignoring ..\CheckForNetObjD.pdb (not a directory) ignoring ..\cm3-d5.5.0.exe (not a directory) ignoring ..\cm3-d5.5.0.pdb (not a directory) ignoring ..\cm3-d5.5.1.exe (not a directory) ignoring ..\cm3-d5.5.1.pdb (not a directory) ignoring ..\cm3.cfg (not a directory) ignoring ..\cm3.exe (not a directory) ignoring ..\cm3.pdb (not a directory) ignoring ..\cm3ide.exe (not a directory) ignoring ..\cm3ide.pdb (not a directory) ignoring ..\cm3Proj.CMD (not a directory) ignoring ..\cm3SetupCmdEnv.CMD (not a directory) ignoring ..\cm3StartIDE.CMD (not a directory) ignoring ..\cm3v41.cfg (not a directory) ignoring ..\cmpdir.exe (not a directory) ignoring ..\cmpdir.pdb (not a directory) ignoring ..\cmpfp.pdb (not a directory) ignoring ..\cmvbt.dll (not a directory) ignoring ..\cmvbt.pdb (not a directory) ignoring ..\Cube.exe (not a directory) ignoring ..\Cube.pdb (not a directory) ignoring ..\CV_Banner.exe (not a directory) ignoring ..\CV_Banner.pdb (not a directory) ignoring ..\CV_Client.exe (not a directory) ignoring ..\CV_Client.pdb (not a directory) ignoring ..\CV_ListConfigDefns.exe (not a directory) ignoring ..\CV_ListConfigDefns.pdb (not a directory) ignoring ..\CV_MessageTool.exe (not a directory) ignoring ..\CV_MessageTool.pdb (not a directory) ignoring ..\CV_Server.exe (not a directory) ignoring ..\CV_Server.pdb (not a directory) ignoring ..\CV_Shutdown.exe (not a directory) ignoring ..\CV_Shutdown.pdb (not a directory) ignoring ..\cygwin1.dll (not a directory) ignoring ..\db.dll (not a directory) ignoring ..\db.pdb (not a directory) ignoring ..\debug.dll (not a directory) ignoring ..\debug.pdb (not a directory) ignoring ..\deepcopy.dll (not a directory) ignoring ..\deepcopy.pdb (not a directory) ignoring ..\DiGraph.dll (not a directory) ignoring ..\DiGraph.pdb (not a directory) ignoring ..\dirfp.exe (not a directory) ignoring ..\dirfp.pdb (not a directory) ignoring ..\Documentation_cm3Proj.htm (not a directory) ignoring ..\Documentation_cm3Proj.pdf (not a directory) ignoring ..\Documentation_CM3SetupCmdEnv.htm (not a directory) ignoring ..\Documentation_CM3SetupCmdEnv.pdf (not a directory) ignoring ..\Documentation_CM3StartIDE.htm (not a directory) ignoring ..\Documentation_CM3StartIDE.pdf (not a directory) ignoring ..\DummyNavServer.exe (not a directory) ignoring ..\DummyNavServer.pdb (not a directory) ignoring ..\embutils.dll (not a directory) ignoring ..\embutils.pdb (not a directory) ignoring ..\events.dll (not a directory) ignoring ..\events.pdb (not a directory) ignoring ..\fisheye.exe (not a directory) ignoring ..\fisheye.pdb (not a directory) ignoring ..\fix_nl.exe (not a directory) ignoring ..\fix_nl.pdb (not a directory) ignoring ..\foo2.pdb (not a directory) ignoring ..\formsedit.exe (not a directory) ignoring ..\formsedit.pdb (not a directory) ignoring ..\formsview.pdb (not a directory) ignoring ..\Geometry.dll (not a directory) ignoring ..\Geometry.pdb (not a directory) ignoring ..\gzip.exe (not a directory) ignoring ..\http.dll (not a directory) ignoring ..\http.pdb (not a directory) ignoring ..\juno-compiler.dll (not a directory) ignoring ..\juno-compiler.pdb (not a directory) ignoring ..\juno-machine.dll (not a directory) ignoring ..\juno-machine.pdb (not a directory) ignoring ..\Juno.exe (not a directory) ignoring ..\Juno.pdb (not a directory) ignoring ..\jvideo.dll (not a directory) ignoring ..\jvideo.pdb (not a directory) ignoring ..\libbuf.dll (not a directory) ignoring ..\libbuf.pdb (not a directory) ignoring ..\libCV.dll (not a directory) ignoring ..\libCV.pdb (not a directory) ignoring ..\libdump.pdb (not a directory) ignoring ..\libGUI.dll (not a directory) ignoring ..\libGUI.pdb (not a directory) ignoring ..\libSciRes3.dll (not a directory) ignoring ..\libSciRes3.pdb (not a directory) ignoring ..\libsio.dll (not a directory) ignoring ..\libsio.pdb (not a directory) ignoring ..\listfuncs.dll (not a directory) ignoring ..\listfuncs.pdb (not a directory) ignoring ..\m3.dll (not a directory) ignoring ..\m3.pdb (not a directory) ignoring ..\m3back.pdb (not a directory) ignoring ..\m3browser.exe (not a directory) ignoring ..\m3browser.pdb (not a directory) ignoring ..\m3bundle.exe (not a directory) ignoring ..\m3bundle.pdb (not a directory) ignoring ..\m3cgcat.pdb (not a directory) ignoring ..\m3cggen.pdb (not a directory) ignoring ..\m3codeview.dll (not a directory) ignoring ..\m3codeview.pdb (not a directory) ignoring ..\m3core.dll (not a directory) ignoring ..\m3core.pdb (not a directory) ignoring ..\m3formsvbt.dll (not a directory) ignoring ..\m3formsvbt.pdb (not a directory) ignoring ..\m3formsvbtpixmaps.dll (not a directory) ignoring ..\m3formsvbtpixmaps.pdb (not a directory) ignoring ..\m3markup.dll (not a directory) ignoring ..\m3markup.pdb (not a directory) ignoring ..\m3mg.dll (not a directory) ignoring ..\m3mg.pdb (not a directory) ignoring ..\m3mgkit.dll (not a directory) ignoring ..\m3mgkit.pdb (not a directory) ignoring ..\m3netobj.dll (not a directory) ignoring ..\m3netobj.pdb (not a directory) ignoring ..\m3parseparams.dll (not a directory) ignoring ..\m3parseparams.pdb (not a directory) ignoring ..\m3scan.dll (not a directory) ignoring ..\m3scan.pdb (not a directory) ignoring ..\m3slisp.dll (not a directory) ignoring ..\m3slisp.pdb (not a directory) ignoring ..\m3smalldb.dll (not a directory) ignoring ..\m3smalldb.pdb (not a directory) ignoring ..\m3tcl.dll (not a directory) ignoring ..\m3tcl.pdb (not a directory) ignoring ..\m3tcp.dll (not a directory) ignoring ..\m3tcp.pdb (not a directory) ignoring ..\m3tk-misc.dll (not a directory) ignoring ..\m3tk-misc.pdb (not a directory) ignoring ..\m3tk.dll (not a directory) ignoring ..\m3tk.pdb (not a directory) ignoring ..\m3tohtml.exe (not a directory) ignoring ..\m3tohtml.pdb (not a directory) ignoring ..\m3totex.exe (not a directory) ignoring ..\m3totex.pdb (not a directory) ignoring ..\m3ui.dll (not a directory) ignoring ..\m3ui.pdb (not a directory) ignoring ..\m3vbtkit.dll (not a directory) ignoring ..\m3vbtkit.pdb (not a directory) ignoring ..\m3zeus.dll (not a directory) ignoring ..\m3zeus.pdb (not a directory) ignoring ..\m3zume.exe (not a directory) ignoring ..\m3zume.pdb (not a directory) ignoring ..\MakeShortPath.cmd (not a directory) ignoring ..\mentor.exe (not a directory) ignoring ..\mentor.pdb (not a directory) ignoring ..\metasyn.dll (not a directory) ignoring ..\metasyn.pdb (not a directory) ignoring ..\mklib.exe (not a directory) ignoring ..\mklib.pdb (not a directory) ignoring ..\netobjd.exe (not a directory) ignoring ..\netobjd.pdb (not a directory) ignoring ..\NT386 (derived object directory) ignoring ..\obliq (not a directory) ignoring ..\obliq-anim.exe (not a directory) ignoring ..\obliq-anim.pdb (not a directory) ignoring ..\obliq-min.exe (not a directory) ignoring ..\obliq-min.pdb (not a directory) ignoring ..\obliq-std.exe (not a directory) ignoring ..\obliq-std.pdb (not a directory) ignoring ..\obliq-ui.exe (not a directory) ignoring ..\obliq-ui.pdb (not a directory) ignoring ..\obliq.dll (not a directory) ignoring ..\obliq.pdb (not a directory) ignoring ..\obliqlibanim.dll (not a directory) ignoring ..\obliqlibanim.pdb (not a directory) ignoring ..\obliqlibemb.dll (not a directory) ignoring ..\obliqlibemb.pdb (not a directory) ignoring ..\obliqlibm3.dll (not a directory) ignoring ..\obliqlibm3.pdb (not a directory) ignoring ..\obliqlibui.dll (not a directory) ignoring ..\obliqlibui.pdb (not a directory) ignoring ..\obliqparse.dll (not a directory) ignoring ..\obliqparse.pdb (not a directory) ignoring ..\obliqprint.dll (not a directory) ignoring ..\obliqprint.pdb (not a directory) ignoring ..\obliqrt.dll (not a directory) ignoring ..\obliqrt.pdb (not a directory) ignoring ..\obliqsrv (not a directory) ignoring ..\obliqsrv-std.exe (not a directory) ignoring ..\obliqsrv-std.pdb (not a directory) ignoring ..\obliqsrv-ui.exe (not a directory) ignoring ..\obliqsrv-ui.pdb (not a directory) ignoring ..\odbc.dll (not a directory) ignoring ..\odbc.pdb (not a directory) ignoring ..\opengl.dll (not a directory) ignoring ..\opengl.pdb (not a directory) ignoring ..\patternmatching.dll (not a directory) ignoring ..\patternmatching.pdb (not a directory) ignoring ..\PklFonts.pdb (not a directory) ignoring ..\rdwr.dll (not a directory) ignoring ..\rdwr.pdb (not a directory) ignoring ..\recordheap (not a directory) ignoring ..\RehearseCode.exe (not a directory) ignoring ..\RehearseCode.pdb (not a directory) ignoring ..\replayheap.exe (not a directory) ignoring ..\replayheap.pdb (not a directory) ignoring ..\serial2.dll (not a directory) ignoring ..\serial2.pdb (not a directory) ignoring ..\serialio.dll (not a directory) ignoring ..\serialio.pdb (not a directory) ignoring ..\set.dll (not a directory) ignoring ..\set.pdb (not a directory) ignoring ..\sgml.dll (not a directory) ignoring ..\sgml.pdb (not a directory) ignoring ..\sharedobj.dll (not a directory) ignoring ..\sharedobj.pdb (not a directory) ignoring ..\shobjcodegen.exe (not a directory) ignoring ..\shobjcodegen.pdb (not a directory) ignoring ..\showheap.exe (not a directory) ignoring ..\showheap.pdb (not a directory) ignoring ..\shownew.exe (not a directory) ignoring ..\shownew.pdb (not a directory) ignoring ..\showthread.exe (not a directory) ignoring ..\showthread.pdb (not a directory) ignoring ..\SortedTableExtras.dll (not a directory) ignoring ..\SortedTableExtras.pdb (not a directory) ignoring ..\stable.dll (not a directory) ignoring ..\stable.pdb (not a directory) ignoring ..\stablegen.exe (not a directory) ignoring ..\stablegen.pdb (not a directory) ignoring ..\stubgen.exe (not a directory) ignoring ..\stubgen.pdb (not a directory) ignoring ..\synex.dll (not a directory) ignoring ..\synex.pdb (not a directory) ignoring ..\synwr.dll (not a directory) ignoring ..\synwr.pdb (not a directory) ignoring ..\table-list.dll (not a directory) ignoring ..\table-list.pdb (not a directory) ignoring ..\tar.exe (not a directory) ignoring ..\TempFiles.dll (not a directory) ignoring ..\TempFiles.pdb (not a directory) ignoring ..\TestPixmap.pdb (not a directory) ignoring ..\UDP.dll (not a directory) ignoring ..\UDP.pdb (not a directory) ignoring ..\uniq.pdb (not a directory) ignoring ..\videovbt.dll (not a directory) ignoring ..\videovbt.pdb (not a directory) ignoring ..\visobliq.exe (not a directory) ignoring ..\visobliq.pdb (not a directory) ignoring ..\vocgi.exe (not a directory) ignoring ..\vocgi.pdb (not a directory) ignoring ..\voquery.exe (not a directory) ignoring ..\voquery.pdb (not a directory) ignoring ..\vorun.exe (not a directory) ignoring ..\vorun.pdb (not a directory) ignoring ..\vostart (not a directory) ignoring ..\vostart.cmd (not a directory) ignoring ..\web.dll (not a directory) ignoring ..\web.pdb (not a directory) ignoring ..\webvbt.dll (not a directory) ignoring ..\webvbt.pdb (not a directory) ignoring ..\windowsResources.dll (not a directory) ignoring ..\windowsResources.pdb (not a directory) ignoring ..\zapNT386.cmd (not a directory) cm3: found nothing to build. rm m3make.args seconds #times operation 0.02 2 garbage collection 0.02 other --------------------------------------------------- 0.04 TOTAL cd .. is_empty (NT386) => rmdir NT386 Regards, Randy -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Wed Jan 23 12:20:02 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 23 Jan 2008 12:20:02 +0100 Subject: [M3devel] platform/build_dir is a big tuple? In-Reply-To: References: <479605CF.1E75.00D7.1@scires.com> Message-ID: <20080123122002.6rcdyji1us4okkww@mail.elegosoft.com> Quoting Henning Thielemann : > > On Tue, 22 Jan 2008, Randy Coleburn wrote: > >> Jay: >> >> For my part on Windows, I am happy to stay with the underlying OS, the >> native windows threading, the integrated backend, and use the free >> Microsoft Visual Studio tools. I don't really want to have to >> install/use cygwin or any of the other variants. When I see target = >> NT386, this list is what I am expecting. For the cm3 newbie coming from >> a Microsoft Windows environment, I think this list would be the most >> appealing and pose the least barrier to getting starting. Yes, I still >> will work on the installer program once I'm satisfied that I have a good >> working cm3 on Windows. > > One year ago I was in the situation to port one of my Modula-3 programs > from Linux to Windows in order to hand it over to a Windows user. As I > never use Windows, I have only a plain Windows installation on my machine > with almost no tools other than cm3. I was glad to be able to run cm3 > immediately and to find all libraries that I needed in binary form without > Cygwin dependencies - otherwise not only I had to install that on my > machine but I also would have to persuade the other Windows guy to install > it as well. Summarized I strongly vote for NT386 being Windows with least > dependencies on other packages. There has never been a question about this. But there are other who prefer something more POSIXish like Cygwin, which is why other targets like NT386GNU (or NT386_CYGWIN or whatever) are 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 wagner at elegosoft.com Wed Jan 23 12:39:37 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 23 Jan 2008 12:39:37 +0100 Subject: [M3devel] new problem on NT386 In-Reply-To: <4796D0BA.1E75.00D7.1@scires.com> References: <4796B970.1E75.00D7.1@scires.com> <4796D0BA.1E75.00D7.1@scires.com> Message-ID: <20080123123937.onc4m6fa4gg8ogg0@mail.elegosoft.com> Quoting Randy Coleburn : > OK, scratch what I said in my prior message about the "cd" not > working. I ran some more tests and I'm not sure anymore. > > Jay, what has changed in the way quake, cm3, and cm3.cfg interact > since v5.2.6? > > What I am seeing is that when Reactor is built using the current > cm3, the output that should be going to the web browser is instead > going to the console log. This is strange. The same exact code > compiled under 5.2.6 works correctly (output goes to browser). > > Also, there are some strange differences in the output and the > results are different. Not only are the results different, they are > wrong under the new system, while they are correct under 5.2.6. > Indeed, the build operation on the new system does not even find the > correct package. > > Reactor is written in Modula-3, but it does use some quake helper > functions. Here are the quake sources that Reactor is using for the > clean and build procedures: > > proc clean_package (pkg) is > exec ("cd", pkg, "| cm3 -verbose -clean") > end > proc build_package (pkg, options) is > exec ("cd", pkg, "| cm3 -verbose", options) > end > As you can see, I've turned on the -verbose cm3 option to make the > differences clear. I don't understand these: | is the pipe symbol even for cmd.exe, isn't it? Shouldn't these commands just read `cd pkg && cm3 -verbose ...'? && should work for /bin/sh as well as for cme.exe, IIRC. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jayk123 at hotmail.com Wed Jan 23 13:37:29 2008 From: jayk123 at hotmail.com (Jay) Date: Wed, 23 Jan 2008 12:37:29 +0000 Subject: [M3devel] new problem on NT386 In-Reply-To: <20080123123937.onc4m6fa4gg8ogg0@mail.elegosoft.com> References: <4796B970.1E75.00D7.1@scires.com> <4796D0BA.1E75.00D7.1@scires.com> <20080123123937.onc4m6fa4gg8ogg0@mail.elegosoft.com> Message-ID: Oops good point Olaf. Yes && works with cmd. If the first command succeeds, the second is run. Succeeds as in exit code is 0. I assume "pkg" contained "enough content to make it work", but if indeed it is a directory, no go. I wasn't really reading the content oops sorry. But yet Randy said it worked with 5.2.6. Randy, you reminded me of a good point though. Upgrade.py plays a new game with config files, one which I like so far, but maybe isn't so great. I don't remember if I updated upgrade.cmd to this new model. In either case, to remove variables, to remove changes, look at your cm3.cfg. Read it a bit. Is it a stub that looks for another config file to include? If so, undo that on your machine. Find the other file, it is cvsroot\m3-sys\cminstall\src\config\nt386, and copy that over \cm3\bin\cm3.cfg, and try again. In either case I'm sure this is not a big deal.... Can you make the code available to me somehow? I do need to get some real work done during the week(s) but the weekend... - Jay > Date: Wed, 23 Jan 2008 12:39:37 +0100> From: wagner at elegosoft.com> To: m3devel at elegosoft.com> Subject: Re: [M3devel] new problem on NT386> > Quoting Randy Coleburn :> > > OK, scratch what I said in my prior message about the "cd" not > > working. I ran some more tests and I'm not sure anymore.> >> > Jay, what has changed in the way quake, cm3, and cm3.cfg interact > > since v5.2.6?> >> > What I am seeing is that when Reactor is built using the current > > cm3, the output that should be going to the web browser is instead > > going to the console log. This is strange. The same exact code > > compiled under 5.2.6 works correctly (output goes to browser).> >> > Also, there are some strange differences in the output and the > > results are different. Not only are the results different, they are > > wrong under the new system, while they are correct under 5.2.6. > > Indeed, the build operation on the new system does not even find the > > correct package.> >> > Reactor is written in Modula-3, but it does use some quake helper > > functions. Here are the quake sources that Reactor is using for the > > clean and build procedures:> >> > proc clean_package (pkg) is> > exec ("cd", pkg, "| cm3 -verbose -clean")> > end> > proc build_package (pkg, options) is> > exec ("cd", pkg, "| cm3 -verbose", options)> > end> > As you can see, I've turned on the -verbose cm3 option to make the > > differences clear.> > I don't understand these: | is the pipe symbol even for cmd.exe, isn't> it?> > Shouldn't these commands just read `cd pkg && cm3 -verbose ...'?> > && should work for /bin/sh as well as for cme.exe, IIRC.> > Olaf> -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194> _________________________________________________________________ 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 Jan 23 13:48:28 2008 From: jayk123 at hotmail.com (Jay) Date: Wed, 23 Jan 2008 12:48:28 +0000 Subject: [M3devel] platform/build_dir is a big tuple? In-Reply-To: <20080123122002.6rcdyji1us4okkww@mail.elegosoft.com> References: <479605CF.1E75.00D7.1@scires.com> <20080123122002.6rcdyji1us4okkww@mail.elegosoft.com> Message-ID: Good point Olaf, thanks for refocusing us. (and here I go again...) The behavior of NT386 is not in question. I churned the underlying code (just the default config file, which "hopefully" nobody has to change at all) and it can/does now share with others, but "nobody should notice anything" that is using NT386 (famous last words..nothing under my sleeve...) NT386GNU's behavior is the question. I made it more like NT386 that some/all folks desire while still using the gcc backend, which is goodness, from a certain point of view, but not everything. Perhaps nobody wants the in between behavior, granted. However if there are people really eager for LONGINT on NT386, then "NT386MINGNU" will be it for now. That's it's critical innovation, perhaps. I was taking too long on the integrated backend changes. I still have stuff sitting around there. And a slower build, with less efficient code without the -O flag but oh well. >> (or NT386_CYGWIN or whatever) I assume that name is out of the question. But if we are still talking about this (!) and still open to such changes, then I like NT386_CYGWIN, NT386_MINGWIN, NT386_MINGNU, I386_CYGWIN, I386_MINGWIN, I386_NT_CYG, I386_NT_?, and simlar with "x86" replacing I386, or maybe I686, maybe drop the "i". I used to use a system that didn't like leading numbers on file names, only latter, but I think that's now always allowed. If we must derive from (and keep) the existing NT386 and NT386GNU names, then NT386MINGNU I like. In any case, my plan remains, for the actual "target" to be NT386. These other names are only file names and have less impact on the system. As well, you know that function over in m3cc\m3makefile and m3gdb\m3makefile? How does that compare with the GNU_PLATFORM defined in the individual config files? Seems redundant, eh? So that reduces slightly this impact. As I said..cm3.exe itself has only a few differences between NT386 and other similar, and adequate bits via "backend mode" and perhaps "os type". cm3 cares about jmpbuf size but it doesn't care about threading library, window library, c library. Maybe hopefully some day it will care about exception handling model but for now, the same across all targets. Really we're talking about 10, maybe 30 lines of diff to push this stuff much further along..depending on how much Cygwin "just works". - Jay > From: wagner at elegosoft.com >> > it as well. Summarized I strongly vote for NT386 being Windows with least> > dependencies on other packages.> > There has never been a question about this. But there are other who> prefer something more POSIXish like Cygwin, which is why other targets> like NT386GNU (or NT386_CYGWIN or whatever) are needed.> > Olaf _________________________________________________________________ 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 Wed Jan 23 13:50:13 2008 From: jayk123 at hotmail.com (Jay) Date: Wed, 23 Jan 2008 12:50:13 +0000 Subject: [M3devel] new problem on NT386 In-Reply-To: References: <4796B970.1E75.00D7.1@scires.com> <4796D0BA.1E75.00D7.1@scires.com> <20080123123937.onc4m6fa4gg8ogg0@mail.elegosoft.com> Message-ID: forgot to answer that, yes. There's good online documentation for cmd viewable from any host. :) - Jay > > I don't understand these: | is the pipe symbol even for cmd.exe, isn't> it?> > Olaf _________________________________________________________________ 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 Jan 23 16:20:47 2008 From: jayk123 at hotmail.com (Jay) Date: Wed, 23 Jan 2008 15:20:47 +0000 Subject: [M3devel] license.. Message-ID: Where must the Critical Mass notice be displayed? See for example cminstall/src/config/NT386*. Did they remove all the individual Digital notices? I'll check later.. I'm not against licensing and all, but I dislike big banners *everywhere*, in every file. One little file per directory I guess ok, still kind of obnoxious. It's not up to me obviously, it's up to the original author. We have it far from the worst, I realize. I have seen some humungous per-file banners. The banners are often the vast majority of the file... (all the more reason to smush files together :) ) - 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 rcoleburn at scires.com Wed Jan 23 18:31:16 2008 From: rcoleburn at scires.com (Randy Coleburn) Date: Wed, 23 Jan 2008 12:31:16 -0500 Subject: [M3devel] new problem on NT386 In-Reply-To: References: <4796B970.1E75.00D7.1@scires.com> <4796D0BA.1E75.00D7.1@scires.com> <20080123123937.onc4m6fa4gg8ogg0@mail.elegosoft.com> Message-ID: <47973393.1E75.00D7.1@scires.com> Jay: Reactor uses quake to invoke procedures that do the build, link, ship, edit, start browser, etc. The user can customize these quake procedures, if needed. The default procedures all cd to the package root. The package should contain a "src" folder and optionally, one or more target folders, e.g. "NT386". So, after cd to the package root, "cm3" is invoked to do the build/clean/ship type work with the package root as the "current dir". A writer is set up to capture the output of the quake calls and the output of this writer is fed back into the browser window so the user can see the progress of the compile/ship/clean/etc. As for "&&" vs. "|", I am not a quake guru, but the pipe symbol has worked in all versions of reactor on all platforms up to this point as a command separator in the built-in quake exec() function call. As for my cm3.cfg, it is the one that came from your MIN distribution that I used to get started, with one exception. There is a place early in the file where INSTALL_ROOT = "c:\\cm3" is commented out. If I run reactor with cm3.cfg this way, it gets a runtime exception "array subscript out of range" in module M3Path.m3 at line 410. So, I un-commented this line and reactor runs without the error, but alas it is having the other aforementioned problems. I have attached the cm3.cfg file that I use in the v5.2.6 tests as cm3.cfg.526 I have attached the cm3.cfg file that I use in the vd5.5.1 tests as cm3.cfg.d551 You should note that Reactor was written by Critical Mass for v4.1 and they had a deep understanding of the system. If the underlying system changes in a way that breaks some deep understanding reliance on the v4.1 architecture, reactor will most likely misbehave. At this point I don't think I am at liberty to give you the source code to look at. My agreement with the Critical Mass license holders is that I had to make certain changes before releasing the code. As for the cm3.cfg at m3-sys\cminstall\src\config\nt386, I took a look at it. It seems to include a NT386.common file. I have not tried this variant yet. If I need to try it, let me know. And, do I have to copy NT386 to cm3\bin as cm3.cfg and then also copy the NT386.common file to cm3\bin? There seems to be a lot of stuff going on under the covers that I don't understand about finding locations for things. I see code in reactor where it tries to locate certain things. It seems the cm3.exe is doing similar stuff. I always thought that the cm3.cfg that was in the INSTALL_ROOT bin folder is the one that rules. Let me know if this is not the case. Regards, Randy >>> Jay 1/23/2008 7:37 AM >>> Oops good point Olaf. Yes && works with cmd. If the first command succeeds, the second is run. Succeeds as in exit code is 0. I assume "pkg" contained "enough content to make it work", but if indeed it is a directory, no go. I wasn't really reading the content oops sorry. But yet Randy said it worked with 5.2.6. Randy, you reminded me of a good point though. Upgrade.py plays a new game with config files, one which I like so far, but maybe isn't so great. I don't remember if I updated upgrade.cmd to this new model. In either case, to remove variables, to remove changes, look at your cm3.cfg. Read it a bit. Is it a stub that looks for another config file to include? If so, undo that on your machine. Find the other file, it is cvsroot\m3-sys\cminstall\src\config\nt386, and copy that over \cm3\bin\cm3.cfg, and try again. In either case I'm sure this is not a big deal.... Can you make the code available to me somehow? I do need to get some real work done during the week(s) but the weekend... - Jay > Date: Wed, 23 Jan 2008 12:39:37 +0100 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] new problem on NT386 > > Quoting Randy Coleburn : > > > OK, scratch what I said in my prior message about the "cd" not > > working. I ran some more tests and I'm not sure anymore. > > > > Jay, what has changed in the way quake, cm3, and cm3.cfg interact > > since v5.2.6? > > > > What I am seeing is that when Reactor is built using the current > > cm3, the output that should be going to the web browser is instead > > going to the console log. This is strange. The same exact code > > compiled under 5.2.6 works correctly (output goes to browser). > > > > Also, there are some strange differences in the output and the > > results are different. Not only are the results different, they are > > wrong under the new system, while they are correct under 5.2.6. > > Indeed, the build operation on the new system does not even find the > > correct package. > > > > Reactor is written in Modula-3, but it does use some quake helper > > functions. Here are the quake sources that Reactor is using for the > > clean and build procedures: > > > > proc clean_package (pkg) is > > exec ("cd", pkg, "| cm3 -verbose -clean") > > end > > proc build_package (pkg, options) is > > exec ("cd", pkg, "| cm3 -verbose", options) > > end > > As you can see, I've turned on the -verbose cm3 option to make the > > differences clear. > > I don't understand these: | is the pipe symbol even for cmd.exe, isn't > it? > > Shouldn't these commands just read `cd pkg && cm3 -verbose ...'? > > && should work for /bin/sh as well as for cme.exe, IIRC. > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > Helping your favorite cause is as easy as instant messaging. You IM, we give. Learn more. ( 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: cm3.cfg.526 Type: application/octet-stream Size: 14465 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: cm3.cfg.d551 Type: application/octet-stream Size: 18873 bytes Desc: not available URL: From wagner at elegosoft.com Wed Jan 23 19:32:16 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 23 Jan 2008 19:32:16 +0100 Subject: [M3devel] new problem on NT386 In-Reply-To: <479734AB.1E75.00D7.1@scires.com> References: <4796B970.1E75.00D7.1@scires.com> <4796D0BA.1E75.00D7.1@scires.com> <20080123123937.onc4m6fa4gg8ogg0@mail.elegosoft.com> <479734AB.1E75.00D7.1@scires.com> Message-ID: <20080123193216.4hun5uus8hwksw88@mail.elegosoft.com> Quoting Randy Coleburn : > Olaf: > > The pipe symbol is used by reactor in the quake exec() calls. I did > not program this; it was done by CMass Inc. My experience has been that > the pipe worked as a command separator in the quake exec() call, even on > the Unix systems. I agree it looks strange, but then, I'm not a quake > expert. Is this documented anywhere? The online doc says exec(...) The arguments are catenated and passed to the operating system to be executed as a child process. The command may start `-' or `@'. These are stripped before the command is passed to the command interpreter. A prefix of `@' indicates that the default action of printing the command to the standard output stream before execution should be overridden. A prefix character of `-' overrides quake's default action of aborting if it detects an error return code after executing the command. I've never seen it, and it seems a really strange choice to me, since it would make it impossible to use pipes within a command. OK, I've found it, but didn't know it ever existed ;-) Here is the diff: % cvs diff -u -r 1.3 -r 1.4 m3-sys/m3quake/src/QMachine.m3 Index: m3-sys/m3quake/src/QMachine.m3 =================================================================== RCS file: /usr/cvs/cm3/m3-sys/m3quake/src/QMachine.m3,v retrieving revision 1.3 retrieving revision 1.4 diff -u -u -r1.3 -r1.4 --- m3-sys/m3quake/src/QMachine.m3 25 Jun 2003 14:36:32 -0000 1.3 +++ m3-sys/m3quake/src/QMachine.m3 16 Oct 2005 13:43:32 -0000 1.4 @@ -1354,7 +1354,6 @@ quake_in : Pipe.T; process_out : Pipe.T; wr : Wr.T := CurWr (t); - wd : TEXT; inbuf : ARRAY [0..255] OF CHAR; BEGIN info.command := ""; @@ -1396,8 +1395,6 @@ Err (t, "write failed" & OSErr (ec)); END; - wd := ExtractInitialDir (info.command); - args [0] := t.sh_option; args [1] := info.command; n_shell_args := 2; @@ -1410,7 +1407,7 @@ (* fire up the subprocess *) handle := Process.Create (t.shell, SUBARRAY (args, 0, n_shell_args), stdin := stdin, stdout := process_out, - stderr := process_out, wd := wd); + stderr := process_out); (* close our copy of the writing end of the output pipe *) process_out.close (); LOOP (* send anything coming through the pipe to the quake output file *) @@ -1439,38 +1436,6 @@ RETURN info; END ExecCommand; -PROCEDURE ExtractInitialDir (VAR cmd: TEXT): TEXT = - (* search for "cd |" or "cd ;" prefix in "cmd". - If it's found, return "" and remove the prefix from "cmd". - Otherwise, return "NIL". *) - VAR - len := Text.Length (cmd); - buf : ARRAY [0..99] OF CHAR; - start, stop: INTEGER; - dir: TEXT; - BEGIN - IF (len < 5) THEN RETURN NIL; END; - Text.SetChars (buf, cmd); - start := 0; - WHILE (start < len) AND (buf[start] = ' ') DO INC (start); END; - IF (start+4 >= len) THEN RETURN NIL; END; - IF (buf[start] # 'c') THEN RETURN NIL; END; - IF (buf[start+1] # 'd') THEN RETURN NIL; END; - IF (buf[start+2] # ' ') THEN RETURN NIL; END; - INC (start, 3); - WHILE (start < len) AND (buf[start] = ' ') DO INC (start); END; - stop := start; - WHILE (stop < len) AND (buf[stop] # ' ') - AND (buf[stop] # '|') AND (buf[stop] # ';') DO INC (stop); END; - IF (stop <= start) THEN RETURN NIL; END; - dir := Text.FromChars (SUBARRAY (buf, start, stop - start)); - WHILE (stop < len) AND (buf[stop] = ' ') DO INC (stop); END; - IF (stop >= len) THEN RETURN NIL; END; - IF (buf[stop] # '|') AND (buf[stop] # ';') THEN RETURN NIL; END; - cmd := Text.Sub (cmd, stop+1); - RETURN dir; - END ExtractInitialDir; - PROCEDURE KillProcess (handle: Process.T) = BEGIN IF (handle # NIL) THEN Obviously it has been remove by rillig (Robert Illig?): revision 1.4 date: 2005-10-16 13:43:32 +0000; author: rillig; state: Exp; lines: +1 -36; Removed the superfluous and error prone ExtractInitialDir procedure, which had tried to parse the shell command, and if it starts with "cd ", changed to that directory itself. So it only looked for cd dir | and then changed the directory accordingly, but it really was an undocumented hack and is not needed. I'd suggest to just use 'cd dir &&' instead. If that doesn't work, please let me know. A grep through the sources for 'cd .*\|' should reveal all occurences. If you need more enhanced execution functions, I can also contribute a module with much better abstractions for running commands. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Jan 23 20:55:21 2008 From: rcoleburn at scires.com (Randy Coleburn) Date: Wed, 23 Jan 2008 14:55:21 -0500 Subject: [M3devel] new problem on NT386 In-Reply-To: <20080123193216.4hun5uus8hwksw88@mail.elegosoft.com> References: <4796B970.1E75.00D7.1@scires.com> <4796D0BA.1E75.00D7.1@scires.com> <20080123123937.onc4m6fa4gg8ogg0@mail.elegosoft.com> <479734AB.1E75.00D7.1@scires.com> <20080123193216.4hun5uus8hwksw88@mail.elegosoft.com> Message-ID: <47975558.1E75.00D7.1@scires.com> Olaf: THANKS! It is obvious that these changes to QMachine are responsible for the problems. It would have taken me forever to find this. Thanks so much! I changed the quake procedures to use "&&" instead of "|" and the build/ship routines seem to work again. Indeed, I even went back and put the comment back in Jay's cm3.cfg and it still works without crashing in M3Path. This is very good! Now, I am not real good at parsing thru these text diff files, but am I seeing there was also a change to QMachine that involves how the output is being redirected? What I am observing in reactor, is that the build/ship/clean/etc output is not being shown in the browser window. Since these functions are being called via a quake procedure, if the QMachine has been altered somehow not to allow this output to be redirected, then reactor is going to have a real problem. The output of these quake routines is showing up in the console log window instead of being redirected back to the browser as it was in 4.1 and 5.2.6. Regards, Randy >>> Olaf Wagner 1/23/2008 1:32 PM >>> Quoting Randy Coleburn : > Olaf: > > The pipe symbol is used by reactor in the quake exec() calls. I did > not program this; it was done by CMass Inc. My experience has been that > the pipe worked as a command separator in the quake exec() call, even on > the Unix systems. I agree it looks strange, but then, I'm not a quake > expert. Is this documented anywhere? The online doc says exec(...) The arguments are catenated and passed to the operating system to be executed as a child process. The command may start `-' or `@'. These are stripped before the command is passed to the command interpreter. A prefix of `@' indicates that the default action of printing the command to the standard output stream before execution should be overridden. A prefix character of `-' overrides quake's default action of aborting if it detects an error return code after executing the command. I've never seen it, and it seems a really strange choice to me, since it would make it impossible to use pipes within a command. OK, I've found it, but didn't know it ever existed ;-) Here is the diff: % cvs diff -u -r 1.3 -r 1.4 m3-sys/m3quake/src/QMachine.m3 Index: m3-sys/m3quake/src/QMachine.m3 =================================================================== RCS file: /usr/cvs/cm3/m3-sys/m3quake/src/QMachine.m3,v retrieving revision 1.3 retrieving revision 1.4 diff -u -u -r1.3 -r1.4 --- m3-sys/m3quake/src/QMachine.m3 25 Jun 2003 14:36:32 -0000 1.3 +++ m3-sys/m3quake/src/QMachine.m3 16 Oct 2005 13:43:32 -0000 1.4 @@ -1354,7 +1354,6 @@ quake_in : Pipe.T; process_out : Pipe.T; wr : Wr.T := CurWr (t); - wd : TEXT; inbuf : ARRAY [0..255] OF CHAR; BEGIN info.command := ""; @@ -1396,8 +1395,6 @@ Err (t, "write failed" & OSErr (ec)); END; - wd := ExtractInitialDir (info.command); - args [0] := t.sh_option; args [1] := info.command; n_shell_args := 2; @@ -1410,7 +1407,7 @@ (* fire up the subprocess *) handle := Process.Create (t.shell, SUBARRAY (args, 0, n_shell_args), stdin := stdin, stdout := process_out, - stderr := process_out, wd := wd); + stderr := process_out); (* close our copy of the writing end of the output pipe *) process_out.close (); LOOP (* send anything coming through the pipe to the quake output file *) @@ -1439,38 +1436,6 @@ RETURN info; END ExecCommand; -PROCEDURE ExtractInitialDir (VAR cmd: TEXT): TEXT = - (* search for "cd |" or "cd ;" prefix in "cmd". - If it's found, return "" and remove the prefix from "cmd". - Otherwise, return "NIL". *) - VAR - len := Text.Length (cmd); - buf : ARRAY [0..99] OF CHAR; - start, stop: INTEGER; - dir: TEXT; - BEGIN - IF (len < 5) THEN RETURN NIL; END; - Text.SetChars (buf, cmd); - start := 0; - WHILE (start < len) AND (buf[start] = ' ') DO INC (start); END; - IF (start+4 >= len) THEN RETURN NIL; END; - IF (buf[start] # 'c') THEN RETURN NIL; END; - IF (buf[start+1] # 'd') THEN RETURN NIL; END; - IF (buf[start+2] # ' ') THEN RETURN NIL; END; - INC (start, 3); - WHILE (start < len) AND (buf[start] = ' ') DO INC (start); END; - stop := start; - WHILE (stop < len) AND (buf[stop] # ' ') - AND (buf[stop] # '|') AND (buf[stop] # ';') DO INC (stop); END; - IF (stop <= start) THEN RETURN NIL; END; - dir := Text.FromChars (SUBARRAY (buf, start, stop - start)); - WHILE (stop < len) AND (buf[stop] = ' ') DO INC (stop); END; - IF (stop >= len) THEN RETURN NIL; END; - IF (buf[stop] # '|') AND (buf[stop] # ';') THEN RETURN NIL; END; - cmd := Text.Sub (cmd, stop+1); - RETURN dir; - END ExtractInitialDir; - PROCEDURE KillProcess (handle: Process.T) = BEGIN IF (handle # NIL) THEN Obviously it has been remove by rillig (Robert Illig?): revision 1.4 date: 2005-10-16 13:43:32 +0000; author: rillig; state: Exp; lines: +1 -36; Removed the superfluous and error prone ExtractInitialDir procedure, which had tried to parse the shell command, and if it starts with "cd ", changed to that directory itself. So it only looked for cd dir | and then changed the directory accordingly, but it really was an undocumented hack and is not needed. I'd suggest to just use 'cd dir &&' instead. If that doesn't work, please let me know. A grep through the sources for 'cd .*\|' should reveal all occurences. If you need more enhanced execution functions, I can also contribute a module with much better abstractions for running commands. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com ( http://www.elegosoft.com/ ) | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Wed Jan 23 21:38:35 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 23 Jan 2008 15:38:35 -0500 Subject: [M3devel] platform/build_dir is a big tuple? In-Reply-To: References: <479605CF.1E75.00D7.1@scires.com> Message-ID: <9402FB12-D4AF-458A-93B8-3A6973D88CFE@cs.purdue.edu> On Jan 23, 2008, at 2:49 AM, Jay wrote: > > If anyone wanted user vtlaram or fiber, this could be > extended. > > It probably always should have been fibers instead of setjmp/ > longjmp where fibers are available... > > Oh, sorry, Modula-3 has never to my knowledge used user/vtalarm > threads. ThreadPosix uses user/vtalarm threads. Swicthing is done using setjmp/longjmp or setcontext/getcontext depending on platform. ON modern POSIX platforms it should always use the latter. > > > If anyone does want to take over their own scheduling and have an > N:M model, fibers are perhaps the way to go, unless you need Win9x. > Fibers take care of creating a stack and swapping register context, > whereas setjmp/longjmp only swap register context and I suspect > Modula-3 uses them in a non-conformant but generally-compatible > way. I haven't looked into this yet. For exceptions, ok. For thread > switching, probably not. > But I'd have to look at how it's implemented.. > > user mode threads, fibers..are problematic. For example Win32 > critical sections can be taken recursively, on the same thread. > Fibers can move around between threads and therefore cannot take > them recursively. > > All in all, as said below, I'm inclined to omit support for user > mode threads on Windows. > I ASSUME the Cygwin pthreads are a thin wrapper over Windows, > except...except there is the condition variables...not sure they > can be layered over thinly... As I said, this is one bit I am > uncertan of. Maybe just always use native Win32 threads. > It would be a perhaps interesting curiosity to see if cygwin > binaries tend to only depend on cygwin .dlls and not win32 .dlls, > as a "proof" of the "completeness" of the layer/wrapping. (though > as to the quality, see below.) Of course, cygwin code can still use > win32..your m3makefile might actually check target==nt386 to know > "the truth". But I doubt anyone would use this flexibility. > > - Jay > > From: jayk123 at hotmail.com > To: lemming at henning-thielemann.de; rcoleburn at scires.com > CC: m3devel at elegosoft.com > Subject: RE: [M3devel] platform/build_dir is a big tuple? > Date: Wed, 23 Jan 2008 07:37:28 +0000 > > Let me cut to the chase, again: > > Everyone will probably be satisfied. > For a very small "everyone". :) > > The underlying implementation shall be "heavily" parameterized. > There shall be three visible pre packaged configurations. > Power users, and clever and crazy people can experiment beyond > those three. > The EXACT three configurations is SLIGHTLY up in the air, but is > likely to be: > > NT386 > same as today, integrated backend, Win32 GUI, msvc*.dll, native > win32 kernel threads, native backslashy paths (and perhaps > increased compat with forward slashes, some of that is already in, > m3core, but not yet cm3), Visual C++ compiler and linker. > > NT386MINGNU > same as today's (recent) NT386GNU, but with Trestle-on-Win32 also > working > external backend, gcc compiler and linker, but otherwise same as > NT386 > One small wrinkle here is there is no m3gdb, but you can use the > m3gdb from the next one, or Cygwin's gdb. > > NT386GNU > As GNU as possible. pthreads (uncertain), X Windows (CygwinX), > Cygwin C library, stupid looking paths that start /cygdrive, wierdo > symlinks that don't interoperate well with the rest of the system > (attempting to run cc.exe crashes ntvdm.exe, for example), "link" > makes file system links (or at least strange files) instead of > linking programs, a slow and perhaps fragile copy-immediately > implementation of fork, problems running one type of program from > another because you don't know which command line parameters and > which environment variables represent paths or lists of paths and > therefore how to translate them, etc. > > The underlying parameters, which are largely independent and which > you can change individually, but which you will actually just > ignore usually, shall be: > > modula-3 backend > integrated 0 > cm3cg 1 > This might be replaced by the existing 0-3 variable. > > C compiler > Visual C++ cl 0 > gcc 1 > In future this could be redefined as decimal digit or a > character to accomodate other choices. > > linker > Visual C++ link 0 > gcc 1 > In future this could be redefined as decimal digit or a > character to accomodate other choices. > > Threading library > Native Win32 kernel threads 0 > Cygwin pthreads which are probably layered on native Win32 > kernel threads 1 > This is the one area where people have suggested using native > Win32 functionality instead of Cygwin > vtalaram user threads probably not available > fiber user threads probably not available > This would have been better than vtalaram, but not Win9x > compatible > If anyone wanted user vtlaram or fiber, this could be > extended. It probably always should have been fibers instead of > setjmp/longjmp where fibers are available... > > Window library > Native Win32 gui 0 (hopefully with bugs to be worked out) > X Windows via CygwinX 1 (hopefully the binaries are X server > agnostic, and even work against a remote Unix machine?) > > C library > native msvcr* through Visual C++ or MinGWin 0 > Cygwin and its path oddities 1 > > The current notion of "OSTYPE" becomes much less useful here, as it > previously embodied multiple factors. > It wasn't all that useful anyway, imho, but as a way to reduce the > matrix of targets down to two, the same two in multiple places. > Now, in a few places, you check a more specific variable. > Theoretically, I don't have to change cm3 here, just the config > file and some m3makefiles. Because, tricky tricky, the main thing > cm3 cares about is the backend "mode", and that does match up above > with the 0/1. There are actually 4 modes and I should maybe hoist > that up to be the variable, very maybe. A few m3makefiles will have > to change, in small ways. > > Therefore, NT386 is all 0s, NT386GNU shall be all 1s, except > maybe threading, and NT386MINGNU shall be a mix -- backend, C > compiler, linker 1, the rest 0. Besides that, what I haven't in my > head yet, is that individual m3makefiles should be able to ask for > one compiler or the other. The base system won't do that, but user > systems could, if they have some code that depends on one compiler > or the other and they are going to link it together. For this > purpose, for exposing these features to users, possibly values > other than "0" and "1" are needed. > > If the configuration is one of these three combinations, build_dir > is translated as shown. > Otherwise, it is "NT386-" plus the unreadable string of 0s and 1s. > > This is essentially already commited. NT386 works this way. > NT386MINGNU works this, but is for now called NT386GNU, and doesn't > have any Trestle yet. The new/old Cygwin NT386GNU isn't active yet, > but easily should be. > > There are three config files, NT386, NT386MINGNU, NT386GNU, they > are all just a few lines and then include NT386.common. > > Oh, one more thing I haven't worked out is how the user asks for > one target or another. > It is probably via the environment variable CM3_TARGET, though in > reality, "TARGET" for all of these shall be NT386. > > Any questions? > Don't ask me when Cygwin NT386GNU will be active or when the names > will flip. I will try it soon. > > This is essentiallyalready in the tree, with a little bit of > "temporary, for compat" sprinkled in to avoid renaming NT386GNU/ > MINGNU just yet, and the Cygwinish stuff not active, no X Windows > on NT386 yet..groundwork is laid, I think I've stopped thinking > through the indecisiveness, I just keep hearing the two extreme > sides, the Windows users who want Windows (do you even care about > the gcc backend? It's slow. It generates inefficient code. It > supports Longint) and a few Unix users who might reluctantly use > Windows a little more if their backend slowed down and their > libraries changed... > > Personally my main goal here is to not feel guilty about not > finishing the LONGINT support yet in the integrated backend. > I'd still like to finish that, but it was taking embarassingly long. > > I'd also like an uber-cross build environment, where I can build > anything from anything. Getting cm3cg working was part of that. I'm > not sure I have the patience to build gcc and ld/binutils that many > times though. > > - Jay > > > > > Date: Wed, 23 Jan 2008 08:06:20 +0100 > > From: lemming at henning-thielemann.de > > Subject: Re: [M3devel] platform/build_dir is a big tuple? > > To: rcoleburn at scires.com > > CC: m3devel at elegosoft.com; jayk123 at hotmail.com > > > > > > On Tue, 22 Jan 2008, Randy Coleburn wrote: > > > > > Jay: > > > > > > For my part on Windows, I am happy to stay with the underlying > OS, the > > > native windows threading, the integrated backend, and use the free > > > Microsoft Visual Studio tools. I don't really want to have to > > > install/use cygwin or any of the other variants. When I see > target = > > > NT386, this list is what I am expecting. For the cm3 newbie > coming from > > > a Microsoft Windows environment, I think this list would be the > most > > > appealing and pose the least barrier to getting starting. Yes, > I still > > > will work on the installer program once I'm satisfied that I > have a good > > > working cm3 on Windows. > > > > One year ago I was in the situation to port one of my Modula-3 > programs > > from Linux to Windows in order to hand it over to a Windows user. > As I > > never use Windows, I have only a plain Windows installation on my > machine > > with almost no tools other than cm3. I was glad to be able to run > cm3 > > immediately and to find all libraries that I needed in binary > form without > > Cygwin dependencies - otherwise not only I had to install that on my > > machine but I also would have to persuade the other Windows guy > to install > > it as well. Summarized I strongly vote for NT386 being Windows > with least > > dependencies on other packages. > > > 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 wagner at elegosoft.com Wed Jan 23 22:10:01 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 23 Jan 2008 22:10:01 +0100 Subject: [M3devel] new problem on NT386 In-Reply-To: <47975558.1E75.00D7.1@scires.com> References: <4796B970.1E75.00D7.1@scires.com> <4796D0BA.1E75.00D7.1@scires.com> <20080123123937.onc4m6fa4gg8ogg0@mail.elegosoft.com> <479734AB.1E75.00D7.1@scires.com> <20080123193216.4hun5uus8hwksw88@mail.elegosoft.com> <47975558.1E75.00D7.1@scires.com> Message-ID: <20080123221001.8pbvhkjdc8408w80@mail.elegosoft.com> Quoting Randy Coleburn : > Olaf: > > THANKS! It is obvious that these changes to QMachine are responsible > for the problems. It would have taken me forever to find this. Thanks > so much! > > I changed the quake procedures to use "&&" instead of "|" and the > build/ship routines seem to work again. Indeed, I even went back and > put the comment back in Jay's cm3.cfg and it still works without > crashing in M3Path. This is very good! > > Now, I am not real good at parsing thru these text diff files, but am I > seeing there was also a change to QMachine that involves how the output > is being redirected? > > What I am observing in reactor, is that the build/ship/clean/etc output > is not being shown in the browser window. Since these functions are > being called via a quake procedure, if the QMachine has been altered > somehow not to allow this output to be redirected, then reactor is going > to have a real problem. The output of these quake routines is showing > up in the console log window instead of being redirected back to the > browser as it was in 4.1 and 5.2.6. Randy, I've added compatibilit procedures that should show the old (queer) behaviour: cm3_exec and try_cm3_exec. The semantics were changed in this commit: revision 1.5 date: 2005-10-17 21:00:36 +0000; author: rillig; state: Exp; lines: +4 -20; Don't pass the stdout and stderr from child processes through quake. This makes the quake code simpler and also allows the user to redirect the stdout and the stderr to different files. Before, the stdout and stderr had been merged by quake and then printed on stdout. I think the main goal of the quake changes was to make CM3 and PM3 compatible; but this now seems to break the old Reactor code. So try if cm3_exec instead of just exec will cure your problem. You'll have to rebuild the m3quake package of course. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Jan 23 22:37:53 2008 From: rcoleburn at scires.com (Randy Coleburn) Date: Wed, 23 Jan 2008 16:37:53 -0500 Subject: [M3devel] new problem on NT386 In-Reply-To: <20080123221001.8pbvhkjdc8408w80@mail.elegosoft.com> References: <4796B970.1E75.00D7.1@scires.com> <4796D0BA.1E75.00D7.1@scires.com> <20080123123937.onc4m6fa4gg8ogg0@mail.elegosoft.com> <479734AB.1E75.00D7.1@scires.com> <20080123193216.4hun5uus8hwksw88@mail.elegosoft.com> <47975558.1E75.00D7.1@scires.com> <20080123221001.8pbvhkjdc8408w80@mail.elegosoft.com> Message-ID: <47976D5F.1E75.00D7.1@scires.com> Olaf: I grabbed the new QMachine via cvs and rebuilt & shipped the m3quake package, then rebuilt reactor (now cm3_ide) to take advantage of it. I replaced the exec calls with cm3_exec(). At first glance, things were working better in that the output is now going back to the browser. Great! But, when I tried to compile a simple "HelloWorld" program, I ran into some errors. See attached PDF file. Does any of this make sense to you? Note that this same HelloWorld program was compiling before the QMachine change, its just that the output went to the wrong window. Regards, Randy >>> Olaf Wagner 1/23/2008 4:10 PM >>> Quoting Randy Coleburn : > Olaf: > > THANKS! It is obvious that these changes to QMachine are responsible > for the problems. It would have taken me forever to find this. Thanks > so much! > > I changed the quake procedures to use "&&" instead of "|" and the > build/ship routines seem to work again. Indeed, I even went back and > put the comment back in Jay's cm3.cfg and it still works without > crashing in M3Path. This is very good! > > Now, I am not real good at parsing thru these text diff files, but am I > seeing there was also a change to QMachine that involves how the output > is being redirected? > > What I am observing in reactor, is that the build/ship/clean/etc output > is not being shown in the browser window. Since these functions are > being called via a quake procedure, if the QMachine has been altered > somehow not to allow this output to be redirected, then reactor is going > to have a real problem. The output of these quake routines is showing > up in the console log window instead of being redirected back to the > browser as it was in 4.1 and 5.2.6. Randy, I've added compatibilit procedures that should show the old (queer) behaviour: cm3_exec and try_cm3_exec. The semantics were changed in this commit: revision 1.5 date: 2005-10-17 21:00:36 +0000; author: rillig; state: Exp; lines: +4 -20; Don't pass the stdout and stderr from child processes through quake. This makes the quake code simpler and also allows the user to redirect the stdout and the stderr to different files. Before, the stdout and stderr had been merged by quake and then printed on stdout. I think the main goal of the quake changes was to make CM3 and PM3 compatible; but this now seems to break the old Reactor code. So try if cm3_exec instead of just exec will cure your problem. You'll have to rebuild the m3quake package of course. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com ( http://www.elegosoft.com/ ) | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: buildHello.pdf Type: application/pdf Size: 30627 bytes Desc: not available URL: From wagner at elegosoft.com Wed Jan 23 23:23:10 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 23 Jan 2008 23:23:10 +0100 Subject: [M3devel] new problem on NT386 In-Reply-To: <47976D5F.1E75.00D7.1@scires.com> References: <4796B970.1E75.00D7.1@scires.com> <4796D0BA.1E75.00D7.1@scires.com> <20080123123937.onc4m6fa4gg8ogg0@mail.elegosoft.com> <479734AB.1E75.00D7.1@scires.com> <20080123193216.4hun5uus8hwksw88@mail.elegosoft.com> <47975558.1E75.00D7.1@scires.com> <20080123221001.8pbvhkjdc8408w80@mail.elegosoft.com> <47976D5F.1E75.00D7.1@scires.com> Message-ID: <20080123232310.5znrlsr5ywwgc4o0@mail.elegosoft.com> Quoting Randy Coleburn : > Olaf: > > I grabbed the new QMachine via cvs and rebuilt & shipped the m3quake > package, then rebuilt reactor (now cm3_ide) to take advantage of it. I > replaced the exec calls with cm3_exec(). > > At first glance, things were working better in that the output is now > going back to the browser. Great! > > But, when I tried to compile a simple "HelloWorld" program, I ran into > some errors. See attached PDF file. Does any of this make sense to > you? > > Note that this same HelloWorld program was compiling before the > QMachine change, its just that the output went to the wrong window. It seems I've made a mistake by forgetting to initialize the std file handles. Please try again, Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Jan 24 00:05:12 2008 From: jayk123 at hotmail.com (Jay) Date: Wed, 23 Jan 2008 23:05:12 +0000 Subject: [M3devel] new problem on NT386 In-Reply-To: <20080123232310.5znrlsr5ywwgc4o0@mail.elegosoft.com> References: <4796B970.1E75.00D7.1@scires.com> <4796D0BA.1E75.00D7.1@scires.com> <20080123123937.onc4m6fa4gg8ogg0@mail.elegosoft.com> <479734AB.1E75.00D7.1@scires.com> <20080123193216.4hun5uus8hwksw88@mail.elegosoft.com> <47975558.1E75.00D7.1@scires.com> <20080123221001.8pbvhkjdc8408w80@mail.elegosoft.com> <47976D5F.1E75.00D7.1@scires.com> <20080123232310.5znrlsr5ywwgc4o0@mail.elegosoft.com> Message-ID: Catching up, just to clearly confirm: | and && have the same meaning in cmd as in sh. | is the pipe, the stdout of the left is the stdin of the right stderr probably is separate, and you should in general imho throw in "2>&1" to avoid hangs that can occur if stderr is used. && is kind of like && in C, boolean and, shortcircuiting. I was unaware of this stuff in Quake. cmd is actually documented online, can read those docs from any host, not just windows, the online docs appear similar to what you can find on a live system. Randy, I ask again, can what you have be made available to anyone to assist with any problems? It seems you have no outstanding problems, so currently moot. Btw, Microsoft nmake handles cd specially as well. Normally each nmake command is a separate process, but a few are "emulated", cd and set. And cd can cross drives, but cd /d does not, which is the opposite of cmd, where cd /d is needed to cross drives, and cd does not.. Later. - Jay > Date: Wed, 23 Jan 2008 23:23:10 +0100> From: wagner at elegosoft.com> To: rcoleburn at scires.com> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] new problem on NT386> > Quoting Randy Coleburn :> > > Olaf:> >> > I grabbed the new QMachine via cvs and rebuilt & shipped the m3quake> > package, then rebuilt reactor (now cm3_ide) to take advantage of it. I> > replaced the exec calls with cm3_exec().> >> > At first glance, things were working better in that the output is now> > going back to the browser. Great!> >> > But, when I tried to compile a simple "HelloWorld" program, I ran into> > some errors. See attached PDF file. Does any of this make sense to> > you?> >> > Note that this same HelloWorld program was compiling before the> > QMachine change, its just that the output went to the wrong window.> > It seems I've made a mistake by forgetting to initialize the std> file handles.> > Please try again,> > Olaf> -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 Thu Jan 24 00:08:20 2008 From: jayk123 at hotmail.com (Jay) Date: Wed, 23 Jan 2008 23:08:20 +0000 Subject: [M3devel] platform/build_dir is a big tuple? In-Reply-To: <9402FB12-D4AF-458A-93B8-3A6973D88CFE@cs.purdue.edu> References: <479605CF.1E75.00D7.1@scires.com> <9402FB12-D4AF-458A-93B8-3A6973D88CFE@cs.purdue.edu> Message-ID: below > From: hosking at cs.purdue.edu> Subject: Re: [M3devel] platform/build_dir is a big tuple?> > On Jan 23, 2008, at 2:49 AM, Jay wrote:> > > Oh, sorry, Modula-3 has never to my knowledge used user/vtalarm > > threads.> > ThreadPosix uses user/vtalarm threads. Swicthing is done using > setjmp/longjmp or setcontext/getcontext depending on platform. ON > modern POSIX platforms it should always use the latter. Oops, I meant on Windows! The use of setjmp/longjmp is not ANSI C conformant, right? I kind of suspect how it'd work without having looked it but I don't have quite in my head. Will look later and know better, just curious, no matter. - 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 Thu Jan 24 00:23:20 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 24 Jan 2008 00:23:20 +0100 Subject: [M3devel] Archive Upload to CM3 WWW Message-ID: <20080124002320.c3lzxz55mso8gs00@mail.elegosoft.com> All those m3-users with ssh access can now upload installation archives they have built to birch.elegosoft.com:/var/www/modula3.elegosoft.com/cm3/uploaded-archives The archives must conform to the standard naming scheme: cm3-{min,std,all,core,base,doc}-{POSIX,WIN32,WIN,WIN64}-*-*.\ {tar.gz,tar.bz,tar.bz2,tgz,tbz,zip} for example cm3-min-WIN32-NT386GNU-d5.5.1.tar.bz2 cm3-min-POSIX-LINUXLIBC6-d5.5.0.tgz You may also add a corresponding description in a file with the same name and added .html or .txt suffix. Please don't copy anything else to this directory; I trust that the service will not be misused. A new index is generated every 5 minutes. You'll find the index under Installation / Uploaded Archives on the CM3 WWW pages. The URL is http://modula3.elegosoft.com/cm3/snaps/snapshot-index.html We can extend the naming scheme if necessary; it's probably a bit limited currently. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Jan 24 01:51:33 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 23 Jan 2008 19:51:33 -0500 Subject: [M3devel] platform/build_dir is a big tuple? In-Reply-To: References: <479605CF.1E75.00D7.1@scires.com> <9402FB12-D4AF-458A-93B8-3A6973D88CFE@cs.purdue.edu> Message-ID: <66444C15-4C87-4444-AECF-A97D79CF461D@cs.purdue.edu> Yes, setjmp/longjmp hacking (changing fields to cause thread switches) breaks on some implementations (Linux) that encrypt the fields to prevent exploits. setcontext/getcontext are the modern POSIX calls that should be used for user-threading on POSIX. On Jan 23, 2008, at 6:08 PM, Jay wrote: > below > > > From: hosking at cs.purdue.edu > > Subject: Re: [M3devel] platform/build_dir is a big tuple? > > > > On Jan 23, 2008, at 2:49 AM, Jay wrote: > > > > > Oh, sorry, Modula-3 has never to my knowledge used user/vtalarm > > > threads. > > > > ThreadPosix uses user/vtalarm threads. Swicthing is done using > > setjmp/longjmp or setcontext/getcontext depending on platform. ON > > modern POSIX platforms it should always use the latter. > > Oops, I meant on Windows! > > The use of setjmp/longjmp is not ANSI C conformant, right? I kind > of suspect how it'd work without having looked it but I don't have > quite in my head. Will look later and know better, just curious, no > matter. > > > - Jay > > Shed those extra pounds with MSN and The Biggest Loser! Learn more. From neels at elego.de Thu Jan 24 14:47:17 2008 From: neels at elego.de (Neels Janosch Hofmeyr) Date: Thu, 24 Jan 2008 14:47:17 +0100 Subject: [M3devel] minimal binary d5.5.0 fails on Ubuntu 7.10 Message-ID: <479896E5.3090106@elego.de> Hello m3-support and m3devel, I tried to bootstrap cm3 on Ubuntu 7.10 using the newer d5.5.0 binaries. Upon running cd scripts ./do-cm3-core.sh buildship I got a series of errors, ending in a segmentation fault. I am now going back to the 5.4.0 minimal binary. For interest, find the error output below. Regards, Neels neels at oubantu:~/cm3-build/scripts $ ./do-cm3-core.sh buildship CM3C = /home/neels/cm3-build/scripts/pkgmap.sh -c "cm3 -build -DROOT='/home/neels/cm3-build' && cm3 -ship -DROOT='/home/neels/cm3-build' " m3gc-simple m3core libm3 patternmatching m3middle m3linker m3front m3quake m3cc cm3 m3scanner m3tools m3cgcat m3cggen m3bundle bitvector digraph parseparams realgeometry set slisp sortedtableextras table-list tempfiles === package /home/neels/cm3-build/m3-libs/m3gc-simple === +++ cm3 -build -DROOT='/home/neels/cm3-build' && cm3 -ship -DROOT='/home/neels/cm3-build' +++ --- building in LINUXLIBC6 --- new source -> compiling sysdeps.c -> archiving libm3gcdefs.a --- shipping from LINUXLIBC6 --- . => /usr/local/cm3/pkg/m3gc-simple/LINUXLIBC6 .M3EXPORTS libm3gcdefs.so.5 libm3gcdefs.a libm3gcdefs.m3x .M3WEB ../src/runtime => /usr/local/cm3/pkg/m3gc-simple/src/runtime RTVM.c ../src/runtime/LINUXLIBC6 => /usr/local/cm3/pkg/m3gc-simple/src/runtime/LINUXLIBC6 sysdeps.c . => /usr/local/cm3/lib libm3gcdefs.a ==> /home/neels/cm3-build/m3-libs/m3gc-simple done === package /home/neels/cm3-build/m3-libs/m3core === +++ cm3 -build -DROOT='/home/neels/cm3-build' && cm3 -ship -DROOT='/home/neels/cm3-build' +++ --- building in LINUXLIBC6 --- ignoring ../src/m3overrides new source -> compiling RTHooks.i3 RTHooks.i3: In function 'RTHooks_I3': RTHooks.i3:141: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling RT0.i3 RT0.i3: In function 'RT0_I3': RT0.i3:230: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling RuntimeError.i3 RuntimeError.i3: In function 'RuntimeError_I3': RuntimeError.i3:63: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling Word.i3 Word.i3: In function 'Word_I3': Word.i3:67: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling RTException.i3 RTException.i3: In function 'RTException_I3': RTException.i3:34: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling RTHooks.m3 RTHooks.m3: In function 'RTHooks_M3': RTHooks.m3:130: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling RT0.m3 RT0.m3:10: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling Compiler.i3 Compiler.i3: In function 'Compiler_I3': Compiler.i3:42: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling RuntimeError.m3 RuntimeError.m3: In function 'RuntimeError_M3': RuntimeError.m3:61: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling Compiler.m3 Compiler.m3: In function 'Compiler_M3': Compiler.m3:11: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling RTAllocator.i3 RTAllocator.i3: In function 'RTAllocator_I3': RTAllocator.i3:79: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling RTType.i3 RTType.i3: In function 'RTType_I3': RTType.i3:65: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling Uucontext.i3 Uucontext.i3: In function 'Uucontext_I3': Uucontext.i3:195: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling Utypes.i3 Utypes.i3: In function 'Utypes_I3': Utypes.i3:108: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling BasicCtypes.i3 BasicCtypes.i3: In function 'BasicCtypes_I3': BasicCtypes.i3:33: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling Ctypes.i3 Ctypes.i3: In function 'Ctypes_I3': Ctypes.i3:67: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling Usignal.i3 Usignal.i3: In function 'Usignal_I3': Usignal.i3:199: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling Csetjmp.i3 Csetjmp.i3: In function 'Csetjmp_I3': Csetjmp.i3:29: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling RTMachine.i3 RTMachine.i3: In function 'RTMachine_I3': RTMachine.i3:87: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling Upthread.i3 Upthread.i3: In function 'Upthread_I3': Upthread.i3:343: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling Utime.i3 Utime.i3: In function 'Utime_I3': Utime.i3:182: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling RTHeapDep.i3 RTHeapDep.i3: In function 'RTHeapDep_I3': RTHeapDep.i3:74: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling RTHeapRep.i3 RTHeapRep.i3: In function 'RTHeapRep_I3': RTHeapRep.i3:310: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling Thread.i3 Thread.i3: In function 'Thread_I3': Thread.i3:120: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling FloatMode.i3 FloatMode.i3: In function 'FloatMode_I3': FloatMode.i3:123: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling ThreadF.i3 ThreadF.i3: In function 'ThreadF_I3': ThreadF.i3:110: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling RTOS.i3 RTOS.i3: In function 'RTOS_I3': RTOS.i3:44: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling RTMisc.i3 RTMisc.i3: In function 'RTMisc_I3': RTMisc.i3:29: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling RTHeap.i3 RTHeap.i3: In function 'RTHeap_I3': RTHeap.i3:44: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling Cstdlib.i3 Cstdlib.i3: In function 'Cstdlib_I3': Cstdlib.i3:34: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling Cstddef.i3 Cstddef.i3: In function 'Cstddef_I3': Cstddef.i3:14: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling RTAllocCnts.i3 RTAllocCnts.i3: In function 'RTAllocCnts_I3': RTAllocCnts.i3:22: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling RTAllocator.m3 RTAllocator.m3: In function 'RTAllocator_M3': RTAllocator.m3:387: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling RTAllocStats.i3 RTAllocStats.i3: In function 'RTAllocStats_I3': RTAllocStats.i3:39: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling Convert.i3 Convert.i3: In function 'Convert_I3': Convert.i3:111: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling TextClass.i3 TextClass.i3: In function 'TextClass_I3': TextClass.i3:46: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling Text.i3 Text.i3: In function 'Text_I3': Text.i3:81: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling RTProcedureSRC.i3 RTProcedureSRC.i3: In function 'RTProcedureSRC_I3': RTProcedureSRC.i3:28: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling Fingerprint.i3 Fingerprint.i3: In function 'Fingerprint_I3': Fingerprint.i3:63: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling RTProcedure.i3 RTProcedure.i3: In function 'RTProcedure_I3': RTProcedure.i3:32: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling RTStack.i3 RTStack.i3: In function 'RTStack_I3': RTStack.i3:53: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. new source -> compiling RTAllocStats.m3 "../src/runtime/common/RTAllocStats.m3", line 46: undefined runtime symbol !! (RTHooks.AllocateTracedRef) *** *** runtime error: *** Segmentation violation - possible attempt to dereference NIL *** pc = 0x811e7ff = StartCall + 0x19 in ../src/values/Procedure.m3 *** Aborted (core dumped) *** execution of failed *** -- Neels Janosch Hofmeyr Software Developer neels at elego.de Public Key: http://binarchy.net/neels/neels.hofmeyr.public.key.asc elego Software Solutions GmbH http://www.elegosoft.com Gustav-Meyer-Allee 25, Geb?ude 12 HRB 77719 13355 Berlin, Germany Amtsgericht Charlottenburg Tel.: +49 30 23 45 86 96 Sitz der Gesellschaft: Berlin Fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Olaf Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From mika at async.caltech.edu Thu Jan 24 15:41:50 2008 From: mika at async.caltech.edu (Mika Nystrom) Date: Thu, 24 Jan 2008 06:41:50 -0800 Subject: [M3devel] minimal binary d5.5.0 fails on Ubuntu 7.10 In-Reply-To: Your message of "Thu, 24 Jan 2008 14:47:17 +0100." <479896E5.3090106@elego.de> Message-ID: <200801241441.m0OEfo13084214@camembert.async.caltech.edu> I think this is the broken cm3.cfg . Search for -g in cm3.cfg and replace it with -gstabs+ This thing bites a lot! I think it got me twice to the extent that I had to ask this mailing list. Several other times that it had me scratching my head and then thinking "oh it's that cm3.cfg thing again..." cm3.cfg in general is pretty weird. I know the compiler looks in at least two places for it. (Undocumented behavior.) Mika Neels Janosch Hofmeyr writes: >This is an OpenPGP/MIME signed message (RFC 2440 and 3156) >--------------enigBBB9AF364E0AAD943688858C >Content-Type: text/plain; charset=UTF-8; format=flowed >Content-Transfer-Encoding: quoted-printable > >Hello m3-support and m3devel, > >I tried to bootstrap cm3 on Ubuntu 7.10 using the newer d5.5.0 binaries. = > >Upon running > cd scripts > ./do-cm3-core.sh buildship > >I got a series of errors, ending in a segmentation fault. I am now going = > >back to the 5.4.0 minimal binary. For interest, find the error output bel= >ow. > >Regards, >Neels > > >neels at oubantu:~/cm3-build/scripts >$ ./do-cm3-core.sh buildship >CM3C =3D >/home/neels/cm3-build/scripts/pkgmap.sh -c "cm3 -build =20 >-DROOT=3D'/home/neels/cm3-build' && cm3 -ship=20 >-DROOT=3D'/home/neels/cm3-build' " m3gc-simple m3core libm3=20 >patternmatching m3middle m3linker m3front m3quake m3cc cm3 m3scanner=20 >m3tools m3cgcat m3cggen m3bundle bitvector digraph parseparams=20 >realgeometry set slisp sortedtableextras table-list tempfiles >=3D=3D=3D package /home/neels/cm3-build/m3-libs/m3gc-simple =3D=3D=3D > +++ cm3 -build -DROOT=3D'/home/neels/cm3-build' && cm3 -ship=20 >-DROOT=3D'/home/neels/cm3-build' +++ >--- building in LINUXLIBC6 --- > >new source -> compiling sysdeps.c > -> archiving libm3gcdefs.a >--- shipping from LINUXLIBC6 --- > >=2E =3D> /usr/local/cm3/pkg/m3gc-simple/LINUXLIBC6 > .M3EXPORTS libm3gcdefs.so.5 libm3gcdefs.a libm3gcdefs.m3x > .M3WEB =20 >=2E./src/runtime =3D> /usr/local/cm3/pkg/m3gc-simple/src/runtime > RTVM.c =20 >=2E./src/runtime/LINUXLIBC6 =3D>=20 >/usr/local/cm3/pkg/m3gc-simple/src/runtime/LINUXLIBC6 > sysdeps.c =20 >=2E =3D> /usr/local/cm3/lib > libm3gcdefs.a =20 > =3D=3D> /home/neels/cm3-build/m3-libs/m3gc-simple done > >=3D=3D=3D package /home/neels/cm3-build/m3-libs/m3core =3D=3D=3D > +++ cm3 -build -DROOT=3D'/home/neels/cm3-build' && cm3 -ship=20 >-DROOT=3D'/home/neels/cm3-build' +++ >--- building in LINUXLIBC6 --- > >ignoring ../src/m3overrides > >new source -> compiling RTHooks.i3 >RTHooks.i3: In function 'RTHooks_I3': >RTHooks.i3:141: internal compiler error: Segmentation fault >Please submit a full bug report, >with preprocessed source if appropriate. >See for instructions. >new source -> compiling RT0.i3 >RT0.i3: In function 'RT0_I3': >RT0.i3:230: internal compiler error: Segmentation fault >Please submit a full bug report, >with preprocessed source if appropriate. >See for instructions. >new source -> compiling RuntimeError.i3 >RuntimeError.i3: In function 'RuntimeError_I3': >RuntimeError.i3:63: internal compiler error: Segmentation fault >Please submit a full bug report, >with preprocessed source if appropriate. >See for instructions. >new source -> compiling Word.i3 >Word.i3: In function 'Word_I3': >Word.i3:67: internal compiler error: Segmentation fault >Please submit a full bug report, >with preprocessed source if appropriate. >See for instructions. >new source -> compiling RTException.i3 >RTException.i3: In function 'RTException_I3': >RTException.i3:34: internal compiler error: Segmentation fault >Please submit a full bug report, >with preprocessed source if appropriate. >See for instructions. >new source -> compiling RTHooks.m3 >RTHooks.m3: In function 'RTHooks_M3': >RTHooks.m3:130: internal compiler error: Segmentation fault >Please submit a full bug report, >with preprocessed source if appropriate. >See for instructions. >new source -> compiling RT0.m3 >RT0.m3:10: internal compiler error: Segmentation fault >Please submit a full bug report, >with preprocessed source if appropriate. >See for instructions. >new source -> compiling Compiler.i3 >Compiler.i3: In function 'Compiler_I3': >Compiler.i3:42: internal compiler error: Segmentation fault >Please submit a full bug report, >with preprocessed source if appropriate. >See for instructions. >new source -> compiling RuntimeError.m3 >RuntimeError.m3: In function 'RuntimeError_M3': >RuntimeError.m3:61: internal compiler error: Segmentation fault >Please submit a full bug report, >with preprocessed source if appropriate. >See for instructions. >new source -> compiling Compiler.m3 >Compiler.m3: In function 'Compiler_M3': >Compiler.m3:11: internal compiler error: Segmentation fault >Please submit a full bug report, >with preprocessed source if appropriate. >See for instructions. >new source -> compiling RTAllocator.i3 >RTAllocator.i3: In function 'RTAllocator_I3': >RTAllocator.i3:79: internal compiler error: Segmentation fault >Please submit a full bug report, >with preprocessed source if appropriate. >See for instructions. >new source -> compiling RTType.i3 >RTType.i3: In function 'RTType_I3': >RTType.i3:65: internal compiler error: Segmentation fault >Please submit a full bug report, >with preprocessed source if appropriate. >See for instructions. >new source -> compiling Uucontext.i3 >Uucontext.i3: In function 'Uucontext_I3': >Uucontext.i3:195: internal compiler error: Segmentation fault >Please submit a full bug report, >with preprocessed source if appropriate. >See for instructions. >new source -> compiling Utypes.i3 >Utypes.i3: In function 'Utypes_I3': >Utypes.i3:108: internal compiler error: Segmentation fault >Please submit a full bug report, >with preprocessed source if appropriate. >See for instructions. >new source -> compiling BasicCtypes.i3 >BasicCtypes.i3: In function 'BasicCtypes_I3': >BasicCtypes.i3:33: internal compiler error: Segmentation fault >Please submit a full bug report, >with preprocessed source if appropriate. >See for instructions. >new source -> compiling Ctypes.i3 Ctypes.i3: In function 'Ctypes_I3': >Ctypes.i3:67: internal compiler error: Segmentation fault >Please submit a full bug report, >with preprocessed source if appropriate. >See for instructions. >new source -> compiling Usignal.i3 >Usignal.i3: In function 'Usignal_I3': >Usignal.i3:199: internal compiler error: Segmentation fault >Please submit a full bug report, >with preprocessed source if appropriate. >See for instructions. >new source -> compiling Csetjmp.i3 >Csetjmp.i3: In function 'Csetjmp_I3': >Csetjmp.i3:29: internal compiler error: Segmentation fault >Please submit a full bug report, >with preprocessed source if appropriate. >See for instructions. >new source -> compiling RTMachine.i3 >RTMachine.i3: In function 'RTMachine_I3': >RTMachine.i3:87: internal compiler error: Segmentation fault >Please submit a full bug report, >with preprocessed source if appropriate. >See for instructions. >new source -> compiling Upthread.i3 >Upthread.i3: In function 'Upthread_I3': >Upthread.i3:343: internal compiler error: Segmentation fault >Please submit a full bug report, >with preprocessed source if appropriate. >See for instructions. >new source -> compiling Utime.i3 >Utime.i3: In function 'Utime_I3': >Utime.i3:182: internal compiler error: Segmentation fault >Please submit a full bug report, >with preprocessed source if appropriate. >See for instructions. >new source -> compiling RTHeapDep.i3 >RTHeapDep.i3: In function 'RTHeapDep_I3': >RTHeapDep.i3:74: internal compiler error: Segmentation fault >Please submit a full bug report, >with preprocessed source if appropriate. >See for instructions. >new source -> compiling RTHeapRep.i3 >RTHeapRep.i3: In function 'RTHeapRep_I3': >RTHeapRep.i3:310: internal compiler error: Segmentation fault >Please submit a full bug report, >with preprocessed source if appropriate. >See for instructions. >new source -> compiling Thread.i3 >Thread.i3: In function 'Thread_I3': >Thread.i3:120: internal compiler error: Segmentation fault >Please submit a full bug report, >with preprocessed source if appropriate. >See for instructions. >new source -> compiling FloatMode.i3 >FloatMode.i3: In function 'FloatMode_I3': >FloatMode.i3:123: internal compiler error: Segmentation fault >Please submit a full bug report, >with preprocessed source if appropriate. >See for instructions. >new source -> compiling ThreadF.i3 >ThreadF.i3: In function 'ThreadF_I3': >ThreadF.i3:110: internal compiler error: Segmentation fault >Please submit a full bug report, >with preprocessed source if appropriate. >See for instructions. >new source -> compiling RTOS.i3 >RTOS.i3: In function 'RTOS_I3': >RTOS.i3:44: internal compiler error: Segmentation fault >Please submit a full bug report, >with preprocessed source if appropriate. >See for instructions. >new source -> compiling RTMisc.i3 >RTMisc.i3: In function 'RTMisc_I3': >RTMisc.i3:29: internal compiler error: Segmentation fault >Please submit a full bug report, >with preprocessed source if appropriate. >See for instructions. >new source -> compiling RTHeap.i3 >RTHeap.i3: In function 'RTHeap_I3': >RTHeap.i3:44: internal compiler error: Segmentation fault >Please submit a full bug report, >with preprocessed source if appropriate. >See for instructions. >new source -> compiling Cstdlib.i3 >Cstdlib.i3: In function 'Cstdlib_I3': >Cstdlib.i3:34: internal compiler error: Segmentation fault >Please submit a full bug report, >with preprocessed source if appropriate. >See for instructions. >new source -> compiling Cstddef.i3 >Cstddef.i3: In function 'Cstddef_I3': >Cstddef.i3:14: internal compiler error: Segmentation fault >Please submit a full bug report, >with preprocessed source if appropriate. >See for instructions. >new source -> compiling RTAllocCnts.i3 >RTAllocCnts.i3: In function 'RTAllocCnts_I3': >RTAllocCnts.i3:22: internal compiler error: Segmentation fault >Please submit a full bug report, >with preprocessed source if appropriate. >See for instructions. >new source -> compiling RTAllocator.m3 >RTAllocator.m3: In function 'RTAllocator_M3': >RTAllocator.m3:387: internal compiler error: Segmentation fault >Please submit a full bug report, >with preprocessed source if appropriate. >See for instructions. >new source -> compiling RTAllocStats.i3 >RTAllocStats.i3: In function 'RTAllocStats_I3': >RTAllocStats.i3:39: internal compiler error: Segmentation fault >Please submit a full bug report, >with preprocessed source if appropriate. >See for instructions. >new source -> compiling Convert.i3 >Convert.i3: In function 'Convert_I3': >Convert.i3:111: internal compiler error: Segmentation fault >Please submit a full bug report, >with preprocessed source if appropriate. >See for instructions. >new source -> compiling TextClass.i3 >TextClass.i3: In function 'TextClass_I3': >TextClass.i3:46: internal compiler error: Segmentation fault >Please submit a full bug report, >with preprocessed source if appropriate. >See for instructions. >new source -> compiling Text.i3 >Text.i3: In function 'Text_I3': >Text.i3:81: internal compiler error: Segmentation fault >Please submit a full bug report, >with preprocessed source if appropriate. >See for instructions. >new source -> compiling RTProcedureSRC.i3 >RTProcedureSRC.i3: In function 'RTProcedureSRC_I3': >RTProcedureSRC.i3:28: internal compiler error: Segmentation fault >Please submit a full bug report, >with preprocessed source if appropriate. >See for instructions. >new source -> compiling Fingerprint.i3 >Fingerprint.i3: In function 'Fingerprint_I3': >Fingerprint.i3:63: internal compiler error: Segmentation fault >Please submit a full bug report, >with preprocessed source if appropriate. >See for instructions. >new source -> compiling RTProcedure.i3 >RTProcedure.i3: In function 'RTProcedure_I3': >RTProcedure.i3:32: internal compiler error: Segmentation fault >Please submit a full bug report, >with preprocessed source if appropriate. >See for instructions. >new source -> compiling RTStack.i3 >RTStack.i3: In function 'RTStack_I3': >RTStack.i3:53: internal compiler error: Segmentation fault >Please submit a full bug report, >with preprocessed source if appropriate. >See for instructions. >new source -> compiling RTAllocStats.m3 >"../src/runtime/common/RTAllocStats.m3", line 46: undefined runtime=20 >symbol !! (RTHooks.AllocateTracedRef) > > >*** >*** runtime error: >*** Segmentation violation - possible attempt to dereference NIL >*** pc =3D 0x811e7ff =3D StartCall + 0x19 in ../src/values/Procedure.m= >3 >*** > >Aborted (core dumped) > *** execution of failed *** > > >--=20 >Neels Janosch Hofmeyr >Software Developer > >neels at elego.de >Public Key: http://binarchy.net/neels/neels.hofmeyr.public.key.asc > >elego Software Solutions GmbH http://www.elegosoft.com >Gustav-Meyer-Allee 25, Geb=C3=A4ude 12 HRB 77719 >13355 Berlin, Germany Amtsgericht Charlottenburg >Tel.: +49 30 23 45 86 96 Sitz der Gesellschaft: Berlin >Fax: +49 30 23 45 86 95 Gesch=C3=A4ftsf=C3=BChrer: Olaf W= >agner > > > >--------------enigBBB9AF364E0AAD943688858C >Content-Type: application/pgp-signature; name="signature.asc" >Content-Description: OpenPGP digital signature >Content-Disposition: attachment; filename="signature.asc" > >-----BEGIN PGP SIGNATURE----- >Version: GnuPG v1.4.6 (GNU/Linux) > >iD8DBQFHmJbkRpHEG7B8Y+ARAtjGAJ47SAvF3xSFUuQT0gd5ZF2OLbOX9wCg12+B >bD8Jx13qOgK+5OasBdztrYg= >=IPcA >-----END PGP SIGNATURE----- > >--------------enigBBB9AF364E0AAD943688858C-- From hendrik at topoi.pooq.com Thu Jan 24 15:44:36 2008 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Thu, 24 Jan 2008 09:44:36 -0500 Subject: [M3devel] license.. In-Reply-To: References: Message-ID: <20080124144436.GC18598@topoi.pooq.com> On Wed, Jan 23, 2008 at 03:20:47PM +0000, Jay wrote: > > I'm not against licensing and all, but I dislike big banners *everywhere*, in every file. > One little file per directory I guess ok, still kind of obnoxious. > It's not up to me obviously, it's up to the original author. > We have it far from the worst, I realize. I have seen some humungous per-file banners. > The banners are often the vast majority of the file... > (all the more reason to smush files together :) ) One of the things I hate about Eiffel is that every class has to be in its own file. Java is almost as bad. It doesn't formally have this restriction, but except for a few very local classes, you pretty well have to follow it anyway. I really like the way you can put multiple classes into one file in Modula 3. Now if I could only have modules within modules too, or at least multiple modules per file, I'd be happy. The way you want break a program up into files -- or don't -- depends on pragmatics, such as the tools you are comfortable with in the operating environment, and not on the way you want to express your program in your programming language. I'm in favour of a greater disconnect between syntactic struture and division into files. Huge copyright banners are an excellent example of how pragmatics affect programming. -- hendrik From wagner at elegosoft.com Thu Jan 24 16:34:03 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 24 Jan 2008 16:34:03 +0100 Subject: [M3devel] minimal binary d5.5.0 fails on Ubuntu 7.10 In-Reply-To: <200801241441.m0OEfo13084214@camembert.async.caltech.edu> References: <200801241441.m0OEfo13084214@camembert.async.caltech.edu> Message-ID: <20080124163403.d91ldw5m8s84gw88@mail.elegosoft.com> Quoting Mika Nystrom : > > I think this is the broken cm3.cfg . > > Search for -g in cm3.cfg and replace it with -gstabs+ > > This thing bites a lot! I think it got me twice to the extent that > I had to ask this mailing list. Several other times that it had > me scratching my head and then thinking "oh it's that cm3.cfg thing > again..." The problem here is that dwarf debugging format which was in wide use seems to be discontinued and now produces segmentation faults if used with gcc or at least cm3cg :-/ Perhaps it's just nor correctly supported in the CM3 gcc backend. There's another possibility for `wrong' update: it does not suffice to run do-cm3-core.sh, you probably need to perform a full upgrade with scripts/upgrade.sh. > cm3.cfg in general is pretty weird. I know the compiler looks > in at least two places for it. (Undocumented behavior.) The compiler looks o based on an environment variable ((C)M3CONFIG?) o in the current directory o in the directory where the cm3 binary resides IIRC. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From lemming at henning-thielemann.de Thu Jan 24 16:39:57 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Thu, 24 Jan 2008 16:39:57 +0100 (MET) Subject: [M3devel] license.. In-Reply-To: <20080124144436.GC18598@topoi.pooq.com> References: <20080124144436.GC18598@topoi.pooq.com> Message-ID: On Thu, 24 Jan 2008 hendrik at topoi.pooq.com wrote: > On Wed, Jan 23, 2008 at 03:20:47PM +0000, Jay wrote: > > > > I'm not against licensing and all, but I dislike big banners *everywhere*, in every file. > > One little file per directory I guess ok, still kind of obnoxious. > > It's not up to me obviously, it's up to the original author. > > We have it far from the worst, I realize. I have seen some humungous per-file banners. > > The banners are often the vast majority of the file... > > (all the more reason to smush files together :) ) > > One of the things I hate about Eiffel is that every class has to be in > its own file. > > Java is almost as bad. It doesn't formally have this restriction, but > except for a few very local classes, you pretty well have to follow it > anyway. > > I really like the way you can put multiple classes into one file in > Modula 3. But you should not do so, because qualification gives more natural names if the module name reflects the name of its main type. In anticipation of generic modules it is also a good idea to call the main type T. I found it good style, also in other programming languages, to setup one module per (important) data type. Sooner or later there are enough functions in the module to justify this separate unit. From mika at async.caltech.edu Thu Jan 24 16:58:21 2008 From: mika at async.caltech.edu (Mika Nystrom) Date: Thu, 24 Jan 2008 07:58:21 -0800 Subject: [M3devel] license.. In-Reply-To: Your message of "Thu, 24 Jan 2008 16:39:57 +0100." Message-ID: <200801241558.m0OFwLIG086411@camembert.async.caltech.edu> Henning Thielemann writes: > >On Thu, 24 Jan 2008 hendrik at topoi.pooq.com wrote: > >> On Wed, Jan 23, 2008 at 03:20:47PM +0000, Jay wrote: >> > >> > I'm not against licensing and all, but I dislike big banners *everywhere*, in every file. >> > One little file per directory I guess ok, still kind of obnoxious. >> > It's not up to me obviously, it's up to the original author. >> > We have it far from the worst, I realize. I have seen some humungous per-file banners. >> > The banners are often the vast majority of the file... >> > (all the more reason to smush files together :) ) >> >> One of the things I hate about Eiffel is that every class has to be in >> its own file. >> >> Java is almost as bad. It doesn't formally have this restriction, but >> except for a few very local classes, you pretty well have to follow it >> anyway. >> >> I really like the way you can put multiple classes into one file in >> Modula 3. > >But you should not do so, because qualification gives more natural names >if the module name reflects the name of its main type. In anticipation of >generic modules it is also a good idea to call the main type T. I found it >good style, also in other programming languages, to setup one module per >(important) data type. Sooner or later there are enough functions in the >module to justify this separate unit. It would be Really Nice to be able to instantiate more than one generic in a single file, I think.... (As it is, using lots of generics in M3 involves writing lots of Quake code.) Mika P.S. I do not believe the language specification makes any reference whatever to the concent of source "files". There is no reason you couldn't have a single file containing: INTERFACE A; TYPE T = RECORD x : SomeType END; END A. INTERFACE B; IMPORT A; TYPE T = A.T; END B. (Two modules in one file.) The stylistic matter of whether to declare more than one type in an interface is a separate issue, I think. From jayk123 at hotmail.com Thu Jan 24 17:06:46 2008 From: jayk123 at hotmail.com (Jay) Date: Thu, 24 Jan 2008 16:06:46 +0000 Subject: [M3devel] license.. In-Reply-To: References: <20080124144436.GC18598@topoi.pooq.com> Message-ID: oh boy.. I'm slightly on the fence here but tend toward the fewer files answer.The open question to me is, is programming more type based or module based? If your modules all have one primary type, then I claim it is really type based masquerading as module based. Lately in C I have: typedef struct Foo_t { .. } Foo_t; typedef struct Bar_t { .. } Bar_t; Bar_DoSomething(Bar_t* ...) { } Foo_DoSomething(Foo_t* ...) { } My code is all about types and not so much about "modules" or "facilities" or "subsystems". The types may be groupable into much, but it seems a secondary thing. I'm thinking of inventing a new programming language called Typo-3. :) - Jay > Date: Thu, 24 Jan 2008 16:39:57 +0100> From: lemming at henning-thielemann.de> To: hendrik at topoi.pooq.com> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] license..> > > On Thu, 24 Jan 2008 hendrik at topoi.pooq.com wrote:> > > On Wed, Jan 23, 2008 at 03:20:47PM +0000, Jay wrote:> > >> > > I'm not against licensing and all, but I dislike big banners *everywhere*, in every file.> > > One little file per directory I guess ok, still kind of obnoxious.> > > It's not up to me obviously, it's up to the original author.> > > We have it far from the worst, I realize. I have seen some humungous per-file banners.> > > The banners are often the vast majority of the file...> > > (all the more reason to smush files together :) )> >> > One of the things I hate about Eiffel is that every class has to be in> > its own file.> >> > Java is almost as bad. It doesn't formally have this restriction, but> > except for a few very local classes, you pretty well have to follow it> > anyway.> >> > I really like the way you can put multiple classes into one file in> > Modula 3.> > But you should not do so, because qualification gives more natural names> if the module name reflects the name of its main type. In anticipation of> generic modules it is also a good idea to call the main type T. I found it> good style, also in other programming languages, to setup one module per> (important) data type. Sooner or later there are enough functions in the> module to justify this separate unit.> _________________________________________________________________ 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 Jan 24 19:30:08 2008 From: jayk123 at hotmail.com (Jay) Date: Thu, 24 Jan 2008 18:30:08 +0000 Subject: [M3devel] minimal binary d5.5.0 fails on Ubuntu 7.10 In-Reply-To: <200801241441.m0OEfo13084214@camembert.async.caltech.edu> References: Your message of "Thu, 24 Jan 2008 14:47:17 +0100." <479896E5.3090106@elego.de> <200801241441.m0OEfo13084214@camembert.async.caltech.edu> Message-ID: I thought Dwarf, or Dwarf2 was the preferred format. Weird all around. On "NT386GNU", as I recall, -ggdb crashes, -g is equiv to -stabs+, which is a little more info than -gstabs. I have to check again to see if there are types. I assume we can't submit bug reports due to having a custom front end unless you can repro with C/C++/Ada/Java. Right I saw the probing for cm3.cfg in the code and was surprised, I only knew the place it was actually present. - Jay > To: neels at elego.de> Date: Thu, 24 Jan 2008 06:41:50 -0800> From: mika at async.caltech.edu> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] minimal binary d5.5.0 fails on Ubuntu 7.10> > > I think this is the broken cm3.cfg .> > Search for -g in cm3.cfg and replace it with -gstabs+> > This thing bites a lot! I think it got me twice to the extent that> I had to ask this mailing list. Several other times that it had> me scratching my head and then thinking "oh it's that cm3.cfg thing> again..."> > cm3.cfg in general is pretty weird. I know the compiler looks> in at least two places for it. (Undocumented behavior.)> > Mika> > Neels Janosch Hofmeyr writes:> >This is an OpenPGP/MIME signed message (RFC 2440 and 3156)> >--------------enigBBB9AF364E0AAD943688858C> >Content-Type: text/plain; charset=UTF-8; format=flowed> >Content-Transfer-Encoding: quoted-printable> >> >Hello m3-support and m3devel,> >> >I tried to bootstrap cm3 on Ubuntu 7.10 using the newer d5.5.0 binaries. => >> >Upon running> > cd scripts> > ./do-cm3-core.sh buildship> >> >I got a series of errors, ending in a segmentation fault. I am now going => >> >back to the 5.4.0 minimal binary. For interest, find the error output bel=> >ow.> >> >Regards,> >Neels> >> >> >neels at oubantu:~/cm3-build/scripts> >$ ./do-cm3-core.sh buildship> >CM3C =3D> >/home/neels/cm3-build/scripts/pkgmap.sh -c "cm3 -build =20> >-DROOT=3D'/home/neels/cm3-build' && cm3 -ship=20> >-DROOT=3D'/home/neels/cm3-build' " m3gc-simple m3core libm3=20> >patternmatching m3middle m3linker m3front m3quake m3cc cm3 m3scanner=20> >m3tools m3cgcat m3cggen m3bundle bitvector digraph parseparams=20> >realgeometry set slisp sortedtableextras table-list tempfiles> >=3D=3D=3D package /home/neels/cm3-build/m3-libs/m3gc-simple =3D=3D=3D> > +++ cm3 -build -DROOT=3D'/home/neels/cm3-build' && cm3 -ship=20> >-DROOT=3D'/home/neels/cm3-build' +++> >--- building in LINUXLIBC6 ---> >> >new source -> compiling sysdeps.c> > -> archiving libm3gcdefs.a> >--- shipping from LINUXLIBC6 ---> >> >=2E =3D> /usr/local/cm3/pkg/m3gc-simple/LINUXLIBC6> > .M3EXPORTS libm3gcdefs.so.5 libm3gcdefs.a libm3gcdefs.m3x> > .M3WEB =20> >=2E./src/runtime =3D> /usr/local/cm3/pkg/m3gc-simple/src/runtime> > RTVM.c =20> >=2E./src/runtime/LINUXLIBC6 =3D>=20> >/usr/local/cm3/pkg/m3gc-simple/src/runtime/LINUXLIBC6> > sysdeps.c =20> >=2E =3D> /usr/local/cm3/lib> > libm3gcdefs.a =20> > =3D=3D> /home/neels/cm3-build/m3-libs/m3gc-simple done> >> >=3D=3D=3D package /home/neels/cm3-build/m3-libs/m3core =3D=3D=3D> > +++ cm3 -build -DROOT=3D'/home/neels/cm3-build' && cm3 -ship=20> >-DROOT=3D'/home/neels/cm3-build' +++> >--- building in LINUXLIBC6 ---> >> >ignoring ../src/m3overrides> >> >new source -> compiling RTHooks.i3> >RTHooks.i3: In function 'RTHooks_I3':> >RTHooks.i3:141: internal compiler error: Segmentation fault> >Please submit a full bug report,> >with preprocessed source if appropriate.> >See for instructions.> >new source -> compiling RT0.i3> >RT0.i3: In function 'RT0_I3':> >RT0.i3:230: internal compiler error: Segmentation fault> >Please submit a full bug report,> >with preprocessed source if appropriate.> >See for instructions.> >new source -> compiling RuntimeError.i3> >RuntimeError.i3: In function 'RuntimeError_I3':> >RuntimeError.i3:63: internal compiler error: Segmentation fault> >Please submit a full bug report,> >with preprocessed source if appropriate.> >See for instructions.> >new source -> compiling Word.i3> >Word.i3: In function 'Word_I3':> >Word.i3:67: internal compiler error: Segmentation fault> >Please submit a full bug report,> >with preprocessed source if appropriate.> >See for instructions.> >new source -> compiling RTException.i3> >RTException.i3: In function 'RTException_I3':> >RTException.i3:34: internal compiler error: Segmentation fault> >Please submit a full bug report,> >with preprocessed source if appropriate.> >See for instructions.> >new source -> compiling RTHooks.m3> >RTHooks.m3: In function 'RTHooks_M3':> >RTHooks.m3:130: internal compiler error: Segmentation fault> >Please submit a full bug report,> >with preprocessed source if appropriate.> >See for instructions.> >new source -> compiling RT0.m3> >RT0.m3:10: internal compiler error: Segmentation fault> >Please submit a full bug report,> >with preprocessed source if appropriate.> >See for instructions.> >new source -> compiling Compiler.i3> >Compiler.i3: In function 'Compiler_I3':> >Compiler.i3:42: internal compiler error: Segmentation fault> >Please submit a full bug report,> >with preprocessed source if appropriate.> >See for instructions.> >new source -> compiling RuntimeError.m3> >RuntimeError.m3: In function 'RuntimeError_M3':> >RuntimeError.m3:61: internal compiler error: Segmentation fault> >Please submit a full bug report,> >with preprocessed source if appropriate.> >See for instructions.> >new source -> compiling Compiler.m3> >Compiler.m3: In function 'Compiler_M3':> >Compiler.m3:11: internal compiler error: Segmentation fault> >Please submit a full bug report,> >with preprocessed source if appropriate.> >See for instructions.> >new source -> compiling RTAllocator.i3> >RTAllocator.i3: In function 'RTAllocator_I3':> >RTAllocator.i3:79: internal compiler error: Segmentation fault> >Please submit a full bug report,> >with preprocessed source if appropriate.> >See for instructions.> >new source -> compiling RTType.i3> >RTType.i3: In function 'RTType_I3':> >RTType.i3:65: internal compiler error: Segmentation fault> >Please submit a full bug report,> >with preprocessed source if appropriate.> >See for instructions.> >new source -> compiling Uucontext.i3> >Uucontext.i3: In function 'Uucontext_I3':> >Uucontext.i3:195: internal compiler error: Segmentation fault> >Please submit a full bug report,> >with preprocessed source if appropriate.> >See for instructions.> >new source -> compiling Utypes.i3> >Utypes.i3: In function 'Utypes_I3':> >Utypes.i3:108: internal compiler error: Segmentation fault> >Please submit a full bug report,> >with preprocessed source if appropriate.> >See for instructions.> >new source -> compiling BasicCtypes.i3> >BasicCtypes.i3: In function 'BasicCtypes_I3':> >BasicCtypes.i3:33: internal compiler error: Segmentation fault> >Please submit a full bug report,> >with preprocessed source if appropriate.> >See for instructions.> >new source -> compiling Ctypes.i3> Ctypes.i3: In function 'Ctypes_I3':> >Ctypes.i3:67: internal compiler error: Segmentation fault> >Please submit a full bug report,> >with preprocessed source if appropriate.> >See for instructions.> >new source -> compiling Usignal.i3> >Usignal.i3: In function 'Usignal_I3':> >Usignal.i3:199: internal compiler error: Segmentation fault> >Please submit a full bug report,> >with preprocessed source if appropriate.> >See for instructions.> >new source -> compiling Csetjmp.i3> >Csetjmp.i3: In function 'Csetjmp_I3':> >Csetjmp.i3:29: internal compiler error: Segmentation fault> >Please submit a full bug report,> >with preprocessed source if appropriate.> >See for instructions.> >new source -> compiling RTMachine.i3> >RTMachine.i3: In function 'RTMachine_I3':> >RTMachine.i3:87: internal compiler error: Segmentation fault> >Please submit a full bug report,> >with preprocessed source if appropriate.> >See for instructions.> >new source -> compiling Upthread.i3> >Upthread.i3: In function 'Upthread_I3':> >Upthread.i3:343: internal compiler error: Segmentation fault> >Please submit a full bug report,> >with preprocessed source if appropriate.> >See for instructions.> >new source -> compiling Utime.i3> >Utime.i3: In function 'Utime_I3':> >Utime.i3:182: internal compiler error: Segmentation fault> >Please submit a full bug report,> >with preprocessed source if appropriate.> >See for instructions.> >new source -> compiling RTHeapDep.i3> >RTHeapDep.i3: In function 'RTHeapDep_I3':> >RTHeapDep.i3:74: internal compiler error: Segmentation fault> >Please submit a full bug report,> >with preprocessed source if appropriate.> >See for instructions.> >new source -> compiling RTHeapRep.i3> >RTHeapRep.i3: In function 'RTHeapRep_I3':> >RTHeapRep.i3:310: internal compiler error: Segmentation fault> >Please submit a full bug report,> >with preprocessed source if appropriate.> >See for instructions.> >new source -> compiling Thread.i3> >Thread.i3: In function 'Thread_I3':> >Thread.i3:120: internal compiler error: Segmentation fault> >Please submit a full bug report,> >with preprocessed source if appropriate.> >See for instructions.> >new source -> compiling FloatMode.i3> >FloatMode.i3: In function 'FloatMode_I3':> >FloatMode.i3:123: internal compiler error: Segmentation fault> >Please submit a full bug report,> >with preprocessed source if appropriate.> >See for instructions.> >new source -> compiling ThreadF.i3> >ThreadF.i3: In function 'ThreadF_I3':> >ThreadF.i3:110: internal compiler error: Segmentation fault> >Please submit a full bug report,> >with preprocessed source if appropriate.> >See for instructions.> >new source -> compiling RTOS.i3> >RTOS.i3: In function 'RTOS_I3':> >RTOS.i3:44: internal compiler error: Segmentation fault> >Please submit a full bug report,> >with preprocessed source if appropriate.> >See for instructions.> >new source -> compiling RTMisc.i3> >RTMisc.i3: In function 'RTMisc_I3':> >RTMisc.i3:29: internal compiler error: Segmentation fault> >Please submit a full bug report,> >with preprocessed source if appropriate.> >See for instructions.> >new source -> compiling RTHeap.i3> >RTHeap.i3: In function 'RTHeap_I3':> >RTHeap.i3:44: internal compiler error: Segmentation fault> >Please submit a full bug report,> >with preprocessed source if appropriate.> >See for instructions.> >new source -> compiling Cstdlib.i3> >Cstdlib.i3: In function 'Cstdlib_I3':> >Cstdlib.i3:34: internal compiler error: Segmentation fault> >Please submit a full bug report,> >with preprocessed source if appropriate.> >See for instructions.> >new source -> compiling Cstddef.i3> >Cstddef.i3: In function 'Cstddef_I3':> >Cstddef.i3:14: internal compiler error: Segmentation fault> >Please submit a full bug report,> >with preprocessed source if appropriate.> >See for instructions.> >new source -> compiling RTAllocCnts.i3> >RTAllocCnts.i3: In function 'RTAllocCnts_I3':> >RTAllocCnts.i3:22: internal compiler error: Segmentation fault> >Please submit a full bug report,> >with preprocessed source if appropriate.> >See for instructions.> >new source -> compiling RTAllocator.m3> >RTAllocator.m3: In function 'RTAllocator_M3':> >RTAllocator.m3:387: internal compiler error: Segmentation fault> >Please submit a full bug report,> >with preprocessed source if appropriate.> >See for instructions.> >new source -> compiling RTAllocStats.i3> >RTAllocStats.i3: In function 'RTAllocStats_I3':> >RTAllocStats.i3:39: internal compiler error: Segmentation fault> >Please submit a full bug report,> >with preprocessed source if appropriate.> >See for instructions.> >new source -> compiling Convert.i3> >Convert.i3: In function 'Convert_I3':> >Convert.i3:111: internal compiler error: Segmentation fault> >Please submit a full bug report,> >with preprocessed source if appropriate.> >See for instructions.> >new source -> compiling TextClass.i3> >TextClass.i3: In function 'TextClass_I3':> >TextClass.i3:46: internal compiler error: Segmentation fault> >Please submit a full bug report,> >with preprocessed source if appropriate.> >See for instructions.> >new source -> compiling Text.i3> >Text.i3: In function 'Text_I3':> >Text.i3:81: internal compiler error: Segmentation fault> >Please submit a full bug report,> >with preprocessed source if appropriate.> >See for instructions.> >new source -> compiling RTProcedureSRC.i3> >RTProcedureSRC.i3: In function 'RTProcedureSRC_I3':> >RTProcedureSRC.i3:28: internal compiler error: Segmentation fault> >Please submit a full bug report,> >with preprocessed source if appropriate.> >See for instructions.> >new source -> compiling Fingerprint.i3> >Fingerprint.i3: In function 'Fingerprint_I3':> >Fingerprint.i3:63: internal compiler error: Segmentation fault> >Please submit a full bug report,> >with preprocessed source if appropriate.> >See for instructions.> >new source -> compiling RTProcedure.i3> >RTProcedure.i3: In function 'RTProcedure_I3':> >RTProcedure.i3:32: internal compiler error: Segmentation fault> >Please submit a full bug report,> >with preprocessed source if appropriate.> >See for instructions.> >new source -> compiling RTStack.i3> >RTStack.i3: In function 'RTStack_I3':> >RTStack.i3:53: internal compiler error: Segmentation fault> >Please submit a full bug report,> >with preprocessed source if appropriate.> >See for instructions.> >new source -> compiling RTAllocStats.m3> >"../src/runtime/common/RTAllocStats.m3", line 46: undefined runtime=20> >symbol !! (RTHooks.AllocateTracedRef)> >> >> >***> >*** runtime error:> >*** Segmentation violation - possible attempt to dereference NIL> >*** pc =3D 0x811e7ff =3D StartCall + 0x19 in ../src/values/Procedure.m=> >3> >***> >> >Aborted (core dumped)> > *** execution of failed ***> >> >> >--=20> >Neels Janosch Hofmeyr> >Software Developer> >> >neels at elego.de> >Public Key: http://binarchy.net/neels/neels.hofmeyr.public.key.asc> >> >elego Software Solutions GmbH http://www.elegosoft.com> >Gustav-Meyer-Allee 25, Geb=C3=A4ude 12 HRB 77719> >13355 Berlin, Germany Amtsgericht Charlottenburg> >Tel.: +49 30 23 45 86 96 Sitz der Gesellschaft: Berlin> >Fax: +49 30 23 45 86 95 Gesch=C3=A4ftsf=C3=BChrer: Olaf W=> >agner> >> >> >> >--------------enigBBB9AF364E0AAD943688858C> >Content-Type: application/pgp-signature; name="signature.asc"> >Content-Description: OpenPGP digital signature> >Content-Disposition: attachment; filename="signature.asc"> >> >-----BEGIN PGP SIGNATURE-----> >Version: GnuPG v1.4.6 (GNU/Linux)> >> >iD8DBQFHmJbkRpHEG7B8Y+ARAtjGAJ47SAvF3xSFUuQT0gd5ZF2OLbOX9wCg12+B> >bD8Jx13qOgK+5OasBdztrYg=> >=IPcA> >-----END PGP SIGNATURE-----> >> >--------------enigBBB9AF364E0AAD943688858C-- _________________________________________________________________ Shed those extra pounds with MSN and The Biggest Loser! http://biggestloser.msn.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From neels at elego.de Thu Jan 24 22:09:47 2008 From: neels at elego.de (Neels Janosch Hofmeyr) Date: Thu, 24 Jan 2008 22:09:47 +0100 Subject: [M3devel] segmentation fault upon ./install-cm3-compiler.sh upgrade Message-ID: <4798FE9B.1090204@elego.de> Hi lists, I am trying to install cm3 5.4.0 on Ubuntu 7.10. I know that it worked on 7.4, and am doing the exact same steps. I have now tried it with cm3-min-...-5.4.0, just as I did last year. But now, I get this output: neels at oubantu:~/cm3-build/scripts $ ./install-cm3-compiler.sh upgrade cp /usr/local/cm3/bin/cm3 /usr/local/cm3/bin/cm3-5.4.0 cp /usr/local/cm3/bin/cm3cg /usr/local/cm3/bin/cm3cg-5.4.0 Segmentation fault (core dumped) cp /home/neels/cm3-build/m3-sys/cm3/LINUXLIBC6/cm3 /usr/local/cm3/bin/cm3- cp /home/neels/cm3-build/m3-sys/m3cc/LINUXLIBC6/cm3cg /usr/local/cm3/bin/cm3cg- cp /usr/local/cm3/bin/cm3- /usr/local/cm3/bin/cm3 cp /usr/local/cm3/bin/cm3cg- /usr/local/cm3/bin/cm3cg I have done this a second time, making sure everything is cleaned out and monitored things. From adding a `set -x' in the install-cm3-compiler.sh, it becomes obvious that `/usr/local/cm3/bin/cm3 -version' exits with a Segmentation Fault. After doing ./cminstall (the minimal binary install), cm3 -version said $ /usr/local/cm3/bin/cm3 -version Critical Mass Modula-3 version 5.4.0 last updated: 2006-10-11 configuration: /usr/local/cm3/bin/cm3.cfg After doing ./do-cm3-core.sh buildship, it still said the same. So, somewhere in install-cm3-compiler.sh, a disfunctional cm3 binary gets installed in /usr/local/cm3/bin/, after which cm3 yields only segmentation faults. After install-cm3-compiler.sh, cm3 -version says $ /usr/local/cm3/bin/cm3 -version *** *** runtime error: *** Segmentation violation - possible attempt to dereference NIL *** pc = 0x9e841069 *** Aborted (core dumped) Trying to backtrace in gdb apparently doesn't work -- I don't know how to compile debugging symbols into it. Giving up. I think now is the time to remove the statement "[cm3 is] easy-to-use [and] easy-to-install" from modula3.elegosoft.com. No piece of software I have ever encountered is as difficult to use and as impossible to install as critical mass modula3. I *am* following all the instructions! argh, Neels -- Neels Janosch Hofmeyr Software Developer neels at elego.de Public Key: http://binarchy.net/neels/neels.hofmeyr.public.key.asc elego Software Solutions GmbH http://www.elegosoft.com Gustav-Meyer-Allee 25, Geb?ude 12 HRB 77719 13355 Berlin, Germany Amtsgericht Charlottenburg Tel.: +49 30 23 45 86 96 Sitz der Gesellschaft: Berlin Fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Olaf Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From neels at elego.de Thu Jan 24 22:23:13 2008 From: neels at elego.de (Neels Janosch Hofmeyr) Date: Thu, 24 Jan 2008 22:23:13 +0100 Subject: [M3devel] minimal binary d5.5.0 fails on Ubuntu 7.10 In-Reply-To: <200801241441.m0OEfo13084214@camembert.async.caltech.edu> References: <200801241441.m0OEfo13084214@camembert.async.caltech.edu> Message-ID: <479901C1.5060208@elego.de> Well, back to trying cm3-min-POSIX-LINUXLIBC6-d5.5.0.tgz, I tried Mikas suggestion ("Search for -g in cm3.cfg and replace it with -gstabs+"), after which I get the following output: $ ./do-cm3-core.sh buildship CM3C = /home/neels/cm3-build/scripts/pkgmap.sh -c "cm3 -build -DROOT='/home/neels/cm3-build' && cm3 -ship -DROOT='/home/neels/cm3-build' " m3gc-simple m3core libm3 patternmatching m3middle m3linker m3front m3quake m3cc cm3 m3scanner m3tools m3cgcat m3cggen m3bundle bitvector digraph parseparams realgeometry set slisp sortedtableextras table-list tempfiles === package /home/neels/cm3-build/m3-libs/m3gc-simple === +++ cm3 -build -DROOT='/home/neels/cm3-build' && cm3 -ship -DROOT='/home/neels/cm3-build' +++ --- building in LINUXLIBC6 --- new source -> compiling sysdeps.c -> archiving libm3gcdefs.a --- shipping from LINUXLIBC6 --- . => /usr/local/cm3/pkg/m3gc-simple/LINUXLIBC6 .M3EXPORTS libm3gcdefs.so.5 libm3gcdefs.a libm3gcdefs.m3x .M3WEB ../src/runtime => /usr/local/cm3/pkg/m3gc-simple/src/runtime RTVM.c ../src/runtime/LINUXLIBC6 => /usr/local/cm3/pkg/m3gc-simple/src/runtime/LINUXLIBC6 sysdeps.c . => /usr/local/cm3/lib libm3gcdefs.a ==> /home/neels/cm3-build/m3-libs/m3gc-simple done === package /home/neels/cm3-build/m3-libs/m3core === +++ cm3 -build -DROOT='/home/neels/cm3-build' && cm3 -ship -DROOT='/home/neels/cm3-build' +++ --- building in LINUXLIBC6 --- ignoring ../src/m3overrides new source -> compiling RTHooks.i3 new source -> compiling RT0.i3 new source -> compiling RuntimeError.i3 new source -> compiling Word.i3 new source -> compiling RTException.i3 new source -> compiling RTHooks.m3 new source -> compiling RT0.m3 new source -> compiling Compiler.i3 new source -> compiling RuntimeError.m3 new source -> compiling Compiler.m3 new source -> compiling RTAllocator.i3 new source -> compiling RTType.i3 new source -> compiling Uucontext.i3 new source -> compiling Utypes.i3 new source -> compiling BasicCtypes.i3 new source -> compiling Ctypes.i3 new source -> compiling Usignal.i3 new source -> compiling Csetjmp.i3 new source -> compiling RTMachine.i3 new source -> compiling Upthread.i3 new source -> compiling Utime.i3 new source -> compiling RTHeapDep.i3 new source -> compiling RTHeapRep.i3 new source -> compiling Thread.i3 new source -> compiling FloatMode.i3 new source -> compiling ThreadF.i3 new source -> compiling RTOS.i3 new source -> compiling RTMisc.i3 new source -> compiling RTHeap.i3 new source -> compiling Cstdlib.i3 new source -> compiling Cstddef.i3 new source -> compiling RTAllocCnts.i3 new source -> compiling RTAllocator.m3 new source -> compiling RTAllocStats.i3 new source -> compiling Convert.i3 new source -> compiling TextClass.i3 new source -> compiling Text.i3 new source -> compiling RTProcedureSRC.i3 new source -> compiling Fingerprint.i3 new source -> compiling RTProcedure.i3 new source -> compiling RTStack.i3 new source -> compiling RTAllocStats.m3 "../src/runtime/common/RTAllocStats.m3", line 46: undefined runtime symbol !! (RTHooks.AllocateTracedRef) *** *** runtime error: *** Segmentation violation - possible attempt to dereference NIL *** pc = 0x811e7ff = StartCall + 0x19 in ../src/values/Procedure.m3 *** Aborted (core dumped) *** execution of failed *** It looks a little better, but still doesn't work. Any more ideas? Mika Nystrom wrote: > I think this is the broken cm3.cfg . > > Search for -g in cm3.cfg and replace it with -gstabs+ > > This thing bites a lot! I think it got me twice to the extent that > I had to ask this mailing list. Several other times that it had > me scratching my head and then thinking "oh it's that cm3.cfg thing > again..." > > cm3.cfg in general is pretty weird. I know the compiler looks > in at least two places for it. (Undocumented behavior.) > > Mika > > Neels Janosch Hofmeyr writes: > >> This is an OpenPGP/MIME signed message (RFC 2440 and 3156) >> --------------enigBBB9AF364E0AAD943688858C >> Content-Type: text/plain; charset=UTF-8; format=flowed >> Content-Transfer-Encoding: quoted-printable >> >> Hello m3-support and m3devel, >> >> I tried to bootstrap cm3 on Ubuntu 7.10 using the newer d5.5.0 binaries. = >> >> Upon running >> cd scripts >> ./do-cm3-core.sh buildship >> >> I got a series of errors, ending in a segmentation fault. I am now going = >> >> back to the 5.4.0 minimal binary. For interest, find the error output bel= >> ow. >> >> Regards, >> Neels >> >> >> neels at oubantu:~/cm3-build/scripts >> $ ./do-cm3-core.sh buildship >> CM3C =3D >> /home/neels/cm3-build/scripts/pkgmap.sh -c "cm3 -build =20 >> -DROOT=3D'/home/neels/cm3-build' && cm3 -ship=20 >> -DROOT=3D'/home/neels/cm3-build' " m3gc-simple m3core libm3=20 >> patternmatching m3middle m3linker m3front m3quake m3cc cm3 m3scanner=20 >> m3tools m3cgcat m3cggen m3bundle bitvector digraph parseparams=20 >> realgeometry set slisp sortedtableextras table-list tempfiles >> =3D=3D=3D package /home/neels/cm3-build/m3-libs/m3gc-simple =3D=3D=3D >> +++ cm3 -build -DROOT=3D'/home/neels/cm3-build' && cm3 -ship=20 >> -DROOT=3D'/home/neels/cm3-build' +++ >> --- building in LINUXLIBC6 --- >> >> new source -> compiling sysdeps.c >> -> archiving libm3gcdefs.a >> --- shipping from LINUXLIBC6 --- >> >> =2E =3D> /usr/local/cm3/pkg/m3gc-simple/LINUXLIBC6 >> .M3EXPORTS libm3gcdefs.so.5 libm3gcdefs.a libm3gcdefs.m3x >> .M3WEB =20 >> =2E./src/runtime =3D> /usr/local/cm3/pkg/m3gc-simple/src/runtime >> RTVM.c =20 >> =2E./src/runtime/LINUXLIBC6 =3D>=20 >> /usr/local/cm3/pkg/m3gc-simple/src/runtime/LINUXLIBC6 >> sysdeps.c =20 >> =2E =3D> /usr/local/cm3/lib >> libm3gcdefs.a =20 >> =3D=3D> /home/neels/cm3-build/m3-libs/m3gc-simple done >> >> =3D=3D=3D package /home/neels/cm3-build/m3-libs/m3core =3D=3D=3D >> +++ cm3 -build -DROOT=3D'/home/neels/cm3-build' && cm3 -ship=20 >> -DROOT=3D'/home/neels/cm3-build' +++ >> --- building in LINUXLIBC6 --- >> >> ignoring ../src/m3overrides >> >> new source -> compiling RTHooks.i3 >> RTHooks.i3: In function 'RTHooks_I3': >> RTHooks.i3:141: internal compiler error: Segmentation fault >> Please submit a full bug report, >> with preprocessed source if appropriate. >> See for instructions. >> new source -> compiling RT0.i3 >> RT0.i3: In function 'RT0_I3': >> RT0.i3:230: internal compiler error: Segmentation fault >> Please submit a full bug report, >> with preprocessed source if appropriate. >> See for instructions. >> new source -> compiling RuntimeError.i3 >> RuntimeError.i3: In function 'RuntimeError_I3': >> RuntimeError.i3:63: internal compiler error: Segmentation fault >> Please submit a full bug report, >> with preprocessed source if appropriate. >> See for instructions. >> new source -> compiling Word.i3 >> Word.i3: In function 'Word_I3': >> Word.i3:67: internal compiler error: Segmentation fault >> Please submit a full bug report, >> with preprocessed source if appropriate. >> See for instructions. >> new source -> compiling RTException.i3 >> RTException.i3: In function 'RTException_I3': >> RTException.i3:34: internal compiler error: Segmentation fault >> Please submit a full bug report, >> with preprocessed source if appropriate. >> See for instructions. >> new source -> compiling RTHooks.m3 >> RTHooks.m3: In function 'RTHooks_M3': >> RTHooks.m3:130: internal compiler error: Segmentation fault >> Please submit a full bug report, >> with preprocessed source if appropriate. >> See for instructions. >> new source -> compiling RT0.m3 >> RT0.m3:10: internal compiler error: Segmentation fault >> Please submit a full bug report, >> with preprocessed source if appropriate. >> See for instructions. >> new source -> compiling Compiler.i3 >> Compiler.i3: In function 'Compiler_I3': >> Compiler.i3:42: internal compiler error: Segmentation fault >> Please submit a full bug report, >> with preprocessed source if appropriate. >> See for instructions. >> new source -> compiling RuntimeError.m3 >> RuntimeError.m3: In function 'RuntimeError_M3': >> RuntimeError.m3:61: internal compiler error: Segmentation fault >> Please submit a full bug report, >> with preprocessed source if appropriate. >> See for instructions. >> new source -> compiling Compiler.m3 >> Compiler.m3: In function 'Compiler_M3': >> Compiler.m3:11: internal compiler error: Segmentation fault >> Please submit a full bug report, >> with preprocessed source if appropriate. >> See for instructions. >> new source -> compiling RTAllocator.i3 >> RTAllocator.i3: In function 'RTAllocator_I3': >> RTAllocator.i3:79: internal compiler error: Segmentation fault >> Please submit a full bug report, >> with preprocessed source if appropriate. >> See for instructions. >> new source -> compiling RTType.i3 >> RTType.i3: In function 'RTType_I3': >> RTType.i3:65: internal compiler error: Segmentation fault >> Please submit a full bug report, >> with preprocessed source if appropriate. >> See for instructions. >> new source -> compiling Uucontext.i3 >> Uucontext.i3: In function 'Uucontext_I3': >> Uucontext.i3:195: internal compiler error: Segmentation fault >> Please submit a full bug report, >> with preprocessed source if appropriate. >> See for instructions. >> new source -> compiling Utypes.i3 >> Utypes.i3: In function 'Utypes_I3': >> Utypes.i3:108: internal compiler error: Segmentation fault >> Please submit a full bug report, >> with preprocessed source if appropriate. >> See for instructions. >> new source -> compiling BasicCtypes.i3 >> BasicCtypes.i3: In function 'BasicCtypes_I3': >> BasicCtypes.i3:33: internal compiler error: Segmentation fault >> Please submit a full bug report, >> with preprocessed source if appropriate. >> See for instructions. >> new source -> compiling Ctypes.i3 >> > Ctypes.i3: In function 'Ctypes_I3': > >> Ctypes.i3:67: internal compiler error: Segmentation fault >> Please submit a full bug report, >> with preprocessed source if appropriate. >> See for instructions. >> new source -> compiling Usignal.i3 >> Usignal.i3: In function 'Usignal_I3': >> Usignal.i3:199: internal compiler error: Segmentation fault >> Please submit a full bug report, >> with preprocessed source if appropriate. >> See for instructions. >> new source -> compiling Csetjmp.i3 >> Csetjmp.i3: In function 'Csetjmp_I3': >> Csetjmp.i3:29: internal compiler error: Segmentation fault >> Please submit a full bug report, >> with preprocessed source if appropriate. >> See for instructions. >> new source -> compiling RTMachine.i3 >> RTMachine.i3: In function 'RTMachine_I3': >> RTMachine.i3:87: internal compiler error: Segmentation fault >> Please submit a full bug report, >> with preprocessed source if appropriate. >> See for instructions. >> new source -> compiling Upthread.i3 >> Upthread.i3: In function 'Upthread_I3': >> Upthread.i3:343: internal compiler error: Segmentation fault >> Please submit a full bug report, >> with preprocessed source if appropriate. >> See for instructions. >> new source -> compiling Utime.i3 >> Utime.i3: In function 'Utime_I3': >> Utime.i3:182: internal compiler error: Segmentation fault >> Please submit a full bug report, >> with preprocessed source if appropriate. >> See for instructions. >> new source -> compiling RTHeapDep.i3 >> RTHeapDep.i3: In function 'RTHeapDep_I3': >> RTHeapDep.i3:74: internal compiler error: Segmentation fault >> Please submit a full bug report, >> with preprocessed source if appropriate. >> See for instructions. >> new source -> compiling RTHeapRep.i3 >> RTHeapRep.i3: In function 'RTHeapRep_I3': >> RTHeapRep.i3:310: internal compiler error: Segmentation fault >> Please submit a full bug report, >> with preprocessed source if appropriate. >> See for instructions. >> new source -> compiling Thread.i3 >> Thread.i3: In function 'Thread_I3': >> Thread.i3:120: internal compiler error: Segmentation fault >> Please submit a full bug report, >> with preprocessed source if appropriate. >> See for instructions. >> new source -> compiling FloatMode.i3 >> FloatMode.i3: In function 'FloatMode_I3': >> FloatMode.i3:123: internal compiler error: Segmentation fault >> Please submit a full bug report, >> with preprocessed source if appropriate. >> See for instructions. >> new source -> compiling ThreadF.i3 >> ThreadF.i3: In function 'ThreadF_I3': >> ThreadF.i3:110: internal compiler error: Segmentation fault >> Please submit a full bug report, >> with preprocessed source if appropriate. >> See for instructions. >> new source -> compiling RTOS.i3 >> RTOS.i3: In function 'RTOS_I3': >> RTOS.i3:44: internal compiler error: Segmentation fault >> Please submit a full bug report, >> with preprocessed source if appropriate. >> See for instructions. >> new source -> compiling RTMisc.i3 >> RTMisc.i3: In function 'RTMisc_I3': >> RTMisc.i3:29: internal compiler error: Segmentation fault >> Please submit a full bug report, >> with preprocessed source if appropriate. >> See for instructions. >> new source -> compiling RTHeap.i3 >> RTHeap.i3: In function 'RTHeap_I3': >> RTHeap.i3:44: internal compiler error: Segmentation fault >> Please submit a full bug report, >> with preprocessed source if appropriate. >> See for instructions. >> new source -> compiling Cstdlib.i3 >> Cstdlib.i3: In function 'Cstdlib_I3': >> Cstdlib.i3:34: internal compiler error: Segmentation fault >> Please submit a full bug report, >> with preprocessed source if appropriate. >> See for instructions. >> new source -> compiling Cstddef.i3 >> Cstddef.i3: In function 'Cstddef_I3': >> Cstddef.i3:14: internal compiler error: Segmentation fault >> Please submit a full bug report, >> with preprocessed source if appropriate. >> See for instructions. >> new source -> compiling RTAllocCnts.i3 >> RTAllocCnts.i3: In function 'RTAllocCnts_I3': >> RTAllocCnts.i3:22: internal compiler error: Segmentation fault >> Please submit a full bug report, >> with preprocessed source if appropriate. >> See for instructions. >> new source -> compiling RTAllocator.m3 >> RTAllocator.m3: In function 'RTAllocator_M3': >> RTAllocator.m3:387: internal compiler error: Segmentation fault >> Please submit a full bug report, >> with preprocessed source if appropriate. >> See for instructions. >> new source -> compiling RTAllocStats.i3 >> RTAllocStats.i3: In function 'RTAllocStats_I3': >> RTAllocStats.i3:39: internal compiler error: Segmentation fault >> Please submit a full bug report, >> with preprocessed source if appropriate. >> See for instructions. >> new source -> compiling Convert.i3 >> Convert.i3: In function 'Convert_I3': >> Convert.i3:111: internal compiler error: Segmentation fault >> Please submit a full bug report, >> with preprocessed source if appropriate. >> See for instructions. >> new source -> compiling TextClass.i3 >> TextClass.i3: In function 'TextClass_I3': >> TextClass.i3:46: internal compiler error: Segmentation fault >> Please submit a full bug report, >> with preprocessed source if appropriate. >> See for instructions. >> new source -> compiling Text.i3 >> Text.i3: In function 'Text_I3': >> Text.i3:81: internal compiler error: Segmentation fault >> Please submit a full bug report, >> with preprocessed source if appropriate. >> See for instructions. >> new source -> compiling RTProcedureSRC.i3 >> RTProcedureSRC.i3: In function 'RTProcedureSRC_I3': >> RTProcedureSRC.i3:28: internal compiler error: Segmentation fault >> Please submit a full bug report, >> with preprocessed source if appropriate. >> See for instructions. >> new source -> compiling Fingerprint.i3 >> Fingerprint.i3: In function 'Fingerprint_I3': >> Fingerprint.i3:63: internal compiler error: Segmentation fault >> Please submit a full bug report, >> with preprocessed source if appropriate. >> See for instructions. >> new source -> compiling RTProcedure.i3 >> RTProcedure.i3: In function 'RTProcedure_I3': >> RTProcedure.i3:32: internal compiler error: Segmentation fault >> Please submit a full bug report, >> with preprocessed source if appropriate. >> See for instructions. >> new source -> compiling RTStack.i3 >> RTStack.i3: In function 'RTStack_I3': >> RTStack.i3:53: internal compiler error: Segmentation fault >> Please submit a full bug report, >> with preprocessed source if appropriate. >> See for instructions. >> new source -> compiling RTAllocStats.m3 >> "../src/runtime/common/RTAllocStats.m3", line 46: undefined runtime=20 >> symbol !! (RTHooks.AllocateTracedRef) >> >> >> *** >> *** runtime error: >> *** Segmentation violation - possible attempt to dereference NIL >> *** pc =3D 0x811e7ff =3D StartCall + 0x19 in ../src/values/Procedure.m= >> 3 >> *** >> >> Aborted (core dumped) >> *** execution of failed *** >> >> >> --=20 >> Neels Janosch Hofmeyr >> Software Developer >> >> neels at elego.de >> Public Key: http://binarchy.net/neels/neels.hofmeyr.public.key.asc >> >> elego Software Solutions GmbH http://www.elegosoft.com >> Gustav-Meyer-Allee 25, Geb=C3=A4ude 12 HRB 77719 >> 13355 Berlin, Germany Amtsgericht Charlottenburg >> Tel.: +49 30 23 45 86 96 Sitz der Gesellschaft: Berlin >> Fax: +49 30 23 45 86 95 Gesch=C3=A4ftsf=C3=BChrer: Olaf W= >> agner >> >> >> >> --------------enigBBB9AF364E0AAD943688858C >> Content-Type: application/pgp-signature; name="signature.asc" >> Content-Description: OpenPGP digital signature >> Content-Disposition: attachment; filename="signature.asc" >> >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG v1.4.6 (GNU/Linux) >> >> iD8DBQFHmJbkRpHEG7B8Y+ARAtjGAJ47SAvF3xSFUuQT0gd5ZF2OLbOX9wCg12+B >> bD8Jx13qOgK+5OasBdztrYg= >> =IPcA >> -----END PGP SIGNATURE----- >> >> --------------enigBBB9AF364E0AAD943688858C-- >> -- Neels Janosch Hofmeyr Software Developer neels at elego.de Public Key: http://binarchy.net/neels/neels.hofmeyr.public.key.asc elego Software Solutions GmbH http://www.elegosoft.com Gustav-Meyer-Allee 25, Geb?ude 12 HRB 77719 13355 Berlin, Germany Amtsgericht Charlottenburg Tel.: +49 30 23 45 86 96 Sitz der Gesellschaft: Berlin Fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Olaf Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From neels at elego.de Thu Jan 24 22:40:24 2008 From: neels at elego.de (Neels Janosch Hofmeyr) Date: Thu, 24 Jan 2008 22:40:24 +0100 Subject: [M3devel] segmentation fault upon ./install-cm3-compiler.sh upgrade In-Reply-To: <4798FE9B.1090204@elego.de> References: <4798FE9B.1090204@elego.de> Message-ID: <479905C8.7080003@elego.de> btw, I am using the "stable release" source tarballs with the 5.4.0 minimal binary as available on the download page. http://modula3.elegosoft.com/cm3/cm3-min-POSIX-LINUXLIBC6-5.4.0.tgz http://modula3.elegosoft.com/cm3/cm3-src-sys-5.4.0.tgz http://modula3.elegosoft.com/cm3/cm3-src-gnu-5.4.0.tgz http://modula3.elegosoft.com/cm3/cm3-src-std-5.4.0.tgz Neels Janosch Hofmeyr wrote: > Hi lists, > > I am trying to install cm3 5.4.0 on Ubuntu 7.10. I know that it worked > on 7.4, and am doing the exact same steps. I have now tried it with > cm3-min-...-5.4.0, just as I did last year. > > But now, I get this output: > > neels at oubantu:~/cm3-build/scripts > $ ./install-cm3-compiler.sh upgrade > cp /usr/local/cm3/bin/cm3 /usr/local/cm3/bin/cm3-5.4.0 > cp /usr/local/cm3/bin/cm3cg /usr/local/cm3/bin/cm3cg-5.4.0 > Segmentation fault (core dumped) > cp /home/neels/cm3-build/m3-sys/cm3/LINUXLIBC6/cm3 > /usr/local/cm3/bin/cm3- > cp /home/neels/cm3-build/m3-sys/m3cc/LINUXLIBC6/cm3cg > /usr/local/cm3/bin/cm3cg- > cp /usr/local/cm3/bin/cm3- /usr/local/cm3/bin/cm3 > cp /usr/local/cm3/bin/cm3cg- /usr/local/cm3/bin/cm3cg > > I have done this a second time, making sure everything is cleaned out > and monitored things. From adding a `set -x' in the > install-cm3-compiler.sh, it becomes obvious that > `/usr/local/cm3/bin/cm3 -version' exits with a Segmentation Fault. > > After doing ./cminstall (the minimal binary install), cm3 -version said > $ /usr/local/cm3/bin/cm3 -version > Critical Mass Modula-3 version 5.4.0 > last updated: 2006-10-11 > configuration: /usr/local/cm3/bin/cm3.cfg > > After doing ./do-cm3-core.sh buildship, it still said the same. > So, somewhere in install-cm3-compiler.sh, a disfunctional cm3 binary > gets installed in /usr/local/cm3/bin/, after which cm3 yields only > segmentation faults. > > After install-cm3-compiler.sh, cm3 -version says > $ /usr/local/cm3/bin/cm3 -version > > > *** > *** runtime error: > *** Segmentation violation - possible attempt to dereference NIL > *** pc = 0x9e841069 > *** > > Aborted (core dumped) > > Trying to backtrace in gdb apparently doesn't work -- I don't know how > to compile debugging symbols into it. Giving up. > > I think now is the time to remove the statement "[cm3 is] easy-to-use > [and] easy-to-install" from modula3.elegosoft.com. No piece of > software I have ever encountered is as difficult to use and as > impossible to install as critical mass modula3. I *am* following all > the instructions! > > argh, > Neels > -- Neels Janosch Hofmeyr Software Developer neels at elego.de Public Key: http://binarchy.net/neels/neels.hofmeyr.public.key.asc elego Software Solutions GmbH http://www.elegosoft.com Gustav-Meyer-Allee 25, Geb?ude 12 HRB 77719 13355 Berlin, Germany Amtsgericht Charlottenburg Tel.: +49 30 23 45 86 96 Sitz der Gesellschaft: Berlin Fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Olaf Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From jayk123 at hotmail.com Thu Jan 24 22:48:17 2008 From: jayk123 at hotmail.com (Jay) Date: Thu, 24 Jan 2008 21:48:17 +0000 Subject: [M3devel] segmentation fault upon ./install-cm3-compiler.sh upgrade In-Reply-To: <479905C8.7080003@elego.de> References: <4798FE9B.1090204@elego.de> <479905C8.7080003@elego.de> Message-ID: Personally I would try checking out the current tree. And I thought there was a 5.5.x build to start from. I'd try it. And if the existing binaries don't have symbols, and you can't build the system, find a system you can build or cross build from and get symbols in there and then debug it here. Symbols can be very valuable and I have mixed thoughts on stripped binaries. Maybe I'll get around to running this x86 Linux stuff in a virtual or physical machine sometime soon. Hopefully this gets solved before I resort to it. - Jay > Date: Thu, 24 Jan 2008 22:40:24 +0100> From: neels at elego.de> To: m3devel at elego.de; m3-support at elego.de> Subject: Re: [M3devel] segmentation fault upon ./install-cm3-compiler.sh upgrade> > btw, I am using the "stable release" source tarballs with the 5.4.0 > minimal binary as available on the download page.> http://modula3.elegosoft.com/cm3/cm3-min-POSIX-LINUXLIBC6-5.4.0.tgz> http://modula3.elegosoft.com/cm3/cm3-src-sys-5.4.0.tgz> http://modula3.elegosoft.com/cm3/cm3-src-gnu-5.4.0.tgz> http://modula3.elegosoft.com/cm3/cm3-src-std-5.4.0.tgz> > Neels Janosch Hofmeyr wrote:> > Hi lists,> >> > I am trying to install cm3 5.4.0 on Ubuntu 7.10. I know that it worked > > on 7.4, and am doing the exact same steps. I have now tried it with > > cm3-min-...-5.4.0, just as I did last year.> >> > But now, I get this output:> >> > neels at oubantu:~/cm3-build/scripts> > $ ./install-cm3-compiler.sh upgrade> > cp /usr/local/cm3/bin/cm3 /usr/local/cm3/bin/cm3-5.4.0> > cp /usr/local/cm3/bin/cm3cg /usr/local/cm3/bin/cm3cg-5.4.0> > Segmentation fault (core dumped)> > cp /home/neels/cm3-build/m3-sys/cm3/LINUXLIBC6/cm3 > > /usr/local/cm3/bin/cm3-> > cp /home/neels/cm3-build/m3-sys/m3cc/LINUXLIBC6/cm3cg > > /usr/local/cm3/bin/cm3cg-> > cp /usr/local/cm3/bin/cm3- /usr/local/cm3/bin/cm3> > cp /usr/local/cm3/bin/cm3cg- /usr/local/cm3/bin/cm3cg> >> > I have done this a second time, making sure everything is cleaned out > > and monitored things. From adding a `set -x' in the > > install-cm3-compiler.sh, it becomes obvious that > > `/usr/local/cm3/bin/cm3 -version' exits with a Segmentation Fault.> >> > After doing ./cminstall (the minimal binary install), cm3 -version said> > $ /usr/local/cm3/bin/cm3 -version> > Critical Mass Modula-3 version 5.4.0> > last updated: 2006-10-11> > configuration: /usr/local/cm3/bin/cm3.cfg> >> > After doing ./do-cm3-core.sh buildship, it still said the same.> > So, somewhere in install-cm3-compiler.sh, a disfunctional cm3 binary > > gets installed in /usr/local/cm3/bin/, after which cm3 yields only > > segmentation faults.> >> > After install-cm3-compiler.sh, cm3 -version says> > $ /usr/local/cm3/bin/cm3 -version> >> >> > ***> > *** runtime error:> > *** Segmentation violation - possible attempt to dereference NIL> > *** pc = 0x9e841069> > ***> >> > Aborted (core dumped)> >> > Trying to backtrace in gdb apparently doesn't work -- I don't know how > > to compile debugging symbols into it. Giving up.> >> > I think now is the time to remove the statement "[cm3 is] easy-to-use > > [and] easy-to-install" from modula3.elegosoft.com. No piece of > > software I have ever encountered is as difficult to use and as > > impossible to install as critical mass modula3. I *am* following all > > the instructions!> >> > argh,> > Neels> >> > -- > Neels Janosch Hofmeyr> Software Developer> > neels at elego.de> Public Key: http://binarchy.net/neels/neels.hofmeyr.public.key.asc> > elego Software Solutions GmbH http://www.elegosoft.com> Gustav-Meyer-Allee 25, Geb?ude 12 HRB 77719> 13355 Berlin, Germany Amtsgericht Charlottenburg> Tel.: +49 30 23 45 86 96 Sitz der Gesellschaft: Berlin> Fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Olaf Wagner> > _________________________________________________________________ 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 neels at elego.de Thu Jan 24 22:59:16 2008 From: neels at elego.de (Neels Janosch Hofmeyr) Date: Thu, 24 Jan 2008 22:59:16 +0100 Subject: [M3devel] segmentation fault upon ./install-cm3-compiler.sh upgrade In-Reply-To: References: <4798FE9B.1090204@elego.de> <479905C8.7080003@elego.de> Message-ID: <47990A34.7070909@elego.de> Jay wrote: > Personally I would try checking out the current tree. that's worth another try... > And I thought there was a 5.5.x build to start from. I'd try it. I have, see my previous mail: "minimal binary d5.5.0 fails on Ubuntu 7.10" > Connect and share in new ways with Windows Live. Get it now! > no thanks. -- Neels Janosch Hofmeyr Software Developer neels at elego.de Public Key: http://binarchy.net/neels/neels.hofmeyr.public.key.asc elego Software Solutions GmbH http://www.elegosoft.com Gustav-Meyer-Allee 25, Geb?ude 12 HRB 77719 13355 Berlin, Germany Amtsgericht Charlottenburg Tel.: +49 30 23 45 86 96 Sitz der Gesellschaft: Berlin Fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Olaf Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From wagner at elegosoft.com Thu Jan 24 23:03:22 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 24 Jan 2008 23:03:22 +0100 Subject: [M3devel] segmentation fault upon ./install-cm3-compiler.sh upgrade In-Reply-To: <479905C8.7080003@elego.de> References: <4798FE9B.1090204@elego.de> <479905C8.7080003@elego.de> Message-ID: <20080124230322.vl12nlls4kosoocs@mail.elegosoft.com> Quoting Neels Janosch Hofmeyr : > btw, I am using the "stable release" source tarballs with the 5.4.0 > minimal binary as available on the download page. > http://modula3.elegosoft.com/cm3/cm3-min-POSIX-LINUXLIBC6-5.4.0.tgz > http://modula3.elegosoft.com/cm3/cm3-src-sys-5.4.0.tgz > http://modula3.elegosoft.com/cm3/cm3-src-gnu-5.4.0.tgz > http://modula3.elegosoft.com/cm3/cm3-src-std-5.4.0.tgz Hi Neels, 5.4.0 is rather old now. I assume Ubuntu has made some incompatible changes to its kernel or C library interfaces that the old cm3 binary cannot cope with. What about trying one the more recent installation archives, like d.5.5.1? Once you have a working cm3 and cm3cg, compiling the rest should be no problem. Stable releases cannot necessarily be expected to run on newer operating systems when the ABI changes, as they don't adapt themselves ;-) Try this, for example: http://modula3.elegosoft.com/cm3/snaps/cm3-min-POSIX-LINUXLIBC6-d5.5.1-2008-01-24-03-35-01.tgz It should also be possible to get a backtrace of the cm3 crash within gdb. There should be debugging symbols in the distributed binaries. What does bt show? If debugging symbols are missing, we've got to fix that. Olaf > Neels Janosch Hofmeyr wrote: >> Hi lists, >> >> I am trying to install cm3 5.4.0 on Ubuntu 7.10. I know that it >> worked on 7.4, and am doing the exact same steps. I have now tried >> it with cm3-min-...-5.4.0, just as I did last year. >> >> But now, I get this output: >> >> neels at oubantu:~/cm3-build/scripts >> $ ./install-cm3-compiler.sh upgrade >> cp /usr/local/cm3/bin/cm3 /usr/local/cm3/bin/cm3-5.4.0 >> cp /usr/local/cm3/bin/cm3cg /usr/local/cm3/bin/cm3cg-5.4.0 >> Segmentation fault (core dumped) >> cp /home/neels/cm3-build/m3-sys/cm3/LINUXLIBC6/cm3 /usr/local/cm3/bin/cm3- >> cp /home/neels/cm3-build/m3-sys/m3cc/LINUXLIBC6/cm3cg >> /usr/local/cm3/bin/cm3cg- >> cp /usr/local/cm3/bin/cm3- /usr/local/cm3/bin/cm3 >> cp /usr/local/cm3/bin/cm3cg- /usr/local/cm3/bin/cm3cg >> >> I have done this a second time, making sure everything is cleaned >> out and monitored things. From adding a `set -x' in the >> install-cm3-compiler.sh, it becomes obvious that >> `/usr/local/cm3/bin/cm3 -version' exits with a Segmentation Fault. >> >> After doing ./cminstall (the minimal binary install), cm3 -version said >> $ /usr/local/cm3/bin/cm3 -version >> Critical Mass Modula-3 version 5.4.0 >> last updated: 2006-10-11 >> configuration: /usr/local/cm3/bin/cm3.cfg >> >> After doing ./do-cm3-core.sh buildship, it still said the same. >> So, somewhere in install-cm3-compiler.sh, a disfunctional cm3 >> binary gets installed in /usr/local/cm3/bin/, after which cm3 >> yields only segmentation faults. >> >> After install-cm3-compiler.sh, cm3 -version says >> $ /usr/local/cm3/bin/cm3 -version >> >> >> *** >> *** runtime error: >> *** Segmentation violation - possible attempt to dereference NIL >> *** pc = 0x9e841069 >> *** >> >> Aborted (core dumped) >> >> Trying to backtrace in gdb apparently doesn't work -- I don't know >> how to compile debugging symbols into it. Giving up. >> >> I think now is the time to remove the statement "[cm3 is] >> easy-to-use [and] easy-to-install" from modula3.elegosoft.com. No >> piece of software I have ever encountered is as difficult to use >> and as impossible to install as critical mass modula3. I *am* >> following all the instructions! >> >> argh, >> Neels >> > > -- > Neels Janosch Hofmeyr > Software Developer > > neels at elego.de > Public Key: http://binarchy.net/neels/neels.hofmeyr.public.key.asc > > elego Software Solutions GmbH http://www.elegosoft.com > Gustav-Meyer-Allee 25, Geb?ude 12 HRB 77719 > 13355 Berlin, Germany Amtsgericht Charlottenburg > Tel.: +49 30 23 45 86 96 Sitz der Gesellschaft: Berlin > Fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Olaf Wagner -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From neels at elego.de Thu Jan 24 23:11:08 2008 From: neels at elego.de (Neels Janosch Hofmeyr) Date: Thu, 24 Jan 2008 23:11:08 +0100 Subject: [M3devel] segmentation fault upon ./install-cm3-compiler.sh upgrade In-Reply-To: <20080124230322.vl12nlls4kosoocs@mail.elegosoft.com> References: <4798FE9B.1090204@elego.de> <479905C8.7080003@elego.de> <20080124230322.vl12nlls4kosoocs@mail.elegosoft.com> Message-ID: <47990CFC.8080609@elego.de> Olaf Wagner wrote: > Quoting Neels Janosch Hofmeyr : > >> btw, I am using the "stable release" source tarballs with the 5.4.0 > > Hi Neels, > > 5.4.0 is rather old now. I assume Ubuntu has made some incompatible > changes to its kernel or C library interfaces that the old cm3 binary > cannot cope with. What about trying one the more recent installation > archives, like d.5.5.1? Once you have a working cm3 and cm3cg, compiling > the rest should be no problem. Stable releases cannot necessarily be > expected to run on newer operating systems when the ABI changes, as they > don't adapt themselves ;-) > > Try this, for example: > > http://modula3.elegosoft.com/cm3/snaps/cm3-min-POSIX-LINUXLIBC6-d5.5.1-2008-01-24-03-35-01.tgz > I'll try it next. btw, I am writing an instructions text for installing on ubuntu 7.10 along the way... > > It should also be possible to get a backtrace of the cm3 crash > within gdb. There should be debugging symbols in the distributed > binaries. What does bt show? I tried bt, it shows nothing: $ gdb /usr/local/cm3/bin/cm3 GNU gdb 6.6-debian Copyright (C) 2006 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i486-linux-gnu"... Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1". (gdb) run -version Starting program: /usr/local/cm3/bin/cm3 -version Program received signal SIGSEGV, Segmentation fault. 0x9e841069 in ?? () (gdb) bt #0 0x9e841069 in ?? () Cannot access memory at address 0xf05fc929 (gdb) > > If debugging symbols are missing, we've got to fix that. Well, that doesn't mean debugging symbols are missing, sometimes this kind of thing happens anyway (right?). > > Olaf > >> Neels Janosch Hofmeyr wrote: >>> Hi lists, >>> >>> I am trying to install cm3 5.4.0 on Ubuntu 7.10. I know that it >>> worked on 7.4, and am doing the exact same steps. I have now tried >>> it with cm3-min-...-5.4.0, just as I did last year. >>> >>> But now, I get this output: >>> >>> neels at oubantu:~/cm3-build/scripts >>> $ ./install-cm3-compiler.sh upgrade >>> cp /usr/local/cm3/bin/cm3 /usr/local/cm3/bin/cm3-5.4.0 >>> cp /usr/local/cm3/bin/cm3cg /usr/local/cm3/bin/cm3cg-5.4.0 >>> Segmentation fault (core dumped) >>> cp /home/neels/cm3-build/m3-sys/cm3/LINUXLIBC6/cm3 >>> /usr/local/cm3/bin/cm3- >>> cp /home/neels/cm3-build/m3-sys/m3cc/LINUXLIBC6/cm3cg >>> /usr/local/cm3/bin/cm3cg- >>> cp /usr/local/cm3/bin/cm3- /usr/local/cm3/bin/cm3 >>> cp /usr/local/cm3/bin/cm3cg- /usr/local/cm3/bin/cm3cg >>> >>> I have done this a second time, making sure everything is cleaned >>> out and monitored things. From adding a `set -x' in the >>> install-cm3-compiler.sh, it becomes obvious that >>> `/usr/local/cm3/bin/cm3 -version' exits with a Segmentation Fault. >>> >>> After doing ./cminstall (the minimal binary install), cm3 -version said >>> $ /usr/local/cm3/bin/cm3 -version >>> Critical Mass Modula-3 version 5.4.0 >>> last updated: 2006-10-11 >>> configuration: /usr/local/cm3/bin/cm3.cfg >>> >>> After doing ./do-cm3-core.sh buildship, it still said the same. >>> So, somewhere in install-cm3-compiler.sh, a disfunctional cm3 >>> binary gets installed in /usr/local/cm3/bin/, after which cm3 >>> yields only segmentation faults. >>> >>> After install-cm3-compiler.sh, cm3 -version says >>> $ /usr/local/cm3/bin/cm3 -version >>> >>> >>> *** >>> *** runtime error: >>> *** Segmentation violation - possible attempt to dereference NIL >>> *** pc = 0x9e841069 >>> *** >>> >>> Aborted (core dumped) >>> >>> Trying to backtrace in gdb apparently doesn't work -- I don't know >>> how to compile debugging symbols into it. Giving up. >>> >>> I think now is the time to remove the statement "[cm3 is] >>> easy-to-use [and] easy-to-install" from modula3.elegosoft.com. No >>> piece of software I have ever encountered is as difficult to use >>> and as impossible to install as critical mass modula3. I *am* >>> following all the instructions! >>> >>> argh, >>> Neels >>> >> >> -- >> Neels Janosch Hofmeyr >> Software Developer >> >> neels at elego.de >> Public Key: http://binarchy.net/neels/neels.hofmeyr.public.key.asc >> >> elego Software Solutions GmbH http://www.elegosoft.com >> Gustav-Meyer-Allee 25, Geb?ude 12 HRB 77719 >> 13355 Berlin, Germany Amtsgericht Charlottenburg >> Tel.: +49 30 23 45 86 96 Sitz der Gesellschaft: Berlin >> Fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Olaf Wagner > > > -- Neels Janosch Hofmeyr Software Developer neels at elego.de Public Key: http://binarchy.net/neels/neels.hofmeyr.public.key.asc elego Software Solutions GmbH http://www.elegosoft.com Gustav-Meyer-Allee 25, Geb?ude 12 HRB 77719 13355 Berlin, Germany Amtsgericht Charlottenburg Tel.: +49 30 23 45 86 96 Sitz der Gesellschaft: Berlin Fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Olaf Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From neels at elego.de Thu Jan 24 23:21:39 2008 From: neels at elego.de (Neels Janosch Hofmeyr) Date: Thu, 24 Jan 2008 23:21:39 +0100 Subject: [M3devel] snapshots checksums are missing Message-ID: <47990F73.3010707@elego.de> btw, on http://modula3.elegosoft.com/cm3/checksums.php3 , I can't find checksums for the daily snapshots. At least not for cm3-min-POSIX-LINUXLIBC6-d5.5.1-2008-01-24-03-35-01.tgz or any other d5.5.1 tarball -- Neels Janosch Hofmeyr Software Developer neels at elego.de Public Key: http://binarchy.net/neels/neels.hofmeyr.public.key.asc elego Software Solutions GmbH http://www.elegosoft.com Gustav-Meyer-Allee 25, Geb?ude 12 HRB 77719 13355 Berlin, Germany Amtsgericht Charlottenburg Tel.: +49 30 23 45 86 96 Sitz der Gesellschaft: Berlin Fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Olaf Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From jayk123 at hotmail.com Thu Jan 24 23:32:08 2008 From: jayk123 at hotmail.com (Jay) Date: Thu, 24 Jan 2008 22:32:08 +0000 Subject: [M3devel] segmentation fault upon ./install-cm3-compiler.sh upgrade In-Reply-To: <47990CFC.8080609@elego.de> References: <4798FE9B.1090204@elego.de> <479905C8.7080003@elego.de> <20080124230322.vl12nlls4kosoocs@mail.elegosoft.com> <47990CFC.8080609@elego.de> Message-ID: > Stable releases cannot necessarily be > expected to run on newer operating systems when the ABI changes, as they > don't adapt themselves ;-) Wow. No stable ABI? What's up with that? I understand that building with current headers/libs might not work on older systems, but building with older headers/libs should almost always work on newer systems, AT LEAST at the ABI level, if not at the exact behavioral level, that's much harder, if there is to be any change or any bug fixes. People get away with the craziest things, like double frees (ok, not in safe Modula-3), only to have newer better heaps be more strict and catch them... > Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1". Is that normal? > Program received signal SIGSEGV, Segmentation fault. > 0x9e841069 in ?? () > (gdb) bt > #0 0x9e841069 in ?? () > Cannot access memory at address 0xf05fc929 > (gdb) If the above is normal..can you break on main? And..I don't know what the name is...a bisection search..for how far it gets before it crashes? You know, either systematically, or at least randomly, step over and step into function calls, if you go to far and it crashes, step into next time instead of step over. > > If debugging symbols are missing, we've got to fix that. Sorry, I was speculating, based mainly on "strip" appear in scripts/*.sh, didn't look if it is used. > Well, that doesn't mean debugging symbols are missing, sometimes this > kind of thing happens anyway (right?). Right. - Jay > Date: Thu, 24 Jan 2008 23:11:08 +0100> From: neels at elego.de> To: wagner at elegosoft.com> CC: m3devel at elego.de; m3-support at elego.de> Subject: Re: [M3devel] segmentation fault upon ./install-cm3-compiler.sh upgrade> > > > Olaf Wagner wrote:> > Quoting Neels Janosch Hofmeyr :> >> >> btw, I am using the "stable release" source tarballs with the 5.4.0> >> > Hi Neels,> >> > 5.4.0 is rather old now. I assume Ubuntu has made some incompatible> > changes to its kernel or C library interfaces that the old cm3 binary> > cannot cope with. What about trying one the more recent installation> > archives, like d.5.5.1? Once you have a working cm3 and cm3cg, compiling> > the rest should be no problem. Stable releases cannot necessarily be> > expected to run on newer operating systems when the ABI changes, as they> > don't adapt themselves ;-)> >> > Try this, for example:> >> > http://modula3.elegosoft.com/cm3/snaps/cm3-min-POSIX-LINUXLIBC6-d5.5.1-2008-01-24-03-35-01.tgz > >> I'll try it next.> btw, I am writing an instructions text for installing on ubuntu 7.10 > along the way...> >> > It should also be possible to get a backtrace of the cm3 crash> > within gdb. There should be debugging symbols in the distributed> > binaries. What does bt show?> I tried bt, it shows nothing:> > $ gdb /usr/local/cm3/bin/cm3> GNU gdb 6.6-debian> Copyright (C) 2006 Free Software Foundation, Inc.> GDB is free software, covered by the GNU General Public License, and you are> welcome to change it and/or distribute copies of it under certain > conditions.> Type "show copying" to see the conditions.> There is absolutely no warranty for GDB. Type "show warranty" for details.> This GDB was configured as "i486-linux-gnu"...> Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1".> (gdb) run -version> Starting program: /usr/local/cm3/bin/cm3 -version> > Program received signal SIGSEGV, Segmentation fault.> 0x9e841069 in ?? ()> (gdb) bt> #0 0x9e841069 in ?? ()> Cannot access memory at address 0xf05fc929> (gdb)> > >> > If debugging symbols are missing, we've got to fix that.> Well, that doesn't mean debugging symbols are missing, sometimes this > kind of thing happens anyway (right?).> >> > Olaf> >> >> Neels Janosch Hofmeyr wrote:> >>> Hi lists,> >>>> >>> I am trying to install cm3 5.4.0 on Ubuntu 7.10. I know that it > >>> worked on 7.4, and am doing the exact same steps. I have now tried > >>> it with cm3-min-...-5.4.0, just as I did last year.> >>>> >>> But now, I get this output:> >>>> >>> neels at oubantu:~/cm3-build/scripts> >>> $ ./install-cm3-compiler.sh upgrade> >>> cp /usr/local/cm3/bin/cm3 /usr/local/cm3/bin/cm3-5.4.0> >>> cp /usr/local/cm3/bin/cm3cg /usr/local/cm3/bin/cm3cg-5.4.0> >>> Segmentation fault (core dumped)> >>> cp /home/neels/cm3-build/m3-sys/cm3/LINUXLIBC6/cm3 > >>> /usr/local/cm3/bin/cm3-> >>> cp /home/neels/cm3-build/m3-sys/m3cc/LINUXLIBC6/cm3cg > >>> /usr/local/cm3/bin/cm3cg-> >>> cp /usr/local/cm3/bin/cm3- /usr/local/cm3/bin/cm3> >>> cp /usr/local/cm3/bin/cm3cg- /usr/local/cm3/bin/cm3cg> >>>> >>> I have done this a second time, making sure everything is cleaned > >>> out and monitored things. From adding a `set -x' in the > >>> install-cm3-compiler.sh, it becomes obvious that > >>> `/usr/local/cm3/bin/cm3 -version' exits with a Segmentation Fault.> >>>> >>> After doing ./cminstall (the minimal binary install), cm3 -version said> >>> $ /usr/local/cm3/bin/cm3 -version> >>> Critical Mass Modula-3 version 5.4.0> >>> last updated: 2006-10-11> >>> configuration: /usr/local/cm3/bin/cm3.cfg> >>>> >>> After doing ./do-cm3-core.sh buildship, it still said the same.> >>> So, somewhere in install-cm3-compiler.sh, a disfunctional cm3 > >>> binary gets installed in /usr/local/cm3/bin/, after which cm3 > >>> yields only segmentation faults.> >>>> >>> After install-cm3-compiler.sh, cm3 -version says> >>> $ /usr/local/cm3/bin/cm3 -version> >>>> >>>> >>> ***> >>> *** runtime error:> >>> *** Segmentation violation - possible attempt to dereference NIL> >>> *** pc = 0x9e841069> >>> ***> >>>> >>> Aborted (core dumped)> >>>> >>> Trying to backtrace in gdb apparently doesn't work -- I don't know > >>> how to compile debugging symbols into it. Giving up.> >>>> >>> I think now is the time to remove the statement "[cm3 is] > >>> easy-to-use [and] easy-to-install" from modula3.elegosoft.com. No > >>> piece of software I have ever encountered is as difficult to use > >>> and as impossible to install as critical mass modula3. I *am* > >>> following all the instructions!> >>>> >>> argh,> >>> Neels> >>>> >>> >> -- > >> Neels Janosch Hofmeyr> >> Software Developer> >>> >> neels at elego.de> >> Public Key: http://binarchy.net/neels/neels.hofmeyr.public.key.asc> >>> >> elego Software Solutions GmbH http://www.elegosoft.com> >> Gustav-Meyer-Allee 25, Geb?ude 12 HRB 77719> >> 13355 Berlin, Germany Amtsgericht Charlottenburg> >> Tel.: +49 30 23 45 86 96 Sitz der Gesellschaft: Berlin> >> Fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Olaf Wagner> >> >> >> > -- > Neels Janosch Hofmeyr> Software Developer> > neels at elego.de> Public Key: http://binarchy.net/neels/neels.hofmeyr.public.key.asc> > elego Software Solutions GmbH http://www.elegosoft.com> Gustav-Meyer-Allee 25, Geb?ude 12 HRB 77719> 13355 Berlin, Germany Amtsgericht Charlottenburg> Tel.: +49 30 23 45 86 96 Sitz der Gesellschaft: Berlin> Fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Olaf Wagner> > _________________________________________________________________ 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 Jan 24 23:35:19 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 24 Jan 2008 23:35:19 +0100 Subject: [M3devel] segmentation fault upon ./install-cm3-compiler.sh upgrade In-Reply-To: <47990CFC.8080609@elego.de> References: <4798FE9B.1090204@elego.de> <479905C8.7080003@elego.de> <20080124230322.vl12nlls4kosoocs@mail.elegosoft.com> <47990CFC.8080609@elego.de> Message-ID: <20080124233519.s3o34cbsmc8kocs8@mail.elegosoft.com> Quoting Neels Janosch Hofmeyr : > Olaf Wagner wrote: >> Quoting Neels Janosch Hofmeyr : >> >>> btw, I am using the "stable release" source tarballs with the 5.4.0 >> >> Hi Neels, >> >> 5.4.0 is rather old now. I assume Ubuntu has made some incompatible >> changes to its kernel or C library interfaces that the old cm3 binary >> cannot cope with. What about trying one the more recent installation >> archives, like d.5.5.1? Once you have a working cm3 and cm3cg, compiling >> the rest should be no problem. Stable releases cannot necessarily be >> expected to run on newer operating systems when the ABI changes, as they >> don't adapt themselves ;-) >> >> Try this, for example: >> >> http://modula3.elegosoft.com/cm3/snaps/cm3-min-POSIX-LINUXLIBC6-d5.5.1-2008-01-24-03-35-01.tgz > I'll try it next. > btw, I am writing an instructions text for installing on ubuntu 7.10 > along the way... >> >> It should also be possible to get a backtrace of the cm3 crash >> within gdb. There should be debugging symbols in the distributed >> binaries. What does bt show? > I tried bt, it shows nothing: > > $ gdb /usr/local/cm3/bin/cm3 > GNU gdb 6.6-debian > Copyright (C) 2006 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and you are > welcome to change it and/or distribute copies of it under certain conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for details. > This GDB was configured as "i486-linux-gnu"... > Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1". > (gdb) run -version > Starting program: /usr/local/cm3/bin/cm3 -version > > Program received signal SIGSEGV, Segmentation fault. > 0x9e841069 in ?? () > (gdb) bt > #0 0x9e841069 in ?? () > Cannot access memory at address 0xf05fc929 > (gdb) Seems to be a random address. My guess would be that Ubuntu now encrypts its jmp_buf data, too, and you are using M3 UTHREADS. Try some runtime arguments to get some more data: @M3debugthreads, @M3nopreemption, @M3novm, @M3nogc Perhaps we get some clues. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Jan 24 23:38:24 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 24 Jan 2008 23:38:24 +0100 Subject: [M3devel] snapshots checksums are missing In-Reply-To: <47990F73.3010707@elego.de> References: <47990F73.3010707@elego.de> Message-ID: <20080124233824.aqrb8ki1kcsww48o@mail.elegosoft.com> Quoting Neels Janosch Hofmeyr : > btw, on > > http://modula3.elegosoft.com/cm3/checksums.php3 > > , I can't find checksums for the daily snapshots. At least not for > > cm3-min-POSIX-LINUXLIBC6-d5.5.1-2008-01-24-03-35-01.tgz > > or any other d5.5.1 tarball There are none so far :-). Are you afraid or is the archive broken? Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From neels at elego.de Thu Jan 24 23:42:11 2008 From: neels at elego.de (Neels Janosch Hofmeyr) Date: Thu, 24 Jan 2008 23:42:11 +0100 Subject: [M3devel] still errors with cm3-min-POSIX-LINUXLIBC6-d5.5.1-2008-01-24-03-35-01 Message-ID: <47991443.2050809@elego.de> Using the cm3-min-POSIX-LINUXLIBC6-d5.5.1-2008-01-24-03-35-01.tgz in conjunction with the 5.4.0 source tarballs, I get, : $ cm3 -version Critical Mass Modula-3 version d5.5.1-2008-01-24-03-35-01 last updated: 2007-12-30 compiled: 2008-01-24 03:54:37 configuration: /usr/local/cm3/bin/cm3.cfg neels at oubantu:~/cm3-build/scripts $ vim ~/cm3-build/m3-libs/m3gc-simple/src/runtime/LINUXLIBC6/sysdeps.c {to remove the asm/ipc.h, as described on the known problems page} neels at oubantu:~/cm3-build/scripts $ ./do-cm3-core.sh buildship CM3C = /home/neels/cm3-build/scripts/pkgmap.sh -c "cm3 -build -DROOT='/home/neels/cm3-build' && cm3 -ship -DROOT='/home/neels/cm3-build' " m3gc-simple m3core libm3 patternmatching m3middle m3linker m3front m3quake m3cc cm3 m3scanner m3tools m3cgcat m3cggen m3bundle bitvector digraph parseparams realgeometry set slisp sortedtableextras table-list tempfiles === package /home/neels/cm3-build/m3-libs/m3gc-simple === +++ cm3 -build -DROOT='/home/neels/cm3-build' && cm3 -ship -DROOT='/home/neels/cm3-build' +++ --- building in LINUXLIBC6 --- new source -> compiling RTVM.c new source -> compiling sysdeps.c -> archiving libm3gcdefs.a --- shipping from LINUXLIBC6 --- . => /usr/local/cm3/pkg/m3gc-simple/LINUXLIBC6 .M3EXPORTS libm3gcdefs.so.5 libm3gcdefs.a libm3gcdefs.m3x .M3WEB ../src/runtime => /usr/local/cm3/pkg/m3gc-simple/src/runtime RTVM.c ../src/runtime/LINUXLIBC6 => /usr/local/cm3/pkg/m3gc-simple/src/runtime/LINUXLIBC6 sysdeps.c . => /usr/local/cm3/lib libm3gcdefs.a ==> /home/neels/cm3-build/m3-libs/m3gc-simple done === package /home/neels/cm3-build/m3-libs/m3core === +++ cm3 -build -DROOT='/home/neels/cm3-build' && cm3 -ship -DROOT='/home/neels/cm3-build' +++ --- building in LINUXLIBC6 --- ignoring ../src/m3overrides new source -> compiling RTHooks.i3 new source -> compiling RT0.i3 new source -> compiling RuntimeError.i3 new source -> compiling Word.i3 new source -> compiling RTException.i3 new source -> compiling RTHooks.m3 new source -> compiling RT0.m3 new source -> compiling Compiler.i3 new source -> compiling RuntimeError.m3 new source -> compiling Compiler.m3 new source -> compiling RTAllocator.i3 new source -> compiling RTType.i3 new source -> compiling Uucontext.i3 new source -> compiling Utypes.i3 new source -> compiling BasicCtypes.i3 new source -> compiling Ctypes.i3 new source -> compiling Usignal.i3 new source -> compiling Csetjmp.i3 new source -> compiling RTMachine.i3 new source -> compiling Upthread.i3 new source -> compiling Utime.i3 new source -> compiling RTHeapDep.i3 new source -> compiling RTHeapRep.i3 new source -> compiling Thread.i3 new source -> compiling FloatMode.i3 new source -> compiling ThreadF.i3 new source -> compiling RTOS.i3 new source -> compiling RTMisc.i3 new source -> compiling RTHeap.i3 new source -> compiling Cstdlib.i3 new source -> compiling Cstddef.i3 new source -> compiling RTAllocCnts.i3 new source -> compiling RTAllocator.m3 new source -> compiling RTAllocStats.i3 new source -> compiling Convert.i3 new source -> compiling TextClass.i3 new source -> compiling Text.i3 new source -> compiling RTProcedureSRC.i3 new source -> compiling Fingerprint.i3 new source -> compiling RTProcedure.i3 new source -> compiling RTStack.i3 new source -> compiling RTAllocStats.m3 "../src/runtime/common/RTAllocStats.m3", line 46: undefined runtime symbol !! (RTHooks.AllocateTracedRef) *** *** runtime error: *** Segmentation violation - possible attempt to dereference NIL *** pc = 0x816f27f = StartCall + 0x19 in ../src/values/Procedure.m3 *** Aborted (core dumped) *** execution of failed *** trying to backtrace yields this: neels at oubantu:~/cm3-build/m3-libs/m3core $ gdb /usr/local/cm3/bin/cm3 GNU gdb 6.6-debian Copyright (C) 2006 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i486-linux-gnu"... (no debugging symbols found) Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1". (gdb) run -build -DROOT='/home/neels/cm3-build' Starting program: /usr/local/cm3/bin/cm3 -build -DROOT='/home/neels/cm3-build' (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) [Thread debugging using libthread_db enabled] [New Thread -1210534224 (LWP 6710)] (no debugging symbols found) [New Thread -1210807408 (LWP 6713)] Program received signal SIG64, Real-time event 64. [Switching to Thread -1210807408 (LWP 6713)] 0xffffe410 in __kernel_vsyscall () (gdb) bt #0 0xffffe410 in __kernel_vsyscall () #1 0xb7ee0676 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/i686/cmov/libpthread.so.0 #2 0x082ac2d0 in ?? () #3 0x08b5c1a0 in ?? () #4 0x08b5c3a8 in ?? () #5 0xb7d48198 in ?? () #6 0x082abeb2 in ?? () #7 0xb7d4a0b0 in ?? () #8 0x082ab578 in ?? () #9 0xb7ede541 in pthread_mutex_lock () from /lib/tls/i686/cmov/libpthread.so.0 #10 0x082ac932 in ?? () #11 0xb7d4a174 in ?? () #12 0xb7d4a0b0 in ?? () #13 0xb7d4a0c0 in ?? () #14 0x00000000 in ?? () (gdb) c Continuing. Program received signal SIG64, Real-time event 64. 0xffffe410 in __kernel_vsyscall () (gdb) c Continuing. --- building in LINUXLIBC6 --- ignoring ../src/m3overrides Program received signal SIG64, Real-time event 64. 0xffffe410 in __kernel_vsyscall () (gdb) c Continuing. Program received signal SIG64, Real-time event 64. 0xffffe410 in __kernel_vsyscall () (gdb) c Continuing. Program received signal SIG64, Real-time event 64. 0xffffe410 in __kernel_vsyscall () (gdb) c Continuing. Program received signal SIG64, Real-time event 64. 0xffffe410 in __kernel_vsyscall () (gdb) c Continuing. Program received signal SIG64, Real-time event 64. 0xffffe410 in __kernel_vsyscall () (gdb) c Continuing. Program received signal SIG64, Real-time event 64. 0xffffe410 in __kernel_vsyscall () (gdb) c Continuing. new source -> compiling RTAllocStats.m3 Program received signal SIG64, Real-time event 64. 0xffffe410 in __kernel_vsyscall () (gdb) c Continuing. Program received signal SIG64, Real-time event 64. 0xffffe410 in __kernel_vsyscall () (gdb) c Continuing. Program received signal SIG64, Real-time event 64. 0xffffe410 in __kernel_vsyscall () (gdb) c Continuing. Program received signal SIG64, Real-time event 64. 0xffffe410 in __kernel_vsyscall () (gdb) c Continuing. "../src/runtime/common/RTAllocStats.m3", line 46: undefined runtime symbol !! (RTHooks.AllocateTracedRef) Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1210534224 (LWP 6710)] 0x0816f27f in ?? () (gdb) c Continuing. *** *** runtime error: *** Segmentation violation - possible attempt to dereference NIL *** pc = 0x816f27f = StartCall + 0x19 in ../src/values/Procedure.m3 *** Program received signal SIGABRT, Aborted. 0xffffe410 in __kernel_vsyscall () (gdb) bt #0 0xffffe410 in __kernel_vsyscall () #1 0xb7db6875 in raise () from /lib/tls/i686/cmov/libc.so.6 #2 0xb7db8201 in abort () from /lib/tls/i686/cmov/libc.so.6 #3 0x082a8daf in ?? () #4 0x080159a4 in ?? () #5 0x082d31a4 in ?? () #6 0xbfe7f578 in ?? () #7 0x0829e3c4 in ?? () #8 0x0000004d in ?? () #9 0x082d31a4 in ?? () #10 0xbfe7f588 in ?? () #11 0x08298aa1 in ?? () #12 0x01b514e0 in ?? () #13 0x082d31a4 in ?? () #14 0xbfe7f598 in ?? () #15 0x0829bd25 in ?? () #16 0x00000000 in ?? () (gdb) c Continuing. Program terminated with signal SIGABRT, Aborted. The program no longer exists. (gdb) This happens both with "-gstabs+" and "-g" in cm3.cfg (Mikas hint reversed). Next, I'll try to checkout the sources from CVS... if that makes any sense. -- Neels Janosch Hofmeyr Software Developer neels at elego.de Public Key: http://binarchy.net/neels/neels.hofmeyr.public.key.asc elego Software Solutions GmbH http://www.elegosoft.com Gustav-Meyer-Allee 25, Geb?ude 12 HRB 77719 13355 Berlin, Germany Amtsgericht Charlottenburg Tel.: +49 30 23 45 86 96 Sitz der Gesellschaft: Berlin Fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Olaf Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From neels at elego.de Thu Jan 24 23:44:58 2008 From: neels at elego.de (Neels Janosch Hofmeyr) Date: Thu, 24 Jan 2008 23:44:58 +0100 Subject: [M3devel] segmentation fault upon ./install-cm3-compiler.sh upgrade In-Reply-To: <20080124233519.s3o34cbsmc8kocs8@mail.elegosoft.com> References: <4798FE9B.1090204@elego.de> <479905C8.7080003@elego.de> <20080124230322.vl12nlls4kosoocs@mail.elegosoft.com> <47990CFC.8080609@elego.de> <20080124233519.s3o34cbsmc8kocs8@mail.elegosoft.com> Message-ID: <479914EA.3060902@elego.de> Olaf Wagner wrote: > > Try some runtime arguments to get some more data: > @M3debugthreads, @M3nopreemption, @M3novm, @M3nogc Sorry, I don't understand... -- Neels Janosch Hofmeyr Software Developer neels at elego.de Public Key: http://binarchy.net/neels/neels.hofmeyr.public.key.asc elego Software Solutions GmbH http://www.elegosoft.com Gustav-Meyer-Allee 25, Geb?ude 12 HRB 77719 13355 Berlin, Germany Amtsgericht Charlottenburg Tel.: +49 30 23 45 86 96 Sitz der Gesellschaft: Berlin Fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Olaf Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From neels at elego.de Thu Jan 24 23:46:03 2008 From: neels at elego.de (Neels Janosch Hofmeyr) Date: Thu, 24 Jan 2008 23:46:03 +0100 Subject: [M3devel] snapshots checksums are missing In-Reply-To: <20080124233824.aqrb8ki1kcsww48o@mail.elegosoft.com> References: <47990F73.3010707@elego.de> <20080124233824.aqrb8ki1kcsww48o@mail.elegosoft.com> Message-ID: <4799152B.2090906@elego.de> Olaf Wagner wrote: > Quoting Neels Janosch Hofmeyr : > >> btw, on >> >> http://modula3.elegosoft.com/cm3/checksums.php3 >> >> , I can't find checksums for the daily snapshots. At least not for >> >> cm3-min-POSIX-LINUXLIBC6-d5.5.1-2008-01-24-03-35-01.tgz >> >> or any other d5.5.1 tarball > > There are none so far :-). Are you afraid or is the archive broken? No, I'm just including the checksums in the instructions text for completeness. Just wanted to double check... nevermind though. -- Neels Janosch Hofmeyr Software Developer neels at elego.de Public Key: http://binarchy.net/neels/neels.hofmeyr.public.key.asc elego Software Solutions GmbH http://www.elegosoft.com Gustav-Meyer-Allee 25, Geb?ude 12 HRB 77719 13355 Berlin, Germany Amtsgericht Charlottenburg Tel.: +49 30 23 45 86 96 Sitz der Gesellschaft: Berlin Fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Olaf Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From hosking at cs.purdue.edu Thu Jan 24 23:46:31 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 24 Jan 2008 17:46:31 -0500 Subject: [M3devel] segmentation fault upon ./install-cm3-compiler.sh upgrade In-Reply-To: <479914EA.3060902@elego.de> References: <4798FE9B.1090204@elego.de> <479905C8.7080003@elego.de> <20080124230322.vl12nlls4kosoocs@mail.elegosoft.com> <47990CFC.8080609@elego.de> <20080124233519.s3o34cbsmc8kocs8@mail.elegosoft.com> <479914EA.3060902@elego.de> Message-ID: <80025F80-FDA6-4E9D-AC2A-73C6498A6EA0@cs.purdue.edu> I'm pretty sure these problems are a result of needing to use a new bootstrap compiler. On Jan 24, 2008, at 5:44 PM, Neels Janosch Hofmeyr wrote: > > > Olaf Wagner wrote: >> >> Try some runtime arguments to get some more data: >> @M3debugthreads, @M3nopreemption, @M3novm, @M3nogc > Sorry, I don't understand... > > -- > Neels Janosch Hofmeyr > Software Developer > > neels at elego.de > Public Key: http://binarchy.net/neels/neels.hofmeyr.public.key.asc > > elego Software Solutions GmbH http://www.elegosoft.com > Gustav-Meyer-Allee 25, Geb?ude 12 HRB 77719 > 13355 Berlin, Germany Amtsgericht Charlottenburg > Tel.: +49 30 23 45 86 96 Sitz der Gesellschaft: Berlin > Fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Olaf Wagner > > From hosking at cs.purdue.edu Thu Jan 24 23:47:24 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 24 Jan 2008 17:47:24 -0500 Subject: [M3devel] still errors with cm3-min-POSIX-LINUXLIBC6-d5.5.1-2008-01-24-03-35-01 In-Reply-To: <47991443.2050809@elego.de> References: <47991443.2050809@elego.de> Message-ID: <0ABA0093-F7F5-440F-98B7-7AFD4317FAC6@cs.purdue.edu> On Jan 24, 2008, at 5:42 PM, Neels Janosch Hofmeyr wrote: > Using the > cm3-min-POSIX-LINUXLIBC6-d5.5.1-2008-01-24-03-35-01.tgz > in conjunction with the 5.4.0 source tarballs, I get, : > > $ cm3 -version > Critical Mass Modula-3 version d5.5.1-2008-01-24-03-35-01 > last updated: 2007-12-30 > compiled: 2008-01-24 03:54:37 > configuration: /usr/local/cm3/bin/cm3.cfg > > neels at oubantu:~/cm3-build/scripts > $ vim ~/cm3-build/m3-libs/m3gc-simple/src/runtime/LINUXLIBC6/sysdeps.c > {to remove the asm/ipc.h, as described on the known problems page} > > neels at oubantu:~/cm3-build/scripts > $ ./do-cm3-core.sh buildship > CM3C = > /home/neels/cm3-build/scripts/pkgmap.sh -c "cm3 -build -DROOT='/ > home/neels/cm3-build' && cm3 -ship -DROOT='/home/neels/cm3-build' > " m3gc-simple m3core libm3 patternmatching m3middle m3linker > m3front m3quake m3cc cm3 m3scanner m3tools m3cgcat m3cggen m3bundle > bitvector digraph parseparams realgeometry set slisp > sortedtableextras table-list tempfiles > === package /home/neels/cm3-build/m3-libs/m3gc-simple === > +++ cm3 -build -DROOT='/home/neels/cm3-build' && cm3 -ship - > DROOT='/home/neels/cm3-build' +++ > --- building in LINUXLIBC6 --- > > new source -> compiling RTVM.c > new source -> compiling sysdeps.c > -> archiving libm3gcdefs.a > --- shipping from LINUXLIBC6 --- > > . => /usr/local/cm3/pkg/m3gc-simple/LINUXLIBC6 > .M3EXPORTS libm3gcdefs.so.5 libm3gcdefs.a libm3gcdefs.m3x > .M3WEB ../src/runtime => /usr/local/cm3/pkg/m3gc-simple/ > src/runtime > RTVM.c ../src/runtime/LINUXLIBC6 => /usr/local/cm3/pkg/ > m3gc-simple/src/runtime/LINUXLIBC6 > sysdeps.c . => /usr/local/cm3/lib > libm3gcdefs.a ==> /home/neels/cm3-build/m3-libs/m3gc-simple done > > === package /home/neels/cm3-build/m3-libs/m3core === > +++ cm3 -build -DROOT='/home/neels/cm3-build' && cm3 -ship - > DROOT='/home/neels/cm3-build' +++ > --- building in LINUXLIBC6 --- > > ignoring ../src/m3overrides > > new source -> compiling RTHooks.i3 > new source -> compiling RT0.i3 > new source -> compiling RuntimeError.i3 > new source -> compiling Word.i3 > new source -> compiling RTException.i3 > new source -> compiling RTHooks.m3 > new source -> compiling RT0.m3 > new source -> compiling Compiler.i3 > new source -> compiling RuntimeError.m3 > new source -> compiling Compiler.m3 > new source -> compiling RTAllocator.i3 > new source -> compiling RTType.i3 > new source -> compiling Uucontext.i3 > new source -> compiling Utypes.i3 > new source -> compiling BasicCtypes.i3 > new source -> compiling Ctypes.i3 > new source -> compiling Usignal.i3 > new source -> compiling Csetjmp.i3 > new source -> compiling RTMachine.i3 > new source -> compiling Upthread.i3 > new source -> compiling Utime.i3 > new source -> compiling RTHeapDep.i3 > new source -> compiling RTHeapRep.i3 > new source -> compiling Thread.i3 > new source -> compiling FloatMode.i3 > new source -> compiling ThreadF.i3 > new source -> compiling RTOS.i3 > new source -> compiling RTMisc.i3 > new source -> compiling RTHeap.i3 > new source -> compiling Cstdlib.i3 > new source -> compiling Cstddef.i3 > new source -> compiling RTAllocCnts.i3 > new source -> compiling RTAllocator.m3 > new source -> compiling RTAllocStats.i3 > new source -> compiling Convert.i3 > new source -> compiling TextClass.i3 > new source -> compiling Text.i3 > new source -> compiling RTProcedureSRC.i3 > new source -> compiling Fingerprint.i3 > new source -> compiling RTProcedure.i3 > new source -> compiling RTStack.i3 > new source -> compiling RTAllocStats.m3 > "../src/runtime/common/RTAllocStats.m3", line 46: undefined runtime > symbol !! This is a new library function: you need newer sources. > (RTHooks.AllocateTracedRef) > > > *** > *** runtime error: > *** Segmentation violation - possible attempt to dereference NIL > *** pc = 0x816f27f = StartCall + 0x19 in ../src/values/Procedure.m3 > *** > > Aborted (core dumped) > *** execution of failed *** > > > trying to backtrace yields this: > > neels at oubantu:~/cm3-build/m3-libs/m3core > $ gdb /usr/local/cm3/bin/cm3 > GNU gdb 6.6-debian > Copyright (C) 2006 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, > and you are > welcome to change it and/or distribute copies of it under certain > conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for > details. > This GDB was configured as "i486-linux-gnu"... > (no debugging symbols found) > Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so. > 1". > (gdb) run -build -DROOT='/home/neels/cm3-build' > Starting program: /usr/local/cm3/bin/cm3 -build -DROOT='/home/ > neels/cm3-build' > (no debugging symbols found) > (no debugging symbols found) > (no debugging symbols found) > (no debugging symbols found) > [Thread debugging using libthread_db enabled] > [New Thread -1210534224 (LWP 6710)] > (no debugging symbols found) > [New Thread -1210807408 (LWP 6713)] > > Program received signal SIG64, Real-time event 64. > [Switching to Thread -1210807408 (LWP 6713)] > 0xffffe410 in __kernel_vsyscall () > (gdb) bt > #0 0xffffe410 in __kernel_vsyscall () > #1 0xb7ee0676 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/ > i686/cmov/libpthread.so.0 > #2 0x082ac2d0 in ?? () > #3 0x08b5c1a0 in ?? () > #4 0x08b5c3a8 in ?? () > #5 0xb7d48198 in ?? () > #6 0x082abeb2 in ?? () > #7 0xb7d4a0b0 in ?? () > #8 0x082ab578 in ?? () > #9 0xb7ede541 in pthread_mutex_lock () from /lib/tls/i686/cmov/ > libpthread.so.0 > #10 0x082ac932 in ?? () > #11 0xb7d4a174 in ?? () > #12 0xb7d4a0b0 in ?? () > #13 0xb7d4a0c0 in ?? () > #14 0x00000000 in ?? () > (gdb) c > Continuing. > > Program received signal SIG64, Real-time event 64. > 0xffffe410 in __kernel_vsyscall () > (gdb) c > Continuing. > --- building in LINUXLIBC6 --- > > ignoring ../src/m3overrides > > > Program received signal SIG64, Real-time event 64. > 0xffffe410 in __kernel_vsyscall () > (gdb) c > Continuing. > > Program received signal SIG64, Real-time event 64. > 0xffffe410 in __kernel_vsyscall () > (gdb) c > Continuing. > > Program received signal SIG64, Real-time event 64. > 0xffffe410 in __kernel_vsyscall () > (gdb) c > Continuing. > > Program received signal SIG64, Real-time event 64. > 0xffffe410 in __kernel_vsyscall () > (gdb) c > Continuing. > > Program received signal SIG64, Real-time event 64. > 0xffffe410 in __kernel_vsyscall () > (gdb) c > Continuing. > > Program received signal SIG64, Real-time event 64. > 0xffffe410 in __kernel_vsyscall () > (gdb) c > Continuing. > new source -> compiling RTAllocStats.m3 > > Program received signal SIG64, Real-time event 64. > 0xffffe410 in __kernel_vsyscall () > (gdb) c > Continuing. > > Program received signal SIG64, Real-time event 64. > 0xffffe410 in __kernel_vsyscall () > (gdb) c > Continuing. > > Program received signal SIG64, Real-time event 64. > 0xffffe410 in __kernel_vsyscall () > (gdb) c > Continuing. > > Program received signal SIG64, Real-time event 64. > 0xffffe410 in __kernel_vsyscall () > (gdb) c > Continuing. > "../src/runtime/common/RTAllocStats.m3", line 46: undefined runtime > symbol !! (RTHooks.AllocateTracedRef) > > Program received signal SIGSEGV, Segmentation fault. > [Switching to Thread -1210534224 (LWP 6710)] > 0x0816f27f in ?? () > (gdb) c > Continuing. > > > *** > *** runtime error: > *** Segmentation violation - possible attempt to dereference NIL > *** pc = 0x816f27f = StartCall + 0x19 in ../src/values/Procedure.m3 > *** > > > Program received signal SIGABRT, Aborted. > 0xffffe410 in __kernel_vsyscall () > (gdb) bt > #0 0xffffe410 in __kernel_vsyscall () > #1 0xb7db6875 in raise () from /lib/tls/i686/cmov/libc.so.6 > #2 0xb7db8201 in abort () from /lib/tls/i686/cmov/libc.so.6 > #3 0x082a8daf in ?? () > #4 0x080159a4 in ?? () > #5 0x082d31a4 in ?? () > #6 0xbfe7f578 in ?? () > #7 0x0829e3c4 in ?? () > #8 0x0000004d in ?? () > #9 0x082d31a4 in ?? () > #10 0xbfe7f588 in ?? () > #11 0x08298aa1 in ?? () > #12 0x01b514e0 in ?? () > #13 0x082d31a4 in ?? () > #14 0xbfe7f598 in ?? () > #15 0x0829bd25 in ?? () > #16 0x00000000 in ?? () > (gdb) c > Continuing. > > Program terminated with signal SIGABRT, Aborted. > The program no longer exists. > (gdb) > > > This happens both with "-gstabs+" and "-g" in cm3.cfg (Mikas hint > reversed). > > Next, I'll try to checkout the sources from CVS... if that makes > any sense. > > -- > Neels Janosch Hofmeyr > Software Developer > > neels at elego.de > Public Key: http://binarchy.net/neels/neels.hofmeyr.public.key.asc > > elego Software Solutions GmbH http://www.elegosoft.com > Gustav-Meyer-Allee 25, Geb?ude 12 HRB 77719 > 13355 Berlin, Germany Amtsgericht Charlottenburg > Tel.: +49 30 23 45 86 96 Sitz der Gesellschaft: Berlin > Fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Olaf Wagner > > From neels at elego.de Thu Jan 24 23:54:24 2008 From: neels at elego.de (Neels Janosch Hofmeyr) Date: Thu, 24 Jan 2008 23:54:24 +0100 Subject: [M3devel] segmentation fault upon ./install-cm3-compiler.sh upgrade In-Reply-To: <80025F80-FDA6-4E9D-AC2A-73C6498A6EA0@cs.purdue.edu> References: <4798FE9B.1090204@elego.de> <479905C8.7080003@elego.de> <20080124230322.vl12nlls4kosoocs@mail.elegosoft.com> <47990CFC.8080609@elego.de> <20080124233519.s3o34cbsmc8kocs8@mail.elegosoft.com> <479914EA.3060902@elego.de> <80025F80-FDA6-4E9D-AC2A-73C6498A6EA0@cs.purdue.edu> Message-ID: <47991720.1030307@elego.de> Tony Hosking wrote: > I'm pretty sure these problems are a result of needing to use a new > bootstrap compiler. How can I build one from source? (does this question make sense?) -- Neels Janosch Hofmeyr Software Developer neels at elego.de Public Key: http://binarchy.net/neels/neels.hofmeyr.public.key.asc elego Software Solutions GmbH http://www.elegosoft.com Gustav-Meyer-Allee 25, Geb?ude 12 HRB 77719 13355 Berlin, Germany Amtsgericht Charlottenburg Tel.: +49 30 23 45 86 96 Sitz der Gesellschaft: Berlin Fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Olaf Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From neels at elego.de Thu Jan 24 23:57:12 2008 From: neels at elego.de (Neels Janosch Hofmeyr) Date: Thu, 24 Jan 2008 23:57:12 +0100 Subject: [M3devel] still errors with cm3-min-POSIX-LINUXLIBC6-d5.5.1-2008-01-24-03-35-01 In-Reply-To: <0ABA0093-F7F5-440F-98B7-7AFD4317FAC6@cs.purdue.edu> References: <47991443.2050809@elego.de> <0ABA0093-F7F5-440F-98B7-7AFD4317FAC6@cs.purdue.edu> Message-ID: <479917C8.1080106@elego.de> Tony Hosking wrote: >> "../src/runtime/common/RTAllocStats.m3", line 46: undefined runtime >> symbol !! > > This is a new library function: you need newer sources. > This seems to do the trick (checked out from CVS)... waiting for the compile to complete. -- Neels Janosch Hofmeyr Software Developer neels at elego.de Public Key: http://binarchy.net/neels/neels.hofmeyr.public.key.asc elego Software Solutions GmbH http://www.elegosoft.com Gustav-Meyer-Allee 25, Geb?ude 12 HRB 77719 13355 Berlin, Germany Amtsgericht Charlottenburg Tel.: +49 30 23 45 86 96 Sitz der Gesellschaft: Berlin Fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Olaf Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From jayk123 at hotmail.com Fri Jan 25 00:02:48 2008 From: jayk123 at hotmail.com (Jay) Date: Thu, 24 Jan 2008 23:02:48 +0000 Subject: [M3devel] segmentation fault upon ./install-cm3-compiler.sh upgrade In-Reply-To: <47991720.1030307@elego.de> References: <4798FE9B.1090204@elego.de> <479905C8.7080003@elego.de> <20080124230322.vl12nlls4kosoocs@mail.elegosoft.com> <47990CFC.8080609@elego.de> <20080124233519.s3o34cbsmc8kocs8@mail.elegosoft.com> <479914EA.3060902@elego.de> <80025F80-FDA6-4E9D-AC2A-73C6498A6EA0@cs.purdue.edu> <47991720.1030307@elego.de> Message-ID: You do it by building the compiler but not building the runtime, upgrade the compiler, rebuild the runtime, rebuild the compiler again clean, update the compiler again. upgrade.sh does this. The thing about @M3novm, @M3debugwhatever, etc. these are command line switches. The Modula-3 runtime (libm3core.so) looks for them and alters its behavior in various ways. For example @M3vm was needed to debug slightly older runtimes without incurrent kind of bogus faults. Anything starting with "@M3" is considered reserved for libm3core.so. - Jay > Date: Thu, 24 Jan 2008 23:54:24 +0100> From: neels at elego.de> To: hosking at cs.purdue.edu> CC: m3devel at elego.de; m3-support at elego.de> Subject: Re: [M3devel] segmentation fault upon ./install-cm3-compiler.sh upgrade> > > Tony Hosking wrote:> > I'm pretty sure these problems are a result of needing to use a new > > bootstrap compiler.> How can I build one from source? (does this question make sense?)> > -- > Neels Janosch Hofmeyr> Software Developer> > neels at elego.de> Public Key: http://binarchy.net/neels/neels.hofmeyr.public.key.asc> > elego Software Solutions GmbH http://www.elegosoft.com> Gustav-Meyer-Allee 25, Geb?ude 12 HRB 77719> 13355 Berlin, Germany Amtsgericht Charlottenburg> Tel.: +49 30 23 45 86 96 Sitz der Gesellschaft: Berlin> Fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Olaf Wagner> > _________________________________________________________________ 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 Fri Jan 25 00:19:27 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 25 Jan 2008 00:19:27 +0100 Subject: [M3devel] snapshots checksums are missing In-Reply-To: <47990F73.3010707@elego.de> References: <47990F73.3010707@elego.de> Message-ID: <20080125001927.92eud7h544gs0csg@mail.elegosoft.com> Quoting Neels Janosch Hofmeyr : > btw, on > > http://modula3.elegosoft.com/cm3/checksums.php3 > > , I can't find checksums for the daily snapshots. At least not for > > cm3-min-POSIX-LINUXLIBC6-d5.5.1-2008-01-24-03-35-01.tgz > > or any other d5.5.1 tarball Fixed :) Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Fri Jan 25 00:53:48 2008 From: rcoleburn at scires.com (Randy Coleburn) Date: Thu, 24 Jan 2008 18:53:48 -0500 Subject: [M3devel] INSTALL_ROOT and PKG_USE in cm3.cfg Message-ID: <4798DEB8.1E75.00D7.1@scires.com> Jay: The cm3.cfg that comes with your minimal binary installation on Windows (NT386) has the following lines: *---------------------------------------- % INSTALL_ROOT = BEGIN_CONFIG % "Where should CM3 be installed?" % 7 %-- user specified install root % END_CONFIG % INSTALL_ROOT = "c:\\cm3" if not defined("INSTALL_ROOT") if not equal ($INSTALLROOT, "") INSTALL_ROOT = $INSTALLROOT else INSTALL_ROOT = (path() & "\\..") end end BIN_INSTALL = INSTALL_ROOT & "\\bin ( file://\bin )" % executables LIB_INSTALL = INSTALL_ROOT & "\\lib ( file://\lib )" % libraries PKG_INSTALL = INSTALL_ROOT & "\\pkg ( file://\pkg )" % packages DOC_INSTALL = INSTALL_ROOT & "\\doc ( file://\doc )" % documents EMACS_INSTALL = INSTALL_ROOT & "\\elisp ( file://\elisp )" % emacs lisp code MAN_INSTALL = INSTALL_ROOT & "\\man ( file://\man )" % man pages HTML_INSTALL = INSTALL_ROOT & "\\www ( file://\www )" % public hypertext % % On some systems (e.g. AFS) you must install public files in a different % place from where you use them. If that is the case for your system, % specify the "use" location here, otherwise leave them alone. % %USE_ROOT = INSTALL_ROOT BIN_USE = BIN_INSTALL % executables LIB_USE = LIB_INSTALL % libraries PKG_USE = PKG_INSTALL % packages *---------------------------------------- Notice that the lines for INSTALL_ROOT and USE_ROOT are commented out. The Reactor program is coded to grab several variables out of cm3.cfg. For example, build_dir := M3Config.Get ("BUILD_DIR"); system_root := M3Config.Get ("PKG_USE"); doc_root := M3Config.Get ("DOC_INSTALL"); initial_browser := M3Config.Get ("INITIAL_CM3_IDE_BROWSER"); initial_editor := M3Config.Get ("INITIAL_CM3_IDE_EDITOR"); What is happening on my installation is that PKG_USE winds up being "\..\PKG". This is not a valid path and it is causing all sorts of trouble for Reactor. The reason it is getting set this way is that the ELSE branch of the, if not defined("INSTALL_ROOT"), is getting executed resulting in INSTALL_ROOT=\.. I'm not sure why this is coded this way. How do you suggest this should be repaired? Note, I have not checked all of the cm3.cfg variants for the other target platforms, but in order for reactor to work properly, it must be able to find a valid "PKG_USE" in the cm3.cfg. Regards, Randy -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Fri Jan 25 01:24:08 2008 From: jayk123 at hotmail.com (Jay) Date: Fri, 25 Jan 2008 00:24:08 +0000 Subject: [M3devel] INSTALL_ROOT and PKG_USE in cm3.cfg In-Reply-To: <4798DEB8.1E75.00D7.1@scires.com> References: <4798DEB8.1E75.00D7.1@scires.com> Message-ID: Blech. My way is more automatic and "portable" in the sense that you can move installations around and they keep working. As well, with my way, you just extract an archive and go, no setup/cminstall, no editing of the cm3.cfg file, just set %PATH% and run vcvars, and vcvars I think I can remove the need for. path() is a builtin Quake function that returns the directory of the currently being run Quake code. But yet Reactor. To unblock yourself, remove my code, add back the commented out, fix the path to match your particular install, don't submit the file. Perhaps move the current checked in file over to the config-no-install directory and then put config's file back in the old style, that requires running cminstall. My workflow will keep working, since it probes for config-no-install first. - Jay Date: Thu, 24 Jan 2008 18:53:48 -0500From: rcoleburn at scires.comTo: jay123 at hotmail.comCC: m3devel at elegosoft.comSubject: [M3devel] INSTALL_ROOT and PKG_USE in cm3.cfg Jay: The cm3.cfg that comes with your minimal binary installation on Windows (NT386) has the following lines: ----------------------------------------- % INSTALL_ROOT = BEGIN_CONFIG% "Where should CM3 be installed?"% 7 %-- user specified install root% END_CONFIG % INSTALL_ROOT = "c:\\cm3" if not defined("INSTALL_ROOT") if not equal ($INSTALLROOT, "") INSTALL_ROOT = $INSTALLROOT else INSTALL_ROOT = (path() & "\\..") endend BIN_INSTALL = INSTALL_ROOT & "\\bin" % executablesLIB_INSTALL = INSTALL_ROOT & "\\lib" % librariesPKG_INSTALL = INSTALL_ROOT & "\\pkg" % packagesDOC_INSTALL = INSTALL_ROOT & "\\doc" % documentsEMACS_INSTALL = INSTALL_ROOT & "\\elisp" % emacs lisp codeMAN_INSTALL = INSTALL_ROOT & "\\man" % man pagesHTML_INSTALL = INSTALL_ROOT & "\\www" % public hypertext %% On some systems (e.g. AFS) you must install public files in a different% place from where you use them. If that is the case for your system,% specify the "use" location here, otherwise leave them alone.%%USE_ROOT = INSTALL_ROOTBIN_USE = BIN_INSTALL % executablesLIB_USE = LIB_INSTALL % librariesPKG_USE = PKG_INSTALL % packages ----------------------------------------- Notice that the lines for INSTALL_ROOT and USE_ROOT are commented out. The Reactor program is coded to grab several variables out of cm3.cfg. For example, build_dir := M3Config.Get ("BUILD_DIR"); system_root := M3Config.Get ("PKG_USE"); doc_root := M3Config.Get ("DOC_INSTALL"); initial_browser := M3Config.Get ("INITIAL_CM3_IDE_BROWSER"); initial_editor := M3Config.Get ("INITIAL_CM3_IDE_EDITOR"); What is happening on my installation is that PKG_USE winds up being "\..\PKG". This is not a valid path and it is causing all sorts of trouble for Reactor. The reason it is getting set this way is that the ELSE branch of the, if not defined("INSTALL_ROOT"), is getting executed resulting in INSTALL_ROOT=\.. I'm not sure why this is coded this way. How do you suggest this should be repaired? Note, I have not checked all of the cm3.cfg variants for the other target platforms, but in order for reactor to work properly, it must be able to find a valid "PKG_USE" in the cm3.cfg. Regards, Randy _________________________________________________________________ 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 neels at elego.de Fri Jan 25 01:45:22 2008 From: neels at elego.de (Neels Janosch Hofmeyr) Date: Fri, 25 Jan 2008 01:45:22 +0100 Subject: [M3devel] CM3 5.5.1 works on Ubuntu 7.10! Message-ID: <47993122.2030201@elego.de> Thanks Olaf, Tony, Mika and Jay, I have cm3 working on Ubuntu 7.10! Complete instructions are given in the attached file. After all, it _does_ look quite simple. But only once you know how. Please let me know if you have any improvements waiting. I'll check this file into the CVS somewhere. We need to add these instructions to modula3.elegosoft.com, so that others do not take the same "shortcuts" I did. If noone else feels like doing it, I will. But right now, it's way past bedtime. All the best, Neels -- Neels Janosch Hofmeyr Software Developer neels at elego.de Public Key: http://binarchy.net/neels/neels.hofmeyr.public.key.asc elego Software Solutions GmbH http://www.elegosoft.com Gustav-Meyer-Allee 25, Geb?ude 12 HRB 77719 13355 Berlin, Germany Amtsgericht Charlottenburg Tel.: +49 30 23 45 86 96 Sitz der Gesellschaft: Berlin Fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Olaf Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: install-cm3-on-ubuntu-7-10.txt Type: application/vnd.ms-powerpoint Size: 9673 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From neels at elego.de Fri Jan 25 01:55:36 2008 From: neels at elego.de (Neels Janosch Hofmeyr) Date: Fri, 25 Jan 2008 01:55:36 +0100 Subject: [M3devel] CM3 5.5.1 works on Ubuntu 7.10! In-Reply-To: <47993122.2030201@elego.de> References: <47993122.2030201@elego.de> Message-ID: <47993388.9030909@elego.de> Well, I've got a change myself. Some libfoo.a need to be libfoo.so for 5.5.1. Wow, does your mail client also think the attachment is a PowerPoint Document? Well, in fact it's a plain ASCII text file. Neels Janosch Hofmeyr wrote: > Thanks Olaf, Tony, Mika and Jay, I have cm3 working on Ubuntu 7.10! > Complete instructions are given in the attached file. After all, it > _does_ look quite simple. But only once you know how. Please let me > know if you have any improvements waiting. I'll check this file into > the CVS somewhere. > > We need to add these instructions to modula3.elegosoft.com, so that > others do not take the same "shortcuts" I did. If noone else feels > like doing it, I will. But right now, it's way past bedtime. > > All the best, > Neels > -- Neels Janosch Hofmeyr Software Developer neels at elego.de Public Key: http://binarchy.net/neels/neels.hofmeyr.public.key.asc elego Software Solutions GmbH http://www.elegosoft.com Gustav-Meyer-Allee 25, Geb?ude 12 HRB 77719 13355 Berlin, Germany Amtsgericht Charlottenburg Tel.: +49 30 23 45 86 96 Sitz der Gesellschaft: Berlin Fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Olaf Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: install-cm3-on-ubuntu-7-10.txt Type: application/vnd.ms-powerpoint Size: 9628 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From rcoleburn at scires.com Fri Jan 25 02:06:09 2008 From: rcoleburn at scires.com (Randy Coleburn) Date: Thu, 24 Jan 2008 20:06:09 -0500 Subject: [M3devel] INSTALL_ROOT and PKG_USE in cm3.cfg In-Reply-To: References: <4798DEB8.1E75.00D7.1@scires.com> Message-ID: <4798EFAE.1E75.00D7.1@scires.com> Jay: That's the reason I asked before making a change. I don't want to break or mess up what you are doing. I can get around the problem easily for me. I just remove the comment from the %INSTALL_ROOT="c:\\cm3" and "everything" is ok. I'm hoping we can come up with a way that works for everyone. Once the CM3_IDE (formerly known as Reactor) package is in the repository and part of the standard distribution, it would be best if folks don't have to go around editing cm3.cfg to make it work properly. Now, you are saying your way is more automatic and portable. I like these words. Is there a way we can set something in cm3.cfg that I can key off of for CM3_IDE/Reactor? I don't mind changing the code to accommodate. The big thing for CM3_IDE/Reactor, is that it needs to know where to look for the cm3 installation because it has to find all of the subdirs, like doc, examples, etc. BTW, I still don't see why all this "works" since I am getting "\.." as my INSTALL_ROOT. Regards, Randy >>> Jay 1/24/2008 7:24 PM >>> Blech. My way is more automatic and "portable" in the sense that you can move installations around and they keep working. As well, with my way, you just extract an archive and go, no setup/cminstall, no editing of the cm3.cfg file, just set %PATH% and run vcvars, and vcvars I think I can remove the need for. path() is a builtin Quake function that returns the directory of the currently being run Quake code. But yet Reactor. To unblock yourself, remove my code, add back the commented out, fix the path to match your particular install, don't submit the file. Perhaps move the current checked in file over to the config-no-install directory and then put config's file back in the old style, that requires running cminstall. My workflow will keep working, since it probes for config-no-install first. - Jay Date: Thu, 24 Jan 2008 18:53:48 -0500 From: rcoleburn at scires.com To: jay123 at hotmail.com CC: m3devel at elegosoft.com Subject: [M3devel] INSTALL_ROOT and PKG_USE in cm3.cfg Jay: The cm3.cfg that comes with your minimal binary installation on Windows (NT386) has the following lines: ----------------------------------------- % INSTALL_ROOT = BEGIN_CONFIG % "Where should CM3 be installed?" % 7 %-- user specified install root % END_CONFIG % INSTALL_ROOT = "c:\\cm3" if not defined("INSTALL_ROOT") if not equal ($INSTALLROOT, "") INSTALL_ROOT = $INSTALLROOT else INSTALL_ROOT = (path() & "\\..") end end BIN_INSTALL = INSTALL_ROOT & "\\bin" % executables LIB_INSTALL = INSTALL_ROOT & "\\lib" % libraries PKG_INSTALL = INSTALL_ROOT & "\\pkg" % packages DOC_INSTALL = INSTALL_ROOT & "\\doc" % documents EMACS_INSTALL = INSTALL_ROOT & "\\elisp" % emacs lisp code MAN_INSTALL = INSTALL_ROOT & "\\man" % man pages HTML_INSTALL = INSTALL_ROOT & "\\www" % public hypertext % % On some systems (e.g. AFS) you must install public files in a different % place from where you use them. If that is the case for your system, % specify the "use" location here, otherwise leave them alone. % %USE_ROOT = INSTALL_ROOT BIN_USE = BIN_INSTALL % executables LIB_USE = LIB_INSTALL % libraries PKG_USE = PKG_INSTALL % packages ----------------------------------------- Notice that the lines for INSTALL_ROOT and USE_ROOT are commented out. The Reactor program is coded to grab several variables out of cm3.cfg. For example, build_dir := M3Config.Get ("BUILD_DIR"); system_root := M3Config.Get ("PKG_USE"); doc_root := M3Config.Get ("DOC_INSTALL"); initial_browser := M3Config.Get ("INITIAL_CM3_IDE_BROWSER"); initial_editor := M3Config.Get ("INITIAL_CM3_IDE_EDITOR"); What is happening on my installation is that PKG_USE winds up being "\..\PKG". This is not a valid path and it is causing all sorts of trouble for Reactor. The reason it is getting set this way is that the ELSE branch of the, if not defined("INSTALL_ROOT"), is getting executed resulting in INSTALL_ROOT=\.. I'm not sure why this is coded this way. How do you suggest this should be repaired? Note, I have not checked all of the cm3.cfg variants for the other target platforms, but in order for reactor to work properly, it must be able to find a valid "PKG_USE" in the cm3.cfg. Regards, Randy 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 jayk123 at hotmail.com Fri Jan 25 02:33:40 2008 From: jayk123 at hotmail.com (Jay) Date: Fri, 25 Jan 2008 01:33:40 +0000 Subject: [M3devel] INSTALL_ROOT and PKG_USE in cm3.cfg In-Reply-To: <4798EFAE.1E75.00D7.1@scires.com> References: <4798DEB8.1E75.00D7.1@scires.com> <4798EFAE.1E75.00D7.1@scires.com> Message-ID: I'm not sure what versions of cm3 have path(). I did think I saw it missing the other day. That could be your problem.m3cgcat also doesn't like my config file, it wants to open it to find TARGET, not sure it uses it at all, but it wants it. When I run mcgcat, I first put back a TARGET line in my cm3.cfg. And then remove it. This is very related. I would suspect that whoever reads the files MIGHT find it acceptable to RUN them. Running them doesn't mean compiling or linking or anything, those are functions that the "host" would chose to call or not. But toplevel can have arbitrary code so maybe this is not great. Reactor is a persistant web server though, right? It should be ok "running" the file, esp. since it doesn't start often. The "normal" alternative that other folks use is to run cminstall, which I find all but useless. In terms of my workflow, you can go ahead and copy NT386 to the config-no-install directory. I'll survive. Randy you should try debugging stuff. Quake is readily debuggabe through printing. if defined("path") write("path is defined") write("path is " & path()) else write("path is not defined") end error("") I put in error so I stop after my printing and don't go and build stuff when my intent was just to run a snippet of Quake. - Jay Date: Thu, 24 Jan 2008 20:06:09 -0500From: rcoleburn at scires.comTo: jay123 at hotmail.com; jayk123 at hotmail.comCC: m3devel at elegosoft.comSubject: RE: [M3devel] INSTALL_ROOT and PKG_USE in cm3.cfg Jay: That's the reason I asked before making a change. I don't want to break or mess up what you are doing. I can get around the problem easily for me. I just remove the comment from the %INSTALL_ROOT="c:\\cm3" and "everything" is ok. I'm hoping we can come up with a way that works for everyone. Once the CM3_IDE (formerly known as Reactor) package is in the repository and part of the standard distribution, it would be best if folks don't have to go around editing cm3.cfg to make it work properly. Now, you are saying your way is more automatic and portable. I like these words. Is there a way we can set something in cm3.cfg that I can key off of for CM3_IDE/Reactor? I don't mind changing the code to accommodate. The big thing for CM3_IDE/Reactor, is that it needs to know where to look for the cm3 installation because it has to find all of the subdirs, like doc, examples, etc. BTW, I still don't see why all this "works" since I am getting "\.." as my INSTALL_ROOT. Regards, Randy>>> Jay 1/24/2008 7:24 PM >>>Blech. My way is more automatic and "portable" in the sense that you can move installations around and they keep working. As well, with my way, you just extract an archive and go, no setup/cminstall, no editing of the cm3.cfg file, just set %PATH% and run vcvars, and vcvars I think I can remove the need for. path() is a builtin Quake function that returns the directory of the currently being run Quake code. But yet Reactor.To unblock yourself, remove my code, add back the commented out, fix the path to match your particular install, don't submit the file. Perhaps move the current checked in file over to the config-no-install directory and then put config's file back in the old style, that requires running cminstall. My workflow will keep working, since it probes for config-no-install first. - Jay Date: Thu, 24 Jan 2008 18:53:48 -0500From: rcoleburn at scires.comTo: jay123 at hotmail.comCC: m3devel at elegosoft.comSubject: [M3devel] INSTALL_ROOT and PKG_USE in cm3.cfg Jay: The cm3.cfg that comes with your minimal binary installation on Windows (NT386) has the following lines: ----------------------------------------- % INSTALL_ROOT = BEGIN_CONFIG% "Where should CM3 be installed?"% 7 %-- user specified install root% END_CONFIG % INSTALL_ROOT = "c:\\cm3" if not defined("INSTALL_ROOT") if not equal ($INSTALLROOT, "") INSTALL_ROOT = $INSTALLROOT else INSTALL_ROOT = (path() & "\\..") endend BIN_INSTALL = INSTALL_ROOT & "\\bin" % executablesLIB_INSTALL = INSTALL_ROOT & "\\lib" % librariesPKG_INSTALL = INSTALL_ROOT & "\\pkg" % packagesDOC_INSTALL = INSTALL_ROOT & "\\doc" % documentsEMACS_INSTALL = INSTALL_ROOT & "\\elisp" % emacs lisp codeMAN_INSTALL = INSTALL_ROOT & "\\man" % man pagesHTML_INSTALL = INSTALL_ROOT & "\\www" % public hypertext %% On some systems (e.g. AFS) you must install public files in a different% place from where you use them. If that is the case for your system,% specify the "use" location here, otherwise leave them alone.%%USE_ROOT = INSTALL_ROOTBIN_USE = BIN_INSTALL % executablesLIB_USE = LIB_INSTALL % librariesPKG_USE = PKG_INSTALL % packages ----------------------------------------- Notice that the lines for INSTALL_ROOT and USE_ROOT are commented out. The Reactor program is coded to grab several variables out of cm3.cfg. For example, build_dir := M3Config.Get ("BUILD_DIR"); system_root := M3Config.Get ("PKG_USE"); doc_root := M3Config.Get ("DOC_INSTALL"); initial_browser := M3Config.Get ("INITIAL_CM3_IDE_BROWSER"); initial_editor := M3Config.Get ("INITIAL_CM3_IDE_EDITOR"); What is happening on my installation is that PKG_USE winds up being "\..\PKG". This is not a valid path and it is causing all sorts of trouble for Reactor. The reason it is getting set this way is that the ELSE branch of the, if not defined("INSTALL_ROOT"), is getting executed resulting in INSTALL_ROOT=\.. I'm not sure why this is coded this way. How do you suggest this should be repaired? Note, I have not checked all of the cm3.cfg variants for the other target platforms, but in order for reactor to work properly, it must be able to find a valid "PKG_USE" in the cm3.cfg. Regards, Randy 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 rodney.bates at wichita.edu Fri Jan 25 02:33:15 2008 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Thu, 24 Jan 2008 19:33:15 -0600 Subject: [M3devel] SIG64 from gdb (was still errors with cm3-min-POSIX-LINUXLIBC6-d5.5.1-2008-01-24-03-35-01) In-Reply-To: <47991443.2050809@elego.de> References: <47991443.2050809@elego.de> Message-ID: <47993C5B.8020505@wichita.edu> See embedded comments at end: Neels Janosch Hofmeyr wrote: > Using the > cm3-min-POSIX-LINUXLIBC6-d5.5.1-2008-01-24-03-35-01.tgz > in conjunction with the 5.4.0 source tarballs, I get, : > ... snip ... > $ cm3 -version > Critical Mass Modula-3 version d5.5.1-2008-01-24-03-35-01 > last updated: 2007-12-30 > compiled: 2008-01-24 03:54:37 > configuration: /usr/local/cm3/bin/cm3.cfg > (gdb) c > Continuing. > > Program received signal SIG64, Real-time event 64. > 0xffffe410 in __kernel_vsyscall () > (gdb) c > Continuing. > --- building in LINUXLIBC6 --- > > ignoring ../src/m3overrides > > > Program received signal SIG64, Real-time event 64. > 0xffffe410 in __kernel_vsyscall () > (gdb) c > Continuing. This is secondary to the original problem, but the SIG64 stops are false stops in gdb. In the phtreads implementation, SIG64 is used internally as a normal event, and you don't want gdb to stop there. (Unless, maybe, you're debugging the use of SIG64 :-) ) To prevent this happening in gdb, type: handle SIG64 nostop noprint pass I checked in an update to m3gdb around Oct. 8, that makes m3gdb adopt this behavior by default, when debugging a program that uses pthreads. From the checkin log text: 6) When PThreads are used, automatically set m3gdb to silently pass SIG64 to the program. Otherwise, this also would cause false stops. -- ------------------------------------------------------------- Rodney 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 Fri Jan 25 03:07:29 2008 From: rcoleburn at scires.com (Randy Coleburn) Date: Thu, 24 Jan 2008 21:07:29 -0500 Subject: [M3devel] INSTALL_ROOT and PKG_USE in cm3.cfg In-Reply-To: References: <4798DEB8.1E75.00D7.1@scires.com> <4798EFAE.1E75.00D7.1@scires.com> Message-ID: <4798FE0E.1E75.00D7.1@scires.com> Jay: Not sure exactly what you mean by: >I'm not sure what versions of cm3 have path(). I did think I saw it missing the other day. I assume you are not referring to the path env variable. Is this some built-in quake function or a function you have written in quake? The version of cm3.cfg that I am using is the one that *you* put in the minimal binary installation for windows. Reactor does indeed "run" the cm3.cfg in that it uses quake to load and interpret this file. What is the significance of doing the copy you suggest below? >In terms of my workflow, you can go ahead and copy NT386 to the config-no-install directory. I'll survive. I'm not trying to be obtuse here. It's just that you have been working on the windows distribution and all these scripts etc for a while now. I don't want to mess up anything you are doing and I know I don't have a deep understanding of all this, so I am reluctant to change anything like cm3.cfg for my needs. My goal is to make the CM3-IDE (old Reactor) available to everyone. As I said before, it does "run" the cm3.cfg and it needs to use this somehow to come up with a valid "PKG_USE" which should point to the "pkg" folder inside the cm3 installation root. Regards, Randy >>> Jay 1/24/2008 8:33 PM >>> I'm not sure what versions of cm3 have path(). I did think I saw it missing the other day. That could be your problem. m3cgcat also doesn't like my config file, it wants to open it to find TARGET, not sure it uses it at all, but it wants it. When I run mcgcat, I first put back a TARGET line in my cm3.cfg. And then remove it. This is very related. I would suspect that whoever reads the files MIGHT find it acceptable to RUN them. Running them doesn't mean compiling or linking or anything, those are functions that the "host" would chose to call or not. But toplevel can have arbitrary code so maybe this is not great. Reactor is a persistant web server though, right? It should be ok "running" the file, esp. since it doesn't start often. The "normal" alternative that other folks use is to run cminstall, which I find all but useless. In terms of my workflow, you can go ahead and copy NT386 to the config-no-install directory. I'll survive. Randy you should try debugging stuff. Quake is readily debuggabe through printing. if defined("path") write("path is defined") write("path is " & path()) else write("path is not defined") end error("") I put in error so I stop after my printing and don't go and build stuff when my intent was just to run a snippet of Quake. - Jay Date: Thu, 24 Jan 2008 20:06:09 -0500 From: rcoleburn at scires.com To: jay123 at hotmail.com; jayk123 at hotmail.com CC: m3devel at elegosoft.com Subject: RE: [M3devel] INSTALL_ROOT and PKG_USE in cm3.cfg Jay: That's the reason I asked before making a change. I don't want to break or mess up what you are doing. I can get around the problem easily for me. I just remove the comment from the %INSTALL_ROOT="c:\\cm3" and "everything" is ok. I'm hoping we can come up with a way that works for everyone. Once the CM3_IDE (formerly known as Reactor) package is in the repository and part of the standard distribution, it would be best if folks don't have to go around editing cm3.cfg to make it work properly. Now, you are saying your way is more automatic and portable. I like these words. Is there a way we can set something in cm3.cfg that I can key off of for CM3_IDE/Reactor? I don't mind changing the code to accommodate. The big thing for CM3_IDE/Reactor, is that it needs to know where to look for the cm3 installation because it has to find all of the subdirs, like doc, examples, etc. BTW, I still don't see why all this "works" since I am getting "\.." as my INSTALL_ROOT. Regards, Randy >>> Jay 1/24/2008 7:24 PM >>> Blech. My way is more automatic and "portable" in the sense that you can move installations around and they keep working. As well, with my way, you just extract an archive and go, no setup/cminstall, no editing of the cm3.cfg file, just set %PATH% and run vcvars, and vcvars I think I can remove the need for. path() is a builtin Quake function that returns the directory of the currently being run Quake code. But yet Reactor. To unblock yourself, remove my code, add back the commented out, fix the path to match your particular install, don't submit the file. Perhaps move the current checked in file over to the config-no-install directory and then put config's file back in the old style, that requires running cminstall. My workflow will keep working, since it probes for config-no-install first. - Jay Date: Thu, 24 Jan 2008 18:53:48 -0500 From: rcoleburn at scires.com To: jay123 at hotmail.com CC: m3devel at elegosoft.com Subject: [M3devel] INSTALL_ROOT and PKG_USE in cm3.cfg Jay: The cm3.cfg that comes with your minimal binary installation on Windows (NT386) has the following lines: ----------------------------------------- % INSTALL_ROOT = BEGIN_CONFIG % "Where should CM3 be installed?" % 7 %-- user specified install root % END_CONFIG % INSTALL_ROOT = "c:\\cm3" if not defined("INSTALL_ROOT") if not equal ($INSTALLROOT, "") INSTALL_ROOT = $INSTALLROOT else INSTALL_ROOT = (path() & "\\..") end end BIN_INSTALL = INSTALL_ROOT & "\\bin" % executables LIB_INSTALL = INSTALL_ROOT & "\\lib" % libraries PKG_INSTALL = INSTALL_ROOT & "\\pkg" % packages DOC_INSTALL = INSTALL_ROOT & "\\doc" % documents EMACS_INSTALL = INSTALL_ROOT & "\\elisp" % emacs lisp code MAN_INSTALL = INSTALL_ROOT & "\\man" % man pages HTML_INSTALL = INSTALL_ROOT & "\\www" % public hypertext % % On some systems (e.g. AFS) you must install public files in a different % place from where you use them. If that is the case for your system, % specify the "use" location here, otherwise leave them alone. % %USE_ROOT = INSTALL_ROOT BIN_USE = BIN_INSTALL % executables LIB_USE = LIB_INSTALL % libraries PKG_USE = PKG_INSTALL % packages ----------------------------------------- Notice that the lines for INSTALL_ROOT and USE_ROOT are commented out. The Reactor program is coded to grab several variables out of cm3.cfg. For example, build_dir := M3Config.Get ("BUILD_DIR"); system_root := M3Config.Get ("PKG_USE"); doc_root := M3Config.Get ("DOC_INSTALL"); initial_browser := M3Config.Get ("INITIAL_CM3_IDE_BROWSER"); initial_editor := M3Config.Get ("INITIAL_CM3_IDE_EDITOR"); What is happening on my installation is that PKG_USE winds up being "\..\PKG". This is not a valid path and it is causing all sorts of trouble for Reactor. The reason it is getting set this way is that the ELSE branch of the, if not defined("INSTALL_ROOT"), is getting executed resulting in INSTALL_ROOT=\.. I'm not sure why this is coded this way. How do you suggest this should be repaired? Note, I have not checked all of the cm3.cfg variants for the other target platforms, but in order for reactor to work properly, it must be able to find a valid "PKG_USE" in the cm3.cfg. Regards, Randy 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 ) 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 jayk123 at hotmail.com Fri Jan 25 03:23:51 2008 From: jayk123 at hotmail.com (Jay) Date: Fri, 25 Jan 2008 02:23:51 +0000 Subject: [M3devel] INSTALL_ROOT and PKG_USE in cm3.cfg In-Reply-To: <4798FE0E.1E75.00D7.1@scires.com> References: <4798DEB8.1E75.00D7.1@scires.com> <4798EFAE.1E75.00D7.1@scires.com> <4798FE0E.1E75.00D7.1@scires.com> Message-ID: Randy, don't worry, whatever you do, I'll be able to recover from. Just try editing your \cm3\bin\cm3.cfg file to say INSTALLROOT="c:\cm3" or whatever. Remove the path() function as a variable. See what happens. Maybe it's the problem, maybe not. It is something that I changed, and is worth trying the old way. Use write() and error() to print the other variables. Can you make the stuff you are working on available? To just some people? - Jay Date: Thu, 24 Jan 2008 21:07:29 -0500From: rcoleburn at scires.comTo: jay123 at hotmail.com; jayk123 at hotmail.comCC: m3devel at elegosoft.comSubject: Re: [M3devel] INSTALL_ROOT and PKG_USE in cm3.cfg Jay: Not sure exactly what you mean by:>I'm not sure what versions of cm3 have path(). I did think I saw it missing the other day. I assume you are not referring to the path env variable. Is this some built-in quake function or a function you have written in quake? The version of cm3.cfg that I am using is the one that *you* put in the minimal binary installation for windows. Reactor does indeed "run" the cm3.cfg in that it uses quake to load and interpret this file. What is the significance of doing the copy you suggest below? >In terms of my workflow, you can go ahead and copy NT386 to the config-no-install directory. I'll survive. I'm not trying to be obtuse here. It's just that you have been working on the windows distribution and all these scripts etc for a while now. I don't want to mess up anything you are doing and I know I don't have a deep understanding of all this, so I am reluctant to change anything like cm3.cfg for my needs. My goal is to make the CM3-IDE (old Reactor) available to everyone. As I said before, it does "run" the cm3.cfg and it needs to use this somehow to come up with a valid "PKG_USE" which should point to the "pkg" folder inside the cm3 installation root. Regards, Randy >>> Jay 1/24/2008 8:33 PM >>>I'm not sure what versions of cm3 have path(). I did think I saw it missing the other day.That could be your problem.m3cgcat also doesn't like my config file, it wants to open it to find TARGET, not sure it uses it at all, but it wants it. When I run mcgcat, I first put back a TARGET line in my cm3.cfg. And then remove it.This is very related.I would suspect that whoever reads the files MIGHT find it acceptable to RUN them.Running them doesn't mean compiling or linking or anything, those are functions that the "host" would chose to call or not. But toplevel can have arbitrary code so maybe this is not great. Reactor is a persistant web server though, right? It should be ok "running" the file, esp. since it doesn't start often. The "normal" alternative that other folks use is to run cminstall, which I find all but useless. In terms of my workflow, you can go ahead and copy NT386 to the config-no-install directory. I'll survive. Randy you should try debugging stuff. Quake is readily debuggabe through printing. if defined("path") write("path is defined") write("path is " & path())else write("path is not defined")enderror("") I put in error so I stop after my printing and don't go and build stuff when my intent was just to run a snippet of Quake. - Jay Date: Thu, 24 Jan 2008 20:06:09 -0500From: rcoleburn at scires.comTo: jay123 at hotmail.com; jayk123 at hotmail.comCC: m3devel at elegosoft.comSubject: RE: [M3devel] INSTALL_ROOT and PKG_USE in cm3.cfg Jay: That's the reason I asked before making a change. I don't want to break or mess up what you are doing. I can get around the problem easily for me. I just remove the comment from the %INSTALL_ROOT="c:\\cm3" and "everything" is ok. I'm hoping we can come up with a way that works for everyone. Once the CM3_IDE (formerly known as Reactor) package is in the repository and part of the standard distribution, it would be best if folks don't have to go around editing cm3.cfg to make it work properly. Now, you are saying your way is more automatic and portable. I like these words. Is there a way we can set something in cm3.cfg that I can key off of for CM3_IDE/Reactor? I don't mind changing the code to accommodate. The big thing for CM3_IDE/Reactor, is that it needs to know where to look for the cm3 installation because it has to find all of the subdirs, like doc, examples, etc. BTW, I still don't see why all this "works" since I am getting "\.." as my INSTALL_ROOT. Regards, Randy>>> Jay 1/24/2008 7:24 PM >>>Blech. My way is more automatic and "portable" in the sense that you can move installations around and they keep working. As well, with my way, you just extract an archive and go, no setup/cminstall, no editing of the cm3.cfg file, just set %PATH% and run vcvars, and vcvars I think I can remove the need for. path() is a builtin Quake function that returns the directory of the currently being run Quake code. But yet Reactor.To unblock yourself, remove my code, add back the commented out, fix the path to match your particular install, don't submit the file. Perhaps move the current checked in file over to the config-no-install directory and then put config's file back in the old style, that requires running cminstall. My workflow will keep working, since it probes for config-no-install first. - Jay Date: Thu, 24 Jan 2008 18:53:48 -0500From: rcoleburn at scires.comTo: jay123 at hotmail.comCC: m3devel at elegosoft.comSubject: [M3devel] INSTALL_ROOT and PKG_USE in cm3.cfg Jay: The cm3.cfg that comes with your minimal binary installation on Windows (NT386) has the following lines: ----------------------------------------- % INSTALL_ROOT = BEGIN_CONFIG% "Where should CM3 be installed?"% 7 %-- user specified install root% END_CONFIG % INSTALL_ROOT = "c:\\cm3" if not defined("INSTALL_ROOT") if not equal ($INSTALLROOT, "") INSTALL_ROOT = $INSTALLROOT else INSTALL_ROOT = (path() & "\\..") endend BIN_INSTALL = INSTALL_ROOT & "\\bin" % executablesLIB_INSTALL = INSTALL_ROOT & "\\lib" % librariesPKG_INSTALL = INSTALL_ROOT & "\\pkg" % packagesDOC_INSTALL = INSTALL_ROOT & "\\doc" % documentsEMACS_INSTALL = INSTALL_ROOT & "\\elisp" % emacs lisp codeMAN_INSTALL = INSTALL_ROOT & "\\man" % man pagesHTML_INSTALL = INSTALL_ROOT & "\\www" % public hypertext %% On some systems (e.g. AFS) you must install public files in a different% place from where you use them. If that is the case for your system,% specify the "use" location here, otherwise leave them alone.%%USE_ROOT = INSTALL_ROOTBIN_USE = BIN_INSTALL % executablesLIB_USE = LIB_INSTALL % librariesPKG_USE = PKG_INSTALL % packages ----------------------------------------- Notice that the lines for INSTALL_ROOT and USE_ROOT are commented out. The Reactor program is coded to grab several variables out of cm3.cfg. For example, build_dir := M3Config.Get ("BUILD_DIR"); system_root := M3Config.Get ("PKG_USE"); doc_root := M3Config.Get ("DOC_INSTALL"); initial_browser := M3Config.Get ("INITIAL_CM3_IDE_BROWSER"); initial_editor := M3Config.Get ("INITIAL_CM3_IDE_EDITOR"); What is happening on my installation is that PKG_USE winds up being "\..\PKG". This is not a valid path and it is causing all sorts of trouble for Reactor. The reason it is getting set this way is that the ELSE branch of the, if not defined("INSTALL_ROOT"), is getting executed resulting in INSTALL_ROOT=\.. I'm not sure why this is coded this way. How do you suggest this should be repaired? Note, I have not checked all of the cm3.cfg variants for the other target platforms, but in order for reactor to work properly, it must be able to find a valid "PKG_USE" in the cm3.cfg. Regards, Randy 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. 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 rcoleburn at scires.com Fri Jan 25 03:48:28 2008 From: rcoleburn at scires.com (Randy Coleburn) Date: Thu, 24 Jan 2008 21:48:28 -0500 Subject: [M3devel] INSTALL_ROOT and PKG_USE in cm3.cfg In-Reply-To: References: <4798DEB8.1E75.00D7.1@scires.com> <4798EFAE.1E75.00D7.1@scires.com> <4798FE0E.1E75.00D7.1@scires.com> Message-ID: <479907A8.1E75.00D7.1@scires.com> Jay: I've already edited my version of cm3.cfg to make it work for me. I don't know what the path() function does. The path() function is only used in the following code: if not defined("INSTALL_ROOT") if not equal ($INSTALLROOT, "") INSTALL_ROOT = $INSTALLROOT else INSTALL_ROOT = (path() & "\\..") end end Since this code is not executed when I define INSTALL_ROOT as "c:\\cm3", there is no need to remove it for my use. I've already confirmed that the other variables I need get set correctly inside CM3-IDE/Reactor once the INSTALL_ROOT is set properly. Note that a bunch of variables inside cm3.cfg depend on INSTALL_ROOT. I'm still want to find a solution for the general user population. Regards, Randy >>> Jay 1/24/2008 9:23 PM >>> Randy, don't worry, whatever you do, I'll be able to recover from. Just try editing your \cm3\bin\cm3.cfg file to say INSTALLROOT="c:\cm3" or whatever. Remove the path() function as a variable. See what happens. Maybe it's the problem, maybe not. It is something that I changed, and is worth trying the old way. Use write() and error() to print the other variables. Can you make the stuff you are working on available? To just some people? - Jay Date: Thu, 24 Jan 2008 21:07:29 -0500 From: rcoleburn at scires.com To: jay123 at hotmail.com; jayk123 at hotmail.com CC: m3devel at elegosoft.com Subject: Re: [M3devel] INSTALL_ROOT and PKG_USE in cm3.cfg Jay: Not sure exactly what you mean by: >I'm not sure what versions of cm3 have path(). I did think I saw it missing the other day. I assume you are not referring to the path env variable. Is this some built-in quake function or a function you have written in quake? The version of cm3.cfg that I am using is the one that *you* put in the minimal binary installation for windows. Reactor does indeed "run" the cm3.cfg in that it uses quake to load and interpret this file. What is the significance of doing the copy you suggest below? >In terms of my workflow, you can go ahead and copy NT386 to the config-no-install directory. I'll survive. I'm not trying to be obtuse here. It's just that you have been working on the windows distribution and all these scripts etc for a while now. I don't want to mess up anything you are doing and I know I don't have a deep understanding of all this, so I am reluctant to change anything like cm3.cfg for my needs. My goal is to make the CM3-IDE (old Reactor) available to everyone. As I said before, it does "run" the cm3.cfg and it needs to use this somehow to come up with a valid "PKG_USE" which should point to the "pkg" folder inside the cm3 installation root. Regards, Randy >>> Jay 1/24/2008 8:33 PM >>> I'm not sure what versions of cm3 have path(). I did think I saw it missing the other day. That could be your problem. m3cgcat also doesn't like my config file, it wants to open it to find TARGET, not sure it uses it at all, but it wants it. When I run mcgcat, I first put back a TARGET line in my cm3.cfg. And then remove it. This is very related. I would suspect that whoever reads the files MIGHT find it acceptable to RUN them. Running them doesn't mean compiling or linking or anything, those are functions that the "host" would chose to call or not. But toplevel can have arbitrary code so maybe this is not great. Reactor is a persistant web server though, right? It should be ok "running" the file, esp. since it doesn't start often. The "normal" alternative that other folks use is to run cminstall, which I find all but useless. In terms of my workflow, you can go ahead and copy NT386 to the config-no-install directory. I'll survive. Randy you should try debugging stuff. Quake is readily debuggabe through printing. if defined("path") write("path is defined") write("path is " & path()) else write("path is not defined") end error("") I put in error so I stop after my printing and don't go and build stuff when my intent was just to run a snippet of Quake. - Jay Date: Thu, 24 Jan 2008 20:06:09 -0500 From: rcoleburn at scires.com To: jay123 at hotmail.com; jayk123 at hotmail.com CC: m3devel at elegosoft.com Subject: RE: [M3devel] INSTALL_ROOT and PKG_USE in cm3.cfg Jay: That's the reason I asked before making a change. I don't want to break or mess up what you are doing. I can get around the problem easily for me. I just remove the comment from the %INSTALL_ROOT="c:\\cm3" and "everything" is ok. I'm hoping we can come up with a way that works for everyone. Once the CM3_IDE (formerly known as Reactor) package is in the repository and part of the standard distribution, it would be best if folks don't have to go around editing cm3.cfg to make it work properly. Now, you are saying your way is more automatic and portable. I like these words. Is there a way we can set something in cm3.cfg that I can key off of for CM3_IDE/Reactor? I don't mind changing the code to accommodate. The big thing for CM3_IDE/Reactor, is that it needs to know where to look for the cm3 installation because it has to find all of the subdirs, like doc, examples, etc. BTW, I still don't see why all this "works" since I am getting "\.." as my INSTALL_ROOT. Regards, Randy >>> Jay 1/24/2008 7:24 PM >>> Blech. My way is more automatic and "portable" in the sense that you can move installations around and they keep working. As well, with my way, you just extract an archive and go, no setup/cminstall, no editing of the cm3.cfg file, just set %PATH% and run vcvars, and vcvars I think I can remove the need for. path() is a builtin Quake function that returns the directory of the currently being run Quake code. But yet Reactor. To unblock yourself, remove my code, add back the commented out, fix the path to match your particular install, don't submit the file. Perhaps move the current checked in file over to the config-no-install directory and then put config's file back in the old style, that requires running cminstall. My workflow will keep working, since it probes for config-no-install first. - Jay Date: Thu, 24 Jan 2008 18:53:48 -0500 From: rcoleburn at scires.com To: jay123 at hotmail.com CC: m3devel at elegosoft.com Subject: [M3devel] INSTALL_ROOT and PKG_USE in cm3.cfg Jay: The cm3.cfg that comes with your minimal binary installation on Windows (NT386) has the following lines: ----------------------------------------- % INSTALL_ROOT = BEGIN_CONFIG % "Where should CM3 be installed?" % 7 %-- user specified install root % END_CONFIG % INSTALL_ROOT = "c:\\cm3" if not defined("INSTALL_ROOT") if not equal ($INSTALLROOT, "") INSTALL_ROOT = $INSTALLROOT else INSTALL_ROOT = (path() & "\\..") end end BIN_INSTALL = INSTALL_ROOT & "\\bin" % executables LIB_INSTALL = INSTALL_ROOT & "\\lib" % libraries PKG_INSTALL = INSTALL_ROOT & "\\pkg" % packages DOC_INSTALL = INSTALL_ROOT & "\\doc" % documents EMACS_INSTALL = INSTALL_ROOT & "\\elisp" % emacs lisp code MAN_INSTALL = INSTALL_ROOT & "\\man" % man pages HTML_INSTALL = INSTALL_ROOT & "\\www" % public hypertext % % On some systems (e.g. AFS) you must install public files in a different % place from where you use them. If that is the case for your system, % specify the "use" location here, otherwise leave them alone. % %USE_ROOT = INSTALL_ROOT BIN_USE = BIN_INSTALL % executables LIB_USE = LIB_INSTALL % libraries PKG_USE = PKG_INSTALL % packages ----------------------------------------- Notice that the lines for INSTALL_ROOT and USE_ROOT are commented out. The Reactor program is coded to grab several variables out of cm3.cfg. For example, build_dir := M3Config.Get ("BUILD_DIR"); system_root := M3Config.Get ("PKG_USE"); doc_root := M3Config.Get ("DOC_INSTALL"); initial_browser := M3Config.Get ("INITIAL_CM3_IDE_BROWSER"); initial_editor := M3Config.Get ("INITIAL_CM3_IDE_EDITOR"); What is happening on my installation is that PKG_USE winds up being "\..\PKG". This is not a valid path and it is causing all sorts of trouble for Reactor. The reason it is getting set this way is that the ELSE branch of the, if not defined("INSTALL_ROOT"), is getting executed resulting in INSTALL_ROOT=\.. I'm not sure why this is coded this way. How do you suggest this should be repaired? Note, I have not checked all of the cm3.cfg variants for the other target platforms, but in order for reactor to work properly, it must be able to find a valid "PKG_USE" in the cm3.cfg. Regards, Randy 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 ) 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 ) 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 ) -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcoleburn at scires.com Fri Jan 25 06:07:28 2008 From: rcoleburn at scires.com (Randy Coleburn) Date: Fri, 25 Jan 2008 00:07:28 -0500 Subject: [M3devel] INSTALL_ROOT and PKG_USE in cm3.cfg In-Reply-To: References: <4798DEB8.1E75.00D7.1@scires.com> <4798EFAE.1E75.00D7.1@scires.com> <4798FE0E.1E75.00D7.1@scires.com> <479907A8.1E75.00D7.1@scires.com> Message-ID: <4799283C.1E75.00D7.1@scires.com> Jay: Based on your description of path(), I don't think it is working correctly. My INSTALL_ROOT is turning up as "\.." instead of "C:\cm3\bin\.." If this path() function worked as advertised, I think your solution might work. Reactor/CM3-IDE is running from C:\cm3\bin, so when it uses quake to evaluate cm3.cfg, shouldn't it come up with "C:\cm3\bin\.." for the path? Maybe it does, and if so, then the ".." in the path may be confusing internally when it tries to make paths like "C:\cm3\bin\..\pkg". I don't know. Just a thought. Regards, Randy >>> Jay 1/24/2008 11:44 PM >>> 1) the general user population could revert back to cminstall; nobody else complained except me (a common occurence), and Olaf did improve it; I'd have to deign to putting together such a distribution yuck. Perhaps when a nice GUI installer comes along it won't feel so bad. 2) Again, can you make the stuff you are working on available? To just some people? path() returns the directory of the currently executing Quake code. And in this case, the file is in the directory that contains cm3.exe, so it is cm3.exe's directory, which we know is INSTALLROOT\bin, so go up one with .. and we have INSTALLROOT. It's a little unsightly to have ".." in all the resulting paths, but I think it is worth it. It could be fixed in a number of ways. 1) add a function PathDotDot or PathUp to cm3 2) more generally add a function PathCanonicalize to cm3. Or heck, move more and more of this stuff into cm3. I asked about this recently -- what are the requirements for compatibility with older tools. It is that unanswered, and presuming "the worst", besides my persistant distaste for Modula-3, that keeps me writing Quake code.. - Jay Date: Thu, 24 Jan 2008 21:48:28 -0500 From: rcoleburn at scires.com To: jay123 at hotmail.com; jayk123 at hotmail.com CC: m3devel at elegosoft.com Subject: Re: [M3devel] INSTALL_ROOT and PKG_USE in cm3.cfg Jay: I've already edited my version of cm3.cfg to make it work for me. I don't know what the path() function does. The path() function is only used in the following code: if not defined("INSTALL_ROOT") if not equal ($INSTALLROOT, "") INSTALL_ROOT = $INSTALLROOT else INSTALL_ROOT = (path() & "\\..") end end Since this code is not executed when I define INSTALL_ROOT as "c:\\cm3", there is no need to remove it for my use. I've already confirmed that the other variables I need get set correctly inside CM3-IDE/Reactor once the INSTALL_ROOT is set properly. Note that a bunch of variables inside cm3.cfg depend on INSTALL_ROOT. I'm still want to find a solution for the general user population. Regards, Randy >>> Jay 1/24/2008 9:23 PM >>> Randy, don't worry, whatever you do, I'll be able to recover from. Just try editing your \cm3\bin\cm3.cfg file to say INSTALLROOT="c:\cm3" or whatever. Remove the path() function as a variable. See what happens. Maybe it's the problem, maybe not. It is something that I changed, and is worth trying the old way. Use write() and error() to print the other variables. Can you make the stuff you are working on available? To just some people? - Jay Date: Thu, 24 Jan 2008 21:07:29 -0500 From: rcoleburn at scires.com To: jay123 at hotmail.com; jayk123 at hotmail.com CC: m3devel at elegosoft.com Subject: Re: [M3devel] INSTALL_ROOT and PKG_USE in cm3.cfg Jay: Not sure exactly what you mean by: >I'm not sure what versions of cm3 have path(). I did think I saw it missing the other day. I assume you are not referring to the path env variable. Is this some built-in quake function or a function you have written in quake? The version of cm3.cfg that I am using is the one that *you* put in the minimal binary installation for windows. Reactor does indeed "run" the cm3.cfg in that it uses quake to load and interpret this file. What is the significance of doing the copy you suggest below? >In terms of my workflow, you can go ahead and copy NT386 to the config-no-install directory. I'll survive. I'm not trying to be obtuse here. It's just that you have been working on the windows distribution and all these scripts etc for a while now. I don't want to mess up anything you are doing and I know I don't have a deep understanding of all this, so I am reluctant to change anything like cm3.cfg for my needs. My goal is to make the CM3-IDE (old Reactor) available to everyone. As I said before, it does "run" the cm3.cfg and it needs to use this somehow to come up with a valid "PKG_USE" which should point to the "pkg" folder inside the cm3 installation root. Regards, Randy >>> Jay 1/24/2008 8:33 PM >>> I'm not sure what versions of cm3 have path(). I did think I saw it missing the other day. That could be your problem. m3cgcat also doesn't like my config file, it wants to open it to find TARGET, not sure it uses it at all, but it wants it. When I run mcgcat, I first put back a TARGET line in my cm3.cfg. And then remove it. This is very related. I would suspect that whoever reads the files MIGHT find it acceptable to RUN them. Running them doesn't mean compiling or linking or anything, those are functions that the "host" would chose to call or not. But toplevel can have arbitrary code so maybe this is not great. Reactor is a persistant web server though, right? It should be ok "running" the file, esp. since it doesn't start often. The "normal" alternative that other folks use is to run cminstall, which I find all but useless. In terms of my workflow, you can go ahead and copy NT386 to the config-no-install directory. I'll survive. Randy you should try debugging stuff. Quake is readily debuggabe through printing. if defined("path") write("path is defined") write("path is " & path()) else write("path is not defined") end error("") I put in error so I stop after my printing and don't go and build stuff when my intent was just to run a snippet of Quake. - Jay Date: Thu, 24 Jan 2008 20:06:09 -0500 From: rcoleburn at scires.com To: jay123 at hotmail.com; jayk123 at hotmail.com CC: m3devel at elegosoft.com Subject: RE: [M3devel] INSTALL_ROOT and PKG_USE in cm3.cfg Jay: That's the reason I asked before making a change. I don't want to break or mess up what you are doing. I can get around the problem easily for me. I just remove the comment from the %INSTALL_ROOT="c:\\cm3" and "everything" is ok. I'm hoping we can come up with a way that works for everyone. Once the CM3_IDE (formerly known as Reactor) package is in the repository and part of the standard distribution, it would be best if folks don't have to go around editing cm3.cfg to make it work properly. Now, you are saying your way is more automatic and portable. I like these words. Is there a way we can set something in cm3.cfg that I can key off of for CM3_IDE/Reactor? I don't mind changing the code to accommodate. The big thing for CM3_IDE/Reactor, is that it needs to know where to look for the cm3 installation because it has to find all of the subdirs, like doc, examples, etc. BTW, I still don't see why all this "works" since I am getting "\.." as my INSTALL_ROOT. Regards, Randy >>> Jay 1/24/2008 7:24 PM >>> Blech. My way is more automatic and "portable" in the sense that you can move installations around and they keep working. As well, with my way, you just extract an archive and go, no setup/cminstall, no editing of the cm3.cfg file, just set %PATH% and run vcvars, and vcvars I think I can remove the need for. path() is a builtin Quake function that returns the directory of the currently being run Quake code. But yet Reactor. To unblock yourself, remove my code, add back the commented out, fix the path to match your particular install, don't submit the file. Perhaps move the current checked in file over to the config-no-install directory and then put config's file back in the old style, that requires running cminstall. My workflow will keep working, since it probes for config-no-install first. - Jay Date: Thu, 24 Jan 2008 18:53:48 -0500 From: rcoleburn at scires.com To: jay123 at hotmail.com CC: m3devel at elegosoft.com Subject: [M3devel] INSTALL_ROOT and PKG_USE in cm3.cfg Jay: The cm3.cfg that comes with your minimal binary installation on Windows (NT386) has the following lines: ----------------------------------------- % INSTALL_ROOT = BEGIN_CONFIG % "Where should CM3 be installed?" % 7 %-- user specified install root % END_CONFIG % INSTALL_ROOT = "c:\\cm3" if not defined("INSTALL_ROOT") if not equal ($INSTALLROOT, "") INSTALL_ROOT = $INSTALLROOT else INSTALL_ROOT = (path() & "\\..") end end BIN_INSTALL = INSTALL_ROOT & "\\bin" % executables LIB_INSTALL = INSTALL_ROOT & "\\lib" % libraries PKG_INSTALL = INSTALL_ROOT & "\\pkg" % packages DOC_INSTALL = INSTALL_ROOT & "\\doc" % documents EMACS_INSTALL = INSTALL_ROOT & "\\elisp" % emacs lisp code MAN_INSTALL = INSTALL_ROOT & "\\man" % man pages HTML_INSTALL = INSTALL_ROOT & "\\www" % public hypertext % % On some systems (e.g. AFS) you must install public files in a different % place from where you use them. If that is the case for your system, % specify the "use" location here, otherwise leave them alone. % %USE_ROOT = INSTALL_ROOT BIN_USE = BIN_INSTALL % executables LIB_USE = LIB_INSTALL % libraries PKG_USE = PKG_INSTALL % packages ----------------------------------------- Notice that the lines for INSTALL_ROOT and USE_ROOT are commented out. The Reactor program is coded to grab several variables out of cm3.cfg. For example, build_dir := M3Config.Get ("BUILD_DIR"); system_root := M3Config.Get ("PKG_USE"); doc_root := M3Config.Get ("DOC_INSTALL"); initial_browser := M3Config.Get ("INITIAL_CM3_IDE_BROWSER"); initial_editor := M3Config.Get ("INITIAL_CM3_IDE_EDITOR"); What is happening on my installation is that PKG_USE winds up being "\..\PKG". This is not a valid path and it is causing all sorts of trouble for Reactor. The reason it is getting set this way is that the ELSE branch of the, if not defined("INSTALL_ROOT"), is getting executed resulting in INSTALL_ROOT=\.. I'm not sure why this is coded this way. How do you suggest this should be repaired? Note, I have not checked all of the cm3.cfg variants for the other target platforms, but in order for reactor to work properly, it must be able to find a valid "PKG_USE" in the cm3.cfg. Regards, Randy 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 ) 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 ) 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 ) 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 ) -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Fri Jan 25 06:19:31 2008 From: jayk123 at hotmail.com (Jay) Date: Fri, 25 Jan 2008 05:19:31 +0000 Subject: [M3devel] INSTALL_ROOT and PKG_USE in cm3.cfg In-Reply-To: <4799283C.1E75.00D7.1@scires.com> References: <4798DEB8.1E75.00D7.1@scires.com> <4798EFAE.1E75.00D7.1@scires.com> <4798FE0E.1E75.00D7.1@scires.com> <479907A8.1E75.00D7.1@scires.com> <4799283C.1E75.00D7.1@scires.com> Message-ID: >> shouldn't it come up with "C:\cm3\bin\.." for the path? Correct. >> be confusing internally when it tries to make paths like "C:\cm3\bin\..\pkg". I don't know. Just a thought No. It works fine. I've been building this way a while now, no problems. YOU built this way I believe, just not using Reactor. It looks a little ugly if you see it, I admit, but it's worth it. I usually bootstrap from circa 5.1.6 and surely from 5.5.0 or .1 itself. I had been bootstrapping from something in between but haven't lately. So I can't vouch for all that many builds. I'm also using this code on PPC_LINUX and PPC_DARWIN (should be called PPC_MACOSX but oh well) successfully (look in m3-sys\cminstall\src\config-no-install). I have seen path() return empty with some older builds, but not with current builds. Where I have seen it, I added in if defined() to cope and something more that I forget, maybe just the "normal" thing, like to bootstrap from an older build, and it gets overwritten during the bootstrap, once there is a current cm3.exe. I should check, I should check the history, and consistently workaround for all the files with this construct (ie. config-no-install and NT386). The documentation says it returns the path or directory of cm3.exe. But I did find that to be false, but the function is still useful. It seems to return the path of the current Quake code. I haven't looked at the implementation (yet). Something is different in the Reactor path. >>> 2) Again again, can you make the stuff you are working on available? To just some people? ? - Jay Date: Fri, 25 Jan 2008 00:07:28 -0500From: rcoleburn at scires.comTo: jay123 at hotmail.com; jayk123 at hotmail.comCC: m3devel at elegosoft.comSubject: RE: [M3devel] INSTALL_ROOT and PKG_USE in cm3.cfg Jay: Based on your description of path(), I don't think it is working correctly. My INSTALL_ROOT is turning up as "\.." instead of "C:\cm3\bin\.." If this path() function worked as advertised, I think your solution might work. Reactor/CM3-IDE is running from C:\cm3\bin, so when it uses quake to evaluate cm3.cfg, shouldn't it come up with "C:\cm3\bin\.." for the path? Maybe it does, and if so, then the ".." in the path may be confusing internally when it tries to make paths like "C:\cm3\bin\..\pkg". I don't know. Just a thought. Regards, Randy>>> Jay 1/24/2008 11:44 PM >>>1) the general user population could revert back to cminstall; nobody else complained except me (a common occurence), and Olaf did improve it; I'd have to deign to putting together such a distribution yuck. Perhaps when a nice GUI installer comes along it won't feel so bad.2) Again, can you make the stuff you are working on available? To just some people? path() returns the directory of the currently executing Quake code.And in this case, the file is in the directory that contains cm3.exe, so it is cm3.exe's directory, which we know is INSTALLROOT\bin, so go up one with .. and we have INSTALLROOT. It's a little unsightly to have ".." in all the resulting paths, but I think it is worth it. It could be fixed in a number of ways. 1) add a function PathDotDot or PathUp to cm3 2) more generally add a function PathCanonicalize to cm3. Or heck, move more and more of this stuff into cm3. I asked about this recently -- what are the requirements for compatibility with older tools. It is that unanswered, and presuming "the worst", besides my persistant distaste for Modula-3, that keeps me writing Quake code.. - Jay Date: Thu, 24 Jan 2008 21:48:28 -0500From: rcoleburn at scires.comTo: jay123 at hotmail.com; jayk123 at hotmail.comCC: m3devel at elegosoft.comSubject: Re: [M3devel] INSTALL_ROOT and PKG_USE in cm3.cfg Jay: I've already edited my version of cm3.cfg to make it work for me. I don't know what the path() function does. The path() function is only used in the following code: if not defined("INSTALL_ROOT") if not equal ($INSTALLROOT, "") INSTALL_ROOT = $INSTALLROOT else INSTALL_ROOT = (path() & "\\..") endend Since this code is not executed when I define INSTALL_ROOT as "c:\\cm3", there is no need to remove it for my use. I've already confirmed that the other variables I need get set correctly inside CM3-IDE/Reactor once the INSTALL_ROOT is set properly. Note that a bunch of variables inside cm3.cfg depend on INSTALL_ROOT. I'm still want to find a solution for the general user population. Regards, Randy>>> Jay 1/24/2008 9:23 PM >>>Randy, don't worry, whatever you do, I'll be able to recover from. Just try editing your \cm3\bin\cm3.cfg file to say INSTALLROOT="c:\cm3" or whatever.Remove the path() function as a variable.See what happens. Maybe it's the problem, maybe not. It is something that I changed, and is worth trying the old way. Use write() and error() to print the other variables. Can you make the stuff you are working on available? To just some people? - Jay Date: Thu, 24 Jan 2008 21:07:29 -0500From: rcoleburn at scires.comTo: jay123 at hotmail.com; jayk123 at hotmail.comCC: m3devel at elegosoft.comSubject: Re: [M3devel] INSTALL_ROOT and PKG_USE in cm3.cfg Jay: Not sure exactly what you mean by:>I'm not sure what versions of cm3 have path(). I did think I saw it missing the other day. I assume you are not referring to the path env variable. Is this some built-in quake function or a function you have written in quake? The version of cm3.cfg that I am using is the one that *you* put in the minimal binary installation for windows. Reactor does indeed "run" the cm3.cfg in that it uses quake to load and interpret this file. What is the significance of doing the copy you suggest below? >In terms of my workflow, you can go ahead and copy NT386 to the config-no-install directory. I'll survive. I'm not trying to be obtuse here. It's just that you have been working on the windows distribution and all these scripts etc for a while now. I don't want to mess up anything you are doing and I know I don't have a deep understanding of all this, so I am reluctant to change anything like cm3.cfg for my needs. My goal is to make the CM3-IDE (old Reactor) available to everyone. As I said before, it does "run" the cm3.cfg and it needs to use this somehow to come up with a valid "PKG_USE" which should point to the "pkg" folder inside the cm3 installation root. Regards, Randy >>> Jay 1/24/2008 8:33 PM >>>I'm not sure what versions of cm3 have path(). I did think I saw it missing the other day.That could be your problem.m3cgcat also doesn't like my config file, it wants to open it to find TARGET, not sure it uses it at all, but it wants it. When I run mcgcat, I first put back a TARGET line in my cm3.cfg. And then remove it.This is very related.I would suspect that whoever reads the files MIGHT find it acceptable to RUN them.Running them doesn't mean compiling or linking or anything, those are functions that the "host" would chose to call or not. But toplevel can have arbitrary code so maybe this is not great. Reactor is a persistant web server though, right? It should be ok "running" the file, esp. since it doesn't start often. The "normal" alternative that other folks use is to run cminstall, which I find all but useless. In terms of my workflow, you can go ahead and copy NT386 to the config-no-install directory. I'll survive. Randy you should try debugging stuff. Quake is readily debuggabe through printing. if defined("path") write("path is defined") write("path is " & path())else write("path is not defined")enderror("") I put in error so I stop after my printing and don't go and build stuff when my intent was just to run a snippet of Quake. - Jay Date: Thu, 24 Jan 2008 20:06:09 -0500From: rcoleburn at scires.comTo: jay123 at hotmail.com; jayk123 at hotmail.comCC: m3devel at elegosoft.comSubject: RE: [M3devel] INSTALL_ROOT and PKG_USE in cm3.cfg Jay: That's the reason I asked before making a change. I don't want to break or mess up what you are doing. I can get around the problem easily for me. I just remove the comment from the %INSTALL_ROOT="c:\\cm3" and "everything" is ok. I'm hoping we can come up with a way that works for everyone. Once the CM3_IDE (formerly known as Reactor) package is in the repository and part of the standard distribution, it would be best if folks don't have to go around editing cm3.cfg to make it work properly. Now, you are saying your way is more automatic and portable. I like these words. Is there a way we can set something in cm3.cfg that I can key off of for CM3_IDE/Reactor? I don't mind changing the code to accommodate. The big thing for CM3_IDE/Reactor, is that it needs to know where to look for the cm3 installation because it has to find all of the subdirs, like doc, examples, etc. BTW, I still don't see why all this "works" since I am getting "\.." as my INSTALL_ROOT. Regards, Randy>>> Jay 1/24/2008 7:24 PM >>>Blech. My way is more automatic and "portable" in the sense that you can move installations around and they keep working. As well, with my way, you just extract an archive and go, no setup/cminstall, no editing of the cm3.cfg file, just set %PATH% and run vcvars, and vcvars I think I can remove the need for. path() is a builtin Quake function that returns the directory of the currently being run Quake code. But yet Reactor.To unblock yourself, remove my code, add back the commented out, fix the path to match your particular install, don't submit the file. Perhaps move the current checked in file over to the config-no-install directory and then put config's file back in the old style, that requires running cminstall. My workflow will keep working, since it probes for config-no-install first. - Jay Date: Thu, 24 Jan 2008 18:53:48 -0500From: rcoleburn at scires.comTo: jay123 at hotmail.comCC: m3devel at elegosoft.comSubject: [M3devel] INSTALL_ROOT and PKG_USE in cm3.cfg Jay: The cm3.cfg that comes with your minimal binary installation on Windows (NT386) has the following lines: ----------------------------------------- % INSTALL_ROOT = BEGIN_CONFIG% "Where should CM3 be installed?"% 7 %-- user specified install root% END_CONFIG % INSTALL_ROOT = "c:\\cm3" if not defined("INSTALL_ROOT") if not equal ($INSTALLROOT, "") INSTALL_ROOT = $INSTALLROOT else INSTALL_ROOT = (path() & "\\..") endend BIN_INSTALL = INSTALL_ROOT & "\\bin" % executablesLIB_INSTALL = INSTALL_ROOT & "\\lib" % librariesPKG_INSTALL = INSTALL_ROOT & "\\pkg" % packagesDOC_INSTALL = INSTALL_ROOT & "\\doc" % documentsEMACS_INSTALL = INSTALL_ROOT & "\\elisp" % emacs lisp codeMAN_INSTALL = INSTALL_ROOT & "\\man" % man pagesHTML_INSTALL = INSTALL_ROOT & "\\www" % public hypertext %% On some systems (e.g. AFS) you must install public files in a different% place from where you use them. If that is the case for your system,% specify the "use" location here, otherwise leave them alone.%%USE_ROOT = INSTALL_ROOTBIN_USE = BIN_INSTALL % executablesLIB_USE = LIB_INSTALL % librariesPKG_USE = PKG_INSTALL % packages ----------------------------------------- Notice that the lines for INSTALL_ROOT and USE_ROOT are commented out. The Reactor program is coded to grab several variables out of cm3.cfg. For example, build_dir := M3Config.Get ("BUILD_DIR"); system_root := M3Config.Get ("PKG_USE"); doc_root := M3Config.Get ("DOC_INSTALL"); initial_browser := M3Config.Get ("INITIAL_CM3_IDE_BROWSER"); initial_editor := M3Config.Get ("INITIAL_CM3_IDE_EDITOR"); What is happening on my installation is that PKG_USE winds up being "\..\PKG". This is not a valid path and it is causing all sorts of trouble for Reactor. The reason it is getting set this way is that the ELSE branch of the, if not defined("INSTALL_ROOT"), is getting executed resulting in INSTALL_ROOT=\.. I'm not sure why this is coded this way. How do you suggest this should be repaired? Note, I have not checked all of the cm3.cfg variants for the other target platforms, but in order for reactor to work properly, it must be able to find a valid "PKG_USE" in the cm3.cfg. Regards, Randy 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. Play now! 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". 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 wagner at elegosoft.com Fri Jan 25 08:06:33 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 25 Jan 2008 08:06:33 +0100 Subject: [M3devel] CM3 5.5.1 works on Ubuntu 7.10! In-Reply-To: <47993122.2030201@elego.de> References: <47993122.2030201@elego.de> Message-ID: <20080125080633.72gtexb6m8cocwsk@mail.elegosoft.com> Quoting Neels Janosch Hofmeyr : > Thanks Olaf, Tony, Mika and Jay, I have cm3 working on Ubuntu 7.10! > Complete instructions are given in the attached file. After all, it > _does_ look quite simple. But only once you know how. Please let me > know if you have any improvements waiting. I'll check this file into > the CVS somewhere. > > We need to add these instructions to modula3.elegosoft.com, so that > others do not take the same "shortcuts" I did. If noone else feels like > doing it, I will. But right now, it's way past bedtime. Would you care to load up your archive to birch.elegosoft.com:/var/www/modula3.elegosoft.com/cm3/uploaded-archives ? And check-in your instructions to cm3/www and link them in? That would be great. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From stsp at elego.de Fri Jan 25 10:35:35 2008 From: stsp at elego.de (Stefan Sperling) Date: Fri, 25 Jan 2008 10:35:35 +0100 Subject: [M3devel] CM3 5.5.1 works on Ubuntu 7.10! In-Reply-To: <47993388.9030909@elego.de> References: <47993122.2030201@elego.de> <47993388.9030909@elego.de> Message-ID: <20080125093535.GA27717@jack.stsp.name> On Fri, Jan 25, 2008 at 01:55:36AM +0100, Neels Janosch Hofmeyr wrote: > Wow, does your mail client also think the attachment is a PowerPoint > Document? Well, in fact it's a plain ASCII text file. Yes, the mime-type is wrong. Mutt tells me: [-- Attachment #2: install-cm3-on-ubuntu-7-10.txt --] [-- Type: application/vnd.ms-powerpoint, Encoding: base64, Size: 12K --] [-- application/vnd.ms-powerpoint is unsupported (use 'v' to view this part) --] -- Stefan Sperling Software Developer elego Software Solutions GmbH HRB 77719 Gustav-Meyer-Allee 25, Gebaeude 12 Tel: +49 30 23 45 86 96 13355 Berlin Fax: +49 30 23 45 86 95 http://www.elego.de Geschaeftsfuehrer: Olaf Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From wagner at elegosoft.com Fri Jan 25 11:09:59 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 25 Jan 2008 11:09:59 +0100 Subject: [M3devel] INSTALL_ROOT and PKG_USE in cm3.cfg In-Reply-To: References: <4798DEB8.1E75.00D7.1@scires.com> <4798EFAE.1E75.00D7.1@scires.com> <4798FE0E.1E75.00D7.1@scires.com> <479907A8.1E75.00D7.1@scires.com> <4799283C.1E75.00D7.1@scires.com> Message-ID: <20080125110959.5oc8u98w0w8csc80@mail.elegosoft.com> Quoting Jay : > using this code on PPC_LINUX and PPC_DARWIN (should be called > PPC_MACOSX but oh well) Actually I did the port on a plain DARWIN system from opendarwin.org when this was still alive. So there should be no dependency on MacOS X extensions. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Fri Jan 25 11:23:10 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 25 Jan 2008 11:23:10 +0100 Subject: [M3devel] INSTALL_ROOT and PKG_USE in cm3.cfg In-Reply-To: References: <4798DEB8.1E75.00D7.1@scires.com> <4798EFAE.1E75.00D7.1@scires.com> <4798FE0E.1E75.00D7.1@scires.com> <479907A8.1E75.00D7.1@scires.com> <4799283C.1E75.00D7.1@scires.com> Message-ID: <20080125112310.9qfns8rzx5gckgck@mail.elegosoft.com> Quoting Jay : > I have seen path() return empty with some older builds, but not with > current builds. > Where I have seen it, I added in if defined() to cope and something > more that I forget, maybe just the "normal" thing, like to bootstrap > from an older build, and it gets overwritten during the bootstrap, > once there is a current cm3.exe. I should check, I should check the > history, and consistently workaround for all the files with this > construct (ie. config-no-install and NT386). > > The documentation says it returns the path or directory of cm3.exe. > But I did find that to be false, but the function is still useful. > It seems to return the path of the current Quake code. I haven't > looked at the implementation (yet). Where did you read that? http://modula3.elegosoft.com/cm3/doc/help/cm3/quake.html says path() Returns the directory of the currently executing file as a string Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Jan 25 11:29:28 2008 From: jayk123 at hotmail.com (Jay) Date: Fri, 25 Jan 2008 10:29:28 +0000 Subject: [M3devel] INSTALL_ROOT and PKG_USE in cm3.cfg In-Reply-To: <20080125110959.5oc8u98w0w8csc80@mail.elegosoft.com> References: <4798DEB8.1E75.00D7.1@scires.com> <4798EFAE.1E75.00D7.1@scires.com> <4798FE0E.1E75.00D7.1@scires.com> <479907A8.1E75.00D7.1@scires.com> <4799283C.1E75.00D7.1@scires.com> <20080125110959.5oc8u98w0w8csc80@mail.elegosoft.com> Message-ID: ok, but independent of what it's actual dependencies are...how many people run Darwin? How many people run Mac OS X? How many people have heard of Darwin (not Charles)? How many people have heard of Mac OS X? Even among the unusual people who might read anything related to Modula-3 and own a Macintosh running Mac OS X? I know it's not a popularity contest but.. NT386 should be called Windows. The name "NT" will probably gradually fade into obscurity and the name "Windows" will live on much longe. Posix and Unix will probably be forgotten and people will only have heard of "Linux". The PPC_DARWIN port has an optional dependency on X Windows..is that available for plain Darwin or only with Mac OS X? Anyway..it's just a gut feeling I have as to what names people would look for and find less surprising. I was surprised by "Darwin", therefore would be.. :) MacX is maybe a better compromise to be shorter. or Macintosh for verbosity and without so many initials.. (NT386 may be short and typable but every letter is a syllable and I think economy of syllables is also important....(not clear if prounounced "eight" or "eighty") Or maybe just Mac, assuming nobody thinks there will ever be a port to pre MacX, which could be called OldMac or MacClassic or Mac9 anyway if necessary.. :) LINUX, LINUXELF, LINUXLIBC6? Please. Couldn't Linux have been recycled for LINUXLIBC6?Does anyone have Linux 1.2 around? That's the version I've run the most, long ago. :) Anyway I don't care THAT much and I will resist suggesting any more names for any preexisting targets or criticizing them. They almost all stink, esp. the active ones. :) Are the older FreeBSD ABIs so inferior that it is worth having newer ones? They didn't have pthreads back then and they do now? - Jay > Date: Fri, 25 Jan 2008 11:09:59 +0100> From: wagner at elegosoft.com> To: m3devel at elegosoft.com> Subject: Re: [M3devel] INSTALL_ROOT and PKG_USE in cm3.cfg> > Quoting Jay :> > > using this code on PPC_LINUX and PPC_DARWIN (should be called > > PPC_MACOSX but oh well)> > Actually I did the port on a plain DARWIN system from opendarwin.org> when this was still alive. So there should be no dependency on MacOS X> extensions.> > Olaf> -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 Fri Jan 25 11:38:17 2008 From: mika at async.caltech.edu (Mika Nystrom) Date: Fri, 25 Jan 2008 02:38:17 -0800 Subject: [M3devel] INSTALL_ROOT and PKG_USE in cm3.cfg In-Reply-To: Your message of "Fri, 25 Jan 2008 10:29:28 GMT." Message-ID: <200801251038.m0PAcHVv014819@camembert.async.caltech.edu> I'm not sure about this MACOSX business. This is what I see when I log in to my Mac: (94)rover:~>ssh -Y lapdog Last login: Tue Jan 22 00:33:21 2008 from rover Welcome to Darwin! [lapdog:~] mika% uname -a Darwin lapdog 8.11.0 Darwin Kernel Version 8.11.0: Wed Oct 10 18:26:00 PDT 2007; root:xnu-792.24.17~1/RELEASE_PPC Power Macintosh powerpc [lapdog:~] mika% Jay writes: >--_587094ee-5029-41f3-88b0-f4a35ad4e834_ >Content-Type: text/plain; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > >ok, but independent of what it's actual dependencies are...how many people = >run Darwin? How many people run Mac OS X? How many people have heard of Dar= >win (not Charles)? How many people have heard of Mac OS X? Even among the u= >nusual people who might read anything related to Modula-3 and own a Macinto= >sh running Mac OS X? I know it's not a popularity contest but.. NT386 shoul= >d be called Windows. The name "NT" will probably gradually fade into obscur= >ity and the name "Windows" will live on much longe. Posix and Unix will pro= >bably be forgotten and people will only have heard of "Linux". >=20 >The PPC_DARWIN port has an optional dependency on X Windows..is that availa= >ble for plain Darwin or only with Mac OS X? >=20 >Anyway..it's just a gut feeling I have as to what names people would look f= >or and find less surprising. >I was surprised by "Darwin", therefore would be.. :) >MacX is maybe a better compromise to be shorter. >or Macintosh for verbosity and without so many initials.. (NT386 may be sho= >rt and typable but every letter is a syllable and I think economy of syllab= >les is also important....(not clear if prounounced "eight" or "eighty") >Or maybe just Mac, assuming nobody thinks there will ever be a port to pre = >MacX, which could be called OldMac or MacClassic or Mac9 anyway if necessar= >y.. :) >=20 >LINUX, LINUXELF, LINUXLIBC6? Please. >Couldn't Linux have been recycled for LINUXLIBC6?Does anyone have Linux 1.2= > around? >That's the version I've run the most, long ago. :) >=20 >Anyway I don't care THAT much and I will resist suggesting any more names f= >or any preexisting targets or criticizing them. >They almost all stink, esp. the active ones. :) >Are the older FreeBSD ABIs so inferior that it is worth having newer ones? = >They didn't have pthreads back then and they do now? >=20 > - Jay > > > >> Date: Fri, 25 Jan 2008 11:09:59 +0100> From: wagner at elegosoft.com> To: m3= >devel at elegosoft.com> Subject: Re: [M3devel] INSTALL_ROOT and PKG_USE in cm3= >.cfg> > Quoting Jay :> > > using this code on PPC_LINU= >X and PPC_DARWIN (should be called > > PPC_MACOSX but oh well)> > Actually = >I did the port on a plain DARWIN system from opendarwin.org> when this was = >still alive. So there should be no dependency on MacOS X> extensions.> > Ol= >af> -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 2= >5 / 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 Cha= >rlottenburg HRB 77719 | USt-IdNr: DE163214194>=20 >_________________________________________________________________ >Helping your favorite cause is as easy as instant messaging.=A0You IM, we g= >ive. >http://im.live.com/Messenger/IM/Home/?source=3Dtext_hotmail_join= > >--_587094ee-5029-41f3-88b0-f4a35ad4e834_ >Content-Type: text/html; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > > > > >ok, but independent of what it's actual dependenc= >ies are...how many people run Darwin? How many people run Mac OS X? How man= >y people have heard of Darwin (not Charles)? How many people have heard of = >Mac OS X? Even among the unusual people who might read anything related to = >Modula-3 and own a Macintosh running Mac OS X? I know it's not a popul= >arity contest but.. NT386 should be called Windows. The name "NT" will prob= >ably gradually fade into obscurity and the name "Windows" will live on much= > longe. Posix and Unix will probably be forgotten and people will only have= > heard of "Linux".
> 
>The PPC_DARWIN port has an optional dependency on X Windows..is that availa= >ble for plain Darwin or only with Mac OS X?
> 
>Anyway..it's just a gut feeling I have as to what names people would look f= >or and find less surprising.
>I was surprised by "Darwin", therefore would be.. :)
>MacX is maybe a better compromise to be shorter.
>or Macintosh for verbosity and without so many initials.. (NT386 may be sho= >rt and typable but every letter is a syllable and I think economy of syllab= >les is also important....(not clear if prounounced "eight" or "eighty")
>Or maybe just Mac, assuming nobody thinks there will ever be a port to pre = >MacX, which could be called OldMac or MacClassic or Mac9 anyway if necessar= >y.. :)
> 
>LINUX, LINUXELF, LINUXLIBC6? Please.
>Couldn't Linux have been recycled for LINUXLIBC6?
Does anyone have Linux= > 1.2 around?
>That's the version I've run the most, long ago. :)
> 
>Anyway I don't care THAT much and I will resist suggesting any more names f= >or any preexisting targets or criticizing them.
>They almost all stink, esp. the active ones. :)
>Are the older FreeBSD ABIs so inferior that it is worth having newer ones? = >They didn't have pthreads back then and they do now?
> 
> - Jay


> >
>
>> Date: Fri, 25 Jan 2008 11:09:59 +0100
> From: wagner at elegosoft.c= >om
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] INSTALL= >_ROOT and PKG_USE in cm3.cfg
>
> Quoting Jay <jayk123 at hotma= >il.com>:
>
> > using this code on PPC_LINUX and PPC_DARW= >IN (should be called
> > PPC_MACOSX but oh well)
>
>= > Actually I did the port on a plain DARWIN system from opendarwin.org
&g= >t; when this was still alive. So there should be no dependency on MacOS XR>> extensions.
>
> 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 2= >345 869 fax: +49 30 23 45 86 95
> http://www.elegosoft.com | Gesch=E4= >ftsf=FChrer: Olaf Wagner | Sitz: Berlin
> Handelregister: Amtsgericht= > Charlottenburg HRB 77719 | USt-IdNr: DE163214194
>


/>Helping your favorite cause is as easy as instant messaging.=A0You IM, w= >e give. ail_join' target=3D'_new'>Learn more. >= > >--_587094ee-5029-41f3-88b0-f4a35ad4e834_-- From jayk123 at hotmail.com Fri Jan 25 11:39:19 2008 From: jayk123 at hotmail.com (Jay) Date: Fri, 25 Jan 2008 10:39:19 +0000 Subject: [M3devel] INSTALL_ROOT and PKG_USE in cm3.cfg In-Reply-To: <20080125112310.9qfns8rzx5gckgck@mail.elegosoft.com> References: <4798DEB8.1E75.00D7.1@scires.com> <4798EFAE.1E75.00D7.1@scires.com> <4798FE0E.1E75.00D7.1@scires.com> <479907A8.1E75.00D7.1@scires.com> <4799283C.1E75.00D7.1@scires.com> <20080125112310.9qfns8rzx5gckgck@mail.elegosoft.com> Message-ID: Oops I must have just misinterpreted that. executing, executable, .exe.. - Jay > Date: Fri, 25 Jan 2008 11:23:10 +0100> From: wagner at elegosoft.com> To: m3devel at elegosoft.com> Subject: Re: [M3devel] INSTALL_ROOT and PKG_USE in cm3.cfg> > Quoting Jay :> > I have seen path() return empty with some older builds, but not with > > current builds.> > Where I have seen it, I added in if defined() to cope and something > > more that I forget, maybe just the "normal" thing, like to bootstrap > > from an older build, and it gets overwritten during the bootstrap, > > once there is a current cm3.exe. I should check, I should check the > > history, and consistently workaround for all the files with this > > construct (ie. config-no-install and NT386).> >> > The documentation says it returns the path or directory of cm3.exe.> > But I did find that to be false, but the function is still useful. > > It seems to return the path of the current Quake code. I haven't > > looked at the implementation (yet).> > Where did you read that?> > http://modula3.elegosoft.com/cm3/doc/help/cm3/quake.html says> > path() Returns the directory of the currently executing file as a string> > Olaf> -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 Fri Jan 25 12:26:09 2008 From: jayk123 at hotmail.com (Jay) Date: Fri, 25 Jan 2008 11:26:09 +0000 Subject: [M3devel] INSTALL_ROOT and PKG_USE in cm3.cfg In-Reply-To: <200801251038.m0PAcHVv014819@camembert.async.caltech.edu> References: Your message of "Fri, 25 Jan 2008 10:29:28 GMT." <200801251038.m0PAcHVv014819@camembert.async.caltech.edu> Message-ID: true.. It looks like binary releases of Darwin are no longer made and apparently there are no instructions for building it from source...though that is the source presumably from which part of MacOSX is built.. > To: jayk123 at hotmail.com> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] INSTALL_ROOT and PKG_USE in cm3.cfg > Date: Fri, 25 Jan 2008 02:38:17 -0800> From: mika at async.caltech.edu> > I'm not sure about this MACOSX business.> > This is what I see when I log in to my Mac:> > (94)rover:~>ssh -Y lapdog> Last login: Tue Jan 22 00:33:21 2008 from rover> Welcome to Darwin!> [lapdog:~] mika% uname -a> Darwin lapdog 8.11.0 Darwin Kernel Version 8.11.0: Wed Oct 10 18:26:00 PDT 2007; root:xnu-792.24.17~1/RELEASE_PPC Power Macintosh powerpc> [lapdog:~] mika% > > > > Jay writes:> >--_587094ee-5029-41f3-88b0-f4a35ad4e834_> >Content-Type: text/plain; charset="iso-8859-1"> >Content-Transfer-Encoding: quoted-printable> >> >ok, but independent of what it's actual dependencies are...how many people => >run Darwin? How many people run Mac OS X? How many people have heard of Dar=> >win (not Charles)? How many people have heard of Mac OS X? Even among the u=> >nusual people who might read anything related to Modula-3 and own a Macinto=> >sh running Mac OS X? I know it's not a popularity contest but.. NT386 shoul=> >d be called Windows. The name "NT" will probably gradually fade into obscur=> >ity and the name "Windows" will live on much longe. Posix and Unix will pro=> >bably be forgotten and people will only have heard of "Linux".> >=20> >The PPC_DARWIN port has an optional dependency on X Windows..is that availa=> >ble for plain Darwin or only with Mac OS X?> >=20> >Anyway..it's just a gut feeling I have as to what names people would look f=> >or and find less surprising.> >I was surprised by "Darwin", therefore would be.. :)> >MacX is maybe a better compromise to be shorter.> >or Macintosh for verbosity and without so many initials.. (NT386 may be sho=> >rt and typable but every letter is a syllable and I think economy of syllab=> >les is also important....(not clear if prounounced "eight" or "eighty")> >Or maybe just Mac, assuming nobody thinks there will ever be a port to pre => >MacX, which could be called OldMac or MacClassic or Mac9 anyway if necessar=> >y.. :)> >=20> >LINUX, LINUXELF, LINUXLIBC6? Please.> >Couldn't Linux have been recycled for LINUXLIBC6?Does anyone have Linux 1.2=> > around?> >That's the version I've run the most, long ago. :)> >=20> >Anyway I don't care THAT much and I will resist suggesting any more names f=> >or any preexisting targets or criticizing them.> >They almost all stink, esp. the active ones. :)> >Are the older FreeBSD ABIs so inferior that it is worth having newer ones? => >They didn't have pthreads back then and they do now?> >=20> > - Jay> >> >> >> >> Date: Fri, 25 Jan 2008 11:09:59 +0100> From: wagner at elegosoft.com> To: m3=> >devel at elegosoft.com> Subject: Re: [M3devel] INSTALL_ROOT and PKG_USE in cm3=> >.cfg> > Quoting Jay :> > > using this code on PPC_LINU=> >X and PPC_DARWIN (should be called > > PPC_MACOSX but oh well)> > Actually => >I did the port on a plain DARWIN system from opendarwin.org> when this was => >still alive. So there should be no dependency on MacOS X> extensions.> > Ol=> >af> -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 2=> >5 / 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 Cha=> >rlottenburg HRB 77719 | USt-IdNr: DE163214194>=20> >_________________________________________________________________> >Helping your favorite cause is as easy as instant messaging.=A0You IM, we g=> >ive.> >http://im.live.com/Messenger/IM/Home/?source=3Dtext_hotmail_join=> >> >--_587094ee-5029-41f3-88b0-f4a35ad4e834_> >Content-Type: text/html; charset="iso-8859-1"> >Content-Transfer-Encoding: quoted-printable> >> >> >> >> >> >ok, but independent of what it's actual dependenc=> >ies are...how many people run Darwin? How many people run Mac OS X? How man=> >y people have heard of Darwin (not Charles)? How many people have heard of => >Mac OS X? Even among the unusual people who might read anything related to => >Modula-3 and own a Macintosh running Mac OS X? I know it's not a popul=> >arity contest but.. NT386 should be called Windows. The name "NT" will prob=> >ably gradually fade into obscurity and the name "Windows" will live on much=> > longe. Posix and Unix will probably be forgotten and people will only have=> > heard of "Linux".
> > 
> >The PPC_DARWIN port has an optional dependency on X Windows..is that availa=> >ble for plain Darwin or only with Mac OS X?
> > 
> >Anyway..it's just a gut feeling I have as to what names people would look f=> >or and find less surprising.
> >I was surprised by "Darwin", therefore would be.. :)
> >MacX is maybe a better compromise to be shorter.
> >or Macintosh for verbosity and without so many initials.. (NT386 may be sho=> >rt and typable but every letter is a syllable and I think economy of syllab=> >les is also important....(not clear if prounounced "eight" or "eighty")
> >Or maybe just Mac, assuming nobody thinks there will ever be a port to pre => >MacX, which could be called OldMac or MacClassic or Mac9 anyway if necessar=> >y.. :)
> > 
> >LINUX, LINUXELF, LINUXLIBC6? Please.
> >Couldn't Linux have been recycled for LINUXLIBC6?
Does anyone have Linux=> > 1.2 around?
> >That's the version I've run the most, long ago. :)
> > 
> >Anyway I don't care THAT much and I will resist suggesting any more names f=> >or any preexisting targets or criticizing them.
> >They almost all stink, esp. the active ones. :)
> >Are the older FreeBSD ABIs so inferior that it is worth having newer ones? => >They didn't have pthreads back then and they do now?
> > 
> > - Jay


> >> >
> >
> >> Date: Fri, 25 Jan 2008 11:09:59 +0100
> From: wagner at elegosoft.c=> >om
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] INSTALL=> >_ROOT and PKG_USE in cm3.cfg
>
> Quoting Jay <jayk123 at hotma=> >il.com>:
>
> > using this code on PPC_LINUX and PPC_DARW=> >IN (should be called
> > PPC_MACOSX but oh well)
>
>=> > Actually I did the port on a plain DARWIN system from opendarwin.org
&g=> >t; when this was still alive. So there should be no dependency on MacOS X >R>> extensions.
>
> 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 2=> >345 869 fax: +49 30 23 45 86 95
> http://www.elegosoft.com | Gesch=E4=> >ftsf=FChrer: Olaf Wagner | Sitz: Berlin
> Handelregister: Amtsgericht=> > Charlottenburg HRB 77719 | USt-IdNr: DE163214194
>


> />Helping your favorite cause is as easy as instant messaging.=A0You IM, w=> >e give. >ail_join' target=3D'_new'>Learn more.> >=> >> >--_587094ee-5029-41f3-88b0-f4a35ad4e834_-- _________________________________________________________________ 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 Fri Jan 25 13:36:49 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 25 Jan 2008 13:36:49 +0100 Subject: [M3devel] INSTALL_ROOT and PKG_USE in cm3.cfg In-Reply-To: References: <4798DEB8.1E75.00D7.1@scires.com> <4798EFAE.1E75.00D7.1@scires.com> <4798FE0E.1E75.00D7.1@scires.com> <479907A8.1E75.00D7.1@scires.com> <4799283C.1E75.00D7.1@scires.com> <20080125110959.5oc8u98w0w8csc80@mail.elegosoft.com> Message-ID: <20080125133649.vq9xj54iqok00so0@mail.elegosoft.com> I just wanted to point out why it's call PPC_DARWIN. Now that the OpenDarwin project has closed down, it may indeed seem strange. But many of the names can only be understood based on their history. I'm with you that they are neither systematic nor intuitive. I think I could even be persuaded to support a general renaming, if the scheme and concepts are well considered before. Quoting Jay : > The PPC_DARWIN port has an optional dependency on X Windows..is that > available for plain Darwin or only with Mac OS X? Yes. Actually the X in X Windows and MacOS X refer to completely different things. MacOS X does not support X Windows out of the box, it uses Aqua as GUI. > I was surprised by "Darwin", therefore would be.. :) That's why I tried to explain it ;-) > LINUX, LINUXELF, LINUXLIBC6? Please. > Couldn't Linux have been recycled for LINUXLIBC6?Does anyone have > Linux 1.2 around? It could be done now, but it couldn't when it was created. > Are the older FreeBSD ABIs so inferior that it is worth having newer > ones? They didn't have pthreads back then and they do now? There are ABI changes with every major release of FreeBSD (and also Linux, Solaris, and other operating systems if I am not much mistaken). Of course, everyone strives for compatibility of the often used and most important interfaces, but there is a grey zone where data structures common to the kernel and userland are touched, and they need to be updated (in order to not hinder improvement) more often than you'd think. If such an update annoys or disturbs users often enough, new interface abstractions tend to appear that should avoid the problem for future releases (for example, changes of the jmp_buf structure break threading code --> new interfaces for thread context access are defined). The M3 runtime is somewhat special and differs from the C runtime in that it makes use of quite a number of not always well-defined system interfaces. We also try to eliminate these dependencies (VM calls, jmp_buf structure, whole threading, ...) Actually I think I was the first one to port any pthread package to FreeBSD (when working for a company building POS solutions, but we could never release the code) back in the 1.5 and 2.x days. I used a pthreads implementation by Frank Mueller. Official pthread support came much later. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From hosking at cs.purdue.edu Fri Jan 25 15:28:46 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 25 Jan 2008 09:28:46 -0500 Subject: [M3devel] segmentation fault upon ./install-cm3-compiler.sh upgrade In-Reply-To: <47991720.1030307@elego.de> References: <4798FE9B.1090204@elego.de> <479905C8.7080003@elego.de> <20080124230322.vl12nlls4kosoocs@mail.elegosoft.com> <47990CFC.8080609@elego.de> <20080124233519.s3o34cbsmc8kocs8@mail.elegosoft.com> <479914EA.3060902@elego.de> <80025F80-FDA6-4E9D-AC2A-73C6498A6EA0@cs.purdue.edu> <47991720.1030307@elego.de> Message-ID: Build and ship packages in the following order: m3middle m3linker m3front m3quake cm3 This builds a bootstrap compiler using the *old* libraries. Use the binary this creates to build your system. On Jan 24, 2008, at 5:54 PM, Neels Janosch Hofmeyr wrote: > > Tony Hosking wrote: >> I'm pretty sure these problems are a result of needing to use a >> new bootstrap compiler. > How can I build one from source? (does this question make sense?) > > -- > Neels Janosch Hofmeyr > Software Developer > > neels at elego.de > Public Key: http://binarchy.net/neels/neels.hofmeyr.public.key.asc > > elego Software Solutions GmbH http://www.elegosoft.com > Gustav-Meyer-Allee 25, Geb?ude 12 HRB 77719 > 13355 Berlin, Germany Amtsgericht Charlottenburg > Tel.: +49 30 23 45 86 96 Sitz der Gesellschaft: Berlin > Fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Olaf Wagner > > From hosking at cs.purdue.edu Fri Jan 25 15:39:22 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 25 Jan 2008 09:39:22 -0500 Subject: [M3devel] INSTALL_ROOT and PKG_USE in cm3.cfg In-Reply-To: References: <4798DEB8.1E75.00D7.1@scires.com> <4798EFAE.1E75.00D7.1@scires.com> <4798FE0E.1E75.00D7.1@scires.com> <479907A8.1E75.00D7.1@scires.com> <4799283C.1E75.00D7.1@scires.com> <20080125110959.5oc8u98w0w8csc80@mail.elegosoft.com> Message-ID: <2157F648-47CC-4C3F-BD9E-07D14841C238@cs.purdue.edu> On Jan 25, 2008, at 5:29 AM, Jay wrote: > ok, but independent of what it's actual dependencies are...how many > people run Darwin? How many people run Mac OS X? How many people > have heard of Darwin (not Charles)? How many people have heard of > Mac OS X? Even among the unusual people who might read anything > related to Modula-3 and own a Macintosh running Mac OS X? I know > it's not a popularity contest but.. NT386 should be called Windows. > The name "NT" will probably gradually fade into obscurity and the > name "Windows" will live on much longe. Posix and Unix will > probably be forgotten and people will only have heard of "Linux". > > The PPC_DARWIN port has an optional dependency on X Windows..is > that available for plain Darwin or only with Mac OS X? Darwin makes sense given that it works on both MacOSX and open source Darwin. > Anyway..it's just a gut feeling I have as to what names people > would look for and find less surprising. > I was surprised by "Darwin", therefore would be.. :) Folks installing from source the way M3 requires generally are familiar with this terminology. If we had binary installers then naturally OSX would make sense. > MacX is maybe a better compromise to be shorter. > or Macintosh for verbosity and without so many initials.. (NT386 > may be short and typable but every letter is a syllable and I think > economy of syllables is also important....(not clear if prounounced > "eight" or "eighty") > Or maybe just Mac, assuming nobody thinks there will ever be a port > to pre MacX, which could be called OldMac or MacClassic or Mac9 > anyway if necessary.. :) > > LINUX, LINUXELF, LINUXLIBC6? Please. > Couldn't Linux have been recycled for LINUXLIBC6? > Does anyone have Linux 1.2 around? > That's the version I've run the most, long ago. :) You must understand that the naming schemes grew organically over the past 20 years or so (before Linux was even widely known!), and when Windows was definitely not NT and never would have supported M3. > Anyway I don't care THAT much and I will resist suggesting any more > names for any preexisting targets or criticizing them. > They almost all stink, esp. the active ones. :) > Are the older FreeBSD ABIs so inferior that it is worth having > newer ones? They didn't have pthreads back then and they do now? Keeping the old distros around with their old names is a convenient historical record that I have frequently used to implement functionality on new systems. For example, much of the current Solaris exception handling (which uses native stack unwinding rather than setjmp/longjmp) was derived from DS3100 and ALPHA_OSF! Remember, the average M3 installer from source will need to be somewhat familiar with the target names. We should also strive to allow easier installs from RPMS on Linux, Fink on OSX, and binary installers on Windows that will cater to the masses! > > > - Jay > > > > > Date: Fri, 25 Jan 2008 11:09:59 +0100 > > From: wagner at elegosoft.com > > To: m3devel at elegosoft.com > > Subject: Re: [M3devel] INSTALL_ROOT and PKG_USE in cm3.cfg > > > > Quoting Jay : > > > > > using this code on PPC_LINUX and PPC_DARWIN (should be called > > > PPC_MACOSX but oh well) > > > > Actually I did the port on a plain DARWIN system from opendarwin.org > > when this was still alive. So there should be no dependency on > MacOS X > > extensions. > > > > Olaf > > -- > > Olaf Wagner -- elego Software Solutions GmbH > > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 Fri Jan 25 15:40:00 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 25 Jan 2008 09:40:00 -0500 Subject: [M3devel] INSTALL_ROOT and PKG_USE in cm3.cfg In-Reply-To: <200801251038.m0PAcHVv014819@camembert.async.caltech.edu> References: <200801251038.m0PAcHVv014819@camembert.async.caltech.edu> Message-ID: <1A4B11E5-3935-4662-AD1F-CDFB0CB940CB@cs.purdue.edu> Precisely! On Jan 25, 2008, at 5:38 AM, Mika Nystrom wrote: > I'm not sure about this MACOSX business. > > This is what I see when I log in to my Mac: > > (94)rover:~>ssh -Y lapdog > Last login: Tue Jan 22 00:33:21 2008 from rover > Welcome to Darwin! > [lapdog:~] mika% uname -a > Darwin lapdog 8.11.0 Darwin Kernel Version 8.11.0: Wed Oct 10 > 18:26:00 PDT 2007; root:xnu-792.24.17~1/RELEASE_PPC Power Macintosh > powerpc > [lapdog:~] mika% > > > > Jay writes: >> --_587094ee-5029-41f3-88b0-f4a35ad4e834_ >> Content-Type: text/plain; charset="iso-8859-1" >> Content-Transfer-Encoding: quoted-printable >> >> ok, but independent of what it's actual dependencies are...how >> many people = >> run Darwin? How many people run Mac OS X? How many people have >> heard of Dar= >> win (not Charles)? How many people have heard of Mac OS X? Even >> among the u= >> nusual people who might read anything related to Modula-3 and own >> a Macinto= >> sh running Mac OS X? I know it's not a popularity contest but.. >> NT386 shoul= >> d be called Windows. The name "NT" will probably gradually fade >> into obscur= >> ity and the name "Windows" will live on much longe. Posix and Unix >> will pro= >> bably be forgotten and people will only have heard of "Linux". >> =20 >> The PPC_DARWIN port has an optional dependency on X Windows..is >> that availa= >> ble for plain Darwin or only with Mac OS X? >> =20 >> Anyway..it's just a gut feeling I have as to what names people >> would look f= >> or and find less surprising. >> I was surprised by "Darwin", therefore would be.. :) >> MacX is maybe a better compromise to be shorter. >> or Macintosh for verbosity and without so many initials.. (NT386 >> may be sho= >> rt and typable but every letter is a syllable and I think economy >> of syllab= >> les is also important....(not clear if prounounced "eight" or >> "eighty") >> Or maybe just Mac, assuming nobody thinks there will ever be a >> port to pre = >> MacX, which could be called OldMac or MacClassic or Mac9 anyway if >> necessar= >> y.. :) >> =20 >> LINUX, LINUXELF, LINUXLIBC6? Please. >> Couldn't Linux have been recycled for LINUXLIBC6?Does anyone have >> Linux 1.2= >> around? >> That's the version I've run the most, long ago. :) >> =20 >> Anyway I don't care THAT much and I will resist suggesting any >> more names f= >> or any preexisting targets or criticizing them. >> They almost all stink, esp. the active ones. :) >> Are the older FreeBSD ABIs so inferior that it is worth having >> newer ones? = >> They didn't have pthreads back then and they do now? >> =20 >> - Jay >> >> >> >>> Date: Fri, 25 Jan 2008 11:09:59 +0100> From: >>> wagner at elegosoft.com> To: m3= >> devel at elegosoft.com> Subject: Re: [M3devel] INSTALL_ROOT and >> PKG_USE in cm3= >> .cfg> > Quoting Jay :> > > using this code on >> PPC_LINU= >> X and PPC_DARWIN (should be called > > PPC_MACOSX but oh well)> > >> Actually = >> I did the port on a plain DARWIN system from opendarwin.org> when >> this was = >> still alive. So there should be no dependency on MacOS X> >> extensions.> > Ol= >> af> -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav- >> Meyer-Allee 2= >> 5 / 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 Cha= >> rlottenburg HRB 77719 | USt-IdNr: DE163214194>=20 >> _________________________________________________________________ >> Helping your favorite cause is as easy as instant messaging.=A0You >> IM, we g= >> ive. >> http://im.live.com/Messenger/IM/Home/?source=3Dtext_hotmail_join= >> >> --_587094ee-5029-41f3-88b0-f4a35ad4e834_ >> Content-Type: text/html; charset="iso-8859-1" >> Content-Transfer-Encoding: quoted-printable >> >> >> >> >> >> ok, but independent of what it's actual >> dependenc= >> ies are...how many people run Darwin? How many people run Mac OS >> X? How man= >> y people have heard of Darwin (not Charles)? How many people have >> heard of = >> Mac OS X? Even among the unusual people who might read anything >> related to = >> Modula-3 and own a Macintosh running Mac OS X? I know it's >> not a popul= >> arity contest but.. NT386 should be called Windows. The name "NT" >> will prob= >> ably gradually fade into obscurity and the name "Windows" will >> live on much= >> longe. Posix and Unix will probably be forgotten and people will >> only have= >> heard of "Linux".
>>  
>> The PPC_DARWIN port has an optional dependency on X Windows..is >> that availa= >> ble for plain Darwin or only with Mac OS X?
>>  
>> Anyway..it's just a gut feeling I have as to what names people >> would look f= >> or and find less surprising.
>> I was surprised by "Darwin", therefore would be.. :)
>> MacX is maybe a better compromise to be shorter.
>> or Macintosh for verbosity and without so many initials.. (NT386 >> may be sho= >> rt and typable but every letter is a syllable and I think economy >> of syllab= >> les is also important....(not clear if prounounced "eight" or >> "eighty")
>> Or maybe just Mac, assuming nobody thinks there will ever be a >> port to pre = >> MacX, which could be called OldMac or MacClassic or Mac9 anyway if >> necessar= >> y.. :)
>>  
>> LINUX, LINUXELF, LINUXLIBC6? Please.
>> Couldn't Linux have been recycled for LINUXLIBC6?
Does anyone >> have Linux= >> 1.2 around?
>> That's the version I've run the most, long ago. :)
>>  
>> Anyway I don't care THAT much and I will resist suggesting any >> more names f= >> or any preexisting targets or criticizing them.
>> They almost all stink, esp. the active ones. :)
>> Are the older FreeBSD ABIs so inferior that it is worth having >> newer ones? = >> They didn't have pthreads back then and they do now?
>>  
>>  - Jay


>> >>
>>
>> > Date: Fri, 25 Jan 2008 11:09:59 +0100
> From: >> wagner at elegosoft.c= >> om
> To: m3devel at elegosoft.com
> Subject: Re: >> [M3devel] INSTALL= >> _ROOT and PKG_USE in cm3.cfg
>
> Quoting Jay >> <jayk123 at hotma= >> il.com>:
>
> > using this code on PPC_LINUX and >> PPC_DARW= >> IN (should be called
> > PPC_MACOSX but oh well)
> >>
>= >> Actually I did the port on a plain DARWIN system from >> opendarwin.org
&g= >> t; when this was still alive. So there should be no dependency on >> MacOS X> R>> extensions.
>
> 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 2= >> 345 869 fax: +49 30 23 45 86 95
> http://www.elegosoft.com | >> Gesch=E4= >> ftsf=FChrer: Olaf Wagner | Sitz: Berlin
> Handelregister: >> Amtsgericht= >> Charlottenburg HRB 77719 | USt-IdNr: DE163214194
> >>


> />Helping your favorite cause is as easy as instant >> messaging.=A0You IM, w= >> e give. > source=3Dtext_hotm= >> ail_join' target=3D'_new'>Learn more. >> = >> >> --_587094ee-5029-41f3-88b0-f4a35ad4e834_-- From hosking at cs.purdue.edu Fri Jan 25 15:49:53 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 25 Jan 2008 09:49:53 -0500 Subject: [M3devel] INSTALL_ROOT and PKG_USE in cm3.cfg In-Reply-To: <1A4B11E5-3935-4662-AD1F-CDFB0CB940CB@cs.purdue.edu> References: <200801251038.m0PAcHVv014819@camembert.async.caltech.edu> <1A4B11E5-3935-4662-AD1F-CDFB0CB940CB@cs.purdue.edu> Message-ID: Latest Darwin source is still at http://www.opensource.apple.com/ darwinsource/ On Jan 25, 2008, at 9:40 AM, Tony Hosking wrote: > Precisely! > > On Jan 25, 2008, at 5:38 AM, Mika Nystrom wrote: > >> I'm not sure about this MACOSX business. >> >> This is what I see when I log in to my Mac: >> >> (94)rover:~>ssh -Y lapdog >> Last login: Tue Jan 22 00:33:21 2008 from rover >> Welcome to Darwin! >> [lapdog:~] mika% uname -a >> Darwin lapdog 8.11.0 Darwin Kernel Version 8.11.0: Wed Oct 10 >> 18:26:00 PDT 2007; root:xnu-792.24.17~1/RELEASE_PPC Power >> Macintosh powerpc >> [lapdog:~] mika% >> >> >> >> Jay writes: >>> --_587094ee-5029-41f3-88b0-f4a35ad4e834_ >>> Content-Type: text/plain; charset="iso-8859-1" >>> Content-Transfer-Encoding: quoted-printable >>> >>> ok, but independent of what it's actual dependencies are...how >>> many people = >>> run Darwin? How many people run Mac OS X? How many people have >>> heard of Dar= >>> win (not Charles)? How many people have heard of Mac OS X? Even >>> among the u= >>> nusual people who might read anything related to Modula-3 and own >>> a Macinto= >>> sh running Mac OS X? I know it's not a popularity contest but.. >>> NT386 shoul= >>> d be called Windows. The name "NT" will probably gradually fade >>> into obscur= >>> ity and the name "Windows" will live on much longe. Posix and >>> Unix will pro= >>> bably be forgotten and people will only have heard of "Linux". >>> =20 >>> The PPC_DARWIN port has an optional dependency on X Windows..is >>> that availa= >>> ble for plain Darwin or only with Mac OS X? >>> =20 >>> Anyway..it's just a gut feeling I have as to what names people >>> would look f= >>> or and find less surprising. >>> I was surprised by "Darwin", therefore would be.. :) >>> MacX is maybe a better compromise to be shorter. >>> or Macintosh for verbosity and without so many initials.. (NT386 >>> may be sho= >>> rt and typable but every letter is a syllable and I think economy >>> of syllab= >>> les is also important....(not clear if prounounced "eight" or >>> "eighty") >>> Or maybe just Mac, assuming nobody thinks there will ever be a >>> port to pre = >>> MacX, which could be called OldMac or MacClassic or Mac9 anyway >>> if necessar= >>> y.. :) >>> =20 >>> LINUX, LINUXELF, LINUXLIBC6? Please. >>> Couldn't Linux have been recycled for LINUXLIBC6?Does anyone have >>> Linux 1.2= >>> around? >>> That's the version I've run the most, long ago. :) >>> =20 >>> Anyway I don't care THAT much and I will resist suggesting any >>> more names f= >>> or any preexisting targets or criticizing them. >>> They almost all stink, esp. the active ones. :) >>> Are the older FreeBSD ABIs so inferior that it is worth having >>> newer ones? = >>> They didn't have pthreads back then and they do now? >>> =20 >>> - Jay >>> >>> >>> >>>> Date: Fri, 25 Jan 2008 11:09:59 +0100> From: >>>> wagner at elegosoft.com> To: m3= >>> devel at elegosoft.com> Subject: Re: [M3devel] INSTALL_ROOT and >>> PKG_USE in cm3= >>> .cfg> > Quoting Jay :> > > using this code >>> on PPC_LINU= >>> X and PPC_DARWIN (should be called > > PPC_MACOSX but oh well)> > >>> Actually = >>> I did the port on a plain DARWIN system from opendarwin.org> when >>> this was = >>> still alive. So there should be no dependency on MacOS X> >>> extensions.> > Ol= >>> af> -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav- >>> Meyer-Allee 2= >>> 5 / 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 Cha= >>> rlottenburg HRB 77719 | USt-IdNr: DE163214194>=20 >>> _________________________________________________________________ >>> Helping your favorite cause is as easy as instant >>> messaging.=A0You IM, we g= >>> ive. >>> http://im.live.com/Messenger/IM/Home/?source=3Dtext_hotmail_join= >>> >>> --_587094ee-5029-41f3-88b0-f4a35ad4e834_ >>> Content-Type: text/html; charset="iso-8859-1" >>> Content-Transfer-Encoding: quoted-printable >>> >>> >>> >>> >>> >>> ok, but independent of what it's actual >>> dependenc= >>> ies are...how many people run Darwin? How many people run Mac OS >>> X? How man= >>> y people have heard of Darwin (not Charles)? How many people have >>> heard of = >>> Mac OS X? Even among the unusual people who might read anything >>> related to = >>> Modula-3 and own a Macintosh running Mac OS X? I know it's >>> not a popul= >>> arity contest but.. NT386 should be called Windows. The name "NT" >>> will prob= >>> ably gradually fade into obscurity and the name "Windows" will >>> live on much= >>> longe. Posix and Unix will probably be forgotten and people will >>> only have= >>> heard of "Linux".
>>>  
>>> The PPC_DARWIN port has an optional dependency on X Windows..is >>> that availa= >>> ble for plain Darwin or only with Mac OS X?
>>>  
>>> Anyway..it's just a gut feeling I have as to what names people >>> would look f= >>> or and find less surprising.
>>> I was surprised by "Darwin", therefore would be.. :)
>>> MacX is maybe a better compromise to be shorter.
>>> or Macintosh for verbosity and without so many initials.. (NT386 >>> may be sho= >>> rt and typable but every letter is a syllable and I think economy >>> of syllab= >>> les is also important....(not clear if prounounced "eight" or >>> "eighty")
>>> Or maybe just Mac, assuming nobody thinks there will ever be a >>> port to pre = >>> MacX, which could be called OldMac or MacClassic or Mac9 anyway >>> if necessar= >>> y.. :)
>>>  
>>> LINUX, LINUXELF, LINUXLIBC6? Please.
>>> Couldn't Linux have been recycled for LINUXLIBC6?
Does anyone >>> have Linux= >>> 1.2 around?
>>> That's the version I've run the most, long ago. :)
>>>  
>>> Anyway I don't care THAT much and I will resist suggesting any >>> more names f= >>> or any preexisting targets or criticizing them.
>>> They almost all stink, esp. the active ones. :)
>>> Are the older FreeBSD ABIs so inferior that it is worth having >>> newer ones? = >>> They didn't have pthreads back then and they do now?
>>>  
>>>  - Jay


>>> >>>
>>>
>>> > Date: Fri, 25 Jan 2008 11:09:59 +0100
> From: >>> wagner at elegosoft.c= >>> om
> To: m3devel at elegosoft.com
> Subject: Re: >>> [M3devel] INSTALL= >>> _ROOT and PKG_USE in cm3.cfg
>
> Quoting Jay >>> <jayk123 at hotma= >>> il.com>:
>
> > using this code on PPC_LINUX >>> and PPC_DARW= >>> IN (should be called
> > PPC_MACOSX but oh well) >>>
>
>= >>> Actually I did the port on a plain DARWIN system from >>> opendarwin.org
&g= >>> t; when this was still alive. So there should be no dependency on >>> MacOS X>> R>> extensions.
>
> 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 2= >>> 345 869 fax: +49 30 23 45 86 95
> http://www.elegosoft.com >>> | Gesch=E4= >>> ftsf=FChrer: Olaf Wagner | Sitz: Berlin
> Handelregister: >>> Amtsgericht= >>> Charlottenburg HRB 77719 | USt-IdNr: DE163214194
> >>>


>> />Helping your favorite cause is as easy as instant >>> messaging.=A0You IM, w= >>> e give. >> source=3Dtext_hotm= >>> ail_join' target=3D'_new'>Learn more. >>> = >>> >>> --_587094ee-5029-41f3-88b0-f4a35ad4e834_-- From jayk123 at hotmail.com Fri Jan 25 16:07:20 2008 From: jayk123 at hotmail.com (Jay) Date: Fri, 25 Jan 2008 15:07:20 +0000 Subject: [M3devel] INSTALL_ROOT and PKG_USE in cm3.cfg In-Reply-To: <20080125133649.vq9xj54iqok00so0@mail.elegosoft.com> References: <4798DEB8.1E75.00D7.1@scires.com> <4798EFAE.1E75.00D7.1@scires.com> <4798FE0E.1E75.00D7.1@scires.com> <479907A8.1E75.00D7.1@scires.com> <4799283C.1E75.00D7.1@scires.com> <20080125110959.5oc8u98w0w8csc80@mail.elegosoft.com> <20080125133649.vq9xj54iqok00so0@mail.elegosoft.com> Message-ID: > I'm with you that they are neither systematic nor intuitive.> I think I could even be persuaded to support a general renaming,> if the scheme and concepts are well considered before. Uh oh... [big ramble...] Darwin: I was surprised, but I understood. I know a lot of the history and I get it. I used the LINUXELF port briefly, or maybe the LINUX (a.out) one. I guess hypothetically you can still boot LINUX 1.2 on either modern hardware or VMs?????? Anyone reporting 10 year uptimes?? Unix ABI: I'm surprised the compat is so bad. Microsoft does an excellent job of ABI compat, but behavioral compat is another matter. > Yes. Actually the X in X Windows and MacOS X refer to completely different> things. MacOS X does not support X Windows out of the box, it uses> Aqua as GUI. I understand. I believe Aqua is mostly just a marketing term even. Apple's got a bazillion different libraries to do the same thing. Want to draw on the screen -- QuickDraw (deprecated) or CoreGraphics, OpenGL.. Want to have a text editor -- TextEdit, MSLTE, and something else, and third party like "WASTE". Want to get a mouse click -- there's two event managers. Want to open a file -- there's like four or more sets of APIs -- FSSpec, FSRef, stdio, unixio, maybe something in Cocoa. Even in the kernel they have multiple frameworks I believe. It appears to be a big random mishmash. They had two APIs for LoadLibrary/GetProcAddress, and then later add dlopen. A lot of this is historical too. They have history back to the early 1980s and they have migration story after migration story after migration story, gradually breaking all existing source code and binaries, but never eveything quite at once. At this point, nothing produced before around the year 2000 can run on an Intel Mac or a PowerPC Mac running 10.5. 10.4 on PowerPC could run stuff going way way back -- 68K even. People used to have access to video memory at fixed addresses, "low memory globals" all kinds of crazy stuff. (Really, I understand -- MacOS X is 10 or Unix. I don't know how/if they are ever going to get to 11. They were up to about version 10 via gradual incrementing through the years. System 7 was a breathrough kind of in the late 80's early 90's, System 7.1ish when the PPC came out in 1994, gradually up to around 7.5, then rapidly through 8 and 9 when Jobs returned before they release Mac OS X. I know a lot here..it's annoying... We had "fat Mac" circa 1984/1985 with 512meg and two floppy drives, a 68020 Mac II, etc. If you see the movie The Firm, when lawyer/actionhero Tom Cruise uses his computer, it plays the Mac floppy disk noise.) And by breathrough, I mean it actually sucked. They had no or nearly no protected memory user/kernel split until this century. Shared library sorts of things were loaded completely into memory at boot time generally. Microsoft beat them by 5+ years, Unix beat by far more. But now it's a fairly level playing field -- everyone has about the same architecture. Except all the low end (free) Unixes seemed to take forever to admit they needed threads, and I doubt any of them scale well. I think they resisted just to avoid being like NT, waiting and waiting and finally giving in, thus some of the ABI issues, no threads, "Linux threads", and finally NPTL -- native pthreads library -- kernel threads. And just when everyone arrived at the same place, along comes web apps distributed across a cluster, too many cores per chip for anyone to schedule... [editing has ripped things away from what they related oh well...] You can have all the smarts you want about your workload and manually schedule (fibers, vtalarm threads), but you'll never likely be able to control what CPU you are on and thus you will generally lose, unless there is only one CPU. I kind of assume we (the larger we m3devel, but indeed, perhaps every pair of developers :) ) would never be able to agree on names. I think the easiest to agree to plan is to leave it alone. But, um, I agree! If we, um, could agree on a scheme and set of names, I'd go for it. I am a little more optimistic than this...but I hesitate, briefly, to suggest... The GNU folks have a system, of triples or more recently quadruples. Something like processor-'hardware'-kernel, I forget and can't look now. 'hardware' seems to be 'unknown' or 'pc' a bunch, so I don't know what it is. uname seems to be the ingredients of most of this. i686-pc-cygwin i686-pc-nt i686-pc-linux ppc-mac-darwin? ppc-mac-classic 68k-mac-classic I figure to vet the design it helps to come up with many examples, even of platforms that don't matter. Maybe even to deal with the msdos mess, could be 16bit, 286, 386.. I agree with you that a double seems to almost always suffice. If you look at the existing names (from memory), I think you can derive something like: {X86,AMD64,PPC,PPC64,ALPHA,MIPS,ARM,SH,SPARC,68K,VAX,IA64,HPPA}_{LINUX,SOLARIS,NT,OSF1,OS2,NEXT,MSDOS,VMS,Mac,OldMac,AIX,HPUX,FreeBSD,NetBSD,OpenBSD} and cover almost the whole problem. This doesn't address the elephants that seems to have finally left the room -- compiler, linker, window library, thread library, C library, modula-3 backend. Probably most platforms should be a 2-tuple but there should guidance on how to build n-tuples. ?? x86-nt-msc-mslink-msgui-kthr-msvcr -- native just call it x86-nt ? x86-nt-gcc-gld-msgui-kthr-msvcr -- mingwin x86-nt-gcc-gld-xwin-kthr-cyg -- nt386gnu x86-nt-gcc-gld-xwin-pthr-cyg -- nt386gnu with pthreads x86-linux-gcc-gld-vga-nothr-newlibx86-linux-icc-glc-nowin-nptl-glibc -- icc Intel compiler x86-linux-gcc-gcc-qtopia-uthread-glibc These names are too long. The n-tuples open up many issues, such as variables that really almost never vary given what preceds them. Linux doesn't always use gcc, but almost. Or whether or not a configuration is link compatible with another. Varying the compiler tends not to break link compatibility, that isn't automatic, it isn't free i general, but the compiler authors usually make it so. You all can see if n-tuples matter for the vast majority of platforms, but they, perhaps matter for x86-nt. But there is a big huge out of this that is in place, as I have said many times.. platform is nt386, everything else is something else, a "configuration" perhaps. Perhaps there should be a few more quake variables specced that cm3 can/should know about. Perhaps all of the target dependencies should be moved into the configuration file?????? I think there's so little, it makes little difference either way. Perhaps the notion of target drops away entire in cm3 and it's all just configuration and has less meaning? I mean..you know, what is the meaning? it's jmpbuf size, it gcc configuration, it's build_dir, those strike me as the majority of what "target" means. alignment, integer-size (always 32...except alpha), whether to use the integrated backend, and if so, a few other variables. I haven't allowed for versions -- FreeBSD4, FreeBSD5, FreeBSD6. I also think, I hate to say, you might want to account for "fat binaries". On a Mac, you can build up for four architectures into one binary. x86,AMD64,PPC,PPC64. However that really strikes at my crazy cross idea and putting in .sh files that call out to the right binary. I heard NextStep/OpenStep ran on four architectures way back when -- 68k, x86, SPARC, HPPA, not to mention the variant the x86 variant that ran in NT (with gcc). Even Win32 lets you build hybrid 16bit/32bit or 16bit/64bit binaries, since there is an "MS-DOS" stub. This is why, of course, you end up with ad-hoc names. Because the extra variables are usually missing, and they vary differently depending on context, so just make up something. Perhaps you use the doubles I gave, and then you are allowed to append a dash and an arbitrary extra string. Oh, sorry, you already said that. You called it "variant". I guess that's it. {x86,AMD64,...}_{NT,SOLARIS,LINUX}{_optional variant} Here are some possible names from this system: X86_NT (WIN? MSWIN?) X86_NT_MINGNU X86_NT_GNU X86_SOLARIS X86_SOLARIS_GNU SPARC_SOLARIS SPARC_SOLARIS_GNU PPC_MAC X86_MAC AMD64_MAC PPC64_MAC IA64_VMS VAX_VMS ALPHA_VMS MIPS_ULTRIX MIPS_IRIX IA64_NT AMD64_NT MIPS_NT PPC_NT PPC_XBOX ? X86_XBOX ? PPC_AIX (Is POWER interesting?) PPC601_AIX ? PPC603_AIX ? G3_MAC ? G4_MAC ? G5_MAC ? PPCG3_MAC ? PPCG4_MAC ? (doesn't run on G3) PPCG4_MAC ? (64 bit, lame names...) X86_MSDOS ? X86_DJGPP ? X86_NT_MWERKS ? X86_NT_DIGITALMARS ? X86_NT_SYMANTEC ? X86_NT_BORLAND ? C_NT ? outputs C code... hm. not right, C gets converted to something else. ALPHA_OSF1 ALPHA_TRU64 ? ALPHA32_NT ? X86_NT_WATCOM ? X86_WINCE ? ARM_WINCE ? ARM_CE ? ARM_MSCE ? ARM_SYMBIAN ? ARM_PALM ? ARM_PALMOS ? X86_BEOS ? 68000_OLDMAC ? 68020_OLDMAC ? Obviously the vast vast vast vast majority of these don't matter, but as I said it helps to see how a bunch of platforms work out to vet the design. I've held back from...6502_APPLEII, 65816_APPLEIIGS.. 6502_C64 :) 65816_SNES ? (Super Nintendo game console) 6502_NES ? (Nintendo...) MIPS_PLAYSTATION ? ?_SONYPS2 ? PPC_SONYPS3 (Linux runs on this, and maybe previous) SH_DREAMCAST ? (NetBSD runs on this... as does CE) X86_XBOX ? MSBOX ? PPC_XBOX360 (or is it PPC64? Oh, and for these things, you probably need to say MS or LINUX) PPC_MSXBOX360 PPC_?XBOX and maybe some virtual machine targets: JVM_ANY ?JAVA_ANY ? MSDOTNET_ANY ?MSIL_ANY ? LLVM_NT ? Is x86 generically named and people can tweak it. Or call it 686 or I686 and if anyone really has an old processor, they can still tweak and rename and keep the name. Sorry if this is all very annoying. I'm ok with doing nothing here. Ultimately as I said, there isn't even that much code involved, as I recall. It seems to me if you move about 50 lines of cm3 out of cm3 into quake, the matter becomes even less "important", because the config file would be the only thing that cared and would only need to make sense to itself. - Jay > Date: Fri, 25 Jan 2008 13:36:49 +0100> From: wagner at elegosoft.com> To: jayk123 at hotmail.com> CC: m3devel at elegosoft.com> Subject: RE: [M3devel] INSTALL_ROOT and PKG_USE in cm3.cfg> > I just wanted to point out why it's call PPC_DARWIN. Now that the> OpenDarwin project has closed down, it may indeed seem strange.> But many of the names can only be understood based on their history.> I'm with you that they are neither systematic nor intuitive.> I think I could even be persuaded to support a general renaming,> if the scheme and concepts are well considered before.> > Quoting Jay :> > > The PPC_DARWIN port has an optional dependency on X Windows..is that > > available for plain Darwin or only with Mac OS X?> > Yes. Actually the X in X Windows and MacOS X refer to completely different> things. MacOS X does not support X Windows out of the box, it uses> Aqua as GUI.> > > I was surprised by "Darwin", therefore would be.. :)> That's why I tried to explain it ;-)> > > LINUX, LINUXELF, LINUXLIBC6? Please.> > Couldn't Linux have been recycled for LINUXLIBC6?Does anyone have > > Linux 1.2 around?> > It could be done now, but it couldn't when it was created.> > > Are the older FreeBSD ABIs so inferior that it is worth having newer > > ones? They didn't have pthreads back then and they do now?> > There are ABI changes with every major release of FreeBSD (and also> Linux, Solaris, and other operating systems if I am not much mistaken).> Of course, everyone strives for compatibility of the often used and> most important interfaces, but there is a grey zone where data> structures common to the kernel and userland are touched, and they> need to be updated (in order to not hinder improvement) more often> than you'd think. If such an update annoys or disturbs users often> enough, new interface abstractions tend to appear that should> avoid the problem for future releases (for example, changes of the> jmp_buf structure break threading code --> new interfaces for thread> context access are defined). The M3 runtime is somewhat special and> differs from the C runtime in that it makes use of quite a number of not> always well-defined system interfaces. We also try to eliminate these> dependencies (VM calls, jmp_buf structure, whole threading, ...)> > Actually I think I was the first one to port any pthread package to> FreeBSD (when working for a company building POS solutions, but we could> never release the code) back in the 1.5 and 2.x days. I used a pthreads> implementation by Frank Mueller.> Official pthread support came much later.> > Olaf> -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194> _________________________________________________________________ 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 Jan 25 16:13:20 2008 From: jayk123 at hotmail.com (Jay) Date: Fri, 25 Jan 2008 15:13:20 +0000 Subject: [M3devel] INSTALL_ROOT and PKG_USE in cm3.cfg In-Reply-To: References: <200801251038.m0PAcHVv014819@camembert.async.caltech.edu> <1A4B11E5-3935-4662-AD1F-CDFB0CB940CB@cs.purdue.edu> Message-ID: Is it usable?buildable? I don't think so but I am curious. Maybe research later, but there are way more pressing matters... I'm fine either way. I think I've said more than my piece, many times over. :) Very cathartic, and less damaging than doing anything to the code. :) Yes yes, I know the names but I don't know what others would know. And I know renaming makes tracking history hard, depending on source control, but pretty much no matter what. This is a huge reason not to rename. History can be super valuable. That's why I took forever to get over the hump and push all the NT386 content into NT386.Common instead of doing it a bit earlier, and I'm still not sure it was a good idea. The code is highly shared though. Perhaps it should be smushed all into NT386 in the source tree and three variants extracted in the build. NT386 seems to have the fewest people that give a damn so... - Jay > From: hosking at cs.purdue.edu> Date: Fri, 25 Jan 2008 09:49:53 -0500> To: hosking at cs.purdue.edu> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] INSTALL_ROOT and PKG_USE in cm3.cfg> > Latest Darwin source is still at http://www.opensource.apple.com/ > darwinsource/> > On Jan 25, 2008, at 9:40 AM, Tony Hosking wrote:> > > Precisely!> >> > On Jan 25, 2008, at 5:38 AM, Mika Nystrom wrote:> >> >> I'm not sure about this MACOSX business.> >>> >> This is what I see when I log in to my Mac:> >>> >> (94)rover:~>ssh -Y lapdog> >> Last login: Tue Jan 22 00:33:21 2008 from rover> >> Welcome to Darwin!> >> [lapdog:~] mika% uname -a> >> Darwin lapdog 8.11.0 Darwin Kernel Version 8.11.0: Wed Oct 10 > >> 18:26:00 PDT 2007; root:xnu-792.24.17~1/RELEASE_PPC Power > >> Macintosh powerpc> >> [lapdog:~] mika%> >>> >>> >>> >> Jay writes:> >>> --_587094ee-5029-41f3-88b0-f4a35ad4e834_> >>> Content-Type: text/plain; charset="iso-8859-1"> >>> Content-Transfer-Encoding: quoted-printable> >>>> >>> ok, but independent of what it's actual dependencies are...how > >>> many people => >>> run Darwin? How many people run Mac OS X? How many people have > >>> heard of Dar=> >>> win (not Charles)? How many people have heard of Mac OS X? Even > >>> among the u=> >>> nusual people who might read anything related to Modula-3 and own > >>> a Macinto=> >>> sh running Mac OS X? I know it's not a popularity contest but.. > >>> NT386 shoul=> >>> d be called Windows. The name "NT" will probably gradually fade > >>> into obscur=> >>> ity and the name "Windows" will live on much longe. Posix and > >>> Unix will pro=> >>> bably be forgotten and people will only have heard of "Linux".> >>> =20> >>> The PPC_DARWIN port has an optional dependency on X Windows..is > >>> that availa=> >>> ble for plain Darwin or only with Mac OS X?> >>> =20> >>> Anyway..it's just a gut feeling I have as to what names people > >>> would look f=> >>> or and find less surprising.> >>> I was surprised by "Darwin", therefore would be.. :)> >>> MacX is maybe a better compromise to be shorter.> >>> or Macintosh for verbosity and without so many initials.. (NT386 > >>> may be sho=> >>> rt and typable but every letter is a syllable and I think economy > >>> of syllab=> >>> les is also important....(not clear if prounounced "eight" or > >>> "eighty")> >>> Or maybe just Mac, assuming nobody thinks there will ever be a > >>> port to pre => >>> MacX, which could be called OldMac or MacClassic or Mac9 anyway > >>> if necessar=> >>> y.. :)> >>> =20> >>> LINUX, LINUXELF, LINUXLIBC6? Please.> >>> Couldn't Linux have been recycled for LINUXLIBC6?Does anyone have > >>> Linux 1.2=> >>> around?> >>> That's the version I've run the most, long ago. :)> >>> =20> >>> Anyway I don't care THAT much and I will resist suggesting any > >>> more names f=> >>> or any preexisting targets or criticizing them.> >>> They almost all stink, esp. the active ones. :)> >>> Are the older FreeBSD ABIs so inferior that it is worth having > >>> newer ones? => >>> They didn't have pthreads back then and they do now?> >>> =20> >>> - Jay> >>>> >>>> >>>> >>>> Date: Fri, 25 Jan 2008 11:09:59 +0100> From: > >>>> wagner at elegosoft.com> To: m3=> >>> devel at elegosoft.com> Subject: Re: [M3devel] INSTALL_ROOT and > >>> PKG_USE in cm3=> >>> .cfg> > Quoting Jay :> > > using this code > >>> on PPC_LINU=> >>> X and PPC_DARWIN (should be called > > PPC_MACOSX but oh well)> > > >>> Actually => >>> I did the port on a plain DARWIN system from opendarwin.org> when > >>> this was => >>> still alive. So there should be no dependency on MacOS X> > >>> extensions.> > Ol=> >>> af> -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav- > >>> Meyer-Allee 2=> >>> 5 / 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 Cha=> >>> rlottenburg HRB 77719 | USt-IdNr: DE163214194>=20> >>> _________________________________________________________________> >>> Helping your favorite cause is as easy as instant > >>> messaging.=A0You IM, we g=> >>> ive.> >>> http://im.live.com/Messenger/IM/Home/?source=3Dtext_hotmail_join=> >>>> >>> --_587094ee-5029-41f3-88b0-f4a35ad4e834_> >>> Content-Type: text/html; charset="iso-8859-1"> >>> Content-Transfer-Encoding: quoted-printable> >>>> >>> > >>> > >>> > >>> > >>> ok, but independent of what it's actual > >>> dependenc=> >>> ies are...how many people run Darwin? How many people run Mac OS > >>> X? How man=> >>> y people have heard of Darwin (not Charles)? How many people have > >>> heard of => >>> Mac OS X? Even among the unusual people who might read anything > >>> related to => >>> Modula-3 and own a Macintosh running Mac OS X? I know it's > >>> not a popul=> >>> arity contest but.. NT386 should be called Windows. The name "NT" > >>> will prob=> >>> ably gradually fade into obscurity and the name "Windows" will > >>> live on much=> >>> longe. Posix and Unix will probably be forgotten and people will > >>> only have=> >>> heard of "Linux".
> >>>  
> >>> The PPC_DARWIN port has an optional dependency on X Windows..is > >>> that availa=> >>> ble for plain Darwin or only with Mac OS X?
> >>>  
> >>> Anyway..it's just a gut feeling I have as to what names people > >>> would look f=> >>> or and find less surprising.
> >>> I was surprised by "Darwin", therefore would be.. :)
> >>> MacX is maybe a better compromise to be shorter.
> >>> or Macintosh for verbosity and without so many initials.. (NT386 > >>> may be sho=> >>> rt and typable but every letter is a syllable and I think economy > >>> of syllab=> >>> les is also important....(not clear if prounounced "eight" or > >>> "eighty")
> >>> Or maybe just Mac, assuming nobody thinks there will ever be a > >>> port to pre => >>> MacX, which could be called OldMac or MacClassic or Mac9 anyway > >>> if necessar=> >>> y.. :)
> >>>  
> >>> LINUX, LINUXELF, LINUXLIBC6? Please.
> >>> Couldn't Linux have been recycled for LINUXLIBC6?
Does anyone > >>> have Linux=> >>> 1.2 around?
> >>> That's the version I've run the most, long ago. :)
> >>>  
> >>> Anyway I don't care THAT much and I will resist suggesting any > >>> more names f=> >>> or any preexisting targets or criticizing them.
> >>> They almost all stink, esp. the active ones. :)
> >>> Are the older FreeBSD ABIs so inferior that it is worth having > >>> newer ones? => >>> They didn't have pthreads back then and they do now?
> >>>  
> >>>  - Jay


> >>>> >>>
> >>>
> >>> > Date: Fri, 25 Jan 2008 11:09:59 +0100
> From: > >>> wagner at elegosoft.c=> >>> om
> To: m3devel at elegosoft.com
> Subject: Re: > >>> [M3devel] INSTALL=> >>> _ROOT and PKG_USE in cm3.cfg
>
> Quoting Jay > >>> <jayk123 at hotma=> >>> il.com>:
>
> > using this code on PPC_LINUX > >>> and PPC_DARW=> >>> IN (should be called
> > PPC_MACOSX but oh well) > >>>
>
>=> >>> Actually I did the port on a plain DARWIN system from > >>> opendarwin.org
&g=> >>> t; when this was still alive. So there should be no dependency on > >>> MacOS X >>> R>> extensions.
>
> 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 2=> >>> 345 869 fax: +49 30 23 45 86 95
> http://www.elegosoft.com > >>> | Gesch=E4=> >>> ftsf=FChrer: Olaf Wagner | Sitz: Berlin
> Handelregister: > >>> Amtsgericht=> >>> Charlottenburg HRB 77719 | USt-IdNr: DE163214194
> > >>>


>>> />Helping your favorite cause is as easy as instant > >>> messaging.=A0You IM, w=> >>> e give. >>> source=3Dtext_hotm=> >>> ail_join' target=3D'_new'>Learn more.> >>> => >>>> >>> --_587094ee-5029-41f3-88b0-f4a35ad4e834_--> _________________________________________________________________ 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 Jan 25 16:14:06 2008 From: jayk123 at hotmail.com (Jay) Date: Fri, 25 Jan 2008 15:14:06 +0000 Subject: [M3devel] INSTALL_ROOT and PKG_USE in cm3.cfg In-Reply-To: References: <4798DEB8.1E75.00D7.1@scires.com> <4798EFAE.1E75.00D7.1@scires.com> <4798FE0E.1E75.00D7.1@scires.com> <479907A8.1E75.00D7.1@scires.com> <4799283C.1E75.00D7.1@scires.com> <20080125110959.5oc8u98w0w8csc80@mail.elegosoft.com> <20080125133649.vq9xj54iqok00so0@mail.elegosoft.com> Message-ID: truncated again! > From: jayk123 at hotmail.com> To: wagner at elegosoft.com> Date: Fri, 25 Jan 2008 15:07:20 +0000> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] INSTALL_ROOT and PKG_USE in cm3.cfg> > > I'm with you that they are neither systematic nor intuitive.> I think I could even be persuaded to support a general renaming,> if the scheme and concepts are well considered before.> Uh oh...> [big ramble...]> > Darwin: I was surprised, but I understood.> > I know a lot of the history and I get it.> I used the LINUXELF port briefly, or maybe the LINUX (a.out) one.> I guess hypothetically you can still boot LINUX 1.2 on either modern hardware or VMs??????> Anyone reporting 10 year uptimes??> > Unix ABI: I'm surprised the compat is so bad. Microsoft does an excellent job of ABI compat, but behavioral compat is another matter.> > > Yes. Actually the X in X Windows and MacOS X refer to completely different> things. MacOS X does not support X Windows out of the box, it uses> Aqua as GUI.> I understand. I believe Aqua is mostly just a marketing term even.> Apple's got a bazillion different libraries to do the same thing.> Want to draw on the screen -- QuickDraw (deprecated) or CoreGraphics, OpenGL..> Want to have a text editor -- TextEdit, MSLTE, and something else, and third party like "WASTE".> Want to get a mouse click -- there's two event managers.> Want to open a file -- there's like four or more sets of APIs -- FSSpec, FSRef, stdio, unixio, maybe something in Cocoa.> Even in the kernel they have multiple frameworks I believe.> It appears to be a big random mishmash.> They had two APIs for LoadLibrary/GetProcAddress, and then later add dlopen _________________________________________________________________ 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 Jan 25 16:21:26 2008 From: jayk123 at hotmail.com (Jay) Date: Fri, 25 Jan 2008 15:21:26 +0000 Subject: [M3devel] FW: INSTALL_ROOT and PKG_USE in cm3.cfg In-Reply-To: <20080125133649.vq9xj54iqok00so0@mail.elegosoft.com> References: <4798DEB8.1E75.00D7.1@scires.com> <4798EFAE.1E75.00D7.1@scires.com> <4798FE0E.1E75.00D7.1@scires.com> <479907A8.1E75.00D7.1@scires.com> <4799283C.1E75.00D7.1@scires.com> <20080125110959.5oc8u98w0w8csc80@mail.elegosoft.com> <20080125133649.vq9xj54iqok00so0@mail.elegosoft.com> Message-ID: This was truncated, and there is a little of value perhaps...except probably just leave all the targets alone and focus on the much less disruptive decision for how to name all the many future targets. :) and the more productive work of bringing them up (I'm thinking, after NT386GNUish stuff, of looking into PPC_{NETBSD,OPENBSD} or NBSD,OBSD. I've got the hardware and the CDs at least.. and then if I'm feeling crazy, X86_DJGPP aka X86_MSDOS or such, and then X86_SOLARIS maybe..I've got X86 and PPC32 you see, grasping at where to go...oh, and AMD64_NT, AMD64_SOLARIS does that exist? Might have to get a new machine for that, but as long as its available in laptop form factor I'm game. (AMD64_F|N|OBSD too, I wonder if AMD64_DJGPP will materialize :) oh but this takes wasting money but AMD64_DARWIN; OLPC is en route but I don't think that merits work, it's just X86_LINUX, I mean LINUXLIBC6.. :) ). No idea how far I'll get here but they are thoughts at least. And fix the Pixmap bug... I basically below just agree with what Olaf already said -- processor-os-variant. Variant is "random", but doing better is probably impossible, and variant is bound to be needed somewhere sometime. And it can be empty so no harm. - Jay From: jayk123 at hotmail.comTo: wagner at elegosoft.comCC: m3devel at elegosoft.comSubject: RE: [M3devel] INSTALL_ROOT and PKG_USE in cm3.cfgDate: Fri, 25 Jan 2008 15:07:20 +0000 > I'm with you that they are neither systematic nor intuitive.> I think I could even be persuaded to support a general renaming,> if the scheme and concepts are well considered before.Uh oh...[big ramble...] Darwin: I was surprised, but I understood. I know a lot of the history and I get it.I used the LINUXELF port briefly, or maybe the LINUX (a.out) one.I guess hypothetically you can still boot LINUX 1.2 on either modern hardware or VMs??????Anyone reporting 10 year uptimes?? Unix ABI: I'm surprised the compat is so bad. Microsoft does an excellent job of ABI compat, but behavioral compat is another matter. > Yes. Actually the X in X Windows and MacOS X refer to completely different> things. MacOS X does not support X Windows out of the box, it uses> Aqua as GUI.I understand. I believe Aqua is mostly just a marketing term even.Apple's got a bazillion different libraries to do the same thing.Want to draw on the screen -- QuickDraw (deprecated) or CoreGraphics, OpenGL..Want to have a text editor -- TextEdit, MSLTE, and something else, and third party like "WASTE".Want to get a mouse click -- there's two event managers.Want to open a file -- there's like four or more sets of APIs -- FSSpec, FSRef, stdio, unixio, maybe something in Cocoa.Even in the kernel they have multiple frameworks I believe.It appears to be a big random mishmash.They had two APIs for LoadLibrary/GetProcAddress, and then later add dlopen.A lot of this is historical too.They have history back to the early 1980s and they have migration story after migration story after migration story, gradually breaking all existing source code and binaries, but never eveything quite at once. At this point, nothing produced before around the year 2000 can run on an Intel Mac or a PowerPC Mac running 10.5. 10.4 on PowerPC could run stuff going way way back -- 68K even. People used to have access to video memory at fixed addresses, "low memory globals" all kinds of crazy stuff. (Really, I understand -- MacOS X is 10 or Unix. I don't know how/if they are ever going to get to 11. They were up to about version 10 via gradual incrementing through the years. System 7 was a breathrough kind of in the late 80's early 90's, System 7.1ish when the PPC came out in 1994, gradually up to around 7.5, then rapidly through 8 and 9 when Jobs returned before they release Mac OS X. I know a lot here..it's annoying... We had "fat Mac" circa 1984/1985 with 512meg and two floppy drives, a 68020 Mac II, etc.If you see the movie The Firm, when lawyer/actionhero Tom Cruise uses his computer, it plays the Mac floppy disk noise.)And by breathrough, I mean it actually sucked. They had no or nearly no protected memory user/kernel split until this century. Shared library sorts of things were loaded completely into memory at boot time generally. Microsoft beat them by 5+ years, Unix beat by far more. But now it's a fairly level playing field -- everyone has about the same architecture. Except all the low end (free) Unixes seemed to take forever to admit they needed threads, and I doubt any of them scale well. I think they resisted just to avoid being like NT, waiting and waiting and finally giving in, thus some of the ABI issues, no threads, "Linux threads", and finally NPTL -- native pthreads library -- kernel threads. And just when everyone arrived at the same place, along comes web apps distributed across a cluster, too many cores per chip for anyone to schedule... [editing has ripped things away from what they related oh well...] You can have all the smarts you want about your workload and manually schedule (fibers, vtalarm threads), but you'll never likely be able to control what CPU you are on and thus you will generally lose, unless there is only one CPU. I kind of assume we (the larger we m3devel, but indeed, perhaps every pair of developers :) ) would never be able to agree on names. I think the easiest to agree to plan is to leave it alone.But, um, I agree! If we, um, could agree on a scheme and set of names, I'd go for it.I am a little more optimistic than this...but I hesitate, briefly, to suggest... The GNU folks have a system, of triples or more recently quadruples.Something like processor-'hardware'-kernel, I forget and can't look now.'hardware' seems to be 'unknown' or 'pc' a bunch, so I don't know what it is.uname seems to be the ingredients of most of this.i686-pc-cygwini686-pc-nti686-pc-linuxppc-mac-darwin?ppc-mac-classic68k-mac-classic I figure to vet the design it helps to come up with many examples, even of platforms that don't matter.Maybe even to deal with the msdos mess, could be 16bit, 286, 386.. I agree with you that a double seems to almost always suffice. If you look at the existing names (from memory), I think you can derive something like:{X86,AMD64,PPC,PPC64,ALPHA,MIPS,ARM,SH,SPARC,68K,VAX,IA64,HPPA}_{LINUX,SOLARIS,NT,OSF1,OS2,NEXT,MSDOS,VMS,Mac,OldMac,AIX,HPUX,FreeBSD,NetBSD,OpenBSD} and cover almost the whole problem. This doesn't address the elephants that seems to have finally left the room -- compiler, linker, window library, thread library, C library, modula-3 backend. Probably most platforms should be a 2-tuple but there should guidance on how to build n-tuples.?? x86-nt-msc-mslink-msgui-kthr-msvcr -- native just call it x86-nt ?x86-nt-gcc-gld-msgui-kthr-msvcr -- mingwinx86-nt-gcc-gld-xwin-kthr-cyg -- nt386gnux86-nt-gcc-gld-xwin-pthr-cyg -- nt386gnu with pthreadsx86-linux-gcc-gld-vga-nothr-newlibx86-linux-icc-glc-nowin-nptl-glibc -- icc Intel compilerx86-linux-gcc-gcc-qtopia-uthread-glibc These names are too long. The n-tuples open up many issues, such as variables that really almost never vary given what preceds them.Linux doesn't always use gcc, but almost.Or whether or not a configuration is link compatible with another.Varying the compiler tends not to break link compatibility, that isn't automatic, it isn't free i general, but the compiler authors usually make it so. You all can see if n-tuples matter for the vast majority of platforms, but they, perhaps matter for x86-nt.But there is a big huge out of this that is in place, as I have said many times.. platform is nt386, everything else is something else, a "configuration" perhaps. Perhaps there should be a few more quake variables specced that cm3 can/should know about. Perhaps all of the target dependencies should be moved into the configuration file?????? I think there's so little, it makes little difference either way. Perhaps the notion of target drops away entire in cm3 and it's all just configuration and has less meaning?I mean..you know, what is the meaning? it's jmpbuf size, it gcc configuration, it's build_dir, those strike me as the majority of what "target" means. alignment, integer-size (always 32...except alpha), whether to use the integrated backend, and if so, a few other variables. I haven't allowed for versions -- FreeBSD4, FreeBSD5, FreeBSD6. I also think, I hate to say, you might want to account for "fat binaries".On a Mac, you can build up for four architectures into one binary.x86,AMD64,PPC,PPC64.However that really strikes at my crazy cross idea and putting in .sh files that call out to the right binary.I heard NextStep/OpenStep ran on four architectures way back when -- 68k, x86, SPARC, HPPA, not to mention the variant the x86 variant that ran in NT (with gcc). Even Win32 lets you build hybrid 16bit/32bit or 16bit/64bit binaries, since there is an "MS-DOS" stub. This is why, of course, you end up with ad-hoc names. Because the extra variables are usually missing, and they vary differently depending on context, so just make up something. Perhaps you use the doubles I gave, and then you are allowed to append a dash and an arbitrary extra string.Oh, sorry, you already said that. You called it "variant". I guess that's it. {x86,AMD64,...}_{NT,SOLARIS,LINUX}{_optional variant} Here are some possible names from this system: X86_NT (WIN? MSWIN?)X86_NT_MINGNUX86_NT_GNUX86_SOLARISX86_SOLARIS_GNUSPARC_SOLARISSPARC_SOLARIS_GNUPPC_MACX86_MACAMD64_MACPPC64_MACIA64_VMSVAX_VMSALPHA_VMSMIPS_ULTRIXMIPS_IRIXIA64_NTAMD64_NTMIPS_NTPPC_NTPPC_XBOX ?X86_XBOX ?PPC_AIX (Is POWER interesting?)PPC601_AIX ?PPC603_AIX ?G3_MAC ?G4_MAC ?G5_MAC ?PPCG3_MAC ?PPCG4_MAC ? (doesn't run on G3)PPCG4_MAC ? (64 bit, lame names...)X86_MSDOS ?X86_DJGPP ? X86_NT_MWERKS ?X86_NT_DIGITALMARS ?X86_NT_SYMANTEC ?X86_NT_BORLAND ?C_NT ? outputs C code... hm. not right, C gets converted to something else.ALPHA_OSF1 ALPHA_TRU64 ?ALPHA32_NT ?X86_NT_WATCOM ?X86_WINCE ?ARM_WINCE ?ARM_CE ?ARM_MSCE ?ARM_SYMBIAN ?ARM_PALM ?ARM_PALMOS ?X86_BEOS ?68000_OLDMAC ?68020_OLDMAC ? Obviously the vast vast vast vast majority of these don't matter, but as I said it helps to see how a bunch of platforms work out to vet the design. I've held back from...6502_APPLEII, 65816_APPLEIIGS.. 6502_C64 :)65816_SNES ? (Super Nintendo game console) 6502_NES ? (Nintendo...)MIPS_PLAYSTATION ??_SONYPS2 ?PPC_SONYPS3 (Linux runs on this, and maybe previous) SH_DREAMCAST ? (NetBSD runs on this... as does CE)X86_XBOX ? MSBOX ?PPC_XBOX360 (or is it PPC64? Oh, and for these things, you probably need to say MS or LINUX)PPC_MSXBOX360PPC_?XBOX and maybe some virtual machine targets:JVM_ANY ?JAVA_ANY ?MSDOTNET_ANY ?MSIL_ANY ?LLVM_NT ? Is x86 generically named and people can tweak it. Or call it 686 or I686 and if anyone really has an old processor, they can still tweak and rename and keep the name. Sorry if this is all very annoying. I'm ok with doing nothing here. Ultimately as I said, there isn't even that much code involved, as I recall.It seems to me if you move about 50 lines of cm3 out of cm3 into quake, the matter becomes even less "important", because the config file would be the only thing that cared and would only need to make sense to itself. - Jay > Date: Fri, 25 Jan 2008 13:36:49 +0100> From: wagner at elegosoft.com> To: jayk123 at hotmail.com> CC: m3devel at elegosoft.com> Subject: RE: [M3devel] INSTALL_ROOT and PKG_USE in cm3.cfg> > I just wanted to point out why it's call PPC_DARWIN. Now that the> OpenDarwin project has closed down, it may indeed seem strange.> But many of the names can only be understood based on their history.> I'm with you that they are neither systematic nor intuitive.> I think I could even be persuaded to support a general renaming,> if the scheme and concepts are well considered before.> > Quoting Jay :> > > The PPC_DARWIN port has an optional dependency on X Windows..is that > > available for plain Darwin or only with Mac OS X?> > Yes. Actually the X in X Windows and MacOS X refer to completely different> things. MacOS X does not support X Windows out of the box, it uses> Aqua as GUI.> > > I was surprised by "Darwin", therefore would be.. :)> That's why I tried to explain it ;-)> > > LINUX, LINUXELF, LINUXLIBC6? Please.> > Couldn't Linux have been recycled for LINUXLIBC6?Does anyone have > > Linux 1.2 around?> > It could be done now, but it couldn't when it was created.> > > Are the older FreeBSD ABIs so inferior that it is worth having newer > > ones? They didn't have pthreads back then and they do now?> > There are ABI changes with every major release of FreeBSD (and also> Linux, Solaris, and other operating systems if I am not much mistaken).> Of course, everyone strives for compatibility of the often used and> most important interfaces, but there is a grey zone where data> structures common to the kernel and userland are touched, and they> need to be updated (in order to not hinder improvement) more often> than you'd think. If such an update annoys or disturbs users often> enough, new interface abstractions tend to appear that should> avoid the problem for future releases (for example, changes of the> jmp_buf structure break threading code --> new interfaces for thread> context access are defined). The M3 runtime is somewhat special and> differs from the C runtime in that it makes use of quite a number of not> always well-defined system interfaces. We also try to eliminate these> dependencies (VM calls, jmp_buf structure, whole threading, ...)> > Actually I think I was the first one to port any pthread package to> FreeBSD (when working for a company building POS solutions, but we could> never release the code) back in the 1.5 and 2.x days. I used a pthreads> implementation by Frank Mueller.> Official pthread support came much later.> > Olaf> -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194> Helping your favorite cause is as easy as instant messaging. You IM, we give. Learn more. _________________________________________________________________ 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 Jan 25 16:41:31 2008 From: jayk123 at hotmail.com (Jay) Date: Fri, 25 Jan 2008 15:41:31 +0000 Subject: [M3devel] m3devel vs. m3support? In-Reply-To: <20080125133649.vq9xj54iqok00so0@mail.elegosoft.com> References: <4798DEB8.1E75.00D7.1@scires.com> <4798EFAE.1E75.00D7.1@scires.com> <4798FE0E.1E75.00D7.1@scires.com> <479907A8.1E75.00D7.1@scires.com> <4799283C.1E75.00D7.1@scires.com> <20080125110959.5oc8u98w0w8csc80@mail.elegosoft.com> <20080125133649.vq9xj54iqok00so0@mail.elegosoft.com> Message-ID: I noticed at the end of the Ubuntu instructions: "see m3-support for help" Which got me thinking: Is m3devel for developers who USE m3, or the developers OF m3. I'm not sure. In particular, is it lower level, discussing how to bring up new targets, how to change the compiler or higher level help with learning the language? Is m3support for support of developers who use m3 (as indicated above), or for infrastructure support for developer OF m3, like fixing networking connectivity to birch or unusual stuff like that? I thought it was the second. AND/OR m3devel is both, if you were to split in half, you'd only have 2 people on each list and you wouldn't need a list? :) (somewhat the small community is a bonus for me, fewer people to piss off if I make a mistake, somewhat it is depressingly small...) - 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 wagner at elegosoft.com Fri Jan 25 18:02:37 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 25 Jan 2008 18:02:37 +0100 Subject: [M3devel] m3devel vs. m3support? In-Reply-To: References: <4798DEB8.1E75.00D7.1@scires.com> <4798EFAE.1E75.00D7.1@scires.com> <4798FE0E.1E75.00D7.1@scires.com> <479907A8.1E75.00D7.1@scires.com> <4799283C.1E75.00D7.1@scires.com> <20080125110959.5oc8u98w0w8csc80@mail.elegosoft.com> <20080125133649.vq9xj54iqok00so0@mail.elegosoft.com> Message-ID: <20080125180237.xderhsyo00wgksgo@mail.elegosoft.com> Quoting Jay : > I noticed at the end of the Ubuntu instructions: > "see m3-support for help" > > Which got me thinking: > > Is m3devel for developers who USE m3, or the developers OF m3. > I'm not sure. In particular, is it lower level, discussing how to > bring up new targets, how to change the compiler > or higher level help with learning the language? > > Is m3support for support of developers who use m3 (as indicated > above), or for infrastructure support for developer OF m3, like > fixing networking connectivity to birch or unusual stuff like that? > I thought it was the second. > > AND/OR m3devel is both, if you were to split in half, you'd only > have 2 people on each list and you wouldn't need a list? :) > > (somewhat the small community is a bonus for me, fewer people to > piss off if I make a mistake, somewhat it is depressingly small...) m3devel was created for developers of M3 and developers using M3. It's a rather technical group. You need to subscribe to it to be able to post. m3-support is (currently) an Elego-internal list of M3-capable users willing to help anybody running into problems with the system. It is basically just a sendmail alias as far as I know, so everybody can freely send mail to it. There is no archive of the mails (or I don't know of it). m3-support is used on all the M3 WWW pages. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Sat Jan 26 07:11:28 2008 From: mika at async.caltech.edu (Mika Nystrom) Date: Fri, 25 Jan 2008 22:11:28 -0800 Subject: [M3devel] INSTALL_ROOT and PKG_USE in cm3.cfg In-Reply-To: Your message of "Fri, 25 Jan 2008 13:36:49 +0100." <20080125133649.vq9xj54iqok00so0@mail.elegosoft.com> Message-ID: <200801260611.m0Q6BS8r045276@camembert.async.caltech.edu> >> LINUX, LINUXELF, LINUXLIBC6? Please. >> Couldn't Linux have been recycled for LINUXLIBC6?Does anyone have >> Linux 1.2 around? > >It could be done now, but it couldn't when it was created. Please don't recycle the names. That's just dumb. More people than you'd think use old hardware and software for reasons that may be out of their control. Mika From jayk123 at hotmail.com Sat Jan 26 10:13:35 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 26 Jan 2008 09:13:35 +0000 Subject: [M3devel] INSTALL_ROOT and PKG_USE in cm3.cfg In-Reply-To: <200801260611.m0Q6BS8r045276@camembert.async.caltech.edu> References: Your message of "Fri, 25 Jan 2008 13:36:49 +0100." <20080125133649.vq9xj54iqok00so0@mail.elegosoft.com> <200801260611.m0Q6BS8r045276@camembert.async.caltech.edu> Message-ID: I'm on the fence. People always miss that changing new software doesn't necessarily impact old software/hardware. Do the LINUX/LINUXELF targets still work? Will they ever again? If they did, couldn't they be renamed as well? X86_LINUX (LINUXLIBC6) X86_LINUX1 or X86_LINUX1_ELF X86_LINUX1_AOUT 1 as in kernel 1.x Or possibly even merged with one and only X86_LINUX and just vary in the configuration file. (Does the codegen even vary across these architectures, or just the the linking options and maybe file format output by as?) Name evolution is tough. There's often some ideal short name Foo and then only in the future you realize you have to differentiate NewAndImprovedFoo or FooX or Foo2 from Foo aka FooClassic aka Foo1 aka OldFoo. FooSr, FooJr, FooIII. Historical records I think are the bigger sale. But sometimes you are just left with cruft upon cruft upon cruft for some hypothetical compat. In this case, it's not a big deal. - Jay > To: wagner at elegosoft.com> Date: Fri, 25 Jan 2008 22:11:28 -0800> From: mika at async.caltech.edu> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] INSTALL_ROOT and PKG_USE in cm3.cfg> > >> LINUX, LINUXELF, LINUXLIBC6? Please.> >> Couldn't Linux have been recycled for LINUXLIBC6?Does anyone have > >> Linux 1.2 around?> >> >It could be done now, but it couldn't when it was created.> > Please don't recycle the names. That's just dumb. More people> than you'd think use old hardware and software for reasons that may> be out of their control.> > Mika _________________________________________________________________ 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 Sun Jan 27 15:03:27 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Sun, 27 Jan 2008 15:03:27 +0100 Subject: [M3devel] Open CM3 regression tests In-Reply-To: <9C00EA97-9B43-43BE-9CDF-EEAC9C1321D5@cs.purdue.edu> References: <20080120211832.GA26993@elegosoft.com> <9C00EA97-9B43-43BE-9CDF-EEAC9C1321D5@cs.purdue.edu> Message-ID: <20080127150327.mh686v2hx4w080w4@mail.elegosoft.com> Quoting Tony Hosking : > The set operations are all coded as external C functions -- should be > easy enough to fix those. Or are there type issues too? Sorry for the long delay. I'm afraid I don't really understand how set operations are implemented after a quick look. I thought it was all done in the Word modules, but these seem to be only self-referring M3 definitions. I'm sure you can point me to the correct location for the >= operation faster than I'll need to find it; I'll have a look at it then. Thanks in advance, Olaf >> --- p155 --- operations on small sets >> --- p1/p155/stderr.pgm 2008-01-20 00:48:16.000000000 +0100 >> +++ ../src/p1/p155/stderr.pgm 2008-01-13 00:55:56.000000000 +0100 >> @@ -2,7 +2,6 @@ >> check set q = {} >> check set r = {a, b} >> check set x = {a, b, e} >> -************************ ERROR: check (NOT (p >= x)) failed >> >>> This concerns the >= operation on sets. The language definition >>> says: >>> >>> infix <=, >= (x,y: Ordinal) : BOOLEAN >>> (x,y: Float) : BOOLEAN >>> (x,y: ADDRESS) : BOOLEAN >>> (x,y: Set) : BOOLEAN >>> >>> In the first three cases, <= returns TRUE if x is at most as large as >>> y. In the last case, <= returns TRUE if every element of x is an >>> element of y. In all cases, it is a static error if the type of x is >>> not assignable to the type of y, or vice versa. The expression x >= y >>> is equivalent to y <= x. >>> >>> So the implementation seems to be plainly wrong. I think the test >>> for the previous operation <= only succeeds accidentally. -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Jan 27 15:26:35 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Sun, 27 Jan 2008 15:26:35 +0100 Subject: [M3devel] Open CM3 regression tests In-Reply-To: References: <20080120211832.GA26993@elegosoft.com> Message-ID: <20080127152635.91rtdsvgsoo4080g@mail.elegosoft.com> Quoting Henning Thielemann : > On Sun, 20 Jan 2008, Olaf Wagner wrote: > >> > no errors for p1 to p115 >> >> --- p116b --- default IEEE floating point tests from Xerox PARC >> --- p1/p116b/stderr.pgm 2008-01-20 00:47:20.000000000 +0100 >> +++ ../src/p1/p116b/stderr.pgm 2008-01-13 00:55:55.000000000 +0100 > > My compiler complains about LONGINT type in src/Test.i3 . I assume that > this is the 64 bit support. Seems that I have to upgrade my compiler. > > In general floating point is a strange issue. You cannot rely on that your > machine supports IEEE format, although most machines do. The precision of > the same float type can be different on different machines. However, the > Float modules shall reflect that. Computation with NaN and Infinity is > broken, it should be avoided and in most cases continueing the computation > with NaN or Infinity only hides the precise error location. It would be > better to abort with an error for a division by zero, overflow and so on. > I think one can enable this with FloatModes. I don't really understand the consequences of what you say above: are the tests wrong and should be adapted, or is the implementation broken for IEEE-default (where most of the FloatMode procedures simply raise exceptions; if so, can we fix that for these platforms), or do we simply rely on broken hardware (x86 floating point processors)? It seems that FloatMode is only implemented for very few targets: DS3100 DS3100_OSF IRIX5 SOLsun SPARC SUN386 VAX. All the others use the default. Will we simply have to implement the missing functionality for all platforms? If so, can e.g. SUN386 be easily adapted to other x86 platforms (FreeBSD4, LINUXLIBC6, I386_DARWIN, NetBSD2_i386)? That would be a start. As I said, I'm no expert in this domain, and would rather rely on others knowledge there. If you don't have a compiler that is up-to-date, you can always use workspaces on birch.elegosoft.com for tests. The regression tests on this machine use CM3 installations at m3 at birch:~/cm3$ ls /home/m3/work/cm3-inst/birch.elegosoft.com/ current last-ok prev-ok rel-5.4.0. If you don't have login access but need it, just let me know. Of course this applies to everybody wanting to work on the tests or other improvements (as long as there aren't hundreds of requests at least :-). Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Sun Jan 27 15:52:04 2008 From: mika at async.caltech.edu (Mika Nystrom) Date: Sun, 27 Jan 2008 06:52:04 -0800 Subject: [M3devel] Open CM3 regression tests In-Reply-To: Your message of "Sun, 27 Jan 2008 15:26:35 +0100." <20080127152635.91rtdsvgsoo4080g@mail.elegosoft.com> Message-ID: <200801271452.m0REq4Oi093531@camembert.async.caltech.edu> Olaf Wagner writes: ... >I don't really understand the consequences of what you say above: >are the tests wrong and should be adapted, or is the implementation >broken for IEEE-default (where most of the FloatMode procedures simply >raise exceptions; if so, can we fix that for these platforms), or do >we simply rely on broken hardware (x86 floating point processors)? > >It seems that FloatMode is only implemented for very few targets: >DS3100 DS3100_OSF IRIX5 SOLsun SPARC SUN386 VAX. All the others use >the default. Will we simply have to implement the missing functionality >for all platforms? If so, can e.g. SUN386 be easily adapted to other >x86 platforms (FreeBSD4, LINUXLIBC6, I386_DARWIN, NetBSD2_i386)? >That would be a start. Hmm this reminds me of something I read a long time ago. My recollection is that what we have is effectively the second implementation of floating point in Modula-3. At some point during the design, I think someone talked to Bill Kahan, and he (or someone like him) persuaded them that the only right way to do floating-point is to provide an interface for turning on and off floating point exceptions. I believe that at least on DS3100, the floating point exceptions (if enabled) are actually turned into bona fide, catch-able, Modula-3 exceptions. It's a little odd because I suppose you can have code like this... TRY x := a/b EXCEPT SomeFloatingException ... END even though no exceptions are declared to be RAISEd anywhere... I think very few programming languages actually support IEEE754 the way Kahan originally envisioned it. Modula-3 on DS3100 is one of the few that actually approach the original intent (most of the others have "fortran" somewhere in their names, and usually only accomplish the goal with compiler flags). It would be very neat if this work could be extended to the modern targets. x86 FP also isn't really that broken---the 8087 was actually to some extent the reference implementation of IEEE754. It works fine if you write back the results between operations. The problem is that it uses higher (EXTENDED) precision internally, so if you keep intermediate values in FP registers you get smaller rounding errors than expected. It's mainly a problem if you are doing step-by-step comparison debugging with an x86 and a non-x86 and you can't somehow tell your compiler to flush intermediate results to memory. Mika From hosking at cs.purdue.edu Sun Jan 27 16:36:04 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 27 Jan 2008 10:36:04 -0500 Subject: [M3devel] Open CM3 regression tests In-Reply-To: <20080127150327.mh686v2hx4w080w4@mail.elegosoft.com> References: <20080120211832.GA26993@elegosoft.com> <9C00EA97-9B43-43BE-9CDF-EEAC9C1321D5@cs.purdue.edu> <20080127150327.mh686v2hx4w080w4@mail.elegosoft.com> Message-ID: <1DA9FA59-6DFF-430C-90C5-F1D30003607A@cs.purdue.edu> The set operations are coded in cm3/m3-libs/m3core/src/Csupport/ Common/hand.c. I notice Jay has made a number of changes here since September -- I wonder if they have broken something. On Jan 27, 2008, at 9:03 AM, Olaf Wagner wrote: > Quoting Tony Hosking : >> The set operations are all coded as external C functions -- should be >> easy enough to fix those. Or are there type issues too? > > Sorry for the long delay. I'm afraid I don't really understand how > set operations are implemented after a quick look. I thought it was > all done in the Word modules, but these seem to be only self-referring > M3 definitions. I'm sure you can point me to the correct location for > the >= operation faster than I'll need to find it; I'll have a look at > it then. > > Thanks in advance, > > Olaf > >>> --- p155 --- operations on small sets >>> --- p1/p155/stderr.pgm 2008-01-20 00:48:16.000000000 +0100 >>> +++ ../src/p1/p155/stderr.pgm 2008-01-13 00:55:56.000000000 +0100 >>> @@ -2,7 +2,6 @@ >>> check set q = {} >>> check set r = {a, b} >>> check set x = {a, b, e} >>> -************************ ERROR: check (NOT (p >= x)) failed >>> >>>> This concerns the >= operation on sets. The language definition >>>> says: >>>> >>>> infix <=, >= (x,y: Ordinal) : BOOLEAN >>>> (x,y: Float) : BOOLEAN >>>> (x,y: ADDRESS) : BOOLEAN >>>> (x,y: Set) : BOOLEAN >>>> >>>> In the first three cases, <= returns TRUE if x is at most as >>>> large as >>>> y. In the last case, <= returns TRUE if every element of x is an >>>> element of y. In all cases, it is a static error if the type of >>>> x is >>>> not assignable to the type of y, or vice versa. The expression x >>>> >= y >>>> is equivalent to y <= x. >>>> >>>> So the implementation seems to be plainly wrong. I think the test >>>> for the previous operation <= only succeeds accidentally. > > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, > Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 > 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: > Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > DE163214194 > From roland.illig at gmx.de Sun Jan 27 17:23:02 2008 From: roland.illig at gmx.de (Roland Illig) Date: Sun, 27 Jan 2008 17:23:02 +0100 Subject: [M3devel] reactor: catalyst vs cm3-ide In-Reply-To: <479223AC.1E75.00D7.1@scires.com> References: <479223AC.1E75.00D7.1@scires.com> Message-ID: <479CAFE6.8050601@gmx.de> Randy Coleburn wrote: > Ok, I've gotten some feedback on the new name for reactor. > > I've attached a PDF that has two pages: one depicts use of Catalyst, > the other CM3-IDE. > > Please let me know which you prefer. If these are going to become logos of any kind, I don't like them both. - They use lots of different font shapes and sizes. This makes the image rather complicated. A logo should use at most one font shape. - There are lots of components in the logo. To view them all, it takes a long time. A logo should be as simple that one can recognize it at a glance. - What does the battery have to do with Modula-3? - How does it relate to the light bulb? - What does the "With Power" on the light bulb mean? Is it important for the logo? - Is there any prior art for these kinds of logos? Roland From dmuysers at hotmail.com Sun Jan 27 18:02:05 2008 From: dmuysers at hotmail.com (Dirk Muysers) Date: Sun, 27 Jan 2008 18:02:05 +0100 Subject: [M3devel] reactor: catalyst vs cm3-ide In-Reply-To: <479223AC.1E75.00D7.1@scires.com> <479CAFE6.8050601@gmx.de> References: <479223AC.1E75.00D7.1@scires.com> <479CAFE6.8050601@gmx.de> Message-ID: What others have done along the same lines: Have a look at the Cocotron (http://www.cocotron.org/Info) -------------------------------------------------- From: "Roland Illig" Sent: Sunday, January 27, 2008 5:23 PM To: "Randy Coleburn" Cc: Subject: Re: [M3devel] reactor: catalyst vs cm3-ide > Randy Coleburn wrote: >> Ok, I've gotten some feedback on the new name for reactor. >> I've attached a PDF that has two pages: one depicts use of Catalyst, >> the other CM3-IDE. >> Please let me know which you prefer. > > If these are going to become logos of any kind, I don't like them both. > > - They use lots of different font shapes and sizes. This makes the image > rather complicated. A logo should use at most one font shape. > > - There are lots of components in the logo. To view them all, it takes a > long time. A logo should be as simple that one can recognize it at a > glance. > > - What does the battery have to do with Modula-3? > > - How does it relate to the light bulb? > > - What does the "With Power" on the light bulb mean? Is it important for > the logo? > > - Is there any prior art for these kinds of logos? > > Roland > From wagner at elegosoft.com Sun Jan 27 18:55:30 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Sun, 27 Jan 2008 18:55:30 +0100 Subject: [M3devel] Open CM3 regression tests In-Reply-To: <1DA9FA59-6DFF-430C-90C5-F1D30003607A@cs.purdue.edu> References: <20080120211832.GA26993@elegosoft.com> <9C00EA97-9B43-43BE-9CDF-EEAC9C1321D5@cs.purdue.edu> <20080127150327.mh686v2hx4w080w4@mail.elegosoft.com> <1DA9FA59-6DFF-430C-90C5-F1D30003607A@cs.purdue.edu> Message-ID: <20080127185530.e255i76vcwckss4o@mail.elegosoft.com> Quoting Tony Hosking : > The set operations are coded in > cm3/m3-libs/m3core/src/Csupport/Common/hand.c. > > I notice Jay has made a number of changes here since September -- I > wonder if they have broken something. I tried different revisions of this file with no difference in the test results. I then took the latest version and added some printfs, and they got never displayed. So I checked what gets linked, but the symbols in question don't occur in the test program: % nm hand.o U __divdi3 U __moddi3 000001e0 R _highbits 00000140 R _lowbits 00000000 T m3_div 000000ac T m3_divL 000001d4 T m3_mod 0000026c T m3_modL U printf 00000494 T set_difference 00000554 T set_eq 0000061c T set_ge 000006ac T set_gt 00000434 T set_intersection 0000077c T set_le 0000080c T set_lt 000003a8 T set_member 000005b8 T set_ne 000008d8 T set_range 000009d8 T set_singleton 000004f4 T set_sym_difference 000003d4 T set_union % nm /usr/local/cm3/pkg/m3core/FreeBSD4/libm3core.so.5 | grep set_ 000243d0 T set_difference 00024490 T set_eq 00024558 T set_ge 000245fc T set_gt 00024370 T set_intersection 000246e0 T set_le 00024784 T set_lt 000242e4 T set_member 000244f4 T set_ne 00024864 T set_range 00024998 T set_singleton 00024430 T set_sym_difference 00024310 T set_union % ldd FreeBSD4/p1/p155/FreeBSD4/pgm FreeBSD4/p1/p155/FreeBSD4/pgm: libtest.so.5 => /d/home/wagner/work/cm3/m3-sys/m3tests/FreeBSD4/libtest.so.5 (0x28085000) libm3.so.5 => /usr/local/cm3/pkg/libm3/FreeBSD4/libm3.so.5 (0x28088000) libm3core.so.5 => /usr/local/cm3/pkg/m3core/FreeBSD4/libm3core.so.5 (0x281aa000) libm.so.4 => /lib/libm.so.4 (0x28a2d000) libpthread.so.2 => /lib/libpthread.so.2 (0x28a46000) libc.so.6 => /lib/libc.so.6 (0x28a6a000) % nm /usr/local/cm3/pkg/m3core/FreeBSD4/libm3core.so.5 | grep set_ 000243d0 T set_difference 00024490 T set_eq 00024558 T set_ge 000245fc T set_gt 00024370 T set_intersection 000246e0 T set_le 00024784 T set_lt 000242e4 T set_member 000244f4 T set_ne 00024864 T set_range 00024998 T set_singleton 00024430 T set_sym_difference 00024310 T set_union luthien [~/work/cm3/m3-sys/m3tests] wagner % ldd FreeBSD4/p1/p155/FreeBSD4/pgm FreeBSD4/p1/p155/FreeBSD4/pgm: libtest.so.5 => /d/home/wagner/work/cm3/m3-sys/m3tests/FreeBSD4/libtest.so.5 (0x28085000) libm3.so.5 => /usr/local/cm3/pkg/libm3/FreeBSD4/libm3.so.5 (0x28088000) libm3core.so.5 => /usr/local/cm3/pkg/m3core/FreeBSD4/libm3core.so.5 (0x281aa000) libm.so.4 => /lib/libm.so.4 (0x28a2d000) libpthread.so.2 => /lib/libpthread.so.2 (0x28a46000) libc.so.6 => /lib/libc.so.6 (0x28a6a000) luthien [~/work/cm3/m3-sys/m3tests] wagner % nm -C -u FreeBSD4/p1/p155/FreeBSD4/pgm U Main_I3 U RTHooks_I3 U RTHooks__CheckLoadTracedRef U RTHooks__Concat U RTHooks__PopEFrame U RTHooks__PushEFrame U RTHooks__TextLitGetChar U RTHooks__TextLitGetChars U RTHooks__TextLitGetWideChar U RTHooks__TextLitGetWideChars U RTHooks__TextLitInfo U RTLinker__AddUnit U RTLinker__InitRuntime U RTProcess__Exit U Stdio_I3 U Test_I3 U Test__checkM U Test__done U Wr_I3 U Wr__Flush U Wr__PutText w _Jv_RegisterClasses w __deregister_frame_info w __register_frame_info U _init_tls U _setjmp U atexit U exit Now I'm rather confused 8-/ Any ideas? Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From rcoleburn at scires.com Sun Jan 27 18:59:32 2008 From: rcoleburn at scires.com (Randy Coleburn) Date: Sun, 27 Jan 2008 12:59:32 -0500 Subject: [M3devel] reactor: catalyst vs cm3-ide In-Reply-To: <479CAFE6.8050601@gmx.de> References: <479223AC.1E75.00D7.1@scires.com> <479CAFE6.8050601@gmx.de> Message-ID: <479C8034.1E75.00D7.1@scires.com> Hi Roland: Thanks for your feedback and to the other folks that responded. At this point, I've elected to go with the CM3-IDE name instead of Catalyst. Despite the fact that several folks like "Catalyst" (it is a more catchy name and easier to pronounce), it did not intuitively convey the purpose of the program and it conflicts with another trademarked name in the industry. As for the graphics, I'm not a trained graphic artist or logo designer. I just tried to put something together that would satisfy the license requirements so we could make this software package available to the community. One of the conditions was that we remove use of the prior trademarked name and logo/graphic. Back a few years ago, Olly Stephens came up with the idea of using the battery theme to show the "power" of Modula-3. In trying to come up with something for CM3-IDE, I went back to Olly's battery theme and embellished it a bit. Here is the message that I was trying to convey: The CM3-IDE light bulb is powered by the Modula-3 battery to perform great things for the developer, including creating, building, running, maintaining, and browsing source code packages. Once we get the CM3-IDE package into the repository, the CM3 community is welcome to improve it and change any of the graphics. I will be putting all of my original artwork in the repository to provide a starting point for anyone who wants to modify the graphics. The original art work was done in Microsoft PowerPoint 2003 and exported to TIF format, then cropped, resized, and converted to GIF as needed for use in the application. I used IrfanView to do the conversions and manipulations from TIF to GIF. An announcement will go out on the m3devel news list as soon as the package has been put in the repository. I am working to finalize the arrangements this week so hopefully you will see it real soon. Regards, Randy >>> Roland Illig 1/27/2008 11:23 AM >>> Randy Coleburn wrote: > Ok, I've gotten some feedback on the new name for reactor. > > I've attached a PDF that has two pages: one depicts use of Catalyst, > the other CM3-IDE. > > Please let me know which you prefer. If these are going to become logos of any kind, I don't like them both. - They use lots of different font shapes and sizes. This makes the image rather complicated. A logo should use at most one font shape. - There are lots of components in the logo. To view them all, it takes a long time. A logo should be as simple that one can recognize it at a glance. - What does the battery have to do with Modula-3? - How does it relate to the light bulb? - What does the "With Power" on the light bulb mean? Is it important for the logo? - Is there any prior art for these kinds of logos? Roland -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Sun Jan 27 21:31:00 2008 From: jayk123 at hotmail.com (Jay) Date: Sun, 27 Jan 2008 20:31:00 +0000 Subject: [M3devel] Open CM3 regression tests In-Reply-To: <20080127185530.e255i76vcwckss4o@mail.elegosoft.com> References: <20080120211832.GA26993@elegosoft.com> <9C00EA97-9B43-43BE-9CDF-EEAC9C1321D5@cs.purdue.edu> <20080127150327.mh686v2hx4w080w4@mail.elegosoft.com> <1DA9FA59-6DFF-430C-90C5-F1D30003607A@cs.purdue.edu> <20080127185530.e255i76vcwckss4o@mail.elegosoft.com> Message-ID: The functions are only used if the set doesn't fit in an integer. I'll try to look at this today. - Jay > Date: Sun, 27 Jan 2008 18:55:30 +0100> From: wagner at elegosoft.com> To: hosking at cs.purdue.edu> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] Open CM3 regression tests> > Quoting Tony Hosking :> > > The set operations are coded in > > cm3/m3-libs/m3core/src/Csupport/Common/hand.c.> >> > I notice Jay has made a number of changes here since September -- I> > wonder if they have broken something.> > I tried different revisions of this file with no difference in the> test results. I then took the latest version and added some printfs,> and they got never displayed. So I checked what gets linked, but the> symbols in question don't occur in the test program:> > % nm hand.o> U __divdi3> U __moddi3> 000001e0 R _highbits> 00000140 R _lowbits> 00000000 T m3_div> 000000ac T m3_divL> 000001d4 T m3_mod> 0000026c T m3_modL> U printf> 00000494 T set_difference> 00000554 T set_eq> 0000061c T set_ge> 000006ac T set_gt> 00000434 T set_intersection> 0000077c T set_le> 0000080c T set_lt> 000003a8 T set_member> 000005b8 T set_ne> 000008d8 T set_range> 000009d8 T set_singleton> 000004f4 T set_sym_difference> 000003d4 T set_union> > % nm /usr/local/cm3/pkg/m3core/FreeBSD4/libm3core.so.5 | grep set_> 000243d0 T set_difference> 00024490 T set_eq> 00024558 T set_ge> 000245fc T set_gt> 00024370 T set_intersection> 000246e0 T set_le> 00024784 T set_lt> 000242e4 T set_member> 000244f4 T set_ne> 00024864 T set_range> 00024998 T set_singleton> 00024430 T set_sym_difference> 00024310 T set_union> > % ldd FreeBSD4/p1/p155/FreeBSD4/pgm> FreeBSD4/p1/p155/FreeBSD4/pgm:> libtest.so.5 => > /d/home/wagner/work/cm3/m3-sys/m3tests/FreeBSD4/libtest.so.5 > (0x28085000)> libm3.so.5 => /usr/local/cm3/pkg/libm3/FreeBSD4/libm3.so.5 > (0x28088000)> libm3core.so.5 => > /usr/local/cm3/pkg/m3core/FreeBSD4/libm3core.so.5 (0x281aa000)> libm.so.4 => /lib/libm.so.4 (0x28a2d000)> libpthread.so.2 => /lib/libpthread.so.2 (0x28a46000)> libc.so.6 => /lib/libc.so.6 (0x28a6a000)> > % nm /usr/local/cm3/pkg/m3core/FreeBSD4/libm3core.so.5 | grep set_> 000243d0 T set_difference> 00024490 T set_eq> 00024558 T set_ge> 000245fc T set_gt> 00024370 T set_intersection> 000246e0 T set_le> 00024784 T set_lt> 000242e4 T set_member> 000244f4 T set_ne> 00024864 T set_range> 00024998 T set_singleton> 00024430 T set_sym_difference> 00024310 T set_union> luthien [~/work/cm3/m3-sys/m3tests] wagner> % ldd FreeBSD4/p1/p155/FreeBSD4/pgm> FreeBSD4/p1/p155/FreeBSD4/pgm:> libtest.so.5 => > /d/home/wagner/work/cm3/m3-sys/m3tests/FreeBSD4/libtest.so.5 > (0x28085000)> libm3.so.5 => /usr/local/cm3/pkg/libm3/FreeBSD4/libm3.so.5 > (0x28088000)> libm3core.so.5 => > /usr/local/cm3/pkg/m3core/FreeBSD4/libm3core.so.5 (0x281aa000)> libm.so.4 => /lib/libm.so.4 (0x28a2d000)> libpthread.so.2 => /lib/libpthread.so.2 (0x28a46000)> libc.so.6 => /lib/libc.so.6 (0x28a6a000)> luthien [~/work/cm3/m3-sys/m3tests] wagner> % nm -C -u FreeBSD4/p1/p155/FreeBSD4/pgm> U Main_I3> U RTHooks_I3> U RTHooks__CheckLoadTracedRef> U RTHooks__Concat> U RTHooks__PopEFrame> U RTHooks__PushEFrame> U RTHooks__TextLitGetChar> U RTHooks__TextLitGetChars> U RTHooks__TextLitGetWideChar> U RTHooks__TextLitGetWideChars> U RTHooks__TextLitInfo> U RTLinker__AddUnit> U RTLinker__InitRuntime> U RTProcess__Exit> U Stdio_I3> U Test_I3> U Test__checkM> U Test__done> U Wr_I3> U Wr__Flush> U Wr__PutText> w _Jv_RegisterClasses> w __deregister_frame_info> w __register_frame_info> U _init_tls> U _setjmp> U atexit> U exit> > Now I'm rather confused 8-/> > Any ideas?> > Olaf> -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194> _________________________________________________________________ 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 Sun Jan 27 21:33:34 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 27 Jan 2008 15:33:34 -0500 Subject: [M3devel] Open CM3 regression tests In-Reply-To: <20080127185530.e255i76vcwckss4o@mail.elegosoft.com> References: <20080120211832.GA26993@elegosoft.com> <9C00EA97-9B43-43BE-9CDF-EEAC9C1321D5@cs.purdue.edu> <20080127150327.mh686v2hx4w080w4@mail.elegosoft.com> <1DA9FA59-6DFF-430C-90C5-F1D30003607A@cs.purdue.edu> <20080127185530.e255i76vcwckss4o@mail.elegosoft.com> Message-ID: <417F5D6F-D9A1-41C0-8B2F-58056170C5F4@cs.purdue.edu> Are your sets larger than a single word? The M3 frontend compiles small sets (elements <= BITSIZE(Word.T)) differently from large (elements > BITSIZE(Word.T)). The out-of-line set operations are only for large sets. On Jan 27, 2008, at 12:55 PM, Olaf Wagner wrote: > Quoting Tony Hosking : > >> The set operations are coded in cm3/m3-libs/m3core/src/Csupport/ >> Common/hand.c. >> >> I notice Jay has made a number of changes here since September -- I >> wonder if they have broken something. > > I tried different revisions of this file with no difference in the > test results. I then took the latest version and added some printfs, > and they got never displayed. So I checked what gets linked, but the > symbols in question don't occur in the test program: > > % nm hand.o > U __divdi3 > U __moddi3 > 000001e0 R _highbits > 00000140 R _lowbits > 00000000 T m3_div > 000000ac T m3_divL > 000001d4 T m3_mod > 0000026c T m3_modL > U printf > 00000494 T set_difference > 00000554 T set_eq > 0000061c T set_ge > 000006ac T set_gt > 00000434 T set_intersection > 0000077c T set_le > 0000080c T set_lt > 000003a8 T set_member > 000005b8 T set_ne > 000008d8 T set_range > 000009d8 T set_singleton > 000004f4 T set_sym_difference > 000003d4 T set_union > > % nm /usr/local/cm3/pkg/m3core/FreeBSD4/libm3core.so.5 | grep set_ > 000243d0 T set_difference > 00024490 T set_eq > 00024558 T set_ge > 000245fc T set_gt > 00024370 T set_intersection > 000246e0 T set_le > 00024784 T set_lt > 000242e4 T set_member > 000244f4 T set_ne > 00024864 T set_range > 00024998 T set_singleton > 00024430 T set_sym_difference > 00024310 T set_union > > % ldd FreeBSD4/p1/p155/FreeBSD4/pgm > FreeBSD4/p1/p155/FreeBSD4/pgm: > libtest.so.5 => /d/home/wagner/work/cm3/m3-sys/m3tests/ > FreeBSD4/libtest.so.5 (0x28085000) > libm3.so.5 => /usr/local/cm3/pkg/libm3/FreeBSD4/libm3.so.5 > (0x28088000) > libm3core.so.5 => /usr/local/cm3/pkg/m3core/FreeBSD4/ > libm3core.so.5 (0x281aa000) > libm.so.4 => /lib/libm.so.4 (0x28a2d000) > libpthread.so.2 => /lib/libpthread.so.2 (0x28a46000) > libc.so.6 => /lib/libc.so.6 (0x28a6a000) > > % nm /usr/local/cm3/pkg/m3core/FreeBSD4/libm3core.so.5 | grep set_ > 000243d0 T set_difference > 00024490 T set_eq > 00024558 T set_ge > 000245fc T set_gt > 00024370 T set_intersection > 000246e0 T set_le > 00024784 T set_lt > 000242e4 T set_member > 000244f4 T set_ne > 00024864 T set_range > 00024998 T set_singleton > 00024430 T set_sym_difference > 00024310 T set_union > luthien [~/work/cm3/m3-sys/m3tests] wagner > % ldd FreeBSD4/p1/p155/FreeBSD4/pgm > FreeBSD4/p1/p155/FreeBSD4/pgm: > libtest.so.5 => /d/home/wagner/work/cm3/m3-sys/m3tests/ > FreeBSD4/libtest.so.5 (0x28085000) > libm3.so.5 => /usr/local/cm3/pkg/libm3/FreeBSD4/libm3.so.5 > (0x28088000) > libm3core.so.5 => /usr/local/cm3/pkg/m3core/FreeBSD4/ > libm3core.so.5 (0x281aa000) > libm.so.4 => /lib/libm.so.4 (0x28a2d000) > libpthread.so.2 => /lib/libpthread.so.2 (0x28a46000) > libc.so.6 => /lib/libc.so.6 (0x28a6a000) > luthien [~/work/cm3/m3-sys/m3tests] wagner > % nm -C -u FreeBSD4/p1/p155/FreeBSD4/pgm > U Main_I3 > U RTHooks_I3 > U RTHooks__CheckLoadTracedRef > U RTHooks__Concat > U RTHooks__PopEFrame > U RTHooks__PushEFrame > U RTHooks__TextLitGetChar > U RTHooks__TextLitGetChars > U RTHooks__TextLitGetWideChar > U RTHooks__TextLitGetWideChars > U RTHooks__TextLitInfo > U RTLinker__AddUnit > U RTLinker__InitRuntime > U RTProcess__Exit > U Stdio_I3 > U Test_I3 > U Test__checkM > U Test__done > U Wr_I3 > U Wr__Flush > U Wr__PutText > w _Jv_RegisterClasses > w __deregister_frame_info > w __register_frame_info > U _init_tls > U _setjmp > U atexit > U exit > > Now I'm rather confused 8-/ > > Any ideas? > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, > Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 > 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: > Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > DE163214194 > From jayk123 at hotmail.com Sun Jan 27 21:44:52 2008 From: jayk123 at hotmail.com (Jay) Date: Sun, 27 Jan 2008 20:44:52 +0000 Subject: [M3devel] Open CM3 regression tests In-Reply-To: <417F5D6F-D9A1-41C0-8B2F-58056170C5F4@cs.purdue.edu> References: <20080120211832.GA26993@elegosoft.com> <9C00EA97-9B43-43BE-9CDF-EEAC9C1321D5@cs.purdue.edu> <20080127150327.mh686v2hx4w080w4@mail.elegosoft.com> <1DA9FA59-6DFF-430C-90C5-F1D30003607A@cs.purdue.edu> <20080127185530.e255i76vcwckss4o@mail.elegosoft.com> <417F5D6F-D9A1-41C0-8B2F-58056170C5F4@cs.purdue.edu> Message-ID: Yes. C:\dev2\cm3.2\m3-sys\m3tests\src\p1\p155\Main.m3 (* Copyright (C) 1994, Digital Equipment Corporation. *)(* All rights reserved. *)(* See the file COPYRIGHT for a full description. *) (* Last modified on Tue Oct 27 14:49:19 PST 1992 by kalsow *)(* modified on Wed Oct 10 13:15:01 1990 by saxe *) (* Set operators on a small set type. *) MODULE Main;IMPORT Test, Wr;FROM Stdio IMPORT stderr; TYPE Elt = {a, b, c, d, e}; Set = SET OF Elt; VAR x: Set; CONST p = Set{Elt.a, Elt.c, Elt.e}; q = Set{}; r = Set{Elt.a .. Elt.b, Elt.a .. Elt.a (* , Elt.d .. Elt.b *)}; PROCEDURE m( s: TEXT ) = BEGIN TRY Wr.PutText (stderr, s & "\n"); Wr.Flush (stderr); EXCEPT ELSE END; END m; BEGIN m ("check set p = {a, c, e}"); Test.checkM (Elt.a IN p, "Elt.a IN p"); Test.checkM (NOT (Elt.b IN p), "NOT (Elt.b IN p)"); Test.checkM (Elt.c IN p, "Elt.c IN p"); Test.checkM (NOT (Elt.d IN p), "NOT (Elt.d IN p)"); Test.checkM (Elt.e IN p, "(Elt.e IN p"); m ("check set q = {}"); Test.checkM (NOT (Elt.a IN q), "NOT (Elt.a IN q)"); Test.checkM (NOT (Elt.b IN q), "NOT (Elt.b IN q)"); Test.checkM (NOT (Elt.c IN q), "NOT (Elt.c IN q)"); Test.checkM (NOT (Elt.d IN q), "NOT (Elt.d IN q)"); Test.checkM (NOT (Elt.e IN q), "NOT (Elt.e IN q)"); m ("check set r = {a, b}"); Test.checkM (Elt.a IN r, "Elt.a IN r"); Test.checkM (Elt.b IN r, "Elt.b IN r"); Test.checkM (NOT (Elt.c IN r), "NOT (Elt.c IN r)"); Test.checkM (NOT (Elt.d IN r), "NOT (Elt.d IN r)"); Test.checkM (NOT (Elt.e IN r), "NOT (Elt.e IN r)"); Test.checkM (r = Set{Elt.b, Elt.a}, "r = Set{Elt.b, Elt.a}"); (** Test.checkM (-p = Set{Elt.d, Elt.b}); **) (** Test.checkM (+p = p); **) Test.checkM (p - p = q, "check (p - p = q)"); Test.checkM ((p - r) * (r - p) = q, "check ((p - r) * (r - p) = q)"); Test.checkM (p - r = Set{Elt.c, Elt.e}, "check (p - r = Set{Elt.c, Elt.e})"); Test.checkM (p + p = p, "check (p + p = p)"); Test.checkM (p + r = Set{Elt.a, Elt.b, Elt.c, Elt.e}, "check (p + r = Set{Elt.a, Elt.b, Elt.c, Elt.e})"); (** Test.checkM (-(-(r)) = r); **) Test.checkM (p * r = Set{Elt.a}, "check (p * r = Set{Elt.a})"); Test.checkM (p * q = Set{}, "check (p * q = Set{})"); Test.checkM (p # q, "check (p # q)"); Test.checkM (q < p, "check (q < p)"); Test.checkM (NOT (p < r), "check (NOT (p < r))"); Test.checkM (NOT (p > r), "check (NOT (p > r))"); Test.checkM (NOT (p = r), "check (NOT (p = r))"); Test.checkM ((p / r) = (Set{Elt.b, Elt.c, Elt.e}), "check ((p / r) = (Set{Elt.b, Elt.c, Elt.e}))"); Test.checkM (r / q = q / r, "check (r / q = q / r)"); Test.checkM (r / p / r / p / q / r = r, "check (r / p / r / p / q / r = r)"); Test.checkM (p / r - r / p = q, "check (p / r - r / p = q)"); x := p; x := x + Set{Elt.b}; (*INCL(x, Elt.b);*) (* x = { a, b, c, e } *) Test.checkM (x > p, "check (x > p)"); Test.checkM (x >= p, "check (x >= p)"); Test.checkM (p <= x, "check (p <= x)"); Test.checkM (p # x, "check (p # x)"); x := x - Set{Elt.c}; (*EXCL(x, Elt.c);*) (* x = { a, b, e } *) m ("check set x = {a, b, e}"); Test.checkM (Elt.a IN x, "Elt.a IN x"); Test.checkM (Elt.b IN x, "Elt.b IN x"); Test.checkM (NOT (Elt.c IN x), "NOT (Elt.c IN x)"); Test.checkM (NOT (Elt.d IN x), "NOT (Elt.d IN x)"); Test.checkM (Elt.e IN x, "Elt.e IN x"); Test.checkM (NOT (p <= x), "check (NOT (p <= x))"); Test.checkM (NOT (p >= x), "check (NOT (p >= x))"); Test.checkM (x = r + Set{Elt.e}, "check (x = r + Set{Elt.e})"); Test.done ();END Main. -Jay > From: hosking at cs.purdue.edu> Date: Sun, 27 Jan 2008 15:33:34 -0500> To: wagner at elegosoft.com> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] Open CM3 regression tests> > Are your sets larger than a single word? The M3 frontend compiles > small sets (elements <= BITSIZE(Word.T)) differently from large > (elements > BITSIZE(Word.T)). The out-of-line set operations are > only for large sets.> > > On Jan 27, 2008, at 12:55 PM, Olaf Wagner wrote:> > > Quoting Tony Hosking :> >> >> The set operations are coded in cm3/m3-libs/m3core/src/Csupport/ > >> Common/hand.c.> >>> >> I notice Jay has made a number of changes here since September -- I> >> wonder if they have broken something.> >> > I tried different revisions of this file with no difference in the> > test results. I then took the latest version and added some printfs,> > and they got never displayed. So I checked what gets linked, but the> > symbols in question don't occur in the test program:> >> > % nm hand.o> > U __divdi3> > U __moddi3> > 000001e0 R _highbits> > 00000140 R _lowbits> > 00000000 T m3_div> > 000000ac T m3_divL> > 000001d4 T m3_mod> > 0000026c T m3_modL> > U printf> > 00000494 T set_difference> > 00000554 T set_eq> > 0000061c T set_ge> > 000006ac T set_gt> > 00000434 T set_intersection> > 0000077c T set_le> > 0000080c T set_lt> > 000003a8 T set_member> > 000005b8 T set_ne> > 000008d8 T set_range> > 000009d8 T set_singleton> > 000004f4 T set_sym_difference> > 000003d4 T set_union> >> > % nm /usr/local/cm3/pkg/m3core/FreeBSD4/libm3core.so.5 | grep set_> > 000243d0 T set_difference> > 00024490 T set_eq> > 00024558 T set_ge> > 000245fc T set_gt> > 00024370 T set_intersection> > 000246e0 T set_le> > 00024784 T set_lt> > 000242e4 T set_member> > 000244f4 T set_ne> > 00024864 T set_range> > 00024998 T set_singleton> > 00024430 T set_sym_difference> > 00024310 T set_union> >> > % ldd FreeBSD4/p1/p155/FreeBSD4/pgm> > FreeBSD4/p1/p155/FreeBSD4/pgm:> > libtest.so.5 => /d/home/wagner/work/cm3/m3-sys/m3tests/ > > FreeBSD4/libtest.so.5 (0x28085000)> > libm3.so.5 => /usr/local/cm3/pkg/libm3/FreeBSD4/libm3.so.5 > > (0x28088000)> > libm3core.so.5 => /usr/local/cm3/pkg/m3core/FreeBSD4/ > > libm3core.so.5 (0x281aa000)> > libm.so.4 => /lib/libm.so.4 (0x28a2d000)> > libpthread.so.2 => /lib/libpthread.so.2 (0x28a46000)> > libc.so.6 => /lib/libc.so.6 (0x28a6a000)> >> > % nm /usr/local/cm3/pkg/m3core/FreeBSD4/libm3core.so.5 | grep set_> > 000243d0 T set_difference> > 00024490 T set_eq> > 00024558 T set_ge> > 000245fc T set_gt> > 00024370 T set_intersection> > 000246e0 T set_le> > 00024784 T set_lt> > 000242e4 T set_member> > 000244f4 T set_ne> > 00024864 T set_range> > 00024998 T set_singleton> > 00024430 T set_sym_difference> > 00024310 T set_union> > luthien [~/work/cm3/m3-sys/m3tests] wagner> > % ldd FreeBSD4/p1/p155/FreeBSD4/pgm> > FreeBSD4/p1/p155/FreeBSD4/pgm:> > libtest.so.5 => /d/home/wagner/work/cm3/m3-sys/m3tests/ > > FreeBSD4/libtest.so.5 (0x28085000)> > libm3.so.5 => /usr/local/cm3/pkg/libm3/FreeBSD4/libm3.so.5 > > (0x28088000)> > libm3core.so.5 => /usr/local/cm3/pkg/m3core/FreeBSD4/ > > libm3core.so.5 (0x281aa000)> > libm.so.4 => /lib/libm.so.4 (0x28a2d000)> > libpthread.so.2 => /lib/libpthread.so.2 (0x28a46000)> > libc.so.6 => /lib/libc.so.6 (0x28a6a000)> > luthien [~/work/cm3/m3-sys/m3tests] wagner> > % nm -C -u FreeBSD4/p1/p155/FreeBSD4/pgm> > U Main_I3> > U RTHooks_I3> > U RTHooks__CheckLoadTracedRef> > U RTHooks__Concat> > U RTHooks__PopEFrame> > U RTHooks__PushEFrame> > U RTHooks__TextLitGetChar> > U RTHooks__TextLitGetChars> > U RTHooks__TextLitGetWideChar> > U RTHooks__TextLitGetWideChars> > U RTHooks__TextLitInfo> > U RTLinker__AddUnit> > U RTLinker__InitRuntime> > U RTProcess__Exit> > U Stdio_I3> > U Test_I3> > U Test__checkM> > U Test__done> > U Wr_I3> > U Wr__Flush> > U Wr__PutText> > w _Jv_RegisterClasses> > w __deregister_frame_info> > w __register_frame_info> > U _init_tls> > U _setjmp> > U atexit> > U exit> >> > Now I'm rather confused 8-/> >> > Any ideas?> >> > Olaf> > -- > > Olaf Wagner -- elego Software Solutions GmbH> > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, > > Germany> > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 > > 45 86 95> > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: > > Berlin> > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > > DE163214194> >> _________________________________________________________________ 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 Sun Jan 27 21:54:55 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Sun, 27 Jan 2008 21:54:55 +0100 Subject: [M3devel] Open CM3 regression tests In-Reply-To: <417F5D6F-D9A1-41C0-8B2F-58056170C5F4@cs.purdue.edu> References: <20080120211832.GA26993@elegosoft.com> <9C00EA97-9B43-43BE-9CDF-EEAC9C1321D5@cs.purdue.edu> <20080127150327.mh686v2hx4w080w4@mail.elegosoft.com> <1DA9FA59-6DFF-430C-90C5-F1D30003607A@cs.purdue.edu> <20080127185530.e255i76vcwckss4o@mail.elegosoft.com> <417F5D6F-D9A1-41C0-8B2F-58056170C5F4@cs.purdue.edu> Message-ID: <20080127215455.4q09uyuj8ko40k4w@mail.elegosoft.com> Quoting Tony Hosking : > Are your sets larger than a single word? The M3 frontend compiles > small sets (elements <= BITSIZE(Word.T)) differently from large > (elements > BITSIZE(Word.T)). The out-of-line set operations are only > for large sets. These are small sets. There are other tests for large sets, which seem to succeed. So obviously the problem is in the cm3cg backend, as in m3middle set_compare will only write Cmd (u, OpName [op]); Int (u, s); TName (u, t); which then gets read by the actual code generator. I guess one of you guys will be much faster tracking this down through the gcc tree construction and manipulation code. It's been several years that I have had a look at that. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From hosking at cs.purdue.edu Sun Jan 27 22:31:22 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 27 Jan 2008 16:31:22 -0500 Subject: [M3devel] Open CM3 regression tests In-Reply-To: <20080127215455.4q09uyuj8ko40k4w@mail.elegosoft.com> References: <20080120211832.GA26993@elegosoft.com> <9C00EA97-9B43-43BE-9CDF-EEAC9C1321D5@cs.purdue.edu> <20080127150327.mh686v2hx4w080w4@mail.elegosoft.com> <1DA9FA59-6DFF-430C-90C5-F1D30003607A@cs.purdue.edu> <20080127185530.e255i76vcwckss4o@mail.elegosoft.com> <417F5D6F-D9A1-41C0-8B2F-58056170C5F4@cs.purdue.edu> <20080127215455.4q09uyuj8ko40k4w@mail.elegosoft.com> Message-ID: <45340E89-F1AD-40CC-BF84-77607A35D4A8@cs.purdue.edu> It is the *front* end that compiles small sets into word operations. The backend doesn't even see small sets. So, this suggests that the small sets are failing due to some interaction between the front end and back end. On Jan 27, 2008, at 3:54 PM, Olaf Wagner wrote: > Quoting Tony Hosking : > >> Are your sets larger than a single word? The M3 frontend compiles >> small sets (elements <= BITSIZE(Word.T)) differently from large >> (elements > BITSIZE(Word.T)). The out-of-line set operations are >> only >> for large sets. > > These are small sets. There are other tests for large sets, which seem > to succeed. > > So obviously the problem is in the cm3cg backend, as in m3middle > set_compare will only write > > Cmd (u, OpName [op]); > Int (u, s); > TName (u, t); > > which then gets read by the actual code generator. > I guess one of you guys will be much faster tracking this down > through the gcc tree construction and manipulation code. It's been > several years that I have had a look at that. > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, > Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 > 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: > Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > DE163214194 > From wagner at elegosoft.com Sun Jan 27 23:11:57 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Sun, 27 Jan 2008 23:11:57 +0100 Subject: [M3devel] Open CM3 regression tests In-Reply-To: <45340E89-F1AD-40CC-BF84-77607A35D4A8@cs.purdue.edu> References: <20080120211832.GA26993@elegosoft.com> <9C00EA97-9B43-43BE-9CDF-EEAC9C1321D5@cs.purdue.edu> <20080127150327.mh686v2hx4w080w4@mail.elegosoft.com> <1DA9FA59-6DFF-430C-90C5-F1D30003607A@cs.purdue.edu> <20080127185530.e255i76vcwckss4o@mail.elegosoft.com> <417F5D6F-D9A1-41C0-8B2F-58056170C5F4@cs.purdue.edu> <20080127215455.4q09uyuj8ko40k4w@mail.elegosoft.com> <45340E89-F1AD-40CC-BF84-77607A35D4A8@cs.purdue.edu> Message-ID: <20080127231157.7y1adg5bksw08o0k@mail.elegosoft.com> Quoting Tony Hosking : > It is the *front* end that compiles small sets into word operations. > The backend doesn't even see small sets. So, this suggests that the > small sets are failing due to some interaction between the front end > and back end. Sorry if I seem to be a bit slow (I've caught a bronchitis again and perhaps cannot think as clearly as I should)... So you think the error is in m3-sys/m3front/src/exprs/SetExpr.m3 in PROCEDURE Compare (a, b: Expr.T; VAR sign: INTEGER): BOOLEAN = and PROCEDURE Visit (VAR s: VisitState): BOOLEAN = or rather in m3middle while writing the intermediate representation? Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Jan 28 00:18:05 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 27 Jan 2008 18:18:05 -0500 Subject: [M3devel] Open CM3 regression tests In-Reply-To: <20080127231157.7y1adg5bksw08o0k@mail.elegosoft.com> References: <20080120211832.GA26993@elegosoft.com> <9C00EA97-9B43-43BE-9CDF-EEAC9C1321D5@cs.purdue.edu> <20080127150327.mh686v2hx4w080w4@mail.elegosoft.com> <1DA9FA59-6DFF-430C-90C5-F1D30003607A@cs.purdue.edu> <20080127185530.e255i76vcwckss4o@mail.elegosoft.com> <417F5D6F-D9A1-41C0-8B2F-58056170C5F4@cs.purdue.edu> <20080127215455.4q09uyuj8ko40k4w@mail.elegosoft.com> <45340E89-F1AD-40CC-BF84-77607A35D4A8@cs.purdue.edu> <20080127231157.7y1adg5bksw08o0k@mail.elegosoft.com> Message-ID: I would be surprised if the front-end is wrong, but it might be. It might also be some strange interaction with the backend. I can put this on my stack of things to look at, but it will be a little while as I catch up with other things -- I've only just begun to regain usable sight in one of my eyes after scratching a cornea last week. On Jan 27, 2008, at 5:11 PM, Olaf Wagner wrote: > Quoting Tony Hosking : > >> It is the *front* end that compiles small sets into word operations. >> The backend doesn't even see small sets. So, this suggests that the >> small sets are failing due to some interaction between the front end >> and back end. > > Sorry if I seem to be a bit slow (I've caught a bronchitis again > and perhaps cannot think as clearly as I should)... So you think > the error is in m3-sys/m3front/src/exprs/SetExpr.m3 in > > PROCEDURE Compare (a, b: Expr.T; VAR sign: INTEGER): BOOLEAN = > and > PROCEDURE Visit (VAR s: VisitState): BOOLEAN = > > or rather in m3middle while writing the intermediate representation? > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, > Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Jan 28 10:48:31 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 28 Jan 2008 09:48:31 +0000 Subject: [M3devel] heap vs. stack? (sort of) Message-ID: Is it possible to have this pattern in Modula-3: PROCEDURE Parse (nm: TEXT; host: BOOLEAN): T = VAR len := Text.Length (nm); buf: ARRAY [0..255] OF CHAR; BEGIN IF (len <= NUMBER (buf)) THEN RETURN DoParse (nm, SUBARRAY (buf, 0, len), host); ELSE RETURN DoParse (nm, NEW (REF ARRAY OF CHAR, len)^, host); END; END Parse; PROCEDURE DoParse (nm_txt: TEXT; VAR nm: ARRAY OF CHAR; host: BOOLEAN): T = without the extra function? There are places in M3Path.m3 that duplicate code otherwise, one branch acting on a local stack allocated array, the other acting on a heap allocated array when the stack array is too small, but otherwise identical code. So far I have not figured out how. Local variables cannot be open array. SUBARRAY returns an ARRAY and not a REF ARRAY... It seems that parameters can be open arrays but local variables cannot, and that seems wrong.. parameters and locals so often share characteristics... - 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 Jan 28 12:29:31 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 28 Jan 2008 11:29:31 +0000 Subject: [M3devel] nt386gnu threads? Message-ID: Can anyone confirm my read that PM3's NT386GNU used user/vtalarm threads? PM3 appears to have no PThread support ant its NT386GNU appears to have OS_TYPE=POSIX. Heck, even its NT386 has OS_TYPE=POSIX, but its NT386 is probably dead/broken. 1) I'm too lazy to tediously rewrite Cygwin's pthread.h et. al. into Modula-3. 2) The thread library you pick is not an independent decision. The Modula-3 File I/O libraries interact with the threading library at least a little bit. The path of less resistance seems to be user/vtalarm threads for now, until such time as Cygwin Upthread.i3 is written. (That is, neither pthreads nor win32 satisfied my laziness; I'm going to try user/vtalarm threads, see how it goes; I'm sure they aren't very good, but...) - Jay _________________________________________________________________ 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 Mon Jan 28 12:39:10 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Mon, 28 Jan 2008 12:39:10 +0100 (MET) Subject: [M3devel] heap vs. stack? (sort of) In-Reply-To: References: Message-ID: On Mon, 28 Jan 2008, Jay wrote: > Is it possible to have this pattern in Modula-3: > > PROCEDURE Parse (nm: TEXT; host: BOOLEAN): T = VAR len := Text.Length (nm); buf: ARRAY [0..255] OF CHAR; BEGIN IF (len <= NUMBER (buf)) THEN RETURN DoParse (nm, SUBARRAY (buf, 0, len), host); ELSE RETURN DoParse (nm, NEW (REF ARRAY OF CHAR, len)^, host); END; END Parse; > > PROCEDURE DoParse (nm_txt: TEXT; VAR nm: ARRAY OF CHAR; host: BOOLEAN): T = I think it is a good idea to encapsulate the common code in DoParse. If DoParse needs local variables, it can be turned into a local PROCEDURE of Parse. On the other hand I doubt that it is sensible to reserve 256 bytes on the stack also if they are not used, or only a part of them are used. What's bad about always using NEW? I think Modula-3's memory management has optimizations for small amounts of memory. From mika at async.caltech.edu Mon Jan 28 13:04:50 2008 From: mika at async.caltech.edu (Mika Nystrom) Date: Mon, 28 Jan 2008 04:04:50 -0800 Subject: [M3devel] nt386gnu threads? In-Reply-To: Your message of "Mon, 28 Jan 2008 11:29:31 GMT." Message-ID: <200801281204.m0SC4oNp025190@camembert.async.caltech.edu> I am almost certain it uses Win32 threads. Attached: ThreadWin32.m3 from PM3-Klagenfurt Mika Jay writes: >--_ddef1601-2afe-4ff4-9567-11d7fc5d354a_ >Content-Type: text/plain; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > >Can anyone confirm my read that PM3's NT386GNU used user/vtalarm threads? .... (* Copyright (C) 1994, Digital Equipment Corporation *) (* All rights reserved. *) (* See the file COPYRIGHT for a full description. *) (* *) (* portions Copyright 1996, Critical Mass, Inc. *) (* *) (* Last modified on Fri Apr 26 10:21:56 PDT 1996 by heydon *) (* modified on Thu Jun 15 09:06:37 PDT 1995 by kalsow *) (* modified on Tue Oct 4 10:34:00 PDT 1994 by isard *) (* modified on Tue May 4 10:20:03 PDT 1993 by mjordan *) (* modified on Wed Apr 21 16:31:21 PDT 1993 by mcjones *) (* modified on Fri Mar 26 15:04:39 PST 1993 by birrell *) UNSAFE MODULE ThreadWin32 EXPORTS Scheduler, Thread, ThreadF, RTThreadInit, RTHooks; IMPORT RTHeapRep, RTLinker, RTMisc, WinBase, WinDef, WinNT, ThreadContext; IMPORT Word; (*** IMPORT RTIO; ***) (*----------------------------------------- Exceptions, types and globals ---*) VAR cm: WinBase.LPCRITICAL_SECTION; (* Global lock for internals of Mutex and Condition *) default_stack: WinDef.DWORD := 16384; nextId: Id := 1; REVEAL Mutex = BRANDED "MUTEX Win32-1.0" OBJECT cs: WinBase.LPCRITICAL_SECTION := NIL; held: BOOLEAN := FALSE; (* LL = self.cs *) (* Because critical sections are thread re-entrant *) END; Condition = BRANDED "Thread.Condition Win32-1.0" OBJECT waiters: T := NIL; (* LL = cm *) (* List of threads waiting on this CV. *) END; T = BRANDED "Thread.T Win32-1.0" OBJECT next, prev: T := NIL; (* LL = threadMu; global doubly-linked, circular list of all threads *) nextIdle: T := NIL; (* LL = threadMu; global list of idle threads *) handle: WinNT.HANDLE := NIL; (* LL = threadMu; thread handle in Windows *) stackbase: ADDRESS := NIL; (* LL = threadMu; base of thread stack for use by GC *) closure: Closure := NIL; (* LL = threadMu *) result: REFANY := NIL; (* LL = threadMu; if not self.completed, used only by self; if self.completed, read-only. *) cond: Condition; (* LL = threadMu; wait here to join, or for rebirth *) waitingOn: Condition := NIL; (* LL = cm; CV that we're blocked on *) nextWaiter: T := NIL; (* LL = cm; queue of threads waiting on the same CV *) waitSema: WinNT.HANDLE := NIL; (* binary semaphore for blocking during "Wait" *) alertable: BOOLEAN := FALSE; (* LL = cm; distinguishes between "Wait" and "AlertWait" *) alerted: BOOLEAN := FALSE; (* LL = cm; the alert flag, of course *) completed: BOOLEAN := FALSE; (* LL = threadMu; indicates that "result" is set *) joined: BOOLEAN := FALSE; (* LL = threadMu; "Join" or "AlertJoin" has already returned *) id: Id; (* LL = threadMu; unique ID of this thread *) slot: INTEGER; (* LL = threadMu; index into global array of active, slotted threads *) END; (*------------------------------------------- Caches of critical sections ---*) CONST CSectCacheSize = 20; (* Everything should work OK if these are 0 *) VAR cSectCache: ARRAY [0..CSectCacheSize-1] OF WinBase.LPCRITICAL_SECTION; cSectCacheContents := 0; PROCEDURE AllocCSect(m: Mutex) = (* LL = 0 *) (* If we can take a critical section from the cache, do so; otherwise create it. In any case, register the containing Mutex with the GC so that we can clean-up on de-allocation. *) VAR mcs: WinBase.LPCRITICAL_SECTION := NIL; lost_race := FALSE; BEGIN WinBase.EnterCriticalSection(cm); IF cSectCacheContents > 0 THEN DEC(cSectCacheContents); m.cs := cSectCache[cSectCacheContents]; ELSE WinBase.LeaveCriticalSection(cm); mcs := NEW(WinBase.LPCRITICAL_SECTION); WinBase.EnterCriticalSection(cm); IF (m.cs = NIL) THEN m.cs := mcs; WinBase.InitializeCriticalSection(m.cs); ELSE (* somebody else beat us thru the preceding NEW *) lost_race := TRUE; END; END; WinBase.LeaveCriticalSection(cm); IF lost_race THEN DISPOSE (mcs); ELSE RTHeapRep.RegisterFinalCleanup(m, FreeCSect); END; END AllocCSect; PROCEDURE FreeCSect(r: REFANY (*Mutex*) ) = (* LL < cm *) (* Must not dereference any traced REF when called from GC *) VAR m: Mutex := r; BEGIN WinBase.EnterCriticalSection(cm); IF m.cs # NIL THEN IF cSectCacheContents < CSectCacheSize THEN cSectCache[cSectCacheContents] := m.cs; INC(cSectCacheContents); ELSE WinBase.DeleteCriticalSection(m.cs); DISPOSE(m.cs); END; m.cs := NIL; END; WinBase.LeaveCriticalSection(cm) END FreeCSect; (*----------------------------------------------------------------- Mutex ---*) (* Note: RTHooks.{Unlock,Lock}Mutex are the routines called directly by the compiler. Acquire and Release are the routines exported through the Thread interface *) PROCEDURE Acquire (m: Mutex) = BEGIN LockMutex (m); END Acquire; PROCEDURE Release (m: Mutex) = BEGIN UnlockMutex (m); END Release; PROCEDURE (*RTHooks.*)LockMutex (m: Mutex) = BEGIN IF (m.cs = NIL) THEN AllocCSect(m); END; WinBase.EnterCriticalSection(m.cs); IF m.held THEN Die("attempt to lock mutex already locked by self") END; m.held := TRUE; END LockMutex; PROCEDURE (*RTHooks.*)UnlockMutex(m: Mutex) = BEGIN IF NOT m.held THEN Die("attempt to release an unlocked mutex") END; m.held := FALSE; WinBase.LeaveCriticalSection(m.cs); END UnlockMutex; (*---------------------------------------- Condition variables and Alerts ---*) PROCEDURE InnerWait(m: Mutex; c: Condition; self: T) = (* LL = cm+m on entry; LL = m on exit *) BEGIN <* ASSERT( (self.waitingOn=NIL) AND (self.nextWaiter=NIL) ) *> self.waitingOn := c; self.nextWaiter := c.waiters; c.waiters := self; WinBase.LeaveCriticalSection(cm); UnlockMutex(m); IF WinBase.WaitForSingleObject(self.waitSema, WinBase.INFINITE) # 0 THEN Choke(); END; LockMutex(m); END InnerWait; PROCEDURE InnerTestAlert(self: T) RAISES {Alerted} = (* LL = cm on entry; LL = cm on normal exit, 0 on exception exit *) (* If self.alerted, clear "alerted", leave cm and raise "Alerted". *) BEGIN IF self.alerted THEN self.alerted := FALSE; WinBase.LeaveCriticalSection(cm); RAISE Alerted END; END InnerTestAlert; PROCEDURE AlertWait (m: Mutex; c: Condition) RAISES {Alerted} = (* LL = m *) VAR self := Self(); BEGIN IF self = NIL THEN Die("AlertWait called from non-Modula-3 thread") END; WinBase.EnterCriticalSection(cm); InnerTestAlert(self); self.alertable := TRUE; InnerWait(m, c, self); WinBase.EnterCriticalSection(cm); InnerTestAlert(self); WinBase.LeaveCriticalSection(cm); END AlertWait; PROCEDURE Wait (m: Mutex; c: Condition) = (* LL = m *) VAR self := Self(); BEGIN IF self = NIL THEN Die("Wait called from non-Modula-3 thread") END; WinBase.EnterCriticalSection(cm); InnerWait(m, c, self); END Wait; PROCEDURE DequeueHead(c: Condition) = (* LL = cm *) VAR t: T; prevCount: WinDef.LONG; BEGIN t := c.waiters; c.waiters := t.nextWaiter; t.nextWaiter := NIL; t.waitingOn := NIL; t.alertable := FALSE; IF WinBase.ReleaseSemaphore(t.waitSema, 1, ADR(prevCount)) = 0 THEN Choke(); END; END DequeueHead; PROCEDURE Signal (c: Condition) = BEGIN WinBase.EnterCriticalSection(cm); IF c.waiters # NIL THEN DequeueHead(c) END; WinBase.LeaveCriticalSection(cm); END Signal; PROCEDURE Broadcast (c: Condition) = BEGIN WinBase.EnterCriticalSection(cm); WHILE c.waiters # NIL DO DequeueHead(c) END; WinBase.LeaveCriticalSection(cm); END Broadcast; PROCEDURE Alert(t: T) = VAR prevCount: WinDef.LONG; prev, next: T; BEGIN IF t = NIL THEN Die("Alert called from non-Modula-3 thread") END; WinBase.EnterCriticalSection(cm); t.alerted := TRUE; IF t.alertable THEN (* Dequeue from any CV and unblock from the semaphore *) IF t.waitingOn # NIL THEN next := t.waitingOn.waiters; prev := NIL; WHILE next # t DO <* ASSERT(next#NIL) *> prev := next; next := next.nextWaiter; END; IF prev = NIL THEN t.waitingOn.waiters := t.nextWaiter ELSE prev.nextWaiter := t.nextWaiter; END; t.nextWaiter := NIL; t.waitingOn := NIL; END; t.alertable := FALSE; IF WinBase.ReleaseSemaphore(t.waitSema, 1, ADR(prevCount)) = 0 THEN Choke(); END; END; WinBase.LeaveCriticalSection(cm); END Alert; PROCEDURE TestAlert(): BOOLEAN = VAR self := Self(); result: BOOLEAN; BEGIN IF self = NIL THEN (* Not created by Fork; not alertable *) RETURN FALSE ELSE WinBase.EnterCriticalSection(cm); result := self.alerted; IF result THEN self.alerted := FALSE END; WinBase.LeaveCriticalSection(cm); RETURN result END; END TestAlert; (*------------------------------------------------------------------ Self ---*) VAR threadIndex: WinDef.DWORD; (* read-only; TLS (Thread Local Storage) index *) VAR (* LL = threadMu *) n_slotted := 0; next_slot := 1; slots : REF ARRAY OF T; (* NOTE: we don't use slots[0]. *) PROCEDURE Self (): T = (* If not the initial thread and not created by Fork, returns NIL *) VAR t: T; x := LOOPHOLE(WinBase.TlsGetValue(threadIndex), INTEGER); BEGIN IF (x < 1) THEN RETURN NIL; END; t := slots[x]; IF (t.slot # x) THEN Die ("thread with bad slot!"); END; RETURN t; END Self; PROCEDURE SetSelf (t: T) = (* LL = 0 *) BEGIN IF (slots [t.slot] # t) THEN Die ("unslotted thread!"); END; IF WinBase.TlsSetValue(threadIndex, LOOPHOLE(t.slot, WinDef.LPVOID)) = 0 THEN Choke(); END; END SetSelf; PROCEDURE AssignSlot (t: T): INTEGER = (* LL = threadMu *) BEGIN (* make sure we have room to register this guy *) IF (slots = NIL) THEN slots := NEW (REF ARRAY OF T, 20); END; IF (n_slotted >= LAST (slots^)) THEN ExpandSlots (); END; (* look for an empty slot *) WHILE (slots [next_slot] # NIL) DO INC (next_slot); IF (next_slot >= NUMBER (slots^)) THEN next_slot := 1; END; END; INC (n_slotted); t.slot := next_slot; slots [next_slot] := t; RETURN t.slot; END AssignSlot; PROCEDURE FreeSlot (t: T) = (* LL = threadMu *) BEGIN DEC (n_slotted); WITH z = slots [t.slot] DO IF (z # t) THEN Die ("unslotted thread!"); END; z := NIL; END; t.slot := 0; END FreeSlot; PROCEDURE ExpandSlots () = VAR n := NUMBER (slots^); new := NEW (REF ARRAY OF T, n+n); BEGIN SUBARRAY (new^, 0, n) := slots^; slots := new; END ExpandSlots; (*------------------------------------------------------------ Fork, Join ---*) CONST MaxIdle = 20; VAR (* LL=threadMu *) threadMu: Mutex; allThreads: T := NIL; (* global list of registered threads *) idleThreads: T := NIL; (* global list of idle threads *) nIdle := 0; PROCEDURE CreateT(): T = (* LL < threadMu, because allocated a traced reference may cause the allocator to start a collection which will call SuspendOthers which will try to acquire threadMu. *) BEGIN RETURN NEW(T, waitSema := WinBase.CreateSemaphore(NIL, 0, 1, NIL), cond := NEW(Condition)); END CreateT; (* ThreadBase calls ThreadMain after finding (approximately) where its stack begins. This dance ensures that all of ThreadMain's traced references are within the stack scanned by the collector. *) PROCEDURE ThreadBase(param: WinDef.DWORD): WinDef.DWORD = VAR self: T; x := LOOPHOLE(param, INTEGER); BEGIN LockMutex(threadMu); self := slots[x]; self.stackbase := ADR(self); UnlockMutex(threadMu); ThreadMain(self); RETURN 0; END ThreadBase; PROCEDURE ThreadMain(self: T) = TYPE ObjRef = UNTRACED REF MethodList; MethodList = UNTRACED REF RECORD typecode: INTEGER; method0: ADDRESS END; VAR next_self: T; cl: Closure; res: REFANY; BEGIN LOOP (* The incarnation loop. *) SetSelf (self); LockMutex(threadMu); cl := self.closure; self.id := nextId; INC (nextId); UnlockMutex(threadMu); IF (cl = NIL) THEN Die ("NIL closure passed to Thread.Fork!"); ELSIF (LOOPHOLE (cl, ObjRef)^^.method0 = NIL) THEN Die ("NIL apply method passed to Thread.Fork!"); END; res := cl.apply(); next_self := NIL; IF nIdle < MaxIdle THEN (* apparently the cache isn't full, although we don't hold threadMu so we can't be certain... *) next_self := NEW(T); END; LockMutex(threadMu); self.result := res; self.completed := TRUE; IF next_self # NIL THEN (* transplant the guts of "self" into next_self *) next_self.handle := self.handle; next_self.stackbase := self.stackbase; next_self.waitSema := self.waitSema; next_self.cond := self.cond; (* put "next_self" on the list of all threads *) next_self.next := allThreads; next_self.prev := allThreads.prev; allThreads.prev.next := next_self; allThreads.prev := next_self; (* put "next_self" on the list of idle threads *) next_self.nextIdle := idleThreads; idleThreads := next_self; INC(nIdle); (* finish making "self" an orphan *) IF allThreads = self THEN allThreads := self.next; END; self.next.prev := self.prev; self.prev.next := self.next; self.next := NIL; self.prev := NIL; self.handle := NIL; self.stackbase := NIL; END; UnlockMutex(threadMu); Broadcast(self.cond); (* let everybody know that "self" is done *) IF next_self = NIL THEN EXIT; END; self := next_self; IF WinBase.WaitForSingleObject(self.waitSema, WinBase.INFINITE) # 0 THEN Choke(); END; END; (* remove ourself from the list of all threads *) LockMutex(threadMu); IF allThreads = self THEN allThreads := self.next; END; self.next.prev := self.prev; self.prev.next := self.next; self.next := NIL; self.prev := NIL; IF WinBase.CloseHandle(self.waitSema) = 0 THEN Choke() END; IF WinBase.CloseHandle(self.handle) = 0 THEN Choke() END; self.handle := NIL; self.waitSema := NIL; FreeSlot (self); UnlockMutex(threadMu); END ThreadMain; PROCEDURE Fork(closure: Closure): T = VAR t: T := NIL; id, stack_size: WinDef.DWORD; prevCount: WinDef.LONG; new_born: BOOLEAN; BEGIN (* determine the initial size of the stack for this thread *) stack_size := default_stack; TYPECASE closure OF SizedClosure (scl) => IF scl.stackSize # 0 THEN stack_size := scl.stackSize * BYTESIZE(INTEGER); END; ELSE (*skip*) END; (* try the cache for a thread *) LockMutex(threadMu); IF nIdle > 0 THEN new_born := FALSE; <* ASSERT(idleThreads # NIL) *> DEC(nIdle); t := idleThreads; idleThreads := t.nextIdle; t.nextIdle := NIL; t.slot := AssignSlot (t); ELSE (* empty cache => we need a fresh thread *) new_born := TRUE; UnlockMutex(threadMu); t := CreateT(); LockMutex(threadMu); t.slot := AssignSlot (t); t.handle := WinBase.CreateThread(NIL, stack_size, LOOPHOLE(ThreadBase, WinBase.LPTHREAD_START_ROUTINE), LOOPHOLE(t.slot,WinDef.LPVOID), WinBase.CREATE_SUSPENDED, ADR(id)); t.next := allThreads; t.prev := allThreads.prev; allThreads.prev.next := t; allThreads.prev := t; END; IF (t.handle = NIL) THEN Choke() END; t.closure := closure; UnlockMutex(threadMu); IF new_born THEN IF WinBase.ResumeThread(t.handle) = -1 THEN Choke() END; ELSE IF WinBase.ReleaseSemaphore(t.waitSema, 1, ADR(prevCount)) = 0 THEN Choke(); END; END; RETURN t END Fork; PROCEDURE Join(t: T): REFANY = VAR res: REFANY; BEGIN LockMutex(threadMu); IF t.joined THEN Die("attempt to join with thread twice"); END; WHILE NOT t.completed DO Wait(threadMu, t.cond) END; res := t.result; t.result := NIL; t.joined := TRUE; UnlockMutex(threadMu); RETURN res; END Join; PROCEDURE AlertJoin(t: T): REFANY RAISES {Alerted} = VAR res: REFANY; BEGIN LockMutex(threadMu); TRY IF t.joined THEN Die("attempt to join with thread twice"); END; WHILE NOT t.completed DO AlertWait(threadMu, t.cond) END; res := t.result; t.result := NIL; t.joined := TRUE; FINALLY UnlockMutex(threadMu); END; RETURN res; END AlertJoin; (*------------------------------------------------ timer-based preemption ---*) PROCEDURE SetSwitchingInterval (<*UNUSED*> usec: CARDINAL) = BEGIN END SetSwitchingInterval; (*---------------------------------------------------- Scheduling support ---*) PROCEDURE Pause(n: LONGREAL) = VAR amount, thisTime: LONGREAL; CONST Limit = FLOAT(LAST(CARDINAL), LONGREAL) / 1000.0D0 - 1.0D0; BEGIN amount := n; WHILE amount > 0.0D0 DO thisTime := MIN (Limit, amount); amount := amount - thisTime; WinBase.Sleep(ROUND(thisTime*1000.0D0)); END; END Pause; PROCEDURE AlertPause(n: LONGREAL) RAISES {Alerted} = VAR amount, thisTime: LONGREAL; CONST Limit = FLOAT(LAST(CARDINAL), LONGREAL) / 1000.0D0 - 1.0D0; VAR self: T; BEGIN self := Self(); amount := n; WHILE amount > 0.0D0 DO thisTime := MIN (Limit, amount); amount := amount - thisTime; WinBase.EnterCriticalSection(cm); InnerTestAlert(self); self.alertable := TRUE; <* ASSERT(self.waitingOn = NIL) *> WinBase.LeaveCriticalSection(cm); EVAL WinBase.WaitForSingleObject(self.waitSema, ROUND(thisTime*1.0D3)); WinBase.EnterCriticalSection(cm); self.alertable := FALSE; IF self.alerted THEN (* Sadly, the alert might have happened after we timed out on the semaphore and before we entered "cm". In that case, we need to decrement the semaphore's count *) EVAL WinBase.WaitForSingleObject(self.waitSema, 0); InnerTestAlert(self); END; WinBase.LeaveCriticalSection(cm); END; END AlertPause; PROCEDURE Yield() = BEGIN WinBase.Sleep(0); END Yield; (*--------------------------------------------------- Stack size controls ---*) PROCEDURE GetDefaultStackSize(): CARDINAL= BEGIN RETURN default_stack DIV BYTESIZE (INTEGER); END GetDefaultStackSize; PROCEDURE MinDefaultStackSize(new_min: CARDINAL)= BEGIN default_stack := MAX (default_stack, new_min * BYTESIZE (INTEGER)); END MinDefaultStackSize; PROCEDURE IncDefaultStackSize(inc: CARDINAL)= BEGIN INC (default_stack, inc * BYTESIZE (INTEGER)); END IncDefaultStackSize; (*-------------------------------------------- Exception handling support ---*) VAR handlersIndex: INTEGER; PROCEDURE GetCurrentHandlers(): ADDRESS= BEGIN RETURN WinBase.TlsGetValue(handlersIndex); END GetCurrentHandlers; PROCEDURE SetCurrentHandlers(h: ADDRESS)= BEGIN EVAL WinBase.TlsSetValue(handlersIndex, h); END SetCurrentHandlers; PROCEDURE PushEFrame (frame: ADDRESS) = TYPE Frame = UNTRACED REF RECORD next: ADDRESS END; VAR f := LOOPHOLE (frame, Frame); BEGIN f.next := WinBase.TlsGetValue(handlersIndex); EVAL WinBase.TlsSetValue(handlersIndex, f); END PushEFrame; PROCEDURE PopEFrame (frame: ADDRESS) = BEGIN EVAL WinBase.TlsSetValue(handlersIndex, frame); END PopEFrame; (*--------------------------------------------- Garbage collector support ---*) VAR suspend_mu : Mutex; suspend_cnt : CARDINAL := 0; (* LL = suspend_mu *) PROCEDURE SuspendOthers () = (* LL=0. Always bracketed with ResumeOthers, which will unlock threadMu *) VAR t: T; self := Self (); cnt: CARDINAL; BEGIN LOCK suspend_mu DO cnt := suspend_cnt; INC (suspend_cnt); END; IF (cnt = 0) THEN LockMutex(threadMu); WinBase.EnterCriticalSection(cm); (* We must hold 'cm' to guarantee that no suspended thread holds it. Otherwise, when the collector tries to acquire a mutex or signal a condition, it will deadlock with the suspended thread that holds 'cm'. *) t := self.next; WHILE (t # self) DO IF WinBase.SuspendThread(t.handle) = -1 THEN Choke() END; t := t.next; END; WinBase.LeaveCriticalSection(cm); END; END SuspendOthers; PROCEDURE ResumeOthers () = (* LL=threadMu. Always preceded by SuspendOthers, which locks threadMu *) VAR t: T; self := Self (); cnt: CARDINAL; BEGIN LOCK suspend_mu DO DEC (suspend_cnt); cnt := suspend_cnt; END; IF (cnt = 0) THEN t := self.next; WHILE (t # self) DO IF WinBase.ResumeThread(t.handle) = -1 THEN Choke() END; t := t.next; END; UnlockMutex(threadMu); END; END ResumeOthers; PROCEDURE ProcessStacks (p: PROCEDURE (start, stop: ADDRESS)) = (* LL=threadMu. Only called within {SuspendOthers, ResumeOthers} *) CONST UserRegs = Word.Or(ThreadContext.CONTEXT_CONTROL, ThreadContext.CONTEXT_INTEGER); VAR t := allThreads; context: ThreadContext.CONTEXT; fixed_SP: ADDRESS; BEGIN REPEAT IF (t.stackbase # NIL) THEN context.ContextFlags := UserRegs; IF WinBase.GetThreadContext(t.handle, ADR(context))=0 THEN Choke() END; fixed_SP := LOOPHOLE (context.Esp, ADDRESS); IF (t.stackbase - fixed_SP) > 10000 THEN fixed_SP := VerifySP (fixed_SP, t.stackbase); END; p(fixed_SP, t.stackbase); (* Process the stack *) p(ADR(context.Edi), ADR(context.Eip)); (* Process the registers *) END; t := t.next; UNTIL (t = allThreads); END ProcessStacks; PROCEDURE VerifySP (start, stop: ADDRESS): ADDRESS = (* Apparently, Win95 will lie about a thread's stack pointer! *) (* Verify that the claimed stack pages are really readable... *) CONST PageSize = 4096; CONST N = BYTESIZE (info); VAR info: WinNT.MEMORY_BASIC_INFORMATION; BEGIN (****** RTIO.PutText ("GC: suspicious stack: ["); RTIO.PutAddr (start); RTIO.PutText (".."); RTIO.PutAddr (stop); RTIO.PutText ("]\n"); RTIO.Flush (); ******) info.BaseAddress := LOOPHOLE (stop-1, ADDRESS); LOOP IF (info.BaseAddress <= start) THEN info.BaseAddress := start; EXIT; END; IF WinBase.VirtualQuery (info.BaseAddress, ADR (info), N) # N THEN Choke(); END; (******* RTIO.PutText (" --> "); RTIO.PutAddr (info.BaseAddress); RTIO.PutText (" "); RTIO.PutAddr (info.AllocationBase); RTIO.PutText (" "); RTIO.PutHex (info.AllocationProtect); RTIO.PutText (" "); RTIO.PutHex (info.RegionSize); RTIO.PutText (" "); RTIO.PutHex (info.State); RTIO.PutText (" "); RTIO.PutHex (info.Protect); RTIO.PutText (" "); RTIO.PutHex (info.Type); RTIO.PutText ("\n"); *******) (* is this chunk readable? *) IF (info.Protect # WinNT.PAGE_READWRITE) AND (info.Protect # WinNT.PAGE_READONLY) THEN (* nope, return the base of the last good chunk *) INC (info.BaseAddress, info.RegionSize); EXIT; END; (* yep, try the next chunk *) DEC (info.BaseAddress, PageSize); END; (******** RTIO.PutText (" ==> ["); RTIO.PutAddr (info.BaseAddress); RTIO.PutText (".."); RTIO.PutAddr (stop); RTIO.PutText ("]"); RTIO.PutText ("\n"); RTIO.Flush (); *******) RETURN info.BaseAddress; END VerifySP; (*------------------------------------------------------------ misc. junk ---*) PROCEDURE MyId(): Id RAISES {}= VAR self := Self (); BEGIN RETURN self.id; END MyId; (*---------------------------------------------------------------- errors ---*) PROCEDURE Die(msg: TEXT) = BEGIN RTMisc.FatalError ("ThreadWin32.m3", 721, "Thread client error: ", msg); END Die; PROCEDURE Choke() = BEGIN RTMisc.FatalErrorI ( "ThreadWin32.m3, line 726: Windows OS failure, GetLastError = ", WinBase.GetLastError ()); END Choke; (*-------------------------------------------------------- Initialization ---*) PROCEDURE Init() = VAR self: T; threadhandle, processhandle: WinNT.HANDLE; BEGIN handlersIndex := WinBase.TlsAlloc(); IF handlersIndex < 0 THEN Choke() END; threadIndex := WinBase.TlsAlloc(); IF threadIndex < 0 THEN Choke() END; cm := NEW(WinBase.LPCRITICAL_SECTION); WinBase.InitializeCriticalSection(cm); suspend_mu := NEW(Mutex); suspend_cnt := 0; threadMu := NEW(Mutex); self := CreateT(); LockMutex(threadMu); threadhandle := WinBase.GetCurrentThread(); processhandle := WinBase.GetCurrentProcess(); IF WinBase.DuplicateHandle(processhandle, threadhandle, processhandle, LOOPHOLE(ADR(self.handle), WinNT.PHANDLE), 0, 0, WinNT.DUPLICATE_SAME_ACCESS) = 0 THEN Choke(); END; self.slot := AssignSlot (self); self.id := nextId; INC (nextId); self.next := self; self.prev := self; allThreads := self; self.stackbase := RTLinker.info.bottom_of_stack; IF self.stackbase = NIL THEN Choke(); END; UnlockMutex(threadMu); SetSelf (self); END Init; BEGIN END ThreadWin32. From jayk123 at hotmail.com Mon Jan 28 13:25:20 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 28 Jan 2008 12:25:20 +0000 Subject: [M3devel] nt386gnu threads? Message-ID: ok, I partially take that back. It looks like pthreads are the path of least resistance.. but still probably not great perf since cygwin pthread mutexes are kernel objects.. (Win32 critical sections only involve the kernel if there is contention, Win32 mutexes are kernel objects.) - Jay From: jayk123 at hotmail.comTo: m3devel at elegosoft.comSubject: nt386gnu threads?Date: Mon, 28 Jan 2008 11:29:31 +0000 Can anyone confirm my read that PM3's NT386GNU used user/vtalarm threads?PM3 appears to have no PThread support ant its NT386GNU appears to have OS_TYPE=POSIX.Heck, even its NT386 has OS_TYPE=POSIX, but its NT386 is probably dead/broken. 1) I'm too lazy to tediously rewrite Cygwin's pthread.h et. al. into Modula-3.2) The thread library you pick is not an independent decision. The Modula-3 File I/O libraries interact with the threading library at least a little bit. The path of less resistance seems to be user/vtalarm threads for now, untilsuch time as Cygwin Upthread.i3 is written.(That is, neither pthreads nor win32 satisfied my laziness; I'm going to try user/vtalarm threads, see how it goes; I'm sure they aren't very good, but...) - Jay 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 neels at elego.de Mon Jan 28 13:25:40 2008 From: neels at elego.de (Neels Janosch Hofmeyr) Date: Mon, 28 Jan 2008 13:25:40 +0100 Subject: [M3devel] new unknown qualification errors Message-ID: <479DC9C4.30505@elego.de> Hi devel, I am trying to compile the suplib with the new 5.5.1 snapshot cm3. It worked fine with 5.4.0, but now I get errors I cannot figure out how to correct: ===> suplib --- building in LINUXLIBC6 --- new source -> compiling StatBufOffT64.m3 "../src/StatBufOffT64.m3", line 40: unknown qualification '.' (asLong) "../src/StatBufOffT64.m3", line 45: unknown qualification '.' (assignOffT) 2 errors encountered new source -> compiling Ugzip.m3 "../src/Ugzip.m3", line 63: unknown qualification '.' (DisableSwitching) "../src/Ugzip.m3", line 67: unknown qualification '.' (EnableSwitching) "../src/Ugzip.m3", line 74: unknown qualification '.' (DisableSwitching) "../src/Ugzip.m3", line 78: unknown qualification '.' (EnableSwitching) 4 errors encountered new source -> compiling CVTree.m3 "../src/CVTree.m3", line 315: unknown qualification '.' (DisableSwitching) "../src/CVTree.m3", line 319: unknown qualification '.' (EnableSwitching) "../src/CVTree.m3", line 325: unknown qualification '.' (DisableSwitching) "../src/CVTree.m3", line 329: unknown qualification '.' (EnableSwitching) "../src/CVTree.m3", line 335: unknown qualification '.' (DisableSwitching) "../src/CVTree.m3", line 339: unknown qualification '.' (EnableSwitching) 6 errors encountered compilation failed => not building library "libsuplib.a" Fatal Error: package build failed I need help with all of these. However, I tried investigating the first one: Utypes.asLong() By coincidence, I saw that in FSPosix.m3, a line saying status.size := Utypes.asLong(statBuf.st_size); was changed to status.size := ORD(statBuf.st_size); Reading the log for the linux/Utypes.i3 gets me confused. It says how to make a off_t from a long, but doesn't say anything about the reverse direction. Is ORD(x) always the way to go? Here is the log extract: revision 1.4 date: 2007-11-29 03:53:15 +0100; author: hosking; state: Exp; lines: +0 -3; commitid: 3xU0vDzVxflBSpHs; Remove residual implementations of Utypes.asLong and Utypes.assignOffT. ---------------------------- revision 1.3 date: 2004-01-30 18:45:34 +0100; author: wagner; state: Exp; lines: +1 -0; add a procedure to assign values to off_t variables, as they may now be structured types, depending on the platform: PROCEDURE expandAssign(VAR dest: off_t; src: long) Well, where would API changes like these be documented, if I ever need to look them up on my own? Thanks, -- Neels Janosch Hofmeyr Software Developer neels at elego.de Public Key: http://binarchy.net/neels/neels.hofmeyr.public.key.asc elego Software Solutions GmbH http://www.elegosoft.com Gustav-Meyer-Allee 25, Geb?ude 12 HRB 77719 13355 Berlin, Germany Amtsgericht Charlottenburg Tel.: +49 30 23 45 86 96 Sitz der Gesellschaft: Berlin Fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Olaf Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From jayk123 at hotmail.com Mon Jan 28 13:37:12 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 28 Jan 2008 12:37:12 +0000 Subject: [M3devel] heap vs. stack? (sort of) In-Reply-To: References: Message-ID: I totally want common code, there's just no point in moving it into a separate function. For now I used a separate function, and I made it nested. I also tried WITH that got its value from "PickBuffer", also a useless function but at least small, but functions can't return open arrays. The problem with heap allocation is that it is slow. This code is optimizing it away in the first place for "small" strings, that's not my doing. Of course you have to pick some heuristic "small" and hope not to blow too much wasted stack. 256 bytes of stack is not small sometimes. It appears that nested functions have to occur up in the variable section but that is very dificult to glean from the documentation or the error messages. Blech. - Jay > Date: Mon, 28 Jan 2008 12:39:10 +0100> From: lemming at henning-thielemann.de> Subject: Re: [M3devel] heap vs. stack? (sort of)> To: jayk123 at hotmail.com> CC: m3devel at elegosoft.com> > > On Mon, 28 Jan 2008, Jay wrote:> > > Is it possible to have this pattern in Modula-3:> >> > PROCEDURE Parse (nm: TEXT; host: BOOLEAN): T = VAR len := Text.Length (nm); buf: ARRAY [0..255] OF CHAR; BEGIN IF (len <= NUMBER (buf)) THEN RETURN DoParse (nm, SUBARRAY (buf, 0, len), host); ELSE RETURN DoParse (nm, NEW (REF ARRAY OF CHAR, len)^, host); END; END Parse;> >> > PROCEDURE DoParse (nm_txt: TEXT; VAR nm: ARRAY OF CHAR; host: BOOLEAN): T => > I think it is a good idea to encapsulate the common code in DoParse. If> DoParse needs local variables, it can be turned into a local PROCEDURE of> Parse. On the other hand I doubt that it is sensible to reserve 256 bytes> on the stack also if they are not used, or only a part of them are used.> What's bad about always using NEW? I think Modula-3's memory management> has optimizations for small amounts of memory. _________________________________________________________________ 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 Jan 28 13:38:38 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 28 Jan 2008 12:38:38 +0000 Subject: [M3devel] nt386gnu threads? In-Reply-To: <200801281204.m0SC4oNp025190@camembert.async.caltech.edu> References: Your message of "Mon, 28 Jan 2008 11:29:31 GMT." <200801281204.m0SC4oNp025190@camembert.async.caltech.edu> Message-ID: Um, so the file exists..does it get compiled? Did you look at the m3makefiles? I skimmed the m3makefiles. I have not tried building PM3 myself. - Jay > To: jayk123 at hotmail.com> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] nt386gnu threads? > Date: Mon, 28 Jan 2008 04:04:50 -0800> From: mika at async.caltech.edu> > I am almost certain it uses Win32 threads. Attached: ThreadWin32.m3> from PM3-Klagenfurt> > Mika> > Jay writes:> >--_ddef1601-2afe-4ff4-9567-11d7fc5d354a_> >Content-Type: text/plain; charset="iso-8859-1"> >Content-Transfer-Encoding: quoted-printable> >> >Can anyone confirm my read that PM3's NT386GNU used user/vtalarm threads?> ....> > > (* Copyright (C) 1994, Digital Equipment Corporation *)> (* All rights reserved. *)> (* See the file COPYRIGHT for a full description. *)> (* *)> (* portions Copyright 1996, Critical Mass, Inc. *)> (* *)> (* Last modified on Fri Apr 26 10:21:56 PDT 1996 by heydon *)> (* modified on Thu Jun 15 09:06:37 PDT 1995 by kalsow *)> (* modified on Tue Oct 4 10:34:00 PDT 1994 by isard *)> (* modified on Tue May 4 10:20:03 PDT 1993 by mjordan *)> (* modified on Wed Apr 21 16:31:21 PDT 1993 by mcjones *)> (* modified on Fri Mar 26 15:04:39 PST 1993 by birrell *)> > UNSAFE MODULE ThreadWin32> EXPORTS Scheduler, Thread, ThreadF, RTThreadInit, RTHooks;> > IMPORT RTHeapRep, RTLinker, RTMisc, WinBase, WinDef, WinNT, ThreadContext;> IMPORT Word;> (*** IMPORT RTIO; ***)> > (*----------------------------------------- Exceptions, types and globals ---*)> > VAR> cm: WinBase.LPCRITICAL_SECTION;> (* Global lock for internals of Mutex and Condition *)> > default_stack: WinDef.DWORD := 16384;> > nextId: Id := 1;> > REVEAL> Mutex = BRANDED "MUTEX Win32-1.0" OBJECT> cs: WinBase.LPCRITICAL_SECTION := NIL;> held: BOOLEAN := FALSE;> (* LL = self.cs *)> (* Because critical sections are thread re-entrant *)> END;> > Condition = BRANDED "Thread.Condition Win32-1.0" OBJECT> waiters: T := NIL;> (* LL = cm *)> (* List of threads waiting on this CV. *)> END;> > T = BRANDED "Thread.T Win32-1.0" OBJECT> next, prev: T := NIL;> (* LL = threadMu; global doubly-linked, circular list of all threads *)> nextIdle: T := NIL;> (* LL = threadMu; global list of idle threads *)> handle: WinNT.HANDLE := NIL;> (* LL = threadMu; thread handle in Windows *)> stackbase: ADDRESS := NIL;> (* LL = threadMu; base of thread stack for use by GC *)> closure: Closure := NIL;> (* LL = threadMu *)> result: REFANY := NIL;> (* LL = threadMu; if not self.completed, used only by self;> if self.completed, read-only. *)> cond: Condition;> (* LL = threadMu; wait here to join, or for rebirth *)> waitingOn: Condition := NIL;> (* LL = cm; CV that we're blocked on *)> nextWaiter: T := NIL;> (* LL = cm; queue of threads waiting on the same CV *)> waitSema: WinNT.HANDLE := NIL;> (* binary semaphore for blocking during "Wait" *)> alertable: BOOLEAN := FALSE;> (* LL = cm; distinguishes between "Wait" and "AlertWait" *)> alerted: BOOLEAN := FALSE;> (* LL = cm; the alert flag, of course *)> completed: BOOLEAN := FALSE;> (* LL = threadMu; indicates that "result" is set *)> joined: BOOLEAN := FALSE;> (* LL = threadMu; "Join" or "AlertJoin" has already returned *)> id: Id;> (* LL = threadMu; unique ID of this thread *)> slot: INTEGER;> (* LL = threadMu; index into global array of active, slotted threads *)> END;> > (*------------------------------------------- Caches of critical sections ---*)> > CONST> CSectCacheSize = 20;> (* Everything should work OK if these are 0 *)> > VAR> cSectCache: ARRAY [0..CSectCacheSize-1] OF WinBase.LPCRITICAL_SECTION;> cSectCacheContents := 0;> > PROCEDURE AllocCSect(m: Mutex) => (* LL = 0 *)> (* If we can take a critical section from the cache, > do so; otherwise create it. In any case, register the containing> Mutex with the GC so that we can clean-up on de-allocation. *)> VAR mcs: WinBase.LPCRITICAL_SECTION := NIL; lost_race := FALSE;> BEGIN> WinBase.EnterCriticalSection(cm);> IF cSectCacheContents > 0 THEN> DEC(cSectCacheContents);> m.cs := cSectCache[cSectCacheContents];> ELSE> WinBase.LeaveCriticalSection(cm);> mcs := NEW(WinBase.LPCRITICAL_SECTION);> WinBase.EnterCriticalSection(cm);> IF (m.cs = NIL) THEN> m.cs := mcs;> WinBase.InitializeCriticalSection(m.cs);> ELSE> (* somebody else beat us thru the preceding NEW *)> lost_race := TRUE;> END;> END;> WinBase.LeaveCriticalSection(cm);> > IF lost_race> THEN DISPOSE (mcs);> ELSE RTHeapRep.RegisterFinalCleanup(m, FreeCSect);> END;> END AllocCSect;> > PROCEDURE FreeCSect(r: REFANY (*Mutex*) ) => (* LL < cm *)> (* Must not dereference any traced REF when called from GC *)> VAR m: Mutex := r;> BEGIN> WinBase.EnterCriticalSection(cm);> IF m.cs # NIL THEN> IF cSectCacheContents < CSectCacheSize THEN> cSectCache[cSectCacheContents] := m.cs;> INC(cSectCacheContents);> ELSE> WinBase.DeleteCriticalSection(m.cs);> DISPOSE(m.cs);> END;> m.cs := NIL;> END;> WinBase.LeaveCriticalSection(cm)> END FreeCSect;> > (*----------------------------------------------------------------- Mutex ---*)> (* Note: RTHooks.{Unlock,Lock}Mutex are the routines called directly by> the compiler. Acquire and Release are the routines exported through> the Thread interface *)> > PROCEDURE Acquire (m: Mutex) => BEGIN> LockMutex (m);> END Acquire;> > PROCEDURE Release (m: Mutex) => BEGIN> UnlockMutex (m);> END Release;> > PROCEDURE (*RTHooks.*)LockMutex (m: Mutex) => BEGIN> IF (m.cs = NIL) THEN AllocCSect(m); END;> WinBase.EnterCriticalSection(m.cs);> IF m.held THEN Die("attempt to lock mutex already locked by self") END;> m.held := TRUE;> END LockMutex;> > PROCEDURE (*RTHooks.*)UnlockMutex(m: Mutex) => BEGIN> IF NOT m.held THEN Die("attempt to release an unlocked mutex") END;> m.held := FALSE;> WinBase.LeaveCriticalSection(m.cs);> END UnlockMutex;> > (*---------------------------------------- Condition variables and Alerts ---*)> > PROCEDURE InnerWait(m: Mutex; c: Condition; self: T) => (* LL = cm+m on entry; LL = m on exit *)> BEGIN> <* ASSERT( (self.waitingOn=NIL) AND (self.nextWaiter=NIL) ) *>> self.waitingOn := c;> self.nextWaiter := c.waiters;> c.waiters := self;> WinBase.LeaveCriticalSection(cm);> UnlockMutex(m);> IF WinBase.WaitForSingleObject(self.waitSema, WinBase.INFINITE) # 0 THEN> Choke();> END;> LockMutex(m);> END InnerWait;> > PROCEDURE InnerTestAlert(self: T) RAISES {Alerted} => (* LL = cm on entry; LL = cm on normal exit, 0 on exception exit *)> (* If self.alerted, clear "alerted", leave cm and raise> "Alerted". *)> BEGIN> IF self.alerted THEN> self.alerted := FALSE;> WinBase.LeaveCriticalSection(cm);> RAISE Alerted> END;> END InnerTestAlert;> > PROCEDURE AlertWait (m: Mutex; c: Condition) RAISES {Alerted} => (* LL = m *)> VAR self := Self();> BEGIN> IF self = NIL THEN Die("AlertWait called from non-Modula-3 thread") END;> WinBase.EnterCriticalSection(cm);> InnerTestAlert(self);> self.alertable := TRUE;> InnerWait(m, c, self);> WinBase.EnterCriticalSection(cm);> InnerTestAlert(self);> WinBase.LeaveCriticalSection(cm);> END AlertWait;> > PROCEDURE Wait (m: Mutex; c: Condition) => (* LL = m *)> VAR self := Self();> BEGIN> IF self = NIL THEN Die("Wait called from non-Modula-3 thread") END;> WinBase.EnterCriticalSection(cm);> InnerWait(m, c, self);> END Wait;> > PROCEDURE DequeueHead(c: Condition) => (* LL = cm *)> VAR t: T; prevCount: WinDef.LONG;> BEGIN> t := c.waiters; c.waiters := t.nextWaiter;> t.nextWaiter := NIL;> t.waitingOn := NIL;> t.alertable := FALSE;> IF WinBase.ReleaseSemaphore(t.waitSema, 1, ADR(prevCount)) = 0 THEN> Choke();> END;> END DequeueHead;> > PROCEDURE Signal (c: Condition) => BEGIN> WinBase.EnterCriticalSection(cm);> IF c.waiters # NIL THEN DequeueHead(c) END;> WinBase.LeaveCriticalSection(cm);> END Signal;> > PROCEDURE Broadcast (c: Condition) => BEGIN> WinBase.EnterCriticalSection(cm);> WHILE c.waiters # NIL DO DequeueHead(c) END;> WinBase.LeaveCriticalSection(cm);> END Broadcast;> > PROCEDURE Alert(t: T) => VAR prevCount: WinDef.LONG; prev, next: T;> BEGIN> IF t = NIL THEN Die("Alert called from non-Modula-3 thread") END;> WinBase.EnterCriticalSection(cm);> t.alerted := TRUE;> IF t.alertable THEN> (* Dequeue from any CV and unblock from the semaphore *)> IF t.waitingOn # NIL THEN> next := t.waitingOn.waiters; prev := NIL;> WHILE next # t DO> <* ASSERT(next#NIL) *>> prev := next; next := next.nextWaiter;> END;> IF prev = NIL THEN> t.waitingOn.waiters := t.nextWaiter> ELSE> prev.nextWaiter := t.nextWaiter;> END;> t.nextWaiter := NIL;> t.waitingOn := NIL;> END;> t.alertable := FALSE;> IF WinBase.ReleaseSemaphore(t.waitSema, 1, ADR(prevCount)) = 0 THEN> Choke();> END;> END;> WinBase.LeaveCriticalSection(cm);> END Alert;> > PROCEDURE TestAlert(): BOOLEAN => VAR self := Self(); result: BOOLEAN;> BEGIN> IF self = NIL THEN> (* Not created by Fork; not alertable *)> RETURN FALSE> ELSE> WinBase.EnterCriticalSection(cm);> result := self.alerted; IF result THEN self.alerted := FALSE END;> WinBase.LeaveCriticalSection(cm);> RETURN result> END;> END TestAlert;> > (*------------------------------------------------------------------ Self ---*)> > VAR> threadIndex: WinDef.DWORD;> (* read-only; TLS (Thread Local Storage) index *)> > VAR (* LL = threadMu *)> n_slotted := 0;> next_slot := 1;> slots : REF ARRAY OF T; (* NOTE: we don't use slots[0]. *)> > PROCEDURE Self (): T => (* If not the initial thread and not created by Fork, returns NIL *)> VAR t: T; x := LOOPHOLE(WinBase.TlsGetValue(threadIndex), INTEGER);> BEGIN> IF (x < 1) THEN RETURN NIL; END;> t := slots[x];> IF (t.slot # x) THEN Die ("thread with bad slot!"); END;> RETURN t;> END Self;> > PROCEDURE SetSelf (t: T) => (* LL = 0 *)> BEGIN> IF (slots [t.slot] # t) THEN Die ("unslotted thread!"); END;> IF WinBase.TlsSetValue(threadIndex, LOOPHOLE(t.slot, WinDef.LPVOID)) = 0> THEN Choke();> END;> END SetSelf;> > PROCEDURE AssignSlot (t: T): INTEGER => (* LL = threadMu *)> BEGIN> (* make sure we have room to register this guy *)> IF (slots = NIL) THEN slots := NEW (REF ARRAY OF T, 20); END;> IF (n_slotted >= LAST (slots^)) THEN ExpandSlots (); END;> > (* look for an empty slot *)> WHILE (slots [next_slot] # NIL) DO> INC (next_slot);> IF (next_slot >= NUMBER (slots^)) THEN next_slot := 1; END;> END;> > INC (n_slotted);> t.slot := next_slot;> slots [next_slot] := t;> RETURN t.slot;> END AssignSlot;> > PROCEDURE FreeSlot (t: T) => (* LL = threadMu *)> BEGIN> DEC (n_slotted);> WITH z = slots [t.slot] DO> IF (z # t) THEN Die ("unslotted thread!"); END;> z := NIL;> END;> t.slot := 0;> END FreeSlot;> > PROCEDURE ExpandSlots () => VAR n := NUMBER (slots^); new := NEW (REF ARRAY OF T, n+n);> BEGIN> SUBARRAY (new^, 0, n) := slots^;> slots := new;> END ExpandSlots;> > (*------------------------------------------------------------ Fork, Join ---*)> > CONST> MaxIdle = 20;> > VAR (* LL=threadMu *)> threadMu: Mutex;> allThreads: T := NIL; (* global list of registered threads *)> idleThreads: T := NIL; (* global list of idle threads *)> nIdle := 0;> > PROCEDURE CreateT(): T => (* LL < threadMu, because allocated a traced reference may cause> the allocator to start a collection which will call SuspendOthers> which will try to acquire threadMu. *)> BEGIN> RETURN NEW(T, waitSema := WinBase.CreateSemaphore(NIL, 0, 1, NIL),> cond := NEW(Condition));> END CreateT;> > (* ThreadBase calls ThreadMain after finding (approximately) where> its stack begins. This dance ensures that all of ThreadMain's> traced references are within the stack scanned by the collector. *)> > PROCEDURE ThreadBase(param: WinDef.DWORD): WinDef.DWORD => VAR self: T; x := LOOPHOLE(param, INTEGER);> BEGIN> LockMutex(threadMu);> self := slots[x];> self.stackbase := ADR(self);> UnlockMutex(threadMu);> ThreadMain(self);> RETURN 0;> END ThreadBase;> > PROCEDURE ThreadMain(self: T) => TYPE> ObjRef = UNTRACED REF MethodList;> MethodList = UNTRACED REF RECORD typecode: INTEGER; method0: ADDRESS END;> VAR next_self: T; cl: Closure; res: REFANY;> BEGIN> LOOP (* The incarnation loop. *)> SetSelf (self);> > LockMutex(threadMu);> cl := self.closure;> self.id := nextId; INC (nextId);> UnlockMutex(threadMu);> > IF (cl = NIL) THEN> Die ("NIL closure passed to Thread.Fork!");> ELSIF (LOOPHOLE (cl, ObjRef)^^.method0 = NIL) THEN> Die ("NIL apply method passed to Thread.Fork!");> END;> > res := cl.apply();> > next_self := NIL;> IF nIdle < MaxIdle THEN> (* apparently the cache isn't full, although we don't hold threadMu> so we can't be certain... *)> next_self := NEW(T);> END;> > LockMutex(threadMu);> self.result := res;> self.completed := TRUE;> > IF next_self # NIL THEN> (* transplant the guts of "self" into next_self *)> next_self.handle := self.handle;> next_self.stackbase := self.stackbase;> next_self.waitSema := self.waitSema;> next_self.cond := self.cond;> > (* put "next_self" on the list of all threads *)> next_self.next := allThreads;> next_self.prev := allThreads.prev;> allThreads.prev.next := next_self;> allThreads.prev := next_self;> > (* put "next_self" on the list of idle threads *)> next_self.nextIdle := idleThreads;> idleThreads := next_self;> INC(nIdle);> > (* finish making "self" an orphan *)> IF allThreads = self THEN allThreads := self.next; END;> self.next.prev := self.prev;> self.prev.next := self.next;> self.next := NIL;> self.prev := NIL;> self.handle := NIL;> self.stackbase := NIL;> END;> UnlockMutex(threadMu);> > Broadcast(self.cond); (* let everybody know that "self" is done *)> > IF next_self = NIL THEN EXIT; END;> self := next_self;> IF WinBase.WaitForSingleObject(self.waitSema, WinBase.INFINITE) # 0 THEN> Choke();> END;> END;> > (* remove ourself from the list of all threads *)> LockMutex(threadMu);> IF allThreads = self THEN allThreads := self.next; END;> self.next.prev := self.prev;> self.prev.next := self.next;> self.next := NIL;> self.prev := NIL;> IF WinBase.CloseHandle(self.waitSema) = 0 THEN Choke() END;> IF WinBase.CloseHandle(self.handle) = 0 THEN Choke() END;> self.handle := NIL;> self.waitSema := NIL;> FreeSlot (self);> UnlockMutex(threadMu);> END ThreadMain;> > PROCEDURE Fork(closure: Closure): T => VAR> t: T := NIL;> id, stack_size: WinDef.DWORD;> prevCount: WinDef.LONG;> new_born: BOOLEAN;> BEGIN> (* determine the initial size of the stack for this thread *)> stack_size := default_stack;> TYPECASE closure OF SizedClosure (scl) =>> IF scl.stackSize # 0 THEN > stack_size := scl.stackSize * BYTESIZE(INTEGER);> END;> ELSE (*skip*)> END;> > (* try the cache for a thread *)> LockMutex(threadMu);> IF nIdle > 0 THEN> new_born := FALSE;> <* ASSERT(idleThreads # NIL) *>> DEC(nIdle);> t := idleThreads;> idleThreads := t.nextIdle;> t.nextIdle := NIL;> t.slot := AssignSlot (t);> ELSE (* empty cache => we need a fresh thread *)> new_born := TRUE;> UnlockMutex(threadMu);> t := CreateT();> LockMutex(threadMu);> t.slot := AssignSlot (t);> t.handle := WinBase.CreateThread(NIL, stack_size,> LOOPHOLE(ThreadBase, WinBase.LPTHREAD_START_ROUTINE),> LOOPHOLE(t.slot,WinDef.LPVOID), WinBase.CREATE_SUSPENDED, ADR(id));> t.next := allThreads;> t.prev := allThreads.prev;> allThreads.prev.next := t;> allThreads.prev := t;> END;> IF (t.handle = NIL) THEN Choke() END;> t.closure := closure;> UnlockMutex(threadMu);> > IF new_born THEN> IF WinBase.ResumeThread(t.handle) = -1 THEN Choke() END;> ELSE> IF WinBase.ReleaseSemaphore(t.waitSema, 1, ADR(prevCount)) = 0 THEN> Choke();> END;> END;> > RETURN t> END Fork;> > PROCEDURE Join(t: T): REFANY => VAR res: REFANY;> BEGIN> LockMutex(threadMu);> IF t.joined THEN Die("attempt to join with thread twice"); END;> WHILE NOT t.completed DO Wait(threadMu, t.cond) END;> res := t.result;> t.result := NIL;> t.joined := TRUE;> UnlockMutex(threadMu);> RETURN res;> END Join;> > PROCEDURE AlertJoin(t: T): REFANY RAISES {Alerted} => VAR res: REFANY;> BEGIN> LockMutex(threadMu);> TRY> IF t.joined THEN Die("attempt to join with thread twice"); END;> WHILE NOT t.completed DO AlertWait(threadMu, t.cond) END;> res := t.result;> t.result := NIL;> t.joined := TRUE;> FINALLY> UnlockMutex(threadMu);> END;> RETURN res;> END AlertJoin;> > (*------------------------------------------------ timer-based preemption ---*)> > PROCEDURE SetSwitchingInterval (<*UNUSED*> usec: CARDINAL) => BEGIN> END SetSwitchingInterval;> > (*---------------------------------------------------- Scheduling support ---*)> > PROCEDURE Pause(n: LONGREAL) => VAR amount, thisTime: LONGREAL;> CONST Limit = FLOAT(LAST(CARDINAL), LONGREAL) / 1000.0D0 - 1.0D0;> BEGIN> amount := n;> WHILE amount > 0.0D0 DO> thisTime := MIN (Limit, amount);> amount := amount - thisTime;> WinBase.Sleep(ROUND(thisTime*1000.0D0));> END;> END Pause;> > PROCEDURE AlertPause(n: LONGREAL) RAISES {Alerted} => VAR amount, thisTime: LONGREAL;> CONST Limit = FLOAT(LAST(CARDINAL), LONGREAL) / 1000.0D0 - 1.0D0;> VAR self: T;> BEGIN> self := Self();> amount := n;> WHILE amount > 0.0D0 DO> thisTime := MIN (Limit, amount);> amount := amount - thisTime;> WinBase.EnterCriticalSection(cm);> InnerTestAlert(self);> self.alertable := TRUE;> <* ASSERT(self.waitingOn = NIL) *>> WinBase.LeaveCriticalSection(cm);> EVAL WinBase.WaitForSingleObject(self.waitSema, ROUND(thisTime*1.0D3));> WinBase.EnterCriticalSection(cm);> self.alertable := FALSE;> IF self.alerted THEN> (* Sadly, the alert might have happened after we timed out on the> semaphore and before we entered "cm". In that case, we need to> decrement the semaphore's count *)> EVAL WinBase.WaitForSingleObject(self.waitSema, 0);> InnerTestAlert(self);> END;> WinBase.LeaveCriticalSection(cm);> END;> END AlertPause;> > PROCEDURE Yield() => BEGIN> WinBase.Sleep(0);> END Yield;> > (*--------------------------------------------------- Stack size controls ---*)> > PROCEDURE GetDefaultStackSize(): CARDINAL=> BEGIN> RETURN default_stack DIV BYTESIZE (INTEGER);> END GetDefaultStackSize;> > PROCEDURE MinDefaultStackSize(new_min: CARDINAL)=> BEGIN> default_stack := MAX (default_stack, new_min * BYTESIZE (INTEGER));> END MinDefaultStackSize;> > PROCEDURE IncDefaultStackSize(inc: CARDINAL)=> BEGIN> INC (default_stack, inc * BYTESIZE (INTEGER));> END IncDefaultStackSize;> > (*-------------------------------------------- Exception handling support ---*)> > VAR handlersIndex: INTEGER;> > PROCEDURE GetCurrentHandlers(): ADDRESS=> BEGIN> RETURN WinBase.TlsGetValue(handlersIndex);> END GetCurrentHandlers;> > PROCEDURE SetCurrentHandlers(h: ADDRESS)=> BEGIN> EVAL WinBase.TlsSetValue(handlersIndex, h);> END SetCurrentHandlers;> > PROCEDURE PushEFrame (frame: ADDRESS) => TYPE Frame = UNTRACED REF RECORD next: ADDRESS END;> VAR f := LOOPHOLE (frame, Frame);> BEGIN> f.next := WinBase.TlsGetValue(handlersIndex);> EVAL WinBase.TlsSetValue(handlersIndex, f);> END PushEFrame;> > PROCEDURE PopEFrame (frame: ADDRESS) => BEGIN> EVAL WinBase.TlsSetValue(handlersIndex, frame);> END PopEFrame;> > (*--------------------------------------------- Garbage collector support ---*)> > VAR> suspend_mu : Mutex;> suspend_cnt : CARDINAL := 0; (* LL = suspend_mu *)> > PROCEDURE SuspendOthers () => (* LL=0. Always bracketed with ResumeOthers, which will unlock threadMu *)> VAR t: T; self := Self (); cnt: CARDINAL;> BEGIN> LOCK suspend_mu DO> cnt := suspend_cnt;> INC (suspend_cnt);> END;> > IF (cnt = 0) THEN> LockMutex(threadMu);> > WinBase.EnterCriticalSection(cm);> (* We must hold 'cm' to guarantee that no suspended thread holds it.> Otherwise, when the collector tries to acquire a mutex or signal> a condition, it will deadlock with the suspended thread that> holds 'cm'. *)> > t := self.next;> WHILE (t # self) DO> IF WinBase.SuspendThread(t.handle) = -1 THEN Choke() END;> t := t.next;> END;> WinBase.LeaveCriticalSection(cm);> END;> END SuspendOthers;> > PROCEDURE ResumeOthers () => (* LL=threadMu. Always preceded by SuspendOthers, which locks threadMu *)> VAR t: T; self := Self (); cnt: CARDINAL;> BEGIN> LOCK suspend_mu DO> DEC (suspend_cnt);> cnt := suspend_cnt;> END;> > IF (cnt = 0) THEN> t := self.next;> WHILE (t # self) DO> IF WinBase.ResumeThread(t.handle) = -1 THEN Choke() END;> t := t.next;> END;> UnlockMutex(threadMu);> END;> END ResumeOthers;> > PROCEDURE ProcessStacks (p: PROCEDURE (start, stop: ADDRESS)) => (* LL=threadMu. Only called within {SuspendOthers, ResumeOthers} *)> CONST UserRegs = Word.Or(ThreadContext.CONTEXT_CONTROL,> ThreadContext.CONTEXT_INTEGER);> VAR t := allThreads; context: ThreadContext.CONTEXT; fixed_SP: ADDRESS;> BEGIN> REPEAT> IF (t.stackbase # NIL) THEN> context.ContextFlags := UserRegs;> IF WinBase.GetThreadContext(t.handle, ADR(context))=0 THEN Choke() END;> fixed_SP := LOOPHOLE (context.Esp, ADDRESS);> IF (t.stackbase - fixed_SP) > 10000 THEN> fixed_SP := VerifySP (fixed_SP, t.stackbase);> END;> p(fixed_SP, t.stackbase); (* Process the stack *)> p(ADR(context.Edi), ADR(context.Eip)); (* Process the registers *)> END;> t := t.next;> UNTIL (t = allThreads);> END ProcessStacks;> > PROCEDURE VerifySP (start, stop: ADDRESS): ADDRESS => (* Apparently, Win95 will lie about a thread's stack pointer! *)> (* Verify that the claimed stack pages are really readable... *)> CONST PageSize = 4096;> CONST N = BYTESIZE (info);> VAR info: WinNT.MEMORY_BASIC_INFORMATION;> BEGIN> > (******> RTIO.PutText ("GC: suspicious stack: [");> RTIO.PutAddr (start);> RTIO.PutText ("..");> RTIO.PutAddr (stop);> RTIO.PutText ("]\n");> RTIO.Flush ();> ******)> > info.BaseAddress := LOOPHOLE (stop-1, ADDRESS);> LOOP> IF (info.BaseAddress <= start) THEN> info.BaseAddress := start;> EXIT;> END;> > IF WinBase.VirtualQuery (info.BaseAddress, ADR (info), N) # N THEN> Choke();> END;> > (*******> RTIO.PutText (" --> "); RTIO.PutAddr (info.BaseAddress);> RTIO.PutText (" "); RTIO.PutAddr (info.AllocationBase);> RTIO.PutText (" "); RTIO.PutHex (info.AllocationProtect);> RTIO.PutText (" "); RTIO.PutHex (info.RegionSize);> RTIO.PutText (" "); RTIO.PutHex (info.State);> RTIO.PutText (" "); RTIO.PutHex (info.Protect);> RTIO.PutText (" "); RTIO.PutHex (info.Type);> RTIO.PutText ("\n");> *******)> > (* is this chunk readable? *)> IF (info.Protect # WinNT.PAGE_READWRITE)> AND (info.Protect # WinNT.PAGE_READONLY) THEN> (* nope, return the base of the last good chunk *)> INC (info.BaseAddress, info.RegionSize);> EXIT;> END;> > (* yep, try the next chunk *)> DEC (info.BaseAddress, PageSize);> END;> > (********> RTIO.PutText (" ==> [");> RTIO.PutAddr (info.BaseAddress);> RTIO.PutText ("..");> RTIO.PutAddr (stop);> RTIO.PutText ("]");> RTIO.PutText ("\n");> RTIO.Flush ();> *******)> > RETURN info.BaseAddress;> END VerifySP;> > (*------------------------------------------------------------ misc. junk ---*)> > PROCEDURE MyId(): Id RAISES {}=> VAR self := Self ();> BEGIN> RETURN self.id;> END MyId;> > (*---------------------------------------------------------------- errors ---*)> > PROCEDURE Die(msg: TEXT) => BEGIN> RTMisc.FatalError ("ThreadWin32.m3", 721, "Thread client error: ", msg);> END Die;> > PROCEDURE Choke() => BEGIN> RTMisc.FatalErrorI (> "ThreadWin32.m3, line 726: Windows OS failure, GetLastError = ",> WinBase.GetLastError ());> END Choke;> > (*-------------------------------------------------------- Initialization ---*)> > > PROCEDURE Init() => VAR> self: T;> threadhandle, processhandle: WinNT.HANDLE;> BEGIN> handlersIndex := WinBase.TlsAlloc();> IF handlersIndex < 0 THEN Choke() END;> > threadIndex := WinBase.TlsAlloc();> IF threadIndex < 0 THEN Choke() END;> > cm := NEW(WinBase.LPCRITICAL_SECTION);> WinBase.InitializeCriticalSection(cm);> > suspend_mu := NEW(Mutex);> suspend_cnt := 0;> > threadMu := NEW(Mutex);> self := CreateT();> > LockMutex(threadMu);> threadhandle := WinBase.GetCurrentThread();> processhandle := WinBase.GetCurrentProcess();> IF WinBase.DuplicateHandle(processhandle, threadhandle, processhandle,> LOOPHOLE(ADR(self.handle), WinNT.PHANDLE), 0,> 0, WinNT.DUPLICATE_SAME_ACCESS) = 0 THEN> Choke();> END;> self.slot := AssignSlot (self);> self.id := nextId; INC (nextId);> self.next := self;> self.prev := self;> allThreads := self;> self.stackbase := RTLinker.info.bottom_of_stack;> IF self.stackbase = NIL THEN Choke(); END;> UnlockMutex(threadMu);> SetSelf (self);> END Init;> > BEGIN> END ThreadWin32. _________________________________________________________________ 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 Jan 28 13:50:54 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 28 Jan 2008 12:50:54 +0000 Subject: [M3devel] new unknown qualification errors In-Reply-To: <479DC9C4.30505@elego.de> References: <479DC9C4.30505@elego.de> Message-ID: (Btw, I find these error messages poor. It should say asLong is not defined in module X, or type T in module X, and give full paths to the two relevant files..meanwhile, my cm3 is outputing user-unfriendly forward slashes on Windows so I could perhaps blow past uninteresting problems oops :) ) - Jay > Date: Mon, 28 Jan 2008 13:25:40 +0100> From: neels at elego.de> To: m3devel at elego.de> Subject: [M3devel] new unknown qualification errors> > Hi devel,> > I am trying to compile the suplib with the new 5.5.1 snapshot cm3. It > worked fine with 5.4.0, but now I get errors I cannot figure out how to > correct:> > ===> suplib> --- building in LINUXLIBC6 ---> > new source -> compiling StatBufOffT64.m3> "../src/StatBufOffT64.m3", line 40: unknown qualification '.' (asLong)> "../src/StatBufOffT64.m3", line 45: unknown qualification '.' (assignOffT)> 2 errors encountered> new source -> compiling Ugzip.m3> "../src/Ugzip.m3", line 63: unknown qualification '.' (DisableSwitching)> "../src/Ugzip.m3", line 67: unknown qualification '.' (EnableSwitching)> "../src/Ugzip.m3", line 74: unknown qualification '.' (DisableSwitching)> "../src/Ugzip.m3", line 78: unknown qualification '.' (EnableSwitching)> 4 errors encountered> new source -> compiling CVTree.m3> "../src/CVTree.m3", line 315: unknown qualification '.' (DisableSwitching)> "../src/CVTree.m3", line 319: unknown qualification '.' (EnableSwitching)> "../src/CVTree.m3", line 325: unknown qualification '.' (DisableSwitching)> "../src/CVTree.m3", line 329: unknown qualification '.' (EnableSwitching)> "../src/CVTree.m3", line 335: unknown qualification '.' (DisableSwitching)> "../src/CVTree.m3", line 339: unknown qualification '.' (EnableSwitching)> 6 errors encountered> compilation failed => not building library "libsuplib.a"> Fatal Error: package build failed> > > I need help with all of these. However, I tried investigating the first > one: Utypes.asLong()> > By coincidence, I saw that in FSPosix.m3, a line saying> status.size := Utypes.asLong(statBuf.st_size);> was changed to> status.size := ORD(statBuf.st_size);> > Reading the log for the linux/Utypes.i3 gets me confused. It says how to > make a off_t from a long, but doesn't say anything about the reverse > direction. Is ORD(x) always the way to go? Here is the log extract:> > revision 1.4> date: 2007-11-29 03:53:15 +0100; author: hosking; state: Exp; lines: > +0 -3; commitid: 3xU0vDzVxflBSpHs;> Remove residual implementations of Utypes.asLong and Utypes.assignOffT.> ----------------------------> revision 1.3> date: 2004-01-30 18:45:34 +0100; author: wagner; state: Exp; lines: > +1 -0;> add a procedure to assign values to off_t variables, as they may now be> structured types, depending on the platform:> > PROCEDURE expandAssign(VAR dest: off_t; src: long)> > > Well, where would API changes like these be documented, if I ever need > to look them up on my own?> Thanks,> > -- > Neels Janosch Hofmeyr> Software Developer> > neels at elego.de> Public Key: http://binarchy.net/neels/neels.hofmeyr.public.key.asc> > elego Software Solutions GmbH http://www.elegosoft.com> Gustav-Meyer-Allee 25, Geb?ude 12 HRB 77719> 13355 Berlin, Germany Amtsgericht Charlottenburg> Tel.: +49 30 23 45 86 96 Sitz der Gesellschaft: Berlin> Fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Olaf Wagner> > _________________________________________________________________ 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 dabenavidesd at yahoo.es Mon Jan 28 13:51:43 2008 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Mon, 28 Jan 2008 13:51:43 +0100 (CET) Subject: [M3devel] new unknown qualification errors In-Reply-To: <479DC9C4.30505@elego.de> Message-ID: <762336.53722.qm@web27110.mail.ukl.yahoo.com> Hi Neels: If I rememeber this happen since some time ago. Just look this post of mine, you need to change the IMPORT and the lines that compiler complains: https://mail.elegosoft.com/pipermail/m3devel/2008-January/000806.html: importing Scheduler instead of SchedulerPosix Then replace the call for the functions of SchedulerPosix for Scheduler I think that would solve that problem. Thanks, Daniel Benavides Neels Janosch Hofmeyr escribi?: Hi devel, I am trying to compile the suplib with the new 5.5.1 snapshot cm3. It worked fine with 5.4.0, but now I get errors I cannot figure out how to correct: ===> suplib --- building in LINUXLIBC6 --- new source -> compiling StatBufOffT64.m3 "../src/StatBufOffT64.m3", line 40: unknown qualification '.' (asLong) "../src/StatBufOffT64.m3", line 45: unknown qualification '.' (assignOffT) 2 errors encountered new source -> compiling Ugzip.m3 "../src/Ugzip.m3", line 63: unknown qualification '.' (DisableSwitching) "../src/Ugzip.m3", line 67: unknown qualification '.' (EnableSwitching) "../src/Ugzip.m3", line 74: unknown qualification '.' (DisableSwitching) "../src/Ugzip.m3", line 78: unknown qualification '.' (EnableSwitching) 4 errors encountered new source -> compiling CVTree.m3 "../src/CVTree.m3", line 315: unknown qualification '.' (DisableSwitching) "../src/CVTree.m3", line 319: unknown qualification '.' (EnableSwitching) "../src/CVTree.m3", line 325: unknown qualification '.' (DisableSwitching) "../src/CVTree.m3", line 329: unknown qualification '.' (EnableSwitching) "../src/CVTree.m3", line 335: unknown qualification '.' (DisableSwitching) "../src/CVTree.m3", line 339: unknown qualification '.' (EnableSwitching) 6 errors encountered compilation failed => not building library "libsuplib.a" Fatal Error: package build failed I need help with all of these. However, I tried investigating the first one: Utypes.asLong() By coincidence, I saw that in FSPosix.m3, a line saying status.size := Utypes.asLong(statBuf.st_size); was changed to status.size := ORD(statBuf.st_size); Reading the log for the linux/Utypes.i3 gets me confused. It says how to make a off_t from a long, but doesn't say anything about the reverse direction. Is ORD(x) always the way to go? Here is the log extract: revision 1.4 date: 2007-11-29 03:53:15 +0100; author: hosking; state: Exp; lines: +0 -3; commitid: 3xU0vDzVxflBSpHs; Remove residual implementations of Utypes.asLong and Utypes.assignOffT. ---------------------------- revision 1.3 date: 2004-01-30 18:45:34 +0100; author: wagner; state: Exp; lines: +1 -0; add a procedure to assign values to off_t variables, as they may now be structured types, depending on the platform: PROCEDURE expandAssign(VAR dest: off_t; src: long) Well, where would API changes like these be documented, if I ever need to look them up on my own? Thanks, -- Neels Janosch Hofmeyr Software Developer neels at elego.de Public Key: http://binarchy.net/neels/neels.hofmeyr.public.key.asc elego Software Solutions GmbH http://www.elegosoft.com Gustav-Meyer-Allee 25, Geb?ude 12 HRB 77719 13355 Berlin, Germany Amtsgericht Charlottenburg Tel.: +49 30 23 45 86 96 Sitz der Gesellschaft: Berlin Fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Olaf Wagner --------------------------------- ?Con Mascota por primera vez? - S? un mejor Amigo Entra en Yahoo! Respuestas. -------------- next part -------------- An HTML attachment was scrubbed... URL: From neels at elego.de Mon Jan 28 14:30:29 2008 From: neels at elego.de (Neels Janosch Hofmeyr) Date: Mon, 28 Jan 2008 14:30:29 +0100 Subject: [M3devel] new unknown qualification errors In-Reply-To: <762336.53722.qm@web27110.mail.ukl.yahoo.com> References: <762336.53722.qm@web27110.mail.ukl.yahoo.com> Message-ID: <479DD8F5.1090001@elego.de> Thanks Daniel, that seems to work. However, if SchedulerPosix does not support these calls (DisableSwitching and EnableSwitching), do we not end up with concurreny problems? (This assuming that the Scheduler internally calls SchedulerPosix on POSIX platforms, which I am just wildly guessing...) Thanks again, Neels Daniel Alejandro Benavides D. wrote: > Hi Neels: > If I rememeber this happen since some time ago. Just look this post of > mine, you need to change the IMPORT and the lines that compiler complains: > https://mail.elegosoft.com/pipermail/m3devel/2008-January/000806.html: > importing Scheduler instead of SchedulerPosix > Then replace the call for the functions of SchedulerPosix for Scheduler > I think that would solve that problem. > > Thanks, > > Daniel Benavides > > > > > > */Neels Janosch Hofmeyr /* escribi?: > > Hi devel, > > I am trying to compile the suplib with the new 5.5.1 snapshot cm3. It > worked fine with 5.4.0, but now I get errors I cannot figure out > how to > correct: > > ===> suplib > --- building in LINUXLIBC6 --- > > new source -> compiling StatBufOffT64.m3 > "../src/StatBufOffT64.m3", line 40: unknown qualification '.' (asLong) > "../src/StatBufOffT64.m3", line 45: unknown qualification '.' > (assignOffT) > 2 errors encountered > new source -> compiling Ugzip.m3 > "../src/Ugzip.m3", line 63: unknown qualification '.' > (DisableSwitching) > "../src/Ugzip.m3", line 67: unknown qualification '.' > (EnableSwitching) > "../src/Ugzip.m3", line 74: unknown qualification '.' > (DisableSwitching) > "../src/Ugzip.m3", line 78: unknown qualification '.' > (EnableSwitching) > 4 errors encountered > new source -> compiling CVTree.m3 > "../src/CVTree.m3", line 315: unknown qualification '.' > (DisableSwitching) > "../src/CVTree.m3", line 319: unknown qualification '.' > (EnableSwitching) > "../src/CVTree.m3", line 325: unknown qualification '.' > (DisableSwitching) > "../src/CVTree.m3", line 329: unknown qualification '.' > (EnableSwitching) > "../src/CVTree.m3", line 335: unknown qualification '.' > (DisableSwitching) > "../src/CVTree.m3", line 339: unknown qualification '.' > (EnableSwitching) > 6 errors encountered > compilation failed => not building library "libsuplib.a" > Fatal Error: package build failed > > > I need help with all of these. However, I tried investigating the > first > one: Utypes.asLong() > > By coincidence, I saw that in FSPosix.m3, a line saying > status.size := Utypes.asLong(statBuf.st_size); > was changed to > status.size := ORD(statBuf.st_size); > > Reading the log for the linux/Utypes.i3 gets me confused. It says > how to > make a off_t from a long, but doesn't say anything about the reverse > direction. Is ORD(x) always the way to go? Here is the log extract: > > revision 1.4 > date: 2007-11-29 03:53:15 +0100; author: hosking; state: Exp; lines: > +0 -3; commitid: 3xU0vDzVxflBSpHs; > Remove residual implementations of Utypes.asLong and > Utypes.assignOffT. > ---------------------------- > revision 1.3 > date: 2004-01-30 18:45:34 +0100; author: wagner; state: Exp; lines: > +1 -0; > add a procedure to assign values to off_t variables, as they may > now be > structured types, depending on the platform: > > PROCEDURE expandAssign(VAR dest: off_t; src: long) > > > Well, where would API changes like these be documented, if I ever > need > to look them up on my own? > Thanks, > > -- > Neels Janosch Hofmeyr > Software Developer > > neels at elego.de > Public Key: http://binarchy.net/neels/neels.hofmeyr.public.key.asc > > elego Software Solutions GmbH http://www.elegosoft.com > Gustav-Meyer-Allee 25, Geb?ude 12 HRB 77719 > 13355 Berlin, Germany Amtsgericht Charlottenburg > Tel.: +49 30 23 45 86 96 Sitz der Gesellschaft: Berlin > Fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Olaf Wagner > > > > > ?Con Mascota por primera vez? - S? un mejor Amigo > Entra en Yahoo! Respuestas > . -- Neels Janosch Hofmeyr Software Developer neels at elego.de Public Key: http://binarchy.net/neels/neels.hofmeyr.public.key.asc elego Software Solutions GmbH http://www.elegosoft.com Gustav-Meyer-Allee 25, Geb?ude 12 HRB 77719 13355 Berlin, Germany Amtsgericht Charlottenburg Tel.: +49 30 23 45 86 96 Sitz der Gesellschaft: Berlin Fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Olaf Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From lemming at henning-thielemann.de Mon Jan 28 14:38:37 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Mon, 28 Jan 2008 14:38:37 +0100 (MET) Subject: [M3devel] heap vs. stack? (sort of) In-Reply-To: References: Message-ID: On Mon, 28 Jan 2008, Jay wrote: > I totally want common code, there's just no point in moving it into a separate function. Are you concerned about efficiency or about readability? In the first case maybe <* INLINE *> helps? > I also tried WITH that got its value from "PickBuffer", also a useless > function but at least small, but functions can't return open arrays. Functions can return pointers to open arrays - isn't this enough? From neels at elego.de Mon Jan 28 14:40:12 2008 From: neels at elego.de (Neels Janosch Hofmeyr) Date: Mon, 28 Jan 2008 14:40:12 +0100 Subject: [M3devel] Utypes.asLong / Utypes.assignOffT Message-ID: <479DDB3C.4020300@elego.de> Hi, after some problems have been resolved, I still cannot figure out these errors: ===> suplib --- building in LINUXLIBC6 --- new source -> compiling StatBufOffT64.m3 "../src/StatBufOffT64.m3", line 40: unknown qualification '.' (asLong) "../src/StatBufOffT64.m3", line 45: unknown qualification '.' (assignOffT) They are trying to access the procedures Utypes.asLong Utypes.assignOffT Apparently, Utypes.asLong(..) can simply be replaced by ORD(..). Is this correct?? Concerning assignOffT, the commit log speaks of a function called PROCEDURE expandAssign(VAR dest: off_t; src: long) , but this function does not exist anywhere in the cm3 source tree (grep -r expandAssign yielded no results). How do I fix this line in suplib/src/StatBufOffT64.m3 (ll.43-46)? PROCEDURE SetStatSize(VAR st: struct_stat; size: CARDINAL) = BEGIN Utypes.assignOffT(st.st_size, size); END SetStatSize; "../src/StatBufOffT64.m3", line 45: unknown qualification '.' (assignOffT) Thanks -- Neels Janosch Hofmeyr Software Developer neels at elego.de Public Key: http://binarchy.net/neels/neels.hofmeyr.public.key.asc elego Software Solutions GmbH http://www.elegosoft.com Gustav-Meyer-Allee 25, Geb?ude 12 HRB 77719 13355 Berlin, Germany Amtsgericht Charlottenburg Tel.: +49 30 23 45 86 96 Sitz der Gesellschaft: Berlin Fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Olaf Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From jayk123 at hotmail.com Mon Jan 28 15:00:46 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 28 Jan 2008 14:00:46 +0000 Subject: [M3devel] heap vs. stack? (sort of) In-Reply-To: References: Message-ID: Both. In thinking about how to write the code, there is no point in splitting the code into two functions. They are each small and the one is only called once. The language should in general not force me to write functions merely to work over the type system. <*inline*> is not implemented by the integrated backend. I assume every function call I write will not be inlined. > Functions can return pointers to open arrays - isn't this enough? Yes that might help. I had tried like PROCEDURE PickBuffer(VAR buf: ARRAY OF CHAR; len: INTEGER): ARRAY OF CHAR = BEGIN IF len <= NUMBER(buf) RETURN buf; END; RETURN NEW ARRAY OF CHAR (len); END PickBuffer; PROCEDURE Parse(...) VAR stack: ARRAY [0..255] OF CHAR; BEGIN ... WITH buf = PickBuffer(stack, len) DO use buf END; END Parse but I couldn't come up with a PickBuffer that the compiler liked. PickBuffer is still a bit iffy. More generally in C++ I would implement that as a template class where one of the parameters is how much to preallocate. In C I would implement it as a struct and some functions and the initialization function would take the preallocated buffer and size. Surely Modula-3 can do either/both of those patterns well and it doesn't have to be reimplemented over and over. The Modula-3 code I see around the system is way more low level and repetitive than seems appropriate, more so than C code that I write. Another example is that it definitely appears that if I try to compile code with a path like \a\b\c\d\e\f\g\h\a\b\c\d\e\f\g...\foo.m3 that has more than around 32 path separators, I'll just get some random failures since the code just "gives up". M3Path has an array of 32 to store the positions of path separators. That whole chunk of code, to remove \.\ I'll probably rewrite to be both more efficient and have no such capacity limits. For \.\ it is trivial. For \..\ it takes a bit of cleverness -- rather than rely on any indefinite amount of storage, what you can do is first reverse the string, then whenever you se .., bump up a counter, whenever you see not .., bump it down, only copy from source to dest when the counter is zero. Roughly. Of course...maybe better here...count the slashes, if there are more than ~30, do the heap alloc, as in the previous pattern. Though it'd be nice, since it is possible, to handle arbitrarily long paths without the heap alloc. In a compacting garbage collection system, heap alloc can be roughly the cost of incrementing an integer. I do not assume Modula-3 has that, though maybe, and I do not assume it has particularly fast heap allocation. I have seen heap allocation just be very slow in general and I avoid it whenever possible/easy/correct. There are competing desires here of course. 1 Be fast. 2 Don't have fixed sized limits. (and esp. don't crash when you go past them! as I complained about recently..) 3 Don't use "too much" stack, however much that is. The easiest way to do #2 and #3 is always heap alloc exactly how much you need, but that kills #1. - Jay > Date: Mon, 28 Jan 2008 14:38:37 +0100> From: lemming at henning-thielemann.de> Subject: RE: [M3devel] heap vs. stack? (sort of)> To: jayk123 at hotmail.com> CC: m3devel at elegosoft.com> > > On Mon, 28 Jan 2008, Jay wrote:> > > I totally want common code, there's just no point in moving it into a separate function.> > Are you concerned about efficiency or about readability? In the first case> maybe <* INLINE *> helps?> > > I also tried WITH that got its value from "PickBuffer", also a useless> > function but at least small, but functions can't return open arrays.> > Functions can return pointers to open arrays - isn't this enough? _________________________________________________________________ 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 hendrik at topoi.pooq.com Mon Jan 28 15:46:29 2008 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Mon, 28 Jan 2008 09:46:29 -0500 Subject: [M3devel] heap vs. stack? (sort of) In-Reply-To: References: Message-ID: <20080128144629.GB1732@topoi.pooq.com> On Mon, Jan 28, 2008 at 02:00:46PM +0000, Jay wrote: > Both. > In thinking about how to write the code, there is no point in splitting the code into two functions. > They are each small and the one is only called once. > The language should in general not force me to write functions merely to work over the type system. > <*inline*> is not implemented by the integrated backend. I assume every function call I write will not be inlined. > > > Functions can return pointers to open arrays - isn't this enough? > > Yes that might help. > I had tried like > > PROCEDURE PickBuffer(VAR buf: ARRAY OF CHAR; len: INTEGER): ARRAY OF CHAR = > BEGIN > IF len <= NUMBER(buf) RETURN buf; > END; > RETURN NEW ARRAY OF CHAR (len); > END PickBuffer; > > PROCEDURE Parse(...) > VAR > stack: ARRAY [0..255] OF CHAR; > BEGIN > ... > WITH buf = PickBuffer(stack, len) DO use buf > END; > END Parse > > but I couldn't come up with a PickBuffer that the compiler liked. > > PickBuffer is still a bit iffy. > > More generally in C++ I would implement that as a template class where one of the parameters is how much to preallocate. In C I would implement it as a struct and some functions and the initialization function would take the preallocated buffer and size. > > Surely Modula-3 can do either/both of those patterns well and it doesn't have to be reimplemented over and over. > > The Modula-3 code I see around the system is way more low level and repetitive than seems appropriate, more so than C code that I write. > > Another example is that it definitely appears that if I try to compile code with a path like > \a\b\c\d\e\f\g\h\a\b\c\d\e\f\g...\foo.m3 > > that has more than around 32 path separators, I'll just get some random failures since the code just "gives up". > M3Path has an array of 32 to store the positions of path separators. > That whole chunk of code, to remove \.\ I'll probably rewrite to be both more efficient and have no such capacity limits. > For \.\ it is trivial. > For \..\ it takes a bit of cleverness -- rather than rely on any indefinite amount of storage, what you can do is first reverse the string, then whenever you se .., bump up a counter, whenever you see not .., bump it down, only copy from source to dest when the counter is zero. Roughly. If you are talking about paths for naming files, you might want to consider that (on Unix systems at least) '..' does not back out of a symbolic link, but may go somewhere else entirely. Whether you want this behaviour is, of course, up to you. -- hendrik From jayk123 at hotmail.com Mon Jan 28 16:40:59 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 28 Jan 2008 15:40:59 +0000 Subject: [M3devel] heap vs. stack? (sort of) In-Reply-To: <20080128144629.GB1732@topoi.pooq.com> References: <20080128144629.GB1732@topoi.pooq.com> Message-ID: > consider that (on Unix systems at least) '..' does not back out of a > symbolic link, but may go somewhere else entirely. Whether you want > this behaviour is, of course, up to you. cm3 does this. Not up to me or you probably. See m3-sys/cm3/src/M3Path.m3 PROCEDURE FixPath (VAR p: ARRAY OF CHAR; host: BOOLEAN): TEXT = (* remove redundant "/arc/../" and "/./" segments *) VAR os := os_map [host]; len, x, s0, s1, s2: INTEGER; info: SepInfo; - Jay > Date: Mon, 28 Jan 2008 09:46:29 -0500> From: hendrik at topoi.pooq.com> To: m3devel at elegosoft.com> Subject: Re: [M3devel] heap vs. stack? (sort of)> > On Mon, Jan 28, 2008 at 02:00:46PM +0000, Jay wrote:> > Both.> > In thinking about how to write the code, there is no point in splitting the code into two functions.> > They are each small and the one is only called once.> > The language should in general not force me to write functions merely to work over the type system.> > <*inline*> is not implemented by the integrated backend. I assume every function call I write will not be inlined.> > > > > Functions can return pointers to open arrays - isn't this enough?> > > > Yes that might help.> > I had tried like> > > > PROCEDURE PickBuffer(VAR buf: ARRAY OF CHAR; len: INTEGER): ARRAY OF CHAR => > BEGIN> > IF len <= NUMBER(buf) RETURN buf;> > END;> > RETURN NEW ARRAY OF CHAR (len);> > END PickBuffer;> > > > PROCEDURE Parse(...)> > VAR> > stack: ARRAY [0..255] OF CHAR;> > BEGIN> > ...> > WITH buf = PickBuffer(stack, len) DO use buf> > END;> > END Parse> > > > but I couldn't come up with a PickBuffer that the compiler liked.> > > > PickBuffer is still a bit iffy.> > > > More generally in C++ I would implement that as a template class where one of the parameters is how much to preallocate. In C I would implement it as a struct and some functions and the initialization function would take the preallocated buffer and size.> > > > Surely Modula-3 can do either/both of those patterns well and it doesn't have to be reimplemented over and over.> > > > The Modula-3 code I see around the system is way more low level and repetitive than seems appropriate, more so than C code that I write.> > > > Another example is that it definitely appears that if I try to compile code with a path like> > \a\b\c\d\e\f\g\h\a\b\c\d\e\f\g...\foo.m3> > > > that has more than around 32 path separators, I'll just get some random failures since the code just "gives up".> > M3Path has an array of 32 to store the positions of path separators.> > That whole chunk of code, to remove \.\ I'll probably rewrite to be both more efficient and have no such capacity limits.> > For \.\ it is trivial.> > For \..\ it takes a bit of cleverness -- rather than rely on any indefinite amount of storage, what you can do is first reverse the string, then whenever you se .., bump up a counter, whenever you see not .., bump it down, only copy from source to dest when the counter is zero. Roughly.> > If you are talking about paths for naming files, you might want to > consider that (on Unix systems at least) '..' does not back out of a > symbolic link, but may go somewhere else entirely. Whether you want > this behaviour is, of course, up to you.> > -- hendrik _________________________________________________________________ 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 Jan 28 17:02:25 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 28 Jan 2008 11:02:25 -0500 Subject: [M3devel] nt386gnu threads? In-Reply-To: References: Message-ID: <591840BD-4494-4A2C-AC0F-CD017338E5ED@cs.purdue.edu> On Jan 28, 2008, at 6:29 AM, Jay wrote: > Can anyone confirm my read that PM3's NT386GNU used user/vtalarm > threads? Indeed. Pthread support has only been available in CM3 since I started on it in in 2006. Thus, unless it was using Win32 threads it had to have been SIGVTALRM based (ie, implemented as in ThreadPosix.m3). > PM3 appears to have no PThread support ant its NT386GNU appears to > have OS_TYPE=POSIX. > Heck, even its NT386 has OS_TYPE=POSIX, but its NT386 is probably > dead/broken. > > 1) I'm too lazy to tediously rewrite Cygwin's pthread.h et. al. > into Modula-3. I am unfamiliar with Cygwin pthread support. Are they layered on win32 threads? It is not terribly hard to write Upthread.i3 and friends. > 2) The thread library you pick is not an independent decision. > The Modula-3 File I/O libraries interact with the threading > library at least a little bit. The POSIX file IO libraries are known to function with both ThreadPThread and ThreadPosix (SIGVTALRM). Thus, you should be able to use them cleanly if the Cygwin-based Modula-3 implementation takes on a purely/mainly POSIX personality (as many of us have argued it should!). > The path of less resistance seems to be user/vtalarm threads for > now, until > such time as Cygwin Upthread.i3 is written. Yes, indeed. > (That is, neither pthreads nor win32 satisfied my laziness; I'm > going to try user/vtalarm threads, see how it goes; I'm sure they > aren't very good, but...) Certainly, you won't get any multicore benefit with SIGVTALRM-based threads. From hosking at cs.purdue.edu Mon Jan 28 17:16:13 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 28 Jan 2008 11:16:13 -0500 Subject: [M3devel] new unknown qualification errors In-Reply-To: <479DD8F5.1090001@elego.de> References: <762336.53722.qm@web27110.mail.ukl.yahoo.com> <479DD8F5.1090001@elego.de> Message-ID: <758D5468-25A7-4853-BD61-F012890358A6@cs.purdue.edu> On Jan 28, 2008, at 8:30 AM, Neels Janosch Hofmeyr wrote: > Thanks Daniel, that seems to work. > > However, if SchedulerPosix does not support these calls > (DisableSwitching and EnableSwitching), do we not end up with > concurreny problems? (This assuming that the Scheduler internally > calls SchedulerPosix on POSIX platforms, which I am just wildly > guessing...) The calls to Schedule.DisableSwitching/EnableSwitching turn into different things for different threading subsystems. The reason is because SIGVTALRM-based thread scheduling (ThreadPosix) can cause thread switches in library code that is not thread-safe. Thus, certain system calls need to be wrapped in DisableSwitching/ EnableSwitching calls which prevent user-level threads switches. With system thread scheduling (ThreadPThread) the library calls are known to be thread-safe (since we link with a pthreads-aware C library) so DisableSwitching/EnableSwitching can be implemented as a no-op. The purpose of this is to allow suplib (and CVSup) to be compiled for all POSIX targets (both pthreads and user-threads). So, short answer to your question is: no, we don't end up with concurrency problems. > > Thanks again, > Neels > > Daniel Alejandro Benavides D. wrote: >> Hi Neels: >> If I rememeber this happen since some time ago. Just look this >> post of mine, you need to change the IMPORT and the lines that >> compiler complains: >> https://mail.elegosoft.com/pipermail/m3devel/2008-January/ >> 000806.html: >> importing Scheduler instead of SchedulerPosix Then replace the >> call for the functions of SchedulerPosix for Scheduler >> I think that would solve that problem. >> >> Thanks, >> >> Daniel Benavides >> >> >> >> >> */Neels Janosch Hofmeyr /* escribi?: >> >> Hi devel, >> >> I am trying to compile the suplib with the new 5.5.1 snapshot >> cm3. It >> worked fine with 5.4.0, but now I get errors I cannot figure out >> how to >> correct: >> >> ===> suplib >> --- building in LINUXLIBC6 --- >> >> new source -> compiling StatBufOffT64.m3 >> "../src/StatBufOffT64.m3", line 40: unknown qualification >> '.' (asLong) >> "../src/StatBufOffT64.m3", line 45: unknown qualification '.' >> (assignOffT) >> 2 errors encountered >> new source -> compiling Ugzip.m3 >> "../src/Ugzip.m3", line 63: unknown qualification '.' >> (DisableSwitching) >> "../src/Ugzip.m3", line 67: unknown qualification '.' >> (EnableSwitching) >> "../src/Ugzip.m3", line 74: unknown qualification '.' >> (DisableSwitching) >> "../src/Ugzip.m3", line 78: unknown qualification '.' >> (EnableSwitching) >> 4 errors encountered >> new source -> compiling CVTree.m3 >> "../src/CVTree.m3", line 315: unknown qualification '.' >> (DisableSwitching) >> "../src/CVTree.m3", line 319: unknown qualification '.' >> (EnableSwitching) >> "../src/CVTree.m3", line 325: unknown qualification '.' >> (DisableSwitching) >> "../src/CVTree.m3", line 329: unknown qualification '.' >> (EnableSwitching) >> "../src/CVTree.m3", line 335: unknown qualification '.' >> (DisableSwitching) >> "../src/CVTree.m3", line 339: unknown qualification '.' >> (EnableSwitching) >> 6 errors encountered >> compilation failed => not building library "libsuplib.a" >> Fatal Error: package build failed >> >> >> I need help with all of these. However, I tried investigating the >> first >> one: Utypes.asLong() >> >> By coincidence, I saw that in FSPosix.m3, a line saying >> status.size := Utypes.asLong(statBuf.st_size); >> was changed to >> status.size := ORD(statBuf.st_size); >> >> Reading the log for the linux/Utypes.i3 gets me confused. It says >> how to >> make a off_t from a long, but doesn't say anything about the >> reverse >> direction. Is ORD(x) always the way to go? Here is the log >> extract: >> >> revision 1.4 >> date: 2007-11-29 03:53:15 +0100; author: hosking; state: Exp; >> lines: >> +0 -3; commitid: 3xU0vDzVxflBSpHs; >> Remove residual implementations of Utypes.asLong and >> Utypes.assignOffT. >> ---------------------------- >> revision 1.3 >> date: 2004-01-30 18:45:34 +0100; author: wagner; state: Exp; >> lines: >> +1 -0; >> add a procedure to assign values to off_t variables, as they may >> now be >> structured types, depending on the platform: >> >> PROCEDURE expandAssign(VAR dest: off_t; src: long) >> >> >> Well, where would API changes like these be documented, if I ever >> need >> to look them up on my own? >> Thanks, >> >> -- Neels Janosch Hofmeyr >> Software Developer >> >> neels at elego.de >> Public Key: http://binarchy.net/neels/ >> neels.hofmeyr.public.key.asc >> >> elego Software Solutions GmbH http://www.elegosoft.com >> Gustav-Meyer-Allee 25, Geb?ude 12 HRB 77719 >> 13355 Berlin, Germany Amtsgericht Charlottenburg >> Tel.: +49 30 23 45 86 96 Sitz der Gesellschaft: Berlin >> Fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Olaf Wagner >> >> >> >> >> ?Con Mascota por primera vez? - S? un mejor Amigo >> Entra en Yahoo! Respuestas > *http://es.answers.yahoo.com/dir/ >> index;_ylc=X3oDMTE4ZWhyZjU0BF9TAzIxMTQ3MTQzMjIEc2VjA0Jhbm5lcgRzbGsDQW >> NxdWlzaXRpb24-?link=over&sid=XXXXXXXX>. > > -- > Neels Janosch Hofmeyr > Software Developer > > neels at elego.de > Public Key: http://binarchy.net/neels/neels.hofmeyr.public.key.asc > > elego Software Solutions GmbH http://www.elegosoft.com > Gustav-Meyer-Allee 25, Geb?ude 12 HRB 77719 > 13355 Berlin, Germany Amtsgericht Charlottenburg > Tel.: +49 30 23 45 86 96 Sitz der Gesellschaft: Berlin > Fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Olaf Wagner > > From jayk123 at hotmail.com Mon Jan 28 17:19:48 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 28 Jan 2008 16:19:48 +0000 Subject: [M3devel] nt386gnu threads? In-Reply-To: <591840BD-4494-4A2C-AC0F-CD017338E5ED@cs.purdue.edu> References: <591840BD-4494-4A2C-AC0F-CD017338E5ED@cs.purdue.edu> Message-ID: I understand how to write pthread.i3 but it is tedious and I am lazy. This idea that the headers have to be rewritten in Modula-3 bugs me. I realize it purchases my "crazy cross" but it's not the only way -- the native headers distributed to other machines could work....but then I realize it buys writing more Modula-3 and less C, and I'm not sure that's valuable. :) For now I've copied/pasted bits and pieces around to get m3core.dll to build. It builds. I believe Cygwin Pthreads are layered on Win32 threads. I'm sure they add cost oh well. Yes NT386GNU will use Cygwin and it'll be slow. NT386MINGNU will use cm3cg and only build slowly. It is painfully noticable how much more slowly NT386GNU m3cc builds than NT386MINGNU m3cc, presumably due to the underlying slower bash/sed/make etc. All just twiddle the slashes around... I did twiddle M3Path to print like c:/cm3 and accept either input. I probably will stil make it accept either input, since from a certain point of view, that is more correct. Oh, I had treating \ and / the same on all platforms -- surely \ never occurs anyway on Unix... :) The Cygwin stuff was either out of date for vtalarm, or I was building the wrong files and thought it was broken. So I went back to pthreads. Besides, vtalarm threads put you in the shady business of creating stacks and such.. - Jay > CC: m3devel at elegosoft.com> From: hosking at cs.purdue.edu> Subject: Re: [M3devel] nt386gnu threads?> Date: Mon, 28 Jan 2008 11:02:25 -0500> To: jayk123 at hotmail.com> > > On Jan 28, 2008, at 6:29 AM, Jay wrote:> > > Can anyone confirm my read that PM3's NT386GNU used user/vtalarm > > threads?> > Indeed. Pthread support has only been available in CM3 since I > started on it in in 2006. Thus, unless it was using Win32 threads it > had to have been SIGVTALRM based (ie, implemented as in ThreadPosix.m3).> > > PM3 appears to have no PThread support ant its NT386GNU appears to > > have OS_TYPE=POSIX.> > Heck, even its NT386 has OS_TYPE=POSIX, but its NT386 is probably > > dead/broken.> >> > 1) I'm too lazy to tediously rewrite Cygwin's pthread.h et. al. > > into Modula-3.> > I am unfamiliar with Cygwin pthread support. Are they layered on > win32 threads? It is not terribly hard to write Upthread.i3 and > friends.> > > 2) The thread library you pick is not an independent decision.> > The Modula-3 File I/O libraries interact with the threading > > library at least a little bit.> > The POSIX file IO libraries are known to function with both > ThreadPThread and ThreadPosix (SIGVTALRM). Thus, you should be able > to use them cleanly if the Cygwin-based Modula-3 implementation takes > on a purely/mainly POSIX personality (as many of us have argued it > should!).> > > The path of less resistance seems to be user/vtalarm threads for > > now, until> > such time as Cygwin Upthread.i3 is written.> > Yes, indeed.> > > (That is, neither pthreads nor win32 satisfied my laziness; I'm > > going to try user/vtalarm threads, see how it goes; I'm sure they > > aren't very good, but...)> > Certainly, you won't get any multicore benefit with SIGVTALRM-based > threads.> _________________________________________________________________ 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 Jan 28 17:26:45 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 28 Jan 2008 16:26:45 +0000 Subject: [M3devel] Open CM3 regression tests In-Reply-To: <20080127185530.e255i76vcwckss4o@mail.elegosoft.com> References: <20080120211832.GA26993@elegosoft.com> <9C00EA97-9B43-43BE-9CDF-EEAC9C1321D5@cs.purdue.edu> <20080127150327.mh686v2hx4w080w4@mail.elegosoft.com> <1DA9FA59-6DFF-430C-90C5-F1D30003607A@cs.purdue.edu> <20080127185530.e255i76vcwckss4o@mail.elegosoft.com> Message-ID: The tests don't even build on Windows and it was going to take more than 5 minutes fix that. They are slightly full of sh. :) (I never tire of this joke. :) ) My current plan is: get NT386GNU working -- I can already build cm3 and it fails an assertion about pthread_mutex_something failing. Hey, maybe I should fix some of the declarations.. :) or go back to my Mac briefly to investigate and/or give Tony a day :) - Jay From: jayk123 at hotmail.comTo: wagner at elegosoft.com; hosking at cs.purdue.eduCC: m3devel at elegosoft.comSubject: RE: [M3devel] Open CM3 regression testsDate: Sun, 27 Jan 2008 20:31:00 +0000 The functions are only used if the set doesn't fit in an integer.I'll try to look at this today. - Jay > Date: Sun, 27 Jan 2008 18:55:30 +0100> From: wagner at elegosoft.com> To: hosking at cs.purdue.edu> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] Open CM3 regression tests> > Quoting Tony Hosking :> > > The set operations are coded in > > cm3/m3-libs/m3core/src/Csupport/Common/hand.c.> >> > I notice Jay has made a number of changes here since September -- I> > wonder if they have broken something.> > I tried different revisions of this file with no difference in the> test results. I then took the latest version and added some printfs,> and they got never displayed. So I checked what gets linked, but the> symbols in question don't occur in the test program:> > % nm hand.o> U __divdi3> U __moddi3> 000001e0 R _highbits> 00000140 R _lowbits> 00000000 T m3_div> 000000ac T m3_divL> 000001d4 T m3_mod> 0000026c T m3_modL> U printf> 00000494 T set_difference> 00000554 T set_eq> 0000061c T set_ge> 000006ac T set_gt> 00000434 T set_intersection> 0000077c T set_le> 0000080c T set_lt> 000003a8 T set_member> 000005b8 T set_ne> 000008d8 T set_range> 000009d8 T set_singleton> 000004f4 T set_sym_difference> 000003d4 T set_union> > % nm /usr/local/cm3/pkg/m3core/FreeBSD4/libm3core.so.5 | grep set_> 000243d0 T set_difference> 00024490 T set_eq> 00024558 T set_ge> 000245fc T set_gt> 00024370 T set_intersection> 000246e0 T set_le> 00024784 T set_lt> 000242e4 T set_member> 000244f4 T set_ne> 00024864 T set_range> 00024998 T set_singleton> 00024430 T set_sym_difference> 00024310 T set_union> > % ldd FreeBSD4/p1/p155/FreeBSD4/pgm> FreeBSD4/p1/p155/FreeBSD4/pgm:> libtest.so.5 => > /d/home/wagner/work/cm3/m3-sys/m3tests/FreeBSD4/libtest.so.5 > (0x28085000)> libm3.so.5 => /usr/local/cm3/pkg/libm3/FreeBSD4/libm3.so.5 > (0x28088000)> libm3core.so.5 => > /usr/local/cm3/pkg/m3core/FreeBSD4/libm3core.so.5 (0x281aa000)> libm.so.4 => /lib/libm.so.4 (0x28a2d000)> libpthread.so.2 => /lib/libpthread.so.2 (0x28a46000)> libc.so.6 => /lib/libc.so.6 (0x28a6a000)> > % nm /usr/local/cm3/pkg/m3core/FreeBSD4/libm3core.so.5 | grep set_> 000243d0 T set_difference> 00024490 T set_eq> 00024558 T set_ge> 000245fc T set_gt> 00024370 T set_intersection> 000246e0 T set_le> 00024784 T set_lt> 000242e4 T set_member> 000244f4 T set_ne> 00024864 T set_range> 00024998 T set_singleton> 00024430 T set_sym_difference> 00024310 T set_union> luthien [~/work/cm3/m3-sys/m3tests] wagner> % ldd FreeBSD4/p1/p155/FreeBSD4/pgm> FreeBSD4/p1/p155/FreeBSD4/pgm:> libtest.so.5 => > /d/home/wagner/work/cm3/m3-sys/m3tests/FreeBSD4/libtest.so.5 > (0x28085000)> libm3.so.5 => /usr/local/cm3/pkg/libm3/FreeBSD4/libm3.so.5 > (0x28088000)> libm3core.so.5 => > /usr/local/cm3/pkg/m3core/FreeBSD4/libm3core.so.5 (0x281aa000)> libm.so.4 => /lib/libm.so.4 (0x28a2d000)> libpthread.so.2 => /lib/libpthread.so.2 (0x28a46000)> libc.so.6 => /lib/libc.so.6 (0x28a6a000)> luthien [~/work/cm3/m3-sys/m3tests] wagner> % nm -C -u FreeBSD4/p1/p155/FreeBSD4/pgm> U Main_I3> U RTHooks_I3> U RTHooks__CheckLoadTracedRef> U RTHooks__Concat> U RTHooks__PopEFrame> U RTHooks__PushEFrame> U RTHooks__TextLitGetChar> U RTHooks__TextLitGetChars> U RTHooks__TextLitGetWideChar> U RTHooks__TextLitGetWideChars> U RTHooks__TextLitInfo> U RTLinker__AddUnit> U RTLinker__InitRuntime> U RTProcess__Exit> U Stdio_I3> U Test_I3> U Test__checkM> U Test__done> U Wr_I3> U Wr__Flush> U Wr__PutText> w _Jv_RegisterClasses> w __deregister_frame_info> w __register_frame_info> U _init_tls> U _setjmp> U atexit> U exit> > Now I'm rather confused 8-/> > Any ideas?> > Olaf> -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194> 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 neels at elego.de Mon Jan 28 17:35:41 2008 From: neels at elego.de (Neels Janosch Hofmeyr) Date: Mon, 28 Jan 2008 17:35:41 +0100 Subject: [M3devel] Utypes.asLong / Utypes.assignOffT In-Reply-To: <479DDB3C.4020300@elego.de> References: <479DDB3C.4020300@elego.de> Message-ID: <479E045D.2000903@elego.de> Apparently, the answer to this is trivial. I found the missing functions in a CVS diff: -PROCEDURE asLong (val: off_t): long = - BEGIN - RETURN val; - END asLong; - -PROCEDURE assignOffT (VAR dest: off_t; src: long) = - BEGIN - dest := src; - END assignOffT; So, just replacing all occurences of these functions with direct assignments compiles without problems. y := Utypes.asLong(x) ==becomes==> y := ORD(x); x := Utypes.assignOffT(y) ==becomes==> x := y; Obviously, CVSup needs to be updated so that it compiles with the most recent CM3! The suplib still uses the obsoleted procedures asLong and assignOffT. Shall I write a mail to Mr. Polstra? Neels Neels Janosch Hofmeyr wrote: > Hi, > > after some problems have been resolved, I still cannot figure out > these errors: > > ===> suplib > --- building in LINUXLIBC6 --- > > new source -> compiling StatBufOffT64.m3 > "../src/StatBufOffT64.m3", line 40: unknown qualification '.' (asLong) > "../src/StatBufOffT64.m3", line 45: unknown qualification '.' > (assignOffT) > > They are trying to access the procedures > Utypes.asLong > Utypes.assignOffT > > Apparently, Utypes.asLong(..) can simply be replaced by ORD(..). Is > this correct?? > > Concerning assignOffT, the commit log speaks of a function called > PROCEDURE expandAssign(VAR dest: off_t; src: long) > , but this function does not exist anywhere in the cm3 source tree > (grep -r expandAssign yielded no results). > > > How do I fix this line in suplib/src/StatBufOffT64.m3 (ll.43-46)? > > PROCEDURE SetStatSize(VAR st: struct_stat; size: CARDINAL) = > BEGIN > Utypes.assignOffT(st.st_size, size); > END SetStatSize; > > "../src/StatBufOffT64.m3", line 45: unknown qualification '.' > (assignOffT) > > > Thanks > -- Neels Janosch Hofmeyr Software Developer neels at elego.de Public Key: http://binarchy.net/neels/neels.hofmeyr.public.key.asc elego Software Solutions GmbH http://www.elegosoft.com Gustav-Meyer-Allee 25, Geb?ude 12 HRB 77719 13355 Berlin, Germany Amtsgericht Charlottenburg Tel.: +49 30 23 45 86 96 Sitz der Gesellschaft: Berlin Fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Olaf Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From hosking at cs.purdue.edu Mon Jan 28 17:38:34 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 28 Jan 2008 11:38:34 -0500 Subject: [M3devel] heap vs. stack? (sort of) In-Reply-To: References: Message-ID: <3FB18C3C-0AE9-482F-AAAB-1196A81F73FB@cs.purdue.edu> <*INLINE*> currently does nothing with CM3. However, the gcc-based backend will inline procedures when optimizations are turned on. On Jan 28, 2008, at 8:38 AM, Henning Thielemann wrote: > > On Mon, 28 Jan 2008, Jay wrote: > >> I totally want common code, there's just no point in moving it >> into a separate function. > > Are you concerned about efficiency or about readability? In the > first case > maybe <* INLINE *> helps? > >> I also tried WITH that got its value from "PickBuffer", also a >> useless >> function but at least small, but functions can't return open arrays. > > Functions can return pointers to open arrays - isn't this enough? From hosking at cs.purdue.edu Mon Jan 28 17:43:35 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 28 Jan 2008 11:43:35 -0500 Subject: [M3devel] heap vs. stack? (sort of) In-Reply-To: References: Message-ID: <5DF1BB14-913D-460B-9F42-BA96B0B3682B@cs.purdue.edu> Modula-3 heap allocation is just bumping a pointer. The M3 GC is a copying (ie, compacting) collector. Fast path allocation doesn't even need synchronization since every thread allocates from its own private heap buffer. On Jan 28, 2008, at 9:00 AM, Jay wrote: > Both. > In thinking about how to write the code, there is no point in > splitting the code into two functions. > They are each small and the one is only called once. > The language should in general not force me to write functions > merely to work over the type system. > <*inline*> is not implemented by the integrated backend. I assume > every function call I write will not be inlined. > > > Functions can return pointers to open arrays - isn't this enough? > > Yes that might help. > I had tried like > > PROCEDURE PickBuffer(VAR buf: ARRAY OF CHAR; len: INTEGER): ARRAY > OF CHAR = > BEGIN > IF len <= NUMBER(buf) > RETURN buf; > END; > RETURN NEW ARRAY OF CHAR (len); > END PickBuffer; > > PROCEDURE Parse(...) > VAR > stack: ARRAY [0..255] OF CHAR; > BEGIN > ... > WITH buf = PickBuffer(stack, len) DO > use buf > END; > END Parse > > but I couldn't come up with a PickBuffer that the compiler liked. > > PickBuffer is still a bit iffy. > > More generally in C++ I would implement that as a template class > where one of the parameters is how much to preallocate. In C I > would implement it as a struct and some functions and the > initialization function would take the preallocated buffer and size. > > Surely Modula-3 can do either/both of those patterns well and it > doesn't have to be reimplemented over and over. > > The Modula-3 code I see around the system is way more low level and > repetitive than seems appropriate, more so than C code that I write. > > Another example is that it definitely appears that if I try to > compile code with a path like > \a\b\c\d\e\f\g\h\a\b\c\d\e\f\g...\foo.m3 > > that has more than around 32 path separators, I'll just get some > random failures since the code just "gives up". > M3Path has an array of 32 to store the positions of path separators. > That whole chunk of code, to remove \.\ I'll probably rewrite to be > both more efficient and have no such capacity limits. > For \.\ it is trivial. > For \..\ it takes a bit of cleverness -- rather than rely on any > indefinite amount of storage, what you can do is first reverse the > string, then whenever you se .., bump up a counter, whenever you > see not .., bump it down, only copy from source to dest when the > counter is zero. Roughly. > > Of course...maybe better here...count the slashes, if there are > more than ~30, do the heap alloc, as in the previous pattern. > Though it'd be nice, since it is possible, to handle arbitrarily > long paths without the heap alloc. > > In a compacting garbage collection system, heap alloc can be > roughly the cost of incrementing an integer. > I do not assume Modula-3 has that, though maybe, and I do not > assume it has particularly fast heap allocation. > I have seen heap allocation just be very slow in general and I > avoid it whenever possible/easy/correct. > > There are competing desires here of course. > 1 Be fast. > 2 Don't have fixed sized limits. (and esp. don't crash when you > go past them! as I complained about recently..) > 3 Don't use "too much" stack, however much that is. > > The easiest way to do #2 and #3 is always heap alloc exactly how > much you need, but that kills #1. > > - Jay > > > > > Date: Mon, 28 Jan 2008 14:38:37 +0100 > > From: lemming at henning-thielemann.de > > Subject: RE: [M3devel] heap vs. stack? (sort of) > > To: jayk123 at hotmail.com > > CC: m3devel at elegosoft.com > > > > > > On Mon, 28 Jan 2008, Jay wrote: > > > > > I totally want common code, there's just no point in moving it > into a separate function. > > > > Are you concerned about efficiency or about readability? In the > first case > > maybe <* INLINE *> helps? > > > > > I also tried WITH that got its value from "PickBuffer", also a > useless > > > function but at least small, but functions can't return open > arrays. > > > > Functions can return pointers to open arrays - isn't this enough? > > > Connect and share in new ways with Windows Live. Get it now! From hosking at cs.purdue.edu Mon Jan 28 17:55:24 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 28 Jan 2008 11:55:24 -0500 Subject: [M3devel] heap vs. stack? (sort of) In-Reply-To: References: Message-ID: <99035865-C3FD-45CB-8508-5D9C6B010D44@cs.purdue.edu> I actually find this idiom for avoiding heap allocation (assuming it really is expensive in the first place) particularly elegant. In any case, what's wrong with defining a generic procedure: PROCEDURE Apply (p: PROCEDURE(nm: ARRAY OF CHAR); nm: TEXT): T = VAR len := Text.Length(nm); buf: ARRAY [0..255] OF CHAR; BEGIN IF len <= NUMBER(buf) THEN RETURN p(SUBARRAY(buf, 0, len)); ELSE RETURN p(NEW(REF ARRAY OF CHAR, len)^); END; END Apply; and then use Apply to apply a nested procedure to the appropriate text at each place you need it? On Jan 28, 2008, at 4:48 AM, Jay wrote: > Is it possible to have this pattern in Modula-3: > > PROCEDURE Parse (nm: TEXT; host: BOOLEAN): T = > VAR len := Text.Length (nm); buf: ARRAY [0..255] OF CHAR; > BEGIN > IF (len <= NUMBER (buf)) > THEN RETURN DoParse (nm, SUBARRAY (buf, 0, len), host); > ELSE RETURN DoParse (nm, NEW (REF ARRAY OF CHAR, len)^, host); > END; > END Parse; > > PROCEDURE DoParse (nm_txt: TEXT; VAR nm: ARRAY OF CHAR; host: > BOOLEAN): T = > > without the extra function? > > There are places in M3Path.m3 that duplicate code otherwise, one > branch acting on a local stack allocated array, the other acting on > a heap allocated array when the stack array is too small, but > otherwise identical code. > > So far I have not figured out how. Local variables cannot be open > array. SUBARRAY returns an ARRAY and not a REF ARRAY... It seems > that parameters can be open arrays but local variables cannot, and > that seems wrong.. parameters and locals so often share > characteristics... > > - 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 Jan 28 17:55:39 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 28 Jan 2008 11:55:39 -0500 Subject: [M3devel] heap vs. stack? (sort of) In-Reply-To: <5DF1BB14-913D-460B-9F42-BA96B0B3682B@cs.purdue.edu> References: <5DF1BB14-913D-460B-9F42-BA96B0B3682B@cs.purdue.edu> Message-ID: I should say CM3 here. On Jan 28, 2008, at 11:43 AM, Tony Hosking wrote: > Modula-3 heap allocation is just bumping a pointer. The M3 GC is a > copying (ie, compacting) collector. Fast path allocation doesn't > even need synchronization since every thread allocates from its own > private heap buffer. > > On Jan 28, 2008, at 9:00 AM, Jay wrote: > >> Both. >> In thinking about how to write the code, there is no point in >> splitting the code into two functions. >> They are each small and the one is only called once. >> The language should in general not force me to write functions >> merely to work over the type system. >> <*inline*> is not implemented by the integrated backend. I assume >> every function call I write will not be inlined. >> >> > Functions can return pointers to open arrays - isn't this enough? >> >> Yes that might help. >> I had tried like >> >> PROCEDURE PickBuffer(VAR buf: ARRAY OF CHAR; len: INTEGER): ARRAY >> OF CHAR = >> BEGIN >> IF len <= NUMBER(buf) >> RETURN buf; >> END; >> RETURN NEW ARRAY OF CHAR (len); >> END PickBuffer; >> >> PROCEDURE Parse(...) >> VAR >> stack: ARRAY [0..255] OF CHAR; >> BEGIN >> ... >> WITH buf = PickBuffer(stack, len) DO >> use buf >> END; >> END Parse >> >> but I couldn't come up with a PickBuffer that the compiler liked. >> >> PickBuffer is still a bit iffy. >> >> More generally in C++ I would implement that as a template class >> where one of the parameters is how much to preallocate. In C I >> would implement it as a struct and some functions and the >> initialization function would take the preallocated buffer and size. >> >> Surely Modula-3 can do either/both of those patterns well and it >> doesn't have to be reimplemented over and over. >> >> The Modula-3 code I see around the system is way more low level >> and repetitive than seems appropriate, more so than C code that I >> write. >> >> Another example is that it definitely appears that if I try to >> compile code with a path like >> \a\b\c\d\e\f\g\h\a\b\c\d\e\f\g...\foo.m3 >> >> that has more than around 32 path separators, I'll just get some >> random failures since the code just "gives up". >> M3Path has an array of 32 to store the positions of path separators. >> That whole chunk of code, to remove \.\ I'll probably rewrite to >> be both more efficient and have no such capacity limits. >> For \.\ it is trivial. >> For \..\ it takes a bit of cleverness -- rather than rely on any >> indefinite amount of storage, what you can do is first reverse the >> string, then whenever you se .., bump up a counter, whenever you >> see not .., bump it down, only copy from source to dest when the >> counter is zero. Roughly. >> >> Of course...maybe better here...count the slashes, if there are >> more than ~30, do the heap alloc, as in the previous pattern. >> Though it'd be nice, since it is possible, to handle arbitrarily >> long paths without the heap alloc. >> >> In a compacting garbage collection system, heap alloc can be >> roughly the cost of incrementing an integer. >> I do not assume Modula-3 has that, though maybe, and I do not >> assume it has particularly fast heap allocation. >> I have seen heap allocation just be very slow in general and I >> avoid it whenever possible/easy/correct. >> >> There are competing desires here of course. >> 1 Be fast. >> 2 Don't have fixed sized limits. (and esp. don't crash when you >> go past them! as I complained about recently..) >> 3 Don't use "too much" stack, however much that is. >> >> The easiest way to do #2 and #3 is always heap alloc exactly how >> much you need, but that kills #1. >> >> - Jay >> >> >> >> > Date: Mon, 28 Jan 2008 14:38:37 +0100 >> > From: lemming at henning-thielemann.de >> > Subject: RE: [M3devel] heap vs. stack? (sort of) >> > To: jayk123 at hotmail.com >> > CC: m3devel at elegosoft.com >> > >> > >> > On Mon, 28 Jan 2008, Jay wrote: >> > >> > > I totally want common code, there's just no point in moving it >> into a separate function. >> > >> > Are you concerned about efficiency or about readability? In the >> first case >> > maybe <* INLINE *> helps? >> > >> > > I also tried WITH that got its value from "PickBuffer", also a >> useless >> > > function but at least small, but functions can't return open >> arrays. >> > >> > Functions can return pointers to open arrays - isn't this enough? >> >> >> Connect and share in new ways with Windows Live. Get it now! From hosking at cs.purdue.edu Mon Jan 28 18:03:10 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 28 Jan 2008 12:03:10 -0500 Subject: [M3devel] nt386gnu threads? In-Reply-To: References: <591840BD-4494-4A2C-AC0F-CD017338E5ED@cs.purdue.edu> Message-ID: <2AEEE262-57C1-4D62-AB21-CA977F6C273E@cs.purdue.edu> On Jan 28, 2008, at 11:19 AM, Jay wrote: > I understand how to write pthread.i3 but it is tedious and I am > lazy. This idea that the headers have to be rewritten in Modula-3 > bugs me. I realize it purchases my "crazy cross" but it's not the > only way -- the native headers distributed to other machines could > work....but then I realize it buys writing more Modula-3 and less > C, and I'm not sure that's valuable. :) > > For now I've copied/pasted bits and pieces around to get m3core.dll > to build. It builds. > I believe Cygwin Pthreads are layered on Win32 threads. > I'm sure they add cost oh well. > Yes NT386GNU will use Cygwin and it'll be slow. > NT386MINGNU will use cm3cg and only build slowly. > > It is painfully noticable how much more slowly NT386GNU m3cc builds > than NT386MINGNU m3cc, presumably due to the underlying slower bash/ > sed/make etc. > > All just twiddle the slashes around... I did twiddle M3Path to > print like c:/cm3 and accept either input. I probably will stil > make it accept either input, since from a certain point of view, > that is more correct. Oh, I had treating \ and / the same on all > platforms -- surely \ never occurs anyway on Unix... :) Not sure: can \ be used as an escape in file names? > The Cygwin stuff was either out of date for vtalarm, or I was > building the wrong files and thought it was broken. So I went back > to pthreads. Besides, vtalarm threads put you in the shady business > of creating stacks and such.. I think NT386GNU always used Win32 threads. > > > - Jay > > > > CC: m3devel at elegosoft.com > > From: hosking at cs.purdue.edu > > Subject: Re: [M3devel] nt386gnu threads? > > Date: Mon, 28 Jan 2008 11:02:25 -0500 > > To: jayk123 at hotmail.com > > > > > > On Jan 28, 2008, at 6:29 AM, Jay wrote: > > > > > Can anyone confirm my read that PM3's NT386GNU used user/vtalarm > > > threads? > > > > Indeed. Pthread support has only been available in CM3 since I > > started on it in in 2006. Thus, unless it was using Win32 threads it > > had to have been SIGVTALRM based (ie, implemented as in > ThreadPosix.m3). > > > > > PM3 appears to have no PThread support ant its NT386GNU appears to > > > have OS_TYPE=POSIX. > > > Heck, even its NT386 has OS_TYPE=POSIX, but its NT386 is probably > > > dead/broken. > > > > > > 1) I'm too lazy to tediously rewrite Cygwin's pthread.h et. al. > > > into Modula-3. > > > > I am unfamiliar with Cygwin pthread support. Are they layered on > > win32 threads? It is not terribly hard to write Upthread.i3 and > > friends. > > > > > 2) The thread library you pick is not an independent decision. > > > The Modula-3 File I/O libraries interact with the threading > > > library at least a little bit. > > > > The POSIX file IO libraries are known to function with both > > ThreadPThread and ThreadPosix (SIGVTALRM). Thus, you should be able > > to use them cleanly if the Cygwin-based Modula-3 implementation > takes > > on a purely/mainly POSIX personality (as many of us have argued it > > should!). > > > > > The path of less resistance seems to be user/vtalarm threads for > > > now, until > > > such time as Cygwin Upthread.i3 is written. > > > > Yes, indeed. > > > > > (That is, neither pthreads nor win32 satisfied my laziness; I'm > > > going to try user/vtalarm threads, see how it goes; I'm sure they > > > aren't very good, but...) > > > > Certainly, you won't get any multicore benefit with SIGVTALRM-based > > threads. > > > > > Helping your favorite cause is as easy as instant messaging. You > IM, we give. Learn more. From hosking at cs.purdue.edu Mon Jan 28 18:04:46 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 28 Jan 2008 12:04:46 -0500 Subject: [M3devel] Utypes.asLong / Utypes.assignOffT In-Reply-To: <479E045D.2000903@elego.de> References: <479DDB3C.4020300@elego.de> <479E045D.2000903@elego.de> Message-ID: <4C6699EA-187B-455D-A7D0-63A69FABF1B7@cs.purdue.edu> You will need to use VAL as I noted to handle the fact that off_t is LONGINT on some targets and INTEGER on others. On Jan 28, 2008, at 11:35 AM, Neels Janosch Hofmeyr wrote: > Apparently, the answer to this is trivial. I found the missing > functions in a CVS diff: > > -PROCEDURE asLong (val: off_t): long = > - BEGIN > - RETURN val; > - END asLong; > - > -PROCEDURE assignOffT (VAR dest: off_t; src: long) = > - BEGIN > - dest := src; > - END assignOffT; > > So, just replacing all occurences of these functions with direct > assignments compiles without problems. > y := Utypes.asLong(x) ==becomes==> y := ORD(x); > x := Utypes.assignOffT(y) ==becomes==> x := y; > > Obviously, CVSup needs to be updated so that it compiles with the > most recent CM3! The suplib still uses the obsoleted procedures > asLong and assignOffT. Shall I write a mail to Mr. Polstra? > > Neels > > Neels Janosch Hofmeyr wrote: >> Hi, >> >> after some problems have been resolved, I still cannot figure out >> these errors: >> >> ===> suplib >> --- building in LINUXLIBC6 --- >> >> new source -> compiling StatBufOffT64.m3 >> "../src/StatBufOffT64.m3", line 40: unknown qualification >> '.' (asLong) >> "../src/StatBufOffT64.m3", line 45: unknown qualification >> '.' (assignOffT) >> >> They are trying to access the procedures >> Utypes.asLong >> Utypes.assignOffT >> >> Apparently, Utypes.asLong(..) can simply be replaced by ORD(..). >> Is this correct?? >> >> Concerning assignOffT, the commit log speaks of a function called >> PROCEDURE expandAssign(VAR dest: off_t; src: long) >> , but this function does not exist anywhere in the cm3 source tree >> (grep -r expandAssign yielded no results). >> >> >> How do I fix this line in suplib/src/StatBufOffT64.m3 (ll.43-46)? >> >> PROCEDURE SetStatSize(VAR st: struct_stat; size: CARDINAL) = >> BEGIN >> Utypes.assignOffT(st.st_size, size); >> END SetStatSize; >> >> "../src/StatBufOffT64.m3", line 45: unknown qualification >> '.' (assignOffT) >> >> >> Thanks >> > > -- > Neels Janosch Hofmeyr > Software Developer > > neels at elego.de > Public Key: http://binarchy.net/neels/neels.hofmeyr.public.key.asc > > elego Software Solutions GmbH http://www.elegosoft.com > Gustav-Meyer-Allee 25, Geb?ude 12 HRB 77719 > 13355 Berlin, Germany Amtsgericht Charlottenburg > Tel.: +49 30 23 45 86 96 Sitz der Gesellschaft: Berlin > Fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Olaf Wagner > > From neels at elego.de Mon Jan 28 18:11:30 2008 From: neels at elego.de (Neels Janosch Hofmeyr) Date: Mon, 28 Jan 2008 18:11:30 +0100 Subject: [M3devel] Utypes.asLong / Utypes.assignOffT In-Reply-To: <4C6699EA-187B-455D-A7D0-63A69FABF1B7@cs.purdue.edu> References: <479DDB3C.4020300@elego.de> <479E045D.2000903@elego.de> <4C6699EA-187B-455D-A7D0-63A69FABF1B7@cs.purdue.edu> Message-ID: <479E0CC2.1020206@elego.de> So, if I understand correctly, this should read y := Utypes.asLong(x) ==becomes==> y := ORD(x); x := Utypes.assignOffT(y) ==becomes==> x := VAL(y); right? Tony Hosking wrote: > You will need to use VAL as I noted to handle the fact that off_t is > LONGINT on some targets and INTEGER on others. > > On Jan 28, 2008, at 11:35 AM, Neels Janosch Hofmeyr wrote: > >> Apparently, the answer to this is trivial. I found the missing >> functions in a CVS diff: >> >> -PROCEDURE asLong (val: off_t): long = >> - BEGIN >> - RETURN val; >> - END asLong; >> - >> -PROCEDURE assignOffT (VAR dest: off_t; src: long) = >> - BEGIN >> - dest := src; >> - END assignOffT; >> >> So, just replacing all occurences of these functions with direct >> assignments compiles without problems. >> y := Utypes.asLong(x) ==becomes==> y := ORD(x); >> x := Utypes.assignOffT(y) ==becomes==> x := y; >> >> Obviously, CVSup needs to be updated so that it compiles with the >> most recent CM3! The suplib still uses the obsoleted procedures >> asLong and assignOffT. Shall I write a mail to Mr. Polstra? >> >> Neels >> >> Neels Janosch Hofmeyr wrote: >>> Hi, >>> >>> after some problems have been resolved, I still cannot figure out >>> these errors: >>> >>> ===> suplib >>> --- building in LINUXLIBC6 --- >>> >>> new source -> compiling StatBufOffT64.m3 >>> "../src/StatBufOffT64.m3", line 40: unknown qualification '.' (asLong) >>> "../src/StatBufOffT64.m3", line 45: unknown qualification '.' >>> (assignOffT) >>> >>> They are trying to access the procedures >>> Utypes.asLong >>> Utypes.assignOffT >>> >>> Apparently, Utypes.asLong(..) can simply be replaced by ORD(..). Is >>> this correct?? >>> >>> Concerning assignOffT, the commit log speaks of a function called >>> PROCEDURE expandAssign(VAR dest: off_t; src: long) >>> , but this function does not exist anywhere in the cm3 source tree >>> (grep -r expandAssign yielded no results). >>> >>> >>> How do I fix this line in suplib/src/StatBufOffT64.m3 (ll.43-46)? >>> >>> PROCEDURE SetStatSize(VAR st: struct_stat; size: CARDINAL) = >>> BEGIN >>> Utypes.assignOffT(st.st_size, size); >>> END SetStatSize; >>> >>> "../src/StatBufOffT64.m3", line 45: unknown qualification '.' >>> (assignOffT) >>> >>> >>> Thanks >>> >> >> -- >> Neels Janosch Hofmeyr >> Software Developer >> >> neels at elego.de >> Public Key: http://binarchy.net/neels/neels.hofmeyr.public.key.asc >> >> elego Software Solutions GmbH http://www.elegosoft.com >> Gustav-Meyer-Allee 25, Geb?ude 12 HRB 77719 >> 13355 Berlin, Germany Amtsgericht Charlottenburg >> Tel.: +49 30 23 45 86 96 Sitz der Gesellschaft: Berlin >> Fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Olaf Wagner >> >> > -- Neels Janosch Hofmeyr Software Developer neels at elego.de Public Key: http://binarchy.net/neels/neels.hofmeyr.public.key.asc elego Software Solutions GmbH http://www.elegosoft.com Gustav-Meyer-Allee 25, Geb?ude 12 HRB 77719 13355 Berlin, Germany Amtsgericht Charlottenburg Tel.: +49 30 23 45 86 96 Sitz der Gesellschaft: Berlin Fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Olaf Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From neels at elego.de Mon Jan 28 18:22:21 2008 From: neels at elego.de (Neels Janosch Hofmeyr) Date: Mon, 28 Jan 2008 18:22:21 +0100 Subject: [M3devel] Utypes.asLong / Utypes.assignOffT In-Reply-To: <479E0CC2.1020206@elego.de> References: <479DDB3C.4020300@elego.de> <479E045D.2000903@elego.de> <4C6699EA-187B-455D-A7D0-63A69FABF1B7@cs.purdue.edu> <479E0CC2.1020206@elego.de> Message-ID: <479E0F4D.3050809@elego.de> Duh, that was definitely wrong. If anything, it should read y := Utypes.asLong(x) ==becomes==> y := ORD(x); x := Utypes.assignOffT(y) ==becomes==> x := VAL(y, Utypes.off_t); So, is this correct, now? Neels Janosch Hofmeyr wrote: > So, if I understand correctly, this should read > > y := Utypes.asLong(x) ==becomes==> y := ORD(x); > x := Utypes.assignOffT(y) ==becomes==> x := VAL(y); > > right? > > Tony Hosking wrote: >> You will need to use VAL as I noted to handle the fact that off_t is >> LONGINT on some targets and INTEGER on others. >> >> On Jan 28, 2008, at 11:35 AM, Neels Janosch Hofmeyr wrote: >> >>> Apparently, the answer to this is trivial. I found the missing >>> functions in a CVS diff: >>> >>> -PROCEDURE asLong (val: off_t): long = >>> - BEGIN >>> - RETURN val; >>> - END asLong; >>> - >>> -PROCEDURE assignOffT (VAR dest: off_t; src: long) = >>> - BEGIN >>> - dest := src; >>> - END assignOffT; >>> >>> So, just replacing all occurences of these functions with direct >>> assignments compiles without problems. >>> y := Utypes.asLong(x) ==becomes==> y := ORD(x); >>> x := Utypes.assignOffT(y) ==becomes==> x := y; >>> >>> Obviously, CVSup needs to be updated so that it compiles with the >>> most recent CM3! The suplib still uses the obsoleted procedures >>> asLong and assignOffT. Shall I write a mail to Mr. Polstra? >>> >>> Neels >>> >>> Neels Janosch Hofmeyr wrote: >>>> Hi, >>>> >>>> after some problems have been resolved, I still cannot figure out >>>> these errors: >>>> >>>> ===> suplib >>>> --- building in LINUXLIBC6 --- >>>> >>>> new source -> compiling StatBufOffT64.m3 >>>> "../src/StatBufOffT64.m3", line 40: unknown qualification '.' (asLong) >>>> "../src/StatBufOffT64.m3", line 45: unknown qualification '.' >>>> (assignOffT) >>>> >>>> They are trying to access the procedures >>>> Utypes.asLong >>>> Utypes.assignOffT >>>> >>>> Apparently, Utypes.asLong(..) can simply be replaced by ORD(..). Is >>>> this correct?? >>>> >>>> Concerning assignOffT, the commit log speaks of a function called >>>> PROCEDURE expandAssign(VAR dest: off_t; src: long) >>>> , but this function does not exist anywhere in the cm3 source tree >>>> (grep -r expandAssign yielded no results). >>>> >>>> >>>> How do I fix this line in suplib/src/StatBufOffT64.m3 (ll.43-46)? >>>> >>>> PROCEDURE SetStatSize(VAR st: struct_stat; size: CARDINAL) = >>>> BEGIN >>>> Utypes.assignOffT(st.st_size, size); >>>> END SetStatSize; >>>> >>>> "../src/StatBufOffT64.m3", line 45: unknown qualification '.' >>>> (assignOffT) >>>> >>>> >>>> Thanks >>>> >>> >>> -- >>> Neels Janosch Hofmeyr >>> Software Developer >>> >>> neels at elego.de >>> Public Key: http://binarchy.net/neels/neels.hofmeyr.public.key.asc >>> >>> elego Software Solutions GmbH http://www.elegosoft.com >>> Gustav-Meyer-Allee 25, Geb?ude 12 HRB 77719 >>> 13355 Berlin, Germany Amtsgericht Charlottenburg >>> Tel.: +49 30 23 45 86 96 Sitz der Gesellschaft: Berlin >>> Fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Olaf Wagner >>> >>> >> > -- Neels Janosch Hofmeyr Software Developer neels at elego.de Public Key: http://binarchy.net/neels/neels.hofmeyr.public.key.asc elego Software Solutions GmbH http://www.elegosoft.com Gustav-Meyer-Allee 25, Geb?ude 12 HRB 77719 13355 Berlin, Germany Amtsgericht Charlottenburg Tel.: +49 30 23 45 86 96 Sitz der Gesellschaft: Berlin Fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Olaf Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From jayk123 at hotmail.com Mon Jan 28 18:27:19 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 28 Jan 2008 17:27:19 +0000 Subject: [M3devel] nt386gnu threads? In-Reply-To: <2AEEE262-57C1-4D62-AB21-CA977F6C273E@cs.purdue.edu> References: <591840BD-4494-4A2C-AC0F-CD017338E5ED@cs.purdue.edu> <2AEEE262-57C1-4D62-AB21-CA977F6C273E@cs.purdue.edu> Message-ID: > > platforms -- surely \ never occurs anyway on Unix... :)> > Not sure: can \ be used as an escape in file names? Escaping? At the libc/kernel level? Are you serious? I assume they are taken literally and either accepted or rejected. I can try some stuff later. But, even if they are accepted literally, nobody uses them. FURTHERMORE, there is way too much low level parsing of paths. It's a big huge mess. They should probably be parsed into a higher level for internal manipulation and then regurgiated into an external form for the lower level APIs and for human display. Of course, abstraction abstraction abstraction show me the real thing already. :) > I think NT386GNU always used Win32 threads. I think not, but nobody has really said anything with certainty. I am not placing bets either way. I have the PM3 source from Elegosoft locally, simple cvs checkout. I haven't built it. It doesn't show much sign of using native Win32 threads, but I realize building the source and looking at the binaries is much more conclusive than reading the source. As well, what is PM3-Klagenfurt compard to what I am looking at? Should I go and get its source? And, what matters anyway? I think this Cygwin port is going to be mostly garbage anyway, and using pthreads does enhance the garbage somewhat what with pthread_once and pthread_cond, that NT doesn't have until Vista (sigh). Oh..I am remembering why it matters. Direct Win32 threads would be nice but you'd have to weed out other stuff, the dependency from the File APIs to the threading library. Once thie "port" is working and available, maybe someone else who actually uses it can improve it? (Bueller?) I'd like to get back to adding longint support to the integrated backend and possibly bringing up other targets.. I mean, heck, I'm no big user/fan of Unix, but running Unix natively has got to be better than this mismash.. And the pixmap bug, and the set regression test.. :) - 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 rcoleburn at scires.com Mon Jan 28 19:15:42 2008 From: rcoleburn at scires.com (Randy Coleburn) Date: Mon, 28 Jan 2008 13:15:42 -0500 Subject: [M3devel] cm3.cfg variables for IDE In-Reply-To: References: <591840BD-4494-4A2C-AC0F-CD017338E5ED@cs.purdue.edu> <2AEEE262-57C1-4D62-AB21-CA977F6C273E@cs.purdue.edu> Message-ID: <479DD57E.1E75.00D7.1@scires.com> Jay: I thought I should let you know what I understand to be the variables that the IDE is looking to find in cm3.cfg. That way, as you work through any changes to the various cm3.cfg, you can make sure these requirements are met. INSTALL_ROOT (e.g., c:\cm3) BUILD_DIR (e.g., NT386) PKG_USE (e.g., c:\cm3\pkg) DOC_INSTALL (e.g., c:\cm3\doc) INITIAL_CM3_IDE_BROWSER (e.g., c:\progra~1\intern~1\iexplore.exe) INITIAL_CM3_IDE_EDITOR (e.g., c:\progra~1\window~1\accessories\wordpad.exe) Now, of these 6 listed above, the first three: INSTALL_ROOT, BUILD_DIR and PKG_USE, are the most critical for the IDE. DOC_INSTALL can be omitted, in which case the IDE will substitute INSTALL_ROOT\doc If INITIAL_CM3_IDE_BROWSER and/or INITIAL_CM3_IDE_EDITOR are not defined, the IDE will prompt the user via its console log window for the complete paths to these two programs; thus their definition can be omitted from the cm3.cfg. The IDE will store the user's input for subsequent reuse in its own private cfg file. This file is stored in the user's home folder or as specified in the optional CM3_IDE_HOME environment variable. The CM3_IDE_HOME environment variable should point to the path of the user's primary private package repository. CM3_IDE_HOME should NOT be defined in cm3.cfg. If anyone wants to keep the cminstall program up-to-date, they should replace INITIAL_REACTOR_BROWSER and INITIAL_REACTOR_EDITOR with INITIAL_CM3_IDE_BROWSER and/or INITIAL_CM3_IDE_EDITOR . Regards, Randy -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon Jan 28 19:27:04 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 28 Jan 2008 13:27:04 -0500 Subject: [M3devel] nt386gnu threads? In-Reply-To: References: <591840BD-4494-4A2C-AC0F-CD017338E5ED@cs.purdue.edu> <2AEEE262-57C1-4D62-AB21-CA977F6C273E@cs.purdue.edu> Message-ID: <8A226653-07FE-4222-9D54-ADB55D6358CB@cs.purdue.edu> On Jan 28, 2008, at 12:27 PM, Jay wrote: > And the pixmap bug, and the set regression test.. :) :-) And the backend (for me to add stdcall tags), and a known bug in pthreads on FreeBSD, ... It's great that there is so much activity in CM3 these days though. > > > - Jay > > > Connect and share in new ways with Windows Live. Get it now! From jayk123 at hotmail.com Mon Jan 28 19:33:18 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 28 Jan 2008 18:33:18 +0000 Subject: [M3devel] nt386gnu threads? In-Reply-To: <8A226653-07FE-4222-9D54-ADB55D6358CB@cs.purdue.edu> References: <591840BD-4494-4A2C-AC0F-CD017338E5ED@cs.purdue.edu> <2AEEE262-57C1-4D62-AB21-CA977F6C273E@cs.purdue.edu> <8A226653-07FE-4222-9D54-ADB55D6358CB@cs.purdue.edu> Message-ID: I believe I'll have an ok workaround for the stdcall stuff. I think I even know how to fix it "properly". First I want the non-gui NT386GNU to work. It builds *now*, but doesn't work. - Jay > CC: m3devel at elegosoft.com> From: hosking at cs.purdue.edu> Subject: Re: [M3devel] nt386gnu threads?> Date: Mon, 28 Jan 2008 13:27:04 -0500> To: jayk123 at hotmail.com> > > On Jan 28, 2008, at 12:27 PM, Jay wrote:> > > And the pixmap bug, and the set regression test.. :)> > :-) And the backend (for me to add stdcall tags), and a known bug in > pthreads on FreeBSD, ...> > It's great that there is so much activity in CM3 these days though.> > >> >> > - 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 Jan 28 19:40:04 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 28 Jan 2008 18:40:04 +0000 Subject: [M3devel] cm3.cfg variables for IDE In-Reply-To: <479DD57E.1E75.00D7.1@scires.com> References: <591840BD-4494-4A2C-AC0F-CD017338E5ED@cs.purdue.edu> <2AEEE262-57C1-4D62-AB21-CA977F6C273E@cs.purdue.edu> <479DD57E.1E75.00D7.1@scires.com> Message-ID: There are other ways to do this...rather than run iexplore, you can use ShellExecute and run a url or something, or find the clsid of mshtml.dll maybe. For wordpad, again ShellExecute wil tend to find it. Notice how if you say start.run and type wordpad, it finds it? Or "start wordpad" from the command line? "start" ~ ShellExecute, instead of CreateProcess. "Shell" meaning the GUI shell -- Windows Explorer. Wordpad and notepad stink as text editors. And notepad doesn't like Unix newlines. I assume that's why wordepad. Someting should be done, like, in the grand gui installer, where it lists some freeware/shareware editors and offers to download and install and set them as the editor for you. Stuf like TextEdit, TextPad, UltraEdit...I think all of those exist, though somewhat I'm guesing based on the obvious formula. :) As well if it locate msdev or devenv that would be super. As I was saying the other day, I believe msdev and devenv are easily findable via normal installs, except not on my machines. :) I need to go through the environment you sent. The way this stuff works in Modula-3 today is..unnecessarily old fashioned...I'm all for simplicity, but having a bajillion environment variables does not seem to be the thing. Or a bajillion line user editor text files. Or short file names anywhere! Just do a backup/restore and see if those names survive. They might. They might not. Oh well, true, nobody ever backs anything up. Still, xcopy your software from one machine to another and see if the paths still work -- definitely it's hard to do that for free, but you can keep the cost down. - Jay Date: Mon, 28 Jan 2008 13:15:42 -0500From: rcoleburn at scires.comTo: jayk123 at hotmail.comCC: m3devel at elegosoft.comSubject: cm3.cfg variables for IDE Jay: I thought I should let you know what I understand to be the variables that the IDE is looking to find in cm3.cfg. That way, as you work through any changes to the various cm3.cfg, you can make sure these requirements are met. INSTALL_ROOT (e.g., c:\cm3)BUILD_DIR (e.g., NT386)PKG_USE (e.g., c:\cm3\pkg) DOC_INSTALL (e.g., c:\cm3\doc)INITIAL_CM3_IDE_BROWSER (e.g., c:\progra~1\intern~1\iexplore.exe)INITIAL_CM3_IDE_EDITOR (e.g., c:\progra~1\window~1\accessories\wordpad.exe) Now, of these 6 listed above, the first three: INSTALL_ROOT, BUILD_DIR and PKG_USE, are the most critical for the IDE. DOC_INSTALL can be omitted, in which case the IDE will substitute INSTALL_ROOT\doc If INITIAL_CM3_IDE_BROWSER and/or INITIAL_CM3_IDE_EDITOR are not defined, the IDE will prompt the user via its console log window for the complete paths to these two programs; thus their definition can be omitted from the cm3.cfg. The IDE will store the user's input for subsequent reuse in its own private cfg file. This file is stored in the user's home folder or as specified in the optional CM3_IDE_HOME environment variable. The CM3_IDE_HOME environment variable should point to the path of the user's primary private package repository. CM3_IDE_HOME should NOT be defined in cm3.cfg. If anyone wants to keep the cminstall program up-to-date, they should replace INITIAL_REACTOR_BROWSER and INITIAL_REACTOR_EDITOR with INITIAL_CM3_IDE_BROWSER and/or INITIAL_CM3_IDE_EDITOR . Regards, Randy _________________________________________________________________ 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 Jan 28 19:54:47 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 28 Jan 2008 18:54:47 +0000 Subject: [M3devel] NT386/NT386GNU/NT386MINGNU? In-Reply-To: <479DD57E.1E75.00D7.1@scires.com> References: <591840BD-4494-4A2C-AC0F-CD017338E5ED@cs.purdue.edu> <2AEEE262-57C1-4D62-AB21-CA977F6C273E@cs.purdue.edu> <479DD57E.1E75.00D7.1@scires.com> Message-ID: NT386/NT386GNU/NT386MINGNU My "vision" of these is pretty much in now.My weirdo target vs. configuration split. They are all TARGET = NT386. That's the "odd" part.TARGET = NT386GNU doesn't really mean anything.BUILD_DIR varies.OS_TYPE varies.Some other things vary. Does it suck or is it ok or is it great? Should they just be targets instead? This question is really aimed at the people who work on it, who have added new targets in the past, and who have perhaps thought about the SOLsun vs. SOLgnu split. How do you specify which you want? There are a few ways. Just use one usual cm3.cfg file next to cm3.exe (granted, you have to have around like four files, since they share code, NT386 and NT386GNU includes NT386.Common, NT386MINGNU includes NT386). or set the M3CONFIG variable; I've been doing that, right into the source tree. Or possibly CM3_TARGET + CM3_OSTYPE + CM3_GCC_BACKEND The Python code sniffs those. I've been trying that too. Or uname. Again the Python code sniffs. In the compiler, TARGET = NT386 + OS_TYPE == POSIX means Cygwin means a larger jmpbuf. Sleazy or reasonable? I think reasonable. There are still missing parts but it is taking shape. NT386GNU now builds, but you can't run the results at all, they crash.Been there before. :)(But it's obvious where to start here -- fix Upthread.i3.) m3makefiles have to cope, at least in m3core.They always did. You know, there are directories named POSIX, NT386, cygwin, pthread.That is, neither include(OS_TYPE) nor include(TARGET) were ever always correct. Sometimes there was special logic.Now there is just slightly more logic.Reasonable? One bit I feel guilty about is probably too much dependency on OS_TYPE.Some of that should probably be on C_LIBRARY and OS_TYPE should fall away ifC_LIBRARY / THREAD_LIBRARY / WINDOW_LIBRARY are used.I changed them from 0 and 1 to more readable like MS, GNU, X, CYG.There's also C_COMPILER = MS or GNULINKER = MS or GNU The primary users of these variables are NT386.Common. NT386GNU, NT386, NT386MINGNU are little stubs that set some variables and include it. Naming conventions isn't working correctly right now, must have been some oversight by me. Still much to do. Folks who favor one coniguration or the other should benchmark the build times.I should report them.The integrated backend is FAST.Cygwin is SLOW. For goodness sakes, look at how it implements fork(). It does an immediate selective copy, erring toward copying stuff. Yeah, it's nice and impressive that it even works, I realize.MinGWin is in betwen. AND you /should/ be able to target the Cygwin runtime using the integrated backend, and either compiler/lnker. That is, if you really want those forward slashes, and a fast build, that should be totally doable.I was thinking of making NT386FASTGNU, but it's not clear if it is builds fast or runs fast -- builds fast. Well, a native build of that would be in between. cm3 would still pay for Cygwin, but the backend would still be faster for most of its work. :) later, - 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 Jan 28 20:00:35 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 28 Jan 2008 19:00:35 +0000 Subject: [M3devel] NT386/NT386GNU/NT386MINGNU? In-Reply-To: References: <591840BD-4494-4A2C-AC0F-CD017338E5ED@cs.purdue.edu> <2AEEE262-57C1-4D62-AB21-CA977F6C273E@cs.purdue.edu> <479DD57E.1E75.00D7.1@scires.com> Message-ID: ps: NT386MINGNU really does not capture it -- it should like NT386_GNUTOOLS or NT386_GCCBACKEND As I've said, there's a bunch of independent variables, and precanned combinations are nice to have, but hard to chose just which ones and hard to name them... - Jay From: jayk123 at hotmail.comTo: m3devel at elegosoft.comDate: Mon, 28 Jan 2008 18:54:47 +0000Subject: [M3devel] NT386/NT386GNU/NT386MINGNU? NT386/NT386GNU/NT386MINGNU My "vision" of these is pretty much in now.My weirdo target vs. configuration split.They are all TARGET = NT386. That's the "odd" part.TARGET = NT386GNU doesn't really mean anything.BUILD_DIR varies.OS_TYPE varies.Some other things vary.Does it suck or is it ok or is it great?Should they just be targets instead?This question is really aimed at the people who work on it, who have added new targets in the past, and who have perhaps thought about the SOLsun vs. SOLgnu split.How do you specify which you want?There are a few ways. Just use one usual cm3.cfg file next to cm3.exe (granted, you have to have around like four files, since they share code, NT386 and NT386GNU includes NT386.Common, NT386MINGNU includes NT386). or set the M3CONFIG variable; I've been doing that, right into the source tree. Or possibly CM3_TARGET + CM3_OSTYPE + CM3_GCC_BACKEND The Python code sniffs those. I've been trying that too. Or uname. Again the Python code sniffs.In the compiler, TARGET = NT386 + OS_TYPE == POSIX means Cygwin means a larger jmpbuf. Sleazy or reasonable? I think reasonable.There are still missing parts but it is taking shape.NT386GNU now builds, but you can't run the results at all, they crash.Been there before. :)(But it's obvious where to start here -- fix Upthread.i3.)m3makefiles have to cope, at least in m3core.They always did. You know, there are directories named POSIX, NT386, cygwin, pthread.That is, neither include(OS_TYPE) nor include(TARGET) were ever always correct.Sometimes there was special logic.Now there is just slightly more logic.Reasonable?One bit I feel guilty about is probably too much dependency on OS_TYPE.Some of that should probably be on C_LIBRARY and OS_TYPE should fall away ifC_LIBRARY / THREAD_LIBRARY / WINDOW_LIBRARY are used.I changed them from 0 and 1 to more readable like MS, GNU, X, CYG.There's also C_COMPILER = MS or GNULINKER = MS or GNU The primary users of these variables are NT386.Common.NT386GNU, NT386, NT386MINGNU are little stubs that set some variables and include it.Naming conventions isn't working correctly right now, must have been some oversight by me.Still much to do.Folks who favor one coniguration or the other should benchmark the build times.I should report them.The integrated backend is FAST.Cygwin is SLOW. For goodness sakes, look at how it implements fork(). It does an immediate selective copy, erring toward copying stuff. Yeah, it's nice and impressive that it even works, I realize.MinGWin is in betwen. AND you /should/ be able to target the Cygwin runtime using the integrated backend, and either compiler/lnker.That is, if you really want those forward slashes, and a fast build, that should be totally doable.I was thinking of making NT386FASTGNU, but it's not clear if it is builds fast or runs fast -- builds fast.Well, a native build of that would be in between. cm3 would still pay for Cygwin, but the backend would still be faster for most of its work. :) later, - 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 Mon Jan 28 20:32:19 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 28 Jan 2008 14:32:19 -0500 Subject: [M3devel] cm3.cfg variables for IDE In-Reply-To: References: <591840BD-4494-4A2C-AC0F-CD017338E5ED@cs.purdue.edu> <2AEEE262-57C1-4D62-AB21-CA977F6C273E@cs.purdue.edu> <479DD57E.1E75.00D7.1@scires.com> Message-ID: It is not so much old-fashioned as consistent across platforms (Unix, Windows, etc.). Ideally, the same install procedure and environment variables make sense on all platforms. Don't fork the install for different platforms if at all possible. On Jan 28, 2008, at 1:40 PM, Jay wrote: > There are other ways to do this...rather than run iexplore, you can > use ShellExecute and run a url or something, or find the clsid of > mshtml.dll maybe. For wordpad, again ShellExecute wil tend to find > it. Notice how if you say start.run and type wordpad, it finds it? > Or "start wordpad" from the command line? "start" ~ ShellExecute, > instead of CreateProcess. "Shell" meaning the GUI shell -- Windows > Explorer. > > Wordpad and notepad stink as text editors. And notepad doesn't like > Unix newlines. I assume that's why wordepad. > Someting should be done, like, in the grand gui installer, where it > lists some freeware/shareware editors and offers to download and > install and set them as the editor for you. Stuf like TextEdit, > TextPad, UltraEdit...I think all of those exist, though somewhat > I'm guesing based on the obvious formula. :) > As well if it locate msdev or devenv that would be super. > > As I was saying the other day, I believe msdev and devenv are > easily findable via normal installs, except not on my machines. :) > I need to go through the environment you sent. > > The way this stuff works in Modula-3 today is..unnecessarily old > fashioned...I'm all for simplicity, but having a bajillion > environment variables does not seem to be the thing. Or a bajillion > line user editor text files. Or short file names anywhere! Just do > a backup/restore and see if those names survive. They might. They > might not. Oh well, true, nobody ever backs anything up. Still, > xcopy your software from one machine to another and see if the > paths still work -- definitely it's hard to do that for free, but > you can keep the cost down. > > - Jay > > > Date: Mon, 28 Jan 2008 13:15:42 -0500From: rcoleburn at scires.comTo: > jayk123 at hotmail.comCC: m3devel at elegosoft.comSubject: cm3.cfg > variables for IDE > > Jay: > > I thought I should let you know what I understand to be the > variables that the IDE is looking to find in cm3.cfg. That way, as > you work through any changes to the various cm3.cfg, you can make > sure these requirements are met From jayk123 at hotmail.com Mon Jan 28 22:33:57 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 28 Jan 2008 21:33:57 +0000 Subject: [M3devel] cm3.cfg variables for IDE In-Reply-To: References: <591840BD-4494-4A2C-AC0F-CD017338E5ED@cs.purdue.edu> <2AEEE262-57C1-4D62-AB21-CA977F6C273E@cs.purdue.edu> <479DD57E.1E75.00D7.1@scires.com> Message-ID: Make it easier on Windows... ? Right? Windows is the oddball anyway, right? Ok, that's not a great excuse. Do people tend to have firefox or firefox-bin on $PATH on Unix, if they have it on their machines? Or they have "shortcuts" on their "start menus"? I know this totally Windows termonilogy but I have used KDE and GNOME and they seem pretty isomorphic in this area. Ok, I guess they are the K menu the Foot menu. I don't know what they call "shortcuts". Is anyone, um, interested in adopting spaces in their file paths on Unix and work out the kinks? I for one put my compiler, linker, headers, libs without spaces, AND the environment variable based approach I put in makes spaces work anyway. Less luck with IE though. The code is likely forked in terms of where it runs stuff. CreateProcess vs. exec. Not that Windows doesn't have stuff that looks more like exec, or esp. system(), but still some chance that it is forked. So going down the Windows CreateProcess path, it could optionally use ShellExecute, and that will more leaf-only paths like "wordpad.exe" and "iexplore.exe" "just work". Here is another idea. There are environment variables for %programfiles% and %programfiles(x86)%. How about letting environment variables be used here? Well, heck, they are already are allowed, in Quake, with a leading dollar sign. BROWSER = $ProgramFiles & "\internet explorer\iexplore.exe" or somesuch. Not sure you could reference x86 IE from a 64bit process, what with hose parens in the variable name.. darnit. I've got to an AMD64 machine for home soon... If these are "paths to files" and not "command lines", then spaces are unambiguous. As well, CreateProcess is a little funky, but one of its parameters is a file path, not a command line and using that might help here, might. - Jay > CC: rcoleburn at scires.com; m3devel at elegosoft.com> From: hosking at cs.purdue.edu> Subject: Re: [M3devel] cm3.cfg variables for IDE> Date: Mon, 28 Jan 2008 14:32:19 -0500> To: jayk123 at hotmail.com> > It is not so much old-fashioned as consistent across platforms (Unix, > Windows, etc.). Ideally, the same install procedure and environment > variables make sense on all platforms. Don't fork the install for > different platforms if at all possible.> > On Jan 28, 2008, at 1:40 PM, Jay wrote:> > > There are other ways to do this...rather than run iexplore, you can > > use ShellExecute and run a url or something, or find the clsid of > > mshtml.dll maybe. For wordpad, again ShellExecute wil tend to find > > it. Notice how if you say start.run and type wordpad, it finds it? > > Or "start wordpad" from the command line? "start" ~ ShellExecute, > > instead of CreateProcess. "Shell" meaning the GUI shell -- Windows > > Explorer.> >> > Wordpad and notepad stink as text editors. And notepad doesn't like > > Unix newlines. I assume that's why wordepad.> > Someting should be done, like, in the grand gui installer, where it > > lists some freeware/shareware editors and offers to download and > > install and set them as the editor for you. Stuf like TextEdit, > > TextPad, UltraEdit...I think all of those exist, though somewhat > > I'm guesing based on the obvious formula. :)> > As well if it locate msdev or devenv that would be super.> >> > As I was saying the other day, I believe msdev and devenv are > > easily findable via normal installs, except not on my machines. :) > > I need to go through the environment you sent.> >> > The way this stuff works in Modula-3 today is..unnecessarily old > > fashioned...I'm all for simplicity, but having a bajillion > > environment variables does not seem to be the thing. Or a bajillion > > line user editor text files. Or short file names anywhere! Just do > > a backup/restore and see if those names survive. They might. They > > might not. Oh well, true, nobody ever backs anything up. Still, > > xcopy your software from one machine to another and see if the > > paths still work -- definitely it's hard to do that for free, but > > you can keep the cost down.> >> > - Jay> >> >> > Date: Mon, 28 Jan 2008 13:15:42 -0500From: rcoleburn at scires.comTo: > > jayk123 at hotmail.comCC: m3devel at elegosoft.comSubject: cm3.cfg > > variables for IDE> >> > Jay:> >> > I thought I should let you know what I understand to be the > > variables that the IDE is looking to find in cm3.cfg. That way, as > > you work through any changes to the various cm3.cfg, you can make > > sure these requirements are met> _________________________________________________________________ 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 Jan 28 22:35:51 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 28 Jan 2008 21:35:51 +0000 Subject: [M3devel] cm3.cfg variables for IDE In-Reply-To: References: <591840BD-4494-4A2C-AC0F-CD017338E5ED@cs.purdue.edu> <2AEEE262-57C1-4D62-AB21-CA977F6C273E@cs.purdue.edu> <479DD57E.1E75.00D7.1@scires.com> Message-ID: or heck, just spec these as command lines, or command line prefixes, instead of file names and say "start iexplore" and "start wordpad". If you want to wait for them to exit, try "start /wait". If it doesn't quite work the first time, try "cmd start wordpad" or "cmd start /wait wordpad", that probably is needed. No more path to configure. No more install.... - Jay From: jayk123 at hotmail.comTo: hosking at cs.purdue.eduCC: rcoleburn at scires.com; m3devel at elegosoft.comSubject: RE: [M3devel] cm3.cfg variables for IDEDate: Mon, 28 Jan 2008 21:33:57 +0000 Make it easier on Windows... ? Right?Windows is the oddball anyway, right? Ok, that's not a great excuse. Do people tend to have firefox or firefox-bin on $PATH on Unix, if they have it on their machines?Or they have "shortcuts" on their "start menus"? I know this totally Windows termonilogy but I have used KDE and GNOME and they seem pretty isomorphic in this area. Ok, I guess they are the K menu the Foot menu. I don't know what they call "shortcuts". Is anyone, um, interested in adopting spaces in their file paths on Unix and work out the kinks?I for one put my compiler, linker, headers, libs without spaces, AND the environment variable based approach I put in makes spaces work anyway.Less luck with IE though. The code is likely forked in terms of where it runs stuff. CreateProcess vs. exec. Not that Windows doesn't have stuff that looks more like exec, or esp. system(), but still some chance that it is forked. So going down the Windows CreateProcess path, it could optionally use ShellExecute, and that will more leaf-only paths like "wordpad.exe" and "iexplore.exe" "just work". Here is another idea. There are environment variables for %programfiles% and %programfiles(x86)%.How about letting environment variables be used here?Well, heck, they are already are allowed, in Quake, with a leading dollar sign.BROWSER = $ProgramFiles & "\internet explorer\iexplore.exe" or somesuch.Not sure you could reference x86 IE from a 64bit process, what with hose parens in the variable name.. darnit.I've got to an AMD64 machine for home soon... If these are "paths to files" and not "command lines", then spaces are unambiguous.As well, CreateProcess is a little funky, but one of its parameters is a file path, not a command line and using that might help here, might. - Jay > CC: rcoleburn at scires.com; m3devel at elegosoft.com> From: hosking at cs.purdue.edu> Subject: Re: [M3devel] cm3.cfg variables for IDE> Date: Mon, 28 Jan 2008 14:32:19 -0500> To: jayk123 at hotmail.com> > It is not so much old-fashioned as consistent across platforms (Unix, > Windows, etc.). Ideally, the same install procedure and environment > variables make sense on all platforms. Don't fork the install for > different platforms if at all possible.> > On Jan 28, 2008, at 1:40 PM, Jay wrote:> > > There are other ways to do this...rather than run iexplore, you can > > use ShellExecute and run a url or something, or find the clsid of > > mshtml.dll maybe. For wordpad, again ShellExecute wil tend to find > > it. Notice how if you say start.run and type wordpad, it finds it? > > Or "start wordpad" from the command line? "start" ~ ShellExecute, > > instead of CreateProcess. "Shell" meaning the GUI shell -- Windows > > Explorer.> >> > Wordpad and notepad stink as text editors. And notepad doesn't like > > Unix newlines. I assume that's why wordepad.> > Someting should be done, like, in the grand gui installer, where it > > lists some freeware/shareware editors and offers to download and > > install and set them as the editor for you. Stuf like TextEdit, > > TextPad, UltraEdit...I think all of those exist, though somewhat > > I'm guesing based on the obvious formula. :)> > As well if it locate msdev or devenv that would be super.> >> > As I was saying the other day, I believe msdev and devenv are > > easily findable via normal installs, except not on my machines. :) > > I need to go through the environment you sent.> >> > The way this stuff works in Modula-3 today is..unnecessarily old > > fashioned...I'm all for simplicity, but having a bajillion > > environment variables does not seem to be the thing. Or a bajillion > > line user editor text files. Or short file names anywhere! Just do > > a backup/restore and see if those names survive. They might. They > > might not. Oh well, true, nobody ever backs anything up. Still, > > xcopy your software from one machine to another and see if the > > paths still work -- definitely it's hard to do that for free, but > > you can keep the cost down.> >> > - Jay> >> >> > Date: Mon, 28 Jan 2008 13:15:42 -0500From: rcoleburn at scires.comTo: > > jayk123 at hotmail.comCC: m3devel at elegosoft.comSubject: cm3.cfg > > variables for IDE> >> > Jay:> >> > I thought I should let you know what I understand to be the > > variables that the IDE is looking to find in cm3.cfg. That way, as > > you work through any changes to the various cm3.cfg, you can make > > sure these requirements are met> 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 wagner at elegosoft.com Mon Jan 28 23:31:30 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 28 Jan 2008 23:31:30 +0100 Subject: [M3devel] cm3.cfg variables for IDE In-Reply-To: References: <591840BD-4494-4A2C-AC0F-CD017338E5ED@cs.purdue.edu> <2AEEE262-57C1-4D62-AB21-CA977F6C273E@cs.purdue.edu> <479DD57E.1E75.00D7.1@scires.com> Message-ID: <20080128233130.qzbxmy3wg444o84k@mail.elegosoft.com> Quoting Jay : > Do people tend to have firefox or firefox-bin on $PATH on Unix, if > they have it on their machines? People I know use all sorts of browsers on Unix: firefox, mozilla, opera, conquerer, ... > Or they have "shortcuts" on their "start menus"? > I know this totally Windows termonilogy but I have used KDE and > GNOME and they seem pretty isomorphic in this area. > Ok, I guess they are the K menu the Foot menu. I don't know what > they call "shortcuts". I still use fvwm and avoid all more enhanced desktops if possible ;-) > Is anyone, um, interested in adopting spaces in their file paths on > Unix and work out the kinks? This has been tried before, but it will break all simple usage of command line utilities (and there are hundreds of these). I personally don't see the point of using spaces in file names, but opinions may differ on this topic. As for the rest: I'd like to see a list of those settings an installer should find out for itself (as they are platform dependent and there is no real choice for the user) and those that are truly user-selectable due to personal preferences etc. These may also depend on the platform. Such a document may might be a start for an installer redesign (if we don't go for the system-dependent installation packages at last). It will be a tedious work to do that 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 rcoleburn at scires.com Mon Jan 28 23:34:19 2008 From: rcoleburn at scires.com (Randy Coleburn) Date: Mon, 28 Jan 2008 17:34:19 -0500 Subject: [M3devel] cm3.cfg variables for IDE In-Reply-To: References: <591840BD-4494-4A2C-AC0F-CD017338E5ED@cs.purdue.edu> <2AEEE262-57C1-4D62-AB21-CA977F6C273E@cs.purdue.edu> <479DD57E.1E75.00D7.1@scires.com> Message-ID: <479E121A.1E75.00D7.1@scires.com> Jay: I understand about use of the "shell" in Windows to find stuff. I use the "start" command all the time. I'm not ASKING for how best to fix/change/improve the current situation. I'm just STATING what is required for now. Anyone is welcome to improve upon things later. I'm just trying to get this "out the door" so it is available to everyone. At one point in time, circa cm3 v4.1, all of this did in fact work; and, it worked across multiple platforms. If we can get the IDE into the repository, we can migrate it along with the rest of cm3 as the system evolves. No, I don't use WordPad or Notepad as my primary editor for m3 code. I use CRiSP, but that is beside the point. The original CMass Reactor designers tried to come up with some reasonable defaults for the various platforms that would work in virtually all cases. CMInstall used notepad as the default editor for Windows because all Windows systems were known to have notepad installed by default. On Unix, it used a different default, probably vi or something. During the CMInstall dialog, my recollection is that it probed your system for "known" editors and browsers and let you pick from a list of what it found, or you could override its default choices by specifying whatever you wanted. At run-time, the IDE has a configuration screen where you can change these selections again. So, the idea was to make sure Reactor worked out-of-the-box, and let the user customize it to make the experience better, e.g., choose your favorite editor, source code control system, etc. Bottom line, for now we need to make sure INSTALL_ROOT, BUILD_DIR and PKG_USE are defined in cm3.cfg for all platforms. Otherwise, the user is going to run into trouble and we will have to deal with a bunch of support requests. Going forward, we can adapt the IDE code to do whatever works best for everyone. Regards, Randy >>> Jay 1/28/2008 1:40 PM >>> There are other ways to do this...rather than run iexplore, you can use ShellExecute and run a url or something, or find the clsid of mshtml.dll maybe. For wordpad, again ShellExecute wil tend to find it. Notice how if you say start.run and type wordpad, it finds it? Or "start wordpad" from the command line? "start" ~ ShellExecute, instead of CreateProcess. "Shell" meaning the GUI shell -- Windows Explorer. Wordpad and notepad stink as text editors. And notepad doesn't like Unix newlines. I assume that's why wordepad. Someting should be done, like, in the grand gui installer, where it lists some freeware/shareware editors and offers to download and install and set them as the editor for you. Stuf like TextEdit, TextPad, UltraEdit...I think all of those exist, though somewhat I'm guesing based on the obvious formula. :) As well if it locate msdev or devenv that would be super. As I was saying the other day, I believe msdev and devenv are easily findable via normal installs, except not on my machines. :) I need to go through the environment you sent. The way this stuff works in Modula-3 today is..unnecessarily old fashioned... I'm all for simplicity, but having a bajillion environment variables does not seem to be the thing. Or a bajillion line user editor text files. Or short file names anywhere! Just do a backup/restore and see if those names survive. They might. They might not. Oh well, true, nobody ever backs anything up. Still, xcopy your software from one machine to another and see if the paths still work -- definitely it's hard to do that for free, but you can keep the cost down. - Jay Date: Mon, 28 Jan 2008 13:15:42 -0500 From: rcoleburn at scires.com To: jayk123 at hotmail.com CC: m3devel at elegosoft.com Subject: cm3.cfg variables for IDE Jay: I thought I should let you know what I understand to be the variables that the IDE is looking to find in cm3.cfg. That way, as you work through any changes to the various cm3.cfg, you can make sure these requirements are met. INSTALL_ROOT (e.g., c:\cm3) BUILD_DIR (e.g., NT386) PKG_USE (e.g., c:\cm3\pkg) DOC_INSTALL (e.g., c:\cm3\doc) INITIAL_CM3_IDE_BROWSER (e.g., c:\progra~1\intern~1\iexplore.exe) INITIAL_CM3_IDE_EDITOR (e.g., c:\progra~1\window~1\accessories\wordpad.exe) Now, of these 6 listed above, the first three: INSTALL_ROOT, BUILD_DIR and PKG_USE, are the most critical for the IDE. DOC_INSTALL can be omitted, in which case the IDE will substitute INSTALL_ROOT\doc If INITIAL_CM3_IDE_BROWSER and/or INITIAL_CM3_IDE_EDITOR are not defined, the IDE will prompt the user via its console log window for the complete paths to these two programs; thus their definition can be omitted from the cm3.cfg. The IDE will store the user's input for subsequent reuse in its own private cfg file. This file is stored in the user's home folder or as specified in the optional CM3_IDE_HOME environment variable. The CM3_IDE_HOME environment variable should point to the path of the user's primary private package repository. CM3_IDE_HOME should NOT be defined in cm3.cfg. If anyone wants to keep the cminstall program up-to-date, they should replace INITIAL_REACTOR_BROWSER and INITIAL_REACTOR_EDITOR with INITIAL_CM3_IDE_BROWSER and/or INITIAL_CM3_IDE_EDITOR . Regards, Randy 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 wagner at elegosoft.com Mon Jan 28 23:48:43 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 28 Jan 2008 23:48:43 +0100 Subject: [M3devel] Open CM3 regression tests In-Reply-To: References: <20080120211832.GA26993@elegosoft.com> <9C00EA97-9B43-43BE-9CDF-EEAC9C1321D5@cs.purdue.edu> <20080127150327.mh686v2hx4w080w4@mail.elegosoft.com> <1DA9FA59-6DFF-430C-90C5-F1D30003607A@cs.purdue.edu> <20080127185530.e255i76vcwckss4o@mail.elegosoft.com> Message-ID: <20080128234843.c4sc4uzy4gs8wk8c@mail.elegosoft.com> Quoting Jay : > The tests don't even build on Windows and it was going to take more > than 5 minutes fix that. > They are slightly full of sh. :) (I never tire of this joke. :) ) > My current plan is: > get NT386GNU working -- I can already build cm3 and it fails an > assertion about pthread_mutex_something failing. Hey, maybe I should > fix some of the declarations.. :) > or go back to my Mac briefly to investigate > and/or give Tony a day :) Hi Jay, don't try to do too much all at once -- take your time, there's no heed to hurry. This is an open source project :-) If I were you, I'd finish the Windows ports you are working on first, and then help Randy with his bitmap and m3ide problems. It's all up to you of course. What exactly in m3tests is slightly full of sh? I just fixed one missing abstraction, but except for some definitions at the top of the m3makefile, the rest should be quake. As for the regression test framework in scripts/regression, we can run that in NT386GNU / Cygwin if needed. It may be slow, but that should be OK. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Jan 29 00:49:32 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 28 Jan 2008 18:49:32 -0500 Subject: [M3devel] cm3.cfg variables for IDE In-Reply-To: References: <591840BD-4494-4A2C-AC0F-CD017338E5ED@cs.purdue.edu> <2AEEE262-57C1-4D62-AB21-CA977F6C273E@cs.purdue.edu> <479DD57E.1E75.00D7.1@scires.com> Message-ID: <770ED7C9-B8D5-42EC-A7A1-C54EAFDEB1AB@cs.purdue.edu> On Jan 28, 2008, at 4:33 PM, Jay wrote: > Make it easier on Windows... ? Right? > Windows is the oddball anyway, right? Ok, that's not a great excuse. > > Do people tend to have firefox or firefox-bin on $PATH on Unix, if > they have it on their machines? > Or they have "shortcuts" on their "start menus"? Nope. Not on Mac OS X. > I know this totally Windows termonilogy but I have used KDE and > GNOME and they seem pretty isomorphic in this area. > Ok, I guess they are the K menu the Foot menu. I don't know what > they call "shortcuts". > > Is anyone, um, interested in adopting spaces in their file paths on > Unix and work out the kinks? > I for one put my compiler, linker, headers, libs without spaces, > AND the environment variable based approach I put in makes spaces > work anyway. > Less luck with IE though. > > The code is likely forked in terms of where it runs stuff. > CreateProcess vs. exec. Not that Windows doesn't have stuff that > looks more like exec, or esp. system(), but still some chance that > it is forked. So going down the Windows CreateProcess path, it > could optionally use ShellExecute, and that will more leaf-only > paths like "wordpad.exe" and "iexplore.exe" "just work". > > Here is another idea. There are environment variables for % > programfiles% and %programfiles(x86)%. > How about letting environment variables be used here? > Well, heck, they are already are allowed, in Quake, with a leading > dollar sign. > BROWSER = $ProgramFiles & "\internet explorer\iexplore.exe" or > somesuch. > Not sure you could reference x86 IE from a 64bit process, what with > hose parens in the variable name.. darnit. > I've got to an AMD64 machine for home soon... > > If these are "paths to files" and not "command lines", then spaces > are unambiguous. > As well, CreateProcess is a little funky, but one of its parameters > is a file path, not a command line and using that might help here, > might. > > - Jay > > > > > CC: rcoleburn at scires.com; m3devel at elegosoft.com > > From: hosking at cs.purdue.edu > > Subject: Re: [M3devel] cm3.cfg variables for IDE > > Date: Mon, 28 Jan 2008 14:32:19 -0500 > > To: jayk123 at hotmail.com > > > > It is not so much old-fashioned as consistent across platforms > (Unix, > > Windows, etc.). Ideally, the same install procedure and environment > > variables make sense on all platforms. Don't fork the install for > > different platforms if at all possible. > > > > On Jan 28, 2008, at 1:40 PM, Jay wrote: > > > > > There are other ways to do this...rather than run iexplore, you > can > > > use ShellExecute and run a url or something, or find the clsid of > > > mshtml.dll maybe. For wordpad, again ShellExecute wil tend to find > > > it. Notice how if you say start.run and type wordpad, it finds it? > > > Or "start wordpad" from the command line? "start" ~ ShellExecute, > > > instead of CreateProcess. "Shell" meaning the GUI shell -- Windows > > > Explorer. > > > > > > Wordpad and notepad stink as text editors. And notepad doesn't > like > > > Unix newlines. I assume that's why wordepad. > > > Someting should be done, like, in the grand gui installer, > where it > > > lists some freeware/shareware editors and offers to download and > > > install and set them as the editor for you. Stuf like TextEdit, > > > TextPad, UltraEdit...I think all of those exist, though somewhat > > > I'm guesing based on the obvious formula. :) > > > As well if it locate msdev or devenv that would be super. > > > > > > As I was saying the other day, I believe msdev and devenv are > > > easily findable via normal installs, except not on my machines. :) > > > I need to go through the environment you sent. > > > > > > The way this stuff works in Modula-3 today is..unnecessarily old > > > fashioned...I'm all for simplicity, but having a bajillion > > > environment variables does not seem to be the thing. Or a > bajillion > > > line user editor text files. Or short file names anywhere! Just do > > > a backup/restore and see if those names survive. They might. They > > > might not. Oh well, true, nobody ever backs anything up. Still, > > > xcopy your software from one machine to another and see if the > > > paths still work -- definitely it's hard to do that for free, but > > > you can keep the cost down. > > > > > > - Jay > > > > > > > > > Date: Mon, 28 Jan 2008 13:15:42 -0500From: rcoleburn at scires.comTo: > > > jayk123 at hotmail.comCC: m3devel at elegosoft.comSubject: cm3.cfg > > > variables for IDE > > > > > > Jay: > > > > > > I thought I should let you know what I understand to be the > > > variables that the IDE is looking to find in cm3.cfg. That way, as > > > you work through any changes to the various cm3.cfg, you can make > > > sure these requirements are met > > > > > 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 Tue Jan 29 00:50:55 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 28 Jan 2008 18:50:55 -0500 Subject: [M3devel] cm3.cfg variables for IDE In-Reply-To: <479E121A.1E75.00D7.1@scires.com> References: <591840BD-4494-4A2C-AC0F-CD017338E5ED@cs.purdue.edu> <2AEEE262-57C1-4D62-AB21-CA977F6C273E@cs.purdue.edu> <479DD57E.1E75.00D7.1@scires.com> <479E121A.1E75.00D7.1@scires.com> Message-ID: <73F72170-FD22-476F-A307-1E9DE9331CA4@cs.purdue.edu> Hear, hear. Jay, please listen to this -- it is important! On Jan 28, 2008, at 5:34 PM, Randy Coleburn wrote: > Jay: > > I understand about use of the "shell" in Windows to find stuff. I > use the "start" command all the time. > > I'm not ASKING for how best to fix/change/improve the current > situation. I'm just STATING what is required for now. Anyone is > welcome to improve upon things later. I'm just trying to get this > "out the door" so it is available to everyone. > > At one point in time, circa cm3 v4.1, all of this did in fact work; > and, it worked across multiple platforms. If we can get the IDE > into the repository, we can migrate it along with the rest of cm3 > as the system evolves. > > No, I don't use WordPad or Notepad as my primary editor for m3 > code. I use CRiSP, but that is beside the point. The original > CMass Reactor designers tried to come up with some reasonable > defaults for the various platforms that would work in virtually all > cases. CMInstall used notepad as the default editor for Windows > because all Windows systems were known to have notepad installed by > default. On Unix, it used a different default, probably vi or > something. During the CMInstall dialog, my recollection is that it > probed your system for "known" editors and browsers and let you > pick from a list of what it found, or you could override its > default choices by specifying whatever you wanted. At run-time, > the IDE has a configuration screen where you can change these > selections again. > > So, the idea was to make sure Reactor worked out-of-the-box, and > let the user customize it to make the experience better, e.g., > choose your favorite editor, source code control system, etc. > > Bottom line, for now we need to make sure INSTALL_ROOT, BUILD_DIR > and PKG_USE are defined in cm3.cfg for all platforms. Otherwise, > the user is going to run into trouble and we will have to deal with > a bunch of support requests. > > Going forward, we can adapt the IDE code to do whatever works best > for everyone. > > Regards, > Randy > > >>> Jay 1/28/2008 1:40 PM >>> > There are other ways to do this...rather than run iexplore, you can > use ShellExecute and run a url or something, or find the clsid of > mshtml.dll maybe. For wordpad, again ShellExecute wil tend to find > it. Notice how if you say start.run and type wordpad, it finds it? > Or "start wordpad" from the command line? "start" ~ ShellExecute, > instead of CreateProcess. "Shell" meaning the GUI shell -- Windows > Explorer. > > Wordpad and notepad stink as text editors. And notepad doesn't like > Unix newlines. I assume that's why wordepad. > Someting should be done, like, in the grand gui installer, where it > lists some freeware/shareware editors and offers to download and > install and set them as the editor for you. Stuf like TextEdit, > TextPad, UltraEdit...I think all of those exist, though somewhat > I'm guesing based on the obvious formula. :) > As well if it locate msdev or devenv that would be super. > > As I was saying the other day, I believe msdev and devenv are > easily findable via normal installs, except not on my machines. :) > I need to go through the environment you sent. > > The way this stuff works in Modula-3 today is..unnecessarily old > fashioned... > I'm all for simplicity, but having a bajillion environment > variables does not seem to be the thing. Or a bajillion line user > editor text files. Or short file names anywhere! Just do a backup/ > restore and see if those names survive. They might. They might not. > Oh well, true, nobody ever backs anything up. Still, xcopy your > software from one machine to another and see if the paths still > work -- definitely it's hard to do that for free, but you can keep > the cost down. > > - Jay > > Date: Mon, 28 Jan 2008 13:15:42 -0500 > From: rcoleburn at scires.com > To: jayk123 at hotmail.com > CC: m3devel at elegosoft.com > Subject: cm3.cfg variables for IDE > > Jay: > > I thought I should let you know what I understand to be the > variables that the IDE is looking to find in cm3.cfg. That way, as > you work through any changes to the various cm3.cfg, you can make > sure these requirements are met. > > INSTALL_ROOT (e.g., c:\cm3) > BUILD_DIR (e.g., NT386) > PKG_USE (e.g., c:\cm3\pkg) > > DOC_INSTALL (e.g., c:\cm3\doc) > INITIAL_CM3_IDE_BROWSER (e.g., c:\progra~1\intern~1\iexplore.exe) > INITIAL_CM3_IDE_EDITOR (e.g., c:\progra~1\window~1\accessories > \wordpad.exe) > > Now, of these 6 listed above, the first three: INSTALL_ROOT, > BUILD_DIR and PKG_USE, are the most critical for the IDE. > > DOC_INSTALL can be omitted, in which case the IDE will substitute > INSTALL_ROOT\doc > > If INITIAL_CM3_IDE_BROWSER and/or INITIAL_CM3_IDE_EDITOR are not > defined, the IDE will prompt the user via its console log window > for the complete paths to these two programs; thus their definition > can be omitted from the cm3.cfg. The IDE will store the user's > input for subsequent reuse in its own private cfg file. This file > is stored in the user's home folder or as specified in the optional > CM3_IDE_HOME environment variable. The CM3_IDE_HOME environment > variable should point to the path of the user's primary private > package repository. CM3_IDE_HOME should NOT be defined in cm3.cfg. > > If anyone wants to keep the cminstall program up-to-date, they should > replace INITIAL_REACTOR_BROWSER and INITIAL_REACTOR_EDITOR > with INITIAL_CM3_IDE_BROWSER and/or INITIAL_CM3_IDE_EDITOR . > > Regards, > Randy > > Connect and share in new ways with Windows Live. Get it now! From hosking at cs.purdue.edu Tue Jan 29 01:02:45 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 28 Jan 2008 19:02:45 -0500 Subject: [M3devel] Utypes.asLong / Utypes.assignOffT In-Reply-To: <479E0F4D.3050809@elego.de> References: <479DDB3C.4020300@elego.de> <479E045D.2000903@elego.de> <4C6699EA-187B-455D-A7D0-63A69FABF1B7@cs.purdue.edu> <479E0CC2.1020206@elego.de> <479E0F4D.3050809@elego.de> Message-ID: Yes! On Jan 28, 2008, at 12:22 PM, Neels Janosch Hofmeyr wrote: > Duh, that was definitely wrong. If anything, it should read > > y := Utypes.asLong(x) ==becomes==> y := ORD(x); > x := Utypes.assignOffT(y) ==becomes==> x := VAL(y, Utypes.off_t); > > So, is this correct, now? > > Neels Janosch Hofmeyr wrote: >> So, if I understand correctly, this should read >> >> y := Utypes.asLong(x) ==becomes==> y := ORD(x); >> x := Utypes.assignOffT(y) ==becomes==> x := VAL(y); >> >> right? >> >> Tony Hosking wrote: >>> You will need to use VAL as I noted to handle the fact that off_t >>> is LONGINT on some targets and INTEGER on others. >>> >>> On Jan 28, 2008, at 11:35 AM, Neels Janosch Hofmeyr wrote: >>> >>>> Apparently, the answer to this is trivial. I found the missing >>>> functions in a CVS diff: >>>> >>>> -PROCEDURE asLong (val: off_t): long = >>>> - BEGIN >>>> - RETURN val; >>>> - END asLong; >>>> - >>>> -PROCEDURE assignOffT (VAR dest: off_t; src: long) = >>>> - BEGIN >>>> - dest := src; >>>> - END assignOffT; >>>> >>>> So, just replacing all occurences of these functions with direct >>>> assignments compiles without problems. >>>> y := Utypes.asLong(x) ==becomes==> y := ORD(x); >>>> x := Utypes.assignOffT(y) ==becomes==> x := y; >>>> >>>> Obviously, CVSup needs to be updated so that it compiles with >>>> the most recent CM3! The suplib still uses the obsoleted >>>> procedures asLong and assignOffT. Shall I write a mail to Mr. >>>> Polstra? >>>> >>>> Neels >>>> >>>> Neels Janosch Hofmeyr wrote: >>>>> Hi, >>>>> >>>>> after some problems have been resolved, I still cannot figure >>>>> out these errors: >>>>> >>>>> ===> suplib >>>>> --- building in LINUXLIBC6 --- >>>>> >>>>> new source -> compiling StatBufOffT64.m3 >>>>> "../src/StatBufOffT64.m3", line 40: unknown qualification >>>>> '.' (asLong) >>>>> "../src/StatBufOffT64.m3", line 45: unknown qualification >>>>> '.' (assignOffT) >>>>> >>>>> They are trying to access the procedures >>>>> Utypes.asLong >>>>> Utypes.assignOffT >>>>> >>>>> Apparently, Utypes.asLong(..) can simply be replaced by ORD >>>>> (..). Is this correct?? >>>>> >>>>> Concerning assignOffT, the commit log speaks of a function called >>>>> PROCEDURE expandAssign(VAR dest: off_t; src: long) >>>>> , but this function does not exist anywhere in the cm3 source >>>>> tree (grep -r expandAssign yielded no results). >>>>> >>>>> >>>>> How do I fix this line in suplib/src/StatBufOffT64.m3 (ll.43-46)? >>>>> >>>>> PROCEDURE SetStatSize(VAR st: struct_stat; size: CARDINAL) = >>>>> BEGIN >>>>> Utypes.assignOffT(st.st_size, size); >>>>> END SetStatSize; >>>>> >>>>> "../src/StatBufOffT64.m3", line 45: unknown qualification >>>>> '.' (assignOffT) >>>>> >>>>> >>>>> Thanks >>>>> >>>> >>>> -- >>>> Neels Janosch Hofmeyr >>>> Software Developer >>>> >>>> neels at elego.de >>>> Public Key: http://binarchy.net/neels/neels.hofmeyr.public.key.asc >>>> >>>> elego Software Solutions GmbH http://www.elegosoft.com >>>> Gustav-Meyer-Allee 25, Geb?ude 12 HRB 77719 >>>> 13355 Berlin, Germany Amtsgericht Charlottenburg >>>> Tel.: +49 30 23 45 86 96 Sitz der Gesellschaft: >>>> Berlin >>>> Fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Olaf >>>> Wagner >>>> >>>> >>> >> > > -- > Neels Janosch Hofmeyr > Software Developer > > neels at elego.de > Public Key: http://binarchy.net/neels/neels.hofmeyr.public.key.asc > > elego Software Solutions GmbH http://www.elegosoft.com > Gustav-Meyer-Allee 25, Geb?ude 12 HRB 77719 > 13355 Berlin, Germany Amtsgericht Charlottenburg > Tel.: +49 30 23 45 86 96 Sitz der Gesellschaft: Berlin > Fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Olaf Wagner > > From jayk123 at hotmail.com Tue Jan 29 01:38:26 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 29 Jan 2008 00:38:26 +0000 Subject: [M3devel] Open CM3 regression tests In-Reply-To: <20080128234843.c4sc4uzy4gs8wk8c@mail.elegosoft.com> References: <20080120211832.GA26993@elegosoft.com> <9C00EA97-9B43-43BE-9CDF-EEAC9C1321D5@cs.purdue.edu> <20080127150327.mh686v2hx4w080w4@mail.elegosoft.com> <1DA9FA59-6DFF-430C-90C5-F1D30003607A@cs.purdue.edu> <20080127185530.e255i76vcwckss4o@mail.elegosoft.com> <20080128234843.c4sc4uzy4gs8wk8c@mail.elegosoft.com> Message-ID: I was stuck on the use of "ln". I know, it should be easy, just copy stuff..or use Cygwin ln, but it kept not working and I moved on for now. I know it's an easy thing but I was being lazy and there are alternatives if it languishes long, I can try on Mac, or PPC_LINUX (which has other problems perhaps that need working out, maybe just that dynamic linking is broken, I put it in hold for now). > As for the regression test framework in scripts/regression, we can> run that in NT386GNU / Cygwin if needed. It may be slow, but that Agreed! Or, for tests failing on all systems, I can use non-Windows. > don't try to do too much all at once -- take your time, there's> no heed to hurry. I've heard this many times already. :) I am taking my time. You have not seen my hurry. And you hopefully never will. :) - Jay > Date: Mon, 28 Jan 2008 23:48:43 +0100> From: wagner at elegosoft.com> To: jayk123 at hotmail.com> CC: m3devel at elegosoft.com> Subject: RE: [M3devel] Open CM3 regression tests> > Quoting Jay :> > > The tests don't even build on Windows and it was going to take more > > than 5 minutes fix that.> > They are slightly full of sh. :) (I never tire of this joke. :) )> > My current plan is:> > get NT386GNU working -- I can already build cm3 and it fails an > > assertion about pthread_mutex_something failing. Hey, maybe I should > > fix some of the declarations.. :)> > or go back to my Mac briefly to investigate> > and/or give Tony a day :)> > Hi Jay,> > don't try to do too much all at once -- take your time, there's> no heed to hurry. This is an open source project :-)> > If I were you, I'd finish the Windows ports you are working on first,> and then help Randy with his bitmap and m3ide problems. It's all> up to you of course.> > What exactly in m3tests is slightly full of sh? I just fixed one> missing abstraction, but except for some definitions at the> top of the m3makefile, the rest should be quake.> > As for the regression test framework in scripts/regression, we can> run that in NT386GNU / Cygwin if needed. It may be slow, but that> should be OK.> > Olaf> -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 Jan 29 01:40:27 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 29 Jan 2008 00:40:27 +0000 Subject: [M3devel] cm3.cfg variables for IDE In-Reply-To: <770ED7C9-B8D5-42EC-A7A1-C54EAFDEB1AB@cs.purdue.edu> References: <591840BD-4494-4A2C-AC0F-CD017338E5ED@cs.purdue.edu> <2AEEE262-57C1-4D62-AB21-CA977F6C273E@cs.purdue.edu> <479DD57E.1E75.00D7.1@scires.com> <770ED7C9-B8D5-42EC-A7A1-C54EAFDEB1AB@cs.purdue.edu> Message-ID: Right, I've got a Mac...bite my tongue bite my tongue... :) (someday maybe we'll get this stuff working on MacClassic and 68K. :) ) - Jay > CC: rcoleburn at scires.com; m3devel at elegosoft.com> From: hosking at cs.purdue.edu> Subject: Re: [M3devel] cm3.cfg variables for IDE> Date: Mon, 28 Jan 2008 18:49:32 -0500> To: jayk123 at hotmail.com> > > On Jan 28, 2008, at 4:33 PM, Jay wrote:> > > Make it easier on Windows... ? Right?> > Windows is the oddball anyway, right? Ok, that's not a great excuse.> >> > Do people tend to have firefox or firefox-bin on $PATH on Unix, if > > they have it on their machines?> > Or they have "shortcuts" on their "start menus"?> > Nope. Not on Mac OS X. _________________________________________________________________ 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 Jan 29 01:46:50 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 29 Jan 2008 00:46:50 +0000 Subject: [M3devel] cm3.cfg variables for IDE In-Reply-To: <20080128233130.qzbxmy3wg444o84k@mail.elegosoft.com> References: <591840BD-4494-4A2C-AC0F-CD017338E5ED@cs.purdue.edu> <2AEEE262-57C1-4D62-AB21-CA977F6C273E@cs.purdue.edu> <479DD57E.1E75.00D7.1@scires.com> <20080128233130.qzbxmy3wg444o84k@mail.elegosoft.com> Message-ID: > Date: Mon, 28 Jan 2008 23:31:30 +0100> From: wagner at elegosoft.com> > Quoting Jay :> > Do people tend to have firefox or firefox-bin on $PATH on Unix, if > > they have it on their machines?> > People I know use all sorts of browsers on Unix: firefox, mozilla,> opera, conquerer, ... That wasn't my complete point, but partly. Do people have their browser in $PATH? Such that a full path isn't needed? I guess the answer is sometimes yes sometimes no. > > I still use fvwm and avoid all more enhanced desktops if possible ;-)> > > Is anyone, um, interested in adopting spaces in their file paths on > > Unix and work out the kinks?> > This has been tried before, but it will break all simple usage> of command line utilities (and there are hundreds of these).> I personally don't see the point of using spaces in file names,> but opinions may differ on this topic. I agree it is pretty pointless, but yet unfortunately on Windows there is "Program Files" and such and it's not going away. The biggest problem with quoting is you never know how many layers are going to quote/unquote. Really it's a major type system problem...one flat string vs. an array of strings. If only we typed in our command lines in a little gui with a box per parameter. :) cm3/cm3cg is very clever in one way here. cm3cg always gets its input and output from the current working directory. Boom, so many annoying problems gone. :) I don't think "hundreds" of utilities are relevant here, just a few. cc, ld, libtool, cl, link, cm3, cm3cg (not), and a little bit over in m3cc/m3gdb make sed sh. Ok, nevermind...just that I see those short paths..what a hack, they aren't even guaranteeably available, the option can be turned off....once this stuff is in I'll try to take a look at and fix it, only for the small number of visible cases, not the hundreds of cases. - 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 Jan 29 01:48:20 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 29 Jan 2008 00:48:20 +0000 Subject: [M3devel] Open CM3 regression tests In-Reply-To: <20080128234843.c4sc4uzy4gs8wk8c@mail.elegosoft.com> References: <20080120211832.GA26993@elegosoft.com> <9C00EA97-9B43-43BE-9CDF-EEAC9C1321D5@cs.purdue.edu> <20080127150327.mh686v2hx4w080w4@mail.elegosoft.com> <1DA9FA59-6DFF-430C-90C5-F1D30003607A@cs.purdue.edu> <20080127185530.e255i76vcwckss4o@mail.elegosoft.com> <20080128234843.c4sc4uzy4gs8wk8c@mail.elegosoft.com> Message-ID: > As for the regression test framework in scripts/regression, we can> run that in NT386GNU / Cygwin if needed. It may be slow, but that> Agreed! Or, for tests failing on all systems, I can use non-Windows. I was actually thinking of m3tests here, but yes, that too. - 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 Tue Jan 29 02:25:41 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 29 Jan 2008 02:25:41 +0100 Subject: [M3devel] Open CM3 regression tests In-Reply-To: References: <20080120211832.GA26993@elegosoft.com> <9C00EA97-9B43-43BE-9CDF-EEAC9C1321D5@cs.purdue.edu> <20080127150327.mh686v2hx4w080w4@mail.elegosoft.com> <1DA9FA59-6DFF-430C-90C5-F1D30003607A@cs.purdue.edu> <20080127185530.e255i76vcwckss4o@mail.elegosoft.com> <20080128234843.c4sc4uzy4gs8wk8c@mail.elegosoft.com> Message-ID: <20080129022541.0m78eettvocc00wo@mail.elegosoft.com> Quoting Jay : > I was stuck on the use of "ln". > I know, it should be easy, just copy stuff..or use Cygwin ln, but it > kept not working and I moved on for now. I can try to fix that. Let me know of anything else that does not work on Windows. > I know it's an easy thing but I was being lazy and there are > alternatives if it languishes long, I can try on Mac, or PPC_LINUX > (which has other problems perhaps that need working out, maybe just > that dynamic linking is broken, I put it in hold for now). You need to set DYLD_LIBRARY_PATH to m3test/PPC_DARWIN for Darwin, as there's a local library which gets used in all tests. Dynamic linking seems to work differently on Darwin from most other Unix systems I know. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Jan 29 11:45:12 2008 From: mika at async.caltech.edu (Mika Nystrom) Date: Tue, 29 Jan 2008 02:45:12 -0800 Subject: [M3devel] nt386gnu threads? In-Reply-To: Your message of "Mon, 28 Jan 2008 16:19:48 GMT." Message-ID: <200801291045.m0TAjCDM062661@camembert.async.caltech.edu> 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 From hosking at cs.purdue.edu Tue Jan 29 14:08:38 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 29 Jan 2008 08:08:38 -0500 Subject: [M3devel] nt386gnu threads? In-Reply-To: <200801291045.m0TAjCDM062661@camembert.async.caltech.edu> References: <200801291045.m0TAjCDM062661@camembert.async.caltech.edu> Message-ID: 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 From jayk123 at hotmail.com Tue Jan 29 20:43:43 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 29 Jan 2008 19:43:43 +0000 Subject: [M3devel] nt386gnu threads? In-Reply-To: References: <200801291045.m0TAjCDM062661@camembert.async.caltech.edu> Message-ID: I wasn't aware of this, but I don't think it is the problem, not having looked at it yet. Building in m3cc is very independent of cm3 one it gets going. So maybe this is just slow upon slow, sleep upon Cygwin.I should run some numbers with all my whining. Has anyone else built either NT386GNU or NT386MINGNU? MINGNU should be fairly easy to build now and work, for non-gui. GNU fairly easy to build but doesn't work. Possibly I broke it over the weekend, didn't test as much as previously. - 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> _________________________________________________________________ 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 Thu Jan 31 01:34:25 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 31 Jan 2008 01:34:25 +0100 Subject: [M3devel] quake extensions for tests / RFC Message-ID: <20080131013425.f1wph3ypkwc8wkw8@mail.elegosoft.com> Hi, I've added a utilities library package from the DCVS project and a whole bunch of quake builtin functions based on it. As I've often found that just the functions I'd need to express something in quake without using platform dependent means (exec cmd) are not available, I've now decided to add some. Most of them are string and file system related. There are standard text and text array functions, and functions that deal with files, directories, and their content. A third group are three new exec calls: one to execute a command list with the usual redirection options known from shell; one to pipe the contents of a quake variable to an external program, and one to capture the contents of an external program in a quake variable (shell's process or command substitution). I think they will be rather useful. I've also added some standard functions that were always missing in quake: a generic len() function (length of text, array, table), embedded quake code evaluation from a string (quake), and string encode and decode (from libm3). There are 80 short quake tests added in m3quake/test/src/m3makefile which can be run by a simple `cm3 -build'. Before I proceed, I'd like to hear comments about the interfaces and functionality, and especially the function names (always the part that takes most of the time in programming ;-). Several things could probably be better named or improved by adding or altering some parameters. Let me know what you think about it before these functions get used in CM3 packages. I'll write up an HTML documentation and add it to the existing quake language description (which is already a bit old and needs an update) on the WWW pages during the next days. Find attached the function overview and tests. Olaf PS: Some things are still missing and may be added during the next weeks, like directory stacks, system information access and pathname functions. -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 -------------- system information ------------------ hostname() --> text command execution ----------------- q_exec( cmd ) --> int # execute with redirections (>, >>,...) q_exec_put( cmd, text ) --> int # execute cmd with stdin from text q_exec_get( cmd ) --> [int, text] # execute cmd and return output text utilities -------------- split( text, seps ) --> text[] sub( text, off, len ) --> text skipl( text ) --> text skipr( text ) --> text compress( text ) --> text squeeze( text ) --> text pos( text, text ) --> int contains( text, text ) --> boolean bool( text ) --> boolean subst_chars( text, a, b ) --> text del_chars( text, a, b ) --> text subst( text, a, b, n ) --> text subst_env( text ) --> text add_prefix( text[], text ) --> text[] add_suffix( text[], text ) --> text[] file system utilities --------------------- pn -> pathname: text dir -> pn ( not yet; really needed? pn_native( pn ) --> text pn_posix( pn ) --> text pn_win( pn ) --> text pn_root( pn ) --> text pn_sep() --> text ) fs_exists( pn ) --> boolean fs_readable( pn ) --> boolean fs_writable( pn ) --> boolean fs_executable( pn ) --> boolean fs_isdir( pn ) --> boolean fs_isfile( pn ) --> boolean fs_lsdirs( pn, baseonly ) --> text[] fs_lsfiles( pn, baseonly ) --> text[] ( fs_canonical_pn( pn ) --> text ) fs_touch( pn ) # update access time of file fs_rm( pn ) # remove file fs_rmdir( pn ) # remove dir fs_rmrec( pn ) # remove dir and everything below fs_mkdir( pn ) # create directories (mkdir -p) fs_cp( pn, pn ) # copy file fs_contents( pn ) --> text # return file contents as text fs_putfile( pn, text ) # (over)write text into file directory stack --------------- ( not yet pushd( dir ) popd() setwd( dir ) getwd() --> text ) -------------- next part -------------- proc test( code, expected ) is write( "quake(", code, ")", CR, "expected: ", expected, CR, "result: ") quake( code ) write( CR ) end proc quote( s ) is return encode( s ) end proc header( id ) is write( CR, "------ " & id & " ------------------------------------------------------------------", CR ) end proc section( name ) is write( CR, CR, "---------------------------------------" & "---------------------------------------", CR ) write( name ) write( CR, "---------------------------------------" & "---------------------------------------", CR, CR ) end oks = [] kos = [] proc summary() is section( "summary" ) nok = len( oks ) nko = len( kos ) write( nok, " tests succeeded:", CR, oks, CR, CR ) write( nko, " tests failed:", CR, kos, CR ) end proc check( id, code, expected ) is header( id ) write( "quake(", quote(code), ")", CR, "expected: ", sub(quote(expected), 0, 68), CR) quake( code ) write( "result: " & sub(quote(res), 0, 68), CR ) if equal( res & "", expected & "") write( "==> OK", CR ) oks += id %return "T" else write( "==> FAILED", CR ) kos += id %return "" end end proc checkExec( id, code ) is header( id ) write( "quake(", code, ") --> " ) quake( code ) if equal( res, 0 ) write( "OK", CR ) oks += id else write( "FAILED", CR ) kos += id end end write( "quake extension tests", CR, CR ) proc findexe( cmd ) is write( "findexe(" & cmd & ")", CR ) local paths = [] if equal( OS_TYPE, "WIN32" ) paths = split( $PATH, ";" ) else paths = split( $PATH, ":" ) end local p = "" foreach p in paths local pn = p & SL & cmd if fs_isfile( pn ) and fs_executable( pn ) return pn end if equal( OS_TYPE, "WIN32" ) local ext = "" foreach ext in [ "exe", "cmd", "bat" ] local pne = pn & "." & ext if fs_isfile( pne ) and fs_executable( pne ) return pne end end end end return "false" end %----------------------------------------------------------------------------- section( "string function tests" ) %tx = "x = 3 write(\"x = \" & x, CR)" %test( tx, "x = 3" ) t = "a = \" \t ha ha\" res = skipl( a )" check( "t001", t, "ha ha" ) t = "a = \" ha\" res = skipl( a )" check( "t002", t, "ha" ) t = "a = \" ha \" res = skipr( a ) & \"x\"" check( "t003", t, " hax" ) t = "a = \" ha \" res = compress( a ) & \"x\"" check( "t004", t, "hax" ) t = "a = \"apple plum orange\" b = split(a, \" \") res = b[0] & b[2]" check( "t005", t, "appleorange" ) t = "a = \"applepie\" res = sub(a, 5, 3)" check( "t006", t, "pie" ) t = "a = \"applepie\" res = sub(a, 7, 3)" check( "t007", t, "e" ) t = "a = \"a\n\n\nb\n\n\n\nc\n\" res = squeeze(a)" check( "t008", t, "a\n\nb\n\nc\n" ) t = "a = \"applepie\" res = tcontains(a, \"pie\")" check( "t009", t, "TRUE" ) t = "a = \"applepie\" res = tcontains(a, \"pies\")" check( "t010", t, "" ) t = "a = \"applepie\" res = pos(a, \"pie\")" check( "t011", t, 5 ) t = "a = \"applepie\" res = pos(a, \"pies\")" check( "t012", t, "-1" ) t = "a = \"applepie\" n = pos(a, \"pie\") res = sub(a, n, 1)" check( "t013", t, "p" ) t = "res = bool(\"true\")" check( "t014", t, "TRUE") t = "res = bool(\"tRuE\")" check( "t015", t, "TRUE") t = "res = bool(\"TRUE\")" check( "t016", t, "TRUE") t = "res = bool(\"y\")" check( "t017", t, "TRUE") t = "res = bool(\"yes\")" check( "t018", t, "TRUE") t = "res = bool(\"Y\")" check( "t019", t, "TRUE") t = "res = bool(\"YES \")" check( "t020", t, "TRUE") t = "res = bool(\"no\")" check( "t021", t, "") t = "res = bool(\"false\")" check( "t022", t, "") t = "res = bool(\"foo\")" check( "t023", t, "") t = "res = bool(\"0\")" check( "t024", t, "") t = "res = bool(\"1\")" check( "t025", t, "TRUE") t = "a = \"aabaacabbbaccbca\" res = subst_chars(a, \"b\", \"d\")" check( "t026", t, "aadaacadddaccdca") t = "a = \"aabaacabbbaccbca\" res = subst_chars(a, \"bc\", \"dd\")" check( "t027", t, "aadaadadddadddda") t = "a = \"aabaacabbbaccbca\" res = del_chars(a, \"b\")" check( "t028", t, "aaaacaaccca") t = "a = \"aabaacabbbaccbca\" res = del_chars(a, \"bc\")" check( "t029", t, "aaaaaaa") t = "a = \"aabaacabbbaaccbca\" res = subst(a, \"aa\", \" 42 \", 1)" check( "t030", t, " 42 baacabbbaaccbca") t = "a = \"aabaacabbbaaccbca\" res = subst(a, \"aa\", \" 42 \", 2)" check( "t031", t, " 42 b 42 cabbbaaccbca") t = "a = \"aabaacabbbaaccbca\" res = subst(a, \"aa\", \" 42 \", 99)" check( "t032", t, " 42 b 42 cabbb 42 ccbca") t = "a = [ \"a\", \"b\", \"c\" ] res = add_prefix(a, \"pre-\")" check( "t033", t, [ "pre-a", "pre-b", "pre-c" ] ) t = "a = [ \"a\", \"b\", \"c\" ] res = add_suffix(a, \"-suf\")" check( "t034", t, [ "a-suf", "b-suf", "c-suf" ] ) t = "a = \"0123456789\"res = len( a )" check( "t035", t, "10") t = "a = [ \"a\", \"b\", \"c\" ] res = len( a )" check( "t036", t, "3") t = "a = { \"a\" : \"b\", \"c\" : \"d\" } res = len( a )" check( "t037", t, "2") %----------------------------------------------------------------------------- section( "large string tests" ) SP = " " write( "16", SP ) b = "0123456789abcdef" write( "32", SP ) b = b & b write( "64", SP ) b = b & b write( "128", SP ) b = b & b write( "256", SP ) b = b & b write( "512", SP ) b = b & b write( "1k", SP ) b = b & b write( "2k", SP ) b = b & b write( "4k", SP ) b = b & b write( "8k", SP ) b = b & b write( "16k", SP ) b = b & b write( "32k", SP ) b = b & b write( "64k", SP ) b = b & b write( "128k", SP ) b = b & b write( "256k", SP ) b = b & b write( "512k", SP ) b = b & b write( "1m", SP ) b = b & b write( "OK", CR ) t = "a = subst_chars(b, \"bc\", \"xy\") res = subst_chars(b, \"xy\", \"bc\")" check( "t100", t, b) t = "res = sub(del_chars(b, \"0123456789cdef\"), 0, 10)" check( "t101", t, "ababababab") t = "res = len( b )" check( "t102", t, "1048576") %----------------------------------------------------------------------------- section( "file system tests" ) f = "res = fs_exists(\".\")" check( "f001", f, "TRUE" ) f = "res = fs_exists(\"..\")" check( "f002", f, "TRUE" ) f = "res = fs_exists(\"..\" & SL & \"src\")" check( "f003", f, "TRUE" ) f = "res = fs_isdir(\".\")" check( "f004", f, "TRUE" ) f = "res = fs_isdir(\"..\")" check( "f005", f, "TRUE" ) f = "res = fs_isdir(\"..\" & SL & \"src\")" check( "f006", f, "TRUE" ) f = "res = fs_isfile(\".\")" check( "f007", f, "" ) f = "res = fs_isfile(\"..\")" check( "f008", f, "" ) f = "res = fs_isfile(\"..\" & SL & \"src\")" check( "f009", f, "" ) f = "res = fs_isfile(\"..\" & SL & \"src\" & SL & \"m3makefile\")" check( "f010", f, "TRUE" ) f = "res = fs_isdir(\"..\" & SL & \"src\" & SL & \"m3makefile\")" check( "f011", f, "" ) more = findexe( "more" ) f = "res = fs_executable( more )" check( "f012", f, "TRUE" ) f = "res = fs_writable( more )" check( "f013", f, "" ) f = "res = fs_writable(\"..\" & SL & \"src\" & SL & \"m3makefile\")" check( "f014", f, "TRUE" ) %write( pn, CR ) cm3 = findexe( "cm3" ) %write( pn , CR ) orange = "orange" data = "line1\nline2\line3\n" f = "fs_putfile( orange, data ) res = fs_contents( orange )" check( "f015", f, data ) dirs = "a" & SL & "b" dirs_0 = dirs & SL & "c" dirs_1 = dirs & SL & "cc" dirs_2 = dirs & SL & "ccc" dirs_3 = "a" & SL & "bb" fn_a = dirs_0 & SL & "a" fn_b = dirs_0 & SL & "b" fn_c = dirs_0 & SL & "c" write( CR, "--------------------------------------", CR ) write( "dirs = ", dirs, CR ) write( "dirs_0 = ", dirs_0, CR ) write( "dirs_1 = ", dirs_1, CR ) write( "dirs_2 = ", dirs_2, CR ) write( "dirs_3 = ", dirs_3, CR ) write( "fn_a = ", fn_a, CR ) write( "fn_b = ", fn_b, CR ) write( "fn_c = ", fn_c, CR ) f = "fs_mkdir( dirs_0 ) res = fs_isdir( dirs_0 )" check( "f016", f, "TRUE" ) f = "fs_mkdir( dirs_1 ) res = fs_isdir( dirs_1 )" check( "f017", f, "TRUE" ) f = "fs_mkdir( dirs_2 ) res = fs_isdir( dirs_2 )" check( "f018", f, "TRUE" ) f = "fs_mkdir( dirs_3 ) res = fs_isdir( dirs_3 )" check( "f019", f, "TRUE" ) f = "res = fs_lsdirs( dirs, \"\" )" check( "f020", f, [dirs_0, dirs_1, dirs_2] ) f = "res = fs_lsdirs( dirs, \"T\" )" check( "f021", f, "c cc ccc" ) f = "fs_touch( fn_a ) res = fs_isfile( fn_a )" check( "f022", f, "TRUE" ) f = "fs_touch( fn_b ) res = fs_isfile( fn_b )" check( "f023", f, "TRUE" ) f = "fs_touch( fn_c ) res = fs_isfile( fn_c )" check( "f024", f, "TRUE" ) f = "res = fs_lsfiles( dirs_0, \"\" )" check( "f025", f, [fn_a, fn_b, fn_c] ) f = "res = fs_lsfiles( dirs_0, \"T\" )" check( "f026", f, "a b c" ) f = "res = fs_lsfiles( dirs, \"T\" )" check( "f027", f, "" ) f = "fs_rmfile(fn_b) res = fs_lsfiles( dirs_0, \"T\" )" check( "f028", f, "a c" ) f = "fs_rmfile(fn_b) res = fs_lsfiles( dirs_0, \"T\" )" check( "f029", f, "a c" ) f = "fs_rmdir(dirs_3) res = fs_lsdirs( \"a\", \"T\" )" check( "f030", f, "b" ) f = "fs_rmdir(dirs_3) res = fs_lsdirs( \"a\", \"T\" )" check( "f031", f, "b" ) f = "fs_rmrec(dirs) res = fs_lsdirs( \"a\", \"T\" )" check( "f032", f, "" ) f = "fs_touch(dirs) res = fs_lsfiles( \"a\", \"T\" )" check( "f033", f, "b" ) apple = "apple" f = "fs_cp( orange, apple ) res = fs_contents( apple )" check( "f034", f, data ) apple2 = "a" & SL & apple f = "fs_cp( orange, apple2 ) res = fs_contents( apple2 )" check( "f035", f, data ) f = "res = fs_lsfiles( \"a\", \"T\" )" check( "f036", f, "b apple" ) f = "fs_rmfile(apple2) res = fs_lsfiles( \"a\", \"T\" )" check( "f037", f, "b" ) %f = "fs_cp( orange, \"a\" ) res = fs_contents( apple2 )" %check( "f038", f, data ) f = "fs_rmrec(\"a\") res = fs_lsdirs( \".\", \"T\" )" check( "f099", f, "" ) %----------------------------------------------------------------------------- section( "exec tests" ) header( "e001" ) res = q_exec_get( "ls -l" ) write( "rc = ", res[0], CR, "out = ", res[1], CR ) checkExec( "e002", "res = q_exec( \"cm3 -version > cm3.version\" )" ) checkExec( "e003", "res = q_exec( \"rm cm3.version\" )" ) header( "e004" ) a = "a\nb\n\c" res = q_exec_put( "cat -", a ) write( CR, "tests done", CR ) summary() -------------- next part -------------- --- building in FreeBSD4 --- quake extension tests ------------------------------------------------------------------------------ string function tests ------------------------------------------------------------------------------ ------ t001 ------------------------------------------------------------------ quake("a = \" \t ha ha\" res = skipl( a )") expected: "ha ha" result: "ha ha" ==> OK ------ t002 ------------------------------------------------------------------ quake("a = \" ha\" res = skipl( a )") expected: "ha" result: "ha" ==> OK ------ t003 ------------------------------------------------------------------ quake("a = \" ha \" res = skipr( a ) & \"x\"") expected: " hax" result: " hax" ==> OK ------ t004 ------------------------------------------------------------------ quake("a = \" ha \" res = compress( a ) & \"x\"") expected: "hax" result: "hax" ==> OK ------ t005 ------------------------------------------------------------------ quake("a = \"apple plum orange\" b = split(a, \" \") res = b[0] & b[2]") expected: "appleorange" result: "appleorange" ==> OK ------ t006 ------------------------------------------------------------------ quake("a = \"applepie\" res = sub(a, 5, 3)") expected: "pie" result: "pie" ==> OK ------ t007 ------------------------------------------------------------------ quake("a = \"applepie\" res = sub(a, 7, 3)") expected: "e" result: "e" ==> OK ------ t008 ------------------------------------------------------------------ quake("a = \"a\n\n\nb\n\n\n\nc\n\" res = squeeze(a)") expected: "a\n\nb\n\nc\n" result: "a\n\nb\n\nc\n" ==> OK ------ t009 ------------------------------------------------------------------ quake("a = \"applepie\" res = tcontains(a, \"pie\")") expected: "TRUE" result: "TRUE" ==> OK ------ t010 ------------------------------------------------------------------ quake("a = \"applepie\" res = tcontains(a, \"pies\")") expected: "" result: "" ==> OK ------ t011 ------------------------------------------------------------------ quake("a = \"applepie\" res = pos(a, \"pie\")") expected: "5" result: "5" ==> OK ------ t012 ------------------------------------------------------------------ quake("a = \"applepie\" res = pos(a, \"pies\")") expected: "-1" result: "-1" ==> OK ------ t013 ------------------------------------------------------------------ quake("a = \"applepie\" n = pos(a, \"pie\") res = sub(a, n, 1)") expected: "p" result: "p" ==> OK ------ t014 ------------------------------------------------------------------ quake("res = bool(\"true\")") expected: "TRUE" result: "TRUE" ==> OK ------ t015 ------------------------------------------------------------------ quake("res = bool(\"tRuE\")") expected: "TRUE" result: "TRUE" ==> OK ------ t016 ------------------------------------------------------------------ quake("res = bool(\"TRUE\")") expected: "TRUE" result: "TRUE" ==> OK ------ t017 ------------------------------------------------------------------ quake("res = bool(\"y\")") expected: "TRUE" result: "TRUE" ==> OK ------ t018 ------------------------------------------------------------------ quake("res = bool(\"yes\")") expected: "TRUE" result: "TRUE" ==> OK ------ t019 ------------------------------------------------------------------ quake("res = bool(\"Y\")") expected: "TRUE" result: "TRUE" ==> OK ------ t020 ------------------------------------------------------------------ quake("res = bool(\"YES \")") expected: "TRUE" result: "TRUE" ==> OK ------ t021 ------------------------------------------------------------------ quake("res = bool(\"no\")") expected: "" result: "" ==> OK ------ t022 ------------------------------------------------------------------ quake("res = bool(\"false\")") expected: "" result: "" ==> OK ------ t023 ------------------------------------------------------------------ quake("res = bool(\"foo\")") expected: "" result: "" ==> OK ------ t024 ------------------------------------------------------------------ quake("res = bool(\"0\")") expected: "" result: "" ==> OK ------ t025 ------------------------------------------------------------------ quake("res = bool(\"1\")") expected: "TRUE" result: "TRUE" ==> OK ------ t026 ------------------------------------------------------------------ quake("a = \"aabaacabbbaccbca\" res = subst_chars(a, \"b\", \"d\")") expected: "aadaacadddaccdca" result: "aadaacadddaccdca" ==> OK ------ t027 ------------------------------------------------------------------ quake("a = \"aabaacabbbaccbca\" res = subst_chars(a, \"bc\", \"dd\")") expected: "aadaadadddadddda" result: "aadaadadddadddda" ==> OK ------ t028 ------------------------------------------------------------------ quake("a = \"aabaacabbbaccbca\" res = del_chars(a, \"b\")") expected: "aaaacaaccca" result: "aaaacaaccca" ==> OK ------ t029 ------------------------------------------------------------------ quake("a = \"aabaacabbbaccbca\" res = del_chars(a, \"bc\")") expected: "aaaaaaa" result: "aaaaaaa" ==> OK ------ t030 ------------------------------------------------------------------ quake("a = \"aabaacabbbaaccbca\" res = subst(a, \"aa\", \" 42 \", 1)") expected: " 42 baacabbbaaccbca" result: " 42 baacabbbaaccbca" ==> OK ------ t031 ------------------------------------------------------------------ quake("a = \"aabaacabbbaaccbca\" res = subst(a, \"aa\", \" 42 \", 2)") expected: " 42 b 42 cabbbaaccbca" result: " 42 b 42 cabbbaaccbca" ==> OK ------ t032 ------------------------------------------------------------------ quake("a = \"aabaacabbbaaccbca\" res = subst(a, \"aa\", \" 42 \", 99)") expected: " 42 b 42 cabbb 42 ccbca" result: " 42 b 42 cabbb 42 ccbca" ==> OK ------ t033 ------------------------------------------------------------------ quake("a = [ \"a\", \"b\", \"c\" ] res = add_prefix(a, \"pre-\")") expected: "pre-a pre-b pre-c" result: "pre-a pre-b pre-c" ==> OK ------ t034 ------------------------------------------------------------------ quake("a = [ \"a\", \"b\", \"c\" ] res = add_suffix(a, \"-suf\")") expected: "a-suf b-suf c-suf" result: "a-suf b-suf c-suf" ==> OK ------ t035 ------------------------------------------------------------------ quake("a = \"0123456789\"res = len( a )") expected: "10" result: "10" ==> OK ------ t036 ------------------------------------------------------------------ quake("a = [ \"a\", \"b\", \"c\" ] res = len( a )") expected: "3" result: "3" ==> OK ------ t037 ------------------------------------------------------------------ quake("a = { \"a\" : \"b\", \"c\" : \"d\" } res = len( a )") expected: "2" result: "2" ==> OK ------------------------------------------------------------------------------ large string tests ------------------------------------------------------------------------------ 16 32 64 128 256 512 1k 2k 4k 8k 16k 32k 64k 128k 256k 512k 1m OK ------ t100 ------------------------------------------------------------------ quake("a = subst_chars(b, \"bc\", \"xy\") res = subst_chars(b, \"xy\", \"bc\")") expected: "0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef012 result: "0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef012 ==> OK ------ t101 ------------------------------------------------------------------ quake("res = sub(del_chars(b, \"0123456789cdef\"), 0, 10)") expected: "ababababab" result: "ababababab" ==> OK ------ t102 ------------------------------------------------------------------ quake("res = len( b )") expected: "1048576" result: "1048576" ==> OK ------------------------------------------------------------------------------ file system tests ------------------------------------------------------------------------------ ------ f001 ------------------------------------------------------------------ quake("res = fs_exists(\".\")") expected: "TRUE" result: "TRUE" ==> OK ------ f002 ------------------------------------------------------------------ quake("res = fs_exists(\"..\")") expected: "TRUE" result: "TRUE" ==> OK ------ f003 ------------------------------------------------------------------ quake("res = fs_exists(\"..\" & SL & \"src\")") expected: "TRUE" result: "TRUE" ==> OK ------ f004 ------------------------------------------------------------------ quake("res = fs_isdir(\".\")") expected: "TRUE" result: "TRUE" ==> OK ------ f005 ------------------------------------------------------------------ quake("res = fs_isdir(\"..\")") expected: "TRUE" result: "TRUE" ==> OK ------ f006 ------------------------------------------------------------------ quake("res = fs_isdir(\"..\" & SL & \"src\")") expected: "TRUE" result: "TRUE" ==> OK ------ f007 ------------------------------------------------------------------ quake("res = fs_isfile(\".\")") expected: "" result: "" ==> OK ------ f008 ------------------------------------------------------------------ quake("res = fs_isfile(\"..\")") expected: "" result: "" ==> OK ------ f009 ------------------------------------------------------------------ quake("res = fs_isfile(\"..\" & SL & \"src\")") expected: "" result: "" ==> OK ------ f010 ------------------------------------------------------------------ quake("res = fs_isfile(\"..\" & SL & \"src\" & SL & \"m3makefile\")") expected: "TRUE" result: "TRUE" ==> OK ------ f011 ------------------------------------------------------------------ quake("res = fs_isdir(\"..\" & SL & \"src\" & SL & \"m3makefile\")") expected: "" result: "" ==> OK findexe(more) ------ f012 ------------------------------------------------------------------ quake("res = fs_executable( more )") expected: "TRUE" result: "TRUE" ==> OK ------ f013 ------------------------------------------------------------------ quake("res = fs_writable( more )") expected: "" result: "" ==> OK ------ f014 ------------------------------------------------------------------ quake("res = fs_writable(\"..\" & SL & \"src\" & SL & \"m3makefile\")") expected: "TRUE" result: "TRUE" ==> OK findexe(cm3) ------ f015 ------------------------------------------------------------------ quake("fs_putfile( orange, data ) res = fs_contents( orange )") expected: "line1\nline2line3\n" result: "line1\nline2line3\n" ==> OK -------------------------------------- dirs = a/b dirs_0 = a/b/c dirs_1 = a/b/cc dirs_2 = a/b/ccc dirs_3 = a/bb fn_a = a/b/c/a fn_b = a/b/c/b fn_c = a/b/c/c ------ f016 ------------------------------------------------------------------ quake("fs_mkdir( dirs_0 ) res = fs_isdir( dirs_0 )") expected: "TRUE" result: "TRUE" ==> OK ------ f017 ------------------------------------------------------------------ quake("fs_mkdir( dirs_1 ) res = fs_isdir( dirs_1 )") expected: "TRUE" result: "TRUE" ==> OK ------ f018 ------------------------------------------------------------------ quake("fs_mkdir( dirs_2 ) res = fs_isdir( dirs_2 )") expected: "TRUE" result: "TRUE" ==> OK ------ f019 ------------------------------------------------------------------ quake("fs_mkdir( dirs_3 ) res = fs_isdir( dirs_3 )") expected: "TRUE" result: "TRUE" ==> OK ------ f020 ------------------------------------------------------------------ quake("res = fs_lsdirs( dirs, \"\" )") expected: "a/b/c a/b/cc a/b/ccc" result: "a/b/c a/b/cc a/b/ccc" ==> OK ------ f021 ------------------------------------------------------------------ quake("res = fs_lsdirs( dirs, \"T\" )") expected: "c cc ccc" result: "c cc ccc" ==> OK ------ f022 ------------------------------------------------------------------ quake("fs_touch( fn_a ) res = fs_isfile( fn_a )") expected: "TRUE" result: "TRUE" ==> OK ------ f023 ------------------------------------------------------------------ quake("fs_touch( fn_b ) res = fs_isfile( fn_b )") expected: "TRUE" result: "TRUE" ==> OK ------ f024 ------------------------------------------------------------------ quake("fs_touch( fn_c ) res = fs_isfile( fn_c )") expected: "TRUE" result: "TRUE" ==> OK ------ f025 ------------------------------------------------------------------ quake("res = fs_lsfiles( dirs_0, \"\" )") expected: "a/b/c/a a/b/c/b a/b/c/c" result: "a/b/c/a a/b/c/b a/b/c/c" ==> OK ------ f026 ------------------------------------------------------------------ quake("res = fs_lsfiles( dirs_0, \"T\" )") expected: "a b c" result: "a b c" ==> OK ------ f027 ------------------------------------------------------------------ quake("res = fs_lsfiles( dirs, \"T\" )") expected: "" result: "" ==> OK ------ f028 ------------------------------------------------------------------ quake("fs_rmfile(fn_b) res = fs_lsfiles( dirs_0, \"T\" )") expected: "a c" result: "a c" ==> OK ------ f029 ------------------------------------------------------------------ quake("fs_rmfile(fn_b) res = fs_lsfiles( dirs_0, \"T\" )") expected: "a c" result: "a c" ==> OK ------ f030 ------------------------------------------------------------------ quake("fs_rmdir(dirs_3) res = fs_lsdirs( \"a\", \"T\" )") expected: "b" result: "b" ==> OK ------ f031 ------------------------------------------------------------------ quake("fs_rmdir(dirs_3) res = fs_lsdirs( \"a\", \"T\" )") expected: "b" result: "b" ==> OK ------ f032 ------------------------------------------------------------------ quake("fs_rmrec(dirs) res = fs_lsdirs( \"a\", \"T\" )") expected: "" result: "" ==> OK ------ f033 ------------------------------------------------------------------ quake("fs_touch(dirs) res = fs_lsfiles( \"a\", \"T\" )") expected: "b" result: "b" ==> OK ------ f034 ------------------------------------------------------------------ quake("fs_cp( orange, apple ) res = fs_contents( apple )") expected: "line1\nline2line3\n" result: "line1\nline2line3\n" ==> OK ------ f035 ------------------------------------------------------------------ quake("fs_cp( orange, apple2 ) res = fs_contents( apple2 )") expected: "line1\nline2line3\n" result: "line1\nline2line3\n" ==> OK ------ f036 ------------------------------------------------------------------ quake("res = fs_lsfiles( \"a\", \"T\" )") expected: "b apple" result: "b apple" ==> OK ------ f037 ------------------------------------------------------------------ quake("fs_rmfile(apple2) res = fs_lsfiles( \"a\", \"T\" )") expected: "b" result: "b" ==> OK ------ f099 ------------------------------------------------------------------ quake("fs_rmrec(\"a\") res = fs_lsdirs( \".\", \"T\" )") expected: "" result: "" ==> OK ------------------------------------------------------------------------------ exec tests ------------------------------------------------------------------------------ ------ e001 ------------------------------------------------------------------ rc = 0 out = total 8 -rw-rw-r-- 1 wagner wheel 17 31 Jan 00:59 apple -rw-rw-r-- 1 wagner wheel 17 29 Jan 18:43 ls-1 -rw-rw-r-- 1 wagner wheel 97 31 Jan 00:59 m3make.args -rw-rw-r-- 1 wagner wheel 17 31 Jan 00:59 orange ------ e002 ------------------------------------------------------------------ quake(res = q_exec( "cm3 -version > cm3.version" )) --> OK ------ e003 ------------------------------------------------------------------ quake(res = q_exec( "rm cm3.version" )) --> OK ------ e004 ------------------------------------------------------------------ a b c tests done ------------------------------------------------------------------------------ summary ------------------------------------------------------------------------------ 80 tests succeeded: t001 t002 t003 t004 t005 t006 t007 t008 t009 t010 t011 t012 t013 t014 t015 t016 t017 t018 t019 t020 t021 t022 t023 t024 t025 t026 t027 t028 t029 t030 t031 t032 t033 t034 t035 t036 t037 t100 t101 t102 f001 f002 f003 f004 f005 f006 f007 f008 f009 f010 f011 f012 f013 f014 f015 f016 f017 f018 f019 f020 f021 f022 f023 f024 f025 f026 f027 f028 f029 f030 f031 f032 f033 f034 f035 f036 f037 f099 e002 e003 0 tests failed: From wagner at elegosoft.com Thu Jan 31 12:43:04 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 31 Jan 2008 12:43:04 +0100 Subject: [M3devel] Looking for CM3 Tinderbox regression test participants, was: Re: M3 concerns In-Reply-To: <20080105143235.ujed2tl3ksogws8k@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> Message-ID: <20080131124304.w0aq9ygt2ckw4okc@mail.elegosoft.com> 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 Thu Jan 31 17:22:23 2008 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Thu, 31 Jan 2008 10:22:23 -0600 Subject: [M3devel] [Fwd: Sanity check request regarding CT arithmetic] Message-ID: <47A1F5BF.3070201@wichita.edu> 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 From hosking at cs.purdue.edu Thu Jan 31 18:29:21 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 31 Jan 2008 12:29:21 -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: <22926B17-1317-4B74-9024-AADFF81ED88A@cs.purdue.edu> I can contribute: see below... 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 I can do OS X 10.4. > o I386_DARWIN I can do OS X 10.4. > o SOLgnu on any Solaris version I can do Solaris 10 T2000. > o SOLsun " I can do Solaris 10 T2000. > o LINUXLIBC6 on RedHat, Fedora, Ubuntu, Suse Linux (have I forgotten > some variants?) I can do these too if noone else wants to take up the cause. > 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 could fire up the one in the corner of my office that is lying dormant if there is need... :-) > > 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 Thu Jan 31 18:44:05 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 31 Jan 2008 12:44:05 -0500 Subject: [M3devel] [Fwd: Sanity check request regarding CT arithmetic] In-Reply-To: <47A1F5BF.3070201@wichita.edu> References: <47A1F5BF.3070201@wichita.edu> Message-ID: <338F5FD0-A818-4792-A583-A17B72EF956D@cs.purdue.edu> 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 > > From wagner at elegosoft.com Thu Jan 31 20:03:17 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 31 Jan 2008 20:03:17 +0100 Subject: [M3devel] Looking for CM3 Tinderbox regression test participants, was: Re: M3 concerns In-Reply-To: <22926B17-1317-4B74-9024-AADFF81ED88A@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> <22926B17-1317-4B74-9024-AADFF81ED88A@cs.purdue.edu> Message-ID: <20080131200317.uwy41vdfkw40o04g@mail.elegosoft.com> Great! Just go ahead and try one target of your choice; I dare say you should have no problem with the setup. (Solaris would be great, as this is a completely different architecture, and our last Sun died some time ago.) If it works OK, we should soon see the results in the tinderbox. We can then add others one by one. As you're the first to respond, you've got the free choice what and how much you will take over; running the tests regularly will cost some resources in form of disk space and cpu, of course. I'd like to set up a reliable network, that's why I want to progress cautiously and observe the effects and impacts. If I can be of any hlep, just let me know; as you've got ssh access already, everything *should* just work... ;-) Thanks in advance, Olaf Quoting Tony Hosking : > I can contribute: see below... > >> o PPC_DARWIN on MacOS X 10.4 or 10.5 > > I can do OS X 10.4. > >> o I386_DARWIN > > I can do OS X 10.4. > >> o SOLgnu on any Solaris version > > I can do Solaris 10 T2000. > >> o SOLsun " > > I can do Solaris 10 T2000. > >> o LINUXLIBC6 on RedHat, Fedora, Ubuntu, Suse Linux (have I forgotten >> some variants?) > > I can do these too if noone else wants to take up the cause. > >> o ALPHA_OSF -- is anybody still using Alphas? > > I could fire up the one in the corner of my office that is lying > dormant if there is need... :-) -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Jan 31 20:23:39 2008 From: jayk123 at hotmail.com (Jay) Date: Thu, 31 Jan 2008 19:23:39 +0000 Subject: [M3devel] Looking for CM3 Tinderbox regression test participants, was: Re: M3 concerns In-Reply-To: <20080131200317.uwy41vdfkw40o04g@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> <22926B17-1317-4B74-9024-AADFF81ED88A@cs.purdue.edu> <20080131200317.uwy41vdfkw40o04g@mail.elegosoft.com> Message-ID: I intendto try first PPC_DARWIN, PPC_LINUX, NT386* but no promises, esp. on regularity, my machines are mostly laptops that sleep a lot, and then maybe other x86 and PPC after that (including maybe try to bring up new ones..another thread..) - Jay > Date: Thu, 31 Jan 2008 20:03:17 +0100> From: wagner at elegosoft.com> To: hosking at cs.purdue.edu> CC: m3devel at elegosoft.com; m3-support at elego.de; tobermueller at elego.de; admins at elego.de> Subject: Re: [M3devel] Looking for CM3 Tinderbox regression test participants, was: Re: M3 concerns> > Great!> > Just go ahead and try one target of your choice; I dare say you should> have no problem with the setup. (Solaris would be great, as this is> a completely different architecture, and our last Sun died some time ago.)> > If it works OK, we should soon see the results in the tinderbox.> We can then add others one by one. As you're the first to respond,> you've got the free choice what and how much you will take over;> running the tests regularly will cost some resources in form of disk> space and cpu, of course. I'd like to set up a reliable network,> that's why I want to progress cautiously and observe the effects and> impacts.> > If I can be of any hlep, just let me know; as you've got ssh access> already, everything *should* just work... ;-)> > Thanks in advance,> > Olaf> > Quoting Tony Hosking :> > > I can contribute: see below...> >> > >> o PPC_DARWIN on MacOS X 10.4 or 10.5> >> > I can do OS X 10.4.> >> >> o I386_DARWIN> >> > I can do OS X 10.4.> >> >> o SOLgnu on any Solaris version> >> > I can do Solaris 10 T2000.> >> >> o SOLsun "> >> > I can do Solaris 10 T2000.> >> >> o LINUXLIBC6 on RedHat, Fedora, Ubuntu, Suse Linux (have I forgotten> >> some variants?)> >> > I can do these too if noone else wants to take up the cause.> >> >> o ALPHA_OSF -- is anybody still using Alphas?> >> > I could fire up the one in the corner of my office that is lying> > dormant if there is need... :-)> -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 Thu Jan 31 20:31:28 2008 From: jayk123 at hotmail.com (Jay) Date: Thu, 31 Jan 2008 19:31:28 +0000 Subject: [M3devel] what platforms/architectures interest people? In-Reply-To: <20080131200317.uwy41vdfkw40o04g@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> <22926B17-1317-4B74-9024-AADFF81ED88A@cs.purdue.edu> <20080131200317.uwy41vdfkw40o04g@mail.elegosoft.com> Message-ID: This is getting way ahead of things, but I was wondering what platforms/architectures interest folks? *_NETBSD (maybe NBSD for short?) *_OPENBSD (OBSD?) *_FREEBSD (FBSD?) MIPS_* SH_* ARM_* (there is some ARM stuff) ALPHA_* IA64_* AMD64_* *_WINCE (mainly ARM, but many possible -- x86, MIPS, PPC, SH) X86_DJGPP ?? SPARC_LINUX ?? SPARC_*BSD ?? Personally I only have PPC, x86, and AMD64 hardware, all laptops, and the rest aren't available in laptops afaik (ok, WINCE devices are small). I'd be willing to try PPC_*BSD, X86_*BSD|SOLARIS, AMD64_LINUX|NT|SOLARIS. Itanium 1 hardware is under $500 on eBay, Itanium 2 under $1000. Far from a laptop but slightly tempting in terms of aggressive porting. At least they run Windows. :) Or is everything pretty dead by now but x86 and AMD64? (other than cell phones, hand helds, game consoles). I was also think expanding the use of the integrated backend would be interesting. - Jay _________________________________________________________________ Shed those extra pounds with MSN and The Biggest Loser! http://biggestloser.msn.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcoleburn at scires.com Thu Jan 31 23:53:30 2008 From: rcoleburn at scires.com (Randy Coleburn) Date: Thu, 31 Jan 2008 17:53:30 -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: <47A20B17.1E75.00D7.1@scires.com> Olaf: I'll take a look at the requirements and see if I can set something up for testing NT386 on Windows XP and perhaps on Windows 2000. Regards, Randy >>> Olaf Wagner 1/31/2008 6:43 AM >>> 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 ( 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 rcoleburn at scires.com Thu Jan 31 23:56:05 2008 From: rcoleburn at scires.com (Randy Coleburn) Date: Thu, 31 Jan 2008 17:56:05 -0500 Subject: [M3devel] what platforms/architectures interest people? 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> <22926B17-1317-4B74-9024-AADFF81ED88A@cs.purdue.edu> <20080131200317.uwy41vdfkw40o04g@mail.elegosoft.com> Message-ID: <47A20BB2.1E75.00D7.1@scires.com> Jay: The platforms I use most for Modula-3 are Windows (NT/2000/XP) and HP-UX. I also may have occasion to use SPARC and Solaris. Of course, the list will change over time. Regards, Randy >>> Jay 1/31/2008 2:31 PM >>> This is getting way ahead of things, but I was wondering what platforms/architectures interest folks? *_NETBSD (maybe NBSD for short?) *_OPENBSD (OBSD?) *_FREEBSD (FBSD?) MIPS_* SH_* ARM_* (there is some ARM stuff) ALPHA_* IA64_* AMD64_* *_WINCE (mainly ARM, but many possible -- x86, MIPS, PPC, SH) X86_DJGPP ?? SPARC_LINUX ?? SPARC_*BSD ?? Personally I only have PPC, x86, and AMD64 hardware, all laptops, and the rest aren't available in laptops afaik (ok, WINCE devices are small). I'd be willing to try PPC_*BSD, X86_*BSD|SOLARIS, AMD64_LINUX|NT|SOLARIS. Itanium 1 hardware is under $500 on eBay, Itanium 2 under $1000. Far from a laptop but slightly tempting in terms of aggressive porting. At least they run Windows. :) Or is everything pretty dead by now but x86 and AMD64? (other than cell phones, hand helds, game consoles). I was also think expanding the use of the integrated backend would be interesting. - Jay 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 Thu Jan 3 11:58:38 2008 From: jayk123 at hotmail.com (Jay) Date: Thu, 03 Jan 2008 10:58:38 -0000 Subject: [M3devel] M3 concerns In-Reply-To: <200801030010.m030AgKN099099@camembert.async.caltech.edu> References: Your message of "Wed, 02 Jan 2008 14:32:02 EST." <477BA060.1E75.00D7.1@scires.com> <200801030010.m030AgKN099099@camembert.async.caltech.edu> Message-ID: This is in reference to me. I have been making pretty small safe tested changes. But yeah I am impatient and impulsive and do commit small bits, usually well tested. I do have more than one copy of the source and at least once recently checked in from the wrong copy. And scripts/python is new and presumably as yet unused so I don't see the harm in churn there. I've been able to build the system many times under Windows for quite a while, since around whenever scripts/win/* was commited. Over a year ago I think. I think self-buildability is a fairly good test already. Please let me know what the errors are. As for your code itself not working, well I can't promise as much and maybe you can't send it, but if you can provide source with problems I might be able to look into it. There was a problem bootstrapping from 5.2.6, since merely things weren't built in the right order, with the int64 work, but I fixed that a while ago. I haven't really touched the gui stuff. And the various gui apps do look very clunky, a bit hard to figure out how to use, and maybe flaky and unreliable. I guess I should try them on other systems. One thing I changed which should be discussed more is the entry code for .dlls. That's what the C/C++ interop question was about. I think where it is "wrong", you will get a link warning, but I didn't check that. It is "only" on the config file, though not sure that's a mitigating factor or not -- how much do people maintain local config files vs. take the checked in one and apply any diffs. The checked in Windows one is now designed to not need any diffs, so then saying people can change it is a bit hypocritical. So I guess I should remove that one line. I use mainly Windows but have Mac PowerPC and /maybe/ can commit to using others, like Linux PowerPC and other x86 systems (Solaris x86 anyone? :), Linux, FreeBSD, NetBSD)..gotta be a laptop though :) and VMware/VirtualPC are ok. (Nothing seems to compare in producitivity to merely older versions of Visual C++ (5.0, 6.0) and aggressive use of find in files, esp. because of the ease of keyboard use. I've been using "TextWrangler" on the Mac and it is ok but not as good, less keyboard accessible, annoying how each find-in-files opens a new window (even though VC can be annoying for lack of new windows there, usually not)..."kate" on Linux was ok, used it a bit, will try a bit more..) - Jay > To: rcoleburn at scires.com > Date: Wed, 2 Jan 2008 16:10:42 -0800 > From: mika at async.caltech.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] M3 concerns > > > I can happily volunteer FreeBSD 4.x and 5.x (i386) systems, Windows > 2000, and, I believe, Digital Unix 4.0 systems to run nightly > (daily?) builds. Unfortunately I am of course a bit short on Time, > which is probably what's lacking the most, anyhow... > > Mika > > "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. > > > >--=__Part103621A2.1__= > >Content-Type: text/plain; charset=US-ASCII > >Content-Transfer-Encoding: quoted-printable > > > >Tony: > >=20 > >I'm thinking that with a little work we could set up an automated set of = > >builds and regression tests that would make available a "scoreboard" via a = > >web interface where everyone could see the results. That way, as problems = > >are uncovered, folks could begin working on them. > >=20 > >For an example of how all this works, take a look at the scoreboard set up = > >for the ACE+TAO+CIAO projects. An overview is at http://www.dre.vanderbilt= > >.edu/Scoreboard/ . They provide instructions for setting up your own = > >daily build and scoreboard at https://svn.dre.vanderbilt.edu/viewvc/autobui= > >ld/trunk/README?revision=3DHEAD . You can see the scoreboard in operation = > >at http://remedy.nl/ . > >=20 > >Regards, > >Randy > > > >>>> Tony Hosking 1/2/2008 1:36 PM >>> > > > >On Jan 2, 2008, at 11:31 AM, Randy Coleburn wrote: > > > >> I've seen quite a number of m3commit and m3devel messages lately. =20 > >> Many of these give the appearance of "thinking out loud" with =20 > >> various commits followed by apparent reversals. In many cases the =20 > >> m3commit log messages are terse and don't give the rationale behind =20 > >> the change. > > > >Yes, I agree. Also, I tend to avoid committing multiple small =20 > >patches and rather defer until I have had a chance to test everything =20 > >and let it stabilize, before checking in as one single commit. So, =20 > >less frequent, coherent commits, are preferable to many smaller, =20 > >incoherent commits. > > > >> For those of us in the M3 community who rely upon the stability of =20 > >> the libraries and core M3 principles, these types of messages cause =20 > >> concern. While I appreciate everyone's efforts to move forward, I =20 > >> don't want to abandon the great care that went into formulating =20 > >> this language. > > > >Indeed. > > > >> Question: As various people make contributions and changes, is =20 > >> there any group of folks who is verifying that the changes don't =20 > >> break existing code or core principles? Another idea would be to =20 > >> have a series of test batteries that have to be passed before =20 > >> changes can be accepted. I know of a number of projects where many =20 > >> people contribute, but the contributions have to be vetted by =20 > >> passing some tests. > > > >I try to verify that all my code doesn't break existing code (though =20 > >I admit GC/thread subsystems can be devilish to completely verify). =20 > >We do need to have some sort of procedures in place for deciding what =20 > >commits make sense and should go into the CVS head. Tentative work =20 > >should always be done to a CVS branch until it can be vetted. > > > >> Without these types of controls, I fear that good forward progress =20 > >> will inevitably be hampered or compromised by changes made by =20 > >> someone who hasn't completely thought out and tested the =20 > >> ramifications of those changes. > > > >Agree! > > > >> For example, I've tried to get cm3 working for me on Windows XP =20 > >> several times. I still can't seem to get the "current" system to =20 > >> build correctly on XP. In the past, I have on occasion gotten the =20 > >> "system" to build, but then some of my programs don't work =20 > >> correctly when rebuilt using the new cm3. Thus, some changes =20 > >> somewhere have "broken" my code, yet all of my code uses the "safe" =20 > >> subset of the language. If I go back to my old reliable cm3 =20 > >> version 4.1 (the last one put out before Critical Mass, Inc. threw =20 > >> in the towel), my code compiles and works, even on Windows XP, even =20 > >> using Trestle, FormsVBT, NetObj, cross-platform pickles (e.g., =20 > >> pickles shared between Windows & Unix boxes), etc.! Much of my =20 > >> code was originally developed under Windows NT, so I think it is a =20 > >> tribute to the original language developers that my code and their =20 > >> compiler work through various OS version upgrades (NT, 2000, XP) =20 > >> and changes to the underlying C/C++ compilers used to build the =20 > >> core components. > > > >I thought we were getting closer to stability in this regard, though =20 > >I am not a heavy Windows user and have never built CM3 on Windows. > > > >> I would appreciate constructive feedback on this topic. > > > >It would be great to have a set of regression tests run on a regular =20 > >basis to ensure that checkins don't break things. What good =20 > >candidates do we have? cm3 itself I suppose. Any others? I can =20 > >probably devise a couple of thread and GC stress tests pretty =20 > >easily. Anyone willing to set up a testing regime? I have machines =20 > >that could be used to test on several supported platforms on a =20 > >nightly basis even. > > > >> > >> Regards, > >> Randy Coleburn > >> > >> > >> Randy C. Coleburn, CISSP > >> Senior Systems Engineer, Communications, Networks, & Electronics =20 > >> Division (CNE) > >> Corporate & Atlanta Information Systems Security Manager (ISSM) > >> Scientific Research Corporation > >> 2300 Windy Ridge Parkway, Suite 400 South, Atlanta, Georgia 30339 > >> voice: (770) 989-9464, email: RColeburn at SciRes.com, fax: (770) =20 > >> 989-9497 > >> > >> Quality Policy: "SRC CNE Division is committed to delivering =20 > >> continually improving research & engineering excellence that meets =20 > >> or exceeds customer requirements." > > > > > > > >--=__Part103621A2.1__= > >Content-Type: text/html; charset=US-ASCII > >Content-Transfer-Encoding: quoted-printable > >Content-Description: HTML > > > > > > >"> > > > > > >
Tony:
> >
 
> >
I'm thinking that with a little work we could set up an automated set = > >of builds and regression tests that would make available a "scoreboard" = > >via a web interface where everyone could see the results.  That way, = > >as problems are uncovered, folks could begin working on them.
> >
 
> >
For an example of how all this works, take a look at the scoreboard = > >set up for the ACE+TAO+CIAO projects.  An overview is at >tp://www.dre.vanderbilt.edu/Scoreboard/">http://www.dre.vanderbilt.edu/Scor= > >eboard/ .  They provide instructions for setting up your own = > >daily build and scoreboard at >wvc/autobuild/trunk/README?revision=3DHEAD">https://svn.dre.vanderbilt.edu/= > >viewvc/autobuild/trunk/README?revision=3DHEAD .  You can see = > >the scoreboard in operation at http://remedy.= > >nl/ .
> >
 
> >
Regards,
> >
Randy
> >

>>> Tony Hosking <hosking at cs.purdue.edu> 1/2/2008 = > >1:36 PM >>>

On Jan 2, 2008, at 11:31 AM, Randy Coleburn = > >wrote:

> I've seen quite a number of m3commit and m3devel = > >messages lately.  
> Many of these give the appearance of = > >"thinking out loud" with 
> various commits followed by = > >apparent reversals.  In many cases the 
> m3commit log = > >messages are terse and don't give the rationale behind 
> the = > >change.

Yes, I agree.  Also, I tend to avoid committing = > >multiple small 
patches and rather defer until I have had a = > >chance to test everything 
and let it stabilize, before checking = > >in as one single commit.   So, 
less frequent, coherent = > >commits, are preferable to many smaller, 
incoherent commits.
<= > >BR>>  For those of us in the M3 community who rely upon the = > >stability of 
> the libraries and core M3 principles, these = > >types of messages cause 
> concern.  While I appreciate = > >everyone's efforts to move forward, I 
> don't want to abandon = > >the great care that went into formulating 
> this language.
= > >
Indeed.

>  Question:  As various people make = > >contributions and changes, is 
> there any group of folks who = > >is verifying that the changes don't 
> break existing code or = > >core principles?  Another idea would be to 
> have a = > >series of test batteries that have to be passed before 
> = > >changes can be accepted.  I know of a number of projects where = > >many 
> people contribute, but the contributions have to be = > >vetted by 
> passing some tests.

I try to verify that = > >all my code doesn't break existing code (though 
I admit = > >GC/thread subsystems can be devilish to completely verify).   = > >
We do need to have some sort of procedures in place for deciding = > >what 
commits make sense and should go into the CVS head.  = > >Tentative work 
should always be done to a CVS branch until it = > >can be vetted.

>  Without these types of controls, I fear = > >that good forward progress 
> will inevitably be hampered or = > >compromised by changes made by 
> someone who hasn't completely= > > thought out and tested the 
> ramifications of those = > >changes.

Agree!

>  For example, I've tried to get = > >cm3 working for me on Windows XP 
> several times.  I = > >still can't seem to get the "current" system to 
> build = > >correctly on XP.  In the past, I have on occasion gotten the  = > >
> "system" to build, but then some of my programs don't work  = > >
> correctly when rebuilt using the new cm3.  Thus, some = > >changes 
> somewhere have "broken" my code, yet all of my code = > >uses the "safe" 
> subset of the language.  If I go back = > >to my old reliable cm3 
> version 4.1 (the last one put out = > >before Critical Mass, Inc. threw 
> in the towel), my code = > >compiles and works, even on Windows XP, even 
> using Trestle, = > >FormsVBT, NetObj, cross-platform pickles (e.g., 
> pickles = > >shared between Windows & Unix boxes), etc.!  Much of my  = > >
> code was originally developed under Windows NT, so I think it is = > >a 
> tribute to the original language developers that my code = > >and their 
> compiler work through various OS version upgrades = > >(NT, 2000, XP) 
> and changes to the underlying C/C++ = > >compilers used to build the 
> core components.

I = > >thought we were getting closer to stability in this regard, though  = > >
I am not a heavy Windows user and have never built CM3 on Windows.
<= > >BR>>  I would appreciate constructive feedback on this topic.
>R>It would be great to have a set of regression tests run on a regular = > >;
basis to ensure that checkins don't break things.  What = > >good 
candidates do we have?  cm3 itself I suppose.  = > >Any others?  I can 
probably devise a couple of thread and = > >GC stress tests pretty 
easily.  Anyone willing to set up a = > >testing regime? I have machines 
that could be used to test on = > >several supported platforms on a 
nightly basis even.

><= > >BR>> Regards,
> Randy Coleburn
>
>
> Randy C. = > >Coleburn, CISSP
> Senior Systems Engineer, Communications, Networks, = > >& Electronics 
> Division (CNE)
> Corporate & = > >Atlanta Information Systems Security Manager (ISSM)
> Scientific = > >Research Corporation
> 2300 Windy Ridge Parkway, Suite 400 South, = > >Atlanta, Georgia 30339
> voice: (770) 989-9464, email: RColeburn at SciR= > >es.com, fax: (770) 
> 989-9497
>
> Quality = > >Policy:  "SRC CNE Division is committed to delivering 
> = > >continually improving research & engineering excellence that meets = > >;
> or exceeds customer requirements."


>L> > > > >--=__Part103621A2.1__=-- _________________________________________________________________ Don't get caught with egg on your face. Play Chicktionary! http://club.live.com/chicktionary.aspx?icid=chick_wlhmtextlink1_dec -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Sat Jan 12 03:47:50 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 12 Jan 2008 02:47:50 -0000 Subject: [M3devel] I need CVS help again In-Reply-To: <20080112012216.k4d438pquc0sw8os@mail.elegosoft.com> References: <478807B4.2080100@wichita.edu> <20080112012216.k4d438pquc0sw8os@mail.elegosoft.com> Message-ID: [tangent as usual :)] I find the CVS usage model "ok", but I would like a choice of another one. I would like to know there is a conflict before it changes any of my files, or AT LEAST the ones with conflicts. And then I want to easily browse the conflicting changes, possibly applying them manually locally, so that CVS can do the merge automatically. In Perforce the way this works is it goes ahead and changes all the files with no merging at all to be done and then you have several choices for the merges and conflicts. You can accept the automatic ones, reviewing them or not before accepting them. For conflicts you can accept theirs or yours or bring up an editor with something like what CVS does, but you can also put it off a bit -- but can't commit (submit) before resolving. A missing or unclear thing though is if you can have it accept automatic merges within a file where possible, and then yours/theirs on the conflicts. Duh I just had a really obvious epiphany finally. I need to try out TortoiseCVS and its nearest competing Mac and Linux analogs. That'll probably make me much more satisified. :) (Reminder to any other folks to try the GUIs if they aren't experts with the command line.) TortoiseSVN has been nice to use for example. - Jay > Date: Sat, 12 Jan 2008 01:22:16 +0100> From: wagner at elegosoft.com> To: m3devel at elegosoft.com> Subject: Re: [M3devel] I need CVS help again> > Quoting "Rodney M. Bates" :> > > I have gotten myself into this jam before, as a result of trying to> > develop/test on more than one local machine with more than one M3> > installation. I have more questions on how to figure out what happened> > and how to fix it.> >> > I did a cvs update when, I guess, I had local uncommitted edits.> > I got messages saying that changes were being merged and there were> > conflicts. For example, I now have local files named:> >> > .#m3-eval.c.1.12> > m3-eval.c> >> > and in CVS/Entries, the line:> >> > /m3-eval.c/1.14/Result of merge...> >> > Have I correctly surmised that this all means> >> > 1) prior to the update, CVS/Entries would have said:> >> > /m3-eval/c/1.12...> >> > meaning 1.12 was the last version cvs knew I had,> >> > 2) But my local m3-eval.c had local changes relative to 1.12,> >> > 3) And .#m3-eval.c.1.12 is a copy of that locally changed> > m3-eval.c, as it was prior to the cvs update,> > Yes, this should be your original file.> > > 4) The latest version cvs has in its repository is 1.14, and> > Yes.> > > 5) My current local m3-eval.c was generated by merging version> > 1.14 from the repository with what is now in .#m3-eval.c.1.12?> > Yes.> You should simply find the comflicts in m3-eval.c by looking for> lines with <<<< and ===== and >>>>.> Often they are easy to edit manually.> > > Is there a simple way to get cvs to diff between its stored> > version 1.12 and my .#m3-eval.1.12?> > You can checkout any version into your workspace and compare locally:> > cvs up -p -r 1.12 m3-eval.c > m3-eval.c.1.12> cvs up -p -r 1.14 m3-eval.c > m3-eval.c.1.14> > diff -u .m3-eval.c.1.12 \#m3-eval.1.12> ...> > HTH,> > Olaf> -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194> _________________________________________________________________ Watch ?Cause Effect,? a show about real people making a real difference. http://im.live.com/Messenger/IM/MTV/?source=text_watchcause -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sun Jan 13 04:10:57 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 13 Jan 2008 03:10:57 -0000 Subject: [M3devel] could someone add __stdcall name mangling to m3cc please? In-Reply-To: References: Your message of "Wed, 09 Jan 2008 17:25:31 PST." <200801100131.m0A1VQYS034516@camembert.async.caltech.edu> <6D467648-44A7-48DC-AB8D-27B3AC19EBB0@cs.purdue.edu> <80BC3E7C-2DA6-4765-9053-A52950700404@cs.purdue.edu> Message-ID: <0FD0008E-575E-4362-8B78-A125EF9FFD07@cs.purdue.edu> Yup. On Jan 12, 2008, at 7:51 PM, Jay wrote: > > current_param_count > > Must this code use globals? > > - Jay > > > From: jayk123 at hotmail.com > To: hosking at cs.purdue.edu > CC: m3devel at elegosoft.com > Subject: RE: [M3devel] could someone add __stdcall name mangling to > m3cc please? > Date: Sun, 13 Jan 2008 00:49:10 +0000 > > I commited something LIKE this, that lets m3core.dll link. > (The below had several errors. Failing to loop, failing to > terminate the list correctly, only getting function pointers or > functions instead of both, for some reason the Windows *.i3 files > use a mix.) > > libm3.dll has a boring pathname format problem, ld doesn't like c: > \foo\../bar.lib and I got sidetracked.. > > It MIGHT not work for SOME functions, a link error -- if taking > __int64 or small structs by value, in a __stdcall function. > I'll see if that comes up as I progress through the system slowly. > > - Jay > > > > CC: m3devel at elegosoft.com > > From: hosking at cs.purdue.edu > > Subject: Re: [M3devel] could someone add __stdcall name mangling > to m3cc please? > > Date: Sat, 12 Jan 2008 19:06:35 -0500 > > To: jayk123 at hotmail.com > > > > It will need to be a little cleaner than that -- I'd rather gather > > the parameters as declared and enter them into the function type. It > > means not ignoring the parameter decls: see m3cg_declare_param check > > for current_param_count==0. To do this it needs to be a little bit > > smarter about managing current_function_decl -- probably a stack. > > > > On Jan 12, 2008, at 2:57 PM, Jay wrote: > > > > > Something like this????? > > > > > > > =================================================================== > > > RCS file: /usr/cvs/cm3/m3-sys/m3cc/gcc/gcc/m3cg/parse.c,v > > > retrieving revision 1.41 > > > diff -r1.41 parse.c > > > 3066a3070 > > > > tree atypes = NULL_TREE); > > > 3091c3095,3102 > > > < TREE_TYPE (p) = build_function_type (return_type, NULL_TREE); > > > --- > > > > /* for NT386 __stdcall, we just need to declare the right number > > > > of parameters > > > > */ > > > > if (--n_params== 0) { > > > > atypes = tree_cons (NULL_TREE, t_word, atypes); > > > > } > > > > > > > > TREE_TYPE (p) = build_function_type (return_type, atypes); > > > > > > haven't even compiled it yet.. > > > > > > - Jay > > > > > > > > > > > > > > > > > > > > > > From: jayk123 at hotmail.com > > > > To: hosking at cs.purdue.edu > > > > Date: Sat, 12 Jan 2008 18:13:27 +0000 > > > > CC: m3devel at elegosoft.com > > > > Subject: Re: [M3devel] could someone add __stdcall name mangling > > > to m3cc please? > > > > > > > > Tony, Sorry, I didn't mean to check those in. Those were wild > > > guesses that I hadn't tested yet.I put it back. Thanks for > catching > > > that. > > > > > > > > - Jay > > > > > > > > > > > > > > > > > CC: m3devel at elegosoft.com> From: hosking at cs.purdue.edu> > > > Subject: Re: [M3devel] could someone add __stdcall name > mangling to > > > m3cc please?> Date: Sat, 12 Jan 2008 10:41:26 -0500> To: > > > jayk123 at hotmail.com> > I'm not sure what you were trying to do > with > > > parse.c by adding a > parameter (nargs*4) to the stdcall > attribute, > > > but that probably > doesn't do anything interesting. The problem > > > appears to be because > on external function decls the parameter > > > decls are currently being > ignored by cm3cg. If I fix parse.c to > > > add the params for those then > it should work properly with the > > > stdcall attribute.> > On Jan 12, 2008, at 8:27 AM, Jay wrote:> > > > > > Thanks, but not quite. The number of parameters times four > needs to > > > > > be appended to the name, in decimal.> > But I'm just getting > > > 0.> > That is, gcc is handling the underlying detail, but you > > > aren't > > giving it enough infomrmation.> > I'll see if I can > bang > > > out those temporary wrappers automatically.. > > (a Quake > > > programming challenge, that I've already invented the hard > > > part > > > of I think -- Quake can't do math..)> >> > - Jay> >> >> > > CC: > > > m3devel at elegosoft.com> > > From: hosking at cs.purdue.edu> > > > > > Subject: Re: [M3devel] could someone add __stdcall name mangling > > > > > to m3cc please?> > > Date: Fri, 11 Jan 2008 13:16:44 -0500> > > > > > To: jayk123 at hotmail.com> > >> > > I just added support for this. > > > Let me know if it seems to work (or> > > not! :-) ).> > >> > >> > > > > > > On Jan 10, 2008, at 7:40 AM, Jay wrote:> > >> > > > Could someone > > > out there (Tony?) familiar with the gcc backend> > > > have it not > > > ignore call_conv and if call_conv is 1, append> > > > an at symbol > > > and the number of bytes of parameters to the function> > > > > name?> > > > > > > (Even for zero, e.g. Sleep at 0, GetFileAttributes at 4).> > > > > > > This would be I guess at least for "imported" functions.> > > >> > > > > > > Not clear about calling function pointers, probably needs> > > > > > > modification.> > > > call_conv 0 is "__cdecl" is push right to > > > left, caller cleans up> > > > call_conv 1 is "__stdcall" is push > > > right to left, callee cleans up> > > > There are various > synonyms.> > > > > > > With no command line switches, __cdecl is the compiler > > > default.> > > > __stdcall is deemed more efficient, and is very > > > widely used.> > > >> > > > Not clear about functions > implemented in > > > Modula-3.> > > > Probably won't occur? Maybe for callbacks? > > > WindowProcs, thread> > > > entry point?> > > >> > > > This could/ > > > should be for NT386GNU only.> > > > The hypothetical other NT > > > targets only have one calling convention> > > > each.> > > >> > > > > > > > I COULD do something sleazy here and generate little adapter> > > > > > > > functions, over in m3-win/import-libs esp.> > > >> > > > I'm still > > > checking out pm3 to see what it does here.> > > > (as in cvs > > > checkout, not "looking at")> > > >> > > > This'll clear up:> > > > >> > > > > > > RTOS.m3:27: undefined reference to `_FatalExit'> > > > > > > RTOS.mo: In function `RTOS__GetMemory':> > > > RTOS.m3:75: > > > undefined reference to `_VirtualAlloc'> > > > RTOS.m3:85: > undefined > > > reference to `_VirtualAlloc'> > > > RTOS.mo: In function > > > `RTOS__InitMemory':> > > > RTOS.m3:96: undefined reference to > > > `_VirtualAlloc'> > > > RTOS.m3:100: undefined reference to > > > `_GetSystemInfo'> > > > RTOS.mo: In function `RTOS__Write':> > > > > > > RTOS.m3:118: undefined reference to `_AllocConsole'> > > > > > > RTOS.m3:119: undefined reference to `_GetStdHandle'> > > > > > > RTOS.m3:122: undefined reference to `_WriteFile'> > > > > > > RTPerfTool.mo: In function `RTPerfTool__Start':> > > > > > > RTPerfTool.m3:19: undefined reference to `_ReadFile'> > > > > > > RTPerfTool.m3:22: undefined reference to `_CloseHandle'> > > > > > > RTPerfTool.mo: In function `RTPerfTool__Close':> > > > > > > RTPerfTool.m3:28: undefined reference to `_CloseHandle'> > > > > > > RTPerfTool.mo: In function `RTPerfTool__Send':> > > > > > > RTPerfTool.m3:34: undefined reference to `_WriteFile'> > > > > > > RTPerfTool.mo: In function `RTPerfTool__PrepHandle':> > > > > > > RTPerfTool.m3:58: undefined reference to `_GetCurrentProcess'> > > > > > > RTPerfTool.m3:59: undefined reference to `_DuplicateHandle'> > > > > > > etc.> > > >> > > > I did think I was past these. I thought I > > > built m3core and libm3> > > > including linking (having even > > > modified cm3.cfg)> > > > COULD be I'm using the wrong .libs, but:> > > > > > >> > > > C:\cygwin\lib\w32api>nm libkernel32.a | findstr > > > CreateFile> > > > 00000000 I __imp__CreateFileW at 28> > > > 00000000 > > > T _CreateFileW at 28> > > > 00000000 I > __imp__CreateFileMappingW at 24> > > > > > > 00000000 T _CreateFileMappingW at 24> > > > 00000000 I > > > __imp__CreateFileMappingA at 24> > > > 00000000 T > > > _CreateFileMappingA at 24> > > > 00000000 I __imp__CreateFileA at 28> > > > > > > > 00000000 T _CreateFileA at 28> > > >> > > > C:\cygwin\lib\w32api>cd > > > \MinGW\lib> > > >> > > > C:\MinGW\lib>nm libkernel32.a | findstr > > > CreateFile> > > > 00000000 I __imp__CreateFileW at 28> > > > 00000000 > > > T _CreateFileW at 28> > > > 00000000 I > __imp__CreateFileMappingW at 24> > > > > > > 00000000 T _CreateFileMappingW at 24> > > > 00000000 I > > > __imp__CreateFileMappingA at 24> > > > 00000000 T > > > _CreateFileMappingA at 24> > > > 00000000 I __imp__CreateFileA at 28> > > > > > > > 00000000 T _CreateFileA at 28> > > >> > > > I think at least THREE > > > calling conventions should be supported --> > > > __cdecl, > > > __stdcall, __fastcall --> > > > but oh well. We can live without > > > __fastcall.> > > > Watcom has another calling convention, > > > "watcall", and they let you> > > > describe calling conventions > > > with #pragmas, neat.> > > >> > > > Thanks,> > > > - Jay> > > >> > > > > > > > Share life as it happens with the new Windows Live. Start > sharing! > > > > > >> >> >> > Make distant family not so distant with Windows > > > Vista? + Windows > > Live?. Start now!> > > > > > _________________________________________________________________ > > > > Watch ?Cause Effect,? a show about real people making a real > > > difference > > > > > > > > > Get the power of Windows + Web with the new Windows Live. Get > it now! > > > > > Watch ?Cause Effect,? a show about real people making a real > difference. Learn more > Watch ?Cause Effect,? a show about real people making a real > difference. Learn more From jayk123 at hotmail.com Wed Jan 16 04:29:40 2008 From: jayk123 at hotmail.com (Jay) Date: Wed, 16 Jan 2008 03:29:40 -0000 Subject: [M3devel] "crazy cross" In-Reply-To: <1DDFAB54-77B6-4593-B309-2C767D4F1FAC@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> <1DDFAB54-77B6-4593-B309-2C767D4F1FAC@cs.purdue.edu> Message-ID: Yeah, but many small bits of string are hard to put together into a useful ball. :) Platitude (I think is the word): Finding the right balance can be difficult, and it is neither one extreme nor the other. I don't like having to search so many different directories and files, I like more stuff readily at hand. And layering so many things together..do-cm3-std calls do-pkg calls syinfo calls cm3 can also be confusing, at least at first, but once known, I guess not, whereas smushed together code can remain confusing to maintain longer term. I'm the odd one out here though. I'd rather the current liberal BSD-ish licenses. I think multithreading would be good. I'm leary of what functionality is in cm3 vs. above. I think more should be in it. I actually like a model where you cd around and run some command it builds from the current directory and on down. But possibly escaping that part of the tree to rebuild dependencies, if they are out of date. Currently we have two choices: cd around to specific packages and run cmd cd to the specific scripts directory and do-pkg a specific list Kind of not not ideal somehow. Maybe all I really want is do-pkg to leave the cm3 command line options -- the local defines -- in its callers environment somehow for cm3 to pickup. So run do-pkg env and then cd around and run cm3. Anyway, much more bugs me than is important and these things are by far not the most important. I'd be happier merely to have quake provide move_file. :) And for it to batch up compilation of C perhaps. But then I get creedy and want to batch up cm3cg runs..back to where I was.. :) So -- dynamic linking is where people draw the line, but not one process running another? That seems dubious. Debugging-wise, there is this issue of "entry points". Where can I easily stop and resume? You are referring to cm3 outputs .ic (I think it is) files and then cm3cg can be run over them, easily, independently, without starting the pipeline all the way back before Modula-3 parsing. The entry points remain in the shipping product/configuration, even though they are "never" taken advantage of there..even if cm3 doesn't run cm3cg, the cost of mapping in a larger executable in a demand-paged environment is neglible, except as it pulls in dependencies on additional .dlls/.sos, though I expect (I will check), cm3cg's dependencies are light and a subset or equal to cm3's, so that's zero. I don't have an answer here, debugging entry points vs. optimized runtime. Debuggability and performance are very often open opposing forces (see the static_link thread :) ) Sometimes you can have the debug path as an option and the perf path by default, but of course, every fork, every if, (every conditional branch, conditional move (x86), predicated instruction (IA64) -- though I guess sometimes the conditions are the same) is another multiplication out of test cases and inevitably reduced coverage. - Jay > CC: m3devel at elegosoft.com> From: hosking at cs.purdue.edu> Subject: Re: [M3devel] "crazy cross"> Date: Tue, 15 Jan 2008 18:51:44 -0500> To: jayk123 at hotmail.com> > > On Jan 15, 2008, at 6:24 PM, Jay wrote:> > >> > I forgot some vaguely related things.> >> > Do people worry about optimizing away creating new processes?> > Perhaps.> > > Could m3cg be built as an .so/.dll? Probably.> > Tricky given gcc's nature.> > But, m3middle could be glued to gcc to build gcc's trees > directly...though I strongly prefer the current arrangement.> > > And ok license-wise?> > Um, no. FSF have been generally opposed to the way the Modula-3 > backend is a thin front-end veneer over gcc, since we get to use > their compiler without infecting M3 with the GPL/LGPL. Of course, it > would probably be preferable to have CM3 under the GPL/LGPL> > > Could m3cg be run once per package instead of once per source?> > Possibly, though right now m3cg does not use the gcc front-end > driver. To be honest, I prefer the separation of concerns between > m3middle and the gcc-based backend. It is much easier for debugging > and development.> > > gcc and cl both can be:> > cl -c foo.c bar.c> > gcc -c foo.c bar.c> > Currently in NT386GNU I depend on -o,> > gcc -c foo.c -o foo.obj> > Would need to handle that, not a big deal.> >> > Also, in the scheme below, either cm3.sh/cm3.cmd would have a > > switch to merely print the "real" cm3's path, or, just as well, > > sysinfo.sh et. al. would know how to find it, save that process.> >> > Furthermore -- multithreaded build?> >> > I believe, maybe absent bootstrapping, that cm3 could read "all" > > the m3makefiles, work out the dependency graph trivially, and build > > things in parallel. Bootstrappinging works too. It builds only what > > you say, in the right order. The Python scripts can implement this > > easily enough.> > I would strongly prefer to see functionality remain decomposed as it > currently is. Tangled balls of string are tough to understand, > maintain, and develop.> > >> > - Jay> >> > ----------------------------------------> >> CC: m3devel at elegosoft.com> >> From: hosking at cs.purdue.edu> >> Subject: Re: [M3devel] "crazy cross"> >> Date: Tue, 15 Jan 2008 08:47:13 -0500> >> To: jayk123 at hotmail.com> >>> >>> >> On Jan 15, 2008, at 2:00 AM, Jay wrote:> >>> >>> It looks like at least cm3 is "always" target-independent.> >>> Whatever target is defined to in cm3.cfg, if it is one of the built> >>> in known ones, cm3 will generate code for. Except maybe NT386,> >>> though it need not be -- cm3 could have both the .obj and "gcc> >>> tree" writing backends both linked into it and dynamically chose> >>> between them.> >>> >> Yes, the cm3 front-end will generate .mo/.io files for any target on> >> any other host. The gcc-based backend runs as a separate process> >> (there are license issues with linking the gcc-based backend directly> >> with the front-end).> >>> >>> Maybe it already does.> >>> cm3 operates at a fairly high level when using gcc, and the target> >>> specific stuff is just some data about the name of setjmp, the> >>> sizeof jmp_buf, etc..> >>>> >>> The "only" "problem" is then m3cg/as/ld/link.> >>> m3cg could be moved to $CM3_INSTALL/pkg/x/HOST/TARGET.> >>> >> True!> >>> >>> cm3, along with everything else, could be $CM3_INSTALL/pkg/x/HOST> >>> leaving $CM3_INSTALL/bin/cm3 that is sh and $CM3_INSTALL/bin/cm3.py> >>> or cm3.cmd that calls out to cm3.> >>> >> Possibly.> >>> >>> "Fixing" as/ld, well, I don't suppose they tend to be target> >>> neutral do they? You'd have to import them like gcc and build them> >>> n times. Gaining a much slower build, much larger tree.> >>> >> Indeed.> >>> >>> I suppose anyone could do this themselves, and change cm3.cfg> >>> appropriately. Doing things "officially" this way for one "big"> >>> distribution, probably folks would not go for.> >>> >> This is how bootstraps to other targets typically go: cm3 *.m3-> >>> *.mo. Copy .mo files to target. Build cm3cg for target. cm3cg> >> *.mo->*.ms as *.ms->*.o ld *.o->libs/execs.> >>> >>> >>>> >>>> >>> - Jay> >>>> >>>> >>>> >>> From: jayk123 at hotmail.com> >>> To: m3devel at elegosoft.com> >>> Subject: "crazy cross"> >>> Date: Sat, 5 Jan 2008 01:22:13 +0000> >>>> >>> You've all heard of "Canadian cross"?> >>>> >>> It is cross-building a cross-compiler.> >>> I'm sitting in Windows. I'm going to build a compiler that is going> >>> to run on Linux that is going to target Solaris.> >>> For one example.> >>>> >>> You've all seen that Apple has switches like so:> >>>> >>> gcc -arch i386 ppc ppc64 x86_64 hello.c> >>> and poof out comes a binary that runs natively on four architectures> >>>> >>> I don't like the "inconvenience" of non cross systems and having to> >>> have all the machines/OSes just to build the binaries.> >>> I realize that you hit the wall if you actually want to test the> >>> results. So cross building only gets so much.> >>> Of course I also don't want to multiply out build times for tools...> >>>> >>> Ok, well what is the possibility of:> >>>> >>> cm3 -target NT386> >>> cm3 -target NT386 -target PPC_DARWIN> >>>> >>> ? In my crazy imagination, you have:> >>>> >>> \cm3\bin\cm3.cmd> >>> %~dp0..\libexec\%processor_architecture%\%TARGET%\cm3.exe %*> >>>> >>> \cm3\bin\cm3> >>> #!/bin/sh> >>> dirname(dirname($0))/libexec/`uname whatever`/$TARGET/cm3 $@> >>>> >>> Thus it becomes POSSIBLE to have an n x m matrix, host x target,> >>> and be able to build> >>> "anything" from one environment.> >>>> >>> Actually the targets could all be merged into one .exe or> >>> be .dll/.sos.> >>> Except the code isn't setup for that.> >>>> >>> Interesting?> >>>> >>> I guess the hard part is the C code and linking?> >>> The Modula-3 stuff is already setup to do most of this?> >>> (partly by virtue of all that header rewriting that I labeled> >>> sleazy)> >>>> >>> - Jay> >>>> >>>> >>>> >>> Share life as it happens with the new Windows Live. Start sharing!> >>>> >>> Share life as it happens with the new Windows Live. Start sharing!> >>> >> > _________________________________________________________________> > Watch ?Cause Effect,? a show about real people making a real > > difference.> > http://im.live.com/Messenger/IM/MTV/?source=text_watchcause> _________________________________________________________________ Watch ?Cause Effect,? a show about real people making a real difference. http://im.live.com/Messenger/IM/MTV/?source=text_watchcause -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Wed Jan 23 03:45:43 2008 From: jayk123 at hotmail.com (Jay) Date: Wed, 23 Jan 2008 02:45:43 -0000 Subject: [M3devel] platform/build_dir is a big tuple? In-Reply-To: <2AB0D273-C3B8-4D46-BCC1-4D032692DCB0@cs.purdue.edu> References: <20080122142922.k73w5es5j4gckso4@mail.elegosoft.com> <2AB0D273-C3B8-4D46-BCC1-4D032692DCB0@cs.purdue.edu> Message-ID: Two of the types are dead and the calling convention doesn't matter. If the function has any parameters, a LOOPHOLE is needed, if it has no pararemeters, as the types are declared, the calling convention has no affect. So fixing the warnings are trivial and will be done momentarily. - Jay From: jayk123 at hotmail.comTo: hosking at cs.purdue.edu; wagner at elegosoft.comCC: m3devel at elegosoft.comSubject: RE: [M3devel] platform/build_dir is a big tuple?Date: Wed, 23 Jan 2008 02:25:39 +0000 > Precisely why I don't like many of the recent changes. I don't want > to build Windows interfaces and gorp for a non-Windows platform. It is *just* types. (I didn't read the code entirely, but it appears so).Other than the three or so types marked WINAPI, which I could see about moving/removing,*types* work fine across architectures.You could produce and consume these types in pure Modula-3 on any platform.That kernel32.dll happens to traffic in them is just coincidence.Except maybe those function pointer types with WINAPI.What's wrong with that?As long as I can fix the warnings I think these should say.Not that there aren't lots of warnings in the build already, but I don't like having any. - Jay > From: hosking at cs.purdue.edu> Date: Tue, 22 Jan 2008 12:54:04 -0500> To: wagner at elegosoft.com> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] platform/build_dir is a big tuple?> > > On Jan 22, 2008, at 8:29 AM, Olaf Wagner wrote:> > > All this may be useful during development, but it is not really> > useful for a software distribution to our users, I think.> >> > Nobody will understand it :-( We need to keep things more simple.> >> > We don't need to support everything out of the box. Instead, we should> > offer some sensible default combinations of everyhing you describe.> >> > First of all: we don't distribute cross compilers (at least until > > now).> > This is a special topic reserved for adding new platforms.> > Precisely why I don't like many of the recent changes. I don't want > to build Windows interfaces and gorp for a non-Windows platform. > Jay, can you *please* back these changes out?> > >> > Runtime and compilers used do not necessarily need to be distinguished> > by target or build dir, in many cases different cm3.cfg may suffice.> >> > Until now, threading models are also no choice that needs to be> > visible at this level. There's one default model for every target,> > and the user can change it by recompiling.> >> > And if we should really agree that changing the target naming scheme> > is a good idea, we should> >> > o use a systematic one with not more than 4 elements (better still,> > 3 (e.g. --))> > o don't use cryptic abbreviations that will confuse most people> >> > Just my 2 cents,> >> > Olaf> >> > Quoting Jay :> >> I'm still torn over that any NT386 target could have a choice of > >> three threading models (win32, pthread, vtalarm), two windowing > >> libraries (ms, x), two (three) compilers (ms, mingwin, cygwin), > >> two (three) linkers (ms, mingwn, cygwin), various runtimes (msvc > >> various versions, cygwin, mingwin (discouraged)) etc.> >>> >> Appending a short string of unreadable bits to BUILD_DIR is very > >> temptingin order to easily generate and test the combinatorial > >> possibilities.> >>> >> backend: 0 integrated, 1 gcc already a setting (with four values)> >>> >> ccompiler/linker: 0 ms, 1 gcc (these could be split, and could > >> allocate more bits...) maybe 00 ms, 01 cygwin, 10 ming maybe > >> define enum up front that allows for watcom, metrowerks, > >> digitalmars, llvm etc.> >> maybe use a decimal digit for all these, and 0 is reserved, maybe.> >>> >> threading: 0 win32, 1 pthreads drop vtalarm, or use two bits?> >>> >> windowing: 0 ms, 1 x> >>> >> cruntime: 0 ms, 1 cyg There is also a ming runtime, discouraged > >> There also really N ms runtimes, ming offers several: > >> msvcrt.dll, msvcr70.dll, msvcr71.dll, msvcr80.dll, > >> msvcr90.dll... but jmpbuf presumbly doesn't change again could > >> allocate multiple bits..> >>> >> cruntime I guess determines oSTYPE Win32 or Posix, thoughit loses > >> its meaning mostly, and X vs. not-X is usually decide the same...> >>> >> The three most common combinations: 00000 -- NT386 11111 -- > >> NT386GNU 11000 -- NT386MINGNU> >>> >> but several others would work 11101 -- cygwin with native > >> windowing 11011 -- cygwin with native threads 11001 -- cygwin > >> with native threads and native windowing> >> BUILD_DIR would be NT386-$(config)as a special case perhaps, the > >> three commoncases could be translated to the above strings.> >>> >> But the underlying implementation would be a few bools/enums,and > >> iterating through them would be easy, while special casingand > >> skipping deemed invalid combinations, like ms runtime and > >> pthreads,and possibly ms runtime and x windows.> >> Really, it might surprise folks, but really, basically every > >> single combination works.> >> Compilers are very independent of headers and libs and headers > >> and libs are very independent of compilers, aside from a few > >> language extensions like __stdcall. You can generally mix > >> runtimes in the same process, just as you can mix them on the > >> same machine, you just need to be careful about what you pass to > >> what. If you call fopen, be sure pass the result back to the > >> matching fclose, malloc/free, etc. Startup code, to the extent > >> that it matters, might be a problem, but really, just avoid C++ > >> globals with constructors/destructors anyway, they are always a > >> problem. Modula-3 has its own startup code, and if you were to > >> write "main" in C and link in Modula-3 static .libs, that > >> probably doesn't work...might actually be better to play into > >> whatever the platform's C++ constructor story is, as problematic > >> as they (probably always?) are -- i.e. unpredictable/hard-to- > >> control ordering.> >>> >> (bad editing...and maybe use hex for compression..)> >>> >> Bringing back cminstall is almost interesting, to promptthe user, > >> or probe their system, though Quake/cm3 can probe at runtime.if > >> os == windows_nt system_cc | findstr version | findstr gcc > >> else system_cc | findstr visual c++else system_cc | grep > >> version | grep gcc else system_cc | grep visual c++end> >>> >> inefficient.> >>> >> anyway, I'll merge current NT386GNU into NT386 and make it > >> chosehow to compile/link which are the main variables today.> >> and then decide about cygwin, but probably do like the above, > >> sinceit'll totally share code with NT386 except the naming > >> conventionsand the removal of the -mno-cygwin switch..> >>> >> I know this seems overly complicated, but it should be > >> exposableeasily enough to users by hiding the choices, presenting > >> three basic ones,and still allow all the obvious and perhaps > >> useful knobs, and iterating throughthe combinations, without > >> creating a combinatorial explosion of source filesor Modula-3 or > >> Quake code.> >> ...Jay> >>> >>> >> From: jayk123 at hotmail.comTo: m3devel at elegosoft.comDate: Tue, 22 > >> Jan 2008 10:48:56 +0000Subject: Re: [M3devel] platform/build_dir > >> is a big tuple?> >>> >>> >> Final answer? I played around with this but just can't accept > >> platforms/build_dirs like: ntx86msmsmscm3msn > >> ntx86gccgcccm3cgmsn ntx86gccgcccm3cgxn ntx86-gggggmn ntx86- > >> ggixn ntx86_mmmimmOk, I have one more name here, and then a bit > >> of a change, or a stronger statement of something I had already > >> said.NT386MINGNUOk, I think we (me!) are confusing host and > >> target, MOSTLY.And cm3 might not have them quite divided > >> appropriately.What is a "host"? What is a "target"?MinGWin and > >> Visual C++ output similar results, targetingthe same runtime > >> (usually), threading library, windowing library.There is a chance > >> for exception handling to diverge however.Well, speaking of > >> Visual C++ the C/C++ compiler and MinGWinthe gcc environment, > >> yes, very different, not interoperable.MinGWin uses what gcc > >> calls "sjlj" -- setjmp/longjmp exceptions.Very inefficient. But > >> heck, gcc doesn't support __try/__except/__finally,only C++ > >> exceptions, and interop of C++ is often not great,what with name > >> mangling and all.NT386GNU's OUTPUT uses a different runtime, > >> unless you trim dependencies, possibly a different threading > >> library, possibly a different windowing library. All this > >> probably configurable. Again exception handling is a sore point > >> in that it is the primary C runtime dependency of Modula-3. If > >> you use Cygwin but say -mno-cygwin, that means you are targeting > >> NT386. (and don't use pthreads or X Windows; behavior of > >> exceptions/setjmp/longjmp TBD -- really, need to not use the - > >> mno-cygwin headers in that case; I'll check).Perhaps m3core.dll > >> should export m3_setjmp/m3_longjmp..Either one can do a cross > >> build to the other.Two cm3.exes, two sets of outputs, that either > >> can produce.NT386 can use gcc or the integrated backend. And the > >> gcc it uses can be MinGWin or Cygwin. (theoretically and probably > >> soon reality) NT386GNU can use either as well! (also currently > >> theory, but a real possibility) It isn't GNU tools, it is GNU > >> runtime.One small area with cm3 might fall down just slightly is > >> that of cross builds where host and target have different > >> naming conventions. -lfoo vs. foo.lib, foo.o vs. foo.obj are an > >> aspect of the host and I vaguely recall that cm3 ties naming > >> convention to ostype. The appending of .exe is a target > >> characteristics, but the others are not really. Naming > >> convention is really a host thing and not a target thing.The > >> config files are a mix of host and target information, mostly > >> actually host, except for the one line that says TARGET. Most of > >> the target variation is in cm3, which always can do any, and > >> cm3cg (which might be nice to be similar, but that's another > >> matter and not likely to ever change, except when AMD64 is the > >> last architecture standing. :) )If Windows had "rpath", then SL > >> would be split between HOST_SL and TARGET_SL.As it stands, SL is > >> HOST_SL.Consider as well the various versions of Visual C++.They > >> output mostly the same, very interoperable.Consider optimization > >> switches. Host or target?Consider version of gcc or Visual C++? > >> Host or target?Well, inevitably, the host has an affect on the > >> target. If not the for the host, the target would not even > >> exist. Bugs in the host produce bugs in the target. etc.(And > >> realize that Cygwin runs on top of an OS built witha Microsoft > >> compiler, so really there is interop, but sometimes through a > >> layer.) So there's a risk of saying there is six+ combinations. > >> (host cygwin, host mingwin, host native) x (target nt386, target > >> nt386gnu) But generally the host is assumed not a factor. I > >> guess "LIBC" could be seperated into several options...You could > >> actually have code that needs one runtime or another, and they > >> couldlink together, depending on what they do.. This is something > >> I don't know if cm3 handles, or anything I have seen. I should be > >> able to build a static .lib, that includes some C code, that > >> imbues its clients with build time dependencies. Well, I guess > >> #pragma comment(linker) is this.So the next tasks are roughly: > >> Merge my NT386 and NT386GNU files. Switching on a variable such > >> as backend mode. Introduce a "new" (old) NT386GNU file, > >> perhaps more like what was already there. Change NT386GNU back > >> to Posix. Build NT386GNU. oh, one more point...while these are > >> two targets from cm3's point of view, they are PROBABLY the same > >> target to cm3cgand so only one is needed. I have to check if > >> configure differentiates between i686-pc-cygwin and i686-pc- > >> mingwin...but I guess it should...It might actually be profitable > >> to have two bloated cm3cg.exe's.And they should ship to \cm3\pkg > >> \m3cc\target\host or host\target and cm3 should know which to > >> run.Blech..four of them when one would suffice?The detail being > >> mainly what the paths to .libs look like, unfortunate.Possibly > >> cm3 can bridge this gap using that "broken" feature that symlinks > >> libs into the target directory,using NTFS hard links, if > >> installroot and root are on the same volume... (or symlinks on > >> Vista).Or maybe convert the paths as appropriate, hacky, but > >> saves an extra cm3cg.exe which is good to avoid. (all the more > >> reason to lump all targets into one file, so that the host x > >> target matrix collapses to just one axis, host; andthen you can > >> write stuff in Perl/Python/Java/C# to collapse that to just one, > >> except for the underlying runtime/interpreter...) Oh, cm3cg isn't > >> the issue. It is always sitting in the correct directory and > >> reads one file and writes one file, no slashes.The issue is gcc > >> as the linker. Again, this is a host issue..and cm3 or the config > >> file definitely should do the translation. - Jay> >>> >>> >> From: jayk123 at hotmail.comTo: m3devel at elegosoft.comDate: Mon, 21 > >> Jan 2008 23:01:44 +0000Subject: [M3devel] platform/build_dir is a > >> big tuple?> >>> >> 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> >> >> >> > -- > > Olaf Wagner -- elego Software Solutions GmbH> > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, > > Germany> > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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". 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 Sun Jan 20 04:42:02 2008 From: mika at async.caltech.edu (Mika Nystrom) Date: Sun, 20 Jan 2008 03:42:02 -0000 Subject: [M3devel] pixmap problem In-Reply-To: Your message of "Sat, 19 Jan 2008 17:54:00 +0100." <235688.77597.qm@web27110.mail.ukl.yahoo.com> Message-ID: <200801200341.m0K3feKM023564@camembert.async.caltech.edu> It works great on NT386GNU, PM3/Klagenfurt, as well, without the build_standalone. Mika "Daniel Alejandro Benavides D." writes: >--0-1095273535-1200761640=:77597 >Content-Type: text/plain; charset=iso-8859-1 >Content-Transfer-Encoding: 8bit > >Hi: >The TestPixmap does show a nice battery on LINUXLIBC6, Ubuntu Gutsy 2.6.22-14-386, 32 bits machine. > >Thanks > > >Jay wrote: .hmmessage P { margin:0px; padding:0px } body.hmmessage { FONT-SIZE: 10pt; FONT-FAMILY:Tahoma } I can repro > the two different behaviors on XP. > I was going to try on PPC_DARWIN but I guess Tony's info suffices. > > I tried rolling hand.c back to before I changed (months/year ago), since it is involved in bit twiddling, no change, phew. > > Debugging here is a big humungous pain. > NT386 has good stacks and line numbers, but no locals or type info, I'd really sometime like to get Codeview info into those .objs...I think it > is documented well enough, but still not necessarily easy, or maybe have a C generating backend partly for this reason (and to bring up more ta >rgets, using native tools), and function calls in disassembly I think don't resolve; NT386GNU can't yet build this, though it will soon, but I'm > not familiar with gdb and there appears to be no type info. I'm building m3gdb right now, I don't know if it will work, I hope it has type info >, and I'm not familiar with the relevant code. In gdb I struggle just to view bytes in memory, add numbers to addresses and see those, etc. I th >ink for MY problem, I'm going to link in C code to dump the structs. There is tracing code and I enabled it, but even it crashes in Text_Length. > At least MY problem crashes, hopefully near the problem, whereas your problem goes all the way through to completion with > no stopping to hint where the problem is. Darn it. :) on the mock rudeness and :( on the lack of a crash. > > You write the bundle out and it matches, so that doesn't rule out bundles as being the problem? (darn) > And bundles look pretty simple, a bundle is just a generated source file with a constant in it. > Maybe newline problems? That wouldn't make sense. I just downloaded some program that might let me separately view the ppm, maybe it'll reveal >something. > > The bad behavior has like regularly spaced solid color veritical bars a few pixels side across the whole picture, and regularly spaced vertical > stripes from the correct picture alternating with that. Perhaps someone with ppm/bitmap/graphics experience has seen this behavior and it resul >ts from some common pixmap mismanagement we could look for? > > I have to say this is very surprising. > > I always wondered, and now I pretty much assume -- Modula-3 never imports/exports data in its dynamic linking, right? It alway imports/exports >functions, right? > On Windows, functions have an optional optimization, but data must be handled differently at compile time if it is going to be dynamically impo >rted. > For functions, if you don't apply the optimization at compile time, the linker will just generate a single instruction thunk instead. > > That is, given a symbol Foo, there is a symbol __imp__Foo that is a pointer to the actual foo in another .dll/.so. > The loader only patches pointers, one per import if you build your .dll correctly, it doesn't patch instructions or code strewn throughout a .d >ll, just one contiguous array of pointers. MAYBE they don't have to be contiguous for each .dl you import from. > > That is, if call msvcrt!fopen, msvcrt!fclose, kernel32!Sleep, my .dll/.exe typically has an array: > > pointer to msvcrt!fopen > pointer to msvcrt!fclose > null > pointer to kernel32!Sleep > > But perhaps kernel32.dll's pointers and msvcrt.dll's pointers need not be adjacent. > > So, going back, my point/question is that, if the compiler knows the function is imported, it can call through __imp__Foo instead of calling Fo >o. > But if it calls Foo and you import Foo, the linker will create the function Foo that just jmps through __imp__Foo. > That doesn't work for data though. There's no ability to intervenve like that. > So for imported data, the compiler must generated a read and dereference of the pointer __imp__Foo for accesses to Foo, if Foo is to be importe >d. > Data imports may be faster when appropriate, but for this reason, I'd say they aren't worth it. > And for this reason, I HOPE Modula-3 never imports/exports data. > > Oh, you could, for data, always reference the pointer __imp_Foo, and if non materializes, create one. > However that would suck perf in order to make an uncommon case work. > I hope Modula-3 doesn't do that either. :) > Though I guess since this global data in question...maybe it is rare??? > > Later, > - Jay > > > >--------------------------------- > > > From: hosking at cs.purdue.edu >> Date: Sat, 19 Jan 2008 03:09:47 -0500 >> To: rcoleburn at scires.com >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] pixmap problem >> >> Looks fine to me on I386_DARWIN. >> >> On Jan 19, 2008, at 12:31 AM, Randy Coleburn wrote: >> >> > >> > > > >--------------------------------- >Need to know the score, the latest news, or you need your Hotmail?-get your "fix" Check it out. > > >--------------------------------- > >Web Revelaci?n Yahoo! 2007: > Premio Favorita del P?blico - ?Vota tu preferida! >--0-1095273535-1200761640=:77597 >Content-Type: text/html; charset=iso-8859-1 >Content-Transfer-Encoding: 8bit > >Hi:
The TestPixmap does show a nice battery on LINUXLIBC6, Ubuntu Gutsy 2.6.22-14-386, 32 bits machine.

Thanks


Jay &l >t;jayk123 at hotmail.com> wrote:
I can repro the two > different behaviors on XP.
I was going to try on PPC_DARWIN but I guess Tony's info suffices.
 
I tried rolling hand.c back to > before I changed (months/year ago), since it is involved in bit twiddling, no change, phew.
 
Debugging here is a big humungous&nb >sp;pain.
NT386 has good stacks and line numbers, but no locals or type info, I'd really sometime like to get Codeview info into those .objs. >..I think it is documented well enough, but still not necessarily easy, or maybe have a C generating backend partly for this > reason (and to bring up more targets, using native tools), and function calls in disassembly I think don't resolve; NT386GNU can't yet bui >ld this, though it will soon, but I'm not familiar with gdb and there appears to be no type info. I'm building m3gdb right now, I don't know if >it will work, I hope it has type info, and I'm not familiar with the relevant code. In gdb I struggle just to view bytes in memory, add numbers >to addresses and see those, etc. I think for MY problem, I'm going to link in C code to dump the structs. There is tracing code and I enabled it >, but even it crashes in Text_Length. At least MY problem crashes, hopefully near the problem, whereas your problem goes all the way through to >completion with no stopping to hint where the problem is. Darn it. :) on the mock rudeness and :( on the lack of a crash.
 
You wri >te the bundle out and it matches, so that doesn't rule out bundles as being the problem? (darn)
And bundles look pretty > simple, a bundle is just a generated source file with a constant in it.
Maybe newline problems? That wouldn't make sense. I just downl >oaded some program that might let me separately view the ppm, maybe it'll reveal something.
 
The bad behavior has like regularly s >paced solid color veritical bars a few pixels side across the whole picture, and regularly spaced vertical stripes from the correct picture alte >rnating with that. Perhaps someone with ppm/bitmap/graphics experience has seen this behavior and it results from some common pixmap mismanageme >nt we could look for?
 
I have to say this is very surprising.
 
I always wondered, and now I pretty much assume -- Mo >dula-3 never imports/exports data in its dynamic linking, right? It alway imports/exports functions, right?
On Windows, functions have an op >tional optimization, but data must be handled differently at compile time if it is going to be dynamically imported.
For > functions, if you don't apply the optimization at compile time, the linker will just generate a single instruction thunk instead.
 
> That is, given a symbol Foo, there is a symbol __imp__Foo that is a pointer to the actual foo in another .dll/.so.
Th >e loader only patches pointers, one per import if you build your .dll correctly, it doesn't patch instructions or code strewn throughout a >.dll, just one contiguous array of pointers. MAYBE they don't have to be contiguous for each .dl you import from.
 
That is, if cal >l msvcrt!fopen, msvcrt!fclose, kernel32!Sleep, my .dll/.exe typically has an array:
 
pointer to msvcrt!fopen
pointer to msvcrt >!fclose
null
pointer to kernel32!Sleep
 
But perhaps kernel32.dll's pointers and msvcrt.dll's pointers need not be adjacent >.
 
So, going back, my point/question is that, if the compiler knows the function is imported, it can call > through __imp__Foo instead of calling Foo.
But if it calls Foo and you import Foo, the linker will create the function Foo that just jmps t >hrough __imp__Foo.
That doesn't work for data though. There's no ability to intervenve like that.
So for imported data, the compiler mus >t generated a read and dereference of the pointer __imp__Foo for accesses to Foo, if Foo is to be imported.
Data import >s may be faster when appropriate, but for this reason, I'd say they aren't worth it.
And for this reason, I HOPE Modula-3 never imports/expo >rts data.
 
Oh, you could, for data, always reference the pointer __imp_Foo, and if non materializes, create one.
However that >would suck perf in order to make an uncommon case work.
I hope Modula-3 doesn't do that either. :)
Though I guess since this global data > in question...maybe it is rare???
 
Later,
 - Jay



> From: > hosking at cs.purdue.edu
> Date: Sat, 19 Jan 2008 03:09:47 -0500
> To: rcoleburn at scires.com
> CC: m3devel at elegosoft.com
> >Subject: Re: [M3devel] pixmap problem
>
> Looks fine to me on I386_DARWIN.
>
> On Jan 19, 2008, at 12:31 AM, Randy Col >eburn wrote:
>
> > <TestPixmap.zip>
>


Need to know the score, the latest news, or you need your Hotm >ail?-get your "fix" Check it out.

> > >


Web Revelaci?n Yahoo! 2007:
Premio Favorita del P?blico - ?Vota tu preferida! >--0-1095273535-1200761640=:77597-- From rcoleburn at scires.com Thu Jan 24 03:51:41 2008 From: rcoleburn at scires.com (Randy Coleburn) Date: Thu, 24 Jan 2008 02:51:41 -0000 Subject: [M3devel] new problem on NT386 In-Reply-To: <20080123232310.5znrlsr5ywwgc4o0@mail.elegosoft.com> References: <4796B970.1E75.00D7.1@scires.com> <4796D0BA.1E75.00D7.1@scires.com> <20080123123937.onc4m6fa4gg8ogg0@mail.elegosoft.com> <479734AB.1E75.00D7.1@scires.com> <20080123193216.4hun5uus8hwksw88@mail.elegosoft.com> <47975558.1E75.00D7.1@scires.com> <20080123221001.8pbvhkjdc8408w80@mail.elegosoft.com> <47976D5F.1E75.00D7.1@scires.com> <20080123232310.5znrlsr5ywwgc4o0@mail.elegosoft.com> Message-ID: <4797B66F.1E75.00D7.1@scires.com> Olaf: Thanks. This is looking very promising now. Regards, Randy >>> Olaf Wagner 1/23/2008 5:23 PM >>> Quoting Randy Coleburn : > Olaf: > > I grabbed the new QMachine via cvs and rebuilt & shipped the m3quake > package, then rebuilt reactor (now cm3_ide) to take advantage of it. I > replaced the exec calls with cm3_exec(). > > At first glance, things were working better in that the output is now > going back to the browser. Great! > > But, when I tried to compile a simple "HelloWorld" program, I ran into > some errors. See attached PDF file. Does any of this make sense to > you? > > Note that this same HelloWorld program was compiling before the > QMachine change, its just that the output went to the wrong window. It seems I've made a mistake by forgetting to initialize the std file handles. Please try again, Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com ( http://www.elegosoft.com/ ) | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Fri Jan 25 05:44:41 2008 From: jayk123 at hotmail.com (Jay) Date: Fri, 25 Jan 2008 04:44:41 -0000 Subject: [M3devel] INSTALL_ROOT and PKG_USE in cm3.cfg In-Reply-To: <479907A8.1E75.00D7.1@scires.com> References: <4798DEB8.1E75.00D7.1@scires.com> <4798EFAE.1E75.00D7.1@scires.com> <4798FE0E.1E75.00D7.1@scires.com> <479907A8.1E75.00D7.1@scires.com> Message-ID: 1) the general user population could revert back to cminstall; nobody else complained except me (a common occurence), and Olaf did improve it; I'd have to deign to putting together such a distribution yuck. Perhaps when a nice GUI installer comes along it won't feel so bad. 2) Again, can you make the stuff you are working on available? To just some people? path() returns the directory of the currently executing Quake code. And in this case, the file is in the directory that contains cm3.exe, so it is cm3.exe's directory, which we know is INSTALLROOT\bin, so go up one with .. and we have INSTALLROOT. It's a little unsightly to have ".." in all the resulting paths, but I think it is worth it. It could be fixed in a number of ways. 1) add a function PathDotDot or PathUp to cm3 2) more generally add a function PathCanonicalize to cm3. Or heck, move more and more of this stuff into cm3. I asked about this recently -- what are the requirements for compatibility with older tools. It is that unanswered, and presuming "the worst", besides my persistant distaste for Modula-3, that keeps me writing Quake code.. - Jay Date: Thu, 24 Jan 2008 21:48:28 -0500From: rcoleburn at scires.comTo: jay123 at hotmail.com; jayk123 at hotmail.comCC: m3devel at elegosoft.comSubject: Re: [M3devel] INSTALL_ROOT and PKG_USE in cm3.cfg Jay: I've already edited my version of cm3.cfg to make it work for me. I don't know what the path() function does. The path() function is only used in the following code: if not defined("INSTALL_ROOT") if not equal ($INSTALLROOT, "") INSTALL_ROOT = $INSTALLROOT else INSTALL_ROOT = (path() & "\\..") endend Since this code is not executed when I define INSTALL_ROOT as "c:\\cm3", there is no need to remove it for my use. I've already confirmed that the other variables I need get set correctly inside CM3-IDE/Reactor once the INSTALL_ROOT is set properly. Note that a bunch of variables inside cm3.cfg depend on INSTALL_ROOT. I'm still want to find a solution for the general user population. Regards, Randy>>> Jay 1/24/2008 9:23 PM >>>Randy, don't worry, whatever you do, I'll be able to recover from. Just try editing your \cm3\bin\cm3.cfg file to say INSTALLROOT="c:\cm3" or whatever.Remove the path() function as a variable.See what happens. Maybe it's the problem, maybe not. It is something that I changed, and is worth trying the old way. Use write() and error() to print the other variables. Can you make the stuff you are working on available? To just some people? - Jay Date: Thu, 24 Jan 2008 21:07:29 -0500From: rcoleburn at scires.comTo: jay123 at hotmail.com; jayk123 at hotmail.comCC: m3devel at elegosoft.comSubject: Re: [M3devel] INSTALL_ROOT and PKG_USE in cm3.cfg Jay: Not sure exactly what you mean by:>I'm not sure what versions of cm3 have path(). I did think I saw it missing the other day. I assume you are not referring to the path env variable. Is this some built-in quake function or a function you have written in quake? The version of cm3.cfg that I am using is the one that *you* put in the minimal binary installation for windows. Reactor does indeed "run" the cm3.cfg in that it uses quake to load and interpret this file. What is the significance of doing the copy you suggest below? >In terms of my workflow, you can go ahead and copy NT386 to the config-no-install directory. I'll survive. I'm not trying to be obtuse here. It's just that you have been working on the windows distribution and all these scripts etc for a while now. I don't want to mess up anything you are doing and I know I don't have a deep understanding of all this, so I am reluctant to change anything like cm3.cfg for my needs. My goal is to make the CM3-IDE (old Reactor) available to everyone. As I said before, it does "run" the cm3.cfg and it needs to use this somehow to come up with a valid "PKG_USE" which should point to the "pkg" folder inside the cm3 installation root. Regards, Randy >>> Jay 1/24/2008 8:33 PM >>>I'm not sure what versions of cm3 have path(). I did think I saw it missing the other day.That could be your problem.m3cgcat also doesn't like my config file, it wants to open it to find TARGET, not sure it uses it at all, but it wants it. When I run mcgcat, I first put back a TARGET line in my cm3.cfg. And then remove it.This is very related.I would suspect that whoever reads the files MIGHT find it acceptable to RUN them.Running them doesn't mean compiling or linking or anything, those are functions that the "host" would chose to call or not. But toplevel can have arbitrary code so maybe this is not great. Reactor is a persistant web server though, right? It should be ok "running" the file, esp. since it doesn't start often. The "normal" alternative that other folks use is to run cminstall, which I find all but useless. In terms of my workflow, you can go ahead and copy NT386 to the config-no-install directory. I'll survive. Randy you should try debugging stuff. Quake is readily debuggabe through printing. if defined("path") write("path is defined") write("path is " & path())else write("path is not defined")enderror("") I put in error so I stop after my printing and don't go and build stuff when my intent was just to run a snippet of Quake. - Jay Date: Thu, 24 Jan 2008 20:06:09 -0500From: rcoleburn at scires.comTo: jay123 at hotmail.com; jayk123 at hotmail.comCC: m3devel at elegosoft.comSubject: RE: [M3devel] INSTALL_ROOT and PKG_USE in cm3.cfg Jay: That's the reason I asked before making a change. I don't want to break or mess up what you are doing. I can get around the problem easily for me. I just remove the comment from the %INSTALL_ROOT="c:\\cm3" and "everything" is ok. I'm hoping we can come up with a way that works for everyone. Once the CM3_IDE (formerly known as Reactor) package is in the repository and part of the standard distribution, it would be best if folks don't have to go around editing cm3.cfg to make it work properly. Now, you are saying your way is more automatic and portable. I like these words. Is there a way we can set something in cm3.cfg that I can key off of for CM3_IDE/Reactor? I don't mind changing the code to accommodate. The big thing for CM3_IDE/Reactor, is that it needs to know where to look for the cm3 installation because it has to find all of the subdirs, like doc, examples, etc. BTW, I still don't see why all this "works" since I am getting "\.." as my INSTALL_ROOT. Regards, Randy>>> Jay 1/24/2008 7:24 PM >>>Blech. My way is more automatic and "portable" in the sense that you can move installations around and they keep working. As well, with my way, you just extract an archive and go, no setup/cminstall, no editing of the cm3.cfg file, just set %PATH% and run vcvars, and vcvars I think I can remove the need for. path() is a builtin Quake function that returns the directory of the currently being run Quake code. But yet Reactor.To unblock yourself, remove my code, add back the commented out, fix the path to match your particular install, don't submit the file. Perhaps move the current checked in file over to the config-no-install directory and then put config's file back in the old style, that requires running cminstall. My workflow will keep working, since it probes for config-no-install first. - Jay Date: Thu, 24 Jan 2008 18:53:48 -0500From: rcoleburn at scires.comTo: jay123 at hotmail.comCC: m3devel at elegosoft.comSubject: [M3devel] INSTALL_ROOT and PKG_USE in cm3.cfg Jay: The cm3.cfg that comes with your minimal binary installation on Windows (NT386) has the following lines: ----------------------------------------- % INSTALL_ROOT = BEGIN_CONFIG% "Where should CM3 be installed?"% 7 %-- user specified install root% END_CONFIG % INSTALL_ROOT = "c:\\cm3" if not defined("INSTALL_ROOT") if not equal ($INSTALLROOT, "") INSTALL_ROOT = $INSTALLROOT else INSTALL_ROOT = (path() & "\\..") endend BIN_INSTALL = INSTALL_ROOT & "\\bin" % executablesLIB_INSTALL = INSTALL_ROOT & "\\lib" % librariesPKG_INSTALL = INSTALL_ROOT & "\\pkg" % packagesDOC_INSTALL = INSTALL_ROOT & "\\doc" % documentsEMACS_INSTALL = INSTALL_ROOT & "\\elisp" % emacs lisp codeMAN_INSTALL = INSTALL_ROOT & "\\man" % man pagesHTML_INSTALL = INSTALL_ROOT & "\\www" % public hypertext %% On some systems (e.g. AFS) you must install public files in a different% place from where you use them. If that is the case for your system,% specify the "use" location here, otherwise leave them alone.%%USE_ROOT = INSTALL_ROOTBIN_USE = BIN_INSTALL % executablesLIB_USE = LIB_INSTALL % librariesPKG_USE = PKG_INSTALL % packages ----------------------------------------- Notice that the lines for INSTALL_ROOT and USE_ROOT are commented out. The Reactor program is coded to grab several variables out of cm3.cfg. For example, build_dir := M3Config.Get ("BUILD_DIR"); system_root := M3Config.Get ("PKG_USE"); doc_root := M3Config.Get ("DOC_INSTALL"); initial_browser := M3Config.Get ("INITIAL_CM3_IDE_BROWSER"); initial_editor := M3Config.Get ("INITIAL_CM3_IDE_EDITOR"); What is happening on my installation is that PKG_USE winds up being "\..\PKG". This is not a valid path and it is causing all sorts of trouble for Reactor. The reason it is getting set this way is that the ELSE branch of the, if not defined("INSTALL_ROOT"), is getting executed resulting in INSTALL_ROOT=\.. I'm not sure why this is coded this way. How do you suggest this should be repaired? Note, I have not checked all of the cm3.cfg variants for the other target platforms, but in order for reactor to work properly, it must be able to find a valid "PKG_USE" in the cm3.cfg. Regards, Randy 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. Play now! 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 rodney.bates at wichita.edu Wed Jan 30 04:15:54 2008 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Wed, 30 Jan 2008 03:15:54 -0000 Subject: [M3devel] Sanity check request regarding CT arithmetic Message-ID: <479FEFA0.5040309@wichita.edu> 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